Microsoft 365 セキュリティ対策｜Entra ID で実践する多層防御

はじめに

Microsoft 365 は、日本企業でもメール・ファイル共有・認証基盤までを一手に担うプラットフォームとして広く普及しています。便利さの裏側で、その認証基盤である Entra ID（旧 Azure AD）が攻撃者にとって最優先のターゲット になっているという事実は、運用する側として強く意識しておく必要があります。

近年の特徴は、「MFA（多要素認証）を入れていれば安心」という前提が崩れつつあることです。AiTM（中間者）攻撃やデバイスコードフィッシングのように、正規の Microsoft 画面で認証させ、発行されたトークンを奪う手口が PhaaS（Phishing-as-a-Service）として量産され、2026 年に入って大規模化しています。

この記事では、個別の設定手順を深掘りする前に、まず M365 / Entra ID のセキュリティを「多層防御の地図」として体系的に整理します。脅威の全体像をつかんだうえで、認証・アクセス制御・メール・監視・対応という各レイヤーで何を押さえるべきか、そして「まず何から手を付けるか」を優先度つきで把握できる構成にしています。各レイヤーの詳細は、それぞれの個別記事（スポーク）で解説していきます。

M365 / Entra ID を取り巻く脅威の全体像

まずは「いま何が起きているのか」を整理します。攻撃の主戦場は、サーバーの脆弱性よりも ID（認証情報とトークン） に移っています。

ID（認証情報）を狙う攻撃が主流に

Microsoft 自身が公表しているデータを見ると、ID を狙う攻撃の規模感がよくわかります。Microsoft の脅威レポートでは、同社サービスに対して 1 日あたり 3 億回を超える資格情報スタッフィング（パスワードの使い回しを突く攻撃） が観測されたと報告されています。パスワード単体に依存した防御が、もはや現実的でないことを示す数字です。

その一方で、MFA の効果も明確です。Microsoft は、MFA を有効にしたアカウントが攻撃の大半をブロックできると繰り返し強調しています。

参考: Announcing mandatory multifactor authentication for the Microsoft 365 admin center（Microsoft）
“Implementing MFA significantly reduces the risk of account compromise”
（MFA の導入は、アカウント侵害のリスクを大幅に低減します）
https://techcommunity.microsoft.com/blog/microsoft_365blog/announcing-mandatory-multifactor-authentication-for-the-microsoft-365-admin-cent/4232568

MFA を突破される新しい現実（トークン窃取）

2026 年に最も警戒すべきなのが、MFA を突破してアクセストークンを奪うタイプの攻撃です。代表的な手口は 2 つあります。

ひとつは AiTM（Adversary-in-the-Middle / 中間者）フィッシングです。攻撃者がリバースプロキシを挟み、被害者と Microsoft の間の認証通信をリアルタイムで中継します。被害者が MFA まで完了すると、その結果として発行されたセッショントークンが攻撃者の手に渡ります。

参考: Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise（Microsoft Security Blog）
“AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication”
（AiTM 攻撃は認証トラフィックをリアルタイムで傍受し、フィッシング耐性のない多要素認証を回避します）
https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/

Microsoft のセキュリティ研究チームによると、2026 年 4 月 14〜16 日のわずか 3 日間で、26 カ国・13,000 以上の組織・35,000 人超のユーザーが「行動規範（code of conduct）違反の通知」を装ったこの種のキャンペーンの標的になったと報告されています。

もうひとつが デバイスコードフィッシングです。本来はスマート TV など入力が難しい端末向けの認証フロー（Device Code Flow）を悪用し、被害者に正規の Microsoft ページでコードを入力させてトークンを奪います。2026 年前半には、EvilTokens や Kali365 といった PhaaS プラットフォームが Telegram 上で出回り、AI が生成した精巧なルアーと組み合わせて自動化された攻撃が日々大量に展開されています。

これらに共通する怖さは、パスワードをリセットしてもアクセスが維持される点です。盗まれるのが資格情報ではなくトークンであるため、従来型のインシデント対応では取りこぼします。デバイスコードフィッシングの具体的なメカニズムと Entra ID 側の対策は、別記事で詳しく解説しています。

不正 OAuth アプリ・同意フィッシング

認証フローだけでなく、OAuth アプリの「同意」も侵入経路になります。攻撃者は正規に見えるアプリへの権限付与（メール読み取りやファイルアクセスなど）をユーザーに承認させ、トークンを通じて継続的にデータへアクセスします。ここでもユーザーは「正規の同意画面」で操作するため、フィッシングだと気づきにくいのが特徴です。これはレイヤー3で触れる「アプリ同意の統制」で対処します。

多層防御の考え方（5つのレイヤーで整理）

ここまでの脅威を踏まえると、単一の対策では守りきれないことがわかります。重要なのは、ID を中心に複数のレイヤーで守るという発想です。本記事では、M365 / Entra ID のセキュリティを次の 5 レイヤーで整理します。

レイヤー	目的	主な打ち手
レイヤー1：認証	「なりすまし」を防ぐ	MFA 強制 / フィッシング耐性 MFA
レイヤー2：アクセス制御	「許可する条件」を絞る	条件付きアクセス / 不要フロー遮断
レイヤー3：メール・アプリ	入口（メール・同意）を固める	EOP・Defender / アプリ同意統制
レイヤー4：監視・検知	異常を早く見つける	サインイン/監査ログ / ID Protection
レイヤー5：対応	被害を最小化する	セッション取り消し / トークン無効化

以降、各レイヤーの要点と、深掘り記事への入口を順に見ていきます。

レイヤー1：認証の強化（MFA / パスワードレス）

すべての土台は認証です。前述のとおり MFA の有無は侵害リスクを大きく左右するため、全ユーザーへの MFA 適用は最優先です。

押さえておきたいのが、Microsoft 自身が MFA を「任意」から「必須」へ段階的に切り替えている点です。Azure portal や Entra/Intune 管理センターへのサインインは 2025 年 3 月までに MFA が強制化され、Azure CLI・PowerShell・SDK・API も 2025 年 10 月から対象（猶予申請で 2026 年 7 月 1 日まで延期可）となりました。そして Microsoft 365 管理センターは、2026 年 2 月 9 日以降、MFA を完了しないと管理者がサインインできなくなっています。まだ未対応のテナントがあれば、最優先で確認すべき項目です。

セキュリティ既定値群と条件付きアクセスの使い分け

MFA を有効化する方法は大きく 2 つあります。

 セキュリティ既定値群（Security Defaults）:
無料で全ユーザーに基本的な MFA を一括適用できる。小規模・シンプルな環境向け。

 条件付きアクセス（Conditional Access）:
対象や条件をきめ細かく制御できる。Entra ID P1 以上が必要だが、実務ではこちらが基本。

Microsoft は、従来の「ユーザーごとの MFA 設定」を非推奨とし、条件付きアクセスへの一本化を推奨しています。フィッシング耐性 MFA（パスキー / FIDO2 セキュリティキー / 証明書ベース認証 / Windows Hello for Business）は、AiTM 攻撃に対する最も効果的な防御のひとつです。これらは認証情報がドメインに暗号的に紐づくため、別ドメインのフィッシングサイトからは再生できません。

ただし注意点として、フィッシング耐性 MFA はデバイスコードフィッシングを直接は防げません。あの手口では、ユーザーが（認証方式が何であれ）発行されたトークンそのものを攻撃者に渡してしまうためです。ここはレイヤー2 の「フロー遮断」で対処する、という役割分担を意識してください。

レイヤー2：アクセス制御（条件付きアクセス）

認証が「あなたは誰か」を確認する仕組みなら、条件付きアクセスは 「どこから・どの端末で・どのリスクで」サインインしているかに応じて許可・ブロックを判断する仕組みです。「管理者なら MFA を必須にし、セッションを短くする」「リスクの高いサインインはブロックする」といったルールを、必要なものだけ適切な順序で設計するのがポイントです。

最低限、次のポリシーは検討に値します。

• 管理者ロールにフィッシング耐性 MFA（または認証強度）を必須化する
• レガシ認証（基本認証を使う古いクライアント）をブロックする
• リスクベース（サインインリスク / ユーザーリスク）で追加認証またはブロックを行う

不要な認証フロー（デバイスコードフロー）の遮断

デバイスコードフィッシング対策として特に効果的なのが、使っていないデバイスコードフローを条件付きアクセスでブロックすることです。Microsoft 自身も、明確な業務上の必要がない限りデバイスコードフローの無効化を推奨しており、Microsoft マネージドの条件付きアクセスポリシーにも、これを既定でブロックするものが用意されています。

参考: Microsoft-Managed Conditional Access Policies for Enhanced Security（Microsoft Learn）
“This policy blocks device code flow”
（このポリシーはデバイスコードフローをブロックします）
https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies

Microsoft Teams 専用デバイスなど、デバイスコードフローが必要なケースもあるため、その場合は 「全ユーザーをブロック＋必要なユーザーだけ除外グループで許可」という形で、例外を最小限かつ管理可能な状態に保つのが定石です。

レイヤー3：メール・アプリのセキュリティ

侵入の多くはメール（フィッシング）と、OAuth アプリへの同意から始まります。ここを固めることで、攻撃の「入口」を狭められます。

EOP と Defender for Office 365

メール防御は役割が分かれています。

 Exchange Online Protection（EOP）:
すべての Exchange Online に標準搭載されるスパム・マルウェアの基本フィルター。

 Microsoft Defender for Office 365:
安全な添付ファイル / 安全なリンク、なりすまし対策、攻撃シミュレーションなどを備えた上位の保護。

Microsoft は AiTM 対策として、Defender for Office 365 による高度なフィッシング対策と、EOP の推奨設定の適用を案内しています。まずは「推奨セキュリティ設定（Preset security policies）」を有効化し、自組織の設定が推奨水準を満たしているかを点検するのが効率的です。

OAuth アプリ同意の統制

不正アプリ・同意フィッシング対策の基本は、ユーザーが自由にアプリへ権限を与えられる状態をやめることです。具体的には、ユーザーの同意を検証済みアプリ・低リスクの権限に限定し、それ以外は管理者の承認ワークフローを経由させます。あわせて、既に付与済みのアプリと権限を棚卸しし、不審なものを失効させることも重要です。

レイヤー4：監視と検知（ログ・サインイン監査）

「侵入される前提」で、いかに早く異常を見つけるか。Entra ID には監視の材料が揃っています。

 サインインログ:
国・IP・端末・認証方式・条件付きアクセスの適用結果を確認できる。デバイスコードフローでの不審な成功や、見慣れない IP / ホスティング事業者からのアクセスをハンティングする。

 監査ログ:
アプリ権限の付与、メール転送ルールの作成など、侵害後によく見られる操作を追跡できる。

 Microsoft Entra ID Protection:
リスクベースでサインインやユーザーのリスクを自動評価し、条件付きアクセスと連動させられる（ライセンス要件あり）

トークン窃取型の攻撃では、侵害後に 受信トレイルールの作成（不審メールの隠蔽・転送） や Microsoft Graph API による偵察 が行われる傾向があります。こうした「サインイン後の挙動」を監査ログで検知できるよう、アラートや SIEM 連携を整えておくと早期発見につながります。

レイヤー5：インシデント対応の基本

万一、トークン窃取型の侵害が疑われた場合、パスワード変更だけでは不十分です。盗まれているのはトークンだからです。初動の要点は次のとおりです。

• 対象ユーザーの セッションを取り消し（Revoke sessions）、発行済みの更新トークンをすべて無効化する。
• 攻撃者が仕込んだ メール転送ルール / 受信トレイルールを点検・削除する。
• 不審な OAuth アプリの同意を失効させる。
• 必要に応じて、攻撃インフラ（特定のホスティング事業者の IP 帯など）からの認証をブロックする。

「トークンを無効化する」「不正な永続化（ルール・アプリ同意）を除去する」までをワンセットで実施することが、再侵入を防ぐ鍵になります。

優先度つき実装チェックリスト

最後に、ここまでの内容を「まず何から手を付けるか」の観点で一覧にまとめます。自組織の現状と照らし合わせる際のたたき台としてご活用ください。

対策	優先度	難易度
管理者 MFA の確実な有効化（2026/2/9 強制を前提）	最高	低
全ユーザーへ条件付きアクセスで MFA を必須化	高	中
デバイスコードフローのブロック（不要な場合）	高	低
レガシ認証（基本認証）のブロック	高	低
EOP / Defender for Office 365 の推奨設定適用	高	中
フィッシング耐性 MFA（パスキー / FIDO2）の段階導入	中〜高	中
ユーザーのアプリ同意制限＋管理者承認ワークフロー	中	中
Entra ID Protection（リスクベース）の有効化	中	中（ライセンス依存）
サインイン / 監査ログの監視・アラート整備	中	中
PIM による特権ロールの Just-In-Time 化	中	中（ライセンス依存）

まずは難易度が低く効果の大きい上位（管理者 MFA、デバイスコードフロー・レガシ認証のブロック）から着手し、段階的にフィッシング耐性 MFA や監視体制へ広げていくのが現実的です。

まとめ

本記事では、Microsoft 365 / Entra ID のセキュリティを多層防御の地図として整理しました。

• 攻撃の主戦場は ID に移り、AiTM やデバイスコードフィッシングなど MFA を突破してトークンを奪う手口が大規模化している。
• 防御は単一の対策ではなく、認証・アクセス制御・メール/アプリ・監視・対応の 5 レイヤーで重ねて考える。
• まずは 管理者 MFA の確実化、デバイスコードフロー / レガシ認証のブロックといった効果の高い設定から着手する。
• トークン窃取型の侵害では、パスワード変更だけでなく セッション取り消しと永続化の除去までを徹底する。

各レイヤーの具体的な設定手順は、今後の個別記事で順次掘り下げていきます。まずは本記事の地図とチェックリストを起点に、自組織の現状把握から始めてみてください。

以上、最後までお読みいただきありがとうございました。