【身份与访问控制工程】PAM、IGA 与审计合规

IAM 前三部分覆盖了认证、授权和平台工程。但安全合规的最后一环不在”普通用户”身上——在”特权用户”和”谁能拿到这些特权”上。这就是 PAM（Privileged Access Management，特权访问管理）和 IGA（Identity Governance and Administration，身份治理与管理）的领域。

一、PAM：特权访问的四层控制

PAM 管理的不是”张三能不能看这个文档”，而是：

• 生产数据库的 root 密码在谁手里？
• 谁有 AWS 根账号的访问权限？
• Domain Admin 账号在多少个工程师手里？
• 紧急故障时谁可以 bypass 审批流去重启生产服务？

PAM 的四层控制模型：

flowchart TD
  L1["第一层：凭据保险库<br/>(Vault / CyberArk)<br/>所有特权凭据集中存储，<br/>从不直接给人看到明文"]
  L2["第二层：会话管理<br/>(Bastion / 会话代理)<br/>所有特权操作通过代理，<br/>全程录像+键盘记录"]
  L3["第三层：Just-in-Time Access<br/>不提前授予特权——高危操作前<br/>发起临时授权申请，用后回收"]
  L4["第四层：权限审计与异常检测<br/>谁在什么时候做了什么，<br/>行为是否偏离基线"]

  L1 --> L2 --> L3 --> L4

1.1 凭据保险库（Credential Vault）

HashiCorp Vault、CyberArk、AWS Secrets Manager 等凭据保险库的核心原则很简单：没有人直接持有生产密码。

工作流： 1. 工程师需要连接生产数据库。 2. 通过 Vault CLI 或 API 请求数据库凭证（vault read database/creds/prod-readonly）。 3. Vault 动态生成一个临时的数据库账号（v-prod-readonly-abc123），TTL 1 小时。 4. Vault 在 TTL 到期后自动删除这个临时账号。 5. 审计日志记录了谁、什么时候、生成了什么凭据。

这种方式比”发一个固定的 readonly 密码给全团队”安全得多——即使凭据泄露，攻击窗口只有 1 小时。

1.2 会话代理与审计

特权会话不应该”直接连接”——应该通过强制代理：

工程师 → Bastion Host (会话代理) → 生产服务器
                ↓
        全程记录 (SSH session log)
        键盘记录 (ttyrec / teleport)
        录屏 (RDP/VNC session recording)

Teleport、Boundary（HashiCorp）、Apache Guacamole 等开源的会话代理提供了这种能力。关键功能： - 特权会话的实时审计和事后回放。 - 特权命令的强制确认（“你确定要在生产库上执行 DROP TABLE 吗？”）。 - 异常行为检测——数据库 DBA 突然在凌晨 3 点 SSH 登录生产服务器。

1.3 Just-in-Time (JIT) Access

JIT Access 的核心思想：“没有人’有’特权——特权是临时的、按需申请的、用完就回收的。”

JIT 工作流： 1. 工程师在运维平台上发起”请求 root 权限 30 分钟”。 2. 请求发送给另一个工程师审批（break-glass 场景）。 3. 审批通过后，30 分钟倒计时开始。 4. 工程师 SSH 到 Bastion，Bastion 验证该用户的 JIT 授权仍有效。 5. 30 分钟到期后，Bastion 自动终止会话，权限回收。 6. 全流程入审计日志。

开源的 JIT 解决方案包括：Teleport（内置 JIT approval flow）、AWS IAM Identity Center（临时权限提升）、Netflix BLESS（SSH 证书签发，已停更但概念仍然经典）。

二、IGA：谁应该有什么权限

PAM 控制的是”已有特权的人不能滥用”（执行层面的控制）。IGA 控制的是”只有该有特权的人才能拿到特权”（治理层面的控制）。

IGA 的三个核心流程：

2.1 访问认证（Access Certification / Attestation）

定期（每季度或每半年）由部门经理审核”我的团队成员当前有什么权限”，确认权限是否仍然必要。例如，市场部经理需要审核所有市场部员工是否仍然需要某个营销 SaaS 工具的账号。系统中检测到已离职员工仍有有效账号时生成告警和强制纠正。

这个过程听起来像”HR 该做的事”，但工程实现需要：权限清单（每个用户的所有权限可查询和可视化）、认证流（经理审批、驳回、标记”不需要”的操作闭环）、纠正执行（认证确认后自动触发 SCIM 取消授权或 PATCH active: false）。

2.2 职责分离（Separation of Duties）

SoD 原则：同一人不能同时持有冲突的权限对。例如：同一人不能既创建采购订单，又审批采购订单；同一人不能既写代码，又部署到生产；同一人不能既发起支付，又确认收款。

IGA 系统维护”冲突权限对”矩阵：

当新权限分配触发 SoD 冲突时，IGA 需要自动阻止并告警。

2.3 自动化开通

IGA 连接 HR 系统（Workday、PeopleSoft）和 IAM 系统——当 HR 系统中出现新员工，IGA 自动触发 SCIM 开通；当员工变岗，IGA 自动调整权限；当员工离职，IGA 自动吊销所有权限。

三、审计日志的不可篡改设计

PAM 和 IGA 都严重依赖审计日志。但如果日志可以被特权用户删除，审计就失去意义。

不可篡改审计日志的工程手段：

1. Append-Only 存储：审计日志写入后不允许更新或删除。使用 S3 Object Lock（WORM）或 PostgreSQL 的只追加表（不带 DELETE 权限的角色）。
2. 链式哈希：每条日志记录包含前一条记录的哈希——形成链式完整性验证。任何修改（即便特权管理员做的）都会导致哈希链断裂。 \[H_i = \text{SHA-256}(record_i \parallel H_{i-1})\]
3. 实时复制到独立账户/区域：审计日志写入主数据库的同时，推送到独立的 S3 桶或 SIEM 系统，该系统的访问权限与主系统隔离（即便是 root 账号也受限于组织 SCP）。
4. 日志即告警：关键特权操作（如”Vault root token 被使用”“生产数据库直接登录”）不计入日志，同时触发实时告警（PagerDuty/Slack）。

上一篇：CIAM 架构：面向 B2B / B2C SaaS 的身份平台 下一篇：身份系统迁移与事故响应