1.2 AAA：认证、授权与审计

1.2 AAA：认证、授权与审计

本节摘要：AAA 是认证（Authentication）、授权（Authorization）、审计（Accounting）三个环节的合称，描述了"一个访问从进门到留痕"的完整生命周期。认证回答"你是谁"，授权回答"你能做什么"，审计回答"你做过了什么"。三者缺一，访问控制就会出现静默失效。本节承接 1.1 节的 CIA 目标层，把镜头转向行为层，通往 1.3 节的风险量化。

从一条登录日志说起

安全部门收到一条告警：某业务服务器的登录日志里，账号 deploy 在凌晨三点从一台陌生设备登录成功，两分钟后执行了一条导出客户表的命令。复盘会上争论激烈——有人说是"账号被盗"，有人说是"权限太大"，还有主管问"为什么没人发现"。

三种说法其实各对应 AAA 的一个失效点。"账号被盗"是认证失效：密码或密钥泄露，冒名者被当成本人。"权限太大"是授权失效：一个部署账号本不该有读取客户表的权限，越权操作畅通无阻。"没人发现"是审计失效：导出动作发生在凌晨，却没有实时告警，直到次日例行巡检才被翻出来。

一桩小事件，三个环节各漏了一截。这也是为什么 AAA 要绑成一个词来记：三者是同一条流水线上的三道工序，任何一道失守，前面工序的成果都会被清零。

验明正身：三个词的边界

认证（Authentication）：核实"你就是你声明的那个身份"。常见凭据从弱到强：知识因素（密码、PIN）、持有因素（手机验证码、硬件令牌）、生物因素（指纹、人脸）。认证只管身份本身，不管身份进来之后能干什么——这一点经常被误解，后文详述。

授权（Authorization）：决定"这个已认证的身份可以对哪些资源执行哪些操作"。授权模型有粗有细：最粗的是"登录即管理员"，细到极致的是按属性逐条判定的策略引擎（第 4 章会展开 RBAC、ABAC 等模型）。授权失败的表现不是"登不进来"，而是"进来了但该拦的操作没拦住"。

审计（Accounting）：把"谁、何时、从哪、做了什么、结果如何"记录下来以备追溯。审计的三要素是完整、防篡改、可检索。只记成功不记失败的日志是最常见的残废形态——而撞库攻击的痕迹恰恰全在失败记录里。

三者的依赖关系是单向的：授权以认证为前提，审计覆盖前两者。认证做再强，授权一刀切全员管理员，认证就形同虚设；前两者都到位，审计缺位，事件发生后连"发生了什么"都答不出来。

运作机理：一次访问的完整时序

下面用时序图走一遍标准流程。注意第四步：认证通过后，系统给访问者签发的是一张短期凭据（令牌），后续每个操作都要带着令牌做授权判定——认证只发生一次，授权判定却发生在每一次操作上。

看懂这张图，就能解释一个高频疑问：为什么登录成功之后，有些按钮还是灰的、有些接口还是报错？因为认证与授权是两道独立的闸门。登录成功只代表第一道开了，每个具体操作还要过第二道。

再看审计落地的最小样例。下面是一段标准化的登录日志，认证成败与来源都留了痕：

时间: 2026-03-14T02:47:11+08:00  事件: 认证失败
账号: deploy   来源IP: 203.0.113.77   方式: 密码   结果: 密码错误(第3次)
时间: 2026-03-14T02:47:25+08:00  事件: 认证成功
账号: deploy   来源IP: 203.0.113.77   方式: 密码+短信验证码   结果: 通过
时间: 2026-03-14T02:49:02+08:00  事件: 授权拒绝
账号: deploy   操作: 导出客户表   策略: 部署角色仅允许发布操作   结果: 拒绝
​

三个环节在同一份日志里各留一笔。对照本节开头那桩判例：如果这套日志当时配了实时告警（凌晨的异地登录）和授权拦截（部署角色禁读客户表），事件根本不会发生。AAA 不是三个产品，是三道必须都焊好的闸门。

工程实践要点

认证强度要分级。 内部 wiki 和生产数据库不能共用同一种认证强度。常见做法是按资产重要性分域：普通办公系统单因素即可，核心系统强制多因素（MFA 的机理与坑，第 4 章 4.1 节专门鉴定）。一刀切地全员上最强化验，代价是用户开始把验证码截图发进工作群——认证强度压过了人的承受力，反而催生新的绕过行为。

授权默认拒绝。 权限体系的黄金规则是"没写允许的就是禁止"。默认允许的体系会随着时间膨胀：每个人都会因为"临时需要"拿到一堆权限，而收回权限永远比授予难。定期做权限复核（回收半年未使用的授权）比上马任何新产品都见效。

审计要防篡改、要外送。 攻击者拿下一台机器后的标准动作之一就是清理本地日志。所以关键系统的日志必须实时外送到独立的日志服务器，并做只追加存储。这也是第 3 章 SIEM 存在的理由：散落各处的日志聚不起来，审计就只是硬盘上的一堆孤儿文件。

💡 关键直觉：排查任何"越权"类安全事件时，先分清是认证被绕过（假身份进来了）还是授权配错（真身份干了不该干的）。两者的修复动作完全不同，混着修会白干。

鉴定结论

• 认证解决身份真实性问题，授权解决权限边界问题，审计解决事后可追溯问题，三者串联成访问控制的完整闭环；
• 认证一次、授权多次：令牌机制是理解现代登录体系（第 4 章 SSO）的钥匙；
• 日志只记成功、日志只存本机，是审计环节最常见的半成品形态；
• 下一节回答一个更根本的问题：坏事发生的可能性，能不能算出来——威胁、漏洞与风险的换算框架。

附卷：三道闸门的快速体检单

给一套访问控制体系做体检，不必上重型评估，拿九个问题逐格打勾就够：

认证三问:
  1. 核心系统的口令策略与 MFA 覆盖率是多少? 特权账号是否 100% 双因素?
  2. 登录失败日志是否保留并有人看? 连续失败有没有自动处置?
  3. 密码找回流程的强度是否不低于登录本身?

授权三问:
  4. 新员工开通权限是按岗位模板还是按领导拍脑袋?
  5. 转岗员工的旧权限多少天内自动消失?
  6. 能否一键列出"某个账号能碰到的全部数据"? (反向查询能力)

审计三问:
  7. 关键系统日志是否实时外送独立存储?
  8. 特权操作是否全程留痕且绑定到自然人?
  9. 上一次用日志成功定位异常, 是什么时候?
​

九问里答不上三问，说明体系是纸面的。特别点一下第 6 问：很多权限体系只回答"这个数据谁能看"（正向），答不了"这个人能看哪些数据"（反向）。反向查询是离职清理、事件波及面评估（6.3 节）和合规数据主体权利响应（6.2 节）共同的基础设施，缺了它三件事都要靠人肉翻配置。

再补一个经常被忽略的交汇点：密码重置是三道闸门的十字路口。重置动作本质是"用替代凭据完成认证"，重置后往往触发"权限确认"，而全过程必须留痕。攻击者也深谙此道——重置流程历来是认证绕过的首选通道（4.1 节的恢复流程后门在此呼应）。体检时给重置流程的权重，应该不低于登录本身。