4. 身份与访问管理架构

身份与访问管理（IAM）不是单一产品，而是一组围绕“谁、能对什么、在什么条件下、做什么”持续做出判断并执行控制的能力集合。在高级数据安全架构中，IAM 是数据访问控制的第一道闸门，也是审计与合规的证据来源。它通常由四个相互咬合的层面构成：身份治理负责身份的创建、变更、注销与权限归集；认证负责确认主体身份的真实性；授权负责判定主体对资源的操作许可；特权访问管理（PAM）则对高权限账号实施隔离、审批、会话录制与凭据轮换。

身份治理的核心是生命周期。以员工入职为例，HR 系统触发账号创建，IAM 依据岗位属性自动分配基础角色；转岗时，旧权限必须被回收，新权限按新岗位重新授予；离职时，账号应在数分钟内被禁用并触发下游系统同步。若缺少治理，权限会随人员流动不断累积，形成“权限蠕变”。治理的产出物包括身份清单、权限归属矩阵、职责分离（SoD）冲突报告和定期访问复核记录。这些不是文档装饰，而是审计时证明“权限被有效管理”的直接证据。

认证、授权与特权访问管理

认证解决“你是不是你声称的那个人”。现代架构中，单因素密码已不足以支撑高价值数据访问，通常采用多因素认证（MFA），并结合设备指纹、地理位置、行为基线等信号做风险评分。认证强度应与资源敏感度匹配：普通内部文档可接受密码加短信验证码，而核心数据库访问应要求硬件密钥或生物特征加设备合规检查。

授权解决“你能做什么”。传统 RBAC 以角色为中介，将权限打包授予角色，再将角色分配给用户。它的优点是管理直观、审计清晰，适合岗位边界稳定的场景。但当资源数量庞大、关系复杂时，角色会爆炸式增长。ABAC 转而基于属性做判断，例如“部门=财务 且 资源分类=机密 且 时间在工作时段 且 设备已合规”，策略表达力强，但策略编写与测试成本高。ReBAC 则基于关系图，例如“用户是项目 A 的成员，项目 A 的文档继承项目权限”，特别适合多租户 SaaS、协作平台和层级化资源。

特权访问管理针对的是“超级权限”。数据库管理员、云平台根账号、域管理员一旦被滥用，影响面远超普通账号。PAM 的典型做法包括：将特权凭据存入保险库，使用时按需申请并审批；通过跳板机或代理建立会话，全程录制操作；对凭据进行定期轮换，避免长期共享。零信任架构进一步要求“永不信任、持续验证”，即每次访问请求都要重新评估身份、设备、网络和上下文，而不是依赖一次登录后的长期会话。

多租户 SaaS 平台 IAM 架构实战

假设我们要为一个多租户 SaaS 平台设计 IAM。平台有租户、工作区、项目、文档四层资源，用户可属于多个租户，每个租户内又有管理员、编辑者、只读成员三种角色。若只用 RBAC，需要为每个租户的每个项目创建角色，角色数量随租户和项目线性增长，难以维护。更合理的做法是混合模型：租户级角色用 RBAC 管理，项目内文档权限用 ReBAC 表达关系继承，敏感操作再用 ABAC 附加条件。

具体实现上，用户登录后获得身份令牌，令牌中携带用户 ID、所属租户列表和租户级角色。访问文档时，策略决策点（PDP）先检查用户是否属于该文档所在租户，再沿“租户→工作区→项目→文档”的关系链判断用户是否具备继承权限。若用户是项目成员，则自动继承项目下所有文档的读取权；若文档标记为“机密”，则额外要求 ABAC 条件：设备合规且访问时间在工作时段。策略执行点（PEP）在 API 网关和文档服务两处拦截请求，确保绕过前端也无法越权。

特权访问方面，平台运维人员不直接持有生产数据库密码。需要执行运维操作时，通过 PAM 提交申请，审批通过后获得一次性凭据，会话被录制并限制在指定命令白名单内。操作结束后凭据自动失效。这样即使运维账号被钓鱼，攻击者也无法直接获得长期有效的数据库访问权。

最后，IAM 架构必须可观测。关键指标包括：认证失败率、MFA 覆盖率、特权会话数量、权限复核完成率、越权尝试次数。这些指标应接入安全运营中心，当某租户的越权尝试突增或特权会话异常延长时，触发告警并自动收紧策略。身份安全不是一次性建设，而是持续验证、持续收敛的过程。