sql server存储过程实现分级权限控制必须显式使用execute as切换执行上下文；默认caller模式无隔离，推荐owner或专用账户如proc_executor，并确保所有权链完整、避免execute as self。
不能直接在存储过程内部“切换用户”执行语句——EXECUTE AS 是定义时的属性，不是运行时的控制流指令。
EXECUTE AS 在 CREATE PROCEDURE 中的作用
SQL Server 允许你在创建存储过程时用 EXECUTE AS 指定执行上下文，但这是编译期绑定的权限模型，不是运行时动态切换。它决定的是“谁来承担该过程内所有操作的权限校验责任”，而非“临时以某人身份跑几行 SQL”。
- 常见写法：
CREATE PROCEDURE [sales].[usp_GetOrderSummary] WITH EXECUTE AS 'app_user' - 效果：过程内所有语句（包括 SELECT、INSERT、动态 SQL）都按
app_user的权限检查，而不是调用者的权限 - 注意：
EXECUTE AS后面必须是数据库中已存在的USER名（不是登录名），且该用户需有对应架构/对象访问权；若指定OWNER或CALLER，行为完全不同
为什么不能在过程体里写 EXECUTE AS USER = 'xxx'
你不能在 BEGIN...END 块里执行 EXECUTE AS USER = 'xxx'，因为该语句要求调用者拥有 IMPERSONATE 权限，而普通用户默认没有——即使你是 db_owner，也不自动获得对其他用户的模拟权。
- 错误现象：
The server principal "app_user" is not able to impersonate the user "admin_user" - 根本原因：模拟权限（
IMPERSONATE）是显式授予的独立权限，和EXECUTE无关 - 如果你真需要运行时切换，必须先由高权限账户执行：
GRANT IMPERSONATE ON USER::[admin_user] TO [app_user]; - 但此举大幅削弱安全边界，不推荐用于生产环境
替代方案：用模块签名（Module Signing）代替 EXECUTE AS
当你要让低权限用户执行涉及敏感表的操作（比如写日志、查配置），又不想开 IMPERSONATE，模块签名是更可控的选择。
- 流程：创建证书 → 用证书给存储过程签名 → 授予证书对应的用户权限 → 用户调用过程即可间接获得那些权限
- 优势：权限只作用于被签名的对象，不会扩散；撤销签名即失效；不依赖所有权链或用户模拟
- 关键命令示例：
ADD SIGNATURE TO [sales].[usp_GetOrderSummary] BY CERTIFICATE [LogWriterCert]; - 陷阱：证书用户（
CERTIFICATE MAPPING创建的用户）不能是guest或dbo，且必须显式授予权限（如SELECT ON [logs].[AuditTrail]）
最容易被忽略的细节：EXECUTE AS 的作用域与清理
EXECUTE AS 定义在过程上，但它会影响整个调用链——如果这个过程再调用另一个带 EXECUTE AS 的过程，后者会覆盖前者，且 REVERT 不会自动回滚嵌套上下文。
- 后果：一个被
EXECUTE AS OWNER的过程调用了另一个EXECUTE AS 'sysadmin'的过程，后者执行完后，权限仍停留在sysadmin上下文，直到显式REVERT - 风险：可能意外暴露高权限操作路径，尤其在动态 SQL 场景下
- 建议：所有含
EXECUTE AS的过程，结尾务必加REVERT;（哪怕只是防御性写法） - 验证方式：在过程内加
SELECT USER_NAME(), SUSER_SNAME();确认当前执行主体是否符合预期
