CloudFront WAF 運用設計書

文書情報

項目	内容
作成日	2026-03-08
対象システム	fastdoctor.jp CloudFront WAF
対象環境	production
運用開始予定日	2026-03-XX（Phase 1 開始日）
関連ドキュメント	CloudFront WAF アーキテクチャ設計書, WAF監視・アラート設計書

前提事項

本ドキュメントに記載されている運用手順、閾値、モニタリング方法は、構築検証およびモニタリング検証の結果に基づいて随時更新されることを前提としています。

特に以下の項目については、実運用での知見やDatadogアラートの動作状況を踏まえて継続的に改善します：

閾値設定: ブロック数、Count数、エラーレート等の判断基準
モニタリング頻度: 日次・週次チェックのタイミングや確認項目
バージョン管理: マネージドルールの更新フローと検証期間
ロールバック判断基準: Phase移行やバージョン更新時の戻し判断
アラート設定: Datadog Monitorの条件、通知先、エスカレーション

運用開始後、定期的に本ドキュメントを見直し、実態に即した内容に更新していきます。

1. 運用体制

1.1 役割と責任

役割	担当チーム	責任範囲
WAF運用	SRE Team	WAF全体の運用管理、Phase移行判断、重大インシデント対応
日次モニタリング	SRE Team	Datadog / S3ログでの日次確認、異常検知
インシデント対応	SRE Team	誤検知の初動対応、ルール調整、WAF設定変更
Terraform管理	SRE Team	Terraformコードの変更、適用、レビュー
事業側連絡	SRE Team	Blockモード適用時の事業部門への事前連絡

運用の基本方針:

WAF運用はSREで完結することを基本とする
Blockモード適用時は事前に事業側へ連絡し、影響を周知
想定外のブロックが発生した場合は即座にCountモードに戻す
事業側から問い合わせがあった場合はSREが対応

1.2 連絡体制

通常時

ユーザー問い合わせ
  ↓
カスタマーサポート / 事業部門
  ↓
SRE Team

緊急時（大量ブロック発生等）

Datadog アラート
  ↓
SRE Team on-call
  ↓（必要に応じて）
事業部門への影響報告

Blockモード適用時の事前連絡

SRE Team（Phase移行実施前）
  ↓
事業部門へ事前連絡（Slack等）
  ├→ 適用日時の通知
  ├→ 影響範囲の説明
  └→ 問い合わせ窓口の案内
  ↓
Phase移行実施
  ↓
事業部門へ完了報告（Slack等）

2. 定常運用フロー

2.1 日次運用（平日 9:00-10:00）

チェック項目

No	項目	確認内容	使用ツール	所要時間
1	WAF動作確認	WAFが正常に動作しているか	AWS Console / Datadog	2分
2	ブロック数確認	前日のブロック数が異常値でないか	Datadog Dashboard	3分
3	Count数確認（Phase 1/2のみ）	Countモードのルールマッチ数	Datadog Logs	5分
4	エラーレート確認	CloudFrontのエラーレート変化	Datadog Dashboard	2分
5	誤検知報告確認	カスタマーサポートからの報告	Slack	3分

実施手順

Step 1: ブロック数確認

Datadog Dashboard「CloudFront WAF - Daily Summary」(仮)で確認：

前日のブロック総数
ルール別ブロック数
ブロックされた上位10 IP

閾値:

ブロック数 > 1000/日: 要調査（DDoS攻撃の可能性）
ブロック数 < 10/日: 正常

Step 2: Count数確認（Phase 1/2のみ）

Datadog Logs で以下のタグベースクエリを実行：

waf_action:count
group by waf_rule

注: Datadog Logs Pipelineでタグ（waf_action:count、waf_rule:<ruleId>）を自動付与しているため、タグベースのクエリが推奨されます。

閾値（仮）:

以下は初期設定値です。運用開始後、実際のトラフィックパターンを観察しながら適切な閾値に調整します。

Rate Limiting Count > 100/日: 要調査（閾値の見直し検討）
Known Bad Inputs Count > 50/日: 要調査（攻撃トレンド確認）

リクエストの中身や傾向分析:

Datadog Logs で詳細分析を実施：

waf_action:count

確認ポイント:

アクセス元: @network.client.ip, @httpRequest.country でどこから来ているか
URIパターン: @httpRequest.uri でどのパスが多いか
User-Agent: @httpRequest.headers.user-agent でボットの可能性
時系列傾向: 特定時間帯に集中していないか

傾向分析例:

同一IPから繰り返しCOUNTされている → ボットの可能性、Rate Limiting閾値調整検討
特定URIに集中している → アプリケーション側の問題可能性、開発チームに共有
海外IPからのCOUNT多数 → 攻撃の初期段階の可能性、継続監視

注意事項（コーポレートサイト特有）:

PR発表時・決算発表時: プレスリリースや決算情報公開直後は、アクセス数が急増し、DoS攻撃に似た正常なトラフィックパターンが発生することがあります
Rate Limiting誤検知の可能性: 上記タイミングでは、正規ユーザーからの短時間の集中アクセスがRate Limitingに引っかかる可能性があるため、一時的に閾値を緩和するか、事前にRate Limitingルールを無効化することを検討
事前調整: PR発表や決算発表の予定が分かっている場合は、事前にSRE Teamにて監視体制を調整

Step 4: エラーレート確認

Datadog で CloudFront の 4xx/5xx エラー率を確認：

4xx エラー率の監視:

絶対値ではなく変動で監視: favicon（/favicon.ico）やクローラによる存在しないページへのアクセスなど、常に404エラーとなるリクエストが一定数存在するため、絶対値（例: > 5%）での判断は誤検知につながる
推奨監視方法: 過去7日間の平均値と比較して、**急激な変動（±20%以上等）**があれば要調査
Datadogクエリ例: anomaly(avg:aws.cloudfront.4xx_error_rate{*}, 'basic', 2) でアノマリー検知

5xx エラー率の監視:

絶対値での監視: 5xx エラーはオリジンサーバーの異常を示すため、**5xx エラー率 > 1%**で即座に要調査
Datadogアラート設定: 5xx エラー率が1%を超えた場合に即座にSlack通知

Step 5: 誤検知報告確認

Slack で確認：

カスタマーサポートからの「アクセスできない」報告
ユーザーからの問い合わせ

報告があった場合: インシデント対応フローに従う

日次レポート

レポート作成方法:

Datadog Notebook で日次チェック結果をまとめる
- ブロック数のグラフ
- ルール別マッチ数の統計
- エラーレートの推移
- 特記事項（あれば）
GitHub Issue に Datadog Notebook のリンクを記載して共有
- Issue タイトル: WAF 日次レポート - 2026-03-XX
- リポジトリ: fastdoctor-jp/terraform_for_aws
- Labels: waf, daily-report
- デイリーで作成・更新

レポートテンプレート（GitHub Issue）:

markdown

## WAF 日次レポート - 2026-03-XX

**Datadog Notebook**: [リンク]

### サマリー
- WAF動作: ✅ 正常
- 前日ブロック数: 45件（正常範囲）
- Count数（Phase 1）: 120件（閾値内）
- CloudFrontエラーレート: 0.3%（正常）
- 誤検知報告: なし

### 特記事項
なし

### 傾向分析
（Datadog Notebookに詳細記載）

今後の改善方針:

現在は手動でチェック・レポート作成を行うが、モニタリング負荷軽減のため以下の自動化を検討：

Datadog MCP Server: Claude Codeから直接Datadogのメトリクス・ログを取得し、分析を自動化
Datadog Workflow Automation: 日次チェックの自動実行とSlack通知

運用開始後、手動運用で得られた知見を基に自動化の優先順位を決定する。

2.2 週次運用（毎週月曜 10:00-11:00）

チェック項目

No	項目	確認内容	所要時間
1	週次トレンド分析	ブロック数・Count数の週次推移	10分
2	Top 10 ブロックIP分析	繰り返しブロックされているIPの分析	10分
3	ルール別マッチ傾向分析	ルール別のBLOCK/COUNTマッチ傾向分析（タグベース）	10分
4	ルール効果測定	各ルールの有効性評価	15分
5	Phase移行判断（該当週のみ）	Phase移行条件を満たしているか	15分
6	コスト確認	Firehose / S3 / Datadog のコスト	5分
7	マネージドルールバージョン確認	新バージョン通知の確認と更新検討	10分
8	ドキュメント更新	運用ドキュメントの更新必要性確認	10分

実施手順

Step 1: 週次トレンド分析

Datadog Dashboard「CloudFront WAF - Weekly Trend」で確認：

過去7日間のブロック数推移
ルール別のマッチ傾向
異常な増減がないか

判断基準（仮、モニタリング検証しながら調整）:

ブロック数が週ごとに2倍以上増加: 攻撃傾向の変化、要調査
ブロック数が急減: WAF設定の問題可能性、要確認

Step 2: Top 10 ブロックIP分析

Datadog Logs タグベースクエリ:

waf_action:BLOCK
group by @network.client.ip

対応:

同一IPから 1000回以上/週ブロック: 正常な攻撃ブロック、特に対応不要
社内IPがブロックされている: 誤検知の可能性、要調査

Step 3: ルール別マッチ傾向分析

Datadog Logs でルール別のマッチ傾向を確認：

waf_action:BLOCK OR waf_action:count
group by waf_rule

または Datadog Dashboard「CloudFront WAF - Rule Analysis」で確認。

確認ポイント:

どのルール（waf_rule タグ）が頻繁にマッチしているか
ルール別のBLOCK/COUNT比率

注: タグベースクエリの詳細およびWAF Labelsを使用しない理由については、CloudFront WAF アーキテクチャ設計書 - WAF Labels によるログ可視化および Datadog Logs Pipeline によるタグ付けを参照してください。

Step 4: ルール効果測定

各ルールの有効性を評価：

ルール名	評価観点	判断基準（仮、モニタリング検証しながら調整）
Rate Limiting	マッチ数、誤検知報告	マッチ数 > 100/週かつ誤検知なし → 有効
IP Reputation	ブロック数	ブロック数 > 50/週 → 有効
Known Bad Inputs	ブロック数、攻撃パターン	ブロック数 > 20/週 → 有効
Core Rule Set	マッチ数、誤検知率	誤検知率 < 5% → 有効

無効と判断された場合:

ルールの閾値調整を検討
除外ルール設定を検討
Phase移行の延期を検討

Step 5: Phase移行判断（該当週のみ）

Phase移行管理を参照。

Step 6: コスト確認

AWS Cost Explorer で確認：

Kinesis Data Firehose の配信コスト
S3 ストレージコスト（WAF ログアーカイブ）
Datadog のログ取り込みコスト（Datadogコンソールで確認）

注: 具体的な予算は運用開始後に実績を基に設定

Step 7: マネージドルールバージョン確認

AWS Managed Rules の新バージョンは Slack通知 で検知します。

運用方針:

AWS Managed Rules の新バージョンリリースは Slack に自動通知される
通知を受けてリリースノートを確認し、更新の必要性を判断
必要に応じてマネージドルールバージョン管理の手順に従って更新を実施

Slack通知がない場合の確認方法（参考）:

手動でバージョン確認する場合のコマンド

bash

# 現在使用中のバージョン確認
aws wafv2 get-web-acl \
  --scope CLOUDFRONT \
  --id <web-acl-id> \
  --region us-east-1 \
  --profile fd-sys-read \
  --query 'WebACL.Rules[*].Statement.ManagedRuleGroupStatement' \
  --output json

# 利用可能なバージョン一覧取得
aws wafv2 describe-managed-rule-group \
  --vendor-name AWS \
  --name AWSManagedRulesCommonRuleSet \
  --scope CLOUDFRONT \
  --region us-east-1 \
  --profile fd-sys-read

Step 8: ドキュメント更新確認

以下のドキュメントに更新が必要か確認：

本ドキュメント（運用設計書）
アーキテクチャ設計書

週次レポート

レポート作成方法:

Datadog Notebook で週次チェック結果をまとめる
- 週次トレンド分析（グラフ）
- Top 10 ブロックIP
- ルール別マッチ傾向分析（waf_rule タグベース）
- ルール効果測定
- コスト推移
GitHub Issue に Datadog Notebook のリンクを記載して共有
- Issue タイトル: WAF 週次レポート - 2026-WXX
- リポジトリ: fastdoctor-jp/terraform_for_aws
- Labels: waf, weekly-report
- 週次で作成・更新

レポートテンプレート（GitHub Issue）:

markdown

## WAF 週次レポート - 2026-WXX

**Datadog Notebook**: [リンク]

### サマリー
- 週間ブロック数: XXX件
- 週間Count数: XXX件（Phase 1/2のみ）
- ルール効果測定: 全ルール有効
- コスト: $XX（予算内）
- Phase移行: 予定なし / Phase X → Phase Y 移行予定

### 特記事項
なし

### 改善提案
（あれば記載）

2.3 マネージドルールバージョン管理

バージョン管理方針の詳細: 静的バージョン選択の理由、Terraform設定例、AWS SNS通知設定等は CloudFront WAF アーキテクチャ設計書 - マネージドルールのバージョン管理を参照してください。

本セクションでは、週次運用での確認手順およびバージョン更新の作業手順を記載します。

注: 本セクションの手順や検証期間は、構築検証・モニタリング検証の結果に応じて見直す場合があります。

バージョン更新作業手順

対象: staging → production の順で実施

Step 1: リリースノート確認

AWS WAF のリリースノートを確認：

https://docs.aws.amazon.com/waf/latest/developerguide/waf-managed-rule-groups-changelog.html
変更内容の理解
既存トラフィックへの影響予測

Step 2: staging環境に適用

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/staging

# waf.tf を編集（バージョン番号更新）
# version_name = "Version_1.5" → "Version_2.0"

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -target=module.waf
terraform apply -var-file=terraform.tfvars -target=module.waf
./upload-tfvar.sh

Step 3: staging環境でモニタリング（1週間）

Datadog Logs でブロック数の変化を確認
Datadog Dashboard で異常がないか監視
誤検知報告がないか確認

Step 4: production環境に適用

staging環境で問題がなければ、production環境に適用：

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# waf.tf を編集（staging と同じバージョンに更新）

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -target=module.waf
terraform apply -var-file=terraform.tfvars -target=module.waf
./upload-tfvar.sh

Step 5: production環境でモニタリング（1週間）

適用後1週間は重点的にモニタリング。

Step 6: 更新完了報告

GitHub Issue に記録：

ルール: AWSManagedRulesCommonRuleSet
旧バージョン → 新バージョン
更新日: staging / production
変更内容（リリースノートより）
影響の有無

ロールバック手順

バージョン更新後に問題が発生した場合：

注: ロールバック判断基準は、モニタリング検証の結果に基づいて調整します。

bash

# Terraform コードで旧バージョンに戻す
version_name = "Version_1.5"  # 旧バージョンに戻す

terraform apply -var-file=terraform.tfvars -target=module.waf

3. Phase移行管理

3.1 Phase移行の全体フロー

Phase定義の詳細: 各Phaseのルール構成、WCU、導入理由等の詳細は CloudFront WAF アーキテクチャ設計書 - フェーズ別ルール構成を参照してください。

本セクションでは、Phase移行の判断基準と作業手順を記載します。

3.2 Phase 1 → Phase 2 移行

移行条件

以下のすべてを満たす必要があります：

No	条件	確認方法
1	運用期間 ≥ 1週間	Phase 1 開始日からの経過日数（test.fastdoctor.jp）
2	test.fastdoctor.jp での検証完了	test.fastdoctor.jp で Phase 2 を1週間運用し、問題なし
3	誤検知報告 = 0件	GitHub Issue / Slack での報告確認（test.fastdoctor.jp / fastdoctor.jp両方）
4	Count数が安定	Rate Limiting Count < 200/日、Known Bad Inputs Count < 100/日（仮閾値）
5	CloudFrontエラーレート変化なし	WAF適用前後で ±0.5% 以内
6	SRE Teamの承認	PRで承認

test.fastdoctor.jp での事前検証

fastdoctor.jp（本番ドメイン）への移行前に、必ずtest.fastdoctor.jp（テスト用ドメイン）で検証を実施します。

検証フロー: infra-dev（構築・疎通検証） → test.fastdoctor.jp（導入・モニタリング検証） → fastdoctor.jp（本番適用）

Step 1: test.fastdoctor.jp に Phase 2 を適用

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# 現在の設定確認
grep waf_phase terraform.tfvars
# waf_phase = "phase1"

# Phase 2 設定に変更
# waf_phase = "phase2"
# enable_waf_crs = true

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -target=module.waf_test_fastdoctor_jp
terraform apply -var-file=terraform.tfvars -target=module.waf_test_fastdoctor_jp
./upload-tfvar.sh

Step 2: test.fastdoctor.jp でモニタリング（1週間）

確認項目	確認方法	閾値（仮）
ブロック数	Datadog Logs（タグ: `waf_action:BLOCK`）	異常な急増がないこと
エラーレート	Datadog Dashboard	test.fastdoctor.jp のエラーレート変化 ±1% 以内
誤検知報告	開発チーム・QAチームからのフィードバック	0件
CRS Count数	Datadog Logs（タグ: `waf_action:count waf_rule:core-rule-set`）	< 500/日

Step 3: test.fastdoctor.jp 検証結果の評価

以下の確認を実施：

[ ] test.fastdoctor.jp で1週間問題なく動作
[ ] 開発チーム・QAチームから誤検知報告なし
[ ] ブロック数が想定範囲内
[ ] エラーレートに悪影響なし

すべてクリア後、fastdoctor.jp（本番ドメイン）への移行を実施

production環境への移行作業手順

作業日時: 平日日中（トラフィック監視可能な時間帯）

作業時間: 約30分

Step 0: 事業部門への事前連絡（作業3営業日前）

Step 1: 事前確認

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# 現在の設定確認
grep waf_phase terraform.tfvars
# waf_phase = "phase1"

# Terraform state 確認
terraform state list | grep waf

Step 2: terraform.tfvars 更新

hcl

# Phase 2 設定に変更
waf_phase      = "phase2"
enable_waf_crs = true

Step 3: Terraform plan

bash

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -out=tfplan

# 変更内容確認
# - Rate Limiting: Count → Block
# - IP Reputation: Count → Block
# - Known Bad Inputs: Count → Block
# - CRS: 新規追加（Count モード）

Step 4: Terraform apply

bash

terraform apply tfplan

Step 5: 動作確認

bash

# WAF設定確認
aws wafv2 get-web-acl \
  --scope CLOUDFRONT \
  --id <web-acl-id> \
  --name fastdoctor-jp-cloudfront-waf \
  --region us-east-1 \
  --profile fd-sys-read

Step 6: モニタリング強化（移行後1時間）

Datadog Dashboard をリアルタイム監視
Datadog Logs で Block 数を5分ごとに確認
CloudFront のエラーレートを監視

Step 7: tfvars アップロード

bash

./upload-tfvar.sh

Step 8: 移行完了報告

Step 9: 想定外のブロックが発生した場合の対応

事業部門からの連絡、またはDatadogアラートで想定外のブロックを検知した場合：

即座にCountモードに戻す（ロールバック）

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# terraform.tfvars を Phase 1 に戻す
waf_phase = "phase1"  # または該当ルールをCountに変更

terraform apply -var-file=terraform.tfvars -target=module.waf_fastdoctor_jp

事業部門へ報告
根本原因調査
- Datadog Logs または S3 ログでブロックされたリクエストを特定
- 誤検知の原因を分析
- 除外ルール設定等の対策を検討
再移行の判断
- 対策実施後、staging環境で再検証
- 再移行の可否を決定

3.3 Phase 2 → Phase 3 移行

移行条件

No	条件	確認方法
1	運用期間 ≥ 2週間	Phase 2 開始日からの経過日数（test.fastdoctor.jp）
2	test.fastdoctor.jp での検証完了	test.fastdoctor.jp で Phase 3 を1週間運用し、問題なし
3	CRS Count数が安定	CRS Count < 500/日（仮閾値、test.fastdoctor.jp）
4	CRS 誤検知分析完了	Datadog Logs での詳細分析実施
5	除外ルール設定完了（必要な場合）	誤検知を除外するルール設定
6	誤検知報告 = 0件	GitHub Issue / Slack での報告確認（test.fastdoctor.jp / fastdoctor.jp両方）
7	SRE Teamの承認	承認

CRS 誤検知分析

Datadog Logs で以下のタグベースクエリを確認：

waf_action:count waf_rule:core-rule-set
group by @httpRequest.uri

確認ポイント:

正常なリクエストがマッチしていないか
特定のURIパターンで集中していないか
必要に応じて除外ルール設定

注: Datadog Logs Pipelineでタグ（waf_action、waf_rule）を自動付与しているため、タグベースのクエリが推奨されます。

除外ルール例:

設定例: 特定ルールを除外する場合

hcl

rule {
  name     = "core-rule-set"
  priority = 10

  override_action {
    none {}
  }

  statement {
    managed_rule_group_statement {
      vendor_name = "AWS"
      name        = "AWSManagedRulesCommonRuleSet"

      # 特定ルールの除外
      rule_action_override {
        action_to_use {
          count {}
        }
        name = "SizeRestrictions_BODY"  # 誤検知が多い場合
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "CoreRuleSet"
    sampled_requests_enabled   = true
  }
}

test.fastdoctor.jp での事前検証

Step 1: test.fastdoctor.jp に Phase 3 を適用

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# Phase 3 設定に変更
# waf_phase = "phase3"

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -target=module.waf_test_fastdoctor_jp
terraform apply -var-file=terraform.tfvars -target=module.waf_test_fastdoctor_jp
./upload-tfvar.sh

Step 2: test.fastdoctor.jp でモニタリング（1週間）

確認項目	確認方法	閾値（仮）
CRS ブロック数	Datadog Logs（タグ: `waf_action:BLOCK waf_rule:core-rule-set`）	異常な急増がないこと
エラーレート	Datadog Dashboard	test.fastdoctor.jp のエラーレート変化 ±1% 以内
誤検知報告	開発チーム・QAチームからのフィードバック	0件
機能テスト	QAチーム	全主要機能が正常動作

Step 3: test.fastdoctor.jp 検証結果の評価

以下の確認を実施：

[ ] test.fastdoctor.jp で1週間問題なく動作
[ ] CRS Block モードで誤検知なし
[ ] 開発チーム・QAチームから問題報告なし
[ ] 全主要機能のテスト完了

すべてクリア後、fastdoctor.jp（本番ドメイン）への移行を実施

production環境への移行作業手順

terraform.tfvars 変更:

bash

cd {terraform_for_aws_root}/fastdoctor-template/common/production

# Phase 3 設定に変更
waf_phase = "phase3"

./download-tfvar.sh
terraform plan -var-file=terraform.tfvars -target=module.waf_fastdoctor_jp
terraform apply -var-file=terraform.tfvars -target=module.waf_fastdoctor_jp
./upload-tfvar.sh

移行後のモニタリング:

基本的にはDatadog Monitorによるアラートベースで機械的に異常を検知する仕組みを導入します。ただし、Phase移行直後は以下のスケジュールで日中に集中的なモニタリングを実施します：

移行後1時間: 5分ごとにリアルタイム監視（Datadog Dashboard + アラート確認）
移行後1日: 1時間ごとに確認（Datadog Dashboard）
移行後1週間: 日次確認（定常運用の日次チェックに含む）

アラート設定の詳細は WAF監視・アラート設計書を参照してください。

3.4 Phase移行のロールバック

移行後に問題が発生した場合、即座にロールバック：

注: 以下の判断基準は暫定値であり、構築検証・モニタリング検証の結果に基づいて調整します。

bash

# terraform.tfvars を前のPhaseに戻す
waf_phase = "phase1"  # または "phase2"

terraform apply -var-file=terraform.tfvars -target=module.waf

ロールバック判断基準（仮、モニタリング検証しながら調整）:

移行後1時間以内にエラーレート +5% 以上
誤検知報告が5件以上/1時間
ブロック数が 1000件以上/5分（異常な高値）

これらの基準は、Datadog Monitorで自動検知されるように設定しますが、最終的な判断はSRE Teamが実施します。

4. インシデント対応

4.1 インシデント分類

重大度	定義	例
Critical	サービス全体に影響、正常トラフィックの50%以上がブロック	WAF設定ミスで全ユーザーがアクセス不可、地理的ブロックで国内IPが誤ブロック
High	一部機能に影響、正常トラフィックの10-50%がブロック	特定ページへのアクセスが全てブロック
Medium	限定的な影響、特定条件下でのブロック	特定のクエリパラメータでブロック、VPN経由の正規ユーザーがブロック
Low	誤検知の可能性はあるが影響は極小	1-2ユーザーのみがブロックされる

4.2 インシデント対応フロー

Critical / High の場合

Step 1: インシデント検知（0分）

検知経路:

Datadog アラート（ブロック数異常）
カスタマーサポートからの報告
ユーザーからの問い合わせ

Step 2: SRE Teamに連絡（5分以内）

Step 3: 初動調査（10分以内）

Datadog Logs でタグベースクエリ実行：

waf_action:BLOCK
group by waf_rule, @httpRequest.uri

タイムレンジ: 直近10分

確認ポイント:

どのルール（waf_rule タグ）がブロックしているか
ブロックされているURIが正常なリクエストか
ブロックされているIPが正常なユーザーか

Step 4: 誤検知判断（15分以内）

以下の場合は誤検知と判断：

正常なページ（/, /about等）が大量にブロック
社内IPがブロック
既知の正常ユーザーIPがブロック

Step 5: 緊急ロールバック（30分以内）

ロールバック手順に従って即座に実施。

Step 6: 事後分析

インシデント解消後、以下を実施：

根本原因分析（RCA: Root Cause Analysis）
再発防止策の策定
ドキュメント更新
Postmortem 作成（テンプレート後述）

Medium / Low の場合

対応時間: 2時間-1営業日以内

Step 1: 詳細調査

Datadog Logs で該当リクエストをタグベースで特定：

waf_action:BLOCK waf_rule:XXX

Step 2: 原因特定

どのルールがマッチしたか
リクエスト内容（URI、ヘッダー、ボディ）
ユーザー情報（IP、国、User-Agent）

Step 3: 対応方針決定

判断	対応
誤検知	除外ルール設定
正常なブロック	特に対応不要
ルール調整必要	Terraform コード変更

Step 4: 対応実施

設定例: 特定URIで特定ルールを除外する場合

hcl

rule {
  name     = "core-rule-set"
  priority = 10

  override_action {
    none {}
  }

  statement {
    managed_rule_group_statement {
      vendor_name = "AWS"
      name        = "AWSManagedRulesCommonRuleSet"

      # 特定URIで特定ルールを除外
      scope_down_statement {
        not_statement {
          statement {
            byte_match_statement {
              search_string         = "/api/webhook"
              positional_constraint = "STARTS_WITH"
              field_to_match {
                uri_path {}
              }
              text_transformation {
                priority = 0
                type     = "NONE"
              }
            }
          }
        }
      }

      rule_action_override {
        action_to_use {
          count {}
        }
        name = "CrossSiteScripting_BODY"
      }
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "CoreRuleSet"
    sampled_requests_enabled   = true
  }
}

Step 5: 動作確認

Terraform apply 後、該当リクエストが正常に処理されることを確認。

4.3 地理的ブロックの誤検知対応

地理的ブロック（国外アクセスのブロック）特有の誤検知パターンと対応方法。

よくある誤検知パターン

パターン	原因	対応方針
VPN経由の正規ユーザー	海外VPNサーバー経由でアクセス	個別対応（ユーザーに国内VPN推奨）
海外在住の日本人ユーザー	海外IPからのアクセス	IP許可リスト追加を検討
CDN/プロキシ経由	海外のCDN/プロキシノード経由	X-Forwarded-For ヘッダーでの判定検討
誤った地理情報	IPアドレスの地理情報が誤っている	AWS サポートに報告、一時的にIP許可

海外アクセスの許可リスト設定

特定のIPまたはIPレンジを地理的ブロックから除外する必要がある場合：

設定例: 地理的ブロックの許可リスト設定

hcl

# 許可リスト用 IP Set の作成
resource "aws_wafv2_ip_set" "geo_allow_list" {
  provider           = aws.virginia
  name               = "${var.project_name}-geo-allow-list"
  scope              = "CLOUDFRONT"
  ip_address_version = "IPV4"

  addresses = [
    "203.0.113.0/24",  # 海外オフィスのIP範囲
    "198.51.100.10/32", # 特定の海外ユーザーIP
  ]
}

# 地理的ブロックルールの修正
rule {
  name     = "geo-blocking-non-japan"
  priority = 0

  action {
    block {}
  }

  statement {
    and_statement {
      statements {
        # 許可リストに含まれないこと
        not_statement {
          statement {
            ip_set_reference_statement {
              arn = aws_wafv2_ip_set.geo_allow_list.arn
            }
          }
        }
      }

      statements {
        # 日本以外からのアクセス
        not_statement {
          statement {
            geo_match_statement {
              country_codes = ["JP"]
            }
          }
        }
      }
    }
  }

  rule_label {
    name = "fastdoctor:geo:non-japan-access"
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "GeoBlocking"
    sampled_requests_enabled   = true
  }
}

緊急時の地理的ブロック一時無効化

Critical インシデント（国内IPが誤ってブロックされている等）の場合、地理的ブロックを一時的に無効化：

bash

# 緊急対応: 地理的ブロックを Count モードに変更
cd {terraform_for_aws_root}/fastdoctor-template/common/production

# waf.tf の該当ルールを編集
# action { block {} } → action { count {} }

terraform apply -var-file=terraform.tfvars -target=module.waf

# Slack に報告

事後対応:

原因調査（Datadog Logs または S3 ログでブロックされたIPを特定）
根本原因の特定（VPN、地理情報の誤り等）
恒久対策の実施（許可リスト追加等）
地理的ブロックを Block モードに戻す

5. 変更管理

5.1 変更の分類

変更タイプ	定義	承認プロセス	例
標準変更	事前計画されたPhase移行	SRE Team承認	Phase 1 → 2 移行
通常変更	WAF設定の調整	SRE Team レビュー + 承認	Rate Limiting閾値変更、除外ルール追加
緊急変更	インシデント対応のための即座の変更	事後承認（ロールバック等）	誤検知による緊急ロールバック（即座にCountモードに戻す）

変更履歴

日付	バージョン	変更内容	担当チーム	担当者
2026-03-12	1.0	初版作成	SRE	大賀

CloudFront WAF 運用設計書 ​

文書情報 ​

前提事項 ​

目次 ​

1. 運用体制 ​

1.1 役割と責任 ​

1.2 連絡体制 ​

通常時 ​

緊急時（大量ブロック発生等） ​

Blockモード適用時の事前連絡 ​

2. 定常運用フロー ​

2.1 日次運用（平日 9:00-10:00） ​

チェック項目 ​

実施手順 ​

日次レポート ​

2.2 週次運用（毎週月曜 10:00-11:00） ​

チェック項目 ​

実施手順 ​

週次レポート ​

2.3 マネージドルールバージョン管理 ​

バージョン更新作業手順 ​

ロールバック手順 ​

3. Phase移行管理 ​

3.1 Phase移行の全体フロー ​

3.2 Phase 1 → Phase 2 移行 ​

移行条件 ​

test.fastdoctor.jp での事前検証 ​

production環境への移行作業手順 ​

3.3 Phase 2 → Phase 3 移行 ​

移行条件 ​

CRS 誤検知分析 ​

test.fastdoctor.jp での事前検証 ​

production環境への移行作業手順 ​

3.4 Phase移行のロールバック ​

4. インシデント対応 ​

4.1 インシデント分類 ​

4.2 インシデント対応フロー ​

Critical / High の場合 ​

Medium / Low の場合 ​

4.3 地理的ブロックの誤検知対応 ​

よくある誤検知パターン ​

海外アクセスの許可リスト設定 ​

緊急時の地理的ブロック一時無効化 ​

5. 変更管理 ​

5.1 変更の分類 ​

関連リンク ​

変更履歴 ​

CloudFront WAF 運用設計書

文書情報

前提事項

目次

1. 運用体制

1.1 役割と責任

1.2 連絡体制

通常時

緊急時（大量ブロック発生等）

Blockモード適用時の事前連絡

2. 定常運用フロー

2.1 日次運用（平日 9:00-10:00）

チェック項目

実施手順

日次レポート

2.2 週次運用（毎週月曜 10:00-11:00）

チェック項目

実施手順

週次レポート

2.3 マネージドルールバージョン管理

バージョン更新作業手順

ロールバック手順

3. Phase移行管理

3.1 Phase移行の全体フロー

3.2 Phase 1 → Phase 2 移行

移行条件

test.fastdoctor.jp での事前検証

production環境への移行作業手順

3.3 Phase 2 → Phase 3 移行

移行条件

CRS 誤検知分析

test.fastdoctor.jp での事前検証

production環境への移行作業手順

3.4 Phase移行のロールバック

4. インシデント対応

4.1 インシデント分類

4.2 インシデント対応フロー

Critical / High の場合

Medium / Low の場合

4.3 地理的ブロックの誤検知対応

よくある誤検知パターン

海外アクセスの許可リスト設定

緊急時の地理的ブロック一時無効化

5. 変更管理

5.1 変更の分類

関連リンク

変更履歴