【実務・中級編】Identification and Authentication Failures: ブルートフォース攻撃の防御 – アプリケーションセキュリティ & 安全な開発防御ガイド

認証の「常識」を疑え：ブルートフォース攻撃を無力化する実戦的アーキテクチャ

現場でインシデント対応をしていると、いまだに「ログイン画面にアカウントロックアウトを実装しているから大丈夫」と胸を張るエンジニアに出会う。だが、はっきり言おう。それ、攻撃者からすれば「DoS攻撃の踏み台」にされているだけだ。

アカウントロックアウトは、正当なユーザーを締め出すリスク（ユーザビリティの毀損）と、攻撃者によるサービス停止（Lockout DoS）という二重の脆弱性を抱えている。真のプロは、システムを「止める」のではなく、攻撃を「無力化」することに注力する。今日は、現場で生き残るための「現代的な認証保護」の最適解を伝授する。

—

1. 攻撃者が狙う「盲点」：なぜ従来の防御は破られるのか

現代の攻撃者は、古典的な「総当たり（Brute Force）」は行わない。彼らが使うのは、流出した認証情報リストを用いた「クレデンシャルスタッフィング」だ。

低速分散攻撃: IPアドレスを数千個のボットネットに分散させ、1IPあたり数分に1回のログインを試みる。これでは単純なIP制限やロックアウトは検知できない。
パスワードスプレー: 多くのユーザーが使いがちな弱いパスワードを、複数のアカウントに対して順番に試行する。

これに対抗するには、「レートリミットの多層化」と「コンテキスト認識」が不可欠だ。

—

2. 実装の鉄則：レートリミットをアプリケーションの外側へ

アプリのコード内でログイン回数をカウントするのは、DB負荷が高く、攻撃者が狙いやすい。WAFやインフラ層で「手前」で弾くのが正攻法だ。

Nginx + Redisによるレートリミット設定

Nginxの limit_req モジュールを使い、ログインエンドポイントに対して厳格な制限をかける。

nginx.conf の http コンテキスト内に記述
$binary_remote_addr をキーに、1秒間に1リクエストまで、バーストは5まで許容
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

server {
location /api/login {
# ログインAPIのみ制限を適用
limit_req zone=login_limit burst=5 nodelay;

# 制限を超えた場合は429 Too Many Requestsを返す
limit_req_status 429;

proxy_pass http://backend_app;
}
}

—

3. アプリケーション層での「守り」：Python (FastAPI) による実装

インフラでの制限をすり抜けた攻撃者に対しては、アプリケーション層で「認証試行の追跡」を行う。ここでは、単なるロックアウトではなく「遅延」を組み込むのが現代的なアプローチだ。

import time
from fastapi import HTTPException, status

本来はRedis等で管理すべき（インメモリの例）
failed_attempts = {}

def check_login_rate_limit(username: str):
now = time.time()
attempts = failed_attempts.get(username, [])

# 過去15分以内の失敗のみを抽出
attempts = [t for t in attempts if now – t < 900] if len(attempts) >= 5:
# 5回失敗したら、擬似的にレスポンスを遅延させる（攻撃コストの増大）
time.sleep(2)
raise HTTPException(
status_code=status.HTTP_429_TOO_MANY_REQUESTS,
detail=”試行回数が多すぎます。しばらく経ってから再試行してください。”
)

failed_attempts[username] = attempts

ログイン成功時には必ずリストをクリアすること（重要！）

—

4. 究極の防御：MFA（多要素認証）の強制

レートリミットやロックアウトは、あくまで「攻撃の緩和」に過ぎない。どれだけ完璧に防いでも、パスワードが漏洩していればログインは突破される。

私たちが提供すべき最大のセキュリティは、「パスワードが漏れても、攻撃者がログインできない状態」を作ることだ。

実務上の設計ルール

1. MFAのデフォルト有効化: 新規ユーザー登録時に、TOTP（Google Authenticator等）の設定を強制するか、強く推奨するフローを組み込む。
2. バックアップコードの管理: MFAデバイス紛失時に備え、回復コードを安全に発行し、ユーザーに物理的な保管を促す。
3. 認証フローの順序: 「パスワード入力 → MFA検証」というステップを踏むことで、パスワードを知っているだけの攻撃者を即座に拒絶する。

—

現場のチーフからの提言：セキュリティは「コスト」ではなく「信頼」

いいか、エンジニア諸君。セキュリティ対策を「面倒な実装」と捉えるな。
攻撃者は、最もセキュリティが甘い「一点」を見つけ出し、そこからシステム全体を崩壊させる。

ログを監視せよ: ログイン失敗ログをSIEM等に飛ばし、異常なアクセスパターンを検知できる状態にしておくこと。
攻撃者の心理を読め: 攻撃者が「割に合わない」と感じるような、遅延と制限を組み合わせた設計を心がけろ。

「安全な実装」とは、コードの行数ではない。攻撃者のやる気を削ぎ、正当なユーザーにストレスを与えない「境界線の絶妙な引き方」にある。今日紹介したコードは、あくまで「最低限」の防壁だ。これをベースに、自社のサービス特性に合わせた「独自の防御層」を積み上げていってほしい。

何かあればいつでも相談してくれ。現場の最前線で、共にシステムを守ろう。