Microsoft 365 / フィッシング・マルウェア対策ポリシーの確認方法

フィッシング・悪意のあるメール防御ポリシーを確認する際は、ポリシー単体のスイッチよりも適用対象、ポリシーの優先順位、検疫・通知結果をあわせて確認する必要があります。Microsoft 365 には基本保護ポリシーがあり、製品により Standard・Strict の事前設定ポリシーおよびカスタムポリシーを使用できます。

まず区分するポリシー

Microsoftのプリセットセキュリティポリシー文書は、基本、Standard、Strictおよびカスタムポリシーの関係を説明します。特に複数のポリシーが同じユーザーに適用される場合、優先順位のために予想と異なる設定が選ばれることがあります。すべての機能がすべてのMicrosoft 365サブスクリプションに含まれるわけではありません。

保持している機能と現在のポリシーをまず記録する

Exchange Onlineの基本メール保護とDefender for Office 365の追加機能を区別してください。例えば、Safe Links・Safe Attachmentsや一部のなりすまし保護が必要な場合には、適用するユーザーの該当サービス権利を確認する必要があります。メニューが表示されるという事実だけで、すべての人に機能が含まれると判断してはいけません。

ポリシーを読む役割と変更する役割も異なります。承認されたセキュリティ・メール管理権限で現在のポリシー名、有効状態、対象ユーザー・グループ・ドメイン、例外、優先順位および検疫動作を記録します。デフォルト値を推測するよりも、実際のテナント設定を読み、既存業務例外の担当者と使用理由が残っているか確認してください。

同じユーザーに複数のポリシーがある場合

同じ種類のポリシーは複数の値を合算して適用しません。該当受信者に最初に一致したポリシー1つが選択されます。基本的な優先関係はStrict → Standard → 評価ポリシー（使用中の場合） → カスタムポリシー → 基本ポリシー・Built-in protectionであり、カスタムポリシー同士では小さい優先度の数が先です。Safe Links・Safe AttachmentsのBuilt-in protectionは、該当製品機能の基本保護であり、すべての基本メールポリシーと同名の機能ではありません。

例えば、テストユーザーがStandardのプリセットポリシーとカスタムスパムポリシーの両方に含まれている場合、カスタムポリシーの優先度を0に上げても、Standardの該当保護が先に適用されます。ユーザーが予想と異なる結果を受け取った場合、その人が含まれているプリセットポリシーの対象から確認してください。マルウェア・スパムのように異なる保護種類の検査順序や、同じ種類のポリシーの優先度を混同してはいけません。

これはMicrosoftの上記ポリシー優先度文書に基づいて判断する方法です。「より強い設定があちこちで合算される」と仮定すると必要な保護が抜け落ちる可能性があるため、受信者1人を決めて種類別の実際の適用ポリシーを照合します。

ポリシー点検の順序

1. Microsoft Defenderポータルで[電子メールと共同作業] → [ポリシーとルール] → [脅威ポリシー]を開きます。画面の言語やライセンスにより詳細メニューが異なる場合があります。
2. プリセットセキュリティポリシーの有効状態と適用対象を確認します。経営陣や機密業務アカウントに別途ポリシーを適用しているかも確認します。

3. フィッシング・マルウェア・スパムポリシーの例外や許可リストを確認します。古い業務例外が過度に広範でないかを確認します。
4. 同じ受信者が複数のポリシーに含まれている場合、Microsoftのポリシー適用優先順位に従って実際に適用されるポリシーを判断します。
5. 検疫された実際のメッセージまたは安全に準備したテストメールで予想される結果を確認します。ユーザーに通知が届くか、誰が検疫を解除できるかも確認します。

Standard・Strict適用を検討する手順

Standardは一般的な保護基準、Strictはより厳格な保護が必要な対象の設定集を検討する出発点です。Strictがすべての職務に無条件で適しているという意味ではありません。事前設定の大部分の詳細値はユーザーが自由に調整できるカスタムポリシーとは異なり、Microsoftが管理するため、個別オプションを探す前にポリシーの選択と対象範囲が要件に合っているか判断してください。

1. 脅威ポリシー → プリセットセキュリティポリシーでStandardまたはStrictの現在の状態を開きます。既存の対象と除外をまず記録します。
2. 変更したい保護に対してテストユーザー・グループを指定し、例外を確認します。ウィザードに基本保護とDefender保護の適用範囲が分かれて表示されている場合、それぞれの対象とライセンスを対照します。
3. なりすまし保護対象のユーザー・ドメインなど、入力が必要な項目を実際の組織情報と照合します。表示名だけでなく、保護対象のアカウント・ドメインを確認します。
4. 確認画面を確認し、承認された範囲に適用した後、保存状態と対象リストを再度読み込みます。既存の事前設定を修正するときは、パイロット外の対象も一緒に変わらないことを確認します。
5. 業務上重要な正常送信経路のメールで、配信・迷惑メール・検疫・通知を確認します。悪意のある添付ファイルや実際のフィッシングサイトは通常の試験メールには入れません。

単純な正常メールの送受信試験では、すべての攻撃検知能力を検証できません。実際のセキュリティ試験は、組織が承認したツールと範囲で別途実施する必要があります。この点検の目的は、ポリシー対象と業務への影響、検疫・通知が予想通りであるかを確認することです。

検疫とユーザー通知の確認

検疫ポリシーは、ユーザーがどのメッセージを見られ、直接解除するかまたは解除をリクエストできるかを制御します。同じ「検疫」であっても、検知種類とポリシーによってユーザーの操作は異なる可能性があります。ユーザーに通知が届いたという理由だけで、自己解除できると案内しないでください。

管理者はメッセージの検出理由と適用ポリシー、 自動対応の状態を確認し、誰が解除を承認するかを決定します。ジャンクフォルダに送られたメッセージ、検疫されたメッセージ、サーバーで拒否されたメッセージは後続対応が異なるため、メッセージ追跡結果と一緒に確認します。

正常なメールがブロックされた場合

正常なメールの配信に問題が発生したからといって、組織全体のフィッシング保護をオフにしないでください。メッセージ追跡で状態を確認し、検疫理由、送信認証結果、実際の適用ポリシーを調査します。誤検知であれば、影響を受ける送信者とポリシー条件を絞って修正し、他の不審な類似メールが通過しないようにテストします。逆にフィッシングメールが受信トレイに届いた場合は、許可リストと優先度、ドメイン認証設定を確認する必要があります。

送信者の要求だけを信じてドメイン全体を許可せず、実際の送信主体とSPF・DKIM・DMARCの結果を確認してください。アドレス帳の安全な送信者に追加する方法は、マルウェアや高信頼フィッシングの検出をすべて回避するわけではありません。誤検知の提出や許可が必要な場合は、該当する検出タイプでサポートされる公式提出ルートを使用し、対象・有効期限・根拠を残します。

ポリシー変更後には、同じ正常送信経路を再度テストし、他の受信者に保護の空白が生じていないか確認します。問題となった変更のみを以前の値に復元できるように、ポリシー・対象・例外を記録し、臨時許可は担当者が期限前に再確認または削除します。セキュリティを弱めたまま、メール一通の到着結果だけで解決処理は行いません。