【テクニカル・上級編】 生成AI利用ガイドラインの策定と禁止事項の定義 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

生成AI時代のガバナンス：プロンプトインジェクションとデータ漏洩を防ぐ「防衛層（ガードレイル）」のアーキテクチャ設計

世の中の多くの企業が「生成AI利用ガイドライン」と称して、「機密情報を入力するな」「出力されたコードをそのまま本番環境にデプロイするな」といった、抽象的で無力なポスターのような文書を量産している。CISSPホルダーとして、また現場で数々のインシデントを踏んできたセキュリティアーキテクトとして断言しよう。人間の善意やリテラシーに依存したセキュリティポリシーなど、高度な攻撃者の前では紙くずと同然だ。

LLM（大規模言語モデル）のAPIやチャットインターフェースは、従来のWebアプリケーションにおけるSQLインジェクションやクロスサイトスクリプティング（XSS）とは根本的に異なる攻撃面（Attack Surface）を持つ。入力データと制御命令が同一のコンテキストウィンドウ（プロンプト）に混在するという、LLMの構造的な脆弱性を突かれるからだ。

本稿では、従業員のうっかりミスや悪意あるプロンプトインジェクションを物理的・論理的に封じ込めるため、APIゲートウェイとプロキシ層に実装すべき「実戦的なガードレイルのアーキテクチャ」と、ポリシーのコード化について深く掘り下げて解説する。

—

1. なぜ「ガイドラインの周知」だけでは防げないのか

「機密情報の入力禁止」というルールを定めても、開発者はデバッグのためにスタックトレースをそのまま貼り付け、営業は顧客のプライバシー情報が含まれた提案書を要約させ、情シスはインフラの構成図をLLMに投げ込んでリファクタリングを指示する。

なぜなら、LLMの利便性は人間の認知バイアス（効率化の誘惑）を容易に凌駕するからだ。セキュリティ部門がやるべきは、従業員に「気をつけるよう教育すること」ではなく、通信パケットのレイヤ、あるいはアプリケーションのプロキシ層で機械的に「悪性・機密データ」を遮断するメカニズムの強制である。

ここで定義すべき「禁止事項」は、単なるテキストのポリシーではなく、後述するDLP（Data Loss Prevention）エンジンとLLMファイアウォールで検証可能な「拒絶条件」でなければならない。

—

2. アーキテクチャ全体像：LLMプロキシ層でのガードレイル実装

従業員が利用するクライアント（ブラウザ、IDE拡張、社内チャットボット）と、外部LLMプロバイダ（OpenAI, Anthropic, 自社ホストのLlama 3等）の間に、専用のセキュリティプロキシ（API Gateway / Reverse Proxy）を配置する。

[ 従業員端末 (IDE / ブラウザ) ]
       │
       ▼ HTTPS (JSON Payload)
[ セキュリティプロキシ (LLM Firewall) ]  <-- ★ここで全リクエスト/レスポンスを検査
       │
       ├─ (NG) -> 403 Forbidden + SOCアラート発報
       │
       ▼ (OK: サニタイズ・難読化済み)
[ 外部 LLM API (OpenAI / Anthropic 等) ]

このプロキシ層で実装すべき主要な防衛機能は以下の3点だ。
1. 正規表現および固有表現抽出（NER）による機密情報の検出とマスキング
2. 間接的・直接的プロンプトインジェクションの検知
3. 出力されるハルシネーションや危険なコード（脆弱性含有コード）のフィルタリング

—

3. 実装コード例：PythonによるLLMプロキシ・ガードレイルの構築

FastAPIを用いた軽量なLLMセキュリティプロキシのサンプルを示す。このコードは、リクエストボディに含まれる機密データ（APIキー、個人情報、内部IPアドレス）を検出し、LLMに到達する前にブロックあるいはマスキングする処理の骨子である。

import re
from fastapi import FastAPI, HTTPException, Request
from pydantic import BaseModel, Field

app = FastAPI(title="Secure LLM Gateway", version="1.0.0")

# 検出対象の機密パターン（正規表現の例）
# 実運用ではより堅牢なNER（固有表現抽出）モデルや専用のDLPエンジンを併用する
SENSITIVE_PATTERNS = [
    {"name": "AWS_Access_Key", "pattern": r"AKIA[0-9A-Z]{16}"},
    {"name": "Private_IP", "pattern": r"(?:10|172\.(?:1[6-9]|2[0-9]|3[0-1])|192\.168)\.\d{1},\.\d{1}"},
    {"name": "Credit_Card", "pattern": r"\b(?:\d{4}[-\s]?){3}\d{4}\b"},
]

class LLMRequest(BaseModel):
    model: str = Field(..., description="利用するLLMモデル名")
    prompt: str = Field(..., description="ユーザーからの入力プロンプト")

def scan_for_sensitive_data(text: str) -> list[str]:
    """テキスト内から機密情報のパターンをスキャンし、ヒットした項目のリストを返す"""
    detected = []
    for item in SENSITIVE_PATTERNS:
        if re.search(item["pattern"], text):
            detected.append(item["name"])
    return detected

def detect_prompt_injection(prompt: str) -> bool:
    """
    簡易的なプロンプトインジェクション検知
    「指示の無視」や「システムプロンプトの開示要求」を模した攻撃パターンを検証
    """
    injection_signatures = [
        r"ignore previous instructions",
        r"これまでの指示を無視",
        r"system prompt",
        r"あなたは誰ですか",
        r"output the exact text above",
    ]
    for sig in injection_signatures:
        if re.search(sig, prompt, re.IGNORECASE):
            return True
    return False

@app.post("/v1/chat/completions")
async def proxy_to_llm(req: LLMRequest, request: Request):
    """
    LLMへのリクエストをインターセプトし、セキュリティ検査を行うエンドポイント
    """
    user_prompt = req.prompt

    # 1. プロンプトインジェクション検知
    if detect_prompt_injection(user_prompt):
        # セキュリティインシデントとしてSIEMへログを飛ばす処理をここに記述
        raise HTTPException(
            status_code=403,
            detail="Security Violation: Potential prompt injection attack detected."
        )

    # 2. 機密情報（DLP）チェック
    leaks = scan_for_sensitive_data(user_prompt)
    if leaks:
        raise HTTPException(
            status_code=403,
            detail=f"Data Loss Prevention (DLP) Violation: Sensitive data detected: {', '.join(leaks)}"
        )

    # 3. 検査を通過した安全なリクエストのみ、上流のLLM APIへ転送する処理（略）
    # 実際にはここでrequestsやhttpxを使ってOpenAI等のAPIを叩く
    
    return {
        "status": "success",
        "message": "Prompt passed security guards and forwarded to LLM.",
        "sanitized_prompt": user_prompt
    }

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8080)

—

4. 監査とインシデントハンドリングの観点

このような技術的ガードレイルを導入した上で、CISOやセキュリティ監査チームが注視すべきポイントは以下の通りだ。

1. シャドーAIの完全な遮断:
社内ネットワークおよび端末からの直接通信（SSL/TLS）において、未承認のAIサービスドメインへのアクセスをファイアウォールやEDR（Endpoint Detection and Response）で強制的にブロックすること。「ガイドラインで禁止しているからアクセスしないだろう」という性善説はエンジニアリングの世界では通用しない。
2. 監査ログの網羅性:
プロキシ層を通過したすべてのプロンプトとレスポンスのメタデータ（タイムスタンプ、ユーザーID、IP、検出された脆弱性フラグ）をイミュータブル（改ざん不能）なストレージに保存する。万が一インシデントが発生した際、どの従業員がどのようなコンテキストで機密情報を流出させようとしたか、あるいは不正なプロンプトインジェクションが試行されたかをフォレンジックできなければならない。
3. 耐量子暗号（PQC）への過渡期における通信路の保護:
LLMプロバイダとの通信において、将来的な「Harvest Now, Decrypt Later（今盗んで将来復号する）」攻撃を防ぐため、TLS 1.3におけるハイブリッド鍵交換アルゴリズム（例: X25519Kyber768 等）の適用をインフラ層で検討し始める時期に来ている。

結び

生成AI利用ガイドラインの策定とは、言葉を飾ったルールの文書化ではない。それは「人間の認知の限界と悪意ある入力を前提とした、境界防御アーキテクチャのコード化」に他ならない。

テックリードやセキュリティアーキテクトであるあなた方が行うべきは、ポリシーの文章を推敲することではなく、開発者や従業員が「不安全な使い方をしたくても、システム的にできない環境」を構築し、守りの要塞をコードで組み上げることなのだ。

スポンサーリンク

コメント

タイトルとURLをコピーしました