自社のGA4データやBigQueryのテーブルが、まったく関係のない第三者に閲覧される可能性がある。 セキュリティリサーチャーにより「LeakyLooker」と名付けられたGoogle Looker Studio（旧Googleデータポータル）の脆弱性は、マルチテナントSaaSの構造的な弱点を突いたものだ。Googleはすでに修正対応を進めているが、企業が自社で確認・対策すべきポイントは残っている。
本記事では、LeakyLooker脆弱性の技術的な概要、影響範囲の確認方法、今すぐやるべき対策3ステップ、そしてLooker Studioを安全に運用するためのガイドラインを解説する。
LeakyLooker脆弱性の概要
何が起きたのか
| 項目 | 内容 |
|---|---|
| 脆弱性名 | LeakyLooker |
| 対象サービス | Google Looker Studio（旧Googleデータポータル） |
| 脆弱性の種類 | クロステナントデータアクセス（IDOR: Insecure Direct Object Reference の変種） |
| 影響範囲 | Looker Studioでデータソースを共有設定しているすべてのユーザー |
| 深刻度 | 高（機密データの漏洩リスク） |
| 発見者 | セキュリティリサーチャー（責任ある開示プロセスを経て公表） |
| Googleの対応 | 修正パッチの適用を進行中 |
技術的な仕組み
LeakyLookerの本質は、Looker Studioのデータソース接続におけるアクセス制御の不備だ。
通常、Looker Studioのレポートは以下の流れでデータを取得する。
- ユーザーがレポートを開く
- レポートに紐づくデータソース（GA4、BigQuery、スプレッドシート等）へ接続
- データソースのオーナーの認証情報を使ってデータを取得
- レポート上にデータを表示
LeakyLookerでは、このステップ2〜3のアクセス制御に問題があった。具体的には、データソースの内部識別子（リソースID）を推測または列挙することで、本来アクセス権限のない他テナントのデータソースに接続し、データを取得できる可能性があった。
なぜ「クロステナント」が問題なのか
Looker StudioはGoogleのマルチテナントSaaSだ。複数の企業（テナント）が同一のインフラ上でサービスを利用する。テナント間のデータ分離が不完全であれば、ある企業のデータが別の企業から閲覧されるリスクがある。
| SaaSの利便性 | セキュリティ上のリスク |
|---|---|
| どこからでもアクセス可能 | アクセス制御の不備で意図しないアクセスが発生しうる |
| 共有・コラボレーションが容易 | 共有設定のミスでデータが外部公開される |
| プロバイダーがインフラを管理 | テナント分離の実装品質に依存する |
| 自動アップデート | 脆弱性修正のタイミングを利用者がコントロールできない |
影響範囲：自社は大丈夫か
影響を受ける可能性が高い条件
以下のいずれかに該当する場合、LeakyLookerの影響を受けるリスクがある。
- Looker Studioでデータソースの「認証情報」を「オーナーの認証情報」に設定している（デフォルト設定）
- データソースにGA4、BigQuery、Cloud SQL等の機密データを接続している
- レポートを「リンクを知っている全員」に共有している
- データソースの共有設定を個別に管理していない
影響を受けにくい条件
- データソースの認証情報を「閲覧者の認証情報」に設定している場合、閲覧者自身の権限でデータアクセスが行われるため、クロステナントのリスクは低減される
- データソースに機密性の低いデータ（公開済みの統計データ等）のみを接続している場合
Looker Studioのセキュリティ設定、不安はありませんか？
GXOはGoogle Workspace・Looker Studioのセキュリティ監査と設定最適化を支援しています。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
今すぐやるべき対策3ステップ
ステップ1：データソースの認証情報設定を確認する（所要時間：30分）
Looker Studioの各レポートで使用しているデータソースの認証情報を確認する。
確認手順：
- Looker Studio（lookerstudio.google.com）にログイン
- 左メニューの「データソース」を選択
- 各データソースを開き、「データの認証情報」を確認
- 「オーナーの認証情報」になっている場合、必要に応じて「閲覧者の認証情報」に変更
| 認証情報の設定 | 動作 | セキュリティリスク |
|---|---|---|
| オーナーの認証情報 | データソースのオーナー権限でデータを取得 | 高（オーナーの権限で全データにアクセス） |
| 閲覧者の認証情報 | レポート閲覧者自身の権限でデータを取得 | 低（閲覧者の権限範囲に限定される） |
ステップ2：レポートとデータソースの共有設定を棚卸しする（所要時間：1〜2時間）
Looker Studioのレポートとデータソースの共有設定を一覧化し、不要な共有を削除する。
確認すべき項目：
- [ ] 「リンクを知っている全員」に共有されているレポートがないか
- [ ] 退職者やプロジェクト終了者にアクセス権限が残っていないか
- [ ] 外部パートナーへの共有が必要最小限になっているか
- [ ] データソース単体で共有されているものがないか（レポート経由のみに限定すべき）
Google Workspace管理者の場合：
Google管理コンソール > アプリ > Google Workspace > Looker Studio で、組織全体の共有ポリシーを確認する。「組織外への共有を制限」する設定が有効になっているかを確認する。
ステップ3：データソースのアクセスログを確認する（所要時間：1〜3時間）
不審なアクセスが過去に発生していないかを確認する。
確認方法：
- Google Workspace監査ログ（管理者のみ）：管理コンソール > レポート > 監査と調査 > Looker Studio のログ で、データソースへのアクセス履歴を確認
- BigQueryの場合：BigQueryの監査ログ（Cloud Audit Logs）で、Looker Studioからのクエリ実行履歴を確認。見覚えのないクエリやIPアドレスからのアクセスがないかをチェック
- GA4の場合：GA4のプロパティ設定 > アカウントのアクセス管理 で、アクセス権限を持つユーザーを確認
Looker Studio安全運用ガイド
LeakyLookerへの対応だけでなく、Looker Studioを長期的に安全に運用するためのベストプラクティスを整理する。
原則1：最小権限の原則を徹底する
| 対象 | 推奨設定 |
|---|---|
| データソースの認証情報 | 可能な限り「閲覧者の認証情報」を使用 |
| レポートの共有 | 「特定のユーザー」に限定。「リンクを知っている全員」は原則禁止 |
| データソースの共有 | レポート経由のアクセスのみに限定。データソース単体の共有は避ける |
| BigQueryの権限 | Looker Studio用のサービスアカウントに必要最小限のテーブル・ビューへのアクセス権限のみ付与 |
原則2：データの露出範囲を制限する
- ビューを活用する：BigQueryのテーブルを直接接続するのではなく、必要なカラムのみを含むビューを作成し、ビューをデータソースとして接続する
- 行レベルセキュリティ：BigQueryの行レベルアクセスポリシーを設定し、ユーザーごとにアクセス可能な行を制限する
- データマスキング：個人情報や機密データを含むカラムにはCloud DLPによるマスキングを適用する
原則3：定期的な棚卸しを仕組み化する
- 四半期に1回、全レポート・データソースの共有設定を棚卸し
- 退職者・異動者のアクセス権限を速やかに削除するプロセスを整備
- Google Workspace管理コンソールのアラートを活用し、異常なアクセスパターンを検知する仕組みを構築
原則4：組織ポリシーで制御する
Google Workspace管理者が設定すべき組織ポリシーは以下の通り。
| ポリシー | 推奨設定 |
|---|---|
| 組織外への共有 | 制限する（必要な場合のみ許可リストで対応） |
| データソースの外部接続 | 承認済みのデータソースタイプのみ許可 |
| サードパーティコネクタ | 必要なもののみ許可リストで管理 |
| ダウンロード | 機密レポートのデータダウンロードを制限 |
よくある質問（FAQ）
Q. LeakyLookerはすでに修正されたのか？
Googleは責任ある開示プロセスを経て脆弱性の報告を受け、修正パッチの適用を進めている。ただし、SaaSの特性上、利用者側で修正の適用状況を確認する手段は限定的だ。本記事で解説した対策（認証情報の設定変更、共有設定の棚卸し、アクセスログの確認）は、LeakyLookerの修正有無にかかわらず実施すべきセキュリティ対策である。
Q. Google Looker Studio以外のBIツールにも同様のリスクはあるか？
マルチテナントSaaSであるBIツール（Tableau Online、Power BI Service等）にはいずれも同様のクロステナントリスクが理論上存在する。各ツールのベンダーがテナント分離の品質をどこまで担保しているかに依存する。BIツールに限らず、SaaSを利用する際は「データソースへの認証情報がどう管理されているか」「共有設定の粒度は十分か」を確認することが重要だ。
Q. 無料版のLooker Studioでも影響を受けるのか？
はい。LeakyLookerはLooker Studioのデータソース接続の仕組みに起因する脆弱性であり、無料版・有料版（Looker Studio Pro）の区別なく影響を受ける可能性がある。むしろ無料版はGoogle Workspace管理コンソールによる組織ポリシーの適用が限定されるため、利用者自身による対策がより重要になる。
Q. すでにデータが漏洩していた場合、どう対応すべきか？
アクセスログの確認で不審なアクセスが検出された場合、以下の手順で対応する。
- 該当のデータソースの共有を即時停止する
- アクセス元の情報（IPアドレス、ユーザーエージェント等）を記録・保全する
- 漏洩した可能性のあるデータの範囲を特定する
- 個人情報が含まれる場合、個人情報保護委員会への報告義務（72時間以内）の該当性を確認する
- 自社のインシデント対応手順に従い、影響範囲の調査と再発防止策を実施する
インシデント対応の全体フローについてはセキュリティインシデント報告チェックリストも参照されたい。
まとめ
| ポイント | 内容 |
|---|---|
| 脆弱性の本質 | Looker Studioのデータソース認証におけるクロステナントアクセス制御の不備 |
| 最優先対策 | データソースの認証情報を「閲覧者の認証情報」に変更 |
| 必須対策 | レポート・データソースの共有設定の棚卸し |
| 長期対策 | 最小権限の原則に基づくLooker Studio運用ポリシーの策定 |
GXO実務追記: サイバーセキュリティで発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、自社で最初に塞ぐべきリスク、外部診断の範囲、初動体制を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- [ ] 重要システムと個人情報の所在を棚卸ししたか
- [ ] VPN、管理画面、クラウド管理者の多要素認証を必須化したか
- [ ] バックアップの世代数、復旧時間、復旧訓練の実施日を確認したか
- [ ] 脆弱性診断の対象をWeb、API、クラウド、社内ネットワークに分けたか
- [ ] EDR/MDR/SOCの必要性を、監視できる人員と照らして判断したか
- [ ] インシデント時の連絡先、意思決定者、広報/法務/顧客対応を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
LeakyLooker脆弱性｜Google Looker Studioのクロステナントリスクと対策を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。
関連記事
- Webアプリケーションセキュリティ OWASP Top 10ガイド — IDORを含む脆弱性の全体像
- APIセキュリティ認証ガイド（OAuth/JWT） — 認証・認可の実装パターン
- セキュリティインシデント報告チェックリスト — インシデント発生時の対応手順
- Microsoft 365セキュリティ設定ガイド — SaaS全般のセキュリティ設定
- 中小企業のセキュリティ対策 完全ガイド — セキュリティの全体像
SaaSのセキュリティ設定、専門家にチェックしてもらいませんか？
GXOはGoogle Workspace、Microsoft 365をはじめとするSaaS環境のセキュリティ監査と最適化を支援しています。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK