三朵公有云的 IAM 权限模型对照：用同一套逻辑看懂

00总览：三朵云共享的同一套骨架

无论 AWS、Azure 还是 OCI，授权的本质都是同一件事：谁（principal）→ 在什么条件（condition）→ 能对哪些资源（resource）→ 做哪些动作（action）→ 被谁的策略允许/拒绝。差异只在实体命名与边界切法。

01概念对照矩阵：同一概念，三种叫法

这是理解多云 IAM 的关键工具。横向看一行，你就知道三朵云里"同一个东西"分别叫什么。点击行可展开官方定义。

02AWS IAM 架构

请求路径：身份（User/Role）→ 挂在身份上的 policy + trust → 组织边界（SCP/RCP、Permissions Boundary）→ 求值。服务账号用 Role 而非 User。

给"服务账号"正确授权（官方正解）

① 用 Role 不用 User；② 本账户负载挂实例/任务角色，外部负载（GitHub Actions 等）走 OIDC 联邦免密钥；③ 写 permissions policy（精确到 Action+Resource）+ trust policy（精确到 Principal，敏感场景加 ExternalId 防混淆代理人）。

# 角色信任策略：允许 ECS 任务扮演我
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ecs-tasks.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

03Azure IAM（基于 Entra ID + RBAC）

Azure 把"身份"归到 Microsoft Entra ID（原 Azure AD），"授权"归到 Azure RBAC（基于 Azure Resource Manager）。授权单元是 Role Assignment = 主体 + 角色定义 + scope。

Scope 层级（官方）

# 作用域从大到小，高层分配自动下钻
Management Group  /providers/Microsoft.Management/managementGroups/{name}
Subscription      /subscriptions/{subscriptionId}
Resource Group    /subscriptions/{id}/resourceGroups/{rg}
Resource          /subscriptions/{id}/resourceGroups/{rg}/providers/{ns}/{type}/{name}

服务账号正解：Managed Identity 免密钥

工作负载直接通过 Azure.Identity SDK / MSAL 向 Entra 取 token，全程无密钥，无需 CyberArk 之类保管密码。这点和 AWS Role、OCI Dynamic Group 思路一致：服务账号默认不发长期密钥。

04OCI IAM 架构

OCI 的授权语言最接近"自然语言"：Allow <subject> to <verb> <resource-type> in <compartment>。核心容器是 Compartment，天然支持层级隔离。

策略语法示例

# 允许 group CMP-Admins 在 target compartment 管理实例与 VC
Allow group CMP-Admins to manage instance-family in compartment Target-CMP
Allow group CMP-Admins to manage virtual-network-family in compartment Target-CMP

# Dynamic Group：匹配带特定标签的实例，作为主体行动
# 规则：ALL {instance.compartment.id = 'ocid1.compartment..'}

# 跨租户：customer 租户 endorse 自己的 group 去 read 另一租户的资源
Define tenancy Partner as ocid1.tenancy..
Endorse group CMP-Integration to read object-family in tenancy Partner

服务账号正解

① 能避免长期密钥就避免：用 Dynamic Group 让资源（如 VM）凭自身身份调 API，无需 API key；② 必须长期凭证时（如外部 CMP 从 OCBC 网络连 OCI API），建 IAM User + API signing key（非密码），并登记到 CyberArk 这类密钥库；③ 策略用 where 条件进一步收窄（如限定来源网络 source IP）。

05OCBC 三云接入清单解码：它到底建了什么

你给的 OCBC_Public_Cloud_Integration_Prerequisite_v15.xlsx 是 OCBC 把内部 Cloud Management Platform（CMP，5 个节点） 接入 AWS / Azure / OCI 的前置 checklist。本质：给 CMP 在每朵云里建一个"服务账号"，让它能发现/开通/管理虚拟机 + 读监控 + 读账单。下面逐云解码它的实体设计与对应策略。

# 单一 Role 信任策略（每成员账户重复）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

# 自定义角色（节选）
{
  "properties": {
    "roleName": "OCBC CMP Azure VM and Run Command",
    "assignableScopes": [ "/subscriptions/<subscription-id>" ],
    "permissions": [{
      "actions": [ "Microsoft.Compute/virtualMachines/*",
                   "Microsoft.Compute/virtualMachineScaleSets/*" ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }]
  }
}

# 自然语言式策略
Allow group CMP-Integration to manage instance-family
  in compartment <target-compartment-ocid>
Allow group CMP-Integration to manage volume-family
  in compartment <target-compartment-ocid>

06策略求值模拟器 ▶ 三云通用逻辑

三朵云的求值骨架高度一致：默认拒绝 → Explicit Deny 否决 → 各天花板须全放行 → 任一 Explicit Allow 通过。下方按真实顺序实现，勾选不同组合看结论。

07落地清单：给服务账号授权，三朵云通用

把前面的内容浓缩成可执行的检查项。无论哪朵云，顺序都是：选身份形态 → 写最小权限 → 写信任/范围 → 进密钥库 → 审计。