3、权限审计的基本原理归纳总结
3.1 到底什么是权限审计？
先问个问题：你给用户开了个权限，然后呢？
很多团队只关心“开权限”这一步，至于后面有没有人拿这个权限干坏事，没人管。权限审计，说白了就是事后翻旧账。
我经历过一个真实案例：某运维同事离职后，他的账号还挂在生产环境某关键密钥的审批名单里。三个月后才发现，他已经用那个权限把几台服务器上的日志全清了。要是当时有权限审计，第一时间就能发现账号异常。
权限审计的核心就三件事：
- 谁（主体）——哪个用户、哪个角色、哪个应用
- 对什么（客体）——哪把密钥、哪个接口、哪台机器
- 干了什么（操作）——申请、审批、执行、拒绝、修改
这三个要素缺一不可。你想想，如果只记了“张三申请了密钥”，不记他申请的是哪把密钥、申请后做了什么，审计就毫无意义。
subject、object、action三个字段设成非空。我踩过坑——早期只存了用户名，后来查问题根本对不上操作记录。
3.2 审计链条：从申请到归档
权限审计不是截个屏，而是一整条链。我习惯把它拆成四个阶段：
- 申请阶段——谁提交了什么权限需求，附带理由
- 审批阶段——第一个审批人、第二个审批人各自的操作时间、审批结果、备注
- 执行阶段——权限实际生效的时间、使用的IP、操作的密钥ID
- 复核阶段——定期或触发式复查，确认权限是否仍然合理
为什么非要四个阶段？因为很多权限失控就发生在“审批通过”到“执行”之间的空档。比如审批通过了，但执行脚本被篡改，实际给了更大权限。
| 阶段 | 关键记录 | 常见漏洞 |
|---|---|---|
| 申请阶段 | 申请人、申请时间、权限范围 | 理由字段为空，事后无法追溯业务原因 |
| 审批阶段 | 审批人列表、审批时间、审批结果 | 单人审批通过，无二次确认 |
| 执行阶段 | 执行人、实际生效配置、返回码 | 执行与审批结果匹配，但日志丢失 |
| 复核阶段 | 检核时间、是否通过、整改记录 | 复核频率过低，沉睡权限积压 |
3.3 双人审批的核心原理
为什么这篇课程一直在强调“双人审批”？因为单点故障太可怕了。
你想想，如果一个人就能批准密钥权限，那这个人的账号一旦被盗，整个密钥体系就完了。双人审批的本质是制衡——任何敏感操作必须经过两个不同的人确认。
这里面有两个关键设计：
- 互斥原则：两个审批人不能是同一个人，也不能属于同一个管理组。我曾经在项目里忘了做这个校验，结果两个人手动串通，还是过了双审。
- 不可跳过原则：任何接口调用，只要涉及敏感权限，都必须走完两次审批。不能有“紧急情况先执行后补单”的后门。后门一开，审计就形同虚设。
还有一种常见误区：觉得双人审批就是两个人点个同意就行。但实际上，真正的双人审批需要记录每个人的完整身份验证信息——比如每次审批都要重新登录、验证二次认证，而不是直接从会话里拿用户ID。我在调整一个金融系统的审计时发现，它们的双审记录里两个审批人竟然是同一个session ，等于一个人批了两次。
3.4 审计日志的可信与不可篡改
审计日志自己要是能被篡改，那整个审计就没意义了。
基本原则是：日志写入权限和普通用户权限隔离。生成日志的服务，只能用最小的写入接口，而且日志表不能有UPDATE、DELETE的权限。我习惯把日志扔到独立的数据库里，连应用服务器都不能直连，只能通过消息队列写入。
另外，时间戳必须使用NTP时钟源，避免服务器时间被回退。如果某条日志的时间比前一条还早，那肯定有问题。
3.5 一张图总结权限审计原理
下面这张SVG图，我把上面提到的核心要点画在了一起。你可以把它当成手边的速查卡片。
3.6 常见的审计模型对比
选哪种模型，取决于你对权限细粒度的要求。
| 模型 | 核心思想 | 适用场景 |
|---|---|---|
| RBAC（基于角色） | 用户通过角色获得权限 | 大部分内部系统，角色固定 |
| ABAC（基于属性） | 通过用户、资源、环境属性动态计算权限 | 云平台、细粒度多租户 |
| ReBAC（基于关系） | 权限继承自用户与资源的关系 | 社交平台、共享文档 |
在双人审批的场景下，RBAC相对容易实现——你只要控制“审批角色”必须由两个人担任就行。ABAC虽然灵活，但动态策略的审计日志更难做全。我个人更倾向于用RBAC做基线，再用属性扩展做例外规则。
3.7 这一章的核心印象
- 权限审计=主体+客体+操作，三者缺一不可
- 审计流程分四段：申请→审批→执行→复核，每段都要独立记录
- 双人审批的本质是制衡，必须互斥且不可跳过
- 日志要防篡改，时间要可信
- 模型选择要匹配业务，但双审机制通用
我把这些总结成一句话：审计不是为了让你管人，而是为了让系统在任何时候都能回答“谁在什么时候做了什么”。