OCI 架构基础：区域、域和 IAM 实际是如何协同工作的

I’m happy to translate the article for you, but I need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link and all formatting exactly as you requested.

🧠 OCI 背后的核心理念

OCI 围绕一个假设构建：

故障是正常的。为此进行设计。

这一理念无处不在：

• Oracle 设计数据中心的方式
• 工作负载部署的方式
• 访问控制的方式

OCI 的基础有两层：

1. 物理弹性 – 工作负载运行的地方
2. 逻辑控制 – 谁可以访问什么

🌍 区域

A Region 是 OCI 运行云基础设施的地理位置。

您选择区域的依据包括：

• Latency – 越靠近用户越好
• Legal and data‑residency requirements – 法律和数据驻留要求
• Service availability – 服务可用性

区域之间相互隔离。如果整个区域宕机，其他区域不受影响。这种隔离正是灾难恢复得以实现的原因。

🏢 可用域 (AD)

可用域是位于同一区域内的 物理上独立的数据中心。

Each AD:

• 拥有独立的电力、冷却和硬件
• 不 与其他 AD 共享物理基础设施
• 通过低延迟链路与其他 AD 连接

如果一个 AD 发生故障，其他 AD 中的工作负载仍可继续运行。并非所有区域都有多个 AD，这直接影响您在高可用性方面的设计。

🧩 Fault Domains (FDs)

Fault Domains exist inside an Availability Domain.
故障域存在于可用域内部。

A Fault Domain is a logical grouping of hardware within an AD.
故障域是 AD 内部硬件的逻辑分组。

Key points
关键点

• Each AD has three Fault Domains
  每个可用域拥有三个故障域
• Hardware such as racks, power units, and cooling are isolated per FD
  机架、电源单元、冷却等硬件在每个故障域内是相互隔离的
• OCI performs maintenance in only one FD at a time
  OCI 每次仅在一个故障域内进行维护

If you place multiple instances in different Fault Domains:
如果在不同的故障域中放置多个实例：

• A single hardware failure won’t take everything down
  单个硬件故障不会导致所有实例宕机
• Planned maintenance won’t affect all instances at once
  计划维护不会一次性影响所有实例

FDs protect you from local hardware failures; ADs protect you from data‑center failures.
故障域可保护您免受本地硬件故障的影响；可用域可保护您免受数据中心故障的影响。

🛡️ 高可用性设计

一个简单、实用的策略：

经验法则

• FDs → 硬件故障
• ADs → 数据中心故障
• Regions → 灾难恢复

OCI 提供工具；由您决定系统的弹性程度。

🔐 OCI 身份与访问管理 (IAM)

一旦工作负载运行起来，下一个显而易见的问题是：

谁被允许操作这些资源？

IAM 有两项职责：

1. 认证 – 你是谁（证明身份）
2. 授权 – 你被允许做什么（执行权限）

👤 认证 (AuthN)

认证在授予访问权限之前验证你的身份。OCI 支持：

• 用户名和密码
• API 密钥
• OAuth 2.0 令牌
• 多因素认证 (MFA)
• 实例主体（无需存储凭证）
• 使用 SAML 2.0 与外部身份提供者的联合认证

目标是实现安全、可验证的访问，同时不泄露机密信息。

🪪 授权 (AuthZ)：策略决定访问

OCI 采用 默认拒绝 的授权模型。除非策略明确允许，否则任何操作都不被允许。

其逻辑始终是：

谁 → 可以做什么 → 在哪些资源上 → 位于哪个位置

策略是实现 IAM 可预测且可审计的执行层。

🧑‍🤝‍🧑 身份域

身份域是用于存放身份的逻辑容器。它包含：

• 用户
• 组
• 应用程序
• 联合设置

可以把身份域想象成用于人的“ compartment”（分区），而不是资源的。

高级视图

OCI Tenancy
└─ Compartment
   └─ Identity Domain
      └─ Users / Groups / Applications

默认身份域

每个 OCI 租户都会配备一个 默认身份域。

重要事实：

• 不能被删除或禁用
• 会复制到所有已订阅的区域
• 始终出现在登录页面上

它包括：

• 一个用户——租户的创建者
• 一个拥有完整租户访问权限的 Administrators 组
• 一个 All Domain Users 组

此域通常用于管理 OCI 基础设施访问。

为什么要创建额外的身份域？

多个身份域用于实现隔离和控制。

常见使用场景

• 将生产环境和开发环境的访问分离
• 隔离合作伙伴的访问
• 为公共应用管理消费者身份

每个域可以拥有：

• 各自的管理员
• 各自的安全策略
• 各自的用户群体

这样可以防止一个团队的错误影响到另一个团队。

📦 隔离区

隔离区是 OCI 资源的逻辑容器。它们具有以下特性：

• 跨区域全局
• 可嵌套至多六层
• 用于隔离、计费、配额和访问控制

策略的作用范围是隔离区，而不是直接作用于资源。

最佳实践： 在可能的最低层级附加策略。

👥 组和委派管理

权限分配给 组，而不是单个用户。

良好实践

1. 根据角色创建组
2. 将策略附加到组
3. 将用户加入组

OCI 还支持委派管理员角色，例如：

• 安全管理员
• 应用管理员
• 帮助台管理员
• 审计管理员

这样可避免为所有人授予完整的管理员访问权限。

🌐 网络来源

Network Source 定义允许的 IP 范围或 VCN。

用于：

• 限制 API 调用仅限受信任的网络
• 对 IAM 强制基于源 IP 的策略

典型场景： 将敏感操作限制在企业网络内。

它们在策略中直接引用，以实现细粒度控制。

✅ Final Takeaway

OCI 并非偶然复杂。它之所以结构化，是因为它被设计用于规模化和容错。

• Regions、ADs 和 FDs 保障可用性
• Compartments 组织资源
• Identity Domains 组织人员
• Policies 强制最小权限

当你把 IAM 和基础设施视为架构决策时，OCI 将变得可预测、可扩展且安全。这就是关键。

🔔 接下来是什么

本文聚焦于 OCI 的架构和 IAM 基础。

在下一部分，我们将深入探讨 IAM policies：授权实际是如何运作的、策略是如何评估的，以及为何 OCI 中的大多数访问问题都归结为策略设计。

敬请期待。