AI時代の「財布を狙う」DoS攻撃：推論コストを悪用させない防御術
現場でシステムを回しているエンジニアなら一度は考えたことがあるはずだ。「LLMのAPI、外部から叩き放題にしていたら、月末の請求書で泡を吹くんじゃないか？」と。
その懸念、全くもって正しい。従来のWebアプリにおけるDoS（サービス拒否）攻撃は「サーバーをダウンさせてサービスを止める」のが目的だったが、生成AI時代のDoSは「推論コストを跳ね上げさせて、運営の財布を空にする（あるいはクラウドの利用制限をトリガーさせてサービスを停止させる）」という、よりエグい手法に進化している。
今回は、セキュリティ責任者の視点から、この「コスト攻撃」をいかに防ぐか、泥臭い防衛戦術を解説する。
—
1. なぜAIシステムは「コスト攻撃」に脆いのか
通常のAPIと異なり、AIモデルの推論は「計算量＝コスト」に直結する。特にトークン消費量やGPUリソースを直接消費する設計の場合、攻撃者は以下のような手口を仕掛けてくる。
- 長文プロンプト攻撃: 許容範囲ギリギリの最大トークン数を指定したリクエストを大量に投げ続ける。
- 並列推論飽和: 短時間に数千のリクエストを同時に投げ、GPUメモリを枯渇させ、正当なユーザーの推論をタイムアウトに追い込む。
これらは単なる「負荷試験」ではない。ビジネスの継続性を破壊するれっきとした「攻撃」だ。
—
2. 実践的防御：レート制限とクォータ管理の多層防御
防御の基本は「誰が、どのくらいのコストを使っているか」を追跡し、閾値を超えたら即座に遮断することだ。API GatewayやWAFだけで解決しようとせず、アプリケーション層との組み合わせで守るのが定石だ。
2.1. Nginxによるリクエスト制限（入り口での遮断）
まず、あまりに異常なリクエスト頻度はWebサーバーの入り口で捨てる。
# nginx.conf: 特定IPからの過度なアクセスを制限する設定
# 1分間に30リクエストまで。超過した場合は 429 Too Many Requests を返す
limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=30r/m;
server {
location /api/v1/generate {
limit_req zone=ai_limit burst=10 nodelay;
proxy_pass http://backend_cluster;
}
}2.2. アプリケーション層でのトークンベース・レート制限（Python/FastAPI）
IPアドレス制限だけでは、分散型攻撃（DDoS）やNAT越しのユーザーを巻き込む。重要なのは「ユーザーID」に基づいた「トークン消費量」の管理だ。
# FastAPI + Redis を使ったトークン消費制限の実装例
import time
from fastapi import FastAPI, HTTPException, Request
import redis
app = FastAPI()
r = redis.Redis(host='localhost', port=6379, db=0)
async def check_token_quota(user_id: str, estimated_tokens: int):
key = f"quota:{user_id}"
# ユーザーごとの1時間あたりの消費トークン制限 (例: 100,000トークン)
current_usage = r.get(key)
if current_usage and int(current_usage) > 100000:
raise HTTPException(status_code=429, detail="クォータ上限に達しました")
# 消費量をインクリメント（1時間で期限切れ）
r.setex(key, 3600, int(current_usage or 0) + estimated_tokens)
@app.post("/generate")
async def generate(request: Request):
user_id = request.headers.get("X-User-ID")
# プロンプトのトークン数を概算（文字数 / 4 など）
prompt = await request.json()
tokens = len(prompt.get("text", "")) // 4
await check_token_quota(user_id, tokens)
# ここでLLMの推論処理を実行
return {"status": "success"}—
3. セキュリティ責任者からの「最後の助言」
コードを書いて終わりではない。以下の3点は運用フェーズで必ず守ってほしい。
1. 観測なき防御は無意味: 429エラーを返した際に、それを単なるエラーとして埋もれさせないこと。ログを集約し、異常なスパイクが発生した際に管理者にアラートが飛ぶ仕組み（DatadogやCloudWatchのメトリクスアラート）を構築する。
2. コストの可視化: ユーザーIDごとに「いくら分のお金を消費したか」をBIツールで追跡できるようにしておけ。赤字を垂れ流すユーザーを特定できなければ、ビジネスとしてのセキュリティは成立しない。
3. フェイルセーフの設計: 万が一、レート制限をすり抜けて攻撃が行われた際、バックエンドのLLM側で「最大出力トークン数」を厳しく制限しておくこと。これにより、APIが乗っ取られたとしても、被害額に上限を設けることができる。
セキュリティとは「鉄壁の城を築くこと」ではなく、「いざという時に傷口を最小限にする仕組みを作ること」だ。今回紹介した実装をテンプレートとして、君たちのプロダクトに合った「防壁」を今すぐ構築してほしい。
何かあれば、またいつでも相談に乗る。健闘を祈る。
コメント