如何应对通过SSMS登录SQL Server绕开应用逻辑的权限问题？

核心应对方案 #

• 账户权限拆分：不给终端用户直接的表修改权限，哪怕是Windows账户。为COTS应用单独创建专用服务账户，仅赋予该账户应用运行所需的最小权限（比如仅能执行COTS调用的特定操作）；终端用户的Windows账户只分配只读权限或完全禁止直接访问表，迫使他们只能通过应用操作数据。
• 限制SSMS登录场景：若必须开放部分用户的SSMS访问权限，使用带容错逻辑的服务器级登录触发器，避免之前锁死登录的问题。示例逻辑如下：

CREATE TRIGGER RestrictNonAppLogin
ON ALL SERVER WITH EXECUTE AS 'sa'
FOR LOGON
AS
BEGIN
    -- 优先排除管理员账户，防止锁死自身
    IF ORIGINAL_LOGIN() IN ('DOMAIN\DBAdmin', 'sa')
        RETURN;

    -- 拒绝SSMS等非应用程序的登录请求
    IF APP_NAME() LIKE '%Microsoft SQL Server Management Studio%'
    BEGIN
        ROLLBACK;
    END
END;

• 精细化权限控制：对确需修改数据的用户，启用SQL Server的行级安全（RLS）和列级权限，限制他们仅能操作权限范围内的数据，即便通过SSMS登录也无法越权。
• 审计追溯：开启SQL Server扩展事件或SQL审计功能，记录所有直接修改表的操作，一旦出现违规操作可快速追溯责任人，形成事后威慑。

避免触发器锁死登录的关键 #

之前触发器导致无法登录，通常是因为未排除特权账户或逻辑存在漏洞。务必在触发器中先判断登录账户是否为管理员/特权账户，直接跳过后续逻辑；且所有触发器需先在测试环境验证无误后，再部署到生产环境。

COTS应用的适配要点 #

由于COTS无法修改代码改用存储过程，核心思路放在账户隔离：让COTS使用专用服务账户连接数据库，而非终端用户的Windows账户。多数COTS支持单独配置数据库连接账户，只需给该账户分配应用所需的最小权限即可。

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