ddl触发器无法可靠监控dba真实操作行为，因其仅识别连接账户（如sa），无法区分运维脚本与人为误操作，也无法获取ip、应用名等业务上下文；应改用sql server audit，它可原生捕获server_principal_name、client_hostname、application_name等完整上下文信息，并通过服务器级审计规范记录drop database、truncate table等高危操作。
DDL 触发器不能可靠监控 DBA 账户的真实操作行为——它看到的只是连接账户（如 sa 或 sysadmin 成员），不是业务上下文中的“谁点了这个按钮”或“哪个应用发起的请求”。真要审计高危操作，得放弃触发器，改用 Extended Events 或 SQL Server Audit。
为什么 DDL 触发器对 DBA 操作监控失效
DBA 通常用固定账号（如 sa、db_owner）连接数据库，所有操作都归到这个账号下。触发器里调 CURRENT_USER() 或 ORIGINAL_LOGIN() 返回的永远是这个账号，无法区分：是运维脚本在删表，还是某人手抖执行了 DROP TABLE；也无法知道来源 IP、应用名、执行时间戳是否异常。
哪些高危操作必须被记录（而非拦截）
-
DROP DATABASE、TRUNCATE TABLE、ALTER DATABASE SET TRUSTWORTHY ON -
sp_configure 'xp_cmdshell', 1+RECONFIGURE组合 -
CREATE LOGIN ... WITH PASSWORD或ALTER SERVER ROLE sysadmin ADD MEMBER
这些操作本身合法，但需留痕、告警、关联上下文。触发器做不到关联上下文，而 SQL Server Audit 可以原生捕获：server_principal_name、client_hostname、application_name、statement 全字段。
正确做法：用 SQL Server Audit 替代触发器
创建服务器级审计对象，捕获关键 DDL 事件：
CREATE SERVER AUDIT [DBA_Action_Audit] TO FILE (FILEPATH = 'C:\Audit\') WITH (ON_FAILURE = CONTINUE); CREATE SERVER AUDIT SPECIFICATION [DBA_DDL_Spec] FOR SERVER AUDIT [DBA_Action_Audit] ADD (SCHEMA_OBJECT_CHANGE_GROUP), ADD (DATABASE_OBJECT_CHANGE_GROUP), ADD (SERVER_OBJECT_CHANGE_GROUP), ADD (SERVER_PERMISSION_CHANGE_GROUP); ALTER SERVER AUDIT [DBA_Action_Audit] WITH (STATE = ON); ALTER SERVER AUDIT SPECIFICATION [DBA_DDL_Spec] WITH (STATE = ON);
注意点：
- 审计日志路径
C:\Audit\必须由SQL Server服务账户有写权限 -
SCHEMA_OBJECT_CHANGE_GROUP覆盖DROP/CREATE/ALTER TABLE，但不包含TRUNCATE（需单独加BATCH_COMPLETED_GROUP并过滤语句） - 审计启用后，日志默认二进制格式，查时用
sys.fn_get_audit_file()，别指望直接打开 .sqlaudit 文件
最常被忽略的细节
审计配置生效后，日志本身成了最高敏感数据——如果攻击者拿到 C:\Audit\ 目录写权限，就能清空或伪造日志。必须同步管控：NTFS 权限仅限 SQL Server 服务账户 + 审计管理员，定期导出归档，且禁用任何账号对审计对象的 ALTER 或 DROP 权限（包括 sysadmin，可用 DENY ALTER ANY SERVER AUDIT TO [public] 锁死）。
