Splunk の脆弱性（CVE-2026-20253）を入口に、データ基盤の本当の急所が「アクセス層」にあることを論じる。Salesforce・Snowflake の事例から、守るべきは保存時の暗号化ではなく設定・ID・権限であることを示し、Tableau を代表例に BI ツールが抱える落とし穴を解説。対策は「正しい設定・監視・素早い修正」を回し続けることだと結論する。
Tableau、Snowflake、AIエージェントに共通する「見えてはいけないもの」の話
データ基盤の怖さは、盗まれたときに初めて分かる。普段は「便利な分析基盤」「監視基盤」「ダッシュボード」に見えているものが、ひとたびアクセス層を破られると、組織中のログ・顧客情報・財務情報を横断できる入口に変わる。Splunk の脆弱性は、その構造を考えるきっかけとしてちょうどよい。
2026年6月、Splunk Enterprise に深刻な脆弱性（CVE-2026-20253、CVSS 9.8）が公表された。内部の PostgreSQL サイドカーのエンドポイントに認証がなく、ネットワークに到達できれば認証なしで任意ファイルの作成・切り詰めが可能になり、条件次第では遠隔コード実行（RCE）につながり得る。影響を受けるのは Splunk Enterprise 10.0.7 未満・10.2.4 未満、および一部の Splunk Cloud Platform バージョンだ。オンプレ運用者は 10.0.7 / 10.2.4 への更新を、Cloud 利用者は管理画面やベンダー通知で自環境の適用状況を確認すべきだ。
ここで一度、技術的詳細から視点を引いてみたい。Splunk は、組織のログとデータを「監視するため」の製品だ。その監視するはずの製品自身が、データへの裏口になった。この皮肉は、Splunk 固有の話では終わらない。私たちがデータを集めて置いている「基盤」そのものが抱える、共通の構造的な問題の入口だと考えたほうがいい。
SIEM、データウェアハウス、BIツール。私たちは利便性と分析力のために、ログも顧客データも財務データも、ひとつの基盤に集約してきた。その結果、組織の「王冠の宝石」は一箇所に集まり、そこが破られれば被害は全データに及ぶ構造になった。
そして重要なのは、ここで起きる事故は必ずしも「製品のバグ」ではないということだ。むしろ多くは、設定とID（権限）の問題で起きる。最近の代表的な3件を並べると、性格の違いがよく分かる。
| 事例 | 穴の正体 | 主な責任 |
|---|---|---|
| Splunk Enterprise | 製品コードの欠陥（無認証サイドカー → 任意ファイル操作、RCE 可能性） | ベンダー |
| Salesforce Experience Cloud | ゲストユーザー権限の設定ミス → 未認証で背後のCRMを参照 | 利用企業（設定） |
| Snowflake | MFA未設定＋盗まれた認証情報 → 正規ログインで大量持ち出し | 利用企業（ID管理） |
メカニズムは三者三様だが、共通する真実はひとつだ。保存時の暗号化（at-rest）でいくらデータを守っても、アクセス層が破られれば意味がない。 データの「置き場所」より、「誰が・どうやって触れるか」が本丸になる。
象徴的なのが Snowflake の一件だ。プラットフォーム本体は破られていない。すべての侵害が、顧客側で盗まれた認証情報と MFA 未設定に起因していた。それでも、AT&T では約1.1億人分の通話・SMSメタデータ、Ticketmaster では約5.6億人分のデータが流出した。製品のバグはゼロ。にもかかわらず、この規模である。
ここで Tableau を取り上げるのは、Tableau だけが危ないと言いたいからではない。むしろ逆だ。BIツールは、データウェアハウスやCRMやログ基盤の上に乗る「最後のアクセス層」だからこそ、どの組織でも同じ問題が起きる。ダッシュボードとして見せているつもりでも、その裏には明細データ、抽出ファイル、ダウンロード権限、編集権限がある。ここを誤ると、攻撃されなくても、正規ユーザーが想定以上のデータに触れてしまう。Power BI や Looker でも構造は同じだ。以下は Tableau を代表例として、その「最後のアクセス層」で起きやすい落とし穴を、できるだけ平易に並べたものだ。
Tableau は高速化のために、接続先のデータベースからデータを「抽出（Extract）」してファイル（.hyper）として手元に持つことが多い。ここで押さえておきたいのは、抽出は、元データベースの権限制御を自動的に継承するものではないという点だ。Tableau 側で行レベルセキュリティ（RLS）を再設計しない限り、抽出は想定より広いデータを含むコピーになり得る。「データベースでちゃんと権限を絞っているから安心」という前提は、抽出した瞬間に必ずしも成り立たなくなる。（抽出にも RLS を効かせる設計手段はある。後述する。）
ワークブックを Tableau Server / Cloud に公開しても、行レベルセキュリティ（RLS）は自動では効かない。ビューにアクセスできるユーザーは、RLS を明示的に設計しない限り、そのビューに含まれるデータを見られる。RLS はユーザーフィルター、動的フィルター、仮想接続のデータポリシーなどで実装できるが、いずれも「自分で明示的に効かせる」ものだ。セキュリティが最初から効いていると思い込むと、設計し忘れたビューが丸見えになる。
ここが一番知られておらず、そして一番怖い点だ。仮に行レベルセキュリティ（ユーザーフィルター）を組んでも、そのユーザーにワークブックのダウンロードや Web 編集の権限があると、RLS は実質的に無効になる。フィルターを外すだけで全データにアクセスできてしまうからだ。
問題の本質を一言で言えば、現場では 「ダッシュボードを見る権限」と「データを取り出す権限」が混ざりやすいということだ。本来この2つは別物のはずなのに、ビューを共有した時点で、ダウンロードや編集も一緒に許してしまう。その結果、「集計済みのグラフだけ見せているつもり」のダッシュボードでも、閲覧者が裏側の生データ（明細行）を引き出せる、という状況が普通に起きる。
これは外部からの攻撃の話ではない。正規にアクセス権を持つ人が、意図よりはるかに多くを見て・持ち出せてしまうという、アクセス層そのものの設計問題だ。だからこそ、後述するように「見せる権限」と「取り出せる権限」は意識的に分けて設計する必要がある。
無料で使える Tableau Public は便利だが、その名の通り、公開したものは世界中から閲覧でき、検索もされる。社内向けのつもりで公開し、給与データや個人情報が外部に晒される、という事故が現実に繰り返されている。
これらに共通するのは、「攻撃された」という話ではないことだ。設定と権限の組み合わせ次第で、見るべき人が・見るべき以上に見て・持ち出せてしまう。BIツールはデータ基盤の最後のアクセス層であり、ここが甘いと、上流でどれだけ権限を絞っても全データが流れ出る。
そして今、分析作業そのものが AI（エージェント）に委ねられ始めている。ここでリスクは一段と広がる。
「誰が見るか」の主体が人から AI へ広がるほど、これまでの権限設定だけでは守りきれない領域が増えていく。
魔法の一手はない。地味だが、次の3つを回し続けるしかない。
1. 正しい設定。 すべての層で最小権限を徹底する。BI層も例外ではない。「見せる権限」と「取り出せる権限（ダウンロード・編集）」を意識的に分ける。 抽出には RLS を組み直し、できればフィルターを外せる方式ではなく、サーバー側で全クエリに強制されるデータポリシー（仮想接続など）で守る。Tableau Public への公開ルールを決め、IDには MFA を強制する。
2. 監視。 権限の付与表（誰に何を許可したか）を見るだけでは足りない。実際のアクセスと出力を見る ― クエリや振る舞いの監査、データの持ち出し（egress）の監視まで踏み込む。そして冒頭の教訓を忘れないこと。監視製品自身も、監視の対象だ。
3. すぐ修正。 製品のバグなら即パッチ（Splunk なら 10.0.7 / 10.2.4 へ）。設定ミスなら、見つけた瞬間に直す。
この3つは一度やって終わりではない。回し続けて初めて意味を持つ。レーダーと同じで、止めた瞬間に価値がゼロになる。
Splunk の脆弱性は、「該当製品を直せば終わり」という話ではない。データ基盤全体に共通する問いの入口だ。データは集約したほうが価値が出る。だが集約は、アクセス層を新しい「王冠の宝石」に変える。そして守りは、製品の堅牢さだけでなく、正しい設定・継続的な監視・素早い修正という運用にしか宿らない。
あなたの組織でも、おそらく誰かが Tableau を使っている。そのダッシュボードの裏側で、誰が・何を・どこまで見られるのか。一度、確かめてみる価値がある。
Aikido Community Japan
公開日: 2026/6/13
最終更新: 2026/6/14
セキュリティの最新情報をお届けします。