JPCERT/CC の不正アクセス注意喚起｜4 つの攻撃手口と点検手順

はじめに

2026 年 10 月 8 日、JPCERT/CC は「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）を公開し、翌 9 日に攻撃手法と不審な送信元 IP アドレスを追記しました。同じ 9 日には IPA も「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」を公表し、点検と対策を示しています。

注意喚起では、一般利用者向けのアプリだけでなく、BI ツールや従業員向け管理システムなど、不特定多数のアクセスを想定していないシステムから情報が漏えいしたケースも報告されています。特定製品の利用者だけを対象にした注意喚起ではないため、自社のどのシステムを、どのログで、どの順に確認するかを決めることが最初の課題になります。

本記事では、JPCERT/CC が示した 4 つの攻撃手法と IPA の点検項目をもとに、確認対象のシステム、ログ調査の注意点、点検の順序、侵害が疑われる場合の初動を整理します。公式情報の確認基準日は 2026 年 10 月 12 日（日本時間）です。国内の公表事例や、漏えいが相次ぐ背景については『情報漏えいはなぜ起きる？｜国内事例から考える情シス・インフラの対策』で扱っています。

結論として、今回の注意喚起は単一の脆弱性への対応ではなく、外部から到達できるシステム全体の点検を求めるものです。外部公開システム、API、管理機能を洗い出し、Web・API・認証・管理操作のログを組み合わせて調べることが対応の軸になります。影響を受けるバージョンの Metabase を自己ホストしている場合は、更新と侵害調査を並行して進めます。

JPCERT/CC が注意喚起した 4 つの攻撃手法

JPCERT/CC は、寄せられた情報などに基づき 4 つの攻撃手法を示しています。これらは共通の侵入経路ではなく、事案ごとに異なる手法が報告されたものです。

参考: JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」
「すべての事案で同一の攻撃手法が使用されていることを示すものではありません。」
https://www.jpcert.or.jp/at/2026/at260030.html

ケース	概要	報告された主な操作・痕跡	主な確認対象
A	さまざまなソフトウェアの既知の脆弱性の探索・悪用試行	標的ごとの脆弱性スキャン、管理不備を突いた環境設定ファイルやバックアップファイルの窃取試行	公開 Web サーバー、ミドルウェア、公開ディレクトリ
B	API 経由での不正な操作	アプリ解析による API のエンドポイントやキーの特定、内部 API での権限変更・アカウント作成、他システムで窃取された API キーの使用	API、管理用 API、認証基盤、スマートフォンアプリ
C	Metabase の SQL インジェクション（CVE-2026-72898）	認証なしの細工したリクエストによる管理者権限の取得	自己ホストの Metabase と接続先データベース
D	公開 Web サーバーから到達可能なアプリケーションサーバーへの Web シェル設置（10 月 9 日追加）	WAR ファイルの設置、JSP の Web シェルによるコマンド実行	アプリケーションサーバー、デプロイ機能

JPCERT/CC は、本注意喚起がランサムウェア攻撃などの事案とは別に、大量の個人情報等の漏えいにつながり、特に増加している恐れのある攻撃類型を取り上げたものとしています。把握している情報は限定的かつ断片的とも明記しているため、今後の追記を前提に、公式ページを定期的に確認する必要があります。

ケース A: 既知の脆弱性と管理不備を探す攻撃

ケース A は、特定の 1 製品の脆弱性ではなく、標的ごとにさまざまな既知の脆弱性の有無をスキャンし、悪用を試みるものです。脆弱性ではない管理不備、たとえば Web から取得できる状態になっている環境設定ファイルやバックアップファイルを狙う試行も含まれます。

このケースで重視したいのは、スキャンの量よりも、本来公開していない設定ファイルやバックアップファイルへのリクエストに、正常応答（200 など）を返していないかです。公開サーバーで存在しないパスへの 404 が大量に記録されることは珍しくありません。一方、200 の応答だけでは、エラーページやトップページを 200 で返す構成もあるため、ファイルの内容が取得されたとは断定できません。応答サイズが実際のファイルと一致するか、同じパスで現在どのような内容が返るかを確認し、機密情報が取得された可能性がある場合は、含まれていた認証情報の無効化と影響調査を検討します。10 月 9 日の更新では、10 月 7 日ごろに悪用された送信元 IP アドレスが追加されています。

ケース B: 画面にない機能を API から操作する攻撃

ケース B は、アプリの管理用 API への不正なリクエストによって、情報の不正な書き換えなどが発生したものです。JPCERT/CC は、次の手口について複数の報告を受けているとしています。

• 一般公開しているスマートフォンアプリを解析し、API のエンドポイントやキーを特定する
• 本来画面操作では実行できない内部 API に対し、ユーザー権限の変更や不正なアカウントの作成を行う
• ヘッダーの有無の切り替えや不正な形式の認証トークンの付与で、応答の違いを確認する
• NoSQL インジェクションによるブラインド探索で、アカウント情報を特定する
• 他のシステムの侵害で窃取した API キーを使用する

アプリに埋め込んだ API キーやエンドポイントは、配布した時点で解析される可能性があります。マクニカのセキュリティ研究センターも、事案対応から得た情報を整理したブログ記事で、スマートフォンアプリから API キーを取り出し、正規のアクセスに見える形で API を呼び出すケースを紹介しています。正規のキーによる呼び出しは、送信元や User-Agent だけでは通常の利用と区別しにくい点に注意が必要です。他のシステムで漏えいした認証情報が別の環境の侵害につながる経路は、『サプライチェーン攻撃対策｜開発環境からのクラウド侵害を防ぐ確認点』でも解説しています。

ケース C: Metabase の CVE-2026-72898

ケース C は、オープンソースの BI ツール Metabase の SQL インジェクションの脆弱性です。JPCERT/CC は 2026 年 8 月 14 日に「Metabase の SQL インジェクションの脆弱性（CVE-2026-72898）に関する注意喚起」を公表しています。悪用された場合、遠隔の第三者が認証なしで細工したリクエストを送り、Metabase のアプリケーションデータベースに不正な SQL を実行して、管理者権限を取得する可能性があります。Metabase は、本脆弱性を悪用したゼロデイ攻撃を確認したと公表しています。

Metabase のアドバイザリによると、管理者権限を得た攻撃者は、設定の変更に加え、接続先データベースの認証情報の窃取や、接続を通じたデータの参照・エクスポートができる可能性があります。

参考: Metabase「SQL injection using an unauthenticated endpoint leading to admin access」
“steal stored credentials for the connected databases”
（接続先データベースの保存済み認証情報を窃取する）
https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf

影響は Metabase 本体にとどまらず、接続しているデータベースやデータウェアハウスまで調査対象になります。CVE-2026-72898 の影響を受けるバージョンと修正版は次のとおりです。修正版は、その後の追加強化版と分けて記載しています。

系列	CVE-2026-72898 の影響を受けるバージョン	CVE-2026-72898 の初期修正版	追加強化版の最小安全リリース（8 月 14 日更新）
63 系	x.63.5 より前	x.63.5	x.63.13
62 系	x.62.9 より前	x.62.9	x.62.16
61 系	x.61.11 より前	x.61.11	x.61.18
60 系	x.60.17 より前	x.60.17	x.60.24
59 系	x.59.21 より前	x.59.21	x.59.28
58 系	x.58.24 より前	x.58.24	x.58.31
58 系より前	CVE-2026-72898 の影響は受けない（Metabase による）	―	―（追加強化の GHSA は 0.58.28 より前の全版を影響範囲としている）
Metabase Cloud	CVE-2026-72898 の対策は実施済み（Metabase による）	―	―

版の「x」には、オープンソース版では 0、Enterprise 版では 1 が入ります（例: v0.63.5、v1.63.5）。なお、GitHub のアドバイザリの影響範囲欄には上表と異なる上限値が記載されていますが、JPCERT/CC と Metabase のブログ記事はいずれも上表の初期修正版を修正版としているため、本記事では初期修正版を CVE-2026-72898 の判定基準にしています。

ただし、初期修正版以上であっても、現在のセキュリティ更新がすべて完了しているとは限りません。Metabase は 8 月 11 日に、クエリの検証、権限確認、ネットワーク露出などの複数の問題を修正したアドバイザリ（GHSA-r495-55cx-fjh7）を公開し、8 月 12 日のブログ記事で追加のセキュリティ強化版を発表しました。同記事の最小安全リリースは 8 月 14 日に更新され、上表の右列の版になっています。実際の更新先は、Metabase の公式情報で利用中の系列の最新の修正リリースを確認して選択してください。

Metabase Cloud の「対策実施済み」は、今後の悪用に対する対策が済んでいるという意味です。Metabase は Cloud 自体がゼロデイ攻撃を受けたと公表しており、過去に侵害がなかったことを示すものではありません。現在のバージョンは、Metabase の画面右上のメニューから「About Metabase」を開いて確認できます。

すぐに更新できない場合の一時的な回避策として、Metabase は /api/session/reset_password へのアクセスをネットワーク機器などで遮断するよう案内しています。ただし、このエンドポイントがインターネットから到達可能だった場合は、更新だけで対応を完了せず、侵害の有無を調べることが推奨されています。次の 2 つの通信が続けて記録されている場合、侵害の可能性が高いとされています。

• POST /api/session/reset_password へのアクセス（HTTP ステータスコード 400）
• 続く GET /api/user/current へのアクセス（HTTP ステータスコード 200）

このパターンは、Metabase のアプリケーションログのほか、前段のリバースプロキシやロードバランサーのアクセスログでも確認できます。侵害の可能性がある場合に Metabase が案内している対応（更新後に実施）は次のとおりです。

• アプリケーションデータベースの core_session テーブルの全行削除による、全ユーザーセッションの無効化
• 身に覚えのない API キーの確認と削除
• 管理者アカウントの想定外の変更の確認
• 接続先データベースの認証情報の変更
• データウェアハウス側のログでの不正アクセスの確認
• Metabase のアクティビティやクエリ履歴の確認

JPCERT/CC は、Metabase が同日に別の SQL インジェクションの脆弱性（CVE-2026-72899）も公表したことに触れています。Metabase のアドバイザリ（GHSA-r8h2-qpfx-mx59）によると、フィールドフィルターのパラメーターを持つカードやダッシュボードを公開共有していると、公開リンクの UUID だけで認証なしに悪用される可能性があります。影響を受けるバージョンと修正版は CVE-2026-72898 と同じです。公開共有は既定で有効とされており、暫定回避策は公開共有の無効化、または該当する公開リンクの公開停止です。該当する公開リンクがあった場合の侵害後の対応も、上記のリストと同じ内容が案内されています。

ケース D: アプリケーションサーバーへの Web シェル設置

10 月 9 日の更新で追加されたケースです。公開 Web サーバーからアクセスできるアプリケーションサーバー上に WAR ファイル（.war）が設置され、含まれる JSP ファイル（.jsp）が簡易 Web シェルとして動作していました。この Web シェルは、特定のクエリパラメーターの値をシェルコマンドとして実行する機能を持ち、9 月ごろに GET と POST による繰り返しのアクセスが確認されています。

JPCERT/CC は、WAR ファイルの設置方法や、アプリケーションサーバーの製品名を公表していません。そのため、特定製品の脆弱性に限定せず、公開 Web サーバーから内部のアプリケーションサーバーへ転送される経路と、アプリケーションをデプロイできる機能の両方を確認対象にします。たとえば、リバースプロキシの転送設定によって管理機能やデプロイ機能のパスまで外部から届く状態になっていないか、変更記録にないアプリケーションが配置されていないかを確認します。

自社で優先して確認すべきシステム

JPCERT/CC と IPA は、いずれも外部に公開しているアプリケーションやサービスの点検を求めています。IPA は、特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず、公表事例の傾向から、外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点になっていることがうかがえるとしています。確認対象は Web サイトだけでなく、次のようなシステムも含めて洗い出します。

• 自組織が独自に構築・運用している Web アプリケーションと API（スマートフォンアプリのバックエンドを含む）
• インターネットから到達できる管理画面、管理用 API、デプロイ機能
• BI ツールや従業員向け管理システムなど、不特定多数のアクセスを想定していないが外部から到達できるシステム
• 部署単位で契約しているものを含む、クラウドサービスや VPN サービスなどの外部サービス
• 終了したキャンペーンや旧バージョンの API など、運用が止まった後も公開が残っているもの

最後の項目は、OWASP API Security Top 10 2023 の API9（Improper Inventory Management）が扱うリスクです。OWASP は、API は従来の Web アプリケーションより多くのエンドポイントを公開する傾向があり、ホストとデプロイ済みの API バージョンの棚卸しが重要だとしています。

システム別の点検表

次の表は、JPCERT/CC と IPA の情報をもとに、システムごとの確認観点を編集上整理したものです。記録できる項目は製品や設定によって異なるため、自社の環境で実際に取得できているかも併せて確認してください。

確認対象	主な確認ログ・設定	探すべき不審な挙動	異常が見つかった場合の次の行動
Web サーバー	アクセスログ、エラーログ、公開ディレクトリの内容	設定ファイルやバックアップファイルへの正常応答、エラー応答の急増、平時と異なる送信元からの集中アクセス	取得されたファイルの内容を確認し、含まれていた認証情報を無効化する
リバースプロキシ・ロードバランサー	アクセスログ、転送設定	内部の管理機能やデプロイ機能へ転送されたリクエスト、Metabase の侵害パターン	転送ルールを制限し、転送先サーバーのログを調べる
WAF	検知ログ、ルールごとの動作（遮断か検知のみか）	検知のみで通過した攻撃、同じ送信元からの継続的な探索	通過したリクエストの応答と、アプリケーション側の処理結果を確認する
API ゲートウェイ	アクセスログ、API キー・クライアントごとの利用量、レート制限の設定	想定外のクライアントやキーによる呼び出し、利用量の急増、認証エラーが続いた後の成功	該当するキーやトークンを無効化し、エンドポイントの認可を確認する
認証基盤	サインインログ、管理者操作ログ、アカウントと権限の一覧	作成した覚えのないアカウント、無効化したはずのアカウントの再有効化、権限の昇格	アカウントを停止し、セッションとトークンを無効化する
アプリケーションサーバー	アクセスログ、デプロイ履歴、配置済みアプリケーションの一覧	変更記録にない WAR ファイルや JSP の配置、見慣れない JSP への GET / POST の繰り返し	ファイルとログを保全し、外部からの経路を遮断する
BI ツール	監査ログ、クエリ履歴、API キーと管理者の一覧、バージョン	Metabase の侵害パターン、身に覚えのない API キーや管理者、大量のデータエクスポート	利用系列の最新の修正リリースを適用し、接続先データベースの認証情報の変更と DB 側のログ調査を行う
クラウドサービス・外部サービス	監査ログ、サインインログ、API キーやアクセスキーの一覧	通常と異なる送信元やログイン時間、新しいキーやアカウントの作成	キーを無効化し、提供者が保有するログの範囲と保存期間を確認する

IPA は、サービスごとにログの保有期間が異なることや、サービス提供者と利用者で確認できるログが異なる可能性があることも指摘しています。表のうち、自社で取得できないログや保存期間が足りないログは、提供者や委託先への確認事項として記録しておきます。

不正アクセスの痕跡を確認する方法

痕跡の確認では、単一のログや指標で判断せず、複数の記録を時刻でつなげて操作の流れを再構成します。

組み合わせて確認する項目

• 時刻と期間（公表された観測時期と、自社ログのタイムゾーンの違いを含む）
• アクセス先（パス、API エンドポイント、HTTP メソッド）
• 応答と処理結果（ステータスコード、応答サイズ、アプリケーション側の処理結果）
• 認証の結果（認証エラーが続いた後の成功、通常と異なる送信元からのログイン）
• アカウントと権限の操作（作成、権限変更、API キーの発行）
• デプロイと設定変更の履歴（変更管理の記録との照合）

たとえば、ある送信元から認証エラーが続いた後に管理用 API の呼び出しが成功し、その直後に新しいアカウントが作成されていれば、個々のログでは目立たなくても一連の不正操作の可能性があります。IPA は、エラーの出力量や平時との差異を手掛かりに、直近 1 か月、その後 3 か月と段階的に範囲を広げて確認すること、今後の再調査に備えて誰がどのように調査できるかを把握しておくことを求めています。

公表された IP アドレスと User-Agent の読み方

JPCERT/CC は、ケース A〜D について不審な送信元 IP アドレスを、ケース B と C について User-Agent の例を公表しています。これらは侵害調査の手掛かりとして有効ですが、そのまま判定基準として使うと誤った結論につながります。一覧は今後も更新される可能性があるため、本記事では転載せず、調査時点の JPCERT/CC の注意喚起を直接参照することをおすすめします。

公表 IP アドレスとの一致だけで侵害と判断しない

JPCERT/CC は、ケース B と C の IP アドレスについて、調査時点では正規に利用されている可能性もあると注記しています。クラウドや VPN の出口のように、複数の利用者が共有するアドレスも含まれ得ます。一致した場合は、その送信元が何に、どの結果でアクセスしたかを確認します。

送信元 IP アドレスの遮断だけで対策完了としない

攻撃者は送信元を変えられます。遮断は当面の緩和策として有効な場合がありますが、悪用された脆弱性や認可の不備、窃取された API キーが残っていれば、別の送信元から同じ操作ができます。

curl や python-requests を不正の証拠としない

curl や python-requests は、監視、システム連携、運用スクリプトなどの正規の用途でも広く使われます。User-Agent はクライアント側で任意に設定できるため、一般的なブラウザーと同じ値を名乗る不正なリクエストもあり得ます。JPCERT/CC の例にも、ブラウザーの User-Agent が含まれています。

WAR や JSP ファイルの存在を不正と断定しない

Java のアプリケーションサーバーでは、WAR ファイルによるデプロイや JSP の利用は通常の構成です。変更管理の記録、配置日時、配置した担当者、ファイルの内容、アクセス元を照合して、正規の配置かを判断します。

ログがないことを侵害がなかった根拠にしない

ログを取得していない種類の操作や、保存期間を過ぎた期間の操作は確認できません。攻撃者がログを削除している可能性もあります。調査結果には確認したログの種類と期間を明記し、確認できなかった範囲は未確認として残します。

情シスが実施すべき対策と優先順位

JPCERT/CC の対策と IPA の点検項目は、実施する順序まで指定したものではありません。次の手順は、両者の内容を点検の作業順に編集上整理したものです。

API の認証・認可で見落としやすい点

ケース B は、画面上で操作できないことと、API から実行できないことは同じではない点を示しています。画面にボタンがない機能でも、サーバー側に API が存在し、呼び出し元の権限を確認していなければ、リクエストを直接送ることで実行できます。OWASP API Security Top 10 2023 は、一般機能と管理機能の分離が不明確な場合に、他の利用者のリソースや管理機能へアクセスされる問題を API5（Broken Function Level Authorization）として挙げています。

API キーも同様に、存在するだけでは適切な認可を保証しません。API キーは呼び出し元のアプリケーションの識別や利用量の管理に使われることが多く、アプリに埋め込んだ時点で解析される前提で扱う必要があります。OWASP の REST Security Cheat Sheet は、重要な資源の保護を API キーだけに頼らないよう求めています。

参考: OWASP Cheat Sheet Series「REST Security Cheat Sheet」
“Do not rely exclusively on API keys to protect sensitive, critical or high-value resources.”
（機密性の高い資源、重要な資源、価値の高い資源の保護を、API キーだけに頼らないでください。）
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

JPCERT/CC が示した API 経由のアクセスへの対策を、役割と限界に分けると次のようになります。

対策	主な役割	限界・確認点
各エンドポイントでのアクセス制御（非公開 API を含む）	許可された利用者と HTTP メソッドからの要求だけを受け付ける	画面側の制御ではなく、サーバー側で呼び出し元の権限を毎回確認しているかを確認する
API 利用者・トークンの権限の最小化	窃取されたトークンで実行できる操作を限定する	一般利用者のトークンで、権限変更やアカウント作成の API を呼び出せないかを確認する
トークンの有効期限	窃取されたトークンを使える期間を短くする	期限内は利用できる。長期間有効なトークンや API キーが残っていないかを棚卸しする
トークンの速やかな無効化	不要になったトークンや漏えいが疑われるトークンの利用を止める	無効化の手順と実施する権限を事前に決めておかないと、発覚時に時間がかかる
レート制限・利用回数制限	短時間の大量実行や総当たり的な探索を抑える	制限内の低頻度な不正操作は防げない。ログイン、パスワードリセット、SMS 送信、検索処理などは個別に設定する
アクセス元の地域制限	利用地域が限られるサービスで、受け付ける送信元の範囲を狭める	国内のクラウドや VPN を経由したアクセスは制限できない

レート制限は、認可の不備そのものを解消する対策ではありません。一度のリクエストで権限変更や大量のデータ取得ができる API は、レート制限を設けても悪用を防げないため、サーバー側の認可と組み合わせて考えます。また、OWASP はパスワード、トークン、API キーを URL に含めないよう求めています。URL に含めると Web サーバーのログに記録され、ログ自体が新たな取得対象になるためです。

API 以外に見直す項目

JPCERT/CC は、API 以外の汎用的な対策として次の項目も挙げています。

• Web サーバーなどが侵害された後の横展開対策の見直し
• 不正アクセスの検知体制と、検知時の初動対応の見直し
• 漏えい発生時を想定した、顧客への二次被害防止の呼びかけ（多要素認証など）
• 法令や契約で定められた保存期間を過ぎたデータや、利用目的を終えたデータの削除

ケース D のように公開 Web サーバーの先にあるアプリケーションサーバーが標的になる場合、公開サーバーから内部へ到達できる範囲を絞ることが横展開対策の起点になります。IPA も保有データの再点検として、不要な情報は持たないという原則のもとで、保有する情報を必要最小限にすることを求めています。

侵害が疑われる場合の初動対応

IPA は、外部公開アプリケーションや外部サービスで異常なログやアカウントを発見した場合、速やかにセキュリティインシデントと判定し、インシデント対応を進めるよう求めています。

参考: IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」
「専門のセキュリティベンダーに詳細調査を依頼することを強く推奨します。」
https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html

疑いの段階と侵害が確認された段階を分ける

段階	判断の例	主な対応
侵害の疑い	公表 IP アドレスとの一致、認証エラーの急増、見慣れない JSP へのアクセスなど、不正の可能性を示す記録がある	関連ログと対象システムの保全、影響範囲の調査、監視の強化、必要に応じた外部公開の一時制限
侵害の確認	不正なアカウント作成や権限変更、Web シェルの動作、データの取得などが確認された	封じ込め、認証情報の無効化、外部専門家への調査依頼、社内の責任者や法務への報告

疑いの段階でも、Metabase の侵害パターンのように侵害の可能性が高いとされる兆候や、進行中の不正操作が見られる場合は、確認を待たずに封じ込めへ進みます。

初動で並行して進める対応

ログと証拠の保全

Web、API、認証、アプリケーション、データベースのログを、保存期間で消える前に取得します。Web シェルなどの不審なファイルは、削除する前に配置日時や内容を記録し、可能であればファイルとサーバーの状態を保全します。

影響範囲の特定

不正な操作に使われたアカウントや API キーが参照できたデータ、接続先のシステム、同じ認証情報を使っている他のシステムを洗い出します。

認証情報の無効化

該当するアカウント、セッション、API トークン、API キーを無効化します。パスワードの変更だけでは、発行済みのトークンや API キーが有効なまま残る場合があります。Metabase の侵害が疑われる場合は、接続先データベースの認証情報も対象です。

外部公開の制限

侵害が疑われる管理機能や API、アプリケーションサーバーへの外部からの経路を制限します。サービス全体を停止するかは、業務への影響と被害拡大のリスクを比較して責任者が判断します。

専門家と関係機関への相談

社内での調査が難しい場合は、セキュリティベンダーに調査を依頼します。JPCERT/CC はインシデント対応依頼の窓口を、IPA は企業組織向けのサイバーセキュリティ相談窓口を案内しています。

個人情報保護委員会への報告の要否や、社外への公表・連絡の判断は、技術担当者だけで行わず、法務や個人情報保護の担当部門と進めます。報告制度の概要は、冒頭で紹介した国内事例の記事でも整理しています。

まとめ

JPCERT/CC の注意喚起は、特定製品の脆弱性だけでなく、外部から到達できるシステム全体の点検を求めるものです。4 つの攻撃手法は共通の経路ではないため、システムごとにログと設定を組み合わせて確認し、異常があれば保全と封じ込めを並行して進めます。

• ケース A〜D は事案ごとに異なり、共通の侵入経路を示すものではない。
• 外部公開の Web、API、管理機能、BI ツールを優先して洗い出す。
• 未修正の Metabase は最新の修正リリースへ更新し、侵害の有無も調べる。
• 公表 IP や User-Agent との一致は、侵害を確定する証拠ではない。
• 画面にない機能も API から実行できる前提で、認可を確認する。
• API キーは認可の代わりにならず、権限と有効期限を絞る。
• 異常時はログを保全し、認証情報の無効化と専門家への相談を進める。

以上、最後までお読みいただきありがとうございました。