Rajan Kapoor(Material Security社 VP Security)著
この2ヶ月間、私はVercel侵害とComposio侵害について、それぞれ個別に取り上げてきました。両者はそれぞれ単独でも学ぶべき教訓を提供してくれます。しかし2つを併せて読むと、私はいつも同じ結論に行き着きます。これらは孤立した事件ではないのです。
両者は実質的に同じ攻撃が、異なる標的に対して2度実行されたものであり、いずれもメールが侵入口ではありませんでした。このパターンをいったん明確に見て取れば、防御すべき対象についての考え方が変わってきます。
同時に、私がずっと考え続けている不都合な問いも浮かび上がります。ここで述べているパターン、すなわちOAuth権限を用いてアカウントにアクセスし、メールやDriveから機密データを読み取り、そのアクセス権を足がかりにワークスペースの外へと展開していく手口は、攻撃者の行動を説明するだけにとどまりません。これは、AIエージェントが設計上、日常的に行っていることの説明にもますます当てはまるようになっているのです。
この議論に入る前に、まずはワークスペースの攻撃チェーンを整理しておきましょう。
旧来のメンタルモデル:危険はメールにある
過去10年のほとんどの期間、ワークスペースセキュリティにおいて主流だったメンタルモデルは、おおよそ次のようなものでした。メールは危険な経路であり、Google Workspaceのそれ以外の部分は比較的安全である、というものです。
攻撃者が主にフィッシングを通じて認証情報を盗もうとしていた時代には、このモデルは理にかなっていました。しかし今ではもはや通用しません。なぜなら攻撃者は、受信トレイから侵入するだけでなく、ワークスペース内を次々と連鎖的に渡り歩く術を身につけたからです。
多くのセキュリティチームにおなじみのモデルは、おおよそ次のようなものです。
- メールが侵入口: ほとんどの攻撃は、悪意あるメール(フィッシングリンク、武器化された添付ファイル、巧妙な口実、あるいはAIエージェントを誤誘導する目的のプロンプトなど)から始まります。
- 認証情報の窃取: 攻撃の結果、有効な認証情報が盗まれ、アカウント乗っ取りが発生します。
- GmailとDrive内の機密データへのアクセス: 乗っ取りが成立すると、攻撃者は容易にGoogle Workspace内の連携アプリへと飛び移ります。
- 横展開: 受信トレイに侵入した攻撃者は、パスワードをリセットし、マジックリンク経由でさらに別のアプリへと侵入できます。
- 持続的アクセスの確立: 攻撃者は数日、数週間、あるいは数ヶ月にわたってアカウント内に検知されずにとどまり、複数のシステムから静かにデータを窃取し続けます。
これらを総合すると、広く認識されている悪夢のシナリオ、すなわちアカウント乗っ取り(ATO)の姿が浮かび上がります。ワークスペースの攻撃チェーンは、メールを介したID侵害から始まり、そこから拡大していくのです。
進化する攻撃チェーン:OAuthが侵入口となる
ワークスペース攻撃チェーンを構成する要素自体は変わっていませんが、攻撃が展開していく順序は進化しています。私がVercel、Composio、そして現在追跡を続けている件数を増しつつあるインシデント群で目にしてきた一連の流れは、そもそもメールから始まってすらいません。
その代わりに、筋書きが逆転し、OAuthトークンがメールへの侵入口となる、つまり従来とは順序が反対になっているのです。
これらの攻撃は、次のような様相を呈していました。
- OAuthが侵入口: これらの攻撃は、盗まれたOAuthトークンを通じて持続的アクセスを確立するところから始まりました。こうしたトークンはパスワードリセットを経ても生き残り、期限切れになることもなく、検知が困難です。ユーザーからは見えず、アプリの挙動を監視していないセキュリティチームにとってもほぼ見えない存在です。さらに恐ろしいことに、盗まれたトークンはサプライチェーン攻撃そのものです。サプライヤーが侵害され、その結果として自社環境へのアクセスが得られてしまうのです。
- 機密データへのアクセス: 盗まれたトークンを使い、攻撃者はGmailとDriveに保存されたデータにアクセスできました。
- メールアカウントの乗っ取り: ATOは当初、メールではなくOAuthを起点に実行されます。メールへのアクセスによって、侵害された受信トレイが、はるかに広範なインシデントへと変貌するのです。
- 横展開: Driveに保存された認証情報と、メール経由のパスワードリセットやマジックリンクを組み合わせることで、攻撃者は連携システム間を横方向に移動できます。
ワークスペース攻撃チェーンを構成する要素自体は今後も一貫したものであり続けると予想されますが、脆弱性を嗅ぎ分けて取り組みを拡大するAIツールを備えた攻撃者は、これらの要素を組み合わせ直す新たな方法を見つけ続けるでしょう。
このOAuthを中心とした攻撃は、こうした進化を示す一例に過ぎません。
同じ連鎖、異なる行為主体
ここで、先ほど説明した4段階の連鎖を念頭に置きながら、視点を切り替えてみましょう。
従業員たちは今この瞬間も、AIエージェントをGoogle Workspaceに接続しています。それらのエージェントは正規に認可されており、正当なOAuth権限を用いて、メールを読み、Driveを検索し、実在するユーザーに代わって実務を遂行しています。多くの組織において、この動きはセキュリティチームが把握できる速度を上回って進行しています。
AIエージェントが予期しない挙動を示すとき、たとえば指示があいまいだった、開発者が想定していなかった推論の連鎖をたどった、あるいは環境内で遭遇したコンテンツを通じてプロンプトを与えられてしまった、といった理由によって、そのエージェントは攻撃者とまったく同じ経路をたどることがあります。
- 本来到達すべきでなかった受信トレイやDriveフォルダにアクセスしてしまう。それは、権限の範囲がタスクに必要な範囲を超えて広すぎたためです。
- メールスレッド内の認証情報や、共有ドライブ内の機密文書といった機密性の高いコンテンツを読み取り、その情報を利用してしまう。
- そのアクセスの延長線上で行動を起こす。メッセージの送信、リンクのクリック、別のサービスへのリクエスト送信などです。
- 複数のアプリケーション間を横方向に移動し、結果として機密情報が第三者へと流出してしまう。
そこに悪意ある行為者はいません。侵害された認証情報もありません。ただ、それを止めるだけの制御機構が備わっていない環境の中で、エージェントが運用者の意図しない何かをしてしまっただけなのです。
この事実が防御の考え方にとって重要な理由
AIエージェントセキュリティをめぐる議論の多くは、プロンプトインジェクションの防止、エージェントの挙動に対するレッドチーム演習、あるいは従業員が接続しているアプリの点検といった枠組みで語られます。これらはいずれも現実の課題であり、取り組む価値があります。
しかし、私がここで述べている脅威は、エージェントが武器化されるという話ではありません。エージェントが本来設計されたとおりに正確に動作しているにもかかわらず、その種の行為主体を想定してガードレールが設計されていない環境が問題なのです。
過剰な権限を与えられた環境で行動する人間の運用者であれば、常識と社内の規範・ポリシーへの理解を組み合わせて、たいていはこの状況をうまく乗り切る術を心得ているものです。
AIエージェントに付与されたOAuthトークンは、人間に付与されたトークンとまったく同じアクセス権を持ちます。しかしエージェントは、行動を起こす前に自分が過剰な権限を与えられていることを理解しません。単にタスクを遂行するために必要なことを、そのまま実行するだけなのです。
ここで重要になる制御は、エージェントそのものに対する制御ではありません。エージェントが動作する環境に対する制御です。
メールとDriveのどこに機密データが存在するかを把握していれば、エージェント(あるいは攻撃者)がそこにたどり着く前に、アクセスを制限するポリシーを適用できます。OAuth権限を調査していれば、攻撃者や暴走したエージェントの詮索の目にさらされる範囲を理解し、制限することができます。
パスワードリセットリンクを秘匿化し、機密性の高い受信トレイのコンテンツを読み取り可能にする前に段階的な検証を要求できれば、そのコンテンツにアクセスしようとしている主体が攻撃者なのか、意図した範囲を逸脱して動作しているエージェントなのかは問題になりません。
最新の攻撃チェーンを防ぐのと同じ防御網が、最新のエージェントリスクからも組織を守ります。両者は姿形こそ違えど、同じ問題なのです。
チェーン全体を通じた防御のあり方
私は、このチェーンの各段階に個別のポイントソリューションを追加していくことが答えだとは考えていません。答えは、このチェーンを一つの連鎖として理解し、メール、OAuth、Drive、アカウントの挙動全体を横断的に把握し、3段階目や4段階目で事態が悪化する前に点と点を結びつけられる、包括的なカバレッジにあると考えています。
それこそが、私たちMaterialで構築してきたものです。私たちのカバレッジが各段階にどう対応するかを以下に示します。
最初のメールペイロードを阻止する。私たちのメールセキュリティは、既存の防御機構が見逃すもの、すなわち巧妙なフィッシング、レピュテーションベースのフィルタを回避するペイロード、中間者攻撃(attacker-in-the-middle)の手口を捕捉するよう設計されています。悪意ある脅威に対しては、最も一般的な攻撃手法を発端の段階で食い止めることが、依然として最も費用対効果の高い介入策です。
不審なOAuthの挙動を検知する。Materialは、どのようなアプリが存在し、どの権限スコープを保持しているかを単に一覧化するだけにとどまりません。
このプラットフォームは、アプリが実際に何を行っているかを監視します。何を読み取り、いつ読み取り、その挙動が時間とともにどう変化するかです。OAuthトークンが攻撃者に利用されている場合であれ、意図した範囲を逸脱して動作するAIエージェントに利用されている場合であれ、アクティビティ層における異常な挙動が危険を浮かび上がらせます。
保存された機密データを検知し保護する。目に見えないものは保護できませんし、存在すら把握していないアクセスに対してポリシーを設計することもできません。
Materialのファイルセキュリティは、メールとDrive全体にわたって機密データがどこに存在するかを可視化します。どの共有ドライブが広範なアクセス権を持っているか、どのメールスレッドに認証情報や個人識別情報(PII)が含まれているか、どのDriveフォルダが意図した閲覧対象を超えて公開されているか、といった情報です。これは、人間であれ自動化された主体であれ、あらゆる行為者に対して最小権限アクセスを徹底するための基盤となります。
パスワードリセットを経由した横展開を阻止する。Materialは、パスワードリセットリンクを含む機密性の高いメッセージ内容を秘匿化し、そのコンテンツにアクセス可能になる前に段階的な検証を要求できます。
受信トレイへのアクセス権を持つ攻撃者であっても、リセットリンクが平文で入手できなければ、それを足がかりとして利用することはできません。何かしらの行動対象を求めて受信トレイにたどり着いたAIエージェントも、同じ制限に直面することになります。
このパターンは繰り返される
Vercel。Composio。このリストは今後も伸び続けると私は予想していますし、次に加わる事例が必ずしも「外部の攻撃者」という分類にきれいに収まるとは限らないだろうとも考えています。
その中には、AIエージェントが予期せぬ行動を取るケースも含まれるでしょう。過剰な権限を与えられた連携アプリが、本来アクセスすべきでなかったデータに手を伸ばしてしまうケースもあるはずです。その裏にある物語が異なっていても、手口そのものは見覚えのあるものになるでしょう。
正しい対応は、AIエージェントに対して警戒感をあらわにすることでも、導入のペースを落とすことでもありません。エージェントは実際に有用であり、その生産性向上の効果は本物です。
正しい対応は、こうしたエージェントが動作するワークスペースには、OAuth認証されたソフトウェア(認可の有無を問わず)が自社環境における一級の行為主体となる世界にふさわしい制御が必要だと認識することです。
もし貴社のGoogle Workspaceセキュリティ戦略が受信トレイで止まっているなら、そこには抜け穴があります。その抜け穴こそ、まさに最新の攻撃チェーンが走り抜ける場所であり、意図した範囲を逸脱して動作するAIエージェントもまた、まさにそこを走り抜けることになるのです。
貴社の環境においてチェーン全体をカバーするワークスペース防御がどのようなものになるか話を聞きたい方は、 Material Securityまでお問い合わせください。
