現代の攻撃チェーン：AI時代のGoogle Workspaceセキュリティの再考

Material Security セキュリティ担当副社長、ラジャン・カプール

この2ヶ月間、私はVercelの侵害事件とComposioの侵害事件について、それぞれ別々に記事を書いてきました。どちらの事例も、それ自体で学ぶべき教訓があります。しかし、これらを併せて読むと、私はいつも同じ考察にたどり着きます。これらは孤立した事件ではないのです

これらは、異なる標的に対して2回実行された同一の攻撃であり、いずれの場合もワークスペースへの侵入経路として電子メールは利用されていません。そして、このパターンを明確に把握すれば、防御すべき対象についての考え方が変わってくるのです。

また、これは私がずっと抱えてきた、気まずい疑問も浮き彫りにします。 私が説明しているこのパターン――OAuthグラントを利用してアカウントにアクセスし、メールやドライブから機密データを読み取り、そのアクセス権を利用してワークスペースの境界を越えていく――は、単に攻撃者が行う行為を説明しているだけではありません。これは、設計上、AIエージェントが日々行っていることをますます如実に表しているのです。

その議論に入る前に、少し時間を取ってワークスペースへの攻撃チェーンを整理してみましょう。

従来の認識：危険はメールにある

過去10年の大半において、ワークスペースのセキュリティに関する主流の認識モデルは、おおむね次のようなものでした。つまり、メールこそが危険な経路であり、Google Workspace内の他のすべては比較的安全であるというものです。

このモデルは、攻撃者が主にフィッシングを通じて認証情報を盗もうとしていた時代には理にかなっていました。しかし、攻撃者が受信トレイ経由で侵入するだけでなく、ワークスペース内を連鎖的に突破する方法を学んだ今、このモデルはもはや成り立ちません。

ほとんどのセキュリティチームが慣れ親しんでいるモデルは、次のようなものです：

• メールが侵入点： 悪意のあるメール （フィッシングリンク、悪用された添付ファイル、説得力のある口実、AIエージェントを誤った方向へ誘導するためのプロンプトなど）が 、ほとんどの攻撃の始まりとなります。
• 認証情報が盗まれる：攻撃の結果、有効な認証情報が盗まれ、アカウント乗っ取りが発生します。
• GmailやDrive内の機密データへのアクセス：アカウント乗っ取りが発生すると、攻撃者はGoogle Workspace内の連携アプリへ容易に侵入します。
• 横方向の移動： 受信トレイ内に侵入した攻撃者は 、パスワードをリセットしたり、「マジックリンク」を介して他のアプリに侵入したりすることができます。
• 持続性の確立：攻撃者は 、数日、数週間、あるいは数ヶ月間、アカウント内に検知されることなく潜伏し、システム間で静かにデータを持ち出すことができます。

これらを総合すると、これは「アカウント乗っ取り（ATO）」として広く認識されている悪夢のようなシナリオとなります。Workspace への攻撃チェーンは、メールを介した ID の侵害から始まり、そこから拡大していきます。

進化する攻撃チェーン：OAuthが侵入の入り口

ワークスペース攻撃チェーンの構成要素自体は変わっていませんが、攻撃が展開される順序は進化しています。私がVercelやComposio、そして追跡している増え続けるインシデントで目撃してきた一連の流れは、そもそもメールから始まるものではありません。

むしろ、シナリオが逆転し、OAuthトークンがメールへの侵入経路となっているのです。その逆ではありません。

こうした攻撃の様相は以下の通りです：

• OAuthが侵入経路：これらの 攻撃は、盗まれたOAuthトークンを通じて持続性を確立することから始まりました。これらのトークンはパスワードのリセット後も存続し、有効期限がなく、検知が困難です。ユーザーには見えませんし、アプリの動作を監視していないセキュリティチームにとっても、ほとんど検知できません。さらに恐ろしいのは、盗まれたトークン自体がサプライチェーン攻撃の一環であるという点です。 サプライヤーが侵害され、その結果として攻撃者が貴社の環境にアクセスできるようになります。
• 機密データへのアクセス：盗まれたトークンを使用して、攻撃者はGmailやDriveに保存されたデータにアクセスすることができました。
• メールアカウントの乗っ取り：ATO（アカウント乗っ取り）は 当初、メールではなくOAuthを使用して実行されます。メールへのアクセスにより、侵害された受信トレイは、はるかに広範なインシデントへと発展します。
• 横方向の移動：Driveに保存された認証情報と、メール経由のパスワードリセットや「マジックリンク」を組み合わせて、攻撃者は接続されたシステム間を横方向に移動することができます。

ワークスペース攻撃チェーンの構成要素自体は一貫して変わらないと予想されますが、脆弱性を嗅ぎ出し、攻撃規模を拡大するためのAIツールを駆使する攻撃者たちは、それらを再組み合わせる方法を模索し続けるでしょう。

こうしたOAuthを中心とした攻撃は、この進化の一例に過ぎません。

同じ攻撃チェーン、異なる攻撃者

それでは、先ほど説明した4段階のシーケンスを念頭に置きつつ、視点を変えてみましょう。

今この瞬間も、御社の従業員はAIエージェントをGoogle Workspaceに接続しています。それらのエージェントは認証済みであり、正当なOAuthグラントを使用しています。メールを読み、Driveを検索し、実際のユーザーに代わって実際の業務を行っています。多くの組織において、こうした動きはセキュリティチームが追跡できる速度を上回る速さで進行しています。

AIエージェントが予期せぬ動作をした場合――指示が曖昧だったため、開発者が想定していなかった推論の連鎖をたどったため、あるいは環境内で遭遇したコンテンツを通じてプロンプトが与えられたため――それは攻撃者と同じ道をたどる可能性があります：

• タスクに必要な範囲を超えてアクセス権限が与えられていたため、本来アクセスする意図がなかった受信トレイやドライブのフォルダにアクセスしてしまう。
• メールスレッド内の認証情報や共有ドライブ内の機密文書といった機密コンテンツを読み取り、その情報を悪用する。
• そのアクセスに続いて、メッセージの送信、リンクの追跡、別のサービスへのリクエストといったアクションを実行します。
• アプリケーション間を横方向に移動し、機密情報が最終的に第三者に流出してしまう。

悪意のある攻撃者も、侵害された認証情報もありません。単に、それを阻止する制御が施されていなかった環境において、オペレーターの意図とは異なる行動をとったエージェントがいるだけです。

これが防御策の考え方においてなぜ重要なのか

AIエージェントのセキュリティに関する議論の多くは、プロンプトインジェクションの防止、エージェントの挙動に対するレッドチーム攻撃、あるいは従業員が接続しているアプリの確認といった点に焦点が当てられています。これらは現実の問題であり、解決すべき課題です。

しかし、私が説明している脅威は、エージェントが武器化されることに関するものではありません。それは、そのようなアクターを想定して設計されていない環境において、エージェントが本来の動作通りに動作してしまうという問題なのです。

過剰な権限が与えられた環境で行動する人間のオペレーターは、一般的に、常識と会社の規範やポリシーへの理解を組み合わせて、この状況を乗り切る方法を知っています。

AIエージェントに付与されたOAuthトークンは、人間に付与されたトークンと同等のアクセス権を持ちますが、エージェントは行動を起こすまで、自分に過剰な権限が与えられていることを理解できません。エージェントは単に、タスクを実行するために必要なことを行うだけです。

ここで重要な制御は、エージェントに対するものではなく、エージェントが動作する環境に対するものです。

メールやドライブ内の機密データの保存場所を把握していれば、エージェント（または攻撃者）がそこに到達する前に、そのデータへのアクセスを制限するポリシーを適用できます。OAuthの権限付与を調査すれば、攻撃者や誤動作したエージェントによる不正アクセスへの曝露を理解し、制限することができます。

パスワードリセットリンクを非表示にし、機密性の高い受信トレイの内容が閲覧可能になる前に追加の認証を義務付けることができれば、そのコンテンツにアクセスしようとしている主体が攻撃者であろうと、本来の権限範囲外で行動しているエージェントであろうと、問題にはなりません。

現代の攻撃チェーンから防御する仕組みは、現代のエージェントによるリスクからも同様に防御します。これらは、異なる側面を持つ同じ問題なのです。

チェーン全体にわたる防御のあり方

このチェーンの各段階に、さらに多くのポイントソリューションを追加することが答えだとは思いません。答えは、チェーンを「チェーン」として捉え、メール、OAuth、ドライブ、アカウントの挙動全体で何が起きているかを把握し、ステップ3や4で問題が発生する前に点と点を結びつけることができる防御策にあると考えています。

Materialでは、まさにそのような防御体制を構築しました。各ステップに対する当社の防御範囲は以下の通りです：

初期のメールペイロードをブロックする。当社のメールセキュリティは、ネイティブの制御機能では検知できないもの――高度なフィッシング、レピュテーションベースのフィルターを迂回するペイロード、中間者攻撃の手法――を捕捉するように設計されています。最も一般的な攻撃手法を未然に阻止することは、悪意のある脅威に対する最も効果的な対策であり続けています。

不審なOAuth動作の検出。Materialは、単にどのアプリが存在し、どのようなスコープを保持しているかをリストアップするだけにとどまりません。

当プラットフォームは、アプリが実際に何を行っているか――何を読み取り、いつ読み取り、その動作が時間の経過とともにどのように変化するか――を監視します。OAuthトークンが攻撃者によって悪用されているか、あるいは意図されたパラメータの範囲外で動作するAIエージェントによって使用されているかに関わらず、アクティビティ層における異常な動作が危険性を浮き彫りにします。

保存中の機密データの検出と保護。「見えないものは守れない」というように、存在すら知らないアクセスに対してポリシーを策定することは不可能です。

Materialのファイルセキュリティ機能により、チームはメールやDrive全体にわたって機密データがどこに存在しているかを可視化できます。どの共有ドライブに広範なアクセス権が設定されているか、どのメールスレッドに認証情報や個人識別情報（PII）が含まれているか、どのDriveフォルダが想定された閲覧対象者以外にも公開されているかなどが把握できます。これが、人間であれ自動化されたアクターであれ、あらゆる主体に対して最小権限のアクセスを徹底するための基盤となります。

パスワードリセットを介した横方向の移動を阻止します。Materialは、パスワードリセットリンクを含む機密性の高いメッセージ内容を伏せ字処理し、そのコンテンツにアクセスする前に追加の認証を要求することができます。

受信トレイへのアクセス権を持つ攻撃者であっても、リセットリンクが平文で表示されていなければ、それを足掛かりとして利用することはできません。何か行動を起こすための材料を探して受信トレイに到達したAIエージェントも、同様の制限に直面します。

このパターンは今後も繰り返されるでしょう

Vercel。Composio。このリストは今後も増え続けると予想され、次に追加される項目が必ずしも「外部の攻撃者」というカテゴリーにすっきりと当てはまるとは限らないでしょう。

その中には、AIエージェントが予期せぬ行動をとるケースもあれば、本来アクセスすべきではないデータに到達してしまう過度な権限が与えられた統合機能に関わるケースもあるでしょう。その背景となるストーリーが異なっていても、そのメカニズム自体は見覚えのあるものになるはずです。

適切な対応は、AIエージェントを過度に警戒したり、導入を遅らせたりすることではありません。エージェントは真に有用であり、生産性向上の効果は実証されています。

正しい対応とは、それらのエージェントが動作するワークスペースには、OAuth認証されたソフトウェア（承認済みか否かを問わず）が環境内で第一級のアクターとして機能する世界にふさわしい制御が必要であることを認識することです。

Google Workspaceのセキュリティ戦略が受信トレイだけで終わっているなら、そこには隙間があります。その隙間はまさに現代の攻撃チェーンが通る場所であり、意図された範囲外で動作するAIエージェントもまた、まさにそこを通り抜けることになるのです。

ご自身の環境において、ワークスペースを全チェーンにわたってカバーする体制がどのようなものかについて話し合いたい場合は、Material Securityまでご連絡ください。

本記事はMaterial Securityによる提供・執筆です。