身份权限

避免使用 Root 身份

在阿里云上，注册完一个阿里云账号后，即可通过用户名和密码的方式登录到阿里云控制台，登录成功后，即获得了 Root 身份。该身份具有该账号下所有的权限，一旦账号密码泄漏，风险极高。另外，如果多人共用该身份，每个人都保有该账号的用户名和密码，会增加泄漏的可能。同时，多人共享的情况下，在云上的操作日志中无法区分出是组织中哪个人使用了该身份进行了操作，也无法进行进一步溯源。因此，除了极个别场景，应该尽可能的使用阿里云 RAM 身份进行云上资源的访问，避免使用阿里云账号的 Root 身份。

实现人员身份的统一认证

通过集中化的身份提供商（Identity Provider，简称 IdP）来进行人员身份的统一认证，能够简化人员身份的管理，确保组织内在云上、云下的人员身份的一致性。当人员结构变更、人员入职、离职时，能够在一个地方完成人员身份的配置。对于云环境的使用者来说，也无需为其颁发额外的用户名和密码（如 RAM 用户名和密码），只需要保管好其在组织内的 IdP 中的身份和凭据即可。

阿里云支持基于 SAML 2.0 协议的单点登录（Single Sign On，简称 SSO）。在阿里云上，我们建议通过 RAM SSO 的方式跟组织内的 IdP 进行集成，实现人员身份的统一认证。对于云上有多个阿里云账号的复杂组织，还可以通过云SSO进行多账号下的 SSO 集中化配置，进一步实现多账号下的人员身份统一管理，提升管理效率。

AI 场景下的实践建议：

对于 AI 场景，建议优先使用 RAM Role 进行身份管理，因为角色身份更安全、便于权限管理。大多数 AI 服务（如百炼、PAI、ACK、OSS 等）都支持 RAM Role，建议采用云SSO + RAM Role 的方式，通过云SSO创建访问配置模板，将企业 IdP 中的用户组映射到阿里云 RAM 角色，从而实现对 AI 服务访问人员的统一管理。

对于不支持 RAM Role 的 AI 服务，需要通过云SSO的用户同步功能，将用户直接同步到对应账号，采用用户 SSO 的方式进行访问。

典型的角色划分包括：

• AI 模型管理员：负责 AI 模型的全局管理，需要跨业务空间的管理权限。

• AI 应用研发：负责智能体开发、模型调用等应用研发工作，仅需要特定业务空间的访问权限。

• 数据管理员：负责 AI 训练数据的准备和管理，需要数据相关的访问权限。

AI 场景下的 SSO 架构示例：

在 AI Landing Zone 场景下，建议采用集中化的 SSO 架构来统一管理多账号下的身份和访问。典型的架构示例如下：

该架构展示了 AI 场景下的 SSO 认证和访问流程：

1. 身份认证发起：用户通过外部身份提供商（IdP），如 Microsoft Entra ID、Okta 等，发起登录请求。

2. 认证和同步：IdP 通过 SAML 2.0 协议将认证信息传递给 IAM 账号中的 Cloud SSO，同时通过 SCIM 协议进行用户信息同步，确保云上用户身份与 IdP 中的身份保持一致。

3. 集中化身份管理：IAM 账号作为核心身份管理中心，通过 Cloud SSO 接收并处理来自 IdP 的认证请求。管理账号（可选）可以通过委派管理员的方式，对 Cloud SSO 进行统一管控，实现身份管理的集中化控制。

4. 访问路由和权限分配：根据用户身份和权限配置，Cloud SSO 将用户路由到不同的生产账号，并根据账号类型采用不同的 SSO 方式：

   • Workload Account (Prod)：采用角色 SSO 方式，通过访问配置模板，用户通过角色扮演（如 Admin、PowerUser、Security、Dev 等角色）访问该账号，管理 ECS、RDS 等工作负载资源。

   • Big Data Account (Prod)：采用用户 SSO 方式，通过用户同步功能，直接将用户身份同步到该账号，用户可以直接访问 MaxCompute、DataWorks 等大数据服务，进行业务空间权限管理等操作。

   • AI Account (Prod)：采用角色 SSO 方式，通过访问配置模板，用户通过角色扮演（如 Admin、PowerUser、Security、Dev 等角色）访问该账号，管理 PAI、Bailian 等 AI 基础设施和平台服务。

5. 资源访问：用户完成 SSO 登录后，根据所分配的角色或用户权限，访问对应账号下的云服务和资源，进行相应的操作和管理。

架构设计要点：

1. 角色SSO vs 用户SSO：

   • 角色SSO：适用于支持 RAM Role 的服务（如百炼、ECS、PAI、ACK、GPU 等），通过角色扮演实现临时身份访问，更安全且便于权限管理。对于 AI 服务，应优先使用角色 SSO。

   • 用户SSO：仅适用于不支持 RAM Role 的 AI 服务，需要直接的用户身份进行业务空间权限管理等操作。对于此类服务，必须使用用户 SSO 的方式。

2. 访问配置模板化：通过云SSO创建访问配置模板，可以实现权限策略的复用，针对不同账号应用相同的权限模板，降低管理复杂度。

3. 多账号统一管理：通过集中化的 IAM 账号管理 Cloud SSO，实现所有生产账号的身份和权限统一管理，当人员变动时，只需在一个地方进行配置即可影响所有账号。

建立更安全的登录机制

对于人员身份的登录方式，往往是通过用户名和密码的方式进行。一旦用户名和密码泄漏，攻击者极有可能通过该身份登录阿里云，造成一些不可挽回的损失。因此，对于人员身份来说，保护好用户名和密码显得尤为重要。可以从以下几种方式提升登录方式的安全性：

1. 提升密码强度：如增加密码位数、混合使用数字、大小写字母、特殊字符等。针对阿里云 RAM 用户，管理员可以设置密码强度规则，强制 RAM 用户使用更复杂的密码，降低密码泄漏和被破解的风险。

2. 避免密码混用：在不同的服务、站点，或不同的用户共用一个密码，增加了密码的暴露面积，会增加密码泄漏的可能性。

3. 定期轮转密码：密码存在的时间越长，泄漏风险越高。通过定期重设密码，降低单个密码存在的时长，能够进一步降低密码泄漏风险。

4. 使用多因素验证：多因素认证 MFA（Multi Factor Authentication）是一种简单有效的安全实践，在用户名和密码之外再增加一层安全保护，用于登录阿里云或进行敏感操作时的二次身份验证。建议为云上的人员身份都启用二次验证。

通过角色扮演代替固定身份

基于缩小暴露面积的原则，使用临时身份替代固定身份，能极大降低身份泄漏风险，同时对于人员身份来说，也能够抽象人员权限模型，如按人员职能进行角色划分，有利于规范化人员权限设置，提升管理效率。

在云上，建议通过单点登录（Single Sign-on，简称 SSO），基于角色扮演的方式，实现人员身份的管理。在 AI 场景下，通过云SSO创建访问配置，定义不同角色的权限模板，然后将用户或用户组映射到相应的访问配置，实现基于角色的统一管理。

不使用云账号 AccessKey

云账号 AccessKey 等同于阿里云账号的 Root 权限，也就是该账号内的完全管理权限，而且无法进行条件限制（例如：访问来源IP地址、访问时间等），也无法缩小权限，一旦泄漏风险极大。对于程序访问的场景，请使用 RAM 用户的 AccessKey 来进行阿里云 API 的调用。

避免共用 AccessKey

多个程序身份共用 AccessKey，或程序身份、人员身份共用 AccessKey 的情况下，AccessKey 所关联的权限需要包含所有身份的使用场景，导致权限扩大。另外，共用场景下，一处泄漏会导致所有应用都受到影响，风险扩大，同时增加了泄漏后的止血难度。

因此，针对不同应用、大型应用的不同模块、同一个应用（或模块）的不同环境（如生产环境、测试环境等），都建议创建不同的 AccessKey 供程序身份使用，每个 AccessKey 只有该场景下所需要的权限，避免共用 AccessKey 的情况。

定期轮转 AccessKey

同人员身份的用户名密码一样，AccessKey 创建和使用时间越长，泄漏的风险越高。每隔一段时间，通过创建新的 AccessKey，替换掉应用在使用的 AccessKey，并将旧 AccessKey 进行禁用和删除，实现 AccessKey 的定期轮转。另外，也可以通过阿里云密钥管理服务（Key Management Service，简称 KMS）的凭据管家功能，实现自动化的定期 AccessKey 轮转。

AI 场景下的 API-Key 管理

对于 AI 服务（如百炼），通常需要创建 API-Key 供应用程序调用。建议创建一个给应用程序用的 RAM User（禁掉控制台登录），给这个 RAM User 分配一个 API-Key。这样就不会出现因为用户离职之后导致的 Key 失效问题，同时也能实现程序身份与人员身份的隔离管理。

使用临时凭据代替固定凭据

通过给 RAM 用户或云账号的 Root 身份创建 AccessKey 供程序调用，都属于固定凭据类型。一旦创建出来，在删除之前，就是由固定的 AccessKey ID 和 AccessKey Secret 组成了该凭据。使用固定凭据会造成很多风险，比如应用研发人员将固定 AccessKey 写入了代码中，并将其上传到了 Github 等公开仓库，造成了 AccessKey 泄漏，最终导致业务受损。在阿里云上，我们建议尽可能通过角色扮演的方式获取临时凭据 STS Token，代替固定 AccessKey 的使用。

针对不同类型的云上应用部署方式，阿里云提供了相应的功能，集成了 STS Token 凭据的使用：

1. ECS 实例：通过实例RAM角色，将 RAM 角色跟实例进行绑定，应用程序中即可通过实例元数据服务获取临时授权Token。

2. 容器服务（ACK）：通过RRSA功能，实现 RAM 角色和指定 ServiceAccount 进行绑定，在 Pod 维度即可扮演对应角色实现 STS Token 的获取。

3. 函数计算（FC）：可以为对应函数所属服务授予函数计算访问其他云服务的权限，实现 STS Token 的获取。

统一管理所有 Agent 身份

AI Agent 是新的攻击面，需要对企业所有的 AI Agent 进行统一的管理，自动发现并注册每个 AI Agent 的身份，避免未纳入管理、监控的 AI Agent 发生非预期的安全事件。

建议通过 Agent Identity 统一管理各类AI Agent，如百炼平台的Agent、Dify 平台的 Agent，以及基于任何 Agent 框架构建的 AI Agent。并基于 Agent Identity 持续监控、管理用户及程序在AI Agent 的访问权限及使用情况。

基于组织 IdP 对 Agent 用户进行认证

IdP 身份提供商集中管理企业员工身份或者用户身份，基于 IdP 建立 Agent 的信任关系并提供对 Agent 的访问能力，可以确保每次用户对 Agent 的访问，都是可信、可验证的，同时当人员变动，如新加入、离开时，对 Agent 的访问权限也随之赋予、撤销。

建议通过 Agent Identity 配置 Agent 对 IdP 的信任关系，从而实现基于 IdP 的无密钥统一认证。

统一管理 Agent 需要使用的凭据

AI Agent 在访问大模型服务（如阿里云百炼）、阿里云服务（如 OSS）、企业服务（如 CRM）、SaaS 服务（如钉钉）时，需要使用各类访问凭据，需要对凭证进行统一的管理。

建议通过 Agent Identity 的凭证提供商进行统一管理，基于 KMS 对凭证进行安全存储，并实现：只有正确的人，使用正确的 AI Agent，才能临时获取到对应服务的访问凭证。

基于人员职能进行授权

对于组织来说，不同职责的人需要访问云上不同类型的资源。对于 AI 场景，建议针对以下角色进行权限设计：

• 全局云管理员：拥有企业在阿里云上资源的全部权限。

• AI 模型管理员：拥有 AI 服务（如百炼）的全局管理权限，可以跨业务空间进行管理，负责模型的分配和业务空间的规划。

• AI 应用研发：拥有特定业务空间的访问权限，可以进行智能体开发、模型调用等工作。

• AI 数据管理员：拥有数据相关的访问权限，负责训练数据的准备和管理。

• 网络管理员：拥有对各类网络产品的管理权限。

• 安全管理员：拥有全部安全产品的管理权限。

• 合规管理员：拥有合规相关产品的管理权限。

在对职能权限进行抽象后，可以通过将人员身份加入到指定职能用户组的方式进行组织，提升授权效率。

按资源范围授权

虽然权限管理的核心原则是最小化授权，但如果为组织中的每个人员身份都定制化权限，对于大型组织来说，会大大降低管理效率。因此，按照人员所管理的业务应用对应的资源范围进行授权，能够简化授权逻辑，提高权限策略复用率，进而在权限最小化和管理效率中取得平衡。

在云上，建议通过阿里云账号或资源组两种方式，区分不同业务应用的资源。如果企业使用多个阿里云账号管理云资源，则可以使用资源目录构建企业组织结构，对账号和资源进行集中、有序地管理，不同的业务应用按账号维度进行区分，授权时应用范围选择整个云账号。如果企业使用一个阿里云账号管理所有云资源，各个项目组可以使用资源组作为资源隔离和权限管理的容器，在授权时应用范围选择指定的资源组。

AI 场景下的实践建议：

对于 AI 场景，特别是使用百炼等 MaaS 平台时，建议通过业务空间进行资源隔离和权限管理：

• 业务空间规划：模型管理员负责规划业务空间，按照不同的业务应用、项目组或部门创建不同的业务空间。

• 业务空间权限：通过 RAM Role（优先）或 RAM User（对于不支持 RAM Role 的服务）的方式将用户或用户组授权访问特定业务空间，实现按业务空间进行权限隔离。

• 跨业务空间管理权限：全局管理权限（如 AliyunBailianFullAccess）允许用户进行跨业务空间的管理操作（如创建业务空间、删除业务空间、分配模型权限等），但不包含对具体业务空间内资源的访问权限（如调用模型、创建应用等）。业务空间内的资源访问权限需要单独授予。因此，全局管理权限建议只分配给模型管理员，用于统一管理业务空间和模型分配。

AI 服务的多层次权限管理

AI 服务（如百炼）通常具有多层次的权限体系，需要分别进行精细化管控：

1. RAM 管控面权限：通过 RAM Role（优先）或 RAM User（对于不支持 RAM Role 的服务）授予用户在 AI 服务上的基础访问权限，如 AliyunBailianFullAccess（全局管理）、AliyunBailianReadOnlyAccess（只读）、AliyunBailianDataFullAccess（数据管理）等。

2. 业务空间权限：控制用户能否访问特定的业务空间。这是 AI 场景下资源隔离的核心机制。

3. 模型权限：控制业务空间能否调用、训练和部署某个模型。模型权限与用户权限分离，由模型管理员统一分配给不同业务空间，与空间成员的权限无关。

实践建议：

• 模型权限统一管理：建议由模型管理员统一为不同业务空间分配模型权限及相关限流配置，避免权限分散管理。

• 权限分离原则：理解 RAM 权限、业务空间权限、模型权限之间的关系，建立清晰的权限管理体系。

精细化授权

除一些特定业务场景外，应用程序所需要访问的阿里云资源，对应进行的操作是可以预期，尽可能的通过自定义权限策略来定义该程序身份所需要的最小权限。对于 AI 场景，应用程序通常只需要调用特定模型权限，不应该授予全局管理权限。

相反，如果直接使用系统策略，给该程序授予 AliyunBailianFullAccess 权限，那么一旦该程序身份泄露，攻击者就有该云账号下所有 AI 服务的所有权限，风险极高。

AI 场景下的程序身份权限设计

对于 AI 应用，建议根据应用的实际需求进行精细化授权：

• 模型调用场景：仅授予特定模型的调用权限，限制调用频率和资源配额。

• 数据访问场景：仅授予特定数据源的读取权限，如特定 OSS Bucket 的读取权限。

• 训练场景：仅授予特定模型的训练权限，限制训练资源的使用。

明确可使用 Agent 的用户范围

AI Agent 的调用方以及 AI Agent 自身，都需要控制允许使用 Agent 的用户范围。需要在 AI Agent 上配置允许的用户域（如企业内部的员工，或者经过某 IdP 认证的用户），从而实现对 Agent 访问的纵深防御。

建议使用 Agent Identity 的身份提供商，并配置允许的 IdP 或者允许的受众，从而避免未经授权的 Agent 访问。

Agent 使用委托代表用户访问资源

对于公共资源，AI Agent 可能以 Agent 自己的身份权限进行资源访问，但对于企业内、用户私有数据，应该使用委托授权的方式，经用户授权后对其访问。

建议使用 Agent Identity 的 OAuth2 凭证提供商，全托管对下游服务、工具的访问授权，在 AI Agent 需要访问服务、数据时，发起 OAuth 授权流程，即时获取对服务、工具的最小访问权限。

对 Agent 获取凭据进行细粒度权限控制

AI Agent 需要访问各类服务、工具，访问这些服务、工具时都需要相应的凭证（如 API Key、Token），AI Agent 在获取凭证时应该遵循零信任理念，对运行时的上下文进行充分验证，通过实时细粒度的权限控制，确保只有正确人在使用正确的 AI Agent 才能获取到凭证。

建议使用 Agent Identity 的凭证提供商能力，在全托管各类访问凭证后，对 AI Agent在什么用户的什么情况下才能获取哪个凭证提供商的凭证进行细粒度的权限控制，最大程度降低凭证暴露、泄露的风险。

定期审查权限

在授权完成后，还需要定期对权限的授予进行审计确保每个身份的权限持续满足最小够用原则。需要重点关注的场景：

1. 特权身份：比如拥有所有产品权限的管理员，拥有 RAM 等管理与治理相关产品所有权限的身份，都属于重点审计对象。确保这些身份拥有这些特权是合理的。

2. 闲置权限：除了特权身份外，对于其他产品权限，也可以结合云上的操作审计日志，判断该身份的权限是否有闲置情况。

3. AI 场景特殊审查：定期审查模型权限分配是否合理，API-Key 使用情况等。

设置权限边界

对于云上有多个阿里云账号的组织，可以基于资源目录管控策略，限制成员账号内的 RAM 身份权限范围，禁用一些高危操作降低身份泄露风险。如禁止成员删除域名或修改域名解析记录、禁止成员删除日志记录等。

AI 场景下的权限边界设置：

• 限制成员账号对 AI 服务的全局配置修改权限。

• 限制成员账号删除业务空间、删除模型等危险操作。

• 限制 API-Key 的创建和使用范围。

在绑定管控策略前，建议先进行局部小范围测试，确保策略的有效性与预期一致，然后再绑定到全部目标节点（资源夹、成员）。

人员变动时的权限管理

当企业发生访问云资源的人员配置（新增用户，删除用户，变更用户权限）时，需要进行相应的权限调整：

• 新增用户：应在 IdP 中将其加入到已经配置了 SSO 访问的用户组，并根据其职能授予相应的访问配置。

• 删除用户：可以直接删除 IdP 中的用户，IdP 通常会自动移除其访问权限。对于 AI 场景，还需要注意检查该用户是否有创建的 API-Key，及时进行清理。

• 用户权限发生修改：应修改其用户组配置或在云SSO中调整其访问配置。

• 转岗场景：需要及时调整用户在不同业务空间的访问权限，确保权限与职责一致。

多账号场景下的权限管理

对于使用多账号架构的企业，建议：

• 在管理账号开通云SSO，统一管理所有成员账号的身份和权限。

• 通过访问配置模板，实现权限策略的复用，降低管理复杂度。

• 利用资源目录的管控策略，统一设置权限边界，确保安全合规。