身分識別決策指南

在任何環境中，無論是內部部署、混合式或僅限雲端，IT 都必須控制哪些系統管理員、使用者和群組可以存取資源。 身分識別和存取管理 （IAM） 服務可讓您管理雲端中的存取控制。

跳至： 判斷身分識別整合需求 | 雲端基準 | 目錄同步 | 處理雲端裝載的網域服務 | Active Directory 同盟服務深入瞭解 |

有數個選項可用於在雲端環境中管理身分識別。 這些選項會因成本和複雜度而異。 建構雲端式身分識別服務的關鍵因素，是與現有內部部署身分識別基礎結構整合所需的層級。

Microsoft Entra ID 提供 Azure 資源的存取控制和身分識別管理基底層級。 如果您的組織內部部署的 Active Directory基礎結構具有複雜的樹系結構或自訂群組織單位（OU），您的雲端式工作負載可能需要與 Microsoft Entra ID 進行目錄同步處理，才能在內部部署和雲端環境之間取得一組一致的身分識別、群組和角色。 此外，對於相依于舊版驗證機制的應用程式，可能需要在雲端中部署Active Directory 網域服務 （AD DS）。

雲端式身分識別管理是反復的程式。 您可以從雲端原生解決方案開始，其中包含一小組使用者和初始部署的對應角色。 隨著移轉的成熟，您可能需要使用目錄同步處理來整合身分識別解決方案，或將網域服務新增為雲端部署的一部分。 在移轉程式的每個反復專案中重新流覽您的身分識別策略。

判斷身分識別整合需求

問題	雲端基準	目錄同步作業	雲端裝載的網域服務	Active Directory Federation Services
您目前是否缺少內部部署目錄服務？	是	否	No	No
您的工作負載是否需要在雲端與內部部署環境之間使用一組常見的使用者和群組？	No	是	否	No
您的工作負載是否相依于舊版驗證機制，例如 Kerberos 或 NTLM？	No	否	是	Yes
您是否需要跨多個識別提供者的單一登入？	No	No	否	Yes

在規劃移轉至 Azure 時，您必須判斷如何最好地整合現有的身分識別管理和雲端身分識別服務。 以下是常見的整合案例。

雲端基準

Microsoft Entra ID 是原生身分識別和存取管理 （IAM） 系統，可授與使用者和群組對 Azure 平臺上管理功能的存取權。 如果您的組織缺少重要的內部部署身分識別解決方案，而且您打算將工作負載移轉至與雲端式驗證機制相容，您應該開始使用 Microsoft Entra ID 作為基底來開發身分識別基礎結構。

雲端基準假設： 使用純雲端原生身分識別基礎結構假設下列各項：

• 雲端式資源不會有內部部署目錄服務或 Active Directory 伺服器的相依性，也可以修改工作負載來移除這些相依性。
• 要移轉的應用程式或服務工作負載要麼支援與 Microsoft Entra ID 相容的驗證機制，也可以輕鬆地修改以支援它們。 Microsoft Entra ID 依賴網際網路就緒的驗證機制，例如 SAML、OAuth 和 OpenID 連線。 使用 Kerberos 或 NTLM 等通訊協定依賴舊版驗證方法的現有工作負載可能需要重構，才能使用雲端基準模式移轉至雲端。

提示

將身分識別服務完全移轉至 Microsoft Entra ID，不需要維護自己的身分識別基礎結構，大幅簡化 IT 管理。

但 Microsoft Entra ID 不是傳統內部部署的 Active Directory基礎結構的完整取代專案。 若未將其他工具或服務部署到雲端，就無法使用舊版驗證方法、電腦管理或群組原則等目錄功能。

如需將內部部署身分識別或網域服務與雲端部署整合的案例，請參閱以下討論的目錄同步處理和雲端裝載網域服務模式。

目錄同步作業

對於具有現有內部部署的 Active Directory基礎結構的組織來說，目錄同步處理通常是保留現有使用者和存取管理的最佳解決方案，同時提供管理雲端資源所需的 IAM 功能。 此程式會持續複寫 Microsoft Entra ID 與內部部署目錄服務之間的目錄資訊，以允許使用者的通用認證，以及整個組織的一致身分識別、角色和許可權系統。

注意

採用 Microsoft 365 的組織可能已經在其內部部署的 Active Directory基礎結構與 Microsoft Entra 識別碼之間實 作目錄同步 處理。

目錄同步處理假設： 使用同步處理的身分識別解決方案假設下列事項：

• 您必須在整個雲端和內部部署 IT 基礎結構之間維護一組常見的使用者帳戶和群組。
• 您的內部部署身分識別服務支援使用 Microsoft Entra ID 進行複寫。

提示

任何依賴內部部署的 Active Directory伺服器所提供的舊版驗證機制且 Microsoft Entra ID 不支援的雲端式工作負載，仍然需要連線到內部部署網域服務或雲端環境中的虛擬伺服器，以提供這些服務。 使用內部部署身分識別服務也引進了雲端與內部部署網路之間的連線相依性。

雲端裝載的網域服務

如果您有工作負載相依于使用 Kerberos 或 NTLM 等舊版通訊協定的宣告式驗證，而且這些工作負載無法重構以接受 SAML 或 OAuth 和 OpenID 連線等新式驗證通訊協定，您可能需要將部分網域服務移轉至雲端，作為雲端部署的一部分。

此模式牽涉到將執行 Active Directory 的虛擬機器部署到雲端式虛擬網路，為雲端中的資源提供Active Directory 網域服務 （AD DS）。 任何移轉至雲端網路的現有應用程式和服務都應該能夠使用這些雲端裝載的目錄伺服器進行次要修改。

現有的目錄和網域服務可能會繼續在內部部署環境中使用。 在此案例中，您也應該使用目錄同步處理，在雲端和內部部署環境中提供一組常見的使用者和角色。

雲端裝載的網域服務假設： 執行目錄移轉假設如下：

• 您的工作負載取決於使用 Kerberos 或 NTLM 等通訊協定的宣告型驗證。
• 您的工作負載虛擬機器必須已加入網域，才能管理或應用 Active Directory 群組原則。

提示

雖然與雲端裝載的網域服務結合的目錄移轉在移轉現有工作負載時提供極大的彈性，但裝載雲端虛擬網路內的虛擬機器以提供這些服務會增加 IT 管理工作的複雜性。 隨著雲端移轉體驗的成熟，請檢查裝載這些伺服器的長期維護需求。 請考慮重構現有的工作負載以符合雲端識別提供者的相容性，例如 Microsoft Entra ID，是否可以減少這些雲端裝載伺服器的需求。

Active Directory Federation Services

身分識別同盟會跨多個身分識別管理系統建立信任關係，以允許常見的驗證和授權功能。 然後，您可以跨組織內的多個網域或客戶或商務合作夥伴所管理的身分識別系統，支援單一登入功能。

Microsoft Entra ID 支援使用 Active Directory 同盟服務 （AD FS） 內部部署的 Active Directory網域同盟。 如需如何在 Azure 中實作這項功能的詳細資訊，請參閱 將 AD FS 擴充至 Azure 。

深入了解

如需 Azure 中身分識別服務的詳細資訊，請參閱：

• Microsoft Entra ID 。 Microsoft Entra ID 提供雲端式身分識別服務。 它可讓您管理 Azure 資源的存取權，並控制身分識別管理、裝置註冊、使用者布建、應用程式存取控制和資料保護。
• Microsoft Entra 連線 。 Microsoft Entra 連線工具可讓您將 Microsoft Entra 實例與現有的身分識別管理解決方案連線，以同步處理雲端中的現有目錄。
• Azure 角色型存取控制 （Azure RBAC） 。 Azure RBAC 有效率且安全地管理管理平面中資源的存取權。 作業和責任會組織成角色，並將使用者指派給這些角色。 Azure RBAC 可讓您控制誰可以存取資源，以及使用者可以在該資源上執行的動作。
• Microsoft Entra Privileged Identity Management （PIM） 。 PIM 會降低資源存取權限的曝光時間，並透過報告和警示提高您對其使用可見度。 它會將使用者限制為 Just-In-Time 許可權，並在有限的期間內指派其許可權，然後自動撤銷這些許可權。
• 整合內部部署的 Active Directory網域與 Microsoft Entra ID 。 此參考架構提供內部部署的 Active Directory網域與 Microsoft Entra ID 之間的目錄同步處理範例。
• 將Active Directory 網域服務 （AD DS） 擴充至 Azure 。 此參考架構提供將 AD DS 伺服器部署至雲端式資源的範例。
• 將Active Directory 同盟服務 （AD FS） 擴充至 Azure 。 此參考架構會將 Active Directory 同盟服務 （AD FS） 設定為與您的 Microsoft Entra 目錄執行同盟驗證和授權。

下一步

身分識別只是雲端採用程式期間需要架構決策的核心基礎結構元件之一。 若要瞭解針對其他類型的基礎結構進行設計決策時所使用的替代模式或模型，請參閱架構決策指南概觀。

架構決策指南概觀