访问控制：面向Azure专业人员的阿里云访问控制指南

• Azure资源层级架构图

  

  Azure 采用“租户 → 管理组 → 订阅 → 资源组 → 资源”的五层架构。租户（Tenant）作为身份边界，管理组用于多订阅的统一合规性控制及逻辑组织分类，订阅是计费和资源隔离的基本单位。

• 阿里云资源层级架构图

  

  阿里云采用“管理账号 → 资源夹 → 成员账号 → 资源组 → 资源”的层级架构。管理账号是资源目录的拥有者，资源夹用于组织成员账号，成员账号是资源隔离边界。

关键差异

• 人员身份设计差异：Entra ID 严格区分人员与程序身份，其用户是专为自然人（如内部员工、外部合作伙伴等）设计的独立实体类型。而阿里云的RAM 用户则是通用的身份载体，其本身不具备绝对的人员或程序属性，而是通过配置凭证来决定应用场景：配置控制台登录密码即作为人员身份使用，创建 AccessKey 即作为程序身份使用。

• 程序身份设计差异：Entra ID 的服务主体是专门为应用程序身份验证设计的实体类型，应用注册、企业应用程序、托管标识等功能均依赖服务主体实现。而阿里云没有专门针对程序的独立身份类型，RAM 用户和RAM角色均可被程序或服务使用：程序既可以使用 RAM 用户的 AccessKey 作为长期访问凭证，也可以通过临时扮演RAM角色，获取更安全的短期访问权限。

关键差异

• 角色与权限策略的语义差异

  Azure/Microsoft Entra中的角色代表权限集合，是权限的载体而非身份。阿里云 RAM 中的角色是一种身份类型，需要被其他身份扮演并被授予权限策略后才能执行操作。Entra ID 中角色的概念对应于阿里云 RAM 中的权限策略。

• 权限策略作用范围差异

  微软体系对权限进行了拆分：Entra RBAC 角色专门用于控制对Entra租户内资源（如用户、用户组、服务主体等）的访问；而针对云资源（如虚拟机、存储等）的控制则由 Azure RBAC 负责。相比之下，阿里云采用统一管理模式，RAM 权限策略的作用范围覆盖整个云账号下的所有服务与资源，
  此外，在授权粒度上，RAM 权限策略提供了极高的灵活性，支持从宏观的服务级别、具体的操作级别，一直细化到最底层的资源级别（最精细）。

  说明

  各阿里云服务对权限管控粒度的支持情况有所差异。关于各云服务具体支持的授权粒度，请参见支持RAM的云服务。

关键差异

• 身份联合差异

  Entra ID 既可作为身份提供商与企业或 SaaS 应用集成，提供统一认证；也能作为服务提供商（SP）信任并对接 ADFS 或其他第三方 IdP。相比之下，阿里云 RAM 主要用于扮演服务提供商（SP）的角色，用于信任并集成企业已有的 IdP。

• 令牌服务差异

  Microsoft Entra与阿里云RAM在令牌下发架构上存在明显差异。Entra ID 采用统一的令牌分发服务，原生支持 OAuth 2.0 和 OIDC 协议，所有身份实体（用户、应用、服务主体等）均通过该单一入口获取 JWT 格式的访问令牌。而阿里云RAM则提供两个相对独立的令牌服务：

  • STS 服务：负责在角色扮演或角色 SSO 场景下，签发具备时效性的临时安全凭证（STS Token）。

  • OAuth 服务：用于为官方工具（如阿里云 CLI）及注册在RAM下的 OIDC/OAuth 应用颁发 JWT 格式的访问令牌。

关键差异

在 Entra ID 中，跨租户访问主要依赖 B2B 协作机制，目标租户需要将外部用户作为来宾邀请并写入本租户目录中，随后再为其分配应用或资源访问角色。

在阿里云中，跨账号访问以角色扮演为核心，无需在目标账号内创建任何实体身份。程序或用户可通过调用 STS 服务（如 AssumeRole、AssumeRoleWithSAML或AssumeRoleWithOIDC 接口）获取临时安全凭证，动态切换为目标账号下的 RAM 角色身份来访问资源。

关键差异

• 日志分类维度： Entra ID 将登录日志与审核日志独立拆分，以便在安全溯源时快速区分认证行为与管理动作。相比之下，阿里云采用集中纳管模式，将控制台登录等身份认证事件统一汇聚至操作审计服务中。

• 审计范围映射： Entra ID 的审核日志仅聚焦于身份侧，专门记录租户内目录对象（如用户、群组、应用程序等）的操作；而针对云资源的操作，则交由Azure 活动日志记录。因此，在概念映射上，Entra ID 审核日志加上 Azure 活动日志的组合，对应阿里云的操作审计（后者同时涵盖了 RAM 身份操作与全局云资源操作）。

两个平台都提供开发与 SDK 支持。