📚 课程目录第4章身份与访问管理跨区域设计

4. 身份与访问管理跨区域设计

在多区域高可用与灾备架构中，计算、存储和网络资源可以复制到多个区域，但身份与访问管理（IAM）的跨区域设计往往被低估。一个常见的误区是：既然资源已经跨区域部署，权限自然也会跟着生效。实际上，Oracle Cloud Infrastructure 的 IAM 是全局服务，策略、用户、组和动态组都定义在租户级别，而资源则分布在各个区域。理解这种“全局身份、区域资源”的错位关系，是设计跨区域权限体系的第一步。

全局 IAM 与区域资源的映射关系

OCI 的 IAM 控制平面是全局的：你在租户中创建的用户、组、动态组、策略和身份提供者，对所有已订阅区域都可见。但策略中引用的资源是区域性的，例如 instance、vcn、volume、autonomous-database 等。策略语句通过 in compartment 和 where 条件来限定作用范围，而区域本身通常不是策略的显式维度——除非你使用 request.region 或资源标签进行约束。

这意味着：一条允许 manage instance-family in compartment Prod 的策略，会同时作用于该租户所有区域中 Prod compartment 下的实例。对于跨区域灾备场景，这既可能是便利，也可能是风险。便利在于无需为每个区域重复授权；风险在于如果生产区域和灾备区域的资源放在同一 compartment，权限边界就无法区分。

动态组：跨区域自动化权限的核心机制

动态组是 OCI 中为计算实例、函数、API 网关等资源主体授予权限的机制。它通过匹配规则（matching rule）自动将资源纳入组，无需人工维护成员列表。在跨区域场景中，动态组的一个关键特性是：匹配规则可以包含区域维度。

例如，灾备区域中的实例需要读取对象存储中的备份数据，可以创建如下动态组：

Dynamic Group: DR-Instance-Readers
Matching Rule:
  Any { instance.compartment.id = 'ocid1.compartment.oc1..aaaa...dr' }
  where { instance.region = 'ap-singapore-1' }

对应的策略为：

Allow dynamic-group DR-Instance-Readers
  to read objects in compartment Backup
  where target.bucket.name = 'dr-backup-bucket'

这样，只有运行在灾备区域的实例才能读取备份桶，生产区域的实例即使属于同一 compartment 也不会被授予该权限。这种“区域+资源类型+compartment”的三维约束，是跨区域最小权限设计的关键手段。

联合身份与跨区域登录

当企业使用 Microsoft Entra ID、Okta 或 Oracle Identity Cloud Service 作为身份提供者时，联合身份让用户通过企业目录登录 OCI，而无需在 OCI 中单独创建本地用户。联合身份本身是全局配置，但登录后的权限仍然由 OCI 策略决定。

跨区域场景下，联合身份需要关注两点：一是身份提供者的可用性——如果 IdP 部署在单一区域，其故障可能影响所有区域的登录；二是联合用户与组的映射——企业目录中的组需要映射到 OCI 组，再由 OCI 策略授予跨区域权限。建议将 IdP 本身也做多区域或高可用部署，并在 OCI 中保留至少一个本地应急用户，用于 IdP 不可用时的紧急访问。

跨区域权限管理的最佳实践

结合上述机制，以下实践可以显著降低跨区域权限管理的复杂度与风险：

按区域划分 compartment 边界。将生产区域和灾备区域的资源放入不同 compartment，策略按 compartment 授权，避免“一处授权、全域生效”带来的权限扩散。
用动态组替代静态用户组管理资源权限。实例、函数等资源主体通过动态组获得权限，减少长期凭证和人工维护。
在策略中使用 request.region 或资源标签收窄范围。对于必须跨区域共享的策略，通过条件限定区域，实现“同一策略、不同区域、不同权限”。
为灾备操作设计独立的权限角色。灾备切换、数据恢复等操作应由专门的组和策略控制，不与日常生产运维权限混用。
定期审计跨区域策略。使用 OCI 的审计日志和策略分析工具，检查是否存在过度授权或区域范围过宽的策略。

动态组的匹配规则支持 instance.compartment.id、instance.region、tag 等条件。在跨区域设计中，优先使用 compartment 和 region 组合来限定动态组范围，比单纯依赖标签更稳定，因为标签可能被误修改。

一个可参考的跨区域权限矩阵

下表给出一个简化的跨区域权限分配示例，适用于“生产区域 + 灾备区域”双活或主备架构。表中“区域”列表示策略实际生效的区域范围，“主体”列表示被授权的用户组或动态组，“权限”列表示授予的操作级别。

区域	主体	Compartment	权限	说明
ap-tokyo-1	组：Prod-Ops	Prod	manage instance-family	生产区域日常运维
ap-singapore-1	组：DR-Ops	DR	manage instance-family	灾备区域运维，与生产隔离
全局	动态组：DR-Instance-Readers	Backup	read objects	仅灾备区域实例可读备份桶
全局	组：Security-Auditors	所有	inspect all-resources	只读审计，跨区域可见

这张矩阵的核心思想是：权限边界与资源边界对齐。生产运维组不应拥有灾备区域的写权限，灾备运维组也不应干预生产区域。审计角色可以跨区域只读，但不应具备修改能力。动态组则用于资源主体之间的自动化授权，其范围通过区域和 compartment 双重限定。

常见陷阱与排查思路

跨区域 IAM 设计中最常见的三个问题：第一，策略在全局定义后，误以为只对某个区域生效，导致权限过大；第二，动态组匹配规则未限定区域，导致灾备区域实例获得了生产区域的权限；第三，联合身份登录后，用户所属的 OCI 组映射错误，导致跨区域权限缺失或多余。

排查时，可以按以下顺序定位：先确认策略语句的 in compartment 和 where 条件是否包含区域约束；再检查动态组的匹配规则是否使用了 instance.region 或 compartment 条件；最后核对联合身份中企业目录组与 OCI 组的映射关系。OCI 的审计日志会记录每次 API 调用的主体、区域和资源，是验证权限实际生效范围的最直接依据。

不要将生产区域和灾备区域的管理权限授予同一个组，除非有明确的业务理由并经过安全评审。跨区域权限一旦过度集中，单点凭证泄露就可能同时影响两个区域，违背灾备架构“隔离风险”的初衷。

总结来说，OCI 的 IAM 是全局的，但跨区域权限管理必须通过 compartment、动态组匹配规则和策略条件来实现区域级隔离。联合身份解决了用户登录的统一入口问题，但不替代权限边界设计。将“全局身份”与“区域资源”通过清晰的 compartment 结构和条件策略连接起来，才能在多区域高可用与灾备架构中既保证操作效率，又守住安全底线。