WAFでパスワードリスト攻撃を防ぐ完全マニュアル【設定例付き】

2025年11月04日作成

コラム

WAF（Web Application Firewall）は、パスワードリスト攻撃に対する最前線の防御壁です。しかし、単に導入するだけでは効果は限定的。適切な設定とチューニングが成否を分けます。本記事では、WAFがどのように攻撃を検知し、防御するのか、その仕組みから解説します。AWS WAF、Cloudflare、Azure WAFなど主要製品での具体的な設定例を示し、実践的な実装方法を提供。レート制限の多層防御、リスクベースのCAPTCHA実装、誤検知を最小化するチューニング手法まで、運用現場で本当に必要な知識を網羅しています。特に、ユーザビリティを損なわずにセキュリティを強化するバランスの取り方、月額数千円から始められるコスト最適化戦略など、実務で直面する課題への解決策も詳述します。

WAFによるパスワードリスト攻撃防御の仕組み

WAFは単なる「Webアプリケーションの盾」ではありません。攻撃者の行動パターンを分析し、正常なユーザーと区別することで、高度な攻撃を防御する知能を持っています。

WAFが検知する攻撃パターン

行動ベースの異常検知

パスワードリスト攻撃の最大の特徴は、人間離れした行動パターンです。WAFはこの違いを利用して攻撃を検知します。

短時間での大量ログイン試行: 人間が手動でパスワードを入力する場合、どんなに急いでも1分間に3〜4回が限界です。しかし、攻撃ツールは1分間に**100回以上**の試行が可能。WAFは、1分間に10回を超えるログイン試行を検知すると、自動的にブロックします。この閾値は、正常なユーザーの「パスワードを忘れて何度か試す」行動を考慮した値です
異なるユーザー名での連続試行: 同一IPアドレスから、短時間で複数の異なるユーザー名でログインを試みるのは、リスト型攻撃の典型的な挙動です。正常なユーザーは自分のアカウントでしかログインしません。5分間で5つ以上の異なるユーザー名を試行したIPは、99.9%の確率で攻撃者です
成功率の異常な低さ: 正常なユーザーは、数回の試行でログインに成功します（パスワードを忘れた場合でも、リセット機能を使うはず）。しかし、攻撃者は漏洩した古いパスワードを使うため、成功率は極めて低くなります。100回試行して1回も成功しない場合、それは攻撃である可能性が極めて高いのです
User-Agentの偽装や欠如: 攻撃ツールは正規のブラウザを偽装しますが、完璧ではありません。例えば、Chrome 120を名乗りながら、HTTP/2をサポートしていない、必須のヘッダーが欠落している、ヘッダーの順序が実際のChromeと異なるなど、細かい不整合が発生します。WAFはこれらの矛盾を検知してブロックします

地理的・時間的異常の検知

攻撃者は世界中から、24時間体制で攻撃を仕掛けてきます。この特徴を利用した検知も有効です。

異常パターン	検知ロジック	誤検知リスク	推奨対応
物理的に不可能な移動	前回東京でログイン、1時間後にニューヨーク	低（ほぼゼロ）	即座にブロック、アカウント凍結
深夜の大量アクセス	午前2-5時に100回以上のログイン試行	低（夜勤除く）	CAPTCHA必須化
複数国からの同時アクセス	5分間で3カ国以上からアクセス	中（VPN利用者）	追加認証要求
Tor/VPN経由	既知の匿名化サービスのIPレンジ	高（プライバシー重視ユーザー）	リスクスコア加算
ボットネットパターン	異なるIPから同一User-Agent、同一挙動	低	IPグループでブロック

レート制限の実装戦略

多段階レート制限の設計

効果的なレート制限は、玉ねぎのような多層構造で実装することが重要です。外側の層で大規模な攻撃を防ぎ、内側の層できめ細かな制御を行います。

第1層：グローバルレート制限（最外層）

設定値：全体で秒間1000リクエストを上限
目的：DDoS攻撃からインフラ全体を保護
実装場所：CDN、ロードバランサー
影響：正常なトラフィックには全く影響なし

第2層：IPアドレスベース制限

設定値：同一IPから認証エンドポイントへ1分間10回まで
目的：単一攻撃者からの集中攻撃を防御
実装場所：WAF
注意点：企業の出口IPなど、NATを考慮した設定

第3層：アカウントベース制限

設定値：同一アカウントへ5分間5回まで
目的：特定アカウントへの総当たり攻撃防止
実装場所：アプリケーション層
配慮：パスワード忘れの正当なユーザーへの配慮

第4層：セッションベース制限（最内層）

設定値：同一セッションから1分間3回まで
目的：より厳格な制限で早期検知
実装場所：アプリケーション内部
効果：攻撃の最も早い段階で検知可能

適応型レート制限

静的な制限値では、攻撃の激しさに応じた柔軟な対応ができません。そこで、信号機のように状況に応じて制限を変える仕組みが必要です。

平常モード（グリーン🟢）: 通常運用時の設定。標準的なレート制限（1分10回）を適用。ユーザビリティを最優先し、正常利用に一切影響しない範囲で設定。CAPTCHAは表示せず、ログ記録のみ実施
警戒モード（イエロー🟡）: 異常な挙動を検知したら自動的に移行。制限を強化（1分5回）し、3回失敗でCAPTCHA表示開始。このモードへの移行トリガーは、5分間で50回以上の失敗、10個以上の異なるアカウントへの試行など
防御モード（レッド🔴）: 明確な攻撃を検知した緊急モード。新規ログインを原則制限（1分1回）、すべてのログインでCAPTCHA必須化。既存の正常セッションは維持し、ビジネスへの影響を最小化。30分後に自動的にイエローモードへ移行

主要WAF製品での具体的な設定方法

理論を理解したところで、実際の製品でどう設定するのか、具体例を見ていきましょう。

AWS WAFでの実装

マネージドルールグループの活用

AWSは「Account Takeover Prevention (ATP)」という専用のマネージドルールを提供しています。これを使えば、複雑な設定なしに基本的な防御が可能です。

基本設定手順：

Web ACLの作成
- AWS WAFコンソールで「Create web ACL」を選択
- リージョンまたはCloudFront用を選択
- 関連付けるリソース（ALB、API Gateway等）を指定
マネージドルールグループの追加
- 「Add rules」→「Add managed rule groups」を選択
- 「AWS managed rule groups」カテゴリを展開
- 「Account takeover prevention」を有効化

ログインエンドポイントの指定

設定項目：
- Login page path: /login, /api/v1/auth, /signin
- Username field: email, username, user_id, account
- Password field: password, pass, passwd, pwd
- Login success codes: 200, 302, 303
- Login failure codes: 401, 403, 400

レスポンスインスペクションの設定
- 成功/失敗の判定条件を設定
- JSONレスポンスの場合："success": true/false のパターン
- HTMLの場合：「ログイン成功」「Invalid credentials」等の文字列

月額コスト目安：

Web ACL: $5/月
ルール: $1/月
リクエスト: $0.60/100万リクエスト
合計: 月間1000万リクエストで約$11

カスタムルールの作成例

マネージドルールでカバーできない、自社特有の要件にはカスタムルールで対応します。

ルール1：短時間での複数失敗検知

名前: RateLimitFailedLogins
優先度: 100
ステートメント:
  - Rate-based rule
  - Aggregation: IP
  - Evaluation window: 5 minutes
  - Threshold: 5
  - Scope: Response code equals 401 OR 403
アクション: Block for 1 hour

ルール2：異なるユーザーでの試行検知

名前: MultipleUserAttempts
優先度: 90
ステートメント:
  - カスタムヘッダーでユーザー名を追跡
  - 同一IPから10種類以上のユニーク値
  - 時間窓: 10分
アクション: Block for 24 hours

ルール3：既知の攻撃ツール検知

名前: BlockAttackTools
優先度: 80
ステートメント:
  - User-Agent contains: "Sentry MBA", "STORM", "OpenBullet"
  - OR Missing required headers (Accept-Language等)
アクション: Permanent block + ログ記録

Cloudflare WAFでの実装

Cloudflareは使いやすさと高性能を両立した、コストパフォーマンスに優れたWAFです。

Rate Limiting Rulesの設定

Cloudflareの高度なレート制限機能を活用した設定例：

ルール名	条件	閾値	アクション	期間
Login Attempt	URI Path = /login AND Method = POST	10回/分/IP	JS Challenge	10分
Failed Login	Response Code = 401 AND URI = /login	5回/5分/IP	Block	1時間
Credential Stuffing	Multiple Usernames from Same IP	20回/10分	Block	24時間
Distributed Attack	Same Username from Multiple IPs	10 IPs/時	Managed Challenge	1時間
API Brute Force	URI contains /api/ AND High request rate	100回/分	Block	6時間

設定のコツ：

「JS Challenge」は軽量で、正常なブラウザは自動通過
「Managed Challenge」はCloudflareが最適な検証方法を自動選択
「Block」は最終手段として使用

Super Bot Fight Modeの活用

Cloudflareの機械学習ベースのBot検知機能は、設定が簡単で効果的です。

Essentially Off（テスト環境向け）: 基本的に無効状態。既知の良性Bot（Googlebot等）のみを分類。新規導入時の最初の1週間はこの設定で様子見することを推奨。誤検知のリスクを最小化しながら、トラフィックパターンを学習
Standard（本番環境の初期設定）: 明らかに悪意のあるBotのみをブロック。確実に攻撃と判定できるものだけを止める保守的な設定。誤検知率1%未満を維持しながら、主要な攻撃の80%を防御。3ヶ月程度運用してデータを蓄積
Challenge（推奨設定）: 疑わしいBotにはCAPTCHA等のチャレンジを要求。人間なら簡単に通過できるが、Botには困難。誤検知があっても、ユーザーは手動で通過可能なため、バランスが取れた設定。防御率95%を実現
Block（緊急時のみ）: 疑わしいトラフィックも即座にブロック。大規模攻撃を受けている緊急時のみ使用。誤検知率が5%程度まで上昇する可能性があるため、通常運用では推奨しない

月額コスト目安：

Free Plan: $0（基本的な防御）
Pro Plan: $20/月（高度なルール、分析機能）
Business Plan: $200/月（完全なカスタマイズ、優先サポート）

Azure WAF (Application Gateway) での実装

Azureを使用している組織向けの設定方法です。

カスタムルールによる防御

Azure WAFのカスタムルール作成例：

パスワードリスト攻撃検知ルールの実装：

基本設定
- ルール名：BlockPasswordListAttack
- 優先度：1（数字が小さいほど優先）
- ルールタイプ：MatchRule
Match条件（すべて満たす）
- RequestUri CONTAINS "/login" OR "/api/auth"
- RequestMethod EQUALS "POST"
- RemoteAddr GeoLocation NOT "Japan"（海外IPを重点監視）
レート制限条件
- Rate limit: 5 requests per minute per IP
- Tracking duration: 1 minute
アクション設定
- Action: Block
- Block duration: 3600 seconds (1 hour)

追加の防御ルール：

ルール名	条件	アクション	用途
BlockSuspiciousUA	User-Agent異常	Block	攻撃ツール検知
LimitAPIAccess	/api/* への高頻度アクセス	Log→Block	API保護
GeoBlocking	特定国からのアクセス	Block	地域制限
TimeBasedLimit	深夜時間帯の大量アクセス	Challenge	時間帯制御

診断ログの設定と分析

Azure WAFのログは、Log Analyticsと連携することで強力な分析が可能です。

ApplicationGatewayAccessLog: すべてのHTTPリクエストを記録。正常なトラフィックも含むため、データ量は膨大になりますが、攻撃パターンの事後分析には不可欠。保持期間は30日推奨
ApplicationGatewayFirewallLog: WAFルールにマッチしたリクエストのみを記録。攻撃の詳細分析用で、実際にブロックまたは検知されたトラフィックの内容を確認できます。長期保存推奨（90日以上）
Log Analyticsワークスペース連携: KQL（Kusto Query Language）で高度なクエリが可能。例えば「過去24時間で最も多くブロックされたIPトップ10」「特定のユーザーエージェントの出現頻度」などを瞬時に分析

分析クエリ例（KQL）：

// 過去1時間の攻撃元IPトップ10
AzureDiagnostics
| where TimeGenerated > ago(1h)
| where action_s == "Blocked"
| summarize Count = count() by clientIP_s
| top 10 by Count desc

CAPTCHA統合とユーザビリティ

CAPTCHAは強力な防御手段ですが、ユーザー体験を著しく損なう可能性があります。いかにバランスを取るかが重要です。

段階的CAPTCHA実装

リスクレベルに応じたCAPTCHA表示

すべてのユーザーにCAPTCHAを強制するのは愚策です。リスクベースのアプローチを採用しましょう。

リスクレベル	スコア	条件例	CAPTCHA種類	ユーザー影響
低（グリーン）	0-30	既知のデバイス、通常の時間帯	なし	影響なし（透過的）
中（イエロー）	31-60	新しいデバイス、別の地域	reCAPTCHA v3（invisible）	見えない検証
高（オレンジ）	61-80	3回ログイン失敗、VPN使用	reCAPTCHA v2（checkbox）	1クリック必要
極高（レッド）	81-100	攻撃パターン検知、Tor使用	画像選択CAPTCHA	30秒程度の作業

実装のポイント：

リスクスコアは複数の要因を総合的に評価
一度CAPTCHAをクリアしたら、一定期間（24時間）は緩和
企業ユーザー（固定IP）は信頼度を高く設定

CAPTCHA回避策への対処

攻撃者もCAPTCHAを回避しようとします。その手法と対策を理解しておきましょう。

CAPTCHA解読サービス対策: 2captchaなどの人力解読サービスは、1000件あたり$1〜3で提供されています。対策として、CAPTCHAに**3分の時間制限**を設け、解読サービスの利用を困難にします。また、同じIPから短時間で大量の正解があった場合は、解読サービスの利用を疑い、追加検証を要求
機械学習による自動解読対策: AI技術の進歩により、単純な文字認識CAPTCHAは突破可能です。対策として、音声CAPTCHAと画像CAPTCHAを**ランダムに切り替え**、問題パターンを**週次で更新**します。さらに、行動分析（マウスの動き、クリックパターン）を組み合わせることで、人間らしさを多角的に検証
セッション使い回し対策: 一度CAPTCHAをクリアしたセッションを使い回す攻撃があります。対策として、CAPTCHAトークンは**1回限り有効**とし、5分で自動失効させます。また、セッションとIPアドレスを紐付け、IPが変わったら再度CAPTCHAを要求

代替認証手段の提供

CAPTCHAはアクセシビリティの問題もあります。代替手段を用意することが重要です。

CAPTCHAを使わない防御オプション

1. ハニーポットフィールド（推奨度：★★★★★）

最もシンプルで効果的な方法：

CSSでdisplay: noneにした入力欄を設置
人間には見えないため入力しない
Botは自動的にすべてのフィールドを埋める習性を利用
実装コスト：ほぼゼロ、効果：高

<!-- 実装例の概念 -->
<input type="text" name="email" required>
<input type="password" name="password" required>
<input type="text" name="confirm_email" style="display:none" tabindex="-1">
<!-- confirm_emailに値が入っていたらBot判定 -->

2. 時間ベース検証（推奨度：★★★★☆）

人間の操作速度を利用：

ページ表示から送信まで最低3秒必要
逆に300秒以上かかったら無効（セッションタイムアウト）
JavaScriptで時刻を記録し、サーバー側で検証
Botは効率重視で即座に送信する傾向

3. JavaScript チャレンジ（推奨度：★★★☆☆）

簡単な計算をクライアントサイドで実行：

「7 + 8 = ?」のような問題をJSで生成
答えをハッシュ化してサーバーに送信
ヘッドレスブラウザ以外のBotは実行不可
ユーザーは計算を意識しない（自動実行）

4. デバイスフィンガープリント（推奨度：★★★☆☆）

ブラウザの特徴から信頼度を判定：

Canvas、WebGL、フォント情報を収集
過去の正常ログインと比較
一致度が高ければCAPTCHA不要
プライバシーへの配慮が必要

運用とモニタリング

WAFを設定したら終わりではありません。継続的な監視と改善が、真の防御力を生み出します。

ダッシュボード設計

重要KPIの可視化

リアルタイムで監視すべき指標と、その意味を理解しましょう。

認証成功率（目標：95%以上）: 正常な状態では95%以上のユーザーがログインに成功するはずです。これが80%を下回ったら、攻撃を受けているか、WAFの設定が厳しすぎる可能性があります。15分単位で監視し、閾値を下回ったら即座にアラート
ブロック率（目標：1%未満）: 通常のトラフィックでは、WAFでブロックされるリクエストは1%未満であるべきです。5%を超える場合は過剰防御の可能性があり、正規ユーザーを誤ってブロックしている恐れがあります。日次でレビューし、誤検知の原因を分析
CAPTCHA表示率（目標：5%以下）: CAPTCHAはユーザビリティを損なうため、できるだけ少なくすべきです。10%を超える場合は、リスク判定ロジックの見直しが必要。特に、モバイルユーザーのCAPTCHA表示率が高い場合は要注意
レスポンスタイム（目標：50ms以下の追加遅延）: WAF処理による追加遅延は50ms以下に抑えるべきです。100msを超えると、ユーザーが体感できる遅さになります。ルールの処理順序を最適化し、キャッシュを活用することで改善可能

アラート設定の最適化

適切なアラート設定が、迅速な対応を可能にします。

アラート条件	閾値	通知先	対応SLA	エスカレーション
大規模攻撃検知	1分で100失敗	SOC, CSIRT	5分以内	15分で経営層
新規攻撃パターン	未知のツール検出	セキュリティ担当	1時間以内	翌日レビュー会
誤検知急増	正常ユーザーブロック10件/時	運用チーム	30分以内	1時間で開発チーム
WAF障害	ヘルスチェック失敗	インフラチーム	即時	5分でベンダー連絡
コスト超過	想定の150%	財務・調達	翌営業日	月次で見直し

継続的なチューニング

WAFの性能は、継続的なチューニングで大きく向上します。

ログ分析による改善サイクル

月次で実施すべき分析と改善：

1. 攻撃トレンド分析（毎月第1月曜）

攻撃元IPの地理分布の変化を分析
新しい攻撃ツールの出現を確認
標的となっているアカウントの傾向を把握
時間帯別の攻撃パターンを可視化

2. 誤検知分析（毎月第2月曜）

False Positiveの詳細な原因を特定
特定の企業IPやISPからのアクセスパターン
除外ルールの追加や閾値の微調整
ユーザーからの問い合わせとの照合

3. パフォーマンス分析（毎月第3月曜）

WAF処理時間の推移をグラフ化
最も処理時間のかかるルールを特定
ルールの処理順序を最適化
キャッシュヒット率の改善

4. コスト分析（毎月末）

WAFの利用料金の内訳確認
不要なルールの削除
トラフィックの最適化
次月の予算計画

A/Bテストによる最適化

レート制限閾値のテスト: 全トラフィックの10%に対して新しい閾値を適用し、2週間テストします。例えば、現在「1分10回」の制限を、テストグループでは「1分8回」に変更。攻撃検知率が向上し、誤検知が許容範囲内であれば、全体に適用。段階的な変更により、リスクを最小化
CAPTCHA表示タイミング: ログイン失敗3回でCAPTCHA表示するグループと、5回で表示するグループを比較。ユーザー離脱率、攻撃成功率、サポート問い合わせ数を2週間測定。結果：3回設定では離脱率が2%上昇したが、攻撃成功率が0.1%から0.01%に減少。セキュリティを重視し3回設定を採用
ブロック期間の調整: 攻撃検知時のIPブロック期間を、1時間、6時間、24時間の3グループでテスト。再攻撃率を分析した結果、6時間ブロックが最もバランスが良いことが判明。1時間では35%が再攻撃、24時間では正規ユーザーの誤ブロック問題が増加

コスト最適化とパフォーマンス

WAFは必要不可欠ですが、コストも無視できません。賢く使って、最大の効果を最小のコストで実現しましょう。

WAFコストの削減戦略

トラフィック最適化によるコスト削減

WAFの多くは処理するトラフィック量で課金されます。不要なトラフィックを削減することで、大幅なコスト削減が可能です。

施策	削減効果	実装難易度	実装方法	副次効果
静的コンテンツ除外	30-40%削減	低（1日）	画像、CSS、JSはWAFをバイパス	レスポンス向上20%
内部通信除外	10-20%削減	低（数時間）	ヘルスチェック、監視をホワイトリスト	誤検知削減
CDNキャッシュ活用	50-60%削減	中（1週間）	動的コンテンツもエッジでキャッシュ	可用性向上
地域制限	20-30%削減	低（1時間）	サービス提供地域外をブロック	攻撃面縮小
Bot除外	15-25%削減	中（2-3日）	良性Botは専用エンドポイントへ	分析精度向上

実装例：CloudflareでのPage Rules設定

パス: /static/*
設定: Security Level = Essentially Off
     WAF = Off
     Cache Level = Cache Everything
効果: 静的ファイルの処理コスト90%削減

複数WAFの使い分け

一つのWAFですべてを賄うのではなく、適材適所で使い分けることで、コストパフォーマンスを最大化できます。

エッジWAF（Cloudflare）- 第1層防御: グローバルなDDoS対策と基本的なBot対策を担当。世界中のDDoS攻撃を防ぎ、既知の悪性Botをフィルタリング。月額$20〜200で、大量のトラフィックを効率的に処理。全トラフィックの90%をここで処理し、クリーンなトラフィックのみを後段に送る
リージョナルWAF（AWS WAF）- 第2層防御: アプリケーション固有の詳細なルールを適用。認証システムの技術実装に特化した防御を実施。リクエスト単位の従量課金なので、第1層でフィルタリングされた後のトラフィックのみが課金対象。結果として月額コストを50%削減
アプリケーションWAF（ModSecurity）- 最終防御層: オープンソースで無料のWAF。アプリケーションサーバー内で動作し、最も詳細な検査が可能。カスタムルールを自由に作成でき、アプリケーション固有の脆弱性にも対応。ただし、パフォーマンスへの影響があるため、重要なエンドポイントのみに適用

パフォーマンスへの影響最小化

WAFは必然的にレイテンシを増加させますが、工夫次第で影響を最小限に抑えられます。

レイテンシ削減のテクニック

1. ルール処理順序の最適化

ルールは上から順に評価されるため、順序が性能に大きく影響します：

優先順位	ルールタイプ	理由	処理時間
1	IPホワイトリスト	信頼できるIPは即通過	1ms
2	IPブラックリスト	既知の攻撃者は即遮断	1ms
3	レート制限	カウンター確認のみ	5ms
4	静的パターンマッチ	単純な文字列比較	10ms
5	正規表現	複雑なパターンマッチ	20ms
6	地理情報確認	GeoIPデータベース参照	30ms
7	機械学習モデル	計算負荷高い	50ms+

2. キャッシング戦略

一度判定した結果を再利用：

IPレピュテーション：1時間キャッシュ
User-Agent判定：24時間キャッシュ
GeoIP結果：7日間キャッシュ
ルール判定結果：60秒キャッシュ（同一セッション）

3. 非同期処理の活用

レスポンスに影響しない処理は非同期化：

ログ記録：メッセージキューに投げて後処理
アラート通知：別スレッドで実行
統計更新：バッチ処理で集計
詳細分析：オフラインで実施

インシデント対応とフォレンジック

攻撃を検知したら、迅速かつ適切な対応が求められます。事前に手順を定めておくことが重要です。

攻撃検知時の対応手順

エスカレーションフロー

攻撃の規模に応じて、段階的にエスカレーションします。

Level 1：自動対応（0-5分）⚡: WAFが定義されたルールに基づいて自動的にブロック。閾値を超えたIPは一時的に遮断され、詳細はログに記録。Slackへの通知も自動送信。この段階では人間の介入は不要で、システムが自律的に防御
Level 2：運用チーム対応（5-30分）⚠️: 自動対応では収まらない規模の攻撃を検知。運用チームがログを手動で確認し、攻撃の規模と手法を評価。必要に応じて追加のIPブロックやルール変更を実施。この段階で経営層への第一報を送信
Level 3：セキュリティチーム対応（30分-2時間）🔴: 新しい攻撃パターンや、標的型攻撃の可能性がある場合に対応。詳細な分析を実施し、攻撃者の目的や手法を特定。恒久的な対策を立案し、他システムへの影響も調査。必要に応じてAPIのレート制限も強化
Level 4：CSIRT対応（2時間以上）🚨: 組織全体に影響を及ぼす可能性がある大規模インシデント。経営層も含めた対策本部を設置。法執行機関への通報、顧客への通知、メディア対応などを検討。外部のセキュリティベンダーとも連携し、総力戦で対応

証拠保全とログ分析

法的対応やインシデント後の改善のため、適切な証拠保全が不可欠です。

フォレンジックのためのログ保管

ログ種別	保管期間	形式	保管場所	法的要件
WAFブロックログ	1年	JSON	S3（暗号化、改ざん防止）	不正アクセス禁止法
アクセスログ	6ヶ月	Common Log Format	SIEM	通信の秘密配慮
認証ログ	3年	構造化ログ	監査用DB	内部統制要件
インシデントログ	7年	詳細記録+スクリーンショット	コールドストレージ	訴訟対応

ログ保全のベストプラクティス：

Write Once Read Many (WORM) ストレージ
- 一度書き込んだら変更不可の設定
- AWS S3 Object Lockなどを活用
- 法的証拠として有効性を確保
ハッシュチェーンによる完全性保証
- 各ログエントリにハッシュ値を付与
- 前のエントリのハッシュを含める
- 改ざんを検知可能に
定期的なバックアップとテスト
- 日次でバックアップ実施
- 月次でリストアテスト
- 異なる地域にレプリケーション
アクセス制御と監査ログ
- ログへのアクセスは最小権限
- 閲覧履歴も記録
- 定期的な棚卸し実施

まとめ：実装ロードマップと次のステップ

ここまで、WAFを使用したパスワードリスト攻撃対策を包括的に解説してきました。最後に、段階的な実装計画をご提案します。

段階的実装計画（3ヶ月）

第1月：基礎構築フェーズ

Week 1: 現状分析とWAF選定
Week 2: 基本ルール設定（レート制限、地域制限）
Week 3: ログ収集環境の構築
Week 4: 初期チューニングと誤検知対応

第2月：最適化フェーズ

Week 5-6: カスタムルール作成
Week 7: CAPTCHA統合
Week 8: A/Bテスト開始

第3月：成熟化フェーズ

Week 9-10: 機械学習モデル導入
Week 11: マルチWAF構成
Week 12: 運用手順確立とドキュメント化

投資対効果

初期投資（3ヶ月）：

WAFライセンス：$600（$200×3）
設定作業：40時間
テスト・検証：20時間

期待効果：

攻撃成功率：5%→0.1%（98%削減）
インシデント対応コスト：年間500万円→50万円
顧客信頼度：NPS +10ポイント

継続的改善のために

WAFは「設定して終わり」ではありません。パスワードリスト攻撃の手法は日々進化しており、防御側も進化し続ける必要があります。

定期的に実施すべきこと：

週次：ログレビュー、誤検知対応
月次：ルール見直し、パフォーマンス分析
四半期：ペネトレーションテスト、大規模な設定見直し
年次：WAF製品の再評価、アーキテクチャ見直し

WAFは強力な防御手段ですが、それだけでは不十分です。多要素認証、アカウントロック、異常検知システムなど、多層防御と組み合わせることで、真に堅牢なセキュリティを実現できます。

本記事で紹介した設定例を参考に、自社の環境に最適な構成を見つけてください。セキュリティは旅であり、目的地ではありません。一歩ずつ、着実に改善していきましょう。

【重要なお知らせ】

本記事は一般的な設定例を示したものであり、実環境での動作を保証するものではありません
WAFの設定変更は必ずテスト環境で検証してから本番適用してください
各WAF製品の最新ドキュメントも必ず確認してください
セキュリティ設定は定期的な見直しが必要です

更新履歴

2025年11月04日: 初稿公開