SQL 审计日志设计与权限追踪技巧

sql 审计日志不是简单记录“谁执行了什么”，而是要支撑安全回溯、责任认定和合规检查。关键在于字段设计合理、采集粒度可控、权限变更可关联。

核心审计字段必须包含哪些

只记 SQL 语句或只记用户名远远不够。以下字段建议作为基础必填项：

• 执行时间（带毫秒+时区）：避免跨时区排查歧义，推荐用 timestamp WITH TIME ZONE 类型存储
• 客户端 IP + 主机名：区分是应用服务器代发还是 dba 直连，必要时可反向 DNS 验证
• 数据库用户 + 应用用户（如有）：例如 db_user='app_pool'，app_user='u12345' ，用于穿透权限代理场景
• 会话 ID / 连接 ID：串联同一次连接中的多条语句，识别事务边界
• SQL 摘要 + 参数化标识：对 DML/DDL 记录标准化后的语句模板（如 UPDATE users SET status = ? WHERE id = ?），避免敏感值落盘
• 影响行数（仅限 DML）：INSERT/UPDATE/delete 后由驱动返回的 rowcount，不依赖解析 SQL

权限变更必须单独建表追踪

GRANT/REVOKE 本身是 DDL，但混在通用审计流里易被忽略。建议独立表结构并触发强通知：

• 表名建议为 audit_privilege_changes，字段含：change_time, grantor, grantee, privilege_type（select/INSERT/ROLE）, object_type（table/SCHEMA/DB）, object_name, is_grant_option, is_with_hierarchy
• 对 postgres 或 pg_monitor 等高危角色赋权，自动触发企业微信/钉钉告警
• 定期比对 pg_roles 和历史授权记录，识别未登记的权限漂移

避免审计性能反噬业务

全量记录每条语句可能拖慢 OLTP 系统。需分层控制采集策略：

• 默认只记录 Error 级别及以上操作（如权限拒绝、语法错误、死锁中断），降低写入压力
• 对敏感表（如 users、payments）开启 STATEMENT 级别审计，无论成功失败都记
• 使用异步日志队列（如 kafka + Logstash）承接审计数据，数据库侧只做轻量写入
• 定期归档冷数据到对象存储，保留最近 90 天热数据供实时查询

权限与行为必须能交叉验证

单看权限列表不知是否真被使用；单看 SQL 日志不知执行者是否有权。两者需可关联分析：

• 审计日志中增加 effective_role_path 字段，记录当前会话实际生效的角色继承链（如 app_user → app_reader → pg_read_all_data）
• 在权限变更表中存快照式 role_inheritance_graph（JSONB），便于回溯某次查询发生时的真实权限上下文
• BI 工具中构建「用户-权限-操作」三元透视视图，支持按表、按角色、按时间段下钻