使用 Microsoft Entra ID 建立彈性存取控制管理原則

注意

本文件包含的資訊代表 Microsoft Corporation 對於截至文件發行當日為止探討之問題的最新觀點。 由於 Microsoft 必須響應不斷變化的市場狀況,因此不應將它解譯為 Microsoft 的承諾,且 Microsoft 無法保證發佈日期之後呈現的任何資訊正確性。

依賴單一訪問控制的組織,例如多重要素驗證或單一網路位置,以保護其IT系統,如果單一訪問控制變得無法使用或設定錯誤,就很容易存取應用程式和資源失敗。 例如,自然災害可能會導致電信基礎結構或公司網路的大型區段無法使用。 這類中斷可能會防止終端使用者和系統管理員能夠登入。

本檔提供組織應採用的策略指引,以提供復原能力,以在下列案例中意外中斷期間降低鎖定的風險:

  • 組織可以藉由實作風險降低策略或應變計劃,提高其復原能力,以降低中斷前鎖定的風險。
  • 組織可以藉由備妥風險降低策略和應變計劃,繼續存取他們在中斷期間選擇的應用程式和資源。
  • 組織應該確保它們會在中斷之後保留資訊,以及在復原其實作的任何應變之前,保留資訊,例如記錄。
  • 尚未實作預防策略或替代計劃的組織,可以實 作緊急選項 來處理中斷。

重要指引

本檔中有四個主要要點:

  • 使用緊急存取帳戶避免系統管理員鎖定。
  • 使用條件式存取實作 MFA,而不是個別使用者 MFA。
  • 使用多個條件式訪問控制來減輕用戶鎖定。
  • 為每個使用者布建多個驗證方法或對等專案,以減輕用戶鎖定。

中斷之前

緩和實際中斷必須是組織處理可能發生的訪問控制問題的主要焦點。 緩和包括規劃實際事件加上實作策略,以確保訪問控制和作業在中斷期間不受影響。

為什麼您需要彈性訪問控制?

身分識別是使用者存取應用程式和資源的控制平面。 您的身分識別系統會控制哪些使用者,以及哪些條件,例如訪問控制或驗證需求,用戶可以存取應用程式。 由於未預期的情況,用戶無法使用一或多個驗證或訪問控制需求進行驗證時,組織可能會遇到下列一或兩個問題:

  • 管理員 istrator 鎖定:管理員 istrators 無法管理租用戶或服務。
  • 使用者鎖定: 用戶無法存取應用程式或資源。

管理員 istrator 鎖定應變

若要解除鎖定租用戶的系統管理員存取權,您應該建立緊急存取帳戶。 這些緊急存取帳戶,也稱為 斷層 帳戶,允許在無法使用一般特殊許可權帳戶存取程式時管理 Microsoft Entra 設定。 至少應遵循 緊急存取帳戶建議建立兩個緊急存取帳戶。

減輕用戶鎖定

若要降低使用者鎖定的風險,請使用條件式存取原則搭配多個控件,讓使用者選擇他們存取應用程式和資源的方式。 藉由為使用者提供選擇,例如,使用 MFA 登入,或 從受管理裝置 登入或 從公司網路登入,如果其中一個訪問控制無法使用,使用者有其他選項可以繼續運作。

Microsoft 建議

在組織的現有條件式存取原則中納入下列訪問控制:

  • 為依賴不同通道的每個使用者布建多個驗證方法,例如 Microsoft Authenticator 應用程式(以因特網為基礎)、OATH 令牌(在裝置上產生),以及 SMS (電話語音)。
  • 在 Windows 10 裝置上部署 Windows Hello 企業版,以直接從裝置登入滿足 MFA 需求。
  • 透過 Microsoft Entra 混合式加入Microsoft Intune 使用受信任的裝置。 信任的裝置可改善使用者體驗,因為受信任的裝置本身可以滿足原則的強式驗證需求,而不需要對使用者提出 MFA 挑戰。 註冊新裝置時,以及從不受信任的裝置存取應用程式或資源時,將需要 MFA。
  • 使用 Microsoft Entra ID Protection 風險型原則,可在使用者或登入有風險時防止存取,以取代固定的 MFA 原則。
  • 如果您要使用 Microsoft Entra 多重要素驗證 NPS 擴充功能來保護 VPN 存取,請考慮將您的 VPN 解決方案同盟為 SAML 應用程式 ,並依照下列建議判斷應用程式類別。

注意

風險型原則需要 Microsoft Entra ID P2 授權。

下列範例說明您必須建立的原則,以提供彈性訪問控制,讓使用者存取其應用程式和資源。 在此範例中,您需要具有想要授與存取權的目標使用者的安全組 AppUsers、具有核心系統管理員的群組、具有核心系統管理員的群組 管理員、具有緊急存取帳戶的名為 EmergencyAccess 的群組。 此範例原則集會授與 AppUsers選取的使用者,如果他們從受信任的裝置連線或提供強身份驗證,例如 MFA,則存取選取的應用程式。 它不包括緊急帳戶和核心系統管理員。

設定條件式存取風險降低原則:

  • 原則 1:封鎖對目標群組外部人員的存取
    • 使用者和群組:包含所有使用者。 排除 AppUsers、Core 管理員 s 和 EmergencyAccess
    • 雲端應用程式:包含所有應用程式
    • 條件: (無)
    • 授與控件:封鎖
  • 原則 2:授與需要 MFA 或受信任裝置之 AppUsers 的存取權。
    • 使用者和群組:包含AppUsers。 排除 Core 管理員 s 和 EmergencyAccess
    • 雲端應用程式:包含所有應用程式
    • 條件: (無)
    • 授與控制:授與存取權、需要多重要素驗證、要求裝置符合規範。 針對多個控件:需要其中一個選取的控件。

用戶鎖定的應變

或者,您的組織也可以建立應變原則。 若要建立應變原則,您必須定義商務持續性、營運成本、財務成本和安全性風險之間的取捨準則。 例如,您可以只對使用者子集、應用程式子集、用戶端子集,或從位置子集啟動應變原則。 應變原則可讓系統管理員和終端使用者存取應用程式和資源,在未實作任何風險降低方法時中斷。 Microsoft 建議在不使用時啟用 僅限報表模式 的應變原則,讓系統管理員能夠在需要開啟原則時監視原則的潛在影響。

瞭解您在中斷期間的風險有助於降低風險,而且是規劃程式的重要部分。 若要建立應變計劃,請先判斷貴組織的下列商務需求:

  1. 事先決定您的任務關鍵性應用程式:您必須授與哪些應用程式存取權,即使風險/安全性狀態較低? 建置這些應用程式的清單,並確定您的其他項目關係人(商務、安全性、法律、領導)都同意,如果所有訪問控制都消失,這些應用程式仍必須繼續執行。 您最終可能會有下列類別:
    • 類別 1 工作關鍵性應用程式 ,無法超過幾分鐘的時間無法使用,例如直接影響組織營收的應用程式。
    • 類別 2 重要的應用程式 ,商務必須在幾個小時記憶體取。
    • 類別 3 低優先順序應用程式 ,可承受幾天的中斷。
  2. 針對類別 1 和 2 中的應用程式,Microsoft 建議您預先規劃您想要允許的存取層級:
    • 您是否想要允許完整存取或限制會話,例如限制下載?
    • 您要允許存取應用程式的一部分,但不能存取整個應用程式嗎?
    • 您要允許資訊工作者存取並封鎖系統管理員存取,直到還原訪問控制為止?
  3. 針對這些應用程式,Microsoft 也建議您規劃您要刻意開啟的存取途徑,以及您將關閉哪些途徑:
    • 您要只允許瀏覽器存取並封鎖可儲存離線數據的豐富用戶端嗎?
    • 您是否只允許公司網路內的使用者存取,並封鎖外部使用者?
    • 您是否只想要在中斷期間允許來自特定國家或地區的存取?
    • 您想要將原則套用至應變原則,特別是任務關鍵性應用程式,如果替代訪問控制無法使用,要失敗或成功嗎?

Microsoft 建議

應變條件式存取原則是一種 備份原則 ,可省略 Microsoft Entra 多重要素驗證、第三方 MFA、風險型或裝置型控件。 為了在啟用應變原則時將非預期的中斷降到最低,原則應該在不使用時維持在僅限報表模式中。 管理員 istrators 可以使用條件式存取深入解析活頁簿來監視其應變原則的潛在影響。 當組織決定啟用應變計劃時,系統管理員可以啟用原則,並停用一般控制型原則。

重要

停用在用戶上強制執行安全性的原則,即使是暫時,也會在應變計劃就緒時減少您的安全性狀態。

  • 如果某個認證類型中斷或一個訪問控制機制會影響應用程式的存取,請設定一組後援原則。 以僅限報表狀態設定原則,以需要網域加入作為控件,做為需要第三方 MFA 提供者的作用中原則備份。
  • 遵循密碼指引白皮書中的做法,降低當不需要 MFA 時,惡意執行者猜測密碼的風險。
  • 部署 Microsoft Entra 自助式密碼重設 (SSPR)Microsoft Entra 密碼保護 ,以確保使用者不會使用您選擇禁止的一般密碼和條款。
  • 如果無法達到特定驗證層級,請使用限制應用程式記憶體取的原則,而不是直接回復為完整存取權。 例如:
    • 設定備份原則,以將受限制的會話宣告傳送至 Exchange 和 SharePoint。
    • 如果您的組織使用 適用於雲端的 Microsoft Defender Apps,請考慮回復到與 適用於雲端的 Defender Apps 互動的原則,然後允許唯讀存取,但不允許上傳。
  • 將您的原則命名為 ,以確保在中斷期間很容易找到這些原則。 在原則名稱包含下列元素:
    • 原則 的標籤號
    • 要顯示的文字,此原則僅適用於緊急情況。 例如: 啟用緊急狀態
    • 其適用的中斷。 例如: 在 MFA 中斷期間
    • 顯示 您必須啟用原則之訂單的序號
    • 其適用的應用程式
    • 將會套用的 控制件
    • 所需的條件

應變原則的這個命名標準如下:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

下列範例: 範例 A - 應變條件式存取原則,可還原存取任務關鍵性共同作業應用程式,是典型的公司應變。 在此案例中,組織通常需要 MFA 才能存取所有 Exchange Online 和 SharePoint Online,在此情況下中斷是客戶的 MFA 提供者中斷(Microsoft Entra 多重要素驗證、內部部署 MFA 提供者或第三方 MFA)。 此原則可藉由只允許特定目標使用者從受信任的 Windows 裝置存取這些應用程式,以減輕此中斷情形。 它也會排除緊急帳戶和核心系統管理員不受這些限制。 目標用戶接著會取得 Exchange Online 和 SharePoint Online 的存取權,而其他使用者仍無法存取應用程式,因為中斷。 此範例需要具名的網路位置 CorpNetwork 和具有目標使用者的安全組 EmergencyyAccess、具有核心系統管理員的群組 管理員、具有核心系統管理員的群組,以及具有緊急存取帳戶的 EmergencyAccess 群組。 應變需要四個原則來提供所需的存取權。

範例 A - 應變條件式存取原則,以還原對任務關鍵性共同作業應用程式的存取:

  • 原則 1:需要 Exchange 和 SharePoint 的已加入網域裝置
    • 名稱:EM001 - 啟用緊急狀態:MFA 中斷[1/4] - Exchange SharePoint - 需要 Microsoft Entra 混合式聯結
    • 使用者和群組:包含應變功能Access。 排除 Core 管理員 和 EmergencyAccess
    • 雲端應用程式:Exchange Online 和 SharePoint Online
    • 條件:任何
    • 授與控制:需要加入網域
    • 狀態:僅限報表
  • 原則 2:封鎖 Windows 以外的平臺
    • 名稱:EM002 - 啟用緊急狀態:MFA 中斷[2/4] - Exchange SharePoint - 封鎖 Windows 以外的存取
    • 使用者和群組:包含所有使用者。 排除 Core 管理員 s 和 EmergencyAccess
    • 雲端應用程式:Exchange Online 和 SharePoint Online
    • 條件:裝置平臺包含所有平臺,排除 Windows
    • 授與控件:封鎖
    • 狀態:僅限報表
  • 原則 3:封鎖 CorpNetwork 以外的網路
    • 名稱:EM003 - 啟用緊急狀態:MFA 中斷[3/4] - Exchange SharePoint - 封鎖公司網络以外的存取
    • 使用者和群組:包含所有使用者。 排除 Core 管理員 和 EmergencyAccess
    • 雲端應用程式:Exchange Online 和 SharePoint Online
    • 條件:位置包含任何位置,排除 CorpNetwork
    • 授與控件:封鎖
    • 狀態:僅限報表
  • 原則 4:明確封鎖 EAS
    • 名稱:EM004 - 啟用緊急狀態:MFA 中斷[4/4] - Exchange - 封鎖所有使用者的 EAS
    • 使用者和群組:包含所有使用者
    • 雲端應用程式:包含 Exchange Online
    • 條件:用戶端應用程式:Exchange Active Sync
    • 授與控件:封鎖
    • 狀態:僅限報表

開啟順序:

  1. 從現有的 MFA 原則中排除 EmergencyyAccess、Core 管理員 s 和 EmergencyAccess。 確認應變功能中的使用者Access 可以存取 SharePoint Online 和 Exchange Online。
  2. 啟用原則 1:確認未在排除群組中加入網域的裝置上的用戶能夠存取 Exchange Online 和 SharePoint Online。 確認 [排除] 群組中的使用者可以從任何裝置存取 SharePoint Online 和 Exchange。
  3. 啟用原則 2:確認不在排除群組中的用戶無法從其行動裝置取得 SharePoint Online 和 Exchange Online。 確認 [排除] 群組中的使用者可以從任何裝置存取 SharePoint 和 Exchange(Windows/iOS/Android)。
  4. 啟用原則 3:確認不在排除群組中的用戶無法從公司網路存取 SharePoint 和 Exchange,即使已加入網域的電腦也是如此。 確認 [排除] 群組中的使用者可以從任何網络存取 SharePoint 和 Exchange。
  5. 啟用原則 4:確認所有使用者無法從行動裝置上的原生郵件應用程式取得 Exchange Online。
  6. 停用 SharePoint Online 和 Exchange Online 的現有 MFA 原則。

在下一個範例中, 範例 B - 應變條件式存取原則可允許行動存取 Salesforce,商務應用程式的存取權會還原。 在此案例中,客戶通常需要其銷售員工從行動裝置存取 Salesforce(設定為使用 Microsoft Entra ID 單一登錄),才能從相容的裝置上存取。 在此情況下,中斷是評估裝置合規性時發生問題,而且中斷發生在銷售小組需要存取 Salesforce 以關閉交易的敏感時間發生。 這些應變原則會授與重要使用者從行動裝置存取 Salesforce 的許可權,讓他們可以繼續關閉交易,而不會干擾業務。 在此範例中,SalesforceContingency 包含所有需要保留存取權和 Sales 的 Sales 員工 管理員 包含 Salesforce 的必要系統管理員。

範例 B - 應變條件式存取原則:

  • 原則 1:封鎖不在 SalesContingency 小組中的每個人
    • 名稱:EM001 - 啟用緊急狀態:裝置合規性中斷[1/2] - Salesforce - 封鎖 SalesforceContingency 以外的所有使用者
    • 使用者和群組:包含所有使用者。 排除 Sales 管理員 s 和 SalesforceContingency
    • Cloud Apps:Salesforce。
    • 條件:無
    • 授與控件:封鎖
    • 狀態:僅限報表
  • 原則 2:封鎖銷售小組從行動裝置以外的任何平臺 (以減少攻擊的表面區域)
    • 名稱:EM002 - 啟用緊急狀態:裝置合規性中斷[2/2] - Salesforce - 封鎖 iOS 和 Android 以外的所有平臺
    • 使用者和群組:包括 SalesforceContingency。 排除銷售 管理員
    • Cloud Apps:Salesforce
    • 條件:裝置平臺包含所有平臺、排除 iOS 和 Android
    • 授與控件:封鎖
    • 狀態:僅限報表

開啟順序:

  1. 從 Salesforce 的現有裝置合規性政策中排除 Sales 管理員 s 和 SalesforceContingency。 確認 SalesforceContingency 群組中的使用者可以存取 Salesforce。
  2. 啟用原則 1:確認 SalesContingency 外部的使用者無法存取 Salesforce。 確認 Sales 管理員 s 和 SalesforceContingency 中的使用者可以存取 Salesforce。
  3. 啟用原則 2:確認 SalesContingency 群組中的用戶無法從其 Windows/Mac 膝上型電腦存取 Salesforce,但仍可以從其行動裝置存取。 確認 Sales 管理員 仍然可以從任何裝置存取 Salesforce。
  4. 停用 Salesforce 的現有裝置合規性政策。

內部部署資源使用者鎖定的應變措施 (NPS 擴充功能)

如果您要使用 Microsoft Entra 多重要素驗證 NPS 擴充功能來保護 VPN 存取,請考慮將您的 VPN 解決方案同盟為 SAML 應用程式 ,並依照下列建議判斷應用程式類別。

如果您已部署 Microsoft Entra 多重要素驗證 NPS 擴充功能來保護內部部署資源,例如 VPN 和遠端桌面閘道,使用 MFA - 如果您已準備好在緊急情況下停用 MFA,您應該事先考慮。

在此情況下,您可以停用 NPS 擴充功能,因此 NPS 伺服器只會驗證主要驗證,而且不會對使用者強制執行 MFA。

停用 NPS 擴充功能:

  • 將 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 登錄機碼匯出為備份。
  • 刪除 「AuthorizationDL」 和 「ExtensionDL」 的登錄值,而不是 Parameters 機碼。
  • 重新啟動網路原則服務 (IAS) 服務,變更才會生效
  • 判斷 VPN 的主要驗證是否成功。

一旦服務復原,且您已準備好再次對用戶強制執行 MFA,請啟用 NPS 擴充功能:

  • 從備份HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 匯入登錄機碼
  • 重新啟動網路原則服務 (IAS) 服務,變更才會生效
  • 判斷 VPN 的主要驗證和次要驗證是否成功。
  • 檢閱 NPS 伺服器和 VPN 記錄檔,以判斷哪些使用者在緊急時段內已登入。

即使您已同盟或使用傳遞驗證,仍部署密碼哈希同步處理

如果下列條件成立,也可能會發生用戶鎖定:

  • 您的組織使用混合式身分識別解決方案搭配傳遞驗證或同盟。
  • 您的內部部署身分識別系統(例如 Active Directory、AD FS 或相依元件)無法使用。

為了更具彈性,您的組織應該 啟用密碼哈希同步,因為它可讓您 在內部部署身分識別系統關閉時切換為使用密碼哈希同步

Microsoft 建議

使用 Microsoft Entra 連線 精靈啟用密碼哈希同步處理,無論您的組織使用同盟還是傳遞驗證。

重要

不需要將使用者從同盟轉換成受控驗證,以使用密碼哈希同步處理。

在中斷期間

如果您選擇實作風險降低方案,您就能夠自動在單一訪問控制中斷中倖存下來。 不過,如果您選擇建立應變計劃,您可以在訪問控制中斷期間啟用應變原則:

  1. 啟用您的應變原則,以授與目標使用者、從特定網路存取特定應用程式的存取權。
  2. 停用您的一般控件型原則。

Microsoft 建議

根據中斷期間使用哪些風險降低或應變措施,您的組織可能會只使用密碼來授與存取權。 沒有保障是必須仔細權衡的相當大的安全性風險。 組織必須:

  1. 作為變更控制策略的一部分,請記錄每個變更和先前的狀態,以在訪問控制完全運作時立即回復您實作的任何應變。
  2. 假設惡意執行者會在您停用 MFA 時,嘗試透過密碼噴灑或網路釣魚攻擊來收穫密碼。 此外,不良動作專案可能已經有先前未授與存取權給此視窗期間可嘗試的任何資源的密碼。 對於主管等重要使用者,您可以在停用 MFA 之前先重設其密碼,部分降低此風險。
  3. 封存所有登入活動,以識別在 MFA 停用期間存取哪些項目的人員。
  4. 分級此時段期間報告 的所有風險偵測。

中斷之後

復原您在啟動應變計劃期間所做的變更,一旦還原導致中斷的服務。

  1. 啟用一般原則
  2. 將應變原則停用為僅限報表模式。
  3. 復原您在中斷期間所做的任何其他變更並記錄。
  4. 如果您使用緊急存取帳戶,請記得重新產生認證,並在緊急存取帳戶程式中實際保護新的認證詳細數據。
  5. 繼續 對可疑活動中斷后報告 的所有風險偵測進行分級。
  6. 撤銷發出以一組用戶為目標的所有重新整理令牌 。 撤銷所有重新整理令牌對於中斷期間所使用的特殊許可權帳戶而言很重要,而且這麼做會強制他們重新驗證並符合已還原原則的控制。

緊急選項

在緊急狀況中,您的組織先前未實作風險降低或應變計劃,然後遵循使用者鎖定應變區段中的建議,如果他們已經使用條件式存取原則來強制執行 MFA。 如果您的組織使用每個使用者 MFA 舊版原則,您可以考慮下列替代方式:

  • 如果您有公司網路輸出IP位址,您可以將它們新增為受信任的IP,以便只對公司網路啟用驗證。
  • 如果您沒有輸出 IP 位址的清查,或必須啟用公司網路內外的存取權,您可以藉由指定 0.0.0.0/1 和 128.0.0.0/1,將整個 IPv4 位址空間新增為受信任的 IP。

重要

如果您擴大信任的IP位址以解除封鎖存取,則不會產生與IP位址相關聯的風險偵測(例如不可能移動或不熟悉的位置)。

深入了解