第2章：IAM 核心理念 — AAA 模型、设计原则与身份架构 | IDaaS Book

2.1 IAM 的定义与范畴#

IAM（Identity and Access Management，身份与访问管理）是信息安全领域的基础性学科，涵盖确保"正确的个体在正确的时间以正确的原因访问正确的资源"所需的所有策略、流程和技术。

IAM 的四大核心要素：

• 身份（Identity）：谁在请求访问？人、设备、服务还是应用？
• 认证（Authentication）：如何证明你是你声称的那个人？
• 授权（Authorization）：你能做什么？能访问什么资源？
• 审计（Audit）：谁在什么时候做了什么？

2.2 身份：数字世界的通行证#

2.2.1 什么是数字身份#

数字身份是一组与实体（人、设备、服务）关联的属性集合，用于在信息系统中唯一标识和描述该实体。

一个典型的用户数字身份包含：

• 标识符（Identifier）：用户名、邮箱、手机号、员工编号
• 属性（Attributes）：姓名、部门、职位、角色、组成员关系
• 凭证（Credentials）：密码哈希、证书、生物特征模板
• 元数据（Metadata）：创建时间、最后登录时间、账户状态

2.2.2 身份的类型#

在 IAM 系统中，身份并非只有"人类用户"一种类型：

2.2.3 身份存储：目录服务#

身份数据需要持久化存储。常见的存储方式：

LDAP 目录：树状结构，读取性能优异，写入性能一般。适合员工身份存储。

关系数据库：扁平表结构，灵活查询。适合需要复杂关联查询的场景。

云目录：如 Microsoft Entra ID（原 Azure AD）、Google Cloud Identity。原生支持云应用，弹性伸缩。

图数据库：如 Neo4j。适合复杂的身份关系建模，如组织架构、权限继承链。

2.3 AAA 模型#

AAA 是 IAM 最经典的三要素模型：

     ┌──────────────┐
     │   你是谁？    │  ← Authentication（认证）
     └──────┬───────┘
            │
     ┌──────▼───────┐
     │  你能做什么？  │  ← Authorization（授权）
     └──────┬───────┘
            │
     ┌──────▼───────┐
     │  你做了什么？  │  ← Accounting（记账/审计）
     └──────────────┘

认证（Authentication）#

解决"你是谁"的问题。认证的三类要素：

1. 知识要素（Something you know）：密码、PIN、安全问题
2. 持有要素（Something you have）：手机、硬件 Token、智能卡
3. 固有要素（Something you are）：指纹、面部、虹膜、声纹

多因素认证（MFA）要求使用两类或以上的要素进行认证。

授权（Authorization）#

解决"你能做什么"的问题。授权回答三个问题：

• 主体（Subject）：谁要访问？
• 客体（Object）：访问什么资源？
• 操作（Action）：执行什么操作？

常见的授权模型将在 第20章详细讨论，这里给出简要对比：

审计（Accounting/Audit）#

解决"你做了什么"的问题。AAA 中的 Accounting 原意为"记账/计费"——记录资源使用情况以便计费与追溯；在 IAM/IDaaS 语境下通常引申为审计（Audit），即记录"谁在何时做了什么"。审计记录包含：谁（Who）、什么时间（When）、从哪里（Where）、做了什么（What）、结果如何（Result）、通过哪个客户端（Client）。

2.4 IAM 架构模型#

2.4.1 中心化 IAM#

所有身份数据集中存储在一个中心目录中，所有应用都到中心进行认证。

  App1 → ┐
  App2 → ├─→ IAM Server → LDAP/DB
  App3 → ┘

优点：管理方便，策略统一。 缺点：单点故障，性能瓶颈。

2.4.2 联邦 IAM#

身份数据分布在不同域中，通过信任关系实现跨域认证。

  [Domain A]                 [Domain B]
   App1 ←→ IdP-A  ←─信任─→  IdP-B ←→ App2

优点：消除身份孤岛，减少密码疲劳。 缺点：信任管理复杂，协议互操作性挑战。

2.4.3 去中心化身份（DID）#

用户自主控制身份数据，通过区块链或分布式账本建立信任。这是 IAM 的未来方向之一，我们将在 第23章详细讨论。

关于 IAM 架构的深入讨论——包括多租户架构、零信任 IAM、混合云部署和高可用设计，参见 IAM 架构设计指南，其中包含 Mermaid 架构图和选型决策树。SaaS 平台和企业级多租户 IAM 的隔离模式（共享 IDP / 独立 Realm / 联邦 IDP）和选型指南见 多租户 IAM 架构设计与方案对比。

关于认证协议的选型——OAuth 2.0、OIDC、SAML、LDAP、SCIM 该在什么场景下使用，参见 IAM 协议选型指南，其中包含 10 种典型场景的选型推荐和决策树。

2.5 IAM 的核心设计原则#

最小权限原则（Least Privilege）#

任何实体只拥有完成其当前任务所需的最小权限集合，不多不少。

实施要点：

• 默认拒绝，显式授权
• 权限定期审查（Access Review / Certification）
• 临时提权审批（Just-in-Time Access）
• 权限使用审计

职责分离（Separation of Duties, SoD）#

将关键操作拆分为多个步骤，由不同的人执行，防止单一实体拥有过大权力。

典型场景：提交代码的人不能审批合并请求；申请采购的人不能审批采购；开发环境的访问权限和生产的访问权限分离。

纵深防御（Defense in Depth）#

在身份链路上设置多层防御：

• 网络层：IP 白名单、地理位置限制
• 传输层：TLS 加密
• 应用层：认证 + MFA + 授权 + 审计
• 数据层：密码哈希、身份数据加密

安全默认（Secure by Default）#

默认配置就是安全的：

• 新创建的用户默认没有任何权限
• 新注册的客户端默认只能使用最安全的授权模式
• 会话超时时间默认较短
• 日志默认开启

可用性优先（Usability First）#

安全措施如果过于繁琐，用户会想方设法绕过它。好的安全设计应该：

• 认证流程简洁明了
• 错误提示有用但不泄露信息
• MFA 方式多样化，用户可选择
• SSO 让用户一次认证即可访问所有应用

2.6 IAM 标准与框架#

国际和国内的主要标准框架：

2.6 IAM 常见问题 FAQ#

Q1: IAM 和 IDaaS 到底有什么区别？#

IAM 是学科/概念，IDaaS 是交付模式。 IAM 回答"身份管理应该怎么做"，IDaaS 回答"身份管理以什么形式交付"。IDaaS 是 IAM 的云服务化实现——你可以自建 IAM（如部署 Keycloak），也可以购买 IAM 即服务（即 IDaaS，如 Okta/Entra ID），但底层的身份管理理念是共通的。详见 第1章：什么是 IDaaS。

Q2: IAM 系统中，认证失败和授权失败有什么区别？#

Q3: 小公司需要 IAM 吗？还是等长大了再说？#

越早建立 IAM 体系越好，哪怕是最简版。 原因：

• 后期迁移成本远高于早期规划：从一个"每个应用自己管用户"的架构迁移到统一 IAM，工作量随应用数量指数增长
• 安全问题不等人：一个员工离职后，如果你要逐个应用回收权限，漏掉一个就是安全隐患
• 最小可用 IAM 并不贵：一个 Keycloak 实例跑在 2C4G 的虚拟机上，足以服务 1000 用户 + 20 个应用

小公司的 IAM 起步方案：Keycloak + 一个 OIDC 客户端库 → 先把 SSO 跑通 → 逐步接入 MFA → 后续再考虑 HR 系统集成和自动化。

Q4: IAM 的认证协议怎么选——OIDC 还是 SAML？#

新项目默认选 OIDC（基于 OAuth 2.0）。 只有在以下情况才选 SAML：

• 要对接的系统只支持 SAML（如老旧的 Salesforce SSO 配置、某些政府系统）
• 组织已经在用 SAML 且迁移成本过高
• 需要 IDP-Initiated SSO（用户从 IdP 门户点击应用图标跳转，不过 OIDC 通过第三方发起登录也能实现类似效果）

详细对比和选型决策见 IAM 协议选型指南，其中包含 10 种典型场景的决策树和 OAuth 2.0 / OIDC / SAML / LDAP / SCIM 的对比速查表。

2.7 小结#

IAM 不仅是一套技术，更是一套管理哲学。好的 IAM 实践让安全成为业务的助推器，而不是绊脚石。理解 IAM 的核心概念——身份、认证、授权、审计，以及最小权限、职责分离、纵深防御、安全默认、可用性优先的设计原则，是进入 IDaaS 世界的基础。

延伸：认证通过后，如何管理会话的生命周期？见 IAM 会话管理与 Token 生命周期——SSO 会话架构、Token 刷新与吊销。