OAuth同意フィッシングとは｜許可してしまった時の確認・初動対応

結論：正規のログインと、アプリへ許可してよいかは別

OAuth同意フィッシングは、利用者を誘導して、不審なアプリへデータアクセスの許可を与えさせる手口です。 MFAやパスキーによるサインインが正常でも、業務に不要なメール・ファイル等への権限を渡す判断は別に残ります。

対象は「許可を押したかもしれない」従業員と、相談を受ける情シス・SaaS管理者です。追加の同意を止め、アプリ・権限・対象・時刻を確認して正規の窓口へ連絡します。 不審なアクセスが進行している疑いがあれば、棚卸しや記録の完成を待たず、権限停止と調査を並行してください。

最初に操作別の判断表で分岐を選び、業務が関係する場合は漏えい疑いの報告テンプレートへ引き継ぎます。本物のトークンや顧客データを、このサイトへ入力・送信する必要はありません。

• 1｜行った操作

  画面表示、同意、情報入力、追加設定を分け、不明は未確認と残す。

• 2｜権限を保護

  管理者がアプリと対象を特定し、必要な付与の取り消し・制限を判断する。

• 3｜反映と影響

  停止の要求と反映を分け、データ操作・残る接続・次の担当を記録する。

なぜMFA・パスキーだけでは同意の問題が終わらないのか

MFAは利用者の認証を保護しますが、「このアプリへ、このデータを渡す業務上の理由があるか」は別の判断です。正規ドメインの同意画面でも、アプリ名、client ID、発行者、要求権限、対象ユーザーやデータ、業務所有者を照合します。検証済み発行者の表示は確認材料であり、要求するすべての権限の必要性を保証しません。

Microsoftの2026年10月21日更新の対策資料も、発行者が検証済みでも同意内容を評価するよう説明しています。これは新たな被害件数・攻撃者の帰属を報告する記事ではなく、2026年10月29日に公開資料を照合した防御解説です。

「同意すると必ず永続アクセスになる」とは限りません。 持続する範囲は付与した権限、トークンの寿命・更新、ポリシー、取り消しによって異なります。一方、ブラウザを閉じる・パスワードを変えるだけで、既存のアプリ権限が消えたとも扱いません。基礎の違いは認証と認可の学習記事で確認できます。

許可してしまった時の初動対応：操作別の判断表

Microsoft Entraで確認すること：委任・アプリ専用・既存の付与

管理者は既知の管理ポータルを使い、対象テナントのエンタープライズアプリでアプリとサービスプリンシパルを照合します。表示名だけでは同名アプリを区別できないため、application/client IDと、テナント内のサービスプリンシパルのobject IDを別々に記録します。これらはパスワードやclient secretとは別です。

2026年10月29日に確認した権限レビューの公式手順では、User consentタブの付与はポータルから取り消せず、管理者がMicrosoft GraphやPowerShellの公式手順を使う制約があります。Admin consentで取り消せる対象と同一視しません。本記事はコマンドを転載せず、必要な最小権限と承認を持つ担当者が公式手順で実行します。

停止・保全・影響確認は次のように分けます。

1. 対象のアプリ、付与、利用者・テナント、業務データを確認し、進行中の影響が疑われる範囲を絞る。
2. 担当者が既存の付与の取り消し、アプリの利用制限など必要な保護を進める。全社の正常アプリまで一律に停止する前に対象と影響を確認する。
3. 並行して同意・サインイン・メールやファイル操作の記録を保全し、取得できない期間を残す。
4. 発行済みアクセストークン、更新用トークン、アプリ独自のセッションの扱いを分け、要求と対象側の反映を確認する。
5. 入力・MFA承認もあればアカウントを保護し、転送ルールや外部共有など別経路の変更も点検する。

Microsoftによる悪意アプリの無効化でも、公式資料には既存アクセストークンは期限まで有効とする説明があります。アプリの無効化通知だけで、取得済みデータの回収や全接続の即時停止を保証しません。具体的な反映は対象APIと公式案内で照合します。

Google Workspace：4種類のアクセス設定と表示遅延

管理コンソールの「セキュリティ」→「アクセスとデータ管理」→「APIの制御」で、アプリ名・OAuth client ID・要求スコープ・対象の組織部門を確認します。管理者権限と表示は環境により異なるため、現行のGoogle公式手順を使います。

設定・一覧	意味と点検する条件
Trusted	制限されたものを含むGoogleサービスへのアクセスを許す設定。自動的な安全認定ではない
Limited	制限されていないGoogleサービスに限る。「すべて読み取り専用」ではない
Specific Google data	管理者が指定したスコープに限る。ログインに必要な範囲も照合する
Blocked	Googleサービスへのアクセスをブロックする設定。対象組織部門の設定を確認する
Configured / Accessed	設定した一覧と、データへアクセスした一覧。名称だけで同じ対象集合と扱わない

公式資料は、詳細表示が許可後24〜48時間、Accessed apps一覧はトークンの付与・取り消しから48時間後に更新と説明しています。これは停止の反映時間や「48時間待てば安全」という保証ではありません。表示されない場合も、client IDと利用者の報告、取得可能なログを照合して、必要な保護を並行します。

Googleの「ドメイン全体の委任」は、利用者の同意を不要にできる別の管理経路です。自動化・移行ツール等が関係するなら、ドメイン全体の委任の管理でもclient IDとスコープを別に確認します。通常の同意画面を確認しただけで、全アプリのアクセスを調べたとは扱いません。

報告・記録テンプレート：値ではなく操作と残件を残す

社内の承認された保存先で、次の欄を使えます。ログの全取得を待たず初報を出し、事実・未確認・次の担当を区別します。

欄	記入内容
発見・操作	日時とタイムゾーン、受信経路、同意・入力・承認・導入の有無
対象	テナント、アプリ表示名、client ID、必要ならservice principal ID、利用者・業務
権限	委任／アプリ専用、同意の主体、データ・操作・組織範囲
停止・反映	実施した設定、要求時刻、対象側の確認時刻、実行結果と未確認
影響・残件	ログ取得期間、疑わしいデータ操作、別経路、担当と次の確認時刻

架空例：「09:05 JSTに業務外アプリの許可を承認／09:08に情シスへ連絡／委任権限の取り消しを実施／対象APIの反映と過去の取得範囲は確認中」。この3分は対応期限や実測値ではありません。 client secret、パスワード、コード、トークン本文、顧客データは報告用の例へ書きません。

この5欄を漏えい疑いの報告テンプレートへ引き継げます。平時の許可・例外・所有者の管理にはSaaS権限棚卸しを使ってください。チェック済みの数は被害がない証明ではありません。

再開・終結の判断と、やってはいけないこと

再開は、①アプリの業務上の必要性と所有者、②必要最小限の権限と承認、③停止・再設定後の反映確認、④影響と未確認・担当・再確認日時、の4点を揃えて判断します。侵害疑いの付与を「業務が止まるから」と根拠なく再付与しません。調査が残る場合は残件として管理し、単なる一覧からの消失を終結条件にしないでください。

不審な許可画面を再び開く、別の利用者に同意させる、実トークンを外部解析へ貼る、証跡を取るために停止を待つ、MFAを無効にして解決しようとする行動は避けます。付与と活動の記録を取らずにアプリを削除すると調査を難しくするため、対象の保護と証跡保全を担当者が並行します。

比較・復習・更新を確認する

• OAuthとOIDCの違いで、IDトークンとAPIアクセスの用途を比較する。
• 認証と認可の権限テスト例で、許可・拒否と変更後の確認を学ぶ。
• ブラウザ拡張機能の権限棚卸しで、端末側とSaaS側の権限を分けて点検する。
• フィッシング判断演習は合成資料だけで練習する。実アプリへの同意は不要。
• 「あとで読む」と進捗ページで同じブラウザから再開し、RSSで新しい記事を確認する。

公式情報・参考情報

• Microsoft Entra：同意フィッシングへの対策 — 2026年10月21日更新の公開資料。正規の同意画面とアプリの正当性、既存トークンの区別。
• Microsoft：不正な同意付与の検出と修復 — 不審な同意と監査・影響範囲の調査。パスワード変更だけでは不足する点。
• Microsoft Entra：アプリに付与された権限のレビュー — Admin consentとUser consent、ポータルで取り消せる対象の制約。
• Microsoft Entra：ユーザー同意の構成 — 同意ポリシー変更は将来の同意に作用し、既存の付与は別に取り消す。
• Microsoft：委任アクセスとアプリ専用アクセス — 利用者とアプリの権限、利用者不在のアプリ専用権限を区別する。
• Google Workspace：アプリのデータアクセス制御 — 4種類のアクセス設定、client ID、組織部門、一覧表示の24〜48時間等の遅れ。
• Google Workspace：ドメイン全体の委任 — 利用者の同意を不要にできる別の管理経路。通常の同意一覧と分けて調査する。
• Microsoft Entra：緊急時のアクセス取り消し — 新規トークン・既存アクセストークン・アプリ独自セッションの違い。