はじめに

本シリーズでは、AIインフラの偵察（Reconnaissance）、フィンガープリント、情報列挙、そして攻撃面マッピングについて解説してきました。攻撃者の視点を知ることは、防御の第一歩です。

しかし、攻撃を「防ぐ」だけで十分でしょうか？現実には、攻撃者は必ず一度はスキャンを試みます。そこで重要なのが、彼らの「足跡（痕跡）」を見つけ出し、侵入が成立する前に検知する「守りの仕組み」です。

最終回となる今回は、AIインフラの偵察活動を SIEM（Security Information and Event Management）で検知するための具体的なログ戦略と、即効性のある防御策（Hardening）を解説します。

1. 攻撃者は必ず「ノイズ」を残す

AIインフラの偵察は非常に強力ですが、完全に隠密に行うことは困難です。なぜなら、彼らは特定の API を執拗に叩く必要があるからです。

以下の表は、SIEM で追跡すべき「偵察活動の代表的な兆候」です。

検知対象の動き	SIEM での検知ロジック (指標)	攻撃フェーズ
AIポートへの掃射	短時間に 5000, 8000, 8888 などの特定ポートへ連続接続	アクティブスキャン
辞書攻撃（ディレクトリ探索）	`/v2/models`, `/api/2.0/mlflow`, `/v1/schema` への 404 レスポンス急増	指紋特定/列挙
Prometheus の不正アクセス	許可された監視 CIDR 以外からの `/metrics` アクセス	情報抽出
API の不自然なアクセス	UI（ブラウザ）を通さない、スクリプトによる連続的な API コール	情報抽出/列挙

検知ロジックを組むためには、ログがなければ始まりません。AIインフラ側で最低限出力すべきログ設定は以下の通りです。

API Gateway / Reverse Proxy ログ:
- 送信元 IP、リクエストパス、ステータスコード、User-Agent を記録。
- ポイント: ここで「非正規の User-Agent（python-requests, curl, nmap 等）」をフィルタリングします。
アプリケーションログ:
- MLflow や Triton のログ出力レベルを INFO 以上に設定し、特定 API へのアクセスを記録。
- ポイント: 認証エラー（401/403）の発生頻度を監視します。
ネットワークフローログ:
- 内部コンポーネント間（例: Jupyter -> MLflow）の通信フロー。
- ポイント: 通常の通信経路を外れた通信（例: 開発用 Notebook が直接本番 DB にアクセスしようとする等）をアラート対象にします。

ログを監視しつつ、インフラ側で以下の「クイックウィン（即効性のある対策）」を実施することで、偵察の難易度を劇的に引き上げることができます。

認証をフロントに置く:
- 鉄則: MLflow, Kubeflow, Jupyter は絶対にインターネットに直公開しない。
- 対策: Nginx や Traefik を用いたリバースプロキシを配置し、OIDC や基本認証を強制する。
管理エンドポイントの隠蔽:
- Prometheus の /metrics や Triton の /config などは、管理用 CIDR 以外からは 404 を返すようプロキシで制御する。
情報漏洩の抑制 (Verbose の無効化):
- 運用フェーズのサービスでは、スタックトレースや詳細なエラーメッセージを返さない設定にする。
Credential 管理の刷新:
- Notebook 内への API Key 直書きを検知するツール（TruffleHog 等）を CI/CD に組み込む。

本シリーズで学んだ知識を、組織の「セキュリティ成熟度」として整理しましょう。

本シリーズ「AI セキュリティ攻防」を通じて、以下のことをお伝えしました。

AI 技術は急速に進化していますが、「適切な認証」「最小権限」「可視化」 というセキュリティの基本は変わりません。AI インフラを運用するすべてのエンジニアが、少しでもこの視点を持つことで、より安全な AI 社会が作られることを願っています。