1. Oracle Cloud身份与访问管理（IAM）总览

在Oracle Cloud Infrastructure（OCI）中，身份与访问管理（Identity and Access Management，简称IAM）并不是一个独立于云资源之外的管理工具，而是贯穿整个租户（Tenancy）的“控制平面”。无论是创建一台计算实例、访问一个对象存储桶，还是调用一个API，OCI都会先回答两个问题：你是谁，以及你能做什么。IAM就是回答这两个问题的核心机制，也是组织治理在云上落地的第一道基础设施。

理解OCI IAM，需要先建立一个基本认知：OCI的权限模型是“默认拒绝”的。任何主体（用户、实例、服务）在未被显式授权之前，对任何资源都没有访问权限。所有访问能力都来自策略（Policy）的授予，而策略又必须依附于某种主体和某种资源范围。这个“默认拒绝、显式授权”的原则，决定了IAM的组件之间不是松散的并列关系，而是一条清晰的授权链路。

核心组件及其职责

OCI IAM的核心组件包括用户、组、动态组、策略、区间和域。它们各自承担不同职责，又通过策略语句相互连接。

用户（User）是代表某个自然人、应用程序或系统账户的身份实体。每个用户拥有唯一的登录名、密码或API密钥，并可以属于一个或多个组。用户是“身份”的载体，但用户本身不携带任何权限——权限永远来自其所属组或直接授予该用户的策略。

组（Group）是用户的集合，是权限授予的主要对象。在OCI中，最佳实践是“权限授予组，而不是授予单个用户”。当新员工加入时，只需将其加入对应组，即可继承该组的全部权限；当员工离职时，只需将其从组中移除或禁用用户，权限即被回收。组是组织治理中“角色”概念的实现载体。

动态组（Dynamic Group）是OCI中一个非常有特色的组件。它不包含具体用户，而是通过匹配规则（Matching Rule）自动纳入满足条件的计算实例、函数或服务。例如，可以定义一条规则，将所有带有特定标签的实例纳入某个动态组，然后为该动态组授予访问对象存储的权限。这样，实例无需存储任何密钥，就能安全地访问所需资源。动态组是“工作负载身份”的核心实现方式。

策略（Policy）是OCI中权限授予的唯一形式。一条策略由“主体 + 动词 + 资源类型 + 位置 + 条件”构成，例如：Allow group NetworkAdmins to manage virtual-network-family in compartment NetworkProd。策略可以授予在租户根级别、区间级别或特定资源级别。策略是声明式的，不描述“如何做”，只描述“允许谁对什么做什么”。

区间（Compartment）是OCI中用于组织和管理资源的逻辑容器。区间可以嵌套，形成层级结构，通常对应组织的部门、项目或环境（如生产、测试、开发）。区间是策略作用范围的关键维度：同一条策略，作用在根区间和作用于某个子区间，效果完全不同。区间设计直接决定了权限边界是否清晰。

域（Domain）是OCI IAM中用于管理身份生命周期的容器，通常与企业的身份源（如Microsoft Active Directory、Oracle Identity Cloud Service）对应。一个租户可以拥有多个域，每个域独立管理自己的用户、组和身份验证策略。域的存在，使得OCI可以同时支持多个身份体系，例如员工身份、合作伙伴身份和客户身份，而不会相互干扰。

组件之间的关系：一条完整的授权链路

把上述组件串起来看，OCI IAM的授权逻辑可以概括为一条链路：身份（用户/动态组）→ 策略 → 区间 → 资源。用户通过组获得策略中定义的主体身份，策略声明了该主体在哪个区间、对哪类资源、拥有什么级别的操作权限，区间则限定了资源的边界。缺少任何一个环节，授权都无法成立。

举一个具体的例子。假设某企业有一个名为NetworkAdmins的组，组内有用户zhangsan。管理员在根区间创建了生产网络区间NetworkProd，并编写策略：

Allow group NetworkAdmins to manage virtual-network-family in compartment NetworkProd
Allow group NetworkAdmins to read instances in compartment NetworkProd

第一条策略允许NetworkAdmins组在NetworkProd区间内管理所有虚拟网络资源（VCN、子网、路由表、安全列表等）；第二条策略允许该组读取该区间内的计算实例信息，但不能创建或删除实例。当zhangsan登录OCI控制台后，他只能看到NetworkProd区间内的网络资源，并且只能对网络资源执行管理操作，对实例只能查看。这就是“最小权限”原则在OCI中的具体体现。

再考虑动态组的场景。假设有一个运行在AppProd区间内的计算实例，需要读取ObjectStore区间内的一个存储桶。传统做法是在实例上配置API密钥，但密钥存在泄露风险。使用动态组，可以定义匹配规则：

Any {instance.compartment.id = 'ocid1.compartment.oc1..aaaa...AppProd'}

然后创建策略：

Allow dynamic-group AppInstances to read objects in compartment ObjectStore where target.bucket.name = 'app-logs'

这样，实例无需任何密钥，即可通过实例 principals 自动获得读取指定存储桶的权限。动态组将“工作负载身份”从“密钥管理”中解放出来，是OCI IAM区别于传统IAM的重要能力。

与组织治理的关联

IAM不仅是技术配置，更是组织治理在云上的映射。组织治理关注的是“谁在什么范围内、以什么方式、对什么资源负责”，而OCI IAM的组件恰好提供了这种映射能力。

区间结构通常对应组织的部门或项目结构。例如，一个企业可以按“根区间 → 业务线区间 → 环境区间（生产/测试/开发）”三层来组织资源。这种结构使得权限边界与组织边界对齐：业务线A的管理员无法看到业务线B的资源，生产环境的管理员与测试环境的管理员可以完全分离。

组则对应组织中的角色。例如，NetworkAdmins对应网络运维团队，AppDevelopers对应应用开发团队，Auditors对应审计团队。每个组被授予与其职责匹配的策略，而不是按个人授予权限。当人员岗位变动时，只需调整其组归属，权限自动跟随角色变化。

域则对应组织的身份源。大型企业往往同时存在员工目录、合作伙伴目录和客户目录。通过多个域，OCI可以分别对接这些身份源，并独立管理各自的认证策略和生命周期。例如，员工域可以强制多因素认证，合作伙伴域可以设置更短的会话超时，客户域可以开放自助注册。

关键设计原则

在实际使用OCI IAM时，有几条原则值得始终遵循。第一，权限授予组，不授予个人。个人权限难以审计和回收，组权限则可以通过成员管理集中控制。第二，区间设计先于策略编写。区间是策略的作用域，区间结构不合理，策略就会变得复杂且难以维护。第三，优先使用动态组管理云上工作负载。动态组消除了密钥分发和轮换的负担，同时降低了密钥泄露的风险。第四，策略尽量使用最小权限动词。OCI策略动词包括inspect、read、use、manage，权限依次递增。能用read完成的操作，不要授予manage。第五，利用域隔离不同身份体系。不要让员工身份、合作伙伴身份和客户身份混在同一个域中，否则认证策略和生命周期管理会相互牵制。

OCI IAM的组件并不复杂，但组件之间的关系和组合方式决定了云上安全与治理的质量。理解“身份 → 策略 → 区间 → 资源”这条链路，是后续深入学习策略语法、区间设计、动态组规则和域管理的基础。在接下来的章节中，我们将逐一展开每个组件的具体配置方法和治理实践。