土法炼钢兴趣小组的算法知识备份

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

2026-04-21 · architecture · security · #pam #iga #audit #compliance #cyberark #teleport #sox #hipaa #privileged-access

文章导航

分类入口
architecturesecurity
标签入口
#pam#iga#audit#compliance#cyberark#teleport#sox#hipaa#privileged-access

目录

前面几篇我们一路从 SSO、OIDC、SAML 讲到 CIAM、SCIM 账号生命周期，再到零信任与工作负载身份，基本覆盖了”登录”这件事本身。但身份工程的另一半不是登录，而是”登录之后谁能干什么、干过什么、谁在监督”。这半边通常被拆成三块：PAM（特权访问管理）、IGA（身份治理与管理）、以及贯穿两者的审计合规。这篇把它们放到一起讲，因为在合规审计（SOX、HIPAA、PCI-DSS、ISO 27001、等保三级）的视角里，这三块是同一个闭环。

治理闭环

和业务 IAM 不同，PAM/IGA/审计的驱动力往往不是产品功能，而是两件事：一是真实发生过的事故（SolarWinds 的供应链特权账号、Uber 的 MFA fatigue + 横向移动），二是审计师和监管机构的合规清单。前者告诉你不做的代价，后者告诉你至少要做什么。

本文讨论的上下文可以参考：零信任架构 定义了”默认不信任”的大原则，SCIM 与账号生命周期 是 IGA 的管道层，工作负载身份 则对应”机器特权账号”这一类。

一、为什么 PAM 是单独一个品类

普通用户的账号管理（Workforce IAM）和特权账号管理（PAM）表面上都在解决”谁能访问什么”，但工程上是两套体系，原因在于风险等级和账号特性完全不一样。

1.1 什么是特权账号

广义的”特权账号”指的是那些一旦被盗、被滥用，足以对业务造成不可逆损害的账号。典型的包括：

这个清单的共同点是：权限大、使用频率低或周期性、一旦泄漏爆炸半径极大。

1.2 真实事故的教训

2020 年 SolarWinds 事件，攻击者在 Orion 产品的构建流水线里植入后门。受害客户侧最终被利用的，是客户自己 SolarWinds 服务账号被赋予了过高的域特权。构建侧+运行侧双重特权账号失守，导致数千家下游受影响。工程结论是：CI/CD 的服务账号必须按特权账号治理，不能因为它”是机器”就放松。

2022 年 Uber 入侵，攻击者先通过社工获取承包商 VPN 凭证，然后对 MFA 进行 fatigue 攻击（反复推送直到用户点同意），进入内网后在一个网络共享里发现了 PAM 系统（Thycotic）的管理员脚本，里面硬编码了凭证，拿到之后横向扩散到 AWS、GCP、Slack、HackerOne。工程结论是：MFA 不是银弹、PAM 凭证本身必须被更强的控制保护、横向移动检测（UEBA/SIEM）是必需的第二道防线。

这两个事故背后，都是”特权账号”这件事没有被当成独立品类去工程化。

1.3 PAM 的五项核心能力

一套合格的 PAM 平台，至少要提供以下五件事。它们不是可选项，而是合规审计师勾选框里的必选项。

  1. Credential Vault（凭证金库）：所有特权账号密码不再由人工记忆或者写在 wiki 里，统一存进加密金库。金库支持自动轮换（check-out / check-in，或每次使用后一次性旋转），即使密码被记下，下一次也会失效。
  2. Session Recording（会话录制）：SSH/RDP/数据库会话的完整视频或终端流录制，可以按时间、按用户、按命令关键字检索回放。高端产品（CyberArk、Teleport Enterprise）提供 OCR 字幕和命令级索引。
  3. JIT（Just-In-Time）访问：特权账号平时不常设，需要使用时走”申请 → 审批 → 授权（有 TTL，30 分钟到 4 小时）→ 到期自动回收”的流程。这是 Zero Standing Privilege 的核心实现。
  4. Approval Workflow：每一次特权使用都有理由、审批人、审批时间戳，全程留痕。审批可以是人工的（Slack/邮件审批），也可以基于策略自动审批（on-call 工程师在值班时间内自动通过）。
  5. Session Brokering：用户不直接拿到密码，而是通过 PAM 的代理层连接目标系统。用户看到的是”点击一个按钮，PAM 自动建立 SSH 会话”，密码在后端由 PAM 使用，用户根本不知道。

二、PAM 的工程落地

2.1 Bastion Host 模式 vs PAM 平台模式

很多公司最早的特权访问控制是 Bastion Host（堡垒机）：一台加固过的跳板机，所有对生产 SSH 的访问必须先 SSH 到堡垒机、再从堡垒机跳转到目标。这种模式有几个关键特性：

维度 传统 Bastion PAM 平台
密码管理 目标机密码仍然是长期静态 目标机凭证由 PAM 托管、动态轮换
会话录制 记录 SSH 命令历史（不完整，可被 bash 规避） 完整 tty 流，带 OCR 字幕
JIT 没有，用户长期有 bastion 权限 审批才开权限
多协议 只擅长 SSH SSH/RDP/DB/Web/K8s 都覆盖
审计 靠 bastion 的 syslog 结构化事件，原生 SIEM 集成

堡垒机在小规模（<50 台生产机、<10 个运维）是够用的。超过这个规模，会话录制的完整性、密码轮换的自动化、多协议统一审计就成了瓶颈。

2.2 SSH Certificate Authority 取代静态 SSH Key

传统的 SSH 认证是”用户把 public key 放到目标机的 ~/.ssh/authorized_keys“。问题是：

SSH Certificate Authority 模式（Teleport、HashiCorp Vault 的 SSH backend、OpenSSH 原生 CA）换一种思路：

# 传统方式
用户生成 key pair → 公钥分发到每台服务器的 authorized_keys

# CA 方式
用户的 public key → CA 签发一张有 TTL 的证书 → 服务器只信任 CA

工程上的好处：

对应的服务器 sshd_config 配置：

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/teleport_user_ca.pub
# 不再需要在 authorized_keys 里维护用户公钥

2.3 短期凭证：Vault Dynamic Secrets 与 AWS STS

数据库访问是特权账号的重灾区，因为 DBA 的密码传统上一改全公司都要改。HashiCorp Vault 的 Database Secrets Engine 提供”动态账号”：

# 用户请求 DB 访问
vault read database/creds/readonly-role

# Vault 现场在目标 DB 上 CREATE USER v-readonly-xxxx PASSWORD '...' 
# 返回给用户，带 TTL（比如 1 小时）
# TTL 到期 Vault 自动 DROP USER

用户拿到的是一个现场创建、绑定自己身份、一小时后消失的账号。审计时”谁在什么时候用什么账号查了什么表”可以一一对应。

AWS STS 的 AssumeRole 是同类思路：长期 IAM 用户或 SSO 用户去 assume 一个 role，拿到的是 15 分钟到 12 小时 TTL 的临时 access key。生产建议：

2.4 K8s 的特权控制

kubectl 的 cluster-admin 和 kubectl exec -it 是 K8s 里最危险的两个操作。PAM 在这里有两层工作：

RBAC 层的 JIT：给用户的常态 kubeconfig 只有 read-only 权限。需要写操作时走 PAM 审批，审批通过后 PAM 动态给这个用户的 ServiceAccount 绑定一个临时 RoleBinding，TTL 到期删除。开源实现可以看 kube-access 之类的项目，或者 Teleport/Rancher 的企业方案。

kubectl exec 的审计：这是一个大坑。kubectl exec -it 进入容器 shell 后的操作，对 apiserver 而言就是一个 WebSocket 流，里面传的是终端字节流。apiserver 的 audit log 只能记录”某用户在某时刻对某 pod 发起了 exec”，进去之后干了什么是看不到的。常见的补救方案有两类：

2.5 数据库访问代理

DBA 和后端工程师对生产库的直接访问是合规审计的重点。StrongDM、Teleport DB Access、CyberArk DPA 都采取代理模式：

工程师 ──► DB Proxy ──► 生产 DB
           (PAM)
           - 认证：用户企业 SSO
           - 授权：按表/按 schema 的 ACL
           - 录制：所有 SQL 查询
           - 脱敏：对 PII 列自动掩码

代理层额外能做一件事：查询结果脱敏。返回的 email 列自动替换成 u***@example.com，phone 自动抹掉中间四位。这对 HIPAA/PCI-DSS 的”最小必要访问”要求非常关键。

三、IGA：身份治理

PAM 管的是”当你需要特权时怎么拿、怎么审计”，IGA 管的是”你应该有哪些权限、为什么有、是不是还需要、什么时候该收回”。IGA 不是技术问题而是治理问题，但所有治理都需要系统支撑。

3.1 访问复核（Access Review）

定义：每隔一段时间（季度或半年），让每个员工的直线主管逐条确认下属目前持有的所有权限是否仍然必要。

执行形态：

产出是一份带签字的报告，作为 SOX/ISO 审计证据。关键工程问题是数据聚合：员工的权限散落在 AD/LDAP、AWS、GitHub、Jira、Salesforce、各种 SaaS 里，IGA 工具要从这些源头拉齐。

3.2 SoD（Segregation of Duties，职责分离）

核心原则：任何一条可以造成严重损失的业务流程，都应当至少由两个互不兼容的角色共同完成。经典例子：

SoD 在 IGA 工具里通常表达为一条规则：“持有 ap.vendor.create 角色的人不能同时持有 ap.payment.approve 角色”。工具在分配权限时做前置检查，在访问复核时做回溯扫描。

3.3 Role Mining（角色挖掘）

大公司常见困境：权限是过去十年一个一个加上去的，没人说得清”财务分析师”到底应该有哪些权限。Role Mining 从现有数据逆向工程：

输入：所有员工 × 所有权限的矩阵
输出：若干"建议角色"，每个角色是一组经常一起出现的权限
      以及每个角色覆盖了哪些人、匹配度是多少

算法本质是聚类+频繁项集挖掘。产出的建议角色经人工评审后，变成正式的 RBAC 角色定义，后续新员工按角色分配权限。

3.4 Certification Campaign

一次”大扫除”性质的访问复核，覆盖全公司、有截止日期（通常 2~4 周）、有逐级 escalation。

工程要点：

3.5 Joiner-Mover-Leaver 自动化

这部分和 SCIM 与账号生命周期 深度耦合，这里只强调 IGA 视角的几个点：

3.6 Orphan Account（孤儿账号）

定义：在目标系统里存在、但在 IGA 的”人”表里找不到对应身份的账号。来源：

治理方法：IGA 定期（每月）对每个目标系统做 reconciliation，列出”目标系统里有、身份源里没有”的账号，逐个处理（Owner 认领、禁用或删除）。

四、审计留痕的工程实现

审计的核心诉求是”日志必须真实且不可事后篡改”。做到”真实”需要完整采集，做到”不可篡改”需要存储层的保障。

4.1 不可篡改的三种技术方案

Append-only 存储：存储介质本身只允许追加不允许修改/删除。典型产品：

Log Signing（日志签名）：每条日志用一个私钥签名，私钥保存在 HSM 里。审计时用对应公钥验签，任何修改都会导致验签失败。Linux auditd + audispd 可以做，企业级 SIEM（Splunk、QRadar）都有内置支持。

Hash Chain（哈希链）：每条日志的记录里包含前一条的 hash。修改任意一条中间记录会导致后续所有 hash 失效。这是区块链的基础思路，在日志场景里 CloudTrail log file integrity validation 用的就是类似机制。

生产落地通常三者组合：CloudTrail → S3 Object Lock（append-only）+ log file integrity（hash chain）+ SIEM 端独立拷贝（多源对账）。

4.2 SIEM 接入

SIEM（Security Information and Event Management）的角色是把分散在各处的日志汇聚、关联、告警。PAM/IGA 要推送到 SIEM 的事件至少包括：

PAM 事件
- 凭证 check-out / check-in
- JIT 申请 / 审批 / 授权 / 回收
- SSH 会话开始 / 结束 / 录制文件位置
- 异常：非工作时间特权使用、批量密码 check-out

IGA 事件
- 权限变更（add/remove role）
- SoD 违规告警
- 访问复核完成情况
- 孤儿账号发现

审计事件
- CloudTrail（AWS 控制面）
- K8s apiserver audit log
- 应用层业务审计（付款、数据导出）

主流 SIEM：Splunk（市场领导者，贵）、Elastic Security（开源栈友好）、Microsoft Sentinel（Azure 原生）、Sumo Logic、Datadog Cloud SIEM。

4.3 日志保留期

不同合规要求下的典型保留期：

合规 在线保留 归档保留
SOX 1 年 7 年（含归档）
PCI-DSS 3 个月 1 年
HIPAA 6 年
ISO 27001 按组织策略 按组织策略（通常 3~7 年）
等保三级 不少于 6 个月

工程设计：热存储（可检索）放 30~90 天在 Elastic/Splunk，冷存储（可恢复）放 S3 Glacier 或磁带。

五、合规映射

这一节的目标是把 PAM / IGA / 审计能力映射到常见控制点，帮助工程团队理解”为什么这些能力会出现在合规清单里”。它不是逐条法规解读，也不能替代法务、审计或合规顾问给出的正式意见。

5.1 SOX（Sarbanes-Oxley Act）

美国上市公司财务报告法案，IT 层面的要求主要落在 ITGC（IT General Controls）：

5.2 HIPAA（Health Insurance Portability and Accountability Act）

美国医疗信息保护法，核心是 PHI（Protected Health Information）的访问：

5.3 PCI-DSS（Payment Card Industry Data Security Standard）

支付卡行业的强制标准，针对 CDE（Cardholder Data Environment）：

5.4 ISO 27001

国际信息安全管理标准，Annex A 附录里和 IAM 直接相关的控制项：

（2022 版标号，旧版 A.9 / A.12.4 条款号在实践中还常见。）

5.5 等保三级

中国《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019）第三级中和 IAM/PAM 相关的条款（摘要）：

六、产品格局

6.1 CyberArk Privileged Access Manager

市场领导者，Gartner Magic Quadrant PAM 多年 Leader。核心产品包括 PAM Self-Hosted（老牌 On-prem）、Privilege Cloud（SaaS）、Endpoint Privilege Manager、Secrets Manager。优点是功能全、合规认证全（SOX/PCI/HIPAA/等保都能打过）、金融大企业的事实标准。缺点是贵（账号数计价，典型单价 100~300 美元/年/特权账号）、实施重（一个中型企业 3~6 个月项目）、云原生场景（K8s、serverless）的体验不如新锐产品。

6.2 BeyondTrust

PAM 综合平台，Password Safe（凭证管理）+ Privileged Remote Access（远程访问）+ Endpoint Privilege Management。定位和 CyberArk 类似，在北美教育、医疗行业份额大。

6.3 Teleport

开源 + 商业双轨的云原生 PAM 新锐，底层是 SSH Certificate Authority。特点：

在 SRE / Cloud Native 团队的采用率很高，是传统堡垒机的自然升级路径。

6.4 HashiCorp Vault + Boundary

Vault 做凭证管理（KV 存储、PKI、Database Dynamic Secrets、SSH CA），Boundary 做网络访问代理（Zero Trust Network Access，ZTNA）。两者配合可以搭出一个”用户 → Boundary 认证 → Vault 动态签发凭证 → 直连目标”的流程。开源版本可用，企业版加 HSM 集成、审计、命名空间。

6.5 StrongDM

SaaS 形态，专注 Database 和 Server 访问代理，强调”30 分钟上线”。对 DB 多协议支持好（Postgres、MySQL、Oracle、Snowflake、Redis、Mongo…），自带查询审计和脱敏。适合 SaaS 数据驱动公司。

6.6 AWS IAM Identity Center + Systems Manager Session Manager

AWS 原生方案：

缺点：只覆盖 AWS 内部、不管 DB/K8s/SaaS 的细粒度访问。合适作为纯 AWS shop 的起步方案。

七、最小可行闭环

假设你在一个 100~500 人的科技公司，需要在 2~3 个月内搭出一个能过 SOC2 Type II 审计的 PAM/IGA 最小闭环，推荐的技术栈和顺序：

第 1 步：堡垒与短期凭证

# Vault Postgres dynamic secrets 示例
resource "vault_database_secrets_mount" "postgres" {
  path = "database"
  postgresql {
    name              = "prod-db"
    connection_url    = "postgresql://vault-admin:xxx@prod-db:5432/postgres"
    allowed_roles     = ["readonly", "readwrite"]
  }
}

resource "vault_database_secret_backend_role" "readonly" {
  backend = vault_database_secrets_mount.postgres.path
  name    = "readonly"
  db_name = "prod-db"
  creation_statements = [
    "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
    "GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
  ]
  default_ttl = 3600   # 1 小时
  max_ttl     = 14400  # 4 小时
}

第 2 步：会话录制与审计归档

# Teleport auth_service 配置 session recording 到 S3
auth_service:
  enabled: yes
  session_recording: "node-sync"
  audit_sessions_uri: "s3://audit-bucket/teleport-sessions?region=us-east-1"
  audit_events_uri:
    - "s3://audit-bucket/teleport-events?region=us-east-1"

对应 S3 Object Lock 策略：

{
  "ObjectLockConfiguration": {
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 2555
      }
    }
  }
}

（2555 天 ≈ 7 年，覆盖 SOX 要求。）

第 3 步：审批工作流

# 用户端
tsh request create --roles=prod-db-admin --reason="debug issue OPS-1234"

# Slack 里 on-call 收到消息，点 Approve，审批链路完整记录到 audit log

第 4 步：IGA 轻量实现

100 人规模不必上 SailPoint/Saviynt 这种重量级 IGA，可以先用：

第 5 步：SIEM 与告警

八、工程坑点

8.1 JIT 审批链路的降级方案

JIT 的审批人不在线怎么办？生产事故凌晨 3 点，on-call 工程师需要 prod DB 写权限，但二级审批人在睡觉。如果 PAM 死板地拒绝，事故扩大是你的责任。

务必设计降级：

原则是”宁可放行+强审计，不可阻塞业务”。监管审计时，“有紧急访问但事后 48 小时内补了 ticket、会话有录制”是可以接受的，“生产挂了两小时因为 PAM 卡审批”是管理层问题。

8.2 Session Recording 的存储成本

经验数据：一个活跃 DBA 或 SRE，每天 4 小时 SSH 会话，终端流（含 resize 事件）大约 100~200 MB。公司有 100 个 DBA/SRE，一年产生：

100 人 × 150 MB/天 × 250 工作日 ≈ 3.75 TB/年（热）

如果合规要求 7 年保留：26 TB。S3 Standard 单价约 0.023 USD/GB/月，26 TB × 12 × 0.023 ≈ 7200 USD/年。直接放 S3 Standard 其实还能承受。但如果升级到 RDP 视频录制，体积 × 20 起步。工程处理：

8.3 Vault Lease 管理

Vault Dynamic Secrets 的每一次签发都产生一个 lease，lease 有 TTL 也有 max_ttl。典型坑：

处理：

8.4 K8s cluster-admin 的审计盲区

kubectl exec 进入容器后的操作 apiserver 看不到。生产常见误区是”K8s audit log 开了就算审计覆盖了”，其实没有。补救方案：

8.5 离职的最后一公里

HR 系统通知 IGA，IGA 通过 SCIM 删除 Okta 里的用户，Okta 下发到下游应用删账号——这条链路理论上 10 分钟内完成。但残留的”非 SCIM 通道”权限常见有：

工程对策：

8.6 访问复核的形式主义

最大的坑不是技术的，是人性的。每季度一次的全员访问复核，经理面对下属 200 条权限记录，为了赶截止日期，一路点”批准”。一年四次，每次如此，相当于审计完全没做。

反疲劳设计：

九、选型建议

产品选错了不是末日，但换产品很痛。原则：先定流程（JIT、审批、会话录制、Review 频率、日志保留），再选工具。流程是合规的核心，工具只是实现手段。

十、补充话题：几个典型场景的详细设计

10.1 场景 A：生产数据库的工程师查询

需求：研发工程师为了排查线上 bug，偶尔需要查生产 Postgres（只读，不能改数据），但不能允许持续长期的访问。

设计：

工程师 ──► Teleport DB Proxy ──► Vault(Dynamic Secret) ──► Postgres Read Replica
          │                       │
          │                       └─ 创建一次性 DB 账号，TTL 1h
          │
          ├─ 认证：企业 SSO（Okta）
          ├─ 授权：基于 Okta Group 映射到 Teleport role
          ├─ 录制：所有 SQL 语句 + 结果元信息（不录制敏感数据内容）
          └─ 审批（可选）：非工作时间访问需要 on-call 审批

关键配置：

# Teleport role: prod-db-read
kind: role
version: v7
metadata:
  name: prod-db-read
spec:
  allow:
    db_labels:
      env: prod
      role: replica
    db_names: ["appdb", "analytics"]
    db_users: ["readonly"]
    request:
      roles: ["prod-db-write"]    # write 权限必须临时申请
  options:
    max_session_ttl: 4h
    record_session:
      db: true

工程师获取访问的 CLI 流程：

tsh login --proxy=teleport.example.com --auth=okta
tsh db login --db-user=readonly --db-name=appdb prod-db-01
# Teleport 从 Vault 取动态凭证，本地写一个临时的 psql config
psql "service=teleport-prod-db-01"

# 4 小时后 session 自动断开，Vault 自动 drop user

排错友好度：Teleport audit log 里每一条 SQL 都能查到，研发出事后的 “我当时查了啥” 有据可依。

10.2 场景 B：K8s prod 集群的故障处理

需求：SRE 需要到 prod K8s 排查 pod 异常，偶尔需要 kubectl exec 进容器。所有人平时只有 read-only，排障时短期升级。

设计：

平时：
  SRE kubeconfig → Teleport K8s Proxy → apiserver (view-only ClusterRole)

排障时：
  SRE 发起 Access Request "need prod-debug for 1h, reason: incident INC-42"
  on-call 或 manager Slack 批准
  Teleport 动态 bind ClusterRoleBinding: prod-debug → SRE's identity
  TTL 1h 到期自动解绑
  exec 会话被 Teleport K8s session recording 录制（包括 tty 流）

对应 ClusterRole（缩略）：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prod-debug
rules:
- apiGroups: [""]
  resources: ["pods/exec", "pods/portforward", "pods/log"]
  verbs: ["create", "get"]
- apiGroups: [""]
  resources: ["pods", "services", "events"]
  verbs: ["get", "list", "watch"]
# 故意不给 delete、不给 secrets 访问

补充：节点层 Falco 规则兜底，监测容器内异常进程（比如从 pod 里启动 curl http://attacker.com），发送告警。

10.3 场景 C：HR 系统 Joiner 的一天

新员工入职第一天，HR 系统触发事件，IGA 走完整 onboarding 流程：

T+00:00  HR（Workday）标记员工 active，触发 webhook
T+00:01  IdP（Okta）从 Workday 拉取 employee record，创建 Okta user
T+00:02  Okta 按 department+title 匹配 Birthright rule
         分配 Group: Everyone, Eng-BE, Office-Shanghai
T+00:03  SCIM 下发到：
           - Google Workspace（创建邮箱）
           - Slack（创建账号）
           - GitHub（加入 org）
           - AWS Identity Center（绑定 Eng-BE PermissionSet）
           - Jira/Confluence（工作空间访问）
T+00:10  全部 provisioning 完成，员工收到欢迎邮件 + 设置密码链接
T+01:00  员工登录 Okta，完成 MFA 注册
T+Day1   员工开始用邮件、Slack、GitHub。生产访问不在 Birthright 里，
         需要时走 Access Request。
T+Day3   经理收到系统通知：确认新员工的 Birthright 权限正确，2 周内 ack

失败处理：任何一个 SCIM 下游失败，IGA 必须有重试+告警，不能让员工”账号一半有一半没有”工作几天才发现。实践中 SCIM 成功率是 IGA 平台的核心 SLI。

10.4 场景 D：敏感操作的双人复核

某些操作风险极高，不应由任何一个人独立完成，如：

设计模式：“双人舞”（Dual Control / Two-Person Integrity）：

User A 发起操作 → 系统生成 pending action，通知候选 reviewer
User B（不能是 A 的下属、不能是 A 本人）批准 → 操作执行
任何一方取消 → 操作取消

AWS 工程实现：

Vault 的 Sentinel 策略引擎支持 MFA + dual-control，企业版功能。

10.5 场景 E：Break-glass 账号演练

Break-glass（应急管理员）账号在监管要求里是必须的，但又是最容易被遗忘、遗忘后反而成为攻击入口的东西。

设计：

这是 SOX/PCI 审计师必看的一项。

十一、度量与 SLI

一个运转健康的 PAM/IGA 体系，需要有可观测的指标：

PAM 指标

IGA 指标

审计指标

把这些指标放到 CISO 的月度 dashboard，治理才有推动力。

十二、实施路线图参考

新搭建 PAM/IGA 体系的 12 个月路线图：

M0~M1 基线盘点

M2~M3 IdP 和 SCIM 收敛

M4~M6 PAM 核心能力上线

M7~M9 JIT 审批与 IGA 轻量化

M10~M12 合规收口

预算参考：中型科技公司（500~1000 人）完整 12 个月实施，软件 + 人力典型预算 150~400 万人民币。CyberArk+Sailpoint 组合会更贵。

十三、小结

PAM、IGA、审计三者构成身份工程的治理闭环：IGA 决定”该不该有”，PAM 决定”用的时候怎么给”，审计决定”用过之后怎么查”。技术上三者落地的核心模式是”短期凭证 + 会话录制 + 不可篡改日志 + 定期认证”，合规框架（SOX/HIPAA/PCI-DSS/ISO 27001/等保三级）在其上各加一层具体要求。

工程上最容易犯的错是把它当纯技术项目：部署了 Vault、上线了 Teleport，但审批流程没人跟、access review 形式主义、离职残留的非 SCIM 权限没人清。真正能通过审计的，是那些把流程设计清楚、工具是流程的自然延伸的团队。

下一篇我们讨论身份系统的迁移（IdP 从 LDAP/AD 迁到 Okta、从 Okta 迁到 Azure AD、自建迁到云）、如何在迁移中不停机，以及真正发生身份泄漏事故时的响应 Playbook。

十四、参考资料

上一篇：CIAM 架构：面向 B2B / B2C SaaS 的身份平台

下一篇：身份系统迁移与事故响应

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-21 · architecture / security

【身份与访问控制工程】IAM 全景：为什么这是高价值赛道

身份与访问控制从一个登录框演进为横跨合规、运维、平台工程和安全的系统工程。本文从一家 SaaS 公司被大客户卡在 SOC 2 合规的真实触发器切入，拆解 IAM、CIAM、IGA、PAM、SSO、目录服务六个子领域的边界，分析 Okta、Entra ID、Auth0、Keycloak、Ping 等主流厂商的定位与落差，给出工程师视角的介入判据与选型路径。

2026-04-21 · architecture / security

【身份与访问控制工程】企业单点登录：OIDC 与现代 SSO

B2B 大客户的安全团队只认自家 Okta，集团五条产品线要统一账号，合规团队要求所有入口都可审计——这些需求最终都落在同一个协议上：OpenID Connect。本文从一个真实的商业谈判场景切入，系统拆解 OIDC 在 OAuth 2.0 之上增加了什么、授权码流程的每一个字段为什么存在、企业集成里最常见的六类实现坑，以及 Discovery、JWKS、Dynamic Client Registration、mTLS Client Auth 的工程细节，帮助你把 SSO 从 demo 做到可以放进 SOC 2 审计报告里。

By .