Microsoft Entra 驗證管理作業參考指南
本節 Microsoft Entra 作業參考指南說明了您應採取的檢查和動作，以保護和管理認證、定義驗證 (AuthN) 體驗、委派指派、測量使用量，以及根據企業安全性態勢來定義存取原則。
注意
這些建議是發佈時的最新資訊，但日後可能依情況修訂。 由於 Microsoft 的產品和服務會隨著時間演進，組織應持續評估其身分識別做法。
重要作業流程
指派各項重要工作的擁有者
管理 Microsoft Entra ID 需要能持續執行重要的操作工作和流程，且可能不屬於專案推出的一部分。 您仍必須將這些工作安排妥當，以最佳化您的環境。 重要工作及其建議的擁有者包括：
| Task | 負責人 |
|---|---|
| 在 Microsoft Entra ID 中管理單一登入 (SSO) 設定的生命週期 | 身分識別和存取權管理 (IAM) 作業小組 |
| 設計 Microsoft Entra 應用程式的條件式存取原則 | InfoSec 架構小組 |
| 在安全性資訊與事件管理 (SIEM) 系統中封存登入活動 | InfoSec 作業小組 |
| 封存 SIEM 系統中的風險事件 | InfoSec 作業小組 |
| 對安全性報告分級和進行調查 | InfoSec 作業小組 |
| 對風險事件分級和進行調查 | InfoSec 作業小組 |
| 針對 Microsoft Entra ID Protection 中標示為風險和弱點報告的使用者進行分級和調查 | InfoSec 作業小組 |
注意
Microsoft Entra ID Protection 需要 Microsoft Entra ID P2 授權。 若要尋找適用於您需求的正確授權，請參閱比較 Microsoft Entra ID Free 和 Microsoft Entra ID P1 或 P2 版本的正式推出功能。
在檢閱您的清單時，您可能會發現需要為沒有擁有者的工作指派擁有者，或是需要對不符合上述建議的工作調整其擁有者的所有權。
擁有者的建議閱讀資料
認證管理
密碼原則
妥當管理密碼是身分識別和存取權管理最重要的一環，通常也是最大的攻擊目標。 Microsoft Entra ID 支援多種功能，可協助防止攻擊取得成功。
使用下表來尋找建議的解決方案，以減輕須處理的問題：
| 問題 | 建議 |
|---|---|
| 沒有任何機制可保護弱式密碼 | 啟用 Microsoft Entra ID 自助式密碼重設 (SSPR) 和密碼保護 |
| 沒有任何機制可偵測密碼外洩 | 啟用密碼雜湊同步 (PHS) 以獲得深入解析 |
| 使用 AD FS 且無法移至受控驗證 | 啟用 AD FS 外部網路智慧鎖定和/或 Microsoft Entra 智慧鎖定 |
| 密碼原則會使用以複雜度為基礎的規則，例如長度、多個字元集或到期日 | 重新考慮使用 Microsoft 建議的作法，並將您的方法切換為密碼管理，以及部署 Microsoft Entra 密碼保護。 |
| 使用者未註冊使用多重要素驗證 | 註冊所有使用者的安全性資訊，就能搭配其密碼做為驗證使用者身分識別的機制 |
| 不會根據使用者風險而撤銷密碼 | 部署 Microsoft Entra ID Protection 使用者風險原則，以利用 SSPR 強制變更認證外洩的密碼 |
| 沒有智慧鎖定機制可防範來自已識別 IP 位址的不良執行者進行惡意驗證 | 使用密碼雜湊同步處理或 傳遞驗證 (PTA) 來部署雲端管理的驗證 |
有關密碼原則的建議閱讀資料
啟用自助式密碼重設和密碼保護
在技術支援中心的來電量和成本中，以需要變更或重設密碼的使用者佔最大宗。 除了成本之外，將變更密碼視為降低使用者風險的工具，是改善組織安全性態勢的基本步驟。
建議您至少部署 Microsoft Entra ID 自助式密碼重設 (SSPR) 和內部部署密碼保護來完成以下事項：
- 轉介技術支援中心的來電。
- 取代使用臨時密碼。
- 取代依賴內部部署解決方案的任何現有自助密碼管理解決方案。
- 避免在組織中使用弱式密碼。
注意
對於具有 Microsoft Entra ID P2 授權的組織，建議部署 SSPR，並將其作為 Microsoft Entra ID Protection 風險型條件式存取原則的一部分。
強式認證管理
密碼本身不夠安全，無法防範不良執行者存取您的環境。 任何具有特殊權限帳戶的使用者至少都必須啟用多重要素驗證。 在理想情況下，您應該啟用合併註冊，並要求所有使用者使用合併註冊體驗來註冊多重要素驗證和 SSPR。 最後，我們建議您採用提供復原的策略，以降低因未預期情況造成鎖定的風險。
內部部署中斷驗證復原
除了操作簡單以及啟用認證外洩偵測功能這兩項優點之外，Microsoft Entra 密碼雜湊同步處理 (PHS) 和 Microsoft Entra 多重要素驗證也可讓使用者存取軟體即服務 (SaaS) 應用程式和 Microsoft 365，不會因內部部署受到網路攻擊 (例如 NotPetya) 而中斷服務。 您也可以搭配同盟同時啟用 PHS。 啟用 PHS 後，若同盟服務無法使用，則可允許以驗證做為後援。
如果您的內部部署組織缺乏中斷復原策略，或該策略未與 Microsoft Entra ID 整合，您應部署 Microsoft Entra PHS，並制定包含 PHS 的災害復原方案。 啟用 Microsoft Entra PHS 後，若您的內部部署 Active Directory 無法使用時，使用者也能驗證 Microsoft Entra ID。
如需進一步了解您的驗證選項，請參閱針對 Microsoft Entra 混合式身分識別解決方案選擇正確的驗證方法。
以程式設計方式使用認證
使用 PowerShell 的 Microsoft Entra ID 指令碼或使用 Microsoft Graph API 的應用程式都需要進行安全驗證。 若執行這些指令碼和工具的認證管理不佳，會增加認證遭竊的風險。 如果您使用的指令碼或應用程式依賴硬式編碼的密碼或密碼提示，您應該先檢視設定檔或原始程式碼中的密碼，然後取代這些相依性，並盡可能使用 Azure 受控身分識別、整合式 Windows 驗證或憑證。 針對無法使用先前解決方案的應用程式，請考慮使用 Azure Key Vault。
如果您判斷有包含密碼認證的服務主體，而您不確定指令碼或應用程式如何保護這些密碼認證，請聯繫應用程式的擁有者，以進一步了解使用模式。
如果有包含密碼認證的服務主體，Microsoft 也建議您聯繫應用程式的擁有者，以了解使用模式。
驗證體驗
內部部署驗證
若內部部署網域控制站在企業網路的可見範圍時，使用整合式 Windows 驗證 (IWA) 的同盟驗證，或是使用密碼雜湊同步處理的無縫單一登入 (SSO) 受控驗證或傳遞驗證會是最佳的使用者體驗。 它能將認證提示疲勞降至最低，並降低使用者成為網路釣魚攻擊受害者的風險。 如果您已經搭配 PHS 或 PTA 使用雲端管理的驗證，但使用者在內部部署驗證時仍需要輸入密碼，則您應該立即部署無縫 SSO。 另一方面，如果您目前已與方案建立同盟，最終要遷移至雲端管理的驗證，則您應該在遷移專案中實行無縫 SSO。
裝置信任存取原則
就像是貴組織中的使用者，裝置是您想要保護的核心身分識別。 您可以使用裝置的身分識別，隨時隨地保護您的資源。 您可透過下列方式驗證裝置並考慮其信任類型，藉以改善您的安全性態勢和可用性：
- 避免在裝置受信任時發生衝突，例如透過多重要素驗證
- 封鎖不受信任裝置的存取權限
- 針對 Windows 10 裝置，請順暢地為內部部署資源提供單一登入。
您可以使用下列其中一種方法，將裝置身分識別導入 Microsoft Entra ID 並加以管理，以達到此目標：
- 組織可以使用 Microsoft Intune 來管理裝置並強制執行合規性原則、證明裝置健康情況，以及根據裝置是否符合規範來設定條件式存取原則。 Microsoft Intune 可以管理 iOS 裝置、Mac 桌上型電腦 (透過 JAMF 整合)、Windows 桌上型電腦 (以原生方式使用 Windows 10 版的行動裝置管理，以及使用 Microsoft Configuration Manager 進行共同管理) 和 Android 行動裝置。
- 透過 Microsoft Entra 混合式聯結，您可在 Active Directory 已加入網域的電腦裝置環境中，使用群組原則或 Microsoft Configuration Manager 進行管理。 組織可以搭配無縫 SSO 透過 PHS 或 PTA 部署受控環境。 將您的裝置導入 Microsoft Entra ID，便可透過跨雲端和內部部署資源的 SSO 來大幅提升使用者的效率，您也可以使用條件式存取來保護雲端和內部部署資源的存取權限。
如果您擁有已加入網域且未在雲端註冊的 Windows 裝置，或是已加入網域且已在雲端註冊的 Windows 裝置，但沒有條件式存取原則，則您應該註冊未註冊的裝置，且無論任一情形，都應在您的條件式存取原則中使用 Microsoft Entra 混合式聯結作為控制項。
如果您使用 MDM 或 Microsoft Intune 來管理裝置，但未在條件式存取原則中使用裝置控制項，則建議您將要求裝置標示為符合規範作為這些原則的控制項。
有關裝置信任存取原則的建議閱讀資料
Windows Hello 企業版
在 Windows 10 中，Windows Hello 企業版會以強式雙因素驗證取代電腦上的密碼。 Windows Hello 企業版可為使用者提供更流暢的多重要素驗證體驗，並降低您對密碼的依賴。 如果您尚未開始推出 Windows 10 的裝置，或只有部分部署這些裝置，建議您升級至 Windows 10，並在所有裝置上啟用 Windows Hello 企業版。
如果您想要深入了解無密碼驗證，請參閱使用 Microsoft Entra ID 的無密碼世界。
應用程式驗證和指派
應用程式的單一登入
為整個企業提供標準化的單一登入機制，對最佳使用者體驗、降低風險、報告和治理能力都非常重要。 如果您使用的應用程式支援搭配 Microsoft Entra ID 的 SSO，但目前設定為使用本機帳戶，則您應該重新設定這些應用程式，以搭配 Microsoft Entra ID 使用 SSO。 同樣地，如果您使用的應用程式支援搭配 Microsoft Entra ID 的 SSO，但目前使用其他識別提供者，則您應該重新設定這些應用程式，以搭配 Microsoft Entra ID 使用 SSO。 對於不支援同盟通訊協定但支援表單架構驗證的應用程式，我們建議您將應用程式設定為搭配 Microsoft Entra 應用程式 Proxy 使用密碼保存庫。
注意
如果您沒有探索組織中非受控應用程式的機制，我們建議使用雲端應用程式安全性代理程式 (CASB) 來執行探索程式，例如 Microsoft Defender for Cloud Apps。
最後，如果您有 Microsoft Entra 應用程式庫，並使用支援 SSO 與 Microsoft Entra ID 的應用程式，我們建議您在應用程式庫中列出該應用程式。
有關單一登入的建議閱讀資料
將 AD FS 應用程式移轉至 Microsoft Entra ID
將應用程式從 AD FS 移轉至 Microsoft Entra ID 可提供安全性的額外功能、更一致的管理能力，以及更完善的共同作業體驗。 如果您在 AD FS 中設定的應用程式支援搭配 Microsoft Entra ID 的 SSO，則應該重新設定這些應用程式，以搭配 Microsoft Entra ID 使用 SSO。 如果您在 AD FS 中設定的應用程式具有 Microsoft Entra ID 不支援的不常用設定，則應聯繫應用程式擁有者，以了解特殊設定是否為應用程式的必要需求。 如果是非必需，您應該重新設定應用程式，以搭配 Microsoft Entra ID 使用 SSO。
注意
適用於 AD FS 的 Microsoft Entra Connect Health 可用來收集每個應用程式的設定詳細資料，並可能會移轉到 Microsoft Entra ID。
將使用者指派至應用程式
將使用者指派給應用程式的最好方法，是使用群組進行對應，因為群組可有更大的彈性和大規模管理的能力。 使用群組的優點包括基於屬性的動態成員資格群組以及對應用程式擁有者的委派。 因此，如果您已經使用和管理群組，建議您採取下列動作來大規模改善管理：
- 將群組管理和治理委派給應用程式擁有者。
- 允許自助式存取應用程式。
- 如果使用者屬性可以一致判斷對應用程式的存取權，請定義動態成員資格群組。
- 使用 Microsoft Entra 存取權檢閱，將證明實作到用來存取應用程式的群組。
另一方面，如果您發現有指派給個別使用者的應用程式，請務必在這些應用程式上實作治理。
有關將使用者指派給應用程式的建議閱讀資料
- 將使用者和群組指派至 Microsoft Entra ID 中的應用程式
- 在 Microsoft Entra ID 中委派應用程式註冊權限
- Microsoft Entra ID 中群組的動態成員資格規則
存取原則
具名位置
您可以使用 Microsoft Entra ID 中的具名位置，標記組織中受信任的 IP 位址範圍。 Microsoft Entra ID 會使用具名位置來：
- 預防風險事件中的誤判。 從受信網路任位置登入可降低使用者的登入風險。
- 設定位置型條件式存取。
根據優先順序，使用下表來尋找最符合貴組織需求的建議解決方案：
| 優先順序 | 案例 | 建議 |
|---|---|---|
| 1 | 如果您使用 PHS 或 PTA，但未定義具名位置 | 定義具名位置以改善對風險事件的偵測能力 |
| 2 | 如果您已建立同盟，但未使用「insideCorporateNetwork」宣告，且未定義具名位置 | 定義具名位置以改善對風險事件的偵測能力 |
| 3 | 如果您未在條件式存取原則中使用具名位置，且條件式存取原則中沒有任何風險或裝置控制 | 設定條件式存取原則以包含具名位置 |
| 4 | 如果您已建立同盟，且使用「insideCorporateNetwork」宣告，但未定義具名位置 | 定義具名位置以改善對風險事件的偵測能力 |
| 5 | 如果您搭配多重要素驗證使用信任的 IP 位址，而不是具名位置並將其標示為受信任 | 定義具名位置，並將其標示為受信任，以改善對風險事件的偵測能力 |
風險型存取原則
Microsoft Entra ID 可以計算每次登入和每位使用者的風險。 使用風險作為存取原則的準則，可提供更好的使用者體驗，例如：驗證提示較少以及更妥善的安全性，像是只在需要時提示使用者，以及將回應和補救自動化。
如果您已經擁有支援在存取原則中使用風險的 Microsoft Entra ID P2 授權，我們強烈建議您在安全性態勢中增加風險。
有關風險型存取原則的的建議閱讀資料
用戶端應用程式存取原則
Microsoft Intune 應用程式管理 (MAM) 可將資料保護控制 (例如：儲存體加密、PIN、遠端儲存體清除等) 發送至相容用戶端行動應用程式 (例如 Outlook 行動應用程式)。 此外，也可以建立條件式存取原則，以限制從核准或相容的應用程式 (例如 Exchange Online) 存取雲端服務。
如果您的員工安裝了支援 MAM 的應用程式 (例如 Office 行動裝置應用程式) 來存取公司資源 (例如 Exchange Online 或 Microsoft 365 中的 SharePoint)，而且您也支援 BYOD (攜帶您自己的裝置)，建議您部署應用程式 MAM 原則，以在沒有 MDM 註冊的個人擁有裝置上管理應用程式設定，然後更新您的條件式存取原則，只允許來自支援 MAM 的用戶端進行存取。
如果員工在受 Intune 管理的裝置上安裝支援 MAM 的應用程式，則您應該考慮部署應用程式 MAM 原則來管理個人裝置的應用程式設定，並將條件式存取原則更新為只允許從支援 MAM 的用戶端存取。
條件式存取的實作
條件式存取是改善貴組織安全性態勢的基本工具。 因此，請務必遵循下列最佳作法：
- 確定所有 SaaS 應用程式都已套用至少一個原則
- 避免將 [所有應用程式] 篩選條件與區塊控制項合併，以避免鎖定風險
- 避免使用 [所有使用者] 做為篩選絛件，並且不小心新增 [來賓]
- 將所有「舊版」原則遷移至 Azure 入口網站
- 攔截使用者、裝置和應用程式的所有準則
- 使用條件式存取原則來實作多重要素驗證，而不是使用每個使用者的 MFA
- 具有可套用至多個應用程式的一小組核心原則
- 定義空白的例外狀況群組，並將其新增至原則，以建立例外狀況策略
- 規劃不使用多重要素驗證控制項的緊急安全窗口帳戶
- 確保跨 Microsoft 365 用戶端應用程式 (例如 Teams、OneDrive、Outlook 等) 有一致的體驗。 針對 Exchange Online 和 Microsoft 365 中的 SharePoint 等服務來實作同一組控制項
- 應透過群組而非個人來實作原則指派
- 定期檢閱用於原則的例外狀況群組，以限制使用者超出安全性態勢的時間。 如果您擁有 Microsoft Entra ID P2，則可以使用存取權檢閱將流程自動化
有關條件式存取的建議閱讀資料
存取介面區
舊版驗證
多重要素驗證等強式認證無法使用舊版驗證通訊協定來保護應用程式，因此容易成為惡意執行者的攻擊媒介。 鎖定舊版驗證對於改善存取安全性態勢非常重要。
舊版驗證是指應用程式所使用的驗證通訊協定，如下所示：
- 不使用新式驗證的舊版 Office 用戶端 (例如，Office 2010 用戶端)
- 使用網際網路訊息存取通訊協定 (IMAP)/簡易郵件傳輸通訊協定 (SMTP)/網路服務提供點 (POP) 等郵件通訊協定的用戶端
攻擊者極之喜歡這些通訊協定，事實上，幾乎 100% 的密碼噴灑攻擊 都使用舊版驗證通訊協定！ 駭客會使用舊版驗證通訊協定，是因為它們不支援互動式登入，而這是額外的安全性挑戰 (例如多重要素驗證和裝置驗證) 所必需的。
如果您的環境普遍使用舊版驗證，您應該儘早規劃將舊版用戶端遷移至支援新式驗證的用戶端。 在相同的權杖中，如果您有某些使用者已經使用新式驗證，但其他使用者仍使用舊版驗證，則您應該採取下列步驟來鎖定舊版驗證用戶端：
使用登入活動報告找出仍然使用舊版驗證的使用者，並規劃補救措施：
將受影響的使用者升級到支援新式驗證的用戶端。
規劃完全移轉的時間範圍，並依下列各步驟進行鎖定。
識別在舊版驗證上有強烈相依性的舊版應用程式。 請參閱下方的步驟 3。
針對未使用舊版驗證的使用者在來源停用舊版通訊協定 (例如 Exchange 信箱)，以免提高暴露程度。
針對其他帳戶 (理想情況下，會是服務帳戶這類非自然人身分識別)，請使用條件式存取來限制在驗證後的舊版通訊協定。
有關舊版驗證的建議閱讀資料
同意授與
在非法同意授與攻擊中，攻擊者會建立 Microsoft Entra 註冊的應用程式，要求存取連絡人資訊、電子郵件或文件等資料。 使用者可能會在登陸惡意網站時，透過網路釣魚攻擊將同意授與給惡意應用程式。
以下清單中的應用程式具有您可能想要針對 Microsoft 雲端服務檢查的權限：
- 具有應用程式或委派 *.ReadWrite 權限的應用程式
- 具有委派權限的應用程式，可以代表使用者讀取、傳送或管理電子郵件
- 獲授與使用下列權限的應用程式：
| 資源 | 權限 |
|---|---|
| Exchange Online | EAS.AccessAsUser.All |
| EWS.AccessAsUser.All | |
| Mail.Read | |
| Microsoft Graph API | Mail.Read |
| Mail.Read.Shared | |
| Mail.ReadWrite |
- 應用程式授與已登入使用者的完整使用者模擬。 例如：
| 資源 | 權限 |
|---|---|
| Microsoft Graph API | Directory.AccessAsUser.All |
| Azure REST API | user_impersonation |
若要避免發生這種情況，您應該參閱 Office 365 中的偵測和補救非法同意授與，以找出並修正具有非法授與的任何應用程式，或具有超過必要授與的應用程式。 接下來，完全移除自助服務並建立治理程序。 最後，安排定期檢閱應用程式的權限，並在不需要時將其移除。
有關同意授與的建議閱讀資料
使用者和群組設定
以下是在沒有明確的商務需求時，可以鎖定的使用者和群組設定：
使用者設定
- 外部使用者 - 使用 Teams、Power BI、Microsoft 365 中的 SharePoint 和 Azure 資訊保護等服務，就能在企業中發展外部共同作業。 如果您有明確的限制式來控制使用者起始的外部共同作業，建議您使用 Microsoft Entra 權利管理或受控制的作業 (例如透過技術支援中心) 來啟用外部使用者。 如果您不想允許服務的有機外部共同作業，可以完全封鎖成員邀請外部使用者。 您也可以允許或封鎖外部使用者邀請中的特定網域。
- 應用程式註冊 - 啟用應用程式註冊時，終端使用者可以將應用程式上線，並授與其資料的存取權。 應用程式註冊的典型範例，就是讓使用者啟用 Outlook 外掛程式，或使用 Alexa 和 Siri 等語音助理來代表他們閱讀電子郵件和行事曆，或傳送電子郵件。 如果客戶決定關閉應用程式註冊程序，InfoSec 和 IAM 小組必須介入例外狀況管理 (根據不同業務需求所需的應用程式註冊程序)，因為他們需要使用系統管理員帳戶來註冊應用程式，而且很可能需要設計流程，確保可順利執行程序。
- 管理入口網站 - 組織可以鎖定 Azure 入口網站中的 Microsoft Entra 刀鋒視窗，這樣非管理員就無法存取 Azure 入口網站中的 Microsoft Entra 管理，而且會感到困惑。 前往 Microsoft Entra 管理入口網站中的使用者設定，以限制存取權：
注意
非管理員仍可透過命令列和其他程式設計介面來存取 Microsoft Entra 管理介面。
群組設定
自助群組管理/使用者可以建立安全性群組/Microsoft 365 群組。 如果雲端中沒有適用於群組的現有自助方案，客戶可能會決定將其關閉，直到準備好使用這項功能為止。
有關群組的建議閱讀資料
- 什麼是 Microsoft Entra B2B 共同作業？
- 整合應用程式與 Microsoft Entra ID
- Microsoft Entra ID 中的應用程式、權限和同意。
- 使用群組來管理 Microsoft Entra ID 中的資源存取權
- 在 Microsoft Entra ID 中設定自助式服務應用程式存取管理
來自非預期位置的流量
攻擊者來自世界各地每一個角落。 使用條件式存取原則並搭配位置作為條件來管理此風險。 條件式存取原則的位置條件可讓您封鎖來自沒有業務需求之登入位置的存取權。
可以的話，請使用安全性資訊與事件管理 (SIEM) 解決方案來分析和尋找跨區域的存取模式。 如果您未使用 SIEM 產品，或未從 Microsoft Entra ID 內嵌驗證資訊，建議您使用 Azure 監視器來識別跨區域的存取模式。
存取使用情況
Microsoft Entra 記錄已封存，並與事件回應計畫整合
擁有 Microsoft Entra ID 登入活動、稽核和風險事件的存取權，對於疑難排解、使用情況分析和鑑識調查而言很重要。 Microsoft Entra ID 透過具有有限保留期間的 REST API 提供這些來源的存取權。 若要長期儲存稽核和提供長期的支援，安全性資訊與事件管理 (SIEM) 系統或同等的封存技術至關重要。 若要啟用 Microsoft Entra 記錄的長期儲存功能，您必須將記錄新增至現有的 SIEM 解決方案或使用 Azure 監視器。 將封存記錄，可用作為事件回應計畫和調查的一部分。
有關記錄的建議閱讀資料
- Microsoft Entra 稽核 API 參照
- Microsoft Entra 登入活動報告 API 參照
- 使用 Microsoft Entra 報告 API 搭配憑證來取得資料
- 適用於 Microsoft Entra ID Protection 的 Microsoft Graph
- Office 365 管理活動 API 參考
- 如何使用 Microsoft Entra ID Power BI 內容套件
摘要
安全的身分識別基礎結構共有 12 個層面。 這份清單將協助您進一步保護和管理認證、定義驗證體驗、委派指派、測量使用量，以及根據企業安全性態勢來定義存取原則。
- 指派各項重要工作的擁有者。
- 實作解決方案來偵測弱式或外洩密碼、改善密碼管理和保護措施，以及進一步保護使用者對資源的存取權。
- 您可以管理裝置的身分識別，以隨時隨地保護您的資源。
- 實作無密碼驗證。
- 在整個組織提供標準化的單一登入機制。
- 將應用程式從 AD FS 移轉至 Microsoft Entra ID，以提供更妥善的安全性和更一致的管理作業。
- 使用群組將使用者指派給應用程式，以提供更大的彈性和大規模管理的能力。
- 設定風險型存取原則。
- 封鎖舊版驗證通訊協定。
- 偵測並補救非法同意授與。
- 鎖定使用者和群組設定。
- 啟用 Microsoft Entra 記錄的長期儲存功能，以進行疑難排解、使用情況分析和鑑識調查。
下一步
開始進行身分識別治理的作業檢查和動作。