G-genの杉村です。Google Cloud（旧称 GCP）のクラウド型 WAF である Google Cloud Armor について、概要や特徴を記載します。

Cloud Armor とは

Cloud Armor の概要

Google Cloud Armor（以下、Cloud Armor）はクラウド型の Web Application Firewall（以下、WAF）であり、フルマネージドサービスです。

WAF とは Web アプリケーションに対する SQL インジェクション、クロスサイトスクリプティングといったアプリケーションレイヤの攻撃を検知し、防御するための仕組みです。加えて、Cloud Armor には DDoS 攻撃への防御機能も持っています。

ただし Cloud Armor は Google Cloud のロードバランサーである Cloud Load Balancing の背後にある Web アプリケーションのみを保護できます。対応しているロードバランサーの種類は後述します。また、一定の制限のもとであればパブリック IP を持っている VM に直接ルールをアタッチすることもできます（ネットワークエッジセキュリティポリシー）。こちらについても後述します。

参考 : Google Cloud Armor の概要

WAF 機能

Cloud Armor の最も基本的な機能は「セキュリティポリシー」を設定することで、Web アプリケーションをアプリケーションレイヤ（L7）の攻撃から保護することです。

WAF ルールは Common Expression Language (CEL) と呼ばれるカスタムルール言語で記述します。

簡単な記述で OWASP Top 10 などの攻撃を緩和する事前構成ルールを呼び出すことができるため、複雑なシグネチャを自前で書く必要はありません。

料金ティア（Standard / Enterprise）

Cloud Armor には Cloud Armor Standard と Cloud Armor Enterprise の2つの料金ティアがあります（Enterprise は以前は Managed Protection Plus と呼ばれていましたが、2024年4月に改称しました）。

Standard ティアでは通常の WAF の機能であるアプリケーションレイヤ（レイヤ 7）へのルールベースの防御機能に加え、一部の Cloud Load Balancing に対する DDoS 攻撃への防御機能を備えています。

Enterprise ティアでは Standard ティアの機能に加えて、以下のような機能を備えています。

Google が管理するサードパーティの IP アドレスリスト
Google が管理する Threat Intelligence（脅威情報）による防御機能
Adaptive Protection（適応型防御。機械学習を活用した脅威検知）
追加の DDoS 防御機能

詳細については、以下の公式ドキュメントも参考にしてください。

参考 : Cloud Armor Enterprise overview

セキュリティポリシー

セキュリティポリシーとは

Cloud Armor のセキュリティポリシーとは、防御ルールの定義のことです。

セキュリティポリシーを作成して、外部 HTTP(S) ロードバランサのバックエンドサービスにアタッチすることで、ルールが効果を発揮します。

セキュリティポリシーごとに以下のような設定値を持ちます。

個別ルール (IPアドレス範囲リスト / カスタムルール言語)
デフォルトアクション (拒否 / 許可)
Adaptive Protection の有効 / 無効
アタッチ先のバックエンドサービス

セキュリティポリシーをアタッチできる対象

セキュリティポリシーは、ロードバランサー（Cloud Load Balancing）を使っている VM 等を保護対象にすることができます。

後述するようにセキュリティポリシーには3種類ありますが、それぞれポリシーをアタッチ可能な対象は以下の通りです (参考)。

バックエンドセキュリティポリシー
- Global external Application Load Balancer
- Classic Application Load Balancer
- Global external proxy Network Load Balancer
- Classic proxy Network Load Balancer
- Regional external Application Load Balancer
エッジセキュリティポリシー
- Global external Application Load Balancer
- Classic Application Load Balancer
ネットワークエッジセキュリティポリシー
- External passthrough Network Load Balancer
- Protocol forwarding
- パブリック IP を持った VM

3種類のセキュリティポリシー

セキュリティポリシーには以下の3種類があります。

バックエンドセキュリティポリシー
エッジセキュリティポリシー
ネットワークエッジセキュリティポリシー

バックエンドセキュリティポリシーは、エッジロケーション (Google のキャッシュサーバー) からバックエンドにルーティングされたリクエストを評価します。つまり、キャッシュヒットしなかったリクエストや動的コンテンツなどが対象です。エッジからキャッシュで返されるリクエストは評価対象になりません。

エッジセキュリティポリシーは、エッジからキャッシュを返す前に評価され、ルールが適用されます。Cloud CDN を有効化したバックエンドや Cloud Storage バケットが対象となります。

ネットワークエッジセキュリティポリシーは、ロードバランサーを使わない VM にも利用可能なポリシーです。接続元 IP アドレスなどによる制限をかけ、Google のネットワークのエッジでブロックすることができます。これにより不正アクセスや DDoS が VM のネットワークリソースを消費することを防ぐことができます。

これら3つのポリシーは併用することも可能です。

またそれぞれのポリシーで利用可能な機能が異なっています。詳細は公式ガイドをご参照ください。

参考 : Types of security policies

ルールとは

複数の ルール を、セキュリティポリシー内に作成できます。
ルールは優先度順に評価され、ルールに合致するとそれより低い優先度のルールは評価されません。

ルールは IP アドレスで許可 / 拒否を評価する 基本モード とCommon Expression Language (CEL) をベースとしたカスタムルール言語で記述する 詳細モード があります。
単純な IP アドレスによる制限であれば基本モードのルールを、 SQL インジェクションなどの L7 攻撃を防ぐには詳細モードのルールを作成します。

詳細モードのルールではカスタムルール言語を使って記述する必要がありますが、 Google が作成する 事前構成されたルール (Preconfigured rules) を呼び出すことで、簡単な記述で防御ルールを作成することができます。

Google 事前構成ルールはオープンソースの ModSecurity Core Rule Set が元になっています。

ルールのプレビューモード

ルールは プレビュー モードにすることができ、実際のアクション (拒否 /許可) を行わずに記録だけをさせることもできます。一般的にドライランやロギングモードと呼ばれる機能です。

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

名前付き IP アドレスリストとは、サードパーティの CDN (Contents Delivery Network) プロバイダが管理する IP アドレスのリストです。
2021 年 12 月現在では Fastly, CloudFlare, Imperva が名前付き IP アドレスリストを提供しています。
これらの CDN を利用している場合は、セキュリティポリシーにて名前付き IP アドレスリストを許可対象として指定し、その他をブロックすることで、 CDN 以外からのアクセスをブロックすることができます。

ただし、名前付き IP アドレスリストは通常版 (Standard) では使用できません。追加料金を支払い Managed Protection Plus サブスクリプションに登録する必要があります。

ルール記述方法

詳細モードのルールでは前述の通り、カスタムルール言語を使ってルールを記述する必要があります。
この言語を使って、 Google の 事前構成されたルール (Preconfigured rules) を呼び出すのが基本的な使い方となります。

以下は、最も簡単な例です。 SQL インジェクションを防ぐ事前構成ルールを呼んでいます。

evaluatePreconfiguredExpr('sqli-stable')

ただし、この書き方だと、事前構成ルール sqli-stable に含まれている全ての SQL インジェクション対策のシグネチャが反応してしまいます。
偽陽性 (本当は正しいリクエストなのに、不正リクエストとして検知されてしまうこと) が起こりやすい状態です。
偽陽性の可能性を下げるために、感度レベルの高いシグネチャを無効化するよう指定することができます。

# ルール名の後に無効化するシグネチャ名を入力
evaluatePreconfiguredExpr('sqli-stable', ['owasp-crs-v030001-id942421-sqli', 'owasp-crs-v030001-id942432-sqli'])

また || (パイプ×2)を使ってルールをOR条件で繋げることができます。
以下のようにルールを数珠つなぎにしてアクションを ブロック にすれば、1つのルールの中で複数の事前構成ルールを呼び出すことができます。

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

どの攻撃に対してどのルールを追加しなければいけないのか、また感度レベル別のシグネチャ名などは、以下のドキュメントを参照してください。

参考 : Google Cloud Armor WAF ルールのチューニング

DDoS 対策

DDoS 保護機能

Cloud Armor には DDoS 保護機能が備わっています。Standard ティアと Enterprise ティアの両方で DDoS 対策機能が利用可能ですが、Enterprise ティアではより保護範囲が広くなり、また Adaptive Protection (適応型保護) などの機能が提供されます。

各ティアの DDoS 対策の範囲は以下のとおりです。

Standard	Enterprise
・External Application Load Balancer ・External proxy Network Load Balancer	・External Application Load Balancer ・External proxy Network Load Balancer ・External passthrough Network Load Balancer ・Protocol forwarding ・Public IP addresses (VMs)

参考 : Cloud Armor Enterprise overview

DDoS 対応サポート

Cloud Armor Enterprise の年間サブスクリプションへの登録に加え、Google Cloud カスタマーケアのプレミアムにも登録している場合、 DDoS 対応サポート（DDoS response support）を利用することができます。

DDoS 対応サポートでは Google の DDoS 対策チームと連絡を取り、支援を受けることができます。

参考 : DDoS response support

DDoS 請求保護

Cloud Armor Enterprise の年間サブスクリプションへ登録している場合、DDoS 請求保護（DDoS bill protection）を受けることができます。

万が一、 Web アプリケーションが DDoS 攻撃を受けてしまい、多大なトラフィックが発生してしまった影響で Cloud Load Balancing、Google Cloud Armor、ネットワーク下りトラフィックなどに大量の課金が発生してしまった場合、 Google に申請することで該当の利用料金に充当できるクレジットを受けられる場合があります。

詳細は以下を確認してください。

参考 : DDoS bill protection

Adaptive Protection（適応型保護）

Adaptive Protection とは

Adaptive Protection（適応型保護）とは、HTTP Flood などのレイヤ 7 の DDoS 攻撃と思われる怪しい挙動を検知し、機械学習モデルによってアラートを出したり、防御のためのシグネチャを自動生成する機能です。

Adaptive Protection のフル機能を利用するためには Cloud Armor Enterprise に登録する必要があります。一方の Standard だと、アラートの一部（basic alert）のみを受け取ることができます。

Adaptive Protection はセキュリティポリシー単位で有効化できます。有効化後、機械学習によってベースラインが確立され、アラート生成ができるようになるまで最低でも 1 時間のトレーニングが必要とされています。

参考 : Google Cloud Armor Adaptive Protection overview

アラート

Adaptive Protection では、一定の学習期間中にトラフィックパターンが学習されます。学習後に高頻度または大容量の異常トラフィックが検出されると、 Cloud Logging にアラートが生成されるようになります。

アラートには 信頼度レベル , 攻撃シグネチャ , 推奨ルール , ベースラインのうち影響を受ける割合の予測値 が含まれます。

信頼度レベル とは、機械学習モデルが予測した結果の確からしさ (確率。 0 〜 1 の数値) です。

ベースラインのうち影響を受ける割合の予測値 とは、自動生成されるルールが実際に適用された場合にベースラインのうちどれくらいの割合のトラフィックが影響を受けるか、という予測値です。

自動生成ルールの適用

自動生成ルールを適用するには以下の 2 つの方法があります。

Cloud Logging に出力されたアラートにルール名が出るので、それを使ってセキュリティポリシーにルールを書く (CEL の記述)
コンソール画面の Adaptive Protection ダッシュボードから GUI で適用する (自動適用)

このように簡単にルールを適用することができますが、実際にはプレビューモードで試運転することが推奨されます。プレビュー期間を設けずに実稼働させると、正しいトラフィックにまで予想外の影響が出る（偽陽性）可能性があるためです。

参考 : 推奨ルールのデプロイ
参考 : 推奨ルールを自動でデプロイする

DDoS 攻撃の可視化

Cloud Armor の Enterprise ティアに登録すると、Cloud Logging と Cloud Monitoring を使い、DDoS 攻撃の状況を可視化することができます。

通常ですと、Cloud Armor の DDoS 保護はセキュリティポリシー適用前に行われてしまうため、DDoS 攻撃の状況はログやメトリクスに残りません。しかし Enterprise ティアに登録していると、Global external HTTP(S) load balancer に限り Cloud Logging ログと Cloud Monitoring メトリクスにおいて DDoS 保護機能によりブロックされたトラフィックを確認することができます。

参考 : Access DDoS attack visibility telemetry

レート制限

Cloud Armor には レート制限機能 があります。

この機能では、少数のクライアントからの大量アクセスを検知して、 スロットル (アクセス数上限) をかけたり、そのクライアントを Ban (禁止) したりできます。

例えば、 20 分間で 2000 リクエスト という上限をルールに設定し、それを超えた場合はアクセス数を制限したり、あるいはそのクライアントを指定した秒数の間、アクセス禁止にすることができます。

「IP アドレス」「HTTP ヘッダ」「Cookie」「リクエストのパス」などの属性のうちから1〜3個までを組み合わせて、それらのキーが一致するリクエストを合算してレート制限をかけることができます。

ルールの作成方法等は以下ドキュメントを参照してください。

参考 : レート制限の概要
参考 : レート制限ルールの構成

Bot 管理

reCAPTCHA Enterprise との統合により bot 対策ができる機能があります。

トラフィックを reCAPTCHA の確認画面 (私はロボットではありません など) へリダイレクトするなどして bot を弾くことができます。

アプリケーションのフロントエンドに Javascript で reCAPTCHA のコードを埋め込むことで、アプリへのリクエストにトークンを埋め込み、Cloud Armor がそのトークンをチェックしてリスク評価を行う「フリクションレス評価」と呼ばれる手法も実装可能です。

詳細は、以下を参照してください。

参考 : Google Cloud Armor bot 管理の概要

なお reCAPTCHA Enterprise は Cloud Armor とは別サービスであり、別途費用が発生することに留意してください。

運用・ロギング

WAF の運用作業

Cloud Armor に限らず、 WAF 製品には運用が必要です。
例として、以下のような作業があるでしょう。

誤検知 (偽陽性) 対応
新たに見つかった脆弱性の対応

前者は、例えば Web アプリケーションの仕様変更により、これまで引っかからなかったトラフィックが不正アクセスとして WAF にブロックされてしまうようなときに、明示的に許可したり誤検知しているルールを無効化したりする作業です。
ブロックされた場合は Cloud Logging に DENY された旨と、その原因になったシグネチャが記録されますので、それを確認します。

また後者では、脆弱性に関する情報収集を適切に行い、ルールを管理していきます。
事前構成ルールを使用していれば基本的にはルールが自動的に更新されていきます。
しかし、世の中を揺るがすような深刻な脆弱性が発生した際には、手動でルールを追加する必要性が出てくるかもしれません。

例として 2021 年 12 月には、広く利用されている Java 用のログ出力ライブラリである log4j の脆弱性が見つかり、各社は対応に追われました。
そのときには Google が新しい事前構成ルール cve-canary を迅速に開発・アップデートしたため、対策を行うことができました。
その際の対応方法は、以下のブログ投稿をご参照ください。

medium.com

Cloud Armor のログ出力

WAF のブロックログを見るためには Cloud Load Balancing 側でログを有効化 する必要がある点に注意してください。
デフォルトで Cloud Armor 自体の監査ログは出力されます。しかし、これにはセキュリティポリシーの設定変更など管理的なログが記録されるだけで、 トラフィックがブロックされた場合のログなどは出力されません 。

実際の攻撃に対する対処や、誤検知 (偽陽性) 対応などを行うためにも、 WAF のログ出力は必須と言っていいでしょう。
これにはロードバランサー側のログを有効化する必要がある、ということを覚えておきましょう。