2、权限边界评审的重要性：为什么需要权限边界评审、合规性要求（SOC2、PCI-DSS）、最小权限原则在制品目录中的应用

在 OCI 制品目录（Artifact Registry）中，权限边界（Permission Boundary）是控制用户、组或服务主体对容器镜像、Helm Chart 和 OCI 制品执行操作的安全防线。缺乏定期的权限边界评审，会导致权限膨胀、横向移动风险上升，并直接违反多项合规审计要求。本章从三个维度阐述权限边界评审的必要性。

2.1 为什么需要权限边界评审

权限边界评审不是一次性配置，而是一个持续的安全治理过程。以下四个核心原因决定了评审的不可替代性：

• 权限膨胀（Permission Creep）： 随着项目迭代、人员流动和自动化流水线接入，用户和服务的实际权限往往远超其职责所需。未评审的权限会逐渐累积，形成“超级用户”或“幽灵权限”。
• 攻击面最小化： 制品目录中存储的镜像和 Chart 可能包含敏感业务逻辑、密钥或基础镜像漏洞。过宽的权限允许攻击者通过一个被攻陷的 CI/CD 节点或离职员工的未回收凭证，批量拉取或篡改制品。
• 变更溯源与审计： 权限边界评审能够建立“谁、在何时、对哪个仓库、执行了什么操作”的完整审计基线。没有评审，就无法区分合法操作与异常行为。
• 多云与多租户隔离： 在 OCI 多租户架构中，不同部门或环境（开发/测试/生产）共享同一租户下的制品目录。权限边界评审确保租户间的隔离策略未被绕过。

2.2 合规性要求：SOC2 与 PCI-DSS

权限边界评审是多项安全合规框架的明确控制项。下表对比了 SOC2 和 PCI-DSS 中对制品仓库权限管理的核心要求：

2.3 最小权限原则在制品目录中的应用

最小权限原则（Principle of Least Privilege, PoLP）要求每个主体只拥有完成其任务所必需的最小权限集合。在 OCI 制品目录中，这一原则通过以下三个层次落地：

1. 仓库级权限隔离： 为每个项目或微服务创建独立的仓库（Repository），并设置对应的 IAM 策略。例如，team-a 只能访问 repo-team-a，无法读取 repo-team-b。
2. 操作类型最小化： 区分拉取（Pull）、推送（Push）、删除（Delete）和列出（List）等操作。CI/CD 流水线通常只需要 Pull 和 Push，不应授予 Delete 权限。
3. 临时权限与动态边界： 使用 OCI 的预认证请求（Pre-authenticated Requests）或临时令牌，为一次性构建任务授予限时权限，避免长期凭证泄露。

下图展示了最小权限原则在制品目录中的典型权限分配模型：

2.4 权限边界评审的核心流程

一个完整的权限边界评审流程通常包含以下五个步骤，建议将其集成到组织的安全运营（SecOps）流程中：

1. 清单收集： 导出 OCI 租户下所有制品仓库的 IAM 策略绑定，包括用户、组、动态组和服务主体。
2. 权限映射： 将每个主体与其实际拥有的操作权限（Pull/Push/Delete/List/Manage）进行矩阵化映射。
3. 基线比对： 将当前权限矩阵与预先定义的“最小权限基线”进行差异分析，标记出超配权限。
4. 审批与修正： 对超配权限发起变更工单，经仓库负责人和安全团队审批后，执行策略收紧或移除。
5. 证据留存： 将评审报告、审批记录和修正后的策略快照归档，用于合规审计。

2.5 评审频率与触发条件

下表总结了推荐的评审频率和触发条件，帮助组织建立可持续的权限治理节奏：