execute as 能切换权限上下文但仅限执行栈内，受主体类型与签名约束；execute as user 限于数据库作用域，execute as login 支持服务器级访问，跨库需目标库存在对应用户并授权。
EXECUTE AS 能否真正切换用户权限上下文
能，但仅限于当前执行栈，且受主体类型和签名严格约束。EXECUTE AS 不会改变会话级登录身份，只影响后续语句的权限检查依据——即“谁在调用对象”被临时替换为指定主体（USER、LOGIN 或 CALLER）。常见错误是以为它等同于 sudo 或会话级身份切换，结果发现 SELECT USER_NAME() 返回了预期值，但访问视图仍报 The SELECT permission was denied——这往往是因为目标用户没被显式授予权限，或未启用模块签名。
EXECUTE AS USER vs EXECUTE AS LOGIN 的权限差异
关键区别在于作用域和凭据继承：
-
EXECUTE AS USER = 'app_reader'：仅切换数据库用户上下文，不继承服务器级权限（如VIEW SERVER STATE），也不能跨库访问未显式授权的其他数据库对象 -
EXECUTE AS LOGIN = 'svc_login'：切换至服务器登录，可访问该登录被授予的任意数据库资源（前提是目标库中存在对应用户并已授权），但要求调用者拥有IMPERSONATE权限，且该登录不能是sa或禁用账户 - 若存储过程内需读取
master.sys.dm_exec_sessions，必须用EXECUTE AS LOGIN并确保该登录有VIEW SERVER STATE
为什么 EXECUTE AS 后仍提示“拒绝访问”，即使用户有权限
最常被忽略的三个原因：
- 目标用户（如
'app_user'）在当前数据库中存在，但未被授予对具体对象（如表orders）的SELECT权限——EXECUTE AS不自动继承角色权限，需显式执行GRANT SELECT ON orders TO app_user - 存储过程本身未用
WITH EXECUTE AS定义，而是运行时用EXECUTE AS语句切换——后者只对后续语句生效，不保护整个过程体；正确做法是在创建时声明：CREATE PROC dbo.GetOrders WITH EXECUTE AS 'app_reader' - 过程引用了跨架构对象（如
hr.employees），但app_reader只在dbo架构有权限——需额外授权：GRANT SELECT ON hr.employees TO app_reader
安全边界：如何防止 EXECUTE AS 被滥用绕过权限检查
SQL Server 默认允许嵌套 EXECUTE AS，但这会模糊调用链路。生产环境应主动限制：
- 避免在动态 SQL 中拼接
EXECUTE AS，例如EXEC('EXECUTE AS USER = ''' + @user + '''')—— 这属于权限提升漏洞，SQL Server 2016+ 会直接报错Msg 3272, Level 16 - 使用模块签名替代明文
EXECUTE AS：对存储过程签名，然后将证书用户授予权限，这样既免去EXECUTE AS的隐式信任链，又支持跨数据库调用 - 检查当前上下文是否已被切换：在关键逻辑前加
IF ORIGINAL_LOGIN() USER_NAME() RAISERROR('Context switched - audit required', 16, 1)
真正难的是权衡：既要让过程以最小权限运行，又要避免频繁签名和证书维护。多数团队卡在“该不该给 EXECUTE AS OWNER”——其实 owner 是过程创建者，如果创建者是 dbo，那等于开了个后门；更稳妥的是绑定到一个专用低权限用户，并用证书签名兜底。
