存储过程的执行身份决定了它能访问哪些表、视图和函数。SQL Server 默认基于所有权链机制判断权限：如果调用者拥有对存储过程的执行权限，而过程内部引用的对象与过程属于同一所有者，SQL Server 不会逐项检查底层对象的权限。这种方式虽然简化了授权，但容易让一个低权限用户通过精心构造的存储过程间接读取敏感数据。EXECUTE AS 提供了一个更直接的控制手段：你可以在创建或修改存储过程时指定 EXECUTE AS 子句，让过程体内的所有语句都以另一个安全上下文运行，而不是依赖隐式的所有权链。
为什么依赖所有权链还不够安全
所有权链的核心假设是：对象之间的引用关系是可信的，如果两个对象属于同一个 schema 或同一个数据库主体，权限检查就可以跳过。但在实际生产环境中，一个数据库往往由多个团队共同维护，表、视图、存储过程可能分属不同的 schema，所有权并不统一。当存储过程引用了其他 schema 下的表时，SQL Server 会重新检查调用者对该表的权限，这就导致调用者需要同时拥有过程执行权和底层表访问权。要么授予过多权限，要么存储过程根本无法运行。
更危险的是动态 SQL。在存储过程内部使用 EXEC(@sql) 或 sp_executesql 执行拼接字符串时，所有权链会被打破，因为动态 SQL 中的对象引用在编译时无法预先确定。调用者必须直接拥有对动态 SQL 所引用对象的权限，否则执行会失败。很多开发者为了省事，干脆给调用者授予 db_datareader 甚至 db_owner 角色，这直接放大了攻击面。EXECUTE AS 可以强制让动态 SQL 也运行在高权限模拟身份之下，但同时也要求我们严格管理这个模拟身份。
此外，隐式所有权链无法应对跨数据库访问。一个数据库中的存储过程访问另一个数据库的表时，需要开启跨数据库所有权链或者使用证书签名，配置繁琐且容易出错。通过 EXECUTE AS 指定一个具有目标数据库权限的登录名或用户，可以绕过部分跨库授权限制，让过程执行身份清晰可见。
EXECUTE AS 的四种模式及其权限边界
SQL Server 的 EXECUTE AS 子句支持多种执行上下文，理解它们之间的区别是安全设计的前提。最常见的是 EXECUTE AS CALLER，这是默认行为，表示过程以调用者的身份执行，底层对象权限仍然按照调用者来检查。它本身不改变权限模型，主要用于显式声明意图。
EXECUTE AS SELF 和 EXECUTE AS OWNER 分别表示以创建或修改过程的用户身份执行，以及以过程所属 schema 的所有者身份执行。SELF 在过程被 ALTER 时可能会变化，因为最后修改者成为了新的 SELF。OWNER 则相对稳定，只要 schema 所有者不变，执行身份就不变。这两种模式适合将底层表的权限封装在过程内部，调用者无需直接访问表。但要注意，如果过程被高权限用户创建，OWNER 可能是 dbo 或一个高权限账号，恶意调用者就能借助过程执行高权限操作。
最具灵活性的是 EXECUTE AS 'user_name' 或 EXECUTE AS 'login_name'，它可以把执行上下文切换为数据库中某个用户或服务器上的某个登录名。这种方式需要创建者拥有 IMPERSONATE 权限。例如，你可以创建一个名为 proc_executor 的数据库用户，只授予它对特定表的 SELECT 权限，然后让存储过程以该用户身份执行。这样无论谁调用过程，实际执行身份都是 proc_executor，权限边界明确且最小化。
不过，模拟指定用户或登录名会带来额外的管理负担。被模拟的用户不能属于系统管理员角色，密码策略也要合理配置；如果模拟的是登录名，还需要考虑服务器级别的权限继承。在审计场景中，EXECUTE AS 会让 SYSTEM_USER 返回模拟身份而不是原始登录名，因此建议同时记录 ORIGINAL_LOGIN() 以追踪真实调用者。
实际案例：用最小权限用户封装跨 schema 访问
假设数据库中有两个 schema：Sales 和 AuditLog。普通业务用户需要调用存储过程 Sales.RecordOrder，该过程既要向 Sales.Orders 表插入订单，也要向 AuditLog.OrderHistory 表写入审计记录。如果两个表属于不同 schema，所有权链无法连续工作，直接授予用户对两个表的写入权限过于宽泛。此时可以创建一个专用数据库用户 order_writer，只授予它对两个表的插入和更新权限，然后让存储过程以该用户身份执行。
-- 创建专用执行用户（不授予登录，仅数据库内使用）
CREATE USER order_writer WITHOUT LOGIN;
GRANT INSERT, UPDATE ON Sales.Orders TO order_writer;
GRANT INSERT ON AuditLog.OrderHistory TO order_writer;
-- 创建存储过程，执行上下文切换为 order_writer
CREATE PROCEDURE Sales.RecordOrder
@CustomerId INT,
@Amount DECIMAL(10,2)
WITH EXECUTE AS 'order_writer'
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO Sales.Orders (CustomerId, Amount, OrderDate)
VALUES (@CustomerId, @Amount, GETDATE());
INSERT INTO AuditLog.OrderHistory (CustomerId, Amount, LogTime)
VALUES (@CustomerId, @Amount, GETDATE());
END;
GO
-- 授予普通用户执行过程的权限
GRANT EXECUTE ON Sales.RecordOrder TO SalesStaff;
上面的代码中，order_writer 是一个 WITHOUT LOGIN 的数据库用户，它无法直接登录服务器，只作为权限容器使用。存储过程通过 WITH EXECUTE AS 'order_writer' 让过程体内的两条 INSERT 语句都以该用户的权限执行。调用者 SalesStaff 只需要拥有 EXECUTE 权限，不需要对两个表有任何直接访问权。这样即使 SalesStaff 成员尝试绕过过程直接查询表，也会被数据库引擎拒绝。
需要注意的是，EXECUTE AS 只影响过程执行期间的上下文切换，过程结束时会自动恢复到原始调用者。但是在过程内部如果使用了 REVERT 语句，也可以手动提前切换回调用者身份。如果不使用 REVERT，上下文会在过程结束时自动恢复。对于包含多个嵌套过程或需要精细控制权限的场景，手动 REVERT 能避免部分代码意外以高权限运行。
动态 SQL 与 REVERT 的配合技巧
存储过程中如果有动态 SQL，直接在字符串中拼接对象名或条件值风险很高，SQL 注入攻击可能让 order_writer 身份执行任意语句。即便使用了参数化查询，动态 SQL 本身仍然会打破所有权链，因此 WITH EXECUTE AS 在这里更有价值。示例如下：
CREATE PROCEDURE Sales.SearchOrders
@TableName sysname,
@MinAmount DECIMAL(10,2)
WITH EXECUTE AS 'order_writer'
AS
BEGIN
SET NOCOUNT ON;
DECLARE @sql NVARCHAR(MAX);
-- 使用 QUOTENAME 防止对象名注入
SET @sql = N'SELECT OrderId, CustomerId, Amount FROM '
+ QUOTENAME(@TableName)
+ N' WHERE Amount >= @MinAmount';
EXEC sp_executesql @sql, N'@MinAmount DECIMAL(10,2)', @MinAmount;
END;
GO
上面的动态 SQL 中，QUOTENAME 函数给表名加上方括号，可以防止表名中的特殊字符破坏语句结构，但并不能防止逻辑注入，例如传入 Sales.Orders; DROP TABLE Sales.Orders;-- 这样的恶意表名时仍会出问题。更稳妥的做法是先用白名单校验 @TableName，只允许特定的表名。无论怎样，动态 SQL 在 EXECUTE AS 'order_writer' 上下文中执行，它只能访问 order_writer 被授予权限的对象，即使发生注入，攻击者能造成的破坏也局限于该用户的权限范围。
有时你希望过程的一部分以高权限执行，另一部分以调用者身份执行，以便记录调用者自己的用户名。可以在过程中显式使用 REVERT 切换回原始上下文。例如：
CREATE PROCEDURE Sales.RecordOrderWithAudit
@CustomerId INT,
@Amount DECIMAL(10,2)
WITH EXECUTE AS 'order_writer'
AS
BEGIN
SET NOCOUNT ON;
-- 以 order_writer 身份插入订单
INSERT INTO Sales.Orders (CustomerId, Amount, OrderDate)
VALUES (@CustomerId, @Amount, GETDATE());
-- 切回调用者身份，记录真实用户
REVERT;
INSERT INTO AuditLog.UserAction (UserName, Action, ActionTime)
VALUES (SUSER_SNAME(), 'RecordOrder', GETDATE());
END;
GO
在这个例子中，前半部分以 order_writer 身份插入订单，然后调用 REVERT 恢复到过程调用者的安全上下文，再向审计表插入用户操作记录。SUSER_SNAME() 在 REVERT 之后返回的是原始登录名，而不是模拟身份。这能精确跟踪哪个真实用户发起了操作，同时订单写入仍享受最小权限。需要特别小心，若在 REVERT 之后还执行了需要高权限的语句，会因为权限不足而失败，因此要合理规划切换点。
常见陷阱与审计建议
最容易被忽略的问题是 REVERT 在循环或错误处理中的使用。如果过程启用了 TRY...CATCH，并且 REVERT 放在 TRY 块中提前执行，一旦后续代码抛出异常，上下文可能已经切换，但异常处理代码（CATCH 块）仍然运行在切换后的上下文中。更麻烦的是，如果 REVERT 没有执行，过程结束后上下文自动恢复，但如果在过程中嵌套调用了另一个同样使用 EXECUTE AS 的过程，模拟身份可能叠加，最终导致 REVERT 次数不匹配。建议在过程开头记录 ORIGINAL_LOGIN()，在关键分支前显式 REVERT，并在 CATCH 块中再次 REVERT 以确保状态一致。
另一个陷阱是模拟账号的密码过期或账户被禁用。如果存储过程指定 EXECUTE AS 'login_name' 模拟一个服务器登录名，而该登录名使用 SQL Server 身份验证且密码过期，存储过程的执行会直接失败。生产环境中应优先使用 WITHOUT LOGIN 的数据库用户作为模拟身份，避免依赖服务器登录名。模拟账号的权限要定期审计，防止因后续 GRANT 操作意外扩大。
从审计角度看，EXECUTE AS 会让 SYSTEM_USER 返回模拟身份而不是实际登录名，这给安全审计带来一定困扰。SQL Server 提供了 ORIGINAL_LOGIN() 函数，它始终返回最初连接到服务器的登录名，不受上下文切换影响。在记录敏感操作日志时，建议同时记录 ORIGINAL_LOGIN() 和 SYSTEM_USER，这样既能追踪到真实用户，也能看到实际执行时使用的模拟身份。此外，可以在服务器级别启用登录审核，或者使用扩展事件监控 impersonate 事件，及时发现有异常模拟行为的过程。
最后，要注意 EXECUTE AS 与跨数据库所有权链的交互。即使过程以 order_writer 身份执行，如果它访问另一个数据库中的表，而 order_writer 在目标数据库中没有对应用户，SQL Server 会尝试将其映射为 guest 用户，如果 guest 被禁用则访问失败。跨数据库场景最好通过证书签名模块或包含数据库用户来解决，EXECUTE AS 并不能完全替代跨库授权设计。理解这个限制可以避免在架构上产生错误依赖。
SQL存储过程EXECUTE AS执行上下文切换修改时间：2026-10-04 22:11:14