【実務・中級編】脅威モデリング（STRIDE手法）の適用 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

現場のエンジニア諸君、日々のアジャイルな開発と終わりの見えない運用、本当にお疲れ様。

今日は「STRIDE」の話をする。教科書には「脅威モデリングのフレームワーク」なんて小難しいことが書いてあるが、俺たちにとってのSTRIDEは、「泥沼のインシデント対応を回避するための、最も効率的な防具」だ。

設計段階でこれを使わずにリリースするのは、目隠しで高速道路を走るようなものだ。今回は、特に生成AIを組み込んだWebアプリを想定し、実務で明日から使える「攻守一体」の視点をお伝えする。

—

1. なぜ「STRIDE」を設計段階で回すのか？

STRIDEは、Spoofing（なりすまし）、Tampering（改ざん）、Repudiation（否認）、Information Disclosure（情報漏洩）、Denial of Service（サービス拒否）、Elevation of Privilege（権限昇格）の頭文字をとったものだ。

多くのエンジニアが陥る罠は、リリース後のペネトレーションテスト（脆弱性診断）で脆弱性を見つけ、慌ててパッチを当てることだ。だが、設計段階でSTRIDEを適用すれば、「どこにどんな細工をされるか」を事前に想定できる。特に生成AIアプリでは、ユーザー入力がモデルを汚染する「プロンプトインジェクション」が現実的な脅威として立ちはだかる。

—

2. 実践：情報漏洩（Information Disclosure）を防ぐための実装

AIを活用したアプリでは、LLMへのプロンプトに機密情報を混ぜ込んでしまうケースが後を絶たない。これを防ぐための、API側でのガードレール実装例を見てみよう。

Python (FastAPI) によるプロンプトフィルタリングの例

ユーザーからの入力をそのままLLMに投げるのは自殺行為だ。まずは正規表現やライブラリを使って、個人情報や危険な命令が含まれていないかチェックするフィルタ層を設ける。

import re
from fastapi import FastAPI, HTTPException

app = FastAPI()

# 簡易的なDLP（Data Loss Prevention）フィルタ
# 本来は専用のライブラリやAIモデルでのチェックを推奨
def contains_sensitive_data(text: str) -> bool:
    # クレジットカード番号やメールアドレスのパターンを検知
    patterns = [
        r'\d{4}-\d{4}-\d{4}-\d{4}',  # クレカ番号（例）
        r'[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+' # メール
    ]
    for pattern in patterns:
        if re.search(pattern, text):
            return True
    return False

@app.post("/chat")
async def chat_with_ai(user_input: str):
    # 脅威検知：なりすましやインジェクションの兆候がないか確認
    if contains_sensitive_data(user_input):
        raise HTTPException(status_code=400, detail="機密情報が含まれています")
    
    # ここで安全なプロンプト構築ロジックへ渡す
    return {"message": "処理成功"}

—

3. インフラ・設定レベルでの防御（なりすまし・権限昇格対策）

クラウド環境における「なりすまし」を防ぐには、IAMロールの権限を最小化することが鉄則だ。特にAWS環境において、AIサービス（Amazon Bedrock等）を呼び出す際は、アプリケーションサーバーに不要な権限を与えてはならない。

AWS IAM ポリシーの最小権限設定（JSON例）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-xxxxxxxx"
        }
      }
    }
  ]
}

*ポイント：ConditionブロックでVPC内からのリクエストに限定することで、万が一アプリケーションサーバーのクレデンシャルが漏洩しても、外部からの直接利用を防げる。*

—

4. 現場のプロとしてのアドバイス：盲点はどこにあるか？

STRIDEを適用する際、多くのエンジニアが「外部との境界」ばかりを気にして、内部の連携を軽視する。

例えば、AIが生成したコードをそのままサーバーサイドで eval() や exec() して実行するような実装は、まさに「改ざん（Tampering）」と「権限昇格（Elevation of Privilege）」の温床だ。

鉄則1: AIの出力を信頼しない。必ずバリデーションを通すこと。
鉄則2: ログを「否認（Repudiation）」防止の要とせよ。誰がどのモデルに何を尋ねたか、メタデータを適切に記録し、改ざん不能なストレージ（S3のObject Lock等）に保存する。
鉄則3: WAFを設定する際、デフォルトの「SQLインジェクション検知」だけで満足するな。生成AI特有の大量リクエストによる「サービス拒否（DoS）」を防ぐため、レート制限（Rate Limiting）を厳しめに設定すること。

Nginxでのレート制限設定例

# 1IPあたり毎秒10リクエストに制限し、バーストを許可
limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=10r/s;

server {
    location /api/chat {
        limit_req zone=ai_limit burst=5 nodelay;
        proxy_pass http://backend_app;
    }
}

—

最後に

セキュリティは「完成して終わり」の静的な成果物じゃない。攻撃者も技術進化に合わせて常に戦術を変えてくる。STRIDEを使った脅威モデリングは、開発チームが「攻撃者の思考」をインストールするためのOSだ。

設計書を見直すとき、「ここで攻撃者はどうやって俺たちの想定を裏切るか？」と自問自答してほしい。その「疑い」こそが、最強のセキュリティ対策になる。

何かあったら、いつでも相談してくれ。共に堅牢なシステムを築いていこう。