MS SQL-SERVER 2016：如何阻止SA模拟特定用户并规避权限风险？

首先得明确一个关键事实：SA账号属于服务器角色sysadmin的成员，默认拥有IMPERSONATE ANY USER的服务器级权限——这就是你执行REVOKE IMPERSONATE ON USER::HeadOffice TO SA无效的原因，因为服务器级的权限优先级高于数据库级的撤销操作。只要是sysadmin角色的账号，本质上可以绕过大部分数据库级安全控制，包括行级安全（RLS）。

针对客户自行托管且持有SA权限的场景，以下是几个可行的规避思路，虽然无法完全阻止SA级别的操作，但能大幅提高绕过的门槛并降低风险：

1. 限制SA账号的使用，改用权限受限的管理员账号 #

这是最有效的核心措施：

• 首先禁用SA账号，执行ALTER LOGIN sa DISABLE;，然后创建一个自定义的服务器管理员账号（比如CustomerAdmin），仅授予其必要的服务器权限，而非直接加入sysadmin角色。
• 对于客户的运维需求，拆分权限：比如只给ALTER ANY DATABASE、VIEW SERVER STATE等必要权限，避免赋予IMPERSONATE ANY USER或ALTER ANY SECURITY POLICY这类高危权限。
• 向客户解释SA权限的风险：SA是内置的最高权限账号，一旦泄露或被滥用，整个数据库的安全机制都会失效，改用自定义管理员账号能在合规性和安全性上双赢。

2. 强化行级安全策略的过滤逻辑 #

修改RLS的过滤函数，加入对原始登录账号的校验，防止SA通过EXECUTE AS模拟合法用户：
比如你的原有过滤逻辑可能是：

CREATE FUNCTION dbo.fn_SecurityPredicate(@UserId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Result
WHERE USER_NAME() = 'HeadOffice' 
OR EXISTS (SELECT 1 FROM dbo.UserFeatures uf WHERE uf.UserId = @UserId AND uf.FeaturePurchased = 1);

可以修改为加入ORIGINAL_LOGIN()的校验，只允许指定的合法登录（比如总部的专用登录HeadOfficeLogin）来使用HeadOffice用户的权限：

CREATE FUNCTION dbo.fn_SecurityPredicate(@UserId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS Result
WHERE 
    -- 允许原始登录为总部专用账号的会话
    ORIGINAL_LOGIN() = 'HeadOfficeLogin'
    -- 允许合法的应用用户访问已购买功能的行
    OR EXISTS (SELECT 1 FROM dbo.UserFeatures uf WHERE uf.UserId = @UserId AND uf.FeaturePurchased = 1);

这样即使SA执行EXECUTE AS USER = 'HeadOffice'，ORIGINAL_LOGIN()仍然是'sa'，会被过滤逻辑拒绝，无法获取数据。

3. 防止SA直接禁用行级安全策略 #

虽然sysadmin能修改安全策略，但你可以通过以下方式增加难度：

• 给RLS的安全策略加上WITH (STATE = ON)，并通过数据库级的DML触发器监控ALTER SECURITY POLICY操作，一旦检测到非授权的修改，自动回滚并记录日志：

CREATE TRIGGER trg_PreventRLSModification
ON DATABASE
FOR ALTER_SECURITY_POLICY
AS
BEGIN
    IF ORIGINAL_LOGIN() NOT IN ('HeadOfficeLogin', 'AuthorizedAdmin')
    BEGIN
        RAISERROR('修改行级安全策略需要授权', 16, 1);
        ROLLBACK TRANSACTION;
        -- 记录审计日志到专用表
        INSERT INTO dbo.SecurityAudit (EventTime, LoginName, Action)
        VALUES (GETDATE(), ORIGINAL_LOGIN(), 'Attempted to alter RLS policy');
    END
END;

• 同时，将安全策略所在的架构设置为仅授权用户可修改，进一步限制操作入口。

4. 启用审计监控，威慑违规操作 #

通过SQL Server的审计功能，跟踪所有高危操作，让客户能及时发现SA账号的滥用：

• 创建服务器级审计，监控IMPERSONATE_USER、ALTER_SECURITY_POLICY、DISABLE_SECURITY_POLICY等事件：

CREATE SERVER AUDIT Audit_HighRiskActions
TO FILE (FILEPATH = 'D:\SQLAudits\', MAXSIZE = 100 MB);
ALTER SERVER AUDIT Audit_HighRiskActions WITH (STATE = ON);

CREATE DATABASE AUDIT SPECIFICATION Audit_RLSAndImpersonation
FOR SERVER AUDIT Audit_HighRiskActions
ADD (IMPERSONATE_USER ON DATABASE::YourAppDatabase BY public),
ADD (ALTER_SECURITY_POLICY ON DATABASE::YourAppDatabase BY public),
ADD (DISABLE_SECURITY_POLICY ON DATABASE::YourAppDatabase BY public);
ALTER DATABASE AUDIT SPECIFICATION Audit_RLSAndImpersonation WITH (STATE = ON);

审计日志会记录所有相关操作的时间、登录名和操作内容，即使SA能绕过RLS，也会留下不可磨灭的痕迹，对恶意操作形成威慑。

5. 补充数据加密（可选） #

如果敏感数据需要更强的保护，可以启用透明数据加密（TDE）加密整个数据库，或者对核心列使用列级加密。这样即使SA能访问表，也无法直接读取明文数据，进一步降低数据泄露的风险。

最后要明确：只要客户持有sysadmin级别的权限，理论上没有100%的方法阻止他们绕过数据库级安全控制，但以上措施能大幅提高攻击成本，同时通过合规性要求和风险沟通，引导客户减少SA账号的使用，这才是最根本的解决方案。

内容的提问来源于stack exchange，提问作者Matthew Baker