Microsoft Defender for Office 365への移行 - フェーズ 3: オンボード
フェーズ 1: 準備 |
フェーズ 2: 設定 |
フェーズ 3: オンボード |
|---|---|---|
| あなたはここにいます! |
フェーズ 3:Microsoft Defender for Office 365への移行のオンボードへようこそ。 この移行フェーズには、次の手順が含まれます。
- Security Teams のオンボードを開始する
- (省略可能)既存の保護サービスによるフィルター処理からパイロット ユーザーを除外する
- スプーフィング インテリジェンスを調整する
- 偽装保護とメールボックス インテリジェンスを調整する
- ユーザーが報告したメッセージのデータを使用して測定および調整する
- (省略可能)パイロットにさらにユーザーを追加し、反復する
- Microsoft 365 保護をすべてのユーザーに拡張し、SCL=-1 メール フロー ルールをオフにする
- MX レコードを切り替える
手順 1: Security Teams のオンボードを開始する
organizationにセキュリティ対応チームがある場合は、チケットシステムを含むMicrosoft Defender for Office 365を応答プロセスに統合する必要があります。 このプロセス自体はトピック全体ですが、見落とされることがあります。 セキュリティ対応チームを早期に関与させると、MX レコードを切り替えるときにorganizationが脅威に対処する準備が整います。 インシデント対応は、次のタスクを処理するために十分に装備されている必要があります。
- 新しいツールを学習し、既存のフローに統合します。 以下に例を示します。
- 検疫されたメッセージの管理管理が重要です。 手順については、「 検疫されたメッセージとファイルを管理者として管理する」を参照してください。
- メッセージ トレースを使用すると、メッセージが Microsoft 365 に入ったり、Microsoft 365 から退出したりするときに、メッセージに何が起こったかを確認できます。 詳細については、「Exchange Onlineの最新の Exchange 管理センターのメッセージ トレース」を参照してください。
- organizationに取り込まれた可能性のあるリスクを特定します。
- 組織のプロセス に関するアラートを 調整およびカスタマイズします。
- インシデント キューを管理し、潜在的なリスクを修復します。
organizationプラン 2 Microsoft Defender for Office 365購入した場合は、脅威エクスプローラー、高度なハンティング、インシデントなどの機能について理解し、使用する必要があります。 関連するトレーニングについては、 を参照してください https://aka.ms/mdoninja。
セキュリティ応答チームがフィルター処理されていないメッセージを収集して分析する場合は、これらのフィルター処理されていないメッセージを受信するように SecOps メールボックスを構成できます。 手順については、「 高度な配信ポリシーで SecOps メールボックスを構成する」を参照してください。
SIEM/SOAR
SIEM/SOAR との統合の詳細については、次の記事を参照してください。
organizationにセキュリティ対応チームや既存のプロセス フローがない場合は、この時間を使用して、Defender for Office 365の基本的なハンティング機能と応答機能について理解することができます。 詳細については、「 脅威の調査と対応」を参照してください。
RBAC ロール
Defender for Office 365のアクセス許可はロールベースのアクセス制御 (RBAC) に基づいており、Microsoft Defender ポータルのアクセス許可で説明されています。 留意すべき重要なポイントを次に示します。
- Microsoft Entraロールは、Microsoft 365 のすべてのワークロードにアクセス許可を付与します。 たとえば、Azure portalのセキュリティ管理者にユーザーを追加した場合、セキュリティ管理者はどこでもアクセス許可を持ちます。
- Microsoft Defender ポータルでコラボレーション ロールをEmail &すると、Microsoft Defender ポータルとMicrosoft Purview コンプライアンス ポータルにアクセス許可が付与されます。 たとえば、Microsoft Defender ポータルでセキュリティ管理者にユーザーを追加すると、Microsoft Defender ポータルとMicrosoft Purview コンプライアンス ポータルでのみセキュリティ管理者アクセス権が付与されます。
- Microsoft Defender ポータルの多くの機能は、Exchange Online PowerShell コマンドレットに基づいているため、対応するExchange Online PowerShell にアクセスするには、Exchange Onlineの対応するロール (技術的にはロール グループ) のロール グループ メンバーシップが必要ですコマンドレット)。
- Microsoft Defender ポータルには、Microsoft Entraロールと同等のEmail &コラボレーション ロールがあり、セキュリティ操作 (プレビュー ロール、Searchロール、消去ロールなど) に重要です。
通常、セキュリティ担当者のサブセットのみが、ユーザー メールボックスから直接メッセージをダウンロードするための追加権限を必要とします。 これには、セキュリティ 閲覧者が既定で持っていない追加のアクセス許可が必要です。
手順 2: (省略可能) パイロット ユーザーが既存の保護サービスによるフィルター処理を除外する
この手順は必要ありませんが、既存の保護サービスによるフィルター処理をバイパスするようにパイロット ユーザーを構成することを検討する必要があります。 このアクションにより、Defender for Office 365はパイロット ユーザーのすべてのフィルター処理と保護の義務を処理できます。 パイロット ユーザーを既存の保護サービスから除外しない場合、Defender for Office 365は、他のサービスからのミス (既にフィルター処理されたメッセージのフィルター処理) でのみ効果的に動作します。
注:
現在の保護サービスでリンク ラッピングが提供されているが、安全なリンク機能をパイロットする場合は、この手順が明示的に必要です。 リンクの二重折り返しはサポートされていません。
手順 3: スプーフィング インテリジェンスを調整する
なりすましインテリジェンスの分析情報を確認して、スプーフィングとして許可またはブロックされている内容を確認し、スプーフィングのシステム評決をオーバーライドする必要があるかどうかを判断します。 ビジネスクリティカルなメールの一部のソースでは、DNS (SPF、DKIM、DMARC) で電子メール認証レコードが正しく構成されていない可能性があり、既存の保護サービスでオーバーライドを使用してドメインの問題をマスクしている可能性があります。
スプーフィング インテリジェンスは、DNS で適切な電子メール認証レコードなしでドメインからメールを救済できますが、この機能では、適切なスプーフィングと不適切なスプーフィングを区別するための支援が必要な場合があります。 次の種類のメッセージ ソースに焦点を当てます。
- コネクタの拡張フィルター処理で定義されている IP アドレス範囲の外部にあるメッセージ ソース。
- メッセージの数が最も多いメッセージ ソース。
- organizationに最も影響を与えるメッセージ ソース。
スプーフィング インテリジェンスは、ユーザーが報告した設定を構成した後に最終的に調整されるため、完成度は必要ありません。
手順 4: 偽装保護とメールボックス インテリジェンスを調整する
[アクション モードを適用しない] で偽装保護の結果を確認するのに十分な時間が経過したら、フィッシング対策ポリシーで各偽装保護アクションを個別に有効にすることができます。
- ユーザー偽装保護: Standard と Strict の両方のメッセージを検疫 します。
- ドメイン偽装保護: Standard と Strict の両方のメッセージを検疫 します。
- メールボックス インテリジェンス保護: Standard の受信者の迷惑メール Email フォルダーにメッセージを移動します。Strict のメッセージを検疫します。
メッセージを処理せずに偽装保護の結果を監視する時間が長いほど、必要になる可能性のある許可またはブロックを識別する必要があるデータが増えます。 観察と調整を可能にするために十分に重要な各保護をオンにするまでの遅延を使用することを検討してください。
注:
これらの保護を頻繁かつ継続的に監視および調整することが重要です。 誤検知が疑われる場合は、原因を調査し、必要に応じてのみオーバーライドを使用し、必要な検出機能に対してのみオーバーライドを使用します。
メールボックス インテリジェンスを調整する
メールボックス インテリジェンスは、 偽装試行と判断されたメッセージに対してアクションを実行するように構成されていますが、パイロット ユーザーの電子メールの送受信パターンをオンにして学習します。 外部ユーザーがパイロット ユーザーの 1 人と接触している場合、その外部ユーザーからのメッセージはメールボックス インテリジェンスによる偽装試行として識別されません (したがって、誤検知を減らします)。
準備ができたら、次の手順を実行して、偽装試行として検出されたメッセージに対してメールボックス インテリジェンスが動作できるようにします。
[標準保護] 設定のフィッシング対策ポリシーで、[メールボックス インテリジェンスが偽装されたユーザーを検出した場合] の値を [受信者の迷惑メール Email フォルダーに移動する] に変更します。
[厳密な保護] 設定のフィッシング対策ポリシーで、[ メールボックス インテリジェンスがユーザーを検出して偽装した場合 ] の値を [ メッセージの検疫] に変更します。
ポリシーを変更するには、「Defender for Office 365でフィッシング対策ポリシーを構成する」を参照してください。
結果を観察し、調整を行った後、次のセクションに進み、ユーザー偽装によって検出されたメッセージを検疫します。
ユーザー偽装保護を調整する
Standard と Strict の両方の設定に基づくフィッシング対策ポリシーで、[ メッセージがユーザー偽装として検出された場合 ] の値を [ メッセージの検疫] に変更します。
偽装の 分析情報 を確認して、ユーザー偽装の試行でブロックされている内容を確認します。
ポリシーを変更するには、「Defender for Office 365でフィッシング対策ポリシーを構成する」を参照してください。
結果を確認し、調整を行った後、次のセクションに進み、ドメイン偽装によって検出されたメッセージを検疫します。
ドメイン偽装保護を調整する
Standard 設定と Strict 設定に基づくフィッシング対策ポリシーの両方で、[ メッセージがドメイン偽装として検出された場合 ] の値を [ メッセージの検疫] に変更します。
偽装の分析情報を確認して、ドメイン偽装試行としてブロックされている内容を確認します。
ポリシーを変更するには、「Defender for Office 365でフィッシング対策ポリシーを構成する」を参照してください。
結果を確認し、必要に応じて調整を行います。
手順 5: ユーザーが報告したメッセージのデータを使用して測定および調整する
パイロット ユーザーが誤検知と偽陰性を報告すると、Microsoft Defender ポータルの [申請] ページの [ユーザー報告] タブにメッセージが表示されます。 誤ったメッセージを Microsoft に報告して分析し、その情報を使用して、必要に応じてパイロット ポリシーの設定と例外を調整できます。
次の機能を使用して、Defender for Office 365の保護設定を監視および反復処理します。
organizationがユーザーから報告されたメッセージにサードパーティサービスを使用している場合は、そのデータをフィードバック ループに統合できます。
手順 6: (省略可能) パイロットにユーザーを追加し、反復処理する
問題を見つけて修正すると、さらにユーザーをパイロット グループに追加できます (それに応じて、これらの新しいパイロット ユーザーが既存の保護サービスによるスキャンから除外されます)。 今行うテストが多いほど、後で対処する必要があるユーザーの問題が少なくなります。 この "ウォーターフォール" アプローチにより、organizationの大部分に対してチューニングが可能になり、セキュリティ チームは新しいツールとプロセスに合わせて調整する時間が得られます。
Microsoft 365 は、組織のポリシーによって高信頼のフィッシング メッセージが許可されている場合にアラートを生成します。 これらのメッセージを識別するには、次のオプションがあります。
- 脅威保護の状態レポートでオーバーライドします。
- Threat エクスプローラーでフィルター処理して、メッセージを識別します。
- 詳細ハンティングでフィルター処理して、メッセージを識別します。
管理者の申請を通じて、できるだけ早く Microsoft に誤検知を報告し、テナント許可/ブロック リスト機能を使用して、これらの誤検知の安全なオーバーライドを構成します。
また、不要なオーバーライドを調べることもお勧めします。 言い換えると、Microsoft 365 がメッセージに対して提供したであろう評決を見てください。 Microsoft 365 が正しい評決をレンダリングした場合、オーバーライドの必要性は大幅に減少または排除されます。
手順 7: Microsoft 365 保護をすべてのユーザーに拡張し、SCL=-1 メール フロー ルールをオフにする
MX レコードを Microsoft 365 を指すように切り替える準備ができたら、このセクションの手順を実行します。
パイロット ポリシーをorganization全体に拡張します。 基本的には、ポリシーを拡張するさまざまな方法があります。
事前設定されたセキュリティ ポリシーを使用し、Standard 保護プロファイルと厳格な保護プロファイルの間でユーザーを分割します (全員が対象になっていることを確認してください)。 事前設定されたセキュリティ ポリシーは、作成したカスタム ポリシーまたは既定のポリシーの前に適用されます。 個々のパイロット ポリシーは削除せずにオフにすることができます。
セキュリティ ポリシーを事前設定する場合の欠点は、作成後に重要な設定の多くを変更できないことです。
パイロット中に作成および調整したポリシーのスコープを変更して、すべてのユーザー (たとえば、すべてのドメインのすべての受信者) を含めます。 同じ種類の複数のポリシー (フィッシング対策ポリシーなど) が同じユーザー (個別に、グループ メンバーシップ、または電子メール ドメインによって) に適用される場合は、優先度が最も高い (最も優先度の低い番号) ポリシーの設定のみが適用され、その種類のポリシーの処理が停止されることに注意してください。
SCL=-1 メール フロー ルールをオフにします (削除せずにオフにすることができます)。
以前の変更が有効になったことと、すべてのユーザーに対してDefender for Office 365が適切に有効になっていることを確認します。 この時点で、Defender for Office 365のすべての保護機能は、すべての受信者のメールに対して処理できるようになりましたが、そのメールは既存の保護サービスによって既にスキャンされています。
この段階で一時停止すると、より大規模なデータの記録とチューニングを行うことができます。
手順 8: MX レコードを切り替える
注:
- ドメインの MX レコードを切り替えると、変更がインターネット全体に反映されるまでに最大 48 時間かかることがあります。
- より高速な応答と可能なロールバック (必要な場合) を有効にするには、DNS レコードの TTL 値を下げることをお勧めします。 切り替えが完了して検証された後、元の TTL 値に戻すことができます。
- 使用頻度の低いドメインの変更から始める必要があります。 大規模なドメインに移行する前に、一時停止と監視を行うことができます。 ただし、これを行った場合でも、セカンダリ SMTP ドメインはポリシー アプリケーションの前にプライマリ ドメインに解決されるため、すべてのユーザーとドメインがポリシーによってカバーされるようにする必要があります。
- 1 つのドメインに対して複数の MX レコードが技術的に機能するため、この記事のすべてのガイダンスに従っている場合は、分割ルーティングを使用できます。 具体的には、「 セットアップ 手順 3: SCL=-1 メール フロー ルールを維持または作成する」の説明に従って、SCL=-1 メール フロー ルールが既存の保護サービスを通過するメールにのみ適用されるように、ポリシーがすべてのユーザーに適用されていることを確認する必要があります。 ただし、この構成ではトラブルシューティングがはるかに困難になる動作が導入されるため、通常は特に長時間お勧めしません。
- MX レコードを切り替える前に、保護サービスから Microsoft 365 への受信コネクタで次の設定が有効になっていないことを確認します。 通常、コネクタには次の 1 つ以上の設定が構成されます。
- パートナーが Office 365 で認証するために使用する証明書のサブジェクト名がこのドメイン名と一致する必要があります (RestrictDomainsToCertificate)
- この IP アドレス範囲内から送信されていないメール メッセージを拒否 する (RestrictDomainsToIPAddresses) コネクタの種類が パートナー で、これらの設定のいずれかがオンになっている場合、MX レコードを切り替えた後、ドメインへのすべてのメール配信は失敗します。 続行する前に、これらの設定を無効にする必要があります。 コネクタがハイブリッドに使用されるオンプレミス コネクタの場合は、オンプレミス コネクタを変更する必要はありません。 ただし、パートナー コネクタの存在をチェックすることもできます。
- 現在のメール ゲートウェイでも受信者の検証が提供されている場合は、ドメインが Microsoft 365 で [権限あり] として構成されていることをチェックできます。 これにより、不要なバウンス メッセージを防ぐことができます。
準備ができたら、ドメインの MX レコードを切り替えます。 すべてのドメインを一度に移行できます。 または、使用頻度の低いドメインを最初に移行してから、後で残りのドメインを移行することもできます。
いつでもここで一時停止して評価してください。 ただし、SCL=-1 メール フロー ルールをオフにすると、ユーザーは誤検知をチェックするための 2 つの異なるエクスペリエンスを持つ可能性があります。 1 つの一貫性のあるエクスペリエンスを提供できる時間が早いほど、ユーザーとヘルプ デスク チームは、不足しているメッセージのトラブルシューティングを行う必要があるときに、より幸せになります。
次の手順
おめでとうございます! Microsoft Defender for Office 365への移行が完了しました。 この移行ガイドの手順に従ったので、メールが Microsoft 365 に直接配信される最初の数日は、はるかにスムーズになります。
次に、Defender for Office 365の通常の操作とメンテナンスを開始します。 パイロット中に発生した問題と似ていますが、大規模な問題を監視してwatchします。 なりすましインテリジェンス分析情報と偽装分析情報が最も役立ちますが、次のアクティビティを定期的に行うことを検討してください。
- ユーザーが報告したメッセージ、特に ユーザーが報告したフィッシング メッセージを確認する
- 脅威保護の状態レポートでオーバーライドを確認します。
- 高度なハンティング クエリを使用して、チューニングの機会と危険なメッセージを検索します。