本指南面向已熟悉 Microsoft Entra（原 Azure Active Directory）中使用者管理、角色指派、條件訪問等功能的專業人員，從產品對標、核心概念對標、應用情境實現等維度，系統梳理 Microsoft Entra與阿里雲存取控制（Resource Access Management，RAM）之間的映射關係與關鍵差異，協助您在跨雲或多雲情境中快速定位對應功能模組，減少因設計和術語概念差異導致的理解偏差。
為什麼需要這份指南
阿里雲 RAM 與 Microsoft Entra 在術語和架構上存在顯著差異。如果你已熟悉 Azure 的身份與訪問管理體系（Microsoft Entra），現在需要在阿里雲上完成類似工作，直接套用 Azure 經驗容易產生誤解。例如：
Azure 的"角色"是許可權集合，而阿里雲的"角色"是一種身份實體。兩者含義完全不同。
Azure 將身份管理與資源存取控制分開，阿里雲 RAM 則統一管控。
阿里雲沒有"服務主體"概念，程式身份通過 AccessKey 或角色扮演實現。
本指南通過系統化的概念對標與情境映射，協助你建立從 Azure/Microsoft Entra 到阿里雲存取控制的完整認知映射。
主題導航
本指南包含以下主題：
產品對標
在展開細節之前，先建立全域視角。下表列出了 Microsoft Entra 體系中的核心服務與阿里雲的對應關係：
Azure服務 | 阿里雲服務 | 說明 |
雲平台的核心身份管理與存取控制服務，提供多因素認證、單點登入、應用整合及令牌頒發等功能。具體請參見身份認證與應用整合。 | ||
阿里雲 RAM 通過權限原則統一管控帳號下所有資源，具體請參見許可權概念映射。 | ||
管理身份實體、應用程式接入及權限原則分配的 API，具體請參見開發與SDK。 | ||
提供跨帳號/租戶的訪問能力，具體請參見跨帳號/租戶訪問。 |
設計理念差異
Azure和阿里雲均提供身份管理與存取控制能力，但兩者在架構設計上採用了不同的方式：
Microsoft Entra ID是Azure中專用於身份和訪問管理的服務。Entra ID租戶是專門的身份邊界，用於集中組織使用者、應用程式和存取原則等實體物件，與 Azure 資源訂閱相互獨立。這種設計便於在複雜的企業環境中實現身份的統一治理。
阿里雲將存取控制作為阿里雲帳號的內建能力。阿里雲帳號同時承擔身份和資源的管理邊界，RAM 使用者、角色和權限原則均在帳號範圍內定義和生效。這種設計使身份與資源的關聯更為直接，便於快速建立存取控制體系。
核心概念對標
本部分從資源架構、身份實體、許可權模型三個維度，系統梳理兩個平台核心概念之間的術語映射與關鍵差異。
資源管理架構
兩個平台都用“層級樹”來組織資源，但層級的名稱和含義有差異。
Azure 概念 | 阿里雲概念 | 層級 | 說明 |
租戶（Tenant） | 管理帳號 | 頂層容器 | 企業級頂層管理容器。管理帳號是整個資來源目錄的擁有者，對資來源目錄、資源夾和成員擁有完全控制許可權。Root 資源夾是目錄結構的頂層節點。 |
管理組（Management Group） | 資源夾 | 組織單元 | 用於組織和管理多個訂閱/帳號的層級結構，都支援嵌套子管理組/資源夾。 |
訂閱（Subscription） | 帳號 | 隔離邊界 | 成員帳號在邏輯上等同於 Azure 訂閱，是資源的隔離邊界。 |
資源群組（Resource Group） | 資源群組 | 分組單元 | 資源的容器。阿里雲的資源群組不用於資源生命週期管理。 |
資源（Resource） | 資源 | 資源 | 具體的雲資源，如虛擬機器、儲存、資料庫等。 |
Azure資源層級架構圖
Azure 採用“租戶 → 管理組 → 訂閱 → 資源群組 → 資源”的五層架構。租戶（Tenant）作為身份邊界，管理組用於多訂閱的統一合規性控制及邏輯組織分類，訂閱是計費和資源隔離的基本單位。
阿里雲資源層級架構圖
阿里雲採用“管理帳號 → 資源夾 → 成員帳號 → 資源群組 → 資源”的層級架構。管理帳號是資來源目錄的擁有者，資源夾用於組織成員帳號，成員帳號是資源隔離邊界。
關鍵差異
身份邊界與資源邊界：Microsoft Entra ID租戶是獨立的身份邊界，用於隔離使用者、應用程式和存取原則等身份相關資料，無法在租戶下直接建立 Azure 資源。阿里雲管理帳號本質是一個阿里雲帳號，具備直接建立資源的能力（但在企業情境下不建議在管理帳號下建立業務資源）。
資來源目錄的可選性：Azure 訂閱必須關聯到租戶，且必須屬於管理組層級結構。阿里雲的資來源目錄是可選功能，只有開啟後才具備管理帳號、資源夾等層級結構。未開啟資來源目錄時，阿里雲帳號可作為獨立的頂層容器使用。
身份概念映射
下表列出了兩個平台身份實體概念的對應關係：
Microsoft Entra術語 | 阿里雲 RAM 術語 | 實體類型 | 說明 |
人員身份 | RAM 使用者是帳號內的身份實體，不支援跨帳號存在（不同於 Entra ID 的來賓使用者）。 | ||
程式身份 | RAM 使用者可建立 AccessKey 用於程式身份認證。AccessKey 的使用方式類似於服務主體的用戶端密鑰。 | ||
程式身份 | 工作負載無需管理長期憑證即可訪問雲資源。阿里雲的對應功能基於 RAM 角色實現。 | ||
分組 | RAM使用者組僅用於大量授權。 | ||
授予全域管理員 | 授予 | 管理員 | RAM超級管理員擁有該帳號下所有資源（包括身份）的完全控制許可權。Entra ID全域管理員只能管理身份，不能管理訂閱， |
關鍵差異
人員身份設計差異：Entra ID 嚴格區分人員與程式身份，其使用者是專為自然人（如內部員工、外部夥伴等）設計的獨立實體類型。而阿里雲的RAM 使用者則是通用的身份載體，其本身不具備絕對的人員或程式屬性，而是通過配置憑證來決定應用情境：配置控制台登入密碼即作為人員身份使用，建立 AccessKey 即作為程式身份使用。
程式身份設計差異：Entra ID 的服務主體是專門為應用程式身分識別驗證設計的實體類型，應用註冊、公司專屬應用程式程式、託管標識等功能均依賴服務主體實現。而阿里雲沒有專門針對程式的獨立身份類型，RAM 使用者和RAM角色均可被程式或服務使用：程式既可以使用 RAM 使用者的 AccessKey 作為長期訪問憑證，也可以通過臨時扮演RAM角色，擷取更安全的短期存取權限。
許可權概念映射
下表列出了兩個平台許可權管理概念的對應關係：
Azure/Microsoft Entra術語 | 阿里雲 RAM 術語 | 說明 |
定義可執行操作的許可權集合。 | ||
將權限原則關聯到身份實體。 | ||
由雲端服務商預定義的許可權集合。 | ||
使用者根據需求自行定義的許可權集合。 | ||
基於條件的存取控制，如來源 IP 限制、MFA 要求等。 |
關鍵差異
角色與權限原則的語義差異
Azure/Microsoft Entra中的角色代表許可權集合，是許可權的載體而非身份。阿里雲 RAM 中的角色是一種身份類型，需要被其他身份扮演並被授予權限原則後才能執行操作。Entra ID 中角色的概念對應於阿里雲 RAM 中的權限原則。
權限原則作用範圍差異
微軟體系對許可權進行了拆分：Entra RBAC 角色專門用於控制對Entra租戶內資源（如使用者、使用者組、服務主體等）的訪問；而針對雲資源（如虛擬機器、儲存等）的控制則由 Azure RBAC 負責。相比之下，阿里雲採用統一管理員模式，RAM 權限原則的作用範圍覆蓋整個雲帳號下的所有服務與資源，
此外，在授權粒度上，RAM 權限原則提供了極高的靈活性，支援從宏觀的服務等級、具體的操作層級，一直細化到最底層的資源層級（最精細）。說明各阿里雲服務對許可權管控粒度的支援情況有所差異。關於各雲端服務具體支援的授權粒度，請參見支援RAM的雲端服務。
情境指引
基於前述架構與概念差異，本部分針對身份認證、跨帳號訪問、日誌審計、開發整合等常見情境，給出 Microsoft Entra 與阿里雲之間的具體方案映射。
身份認證與應用整合
兩個平台都提供多因素認證、企業單點登入及應用整合等能力，但在具體設計與實現上存在差異。
Microsoft Entra | 阿里雲 | 應用情境 | 說明 |
系統管理使用者/組 | 系統管理使用者、使用者組，如建立、刪除、修改屬性等。 | ||
多因素認證 | RAM支援虛擬 MFA（對應Entra的軟體OATH令牌）、通行密鑰、安全手機（對應Entra的SMS）、安全郵箱等多種方式。 | ||
身份聯合 | 阿里雲支援使用者 SSO 和角色 SSO 兩種模式與企業 IdP 整合。雲 SSO 適用於資來源目錄多帳號情境。 | ||
企業單點登入 | OAuth應用管理面向與阿里雲服務整合的情境提供授權整合。阿里雲IDaaS作為身份供應商（IdP），以獨立的身份提供公司專屬應用程式整合。 | ||
- | 帳號同步 | 企業本地部署身份同步至雲端。 | |
憑證令牌服務 | 阿里雲STS服務用於在角色扮演情境下頒發臨時安全憑證，OAuth 服務用於為 OIDC/OAuth 應用發放存取權杖。 |
關鍵差異
身份聯合差異
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中稱為跨租戶）的訪問情境，但採用不同的實現機制。
Microsoft Entra | 阿里雲 | 應用情境 | 說明 |
企業使用者跨帳號訪問 | 阿里雲主要通過扮演目標帳號下的 RAM 角色實現。 | ||
公司專屬應用程式程式跨帳號訪問 | Entra ID 支援將應用註冊為多租戶應用，阿里雲通過 STS AssumeRole 擷取臨時憑證。 | ||
面向消費使用者的應用訪問 | RAM 不提供此功能，需使用阿里雲 IDaaS CIAM。 |
關鍵差異
在 Entra ID 中，跨租戶訪問主要依賴 B2B 協作機制，目標租戶需要將外部使用者作為來賓邀請並寫入本租戶目錄中，隨後再為其分配應用或資源訪問角色。
在阿里雲中，跨帳號訪問以角色扮演為核心，無需在目標帳號內建立任何實體身份。程式或使用者可通過調用 STS 服務（如 AssumeRole、AssumeRoleWithSAML或AssumeRoleWithOIDC 介面）擷取臨時安全憑證，動態切換為目標帳號下的 RAM 角色身份來訪問資源。
除RAM角色扮演這種通用方案外，阿里雲還提供基於資源的跨帳號授權機制（如配置 OSS Bucket Policy 或使用資源共用）作為特定產品下的補充方案。
日誌與審計
兩個平台都提供完整的Action Trail和日誌記錄能力。
Microsoft Entra | 阿里雲 | 說明 |
均用於追蹤控制台與 API 的操作。Action Trail為阿里雲下的獨立服務，而非RAM的內建功能。 | ||
Action Trail（登入事件） | 阿里雲的控制台登入事件記錄在Action Trail日誌中，不單獨提供登入Log Service。 | |
均用於配置日誌的長期儲存和分析。 |
關鍵差異
日誌分類維度： Entra ID 將登入日誌與稽核線索獨立拆分，以便在安全溯源時快速區分認證行為與管理動作。相比之下，阿里雲採用集中納管模式，將控制台登入等身份認證事件統一匯聚至Action Trail服務中。
審計範圍映射： Entra ID 的稽核線索僅聚焦於身份側，專門記錄租戶內目錄對象（如使用者、群組、應用程式等）的操作；而針對雲資源的操作，則交由Azure 活動紀錄記錄。因此，在概念映射上，Entra ID 稽核線索加上 Azure 活動紀錄的組合，對應阿里雲的Action Trail（後者同時涵蓋了 RAM 身份操作與全域雲資源操作）。
開發與SDK
兩個平台都提供開發與 SDK 支援。
Microsoft Entra | 阿里雲RAM | 應用情境 | 說明 |
OAuth/OIDC應用整合 | 均可用於構建 OAuth/OIDC 應用並與雲認證平台整合。 | ||
API調用 | 均提供對身份實體（如使用者、使用者組）、應用程式接入及權限原則分配的全生命週期管理能力。 | ||
身份認證 SDK | 阿里雲SDK下的 Credentials 模組提供憑證管理功能，兩者均支援憑據鏈。 | ||
- | 認證庫 | MSAL 等認證庫可協助開發人員將應用整合到 Microsoft Identity Platform。阿里雲無直接對應的認證庫，需使用第三方 OAuth/OIDC 庫。 |
阿里雲 OpenAPI 目前僅部分介面支援使用存取權杖（Bearer Token）調用，具體請參見憑據。Azure REST API 和 Microsoft Graph 的所有介面均使用 Entra Token Service 頒發的存取權杖進行調用。
關鍵差異
API 架構設計差異：Microsoft Entra採用全域統一入口設計，所有針對身份、應用與權限原則的調用均通過 Microsoft Graph API 這一單一網關完成。而阿里雲RAM採用按功能模組劃分的設計，使用以下三個獨立的API端點以應對不同情境：
IMS（身份管理服務）： 主要負責身份實體（如使用者、使用者組）的生命週期管理、單點登入配置與以及OAuth應用的管理。
RAM（存取控制服務）： 主要用於權限原則管理與授權配置。
STS（Security Token Service）： 主要用於角色扮演及臨時安全憑證的頒發。