Microsoft 365 同意フィッシング

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Microsoft 365 の同意フィッシングが従来の MFA による防御をどのように回避し、OAuth のアクセス許可をどう悪用するのか、また、その検出と防止の方法を解説します。

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

同意フィッシングは、Microsoft 365 と Azure 環境で最も急速に拡大している脅威の一つです。最も強力な認証による防御さえすり抜けるため、多くの組織が不意を突かれています。従来のフィッシングがパスワードを盗もうとするのとは異なり、同意フィッシングは「裏口」から侵入します。つまり、サインインを安全にするための仕組みそのものを悪用するのです。この手口はユーザーの信頼につけ込み、クラウドで正規のシングルサインオンやアプリ連携を支えている認可の仕組み、OAuth を利用します。

攻撃者は同意フィッシングを使い、多要素認証 (MFA) で保護された環境でも、機密性の高いビジネスデータへの永続的かつ人目につきにくいアクセスを維持できます。本ガイドでは、同意フィッシングが従来のセキュリティをどのように、なぜ回避するのかを掘り下げ、実際の攻撃を分析します。そのうえで、同意に関連する脅威を検出、防止、封じ込めるための実践的な手順を説明します。小規模チームの Microsoft 365 を管理している方も、数千人規模のセキュリティを担当している方も、攻撃者が OAuth の同意フローの中でどのように動くかを理解することは、今や必須のスキルです。

同意フィッシングを理解し、MFA が機能しない理由

技術的な詳細に入る前に、なぜ同意フィッシングがクラウドセキュリティの分野で話題になり続けているのか、全体像をつかんでおくことが重要です。ここで扱うのは、ログイン情報を盗み取り、防御を総当たりで突破しようとする、いつものフィッシングの手口ではありません。同意フィッシングは、より新しく、より巧妙な種類の攻撃です。正規のアプリのアクセス許可と認可フローを武器にして、利便性を逆手に取ります。

Microsoft 365 や Azure のようなクラウドプラットフォームでは、OAuth があらゆる場面で使われています。ユーザーはこの仕組みを使ってサードパーティのアプリを接続し、データを共有し、タスクを自動化します。多くの場合、クリック一回で済みます。残念ながら、攻撃者はユーザーが公式に見えるものを信頼しがちであることを知っています。そして、アクセス許可の確認画面が一瞬表示されて、誰も深く考えない瞬間を最大限に利用します。重要なのは、これらの攻撃がパスワードの窃取に頼らない点です。代わりに、本物のユーザーに「組織のすべてを支配する鍵」を自ら渡させます。ハッキングは不要で、必要なのは少しのソーシャルエンジニアリングと巧妙な偽装だけです。

同意フィッシングが特に危険なのは、多要素認証 (MFA) や従来のセキュリティ対策をすり抜けられることです。攻撃者は侵入を試みる代わりに、丁寧に依頼します。急いでいたり、事情を知らなかったりするユーザーは、悪意のあるアプリへのアクセスを自ら許可してしまいます。本ガイドでは、この攻撃がどのように行われ、なぜ行われ、Microsoft の ID 基盤にとってどのような点で特に危険なのかを理解していただきます。この視点を持てば、同意フィッシングへの防御には、従来の資格情報保護とは大きく異なる考え方が必要だとわかるはずです。

同意フィッシングとは何か、なぜ多要素認証を回避できるのか

同意フィッシングとは、正規に見える OAuth のアクセス許可要求を承認するよう誘導され、攻撃者が管理するアプリにクラウドリソースへのアクセスを与えてしまう攻撃の一種です。従来のフィッシングのように資格情報を盗んだり推測したりするのではなく、同意フィッシングはユーザー自身が悪意のあるアプリを承認することに依存します。そのため、クラウドを基盤とする現在の環境では特に危険です。

ここが最大のポイントです。同意画面を承認すると、アプリは ID プロバイダー (Microsoft Entra ID、旧称 Azure AD など) からアクセストークンと更新トークンを受け取ります。これらのトークンを使うと、パスワードを知らなくても、また MFA を突破しなくても、メール、ファイル、予定表などの Microsoft 365 データにアクセスできます。攻撃者はログインの防御を突破する必要はありません。ユーザーが自ら許可したアクセスをそのまま使うだけで、プラットフォームはそれを完全に正規のものとみなします。

資格情報フィッシングと同意フィッシングの違いは、わずかですが決定的です。資格情報フィッシングはユーザー名とパスワードの窃取を狙います (MFA によって保護されることが多い手口です)。一方、同意フィッシングは正規の OAuth 2.0 認可コードフローの中で動作します。MFA を完全に適用していても、攻撃者はユーザーの既存のセッションを使って同意のワークフローを完了させ、MFA を丸ごと回避します。いったん OAuth トークンが発行されると、被害者がパスワードを変更したり、セッションを取り消したりしても、攻撃者の足場は残ります。

OAuth同意フィッシングの詳しい解説は、Entra IDにおけるOAuth同意攻撃の概要をご覧ください。組織が攻撃を根本から防ぐには、資格情報の保護や多要素認証だけでは不十分であり、優先すべき実際のリスクと防御策を理解することが重要です。結論として、攻撃を発生源で止めたいのであれば、資格情報のセキュリティやMFAの枠を超えて考える必要があります。

OAuth同意フィッシングが信頼を悪用して データを侵害する仕組み

同意フィッシングキャンペーンを実行する攻撃者は、サードパーティ製アプリケーションを作成するか、なりすましてユーザーに提示し、広範なアクセス許可を付与するよう誘導します。多くの場合、使い慣れた「安全」に見えるOAuth 2.0フローを利用します。ユーザーには「メールの読み取り」や「ファイルへのアクセス」といった一般的な同意画面が表示されます。ユーザーが「承諾」をクリックすると、その悪意あるアプリは実際のOAuthトークンを取得し、指定されたMicrosoft 365やAzureのリソースに直接アクセスできるようになります。

この時点で、攻撃者はパスワードやコード、回避手段を必要としません。OAuthトークン（特にアクセストークンと更新トークン）により、表立ってわからない形で継続的なアクセスが可能になります。これらのトークンは手動で取り消されるか、有効期限が切れるまで有効です。つまり、攻撃者はパスワードが変更されたり、ユーザーが別の場所でサインアウトしたりしても、被害者になりすましてデータの取得、メールの送信、各種操作を続けることができます。

この手法は、同意ダイアログに対してユーザーが暗黙のうちに寄せる信頼を悪用します。特に、画面が公式に見え、時間に追われている環境ではその傾向が強まります。OAuthフローは実際のIDプロバイダーの仕組みを使うため、不審なサインインとして検知される要素がなく、攻撃者が突破すべきMFAの要求もありません。攻撃は、日常業務で信頼されている同じAPIを使って、静かに進行します。

実際の侵害事例や攻撃の連鎖についての具体的な知見を得るには、Microsoft 365におけるOAuthの悪用に関するステップごとの分析をご覧ください。結局のところ、このような持続的なアクセスは防御側にとって厄介な問題です。攻撃者は長期間気づかれずに潜伏し、データの完全な復旧やアプリの修復までの道のりは長く、困難になりがちです。

一般的な手法と実際の同意フィッシング攻撃

同意フィッシングは理論上の脅威ではなく、Microsoft 365、Google Workspace、その他のクラウドエコシステムを狙った影響の大きいキャンペーンで実際に悪用されています。攻撃者は、説得力のあるアプリ名から巧妙に権限を絞った要求まで、さまざまな手口で絶えず手法を改良しています。その結果、セキュリティチームは進化し続ける攻撃手法に常に直面することになります。

このセクションでは、理論が実践に触れたときに何が起こるのかを取り上げます。攻撃のライフサイクル、一般的なフィッシングの試みでユーザーが実際に目にする画面、攻撃者がアクセス権を拡大したり、プラットフォーム間を移動したりする方法を紹介します。少しずつ権限を広げていく手法から、大きく報道されたConsentFixのようなキャンペーンまで、ここで取り上げる手口からは、脅威アクターが通常の統制をすり抜けるために、いかに巧妙で粘り強くなっているかがわかります。

何より重要なのは、これらの実例から、「とにかく多要素認証を有効にする」といった一律の指針を超える必要性が明らかになることです。同意フィッシングに対抗するには、人の心理と技術的な防止策の両方を考える必要があります。巧妙なソーシャルエンジニアリング、同意画面の設計上の欠陥、アプリのガバナンスの不備が、攻撃者に機会を与えることを理解しなければなりません。このセクションでは実践的な攻撃を分解することで、セキュリティチームがより鋭い判断力を養い、より効果的な緩和策のプレイブックを作成できるよう支援します。

セキュリティチームが知っておくべき同意フィッシングの主要な5つの攻撃手法

1. 発行元のなりすまし: 攻撃者は、正規のベンダーに似た名前のアプリを作成します。たとえば「Microsoft Secure Suite」や「HR Docs Cloud」などです。ユーザーは見慣れたブランドを信頼するため、要求を承認してしまう可能性が高くなります。必ず発行元の詳細を確認し、提供元を検証してください。
2. アクセス許可の誤認させる表示: 悪意のあるアプリは、同意画面で無害なアクセス許可を目立たせる一方で、「すべてのメールボックスの読み取り/書き込み」や「ファイルへのフルアクセス」といった高い権限のスコープをこっそり含めることがよくあります。太字のテキストだけを見るように訓練されたユーザーは、実際に承認されているリスクを見落とす可能性があります。
3. 後の段階での権限昇格を狙った限定的なアクセス許可の取得: 攻撃者の中には、疑いを避けるために、プロファイルへのアクセスといった基本的なアクセス許可だけを要求するケースがあります。その後、この初期のトークンアクセスを足がかりとして、段階的なフィッシングや権限昇格を通じて、より危険な同意を得ようとします。
4. 永続的なOAuthトークンを使った横方向の移動: いったん侵入すると、攻撃者はトークンやアプリのアクセス許可を利用して横方向に移動します。共有ドライブやカレンダーの予定にアクセスしたり、Microsoft 365内で権限を昇格させたりします。トークンは、最初は「かろうじて足りる」程度のアクセス権しか付与しないものの、後から拡張や更新が行われることがあります。
5. 侵害されたサードパーティ製アプリ: 攻撃者は独自にアプリを作るのではなく、多くのテナントで広範なアクセス許可がすでに付与されている、信頼された独立系ソフトウェアベンダー(ISV)のアプリケーションを侵害したり、悪用したりすることがあります。こうしたサプライチェーン攻撃は検出が特に困難で、組織全体に急速に広がるおそれがあります。

基盤となる仕組みや、Entra IDがこれらのパターンに対してどのように強化できるかを技術的に詳しく知りたい場合は、OAuth同意の悪用に関するこの詳細な解説をご覧ください。これらは、攻撃者が従来の防御やMFAを回避するために編み出してきた多くの手口のごく一部にすぎません。

ConsentFixキャンペーンの手順(ステップバイステップ)

1. 最初のフィッシングメール: 攻撃は、「ポリシーの問題を修正してください」や「メールボックスを保護してください」とユーザーに促す、もっともらしいメールから始まります。メッセージには、正式なMicrosoftのリソースを装ったリンクが含まれています。
2. 悪意のあるアプリの同意ページへのリダイレクト: リンクをクリックすると、ユーザーはOAuthの同意プロンプトに誘導されます。画面は見慣れた、ブランドらしく正規のもののように見えますが、その背後のアプリは攻撃者が管理しており、名前が偽装または似せられていることがよくあります。
3. 同意の付与とトークンの発行: ユーザーは要求されたアクセス許可を確認します。多くの場合、「セキュリティ」や「コンプライアンス」に必要なものとして説明されており、ユーザーが「承諾」をクリックすると、攻撃者はそのユーザーのアカウントに対するアクセストークンと更新トークンを入手します。
4. 攻撃者による永続的なアクセスの確保: 攻撃者はこれらのトークンを使い、Microsoft 365のメールボックス、ファイル、カレンダー、その他の機密データAPIにアクセスします。このセッションはパスワードの変更やほとんどのMFAの再設定を経ても維持され、同意が手動で取り消されるまで有効であり続けます。
5. 静かなデータの窃取と収益化: 攻撃者は、メールの内容や機密文書を密かに持ち出したり、接続されたサービスへの横方向の移動を開始したりします。すべてが「許可された」ものに見えるため、検出は困難です。ただし、チームが異常なアプリの動作や新たな同意の付与を監視していれば話は別です。

Entra IDを使って、攻撃者がこれらの手順をMicrosoft 365内でどのように連鎖させるのかを正確に知りたい場合は、OAuth同意攻撃に関するこの技術的な解説をご覧ください。

ConsentFixがMicrosoft 365とクラウドセキュリティにとって重要な理由

ConsentFixキャンペーンは、正規のOAuthフローを悪用することで、攻撃者がMicrosoft 365、Google Workspace、その他のSaaSテナントをいかに迅速かつ密かに侵害できるかを示しました。パスワードのリセットやMFAを強制した後でも、さまざまな業界の組織で、不正なメールアクセス、ファイルの漏えい、アカウントの長期的な持続が発生しました。これらの攻撃は、多層防御の必要性を浮き彫りにしています。ユーザーの意識向上、リアルタイムの同意監視、強固なアプリガバナンスは「あればよいもの」ではなく、大規模な侵害やクラウド上のデータ損失を防ぐうえで不可欠です。

悪意のあるアプリの検出と、異常な同意の監視

OAuthを悪用した脅威を発見し、対応することは、必ずしも容易ではありません。攻撃は通常の業務トラフィックに紛れ込んでしまうためです。影響が目に見える頃には、悪意のあるアプリが数日から数週間にわたって、機密データを静かに吸い上げていたかもしれません。だからこそ、事前の検出戦略が非常に重要です。セキュリティチームには予防的な統制だけでなく、ユーザーの同意パターン、アプリの動作、そして組織全体における「通常」の姿について、実際に把握できる情報が必要です。

本セクションでは、早期検知と調査のための実践的なアプローチを取り上げます。行動シグナル、異常監視、Microsoft のネイティブなエンタープライズ ツールを使い、リスクの高い同意イベントが手に負えなくなる前に検出する方法を学びます。通常と異なる API アクティビティや新規アプリ登録の急増など、適切な手がかりを押さえれば、進行中の攻撃を見つけて素早く封じ込められます。

これは、クラウド環境の「防犯カメラ」のようなものと考えてください。継続的な監視、自動ログ記録、スマートなアラートがあれば、攻撃者の潜伏期間を抑え、被害を最小限に留めることが現実的に可能になります。コンプライアンスの自動化が目標である場合や、より広範なリスク管理と連携させたい場合は、Microsoft Defender for Cloud などのツールとの統合によって取り組みを次のレベルに引き上げられます。自動化によって環境をコンプライアンス準拠かつ安全に保つための知見については、Microsoft Defender for Cloud でコンプライアンスを監視する方法のガイドをご覧ください。

行動および同意シグナルを使って悪意のあるアプリケーションを検出する方法

1. 想定外の同意付与を監視する: 新しい OAuth の同意、特に通常の業務時間外に承認されたものや、見慣れない発行元から発生したものに注意してください。新たに認可されたアプリが大量にある場合は、危険信号かもしれません。
2. 不審な API 呼び出しパターンを分析する: ファイルへの高速アクセス、大量のメールボックス読み取り、通常とは異なる管理 API の使用など、異常な動作を探します。攻撃者は、通常のアプリと比べてアクセス許可を「使いすぎる」傾向があります。
3. 通常と異なるトークンの動きに注意する: 更新トークンの急速または繰り返しの生成や、トークンのライフサイクルにおける不審なパターンを追跡します。悪意のあるアプリは、更新トークンを悪用して、最初の侵害から長期間にわたってアクセスを維持することがあります。
4. Microsoft のログと Defender を活用する: クラウド アプリ セキュリティ製品と Entra ID のログを使い、承認済みのすべてのアプリを一覧化します。通常の IT 承認ワークフローを回避したリスクの高いアプリやシャドー アプリを明らかにします。Microsoft Defender for Cloud Apps などのツールは、不審なアプリの動作に対する可視化とアラートを提供します。
5. シャドー IT の検出結果に対処する: 多くのインシデントは、未承認または管理されていないアプリのアクセスが原因です。テナントを定期的に監査し、リスクの高いアプリの検出結果をフォローアップし、過剰な権限を持つ OAuth の付与をクリーンアップしてください。シャドー IT への対処と不正なアプリの管理について詳しくは、Microsoft 365 におけるシャドー IT の管理ガイドをご覧ください。

Microsoft 365 Defender と Entra ID Protection による同意フィッシング攻撃の調査

1. 脅威ハンティング: まず、Entra ID のログと Microsoft 365 Defender のアラートを検索し、最近の同意イベント、不審なアプリの作成、OAuth アプリに関連する異常なサインイン パターンを確認します。
2. 対象を絞った調査: 個々のユーザーとアプリの履歴を詳しく確認し、どのアクセス許可が、いつ、誰によって付与されたかを調べます。このアクティビティを通常のベースラインや業務ワークフローのタイミングと照合します。
3. 修復: 悪意のある同意が見つかった場合は、直ちにアプリのトークンと同意の付与を取り消します。Microsoft 365 Defender では一括取り消しが可能で、追加のリスクの高いセッションにフラグを立てることもできます。これにより、攻撃者が永続的なトークンを使ってアクセスを維持することを防げます。
4. 継続的な監視と自動化: 新たな高リスクのアプリへの同意、繰り返される管理者の同意要求、既知の悪意ある発行元 ID について、自動アラートを設定します。自動化されたポリシーを設定すれば、対応を迅速化し、攻撃者の潜伏期間を短縮できます。
5. コンプライアンスとポリシーの適用を統合する: インシデント対応と並行して、継続的なコンプライアンス監視には Microsoft Defender for Cloud を使用し、セキュリティ ポリシーを長期にわたって確実に適用するために、Entra ID でのアイデンティティ ガバナンスのアプローチも確認してください。これにより、リアルタイムの攻撃を捕捉するとともに、新たなリスクを生む構成のドリフトや、アイデンティティの負債を防げます。

同意ポリシーとアプリの制限による環境の保護

コンセント型フィッシングを確実に食い止めたいなら、アプリがユーザーの同意を要求し、受け取る仕組みを制御するポリシーと構成設定に直接取り組む必要があります。これらの制御を調整するには慎重なバランスが求められます。信頼できる統合を使ってユーザーの生産性を保ちつつ、羊の皮をかぶった狼を誰かが（意図的であれ誤ってであれ）招き入れてしまうことを防がなければなりません。

このセクションは、クラウド管理者とCISOにとっての実践的なロードマップです。同意ポリシーの設計や発行元の検証から、OAuthトークンの有効期間の厳格な管理まで、利用できる主要な技術的手段を順に解説します。適切に実施すれば、これらの対策はリスクを最小限に抑え、攻撃者に侵入された場合の被害も限定できます。SaaS統合の数が増え、シャドーITが無視できない規模になるにつれて、一貫したガバナンスが不可欠です。

ガバナンスは、イノベーションに「ノー」と言うためのものではありません。アクセスを管理し、信頼できるワークフローを定義し、環境が成長しても健全さを保つための境界を徹底することが目的です。より広範なセキュリティフレームワークに取り組んでいるなら、ここで取り上げる教訓は Microsoft 365 にとどまらず、Power Platform やその他のビジネス向けSaaSにも十分に当てはまります。ベストプラクティスについてさらに詳しく知りたい方は、Power Platform のガバナンスとセキュリティに関するガイドをご覧ください。

同意ポリシーを構成し、ユーザーの同意を制限する方法

1. デフォルトでユーザーの同意を制限する: Microsoft Entra ID で、テナント全体の設定を構成し、リスクの高いアプリへの同意は管理者だけが承認できるようにします。エンドユーザーに表示される同意画面は、リスクの低いアプリに限定します。これにより、誤った承認を最小限に抑えられます。
2. 管理者による承認ワークフローを有効にする: 広範囲または機密性の高いアクセス許可を要求するアプリには、管理者によるレビューと承認を必須にします。これにより、リスクのあるアプリが「ついでに」認可されることを防ぎ、同意の操作履歴を正式に記録できます。
3. アクセス許可のスコープを細かく設定する: 包括的な「すべて許可」のアクセス許可は使用しないでください。同意は業務上必要な範囲だけに限定します。カスタムスコープを定義しておくと、攻撃者が危険な権限を紛れ込ませることが難しくなります。
4. 同意の付与状況を定期的に監査する: 現在テナントへのアクセス許可を持っているアプリを確認します。特に、IT部門の監視が及ばないままユーザーが付与したものは要注意です。古くなった不要な同意は取り消し、攻撃対象領域を縮小してください。
5. 条件付きアクセス ポリシーを活用する: 同意の制限と、場所、デバイス、リスクベースの強力な条件付きアクセス ポリシーを組み合わせ、セッションのハイジャックや管理対象外デバイスからのアクセスをブロックします。

Entra ID の強化と、リスクの高い同意フローの最小化について、具体的で実践的なヒントを知りたい方は、こちらの包括的な解説記事をご覧ください。

発行元の検証を徹底し、ファーストパーティ アプリへのアクセスを制限する

1. 発行元の検証を必須にする: 検証済みの発行元のアプリだけに、環境内でユーザーまたは管理者の同意を要求することを許可します。これにより、アプリ開発者が本人確認を済ませていることが保証され、大半のなりすまし攻撃を防ぐ追加の信頼層になります。
2. 未検証の発行元をブロックする: Microsoft Entra ID やその他のプラットフォームで、発行元の検証基準を満たさないアプリへの同意を自動的に拒否する基本ポリシーを設定します。既存および新規のすべてのアプリについて、発行元のステータスを定期的に確認してください。
3. 信頼できるファーストパーティ アプリに同意を限定する: 公式の Microsoft アプリなどのファーストパーティ アプリ、または明示的に承認されたサードパーティ アプリだけが新たな同意を要求できるように構成を強化します。これにより、侵害された1つのアプリから別のアプリへ横展開されるリスクを大幅に減らせます。
4. 発行元へのアクセスを監査し、一覧化する: 発行元のステータスとアプリの一覧を、IT部門の定期的なセキュリティレビューの恒常的な項目にします。自動化ツールを使い、新規または未承認の発行元を洗い出してください。
5. 接続されているすべてのプラットフォームに適用する: 発行元の検証とアプリの制限を、Power Platform、Teams アプリ、接続された SaaS にも広げます。この取り組みを大規模に進める方法については、こちらの Power Platform ガバナンス ガイドで詳しく紹介しています。

OAuth のセキュリティに向けたトークン有効期間の管理と継続的な監視の実装

OAuthトークンの有効期間を短く設定すると、攻撃者が盗まれたトークンや同意済みトークンを悪用できる期間を減らせます。アクセス トークンはすぐに失効し、更新トークンは定期的にローテーションされるよう、トークンの有効期限ポリシーを調整してください。トークン バインディングとリスクベースの取り消しを導入し、不審なセッションや不正利用されたセッションを遮断します。これらに加えて、トークンの使用状況と同意イベントを継続的に監視し、異常なパターンを検出します。その際には、Microsoft Defender for Office 365 や Entra の条件付きアクセス ポリシーなどのツールを活用してください。侵害されたトークンが、気づかれないまま長期にわたる脅威になるのを防ぐためです。実践的な設定と継続的な監視の戦略については、こちらの Microsoft のセキュリティ推奨事項をご覧ください。

同意フィッシングに備えたガバナンスの強化とユーザー意識の向上

技術的な対策だけでは、進化するクラウド攻撃に対して限界があります。長期的なレジリエンスには、堅牢なガバナンス、定期的な監査、ユーザー教育が互いに補強し合う、セキュリティ文化が必要です。同意フィッシングは技術だけでなく人の心理also突いてくるため、成功の鍵はチーム全員が正式なポリシーと日々の注意を両立させることにあります。

このセクションでは、OAuth ガバナンスの枠組みの構築と既存のアプリ許可の監査、ユーザーが不審な同意プロンプトを見分けられるようにする実践的なトレーニング手法、そして攻撃者の前に現実的な障壁を設けるワークフローの構築方法を詳しく解説します。目標は、防御を IT 部門の中だけにとどめず、組織全体に行き渡らせることです。

複雑なアプリ環境を持つ組織では、リスクはさらに高くなります。サプライ チェーンのどこかで起きた誤りは、外部へと波及する可能性があるためです。ユーザー数やアプリの数が増え続けても、機密データを保護しコンプライアンスを維持するには、継続的で先回りしたガバナンスと意識向上が欠かせません。高度なガバナンスのアドバイス、特に Microsoft 環境における DLP と高度な監査については、この Copilot ガバナンスに関する詳細ガイドと、Microsoft Purview 監査によるユーザー アクティビティの監査については、こちらの解説をご覧ください。

OAuth ガバナンスの枠組みの構築と既存の許可の監査

1. 同意とアプリ利用のポリシーを定義する: どのユーザーとアプリが同意を要求できるか、許可されるアクセス許可の種類と業務上のユースケースを明確に定めます。組織の全員がルールを把握できるよう、このガイドラインを公開してください。
2. アプリの一覧を完全に維持する: Entra ID で OAuth 接続されているすべてのアプリを一覧化し、各アプリへの同意を誰が与えたか、発行元、要求されたスコープ、業務上の理由を記録します。Entra API または Microsoft Defender を使った自動検出により作業を効率化でき、シャドー アプリの発見にも役立ちます。
3. 定期的な許可の監査を実施する: 四半期ごとまたは半年ごとにレビューを行い、古くなった、重複した、リスクのあるアクセス許可を洗い出します。アプリの発行元確認の状態を照合し、もう使われていないアプリや不審になったアプリの許可を削除します。
4. 逸脱を監視して是正する: 未承認の発行元に広範なアクセス許可を与えるといったポリシー違反についてアラートを設定し、ギャップが見つかったらすぐに是正キャンペーンを実施します。定期的な監査により、防御を機動的に保ち、アプリ環境を健全な状態に維持できます。
5. ガバナンスをコンプライアンスと DLP に統合する: リスクが高い、または規制の対象となる環境では、OAuth ガバナンスを Microsoft Purview の DLP と監査ログに連携させます。大規模にユーザー アクティビティとコネクタの境界を監視する実践的な方法については、この Purview ガバナンスに関するガイドをご覧ください。

意識向上のためのトレーニングとアプリ承認ワークフローの強化

• OAuth のリスクに関する重点的なユーザー トレーニング: 不審なアプリのプロンプト、誤解を招くアクセス許可、ブランドされた画面への過信の危険性について、定期的なワークショップや e-ラーニングのモジュールを実施し、職員に教育します。フィッシング メールや同意画面といった実例を取り上げ、ユーザーが危険信号を見分けられるようにします。
• コンセント フィッシング攻撃をシミュレーションする: OAuth フローを中心としたモック フィッシング テストを実施し、ユーザーの判断力と即応力を養います。不審な確認画面を、怖がらずに報告できる環境を整えます。
• アプリ承認ワークフローを正式化する: サードパーティ製アプリの連携、特に機密性の高いアクセス許可を要求するものは、誰かが同意を与える前に、必ず IT 部門主導の承認プロセスを経るよう義務付けます。
• ポリシー認知キャンペーンを実施する: 技術的なトレーニングに加え、ポスター、定期的なリマインダー、ポリシーの再確認を行います。安全な同意の判断を「一度設定したら終わり」ではなく、継続的なテーマとして扱います。
• ユーザー側からシャドー IT を監視する: ワークフローの強制と併せて、未承認の SaaS や不正な AI エージェントの利用を検知してブロックするテクノロジーを導入します。AI シャドー IT の課題への取り組みについて詳しくは、こちらのガバナンス ガイドをご覧ください。

ISV と CISO のための開発者側の衛生管理およびアプリ セキュリティの推奨事項

• パブリッシャー検証: パブリッシャーを登録して検証し、エンタープライズの購入者にとってアプリの透明性と信頼性を高めます。
• 明確で最小限のアクセス許可: 機能の実現に必要最小限のスコープのみを要求します。ユーザーの不信感を招き、審査で却下されるリスクを生む過剰なアクセス許可の要求は避けてください。
• 安全な同意フロー: 同意ページには、アプリ名を偽らず、わかりやすい説明と明確な目的を記載し、ユーザーの混乱や誤った承認を防ぎます。
• 安全な開発プラクティスを徹底する: アプリのコンポーネントを定期的にパッチ適用し、セキュリティ テスト パイプラインを導入して、サプライ チェーンの脆弱性を遮断します。
• CISO のポリシー ガイダンス: 社内でのアプリ セキュリティ レビューを義務付け、常に最新の状態に保つアプリ インベントリを維持するとともに、新しい連携を承認する前に、サードパーティ パブリッシャーのリスクに対する組織の方針を明文化します。

あわせて聴いていただきたいエピソード

Microsoft 365 の同意フィッシングについて調べている方には、安全な Microsoft 365 の導入、データ保護、ガバナンス、AI リスク管理について実践的な視点を加えてくれる、以下のエピソードがおすすめです。

• Microsoft Purview – Simply Explained — 分類、保持、コンプライアンス、保護が、ひとつの Microsoft データ ガバナンス モデルにどのようにまとまるかを確認できます。
• Microsoft Defender XDR – Simply Explained — データ保護の管理を、検出、調査、対応と結び付けて考えられます。
• Conditional Access – Simply Explained — ID とリスクのシグナルが、アクセス判断にどのような文脈を加えるかを理解できます。
• Microsoft AI Agent Harness – Simply Explained — AI による自動化をより信頼性が高く、可視化され、安全なものにする管理手段を解説します。

これらのエピソードは、本記事の概念を、実践的な設計と展開の判断に結び付ける助けとなります。