2. OCI生产环境接入与身份管理
在OCI生产环境中，身份与访问管理（IAM）不是“建完账号就结束”的初始化动作，而是贯穿资源生命周期的基础控制面。生产事故中相当一部分并非来自底层硬件或网络，而是来自权限边界不清：某个开发人员误删了生产数据库、某个实例被赋予了过宽的权限、某个动态组被错误地允许访问对象存储中的备份桶。理解租户、区间、用户、组、策略、动态组之间的层级与授权关系，是生产运维的第一道防线。
一、租户与区间：资源隔离的两层结构
租户（Tenancy）是OCI中的顶层账户边界，所有资源、用户、策略都归属于某个租户。一个企业通常只有一个生产租户，也可能按业务线或合规要求拆分为多个租户。租户之下是区间（Compartment），区间是资源的逻辑容器，也是策略授权的基本作用域。生产环境常见的区间划分方式包括：按环境划分（prod、stage、dev）、按业务系统划分（order、payment、inventory）、按资源类型划分（network、compute、database）。
区间可以嵌套，形成树状结构。例如根区间下建立 Production，其下再建立 Production-Network、Production-App、Production-DB。策略写在父区间上时，默认对子区间生效，这既是便利也是风险：一条写在 Production 上的宽泛策略，会同时影响其下所有子区间。因此生产实践中，策略应尽量写在最具体的区间层级，避免在根区间或生产父区间上授予写权限。
二、用户、组与策略：授权的基本链路
OCI的授权模型可以概括为：策略（Policy）把“谁”对“什么资源”在“哪个区间”拥有“哪些权限”写成一条可读语句。策略的主体（subject）通常是组或动态组，而不是单个用户。这是生产环境必须坚持的原则：用户加入组，组被策略授权，用户离职或转岗时只需调整组成员关系，不必逐条修改策略。
一条典型的生产策略如下：
Allow group Prod-Network-Admins to manage virtual-network-family in compartment Production-Network
Allow group Prod-App-Operators to use instances in compartment Production-App
Allow group Prod-DBA to manage db-systems in compartment Production-DB
Allow group Prod-Auditors to read all-resources in tenancy
Allow dynamic-group Prod-App-Instances to read objects in compartment Production-App
Allow dynamic-group Prod-App-Instances to use secrets in compartment Production-App这里有几个关键点。第一，manage 包含创建、修改、删除等全部动作，use 通常只包含使用已有资源（如启动、停止、连接），read 只读。第二，virtual-network-family 是一个资源族，包含VCN、子网、路由表、安全列表等，比逐个资源授权更简洁，但也更宽，需要评估。第三，in compartment 限定了作用域，若写成 in tenancy，则对整个租户生效，生产环境应严格避免。
三、动态组：为实例和函数赋予身份
动态组解决的是“非人类身份”的授权问题。生产中的计算实例、函数、容器实例需要访问对象存储、密钥管理、数据库等服务，传统做法是把用户凭证写在实例上，这既难轮换又容易泄露。动态组通过匹配规则（matching rule）自动把符合条件的资源纳入组，再通过策略授权。
例如，只允许 Production-App 区间中带有标签 Role=app 的实例读取备份桶：
Allow dynamic-group Prod-App-Instances to read objects in compartment Production-App
where target.bucket.name = 'prod-app-backup'动态组的匹配规则应尽量精确，避免使用 instance.compartment.id = '...' 这种把整个区间所有实例都纳入的宽泛条件。更安全的做法是结合标签：tag.Environment.Value = 'Production' 且 tag.Role.Value = 'App'。同时，动态组策略应只授予实例运行所必需的最小权限，例如只读特定桶、只读取特定密钥，而不是 manage all-resources。
四、生产权限最小化的落地检查
权限最小化不是一句口号，而是可以逐项核对的工程实践。以下检查表可直接用于生产租户的IAM审计：
| 检查项 | 合格标准 | 常见问题 |
|---|---|---|
| 根区间策略 | 无写权限策略 | 存在 manage all-resources in tenancy |
| 用户直授 | 策略主体均为组或动态组 | 存在以用户为主体的策略 |
| 组划分 | 按角色分离：网络、应用、DBA、审计 | 一个组拥有全部生产权限 |
| 动态组规则 | 基于标签精确匹配 | 按区间匹配，范围过大 |
| MFA | 所有生产用户启用MFA | 部分用户未启用 |
| 审计组 | 只读权限，独立于运维组 | 审计人员拥有写权限 |
Allow group XXX to manage all-resources in tenancy，应视为高危项。该策略等价于租户管理员，可删除任意资源、修改任意策略、创建任意用户。除非是极少数受控的租户管理员组，否则必须移除或收窄到具体区间和资源族。
五、接入生产环境的实际操作顺序
当一名运维人员需要接入生产环境时，推荐按以下顺序操作，而不是直接给用户开权限：
- 在
Production下确认或创建目标区间，明确该人员负责的资源范围。 - 创建或复用一个角色组，例如
Prod-App-Operators，组名体现职责而非人名。 - 为该组编写策略，使用
use或read而非manage，作用域限定到具体区间。 - 创建用户，启用MFA，将用户加入对应组，不直接给用户写策略。
- 若涉及实例访问其他服务，创建动态组并编写精确匹配规则，授予最小权限。
- 用审计日志验证：让该用户执行一次预期操作和一次越权操作，确认前者成功、后者被拒绝。
最后一步的验证常被忽略，但它是确认权限边界是否正确的唯一手段。例如，让 Prod-App-Operators 组中的用户尝试删除 Production-DB 中的数据库，预期应返回 NotAuthorizedOrNotFound；尝试停止 Production-App 中的实例，预期应成功。只有通过这种正反两面的验证，才能确认策略既没有过宽，也没有过窄影响正常运维。