Share via

移轉至 適用於 Office 365 的 Microsoft Defender - 階段 3：上線


階段 1：準備。
階段 1：準備		 階段 2：設定。
階段 2：設定		 階段 3：上線。
階段 3：上線
您在這裡！

歡迎使用階段 3：將移轉上線至 適用於 Office 365 的 Microsoft Defender！ 此移轉階段包含下列步驟：

  1. 開始讓安全性小組上線
  2. (選擇性) 讓試驗使用者不受現有保護服務篩選
  3. 調整詐騙情報
  4. 調整模擬保護和信箱智慧
  5. 使用來自使用者報告訊息的數據來測量和調整
  6. (選擇性) 將更多使用者新增至試驗並逐一查看
  7. 將 Microsoft 365 保護延伸至所有使用者，並關閉 SCL=-1 郵件流程規則
  8. 切換 MX 記錄

步驟 1：開始將安全性小組上線

如果您的組織有安全性回應小組，現在是開始將 適用於 Office 365 的 Microsoft Defender 整合到回應程式，包括票證系統的時間。 此程式本身是整個主題，但有時會被忽略。 提早讓安全性回應小組參與，可確保您的組織已準備好在切換 MX 記錄時處理威脅。 事件回應必須具備充分的功能，才能處理下列工作：

如果您的組織購買 適用於 Office 365 的 Microsoft Defender 方案 2，則應該開始熟悉並使用威脅總管、進階搜捕和事件等功能。 如需相關訓練，請參閱 https://aka.ms/mdoninja。

如果您的安全性回應小組收集並分析未篩選的郵件，您可以設定 SecOps 信箱來接收這些未篩選的郵件。 如需指示， 請參閱在進階傳遞原則中設定 SecOps 信箱。

SIEM/SOAR

如需與 SIEM/SOAR 整合的詳細資訊，請參閱下列文章：

如果您的組織沒有安全性回應小組或現有的程式流程，您可以使用此時間來熟悉 適用於 Office 365 的 Defender 中的基本搜捕和回應功能。 如需詳細資訊，請參閱 威脅調查和回應。

RBAC 角色

適用於 Office 365 的 Defender 中的許可權是以角色型訪問控制 (RBAC) 為基礎，並在 Microsoft Defender 入口網站的 [許可權] 中說明。 以下是要牢記在心的重點：

  • Microsoft Entra 角色會授與 Microsoft 365 中所有工作負載的許可權。 例如，如果您在 Azure 入口網站 中將使用者新增至安全性系統管理員，他們在任何地方都有安全性系統管理員許可權。
  • Microsoft Defender 入口網站中 Email & 共同作業角色會將許可權授與 Microsoft Defender 入口網站和 Microsoft Purview 合規性入口網站。 例如，如果您在 Microsoft Defender 入口網站中將使用者新增至安全性系統管理員，則他們只能在 Microsoft Defender 入口網站和 Microsoft Purview 合規性入口網站 中存取安全性系統管理員。
  • Microsoft Defender 入口網站中的許多功能都是以 Exchange Online PowerShell Cmdlet 為基礎，因此需要對應角色中的角色群組成員資格， (技術上來說，角色群組) Exchange Online (，才能存取對應的 Exchange OnlinePowerShell Cmdlet) 。
  • Microsoft Defender 入口網站中有 Email & 個共同作業角色，其不等於 Microsoft Entra 角色，而且對於安全性作業很重要 (例如預覽角色和 搜尋 和清除角色) 。

一般而言，只有一部分安全性人員需要額外的許可權，才能直接從使用者信箱下載郵件。 此需求需要安全性讀取器預設沒有的額外許可權。

步驟 2： (選擇性) 讓試驗使用者不受現有保護服務篩選

雖然不需要此步驟，但您應該考慮將試驗用戶設定為略過現有保護服務的篩選。 此動作可讓 適用於 Office 365 的 Defender 處理試驗使用者的所有篩選和保護責任。 如果您未豁免試驗使用者現有的保護服務，適用於 Office 365 的 Defender 只在其他服務遺漏時有效運作， (篩選已篩選) 的訊息。

注意事項

如果您目前的保護服務提供鏈接包裝，但您想要試驗安全連結功能，則明確需要此步驟。 不支援連結的雙重包裝。

步驟 3：調整詐騙情報

請檢查 詐騙情報深入解析 ，以查看允許或封鎖的詐騙專案，以及判斷是否需要覆寫系統決策以進行詐騙。 某些業務關鍵電子郵件來源在 DNS (SPF、DKIM 和 DMARC) 中可能設定錯誤的電子郵件驗證記錄，而且您可能在現有的保護服務中使用覆寫來遮罩其網域問題。

詐騙情報可以從網域中修復電子郵件，而不需要 DNS 中適當的電子郵件驗證記錄，但此功能有時需要協助來區別良好的詐騙與惡意詐騙。 專注於下列型態的訊息來源：

  • 在 [ 增強連接器篩選] 中定義的IP位址範圍之外的訊息來源。
  • 訊息來源的訊息數目最高。
  • 對組織影響最大的訊息來源。

在您設定用戶回報的設定之後，詐騙情報最終會自行調整，因此不需要使用預設值。

步驟 4：調整模擬保護和信箱智慧

在 [不要套用 任何動作 模式] 中有足夠的時間觀察模擬保護的結果之後，您可以個別開啟反網络釣魚原則中的每個模擬保護動作：

  • 用戶模擬保護：隔離標準和嚴格兩者的 訊息 。
  • 網域模擬保護： 隔離 Standard 和 Strict 的訊息。
  • 信箱智慧保護：將郵件移至收件者的垃圾郵件 Email資料夾，以用於標準;將郵件隔離為 Strict。

監視模擬保護結果的時間越長，而不對訊息採取動作，您必須識別的數據越多，就允許或封鎖可能需要的數據。 請考慮在開啟每個足以允許觀察和調整的保護之間使用延遲。

注意事項

經常且持續地監視和微調這些保護非常重要。 如果您懷疑為誤判，請調查原因，並只在必要時使用覆寫，只針對需要它的偵測功能使用覆寫。

調整信箱智慧

雖然信箱智慧已設定為不會對 判斷為模擬嘗試的郵件採取任何動作，但會開啟信箱智慧，並學習試驗用戶的電子郵件傳送和接收模式。 如果外部使用者與您的試驗用戶聯繫，信箱智慧不會將來自該外部使用者的郵件識別為模擬嘗試 (因而減少誤判) 。

當您準備好時，請執行下列步驟，以允許信箱智慧對偵測到模擬嘗試的郵件採取行動：

  • 在具有標準保護設定的反網路釣魚原則中，將 [如果信箱智慧偵測到仿真的使用者] 的值變更為 [將郵件移至收件者的垃圾郵件] Email 資料夾。

  • 在具有 [嚴格保護] 設定的反網络釣魚原則中，將 [ 如果信箱智慧偵測到並模擬使用者 ] 的值從 變更為 [隔離郵件]。

若要修改原則，請參閱在 適用於 Office 365 的 Defender 中設定防網路釣魚原則。

觀察到結果並進行任何調整之後，請繼續進行下一節，以隔離用戶模擬偵測到的訊息。

調整用戶模擬保護

在根據標準和嚴格設定的兩個防網路釣魚原則中，將 [ 如果在用戶模擬時偵測到訊息 ] 的值變更為 [隔離郵件]。

請檢查 模擬深入解析 ，以查看在用戶模擬嘗試時封鎖的專案。

若要修改原則，請參閱在 適用於 Office 365 的 Defender 中設定防網路釣魚原則。

觀察到結果並進行任何調整之後，請繼續進行下一節，以隔離網域模擬偵測到的訊息。

調整網域模擬保護

在根據標準和嚴格設定的兩個防網路釣魚原則中，將 [ 如果偵測到郵件為網域模擬 ] 的值變更為 [隔離郵件]。

請檢查 模擬深入解析 ，以查看在嘗試進行網域模擬時封鎖的內容。

若要修改原則，請參閱在 適用於 Office 365 的 Defender 中設定防網路釣魚原則。

觀察結果，並視需要進行任何調整。

步驟 5：使用來自使用者報告訊息的數據來測量和調整

當試驗用戶回報誤判和誤判時，訊息會出現在 Microsoft Defender 入口網站中 [提交] 頁面的 [用戶報告] 索引卷標上。 您可以將錯誤識別的訊息回報給 Microsoft 進行分析，並視需要使用資訊來調整試驗原則中的設定和例外狀況。

使用下列功能來監視和逐一查看 適用於 Office 365 的 Defender 中的保護設定：

如果您的組織針對用戶回報的訊息使用第三方服務，您可以將該數據整合到意見反應迴圈中。

步驟 6： (選擇性) 將更多使用者新增至試驗並逐一查看

當您找到並修正問題時，您可以將更多使用者新增至試驗群組 (，並根據適當的) ，免除現有保護服務掃描這些新的試驗使用者。 您現在執行的測試越多，稍後需要處理的用戶問題就越少。 這種「瀑布式」方法可讓您針對組織中的較大部分進行微調，並讓您的安全性小組有時間適應新的工具和程式。

  • 當組織原則允許高信賴度網路釣魚訊息時，Microsoft 365 會產生警示。 若要識別這些訊息，您有下列選項：

    透過系統 管理員提交，儘早向 Microsoft 回報任何誤判，並使用 租用戶允許/封鎖清單 功能來設定這些誤判的安全覆寫。

  • 檢查不必要的覆寫也是不錯的主意。 換句話說，請查看 Microsoft 365 對訊息所提供的決策。 如果 Microsoft 365 轉譯了正確的決策，則覆寫的需求會大幅降低或消除。

步驟 7：將 Microsoft 365 保護延伸至所有使用者，並關閉 SCL=-1 郵件流程規則

當您準備好切換 MX 記錄以指向 Microsoft 365 時，請執行本節中的步驟。

  1. 將試驗原則延伸至整個組織。 基本上，有不同的方式可以擴充原則：

    • 使用 預設的安全 策略，並將使用者分成標準保護配置檔和嚴格保護配置檔 (確定每個人都涵蓋在) 。 預設安全策略會在您建立的任何自定義原則或任何默認原則之前套用。 您可以關閉個別的試驗原則，而不需要刪除它們。

      預設安全策略的缺點是您無法在建立安全策略之後變更許多重要設定。

    • 變更您在試驗期間建立和調整的原則範圍，以包含所有使用者 (例如，所有網域中的所有收件者) 。 請記住，如果相同類型的多個原則 (例如，反網路釣魚原則) 個別套用至相同的使用者 (、依群組成員資格或電子郵件網域) ，則只會套用優先順序最高 (優先順序數位) 最低的原則設定，並針對該類型的原則套用處理停止。

  2. 關閉 SCL=-1 郵件流程規則 (您可以將它關閉，而不需要將它刪除) 。

  3. 確認先前的變更已生效，且所有用戶現在都已正確啟用 適用於 Office 365 的 Defender。 此時，適用於 Office 365 的 Defender 的所有保護功能現在都可對所有收件者的郵件採取行動，但您現有的保護服務已掃描該郵件。

您可以在這個階段暫停以進行更大規模的數據錄製和微調。

步驟 8：切換 MX 記錄

注意事項

  • 當您切換網域的 MX 記錄時，最多可能需要 48 小時，變更才會傳播到整個因特網。
  • 建議您降低 DNS 記錄的 TTL 值，以便在必要時) 更快的回應和可能的復原 (。 您可以在切換完成並驗證之後還原為原始 TTL 值。
  • 您應該考慮從變更較不常使用的網域開始。 您可以先暫停並監視，再移至較大的網域。 不過，即使您這麼做，仍應確定所有用戶和網域都受原則涵蓋，因為次要 SMTP 網域會在原則應用程式之前解析為主要網域。
  • 只要您已遵循本文中的所有指引，單一網域的多筆 MX 記錄在技術上可運作，可讓您進行分割路由。 具體來說，您應該確定原則已套用至所有使用者，SCL=-1 郵件流程規則只會套用至通過現有保護服務的郵件，如 安裝步驟 3：維護或建立 SCL=-1 郵件流程規則中所述。 不過，此設定會引進讓疑難解答更困難的行為，因此我們通常不建議這麼做，尤其是長時間。
  • 切換 MX 記錄之前，請確認從保護服務到 Microsoft 365 的輸入連接器上未啟用下列設定。 連接器通常會設定下列一或多個設定：
    • 並且要求合作夥伴用來向 Office 365 驗證之憑證上的主體名稱符合此域名 (RestrictDomainsToCertificate)
    • 如果電子郵件訊息不是從此IP位址範圍內傳送 ， (RestrictDomainsToIPAddresses) 如果連接器類型為 Partner 且其中一項設定已開啟，則在切換 MX 記錄之後，所有傳送到網域的郵件都會失敗。 您必須先停用這些設定，才能繼續進行。 如果連接器是用於混合式的內部部署連接器，您就不需要修改內部部署連接器。 但是，您仍然可以檢查 合作夥伴 連接器是否存在。
  • 如果您目前的郵件閘道也提供收件者驗證，您可能想要檢查網域是否已在 Microsoft 365 中設定為 授權 。 這可以防止不必要的退回訊息。

當您準備好時，請切換網域的 MX 記錄。 您可以一次移轉所有網域。 或者，您可以先移轉較不常使用的網域，然後稍後再移轉其餘的網域。

您可以隨時在這裡暫停並評估。 但請記住：關閉 SCL=-1 郵件流程規則之後，使用者可能會有兩種不同的檢查誤判體驗。 當您的使用者和技術支援人員小組必須針對遺漏的訊息進行疑難解答時，越快提供單一且一致的體驗。

後續步驟

恭喜您！ 您已完成移轉至 適用於 Office 365 的 Microsoft Defender！ 因為您已遵循本移轉指南中的步驟，所以直接將郵件傳遞至 Microsoft 365 的頭幾天應該會更順暢。

現在您已開始一般作業和維護 適用於 Office 365 的 Defender。 監視並 watch 與您在試驗期間所遇到但規模較大的問題。 詐騙 情報深入解析 和 模擬見解 最有用，但請考慮定期發生下列活動：