Microsoft Entra 驗證管理作業參考指南
Microsoft Entra 作業參考指南的這一節說明您應該採取的檢查和管理認證、定義驗證 （AuthN） 體驗、委派指派、測量使用方式，以及根據企業安全性狀態定義存取原則。
注意
這些建議是發佈時的最新資訊，但日後可能依情況修訂。 由於 Microsoft 的產品和服務會隨著時間演進，組織應持續評估其身分識別做法。
重要作業流程
指派各項重要工作的擁有者
管理 Microsoft Entra 識別碼需要持續執行重要的作業工作和程式，而這可能不屬於推出專案的一部分。 您仍然必須設定這些工作，以優化您的環境。 重要工作及其建議的擁有者包括：
| 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 Smart Lockout |
| 密碼原則會使用複雜度型規則，例如長度、多個字元集或到期日 | 請重新考慮 Microsoft 建議的做法 ，並將您的方法切換至密碼管理，並部署 Microsoft Entra 密碼保護。 |
| 用戶未註冊以使用多重要素驗證 | 註冊所有使用者的安全性資訊 ，使其可作為驗證使用者身分識別及其密碼的機制 |
| 不會根據用戶風險撤銷密碼 | 部署 Microsoft Entra Identity Protection 用戶風險原則 ，以使用 SSPR 強制變更外泄認證的密碼 |
| 沒有智慧鎖定機制可保護惡意驗證，防止來自已識別IP位址的不良動作專案 | 使用密碼哈希同步或 傳遞驗證部署雲端管理的驗證 （PTA） |
建議讀取密碼原則
啟用自助式密碼重設和密碼保護
需要變更或重設其密碼的用戶是技術支援中心通話數量和成本最大的來源之一。 除了成本之外，將密碼變更為降低用戶風險的工具，是改善組織安全性狀態的基本步驟。
建議您至少部署 Microsoft Entra ID 自助式密碼重設 （SSPR） 和內部部署 密碼保護 來完成：
- 轉移技術支援中心通話。
- 取代使用暫存密碼。
- 取代任何依賴內部部署解決方案的現有自助式密碼管理解決方案。
- 排除組織中的弱式密碼 。
注意
對於具有 Microsoft Entra ID P2 訂用帳戶的組織，建議部署 SSPR，並將其作為 Identity Protection 用戶風險原則的一部分。
強認證管理
密碼本身並不安全，無法防止不良執行者存取您的環境。 至少必須啟用具有特殊許可權帳戶的任何使用者，才能進行多重要素驗證。 在理想情況下，您應該啟用 合併註冊 ，並要求所有使用者使用 合併註冊體驗註冊多重要素驗證和 SSPR。 最後，我們建議您採用一種策略來提供復原能力，以減少因未預期的情況而造成鎖定的風險。
內部部署中斷驗證復原能力
除了簡單且啟用洩漏認證偵測的優點外，Microsoft Entra 密碼哈希同步處理 （PHS） 和 Microsoft Entra 多重要素驗證可讓使用者存取軟體即服務 （SaaS） 應用程式和 Microsoft 365，儘管因為 NotPetya 等網路攻擊而發生內部部署中斷。 您也可以在與同盟一起啟用 PHS。 啟用 PHS 可在無法使用同盟服務時，允許驗證的後援。
如果您的內部部署組織缺少中斷復原策略，或有未與 Microsoft Entra 識別元整合的復原策略，您應該部署 Microsoft Entra PHS，並定義包含 PHS 的災害復原計劃。 啟用 Microsoft Entra PHS 可讓使用者根據 Microsoft Entra 識別碼進行驗證，如果您的 內部部署的 Active Directory 無法使用。
若要進一步瞭解您的驗證選項，請參閱 為您的 Microsoft Entra 混合式身分識別解決方案選擇正確的驗證方法。
以程序設計方式使用認證
使用 PowerShell 的 Microsoft Entra ID 腳本或使用 Microsoft Graph API 的應用程式需要安全驗證。 執行這些腳本和工具的認證管理不佳會增加認證竊取的風險。 如果您使用依賴硬式編碼密碼或密碼的腳本或應用程式提示，您應該先檢閱組態檔或原始程式碼中的密碼，然後盡可能取代這些相依性，並使用 Azure 受控識別、整合式 Windows 驗證或 憑證 。 對於無法使用先前解決方案的應用程式，請考慮使用 Azure 金鑰保存庫。
如果您判斷有具有密碼認證的服務主體，且不確定這些密碼認證如何受到腳本或應用程式保護，請連絡應用程式的擁有者，以進一步瞭解使用模式。
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 來管理。 組織可以透過 PHS 或具有無縫 SSO 的 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 識別碼之密碼的世界。
應用程式驗證和指派
應用程式的單一登錄
為整個企業提供標準化的單一登錄機制，對於最佳用戶體驗、降低風險、報告和治理的能力至關重要。 如果您使用支援 SSO 的應用程式搭配 Microsoft Entra ID，但目前已設定為使用本機帳戶，您應該重新設定這些應用程式以搭配 Microsoft Entra ID 使用 SSO。 同樣地，如果您使用任何支援 SSO 的應用程式搭配 Microsoft Entra ID，但使用的是另一個識別提供者，則也應該重新設定這些應用程式以搭配 Microsoft Entra ID 使用 SSO。 對於不支援同盟通訊協定但支援窗體型驗證的應用程式，我們建議您將應用程式設定為搭配 Microsoft Entra 應用程式 Proxy 使用 密碼保存庫 。
注意
如果您沒有在組織中探索非受控應用程式的機制，建議您使用雲端應用程式安全性代理程式 （CASB） 實作探索程式，例如 適用於雲端的 Microsoft Defender Apps。
最後，如果您有 Microsoft Entra 應用連結庫，並使用支援 SSO 的應用程式搭配 Microsoft Entra ID，建議您 在應用連結庫中列出應用程式。
建議閱讀單一登錄
將AD FS 應用程式移轉至 Microsoft Entra 識別碼
將應用程式從 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 連線 Health 可用來收集可能移轉至 Microsoft Entra 識別碼之每個應用程式的設定詳細數據。
將使用者指派給應用程式
將使用者指派給應用程式 最適合使用群組來對應，因為它們能夠有更大的彈性和規模管理能力。 使用群組的優點包括 屬性型動態群組成員資格 ，以及 委派給應用程式擁有者。 因此，如果您已經使用和管理群組，建議您採取下列動作來大規模改善管理：
- 將群組管理和控管委派給應用程式擁有者。
- 允許對應用程式的自助式存取。
- 如果使用者屬性可以一致地判斷應用程式的存取權，請定義動態群組。
- 使用 Microsoft Entra 存取權檢閱，實作用於應用程式存取的群組證明。
另一方面，如果您發現有指派給個別使用者的應用程式，請務必針對這些應用程式實 作治理 。
將使用者指派給建議讀取的應用程式
- 在 Microsoft Entra ID 中將使用者和群組指派給應用程式
- 在 Microsoft Entra 識別碼中委派應用程式註冊許可權
- Microsoft Entra ID 中群組的動態成員資格規則
存取原則
具名位置
使用 Microsoft Entra 識別碼中的具名位置 ，您可以為組織中的受信任 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 Mobile。 此外，您可以建立條件式存取原則，以 限制從核准或相容的應用程式存取 Exchange Online 等雲端服務。
如果您的員工安裝支援 MAM 的應用程式，例如 Office 行動裝置應用程式，以存取 Microsoft 365 中的 Exchange Online 或 SharePoint 等公司資源，而且您也支援 BYOD（攜帶您自己的裝置），建議您部署應用程式 MAM 原則來管理沒有 MDM 註冊的個人擁有裝置中的應用程式組態，然後更新條件式存取原則，只允許從支援 MAM 的用戶端存取。
如果員工針對公司資源安裝具有 MAM 功能的應用程式，且受 Intune 管理的裝置上限制存取，則您應該考慮部署應用程式 MAM 原則來管理個人裝置的應用程式組態，並更新條件式存取原則以只允許從具有 MAM 功能的用戶端存取。
條件式存取實作
條件式存取是改善組織安全性狀態的重要工具。 因此，請務必遵循下列最佳做法：
- 確定所有 SaaS 應用程式都已套用至少一個原則
- 避免將 [所有應用程式 ] 篩選與 封鎖 控件結合，以避免鎖定風險
- 避免使用 [所有使用者 ] 做為篩選條件，並不小心新增 來賓
- 將所有「舊版」原則移轉至 Azure 入口網站
- 擷取使用者、裝置和應用程式的所有準則
- 使用條件式存取原則來 實作多重要素驗證，而不是使用 每個使用者的 MFA
- 有一組可套用至多個應用程式的核心原則
- 定義空的例外狀況群組，並將其新增至原則，以具有例外狀況策略
- 規劃不使用多重要素驗證控件的打破帳戶
- 確保 Microsoft 365 用戶端應用程式的一致體驗，例如 Teams、OneDrive、Outlook 等等。 在 Microsoft 365 中為 Exchange Online 和 SharePoint 等服務實作相同的控件集
- 指派原則應該透過群組實作，而不是個人
- 定期檢閱原則中使用的例外狀況群組，以限制使用者超出安全性狀態的時間。 如果您擁有 Microsoft Entra ID P2，則可以使用存取權檢閱將程式自動化
條件式存取建議讀取
存取介面區
舊版驗證
強式認證，例如多重要素驗證無法保護使用舊版驗證通訊協定的應用程式，這使得它成為惡意執行者慣用的攻擊媒介。 鎖定舊版驗證對於改善存取安全性狀態至關重要。
舊版驗證是指應用程式所使用的驗證通訊協定，例如：
- 不使用新式驗證的舊版 Office 用戶端（例如 Office 2010 用戶端）
- 使用因特網郵件存取通訊協定（IMAP）/簡易郵件傳輸通訊協定（SMTP）/存在點 （POP） 等郵件通訊協定的用戶端
攻擊者強烈偏好這些通訊協議-事實上，近 100% 的密碼噴洒攻擊 使用舊版驗證通訊協定！ 駭客會使用舊版驗證通訊協議，因為它們不支援互動式登錄，這在多重要素驗證和裝置驗證等其他安全性挑戰中是必要的。
如果您的環境中廣泛使用舊版驗證，您應該計劃儘快將舊版用戶端移轉至支援 新式驗證 的用戶端。 在相同的令牌中，如果您有一些用戶已經使用新式驗證，但其他仍使用舊版驗證的使用者，您應該採取下列步驟來鎖定舊版驗證用戶端：
使用 登入活動報告 來識別仍在使用舊版驗證和規劃補救的使用者：
升級至支援新式驗證的新式用戶端給受影響的使用者。
規劃完全移轉時間範圍，以鎖定下列步驟。
識別哪些舊版應用程式與舊版驗證有硬式相依性。 請參閱下面的步驟 3。
針對未使用舊版驗證的使用者停用來源的舊版通訊協定（例如 Exchange Mailbox），以避免暴露更多。
針對其餘帳戶（理想情況下非人為身分識別，例如服務帳戶），請使用 條件式存取來限制舊版通訊協定 的驗證后。
建議讀取舊版驗證
同意授與
在非法同意授與攻擊中，攻擊者會建立 Microsoft Entra 註冊的應用程式，要求存取連絡資訊、電子郵件或檔等數據。 當使用者登陸惡意網站時，可能會透過網路釣魚攻擊授與惡意應用程式的同意。
以下是您可能想要仔細檢查 Microsoft 雲端服務之權限的應用程式清單：
- 具有應用程式或委派的應用程式 *。ReadWrite 許可權
- 具有委派許可權的應用程式可以代表使用者讀取、傳送或管理電子郵件
- 使用下列權限授與的應用程式：
| 資源 | 權限 |
|---|---|
| Exchange Online | 大通。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 小組必須參與例外狀況的管理（根據商務需求所需的應用程式註冊），因為他們需要向系統管理員帳戶註冊應用程式，而且最可能需要設計程式才能讓程式運作。
- 管理員 istration Portal - 組織可以鎖定 Azure 入口網站 中的 Microsoft Entra 刀鋒視窗，讓非系統管理員無法存取 Azure 入口網站 中的 Microsoft Entra 管理，並感到困惑。 移至 Microsoft Entra 管理入口網站中的使用者設定，以限制存取：
注意
非系統管理員仍然可以透過命令行和其他程序設計介面存取 Microsoft Entra 管理介面。
群組設定
自助群組管理/使用者可以建立安全組/Microsoft 365 群組。 如果雲端中的群組目前沒有自助式方案，客戶可能會決定將其關閉，直到他們準備好使用這項功能為止。
建議閱讀的群組
- 什麼是 Microsoft Entra B2B 共同作業？
- 整合應用程式與 Microsoft Entra 識別碼
- Microsoft Entra 識別碼中的應用程式、許可權和同意。
- 使用群組來管理 Microsoft Entra 識別符中資源的存取權
- 在 Microsoft Entra ID 中設定自助式應用程式存取管理
來自非預期位置的流量
攻擊者來自世界各地。 使用具有位置作為條件的條件式存取原則來管理此風險。 條件 式存取原則的位置條件 可讓您封鎖從沒有商務理由登入的位置存取。
如果有的話，請使用安全性資訊和事件管理 （SIEM） 解決方案來分析及尋找跨區域存取的模式。 如果您未使用 SIEM 產品，或未從 Microsoft Entra ID 擷取驗證資訊，建議您使用 Azure 監視器 來識別跨區域的存取模式。
存取使用方式
Microsoft Entra 記錄已封存並與事件響應計劃整合
存取登入活動、Microsoft Entra 標識符的稽核和風險事件對於疑難解答、使用分析和鑑識調查至關重要。 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 記錄的長期記憶體，以進行疑難解答、使用分析和鑑識調查。
下一步
開始使用 身分識別治理作業檢查和動作。