3. 身份与访问管理（IAM）落地：统一身份认证平台建设、单点登录（SSO）与多因素认证（MFA）集成、动态访问控制策略（RBAC/ABAC）设计

身份与访问管理，说白了就是零信任的“守门员”。你想想看，网络边界已经模糊了，员工在家、在咖啡厅、在客户现场都要访问公司资源。这时候，你是谁、你能干什么、你在什么环境下操作，就成了安全决策的核心。

我个人习惯把 IAM 落地拆成三个层次：认证（Authentication）——证明你是你；授权（Authorization）——决定你能做什么；审计（Auditing）——记录你干了什么。这一章我们重点讲前两个，审计后面单独开一章。

3.1 统一身份认证平台建设

很多公司一开始都是“烟囱式”认证——OA 一套账号、CRM 一套账号、GitLab 又一套。员工记密码记到崩溃，IT 部门每天处理密码重置工单。我接手过一个项目，光密码重置就占了 helpdesk 工作量的 40%。

统一身份认证平台要解决的就是这个问题。它把分散的用户身份集中到一个 身份库（Identity Store），通常基于 LDAP 或企业级 Active Directory。但注意，不是简单地把账号搬到一个地方就完事了。

我建议从这几个维度来建设：

• 身份生命周期管理：入职自动创建账号，转岗自动调整权限，离职自动禁用。别等人走了三个月还在用公司 VPN。
• 身份数据同步：HR 系统作为权威数据源，通过 SCIM 协议或定制同步器，把人员信息推送到 IAM 平台。
• 认证协议适配：平台要支持 OAuth 2.0、OIDC、SAML 2.0、LDAP 等多种协议，才能对接各种老系统和新应用。
• 高可用设计：认证服务挂了，全公司都进不去系统。我见过一次 AD 域控宕机，整个研发团队摸鱼半天。所以一定要做多节点集群，最好跨机房部署。

3.2 单点登录（SSO）与多因素认证（MFA）集成

SSO 是统一认证的“面子工程”——用户只登录一次，就能访问所有授权应用。但 SSO 有个天然矛盾：登录越方便，风险越集中。一旦主账号被盗，所有系统都失守。

所以，SSO 必须和 MFA 绑定。这不是可选项，是必选项。

3.2.1 SSO 的实现模式

目前主流有两种模式：

模式	协议	适用场景	典型产品
基于 SAML 2.0	断言（Assertion）	企业级 Web 应用、SaaS	Okta、Azure AD
基于 OIDC	ID Token + Access Token	移动端、单页应用、API	Keycloak、Auth0

我个人更推荐 OIDC 作为新建系统的首选。为什么？因为它基于 OAuth 2.0，天然支持 API 授权，而且 ID Token 用 JWT 格式，解析方便，不需要像 SAML 那样解析 XML。嗯，XML 解析的坑，做过的人都知道。

3.2.2 MFA 的集成策略

MFA 不是简单地在密码后面加个验证码。我建议按风险等级分层部署：

• 低风险操作（查看公告、浏览文档）：密码 + 可选 MFA
• 中风险操作（提交工单、修改个人信息）：密码 + 强制 TOTP（时间型一次性密码）
• 高风险操作（修改权限、转账、删除数据）：密码 + 硬件密钥（FIDO2/U2F）或生物识别

这里有个坑——MFA 的恢复机制。用户手机丢了怎么办？我曾经遇到一个客户，强制全员使用手机验证码，结果周末有人的手机掉水里了，周一进不了系统，IT 被骂惨了。所以一定要设计好恢复码、备用邮箱、管理员代操作等兜底方案。

3.3 动态访问控制策略设计（RBAC/ABAC）

认证搞定了，接下来是授权。传统做法是 RBAC（基于角色的访问控制），但零信任场景下，光有角色不够。你想想看，一个“管理员”角色，在公司内网操作是合理的，但如果他凌晨 3 点从国外 IP 登录，你还敢让他执行敏感操作吗？

所以，我建议采用 RBAC + ABAC 混合模型。RBAC 负责“静态授权”，ABAC 负责“动态决策”。

3.3.1 RBAC 设计要点

RBAC 的核心是“角色-权限”映射。设计时要注意：

• 最小权限原则：每个角色只分配完成工作所需的最小权限。不要搞“超级管理员”这种万能角色。
• 角色分层：比如“只读用户”、“普通用户”、“高级用户”、“管理员”。层级之间权限递增，但不要有重叠和冲突。
• 角色互斥：一个人不能同时拥有“审批人”和“申请人”角色，防止自己审批自己的申请。

我见过一个反面案例：某公司给所有开发人员都分配了“生产环境管理员”角色，结果有人误操作删了数据库。这就是角色设计太粗放。

3.3.2 ABAC 动态策略引擎

ABAC 的决策基于属性（Attributes）。常见的属性维度包括：

属性类别	示例	说明
主体属性	用户部门、职级、安全等级	你是谁
环境属性	时间、IP 地址、设备指纹、地理位置	你在哪里、什么时间
资源属性	数据密级、资源类型、所属项目	你要访问什么
操作属性	读、写、删除、导出	你要做什么

策略引擎的决策逻辑可以用伪代码表示：

// 策略示例：只有财务部员工在工作时间从内网IP才能访问财务系统
if (user.department == "Finance" 
    && currentTime between "09:00" and "18:00" 
    && sourceIP in internalNetwork) {
    grantAccess("FinanceSystem", "read");
} else {
    denyAccess("FinanceSystem");
    triggerMFAChallenge(); // 触发二次认证
}

实际生产环境中，策略引擎通常用 PDP（策略决策点） 和 PEP（策略执行点） 分离的架构。PDP 负责计算，PEP 负责拦截请求并执行决策。我习惯用 Open Policy Agent（OPA）作为 PDP，它用 Rego 语言写策略，灵活且性能不错。

3.4 整体架构与流程

下面这张图展示了 IAM 落地的核心流程和组件关系：

3.5 落地避坑与最佳实践

最后，我总结几个实际项目中容易踩的坑：

• 不要迷信“全自动”：身份治理工具可以自动发现账号，但权限的合理性需要人工审核。我见过一个项目，自动同步把离职员工的权限继承给了新员工，结果新员工能看到前任的所有数据。
• MFA 的备用通道：一定要有。短信、邮件、TOTP、硬件密钥，至少准备两种。我曾经遇到一次短信网关故障，全员无法登录，紧急切到邮件验证码才恢复。
• ABAC 策略的性能：属性越多，决策越慢。不要一股脑把所有属性都加进去。我建议先选 5-8 个核心属性，上线后再根据需求逐步扩展。
• 策略的版本管理：策略就是代码。要用 Git 管理，要有测试环境，要有灰度发布。我见过有人直接在生产环境改策略，改错了导致全公司无法访问，回滚都找不到历史版本。