在 Azure AD 中設定身分保護和 MFA

在雲端保護身分不再是可選項，而是必需品。 任何現代安全戰略的關鍵組成部分Azure AD（現在更名為 Microsoft Entra ID）已成為 Microsoft 365、SaaS 應用程式和混合式環境的中央驗證中心（參見 配置 Azure AD 和 SharePoint因此，任何這方面的失誤都可能為整個組織帶來風險。這就是為什麼了解如何正確配置這兩項如此重要的原因。 身分保護 如 多重身份驗證 (MFA) 正確且始終如一。

透過適當的配置，您可以將多因素身份驗證 (MFA)、條件存取、身分保護和現代身份驗證方法（包括 OATH 令牌和 FIDO2 金鑰；請參閱）結合起來使用。 密碼學導論）以達到兩者之間的平衡 強大的安全性和合理的使用者體驗在本文中，我們將詳細介紹所有關鍵選項：可疑活動通知、OATH 令牌的使用、電話呼叫配置、受信任的 IP 位址、驗證方法、條件存取原則、與 Active Directory 的混合場景以及基於風險的自適應身份驗證的可能性。

多因素身份驗證是指在登入過程中，系統會提示使用者進行對應驗證的過程。 一個或多個附加驗證因素 除了密碼之外，還可以是傳送到您手機的驗證碼、Microsoft Authenticator 中的推播通知、OATH 硬體令牌、FIDO2 金鑰，甚至是生物辨識數據，例如指紋（透過 Windows Hello 企業版）。

這樣做的目的是，即使攻擊者竊取或猜中了密碼，他們也會束手無策，因為 它不具備第二個因素。鑑於網路外洩和購買的憑證數量龐大，以及網路釣魚的有效性，多因素身份驗證 (MFA) 已成為最有效的防禦措施之一。 阻止基於身分的攻擊無論是在 Azure AD 還是本機 Active Directory 中。

同時，Microsoft Entra ID Protection 增加了一層保護。 風險偵測與評估 關於登入和身份，根據異常位置、未知設備、已知攻擊模式甚至用戶報告等訊號，系統可以將帳戶標記為高風險，並允許應用糾正策略（存取阻止或密碼重設）。

在實踐中，將多因素身份驗證 (MFA) 與身份保護和條件存取相結合，可以讓你提出要求。 僅在情況需要時才考慮其他因素。 （例如，在高風險情況下），在不損害安全性的前提下減少摩擦。這種適應性方法正是越來越多的組織在其混合辦公和遠距辦公環境中所尋求的。

可疑活動和高風險用戶通知

Azure AD 中身分保護最有趣的方面之一是使用者能夠… 直接將他們標記為可疑人員 無法辨識的 MFA 請求。這可以透過 Microsoft Authenticator 應用（拒絕並報告）或透過電話選項來解決。

當使用者舉報 MFA 要求為詐欺性請求時，Entra ID Protection 會將其記錄為詐欺性請求。 用戶回報的可疑活動 並將帳戶餘額提高到 高風險用戶接下來，您配置的基於風險的策略或手動回應流程就會發揮作用。

此事件反映在多個日誌和儀表板中：風險檢測報告（檢測類型“用戶報告的可疑活動”，高風險級別，最終用戶來源）、登入日誌（身份驗證結果為 用戶拒絕了多因素身份驗證並在審計日誌中作為一項特定活動記錄下來。如果您想要…，所有這些都至關重要。 調查身分盜竊事件 或自動回复，為此目的 網路安全培訓 員工非常勝任。

若要啟用此功能，請從 Microsoft 管理中心前往： 輸入ID > 身份驗證方式 > 設定 並設置選項 檢舉可疑活動 已啟用。如果保留「由 Microsoft 管理」選項，該功能將保持非活動狀態，因此如果您希望使用者主動協作偵測攻擊，則值得檢查一下。

您也可以定義一個 報告代碼 如果您已為租用戶上傳自訂語音問候語，則使用者在語音通話期間將輸入此代碼以將通話標記為可疑。如果您未進行任何配置，則無論您在策略中如何定義，預設代碼均為 0。

使用 Microsoft 授權進行風險管理。輸入 ID P1

使用 P1 許可證，身分保護功能會受到一些限制，但您仍然可以… 可視化和調查風險檢測 與已將多因素身份驗證 (MFA) 標記為可疑的用戶相關。這些檢測結果會出現在風險報告、登入日誌和稽核日誌中，這已經為取證分析提供了一個很好的起點。

在這種情況下，緩解措施通常是手動或半自動的：IT 團隊或支援服務可能會要求使用者執行以下操作： 使用 SSPR 重設密碼 （自助密碼重設）或代表您更改密碼。您也可以使用 Microsoft Graph 或 PowerShell 自動執行工作流程，以強制變更密碼、撤銷活動會話，甚至 暫時停用該帳戶 調查正在進行中。

在沒有 P2 的環境中，您還可以透過 Graph API 利用風險事件來構建 自訂回應工作流程將它們與工單系統或 SIEM/SOAR 解決方案集成，以實現更專業的身份事件編排。

使用 Microsoft Enter ID P2 進行自動風險修正

有了P2許可證，最強大的部分就發揮作用了： 基於風險的條件存取策略這些策略允許系統在使用者被標記為高風險時（例如，在報告可疑活動後）自動執行諸如阻止登入或要求重設密碼之類的操作。

在條件存取設定中，您可以轉到 條件 > 使用者風險 並建立對高風險或中等風險等值做出反應的規則。一個經典的例子是配置高風險用戶必須 請先更改密碼才能繼續否則，他們將被直接封禁，直到管理員審核該案例。

這個自適應身分驗證模型與多因素身份驗證 (MFA) 非常契合：它不再總是靜態地要求第二個因素，而是可以 提高身份驗證要求 基於即時風險（異常位置、可疑 IP、異常行為等）。這樣，在一切「正常」的情況下，使用者不會被過多的多因素身份驗證請求所困擾；而一旦出現任何攻擊跡象，閾值就會立即提高。

Azure AD 中的 OATH 令牌和 TOTP 程式碼

除了經典的 Microsoft Authenticator 應用程式外，Entra ID 還支持 誓言 TOTP 硬體令牌 它使用 SHA-1 演算法產生基於時間的一次性代碼 (OTP)，通常每 30 或 60 秒產生一次。對於因內部政策、受監管行業或用戶沒有公司智慧型手機而更傾向於使用專用實體設備進行多因素身份驗證 (MFA) 的組織而言，此選項非常合適。

這些令牌通常會附帶一個出廠預設的密鑰（種子）。若要將它們與 Azure AD 搭配使用，必須透過 CSV 檔案將此金鑰輸入到租用戶。有一些重要的限制：密鑰的使用次數有限。 128 個字元以 Base32 編碼它只能包含字母 az/AZ 和數字 1 到 7，並且必須符合預期格式，系統才能接受它。

也可以使用 可程式 OATH TOTP 硬體令牌 可重新配置，其處理方式與軟體令牌類似。無論如何，對硬體 OATH 令牌的支援目前處於公開預覽階段，這意味著：Azure 預覽條款中可能存在變更、限制和附加使用條款。

令牌上傳過程使用包含 UPN、序號、金鑰、時間間隔、製造商和型號等列的 CSV 檔案進行。上傳完成後， 登入 ID > 多因素認證 > OATH 令牌該服務會處理文件，並允許您在可下載的 CSV 文件中查看格式錯誤。

錯誤糾正後，每個令牌必須 手動啟用管理員選擇「啟動」並輸入裝置上顯示的驗證碼，即可將令牌永久關聯到使用者。每個人最多可以組合… 五因素認證基於令牌或身份驗證器應用程式 同時，這為方法之間的冗餘或過渡提供了相當大的靈活性。

電話和語音留言設置

Azure AD 中另一種廣泛使用的 MFA 方法是 透過語音電話進行電話驗證使用者會接到自動語音電話，根據設定狀況，按下「#」鍵或輸入PIN碼即可完成身份驗證。這種體驗可以高度客製化，尤其是在語音通話仍然是首選或必要方式的環境中。

預設情況下，Microsoft 使用特定國家或地區的電話號碼發起通話。例如，在美國，有幾個預先定義的號碼，而在其他國家/地區，則提供了一個特定的號碼清單。務必將這些號碼告知使用者或合作夥伴。 請他們將這些添加到允許清單中 如果他們使用垃圾郵件過濾器，以避免通話傳遞問題。

如果你願意，你也可以自訂。 來電顯示號碼 （來電顯示）功能可用於多因素身份驗證 (MFA) 呼叫，但必須是美國號碼。此選項可在以下位置進行設定： 登入 ID > 多重驗證 > 電話通話設置您只需設定所需的數字並儲存變更即可。

另一個有趣的客製化是使用 個性化語音留言除了微軟的標準語音提示外，您還可以上傳自己的音訊文件，格式為 .wav 或 .mp3，文件大小不超過 1 MB，時長不超過 20 秒。如果訊息太長，驗證可能會失敗，因為使用者可能在語音提示結束前沒有回應。

使用者聽到的語言取決於瀏覽器或上下文中偵測到的語言，以及管理員上傳的自訂訊息中可用的語言。例如，如果只有一條德語問候語，那麼除非有其他語言的更合適的替代方案，否則這條訊息將同時播放給德語用戶和其他用戶。

微軟為不同類型的訊息（身份驗證成功、標準問候、詐騙訊息、重試、啟動等）提供了預設腳本，您可以將其用作基礎。 錄製你自己的音頻若要進行配置，請返回電話通話設定部分，選擇“新增問候語”，選擇訊息類型、語言並上傳聲音檔案。

進階 MFA 服務配置和受信任的 IP 位址

除了驗證方法外，傳統 MFA 服務配置入口網站還提供以下選項： 受信任的IP位址、應用程式密碼 以及「記住多重身份驗證」功能。儘管微軟正日益推廣使用條件存取和統一身分驗證策略，但此入口網站在許多環境中仍然適用。

受信任的 IP 位址允許使用者從以下位置連接： 企業內部網路 （特定 IP 網段）在某些瀏覽器流程中無需進行多因素身份驗證 (MFA)。此功能適用於 Microsoft Entra ID P1，有助於減少您在網路內部存取時的阻力，同時保持對外部存取的 MFA 驗證。

在託管租用戶中，您最多可以定義 50個IP位址範圍 在被視為受信任的 CIDR 表示法中。在聯合租用戶中，也可以啟用「所有聯合使用者」選項，以便透過 AD FS 從內部網路進行驗證的使用者繞過 MFA，前提是 AD FS 發出相應的通知（insidecorporatenetwork），該通知透過聲明頒發規則進行設定。

請注意，如果您使用 NPS 擴充功能為本機應用程式提供 MFA，Azure AD 看到的 IP 位址始終是 NPS 伺服器的 IP 位址，因此使用受信任的 IP 位址範圍可能無法如預期運作。此外，還需記住： 企業網路之外無論是否定義了受信任的 IP 位址，多因素身份驗證 (MFA) 仍然是必要的。

目前管理可信位置的建議方法是透過以下方式： 使用命名位置進行條件訪問在「登入 ID」>「條件存取」>「命名位置」中，您可以建立新位置，將其標記為受信任位置，並定義 IP 位址範圍（例如，40.77.182.32/27）。這些位置隨後會在條件存取策略中使用，以確定何時需要多因素身份驗證 (MFA)。

使用條件存取或傳統服務啟用受信任的 IP 位址

如果您希望將傳統的受信任 IP 設定與條件存取保持一致，可以在「命名位置」部分找到「設定多重驗證受信任 IP 位址」選項。您可以在此指定是否對聯合使用者使用 AD FS 內部網路通知，以及要視為受信任的特定公用 IP 位址範圍。

如果您希望繼續使用 傳統服務配置在該頁面上，您還可以找到「針對來自我內部網路聯合使用者的請求」和「針對來自特定 IP 位址子網路範圍的請求」選項，它們使用相同的 CIDR 表示法邏輯和範圍限制。此配置將一直有效，直到您完成向現代身份驗證方法策略的遷移。

可用的驗證方法及其管理

Azure AD 提供相當廣泛的功能 認證方式 根據您的配置，這些方法可用於多因素身份驗證 (MFA) 和單一登入驗證 (SSPR)。支援的多因素身份驗證方法包括：Microsoft Authenticator、Authenticator Lite（Outlook 中的）、Windows Hello 企業版、FIDO2 安全性金鑰、OATH 硬體令牌、OATH 軟體令牌、簡訊和語音通話。

此外，還有一些方法，例如 電子郵件驗證 或安全性問題，雖然它們不屬於多因素身份驗證 (MFA)，但可以用作單一登入驗證 (SSPR) 的驗證因素。此外，還有應用程式密碼，專為不支援現代身份驗證的舊版應用程式設計，專門用於基於使用者的 MFA 場景。

微軟推薦的管理所有這些方法的方式是： 身份驗證方法策略您可以透過「登入 ID」>「安全性」>「驗證方法」>「原則」存取此統一控制台，從而為不同的使用者群組啟用或停用驗證方法，定義其他參數（例如，使用 Microsoft Authenticator 進行無密碼配置，顯示位置和應用程式名稱），並從單一位置控制 MFA 和 SSPR。

同時，沿襲下來的政策仍然存在： 365 管理中心中的 MFA 設置 （這會影響基於使用者的 MFA 和帶有條件存取的 MFA）以及 SSPR 驗證方法的配置（使用者 > 密碼重設 > 驗證方法）。這些策略不會自動與新的統一策略同步，因此在共存期間，您必須注意… 所有地方的配置保持一致.

當多個策略共存時，處理順序為：首先是身份驗證方法策略，然後是舊版 MFA 設置，最後是 SSPR 設定。 Azure AD 會遵循所有這些策略的配置，因此，如果某個方法在任何策略中被允許，使用者就可以註冊並使用它。要完全阻止某個方法，您需要在 SSPR 策略中對其進行限制。 所有相關政策.

在驗證方法控制台中，您也會找到一個遷移部分，其中指示您目前的階段：遷移前、遷移進行中或遷移完成。在前兩個狀態下，仍會套用舊版策略。選擇「遷移完成」後，將只採用新版身份驗證方法策略，而忽略舊版策略。

請記住啟用多重身份驗證和可信任設備。

「記住多因素身份驗證」功能旨在減少使用者操作的繁瑣步驟，允許使用者在裝置和瀏覽器上成功完成多因素身份驗證後，… 跳過其他檢查 在設定的天數內不再詢問。其運作方式是使用持久性 cookie，當使用者選擇「X 天內不再詢問」選項時，該 cookie 會保存在瀏覽器中。

只要 Cookie 仍然有效（未被刪除或過期），且使用者使用相同瀏覽器，則在該特定情況下不會再次要求多因素身份驗證 (MFA)。如果使用者在同一裝置上切換瀏覽器或清除 Cookie，則會再次要求驗證。此選項僅適用於基於瀏覽器的流程，不適用於其他流程。 無需瀏覽器的應用程式但是，在這些 Azure AD 執行個體中，當驗證升級令牌時，它也會檢查上次多重驗證的有效期限。

此功能可大幅減少 Web 應用程式中的多因素身份驗證 (MFA) 提示次數，但天數必須仔細調整：如果將其設定為低於現代用戶端中典型的 90 天令牌過期期，則甚至可能出現問題。 提高 某些應用程式中的 MFA 請求頻率。此外，如果將此功能與條件存取結合使用，則兩者之間的交互作用可能會導致 MFA 請求數量增加或減少，具體取決於配置的規則。

若要啟用此功能，您必須從舊版 MFA 服務設定入口網站前往 服務設定 > 記住多重身份驗證若要啟用此功能，請選擇“允許使用者在受信任的裝置上記住多因素身份驗證”，並設定保留天數（建議 90 天或更短，以獲得良好的使用者體驗）。啟用後，用戶在進行多因素身份驗證時將看到「不再詢問」選項。

啟用具有條件存取策略的多因素身份驗證

雖然 Azure AD 允許您直接為每個使用者啟用 MFA，但 Microsoft 建議使用 條件存取策略 控制何時以及哪些人需要使用多因素身份驗證。這提供了更精細的控制級別，更適合實際應用場景：例如某些關鍵應用程式、來自不受信任網路的存取、特權角色等。

要將條件存取與多因素身份驗證 (MFA) 結合使用，您需要一個租戶。它將於 [日期] 生效。 P1 或試用許可證並且需要一個至少具有條件存取管理員角色的帳戶（某些多因素身份驗證選項也可以使用身份驗證策略管理員角色進行管理）。此外，建議建立一個非管理員測試使用者和一個測試群組（例如，「MFA-Test-Group」），以便在不影響整個組織的情況下驗證體驗。

典型的做法是建立一個策略，該策略適用於特定的使用者或使用者群組，並針對特定的雲端應用程式或特定操作觸發。然後，在存取控制中，選擇“授予存取權限”，並將“需要多因素身份驗證”標記為必要條件。之後，該策略即可保持啟動狀態。 僅報告 先觀察其影響再啟動。

一個經典的測試範例是將策略套用到測試群組以及諸如「Windows Azure 服務管理 API」或 Microsoft Entra 管理中心之類的資源。這將向您展示，當存取這些資源時，系統如何要求 MFA，或者如果使用者尚未註冊 MFA，系統如何提示使用者註冊。

最終使用者體驗通常包括：首先在未啟用多因素身份驗證 (MFA) 的情況下登入未受保護的資源，然後登出，最後存取受保護的資源，並在該資源中獲得引導。 MFA註冊流程 （身份驗證手機、帶分機的工作手機或行動應用程式）。註冊完成後，後續登入受保護資源時，將根據配置的方式（推播通知、簡訊、電話、應用程式碼等）觸發驗證。

混合場景，結合 Active Directory 和 MFA

在許多環境中，本機部署的 Active Directory 仍然是 身分基礎設施的核心Azure AD 為 Microsoft 365 和雲端應用程式提供驗證前端。在這種情況下，如何在本地端和雲端一致地部署多因素身份驗證 (MFA) 是主要挑戰之一。

Active Directory 本身僅透過以下方式提供原生 MFA 支持 智慧卡認證這不應與 AD FS 的 MFA 混淆。為了加強伺服器和 PC 上的互動式登入或 RDP，許多組織將 Windows Hello 企業版或第三方 MFA 提供者（例如 Duo）等解決方案直接整合到終端機或跳轉伺服器中； 身分認同韌性 高可用性是這些設計中的重要考慮因素。

在使用基於雲端的身份服務提供者（例如 Entra ID）時，通常會依賴以下工具： Microsoft Enter Connect （以前稱為 Azure AD Connect）用於同步本機 AD 和雲端租用戶之間的身分。之後，對於所有直接透過 Entra ID 進行身份驗證的應用程序，都會在 Entra ID 層強制執行多因素身份驗證 (MFA)、條件存取和身份保護。

沒有高級授權的Entra租戶可以使用 安全預設設定 要啟用基本安全性設置，包括強制多因素身份驗證 (MFA) 和阻止舊式身份驗證，需要啟用 P1 或 P2 權限。但是，如果沒有 P1 或 P2 權限，則無法使用條件訪問，這嚴重限制了定義特定規則（例如按應用程式、位置、風險等）的能力。

相反，對於 Microsoft 365 Business、E3、E5 或 Entra ID P1/P2 授權等方案，以下功能將會解鎖： 條件存取策略 並且在適當情況下可以與基於使用者的 MFA 結合使用。 Microsoft 365 和 Office 365 都支援透過簡訊、語音通話和 Microsoft Authenticator 進行 MFA，而 Entra ID 則增加了更多選項，例如 FIDO2、Windows Hello、OATH 令牌等。

使用現代身份驗證（例如 OpenID Connect 或 OAuth2）並與 Entra ID 直接整合的應用程式可以無縫利用所有這些條件存取功能。對於不直接與 Entra 通訊的傳統應用程式或本機應用程序，可以使用其他方法。 Azure AD 應用程式代理 或與 NPS（網路策略伺服器）集成，在身份驗證流程中插入 MFA。

自適應身份驗證和身份保護

目前身分安全的發展趨勢已經超越了簡單地統一應用多因素身份驗證（MFA）。其理念是 增加或減少身份驗證要求 這取決於具體情況、風險以及使用者的歷史行為。這就是自適應身份驗證的用武之地。

Entra ID Protection 會持續分析與使用者和登入流程相關的風險：異常位置、未知設備、與機器人或暴力破解攻擊相關的模式、在被盜名單中發現的憑證等等。當風險較高時，系統會觸發糾正措施，例如要求使用者… 重設密碼 或直接阻止訪問，直到管理員介入。

透過將這些功能與條件存取結合，您可以設計諸如「如果使用者風險高，則阻止存取」或「如果登入風險為中高，則要求進行多因素身份驗證 (MFA)」之類的策略。這樣，驗證要求僅在可疑情況下才會啟動，而在正常情況下，使用者的工作流程不會發生任何變更。

這額外的安全層與其他防禦措施（修補程式、網路分段、終端保護、日誌監控等）相輔相成，增強了整體抵禦攻擊的能力。需要注意的是… 單憑MFA學位是不夠的然而，它是以身分為中心的縱深防禦策略中最有效的組成部分之一。

最終，無論是在雲端還是在與 Active Directory 混合的環境中，仔細配置身份驗證方法、多因素身份驗證 (MFA)、條件存取、受信任的 IP 位址、單點登入驗證 (SSPR) 和身份保護，都能建立一道非常強大的屏障，防止憑證被盜、網路釣魚攻擊和橫向移動，同時保持日常使用可接受的用戶體驗。