サプライチェーン攻撃の深刻な現実：1 つの盗まれたベンダーキーで顧客データが晒される

サードパーティへの侵害が、複数の組織へ同時アクセス経路を開いた事例。Sentra の検知により、被害発覚までの時間は24 時間未満でした。 著者：Sagy Drucker, Asaf Rozali, Riva Kranz（Sentra）

---

1. 事件の概要と背景

• 広範なサプライチェーン攻撃
  • Qubole という大規模データプラットフォームを利用している数十社の顧客が影響を受けました。
  • 攻撃者は企業を直接突破せず、すべての企業が信頼するベンダー（Qubole）を通じて侵入しました。
  • 攻撃者は Qubole に付与された認証情報を入手し、静的に顧客データを転出（pull）しました。
• リスクの本質
  • クラウド環境には「人間」ではなく**「アイデンティティ」**として機能するものが多数存在します。
  • これらはすべてデータへの常時アクセス権を持っており（ベンダー連携、自動化スクリプト、AI エージェントなど）、普段と同じ場所・スケジュールからのアクセスが異変を起こすと危険です。
• 「忘れられた」接続先のリスク
  • 過去に接続したすべてのベンダーは、背後に「ドア（アクセス経路）」を残しています。
  • 多くのこうしたドアは今も開いたままあり、監視されず、最も機密性の高いデータにアクセス可能な状態にあります。

2. 攻撃の具体手順と成果

• 侵入速度
  • Qubole の信頼関係を有するロールを仮装して利用するのは約 1 秒。ほぼ瞬時に企業間を移動しました。
• 収集された情報量
  • 7 分以内に 3 つの異なる保管場所から、約100 のパスワードや鍵を読み取りました。
  • さらに攻撃者がダウンロードしたファイル内に含まれる数千件の認証情報レコードも入手しました。
• 書込み操作ゼロ（Read-Only）
  • 何らデータを変更・削除する行為は行われず、すべてが「盗み出し」に留まったため、発見されにくい状況を作っていました。

3. 攻撃の経路：有効な認証情報からの侵入

• 設定の正しさとアクセス権限
  • 被害組織は粗忽者ではありませんでした（AWS の推奨手順、外部 ID 設定など）。
  • ただし、Qubole 関連のロールは春以降不活性化しておりましたが、再び利用可能な状態にされました。
• ネットワーク由来の違い
  • すべてのアクティビティは Qubole 自体のネットワークからではなく、レンタルされた OVH サーバーおよび Mullvad VPN から発生しました。
  • 通常時と異なり、その期間中は通常の Qubole アクティビティは一切確認できませんでした。
• なぜこれほど危険なのか
  • 信頼できるベンダーが侵害された場合、ベストプラクティスの遵守だけでは不十分です。
  • 攻撃者のアクセス権限は本物であり、ログ上もすべて「正当」と見なされます。

4. 攻撃者の手法と隠れ蓑

• 慎重かつ段階的なアプローチ
  • 低価値のロールから開始し、周囲を窺察した後に大量ダウンロードを実行しました。
  • 最終的に生産環境のデータベースバックアップを抽出するまで、信頼関係を維持しつつ静かに行動しました。
  • アクティビティは停止し、攻撃者はアクセス権を失うことなく消えました。
• 認証情報の盗み出し経路
  • Secrets Manager: バッチで機密情報を抽出（CI/CD パイプライン、データベース認証情報など）。
  • SSM パラメータストア: 暗号化解除されたパラメータ（監視機能用の鍵など）を閲覧。
  • Lambda 環境変数: ルートがブロックされると即座に切り替え収集。
  • EC2 ユーザーデータ: 起動スクリプトから潜むトークンやパスワードをスクレイピング。

5. 調査プロセスと発見

• 追跡戦略
  • 流出サンプルの内容（ファイル名だけでなく）を既存のデータと比較し、ソースとなる S3 バケットを特定しました。
  • アクセス可能なアイデンティティは数百ありますが、その中で際立って多くを読み込めていたのはQuboleでした。
• 事実と仮定の区別
  • チームは AI を活用し、「証明された事実」と「合理的な仮定」の基準だけで判断し、誤った懸念を早期に排除しました。
• 何が発生したかの検証方法
  • 多くのクラウドストレージではデフォルトでファイル読み取りログが残らないため、以下の 3 視点から再構成しました：
    1. 暗号化ログ: ファイルをダウンロードすると解読処理があり、そのログが流出ファイルの特定に役立ちました。
    2. 機密情報自体: 盗まれたパスワードや鍵の記録が残っていたため、必要な対応リストを作成できました。
    3. ファイルアクセスログ: ログ有効化地点では IP アドレスとセッション情報が付与され、数百万件のファイルに対しても一致しました。

6. 迅速な対応と被害封じ込め

• 1 ヶ月ではなく 1 日で完了した理由
  • Sentra はすでに顧客の機密データを発見・分類していたため、流出サンプルを追跡してソースに戻すことができました。
  • 侵害発生前からリスク（不使用だがアクセス可能なロール）を特定し警告しており、異常な振る舞いの検知に有利でした。
• 被害者に提示された 5 つの行動指針
  1. Qubole の取り除き: 信頼しているすべてのロールから Qubole を排除する。
  2. 機密情報のローテーション: 読み取られたすべての機密情報を更新・再発行する。
  3. 攻撃者の IP アドレスのブロック。
  4. ログの保存: 期限切れになる前にログを適切に保全する。
  5. Qubole への連絡。

7. 対策と推奨事項：忘れられたドアを閉じる

• ゼロトラストアプローチの適用
  • アクセス範囲を本当に必要なデータのみへ限定します（キーが盗まれても被害を最小化）。
  • 不活性化している特権的外部ロールは「監視する」のではなく、削除すべきです。
• 具体的な対策アクション
  • 継続的な機密データ発見: クラウド、SaaS、AI 環境全体で自動特定・分類。
  • アイデンティティとデータのマッピング: 従業員、ベンダー、AI エージェントがアクセスできるデータを可視化。
  • 不活性アクセスの整理: 使用されていないサードパーティ連携を即座に無効化。
  • リアルタイム異常検知（DDR）: アクセスパターン変化を瞬時に検知・警告。
  • 迅速なインシデント封じ込め: 事前に分類されたデータ文脈を活用し、数時間以内に被害範囲特定。

まとめ

今回の事例では、単一のベンダー侵害が多数の組織に波及しました。Sentra は調査を「空白の紙」ではなく**「プレイブック（標準手順書）」**から始めており、1 ヶ月かかるべき調査を 1 日で完了させました。 現在、どの外部アイデンティティが貴社の機密データをアクセス可能にしているかを可視化し、過剰な権限を削減するための支援を提供しています。

重要: 今日から、どの外部アイデンティティが貴社の機密データをアクセス可能にしているかをご確認になりたいですか？デモのご予約をお受けいたします。