企业出海多云特权访问管理（PAM）与运维审计实战：SSM/JIT/云堡垒机统一特权身份治理指南
Meta Description: 出海企业多云特权访问管理完整指南：讲清 IAM 与 PAM 的边界、JIT 临时提权、会话审计证据链、SSM/云堡垒机/零信任三路线对比，附三云能力对比表、CLI 与 Terraform 实操、新加坡参考价格与 90 天落地路线。
> 关键词： 特权访问管理、PAM、运维审计、JIT 临时提权、多云堡垒机、SSM Session Manager、等保三级、ISO 27001、会话录像
前言：先说结论
如果你只有 5～10 台云服务器、团队不到 10 人、也没有向第三方交付审计证据的需求，不要买云堡垒机。 先做 SSH 加固、上零信任接入、把云审计日志打开，这三步免费，能解决 80% 的"谁在什么时候上了哪台机器"问题。
真正需要 PAM（Privileged Access Management，特权访问管理）的触发条件只有三条：
1. 你需要向外部交付审计证据——等保三级测评、ISO 27001 审核、客户尽调问卷里那句"请提供管理员会话记录"； 2. 有人以临时身份进出——外包运维、实习生、离职交接期间的过渡账号、云厂商工程师远程协助； 3. 资产规模大到每人一套密钥管不动——几十上百台机器、多个云账号、多套数据库，密钥轮换和离职回收已经开始靠 Excel 跟踪。
三条命中任意一条，PAM 就不再是"要不要买"，而是"怎么设计才不留坑"。
很多出海团队把 PAM 当成"网络设备的替代品"，这是最大的认知偏差。堡垒机是审计产品，不是连接产品。 它的计费口径是「资产数 × 并发会话数」，与服务器本身的规格和价格完全脱钩——5 台 $5/月的轻量服务器（合计 $25）配一台最低规格的云堡垒机（$400/月），通道成本是服务器成本的 16 倍。想清楚你要买的是证据，还是连接，这篇文章的每一条结论都建立在这个区分上。
一、特权访问为什么是合规评审第一个被问的域
普通账号的权限治理，行业里已经讲得比较清楚了：最小权限、角色联邦、MFA、离职回收。真正在评审现场卡住人的，是特权账号——root、云账号管理员、数据库超级用户、Kubernetes cluster-admin、网络设备管理口，以及那个永远躺在某个运维人员 .ssh/ 目录里的私钥。
三个真实场景，几乎每家出海企业都会遇到至少一个：
场景一：私钥散落，人走了权限还在。 团队 8 个人、40 台机器，每人一把 SSH 私钥，authorized_keys 里躺着三年前离职同事的公钥。安全评审问"请列出当前所有能登录生产环境的主体"，你花两天才拼出一份不完整的清单。这不是技术问题，是权限资产没有单一事实来源的问题。
场景二：外包需要进生产，但你不放心。 本地化实施方要动数据库、海外市场营销方要装统计脚本。给他们一套长期密钥，风险敞口是全程敞开；不给，业务推进不了。正确做法是JIT（Just-In-Time）临时提权：按需申请、自动审批或人工点一次、会话结束权限自动失效，全过程录像——权限的生命周期从"几个月"压缩到"几十分钟"。
场景三：出了事故查不到人。 凌晨三点配置文件被改，早上业务报错。云审计日志（CloudTrail / ActionTrail / 腾讯云 CloudAudit）记录了"某个 API 被调用"，但那是控制面；谁在用 SSH 登录进去手工改了一个 Nginx 配置，控制面一无所知。你需要的是数据面/会话层的记录：命令历史、会话录像、文件传输日志。
结论一句话：IAM 解决"谁能对云资源做什么"，PAM 解决"谁在什么时间用特权身份进了哪台机器、做了什么、有没有留下证据"。 两者是正交的，缺一不可。
本文边界：与站内相邻文章的划分
| 相邻主题 | 已发布文章 | 与本文的边界 |
|---|---|---|
| 统一身份认证（普通身份） | 2026-08-07-multicloud-iam-sso-unified-identity | 那篇解决"全员用什么账号登录云控制台"；本文只处理特权身份与运维会话 |
| 零信任网络架构 | 2026-08-25-multicloud-zero-trust-network-architecture | 那篇是连接与网络层（能不能到）；本文是授权与审计层（到了之后能做什么、留什么证据） |
| 密钥与 KMS 加密 | 2026-08-26-multicloud-secrets-management-kms-encryption-strategy | 那篇管密钥本身；本文管使用密钥的人，并复用其 KMS/Secrets Manager 作为凭据落点 |
| 安全运营中心 SOC | 2026-09-17-multicloud-soc-siem-soar-security-operations | 那篇是日志的检测与响应；本文产出的是它的高价值日志源之一（会话审计） |
| 主机安全加固 24 项 | 2026-09-06-overseas-server-security-hardening-checklist | 那篇是主机层配置基线（sshd、防火墙、auditd）；本文处理访问这些主机的身份链路 |
| 多云账号治理 Landing Zone | 2026-08-15-multicloud-landing-zone-account-governance | 那篇搭的是账号树与管理边界；本文在其上补特权访问的最后一公里 |
二、先分清：IAM、PAM、零信任、堡垒机、OIDC 各管哪一段
这五个词经常被混用，混用的代价是买错产品、或者以为买了一个就全解决了。
| 层 | 概念 | 解决的问题 | 典型实现 | 计费/成本形态 | |---|---|---|---|---| | 身份层 | IAM | 谁能对云资源做什么 API 操作 | RAM / IAM / CAM、SCP、Permission Set | 免费（随云账号） | | 身份层 | IdP / SSO | 全员一个账号、一处登录 | Keycloak、IAM Identity Center、企业身份中心 | 自建或按席位 | | 网络层 | VPN / 零信任接入 | 能不能到达内网/主机 | WireGuard、Tailscale、Cloudflare Access、SSM 隧道 | 按席位或按节点 | | 身份层 | OIDC 联邦 | 机器身份不落地长期密钥 | GitHub Actions OIDC → 云角色 | 免费 | | 审计层 | PAM / 云堡垒机 | 特权会话的账号收敛、最小权限、录像、审批、举证 | 阿里云堡垒机、自建 Teleport/JumpServer | 按资产数 × 并发数 | | 关联层 | CI/CD 与自动化 | 无人值守的特权操作 | SSM Run Command、K8s 控制器、Terraform | 按调用/免费 |
三条选型结论：
1. 零信任接入 + 会话记录 ≠ PAM，但能替代 PAM 的大部分价值。 如果只要"出事能查到人"，AWS SSM Session Manager 的会话日志（落到 S3 + CloudWatch Logs）、auditd、零信任访问日志三件套就够了，成本近乎为零。
2. PAM 的独占价值是"录像 + 审批 + 第三方举证"。 只有需要向测评机构或客户出示不可否认的会话记录时，才值得买。
3. 任何一层都不能替代另一层。 上了零信任就不做 SSH 加固、买了 PAM 就不收回长期 AccessKey——这类组合在评审里会被单独点名。
`mermaid
graph TD
A[请求方<br/>运维 / DBA / 外包 / 应急] --> B[身份层<br/>IdP 统一登录 + MFA + 角色映射]
B --> C[入口层<br/>SSM 隧道 / 零信任接入 / 云堡垒机]
C --> D[授权层<br/>JIT 临时提权 + 审批门 + 最小权限角色]
D --> E[目标层<br/>云主机 / 数据库 / K8s / 网络设备]
E --> F[审计层<br/>会话录像 + 命令日志 + 云审计日志]
F --> G[证据层<br/>SIEM 汇聚 + 保留策略 + 审计报告]
H[机器身份<br/>OIDC 联邦 / 实例角色] --> D
`
三、架构全景：四层特权访问模型
把特权访问拆成四层，是为了让每一层都可以独立替换、独立买单，而不是被一家厂商绑死。
架构全景（Mermaid 分层视图）：
`mermaid
graph TD
subgraph 身份层
I1[IdP：Keycloak / IAM Identity Center]
I2[MFA：硬件密钥 / TOTP]
I3[角色目录：运维 / DBA / 只读 / 应急]
end
subgraph 入口层
E1[AWS SSM Session Manager]
E2[零信任接入：Tailscale / Cloudflare Access]
E3[云堡垒机 / 自建 Teleport]
end
subgraph 授权层
A1[JIT 临时提权：按需、限时、限资产]
A2[审批门：单人 / 双人复核]
A3[凭据来源：KMS / Secrets Manager / 短期 STS]
end
subgraph 审计层
L1[会话录像]
L2[命令与文件传输日志]
L3[云审计日志：CloudTrail / ActionTrail]
L4[SIEM 汇聚 + 保留策略]
end
I1 --> E1
I1 --> E2
I1 --> E3
E1 --> A1
E2 --> A1
E3 --> A1
A1 --> A2
A2 --> A3
L1 --> L4
L2 --> L4
L3 --> L4
`
物理拓扑（ASCII 全景图，双云 + 外包方三方视角）：
`text
┌──────────────────────────────┐
│ 身份源（IdP） │
│ Keycloak / Identity Center │
│ MFA + 角色映射 + 离职回收 │
└───────────────┬──────────────┘
│ SAML / OIDC
┌────────────────────────────────┼────────────────────────────────┐
│ │ │
┌───────▼────────┐ ┌────────▼─────────┐ ┌─────────▼────────┐
│ 自建运维工程师 │ │ 外包 / 第三方 │ │ 机器身份（CI/CD） │
│ 常驻特权角色 │ │ 临时 JIT 授权 │ │ OIDC → 云角色 │
└───────┬────────┘ └────────┬─────────┘ └─────────┬────────┘
│ │ │
└──────────┬─────────────────────┴────────────────────┬───────────┘
│ │
┌──────────▼──────────┐ ┌───────────▼───────────┐
│ 云 A（阿里云） │ │ 云 B（AWS） │
│ ┌────────────────┐ │ │ ┌─────────────────┐ │
│ │ 堡垒机 / 审计 │ │◄─── 会话审计 ────►│ │ SSM Session Mgr │ │
│ └───────┬────────┘ │ （统一汇聚） │ └────────┬────────┘ │
│ │ │ │ │ │
│ ┌──────▼───────┐ │ │ ┌───────▼────────┐ │
│ │ ECS / RDS │ │ │ │ EC2 / RDS │ │
│ │ VPC 私网 │ │ │ │ VPC 私网 │ │
│ └──────────────┘ │ │ └────────────────┘ │
└──────────┬──────────┘ └───────────┬───────────┘
│ │
└────────────────┬─────────────────────────┘
│ 只汇聚"事件与元数据"，原始录像留在本地域
┌─────────▼──────────┐
│ SIEM / 审计存储 │
│ 保留 ≥180 天 │
└────────────────────┘
`
四条设计铁律：
1. 原始会话录像不跨地域、不跨云搬运，只把"事件与元数据"汇聚出去。 录像体积大、含敏感操作画面，跨境搬运既是成本问题也是合规问题（参见 GDPR 数据出境的技术处理）。 2. 每个入口都要有独立的失效路径。 SSM 挂了还能用零信任接入，堡垒机在维护窗口时还有受控的应急通道——但应急通道本身必须被录像或被事后审批补录。 3. 特权角色与环境绑定，不与环境混合。 生产 DBA 角色不能顺手改生产网络；网络角色不能顺手读业务库。 4. 审计日志的保留期是整个体系的短板。 等保三级要求相关日志留存不少于 6 个月，ISO 27001 与社会责任审核通常问 12 个月。保留策略要在上线第一天配好，事后补的日志在评审里不算证据。
四、特权身份的四种形态与最小权限模型
特权身份不是"管理员"一种。按主体分四类，治理动作完全不同。
| 形态 | 典型主体 | 权限特征 | 风险 | 治理动作 | |---|---|---|---|---| | 人 - 常驻 | 内部运维、SRE | 长期角色 + 日常使用 | 权限膨胀、角色混用 | 角色分层、按需再提权、季度权限复查 | | 人 - 临时 | 外包、实习生、离职过渡 | 有明确起止时间 | 忘记回收、范围过宽 | JIT 授权 + 自动过期 + 双人审批 | | 机器 | CI/CD、控制器、定时任务 | 高频、无人值守 | 长期 AccessKey 泄露 | OIDC 联邦、实例角色、禁止长期密钥 | | 应急 | 故障处理、厂商标线 | 最高权限、极少使用 | 越权使用、无痕操作 | 独立账号 + 强制录像 + 事后强制补审 |
最小权限在这四类上的落地口径：
- 人 - 常驻：默认只给"只读 + 指定服务重启"，天级的临时提权走审批； - 人 - 临时：默认零权限，按工单开通、会话结束即撤销，权限有效期短于任务承诺期； - 机器：凭据不得写入代码与镜像，走 OIDC 或实例角色换取短期令牌； - 应急：凭据封存在 KMS/GPG 加密的信封里，每次使用触发告警，用后强制轮换。
破坏性操作的强制复核清单（建议直接写进运维规范）：
- 删除或重建生产数据库实例； - 修改 VPC 路由表、安全组入站规则、NAT/EIP 关联； - 关闭或删除审计日志（CloudTrail / ActionTrail / CloudAudit）； - 修改或删除对象存储桶策略与生命周期规则； - 导出包含个人数据的生产数据集。
这五类操作在至少两家云的托管能力里都能配置成"需要额外审批"，在自建方案里则靠 sudo 策略 + 审批工单 + 录像三重约束。注意：关闭审计日志本身就是一条高风险动作，任何"合法"的关日志行为都必须有工单号，否则等同入侵。
五、JIT 临时提权：把权限生命周期从"几个月"压到"几十分钟"
JIT 是这一轮特权访问治理里最值得做、投入产出比最高的一件事。它的核心不是买产品，而是改流程：默认没有任何人持有长期特权，需要时按需申请、限时生效、到期自动收回。
JIT 的三个必备要素：
1. 申请有依据：工单号、变更单号、或故障单号，不能是"群里说一声"； 2. 授权有边界：限人、限资产、限动作、限时间窗口，四者缺一不可； 3. 到期必失效：靠技术强制，不靠人记得。
5.1 AWS：SSM Session Manager + 实例角色（推荐作为默认通道）
AWS 的做法最省事——服务器不开 SSH 入站端口，运维通过 SSM 隧道进出。前置条件是实例挂了 SSM Agent 并绑定含 AmazonSSMManagedInstanceCore 的实例角色。
安装并确认 SSM Agent 在线（Amazon Linux / RHEL 系）：
`bash
// 安装 SSM Agent（CentOS / RHEL 系）
sudo yum install -y amazon-ssm-agent
sudo systemctl enable --now amazon-ssm-agent
// 确认实例已被 SSM 纳管（Instances 列表里能看到，PingStatus 为 Online）
aws ssm describe-instance-information \
--query "InstanceInformationList[].[InstanceId,PingStatus,PlatformName]" \
--output table
`
开启会话录像与审计日志——这是 SSM 从"连接工具"升级为"审计工具"的关键一步。会话偏好文档默认名为 SSM-SessionManagerRunShell，把输出同时投到 CloudWatch Logs 与 S3：
`json
{
"schemaVersion": "1.0",
"description": "session logging to CW Logs and S3",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "ops-session-audit-sg",
"s3KeyPrefix": "sessions/",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "/aws/ssm/sessions",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": true,
"runAsEnabled": true,
"runAsDefaultUser": "ssm-user",
"idleSessionTimeout": "20"
}
}
`
`bash
// 写入会话偏好（JSON 文件上传后执行）
aws ssm update-document \
--name "SSM-SessionManagerRunShell" \
--document-format JSON \
--content file://session-preferences.json
// 交互式会话（无需开放 22 端口，无需私钥） aws ssm start-session --target i-0123456789abcdef0
// 端口转发：把远程数据库端口映射到本地，凭据仍走 Secrets Manager
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["db.internal"],"portNumber":["5432"],"localPortNumber":["15432"]}'
`
三个容易被忽略的细节：
- runAsDefaultUser: ssm-user 让运维默认以受限用户进入，需要 root 时显式 sudo，把提权动作显式化，日志里也就有了明确的分界；
- idleSessionTimeout 是防"挂着的会话"的第一道闸，20 分钟无操作自动断开；
- S3 桶必须开加密 + 对象锁，否则能改日志的人等于能改证据。
JIT 节点访问能力则进一步把"授权"这件事变成按节点 × 小时的计费对象（见后文价格表），适合"外包只需要进 2 台机器、每次 30 分钟"这类场景：授权窗口结束，权限自动消失，不需要人工回收。
5.2 阿里云 / 腾讯云 / 自建路线
- 阿里云：云堡垒机提供账号收敛、细粒度授权、会话录像与命令审计，支持审批流。计费口径是资产数 × 并发会话数，规格捆绑公网带宽与会话录像存储。海外区域（香港/新加坡/吉隆坡/雅加达/东京/法兰克福/伦敦/弗吉尼亚/硅谷）比中国大陆区域贵约 60%~75%。 - 腾讯云：国际站不提供独立售卖的云堡垒机（产品路径返回 404，非前端外壳）。国际站用户若需要 PAM 能力，只能跨云采购、或改用零信任接入 + 会话记录补齐。 - 自建：一台 $3~5/月的入门 VPS 跑 Teleport / JumpServer 即可获得基础能力，但运维量、升级、证书、备份、审计存储都要自己扛。资产 20 台以内可以评估，50 台以上通常不如买托管。
5.3 保留 SSH 直连时的最小加固（过渡期必做）
如果短期内无法切换到 SSM/堡垒机，至少把 SSH 侧收紧到"可被审计"的状态。下面这段是 /etc/ssh/sshd_config 的关键项（配置项本身不含注释，说明见下文）：
`text
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowGroups ops sre
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
X11Forwarding no
AllowTcpForwarding no
`
本地侧用 ProxyJump 收敛入口，避免每台机器各自暴露（写入 ~/.ssh/config）：
`text
Host bastion
HostName bastion.example.com
User ops
IdentityFile ~/.ssh/id_ed25519_ops
Host prod-*
ProxyJump bastion
User ops
IdentityFile ~/.ssh/id_ed25519_ops
`
再补一条审计闭环：把 auditd 的 EXECVE、USER_LOGIN、USER_CMD 三类事件投到中心日志，命令历史用 HISTTIMEFORMAT 带上时间戳：
`bash
// 让 shell 历史带上时间戳，便于事后对账
echo 'export HISTTIMEFORMAT="%F %T "' | sudo tee -a /etc/profile.d/histtime.sh
`
注意这只是补丁，不是 PAM 的替代：命令历史可以被人为清除，会话录像不会。
六、会话审计与证据链：审计的本质是"可举证"
审计评审不看你装了什么工具，只看三件事：记录全不全、能不能证明没被篡改、能不能在合理时间内取出来。
会话审计的三件套（缺一不可）：
| 证据类型 | 记录什么 | 典型落点 | 关键要求 | |---|---|---|---| | 会话录像 | 完整终端画面与交互 | 堡垒机会话录像存储 / SSM S3 | 开启加密 + 对象锁，不可单方删除 | | 命令与操作日志 | 命令、文件传输、SQL 语句 | CloudWatch Logs / SLS / 本地 + 汇聚 | 结构化、含主体与时间戳 | | 控制面审计日志 | 谁调用了哪个云 API | CloudTrail / ActionTrail / CloudAudit | 全区域、全账号、禁止关闭 |
五个技术细节，决定你的证据在评审现场能不能站住：
1. 统一时间源。 所有节点必须走同一 NTP 源并开启时间同步服务；时间错乱的日志在关联分析里等于废纸。跨境服务器要注意时区，日志统一存 UTC、展示时按需转换。 2. 防篡改优先于留存。 审计日志桶开启对象锁（治理模式或合规模式）与版本控制；写日志的账号与改日志的账号必须分离——用独立的只写子账号做投递。 3. 保留期一次配到位。 等保三级相关日志留存不少于 6 个月；涉及财务、个人数据的场景按 12 个月规划。生命周期规则把冷数据自动转归档层，但归档层有最低存储时长和取回费，别把"取证方便"和"最便宜"混为一谈。 4. 元数据也要采。 只留命令不留主体（谁、从哪个 IP、用的哪个角色、哪个工单号）等于没留。 5. 审计链路自身要告警。 日志停止投递、投递量骤降、审计桶策略被修改，这三类事件必须触发告警——攻击者做的第一件事往往是关掉日志。这类"防致盲"告警建议双人复核。
一个可直接复用的月度对账动作： 把"云控制面审计日志里的特权 API 调用"与"会话审计里的会话起止时间"做一次时间轴对齐，检查是否存在无会话记录的特权变更。有，就说明存在绕过审计通道的操作，这是评审里最容易被追问的缺口。
七、四方案能力对比：买托管还是自建
| 维度 | 阿里云堡垒机 | AWS SSM Session Manager | AWS SSM JIT 节点访问 | 自建 Teleport / JumpServer | |---|---|---|---|---| | 主要定位 | PAM 全功能 | 无端口会话接入 + 记录 | 按节点的临时授权 | 自建 PAM | | 是否需开公网端口 | 否（内网代理） | 否 | 否 | 否（需自建入口） | | 会话录像 | ✅ 原生 | ✅ 输出到 S3/CW Logs | 依赖 SSM 会话记录 | ✅ 需配置存储 | | 命令审计 | ✅ | ✅（CloudWatch Logs 可查询） | ✅ | ✅ | | 审批流 | ✅ 内置 | ❌（需自建工单/CI 流程） | ⚠️ 按授权窗口自动失效 | ⚠️ 需自建 | | 覆盖非云主机 | ✅（需代理） | ✅（混合节点按会话计费） | ✅ | ✅ | | 数据库/网络设备协议 | ✅ RDP/SSH/数据库 | ⚠️ 以 SSH/端口转发为主 | ⚠️ 同左 | ✅ | | 计费口径 | 资产数 × 并发数 | EC2 免费；混合节点按会话 | 按节点 × 小时 | VPS $3~5/月 + 人力 | | 上手门槛 | 低（控制台） | 低（IAM 角色 + Agent） | 中（需能力开通） | 高（组件多） | | 适合规模 | 有第三方举证需求 | 单云/以 AWS 为主 | 外包临时进出少量节点 | 20 台以内、有运维余力 |
四条选型结论：
1. 以 AWS 为主、无第三方举证需求 → 直接用 SSM Session Manager，成本接近零，安全收益最大。 2. 需要给测评机构/客户出示会话录像 → 托管 PAM（阿里云堡垒机），或自建 + 独立审计存储。 3. 外包只需偶尔进 2~5 台机器 → JIT 节点访问，授权窗口结束自动失效，不需要人工回收。 4. 多云混合 → 用统一身份源 + 每朵云用自己的接入通道 + 审计日志集中汇聚。不要试图用一套软件同时接管三朵云的所有协议，代价是复杂度爆炸和维护成本不可控。
八、实操：把特权访问治理变成代码
PAM 最大的落地障碍不是技术，而是配置漂移：控制台点出来的账号、授权、录像策略，半年后没人说得清。把能 IaC 化的部分固化下来，能显著降低评审准备成本。
8.1 Terraform：会话审计存储骨架（AWS）
`hcl
// 会话录像与命令日志的落点：加密 + 版本控制 + 不可删
resource "aws_kms_key" "audit" {
description = "session audit encryption"
enable_key_rotation = true
deletion_window_in_days = 30
}
resource "aws_s3_bucket" "session_audit" { bucket = "ops-session-audit-sg" }
resource "aws_s3_bucket_versioning" "session_audit" { bucket = aws_s3_bucket.session_audit.id versioning_configuration { status = "Enabled" } }
resource "aws_s3_bucket_server_side_encryption_configuration" "session_audit" { bucket = aws_s3_bucket.session_audit.id rule { apply_server_side_encryption_by_default { kms_master_key_id = aws_kms_key.audit.arn sse_algorithm = "aws:kms" } } }
resource "aws_cloudwatch_log_group" "sessions" { name = "/aws/ssm/sessions" retention_in_days = 400 kms_key_id = aws_kms_key.audit.arn }
// 让 EC2 能通过 SSM 被纳管（按需附加到实例角色）
resource "aws_iam_role" "ssm_managed" {
name = "ssm-managed-instance"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "sts:AssumeRole"
Principal = { Service = "ec2.amazonaws.com" }
}]
})
}
`
三条 IaC 纪律：
- 凭据类资源永远不进代码库：SSM 参数、KMS 别名、第三方账号密码走 Secrets Manager 或 Vault，Terraform 只引用 ARN；
- 审计存储的删除保护要单独声明：对象锁、桶版本控制、KMS 密钥的 deletion_window 都要显式写，默认值往往不满足合规；
- 云堡垒机类产品 IaC 覆盖度有限：多数厂商的 PAM 仍以控制台/API 配置为主，把"如何配置"写成带截图 ID 与工单号的运行手册（Runbook），比硬套 IaC 更现实。
8.2 三云 CLI 骨架：把"谁有特权"定期导出来
审计的第一步是能回答"当前有多少主体拥有特权"。这三条命令建议做成每周定时任务，输出直接进 SIEM：
`bash
// AWS：列出所有绑定 AdministratorAccess 的用户与角色
aws iam list-users --query "Users[].UserName" --output text
aws iam list-attached-user-policies --user-name ops-admin --output table
aws iam list-roles --query "Roles[?contains(RoleName,'admin')].[RoleName,Arn]" --output table
// 阿里云：导出 RAM 用户与角色，对照是否有长期 AccessKey aliyun ram ListUsers --output cols=UserName aliyun ram ListRoles --output cols=RoleName
// 腾讯云：导出 CAM 用户与角色（国际站同样适用）
tccli cam ListUsers
tccli cam ListRoles
`
再补一条机器身份体检：长期 AccessKey 是特权访问治理里最容易被忽略的敞口。检查是否存在创建超过 90 天、且最近 90 天未被使用的密钥，发现即轮换或删除。
`bash
// AWS：按创建时间列出 AccessKey，人工核对后轮换
aws iam list-access-keys --user-name ops-ci --output table
`
应急通道（Break-glass）设计要点： 保留一条在 SSM/堡垒机全部不可用时的通道，但必须满足——凭据封存在 KMS 信封加密的离线介质中、每次取用触发实时告警、使用后 24 小时内强制轮换、事后 3 个工作日内补写事后审批单。没有告警的应急通道等于永久后门。
九、成本账与采购决策：什么时候该花这笔钱
特权访问治理的成本结构非常特殊——它最大的一笔支出通常不是软件费，而是流程改造和人的时间。
| 成本项 | 免费/轻量路线 | 托管 PAM 路线 | 常见误算点 | |---|---|---|---| | 接入通道 | SSM（$0）或零信任接入 | 堡垒机月费 | 只算月费，不算迁移与培训 | | 审计存储 | 对象存储按量 | 已含在月费（规格捆绑） | 归档层最低存储时长与取回费 | | 审批流程 | 自建工单/CI 流程（人力） | 产品内置 | 人力才是真实成本 | | 运维量 | 无（托管方维护） | 低 | 自建方案每年数十到上百小时 | | 应急通道 | 人工流程 + 告警 | 产品内置 | 缺告警的应急通道 = 后门 |
决策口诀：
- 先加固，再谈采购。 SSH 加固、关闭密码登录、收回长期密钥、开审计日志——这四件事免费且收益最大；
- 按低谷需求买规格。 清理下线资产后再核算资产数与并发数，两者分别估算后取大者；
- 短约验证再长约。 首个合规需求未验证前，按月或按季采购，验证留存策略与流程跑得通之后再换长约——这是少数"短租验证再长约"更划算的产品；
- 不需要录像就别买 PAM。 只要"出事能查到人"，会话记录 + auditd + 零信任访问日志三件套就够。
十、参考价格表（新加坡/海外区域，USD）
| 项目 | 规格 / 口径 | 参考价 | 备注 | |---|---|---|---| | 阿里云堡垒机 基础版 | 50 资产 / 50 并发 | $400/月 | 海外区域 | | 阿里云堡垒机 基础版 | 100 资产 / 100 并发 | $600/月 | 海外区域 | | 阿里云堡垒机 基础版 | 500 资产 / 500 并发 | $1,100/月 | 含 16 Mbps 带宽 + 2T 存储 | | 阿里云堡垒机 企业版 | 100 资产 / 100 并发 | $1,000/月 | 功能更全 | | 阿里云堡垒机 企业版 | 500 资产 / 500 并发 | $1,900/月 | — | | AWS SSM Session Manager | EC2 实例 | $0 | 不额外收费 | | AWS SSM 会话（混合节点） | 从 2026-09-30 起 | $0.05/会话 | Run Command $0.002/次调用 | | AWS SSM 混合节点算例 | 200 节点 × 1 会话 + 4 命令 | ≈ $11.6/月 | 官方算例口径 | | AWS JIT 节点访问 | 首档（≤72,000 节点·小时） | $0.0137/节点/小时 | 逐档递减 | | AWS Parameter Store | 标准 | 免费 | 高级 $0.05/参数/月 | | Tailscale | Standard | $8/用户/月 | 个人免费 ≤6 用户（官网注明非商业用途） | | Cloudflare Zero Trust Access | 免费计划 | $0 | 官网定位 50 用户以内团队 | | 自建 Teleport / JumpServer | 入门 VPS | $3~5/月 | 另计人力成本 |
口径说明： ① 表内为海外区域列表价，海外区域同规格比中国大陆区域贵约 60%~75%；② 阿里云堡垒机规格捆绑若干公网带宽与会话录像存储，实际账单还需叠加底层 ECS/RDS 费用；③ AWS SSM 对 EC2 免费但混合节点（本机/边缘/其他云主机）自 2026-09-30 起按会话计费；④ 实际以各厂商官网实时报价为准，本表仅用于量级估算。
成本对比最直观的一组数字： 5 台 $5/月的轻量服务器合计 $25/月，配最低规格云堡垒机 $400/月 → 通道成本是服务器成本的 16 倍。这不是说堡垒机贵，而是提醒你：它的定价逻辑服务的是"证据需求"，不是"连接需求"。
十一、90 天四阶段落地路线
| 阶段 | 时间 | 动作 | 交付物 | 验收口径 | |---|---|---|---|---| | 一、摸底 | 第 1~2 周 | 盘点特权主体与凭据、导出长期 AccessKey、绘制当前接入链路 | 特权主体清单、凭据台账 | 能回答"当前有几把能进生产的钥匙" | | 二、止血 | 第 3~4 周 | 关闭密码登录、收回冗余公钥、轮换 90 天以上未用密钥、开启三云审计日志 | 加固后的 sshd 基线、审计日志已投递 | 新密钥全部走角色/OIDC | | 三、收敛 | 第 5~8 周 | 接入 SSM 或零信任通道、开启会话记录、建立 JIT 流程与审批门 | 会话审计落点、JIT 流程文档 | 存在一条无会话记录的特权变更即不通过 | | 四、举证 | 第 9~12 周 | 会话录像不可删、保留策略、SIEM 汇聚、月度特权对账 | 审计报告模板、对账脚本 | 评审要求的证据能在 30 分钟内取出 |
阶段三的验收口径最值得强调：不是"装了什么"，而是能不能证明没有旁路——随机抽一次生产变更，能不能在 30 分钟内找到对应的会话记录与审批单。
十二、常见问题 FAQ
Q1：PAM 和 IAM 到底是不是一回事？ 不是。IAM 管"谁能对云资源做什么 API 操作"，是控制面；PAM 管"谁在什么时间用特权身份进了哪台机器做了什么"，是会话面。两者正交——IAM 再严也管不到有人 SSH 进去手改配置，PAM 再全也管不到一个越权的 API 调用。
Q2：我们只有 10 个人、8 台服务器，要不要买堡垒机？
不要。这个规模下正确的顺序是：SSH 加固（关密码登录、禁 root 直登）→ 零信任接入或 SSM 通道 → 会话记录 + auditd。总成本接近零，安全收益的绝大部分已经拿到。
Q3：已经上了零信任，还需要 PAM 吗？ 取决于是否需要不可否认的举证。零信任解决"能不能到"和"谁到了"，但多数零信任产品的会话记录粒度不如 PAM 的完整录像，也没有内置审批流。若评审明确要求"提供管理员会话录像"，零信任替代不了。
Q4：会话录像要存多久、存在哪里？ 存在与被审计资源的同一法域内，只把事件与元数据跨境汇聚。 等保三级相关日志留存不少于 6 个月，涉及财务或大量个人数据的场景建议按 12 个月规划。存储桶必须开启加密与对象锁，写日志与改日志用不同账号。
Q5：外包要进生产，怎么授权最稳妥？ 默认零权限 + 按工单开通 + 限资产限时长 + 会话全程录像 + 到期自动失效 + 双人审批。给一套"长期密钥 + 事后回收"是常见做法，但它把最危险的窗口（密钥生效到回收之间）完全敞开。
Q6：JIT 比长期密钥省多少？ 省的主要不是钱，是风险敞口时间：把权限从"数月常开"压到"几十分钟按需"，等于把可利用窗口缩了两个数量级。费用上，JIT 节点访问首档 $0.0137/节点/小时，按每月 20 小时/节点估算，成本远低于一套长期密钥泄露带来的处置代价。
Q7：腾讯云国际站没有堡垒机，是不是就没法做 PAM？ 不是。三条路：跨云采购带有 PAM 能力的服务、用零信任接入 + 会话记录补齐审计、或自建（Teleport/JumpServer on 一台 VPS）。关键是把审计落点设在同一法域并做不可删保护，而不是必须用某家产品。
Q8：这些动作和等保三级、ISO 27001、SOC 2 怎么对应？ 粗略对应关系：身份鉴别与访问控制 ← 统一身份源 + MFA + 角色分层；安全审计 ← 会话录像 + 命令日志 + 控制面审计日志；入侵防范 ← 主机加固 + 防致盲告警；数据完整性/保密性 ← KMS 加密 + 对象锁。本文为技术实践整理，不构成法律或合规意见，具体条款请以测评机构与审核方的口径为准。
十三、总结
四句话记住这套体系：
1. IAM 管 API，PAM 管会话——两者正交，谁也替代不了谁。 2. 先加固，再接入，最后才谈采购——购买触发条件只有"要举证、有人临时进出、资产管不动"三条。 3. 审计的本质是可举证——记录全、防篡改、能取出，三者缺一不可；保留策略必须在第一天配好。 4. JIT 是投入产出比最高的一件事——把权限生命周期从几个月压到几十分钟，不需要买任何产品也能先跑起来。
> 🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。我们可以协助完成特权访问链路设计、会话审计基线搭建、多云身份与权限治理评估。
相关阅读
- 企业出海多云统一身份认证：Keycloak + 三云 IdP 联邦实战 — 全员身份源与角色映射的前置工程 - 多云零信任网络架构落地实战 — 连接与网络层，与本文的授权审计层互补 - 多云密钥管理与加密策略实战 — 凭据与密钥的落点，本文的审计存储复用其 KMS 设计 - 多云安全运营中心 SOC 建设（SIEM + SOAR） — 会话审计日志的高价值消费方 - 海外服务器安全加固 24 项检查完整指南 — 主机层基线，特权身份的落地目标 - 多云 Landing Zone 账号治理 — 账号树与管理边界，特权访问的治理底座
> 本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多