AIセキュリティ要件定義書（SRD）の「嘘」を見抜き、実戦的ガードレイルを実装する
多くの企業が策定する「AIセキュリティ要件定義書（SRD）」は、得てして空虚なコンプライアンス文書に成り下がる。ISO 27001の枠組みをなぞっただけの、AIの特性を無視したチェックリストなど、攻撃者にとっては格好の餌食だ。
我々が向き合うべきは、LLMの確率的挙動が生む「論理的脆弱性」と、従来のソフトウェアが抱える「低レイヤのメモリ汚染」という二重の地獄である。本稿では、テックリードが設計段階で組み込むべき、泥臭くも強固なセキュリティ要件定義の勘所を伝授する。
—
1. 攻撃対象領域を「プロンプト」に限定しない
多くの技術者は、生成AIに対するセキュリティを「プロンプトインジェクション対策」と同義だと誤解している。しかし、真の攻撃者はLLMのバックエンドにあるコンテキストウィンドウの枯渇（DoS）、あるいはトークナイザの境界を突いたエンコーディング攻撃を狙う。
要件定義書には、以下の「物理的・論理的境界」を明記せよ。
- 入力の正規化: トークン化前のバイト列レベルで制御文字やNULLバイトをサニタイズする。
- 通信の健全性: 推論サーバーとの対話は、TLS 1.3以上かつ証明書ピンニングを強制する。
- メモリ安全性: 推論エンジン（C++/Rust）におけるバッファオーバーフローを防止するため、メモリ安全なインターフェースを介したパラメーター受け渡しを設計する。
—
2. ガードレイル・アーキテクチャの実装要件
プロンプトインジェクションを防ぐためのガードレイルは、「LLMの外側」に置く必要がある。ユーザー入力をそのままモデルに流し込むのは、玄関の鍵を開けたまま外出するようなものだ。
以下は、ガードレイル層で実施すべき「入力・出力検証」の論理構造である。
# ガードレイル：入力バリデーションのサンプル
def validate_input(user_input):
# 1. 構造化攻撃の検出（プロンプトの注入パターンを正規表現で排除）
# 2. コンテキスト長制限の適用（過剰なトークン入力によるメモリ負荷を防止）
max_tokens = 2048
if len(user_input) > max_tokens:
raise SecurityException("トークン制限超過。攻撃の可能性があるため遮断します。")
# 3. 再帰的サニタイズ：HTMLタグやスクリプトタグの除去
# 注意: <script> や <iframe> 等を単に削除するのではなく、
# 実行不可なエスケープ状態に変換する
sanitized_input = escape_html_entities(user_input)
return sanitized_input—
3. 推論時における「シリアライゼーション」の盲点
AIシステムにおいて、モデルの重みファイルや設定ファイルは、攻撃者の標的だ。特に、不適切なシリアライゼーション（例：pickleの使用）は、任意コード実行（RCE）の入り口になる。
要件定義書には「信頼できないソースからのモデル読み込み禁止」を必ず盛り込み、以下のチェックを自動化パイプラインに組み込む。
- モデルの署名検証: ロード前にハッシュ値（SHA-256以上）を照合し、改ざんを検知する。
- サンドボックス実行: 推論プロセスは、必要最小限の権限（Least Privilege）を持つコンテナ内で実行し、外部ネットワークへのアクセスを物理的に制限する。
—
4. 耐量子暗号（PQC）への意識的移行
現時点では「未来の話」として片付けられがちだが、大規模言語モデルのトレーニングデータや機密性の高い推論ログは、今日奪われれば将来的に復号されるリスクがある（Store Now, Decrypt Later）。
要件定義書には、将来的な暗号スイートの更新を見越した「アジリティ（俊敏性）」を盛り込むべきだ。
- 暗号化要件: 現在のAES-256に加え、将来的にKyber等の耐量子暗号アルゴリズムへプラグイン式で移行可能なアーキテクチャを選択する。
- 鍵管理: 暗号鍵はHSM（ハードウェアセキュリティモジュール）内で管理し、ソフトウェア層から直接アクセスさせない。
—
5. 監査：ログから見える「攻撃の予兆」
防御は完璧ではない。重要なのは、何が起きたかを事後的に、かつ瞬時に特定できるログ設計だ。
監査ログに含めるべき最低限のメタデータ
1. プロンプト・トークン詳細: どのユーザーが、どのようなエンコーディング形式で何を入力したか。
2. 推論の確率分布: モデルの出力が異常に低い信頼度（Confidence Score）を示していないか。
3. システムコール監視: 推論エンジンが意図しないライブラリをロードしていないか（strace等による継続的な観測）。
—
最高責任者からの提言
AIシステムのセキュリティは、境界防御の時代から「データそのものへの信頼性（Data Integrity）」を巡る戦いへとシフトした。SRDは、単なるドキュメント作成作業ではない。「どの部分を信じ、どの部分を完全に疑うか」という、システムとしての哲学を定義する作業である。
「便利さ」と「安全性」のトレードオフにおいて、安全性を犠牲にする判断は、技術者として一度でもあってはならない。攻撃者は常に我々のSRDの隙間、つまり「例外処理」の先にある混沌を狙っていることを忘れるな。
次のステップとして、自身のシステムで直近のログを抽出し、異常なトークン分布がないか確認することから始めてほしい。それが、セキュリティアーキテクトとしての第一歩だ。
コメント