0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@dkuro

BI ツールを替えれば、同じ事故は防げるのか — Metabase の件をデータ基盤の側から考える

0
Last updated at Posted at 2026-10-12

はじめに

こんにちは。
この頃の仕事はデータ基盤の比重が高い者です。
セキュリティ関連の動きで気になったことがあります。

2026年の夏から秋にかけて、BI ツール Metabase の脆弱性を突かれたというニュースが国内で続きました。
再発防止策に「Metabase の利用を終了する」と書いた例も複数あります。

ツールを替えれば、同じ事故は防げるのでしょうか。データ基盤を作る側から、セキュリティの目線で考えてみます。

この記事について
セキュリティの専門家ではありません。
データ基盤を作る側の目線で書いています。誤りや足りない点があれば、ご指摘を歓迎します。

生成 AI の利用について
調べものと下書きには生成 AI をかなり使っています。
事実と日付は、一次情報を自分で開いて確かめました。

ざっくり言うと

  • 脆弱性の中身と対処の手順は、すでに詳しい記事がある。この記事では繰り返さない
  • 気になったのは、再発防止策が「Metabase の利用終了」で締めくくられていること
  • セルフホストなら、修正版の適用は利用者側の役目。その役目は、次のツールでも必要になる
  • それ以前に、アクセス元を絞っていたかを確かめたい
  • 公開直後の版を数日待つ運用は、今回のような修正版では裏目に出る

何が起きたか

要点だけ並べます。

  • 2026-08-06、Metabase が SQL インジェクションの脆弱性を公表した（CVE-2026-72898、CVSS 10.0）。未認証で管理者権限を奪取でき、公表の前から悪用されていた（ゼロデイ）
  • 開発元は同じ日の報告で、修正版と回避策を示した。Metabase Cloud は対策済みで、セルフホストの環境は利用者が修正版に更新する必要があった
  • JPCERT/CC によると、攻撃元の IP アドレスは8月上旬から9月上旬まで悪用されていた

一次情報は、Metabase の報告と、JPCERT/CC の注意喚起（8月・10月）です。以下では、それぞれ「報告」「8月の注意喚起」「10月の注意喚起」と書きます。

経緯と対処の手順は、次の記事が詳しいです。公開範囲の見直し、最小権限、侵害の確認、認証情報のローテーションまで書かれています。

個別の会社を評価する記事ではありません。確認できている範囲では、公表文に、いつ侵入されたかや、修正版を適用していたかが書かれていないものもあります。修正版が出る前に侵入されていた場合、パッチでは防げませんでした。

「利用終了」は、再発防止になっているのか

事実関係を整理しておきます。

Metabase には、開発元が運用する Metabase Cloud と、セルフホスト版があります。Metabase Cloud は、公表の時点で対策済みでした。セルフホスト版は、公式ドキュメントの比較表で、アップグレードは利用者側の作業（Manual）とされています。

セルフホスト版にも2種類あります。オープンソース版のライセンスは AGPL v3 で、無保証です。有償版は別の商用ライセンスで、契約の内容が違います。公表した各社がどちらを使っていたかは、公表文からは分かりません。ただ、どちらであっても、修正版を自分の環境に適用する作業は利用者側に残ります。

こう並べると、再発防止策が「利用の終了」で終わるのは、少し不思議に思えます。修正がいちばん早く入ったのは Metabase Cloud でした。パッチ適用の速さが課題だったのなら、Metabase Cloud へ移る道もあったはずです。

Metabase Cloud なら無傷だった、とは言えません。Metabase Cloud 自身も、修正の前にゼロデイ攻撃を受けています。それでも、「修正版が出たあとも1か月ほど攻撃が続いた」という部分は、Metabase Cloud では起きません。

各社には、外からは見えない事情があるのだと思います。
そこを責めるつもりはありません。
ただ、ツールをやめても、パッチを適用する役目は次のツールでも必要です。

それ以前に、アクセス元を絞っていましたか

私は、ここ15年ほど主にウェブサービスを作る側です。
そこでは、認証前のエンドポイントをインターネットに晒さないことと、アクセス元を絞ることは、最初に考えることです。ところが BI ツールは「社内ツール」として、その外に置かれがちに見えます。

確かめたいことが2つあります。
セキュリティの専門家から見れば、基本的すぎる話かもしれませんが。

  • アクセス元を全世界（0.0.0.0/0）に開けていませんか。社内向けのツールなら、オフィスや VPN の IP アドレスだけを許可リストに入れれば済むはずです
  • どうしても公開するなら、匿名 VPN やホスティング事業者のアドレス帯からのアクセスを弾いていますか

ただ、私がこれまで見てきた現場では、これができているほうが少数でした。

10月の注意喚起には、攻撃元の IP アドレスが3つ載っています。登録情報を調べると、海外のクラウド事業者のものが1つ、海外の通信事業者のものが2つでした。公表された分に限って言えば、どちらかの対策をしていれば通らなかったアクセスです。

アドレス帯で弾くほうは、決定的な対策ではありません。国内の回線や住宅用のプロキシを経由されれば、すり抜けられます。それでも、攻撃する側のコストは上がります。公開された攻撃コードで無差別に探して回る型の攻撃には、効くはずです。

ツールを替えても、残るもの

アクセス元のほかに、ツールを替えても残るものが2つあります。

  • 修正版を何日で適用できるか。セルフホストなら、脆弱性情報を誰が毎日見るのかまで決めておく必要がある
  • BI に、どの権限で何をつないでいたか。管理者権限を奪取されると、保存してある接続先データベースの認証情報で読める範囲が、そのまま漏えいの範囲になる

ちなみに、私には品質保証（QA）のエンジニアという顔もあります。直近のネイティブアプリの現場では、脆弱性情報の確認は週に1回でした。毎日見るというのは、多くの部品を外のエコシステムに頼っている、ウェブの世界ならではの義務とも言えます。

修正版の適用には、落とし穴があります。最近は、公開されたばかりの版をすぐには入れず、数日置いてから取り込む運用が広まっています（依存関係のクールダウン。pnpm の minimumReleaseAge や Dependabot の cooldown など）。乗っ取られたパッケージをつかまないための、サプライチェーン攻撃への防御です。

今回は、これが裏目に出ます。修正版そのものが「公開されたばかりの版」だからです。しかも、公表の時点ですでに悪用されていて、8月の注意喚起（公表の8日後）の時点では、攻撃コードとみられる情報も確認されていました。待っている数日が、そのまま攻撃を受けられる期間になります。

「新しい版は少し待つ」と「セキュリティ修正はすぐ適用する」は、別の規則として必要です。
ツールの側にも、セキュリティ修正を待機の対象から外しているものがあります。たとえば Dependabot の cooldown は、通常のバージョン更新だけを遅らせる設定で、セキュリティ更新には効きません。

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7        # 公開から7日たった版だけ、更新の PR を出す
      semver-major-days: 14  # メジャー更新はさらに長く待つ

この設定でも、セキュリティ更新の PR は待たずに出ます。セキュリティ更新は、GitHub のアドバイザリに載った脆弱性に対して出るものです。

BI につないでいた権限のほうは、データ基盤の設計で小さくできます。BI に見せるのを集計済みか仮名化済みのデータだけにしておけば、漏えいの範囲は先に狭まります。ここは、データ基盤を作る側の持ち場だと考えています。

おわりに

ツールを替えれば、同じ事故は防げるのか。
替えるだけでは、防げないのかもしれません。

今回の欠陥は重いものでした。
ただ、アクセス元の絞り込み、パッチ適用の速さ、つないでいた権限の3つは、どのツールでも問われます。Metabase をやめても、次のツールで同じ問いに答えることになります。逆に、この3つに答えられるなら、Metabase を使い続ける道もあると私は思います。

※ちなみに私は Metabase 関係者ではありません。ロジカルに読み解きたいだけです。

セルフホストで Metabase を運用している方は、まず8月の注意喚起にある侵害有無の確認手順を見てみてください。アップグレードを済ませていても、確かめる価値があります。

参考資料
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?