最可靠方案是在存储过程中用GRANT语句动态赋权并显式写入audit_log表；触发器不响应DDL，数据库审核日志缺失参数与被授权对象详情，无法满足闭环审计要求。
直接在存储过程中用 GRANT 语句动态赋权 + 显式写入 audit_log 表，是最可靠、可审计、可回溯的方案。触发器或外部审核工具无法捕获“谁调用了哪个过程、传了什么参数、给谁授了什么权”，只有过程内主动记录才能闭环。
为什么不能依赖触发器或数据库级审核做权限审计
触发器对 GRANT 语句完全无感——它只响应 INSERT/UPDATE/DELETE，不拦截 DDL；SQL Server 的数据库审核规范（DATABASE AUDIT SPECIFICATION）能捕获 GRANT 动作，但只记到 principal_name 和 object_name，不带参数、不记被授权对象列表、不区分是批量还是单条。你看到日志里只有 GRANT EXECUTE ON usp_GrantToTeam，却不知道这次调用实际给 user_a, user_b, role_dev 都加了 SELECT 权限。
存储过程内动态赋权的关键写法
必须用 EXEC sp_executesql 执行拼接好的 GRANT 语句，不能硬编码。参数需严格校验，避免注入和越权：
-
@target_list必须是预定义白名单（如从valid_users表查出），禁止直接接收逗号分隔字符串后EXEC('GRANT ... TO ' + @input) - 权限类型（
SELECT、EXECUTE等）必须从枚举值校验，不能由调用者自由传入 - 对象范围（schema.table、function、procedure）要解析并验证是否存在，防止跨库/跨 schema 提权
- 每条生成的
GRANT语句执行后，检查@@ROWCOUNT和ERROR_MESSAGE()，失败则中断并记日志
审计日志必须包含的字段与写入时机
日志不是可选项，而是赋权逻辑的组成部分。必须在事务内、与 GRANT 同一事务上下文中写入，否则主操作失败而日志已提交，或日志失败导致整个授权流程中断：
-
proc_name：硬编码字符串，如'usp_BatchGrant'，比OBJECT_NAME(@@PROCID)更准（嵌套调用时后者会变） -
granted_by：优先取应用层传入的@operator_login，不是CURRENT_USER（后者可能是代理账号） -
target_objects：JSON 格式，如'["Sales.Orders","Sales.Customers"]'，用CONCAT拼，不查系统视图 -
grant_statements：实际执行的完整GRANT语句（脱敏敏感字面量，如密码不记明文） -
start_time/end_time：统一用@log_time = SYSDATETIME()赋值，避免时钟漂移
高频批量场景下的性能与安全平衡
一次给 200 个用户授 5 类权限，别循环 1000 次 GRANT + 1000 次 INSERT INTO audit_log。正确做法是：
- 先用
INSERT INTO #grant_temp缓存所有待授权组合（user + object + permission） - 用
STRING_AGG批量生成GRANT语句，再用sp_executesql一次性执行（SQL Server 2017+） - 审计日志也先写进临时表
#audit_temp，最后INSERT INTO audit_log SELECT * FROM #audit_temp - 全程在
TRY...CATCH中，任一环节失败，整个事务回滚，日志也不留残迹
最易被忽略的是：权限变更后，没刷新连接池里的旧会话权限缓存。SQL Server 需要客户端重新登录，PostgreSQL 要 SET ROLE 或重连，MySQL 则依赖 FLUSH PRIVILEGES（仅部分版本）。这步不验证，就可能出现“日志写了，权限却没生效”的假成功。
