3. 身份与访问管理（IAM）：统一身份认证、单点登录（SSO）、多因素认证（MFA）实战配置
零信任的核心原则，说白了就是「永不信任，始终验证」。但验证谁？怎么验证？验证完怎么授权？这三个问题，就是 IAM 要解决的事。
我在不少项目里见过一种通病：公司上了零信任网络，但身份认证还停留在「用户名+静态密码」阶段。结果呢？攻击者只要搞到一组凭证，整个网络就形同虚设。所以，IAM 是零信任的第一道门，也是最后一道防线。
3.1 统一身份认证：把散落的用户源收拢
很多企业早期业务扩张快，每个系统都有自己的用户表。CRM 一套、ERP 一套、OA 又一套。员工离职了，OA 账号关了，但 CRM 的账号还活着。这就是身份孤岛。
统一身份认证要做的，就是把所有用户源收拢到一个中心。我习惯叫它 IdP（身份提供者）。
核心思路：所有应用不再自己管用户，而是把认证委托给 IdP。IdP 统一管理用户生命周期——入职、转岗、离职，都在一个地方操作。
实战中，常见的 IdP 方案有这些：
| 方案 | 适用场景 | 我踩过的坑 |
|---|---|---|
| LDAP / OpenLDAP | 传统企业、内部工具 | 树形结构设计不好，后期迁移很痛苦 |
| Azure AD / Entra ID | 微软生态、Office 365 用户 | 同步延迟问题，曾导致新员工半天登不上系统 |
| Keycloak（开源） | 自建、云原生、容器化 | 配置复杂，但灵活度最高 |
| Okta / Auth0 | SaaS 为主、全球化 | 成本偏高，小团队慎入 |
我个人建议，中小团队优先考虑 Keycloak。开源、社区活跃、支持标准协议（OIDC、SAML、LDAP）。我去年帮一家金融科技公司搭 IdP，就是用 Keycloak 对接了他们的 HR 系统，实现了自动入职/离职同步。
小技巧：IdP 的用户源不要只依赖一个。最好同时对接 HR 系统（权威源）和 AD（存量源），以 HR 数据为准，定期做 reconcile。
3.2 单点登录（SSO）：一次登录，到处通行
统一了用户源，接下来就是 SSO。用户只需要登录一次，就能访问所有授权的应用。
嗯，这里要注意：SSO 不是把密码共享给所有应用。而是通过 Token 或 Ticket 来传递认证状态。
主流协议就两个：
- OIDC（OpenID Connect）：基于 OAuth 2.0，适合现代 Web 和移动端。返回的是 ID Token（JWT 格式）。
- SAML 2.0：基于 XML，老牌协议，适合企业级 SaaS 和传统应用。
我曾经在一个项目里，非要让一个 2005 年开发的旧系统支持 OIDC。折腾了两周，最后发现它只支持 SAML。所以，不要跟协议较劲，兼容才是王道。
实战配置步骤（以 Keycloak + OIDC 为例）：
- 创建 Realm：相当于一个租户或项目空间。
- 创建 Client：代表你的应用，配置回调 URL（Redirect URI）。
- 配置用户和角色：可以直接建用户，也可以对接 LDAP。
- 应用集成：在应用代码里引入 OIDC 客户端库（比如 Spring Security、Passport.js）。
- 测试 SSO 流程：登录一次，访问多个应用，确认 Token 刷新正常。
避坑指南：我曾经遇到过回调 URL 没配 HTTPS，导致浏览器拦截重定向。还有一次是 Token 过期时间设得太短（5 分钟），用户写个文档的功夫就被踢出去了。建议：Access Token 15-30 分钟，Refresh Token 8-24 小时。
3.3 多因素认证（MFA）：密码不够，再加一把锁
密码泄露是常态。光靠密码，你挡不住撞库、钓鱼、暴力破解。MFA 就是在密码之外，再加一个验证因子。
常见的因子类型：
- 知识因子：密码、PIN 码（你知道的）
- 持有因子：手机、硬件 Key、TOTP 验证码（你拥有的）
- 固有因子：指纹、人脸、声纹（你是什么）
零信任场景下，至少启用两种不同的因子。我个人习惯是「密码 + TOTP」作为标配，高权限操作再加硬件 Key（比如 YubiKey）。
实战配置 MFA（以 Keycloak 为例）：
- 进入 Realm 设置 → Authentication → Flows。
- 复制默认的 Browser Flow，重命名为
Browser with MFA。 - 在 Browser Flow 里添加执行器：
OTP Form。 - 配置 OTP 策略：算法（SHA1/SHA256）、位数（6位）、有效期（30秒）。
- 绑定 Flow 到应用的 Authentication Flow。
- 用户首次登录时，会被引导绑定 TOTP（扫码或手动输入密钥）。
关键点：MFA 不要一刀切。内部网络、低风险操作可以跳过 MFA；外部访问、敏感操作必须 MFA。这叫 自适应 MFA（Adaptive MFA）。
我曾经帮一家电商公司做 MFA 改造。一开始全员强制 MFA，结果客服部门炸了——他们每天要登录几十次，每次都要输验证码。后来改成「首次登录 + 敏感操作」才触发 MFA，投诉率直接降到零。
3.4 实战架构：IAM 在零信任中的位置
下面这张图，是我在项目中常用的 IAM 核心架构。它把身份认证、SSO、MFA 串在了一起。
你看，整个流程里，用户只跟 PEP 打交道。PEP 不自己做决策，它把认证丢给 IdP，把授权丢给 PDP。这样，身份和策略就解耦了。
3.5 配置清单与避坑总结
最后，我整理了一份实战配置清单。你照着这个清单做，基本不会漏掉关键点。
| 阶段 | 检查项 | 常见问题 |
|---|---|---|
| 统一身份 | 用户源是否唯一？是否支持 SCIM 自动同步？ | 多源冲突、同步延迟 |
| SSO | 回调 URL 是否 HTTPS？Token 过期策略是否合理？ | HTTP 重定向被拦截、Token 太短 |
| MFA | 是否区分风险等级？是否支持备用码？ | 全员强制导致体验差、备用码丢失无法恢复 |
| 日志审计 | 认证日志是否集中存储？是否关联用户行为？ | 日志分散、无法溯源 |
最后一条忠告：IAM 不是配完就完事的。你需要持续监控认证失败率、MFA 绑定率、异常登录行为。我曾经见过一个客户，MFA 配了半年，绑定率只有 30%——因为没人强制。所以，技术配好了，流程和制度也得跟上。