OCI WAF Edge Policy

解決する課題

• 複数リージョン・複数オリジンに配信する Web アプリを、世界中のエッジで一元的に検査・防御したい
• SQL インジェクションや XSS など OWASP Top 10 系の攻撃を、アプリ改修なしにオリジン手前で遮断したい
• 攻撃トラフィックや過剰アクセスをオリジンに到達する前に吸収し、可用性とレイテンシを守りたい
• ボット・スクレイピング・総当たりを JS チャレンジや CAPTCHA で選別したい
• 静的コンテンツをエッジでキャッシュし、オリジン負荷と応答時間を下げたい

主要概念と用語

• Edge Policy（エッジポリシー）: DNS でトラフィックを Oracle のグローバルエッジへ向け、エッジ上でリクエストを検査する WAF 方式。**グローバル（リージョン非依存）**に動作する
• WAF ポリシー（リージョン型）: ロードバランサや Web ドメインにアタッチするリージョン内の方式。Edge Policy とは別系統のリソースで、相互変換は手動の再作成が必要
• CNAME / DNS 切替: 保護対象ドメインの DNS を Oracle 提供の CNAME へ向けることで、トラフィックがエッジを経由するようになる
• オリジン（Origin）: 実際のアプリが動くバックエンド。エッジで検査されたリクエストだけがオリジンへ転送される
• 保護ルール（Protection Rule）: 既知攻撃のシグネチャに基づきペイロードを検出する OWASP/ModSecurity 系のマネージドルール
• アクセス制御（Access Control）: 送信元 IP・国・URL パス・ヘッダ等の条件で許可/拒否を決めるルール
• ボット管理（Bot Management）: 自動化トラフィックを判定する仕組み。JS チャレンジ・CAPTCHA・GoodBot 許可などで人間と自動化を切り分ける
• アクション: マッチ時の挙動。**Detect（検知のみ・ログ記録）/ Block（遮断）**を基本に、ボット管理ではチャレンジ系のアクションを使う
• キャッシュ（Caching）: エッジで静的レスポンスを保持し、オリジンへのリクエストを削減する機能

仕様・制限・クォータ

• Edge Policy はグローバル方式で、利用には Oracle のエッジノードを許可リストに加えることと、ドメインを Oracle の CNAME へ向ける DNS 設定が前提
• リージョン型の WAF ポリシー（ロードバランサ統合）とは別系統のリソースで、片方からもう片方への自動移行ツールは無く、設定を手動で再作成する必要がある
• 保護ルールは Detect（検知のみ） と Block（遮断） のモードを持ち、まず Detect で誤検知を観測してから Block へ昇格させる運用が前提
• マネージドの保護ルールセットに加え、条件を組み合わせたアクセス制御ルールやボット管理をポリシー内で構成できる
• ポリシーあたりのルール数・条件数・レート制限のしきい値などにはサービス上限があり、テナンシ既定値を超える場合は引き上げ申請が必要
• 主にレイヤー7（HTTP/HTTPS）を対象とする。L3/L4 のボリューム型 DDoS は OCI の基盤 DDoS 防御側で吸収される前提

内部の仕組み

Edge Policy はオリジンの手前に割り込むグローバルなレイヤー7検査点として動作します。まず保護対象ドメインの DNS を Oracle の CNAME へ向けることで、クライアントのリクエストは世界中の Oracle エッジロケーションへ誘導されます。エッジはリクエストのメソッド・URL・ヘッダ・クエリ・ボディを検査し、ポリシーのルールと突き合わせます。

マッチした場合は設定アクション（Detect / Block やボットチャレンジ）を実行し、問題なければオリジンへ転送します。エッジで TLS を終端し、保護ルール・アクセス制御・ボット管理・キャッシュをまとめて担うため、攻撃トラフィックや過剰アクセスをオリジンに到達する前に吸収できます。静的レスポンスはエッジでキャッシュされ、オリジンへのリクエスト数とレイテンシを削減します。

保護ルールはシグネチャ（既知攻撃パターン）で評価され、アクセス制御は条件マッチ、ボット管理は自動化の特徴やチャレンジ応答で判定されます。すべての判定はログとして記録され、検知・遮断の状況を可視化できます。

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

• 方式を最初に確定: Edge Policy とリージョン型は別リソースで相互移行が手動になるため、グローバル配信かリージョン内保護かを設計初期に決める
• Detect で慣らしてから Block: 本番投入前に検知モードで運用し、誤検知パターンを洗い出してチューニング
• オリジンをエッジ専用に絞る: オリジン側で Oracle エッジ IP のみ許可し、直接到達によるバイパスを塞ぐ
• 多層防御の一部として配置: Edge Policy は L7 防御。基盤 DDoS 防御・ネットワーク制御（セキュリティリスト/NSG）・IAM と組み合わせて使う
• ボット管理で自動化を選別: ログインや検索など高負荷エンドポイントに JS チャレンジ/CAPTCHA を挟み、人間と自動化を切り分ける
• キャッシュで負荷とレイテンシを軽減: 静的コンテンツをエッジでキャッシュし、オリジン負荷と応答時間を下げる
• ルールはコード管理（IaC）: Terraform 等でポリシーを定義し、環境間で再現性を確保

運用・監視

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

コスト

具体的な単価やしきい値は変動するため、最新の料金ページで確認してください。トラフィック量と保護対象ドメイン数が主なコストドライバになります。エッジキャッシュが効くとオリジンへの転送量を抑えられる点も考慮します。

セキュリティ

• OWASP Top 10 対策: SQLi・XSS 等のシグネチャをマネージドルールでカバーし、アプリ改修なしに既知攻撃を遮断する
• オリジン秘匿の原則: オリジンの直接到達を遮断し、Oracle エッジ経由のトラフィックのみを受け付ける
• TLS 終端と検査: エッジで HTTPS を終端し、暗号化ペイロードも検査対象にする
• ボット・不正アクセス対策: アクセス制御とボット管理で自動化・地理/IP ベースの不正アクセスを入口で抑止する
• IAM ポリシーで権限分離: ポリシーの編集権限を運用者に限定し、誤設定の範囲を抑える
• 多層防御: Edge Policy 単体に依存せず、NSG/セキュリティリスト・IAM・基盤 DDoS 防御と組み合わせる

関連サービス・比較

リージョン型のロードバランサ統合 WAF ポリシーが最も近い関連サービスです。配置方式と適用範囲が異なるため、要件で選び分けます。

ハンズオン / CLI例

# 1. 保護対象ドメインを登録（DNS をこのドメインの CNAME へ向ける前提）
oci waas waas-policy create \
  --compartment-id <compartment-ocid> \
  --domain app.example.com \
  --origins '{"primary":{"uri":"origin.example.com"}}' \
  --display-name app-edge-policy

# 2. 作成したエッジポリシーの一覧を確認
oci waas waas-policy list \
  --compartment-id <compartment-ocid>

# 3. ポリシーの内容（ルール・オリジン・設定）を確認
oci waas waas-policy get \
  --waas-policy-id <waas-policy-ocid>

# 4. アクセス制御ルールを更新（地理/IP ベースの許可・拒否などを設定）
oci waas access-rule update \
  --waas-policy-id <waas-policy-ocid> \
  --access-rules file://access-rules.json