ドアだけでなくターゲットを守れ：Google Workspaceのための最新プラン

現代の仕事は1つのアプリの中だけで完結しません。メール、ファイル、チャット、そしてそれらの間でデータをやり取りするコネクタの網の目の中で行われています。だからこそ、Salesloft/DriftインシデントはGoogle Workspaceチームに大きな衝撃を与えました。誰も「Googleをハッキング」したわけではありません。攻撃者は信頼された連携を利用し、まさに欲しかったもの――データ――を手に入れたのです。

8月初旬、Salesforceの記録を盗んだのと同じ脅威アクターが、盗まれたDrift Emailトークンを使って、Driftと明示的に連携していた少数のGoogle Workspaceメールボックスにアクセスしました。

8月9日、Googleはこの活動を確認し、トークンを無効化し、連携を停止しました。これは、委任されたアクセスが通常の防御策を回避できることを端的に示しています。

アプリグラフが攻撃対象になるとき

ここ数年、ID管理の強化、多要素認証（MFA）の堅牢化、レガシープロトコルの廃止に取り組んできた方にとっては、不公平に感じるかもしれません。それらをすべて実施しても、正当な権限を持つサードパーティのトークンに敗北することがあるのです。

不都合な真実は、攻撃対象が今やアプリグラフ――OAuth許可やAPI権限の格子構造――になっていることです。

セキュリティの話は、もはやログインプロンプトが表示されたかどうかではありません。連携が一度許可されると、何ができるのかが問題なのです。

Salesloft/Driftで実際に顧客が感じたこと

情報公開後、私たちは顧客と話をしました。パニックではなく、冷静な評価が支配的でした。脅威リサーチチームは、侵害に関連するIOCを検出するための仕組みを構築しました。各チームはDriftの接続状況を把握し、アクセス権を整理し、キーをローテーションしました。

Materialを導入していれば、攻撃者の滞在時間はほとんど意味を持ちません。Materialのアカウント乗っ取り耐性は、保存中の機密メールデータを保護します。つまり、トークンでメールボックスにアクセスできても、最も機密性の高いデータには人間による追加認証が必要です。

これが「侵害前提」の考え方の実践です――誰かが最終的に正当なアクセス権を得ることを受け入れ、ターゲットがデフォルトで読めないようにするのです。

これは一度きりの出来事ではない

Salesloft/Driftは、より広いパターンに当てはまります。最近のSalesforce侵害の背後にいるグループは、エンドポイントのシェルを狙っているのではなく、トークンや正規のアクセス権を狙い、その隠れ蓑を利用しています。

手口はシンプルかつスケーラブルです：有効なトークンを使い、大量のクエリを実行し、データを持ち去る。同時期、攻撃者がエクスポートデータを漁ってクラウドのシークレットを探し、さらに攻撃を展開するのも目撃しました。

昨年のSnowflake攻撃も、ロゴが違うだけで同じ話でした。認証情報やトークンが大規模なデータ窃盗の手段となり、その後は同じような後処理――メールやファイルの中のシークレットを探し、キーをローテーションし、トークンをリセットし、アプリのアクセス権を再設定――が続きます。

こうした攻撃は当分なくなりません。異なるプラットフォームで発生しても、教訓は似ています。クラウドオフィスの境界防御だけではもはや十分ではありません――そして正直なところ、しばらく前からそうでした。クラウドワークスペース内のメール、ファイル、アカウントに侵入する方法が多すぎるのです。私たちのアプローチは、クラウドオフィス全体にわたる堅牢な検知・対応能力を含むよう進化しなければなりません。

「最新」クラウドワークスペースのレジリエンスに本当に必要なもの

では、この現実においてGoogle Workspaceのレジリエントなセキュリティとはどのようなものでしょうか？それは、重点の置き方を変えることから始まります。依然として外部からの脅威を防ぎますが、予防だけにビジネスを賭けるのはやめます。封じ込めとレジリエンスを設計します。

実際には、Workspaceを重要インフラとして扱うこと――独自のシグナル、障害モード、影響範囲を持つ独立した環境として、連携・ID・コンテンツの3層で保護することが必要です。

連携については、可視化とコントロールが仕事です。Gmail、Drive、Calendar、Admin APIにアクセスできるすべてのサードパーティアプリを棚卸しします。不要なものは削除し、必要なものは権限を絞ります。新たな高リスクの許可が現れたら、それが新しい管理者アカウントであるかのように監視します。実際、その通りだからです。

Driftのようなインシデントが発生した場合、まず一括でトークンを無効化・ローテーションし、その後調査します。ログに完璧な証拠が揃うのを待っていたら、すでに手遅れです。8月9日のプラットフォーム対応は迅速でした。社内対応も同じくらい迅速であるべきです。

IDについては、チェックリスト的なMFAを超えます。フィッシング耐性のある認証方式が今や必須です。IMAPやPOPのようなレガシープロトコルや、長期間有効なアプリ固有パスワードは排除しなければなりません。コンセントフィッシングやトークンリプレイは今後も続くと考えるべきです。

ID強化は必要ですが、それだけでは不十分です。アカウントの不審な行動を検知する能力は、単に異常なログインを検知するだけでなく、環境内での行動――データアクセスパターン、メールルール、ファイル共有行動など――の監視にまで及ぶ必要があります。

攻撃者は回避技術を進化させ、痕跡を隠すのが上手くなっています。こうした行動をリアルタイムで検知・対応できることが重要です。

決定的な層はコンテンツです。連携や盗まれたセッションで役員メールボックス内のすべてが読めてしまえば、他の対策は無意味です。しかし、メッセージレベルのMFAがあれば状況は一変します。機密スレッド、法的アーカイブ、規制対象メールは、人間がその場で意図と正当性を証明するまでロックされたままです。この設計だけで、盗まれたトークンは壊滅的な被害から単なる迷惑に変わります。また、他の対応――トークン無効化、キーのローテーション、クリーンアップ――の時間を稼げます。

しかし、これらのコントロールは、チームがプレッシャー下で使いこなせてこそ意味があります――さらに言えば、これらのコントロールが機械のスピードで自律的に動作できれば理想的です。つまり、Workspaceネイティブのテレメトリを活用し、リアルタイムで動作する自動化プレイブックが必要です。

これはつまり、侵害されたベンダーに紐づくアプリトークンの無効化、不審な行動をするアカウントの一時停止、新たなインジケーターに一致するメールの隔離、リスキーなDrive共有の取り消し、機密指定されたものを開く際の追加認証要求――これらを環境内で観測された時点で即座に実行できることを意味します。

Material Securityの役割

Materialは、まさにこの現実に即したGoogle Workspaceの運用のために設計されました。私たちは、メールとクラウドオフィスのセキュリティに現代的なアプローチで取り組むために創業しました。たとえ有効なトークンが手に入っても、Workspaceの悪用を困難にします。

私たちは、メッセージレベルのMFA、ジャストインタイムアクセス、リスクの高いDrive共有へのスムーズなコントロールで、最も重要なコンテンツを保護します。これにより、侵害された連携でも、最も機密性の高いメッセージやファイルを開くことはできません。

Gmail、Drive、Admin APIからのノイズの多いシグナルを正規化し、チームが迅速に行動できるアクションに変換します。また、OAuthガバナンスを最重要視します。危険な権限を持つアプリを可視化し、古くなったものを自動で無効化し、次のベンダーがトークン問題を公表した際にも広範囲に対応できます。

覚えておくべき教訓

連携は悪用されるものと想定しましょう。トークンは漏洩するものと想定しましょう。創造的な攻撃者は最短でデータにたどり着く方法を見つけるものと想定しましょう。そして、それらの想定がニュースにならないように設計しましょう。

Salesloft/Driftの出来事は、私たちが今後目にするサプライチェーンやトークン関連の話の最後ではありません。1か月後には、別のアプリ、別の権限、別のロゴかもしれません。

しかし、共通するのはこうです：防御はターゲットそのものを直接守り、誰かがいつか正面玄関をすり抜けることを前提にしたとき最も強固になります。その世界に備えれば、盗まれたトークンは侵害ではなく、単なる障害物に過ぎません。

Material Securityのアプローチについてさらに詳しく知り、目的特化型クラウドワークスペースセキュリティの実例をご覧ください。

スポンサー：Material Securityによる執筆。