默认execute as caller无权限隔离，因所有操作均以调用者权限执行，易致数据泄露或注入；应显式设execute as owner或专用用户并严格校验上下文权限。
为什么默认EXECUTE AS CALLER等于没设权限隔离
SQL Server 存储过程默认就是 EXECUTE AS CALLER，不写这句也一样。这意味着：谁执行它，里面所有语句（包括 SELECT * FROM sys.tables、EXEC(@sql)）都用谁的权限跑。普通用户只要能 EXEC 这个过程，就可能顺手扫出系统表、跨库查数据、甚至触发动态 SQL 注入。
常见错误现象：The SELECT permission was denied on the object 'sys.tables'——不是过程写错了，是你没关掉 caller 模式，又没给用户授元数据权限；更危险的是，它根本不会报错，而是静默返回结果，把不该看的数据漏出去。
- 所有权链只在
EXECUTE AS OWNER或指定用户时才稳定生效，且要求所有被访问对象（表、视图、其他过程）属于同一 owner（比如全是dbo） - 跨 schema 访问（如
sales.Customers）会立即中断所有权链，除非两个 schema 的 owner 完全一致 -
EXECUTE AS SELF是坑：它把创建时的 login/user 名字硬编码进过程定义，DBA 换人后 owner 变更，过程直接执行失败
EXECUTE AS OWNER 是最稳的选择，但要注意 owner 身份本身是否干净
EXECUTE AS OWNER 让过程始终以创建者（通常是 dbo 或专用高权限账户）身份运行，调用者只需有 EXECUTE 权限，无需底层表的任何 SELECT/INSERT 权限。这是最常用、最可控的方式。
但前提是 owner 账户本身不能被滥用：
- 如果 owner 是
dbo，确保dbo对应的登录名（比如sa或某个 Windows account）不被普通用户直接登录或交互式使用 - 过程里别写
USE other_db或分布式查询——USER级别的上下文切换不继承服务器权限，这类操作会直接失败 - 创建语句必须显式声明：
CREATE PROCEDURE dbo.GetActiveOrders WITH EXECUTE AS OWNER AS ...
需要最小权限时，该用 EXECUTE AS 'username' 而不是 OWNER
当过程只更新某几张表的几个字段，或者要避免高权限账户被误用，就得建专用执行账户，比如 proc_executor：
- 该账户必须已存在，且数据库中已有对应
USER（不能只是 server-levellogin） - 只授予它过程内实际需要的权限，例如：
GRANT UPDATE ON dbo.Orders (Status, UpdatedAt) TO proc_executor - 禁用其交互式登录能力（不配密码、不加到 public 角色、不给
CONNECT权限） - 声明方式：
CREATE PROCEDURE dbo.UpdateOrderStatus WITH EXECUTE AS 'proc_executor' AS ...
注意：如果过程里还调用了另一个没设 EXECUTE AS 的过程，调用链会回落到 caller 权限，可能意外突破边界。
动态 SQL 和跨库访问是 EXECUTE AS 最容易翻车的地方
EXEC(@sql) 在 CALLER 模式下完全继承调用者权限，极易被注入利用；换成 OWNER 或指定用户后，它的执行范围就被严格框定——但这也意味着：你得确保拼出来的语句真能被那个上下文执行。
- 不要在
EXECUTE AS 'proc_executor'过程里写EXEC('SELECT * FROM master..spt_values')——proc_executor很可能没master的权限，会直接报错 - 三段式引用（
db.schema.table）会跳出当前数据库上下文，USER级切换无法覆盖，必须用LOGIN级切换（仅限本地 SQL Server，Azure 不支持）或改用同库对象+所有权链 - 若必须跨库，且目标库 owner 与当前过程 owner 不一致，要么统一 owner，要么显式
GRANT权限，别指望所有权链自动兜底
真正难的不是写对那行 WITH EXECUTE AS，而是想清楚：过程里每一句 SQL 在切换后的上下文里，到底有没有权限执行、会不会意外暴露元数据、调用链中途会不会掉回 caller——这些细节不逐条核验，权限控制就只是纸面安全。
