目次
Microsoft 365の正規の画面でログインし、アプリからのアクセス要求を承認した。その後で不審な依頼だったと気付いたとき、パスワードを変えるだけでは対応が終わらない場合があります。OAuth同意フィッシングでは、攻撃者が利用者をだましてアプリへ権限を与えさせ、許可されたメールや文書などへアクセスします。狙われるのは認証情報だけではありません。
本稿は、Microsoft Entra IDとMicrosoft 365を使うWeb開発・運用チーム向けの恒久対策です。新たな事件や脆弱性の速報ではなく、2026年10月24日にMicrosoftの一次資料を確認して整理しました。以下の仮想例、初動の整理方法、復旧判定は本サイトの提案です。実際のテナントで侵害調査や操作の動作試験を実施したものではありません。
スポンサーリンク
正規の認可画面でも許可先が正当とは限らない
Microsoftの同意フィッシング対策資料は、利用者が悪意あるクラウドアプリへ権限を与えるよう誘導される攻撃を説明しています。ログイン先が本物であることと、その後に許可するアプリが業務上必要であることは別の確認です。
仮に、取引先の資料を見るために必要だと言われ、メールの読み取りまで求めるアプリへ同意したとします。認証は正しく完了していても、文書を見るという目的と、付与した権限が一致していません。これは説明用の仮想例であり、特定のサービスや顧客が被害を受けたという主張ではありません。
URLの確認やMFAは引き続き必要です。ただし、本人が正規の手続きで不適切なアプリへ許可を与える問題まで、認証の成功だけで解決したとは考えません。アプリ名、発行元、求める権限、利用目的を対応付けることが、同意する場面の判断になります。
読み取りだけの権限も、無害とは限りません。運用担当者のメールや共有文書には、顧客とのやり取り、非公開の設計資料、復旧の案内などが含まれ得ます。書き込みや削除ができないという理由で、機密性への影響を低く見積もらないようにします。
パスワードとアプリへの同意を別に扱う
Microsoftの不正な同意付与への対処資料は、通常のパスワードリセットやMFAの要求だけでは、この種類の攻撃への有効な対処にならないと説明しています。侵害された可能性のある認証情報への対応と、アプリに許可したアクセスの取り消しを分けて確認する必要があります。
パスワード変更が不要という意味ではありません。利用者のアカウント自体にも不正アクセスがあった場合は、その封じ込めを併せて行います。しかし、「パスワード変更済み」という一つの記録から、同意、更新トークン、アプリ独自のセッションまで取り消せたと判断しないでください。
本サイトでは、対応票を「利用者の認証」「対象アプリ」「付与した権限」「既に発行されたアクセス」の四つに分ける方法を提案します。どの操作をいつ行い、何が止まったのかを記録します。画面上で連携が消えたことだけを、すべてのアクセスが停止した証拠にはしません。
スポンサーリンク
初動は対象を特定しアクセスを止める
不審な同意に気付いた利用者は、同じリンクを開いて承認をやり直したり、確認のために追加権限を与えたりせず、管理担当へ連絡します。分かる範囲のアプリ名、操作時刻、利用アカウント、元の依頼を残します。認可コードやトークンを含むURLを、そのまま共有チケットへ貼り付けることは避けます。
管理担当は、表示名だけでなくアプリの識別子、テナント内のサービスプリンシパル、同意した主体と権限を対応させます。同じ表示名の別アプリや、正規アプリに似せた名前を取り違えないためです。業務台帳と照合し、不審という判断の根拠も残します。
- 対象アプリと付与済み権限を特定し、停止・取り消しの対象を確定する。
- 必要な記録を短時間で保全し、不正なアクセスの封じ込めを進める。
- 本人のアカウントも侵害された可能性があれば、その停止・復旧を並行して判断する。
- 同じアプリへ他の利用者や管理者も同意していないか確認する。
記録を完全に集めるまでアクセスを許可し続ける必要はありません。一方で、識別子や付与内容を残さず何でも削除すると、影響範囲の調査が難しくなります。継続中の危険、記録の取得、業務停止の影響を責任者が判断し、行った操作と時刻を残します。
ユーザー同意と管理者同意で調査範囲を変える
Microsoftのアプリ同意調査プレイブックは、個人が付与した同意と、管理者が組織のために付与した同意、委任された権限とアプリケーション権限を区別しています。報告した利用者一人だけを調べれば十分かは、実際の付与範囲によって変わります。
委任された権限はユーザーに結び付く利用で扱われますが、管理者が同意した委任権限もあります。「委任だから一人」「管理者同意だからすべてのデータ」と機械的に決めず、同意の対象、権限名、アクセス先の制約を読んで範囲を確定します。
アプリケーション権限は、サインインしたユーザーを伴わないバックグラウンド処理でも使われます。これが不正に付与されていた場合、あるユーザーのパスワードやセッションだけを止めても、アプリ側の権限を取り消したことにはなりません。利用者とアプリの両方を調査対象にします。
メール、ファイル、連絡先を扱うアプリでは、読み取れる対象と、送信・変更できる対象を分けて確認します。権限の名前にReadがあるだけで、影響が軽いと判断しません。サイト運用の復旧に使うメールや、顧客データへアクセスできた場合は、関連するサービスの担当にも連絡して調査範囲を広げます。
スポンサーリンク
同意の取り消しと再同意の防止は別の作業
Microsoftのアプリ権限の確認・取り消し資料では、組織全体への管理者同意と、ユーザー同意を別に確認します。同資料は、User consentタブからのポータル上の取り消しには対応せず、Microsoft GraphやPowerShellを使う方法を案内しています。画面に対象が見えることと、その画面から解除できることは同じではありません。
実際の作業は、現在の公式手順と必要な管理ロールを確認して行います。表示名だけを条件にした一括削除や、すべてのアプリの権限を消す操作を初動の定型にしません。正規の通知、デプロイ、顧客対応まで止まる可能性があるため、対象の識別と業務上の所有者を確認します。
Microsoftは、現在の同意を取り消しても、ユーザーが再び同意することまでは防げないと説明しています。取り消し後に同じ誘導から許可が戻るなら、封じ込めを維持できません。利用者が同意できる条件やアプリの利用制御を見直し、再度の許可をどの経路で防ぐかを確認します。
また、アプリへのアクセス権には、OAuthの同意以外の仕組みが関係する場合もあります。取り消した項目の一覧だけで安全を断定せず、実際に問題となったデータへの経路が残っていないかを調べます。複数の認可方式を使うアプリでは、担当者間で解除対象を共有します。
停止操作の成功と実際の停止時刻を分ける
Microsoftが規約違反のOAuthアプリを無効にした場合について、同社の対策資料は、新しいトークンや更新要求を拒否する一方、既存のアクセストークンは期限まで有効だと説明しています。これは提供元が行う当該無効化の説明であり、すべての取り消し操作が同じ挙動になるという一般化はできません。
Microsoftの緊急アクセス失効資料も、アクセストークン、更新トークン、アプリが独自に発行したセッションを区別しています。Entra IDはアプリ独自のセッションを直接失効できません。何を無効にしたかと、対象サービスがその停止をいつ反映するかを別に確かめます。
本サイトでは、操作の実施時刻、提供元が示す反映条件、最後に観測した不正な活動、再確認する時刻を対応票へ残す方法を提案します。管理画面の成功表示だけで即時停止と報告せず、観測できていない範囲があれば未確認として引き継ぎます。攻撃者が取得したトークンを通常端末で再利用して試す必要はありません。
アクセスできた範囲と持ち出しを確認した範囲を分ける
調査では、いつ同意が付与され、どの権限を使って、どのデータへアクセスしたかを時系列で調べます。認可された範囲は被害の最大範囲を考える手掛かりですが、その全データが実際に持ち出された証拠ではありません。逆に、不審なログインが見当たらないことだけで、アプリによるアクセスまで否定しません。
同意の監査記録、アプリのサインインや活動、メール・文書側の監査情報を突き合わせます。監査機能の有効化、契約、保存期間によって確認可能な範囲が変わるため、記録がない場合は理由を調べます。後から監査を有効にしても、過去のすべての操作が復元できるとは案内しません。
既に取得されたメールや文書は、同意を取り消しても回収できません。転送設定、送信されたメッセージ、他サービスの復旧につながる情報など、観測した活動に応じて追加の対応を判断します。漏えい確認と可能性の区別を保ち、関係者への説明にも調査の限界を含めます。
平時は許可の入口と例外の期限を決める
新しいアプリへの同意を全員の自己判断に任せず、業務目的、発行元、求めるデータ、所有者を確認する運用を設けます。検証済み発行元という表示は手掛かりになりますが、必要以上の権限を要求していないかのレビューは残ります。正規の発行元でも、業務に不要なアクセスまで許可する理由にはなりません。
一律に外部連携を止めるだけでは、必要な業務が個人アカウントや非公式な手順へ移るおそれがあります。本サイトでは、低リスクな許可条件と管理者へ依頼する経路を用意し、例外には責任者と見直し期限を付ける方法を勧めます。廃止したアプリの同意も定期的に点検します。
訓練では、本番のメールや文書を使わず、管理者が用意したテスト用アプリと架空データで、申請、拒否、許可、取り消し、再同意の制限を確認します。これは未実施の訓練案です。認証が成功するかだけでなく、不適切な許可を止め、付与してしまった場合に誰が取り消すかまで確かめることが目的です。
スポンサーリンク
関連記事
本物のログイン画面でも要注意｜デバイスコード・フィッシングとMFAの限界では、攻撃者が始めた端末認証を承認させる手口を扱います。2026年10月13日時点の資料に基づく解説で、本稿は悪意あるアプリへの同意と、その取り消しを中心に補うものです。
参考資料
- Microsoft：同意フィッシングの防止と無効化後の注意点
- Microsoft：不正な同意付与の検出と対処
- Microsoft：アプリ同意付与の調査プレイブック
- Microsoft：アプリに付与した権限の確認と取り消し
- Microsoft：緊急時のユーザーアクセス失効
情報確認日：2026年10月24日。本文と概念イラストの作成に生成AIを使用し、一次資料と保存内容を確認しています。
