MFA では防げないOAuth同意悪用

OPINION

攻撃者は、説得力のある同意プロンプトを1回提示するだけで、パスワードもマルウェアも使わずにSaaS（software-as-a-service）への持続的なアクセス権を得ることができます。

セキュリティチームは長年、多要素認証（MFA）をアカウント保護の強力な指標として扱ってきました。その考え方自体は理解できますが、不完全です。MFAが保護するのは認証プロセスであり、ログイン後にユーザーが何を許可できるかを制御するものではありません。

この違いが重要なのは、OAuth同意がSaaSやクラウド環境において、独立したアクセス経路になっているからです。ユーザーはサインインしてMFAを突破した後でも、メール、ファイル、リポジトリ、業務プラットフォーム、あるいはクラウド連携のワークフローにアクセスできるアプリケーションを承認してしまうことがあります。パスワードを盗む必要も、マルウェアを実行する必要もありません。ユーザーが正規のプロバイダーのドメインを見ている最中に、リスクが始まる可能性があるのです。

OAuth同意の悪用は、単なるフィッシングの問題ではないため、もっと注目されるべきです。これは認可(authorization)のガバナンスに関わる問題なのです。

攻撃の経路は単純です。ユーザーはメール、チャット、共有ドキュメント、あるいは課題管理システムを通じてリンクを受け取ります。そのリンクは、クラウドやSaaSプロバイダーの正規のOAuth認可フローにつながっています。アプリケーション自体は、生産性向上コネクタやレポートツール、ワークフロー支援ツールなど、一見無害に見えるものであることが多いです。

ユーザーはすでにサインイン済みであるため、この一連の流れはごく日常的な操作に感じられます。同意画面に権限のリクエストが表示され、ユーザーはそれを承認してしまいます。

この時点で、攻撃者はユーザーのパスワードを必要としません。プロバイダーの種類、アプリの種類、テナントポリシー、付与されたスコープによっては、攻撃者はトークンやアプリの許可を取得し、それらの権限が取り消されるかトークンが無効化されるまで、継続的にAPIへアクセスできる可能性があります。

その後、攻撃者は承認済みのAPIを通じてデータにアクセスし、メールボックスを検索し、ファイルを列挙し、ソースコードを抽出し、リポジトリの設定を変更し、CI/CDのメタデータにアクセスし、業務プラットフォームと連携することが可能になります。

壊れているのはOAuthではなくガバナンス

問題はOAuth自体が壊れていることではありません。OAuthは、アクセスを委任するという本来の設計どおりに機能しています。

問題は、多くの組織が委任アクセスを最小限のレビューと過剰なスコープ、承認後の監視の甘さのまま許容していることです。その結果、たった1回のユーザーの判断が、機密システムへの持続的なアクセスを生み出しかねません。

これが、MFAだけでは不十分な理由です。認証後の同意判断の多くは、信頼されたセッション内で行われます。セキュリティチームからは、正常なサインイン、正規のドメイン、通常のAPIトラフィックしか見えません。エンドポイントやネットワークのツールも、マルウェアや従来型のコマンド&コントロール通信を伴わず承認済みのAPI経由でアクティビティが発生するため、不審な動きを検知できない可能性があります。

成熟したSIEM（セキュリティ情報およびイベント管理）プログラムであっても、新規のアプリ許可、リスクのあるスコープ、異常なトークンの動き、同意後のAPI挙動の大きな変化を専門に監視していなければ、このリスクを見逃す可能性があります。

多くのIDプログラムは、MFAの導入状況、ブロックされたリスクの高いサインイン、特権アカウントの保護状況を追跡しています。これらの管理策は重要ですが、次の重要な問いには答えていません。「誰がサードパーティアプリケーションに企業データへのアクセスを許可できるのか、そしてその同意が悪用された場合、どれだけ早くそれを検知できるのか」という問いです。

組織がSaaSプラットフォーム、クラウドコンソール、ソースコードリポジトリ、自動化ツール、生産性向上アプリケーションへの依存を強めるほど、この問いの重要性は増します。すべての連携リクエストは、利便性に関する判断であると同時に、セキュリティ上の判断でもあります。

カレンダーへのアクセスを承認することと、メール全般、ファイル、リポジトリ、あるいは管理者権限への広範なアクセスを承認することとは、まったく別の話です。

1つ目の対策は同意のガバナンスです。組織は、サードパーティアプリケーションに対するユーザーによるデフォルトの承認を制限すべきです。

リスクの高いスコープには管理者の承認を必須とすべきです。未検証または馴染みのないアプリはブロックするか、レビュープロセスを経由させるべきです。セキュリティチームは、メール、ファイルストレージ、ソースコード管理、CRM、ID管理システム、クラウドコンソール、自動化プラットフォームなど、より厳格な同意管理を必要とする重要度の高いプラットフォームを特定する必要があります。

すべての連携をブロックすべきというわけではありません。しかし同意は、ユーザーが数秒で理解することを期待される単なるポップアップとして扱うのではなく、アクセス権と同じくらい慎重に管理されるべきです。

2つ目の対策はスコープの規律です。広範な権限は利便性が高い一方で、OAuthの悪用も可能にしてしまいます。

カレンダー連携アプリに広範なファイルアクセス権は不要なはずです。レポート用コネクタにリポジトリの管理者権限は必要ないはずです。明確な業務上の必要性と責任を持つ担当者がいない限り、ワークフローツールに組織全体にわたる権限を与えるべきではありません。

セキュリティチームは、ファイアウォールルールや特権ロール、本番環境アクセスと同じくらい厳格に、OAuthのスコープをレビューすべきです。スコープは具体的で、正当な理由があり、文書化され、定期的に再検証されるべきです。

3つ目の対策は同意後の監視です。検知はログインイベントの時点で終わらせてはいけません。

重要なシグナルとしては、新規のアプリケーション同意、新しいサービスプリンシパルやエンタープライズアプリの登録、高権限スコープの承認、通常とは異なる場所からの認可、馴染みのないインフラからのリフレッシュトークンの活動、そしてユーザーの通常の行動パターンから逸脱したAPI挙動が挙げられます。

普段は数件のドキュメントを閲覧するだけのユーザーが、突然大量のダウンロードやリポジトリの変更、メールボックスの検索、CI/CDの更新を行った場合、たとえセッションが認証済みであっても調査の対象とすべきです。

優先すべきは、玄関先での認証だけでなく、認可後の挙動を監視することです。

4つ目の対策は取り消し対応の準備です。多くの組織は不審なOAuth許可を特定できても、それを迅速に取り消すための効率的なプロセスを備えていません。

インシデント対応のプレイブックには、該当アプリケーションの特定方法、誰が同意したかの確認、付与されたスコープのレビュー、アプリの許可の取り消し、対応可能な場合のリフレッシュトークンの無効化、漏えいしたシークレットのローテーション、連携している各SaaSシステム全体での波及的な活動の確認まで含めるべきです。

このプロセスは、インシデントが発生する前にテストしておくべきです。実際の侵害が発生してからトークンの取り消しやアプリ許可のクリーンアップ方法を検討し始めるのは誤りです。

ユーザー教育も、より具体的な内容へと進化させる必要があります。「URLを確認しましょう」という助言は、そのURLが正規のものである場合には不十分です。

ユーザーは、同意画面の表示自体がセキュリティ上の判断であることを認識すべきです。重要な問いは「これはMicrosoft、Google、GitHub、Salesforceなのか」だけではありません。より適切な問いは、「このアプリはなぜこの権限を必要としているのか、誰が公開しているのか、そして自分の組織はこれを承認しているのか」です。

この教訓は従来のフィッシング対策啓発よりも習得が難しいものですが、今や必要不可欠です。

認証はゴールではない

重要な結論は明確です。IDセキュリティは認証だけにとどまらないということです。

SaaSに大きく依存する環境では、認可に関する判断が、盗まれた認証情報と同じくらい効果的に持続的なアクセスを可能にしてしまいます。MFAは不可欠ですが、OAuthガバナンス、最小権限のスコープ設定、同意の監視、迅速な取り消しの代わりにはなりません。

次の侵害は、ログイン失敗から始まるのではなく、ログイン成功と「許可する」への何気ない1回のクリックから始まるかもしれません。