Microsoft 365のAnti-phishing policiesでなりすまし保護を設定する更新は、Microsoft Defender for Office 365利用者にとって「新機能を探す」よりも、既存のなりすまし保護が本当に効いているかを点検する機会として見るのが重要です。特に確認すべきなのは、ユーザーなりすまし保護、ドメインなりすまし保護、Mailbox intelligence、スプーフィング対策、DMARC処理、ポリシーの優先順位です。
Microsoft Learnの該当ドキュメントでは、Anti-phishing policiesがMicrosoft Defender for Office 365 Plan 1/Plan 2とMicrosoft Defender XDRに適用され、既定ポリシーは全受信者に自動適用される一方、より細かく制御したい場合はユーザー、グループ、ドメイン単位のカスタムポリシーを作成できると説明されています。(Microsoft Learn)
Microsoft 365のAnti-phishing policiesでなりすまし保護を設定する更新の要点
今回のポイントは、Microsoft Defender for Office 365のAnti-phishing policiesで「設定しているつもりだが、実際には十分に効いていない」状態を避けることです。公式ソース上の分類はDocumentationであり、テナント側の設定が自動的に変わる告知というより、管理者が設定内容を見直すための整理として読むのが実務的です。
特に注意したいのは、既定のAnti-phishing policyだけでは、組織が期待するなりすまし保護がすべて有効になっているとは限らない点です。Microsoft Learnでは、Defender for Office 365の既定Anti-phishing policyはスプーフィング保護とMailbox intelligenceを提供するものの、その他のなりすまし保護機能やフィッシングメールしきい値は既定では構成されていないため、保護を有効にするには既定ポリシーを変更するか、別のAnti-phishing policyを作成する必要があるとされています。(Microsoft Learn)
| 確認項目 | 影響 | すぐ見るべきポイント |
|---|---|---|
| ユーザーなりすまし保護 | CEO、役員、経理、人事、IT管理者などを装うメールへの対策 | 保護対象ユーザーが登録されているか |
| ドメインなりすまし保護 | 自社ドメインや取引先ドメインに似たドメインを使う攻撃への対策 | 自社所有ドメイン、重要な外部ドメインが対象か |
| Mailbox intelligence | 過去の通信関係をもとに不自然な送信者を判定 | 有効化だけでなく、検出時のアクションも設定されているか |
| Spoof intelligence | Fromアドレスの偽装や認証失敗への対策 | 無効化していないか、許可リストが増えすぎていないか |
| DMARCポリシーの扱い | 送信元ドメインのDMARC方針を尊重するか | p=quarantine、p=reject時の動作が業務に合うか |
| ポリシー優先順位 | どの設定が実際に適用されるか | Standard/Strictプリセットやカスタムポリシーとの競合がないか |
対象になる管理者と利用者
対象になるのは、Microsoft Defender for Office 365を利用している組織のメールセキュリティ管理者、Microsoft 365管理者、SOC担当者、Exchange Online管理者です。Microsoft Learnでは、Defender for Office 365のAnti-phishing policiesは、Microsoft DefenderポータルまたはExchange Online PowerShellで構成できると説明されています。(Microsoft Learn)
一方、Defender for Office 365を利用していないMicrosoft 365環境でも、基本的なAnti-phishing機能は存在します。ただし、ユーザーなりすまし保護やドメインなりすまし保護など、今回の確認ポイントの中心になる高度な機能はDefender for Office 365側のAnti-phishing policiesで扱う領域です。
実務上、次のような組織ほど優先して確認すべきです。
- 役員や経理担当者を狙ったBusiness Email Compromise対策を強化したい
- 取引先、親会社、子会社、ブランド名を装うメールが多い
- 既定ポリシーだけで運用しており、なりすまし保護の対象ユーザーを明示的に設定していない
- メールゲートウェイや外部セキュリティ製品をMicrosoft 365の前段に置いている
- 誤検知を恐れて許可リストやトランスポートルールが増えている
変更点として見るべき実務上のポイント
既定ポリシーだけに頼ると保護が不足しやすい
Anti-phishing policiesには既定ポリシーがありますが、既定ポリシーが存在することと、組織に必要ななりすまし保護が十分に設定されていることは別です。Microsoft Learnでは、カスタムAnti-phishing policyを作成し、特定のユーザー、グループ、ドメインに適用できると説明されています。(Microsoft Learn)
たとえば、次のような運用では見直しが必要です。
| 状態 | リスク | 改善例 |
|---|---|---|
| 既定ポリシーのみ | 役員や経理担当者を個別に保護していない可能性 | 高リスクユーザー向けカスタムポリシーを作成 |
| ユーザー保護を有効化していない | 表示名だけ似せた攻撃に弱い | CEO、CFO、経理、人事、IT管理者を登録 |
| ドメイン保護を有効化していない | 類似ドメイン攻撃を見逃しやすい | 自社ドメイン、重要取引先ドメインを対象化 |
| 検出時アクションが弱い | 警告だけでユーザーに届く可能性 | Quarantineを基本に段階的に調整 |
特に、ユーザーなりすまし保護は「Enable users to protect」を選択し、保護したい送信者を表示名とメールアドレスの組み合わせで登録する必要があります。この設定は既定では選択されていないため、導入済みテナントでも未構成のままになっていることがあります。(Microsoft Learn)
ユーザーなりすまし保護は保護対象の選び方が重要
ユーザーなりすまし保護では、特定の内部または外部メールアドレスが送信者として偽装されるケースを検出します。Microsoft Learnでは、1つのAnti-phishing policyでユーザーなりすまし保護に指定できるユーザー数は最大350人とされています。(Microsoft Learn)
全社員を一律に登録しようとすると、上限や誤検知対応の面で運用が重くなります。最初は次の順で対象を決めると実務に乗せやすくなります。
| 優先度 | 保護対象の例 | 理由 |
|---|---|---|
| 高 | CEO、CFO、役員、経理責任者 | 振込依頼、承認依頼、緊急対応を装われやすい |
| 高 | IT管理者、ヘルプデスク責任者 | パスワード、MFA、アカウント確認を装われやすい |
| 中 | 人事、総務、購買 | 個人情報、契約、請求書関連の攻撃対象になりやすい |
| 中 | 主要な外部関係者 | 顧問、監査法人、重要ベンダーを装う攻撃に備えられる |
注意点は、過去に送受信履歴がある相手については、Mailbox intelligenceの判断により、なりすましとして扱われない場合があることです。Microsoft Learnでは、送信者と受信者が以前メールでやり取りしている場合、ユーザーなりすまし保護やMailbox intelligence protectionが機能しないケースがあると説明されています。(Microsoft Learn)
ドメインなりすまし保護は自社ドメインだけで終わらせない
ドメインなりすまし保護は、自社ドメインや指定したカスタムドメインに似たドメインを使う攻撃を検出するための機能です。Microsoft Learnでは、自社が所有する受け入れ済みドメインや、保護したいカスタムドメインを対象にできると説明されています。(Microsoft Learn)
見落としやすいのは、取引先やグループ会社のドメインです。攻撃者は自社ドメインそのものではなく、請求書を送るベンダー、採用支援会社、クラウドサービス、配送業者などに似たドメインを使うことがあります。
ただし、カスタムドメインを入れすぎると誤検知や例外管理が増えます。まずは次のように絞り込むとよいでしょう。
| 登録候補 | 判断基準 |
|---|---|
| 自社の主要ドメイン | 全社メール、請求書、認証通知に使うドメイン |
| グループ会社ドメイン | 社内扱いでやり取りするが別テナント・別ドメインのもの |
| 金銭処理に関わる取引先 | 請求書、支払い、契約変更の連絡が発生する相手 |
| ブランド名に近い公開ドメイン | 顧客や社員が本物と誤認しやすいもの |
Microsoft Learnでは、ドメインなりすまし保護で指定できるカスタムドメインは1つのAnti-phishing policyあたり最大50個とされています。(Microsoft Learn)
すぐ確認したいAnti-phishing policy設定
Microsoft Defenderポータルで確認する場所
Microsoft Defenderポータルでは、Anti-phishing policiesは「Email & collaboration > Policies & rules > Threat policies > Anti-phishing」から確認できます。Microsoft Learnでも、同じ場所からAnti-phishingページを開き、ポリシーのStatusやPriorityを確認できると説明されています。(Microsoft Learn)
まず確認する順番は、次の通りです。
| 手順 | 確認すること | 判断ポイント |
|---|---|---|
| 1 | Anti-phishing policyの一覧 | 既定、Standard/Strictプリセット、カスタムのどれがあるか |
| 2 | Status | カスタムポリシーが無効化されていないか |
| 3 | Priority | 意図したポリシーが先に適用されるか |
| 4 | Users, groups, domains | 保護対象の受信者が正しいか |
| 5 | Phishing threshold & protection | なりすまし保護、Mailbox intelligence、Spoof intelligenceの状態 |
| 6 | Actions | 検出時に迷惑メール、隔離、拒否などどの動作になるか |
| 7 | Safety tips & indicators | ユーザーに警告表示されるか |
設定変更後は即時反映と考えず、Microsoft Learnの説明どおり、新規または更新したポリシーの適用には最大30分程度を見込む必要があります。(Microsoft Learn)
検出時アクションは「有効化」とセットで確認する
なりすまし保護で失敗しやすいのは、保護対象だけを設定して、検出時のアクションを十分に確認しないことです。Microsoft Learnでは、ユーザーなりすまし、ドメインなりすまし、Mailbox intelligenceによる検出時のアクションとして、何もしない、リダイレクト、迷惑メールフォルダーへ移動、隔離、Bcc追加、配信前削除などが示されています。(Microsoft Learn)
実務では、次のように段階を分けると安全です。
| 運用フェーズ | 推奨しやすいアクション | 理由 |
|---|---|---|
| 初期確認 | QuarantineまたはJunkへ移動 | 誤検知を確認しながら被害を抑えやすい |
| 高リスクユーザー向け | Quarantine | CEO詐称、経理詐称などを受信箱に入れにくい |
| 誤検知が多い相手 | Trusted senders/domainsを慎重に使用 | 業務影響を抑えられるが過剰登録は危険 |
| 明確に悪質なパターン | Rejectまたは削除を検討 | ただし監査・調査に必要な証跡を失わない設計が必要 |
最初から「Delete the message before it’s delivered」を広範囲に使うと、誤検知時に調査や復旧が難しくなります。多くの組織では、まずQuarantineで管理者確認やユーザー通知の運用を整えるほうが現実的です。
Phishing email thresholdは強くすればよいわけではない
Defender for Office 365のAnti-phishing policiesでは、Phishing email thresholdを1 – Standard、2 – Aggressive、3 – More aggressive、4 – Most aggressiveから選べます。Microsoft Learnでは、この値を上げるほど、正当なメールが悪いメールとして扱われる誤検知の可能性が高まると説明されています。(Microsoft Learn)
判断基準は次の通りです。
| 設定 | 向いているケース | 注意点 |
|---|---|---|
| Standard | 一般社員向けの標準運用 | 強い対策が必要な部署では不足する可能性 |
| Aggressive | 経理、役員秘書、購買など | 隔離レビューの体制が必要 |
| More aggressive | 攻撃が多い部門、監視体制がある組織 | 誤検知対応の負荷が上がる |
| Most aggressive | 短期的な緊急対策や高リスク限定 | 全社適用は業務影響を慎重に検証 |
全社一律で最強にするより、高リスク部門向けのカスタムポリシーで段階的に強めるほうが運用しやすくなります。
ポリシー優先順位で起きやすい落とし穴
Anti-phishing policiesでは、どのポリシーが先に適用されるかが非常に重要です。Microsoft Learnでは、Strict preset security policyが最初、Standard preset security policyが次、その後にカスタムAnti-phishing policies、最後に既定Anti-phishing policyが適用されると説明されています。また、受信者に最初のポリシーが適用されると、その受信者に対するAnti-phishing保護の処理はそこで止まります。(Microsoft Learn)
つまり、カスタムポリシーで強い設定を作っていても、同じ受信者がStandardまたはStrict preset security policyに含まれていると、カスタムポリシーの設定が期待通りに効かない可能性があります。
特に次のパターンに注意してください。
| よくある状態 | 起きること | 対処 |
|---|---|---|
| Standard presetに全ユーザーを入れている | カスタムポリシーより先に適用される | 高リスクユーザーの設計をプリセット側も含めて見直す |
| カスタムポリシーを複数作成 | 優先順位によって適用対象が変わる | Priorityを一覧で確認する |
| 例外設定が多い | 本来守るべきユーザーが対象外になる | 除外ユーザー・グループ・ドメインを棚卸しする |
| 既定ポリシーを変更したつもり | プリセットやカスタムが先に適用される | 実際に対象ユーザーへ適用される最初のポリシーを確認する |
Microsoft Learnでは、既定またはカスタムAnti-phishing policiesの設定は、受信者がStandardまたはStrict preset security policiesに含まれている場合は無視されると明記されています。(Microsoft Learn)
Spoof intelligenceとDMARCで確認すべきこと
Spoof intelligenceは、送信者のなりすましや認証失敗を見分けるための重要な設定です。Microsoft Learnでは、Spoof intelligenceは既定で選択されており、オンのままにすることが推奨されています。また、MXレコードがMicrosoft 365を直接指していない場合でも、Spoof intelligenceを無効にするのではなく、Enhanced Filtering for Connectorsを有効にするよう説明されています。(Microsoft Learn)
特に外部メールゲートウェイを使っている組織では、Microsoft 365から見ると本来の送信元情報が見えにくくなる場合があります。その状態でスプーフィング判定が不安定になると、管理者が安易に許可リストを増やし、結果として防御力が落ちます。
DMARCについては、Anti-phishing policiesで送信元ドメインのDMARCポリシーを尊重するかを制御できます。Microsoft Learnでは、「Honor DMARC record policy when the message is detected as spoof」が既定で選択され、p=quarantineの場合は隔離、p=rejectの場合は拒否が既定動作として説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| Spoof intelligence | 無効化されていないか |
| Tenant Allow/Block List | 過去の例外登録が残り続けていないか |
| DMARC p=quarantine | 迷惑メール移動ではなく隔離にすべきか |
| DMARC p=reject | 拒否にして業務上問題がないか |
| 外部ゲートウェイ | Enhanced Filtering for Connectorsを検討しているか |
Trusted senders and domainsは便利だが過信しない
Trusted senders and domainsは、なりすまし保護の例外として使える設定です。Microsoft Learnでは、Trusted senders and domainsに登録された送信者やドメインは、そのポリシーではなりすましベースの攻撃として分類されないと説明されています。最大数は1,024件で、Trusted domain entriesはサブドメインを含まないため、必要なサブドメインは個別に追加する必要があります。(Microsoft Learn)
これは誤検知対応に役立つ一方、使いすぎると防御の穴になります。たとえば、取引先の正規メールが頻繁に隔離される場合でも、いきなり取引先ドメイン全体をTrusted domainsに入れるのではなく、まずSPF、DKIM、DMARC、送信経路、Fromドメイン、DKIM署名ドメインの整合性を確認するべきです。
安全な運用ルールは次の通りです。
| ルール | 理由 |
|---|---|
| 登録理由をチケットや台帳に残す | 後から削除判断できる |
| ドメイン全体ではなく送信者単位を優先 | 例外範囲を小さくできる |
| サブドメインを別扱いで確認 | Trusted domainはサブドメインを自動包含しない |
| 定期的に棚卸しする | 退職者、廃止サービス、古い取引先を残さない |
| メール認証の修正を優先する | 例外登録を恒久対策にしない |
Safety tipsはユーザー教育とセットで有効にする
Safety tips & indicatorsでは、初回接触の警告、ユーザーなりすまし警告、ドメインなりすまし警告、不審な文字を含む送信者の警告、未認証送信者の「?」表示、「via」タグなどを設定できます。Microsoft Learnでは、未認証送信者の「?」表示や「via」タグはSpoof intelligenceが有効な場合に利用できると説明されています。(Microsoft Learn)
Safety tipsは、ユーザーが不審なメールに気づく助けになります。ただし、警告文を見慣れてしまうと無視されるため、単に有効化するだけでは不十分です。
次のように運用と組み合わせると効果が出やすくなります。
| 設定 | 併せて行うこと |
|---|---|
| First contact safety tip | 「初めての送信者からの依頼は確認する」ルールを周知 |
| User impersonation safety tip | 役員名のメールはTeamsや電話で確認する手順を整備 |
| Domain impersonation safety tip | 取引先ドメインの似せ方を教育資料に入れる |
| Unusual characters safety tip | IDNホモグラフ攻撃の例を紹介する |
| viaタグ | 正規の外部配信サービスと不審な中継を見分ける基準を示す |
ただし、First contact safety tipには注意もあります。Microsoft Learnでは、複数受信者のメールでは多数派モデルに基づいて表示対象が決まり、通信習慣の露出が気になる場合はFirst contact safety tipを有効にせず、メールフロールールとヘッダーを使う選択肢も示されています。(Microsoft Learn)
PowerShellで確認する場合の実用コマンド
Microsoft Defenderポータルだけでなく、Exchange Online PowerShellでもAnti-phishing policyとAnti-phish ruleを確認できます。Microsoft Learnでは、Get-AntiPhishPolicyとGet-AntiPhishRuleを使って設定を確認する方法が示されています。(Microsoft Learn)
まずは一覧を確認します。
Get-AntiPhishPolicy | Format-Table Name,IsDefault
Get-AntiPhishRule | Format-Table Name,Priority,State特定ポリシーの詳細を確認する場合は、次のように実行します。
Get-AntiPhishPolicy -Identity "<PolicyName>" | Format-List
Get-AntiPhishRule -Identity "<RuleName>" | Format-List運用確認では、次の観点で見ると設定漏れを見つけやすくなります。
| 見る対象 | 確認したいこと |
|---|---|
| AntiPhishPolicy | なりすまし保護、Mailbox intelligence、Spoof、DMARC、アクション |
| AntiPhishRule | 適用対象、例外、優先順位、有効/無効 |
| プリセットポリシー | Standard/Strictが対象ユーザーに先に適用されていないか |
| Quarantine policy | ユーザー通知、リリース権限、管理者承認の有無 |
PowerShellで変更する場合は、ポリシーとルールの関係に注意が必要です。Microsoft Learnでは、PowerShellでAnti-phish policyを削除しても対応するAnti-phish ruleは削除されず、逆にAnti-phish ruleを削除しても対応するAnti-phish policyは削除されないと説明されています。(Microsoft Learn)
運用上の注意点
「許可リストで解決」を標準運用にしない
なりすまし保護の誤検知が出たとき、最も簡単なのはTrusted senders and domainsやTenant Allow/Block Listに追加することです。しかし、例外登録は攻撃者に悪用される可能性があるため、恒久対策にしてはいけません。
優先順位は、次の順に考えるべきです。
- 正規送信元のSPF、DKIM、DMARCを修正する
- 外部ゲートウェイがある場合はEnhanced Filtering for Connectorsを確認する
- 送信サービスのFrom、MAIL FROM、DKIM署名ドメインを整える
- それでも必要な場合だけ、最小範囲でTrusted senders and domainsを使う
高リスクユーザーは通常ユーザーと同じ設定にしない
役員、経理、人事、IT管理者は、攻撃者にとって価値が高い対象です。全社標準ポリシーだけで守るのではなく、高リスクユーザー向けに別ポリシーを設計するほうが現実的です。
たとえば、一般社員向けはStandardのしきい値とSafety tipsを中心にし、経理・役員向けはQuarantineを強め、なりすまし対象ユーザーとドメインを明示的に登録する、といった分け方が考えられます。
隔離運用を決めずにQuarantineを増やさない
Quarantineは強力ですが、運用設計がないと業務停止や問い合わせ増につながります。次の点を先に決めておくべきです。
| 項目 | 決める内容 |
|---|---|
| 通知 | ユーザーに隔離通知を出すか |
| リリース権限 | ユーザーが自分で解放できるか、管理者承認にするか |
| 確認担当 | 情シス、SOC、ヘルプデスクの誰が見るか |
| SLA | 業務メールの解放依頼を何時間以内に処理するか |
| 記録 | 誤検知、正検知、例外追加をどこに記録するか |
ポリシー変更後はメッセージトレースと隔離を確認する
Anti-phishing policyは設定して終わりではありません。変更後は、隔離されたメール、ユーザーからの報告、メッセージトレース、Defenderポータルの検出状況を見て、過剰検知と見逃しの両方を確認します。
最低限、次の1週間は重点的に見るとよいでしょう。
- 役員名や経理担当者名を含む検出メール
- 類似ドメインとして検出されたメール
- 隔離された正規メール
- Trusted senders and domainsへの追加依頼
- ユーザーからの「届かない」「警告が出る」問い合わせ
まず実行すべき確認リスト
Microsoft Defender for Office 365利用者は、今回のDocumentation更新をきっかけに、次の順で確認すると効率的です。
| 優先度 | 確認すること | 目安 |
|---|---|---|
| 高 | Anti-phishing policyの一覧、Status、Priorityを確認 | すぐ実施 |
| 高 | Standard/Strict preset security policyとの重なりを確認 | すぐ実施 |
| 高 | ユーザーなりすまし保護の対象者を確認 | 役員、経理、人事、IT管理者から |
| 高 | 検出時アクションが「何もしない」になっていないか確認 | Quarantine中心に検討 |
| 中 | ドメインなりすまし保護の対象を確認 | 自社、グループ会社、重要取引先 |
| 中 | Mailbox intelligence protectionが有効か確認 | アクション設定も見る |
| 中 | Spoof intelligenceとDMARC動作を確認 | 外部ゲートウェイ利用時は特に注意 |
| 中 | Trusted senders and domainsを棚卸し | 登録理由が不明なものを削除候補に |
| 低 | Safety tipsの表示とユーザー教育資料を確認 | 警告を無視されない運用にする |
まとめ
Microsoft 365のAnti-phishing policiesでなりすまし保護を設定する更新は、Microsoft Defender for Office 365の管理者に対し、Anti-phishing policyの実効性を見直すきっかけになります。重要なのは、既定ポリシーがあるかどうかではなく、誰を保護し、どのドメインを守り、検出時にどう処理し、どのポリシーが実際に適用されるかです。
まずはMicrosoft DefenderポータルでAnti-phishing policyの一覧、Status、Priorityを確認し、Standard/Strictプリセットとカスタムポリシーの関係を整理してください。そのうえで、役員、経理、人事、IT管理者などの高リスクユーザーをユーザーなりすまし保護に登録し、自社ドメインや重要取引先ドメインの保護、Quarantine運用、Trusted senders and domainsの棚卸しを進めるのが現実的です。
コメント