問題タブ [google-cloud-armor]

https://cloud.google.com/armor/docs/rules-language-referenceを参照して Google Cloud Armor セキュリティ ポリシーを設定しました。うまくいきました。オフィスからのシミュレートされた SQL インジェクション攻撃が検出され、その後のアクセスがブロックされました。Stackdriver のログ エントリは、対応する enforcedSecurityPolicy の結果が「deny」で、適用された式 ID が「owasp-crs-v030001-id942421-sqli」であることを示しています。主な WAF ルールは次のとおりです。

evaluatePreconfiguredExpr('xss-stable') && evaluatePreconfiguredExpr('sqli-stable')

コントロールできないワンポイント。私の模擬攻撃の後、私のオフィスからのすべてのアクセスはずっとブロックされています。クラウド アーマー セキュリティ ポリシーを LB との間で切り離して再付加した後も、オフィスからのアクセスはブロックされたままです。そのセキュリティ ポリシーを削除して、再度作成しても役に立ちません。これは、目に見えない SQLi および XSS 攻撃者の永続的なデータベースがあり、私のオフィスの IP がそこに登録されている可能性があることを意味し、「常に」拒否を引き起こします。

質問: 目に見えない「SQLi & XSS ブラックリスト」データベースから IP を削除して、ルールを変更せずにバックエンド アクセスを取り戻すにはどうすればよいですか? Cloud Armor の本番運用では、一度禁止された IP は、攻撃元が削除された後、ターゲット バックエンド サービスへのアクセスを回復する必要がある場合があります。

確かに、WAF ルールよりも優先度の高いパーミッション ルールを追加すると、対象のバックエンドへのアクセスを取り戻すことができますが、WAF チェックがバイパスされてしまい、これは望ましくありません。

よろしくお願いいたします。

R.栗島

Cloud Armor WAF ですべてのルールの詳細を探していました。ハンドブック（有料）とすべてのルールのコード正規表現を見つけました。すべてのルールの説明の詳細はまだ見つかりませんでした。これに関する公式ドキュメントはありますか？

イングレスに L7 Google LB を使用しており、特定の IP のみを許可する cloudarmor ポリシーを使用するように接続しています。

DDoS 防御をセットアップしたいのですが、ドキュメントがわかりにくい

Google Cloud Armor セキュリティ ポリシーは、外部 HTTP(S) ロードバランサの背後にあるバックエンド サービスでのみ使用できます。ロード バランサーは、プレミアム ティアまたはスタンダード ティアに配置できます。DDoS 保護は、HTTP(S) 負荷分散、SSL プロキシ負荷分散、および TCP プロキシ負荷分散に対して自動的に提供されます。

これは、クラウド アーマー ポリシーを (空の場合でも) gke L7 LB イングレスに適用するだけで、DDoS が発生するということですか? それとも、すべての L7 LB には DDoS が既に搭載されており、cloudarmor で何もする必要がないということですか。