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 などの攻撃を緩和する事前構成ルールを呼び出すことができるため、複雑なシグネチャを自前で書く必要はありません。

なお OWASP Top 10 とは、米国の非営利団体である Open Worldwide Application Security Project（OWASP）が定期的に公開している、Web アプリケーションに関する重大なリスクのランキングです。Web アプリのセキュリティリスクを評価する際に、広く参照されています。

参考 : OWASP Top Ten

料金ティア（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
Regional internal Application Load Balancer

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

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

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

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

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

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

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

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

参考 : セキュリティポリシーの種類

ルールとは

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

ルールには、基本モードと詳細モードの2つのモードがあります。

モード名	概要
基本モード	IP アドレスに基づいてトラフィックを許可または拒否
詳細モード	Common Expression Language（CEL）で記述したカスタムルールに基づいてトラフィックを許可または拒否

IP アドレスによる制限であれば基本モードのルールを、SQL インジェクションなどの L7 攻撃を防ぐには詳細モードのルールを作成します。

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

また詳細モードのルールでは、IP アドレスから推測する地理的情報や、bot を防ぐためのルール、レート制限など、多様なルールが定義可能です。

参考 : セキュリティポリシーのルールを管理する
参考 : ルールの種類

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

参考 : GitHub - coreruleset

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

ルールはプレビューモードにすることができ、実際にトラフィックを拒否せずに、ログの記録だけをさせることもできます。一般的にドライランやロギングモードと呼ばれる機能です。

参考 : プレビューモード

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

名前付き IP アドレスリストとは、サードパーティの CDN (Contents Delivery Network) プロバイダが管理する IP アドレスのリストです。2025年3月現在では Fastly、CloudFlare、Imperva が名前付き IP アドレスリストを提供しています。

これらの CDN を利用している場合は、セキュリティポリシーにて名前付き IP アドレスリストを許可対象として指定し、その他をブロックすることで、 CDN 以外からのアクセスをブロックすることができます。

ただし、名前付き IP アドレスリストは通常版（Standard）では使用できません。追加料金を支払い、Cloud Armor Enterprise ティアに登録する必要があります。

参考 : 名前付き IP アドレスリストの可用性
参考 : IP アドレスリストプロバイダ

ルールの記述

詳細モードのルールでは前述の通り、カスタムルール言語を使ってルールを記述する必要があります。この言語を使って、 Google の事前構成 WAF ルール（または事前構成されたルール、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')

事前構成 WAF ルールの一覧や設定方法は、以下のドキュメントを参照してください。

参考 : Google Cloud Armor の事前構成 WAF ルールの概要
参考 : 事前構成された WAF ルールを設定する
参考 : 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 の概要

DDoS 対応サポート

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

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

参考 : DDoS 対応サポート

DDoS 請求保護

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

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

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

参考 : DDoS 請求対策

Adaptive Protection（適応型保護）

Adaptive Protection とは

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

Adaptive Protection のフル機能を利用するためには Cloud Armor Enterprise に登録する必要があります。一方の Standard だと、アラートの一部（基本アラート）のみを受け取ることができます。基本アラートには、攻撃シグネチャや推奨ルールが含まれません。

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

参考 : Google Cloud Armor 適応型保護の概要

アラート

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 Application Load balancers に限り、Cloud Logging ログと Cloud Monitoring メトリクスにおいて DDoS 保護機能によりブロックされたトラフィックを確認することができます。

参考 : DDoS 攻撃の可視性テレメトリーにアクセスする

レート制限

Cloud Armor にはレート制限機能があります。この機能では、少数のクライアントからの大量アクセスを検知して、スロットル（アクセス数の上限）をかけたり、そのクライアントを Ban（禁止）することができます。

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

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

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

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

Bot 管理

Cloud Armor では、reCAPTCHA Enterprise との統合により、bot 対策が可能です。

トラフィックを reCAPTCHA の確認画面（私はロボットではありません など）へリダイレクトするなどして bot からのアクセスを拒否することができます。

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

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

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

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

参考 : reCAPTCHA の概要
参考 : reCAPTCHA の料金

運用・ロギング

WAF の運用作業

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

誤検知（偽陽性）への対応
新たに見つかった脆弱性への対応

誤検知（偽陽性）への対応とは、Web アプリケーションの仕様変更や、ルールのシグネチャの更新等をきっかけとして、正当なトラフィックが不正アクセスとして WAF にブロックされてしまうようなときに、明示的にトラフィックを許可したり、誤検知しているルールを無効化したりする作業です。

トラフィックがブロックされた場合は、Cloud Logging のログを確認して、原因となったトラフィックやシグネチャを確認して対応を検討します。

後者の新たに見つかった脆弱性への対応では、日頃から脆弱性に関する情報収集を適切に行い、ルールを管理していきます。Google の事前構成ルールを使用していれば、基本的にはルールが自動的に更新されていきます。しかし、ニュースとなるような深刻な脆弱性が発生した直後には、手動でルールを追加する必要性が出てくるかもしれません。

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