編輯

共用方式為


條件式存取架構和角色

Microsoft Entra ID

本文說明遵循 零信任 原則的條件式存取架構。 架構會使用以角色為基礎的方法來形成結構化的條件式存取架構。

條件式存取 零信任架構

首先您需選擇一個架構。 我們建議您考慮目標或 零信任 條件式存取架構。 本圖顯示對應的設定:

Diagram that shows the settings for Targeted and Zero Trust architectures.

零信任條件式存取架構是最適合零信任原理的架構。 如果您在條件式存取原則中選取 [ 所有雲端應用程式 ] 選項,所有端點都會受到所提供授與控件的保護,例如已知使用者和已知或相容的裝置。 但原則不只是套用至支援條件式存取的端點和應用程式而已, 還會套用至使用者進行互動的任何端點。

例如,用於各種新 PowerShell 和 Microsoft Graph 工具的裝置登入流程端點。 裝置登入流程提供一種方式,允許從無法顯示登入畫面的裝置登入,例如IoT裝置。

裝置型登入命令會在指定的裝置上執行,並向用戶顯示程序代碼。 此程式代碼用於另一個裝置上。 使用者前往 https://aka.ms/devicelogin 並指定其使用者名稱和密碼。 從其他裝置登入之後,登入會在該用戶內容中的IoT裝置上成功。

這種登入的挑戰是它不支援裝置型條件式存取。 這表示如果您針對所有雲端應用程式套用需要已知使用者和已知裝置的基準原則,則沒有人可以使用工具和命令。 還有其他應用程式與裝置型條件式存取有相同的問題。

另一個架構是 目標 架構,是以您只以您想要在條件式存取原則中保護的個別應用程式為目標的原則所建置。 在此情況下,所有雲端應用程式先前涵蓋的端點的裝置登入,例如對 Microsoft Entra ID 的圖形呼叫,不會受到條件式存取原則的保護,因此它們會繼續運作。

使用 device-login 作為區分這兩個架構的範例時,您可以使用 device-login 進行驗證。 裝置登入可能會允許一或幾個個別應用程式使用,因為每個應用程式都是可設定目標的,因此可以在需要裝置型登入的條件式存取原則中排除。

目標架構的挑戰是您可能忘記保護所有雲端應用程式。 即便如此,您也可以選擇條件式存取原則中的所有可選取應用程式。 您可以保留無法選取未受保護的應用程式的存取權。 範例包括存取 Office 入口網站、Azure EA (Enterprise 合約) 入口網站,以及安全性資訊入口網站,全都是非常敏感的入口網站。

另一個考慮是,隨著 Microsoft 和合作夥伴發行新功能,以及 IT 系統管理員整合各種應用程式與 Microsoft Entra ID,Office 365 和 Microsoft Entra 應用程式的數目會隨著時間而增加。 只有在您有一個機制可偵測任何支援條件式存取的新應用程式,且會自動套用原則時,才能保護所有這類應用程式的存取。 建立和維護這類腳本可能很困難。

此外,任何一個條件式存取原則所支援的應用程式數目上限約為 250。 您可能會在收到超過承載的錯誤之前新增多達 600 個應用程式,但不支援該數目。

條件式存取角色

建構條件式存取原則的方式有很多。 其中一種做法是根據所存取資源的敏感度來建構原則。 在實務上,若要同時確保不同使用者仍可存取資源,這種做法可能難以實作。

例如,您可以定義條件式存取原則,要求已知使用者和已知裝置存取需要來賓和員工存取的敏感性資源。 當來賓嘗試從受控裝置存取時,存取要求將無法運作。 您必須調整條件式存取原則以符合這兩個需求,這通常會導致符合較不安全需求的原則。

另一種方法是嘗試根據使用者所在的組織位置定義存取原則。 這種做法可能會產生很多條件式存取原則,而且可能無法管理。

較好的做法是建構與一般存取需求相關的原則,並將一組存取需求結合在一群具有相同需求的使用者。 角色是具有共同業務屬性、職責、經驗、目標和存取權的身分識別類型。

了解各種角色如何存取企業資產和資源,是開發全方位零信任策略不可或缺的一環。

以下顯示一些來自 Microsoft 的建議條件式存取角色:

Image that shows recommended Conditional Access personas.

Microsoft 也建議為不屬於任何其他角色群組的身分識別獨立定義一個角色。 這稱為 Global 角色。 Global 的用意是針對不屬於角色群組的身分識別強制執行原則,以及用於應針對所有角色強制執行的原則。

下列各節說明一些建議的角色。

全球

全域是一般性質的原則角色/佔位符。 用來定義套用至所有角色或不適用於某個特定角色的原則。 可用於其他角色未涵蓋的原則。 您需要此角色來保護所有相關案例。

例如,假設您想要使用一個原則來封鎖所有使用者的舊版驗證。 您可以將它設為全域原則,而不是針對各種角色使用可能不同的舊版原則群組。

另一個範例:您想要封鎖特定帳戶或使用者的特定應用程式,而且該使用者或帳戶不屬於任何角色。 例如,如果您在 Microsoft Entra 租使用者中建立雲端身分識別,此身分識別不是任何其他角色的一部分,因為它未獲指派任何 Microsoft Entra 角色。 您仍可能想要封鎖身分識別,以存取 Office 365 服務。

您可能想要封鎖任何角色群組未涵蓋之身分識別的所有存取。 或者,您可能只想強制執行多重要素驗證。

管理員

在此內容中,系統管理員是任何非來賓身分識別、雲端或同步處理,其具有任何 Microsoft Entra ID 或其他 Microsoft 365 系統管理員角色(例如,在 適用於雲端的 Microsoft Defender Apps、Exchange、適用於端點的 Defender 或合規性管理員中)。 由於具有這些角色的來賓會涵蓋在不同的角色中,因此來賓會從此角色中排除。

有些公司針對此角色所依據的敏感性系統管理員角色有個別帳戶。 以最佳方式,系統管理員會從特殊許可權存取工作站使用這些敏感性帳戶(PAW)。 但是,我們通常會看到系統管理帳戶用於標準工作站,其中使用者只會在一部裝置上的帳戶之間切換。

您可能會想要根據雲端管理員角色的敏感度來區分,並將較不敏感的 Azure 角色指派給內部人員,而不是使用不同的帳戶。 然後,您可以改用 Just-In-Time (JIT) 提高許可權。 在此情況下,用戶的目標為兩組條件式存取原則,每個角色各一個。 如果您使用PAW,您可能也想要介紹在條件式存取中使用裝置篩選器來限制存取的原則,讓系統管理員只能在PAW上允許。

開發人員

開發人員角色包含具有唯一需求的使用者。 它們是以同步處理至 Microsoft Entra ID 的 Active Directory 帳戶為基礎,但需要特殊存取 Azure DevOps、CI/CD 管線、裝置程式代碼流程和 GitHub 等服務。 開發人員角色可以包含被視為內部使用者,而其他人視為外部使用者,但人員應只屬於其中一個角色。

內部項目

內部包含已同步處理 Active Directory 帳戶至 Microsoft Entra ID、公司員工,以及以標準使用者角色工作的所有使用者。 建議您將屬於開發人員的內部使用者新增至開發人員角色。

外部

此角色會保存所有已同步至 Microsoft Entra 識別碼之 Active Directory 帳戶的外部顧問。 建議您將屬於開發人員的外部使用者新增至開發人員角色。

來賓

來賓會保留已邀請給客戶租使用者之 Microsoft Entra 來賓帳戶的所有使用者。

來賓 管理員

來賓 管理員 角色會保留所有擁有 Microsoft Entra 來賓帳戶的使用者,該帳戶已獲指派任何先前提及的系統管理員角色。

Microsoft365ServiceAccounts

此角色包含雲端 (Microsoft Entra ID) 用戶型服務帳戶,當沒有任何其他解決方案符合需求時,用來存取 Microsoft 365 服務,例如使用受控服務識別。

AzureServiceAccounts

此角色包含雲端 (Microsoft Entra ID) 使用者型服務帳戶,當沒有任何其他解決方案符合需求時,用來存取 Azure (IaaS/PaaS) 服務,例如使用受控服務識別。

CorpServiceAccounts

此角色包含具有下列所有特性的使用者型服務帳戶:

  • 源自內部部署 Active Directory。
  • 會從內部部署或另一個 (雲端) 資料中心的 IaaS 型虛擬機使用,例如 Azure。
  • 會同步處理至可存取任何 Azure 或 Microsoft 365 服務的 Microsoft Entra 實例。

應避免這種情況。

WorkloadIdentities

此角色包含計算機身分識別,例如 Microsoft Entra 服務主體和受控識別。 條件式存取現在支援保護對這些帳戶資源的存取,但對於哪些條件和授與控件有一些限制。

存取範本卡片

我們建議您使用存取範本卡片來定義每個角色的特性。 以下是範例:

Example of an access template card.

每個角色的範本卡片都提供輸入,用於建立每個角色的具體條件式存取原則。

條件式存取指引

檢閱條件式存取架構,其中包含根據所建立人員分組原則的結構化方法。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者:

若要查看非公用LinkedIn配置檔,請登入LinkedIn。

下一步