條件訪問基礎策略：最先要建的 6 條

簡短回答： 小型租戶先建六條條件訪問策略：管理員 MFA、全體用戶 MFA、封鎖舊式驗證、保護安全性資訊註冊、Azure 管理 MFA、訪客 MFA。六條都要排除緊急訪問帳戶，除註冊策略外，都先用僅報告（Report-only）模式建立，看完結果再逐條改為 On；註冊策略無法在僅報告模式下測試，要改用試行組驗證。下文按 CA001 至 CA006 編號，上線次序不同，寫在「先用僅報告模式測試」一節末尾。需要 Microsoft Entra ID P1，微軟表示 Microsoft 365 Business Premium 的客戶同樣可以使用。

本文寫給小型或中型 Microsoft 365 租戶的管理員：已經有授權，但還沒建立條件訪問基線。每條策略都會列出適用對象、條件、授予控制項和排除帳戶，然後是用僅報告模式安全上線的步驟。步驟已於 2026 年 10 月 28 日對照 Microsoft Learn 核對。

動手之前

建立兩個緊急訪問帳戶。 微軟建議：僅雲端帳戶、使用 onmicrosoft.com 域名、永久指派 Global Administrator 角色，登入方式用通行密鑰（passkey，FIDO2）。把兩個帳戶放進名為 EmergencyAccess 的群組。
決定安全預設值怎麼處理。 安全預設值與條件訪問互相取代。依靠這些策略之前，先停用安全預設值（Entra ID > Overview > Properties > Manage security defaults > Disabled）。
檢查有沒有微軟管理的策略。 在 Entra ID > Conditional Access > Policies 中，Created by 欄寫著 Microsoft 的項目，是微軟以僅報告狀態建立的。如果你不處理，微軟會在推出後不少於 30 天啟用它們。沒有理由就不要再建一份相同規則的副本。微軟管理的策略（例如「Multifactor authentication for all users」和「Block legacy authentication」）可能已涵蓋 CA003 和 CA001，請直接編輯它們的狀態和排除項，不要重複建立。
訂一個命名準則， 例如 CA001 至 CA006，加一句簡短描述。
確認角色。 建立策略至少需要 Conditional Access Administrator。授權：Microsoft Entra ID P1 或 Microsoft 365 Business Premium；以風險為基礎的策略需要 Entra ID P2。

以下所有操作都在 Microsoft Entra 管理中心（entra.microsoft.com）的 Entra ID > Conditional Access > Policies > New policy 下進行。你也可以從 Entra ID > Conditional Access > Create new policy from templates 開始。微軟的模板預設以僅報告模式建立，而且針對用戶的模板只會排除建立者本人，所以建立之後要打開策略，加入你的緊急訪問群組。

六條策略

每條策略都按同樣次序：用戶、目標資源、條件、授予控制項、排除。

CA001：封鎖舊式驗證

用戶： All users。
目標資源： All resources (formerly 'All cloud apps')。
條件： Client apps > Configure = Yes，只勾選 Exchange ActiveSync clients 和 Other clients。
授予： Block access。
排除： EmergencyAccess 群組。必須繼續使用舊式協定的帳戶，作為臨時例外加入，並註明截止日期。
啟用前： 先找出誰在用。前往 Entra ID > Monitoring & health > Sign-in logs，加上 Client App 欄，按舊式協定篩選。互動式登入和 User sign-ins (non-interactive) 兩個分頁都要看。

CA002：管理員要求 MFA

用戶： Include > Directory roles。微軟的清單是 Global Administrator、Application Administrator、Authentication Administrator、Billing Administrator、Cloud Application Administrator、Conditional Access Administrator、Exchange Administrator、Helpdesk Administrator、Password Administrator、Privileged Authentication Administrator、Privileged Role Administrator、Security Administrator、SharePoint Administrator 和 User Administrator。
目標資源： All resources。
條件： 無。
授予： Grant access > Require multifactor authentication。微軟建議管理員準備好之後，考慮透過驗證強度（authentication strength）要求防網絡釣魚的 MFA。
排除： EmergencyAccess 群組。
注意： 這條策略只涵蓋內建角色，不對系統管理單位範圍的角色和自訂角色強制執行。

CA003：全體用戶要求 MFA

用戶： All users。
目標資源： All resources (formerly 'All cloud apps')，不排除任何應用程式。微軟建議以此作為基線。
條件： 無。如果要加受信任網絡例外（Network > Include Any network or location > Exclude All trusted networks and locations），請記錄在案，因為它會削弱策略。
授予： Grant access > Require authentication strength > Multifactor authentication。
排除： EmergencyAccess 群組；如果使用 Entra Connect 或 Cloud Sync，還要排除目錄角色 Directory Synchronization Accounts；只有在用 CA006 單獨涵蓋訪客時，才排除訪客。

CA004：保護安全性資訊註冊

用戶： All users。排除 All guest and external users（Temporary Access Pass 對訪客不適用）和 EmergencyAccess 群組。
目標資源： User actions > Register security information。
條件： Locations > Configure = Yes，包含 Any location，排除 All trusted locations。
授予： Grant access > Require authentication strength，選擇內建或自訂的強度。
排除： 同上。
注意： 需要啟用合併註冊（combined registration）。為新入職員工發出 Temporary Access Pass，讓他們能符合註冊時的 MFA 要求。微軟頁面說明，自 2026 年 7 月 6 日起，針對 Register security information 的策略，在用戶註冊 Windows Hello for Business 或 macOS Platform SSO 憑據時也會生效。

CA005：Azure 管理要求 MFA

用戶： All users。
目標資源： Select resources > Windows Azure Service Management API。涵蓋 Azure 門戶、Microsoft Entra 管理中心、Azure PowerShell 和 Azure CLI。
條件： 無。
授予： Grant access > Require multifactor authentication。
排除： EmergencyAccess 群組。
注意： 微軟自己也對 Azure 登入強制 MFA，並說明這包括緊急帳戶。仍然建議保留這條策略，讓你自己的規則可見、可測試。

CA006：訪客和外部用戶要求 MFA

用戶： Include > Select users and groups > Guest or external users，並選擇你使用的訪客類型。
目標資源： All resources，或訪客需要的應用程式。
條件： 無。
授予： Grant access > Require authentication strength > Multifactor authentication。先檢查跨租戶訪問設定中的輸入 MFA 信任。
排除： EmergencyAccess 群組。
注意： 微軟說明，驗證強度目前只適用於透過 Microsoft Entra ID 驗證的訪客。對於電郵一次性密碼、SAML/WS-Fed、Google 同盟和個人 Microsoft 帳戶的訪客，請使用 Require multifactor authentication 授予控制項。

先用僅報告模式測試

建立每條策略時，把 Enable policy 設為 Report-only，再選取 Create。
至少收集一個完整工作週的登入，讓月底或每週的工作也出現。CA001 等得越久越好。「一週」只是作者的建議，不是微軟給出的數字。
打開策略，查看 Policy impact（需要 Security Reader 或更高角色），它顯示 24 小時、7 天或 1 個月內對互動式登入的影響。
打開 Entra ID > Monitoring & health > Sign-in logs，選一筆登入，在 Report-only 分頁查看每條策略的結果：Success、Failure 或 User action required。
如果有 Entra ID P1，並有接收登入記錄的 Log Analytics 工作區，可以用 Conditional Access Insights and Reporting 工作簿一次比較大量登入。
補上缺口：加排除、把掃描器改用現代驗證、讓落後的人註冊 MFA 方法。
把 Enable policy 從 Report-only 改為 On，一次一條，每條之間隔一兩天。如果策略改為 On 後登入出現問題，用緊急訪問帳戶登入，把該策略改回 Report-only 或 Off。

微軟的僅報告頁面說明，User actions 範圍內的項目無法在僅報告模式下評估。CA004 就屬於這一類，所以要先指派給試行組、再逐步擴大，而不是倚賴僅報告結果。

大多數小型租戶適用的上線次序：CA002（管理員）、CA005、CA001（完成舊式驗證排查後）、CA003、CA006，最後是 CA004。

常見錯誤

沒有緊急訪問帳戶，或者沒有排除。 一條有問題的策略可能把所有人鎖在門外，包括你自己。每季測試這些帳戶。
排除過多。 對「IT 團隊」或「董事」的排除會變成漏洞。排除只留給緊急帳戶和確實無法避免的服務帳戶。
用模板卻不改排除。 模板只排除建立策略的那個人。
沒看僅報告的結果就啟用。 登入記錄會顯示本來會被封鎖的是誰。
忘了服務帳戶和同步帳戶。 Entra Connect 或 Cloud Sync 帳戶需要排除 Directory Synchronization Accounts。把用於腳本的用戶帳戶換成受控識別或工作負載身份識別。
遺留傳統策略。 傳統條件訪問策略已於 2024 年 7 月 10 日停止執行。請重建為現代策略（Entra ID > Conditional Access > Classic policies），再停用舊的。

如何確認生效

在登入記錄中打開一筆最近登入的 Conditional Access 分頁，確認每條策略的結果是 Success 或 Not applied，與預期一致。
在 Conditional Access 中用 What If 工具，選測試用戶、應用程式和客戶端類型，查看會套用哪些策略。
用測試用戶在私密視窗登入，確認出現 MFA 提示。
用測試郵箱嘗試舊式協定連線，確認被封鎖。
用緊急訪問帳戶登入，確認仍然可用，並記錄日期。
查看 Conditional Access 的 Overview 和 Coverage 分頁，了解哪些應用程式還沒有策略涵蓋。

租戶裡已經有一批條件訪問策略，怎樣審計它們？

上面六條策略是給「還什麼都沒有」的租戶準備的。我們接觸到的大多數租戶並不是這種情況：兩三年前有人建過一批策略，後來為某個項目又加了幾條，之後再沒有人完整讀過這個列表。審計一個已有的策略集合，和從零搭建是兩件事。你要問的不是「應該有哪些策略」，而是「現有的策略是否仍然在做負責人以為它在做的事」。在 Microsoft Entra 管理中心的 Entra ID > Conditional Access > Policies 裡逐條打開，另開一個標籤頁放登入日誌（Entra ID > Monitoring & health > Sign-in logs，按 Conditional Access 篩選），按下面的清單逐條核對。記下策略名、狀態和發現，這些記錄就是報告的底稿。

審計現有條件訪問策略時要檢查的十件事

仍停在僅報告模式的策略。 看 State 一欄。一條在僅報告模式下放了幾個月的策略什麼都沒有強制，而建它的人往往已經忘了。合格的樣子：每條策略要麼是 On 並有理由，要麼是 Off 並有理由；沒有任何一條在測試期過後還停在 Report-only。
越來越大的排除組。 打開每條策略的 Users > Exclude，再打開這些組本身。2024 年只有兩個成員的 EmergencyAccess 組，今天可能已經有九個人。合格的樣子：排除項只限兩個緊急訪問帳戶和有記錄的服務帳戶，每一項都有負責人和複查日期。
與辦公室實際地址不再一致的命名位置。 在 Entra ID > Conditional Access > Named locations 裡，把受信任的 IP 段和各辦公室現在實際使用的地址逐一對比。前一家網絡供應商留下的網段，或者已經關閉的辦公室的網段，對今天拿到那個地址的任何人來說都是受信任位置。合格的樣子：每個網段都對應一個現有辦公室或 VPN 出口，列表上有最後核對日期。
沒有封鎖舊式驗證。 確認存在一條相當於 CA001 的策略且為 On，然後在登入日誌裡按 Client app 篩選 Exchange ActiveSync 和 Other clients，看是否還有東西能通過。合格的樣子：封鎖策略為 On，最近 30 天的舊式協議登入為零或都能解釋。
沒有登入頻率或持久瀏覽器會話控制。 檢查面向用戶的策略裡的 Session 控制。沒有這些控制，共用或非受管機器上的令牌可以長時間有效。合格的樣子：對非受管設備設定了登入頻率，在設備不符合規範或非混合加入時停用持久瀏覽器會話。
面向 All users 卻沒有排除緊急訪問帳戶的策略。 任何作用於 All users 而沒有排除 EmergencyAccess 組的策略，都是等著一次錯誤改動就把所有人鎖在外面。合格的樣子：每條 All users 策略恰好排除這個組，並且緊急帳戶按計劃定期測試。
引用已淘汰設備型號的設備篩選規則。 打開 Conditions > Filter for devices 讀一遍規則。圍繞公司已不再使用的設備型號、操作系統版本或命名前綴寫的篩選條件，會悄悄地什麼都匹配不上，通常意味著它本該施加的控制已經不再生效。合格的樣子：篩選條件用仍在維護的屬性表達，例如符合規範狀態或信任類型。
重複的微軟管理策略。 Created by 一欄寫著 Microsoft 的項目，可能和 CA001 或 CA003 重複。兩條規則相同、排除項不同的策略，結果沒有人能預測。合格的樣子：一條規則只有一條策略，微軟管理的那份要麼被採納並編輯，要麼被有意關閉。
把服務帳戶排除在外的管理員 MFA 策略。 打開相當於 CA002 的策略讀排除項。持有管理員角色卻沒有 MFA 的服務帳戶，是從一個洩露的密碼走到整個租戶被接管最常見的路徑。合格的樣子：沒有任何持有特權角色的人員或服務帳戶被排除；自動化改用受管識別或工作負載識別運行。
沒有覆蓋訪客的策略。 檢查是否有任何策略以 Guest or external users 為目標。兩個項目之前的合作方訪客，今天仍在 Teams 和 SharePoint 裡佔著位置。合格的樣子：相當於 CA006 的策略為 On，跨租戶訪問設定有人複查，過期訪客按計劃清理。

每一條發現，只有在別人日後也能核對時才有用。把策略集合導出為 JSON（每條策略的 Download JSON 操作，或者 Graph API），保存一份帶日期的登入日誌樣本，顯示某個有代表性的用戶的條件訪問結果，並記錄是誰在什麼時候複查了排除組。這三樣東西連同複查日期一起保存，就是在保險公司、審計方或客戶問「訪問是如何控制的」時可以用作證據的材料；單獨一張策略列表截圖不是。

這份清單是我們一次性 Microsoft 365 保安審計身份部分的主要內容：審計會逐條檢查租戶裡每條策略、每個排除組和每個命名位置，並對照 CIS Microsoft 365 Benchmark 記錄結果。配套文章MFA 缺口報告講的是身份這一側的另一半：哪些用戶真正註冊了 MFA，用的是什麼方法。

FAQ

什麼是條件訪問（Conditional Access）？

它是 Microsoft Entra 的一項功能，按「如果……就……」的方式作出訪問決定：如果用戶要訪問 Microsoft 365 之類的資源，就必須符合某項要求，例如 MFA。微軟在第一重驗證完成之後才執行策略。

什麼是 Microsoft Entra？

Microsoft Entra 是微軟身份識別與訪問類產品的品牌。Microsoft Entra ID（前稱 Azure Active Directory）是儲存你 Microsoft 365 用戶的目錄。條件訪問在 Microsoft Entra 管理中心的 Entra ID > Conditional Access 下設定。