2026年3月10日、TenableはGoogle Looker Studioにおける9件の脆弱性群を「LeakyLooker」として公開した。中核は、閲覧者権限からクエリ実行主体を乗っ取るクロステナントSQLインジェクション連鎖である。Google Cloud Security Bulletin（GCP-2025-053、2025年9月30日公開）は、共有レポート、閲覧者資格情報、Studio Linking API、Conversational Analyticsに起因する問題を修正済みとし、悪用の証拠は確認していないと述べている。本稿は「個別バグの列挙」ではなく、BigQuery/Spanner統合BIで再発しうる構造的攻撃面を技術的に分解する。

1. 9件の脆弱性群を攻撃チェーンとして読む

Tenableの公開情報では、LeakyLookerは0-click/1-click経路を含む9件で構成される。代表例として、batchedDataV2の入力処理不備を突くゼロクリック系（TRA-2025-28）、レポート複製時の保存済み資格情報継承を悪用する権限逸脱（TRA-2025-29）、Linking APIのds.*.sqlパラメータを悪用する1-click SQL実行（TRA-2025-37）が示されている。攻撃者視点では、これは別個の脆弱性ではなく、閲覧者コンテキスト→資格情報コンテキスト→データ平面へ段階的に遷移する連鎖である。

とくに重要なのは、最終的なSQLが被害者のBigQuery/Spanner権限で実行される点である。つまり被害規模はBI側の脆弱性単体で決まらず、接続先データ基盤のIAM設計、列・行レベル制御、課金上限設計まで含めた「下流の権限設計」で増幅される。

2. なぜクロステナント化したか: 境界設計の破綻点

Looker Studioのデータ資格情報モデルには、Owner's Credentials、Viewer's Credentials、Service Account Credentialsがある。BI製品としては合理的な柔軟性だが、複製、共有、リンク生成、埋め込み、対話機能が同時に存在する環境では、「誰の権限でクエリが発行されるか」の境界が急速に複雑化する。Tenableが示した問題は、この境界の複雑性に入力注入と状態継承が重なったケースである。

設計上の教訓は明確である。マルチテナントBIでは、テナント分離を「保存データの分離」だけで評価してはならない。実際には、(1) クエリ組立経路、(2) 資格情報の所有権遷移、(3) URL/API経由の暗黙的データソース生成、(4) ビューア機能が誘発するサイドチャネル、の4層を一体で検証する必要がある。

3. BigQuery/Spanner統合時に露出する実装上の弱点

BigQuery連携では、アナリスト利便性のために広いroles/bigquery.dataViewerやジョブ実行権限が付与されることが多い。この状態で実行主体が乗っ取られると、正規クエリとして監査ログに残りつつデータ抽出が成立する。さらにLeakyLookerでは「Cross Tenant Denial of Wallet Through BigQuery（TRA-2025-41）」が示す通り、機密性だけでなく課金面も攻撃対象になる。

Spanner連携でも同様に、DBレベルIAMに依存した粗い権限付与は被害面積を広げる。Googleが提供するFine-grained access control（FGAC）は、IAM主体とデータベースロールを結合し、テーブル・カラム・ビュー単位で権限を限定できる。BI統合時は「接続成功する最小権限」で止め、アプリ都合の広権限を避けることが要点である。

4. 防御設計: BIを特権プロキシとして扱う

対策は「BIを可視化層」と見なす発想を捨て、特権クエリプロキシとして扱うことから始まる。実装優先順位は次の通りである。

第一に、Looker Studio側ではOwner's Credentialsの利用範囲を最小化し、不要な共有レポートとデータソースを定期削除する。Viewer's Credentialsを使う場合は、公式仕様上ハイパーリンク/画像レンダリング制約があるため、業務要件と安全性を同時評価して選択する。

第二に、BigQuery側ではAuthorized Views、列レベルアクセス制御（Policy Tags）、行レベル制御を組み合わせ、BI実行主体が到達できる列と行を縮小する。第三に、Spanner側ではFGACのデータベースロール運用へ寄せ、DBレベルIAMの過剰権限を段階的に削る。第四に、VPC Service ControlsでBigQuery等のデータ越境経路を制限し、資格情報流出後の外部持ち出しを抑止する。

5. インシデント対応と設計審査で見るべき指標

LeakyLooker型の教訓は、脆弱性管理をCVE単位で閉じないことである。運用上は、(a) 共有レポートの公開範囲、(b) データソース資格情報の所有者変更履歴、(c) BI経由の高コストクエリ急増、(d) 通常業務と不一致な時間帯・地域の実行主体、を継続監視すべきである。これらは「修正済み脆弱性」の再発防止だけでなく、将来の同型設計欠陥の早期検知にも効く。

2025年9月30日のGoogle公開情報が示す通り、該当問題は修正済みである。しかし、BIとデータ基盤の結合が深まるほど、攻撃面はUIの外側で拡張する。ゆえに組織が守るべき対象は、個別画面ではなく「権限委譲が連鎖するクエリ実行経路」そのものである。

FAQ

LeakyLookerは現在も未修正なのか

公開情報ベースでは、Googleは修正を適用済みであり、GCP-2025-053（2025年9月30日公開）で「no user action is required」としている。Tenable側も2026年3月10日の公開記事で、報告した問題は修正済みと記載している。

最も優先すべき防御策は何か

単一施策では不十分である。短期的には、Looker Studio共有設定と資格情報モデルの棚卸し、BigQuery/Spannerの最小権限化、BI経由クエリ監視の3点を同時に実施するのが実務的である。

VPC Service ControlsはSQLインジェクション自体を防げるか

防げない。VPC Service Controlsは主にデータ越境と持ち出し経路の制限であり、注入そのものの発生防止はアプリ側入力処理と権限境界設計で担保する必要がある。

BigQueryとSpannerのどちらが安全か

優劣ではなく運用設計の問題である。BigQueryはAuthorized Viewや列・行制御、SpannerはFGACによるDBロール分離が強みであり、いずれも「BI実行主体に必要最小権限だけを与える」実装で安全性が決まる。

参考文献