観測基盤のクエリURL一発で他テナントへデータが吸い出される——GCP Cloud Logging/Log Analyticsの設計不備が示した境界の脆さです

今日の深掘りポイント

• ログ分析（可観測性）を担うCloud LoggingのLog Analyticsが、攻撃経路として機能してしまった新規性が高い事案です。
• ポイントは「URLで指定したBigQueryクエリがユーザー文脈で自動実行」され、「攻撃者側が被害者に権限を付与する」という“権限の逆流”トリックで結果を書き出せたことです。
• Googleは自動実行を停止し警告を追加して封じましたが、UIでの明示実行を誘うだけでも同等の目的を達成し得るため、運用・監視側の対策が依然として重要です。
• 多国籍企業では、攻撃者の用意したBigQueryデータセットのリージョン（例：US/EU）に強制的にデータが流出し、データ主権・域外移転の監査に波及します。
• 検知の要は「クロスプロジェクトの結果書き出し」と「クエリのリファラ/UI起点」を監査ログで結びつける視点です。

はじめに

Tenableが、Google Cloud Platform（GCP）のCloud Loggingに含まれるLog Analytics機能を悪用し、被害者組織のBigQueryデータを攻撃者プロジェクトへ流出させ得る欠陥を開示しました。要点は、Cloud LoggingのUIで共有可能なURLにSQLを埋め込むと、そのURLを開いたユーザーの権限でBigQueryクエリが自動実行され、クエリ内の書き込み先を攻撃者側に指定できてしまった、という動作です。Googleは既に自動実行の停止と警告メッセージの追加で修正を完了しています。Tenableの公開情報によると、報告は2025年11月、修正は2026年1月に完了しています［出典は参考情報参照］。

今回のポイントは、セキュリティ製品やデータ基盤ではなく、日々の運用を支える“可観測性の入り口（ログ分析UI）”が攻撃の踏み台になり得ることを、具体的な手順で示した点にあります。新規性も実務的な緊急度も高く、CISOやSOCにとっては、IAMや監査ログの「境界の張り方」を見直すべき合図になります。

深掘り詳細

事実（ファクト）——何が起き、Googleはどう封じたか

• 攻撃の骨子:
  • 攻撃者は自分のGCPプロジェクトにBigQueryデータセットを用意し、被害者のアカウント（ユーザー/サービスアカウント）にそのデータセットへの書き込み可能な権限（例：BigQuery Data Editorなど）を付与します。
  • その上で、Cloud LoggingのLog Analyticsで実行される形式のURLを作成し、SQL文に「被害者のBigQueryデータを読み出し、攻撃者のデータセットに書き出す」処理（例：CREATE TABLE attacker.dataset.t AS SELECT … FROM victim.project.dataset.table）を埋め込みます。
  • 被害者がURLを開くと、従来の挙動ではそのクエリが自動実行され、被害者の権限で読み出したデータが攻撃者プロジェクトに新規テーブルとして保存されます。
• 重要な前提:
  • 読み出しは「被害者自身の権限」で行われるため、攻撃者は被害者のデータに直接アクセス権を持つ必要がありません。
  • 書き込みは「攻撃者が事前に被害者へ付与した」権限によって成立します。つまり、通常想定する「被害者が攻撃者へ権限を渡す」図ではなく、攻撃者側から書き込み先プロジェクトへの権限を被害者に“与える”という逆転の発想です。
• Googleの対応:
  • クエリの自動実行を停止し、ユーザーに警告メッセージを表示するよう修正済みです。これにより、リンクを開いただけで意図せずクエリが走るリスクは抑制されました。
• 公開と修正のタイムライン:
  • 2025年11月にTenableが報告、2026年1月に修正完了と公表されています。

出典: Tenableの開示文書［参考情報］です。

インサイト（示唆）——なぜ成立し、どこに教訓があるか

• “権限の逆流”が生む予期せぬデータ移送:
  • 企業は「自組織側から外部へ権限を出さない」ことに注意を払いますが、本件は「外部（攻撃者）が自組織の主体に外部プロジェクトへの書き込み権限を与える」ことでデータが流れ出るという逆流モデルでした。IAMの境界思考を「誰が誰に権限を付与するか」だけでなく、「どの主体がどのリソースへ書ける状態になるか」に引き直す必要があります。
• 「URLで実行」の利便性と安全性のトレードオフ:
  • ログ分析UIの共有URLは、コラボレーションを加速させる一方、「ユーザー文脈でSQLを実行する」強力な機能でもあります。自動実行が止まった今でも、ユーザーにワンクリック実行を促すソーシャル工学の余地は残ります。利便性機能には「どの権限で何を実行するか」を明示・可視化するUIデザインが欠かせません。
• 監査・主権への波及:
  • BigQueryは書き出し先データセットのリージョンにデータを保存します。攻撃者がUSやEUなど別リージョンにデータセットを置けば、被害企業はデータ主権・域外移転違反の監査対応に追われます。技術的インパクトに加えてコンプライアンスの二次被害が大きい論点です。
• メトリクス全体観からの示唆:
  • 本件は新規性・即応性・実務適用性がいずれも高く、かつ成立確率も低くありません。可観測性基盤や“管理系UI”を防御外周とみなさず、攻撃面として扱うポリシー・監視・教育のセットを早期に適用すべき事案です。

脅威シナリオと影響

以下は仮説ベースのシナリオですが、実務的な検討材料として挙げます。MITRE ATT&CKは対応し得るテクニックの例示であり、実環境に応じて読み替えが必要です。

• シナリオA：標的型リンクでSRE/データアナリストを狙う
  • 手口: 攻撃者が「ログ分析の便利なクエリです」としてCloud Loggingの共有リンクをメールやチャットで送付。被害者が開いてクエリを実行すると、機微データが攻撃者プロジェクトにテーブル作成されます。
  • 該当し得るATT&CK:
    • T1566.002（フィッシング：リンク）
    • T1204.001（ユーザー実行：悪意あるリンク/ファイル）
    • T1526（クラウドサービス発見）※INFORMATION_SCHEMA等での列挙をクエリで同時に仕込む仮説です
    • T1567.002（外部Webサービスへの流出／クラウドサービス）※BigQuery上の他テナントへの書き出しを広義の外部サービス流出として位置付ける仮説です
• シナリオB：社内Wiki/チケットに“便利リンク”を埋め込み、継続的に吸い出す
  • 手口: 開発・運用ドキュメント内に、Log Analyticsの共有URLを貼り付け、運用者が参照するたびに（修正前は自動、修正後は押下誘導で）機密クエリを実行させる。
  • 影響: 継続的・断片的な抜き取りで発見が遅延。抜き取り先リージョンを変えることでコンプライアンス上の火種が増大。
• シナリオC：権限境界の盲点を突いた越境
  • 手口: 攻撃者は被害者主体（ユーザー/SA）を自分のBigQueryデータセットの“書き込み可能メンバー”に追加。組織側は“自組織外のプロジェクトに権限を付与された事実”を把握できないため、予兆検知が難しい。
  • 影響: 監査ログの観点では「被害者主体が正当に実行したBigQueryジョブ」に見えるため、通常の“不審な認証”や“権限昇格”では検知できません。

組織への影響は、データ流出（PII/知財/取引情報）の一次損害に加え、データ主権違反、リージョン規制違反、第三者移転に関する契約上の通知義務や罰金のリスクに波及します。特に多国籍企業は、BigQueryデータセットの地域的配置とアクセスフローの監査可能性を、今回を機に棚卸しすべきです。

セキュリティ担当者のアクション

“Googleの修正で終わり”にしないための、現実解を優先度順に整理します。

• 即応（24〜72時間）

  • 社内告知とユーザー教育の上書き:
    • Cloud Consoleの共有リンク（特に「console.cloud.google.com/logs/query」系）に対する取り扱い注意を全社周知します。リンクを開いた直後にクエリ内容と書き込み先を確認する、疑わしければ実行しない、を徹底します。
  • 監査ログのハイリスク探索（初動ハント）:
    • BigQueryの監査ログで以下の条件を横断チェックします（表現は概念的な条件です）。
      • 実行主体が人間ユーザー/汎用サービスアカウントで、configuration.query.destinationTable.projectIdが自組織のプロジェクト外（または自組織内でも予期せぬ他プロジェクト）。
      • referencedTablesのprojectIdとdestinationTable.projectIdが異なる。
      • 直近で大量行数/大容量（jobStatistics.totalBytesProcessed/totalBytesBilledが平常から大きく乖離）。
      • requestMetadata.callerSuppliedUserAgentやリファラにCloud Logging/Log Analytics UI由来が示唆される痕跡（仮説：実環境で要検証）です。
  • Cloud DLP/サードパーティDLPの一時スキャン:
    • 攻撃者側プロジェクトに生成された可能性のあるテーブル名パターンや時刻帯での漏えい推定をもとに、社内側データのDLPスキャンを強化します。

• 短期（1〜2週間）

  • VPC Service Controls（VPC SC）の適用評価:
    • BigQueryを含むサービス境界を構築し、「自組織のサービス境界外へのデータ移送」を抑止・監査する設計を検討します。VPC SCは“結果セットの外部書き出し”のようなデータ越境を包括的に抑制する際の有力な手段です（適用可否・制約は環境依存のため事前検証が前提です）。
  • 最小権限の再徹底（人間ユーザーのクエリ権限棚卸し）:
    • roles/bigquery.adminや広範なroles/bigquery.user/roles/bigquery.jobUserの付与状態を再点検し、機密データセットのクエリは“専用サービスアカウント経由”に収斂させます。人間ユーザー直実行を減らすだけで、ソーシャル工学の可動域は大幅に狭まります。
  • 結果書き出しポリシーのガードレール:
    • 機微データセットについては、結果テーブルの作成先を限定する運用標準（命名規則・承認フロー・専用プロジェクト）を設け、クエリレビューのチェックリストに「CREATE TABLE/INSERT…SELECT の宛先が自組織内適正か」を明記します。

• 中期（1〜3ヶ月）

  • 継続的検知のルール化とダッシュボード
    • 検知KPIを定義します。
      • クロスプロジェクト書き出し率（destとrefのプロジェクト相違ジョブの比率）
      • 高容量ジョブのUI起点割合（Logging UI/BigQuery UI/CLI/SDKなど起点別）
      • 実行主体別のクエリ宛先多様性（単一主体が短期間に複数プロジェクトへ書き出していないか）
    • しきい値超過でSOCチケット化し、問合せテンプレート（「リンクの入手経路」「クエリ実行時の意図」「宛先確認」）を整備します。
  • ブラウザ/メールの安全策（ソーシャル面の削減）
    • セーフリンク系のURL再書き換えで、実行前にランディングを解析・警告するCASB/SEG機能を活用します。Cloud Consoleドメインであっても“危険なクエリパラメータを含む”場合に警告するルールを試験導入します。
  • 可観測性基盤のガバナンス
    • ログ分析に用いるUI/ワークスペースを業務/検証/共有に分離し、「共有リンクは検証ワークスペースでのみ開く」などの運用境界を設定します。

• 留意事項（構造的な限界）

  • 「外部の攻撃者プロジェクトが自組織の主体へ権限を付与する」行為は、原理的に自組織側では阻止できません。したがって、検知は「自組織から外部へデータが出た痕跡（ジョブ実行結果）」に寄らざるを得ません。ここを“見える化”するために、監査ログの保全、長期保管、相関分析（UI起点・宛先・容量・実行主体）を優先投資すべきです。

参考情報

• Tenable Research: TRA-2026-06 — Cross-tenant BigQuery data exfil via GCP Cloud Logging Log Analytics（公開情報、報告/修正の時系列と技術詳細）: https://www.tenable.com/security/research/tra-2026-06

本件は、可観測性という“日常の道具”が攻撃面へ転じる瞬間を明確に示したインシデントです。利便性と安全性の張り合わせを怠ると、境界は思った以上に薄い——そんな当たり前を、私たちの運用にもう一度根付かせる契機にしたいです。今回の修正で直ちに致命的な自動実行は止まりましたが、攻撃者は次の一手を用意します。だからこそ、UIの一振りを“誰の権限で、どこへ書くのか”という視点で常に観察し続けることが、これからの強さだと考えます。