如何优化SQL存储过程执行上下文_设置执行者身份与权限-SQL-PHP中文网

能，但仅限权限上下文而非操作系统级身份切换；它只改变权限检查路径，不改变登录会话、不触发新审计、不影响ORIGINAL_LOGIN()等函数值，且不跨实例传播。

如何优化sql存储过程执行上下文_设置执行者身份与权限

EXECUTE AS 能否真正切换执行者身份？

能，但仅限于权限上下文，不是操作系统级身份切换。SQL Server 的 EXECUTE AS 只影响语句运行时的权限检查路径，不改变登录会话归属、不触发新的登录审计、也不影响 ORIGINAL_LOGIN() 或 SUSER_SNAME() 的返回值。

常见误用是以为设了 EXECUTE AS USER = 'appuser' 就能绕过调用者权限限制——其实它只让存储过程内部语句以该用户身份去查 sys.database_permissions，若目标对象（比如某张表）没给该用户显式授权，照样报错 The SELECT permission was denied on the object 'Orders'...。

必须配合 GRANT 显式授权（不能依赖角色继承，除非角色在当前数据库中已存在且被授予权限）
EXECUTE AS OWNER 仅在模块所有者具备足够权限且未被显式拒权（DENY）时才可靠
嵌套调用中，EXECUTE AS 不自动传递；子过程需单独声明，否则回退到调用者上下文

EXECUTE AS 和 WITH EXECUTE AS 的区别在哪？

关键差异在作用域和持久性：WITH EXECUTE AS 是创建存储过程时绑定的执行上下文，每次调用都强制生效；而 EXECUTE AS 语句是运行时动态切换，需手动配对 REVERT，否则后续批处理仍处于切换后的上下文。

例如，在 SSMS 中执行：

EXECUTE AS USER = 'report_user';
SELECT * FROM Sales.SalesOrderHeader; -- 成功（假设已授权）
REVERT;
SELECT * FROM Sales.SalesOrderHeader; -- 可能失败（取决于当前登录权限）

若漏掉 REVERT，下一条语句仍以 report_user 身份执行，容易引发意料外的权限错误或日志混淆。

WITH EXECUTE AS 'user' 写在 CREATE PROCEDURE 语句末尾，不可在运行时更改
WITH EXECUTE AS CALLER 等价于不设，即始终用调用者上下文
使用 OWNER 时，Owner 必须是数据库用户（不能是 guest 或 public），且该用户不能被 DENY 相关权限

为什么 EXECUTE AS 后调用链接服务器总失败？

因为 EXECUTE AS 不跨实例传播——本地上下文切换不会让远程查询自动带上对应凭据。SQL Server 默认禁止“委托”（impersonation hop），这是安全限制，不是配置疏漏。

典型报错是：Msg 7411, Level 16, State 1: Server '' is not configured for DATA ACCESS. 或更隐蔽的 Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'（双跳 Kerberos 失败）。

启用数据访问只是第一步：EXEC sp_serveroption @server='RemoteSrv', @optname='data access', @optvalue='true'
若用 Windows 身份，需配置 Kerberos 约束委派（CCD），并在 AD 中为 SQL Server 服务账户设置「Trust this user for delegation to specified services only」
更可控的做法：改用 SQL 登录 + EXECUTE AS LOGIN（需 IMPERSONATE 权限），并在远程服务器上创建同名登录并授权

如何安全地清理 EXECUTE AS 堆栈？

不能依赖自动恢复。SQL Server 用栈管理上下文切换，每层 EXECUTE AS 都压栈，REVERT 弹出一层。存储过程中若含条件分支、异常处理（TRY/CATCH）或提前 RETURN，极易遗漏 REVERT。

最稳妥的方式是在 BEGIN TRY 前切换，在 END CATCH 末尾加 REVERT，并在主流程结尾再补一次——但更推荐根本性规避：优先用 WITH EXECUTE AS 声明式绑定，而非过程内动态切换。

SELECT SESSION_CONTEXT(N'exec_as_active') 无法检测当前是否处于 impersonated 状态
可用 SELECT SUSER_NAME(), USER_NAME() 对比判断是否已切换（前者是登录名，后者是当前数据库用户）
在调试时，执行 SELECT * FROM sys.dm_exec_sessions WHERE session_id = @@SPID，看 original_login_name 和 login_name 是否不同

真正的难点不在语法，而在权限拓扑设计：谁该拥有什么、在哪一级（服务器/数据库/模式/对象）授权、是否允许跨库引用、链接服务器凭据如何同步——这些决定了 EXECUTE AS 是简化还是加剧权限混乱。