概要

Cloud ArmorはDDoS攻撃やXSS、SQLインジェクションなどからアプリケーションを保護するためのサービス。構成済みのルール（XSSやインジェクションなど）と手動で構成するルール（IPアドレスのホワイトルール、その他リクエストの属性に基づく許可・拒否ルール）がある。

Cloud Armorは外部HTTP(S)ロードバランサにのみアタッチできる。ロードバランサのバックエンドは以下のいずれかを使用できる。

インスタンスグループ
ゾーンNEG
サーバーレスNEG
インターネットNEG
GCSバケット

セキュリティポリシー

セキュリティポリシーにはバックエンドセキュリティポリシーとエッジセキュリティポリシーの2種類がある。エッジセキュリティーポリシーは現在(2021/8/10）プレビュー版になっている。バックエンドセキュリティポリシーはロードバランサのバックエンドに対して適用されるポリシーで、エッジセキュリティポリシーはCDNによってキャッシュされているコンテンツへのトラフィックに適用されるポリシーになっている。以前はキャッシュにヒットしたリクエストにはポリシーが適用されてなかったっぽい。

事前構成済みの保護の構成

事前構成済みの保護は主にOWASP TOP10を含んだ広範囲の攻撃を防御するためのものになっている。
以下は事前に防御されるルールのリスト。XSSやSQLインジェクションなどが防御される項目として定義されている。

だがこれだけだと、どのような条件でブロックされるかがわからないと思うので、より詳細にルールを定義しているリポジトリも公開されている。ただ、少し読んでみたけど全くわからなかった。リポジトリはルールのソースだが、Google Cloudのドキュメントにもうまくまとめられているので、こちらも参照してほしい。

事前構成済みのルールが必要なリクエストをブロックしている場合は、evaluatePreconfigureExprコマンドを使用して特定のCRS(Core Rules Set)を除外することができる。(CRSは上のリポジトリに乗っている）

カスタムルールの作成

カスタムルールを構成すると、一致条件とそのアクションを定義することで特定の受信リクエストを許可・拒否できる。
一致条件には以下の条件が使用できる。式の評価はCEL（Common Expression Language）の拡張版によって記述される。
https://github.com/google/cel-spec

基本一致条件：IPアドレスの範囲のリストで構成される
詳細一致条件：受信リクエストの属性に基づいて構成できる。

詳細一致条件に使用できる属性は以下の通り。

例えば、inIpRange(origin.ip, "9.9.9.0/24") という値を使用すると、送信元IPアドレスが9.9.9.0/24以内であれば式はtrueを返す。式の例がドキュメントに記載されているので、ここを読めばイメージがつくと思う。ドキュメントを読めばわかるが、正規表現や簡単な関数（デコードの処理）なども使用できて、結構柔軟に設定できることがわかる。
https://cloud.google.com/armor/docs/rules-language-reference?hl=ja#expression-examples

名前付きIPアドレスのリスト

サードパーティプロバイダが管理しているIPアドレスのリストを使用して、一括で複数のIPアドレスを許可・拒否することができる。ユースケースとしては、特定のプロバイダ経由のみのトラフィックを許可したい場合。これのメリットとしては、、Cloud Armorは自動的にリストを毎日同期すことにあるる。プロバイダがIPアドレスのリストを変更したとしても、手動で変更する必要がなくなる。