FDサービス系WAF 運用設計書
文書情報
| 項目 | 内容 |
|---|---|
| 作成日 | 2026-05-25 |
| 対象システム | FDサービス系 ALB + WAF（*.fstdr.jp） |
| 対象環境 | production |
| 関連ドキュメント | FDサービス系 移行設計書, WAF 運用設計書（LP向け）, CloudFront WAF アーキテクチャ設計書 |
| 関連Issue | mental-online-karte#11672 |
本ドキュメントの位置づけ
FDサービス系WAF（*.fstdr.jp）固有の運用差分を記載する。 運用体制・定常運用フロー・インシデント対応・変更管理等の共通事項は WAF 運用設計書（LP向け） に従う。
1. 対象範囲
| 項目 | LP向けWAF（既存） | FDサービス系WAF（本ドキュメント） |
|---|---|---|
| 対象ドメイン | fastdoctor.jp, test.fastdoctor.jp | *.fstdr.jp（11サービス） |
| AWSアカウント | fd-sys（913831226605） | fd-prod（967691968827） |
| WAFスコープ | CLOUDFRONT | REGIONAL（ALB に直接アタッチ。API Gateway は HTTP API のため WAF 非サポート、別途検討） |
| 共有リソース | waf-shared-sets（IP/UA Blacklist、CLOUDFRONT スコープ） | REGIONAL スコープで別途作成（IP リストの内容は Terraform 変数で共通化） |
| Datadog Pipeline | source:waf（共通） | 同一Pipelineを利用（waf_host タグでドメイン区別） |
2. ログコスト最適化（#11672）
Geo制限は導入しない方針のため（海外勤務の医師・渡航中の患者向けサービスがあるため）、当初想定していた国外Blockログによるコスト圧迫リスクは低下した。 ただし Block/Count ログ量が想定を超える場合に備え、以下のコスト最適化手段を記載する。
2.1 Datadog Index Exclusion Filter
Datadog側で国外BlockログをIndexから除外し、インデックスコスト（保存・検索）を削減する。
- 対象インデックス:
main - Exclusion Filter 名:
waf-geo-block-non-jp - 除外クエリ:
source:waf @httpRequest.country:(-JP) @action:BLOCK - サンプリング率: 100%（全て除外）
- 設定場所: Datadog Log Index Configuration
| ログ種別 | Datadog Index | Datadog検索 | S3 | Athena検索 |
|---|---|---|---|---|
| JP の Block/Count | 保存 | 可能 | 保存 | 可能 |
| 国外（JP以外）の Block | 除外 | 不可 | 保存 | 可能 |
| 国外（JP以外）の Count | 保存 | 可能 | 保存 | 可能 |
| ALLOW | 送信しない | - | - | - |
なぜDatadog側で除外するか:
- WAF Logging Filterでは
countryフィールドで条件分岐できない（action条件のみ）- Firehose Lambda Data Transformation で除去する方法もあるが、Lambda の開発工数・メンテナンスコスト（コード管理、エラーハンドリング、バージョン管理等）がかかる
- Datadog Index Exclusion Filter は設定のみで完結し、追加の開発・運用負荷がない
- 除外されたログもLive Tail・Log-based Metricsでは利用可能
2.2 誤検知調査: S3 + Athena
Datadog Indexから除外された国外Blockログの誤検知調査は、Firehose S3バックアップに保管された全ログを Athena で SQL 検索する。
WAF → Firehose → Datadog（Index除外で国外Block非表示）
└→ S3（AllData、全ログ保管）→ Athena（必要時にSQL検索）S3 + Athena を採用した理由（Datadogカスタムメトリクス案との比較、#11672で検討）:
既存の fastdoctor.jp, test.fastdoctor.jp のWAFログ（約5,215件/日）をベースに比較調査した結果、以下の通り。FDサービス系はこれよりログ量が大幅に多くなる見込みのため、コスト面でも S3 + Athena が有利。
| 観点 | S3 + Athena | Datadogカスタムメトリクス |
|---|---|---|
| 誤検知調査 | 全フィールド（URI, ヘッダー, ルールID等）をSQLで自由検索 | 集計値のみ。「なぜブロックされたか」は不明 |
| コスト | 月 $0.1〜0.5（実質無料） | 月 $2〜40（group by粒度次第。攻撃時にIP急増でコスト増リスク） |
| セキュリティ | 自社AWS内にログ保管。IAM/KMS/CloudTrailで制御 | Datadog SaaS委託 |
Datadogカスタムメトリクス（Generate Metrics）はDatadog社から提案されたが、 誤検知調査のユースケース（低頻度・全フィールド参照）にはS3+Athenaの方が適しており、見送り。 国内サービスのため国外トラフィックの傾向分析も不要。
S3 保管設計
| 項目 | 設定 |
|---|---|
| バックアップモード | AllData（Firehose Source record backup） |
| 圧縮 | gzip（Firehose標準） |
| パーティション | year/month/day（動的パーティショニング） |
| ライフサイクル | Standard → 30日後 Standard-IA → 90日後 Glacier Instant Retrieval |
| 保持期間 | 1年（監査要件） |
| 暗号化 | SSE-S3 or SSE-KMS |
| パブリックアクセス | 全ブロック |
Athena 関連設計
Athenaのデータベース・テーブル定義、Workgroup設定、コストモニタリング、クエリの投げ方については別途設計する。
関連ドキュメント:
2.3 Ingestionコスト削減（必要に応じて追加検討）
上記でもDatadogのインジェストコストが予算を超える場合、Firehose Lambda Data Transformation で国外BlockログをDatadogに送信する前に除去する方法がある。1-2ヶ月運用してコストを確認してから判断。
3. 疎通検証期間のDatadogアカウント分離
アクセス数が多いサービスのみ、疎通検証期間（約1週間）にインフラDatadogアカウントでログ量を計測する。
| サービス | Datadogアカウント |
|---|---|
| backend.fastdoctor.jp, p.fstdr.jp | インフラで検証後に本番切替 |
| その他（mental-reserve-patient 等） | 最初から本番 |
インフラアカウントは現状ログが無いため、WAFログの影響を正確に計測できる- 検証期間中も
インフラDatadogアカウントでダッシュボードでモニタリングする - 疎通検証完了後、本番Datadogアカウントに切り替え。ダッシュボードもexport/importする
変更履歴
| 日付 | バージョン | 変更内容 | 担当チーム | 担当者 |
|---|---|---|---|---|
| 2026-05-25 | 1.0 | 初版作成（WAF運用設計書からFDサービス固有部分を分離） | SRE | 大賀 |
| 2026-06-08 | 1.1 | WAFスコープを CLOUDFRONT → REGIONAL に変更。共有IPセットの管理方針を更新 | SRE | 大賀 |