Conditional Access 和 PIM 如何實際阻止攻擊？

密碼策略能阻止猜測攻擊。但對於被竊取的工作階段權杖、釣魚式 MFA 提示，或是已經坐著擁有全域管理員權限兩年的常駐管理帳戶，密碼策略無能為力。Conditional Access 和 Privileged Identity Management (PIM) 是 Azure AD / Entra ID 中實際解決這些漏洞的兩個控制項，它們搭配使用效果最佳。

Conditional Access 在底層的運作方式

Conditional Access 是一個在登入時評估的 if-this-then-that 引擎。"if" 部分（訊號）包括使用者/群組成員資格、裝置合規狀態、網路位置、登入風險（來自 Identity Protection）、存取的應用程式和用戶端應用程式類型（瀏覽器 vs. 舊版通訊協定）。"then" 部分（控制項）包括：要求 MFA、要求合規裝置、要求已核准的用戶端應用程式、完全封鎖存取，或要求接受使用條款。

在幾乎每個租用戶中都很重要的一個策略：封鎖舊版驗證。POP、IMAP 和較舊的 SMTP 等通訊協定不支援現代 MFA 質詢，所以它們是認證填充工具首先嘗試的對象。在封鎖前，檢查按 "Client App = Other clients" 篩選的登入日誌 — 你通常會發現某個舊版掃描器或老式多功能印表機仍在使用基本驗證進行驗證。

從第一天開始就值得設定的第二個：要求所有使用者進行 MFA，使用僅針對緊急玻璃帳戶的排除群組進行限制。不要只限 MFA 於「管理員」。遭入侵的標準使用者帳戶是攻擊者在權限提升甚至開始之前獲得初期立足點的方式。

登入風險 vs. 使用者風險 — 不同的訊號，不同的應對

Identity Protection（Entra ID P2 的一部分）生成兩個獨立的風險分數，很容易混淆它們：

• 登入風險 — 這個特定驗證嘗試看起來異常（不可能旅行、匿名 IP、不熟悉的登入屬性）。
• 使用者風險 — 這個帳戶因與身份本身相關的原因而被標記（洩露的認證在違規資料庫中被發現、已確認的入侵活動）。

回應登入風險的 Conditional Access 策略通常應該以 MFA 進行質詢 — 如果真正的使用者可以完成質詢，就允許他們通過。回應使用者風險的策略應該強制重設密碼，因為如果認證本身已經洩露，MFA 單獨無法幫助。

為什麼常駐管理員存取是更大的問題

即使 Conditional Access 嚴密，永久擁有全域管理員的帳戶也是目錄中顯而易見的目標。任何破壞它的人都會繼承完整的租用戶控制權，而不需要額外的步驟。PIM 移除了「永久」的部分。

使用 PIM，管理員角色被指派為合格而不是主動。使用者必須明確啟用角色，這會觸發必需的理由、可選的核准工作流程、MFA 重新確認，以及一個時間限制的時間視窗 — 通常 1 到 8 小時 — 在此之後角色會自動停用。除非他們正在主動使用它，否則沒有人（包括帳戶擁有者）擁有常駐全域管理員。

實際可用的最小 PIM 配置

• 每個高於技術服務台管理員的角色：合格，非永久。
• 全域管理員和特殊權限角色管理員：需要來自第二個管理員的核准，而不僅是自我啟用。
• 啟用 MFA 必需，無例外。
• 最多 4 小時的啟用期限會強制人員針對真正不同的工作工作階段重新啟用，這也會產生更清潔的審計軌跡。
• 對所有合格指派進行每 90 天的存取審查 — 帳戶被新增用於一個專案，之後永遠不會被移除。

團隊在這方面出錯的地方

最常見的失敗不是策略設計，而是排除清單。一個 Conditional Access 策略，其中不斷增長的「排除這些使用者，因為應用程式不支援 MFA」群組最終排除了租用戶的一半。將排除項追蹤為待辦項目，具有擁有者和移除日期，而不是永久的桶。

第二個失敗是實際上未經測試的緊急玻璃帳戶。兩個緊急帳戶，排除在 Conditional Access 和 PIM 之外，有長隨機密碼離線儲存，並對任何登入進行警報 — 有人應該每季嘗試登入它們，以確認它們仍然有效。

Conditional Access 和 PIM 不是合規稽核的複選框。它們是釣魚認證成為不便之事與完整租用戶入侵之間的差異。如果你正在將身份控制對應為藍隊部署的一部分，Korra Studio 的雲端和藍隊部分涵蓋了檢測方面 — Identity Protection 風險事件在 Sentinel 中實際的樣子，以及如何對不可能的 PIM 啟用模式進行警報。