触发器不能替代权限控制，必须配合细粒度权限管理、禁用ddl操作审计及禁用结果集返回。需收回全表update权、授予必要列权限、显式deny主键更新、分离开发与运维账号、部署ddl触发器审计disable trigger，并启用disallow results from triggers选项。
普通账号仍有UPDATE权限，触发器就形同虚设
只要用户对基表有UPDATE权限，就能绕过触发器直接写数据——触发器根本不会运行。这不是逻辑漏洞，是SQL Server的执行顺序决定的：权限检查 → 约束校验 → 触发器执行。一旦前两步通过，触发器才登场；而如果用户本就不该改某列（比如主键、状态字段），那必须先收走权限。
- 用
REVOKE UPDATE ON users FROM dev_user收回全表UPDATE权，只授必要列：GRANT UPDATE(name, email) ON users TO dev_user - 对主键列（如
id）显式拒绝更新：DENY UPDATE(id) ON users TO dev_user，DENY优先级高于GRANT - 避免使用
db_owner角色分配账号——哪怕只给一个开发库，db_owner也能DISABLE TRIGGER或ALTER TABLE
高权限用户能禁用触发器，必须堵住DISABLE TRIGGER路径
DISABLE TRIGGER不需要EXECUTE权限，只要对表有ALTER或CONTROL权限就能执行。常见错误是把触发器部署在开发账号下，而该账号同时是db_owner——一行命令DISABLE TRIGGER tr_protect ON users就让所有防护失效。
- 检查当前触发器状态：
SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('users') - 回收账号的
ALTER权限：REVOKE ALTER ON users FROM dev_user - 若需保留结构变更能力（如DBA运维），应分离账号：开发用低权限账号，DDL操作由专用运维账号执行
触发器本身不能替代权限控制，必须配合DDL审计
SQL Server不默认记录DISABLE TRIGGER操作，sys.dm_exec_sessions和默认错误日志里都看不到。攻击者禁用后修改数据，再启用触发器，整个过程无痕。
- 必须建DDL触发器捕获关键动作：
CREATE TRIGGER tr_audit_disable ON DATABASE FOR DISABLE_TRIGGER AS ... - DDL触发器作用域是
ON DATABASE，不是单张表；它能捕获DISABLE TRIGGER、ALTER TABLE等事件 - 注意：
EVENTDATA()返回XML，提取对象名要用.value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')
disallow results from triggers选项要设为1，防止触发器返回结果集干扰业务
触发器里写SELECT或未加SET NOCOUNT ON会返回结果集，某些ORM或连接池会因此报错或卡死。该行为已在SQL Server未来版本中标记为废弃，且默认值将在后续版本改为1。
- 立即生效的配置方式：
EXEC sp_configure 'disallow results from triggers', 1; RECONFIGURE; - 验证是否生效：
SELECT name, value_in_use FROM sys.configurations WHERE name = 'disallow results from triggers' - 设为1后，任何触发器内
SELECT都会抛出Msg 524错误，强制开发者清理副作用逻辑
