現場で泥をすすりながらインシデント対応をしていると痛感するんだが、「暗号化しています」という言葉ほどあてにならないものはない。
「SSL/TLSを入れているから大丈夫」と胸を張るエンジニアに限って、実はTLS 1.0/1.1の脆弱な暗号スイートを許容していたり、Bearerトークンを無防備にログに残していたりする。今日は、API認証の要であるトークン漏洩を防ぐための、現場で「死ぬ気で守るべき」実装と設定について話そう。
—
1. なぜ「Bearerトークン」はこれほどまでに狙われるのか？
Bearer（持参人）トークンはその名の通り、持っているだけで本人とみなされる「物理的な鍵」だ。これが漏洩すれば、攻撃者はあなたの認証基盤をバイパスし、正規ユーザーになりすます。
攻撃者が狙うのは、通信経路の「隙間」だ。特に公衆Wi-Fiや、設定が甘いプロキシサーバーを経由した際の「中間者攻撃（MITM）」は古典的だが、今でも強力だ。攻撃者はSSL Stripのような手法を使い、強制的にHTTPへダウングレードさせ、暗号化されていない平文のトークンを横取りする。
これを防ぐための鉄則はシンプルだ：「通信を許可するな。暗号化されていない通信は、存在しないものとして扱え」。
—
2. NginxでTLS 1.3を強制し、HSTSで「帰路を断つ」
TLS 1.3は、過去の脆弱なプロトコル（TLS 1.0/1.1など）をバッサリと切り捨てた、現在最強のプロトコルだ。これをNginxで強制し、さらにHSTS（HTTP Strict Transport Security）でブラウザに「二度とHTTPでアクセスするな」と誓約させる。
以下は、本番環境で推奨するNginxのサーバーブロック設定だ。
server {
listen 443 ssl http2;
server_name api.example.com;
# TLS 1.3のみを許可し、古い脆弱なプロトコルを排除
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# HSTS: ブラウザに対して「今後1年間はHTTPS以外で接続するな」と命令する
# includeSubDomains: サブドメインも対象に
# preload: HSTSプリロードリストへの登録を許可
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# 不正なHTTPリクエストは即座に拒否する設計がベスト
location / {
# トークン漏洩の温床となるRefererヘッダーを抑制
add_header Referrer-Policy "no-referrer" always;
# XSS対策もセットで
add_header X-Content-Type-Options "nosniff" always;
}
}—
3. アプリケーションコード側での「防御的実装」
通信経路を固めても、アプリ側のコードがずさんなら意味がない。特にバックエンドでAPIのトークンを扱う際、ログ出力やエラーハンドリングでトークンが漏洩するケースが後を絶たない。
Python (FastAPI) でのセキュアな認証実装例
認証の際、トークンを安易にログに出力しないようにするのは基本中の基本だ。
from fastapi import FastAPI, Depends, HTTPException, Header
import logging
# ログ設定: トークンが混入しないよう注意
logger = logging.getLogger(__name__)
app = FastAPI()
def get_token(authorization: str = Header(...)):
# Bearer スキームの確認
if not authorization.startswith("Bearer "):
raise HTTPException(status_code=401, detail="Invalid Auth Scheme")
# トークンの実体のみを抽出
token = authorization.split(" ")[1]
# ここで決して token 変数をログに出力してはならない！
# logger.debug(f"Received token: {token}") # 絶対にNG
return token
@app.get("/secure-data")
def read_data(token: str = Depends(get_token)):
# 認証処理のロジック
return {"data": "機密情報です"}—
4. 現場の盲点：ログ監視とWAFの役割
最後に、どれだけ堅牢な設定をしても「設定ミス」や「ゼロデイ脆弱性」は防ぎきれない。
1. ログのマスキング: Fluentd や Logstash のパイプラインで、正規表現を使って Authorization: Bearer <token> のようなパターンを自動的に [MASKED] に置換するフィルタを必ず入れること。
2. WAFでの異常検知: AWS WAFなどを利用している場合、Authorization ヘッダーに異常な長さや、SQLインジェクションの兆候（' OR 1=1 など）が含まれていないかチェックするルールを適用せよ。
チーフからのアドバイス
セキュリティは「完成」しない。暗号学的な脆弱性（RSAの鍵長不足や、ECCのカーブ選択ミスなど）は日々更新される。常に ssllabs などのツールで自分のサーバーをスキャンし、自分の手で弱点を晒し出す習慣をつけてほしい。
「自分の書いたコードは、悪意あるハッカーに一番先に読まれる」という前提で設計すれば、自ずと堅牢なシステムが出来上がるはずだ。健闘を祈る。
コメント