WAF管理ルールの移行

2022年5月4日、Cloudflareは以前のWAF管理ルールのバージョンから新しいWAF管理ルールへのWAF移行を開始し、最初の適格ゾーンのセットが移行できるようになりました。現在、すべてのゾーンがWAF管理ルールに移行でき、パートナーアカウントも含まれます。

CloudflareダッシュボードまたはAPIを介してゾーンの更新プロセスを開始できます。現在、更新プロセスは常にあなたによって開始されます。移行は元に戻せません — 新しいWAF管理ルールに更新すると、WAF管理ルールを使用することはできなくなります。

移行が完了すると、CloudflareダッシュボードのManaged rulesタブ（Security > WAF > Managed rulesで利用可能）は新しいインターフェースを表示し、WAF管理ルールAPIは機能しなくなります。

主な利点

新しいWAF管理ルールのバージョンは、以前のバージョンに対して以下の利点を提供します：

新しいマッチングエンジン – WAF管理ルールはRuleset Engineによって動作し、より迅速な管理ルールの展開と、スケーリングの問題なしにさらに多くのトラフィックをチェックする能力を提供します。ルールは、WAFカスタムルールなどの他のCloudflareセキュリティ製品で使用されるのと同じ構文に従います。
更新された管理ルールセット – WAFの管理ルールセットの1つであるCloudflare OWASP Core Rulesetは、最新のOWASP Core Ruleset（v3.x）に基づいており、パラノイアレベルを追加し、WAF管理ルールで使用されていたバージョン（2.x）と比較して誤検知率を改善します。また、各ルールがスコアにどの程度寄与しているか、トリガーされたリクエストの合計スコアが何であったかを明確に示すことで、感度スコアに対するより多くの制御が可能です。
より良いルールのブラウジングと構成 – 1クリックで管理ルールセットを展開し、即座に保護を得ることができます。全体のルールセットの動作をオーバーライドするか、単一のルールをカスタマイズします。特定のタグを持つすべてのルールにオーバーライドを適用して、特定のソフトウェアや攻撃ベクターに適用されるルールを調整できます。以下のような構成を展開できます：
- Cloudflare管理ルールセットをすべてのゾーンに展開します。
- パスに/api/*を含まないすべてのトラフィックにCloudflare OWASP Core Rulesetを展開します。
- 自分のIPからのトラフィックに対してアカウント全体で管理ルールセットを無効にします。

WAF管理ルールの利点についての詳細は、ブログ記事 ↗を参照してください。

移行の影響

URIベースのWAFオーバーライドがないすべてのゾーンを移行できます。新しいWAFに移行すると、同じ保護がゾーンに適用されます。

以前のWAF管理ルールのバージョンからのほとんどの構成設定は新しいバージョンに移行されますが、OWASP ModSecurity Core Rule Setで元々定義されていた特定の構成は失われます — 必要に応じて新しいWAF管理ルールでこれらの構成を作成する必要があります。

APIユーザーにとって、以前のWAF管理ルールを管理するためのAPIは、移行後に機能しなくなります。新しいWAF管理ルールを管理するには、Rulesets APIを使用する必要があります。

移行される構成

更新プロセスは、WAF管理ルールの以下の設定に対して同等の構成を作成します：

Bypass > _WAF Managed Rules_で構成されたファイアウォールルール。
_Disable Security_で構成されたページルール。
_Web Application Firewall: Off_または_Web Application Firewall: On_で構成されたページルール。

OWASPルールセットの構成は部分的に移行されます。詳細については次のセクションを参照してください。

更新プロセスで失われる構成

更新プロセスは、以前のWAF管理ルールで利用可能なOWASP ModSecurity Core Rule Setの設定を部分的に移行します。

移行されるOWASP設定は以下の通りです：

感度: 古い感度値は、新しいOWASPルールセットの以下のパラノイアレベル（PL）およびスコア閾値の組み合わせに移行されます：

古い感度新しいOWASPのPL 新しいOWASPのスコア閾値
高 PL2 中 – 40以上
中 PL1 高 – 25以上
低 PL1 中 – 40以上
デフォルト PL2 中 – 40以上
アクション: 以前のOWASPルールセットのアクションは、新しいOWASP管理ルールセットでほぼ直接的にマッピングされますが、_Simulate_アクションは_Log_に移行されます。

古い感度	新しいOWASPのPL	新しいOWASPのスコア閾値
高	PL2	中 – 40以上
中	PL1	高 – 25以上
低	PL1	中 – 40以上
デフォルト	PL2	中 – 40以上

以下のOWASP設定は移行されません。2つのバージョン間に直接的な同等性がないためです：

OWASPグループオーバーライド
OWASPルールオーバーライド

これらの設定を置き換えるには、Cloudflare OWASP Core RulesetをWAF管理ルールで再度構成する必要があります。新しいOWASP Core Rulesetの構成についての詳細は、Cloudflare OWASP Core Rulesetを参照してください。

更新を妨げる構成

ゾーンにURIベースのWAFオーバーライド（API経由でのみ利用可能）がある場合、WAF管理ルールに移行するオプションはありません。WAF管理ルールに更新するには、次の手順を実行する必要があります：

WAFオーバーライドを削除する操作を使用して、既存のURIベースのWAFオーバーライドを削除します。
以下に説明する更新プロセスに従います。

Cloudflareダッシュボードの変更

更新プロセスが完了すると、CloudflareダッシュボードはSecurity > WAF > Managed rulesに新しいWAF管理ルールインターフェースを表示し、管理ルールセットを展開し、その構成を調整できます。

WAF管理ルールに移行した後、Cloudflareダッシュボードは、ゾーンに管理ルールセットを展開できる新しいインターフェースを表示します。

WAF管理ルールとは異なり、新しいインターフェースにはWAFを有効にするためのグローバルなオン/オフ設定はありません。代わりに、各管理ルールセットを個別にゾーンに展開します。

ダッシュボードでWAF管理ルールを構成する方法についての詳細は、ダッシュボードでゾーンの管理ルールセットを展開するを参照してください。

APIの変更

移行が完了すると、WAF管理ルールと対話するためのAPIは機能しなくなります。これらのAPIは以下の通りです：

WAF管理ルールで作業するには、Rulesets APIを使用する必要があります。APIを介してWAF管理ルールを展開する方法についての詳細は、APIを介して管理ルールセットを展開するを参照してください。

Terraformの変更

移行が完了すると、WAF管理ルールを構成するための以下のTerraformリソースは機能しなくなります：

これらのリソースは、Terraform Cloudflareプロバイダーのバージョン3.35までのみサポートされていました。バージョン4.xはこれらのリソースをサポートしていません ↗。

新しいWAF管理ルールの構成をTerraformで管理するには、cloudflare_ruleset ↗リソースを使用する必要があります。

適格ゾーン

フェーズ2（2022年9月19日以降）

フェーズ2では、すべてのゾーンが移行の対象となります。正確な移行手順は、Cloudflareプランによって異なります。

ProおよびBusinessの顧客は、CloudflareダッシュボードまたはAPIを介して新しいWAF管理ルールに更新できます。新しいバージョンが有効になると、以前のWAF管理ルールのバージョンは自動的に無効になります。
Enterpriseの顧客は、以前のWAF管理ルールのバージョンを有効にしたまま新しいWAF管理ルールの構成を有効にでき、新しいWAF構成の影響を確認できます。新しい構成の動作を確認し、特定の管理ルールに必要な調整を行った後、Enterpriseユーザーは移行を完了し、以前のWAF管理ルールのバージョンを無効にできます。

注意: URIベースのWAFオーバーライドがあるゾーンは、API経由でのみ管理でき、すぐに新しいWAF管理ルールに移行できません。移行する前にこれらのオーバーライドを削除する必要があります。

フェーズ1（2022年5月4日以降）

フェーズ1では、移行が適格ゾーンのサブセットに対して利用可能になり、以下の要件を満たす必要がありました：

ゾーンには：
- WAFが無効、または
- WAFが有効で、Cloudflare管理ルールセットのみが有効（OWASP ModSecurity Core Rule Setは無効である必要があります）。
ゾーンには、WAF管理ルールをバイパス、無効化、または有効化するファイアウォールルールやページルールがありません：
- Bypass > _WAF Managed Rules_で構成されたファイアウォールルール。
- _Disable Security_で構成されたページルール。
- _Web Application Firewall: Off_または_Web Application Firewall: On_で構成されたページルール。
ゾーンにはURIベースのWAFオーバーライドがありません（API経由でのみ利用可能）。

移行の開始

CloudflareダッシュボードまたはAPIを介してWAFの更新を開始できます。

ダッシュボードを使用する

Cloudflareダッシュボード ↗にログインし、アカウントとゾーンを選択します。
Security > WAF > Managed rulesに移動します。

Enterprise顧客の場合、ダッシュボードには以下のバナーが表示されます：

Professional/Business顧客の場合、ダッシュボードには以下のバナーが表示されます：
更新バナーでReview configurationを選択します。このバナーは適格ゾーンでのみ表示されます。
提案されたWAF構成ルールを確認します。提案された構成に対して、WAF管理ルールの構成を編集するや、ルールセットや特定のルールの実行をスキップするための例外を作成するなどの調整を行うことができます。
確認が完了したら、Deployを選択して新しいWAF管理ルール構成を展開します。

Professional/Business顧客の場合、Cloudflareは新しいWAF構成を展開し、その後以前のWAFバージョンを無効にします。移行プロセスには数分かかる場合があります。移行が完了すると、ダッシュボードにはSecurity > WAF > Managed rulesに新しいWAF管理ルールインターフェースが表示されます。移行が完了したかどうかを確認するには、ダッシュボードを更新してください。

Enterprise顧客の場合、Deployを選択すると、両方のWAF実装が同時に有効になり、新しい構成を検証できます。追加のガイダンスについては、次のセクションの手順を参照してください。

新しいWAF構成を検証し、アップグレードを完了する（Enterprise顧客のみ）

Enterprise顧客の場合、新しいWAF構成を展開した後、両方のWAF実装が同時に有効になります。この段階（検証モードと呼ばれます）では、Cloudflareダッシュボードに新旧のWAF管理ルールがManaged rulesタブに表示されます。新しいWAF管理ルールは以前のバージョンの前に実行されます。

現在の検証モードを使用して、新しいWAF構成の動作をSecurity Events（Security > Events）で確認します。詳細については、Security Eventsでの新しいWAFの動作を分析するを参照してください。
WAFを両方有効にした状態で設定の確認が完了したら、更新バナーでReady to updateを選択し、次にTurn off previous versionを選択します。この操作により、移行が完了し、以前のWAFバージョンが無効になります。

移行が完了すると、ダッシュボードにはSecurity > WAF > Managed rulesの新しいWAF管理ルールインターフェースのみが表示されます。移行が完了したかどうかを確認するには、ダッシュボードを更新してください。

APIの使用

Check WAF update compatibility操作を使用して、現在の設定に基づいてゾーンが新しいWAFに更新できるかどうかを確認します：
Terminal window
```
curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/waf_migration/check?phase_two=1" \
--header "Authorization: Bearer <API_TOKEN>"
```
例の応答：
```
{
  "result": {
    "compatible": true,
    "migration_state": "start"
  },
  "success": true,
  "errors": [],
  "messages": []
}
```
応答に"compatible": trueが含まれている場合、これはゾーンが新しいWAFに更新できることを意味し、更新プロセスを進めることができます。応答に"compatible": falseが含まれている場合、これは現在の設定に基づいてゾーンが更新の対象外であることを意味します。詳細についてはEligible zonesを参照してください。

現在の設定に対応する新しいWAF設定を取得するには、Get new WAF configuration操作を使用します：

curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/waf_migration/config?phase_two=1" \
--header "Authorization: Bearer <API_TOKEN>"

例の応答：

{
  "result": {
    "name": "default",
    "rules": [
      {
        "id": "",
        "version": "",
        "action": "execute",
        "expression": "true",
        "description": "",
        "ref": "",
        "enabled": true,
        "action_parameters": {
          "id": "efb7b8c949ac4650a09736fc376e9aee",
          "overrides": {
            "rules": [
              {
                "id": "23ee7cebe6e8443e99ecf932ab579455",
                "action": "log",
                "enabled": false
              }
            ]
          }
        }
      }
    ]
  },
  "success": true,
  "errors": [],
  "messages": []
}

上記の例で返された設定は、以前のWAFバージョンの既存の設定に一致し、以下を含みます：

Cloudflare Managed Rulesetを実行するルール（ルールセットID efb7b8c949ac4650a09736fc376e9aee）。
同じルールセット内のルールApache Struts - Open Redirect - CVE:CVE-2013-2248（ルールID 23ee7cebe6e8443e99ecf932ab579455）に対する単一のオーバーライドで、アクションをlogに設定し、ルールを無効にします。

（オプション、エンタープライズ顧客のみ）エンタープライズゾーンをWAF管理ルールに移行する場合、移行を完了する前に検証モードに入ることができます。このモードでは、両方のWAF実装が有効になります。Update a zone entry point ruleset操作を使用し、waf_migration=validation&phase_two=1のクエリ文字列パラメータを含めることを確認してください：
Terminal window
```
curl --request PUT \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_request_firewall_managed/entrypoint?waf_migration=validation&phase_two=1" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "name": "default",
  "rules": [
    {
      "action": "execute",
      "expression": "true",
      "description": "",
      "enabled": true,
      "action_parameters": {
        "id": "efb7b8c949ac4650a09736fc376e9aee",
        "overrides": {
          "rules": [
            {
              "id": "23ee7cebe6e8443e99ecf932ab579455",
              "action": "log",
              "enabled": false
            }
          ]
        }
      }
    }
  ]
}'
```
このAPIエンドポイントを呼び出した後、WAF管理ルールとWAF Managed Rulesの両方が有効になります。セキュリティイベントのActivity logを確認して、正当なトラフィックがブロックされていないかを確認し、WAF Managed Rules設定に必要な調整を行ってください。たとえば、単一のルールを無効にするか、アクションを変更するためにadd an overrideを行うことができます。

移行を完了し、WAF管理ルールを無効にするには、ステップ2で取得した設定を使用して新しいWAFの設定を行い、ステップ3で調整した可能性があります。waf_migration=pending&phase_two=1のクエリ文字列パラメータを含めることを確認してください。

curl --request PUT \
"https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_request_firewall_managed/entrypoint?waf_migration=pending&phase_two=1" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "name": "default",
  "rules": [
    {
      "id": "",
      "version": "",
      "action": "execute",
      "expression": "true",
      "description": "",
      "ref": "",
      "enabled": true,
      "action_parameters": {
        "id": "efb7b8c949ac4650a09736fc376e9aee",
        "overrides": {
          "rules": [
            {
              "id": "23ee7cebe6e8443e99ecf932ab579455",
              "action": "log",
              "enabled": false
            }
          ]
        }
      }
    }
  ]
}'

提供された設定が保存され、新しいWAF管理ルールが有効になると、以前のWAF管理ルールのバージョンは自動的に無効になります。これは、waf_migration=pending&phase_two=1パラメータが存在するためです。これにより、更新プロセス中にゾーンがWAFのいずれかのバージョンによって保護され続けることが保証されます。

セキュリティイベントにおける新しいWAFの動作の分析

エンタープライズ顧客向け

エンタープライズ顧客の場合、WAF移行プロセスの検証モードを使用して、新しいWAF管理ルール設定の動作を確認します。Cloudflareは、新しいWAF設定を展開した後に検証モードを有効にします。このモードでは、以前のWAFバージョンがまだ有効であるため、移行プロセス中に新しい設定の動作を検証できます。新しいWAF管理ルールは、以前のバージョンの前に実行されます。

検証モード中にセキュリティイベントのActivity logに移動し、以下を確認してください：

新しいWAFによって許可されたリクエストが以前のWAFバージョンによって処理されているかどうかを確認します（たとえば、チャレンジやブロックアクションによって）。この場合、以前に特定したリクエストを処理するためにfirewall ruleまたはWAF custom ruleを作成することを検討してください。
新しいWAFによってブロックされている正当なリクエストを探します。この場合、これらのリクエストをブロックしているWAF管理ルールを編集し、実行されるアクションを変更するか、ルールを無効にします。詳細については、Configure a managed rulesetを参照してください。

Business/Professional顧客向け

BusinessおよびProfessional顧客は検証モードにアクセスできないため、新しいWAFの動作を新しいWAF管理ルールに移行した後に確認できます。

移行後の日々に、セキュリティイベントのActivity logを確認し、WAF管理ルールによってブロックされている正当なリクエストを探します。誤ってブロックされたリクエストを特定した場合、対応するWAFルールのアクションをLogに調整します。管理ルールセットルールのアクションを変更する方法については、Configure a single rule in a managed rulesetを参照してください。

また、ブロックされるべきリクエストがあるかどうかも確認してください。この場合、これらのリクエストをブロックするためにfirewall ruleまたはWAF custom ruleを作成することを検討してください。

API操作

APIを介して新しいWAF管理ルールに更新するには、以下のAPI操作を呼び出す必要があります：

名前	メソッド + エンドポイント	説明
WAFの互換性を確認する更新	`GET` `/zones/<ZONE_ID>/waf_migration/check?phase_two=1`	現在の設定に基づいて、現在のゾーンが新しいWAFに更新できるかどうかを確認します。
新しいWAFの設定を取得する	`GET` `/zones/<ZONE_ID>/waf_migration/config?phase_two=1`	現在の設定（以前のバージョンのWAF管理ルール）に相当する新しいWAF管理ルールの設定を取得します。
ゾーンの更新エントリポイントルールセット	`PUT` `/zones/<ZONE_ID>/rulesets/` `phases/http_request_firewall_managed/entrypoint?waf_migration=<VALUE>&phase_two=1`	`http_request_firewall_managed`フェーズのゾーンエントリポイントルールセットの設定を更新します。 `waf_migration`クエリ文字列パラメータの利用可能な値： – `pending` / `1`: 新しいWAF管理ルールの設定を定義し、提供された設定が保存され、新しいWAFが有効化されると同時に以前のバージョンのWAF管理ルールを無効にします。 – `validation` / `2`: （エンタープライズゾーンのみ）新しいWAF管理ルールの設定を定義し、以前のバージョンと並行して新しいWAF管理ルールを有効にし、検証モードに入ります。検証モードを終了し、移行を完了するには、同じAPIエンドポイントを`waf_migration=pending`で呼び出します。
WAFのステータスを取得する	`GET` `/zones/<ZONE_ID>/waf_migration/status`	ゾーンの古いWAF管理ルールと新しいWAF管理ルールのステータス（有効/無効）を取得します。レスポンスには、現在の移行状態（またはモード）も含まれます。

上記のエンドポイントにCloudflare APIのベースURLを追加して、完全なエンドポイントを取得する必要があります：

https://api.cloudflare.com/client/v4

可能な移行エラー

以下のエラーについてはCloudflareサポートに連絡して支援を受けてください：

移行するファイアウォールルールの数が200を超えています。
ファイアウォールルールの式の長さが4 KBを超えています。

追加リソース

Cloudflare APIを使用して新しいWAF管理ルールを設定する

WAFパッケージ、ルールグループ、およびルールを管理するための以前のAPIを使用する代わりに、Rulesets APIを使用してプログラム的にWAF管理ルールを設定する必要があります。

デフォルトのWAF管理ルール設定の上に実行される変更を指定するためにオーバーライドを作成することもできます。これらの変更は、管理ルールセットのデフォルトの動作に優先します。

詳細については、以下のリソースを参照してください：

Terraformを使用して新しいWAF管理ルールを設定する

WAFパッケージ、ルールグループ、およびルールを管理するための以前のリソースを使用する代わりに、cloudflare_ruleset ↗ Terraformリソースを使用してWAF管理ルールを設定する必要があります。設定例については、WAF管理ルールを設定するを参照してください。

`cf-terraforming`を使用して設定を置き換える

移行後に新しいWAF管理ルール設定のTerraform構成を生成するためにcf-terraforming ↗ツールを使用できます。その後、新しいリソースをTerraformステートにインポートします。

古いWAF管理ルール設定を新しいWAF管理ルールのルールセットベースの設定に置き換えるための推奨手順は次のとおりです：

ゾーンのすべてのルールセット設定を生成するために次のコマンドを実行します：

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_managed"
  zone_id = "<ZONE_ID>"
  rules {
    [...]
  }
  [...]
}
[...]

前のコマンドは、Ruleset Engineに基づいて他のCloudflare製品のための追加のルールセット設定を返す場合があります。WAF管理ルール設定を探しているので、http_request_firewall_managedフェーズのTerraformリソースのみを保持し、それを.tf設定ファイルに保存します。次のステップで完全なリソース名が必要になります。
以前に特定したcloudflare_rulesetリソースをterraform importコマンドを使用してTerraformステートにインポートします。例えば：

terraform import cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31 zone/<ZONE_ID>/3c0b456bc2aa443089c5f40f45f51b31

 cloudflare_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によって管理されている他のリソースに加えて、例えば：

terraform plan

cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ステートを更新中... [id=3c0b456bc2aa443089c5f40f45f51b31]
[...]
cloudflare_waf_package.my_package: ステートを更新中... [id=14a2524fd75c419f8d273116815b6349]
cloudflare_waf_group.my_group: ステートを更新中... [id=0580eb5d92e344ddb2374979f74c3ddf]
[...]

Terraformステートから以前のバージョンのWAF管理ルールに関連するすべてのステートを削除します：

問題を防ぐために、.tf設定ファイルから設定を削除する前に、TerraformステートからWAFパッケージ、グループ、およびルールを削除する必要があります。
1. 次のコマンドを実行して、以前のバージョンのWAF管理ルールに関連するすべてのリソースを見つけます：
  Terminal window
```
terraform state list | grep -E '^cloudflare_waf_(package|group|rule)\.'
```
```
cloudflare_waf_package.my_package
cloudflare_waf_group.my_group
```
2. 影響を理解するために、terraform state rm ...コマンドをドライランモードで実行して、リソースを削除することによる影響を確認します：
  Terminal window
```
terraform state rm -dry-run cloudflare_waf_package.my_package cloudflare_waf_group.my_group
```
```
cloudflare_waf_package.my_packageを削除します
cloudflare_waf_group.my_groupを削除します
```
3. 影響が正しい場合、-dry-runパラメータなしで同じコマンドを実行して、実際にリソースをTerraformステートから削除します：
  Terminal window
```
terraform state rm cloudflare_waf_package.my_package cloudflare_waf_group.my_group
```
```
cloudflare_waf_package.my_packageを削除しました
cloudflare_waf_group.my_groupを削除しました
2つのリソースインスタンスを正常に削除しました。
```
TerraformステートからWAFパッケージ、グループ、およびルールリソースを削除した後、.tf設定ファイルからcloudflare_waf_package、cloudflare_waf_group、およびcloudflare_waf_ruleリソースを削除します。

terraform planを実行して、設定ファイルから削除したリソースがもはや表示されないことを確認します。保留中の変更がないはずです。

terraform plan

cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: ステートを更新中... [id=3c0b456bc2aa443089c5f40f45f51b31]
[...]

変更はありません。あなたのインフラストラクチャは設定と一致しています。

Terraformはあなたの実際のインフラストラクチャを設定と比較し、違いがないことを確認したので、変更は必要ありません。

CloudflareリソースをTerraformにインポートし、cf-terraformingツールを使用する詳細については、以下のリソースを参照してください：

最後の注意事項

パラノイアレベルの概念は、WAF管理ルールで使用されているOWASPバージョン（2.x）には存在しませんでした。OWASPガイドの推奨に基づいて、WAF移行プロセスはCloudflare OWASPコアルールセットのパラノイアレベルを_PL2_に設定します。

ページルールを使用して新しいWAF管理ルールのバージョンを無効にすることはできません。ページルールの_WAF: Off_設定は、以前のバージョンのWAF管理ルールにのみ適用されます。新しいWAF管理ルールを無効にするには、例外（スキップルールとも呼ばれます）を設定する必要があります。

Cloudflare Dashboard Discord Community Learning Center Support Portal

Cookie Settings