仕組み

WAF サービスは Fastly と統合され、Fastly CDN サービス内のキャッシュロジックを使用して、Fastly グローバルノードでトラフィックをフィルタリングします。 Trustwave SpiderLabs の ModSecurity ルールとOWASP Top Ten Security Threat に基づくデフォルトのWAF ポリシーを使用して、実稼動環境でWAF サービスを有効にします。

WAF サービスは、WAF ルールセットに対して HTTP および HTTPS トラフィック(GETおよび POST リクエスト)を調べ、悪意のあるトラフィックや特定の規則に準拠しないトラフィックをブロックします。 サービスは、キャッシュの更新を試みるオリジンバインドトラフィックのみを調べます。 その結果、Fastly キャッシュでの攻撃トラフィックのほとんどを停止し、悪意のある攻撃からオリジントラフィックを保護します。 オリジントラフィックのみを処理することで、WAF サービスはキャッシュのパフォーマンスを維持し、キャッシュされていないリクエストごとに推定 1.5 ~ 20 ミリ秒の待ち時間しか発生しません。

ブロックされたリクエストのトラブルシューティング

WAF サービスが有効な場合、すべての web トラフィックと管理者トラフィックがWAFのルールに照らして検査され、ルールをトリガーするすべての web リクエストがブロックされます。 リクエストがブロックされると、ブロッキングイベントの参照 ID を含んだデフォルトの 403 Forbidden エラーページがリクエスターに表示されます。

WAF エラーページ

管理者からこのエラー応答ページをカスタマイズできます。 WAF応答ページのカスタマイズを参照してください。

Adobe Commerce管理ページまたはストアフロントが、正当な URL リクエストに対して 403 Forbidden エラーページを返した場合は、Adobe Commerce サポートチケットを送信します。 エラー応答ページから参照 ID をコピーし、チケットの説明に貼り付けます。

New Relicを使用して特定のリクエストに対するWAFの応答を特定するには、次を参照してください。

  • Agent_response - WAFのレスポンスコードを示します(200 は良好、406 はブロックを意味します)。
  • sigsci tags:要求の特性に基づいて、要求を特定の signal sciences タグにタグ付けします

WAFのメンテナンスとアップデート

Fastly は、商用のサードパーティ、Fastly の調査、オープンソースからのルールアップデートに基づいて、新しい CVE/テンプレートルールのパッチを更新およびロールアウトします。 Fastly は、必要に応じて、またはルールの変更がそれぞれのソースから利用可能な場合に、公開されたルールをポリシーに更新します。 また、Fastly では、WAF サービスが有効になった後で、公開されたルールクラスに一致するルールを、任意のサービスのWAF インスタンスに追加することができます。 これらの更新により、新しい攻撃や進化する攻撃に対する迅速な対応が保証されます。

Adobeと Fastly は、更新プロセスを管理して、更新がブロッキングモードでデプロイされる前に、新規または変更されたWAF ルールが実稼動環境で効果的に機能することを確認します。