現場のエンジニア諸君、お疲れ様。今日もどこかでAPIが叩かれ、どこかで誰かが認証を突破しようと血眼になっている。
「APIゲートウェイがあるから安心」と高を括っているなら、今すぐその考えを捨ててくれ。ゲートウェイは魔法の杖じゃない。正しく設定しなければ、それはただの「高くそびえ立つだけの門」であり、攻撃者はその下を潜り抜けるか、横から壁を壊す方法を常に探している。
今日は、APIの防衛線における「レートリミット」と「認証・認可」の統合について、現場の泥臭い教訓を交えて話そう。
1. 攻撃者が「レートリミット」をバイパスする瞬間
君たちが実装したレートリミットが、なぜ簡単に突破されるのか。答えはシンプルだ。「識別子の甘さ」にある。IPアドレスだけで制限をかけていないか？
攻撃者は分散ボットネット（DDoS）や、IPローテーションを駆使してくる。IPを1万個用意すれば、1万回のリクエストは「正当なアクセス」としてゲートウェイを通過する。これがブルートフォース攻撃の真骨頂だ。
対策の鉄則：
IPアドレスだけでなく、Authorizationヘッダーのトークン（JWTのsubクレーム等）や、ユーザーIDをキーにしたスロットリングを必ず組み合わせろ。
2. Nginxで実装する「多層防御」の設定
ゲートウェイの手前、あるいはゲートウェイそのものであるNginxで、まずは「雑音」を遮断する。単なるリミットではなく、バースト（急激なアクセス）を許容しつつ、平均レートを制御する設定がこれだ。
# Nginx設定: ユーザー単位のレートリミット
# $http_authorization をキーにすることで、IPがバラバラでもトークン単位で制限をかける
limit_req_zone $http_authorization zone=api_limit:10m rate=5r/s;
server {
location /api/ {
# 5リクエスト/秒を超えたら、バースト分は待機。それでも溢れたら即座に503を返す
limit_req zone=api_limit burst=10 nodelay;
# 認証が必要なエンドポイントは、必ずここでJWTを検証するフローへ回す
# ここで処理を止めないと、バックエンドのDBが死ぬ
...
}
}3. OAuth 2.0/OIDCとレートリミットの統合（Python実装）
認証の検証は、ゲートウェイで行うのが鉄則だ。バックエンドのアプリケーションに到達する前に「誰か」を特定し、「権限」を剥奪する。
以下は、FastAPIを使った認証検証の例だ。ここでは、レートリミットの判定ロジックを認証後に組み込むことで、攻撃者に「認証後のリソース」を無駄に消費させない工夫をしている。
from fastapi import FastAPI, Request, HTTPException, Security
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
import time
app = FastAPI()
security = HTTPBearer()
# 簡易的なインメモリ・レートリミッター（本番はRedisを使うこと！）
rate_limit_store = {}
async def verify_token(credentials: HTTPAuthorizationCredentials = Security(security)):
token = credentials.credentials
# 実際にはここでJWTの署名検証を行う
# user_id = decode_jwt(token).get("sub")
user_id = "user_123" # ダミー
# レートリミットチェック: 1分間に60回まで
now = time.time()
user_history = rate_limit_store.get(user_id, [])
user_history = [t for t in user_history if now - t < 60]
if len(user_history) >= 60:
raise HTTPException(status_code=429, detail="Too many requests. Chill out.")
user_history.append(now)
rate_limit_store[user_id] = user_history
return user_id
@app.get("/secure-data")
async def get_data(user_id: str = Security(verify_token)):
return {"message": f"Hello {user_id}, here is your secret data."}4. 現場で生き残るための「セキュリティ・マインドセット」
コードを書くだけで満足するな。以下の3点を常に自問自答してほしい。
1. 503エラーを「監視」しているか？
レートリミットが発動したというログは、攻撃の予兆そのものだ。ダッシュボードに「429/503の発生数」を可視化し、閾値を超えたらSlackに通知を飛ばせ。
2. 認証情報は「ヘッダー」以外で渡されていないか？
クエリパラメータでAPIキーを渡すような設計は、ログに機密情報が残るため即刻廃止だ。必ずAuthorization: Bearer <token>を使え。
3. 「失敗のコスト」を攻撃者に課せているか？
認証失敗時やレートリミット超過時のレスポンスは、可能な限り軽量にしろ。重いDB処理を走らせる前に、ゲートウェイで遮断するのが最大の防御だ。
セキュリティは「完成」しない。攻撃手法は常にアップデートされる。我々エンジニアがやるべきことは、攻撃コストを限界まで引き上げ、攻撃者のモチベーションを削ぐことだ。
もし今の君のシステムが、攻撃者に「このAPIは面倒だから他を狙おう」と思わせているなら、君の仕事は成功だ。自信を持って、セキュアな設計を突き詰めてくれ。また何かあればいつでも聞け。現場からは以上だ。
コメント