OCI Web Application Firewall (WAF)

解決する課題

• SQL インジェクションや XSS など OWASP Top 10 系の攻撃をアプリ改修せずに防ぎたい
• ボットや総当たり・スクレイピングからの過剰なリクエストをレート制限したい
• 特定の国・地域や悪意ある IP からのアクセスを地理/IP ベースで遮断したい
• アプリ本体に手を入れずに、入口で一元的にトラフィックを検査・記録したい

主要概念と用語

• WAF ポリシー（WAF Policy）: 検査ルールや対処（許可/ブロック/チャレンジ）の集合。これを保護対象に適用する中心的な設定単位
• エッジ型 WAF（旧 WAF / Edge Policy）: DNS で WAF を経由させる CDN/エッジ配置型。世界中のエッジでリクエストを終端し、DDoS 緩和やキャッシュも担う
• ロードバランサ統合型 WAF（Network/Flexible LB に付与）: リージョン内の ロードバランサに直接アタッチする方式。VCN 内のバックエンドを近接で保護する
• 保護ルール（Protection Rule）: シグネチャに基づき悪性ペイロードを検出するルール。OWASP/ModSecurity 系のマネージドルールを含む
• アクセスルール（Access Control）: 送信元 IP・国・URL パス・ヘッダ等の条件で許可/拒否を決めるルール
• レート制限（Rate Limiting）: 一定時間あたりの同一送信元リクエスト数に上限を設け、超過分をブロック/チャレンジ
• アクション: マッチ時の挙動。Allow（許可）/ Detect（検知のみ・ログ記録）/ Block（遮断）/ Challenge（JS チャレンジや CAPTCHA でボット判定）
• WAF キャパシティと検査対象: HTTP/HTTPS のリクエスト（メソッド・URL・ヘッダ・ボディ・クエリ）をレイヤ7で検査する

仕様・制限・クォータ

• 2 つの配置方式: DNS 経由でエッジに通す エッジ型と、ロードバランサにアタッチする統合型。要件（グローバル配信か、リージョン内バックエンド保護か）で選ぶ
• ルールは Detect（検知のみ） と Block（遮断） のモードを持ち、まず Detect で誤検知を観測してから Block へ昇格させる運用が前提
• マネージドの保護ルールセットに加え、条件を組み合わせたカスタムルールを定義できる
• レート制限・アクセス制御・ボット管理（チャレンジ）などの機能をポリシー内で組み合わせ可能
• ポリシーあたりのルール数や条件数、レート制限のしきい値にはサービス上限があり、テナンシ既定値を超える場合は引き上げ申請が必要
• 主にレイヤ7（HTTP/HTTPS）を対象とする。L3/L4 のボリューム型 DDoS は OCI の基盤 DDoS 防御側で吸収される前提

内部の仕組み

WAF はアプリの手前に割り込むリバースプロキシ的なレイヤ7検査点として動作します。クライアントからの HTTP/HTTPS リクエストは、まず WAF がメソッド・URL・ヘッダ・クエリ・ボディを検査し、ポリシーのルールと突き合わせます。マッチした場合は設定アクション（Allow / Detect / Block / Challenge）を実行し、問題なければバックエンド（ロードバランサやオリジン）へ転送します。

エッジ型では DNS で WAF のエンドポイントへ向けることで、世界中のエッジロケーションがリクエストを終端し、TLS 終端・キャッシュ・DDoS 緩和とあわせて検査します。ロードバランサ統合型では、Flexible ロードバランサにポリシーをアタッチし、リージョン内でトラフィックを検査してからバックエンドセットへ流します。

保護ルールはシグネチャ（既知攻撃パターン）で評価され、レート制限は送信元ごとのカウンタで評価されます。すべての判定はログとして記録され、検知・遮断の状況を可視化できます。

設計パターン / ベストプラクティス

• Detect で慣らしてから Block: 本番投入前に検知モードで運用し、誤検知パターンを洗い出してチューニング
• 多層防御の一部として配置: WAF は L7 防御。L3/L4 の DDoS、ネットワーク制御（セキュリティリスト/NSG）、IAM と組み合わせて使う
• レート制限でボット・総当たりを抑止: ログインや検索など高負荷エンドポイントに送信元単位の上限を設定
• 地理/IP フィルタで攻撃面を縮小: サービス提供国以外や既知の悪性 IP を入口で遮断
• チャレンジでボット選別: 怪しいトラフィックには JS チャレンジ/CAPTCHA を挟み、人間と自動化を切り分け
• ルールはコード管理（IaC）: Terraform 等でポリシーを定義し、環境間で再現性を確保

運用・監視

• WAF のリクエスト判定は OCI Logging に出力し、検知/遮断の傾向やルール別ヒット数を可視化
• OCI Monitoring / アラームでブロック率やリクエスト急増を監視し、攻撃や誤検知を早期検知
• 誤検知が出たら、対象ルールを Detect に戻すか、条件で**例外（除外）**を追加してから再度 Block 化
• Cloud Guard と併用し、公開リソースや設定ミスを横断的に検出
• ルール変更は段階的に適用し、変更前後のブロック率・エラー率を比較してリグレッションを防ぐ

コスト

具体的な単価やしきい値は変動するため、最新の料金ページで確認してください。トラフィック量と保護対象数が主なコストドライバになります。

セキュリティ

• OWASP Top 10 対策: SQLi・XSS 等のシグネチャをマネージドルールでカバーし、アプリ改修なしに既知攻撃を遮断
• 最小公開の原則: WAF で守るエンドポイントのみを公開し、バックエンドはプライベートサブネットに置いて直接到達を防ぐ
• TLS 終端と検査: HTTPS を終端して暗号化ペイロードも検査対象にする
• IAM ポリシーで権限分離: WAF ポリシーの編集権限を運用者に限定し、誤設定の範囲を抑制
• 多層防御: WAF 単体に依存せず、NSG/セキュリティリスト・IAM・基盤 DDoS 防御と組み合わせる

Well-Architected の観点

• セキュリティ: レイヤ7の入口防御として OWASP 系攻撃・ボット・不正アクセスを遮断し、攻撃面を縮小する中心的なコントロール
• 信頼性: レート制限とエッジ型の DDoS 緩和により、過剰トラフィックからアプリの可用性を守る
• 運用上の優秀性: 検知ログを Logging/Monitoring に集約し、Detect から Block への段階適用で安全に運用変更できる
• パフォーマンス: エッジ型ではキャッシュ・TLS 終端をエッジで担い、オリジン負荷とレイテンシを軽減できる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. WAF ポリシーを作成（保護ルールやアクションを定義する器）
oci waf web-app-firewall-policy create \
  --compartment-id <compartment-ocid> \
  --display-name app-waf-policy

# 2. 作成したポリシーをロードバランサに紐づける WAF を作成
#    （ロードバランサ統合型。backend-type に LOAD_BALANCER を指定）
oci waf web-app-firewall create-load-balancer \
  --compartment-id <compartment-ocid> \
  --display-name app-waf \
  --web-app-firewall-policy-id <waf-policy-ocid> \
  --load-balancer-id <load-balancer-ocid>

# 3. ポリシーの内容（ルール・アクション）を確認
oci waf web-app-firewall-policy get \
  --web-app-firewall-policy-id <waf-policy-ocid>

# 4. 作成済み WAF の一覧を確認
oci waf web-app-firewall list \
  --compartment-id <compartment-ocid>