はじめに
前回の記事では、AIインフラの構成と、なぜそれが従来のセキュリティツールから見逃されやすいのかを解説しました。今回は一歩踏み込み、「見つけたAIサービスが具体的に何なのか」を特定し、「そこから何が読み取れるのか」を抽出する技術的なアプローチを解説します。
AIサービスはデバッグを容易にするため、意図的に「饒舌（Verbose）」に作られているものが多く、攻撃者（および監査者）にとって非常に情報が引き出しやすい特性を持っています。
1. AIサービスのフィンガープリント（特定）
ポートスキャンで「HTTP 8000番が開いている」だけでは不十分です。それが Triton なのか、vLLM なのか、それとも単なる Web サーバーなのかを特定する必要があります。
A. HTTP ヘッダー分析
多くのフレームワークは、レスポンスヘッダーに自身の正体を明かします。
-
TorchServe:
Server: TorchServe/0.x.x -
FastAPIベース:
Server: uvicornが見え、/predictなどのパスがあれば Python ML バックエンドの可能性が高い。 -
Triton: 特徴的な
NV-Statusヘッダーや、特定のメトリクスヘッダーを返します。
B. エラーメッセージの誘発（最も確実な手法）
AIサービスは「期待する入力形式（Tensor形状など）」が非常に厳格です。わざと**「意図的に間違った JSON データ」**を投げると、バックエンドがスタックトレースと共に親切に正解を教えてくれます。
Bash
# 誤ったペイロードをPOSTしてエラーを引き出す
curl -X POST http://target:8000/v2/models/model_name/infer -d '{"bad": "data"}'
-
TensorFlow Servingの場合: エラーレスポンスに
tensorinfo_mapという文字列が含まれていれば、ほぼ間違いなく TF Serving です。 -
MLflowの場合:
mlflow.serverやmlflow.trackingというネームスペースを含むスタックトレースが返ってきます。
C. gRPC の特定
Triton や TensorFlow Serving は、HTTP だけでなく gRPC（ポート 8001/8500）も公開しています。HTTP スキャナでは検知できません。
- grpcurl を使って反射（Reflection）を試みるのが定石です。
Bash
grpcurl -plaintext target:8001 list
もしこれが通れば、APIの全構造（どのようなデータを受け付けるか）が丸裸になります。
2. APIからの情報列挙（エニュメレーション）
サービスが特定できたら、次は「中身」を確認します。特に以下のサービスが稼働している場合、深刻な情報漏洩リスクがあります。
① MLflow：情報の宝庫
MLflow が認証なしで公開されている場合、以下の API を叩くだけで企業のML戦略がすべて見えます。
-
実験の全リスト:
POST /api/2.0/mlflow/experiments/search -
モデルのインベントリ:
GET /api/2.0/mlflow/registered-models/list -
Artifact URI:
GET /api/2.0/mlflow/model-versions/search- ここには S3 や MinIO のフルパスが含まれています。つまり、「どこにモデルが保存されているか」が分かります。
② 推論サーバー：モデルの仕様公開
Triton などで /v2/models/<name>/config を叩くと、入力テンソルの名前、データ型（FP32/INT8）、バッチサイズなどの詳細設定が返ってきます。これは、**「悪意ある入力（Adversarial Example）を生成するための設計図」**を渡しているようなものです。
③ Jupyter Notebook：神モードの鍵
もし Jupyter (8888番) が認証なしで動いていれば、それは単なるコード環境ではありません。
-
/api/kernelsで現在実行中のコードを確認。 - セル内に
HF_TOKENやAWS_ACCESS_KEYがハードコードされていることは珍しくありません。ここを見つければ、クラウド環境への侵入が完了します。
3. 推奨する監査用ツールセット
この偵察プロセスを自動化・効率化するためのツール例です。
-
Nmap: ポートスキャンの基本。
-sVでサービスバナーを確認。 - grpcurl: gRPC サービスを調べるための必須ツール。
-
ffuf / feroxbuster:
AI-specificなパスワードリスト（/v1/models, /api/kernels などを含む）を用いたディレクトリ探索。 - Nuclei: 既知のAI系CVEや構成ミスを自動検出するテンプレートを実行。
4. 防御者への提言：どうやって隠すか？
もしあなたが防御側なら、以下の対策を即座に実施してください。
- Verbose を殺す: エラーメッセージを詳細に返さないよう設定し、スタックトレースをログ出力のみに制限する。
- 認証の強制: AI系ダッシュボード（MLflow, Jupyter, Kubeflow）をインターネットに直公開するのは論外です。認証ゲートウェイを挟んでください。
-
パスの制限:
/v2/modelsや/metricsなど、本来外部に公開する必要のない管理エンドポイントを Nginx 等のリバースプロキシで遮断する。
まとめ
AIサービスの偵察は、「相手が何者で、何を持っているか」をAPIを通して対話するプロセスです。「デバッグに便利な機能」は「攻撃者にとっても便利な情報源」 であることを忘れないでください。