Microsoft 365 應急訪問帳戶：設定與審計指南

先說結論：Break-glass 帳戶（微軟稱“應急訪問帳戶”）是一個僅雲端的全域管理員帳戶，用於正常管理員無法登入的那一天。依據微軟 2026 年 6 月 4 日更新的指引：至少保留兩個；用密碼密鑰（FIDO2）或憑證登入，不依賴手機；從阻止或限制登入的條件訪問策略中排除；每次使用都告警；至少每 90 天測試一次。

每個 Microsoft 365 租戶遲早會遇到管理員全部登入不了的下午：條件訪問策略寫錯了，手機網絡中斷收不到 MFA 提示，或者唯一的全域管理員已經離職。沒有應急帳戶，只能聯絡微軟支持並等待；有帳戶卻沒人找得到，或者在清理時被禁用，結果一樣。

本文回答幾個實際問題：需要幾個帳戶；在管理門戶已強制 MFA 的 2026 年怎樣設定；應該排除哪些策略；怎樣告警；以及怎樣用半小時審計整個安排。內容依據 Microsoft Learn 頁面 Manage emergency access admin accounts，我們於 2026 年 11 月 10 日閲讀。

什麼是 Microsoft 365 的 break-glass 帳戶？

它是 Microsoft Entra ID 中擁有全域管理員角色的用戶帳戶，只在正常管理帳戶無法使用時才用。它不是為方便準備的備用管理員，也不是 IT 團隊日常共用的登入。它的作用是讓一次故障（錯誤的策略、身分提供方宕機、管理員離職）不至於把整個組織鎖在自己的租戶之外。

微軟列出的場景包括：聯合身分不可用；管理員的 MFA 設備或 MFA 服務不可用；最後一位全域管理員離開；災害造成手機網絡中斷；所有特權角色都是“符合資格”而非“活動”，且沒有人能批准啟用。

需要幾個應急訪問帳戶？

兩個或以上。微軟寫明“建立兩個或更多”，並在安全護欄中列出“至少保留兩個以實現冗餘”。對大多數中小租戶，兩個剛好：一個出問題（鑰匙丟失、被誤禁用）時另一個還在。超過三個只會增加要保管的憑據，不會增加韌性。

全域管理員總數是另一個問題。小型租戶有兩三位管理員加上應急帳戶就夠。如果審查時發現十個以上長期全域管理員，那本身就是一項發現。

2026 年怎樣設定？

微軟現行步驟與舊做法不同，主要因為管理門戶已強制 MFA。概括如下：

建立僅雲端用戶，使用 *.onmicrosoft.com 域名，不要聯合身分，也不要從本地 Active Directory 同步。
分配全域管理員角色；在 Privileged Identity Management 中設為永久使用中，而不是符合資格。
選擇防釣魚的登入方式。微軟推薦密碼密鑰（FIDO2）；已有 PKI 的組織可用憑證身分驗證。兩者都滿足強制 MFA 的要求。
與日常管理員使用不同的方式。日常用 Authenticator 應用程式，應急帳戶就用硬件安全密鑰。
不要綁定到個人或個人手機。憑據應放在多位授權管理員都能取得的地方，例如不同地點的保險箱。
確保憑據不會過期，也不會被“長期未使用帳戶”自動清理掃到。

為什麼不直接用一個很長的密碼？

舊建議是用超長密碼並把帳戶排除在 MFA 之外。這個建議已經過時。微軟頁面現在的說法是，由帳戶上登記的防釣魚方式來保護它，所列方式也正是滿足強制 MFA 的那些。只有密碼又排除 MFA 的帳戶，正是審計人員和攻擊者最先找的東西。

應急帳戶要從條件訪問中排除嗎？

要，但只針對阻止或限制登入的策略。原因是：強制要求 MFA、合規設備或指定位置的策略，可能讓帳戶在它本應應對的緊急情況下無法使用。兩點實踐建議：

建一個專用安全組，例如 EmergencyAccess，排除這個組，而不是逐個用戶。以後新建策略只需記得添加這一個排除項。
按同一頁面的說法，僅報告（report-only）策略不會阻止訪問，不需要排除。

多數租戶在這裡會向兩個方向出錯：要麼帳戶受“所有用戶要求 MFA”策略約束，真正鎖死時無法登入；要麼排除了一切卻沒人盯著。只有帳戶憑據夠強並且受到監控，排除才是安全的。如果你還在決定策略怎樣設計，可先看我們對安全預設值與條件訪問的比較。

怎樣監控應急帳戶？

應急帳戶每一次登入都應通知不止一位管理員。微軟的示例是把 Entra 登入日誌送到 Azure Monitor，針對這些帳戶的對象 ID 建立基於查詢的告警，閾值大於 0、嚴重性 0（嚴重），並通過郵件或短信操作組通知。Microsoft Sentinel 等工具同樣可行。重點在原則而不是產品：沒人計劃的登入，必須在幾分鐘內送到真人面前。

有兩處容易漏掉。登入日誌必須先送到工作區，告警才能觸發；審計日誌也要開啓，並且保留足夠長的時間供事後查看。我們的 Microsoft 365 審計日誌保留檢查說明了各種授權保留多久。

任何一次使用之後，微軟建議做簡短復盤：是計劃內演練、真實緊急情況還是濫用？所做操作是否符合授權用途？

怎樣審計應急帳戶？

這是我們使用的清單，你自己在 Entra 管理中心一小時內就能走完。

數量。至少兩個嗎？你能說出名字嗎？列出全域管理員，找 breakglass、emergency、ea- 之類名稱。
類型。是僅雲端的 onmicrosoft.com 帳戶嗎？來自本地同步或聯合域都算發現項。
角色。全域管理員是永久使用中嗎？“符合資格”意味著要先啟用，而啟用本身可能被卡住。
登入方式。登記了密碼密鑰或憑證嗎？與日常管理員方式不同嗎？密碼加登記在某個人名下的手機號碼，不符合微軟自己的要求。
條件訪問。對每個啓用且會阻止或限制登入的策略，應急組被排除了嗎？用 What If 工具測試；僅報告策略不需要排除。
告警。這些帳戶的登入有實時告警嗎？誰收到？在計劃演練時讓人登入一次，看告警是否到達。
上次測試。上一次授權人員登入並執行管理操作是什麼時候？微軟說至少每 90 天一次，IT 人員或訂閲變動後也要做。
保管。憑據放在哪裡，誰能取得？有權限的人離開後換過保險箱密碼嗎？
衞生。帳戶沒有分配郵箱授權，不用於日常工作，也不在正常登入報告裡出現。

不合格的結果長什麼樣？

常見發現包括：只有一個應急帳戶；帳戶仍是從本地同步的用戶；帳戶排除了 MFA 卻只有密碼；帳戶在清理時被禁用後沒有恢復；告警發到沒人看的郵箱。這些都不罕見，而且光看配置就能發現。

這和完整的 Microsoft 365 保安審計是什麼關係？

應急訪問只是更廣泛審查中 Entra ID 與特權訪問部分的一項控制。我們的 Microsoft 365 CIS Benchmark 審計通過只讀 Microsoft Graph 應用程式讀取租戶配置，檢查包括：誰擁有全域管理員、他們的登入如何受保護、存在哪些條件訪問排除。報告設計為可作為常見網絡保險問卷和 Cyber Essentials 中管理員訪問相關問題的證據，不讀取郵件或文檔內容。發現項的呈現方式可看樣本報告解讀，完整檢查範圍見 Microsoft 365 保安審計服務頁（英文頁）。

關於誰應該持有管理員角色，可延伸閲讀我們的 Microsoft 365 與 Entra ID 保安審計說明。