Microsoft Defender for Office 365 のプリセットとカスタムのフィッシング対策ポリシー

By Mirko Peters · 2026-10-29

Microsoft Defender for Office 365 でプリセットとカスタムのフィッシング対策ポリシーをいつ使い分けるかを解説します。優先順位の落とし穴を避け、クラウド テナントを安全に保つ方法を紹介します。

Automatically translated with AI from the original post. Read the English original

Microsoft Defender for Office 365 でプリセット セキュリティ ポリシーとカスタム構成のどちらを選ぶかによって、組織が標的型フィッシング攻撃をどれだけ効果的に防げるかが決まります。このガイドでは、ポリシーの評価順序、見落としがちな優先順位の落とし穴、そして組み込みの Microsoft 推奨設定よりカスタム ルールが本当に必要となるケースを判断するための実践的な枠組みを解説します。

重要なポイント

• Microsoft は、メール保護ポリシーを厳密な上から下の順序で評価します。Strict プリセット、Standard プリセット、カスタム ポリシー、最後に組み込みの保護の順です。
• 評価エンジンは最初に一致したポリシーで停止します。つまり、プリセットの対象範囲にあるユーザーは、作成したカスタムのフィッシング対策ポリシーをすべて迂回してしまいます。
• プリセット セキュリティ ポリシーでは、保守とポリシー ドリフトの管理を Microsoft が担うため、新たな脅威に対する基準設定が自動的に更新されます。
• カスタム ポリシーは管理の手間がかかるため、文書化された正当な業務上の例外にのみ使用すべきです。
• 経営層、財務担当者、IT 管理者などリスクの高いユーザーは、個別に作成した分離ルールではなく、Strict プリセットの対象範囲に含めるべきです。

優先順位の落とし穴: カスタム ルールが静かに機能しなくなる理由

多くのメール セキュリティ管理者は、Microsoft Defender ポータルでカスタムのフィッシング対策ポリシーを作成するのに何日も費やします。フィッシングの信頼度レベルを細かく調整し、保護対象ユーザーの一覧を充実させ、なりすまし試行に対する具体的なアクションを設定します。ポータルには「有効」と表示され、構成は紙の上では完璧に見えます。それでも、これほど慎重に準備したポリシーが、一人のユーザーに対しても一度も適用されないことがあります。

問題の核心は、Microsoft 365 が重複する複数のルールをどのように処理するかにあります。評価エンジンは設定を混ぜ合わせたり、最も厳しいルールを選んだりはしません。代わりに、厳格な階層に従って読み進めます。まず Strict プリセット ポリシーが評価され、次に Standard プリセット ポリシー、続いてカスタム ポリシー、最後に最下層の組み込みの保護が評価されます。受信者が上位のポリシーに一致した時点で、評価は完全に停止します。財務チームのメンバーが Standard プリセット ポリシーの対象範囲に含まれていると、作成した財務向けのカスタムのフィッシング対策ルールは完全に無視されます。エラー メッセージは表示されず、アラートも発生しません。その結果、攻撃者が容易に悪用できる、目に見えないセキュリティの穴が残ります。

プリセットとカスタム ポリシー: 管理上のトレードオフ

Microsoft のプリセット セキュリティ ポリシーとテナントのカスタム構成の間にある考え方の違いを理解することは、長期的なクラウド アーキテクチャの管理に欠かせません。プリセット ポリシー(Standard と Strict)は、世界中の数百万のメールボックスから集められた集合知を反映しています。Microsoft はリアルタイムの脅威テレメトリに基づいてこれらの設定を継続的に更新するため、個々のテナントだけでは到底得られない業界全体の知見の恩恵を受けられます。

一方、カスタム ポリシーは、特定の時点で 1 つの組織に適用される、管理者個人の主観的な判断を表したものです。カスタム ルールは特定のメール フローや独自の業務要件に対して細かな制御を可能にしますが、その分、保守の負担が大きくなります。攻撃手法が進化しても、カスタム ポリシーは何も変わりません。定期的な見直しの仕組みがないと、カスタム構成は知らないうちに最新のセキュリティ標準から外れていき、インシデントが起きてから原因を特定するのが難しい脆弱性を生むことになります。

カスタムのフィッシング対策ポリシーが本当に必要になるのはどのような場合か

事前定義済みのプリセットでほとんどのユーザー シナリオに十分対応できるため、カスタム ポリシーは既定の展開戦略ではなく、例外として扱うべきです。カスタム ルールの継続的な保守負担を正当化するには、一般的に次の 3 つの運用カテゴリのいずれかに当てはまる必要があります。

• 手動で選んだ保護対象ユーザーの一覧: 役員、取締役、財務承認者などの特定のユーザーを、個別に設定したなりすまし検出のしきい値で保護する必要がある場合、カスタム フィッシング対策ポリシーでそれらの正確なユーザー名を指定できます。
• 特殊なメール フロー: 標準外の外部ファイルを日常的に受信する事業部門や、誤検出を起こしやすい社内の自動化システムに依存している事業部門では、業務の継続性を保つために、適用範囲を絞り込んだカスタム ルールが必要になる場合があります。
• サードパーティのメール ゲートウェイ: Microsoft 365 の前段で外部のセキュリティ ゲートウェイを経由してメールを転送している組織では、接続情報や認証結果が変わることがよくあります。そのため、カスタム ポリシーのパラメーターで個別の対応が必要になります。

カスタム ルールを作る理由が、単に別のしきい値設定を好むというだけだったり、既定値では緩すぎるように思えるといった漠然とした感覚だったりする場合、そのポリシーは長期的な運用コストに見合わない可能性が高いです。

まとめと次のステップ

自動化された高度な検出機能と、的を絞ったカスタム構成のバランスを取ることが、成熟したクラウド セキュリティ戦略の特徴です。一般的な従業員には Microsoft のプリセット ポリシーを使い、文書化された例外にのみカスタム ルールを限定して使うことで、管理の負担を減らしつつ、脅威検出の効果を最大化できます。より詳細な実装戦略、構成の確認サイクル、レポートの指標について知りたい場合は、M365 FM Podcast の エピソード全編を聴いて、専門家の知見と実践的なガイダンスを参考に、Microsoft 365 のセキュリティ態勢を今すぐ最適化してください。

よくある質問

ユーザーがプリセット ポリシーとカスタム ポリシーの両方に含まれている場合はどうなりますか?

Microsoft 365 の評価エンジンは、ポリシーを厳密な順序で処理し、カスタム ポリシーよりもプリセット ポリシー(Strict、次に Standard)を優先します。ユーザーがプリセット ポリシーに一致すると、システムはそれ以降の評価を停止し、その受信者に対してカスタム ポリシーは完全に適用されません。

Microsoft のプリセット セキュリティ ポリシーは自動的に更新されますか?

はい。プリセット ポリシーは Microsoft が直接管理しています。脅威の状況が変化し、推奨される基準値が変わると、Microsoft が Standard と Strict のプリセットに含まれる設定を自動的に更新するため、管理者が手動で見直す作業は不要になります。

役員などの高リスク ユーザーは、カスタム ルールではなく Strict プリセットに含めるべきなのはなぜですか?

高リスクの役割は、巧妙なスピア フィッシングやなりすまし攻撃の主な標的になります。Strict プリセットは、Microsoft のグローバルなテレメトリに基づいた積極的な保護しきい値を適用するため、管理者が複雑なカスタム例外リストを手動で保守しなくても、包括的なセキュリティを提供できます。

特定のユーザーのメールボックスに実際に適用されているポリシーを確認するにはどうすればよいですか?

適用中のポリシーは、Microsoft Defender ポータルの構成分析ツールを使用するか、メール イベントに対して高度なハンティング クエリを実行することで確認できます。これにより、ユーザーの受信メッセージに対してどの検出メカニズムとポリシーが動作したかを追跡できます。