條件式存取架構和原則
本文提供實作角色型條件式存取架構的架構，例如 條件式存取零信任架構中所述的架構。 在本文中，有有關如何形成及命名條件式存取原則的詳細數據。 制定政策也有其起始點。
如果您未使用此處提供的架構，包括命名標準，原則通常會隨著時間而由不同人員以臨機操作方式建立。 這可能會導致原則重疊。 如果建立政策的人員已不在，其他人可能很難知道該政策的目的。
遵循結構化架構可讓您更輕鬆地了解原則。 它也可讓您更輕鬆地涵蓋所有案例，並避免難以疑難解答的衝突原則。
命名慣例
正確定義的命名慣例可協助您和同事了解原則的用途，這可讓您更輕鬆地進行原則管理和疑難解答。 您的命名慣例應該符合您用來建構原則的架構。
建議的命名原則是以角色、原則類型和應用程式為基礎。 看起來像這樣：
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
此名稱的元件如下所述：
| 命名元件 | 描述/範例 |
|---|---|
| CA 編號 | 用來快速識別原則類型範圍和順序。 範例：CA001-CA099。 |
| 人物設定 | 全域、管理員、內部用戶、外部用戶、訪客用戶、訪客管理員、Microsoft365帳戶、Azure帳戶、企業帳戶。 |
| 原則類型 | 基本保護 (Base Protection)、應用程式保護 (App Protection)、資料保護 (Data Protection)、身份保護 (Identity Protection)、攻擊面減少 (Attack Surface Reduction)、合規性 (Compliance)。 |
| 應用程式 | AllApps、O365（適用於所有 Office 365 服務）、EXO（適用於 Exchange Online）。 |
| 平臺 | AnyPlatform、Unknown、WindowsPhone、macOS、iOS、Android。 |
| 授予控制權 | Block、ADHJ、符合規範、Unmanaged（其中 Unmanaged 是在裝置狀態條件中指定）。 |
| 描述 | 政策目的的非必要描述。 |
編號方案
為了讓系統管理變得簡單，我們建議此編號配置：
| 角色群組 | 號碼分配 |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | 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 | 針對每個使用者角色，皆有此政策類型涵蓋的基本保護。 針對受管理裝置上的使用者，這通常指的是已知使用者和已知裝置。 針對外部來賓，可能為已識別的用戶和多因素驗證。 基底保護是指定角色中使用者所有應用程式的默認原則。 如果特定應用程式應該有不同的原則，請從基底保護原則中排除該應用程式，並新增以該應用程式為目標的明確原則。 範例：假設對內部的基本保護要求所有雲端應用程式由已知使用者和已知裝置使用，但您想允許在任何裝置上使用 Outlook 網頁版。 您可以從基底保護原則中排除 Exchange Online，併為 Exchange Online 新增個別的原則，而您需要已知的裝置或多重要素驗證。 |
| 身份保護 | 在每個角色的基礎保護之上，您可以擁有與身分識別相關的條件式存取原則。 範例：封鎖舊版驗證、對於高風險的使用者或登入需要額外的多重要素驗證、需要使用已知裝置進行多重要素驗證註冊。 |
| 資料保護 | 此原則類型表示差異原則，這些原則在基礎保護之上提供額外的一層數據保護。 例子：
|
| AppProtection | 此政策類型是基底保護的額外新增。 例子：
|
| 攻擊面縮減 | 這種類型的原則的目的是減輕各種攻擊。 例子：
|
| 合規 | 您可以使用合規性政策來要求用戶檢視存取客戶服務的來賓使用規定。 |
應用程式
下表描述策略名稱的應用程式元件：
| 應用程式名稱 | 描述/範例 |
|---|---|
| AllApps | AllApps 表示所有雲端應用程式都是以條件式存取原則為目標。 涵蓋所有端點，包括支援條件式存取和不支援的端點。 在某些情況下，以所有應用程式為目標並無法正常運作。 我們建議以基底原則中的所有應用程式為目標，讓該原則涵蓋所有端點。 Microsoft Entra ID 中顯示的新應用程式也會自動遵守原則。 |
| <AppName> |
<AppName> 是政策涵蓋的應用程式名稱的佔位符號。 避免讓名稱太長。 範例名稱：
|
平台類型
下表描述策略名稱中的平台組件：
| 平台類型 | 描述 |
|---|---|
| AnyPlatform | 政策針對任何平台。 您通常會選取 [[任何裝置]來設定此設定。 在條件式存取原則中，會使用 平台 和 裝置 一字。 |
| iOS | 此原則是以AppleiOS平臺為目標。 |
| Android 系統 | 此原則以Google Android平臺為目標。 |
| 窗戶 | 此原則的目標是 Windows 平臺。 |
| Linux | 此原則會以Linux平臺為目標。 |
| WindowsPhone | 此原則是以 Windows Phone 平台為目標。 |
| macOS | 此原則以macOS平台為目標 |
| iOSAndroid | 原則以 iOS 和 Android 平台為目標。 |
| 未知 | 此原則會以先前未列出的任何平台為目標。 通常，您可以藉由包含 任何裝置 並排除所有個別的平台來進行設定。 |
授與控件類型
下表描述政策名稱中的授與控制元件：
| 授與類型 | 描述/範例 |
|---|---|
| 區塊 | 政策會封鎖登入 |
| MFA | 政策要求多重因素驗證。 |
| 合規的 | 此原則需要由端點管理員決定的相容裝置，因此裝置必須由端點管理員管理。 |
| 符合規範的AADHJ | 此原則需要相容的裝置或Microsoft Entra 混合式已加入裝置。 已加入網域的標準公司計算機也會加入混合式Microsoft Entra ID。 已共同管理或加入 Microsoft Entra 的行動電話和 Windows 10 電腦可以符合規範。 |
| 符合規範的AADHJ | 此原則需要符合且已加入 Microsoft Entra 混合式聯結的裝置。 |
| MFA或符合點 | 如果不符合規範，原則會要求符合規範的裝置或多重要素驗證。 |
| MFAandCompliant | 此原則需要相容的裝置及多重要素驗證。 |
| MFAorAADHJ | 政策要求使用 Microsoft Entra 混合式加入的電腦，或者，如果不是 Microsoft Entra 混合式加入的電腦，則需要多重要素驗證。 |
| MFAandAADHJ | 此原則需要Microsoft Entra 混合式聯結計算機 AND 多重要素驗證。 |
| 需要批准的客戶 | 原則需要核准的用戶端應用程式。 |
| AppProtection | 政策要求應用程式保護 |
| 未受管理 | 此原則會以不被 Microsoft Entra ID 所知道的裝置為目標。 例如，您可以使用此授與類型，允許從任何裝置存取 Exchange Online。 |
具名位置
建議您定義這些標準位置，以用於條件式存取原則：
- 受信任的IP/內部網路。 這些IP子網代表具有實體存取限制或其他控制的位置和網路，例如計算機系統管理、網路層級驗證或入侵偵測。 這些位置更安全，因此條件式存取強制執行可以放寬。 請考慮 Azure 或其他資料中心位置 （IP） 是否應包含在此位置，或有自己的具名位置。
- Citrix 信任的 IP 位址。 如果您有 Citrix 內部部署，如果您需要能夠從 Citrix 會話連線到雲端服務，設定 Citrix 伺服器陣列的個別傳出 IPv4 位址可能會很有用。 在此情況下，如果需要，您可以將這些位置從條件式存取原則中排除。
- Zscaler 的位置（如果適用）。 計算機已安裝 ZPA 代理程式，並將所有網路流量轉送到互聯網，然後經由或直接轉送至 Zscaler 雲端。 因此，請務必在條件式存取中定義 Zscaler 來源 IP，並要求來自非行動裝置的所有要求通過 Zscaler。
- 允許商務的國家/地區。 將國家/地區分成兩個位置群組很有用：一個代表員工通常工作所在的世界區域，另一個代表其他位置。 這可讓您將其他控制件套用至來自組織正常運作區域外部的要求。
- 多重身份驗證可能困難或無法使用的地點。 在某些情況下，要求多重要素驗證可能會讓員工難以執行其工作。 例如，員工可能沒有時間或機會回應頻繁的多重要素驗證挑戰。 或者，在某些位置，RF 檢測或電干擾可能會使行動裝置的使用變得困難。 一般而言，您會在這些位置使用其他控制件，或可能信任這些控制件。
位置型訪問控制依賴要求的來源IP來判斷要求時使用者的位置。 在公共互聯網上進行偽裝並不容易，但網絡邊界提供的保護可能被認為已不像以前那樣相關。 我們不建議只依賴位置作為存取條件。 但在某些情況下，這可能是您可以使用的最佳控制措施，例如，如果您要保護來自內部部署的服務帳戶存取，而該帳戶用於非互動式的情境。
建議的條件式存取原則
我們已建立包含建議條件式存取原則的電子表格。 您可以在這裏 下載電子表格，。
使用建議的原則作為起點。
您的原則可能會隨著時間而變更，以因應對企業而言很重要的使用案例。 以下是一些可能需要變更的案例範例：
- 使用任何非受控裝置，根據多重要素驗證、應用程式保護和核准的用戶端應用程式，為員工實作 Exchange Online 的唯讀存取權。
- 藉由實施 Azure 資訊保護來確保敏感性資訊不會在沒有這項強化的保護下被下載。
- 提供保護以防止來賓複製和貼上。
多個預覽目前正在進入公開預覽，因此預期建議的條件式存取（CA）入門原則將很快更新。
條件式存取指引
既然您有一組入門的條件式存取原則，您必須以受控制且分階段的方式部署它們。 我們建議您使用部署模型。
以下是一種方法：
其概念是先將原則部署到一個角色群組內的少數使用者。 您可以針對此部署使用名為 Persona Ring 0 的相關聯Microsoft Entra 群組。 確認一切正常運作之後，您會將任務指派變更為成員較多的群組 Persona Ring 1，依此類推。
然後，您會使用相同的環型方法來啟用原則，直到所有原則都已部署。
您通常會手動管理 Ring 0 和 ring 1 的成員。 包含數百或甚至數千位使用者的環形 2 或 3 群組可以透過動態群組來管理，而動態群組是根據指定角色中的使用者百分比。
使用環作為部署模型的一部分不僅僅是用於初始部署。 當需要新的原則或現有原則的變更時，您也可以使用它。
完成部署后，您也應該設計和實作 條件式存取原則中所討論的監視控件，。
除了自動化初始部署之外，您可能還想要使用 CI/CD 管線將原則的變更自動化。 您可以使用 Microsoft365DSC 進行此自動化。
貢獻者們
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者
- 克勞斯·傑斯珀森 |主體顧問標識碼&秒
若要查看非公開的 LinkedIn 配置檔，請登入 LinkedIn。