WAFカスタムルールへのファイアウォールルール移行
Cloudflareは既存のファイアウォールルールをWAFカスタムルールに変換しました。カスタムルールを使用すると、同じレベルの保護といくつかの追加機能を得ることができます。カスタムルールはCloudflareダッシュボードのセキュリティ > WAF > カスタムルールで利用可能です。
ファイアウォールルールとWAFカスタムルールの主な違いは以下の通りです。
- ブロックアクションの改善された応答
- ブロックされたリクエストの異なるエラーページ
- 許可およびバイパスアクションの両方を置き換える新しいスキップアクション
- カスタムルールは順番に評価される
- ログとイベント
- 新しいAPIとTerraformリソース
WAFカスタムルールでは、_ブロック_アクションの応答をカスタマイズすることができます。
デフォルトのブロック応答はCloudflareの標準HTMLページです。_ブロック_アクションに対してカスタム応答を送信する必要がある場合は、カスタムルールを設定して、カスタム応答コード（デフォルトは403）とカスタムボディ（HTML、JSON、XML、またはプレーンテキスト）を持つ固定応答を返すようにします。
単一のルールに対してカスタム応答を定義するには、セキュリティ > WAF > カスタムルール ↗に移動し、カスタムルールを編集してブロック関連のオプションを入力します。
_ブロック_アクションを持つファイアウォールルールによってブロックされたリクエストは、Cloudflareの1020エラーコード応答を受け取ります。Cloudflareユーザーは、カスタムページ > 1000クラスエラーでこのエラーページをカスタマイズできます。
WAFカスタムルールによってブロックされたリクエストは、異なる応答を受け取ります：WAFブロック応答です。デフォルトのブロック応答をカスタマイズするには、次のいずれかを行います。
- カスタムページ ↗ > WAFブロックで、ゾーン全体に対してカスタムWAFブロック応答を定義します。このカスタムページは常にHTMLコンテンツタイプを持ちます。
- 特定のWAFカスタムルールによってブロックされたリクエストに対してカスタム応答を定義します。このカスタム応答はHTML以外の他のコンテンツタイプもサポートしています。
ファイアウォールルールによってブロックされたリクエストのためにカスタムページで1xxxエラーページをカスタマイズしている場合は、上記のいずれかの方法を使用してブロックされたリクエストのための新しい応答ページを作成する必要があります。
カスタムページに関する詳細は、カスタムページの設定を参照してください。
ファイアウォールルールは、_許可_および_バイパス_アクションをサポートしており、これらはしばしば一緒に使用されました。これらのアクションは、信頼できるIPアドレスからのリクエストなど、既知の正当なリクエストを処理するために一般的に使用されました。
リクエストが_許可_をトリガーすると、残りのファイアウォールルールは評価されず、リクエストは次のセキュリティ製品に進むことが許可されます。_バイパス_アクションは、アクションをトリガーするリクエストで実行しないべきセキュリティ製品（WAF管理ルール、レート制限ルール、ユーザーエージェントブロックなど）を指定するために設計されました。
ファイアウォールルールでは、特定のリクエストに対してすべてのセキュリティ製品の実行を停止したい場合、2つのルールを作成する必要がありました：
- _バイパス_アクションを持つ1つのルール（すべてのセキュリティ製品を選択）。
- 他のファイアウォールルールの実行を停止するための_許可_アクションを持つ1つのルール。
この一般的なシナリオに対処するために2つのルールを持つ必要がある要件は、WAFカスタムルールには適用されません。今後は、_スキップ_アクションを使用する必要があります。これは_許可_および_バイパス_アクションを組み合わせたものです。_スキップ_アクションは、WAFカスタムルールではサポートされていない_許可_および_バイパス_アクションを完全に置き換えます。
_スキップ_アクションを使用すると、次のことができます：
- 残りのカスタムルールの実行を停止する（_許可_アクションに相当）
- 他のセキュリティ製品の実行を避ける（_バイパス_アクションに相当）
- 上記の組み合わせ。
また、_スキップ_アクションに一致するカスタムルールのイベントをログに記録するかどうかを選択することもできます。これは、正のセキュリティモデルを作成する際に、大量の正当なトラフィックをログに記録しないようにするのに特に便利です。
ファイアウォールルールのアクションには、優先順位の順序を使用する際に特定の優先順位の順序がありました。対照的に、カスタムルールのアクションにはそのような順序はありません。カスタムルールは常に順番に評価され、一部のアクション（_ブロック_など）は他のルールの評価を停止します。
たとえば、優先順位の順序を使用して、同じ優先順位で両方が受信リクエストに一致する次のファイアウォールルールを持っている場合：
- ファイアウォールルール #1 — 優先順位: 2 / アクション: ブロック
- ファイアウォールルール #2 — 優先順位: 2 / アクション: 許可
リクエストは許可されます。なぜなら、ファイアウォールルールの_許可_アクションが_ブロック_アクションよりも優先されるからです。
対照的に、受信リクエストに一致する2つのカスタムルールを作成した場合：
- カスタムルール #1 — アクション: ブロック
- カスタムルール #2 — アクション: スキップ（残りのカスタムルールをスキップするように設定）
リクエストはブロックされます。なぜなら、カスタムルールは順番に評価され、_ブロック_アクションが他のルールの評価を停止するからです。
カスタムルールによって記録されたイベントは、セキュリティイベントに表示され、セキュリティ > イベントでCustom Rulesをソースとして利用できます。
移行が行われた日を含む期間を選択すると、セキュリティイベントページでファイアウォールルールによって生成されたイベントも見つけることができます。同様に、移行期間中に_スキップ_および_許可_アクションの両方を持つイベントも同じビューで見つけることができます。
WAFカスタムルールを管理するための推奨APIはルールセットAPIです。ルールセットAPIは、最近のCloudflareセキュリティ製品で使用され、APIとの対話時に一貫したユーザーエクスペリエンスを提供します。ルールセットAPIへの移行に関する詳細は、APIユーザーに関する関連変更を参照してください。
ファイアウォールルールAPIとフィルターAPIは、2025-01-15まで動作します。ファイアウォールルールとWAFカスタムルールの両方に対して単一のルールリストがあり、このリストにはWAFカスタムルールが含まれます。内部変換プロセスのおかげで、ファイアウォールルールAPIとフィルターAPIは、これらのWAFカスタムルールから変換されたファイアウォールルール/フィルターを返します。
Terraformを使用している場合、WAFカスタムルールを構成するための推奨方法は、http_request_firewall_customフェーズで構成されたcloudflare_ruleset ↗リソースを使用することです。Terraform構成の更新に関する詳細は、Terraformユーザーに関する関連変更を参照してください。
Cloudflareダッシュボードのファイアウォールルールタブは現在非推奨です。ファイアウォールルールは、Cloudflareダッシュボードのセキュリティ > WAF > カスタムルールにWAFカスタムルールとして表示されます。
両方の製品にアクセスできるユーザーには、ファイアウォールルールタブは2025-01-15までのみ利用可能です。
ファイアウォールルールAPIおよび関連するCloudflareフィルターAPIは現在非推奨です。 これらのAPIは2025-01-15に動作を停止します。ファイアウォールルールAPIまたはCloudflareフィルターAPIに基づく自動化をこの日までにルールセットAPIに移行する必要があります。ルールIDはファイアウォールルールとカスタムルールで異なるため、特定のルールIDを扱う自動化プロセスに影響を与える可能性があります。
現時点では、すべての3つのAPI（ファイアウォールルールAPI、フィルターAPI、ルールセットAPI）が利用可能です。Cloudflareは、内部的にファイアウォールルールAPIおよびフィルターAPIの呼び出しを対応するルールセットAPIの呼び出しに変換します。ファイアウォールルールAPI/フィルターAPIとルールセットAPIの間の変換されたAPI呼び出しは、Cloudflareによって生成された監査ログに表示され、実際にリクエストを行ったユーザーによって生成されたものではありません。ファイアウォールルールとWAFカスタムルールの両方に対して単一のルールリストがあります。
ブロックされたリクエストのカスタム応答や_スキップ_アクションなど、WAFカスタムルールの新機能はファイアウォールルールAPIではサポートされていません。これらの機能を利用するには、CloudflareはCloudflareダッシュボードのカスタムルールページまたはルールセットAPIを使用することを推奨しています。
WAFカスタムルールをルールセットAPIを使用して管理するための例については、WAFドキュメントを参照してください。
Cloudflareプロバイダーの以下のTerraformリソースは現在非推奨です：
これらのリソースは2025-01-15に動作を停止します。これらのリソースを使用してファイアウォールルールの構成を管理している場合は、この日までに手動でcloudflare_ruleset ↗リソースにTerraform構成を移行する必要があります。
現時点では、すべての3つのTerraformリソース（cloudflare_firewall_rule、cloudflare_filter、cloudflare_ruleset）が利用可能です。ファイアウォールルールとWAFカスタムルールの両方に対して単一のルールリストがあります。
WAFカスタムルールの新機能の一部は、非推奨のTerraformリソースではサポートされていません。これらの機能を利用するには、Cloudflareはcloudflare_rulesetリソースを使用することを推奨しています。
Terraformを使用してWAFカスタムルールを構成するための例については、Terraformに関するドキュメントを参照してください。
cf-terraforming ↗ツールを使用して、現在のWAFカスタムルール（Cloudflareがファイアウォールルールから変換したもの）のTerraform構成を生成できます。その後、新しいリソースをTerraformステートにインポートします。
Terraformでファイアウォールルール（およびフィルター）の構成を新しいルールセット構成に置き換えるための推奨手順は以下の通りです。
-
次のコマンドを実行して、ゾーンのすべてのルールセット構成を生成します：
Terminal window cf-terraforming generate --zone <ZONE_ID> --resource-type "cloudflare_ruleset"resource "cloudflare_ruleset" "terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31" {kind = "zone"name = "default"phase = "http_request_firewall_custom"zone_id = "<ZONE_ID>"rules {[...]}[...]}[...] -
前のコマンドは、ルールセットエンジンに基づく他のCloudflare製品のための追加のルールセット構成を返す場合があります。ファイアウォールルールをカスタムルールに移行しているため、
http_request_firewall_customフェーズのTerraformリソースのみを保持し、.tf構成ファイルに保存します。次のステップで完全なリソース名が必要になります。 -
以前に特定した
cloudflare_rulesetリソースをterraform importコマンドを使用して Terraform ステートにインポートします。例えば：
terraform import cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31 zone/<ZONE_ID>/3c0b456bc2aa443089c5f40f45f51b31cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ID "zone/<ZONE_ID>/3c0b456bc2aa443089c5f40f45f51b31" からインポート中...cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: インポートの準備完了！ cloudflare_ruleset のインポートの準備ができましたcloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ステートを更新中... [id=3c0b456bc2aa443089c5f40f45f51b31]
インポート成功！
インポートされたリソースは上記に示されています。これらのリソースは現在、あなたの Terraform ステートにあり、以後 Terraform によって管理されます。-
terraform planを実行して、Terraform が新しいcloudflare_rulesetリソースのステートを確認することを検証します。これは、すでに Terraform によって管理されている他の既存のリソースに加えて行われます。例えば：Terminal window terraform plancloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ステートを更新中... [id=3c0b456bc2aa443089c5f40f45f51b31][...]cloudflare_filter.my_filter: ステートを更新中... [id=14a2524fd75c419f8d273116815b6349]cloudflare_firewall_rule.my_firewall_rule: ステートを更新中... [id=0580eb5d92e344ddb2374979f74c3ddf][...] -
Terraform ステートからファイアウォールルールとフィルターに関連するすべてのステートを削除します：
-
次のコマンドを実行して、ファイアウォールルールとフィルターに関連するすべてのリソースを見つけます：
Terminal window terraform state list | grep -E '^cloudflare_(filter|firewall_rule)\.'cloudflare_filter.my_filtercloudflare_firewall_rule.my_firewall_rule -
影響を理解するために、リソースを削除することなく、ドライランモードで
terraform state rm ...コマンドを実行します：Terminal window terraform state rm -dry-run cloudflare_filter.my_filter cloudflare_firewall_rule.my_firewall_rulecloudflare_filter.my_filter を削除しますcloudflare_firewall_rule.my_firewall_rule を削除します -
影響が正しいように見える場合は、
-dry-runパラメータなしで同じコマンドを実行して、実際にリソースを Terraform ステートから削除します：Terminal window terraform state rm cloudflare_filter.my_filter cloudflare_firewall_rule.my_firewall_rulecloudflare_filter.my_filter を削除しましたcloudflare_firewall_rule.my_firewall_rule を削除しました2 つのリソースインスタンスを正常に削除しました。
-
-
Terraform ステートからファイアウォールルールとフィルターリソースを削除した後、
.tf設定ファイルからcloudflare_filterとcloudflare_firewall_ruleリソースを削除します。 -
terraform planを実行して、設定ファイルから削除したリソースがもはや表示されないことを確認します。保留中の変更はないはずです。
terraform plancloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ステートを更新中... [id=3c0b456bc2aa443089c5f40f45f51b31][...]
変更はありません。あなたのインフラストラクチャは設定と一致しています。
Terraform はあなたの実際のインフラストラクチャを設定と比較し、違いがないことを確認したため、変更は必要ありません。Cloudflare リソースを Terraform にインポートし、cf-terraforming ツールを使用する詳細については、以下のリソースを参照してください：