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.栗島