條件式存取架構和原則

  • 發行項

本文提供實作角色型條件式存取架構的架構，例如條件式存取 零信任 架構中所述的架構。 在本文中，有有關如何形成及命名條件式存取原則的詳細數據。 建立原則也有起點。

如果您未使用此處提供的架構，包括命名標準，原則通常會隨著時間而由不同人員以臨機操作方式建立。 這可能會導致原則重疊。 如果建立原則的人員已無法使用，其他人可能很難知道原則的目的。

遵循結構化架構可讓您更輕鬆地了解原則。 它也可讓您更輕鬆地涵蓋所有案例，並避免難以疑難解答的衝突原則。

命名規範

正確定義的命名慣例可協助您和同事了解原則的用途，這可讓您更輕鬆地進行原則管理和疑難解答。 您的命名慣例應符合用來建構原則的架構。

建議的命名原則是以角色、原則類型和應用程式為基礎。 畫面顯示為這樣：

<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>

此名稱的元件如下所述：

命名元件 描述/範例
CA 編號 用來快速識別原則類型範圍和順序。 範例：CA001-CA099。
角色 Global、管理員 s、Internals、Externals、GuestUsers、Guest 管理員 s、Microsoft365ServiceAccounts、AzureServiceAccounts、CorpServiceAccounts。
原則類型 BaseProtection、AppProtection、DataProtection、IdentityProtection、AttackSurfaceReduction、Compliance。
App AllApps、O365（適用於所有 Office 365 服務）、EXO（適用於 Exchange Online）。
平台 AnyPlatform、Unknown、Windows 電話、macOS、iOS、Android。
授與控件 Block、ADHJ、符合規範、Unmanaged（其中 Unmanaged 是在裝置狀態條件中指定）。
描述 原則用途的選擇性描述。

編號配置

為了讓系統管理變得簡單，我們建議此編號配置：

角色群組 數位配置
CA-Persona-Global CA001-CA099
CA-Persona-管理員 CA100-CA199
CA-Persona-Internals CA200-CA299
CA-Persona-Externals CA300-CA399
CA-Persona-GuestUsers CA400-CA499
CA-Persona-Guest 管理員 s CA500-CA599
CA-Persona-M365ServiceAccounts CA600-CA699
CA-Persona-AzureServiceAccounts CA700-CA799
CA-Persona-CorpServiceAccounts CA800-CA899
CA-Persona-WorkloadIdentities CA900-CA999
CA-Persona-Developers CA1000-CA1099

原則類型

以下是建議的原則類型：

原則類型 描述/範例
BaseProtection 針對每個角色，有此原則類型涵蓋的基準保護。 針對受管理裝置上的使用者，這通常是已知的使用者和已知裝置。 針對外部來賓，可能是已知的使用者和多重要素驗證。

基底保護是指定角色中使用者所有應用程式的默認原則。 如果特定應用程式應該有不同的原則，請從基底保護原則中排除該應用程式，並新增以該應用程式為目標的明確原則。

範例：假設 Internals 的基本保護是要求所有雲端應用程式的已知使用者和已知裝置，但您想要允許從任何裝置 Outlook 網頁版。 您可以從基底保護原則中排除 Exchange Online，併為 Exchange Online 新增個別的原則，而您需要已知的裝置或多重要素驗證。
IdentityProtection 在每個角色的基礎保護之上，您可以擁有與身分識別相關的條件式存取原則。

範例：封鎖舊版驗證、需要額外的多重要素驗證，以達到高使用者或登入風險，需要已知裝置進行多重要素驗證註冊。
DataProtection 此原則類型表示在基礎保護之上，以額外層的形式保護數據的差異原則。

例如：
  • 應用程式防護 iOS 和 Android 的原則，可用來加密手機上的數據，並提供該數據的改善保護。 （應用程式防護 原則還包括應用程式保護。
  • Azure 資訊保護 在下載期間協助保護數據的會話原則，如果數據是機密的。
AppProtection 此原則類型是基底保護的另一個新增專案。

範例：
  • 假設您想要允許從任何裝置存取 Exchange Online。 您可以將 Exchange 排除在基底原則中，並建立新的明確原則來存取 Exchange，例如，您只允許對 Exchange Online 的只讀存取。
  • 假設您需要進行 Microsoft 端點管理員註冊的多重要素驗證。 您可以從基底原則排除 Intune 端點管理員註冊，並新增需要端點管理員註冊多重要素驗證的應用程式保護原則。
AttackSurfaceReduction 這種類型的原則的目的是減輕各種攻擊。

範例：
  • 如果存取嘗試來自未知的平臺，則可能是嘗試略過您需要特定平台的條件式存取原則。 您可以封鎖來自未知平臺的要求，以降低此風險。
  • 封鎖存取 Azure 管理員 istrators 的 Office 365 服務，或封鎖對所有使用者的應用程式存取，如果已知應用程式不正確。
合規性 您可以使用合規性政策來要求用戶檢視存取客戶服務的來賓使用規定。

App

下表描述原則名稱的應用程式元件：

應用程式名稱 描述/範例
AllApps AllApps 表示所有雲端應用程式都是以條件式存取原則為目標。 涵蓋所有端點，包括支援條件式存取和不支援的端點。 在某些情況下，以所有應用程式為目標並無法正常運作。 我們建議以基底原則中的所有應用程式為目標，讓該原則涵蓋所有端點。 Microsoft Entra ID 中顯示的新應用程式也會自動遵守原則。
<AppName> <AppName> 是原則所位址之應用程式名稱的佔位元。 避免讓名稱太長。

範例名稱：
  • 適用於 Exchange Online 的 EXO
  • SPO for SharePoint Online

平台類型

下表描述原則名稱的平台元件：

平台類型 描述
AnyPlatform 原則會以任何平台為目標。 您通常會選取 [ 任何裝置] 來設定此設定。 （在條件式存取原則中，會同時使用平臺和裝置一詞。
iOS 此原則是以AppleiOS平臺為目標。
Android 此原則以Google Android平臺為目標。
Windows 此原則的目標是 Windows 平臺。
Linux 此原則會以Linux平臺為目標。
Windows 電話 此原則是以 Windows 電話 平台為目標。
macOS 此原則以macOS平台為目標
iOSAndroid 原則以 iOS 和 Android 平台為目標。
未知 此原則會以先前未列出的任何平台為目標。 您通常會藉由包含 任何裝置 並排除所有個別平台來設定此設定。

授與控件類型

下表描述原則名稱的授與控制元件：

授與類型 描述/範例
封鎖 原則會封鎖登入
MFA 原則需要多重要素驗證。
符合標準 此原則需要由端點管理員決定的相容裝置，因此裝置必須由端點管理員管理。
符合規範的AADHJ 此原則需要相容的裝置或 Microsoft Entra 混合式已加入裝置。 已加入網域的標準公司計算機也會加入混合式 Microsoft Entra ID。 已共同管理或加入 Microsoft Entra 的行動電話和 Windows 10 電腦可以相容。
符合規範的ANDAADHJ 原則需要符合規範且已加入 AND Microsoft Entra 混合式的裝置。
MFAorCompliant 如果不符合規範，原則會要求符合規範的裝置或多重要素驗證。
MFAandCompliant 此原則需要相容的裝置 AND 多重要素驗證。
MFAorAADHJ 如果不是已加入 Microsoft Entra 混合式計算機，則原則需要 Microsoft Entra 混合式聯結電腦或多重要素驗證。
MFAandAADHJ 此原則需要 Microsoft Entra 混合式聯結電腦 AND 多重要素驗證。
RequireApprovedClient 原則需要核准的用戶端應用程式。
AppProtection 原則需要應用程式保護
非受控 此原則會以 Microsoft Entra ID 未知的裝置為目標。 例如，您可以使用此授與類型，允許從任何裝置存取 Exchange Online。

具名位置

建議您定義這些標準位置，以用於條件式存取原則：

  • 受信任的IP/內部網路。 這些IP子網代表具有實體存取限制或其他控制的位置和網路，例如計算機系統管理、網路層級驗證或入侵偵測。 這些位置更安全，因此條件式存取強制執行可以放寬。 請考慮 Azure 或其他資料中心位置 （IP） 是否應包含在此位置，或有自己的具名位置。
  • Citrix 信任的IP。 如果您有 Citrix 內部部署，如果您需要能夠從 Citrix 會話連線到雲端服務，設定 Citrix 伺服器陣列的個別傳出 IPv4 位址可能會很有用。 在此情況下，如果需要，您可以將這些位置從條件式存取原則中排除。
  • Zscaler 位置，如果適用的話。 計算機已安裝 ZPA 代理程式，並將所有流量轉送至 Zscaler 雲端或透過 Zscaler 雲端。 因此，請務必在條件式存取中定義 Zscaler 來源 IP，並要求來自非行動裝置的所有要求通過 Zscaler。
  • 允許商務的國家/地區。 將國家/地區分成兩個位置群組很有用：一個代表員工通常工作所在的世界區域，另一個代表其他位置。 這可讓您將其他控制件套用至來自組織正常運作區域外部的要求。
  • 多重要素驗證可能很困難或不可能的位置。 在某些情況下，要求多重要素驗證可能會讓員工難以執行其工作。 例如，員工可能沒有時間或機會回應頻繁的多重要素驗證挑戰。 或者，在某些位置，RF 檢測或電干擾可能會使行動裝置的使用變得困難。 一般而言，您會在這些位置使用其他控制件，或可能信任這些控制件。

位置型訪問控制依賴要求的來源IP來判斷要求時使用者的位置。 在公用因特網上執行詐騙並不容易，但網路界限所提供的保護可能被認為比一次更不相關。 我們不建議只依賴位置作為存取條件。 但在某些案例中，這可能是您可以使用的最佳控件，例如，如果您要保護來自內部部署的服務帳戶存取權，而內部部署則用於非互動式案例。

我們已建立包含建議條件式存取原則的電子表格。 您可以 在這裡下載電子錶格。

使用建議的原則作為起點。

您的原則可能會隨著時間而變更，以因應對企業而言很重要的使用案例。 以下是一些可能需要變更的案例範例：

  • 使用任何非受控裝置，根據多重要素驗證、應用程式保護和核准的用戶端應用程式，為員工實作 Exchange Online 的唯讀存取權。
  • 實作信息保護，以確保不會下載敏感性資訊，而不需改善 Azure 資訊保護 所提供的保護。
  • 提供保護以防止來賓複製和貼上。

目前有多個預覽即將進入公開預覽狀態，因此預期即將推出一組建議的條件式存取 （CA） 入門原則更新。

條件式存取指引

既然您有一組入門的條件式存取原則，您必須以受控制且分階段的方式部署它們。 我們建議您使用部署模型。

以下是一種方法：

Diagram that shows a Conditional Access deployment model.

其概念是先將原則部署到一個角色群組內的少數使用者。 您可以針對此部署使用名為 Persona Ring 0 的相關聯 Microsoft Entra 群組。 確認一切正常運作之後，您會將指派變更為具有更多成員的群組 Persona Ring 1 等等。

接著，您會使用相同的通道型方法來啟用原則，直到部署所有原則為止。

您通常會手動管理 Ring 0 和 ring 1 的成員。 包含數百或甚至數千位使用者的環形 2 或 3 群組可以透過動態群組來管理，而動態群組是根據指定角色中的使用者百分比。

使用通道作為部署模型的一部分不只是用於初始部署。 當需要新的原則或現有原則的變更時，您也可以使用它。

完成部署之後，您也應該設計和實作條件式存取原則中所討論的監視控件。

除了自動化初始部署之外，您可能還想要使用 CI/CD 管線將原則的變更自動化。 您可以使用 Microsoft365DSC 進行此自動化。

參與者

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

主體作者：

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

下一步