前回、攻撃者が探しているのは「鍵・鍵穴・地図が揃った、すぐ使える場所」だと書いた。
結びは「地図をゼロにはできない」だった。
では、守る側は何をすればいいのか。
今回はその続きを書く。
マクニカ セキュリティ研究センターの集計では、国内Webシステムからの個人情報漏えいは、今年10月6日時点で119件。そのうち81件が7月以降に公表されている。
ただし、この81件のうち65件は、公表内容だけでは原因を分類できない。すべてが同じ手口だったと分かっているわけではない。
それでも、実際の事案対応やログ分析からは、特定の脆弱性だけを探すのではない動きが確認されている。
サイト全体を広く調べ、画面やAPIを普通に動かしながら、情報に届く不備を探す。
狙われているのは、データを返しすぎるAPI、権限が大きすぎるAPI、ログインしていなくても会員向けの機能に届いてしまう作りなどだ。
10月8日に公開されたJPCERT/CCの注意喚起は、確認されている手口をケースごとに整理している。既知の脆弱性を探して試すもの、API経由の不正な操作、Metabaseの脆弱性を突くものなどだ。
このうち、今回注目したいのはAPI経由の不正な操作で、次の手口が挙がっている。
既知の脆弱性も、弱いパスワードも、今も使われている。パッチは必要だ。
ただ、それだけでは届かない場所も狙われている。
CVE番号が付かない、そのサイト固有の作りだ。
攻撃者は、目隠しをしたままゾウに触っているようなものだ。
フロントを読み、アプリを解析し、応答の違いを比べる。触れたところから、全体の形を少しずつ推し量っていく。
時間をかければ、形はかなり分かる。前回書いたとおりだ。
しかし、守る側は本来、目隠しをする必要がない。
ソースコードがある。API仕様がある。設計書もあるはずだ。
長年動いているシステムでは、それらが揃っているとは限らない。それでも、外から手探りする攻撃者より、はるかに多くの情報に手が届く立場にいる。
そして、外から触るだけでは分かりにくいものを、もう一つ持っている。
どの扉を、誰に開けるべきかという、設計の意図だ。
どの利用者に何を許すのか。それを決められるのは、事業を運営している側だけだ。
手が届く情報の量で言えば、守る側の方が圧倒的に有利なはずだ。
理由を、前回の三つの言葉で考えてみる。
鍵穴、地図、鍵だ。
問題は、入口が見えていることだけではない。その入口で、正しく権限を確かめているかどうかだ。
見えないから負けるのではない。見える立場にいるのに、確かめていないからだ。
一つずつ見ていく。
鍵穴を、塞いでいるか
まず、要らない入口が外に出ていないか。管理画面、デバッグ用の画面、使っていないAPI。
次に、必要な入口が、開いてはいけない鍵で開かないか。
最近の事案でいちばん問われているのは、ここだ。
どちらも、共通ソフトウェアの更新パッチを当てるだけでは直らない。そのアプリ自身が、誰に何を許すかという作りの問題だからだ。
地図を、見せすぎていないか
地図はゼロにはできない。
フロントがAPIを呼ぶ以上、呼び方は外から見える。外との接面は、そのまま設計書として読まれる。
ただ、出さなくていい分まで出す必要はない。
鍵を、取られていないか
JPCERT/CCが挙げた手口には、鍵を手に入れる経路が二つあった。公開アプリの解析と、別のシステムへの侵害だ。
取られたことに気づけるか、という問いもある。これは後でもう一度書く。
「脆弱性診断は受けています」だけでは、ここまでは答えられない。
診断を受けていても、管理画面のような外に見せない機能は、診断の範囲から漏れやすい。マクニカもこの点を指摘している。
外から動かして確かめられることは多い。
他人のIDに書き換えたら、他人の情報が見えるか。一般ユーザーのまま、管理者向けのAPIを呼べるか。これは、許可を得たうえで外から試せば分かる。
しかし、画面から辿れないAPIや、内部でどう権限を判断しているかまでは、外からの検査だけでは把握しきれないことがある。
逆に、コードの上では正しく見えても、実際の設定や環境で意図どおりに動くとは限らない。
そして、コードが設計どおりに動いていても、設計そのものが間違っていることがある。
だから、三つを組み合わせる。
手探りの攻撃者より先に、見える立場にいる側が、自分で確かめておく。
AikidoのAI Pentestは、AIエージェントが実際に動いているアプリを操作し、脆弱性が本当に悪用できるかを確かめる。
コード上の疑いにとどめず、実際のリクエストと応答を証拠として示す。
攻撃が成立しやすくなる設定の不備（TLS、セキュリティヘッダー、レート制限の欠如など）も、検査の対象に入る。
外からの検査（ブラックボックス）だけでも実行できる。そのうえで、渡すものを増やすほど、検査は深くなる。
コードを読む。動かして試す。設計の意図と比べる。
ホワイトボックスで行うAIペネトレーションテストは、先ほどの三つを同じ検査の中で行う。
破られる三つの理由とは、こう対応する。
JPCERT/CCが挙げた手口との重なりも大きい。
権限の変更、NoSQLインジェクション、そして対策に挙がっていたレート制限。いずれも検査項目に入っている。
対象は、WebアプリケーションとAPIだけではない。
Androidアプリ（現時点ではソースコードの接続が前提）、チャットやRAGなどのAIエージェント機能、MCPサーバーも検査できる。
AIエージェントは、鍵を預かって、代わりに回す存在だ。権限の低い利用者が、エージェント経由で別の役割やテナント向けの操作に届かないか。これも検査項目に入っている。
ただし、順番がある。
最近の事案を受けて最初に確かめるべきなのは、自分のシステムが既に侵害されていないかだ。
鍵は、知らない間に取られる。
不審なAPIアクセス、管理機能の利用、大量のデータ取得がなかったか。まずログを調べる。マクニカも、対策の一番目にこれを挙げている。
AI Pentestは、過去の侵害の有無を確かめるログ調査やフォレンジック調査の代わりにはならない。
その次に、同じような侵入が成立する入口が残っていないかを調べる手段だ。
そのうえで、新しく作るシステムだけでなく、既に動いているアプリこそ試してほしい。
何年も動いているアプリほど、当時の設計の前提を覚えている人がいない。
どの鍵で、どの扉まで開く設計だったのか。
それを、いま動いているコードで確かめ直す。
一つ、注意がある。
当てる先は、本番そのものではなく、同じ構成の検証環境にしてほしい。 Aikidoも、それを強く勧めている。
エージェントは、問題を証明したところで止まる。それ以上掘り進めたり、データを抜き出したりはしない。さらに深く試すかどうかは、人が攻撃の内容を見てから選ぶ（Exploit Further）。
証明の多くは、無害な形で行われる。たとえばSQLインジェクションなら、データを消すのではなく、応答を数秒遅らせて確かめる。
それでも、データを変更したり削除したりしないと証明できない問題が、少数ある。本番でそれが起きれば、実在のファイルや注文が消えるおそれがある。
だから、検証環境で行う。
ただし、検証環境という名前だけでは安全にならない。本番のデータベースや実際の顧客情報につながったままなら、影響は本番に及ぶ。データも認証情報も、検証用に分けておく必要がある。
負荷が心配なら、毎秒のリクエスト数に上限を設け、業務時間外に走らせることもできる。攻撃の段階に入ってからは、一時停止もできる（手動では3回まで）。
対象や規模によって変わるが、数時間で結果を得られることもある。見つかった問題は、直したあとに再テストできる。
一度確かめても、その後の改修で新しいAPIが増え、認可の条件が変わる。
年に一度の診断という間隔では、その変化に合わない。
Aikidoには、初回の検査を土台に、デプロイ時や指定した間隔で、変更内容に応じた検査を行う仕組み（Continuous Pentesting）もある。
初回の検査を終えていること、リポジトリを接続していることなどの利用条件はある。それでも、一度の検査で終わらせず、変更に合わせて繰り返せる。
見つけて、直して、もう一度試す。
そして、次に同じ操作をされたら検知できるようにする。
ここまでが一続きだ。
できないことも書いておく。
今回の一連の事案について、AIの使用を裏づけるログは見つかっていない。
マクニカはそう書いたうえで、これだけ多くのサイトを一つずつ調べる作業は人手では回らず、AIが使われていないと考える方が無理がある、という見方を示している。
実際に確認されているのは、サイト固有の不備を広く探る動きだ。
攻撃者は、手探りで鍵穴を探し、地図を読み、使える鍵を試す。
守る側は、目隠しをする必要がない。ソースコードにも、API仕様にも、設計の意図にも手が届く。
その優位を、使わない理由はない。
攻撃者より先に、自分のシステムを試しておく。一度ではなく、変更のたびに。
攻撃者がAIを使った証拠を待つ必要はない。守る側は、今日からAIを使える。
Aikido Community Japan
公開日: 2026/10/9
最終更新: 2026/10/9
セキュリティの最新情報をお届けします。