安全审计日志审查工作流

目标

审计日志在启用的那天满足合规，只有在有人持续阅读时才满足安全。按关切类别出查询让审查有界可重复，每条命中都有处置归类，未知项当日升级并要求解释——这才构成闭环的控制，而不是满足合规的仪式。

步骤要点

1. 定义关切类别：枚举审查要找什么——权限授予、非工作时段提权、密钥访问尖峰、break-glass 使用、批量导出，每类配一条查询。
2. 按计划跑类别查询：在审查窗口上执行，每类产出有界结果集，而不是读原始日志。
3. 每条命中都归类处置：预期（对应变更工单）、良性（例行自动化）、未知（需升级），无例外。
4. 带上下文升级未知项：把确切日志行发给账号 owner 及其经理，要求解释并关联到被授权的工作。
5. 从漏报中调优：事后分析发现本该被标记的动作时，为该类别新增或调整查询，清单保持活性。

排错提示

审查变成签字仪式是因为每次都面对海量原始日志，按类查询把结果集压到可真正阅读的量级；未知项发出去石沉大海是升级缺强制，让无响应自动触发访问冻结；某类别月月零命中不一定是太平，可能是查询的事件名过时了。

适用边界

类别查询的召回依赖审计日志的完备性，未打审计的系统是盲区要先行补齐；升级流程对人有成本，类别要挑高价值信号避免告警疲劳。

代码示例

-- class: permission grants (review window: 7d)
SELECT event_time, actor, action, target, ticket_ref
FROM audit_iam
WHERE action IN ('CreateRole', 'AttachPolicy', 'AssumeRole')
  AND event_time > now() - interval '7 days'
ORDER BY event_time DESC;

-- hits:
-- 10-21 02:14  svc-deployer  AttachPolicy  S3Full   ticket: NONE  -> UNKNOWN
-- 10-21 14:02  wei@team      CreateRole    db-ro    ticket: #4821 -> expected
-- 10-20 09:30  automation    AssumeRole    backup   ticket: n/a   -> benign

-- UNKNOWN -> escalated to owner + manager (same day)