OAuth同意フィッシングは、MFAを破らずSaaSアプリ連携の権限を奪う。危険な同意画面、管理者同意、監査ログ、アプリ制御の実務対応を整理する。
OAuth同意フィッシングは「ログイン突破」ではなく「権限付与」を狙う
組織の認証を強化しても、SaaSのアプリ連携が無防備なら別の入口が残る。OAuth同意フィッシングは、ユーザーに偽アプリや悪意あるクラウドアプリへのアクセス許可を与えさせ、メール、ファイル、連絡先、カレンダーなどへ継続的にアクセスする攻撃だ。
厄介なのは、攻撃者が必ずしもパスワードやMFAコードを盗む必要がない点にある。ユーザーが正規の Microsoft Entra ID や Google Workspace の同意画面で「許可」を押すと、攻撃者のアプリにトークンや権限が渡る。見た目は正規のクラウド認可フローなので、従来の偽ログイン画面よりも違和感が小さい。
Microsoft はこの種の攻撃を「consent phishing」や「illicit consent grant」として整理しており、Microsoft 365環境ではパスワードリセットやMFA再要求だけでは不十分になり得ると説明している。つまり、これは「認証を強くする」だけでは閉じない、認証と認可の後段にある問題だ。
この記事では、OAuth 2.0そのものの仕様解説ではなく、企業SaaS運用で発生する「同意画面を悪用した権限奪取」を扱う。基礎用語は OAuth 2.0 と OpenID Connect を先に確認すると読みやすい。
なぜMFAやパスキーだけでは止まらないのか
パスキー導入やFIDO2は、偽サイトにパスワードやワンタイムコードを入力させる攻撃に強い。AiTM型のフィッシングや Tycoon 2FA のようなMFA中継攻撃に対しても、有効な防御になる。
しかしOAuth同意フィッシングの焦点は、ログインフォームではない。ユーザーが本物のIdPにサインインしたあと、攻撃者が用意したアプリに「このアプリがあなたのメールを読んでもよいか」「ファイル一覧を見てもよいか」といった許可を与えさせる。認証自体は正規に成功しているため、MFAは期待通り動いている。それでも、許可されたアプリが危険ならデータは読まれる。
| 攻撃タイプ | 攻撃者が狙うもの | MFAの効き方 |
|---|---|---|
| パスワードフィッシング | ID / パスワード | 強いMFAで被害を抑えやすい |
| AiTMフィッシング | セッションCookie / MFAコード | フィッシング耐性MFAが有効 |
| インフォスティーラー | 保存済みCookie / トークン | 端末防御とトークン失効が必要 |
| OAuth同意フィッシング | アプリ権限 / 同意済みトークン | MFAだけでは止めにくい |
ここで重要なのは、MFAを軽視することではない。MFAは今も必須だ。ただし、SaaS時代の攻撃面はログイン画面の外側へ広がっている。認証を守った次に、アプリ権限、APIスコープ、管理者同意、トークン失効まで見なければならない。
危険な同意画面で見るべきポイント
OAuth同意画面では、アプリ名や発行者、要求する権限、対象データが表示される。問題は、多くの利用者がそれを「いつもの許可画面」として読み飛ばしてしまうことだ。
特に注意したいのは、次のような組み合わせだ。
| 観点 | 危険な兆候 | 確認する理由 |
|---|---|---|
| アプリ名 | 業務ツールに似た曖昧な名前 | 偽の生産性ツールや文書ビューアを装いやすい |
| 発行者 | 未確認、見慣れない組織、個人名 | 誰がアプリを管理しているか追えない |
| 権限 | メール読取、ファイル読取、オフラインアクセス | 侵害後も継続的にデータへ触れる可能性がある |
| 同意範囲 | 組織全体、管理者同意 | 1人の判断が全社影響に拡大する |
| 利用状況 | 少数ユーザーだけが利用 | 標的型の入口になっている可能性がある |
たとえば、PDF変換ツールを名乗るアプリが「すべてのメールを読む」「ファイルを読み書きする」「サインインしていないときもアクセスする」といった権限を要求していたら、業務上の必要性と釣り合っていない。これは脆弱性の悪用ではなく、権限設計のミスマッチを突く攻撃だ。
個人のメールボックスだけに見えても、共有メールボックス、共有ドライブ、TeamsやSharePoint上のファイル、取引先情報へ波及する場合がある。SaaS権限は、個人アカウントの境界よりも広く効くことがある。
Microsoft Entra IDで見るべき管理ポイント
Microsoft Entra ID では、ユーザー同意をどこまで許可するか、管理者同意ワークフローを使うか、アプリ同意ポリシーでどの条件なら許可できるかを制御できる。
まず確認したいのは、一般ユーザーが任意のアプリへ自由に同意できる状態になっていないかだ。Microsoft のドキュメントでは、リスク低減のため、検証済み発行者のアプリや選択した権限にユーザー同意を制限する考え方が示されている。業務上どうしても必要なアプリは、管理者同意の申請フローに乗せる方が追跡しやすい。
実務では、次の順に棚卸しする。
- エンタープライズアプリケーションの一覧を取得する
- 高権限スコープ、オフラインアクセス、メール・ファイル系API権限を抽出する
- 発行者確認、所有者、利用ユーザー数、最終利用日時を見る
- 不明アプリは所有部門へ確認し、説明できないものは無効化候補にする
- 管理者同意のルールを文書化し、申請と承認の履歴を残す
ここで見落としやすいのは、使われていないアプリだ。過去に検証目的で入れたSaaS連携、退職者が作った社内アプリ、放置された自動化ツールは、攻撃者にとって「誰も見ていない権限」になる。
Google Workspaceではアプリアクセス制御を確認する
Google Workspace でも、OAuth 2.0スコープを使うサードパーティアプリのアクセスを管理できる。Google 管理コンソールのアプリアクセス制御では、アプリを Trusted、Limited、Blocked などに分類し、どのGoogleサービスやスコープへアクセスできるかを制御する。
特に、Gmail、Drive、Calendar、Admin SDK などのデータへ触れるアプリは、ユーザー利便性だけで判断しない方がよい。業務部門が便利なツールを導入したつもりでも、そのツールが広いスコープを要求していれば、組織データの出口になる。
| 管理対象 | 確認すること |
|---|---|
| Configured apps | 管理者が明示的に許可・制限したアプリ |
| Accessed apps | 実際にユーザーが利用したアプリ |
| OAuth client ID | 同名アプリのなりすましや別クライアントを区別する |
| Requested services / scopes | Gmail、Driveなど機微データへのアクセス有無 |
| Access level | Trusted、Limited、Blocked の妥当性 |
Google Workspaceでは、アプリ名だけでなくOAuth client ID単位で確認することが大切だ。同じような名前のアプリでも、実体が異なる場合がある。ユーザー数が少ないのに高権限スコープを持つアプリは、優先的に確認したい。
インシデント時の初動：パスワード変更だけで終わらせない
OAuth同意フィッシングが疑われる場合、パスワード変更やMFA再登録だけで安心してはいけない。攻撃者のアプリに同意済みの権限が残っていれば、認証情報を変えてもアクセスが続く可能性がある。
初動では、次の順で見る。
| 手順 | やること | 目的 |
|---|---|---|
| 1 | 不審なアプリとサービスプリンシパルを特定する | 攻撃の入口を見つける |
| 2 | 対象ユーザー、同意日時、要求権限を確認する | 影響範囲を確定する |
| 3 | アプリの権限を取り消す | 継続アクセスを止める |
| 4 | トークン失効、セッション無効化を行う | 既存セッションを切る |
| 5 | メール転送、受信ルール、外部共有を確認する | 二次被害を探す |
| 6 | 監査ログとファイルアクセス履歴を保全する | 事後調査に備える |
インフォスティーラーとAI時代の認証情報危機でも触れた通り、現代の侵害対応では「パスワードを変えたから終わり」では足りない。Cookie、トークン、APIキー、SaaS連携まで含めて失効させる必要がある。
メール読取、ファイル読取、管理API、オフラインアクセスを持つ不明アプリは、通常のヘルプデスク対応ではなくインシデントとして扱うべきだ。業務影響を恐れて放置すると、調査中にもデータ閲覧が続く。
平時の防御：同意を「ユーザー任せ」にしない
OAuth同意フィッシングの防御は、ユーザー教育だけでは弱い。許可画面を見抜ける人を増やすことは重要だが、最終的には管理側で「危険な同意を成立させない」設計が必要になる。
まず、一般ユーザーが高リスク権限へ自由に同意できないようにする。次に、業務上必要なSaaS連携をホワイトリスト化し、申請・審査・期限・所有者を決める。最後に、監査ログで新規アプリ追加や権限変更を検知する。
| 対策 | 実装の考え方 |
|---|---|
| ユーザー同意の制限 | 低リスク権限のみ許可し、高リスク権限は管理者承認へ回す |
| 管理者同意ワークフロー | 申請者、業務目的、要求スコープ、期限を記録する |
| アプリ棚卸し | 月次または四半期で未利用・所有者不明アプリを削除する |
| 高リスクスコープ監視 | メール、ファイル、管理API、オフラインアクセスを重点監視する |
| 条件付きアクセス | 危険な場所、未管理端末、異常サインインと組み合わせて判断する |
これは ゼロトラストアーキテクチャ の「決して信頼せず、常に検証する」という考え方と同じだ。ユーザーが一度許可したアプリを永続的に信頼するのではなく、誰が、何のために、どのデータへ、いつまでアクセスするのかを継続的に検証する。
まとめ：認証強化の次はアプリ権限の統制へ
OAuth同意フィッシングは、MFAやパスキーの価値を否定する攻撃ではない。むしろ、認証が強くなったことで、攻撃者が「ログインを破る」から「正規の同意を悪用する」方向へ回り込んでいると見るべきだ。
組織がまず確認すべきなのは、一般ユーザーがどこまでアプリ同意できるか、誰が管理者同意を承認しているか、そして高権限アプリを定期的に棚卸ししているかだ。SaaSの便利な連携は止めるものではなく、見える化して管理するものだ。
次に読むなら、認証の基礎として 認証と認可、フィッシング耐性MFAの実装課題として パスキー導入の落とし穴、攻撃側の文脈として AIフィッシング を合わせて確認すると、クラウドID防御の全体像がつかみやすい。
参考情報
- Microsoft Learn: Protect against consent phishing
- Microsoft Learn: Detect and remediate illicit consent grants in Microsoft 365
- Microsoft Learn: Configure how users consent to applications
- Microsoft Learn: Application consent management and evaluation of consent requests
- Google Workspace Admin Help: Control which apps access Google Workspace data
