3. 用户与组管理实战

在 Oracle Cloud Infrastructure（OCI）的身份与访问管理（IAM）体系中，本地用户（Local User）是指直接创建在某个租户（Tenancy）内、由该租户自行维护凭证的 IAM 用户，区别于通过身份联合（Federation）从外部 IdP 映射进来的联合用户。本地用户适合管理员账号、服务账号、临时运维账号以及尚未接入企业 IdP 的场景。理解本地用户、用户组与凭证三者的关系，是后续所有权限治理工作的基础。

一、本地用户与用户组的基本关系

OCI 的授权模型可以概括为一句话：策略（Policy）把权限授予组，组把用户聚合起来，用户凭凭证登录或调用 API。也就是说，权限从不直接绑定到单个用户，而是绑定到组。用户通过“加入组”间接获得权限。这种设计的好处是：当人员岗位变化时，只需调整组成员关系，而不必逐条修改策略。

一个用户可以同时属于多个组，其最终权限是所属各组的权限并集；OCI 没有“拒绝优先”的显式 deny 机制，因此权限只增不减，设计组结构时必须谨慎，避免把高权限组随意授予普通用户。组本身是租户级的全局对象，不隶属于某个区间（Compartment），但策略中可以通过 in compartment 限定组权限生效的范围。

二、创建本地用户与用户组

创建本地用户时，需要提供用户名（唯一，登录名）、描述、邮箱（用于接收通知和密码重置），并选择是否在创建时直接分配控制台密码。用户名一旦创建不可修改，因此命名应遵循统一规范，例如 alice.zhang、svc-backup。创建完成后，用户默认没有任何权限，必须加入组并通过策略获得授权。

创建用户组的操作更简单，只需提供组名和描述。组名同样在租户内唯一。建议按“职责”而非“部门”建组，例如 Developers、DBA-Admins、Network-Operators，这样策略语义清晰，人员调动时只需改组成员。把用户加入组时，可以在用户详情页的“Groups”标签中操作，也可以在组详情页的“Users”标签中反向添加。

三、批量导入用户

当需要一次性创建几十上百个用户时，逐个手工创建效率极低。OCI 支持通过 CSV 文件批量导入用户。典型流程是：在 IAM 控制台选择“Import Users”，下载模板 CSV，按模板填写字段后上传。模板关键字段包括：

username,email,description,groups,password
alice.zhang,alice@example.com,Dev lead,Developers,
bob.li,bob@example.com,Developer,Developers,
carol.wang,carol@example.com,Auditor,Auditors,
svc-backup,ops@example.com,Backup service account,ServiceAccounts,

需要注意：CSV 中的 groups 字段若引用了尚不存在的组，导入会失败，因此应先建组、再导用户。密码列通常留空，由系统生成一次性密码并通过邮件发送，用户首次登录时强制修改。批量导入适合初始化阶段；日常新增单个用户仍建议手工创建，便于即时校验。

四、设置用户凭证

本地用户可持有三类主要凭证，用途各不相同：

• 控制台密码（Console Password）：用于登录 OCI 网页控制台。管理员可创建、重置或删除。重置后系统生成一次性密码，用户首次登录必须修改。密码策略由租户级设置统一约束，例如最小长度、是否要求大小写与特殊字符、有效期等。
• API 签名密钥（API Key）：用于通过 CLI、SDK 或 REST API 以该用户身份调用 OCI 接口。采用 RSA 公私钥对，用户上传公钥，OCI 保存公钥指纹，私钥由用户本地保管。调用时用私钥签名请求，OCI 用公钥验签。一个用户最多可拥有 3 个 API 密钥，便于轮换。
• Auth Token（认证令牌）：用于访问 OCI 的 Swift 兼容对象存储接口、以及部分需要令牌的注册表/制品仓库场景。它是随机生成的字符串，只在创建时显示一次，必须立即保存，之后无法再次查看。

五、组在权限分配中的作用

组是 OCI 授权的最小单位。策略语句的基本形式是：

Allow group Developers to use instances in compartment Dev
Allow group Auditors to read all-resources in tenancy
Allow group ServiceAccounts to manage object-family in compartment Backup

第一条允许 Developers 组在 Dev 区间内使用计算实例；第二条允许 Auditors 组只读整个租户的资源；第三条允许服务账号组在 Backup 区间管理对象存储。可以看到，策略的“主语”永远是组，而不是用户。因此，组设计的合理性直接决定权限治理的质量。如果组划分过粗，会导致权限过度集中；划分过细，则策略数量膨胀、维护困难。实践中常采用“角色组 + 资源域组”的组合方式，例如 Dev-Developers、Prod-Developers，让同一角色在不同环境获得不同范围的权限。

最后需要强调：删除用户前应先移除其 API 密钥、Auth Token 和组成员关系，避免残留凭证造成安全风险；停用（Deactivate）用户是比直接删除更稳妥的过渡手段，可在保留审计记录的同时立即阻断登录与 API 调用。