はじめに

前回の記事では、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を通して対話するプロセスです。「デバッグに便利な機能」は「攻撃者にとっても便利な情報源」　であることを忘れないでください。