📚 课程目录第3章身份与访问管理审计

身份与访问管理审计：用户认证机制、MFA 与权限分离

身份与访问管理，说白了就是回答三个问题：你是谁？你能干什么？你干的事被记录了吗？

我在做安全审计时，见过太多公司在这上面翻车。有的连基础密码策略都没做好，有的 MFA 形同虚设，还有的权限给得比双十一优惠券还随意。嗯，这一章我们就来把这些坑一个个填上。

用户认证机制审计

认证是身份管理的第一个关卡。我习惯把它拆成三个层面来审：密码策略、会话管理、以及认证协议。

密码策略审计要点

先看一个典型的弱密码配置：

# 不安全的密码策略示例
password_policy:
  min_length: 6
  require_uppercase: false
  require_special: false
  max_age: 365  # 一年才换一次
  history_size: 3  # 只记住3个历史密码

这种配置，我曾在某金融科技公司的生产环境里见过。你想想看，6位纯数字密码，一年不换，跟没锁门有什么区别？

审计时我建议至少检查以下几点：

密码长度：不低于 8 位，推荐 12 位以上
复杂度要求：必须包含大写、小写、数字、特殊字符中至少三类
密码有效期：普通用户 90 天，管理员 60 天
历史记录：至少记住 5 个历史密码，防止循环使用
失败锁定：连续 5 次失败锁定 15 分钟

审计重点：不要只看策略配置文件，要实际验证。我曾经遇到过策略写得漂亮，但底层 LDAP 根本没生效的情况。用测试账号试一下，比看文档靠谱得多。

会话管理审计

认证通过后，会话管理就是下一个薄弱环节。我见过最离谱的是某系统会话超时设了 24 小时，员工下班不锁屏，第二天别人直接接着用。

会话审计的核心指标：

审计项	安全要求	常见问题
会话超时	空闲 15 分钟自动登出	超时时间过长或不设超时
并发会话	同一用户最多 2 个会话	无限制导致账号共享
会话令牌	使用 HttpOnly + Secure 标志	令牌暴露在 URL 或日志中
登出机制	服务端销毁会话	仅清除前端 Cookie

注意：很多系统只在前端清除 Cookie，服务端会话仍然有效。这意味着攻击者如果拿到了旧的会话 ID，依然可以冒充用户。审计时一定要验证服务端是否真的销毁了会话。

多因素认证（MFA）审计

MFA 不是装了就完事的。我审计过一家公司，他们给所有员工配了硬件令牌，但管理员账号居然可以绕过 MFA 直接登录。你猜怎么着？因为他们在代码里写了个「调试模式」。

MFA 覆盖范围审计

先画一张 MFA 覆盖的决策图，看看哪些场景必须启用：

MFA 实现方式审计

常见的 MFA 方式各有优劣，我整理了一个对比表：

MFA 方式	安全等级	用户体验	审计关注点
TOTP（如 Google Authenticator）	高	中	密钥生成是否安全？初始分发是否加密？
SMS 验证码	中	高	SIM 换卡攻击风险，建议降级使用
硬件令牌（如 YubiKey）	极高	低	丢失后的吊销流程是否完善？
生物识别	高	高	生物特征存储是否本地化？是否可被绕过？

我的建议：优先使用 TOTP 或硬件令牌。SMS 验证码虽然方便，但我在项目中遇到过两次 SIM 卡劫持攻击，损失惨重。如果非用不可，至少加上风控策略——比如异常地点登录时禁止使用 SMS。

权限分离与最小权限原则

权限审计是我最看重的一块。为什么？因为大部分数据泄露都不是外部黑客干的，而是内部权限滥用。

权限分离（SoD）审计

权限分离的核心思想是：一个人不能同时拥有互相冲突的权限。比如，不能既创建采购订单，又审批采购订单。

我习惯用「冲突矩阵」来审计。举个例子：

角色	创建用户	分配权限	审计日志	数据导出
系统管理员	✅	✅	❌	❌
安全审计员	❌	❌	✅	❌
数据管理员	❌	❌	❌	✅
普通用户	❌	❌	❌	❌

你看，系统管理员能创建用户也能分配权限，但就不能再看审计日志了——否则他删了日志你都不知道。

曾经踩过的坑：有一次审计发现，某公司的 DBA 账号既有数据查询权限，又有日志删除权限。我问他们为什么，回答是「方便排查问题」。嗯，方便是方便了，但数据被删了也查不出来是谁干的。最后我强制要求拆分成两个角色，DBA 查询和 DBA 审计分开。

最小权限原则审计

最小权限，说白了就是「给刚刚好的权限，不多给一丁点」。但实际执行起来，很多公司变成了「给刚刚够用的权限，然后多给一堆」。

审计时我重点关注这几个方面：

默认权限：新账号默认应该没有任何权限，而不是默认给个「普通用户」角色
权限继承：检查是否通过组继承获得了不必要的权限
临时权限：是否有过期机制？我见过临时权限给了三年还没收回的
权限回收：员工转岗或离职后，权限是否及时回收？

来看一个实际审计中发现的权限过度分配案例：

# 审计发现的过度权限配置
User: zhangsan
Role: developer
Effective Permissions:
  - read: /prod/database/customer_info  # 开发不需要读生产库
  - write: /prod/config/application.yml  # 开发不应该写生产配置
  - admin: /ci/cd/pipeline               # 开发不应该有 CI/CD 管理权限
  - delete: /logs/audit                  # 绝对不能有审计日志删除权限

这个案例里，一个普通开发居然有 4 项越权操作。我建议的修复方案是：

先回收所有权限，从零开始重新评估
按「职责所需」原则重新分配
加上「权限变更审批流程」
每季度做一次权限复核

审计小技巧：我每次做权限审计，都会导出一份「权限-用户」交叉表。然后随机抽 10% 的用户，找他们的直属上级确认「这个人真的需要这个权限吗？」。结果通常很有意思——至少有一半的权限是多余的。

审计检查清单

最后，给一份我常用的检查清单，审计时逐项核对：

审计项	检查内容	通过标准
密码策略	最小长度、复杂度、有效期、历史记录	符合行业标准（如 NIST SP 800-63）
会话管理	超时时间、并发限制、令牌安全	空闲 15 分钟超时，令牌 HttpOnly
MFA 覆盖	管理员、敏感系统、远程访问	100% 覆盖，无绕过路径
MFA 实现	密钥管理、备用码、恢复流程	密钥加密存储，备用码安全保管
权限分离	冲突角色、互斥权限	无一人身兼多职的冲突情况
最小权限	默认权限、权限继承、临时权限	默认无权限，临时权限有过期时间
权限回收	离职、转岗、合同到期	24 小时内完成回收

身份与访问管理审计，说到底就是跟「人性」作斗争。人总是图方便，但安全不能图方便。我做了这么多年审计，最大的体会就是：好的身份管理体系，应该让坏人进不来，好人也不觉得麻烦。嗯，这句话你可以记下来，面试的时候也能用。