次の方法で共有

Microsoft Defender for Office 365に移行する - フェーズ 2: セットアップ


フェーズ 1: 準備します。
フェーズ 1: 準備		 フェーズ 2: セットアップ。
フェーズ 2: 設定		 フェーズ 3: オンボード。
フェーズ 3: オンボード
あなたはここにいます!

フェーズ 2:Microsoft Defender for Office 365への移行のセットアップへようこそ。 この移行フェーズには、次の手順が含まれます。

  1. パイロット ユーザーのCreate配布グループ
  2. ユーザーが報告したメッセージ設定を構成する
  3. SCL=-1 メール フロー ルールを維持または作成する
  4. コネクタの拡張フィルター処理を構成する
  5. パイロット保護ポリシーのCreate

手順 1: パイロット ユーザーの配布グループをCreateする

移行の次の側面については、Microsoft 365 で配布グループが必要です。

  • SCL=-1 メール フロー ルールの例外: パイロット ユーザーがDefender for Office 365保護の完全な効果を得るようにするため、受信メッセージをスキャンDefender for Office 365必要があります。 この結果を得るには、Microsoft 365 の適切な配布グループでパイロット ユーザーを定義し、これらのグループを SCL=-1 メール フロー ルールの例外として構成します。

    「オンボード 手順 2: (省略可能)既存の保護サービスによるフィルター処理からパイロット ユーザーを除外する」で説明したように、これらの同じパイロット ユーザーが既存の保護サービスによるスキャンを除外することを検討する必要があります。 既存の保護サービスによるフィルター処理の可能性を排除し、Defender for Office 365のみに依存することは、移行が完了した後に何が起こるかを最も適切かつ最も近く表現することです。

  • 特定のDefender for Office 365保護機能のテスト: パイロット ユーザーの場合でも、すべてを一度に有効にしたくありません。 パイロット ユーザーに有効な保護機能に段階的なアプローチを使用すると、トラブルシューティングと調整が簡単になります。 この方法を念頭に置いて、次の配布グループをお勧めします。

    • 安全な添付ファイルのパイロット グループ: たとえば、 MDOPilot_SafeAttachments
    • 安全なリンクのパイロット グループ: たとえば、 MDOPilot_SafeLinks
    • Standard スパム対策ポリシーとフィッシング対策ポリシー設定のパイロット グループ: たとえば、 MDOPilot_SpamPhish_Standard
    • 厳密なスパム対策ポリシーとフィッシング対策ポリシー設定のパイロット グループ: たとえば、 MDOPilot_SpamPhish_Strict

わかりやすくするために、この記事全体でこれらの特定のグループ名を使用しますが、独自の名前付け規則を自由に使用できます。

テストを開始する準備ができたら、これらのグループを 例外として SCL=-1 メール フロー ルールに追加します。 Defender for Office 365のさまざまな保護機能のポリシーを作成するときは、ポリシーが適用されるユーザーを定義する条件としてこれらのグループを使用します。

注:

  • Standard と Strict という用語は、 推奨されるセキュリティ設定に由来します。これは、 事前設定されたセキュリティ ポリシーでも使用されます。 理想的には、Standard および Strict の事前設定されたセキュリティ ポリシーでパイロット ユーザーを定義するように指示しますが、これを行うことはできません。 どうしてでしょうか? 事前設定されたセキュリティ ポリシー (特にメッセージに対して実行されるアクション) の設定をカスタマイズできないためです。 移行テスト中に、メッセージにDefender for Office 365が何を行うかを確認し、それが目的の結果であることを確認し、ポリシー構成を調整して、それらの結果を許可または禁止する場合があります。

    そのため、事前設定されたセキュリティ ポリシーを使用する代わりに、似た設定を使用してカスタム ポリシーを手動で作成しますが、場合によっては、Standard と Strict のプリセット セキュリティ ポリシーの設定とは異なる場合があります。

  • Standard または Strict の推奨値とは 大きく 異なる設定を試す場合は、これらのシナリオでパイロット ユーザー用の追加および特定の配布グループを作成して使用することを検討する必要があります。 Configuration Analyzer を使用して、設定のセキュリティを確認できます。 手順については、「EOP とMicrosoft Defender for Office 365の保護ポリシーの構成アナライザー」を参照してください。

    ほとんどの組織にとって、推奨される Standard 設定と密接に一致するポリシーから始めるのが最善の方法です。 利用可能な時間枠で行うことができる限り多くの観察とフィードバックの後で、後でより積極的な設定に移動できます。 偽装保護と迷惑メール Email フォルダーへの配信と検疫への配信には、カスタマイズが必要になる場合があります。

    カスタマイズしたポリシーを使用する場合は、移行の推奨設定が含まれているポリシーの 前に 適用されていることを確認してください。 ユーザーが同じ種類の複数のポリシー (フィッシング対策など) で識別された場合は、その種類のポリシーが 1 つだけユーザーに適用されます (ポリシーの優先順位の値に基づいて)。 詳細については、「メール保護の順序と優先順位」を参照してください。

手順 2: ユーザーが報告したメッセージ設定を構成する

ユーザーがDefender for Office 365から誤検知または偽陰性を報告する機能は、移行の重要な部分です。

Exchange Onlineメールボックスを指定して、ユーザーが悪意があると報告するメッセージを受信できます。 手順については、「 ユーザーが報告した設定」を参照してください。 このメールボックスは、ユーザーが Microsoft に送信したメッセージのコピーを受け取ることができます。または、メールボックスは Microsoft に報告せずにメッセージを傍受できます (セキュリティ チームは、メッセージを手動で分析して送信できます)。 ただし、インターセプト アプローチでは、サービスが自動的に調整および学習することはできません。

また、パイロットのすべてのユーザーが、Defender for Office 365から誤った判定を受けたメッセージを報告するサポートされている方法があることを確認する必要があります。 これらのオプションには以下のものがあります。

この手順の重要性を過小評価しないでください。 ユーザーから報告されたメッセージからのデータは、移行の前後に一貫性のある優れたエンド ユーザー エクスペリエンスを確認するために必要なフィードバック ループを提供します。 このフィードバックは、情報に基づいたポリシー構成の決定を行い、移行がスムーズに進んだデータに基づくレポートを管理に提供するのに役立ちます。

organization全体のエクスペリエンスに基づくデータに依存する代わりに、複数の移行によって、1 つの否定的なユーザー エクスペリエンスに基づいて感情的な推測が生じます。 さらに、フィッシング シミュレーションを実行している場合は、ユーザーからのフィードバックを使用して、調査が必要になる可能性のあるリスクが発生した場合に通知することができます。

手順 3: SCL=-1 メール フロー ルールを維持または作成する

受信メールは Microsoft 365 の前にある別の保護サービスを介してルーティングされるため、すべての受信メールのスパム信頼レベル (SCL) を値 -1 に設定するメール フロー ルール (トランスポート ルールとも呼ばれます) がExchange Onlineに既にある可能性があります (スパム フィルター処理をバイパスします)。 ほとんどのサード パーティの保護サービスは、サービスを使用する Microsoft 365 のお客様に対して、この SCL=-1 メール フロー ルールを推奨しています。

他のメカニズムを使用して Microsoft フィルタリング スタック (IP 許可リストなど) をオーバーライドする場合は、Microsoft 365 へのすべての受信 インターネット メールがサード パーティの保護サービスから送信される限り、SCL=-1 メール フロー ルールの使用に切り替えることをお勧めします (インターネットから Microsoft 365 への直接のメール フローはありません)。

SCL=-1 メール フロー ルールは、次の理由から移行中に重要です。

  • Threat エクスプローラー (エクスプローラー) を使用すると、既存の保護サービスの結果に影響を与えずに、Microsoft スタックのどの機能がメッセージに対して動作していたかを確認できます。

  • SCL=-1 メール フロー ルールに対する例外を構成することで、Microsoft 365 フィルタリング スタックによって保護されるユーザーを徐々に調整できます。 例外は、この記事の後半で推奨するパイロット配布グループのメンバーです。

    MX レコードを Microsoft 365 に切り替える前または間に、このルールを無効にして、organization内のすべての受信者に対して Microsoft 365 保護スタックの完全な保護を有効にします。

詳細については、「メール フロー ルールを使用して、Exchange Onlineのメッセージでスパム信頼レベル (SCL) を設定する」を参照してください。

注:

  • インターネット メールが既存の保護サービスを経由 して Microsoft 365 に直接同時に送信されるように計画している場合は、SCL=-1 メール フロー ルール (スパム フィルターをバイパスするメール) を、既存の保護サービスのみを経由するメールに制限する必要があります。 Microsoft 365 のユーザー メールボックスにフィルター処理されていないインターネット メールのランディングは必要ありません。

    既存の保護サービスによって既にスキャンされているメールを正しく識別するには、SCL=-1 メール フロー ルールに条件を追加します。 以下に例を示します。

    • クラウドベースの保護サービスの場合: organizationに固有のヘッダーとヘッダー値を使用できます。 ヘッダーを持つメッセージは、Microsoft 365 によってスキャンされません。 ヘッダーのないメッセージは Microsoft 365 によってスキャンされます
    • オンプレミスの保護サービスまたはデバイスの場合: ソース IP アドレスを使用できます。 ソース IP アドレスからのメッセージは、Microsoft 365 によってスキャンされません。 ソース IP アドレスからのメッセージは、Microsoft 365 によってスキャンされます。

  • メールがフィルター処理されるかどうかを制御するために MX レコードのみに依存しないでください。 送信者は MX レコードを簡単に無視し、Microsoft 365 に直接メールを送信できます。

手順 4: コネクタの拡張フィルター処理を構成する

最初に、既存の保護サービスから Microsoft 365 へのメール フローに使用される コネクタの拡張フィルター処理 ( リストのスキップとも呼ばれます) を構成します。 [受信メッセージ] レポートを使用すると、コネクタの識別に役立ちます。

コネクタの拡張フィルター処理は、インターネット メッセージが実際にどこから送信されたのかを確認するために、Defender for Office 365によって必要になります。 コネクタのフィルター処理の強化により、Microsoft フィルタリング スタックの精度が大幅に向上します (特に、脅威エクスプローラーと自動調査 & 応答 (AIR) のスプーフィング インテリジェンス、侵害後機能)。

コネクタの拡張フィルター処理を正しく有効にするには、受信メールを Microsoft 365 にルーティングする **all** サードパーティサービスやオンプレミスのメール システム ホストのパブリック IP アドレスを追加する必要があります。

コネクタの拡張フィルター処理が機能していることを確認するには、受信メッセージに次のヘッダーの一方または両方が含まれていることを確認します。

  • X-MS-Exchange-SkipListedInternetSender
  • X-MS-Exchange-ExternalOriginalInternetSender

手順 5: パイロット保護ポリシーをCreateする

運用ポリシーを作成することで、すべてのユーザーに適用されていない場合でも、脅威エクスプローラーなどの侵害後の機能をテストし、Defender for Office 365をセキュリティ対応チームのプロセスに統合することをテストできます。

重要

ポリシーのスコープは、ユーザー、グループ、またはドメインに設定できます。 3 つのポリシーすべてに一致するユーザーのみがポリシーのスコープに含まれるため、1 つのポリシーに 3 つすべてを混在することはお勧めしません。 パイロット ポリシーの場合は、グループまたはユーザーを使用することをお勧めします。 運用ポリシーの場合は、ドメインを使用することをお勧めします。 ユーザーがポリシーのスコープ内に入るかどうかを判断するのは、ユーザーのプライマリ 電子メール ドメイン だけ であることを理解することが非常に重要です。 そのため、ユーザーのセカンダリ ドメインの MX レコードを切り替える場合は、プライマリ ドメインもポリシーでカバーされていることを確認します。

Createパイロットの安全な添付ファイル ポリシー

安全な添付ファイルは、MX レコードを切り替える前に有効にしてテストする最も簡単なDefender for Office 365機能です。 安全な添付ファイルには、次の利点があります。

  • 最小限の構成。
  • 誤検知の可能性が非常に低い。
  • マルウェア対策保護と同様の動作。これは常にオンであり、SCL=-1 メール フロー ルールの影響を受けません。

推奨される設定については、「 推奨される安全な添付ファイルのポリシー設定」を参照してください。 Standard と Strict の推奨事項は同じです。 ポリシーを作成するには、「 安全な添付ファイル ポリシーを設定する」を参照してください。 ポリシーの条件 (ポリシーが適用されるユーザー) として、グループ MDOPilot_SafeAttachments を使用してください。

注:

組み込みの保護プリセットセキュリティ ポリシーは、安全な添付ファイル ポリシーで定義されていないすべての受信者に安全な添付ファイルの保護を提供します。 詳しくは、「EOP と Microsoft Defender for Office 365 の事前設定されたセキュリティ ポリシー」を参照してください。

注:

既にラップまたは書き換えられたリンクのラップや書き換えはサポートされていません。 現在の保護サービスが既にメール メッセージ内のリンクをラップまたは書き換える場合は、パイロット ユーザーに対してこの機能をオフにする必要があります。 これが発生しないようにする 1 つの方法は、安全なリンク ポリシーで他のサービスの URL ドメインを除外することです。

安全なリンクの誤検知の可能性も非常に低いですが、安全な添付ファイルよりもパイロット ユーザーの数が少ない場合に、この機能をテストすることを検討する必要があります。 この機能はユーザー エクスペリエンスに影響するため、ユーザーを教育する計画を検討する必要があります。

推奨される設定については、「 安全なリンクのポリシー設定」を参照してください。 Standard と Strict の推奨事項は同じです。 ポリシーを作成するには、「 安全なリンク ポリシーを設定する」を参照してください。 ポリシーの条件として MDOPilot_SafeLinks グループ (ポリシーが適用されるユーザー) を使用してください。

注:

組み込みの保護プリセットセキュリティ ポリシーは、安全なリンク ポリシーで定義されていないすべての受信者に安全なリンク保護を提供します。 詳しくは、「EOP と Microsoft Defender for Office 365 の事前設定されたセキュリティ ポリシー」を参照してください。

パイロットスパム対策ポリシーのCreate

パイロット ユーザー向けの 2 つのスパム対策ポリシーをCreateします。

  • 標準設定を使用するポリシー。 ポリシーの条件として MDOPilot_SpamPhish_Standard グループを使用します (ポリシーが適用されるユーザー)。
  • 厳密な設定を使用するポリシー。 ポリシーの条件 (ポリシーが適用されるユーザー) として、グループ MDOPilot_SpamPhish_Strictを使用します。 このポリシーは、標準設定のポリシーよりも優先度が高い (数値が小さい) 必要があります。

推奨される Standard と Strict の設定については、「 推奨されるスパム対策ポリシー設定」を参照してください。 ポリシーを作成するには、「 スパム対策ポリシーを構成する」を参照してください。

パイロットフィッシング対策ポリシーのCreate

パイロット ユーザー向けの 2 つのフィッシング対策ポリシーをCreateします。

  • 次に説明するように偽装検出アクションを除き、Standard 設定を使用するポリシー。 ポリシーの条件として MDOPilot_SpamPhish_Standard グループを使用します (ポリシーが適用されるユーザー)。
  • 以下で説明するように偽装検出アクションを除き、厳密な設定を使用するポリシー。 ポリシーの条件 (ポリシーが適用されるユーザー) として、グループ MDOPilot_SpamPhish_Strictを使用します。 このポリシーは、標準設定のポリシーよりも優先度が高い (数値が小さい) 必要があります。

スプーフィング検出の場合、推奨される Standard アクションは [受信者の迷惑メール Email フォルダーにメッセージを移動する] で、推奨される [厳格なアクション] は [メッセージの検疫] です。 スプーフィング インテリジェンスの分析情報を使用して結果を確認します。 オーバーライドについては、次のセクションで説明します。 詳細については、「EOP でのスプーフィング インテリジェンス分析」を参照してください。

偽装検出の場合は、パイロット ポリシーに対して推奨される Standard アクションと Strict アクションを無視します。 代わりに、[次の設定に 対してアクションを適用しない ] の値を使用します。

  • ユーザー偽装としてメッセージが検出された場合
  • 偽装ドメインとしてメッセージが検出された場合
  • メールボックス インテリジェンスが偽装ユーザーを検出した場合

偽装分析情報を使用して結果を確認します。 詳細については、「Defender for Office 365の偽装分析情報」を参照してください。

なりすまし保護の調整 (許可とブロックの調整) を行い、権限借用保護の各アクションをオンにして、メッセージを検疫するか、迷惑メール Email フォルダーに移動します (Standard または Strict の推奨事項に基づく)。 結果を確認し、必要に応じて設定を調整します。

詳細については、次の記事を参照してください。

次の手順

おめでとうございます。 Microsoft Defender for Office 365への移行のセットアップ フェーズが完了しました。