G-gen の武井です。当記事では、Google Cloud の WAF サービスである Cloud Armor のベストプラクティスを整理します。 はじめに 前提知識 WAF の基本用語 事前構成 WAF ルール SQL インジェクション クロスサイトスクリプティング Cloud Armor の基本 Cloud Armor の仕組み セキュリティポリシーの種類 ルールの種類 Cloud NGFW との役割分担 ベストプラクティスの全体像 セキュリティポリシーとルールの作成 ルールの評価順を設計する プレビューモードで検証する Adaptive Protection を有効にする レート制限を設定する 優先度の間隔とルールの説明 JSON の解析と Bot 管理 ルールのチューニング 感度レベルを選ぶ 詳細ログを使う stable と canary を使い分ける ロギングとモニタリング ログを有効にする Security Command Center と Cloud Monitoring 全般的な管理 IAM でアクセスを制御する ポリシーの利活用 GKE での構成 導入の進め方 確認ポイント ロードマップ ティアと料金 はじめに Cloud Armor は、Google Cloud が提供する Web Application Firewall（以下、WAF）と DDoS 対策のサービスです。ロードバランサが受けたリクエストを検査し、Web アプリケーションへの攻撃や DDoS 攻撃を防ぎます。 2026年10月現在、公式ドキュメントでは20項目のベストプラクティスが公開されています。当記事では、これらを Cloud Armor の導入から運用までの流れに沿って整理し、項目ごとに設定の考え方を解説します。あわせて、前提となる WAF の用語、Cloud Next Generation Firewall（以下、Cloud NGFW）との役割分担、導入の進め方、料金の目安も説明します。 Cloud Armor については、以下の記事も参照してください。 blog.g-gen.co.jp 前提知識 WAF の基本用語 WAF は、Web アプリケーションへのリクエストの中身を検査し、攻撃と判断したリクエストを遮断する仕組みです。一般的なファイアウォールが IP アドレスやポート番号で通信を制御するのに対し、WAF はリクエストのパス、ヘッダー、ボディに含まれる文字列まで見て判断します。 Cloud Armor の WAF 機能を理解するには、以下の用語を知っておく必要があります。 用語 意味 Cloud Armor との関係 OWASP Web アプリケーションのセキュリティ向上に取り組む非営利団体（Open Worldwide Application Security Project） 以下の OWASP Top 10 や CRS を公開している OWASP Top 10 Web アプリケーションの重大なセキュリティリスクを 10 項目にまとめたもの。数年ごとに改訂され、2026年10月現在の最新版は 2025 年版 事前構成 WAF ルールは、OWASP Top 10 のリスクへの対策として提供されている OWASP CRS OWASP ModSecurity Core Rule Set の略。オープンソースの WAF 用の攻撃検知ルール集 事前構成 WAF ルールの元になっている。2026年10月現在、Cloud Armor ではバージョン 4.22 の使用が推奨されている パラノイアレベル CRS の検知の厳しさを表す段階。レベルが高いほど検知の範囲が広がり、誤検知も増える Cloud Armor の「感度」に対応する 参考 : OWASP Top 10:2025 参考 : OWASP CRS 事前構成 WAF ルール 事前構成 WAF ルールは、CRS のシグネチャ（攻撃を見分けるためのパターン）を攻撃の種類ごとにまとめたものです。CRS 4.22 では、以下の 12 種類のルールが用意されています。 ルール名 検知する攻撃 sqli-v422 SQL インジェクション （入力値に SQL 文を混ぜて、データベースを不正に操作する攻撃） xss-v422 クロスサイトスクリプティング （Web ページに悪意のあるスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃） lfi-v422 ローカルファイルインクルード （サーバー上のファイルを不正に読み込ませる攻撃） rfi-v422 リモートファイルインクルード （外部のファイルを読み込ませて実行させる攻撃） rce-v422 リモートコード実行 （サーバー上で任意のコマンドを実行させる攻撃） methodenforcement-v422 許可されていない HTTP メソッドの使用 scannerdetection-v422 脆弱性スキャナなどの自動化ツールからのアクセス protocolattack-v422 HTTP の仕様を悪用する攻撃 php-v422 PHP のアプリケーションを狙うインジェクション攻撃 sessionfixation-v422 セッション固定 （攻撃者が用意したセッション ID を使わせる攻撃） java-v422 Java のアプリケーションを狙う攻撃 generic-v422 上記に分類されない汎用的な攻撃 実際にセキュリティポリシーで指定するときは、ルール名の末尾に -stable または -canary を付けます（例 : sqli-v422-stable ）。詳しくは後述しますが、stable は動作が安定したシグネチャで構成された版で、canary は新しいシグネチャが先に反映される版です。 このほか、特定の脆弱性を狙う攻撃を検知するルールとして、以下の 2 つがあります。どちらもすべての Cloud Armor ユーザーが使用できます。 ルール名 対象の脆弱性 cve-canary Log4j と React のリモートコード実行の脆弱性 json-sqli-canary JSON 形式のリクエストで SQL インジェクションの検知をすり抜ける脆弱性 以下では、代表的な攻撃である SQL インジェクションとクロスサイトスクリプティングについて、仕組みと Cloud Armor での対策を説明します。 参考 : Preconfigured WAF rules overview SQL インジェクション SQL インジェクション （以下、SQLi）は、フォームや URL のパラメータに SQL 文の一部を混ぜて送り、アプリケーションが組み立てる SQL 文を不正に書き換える攻撃です。入力値をそのまま SQL 文に連結しているアプリケーションが狙われます。 たとえば、ログイン画面で入力された ID とパスワードを、アプリケーションが以下のように SQL 文へそのまま連結しているとします。 SELECT * FROM users WHERE id = ' （入力された ID） ' AND password = ' （入力されたパスワード） ' ; ID に yamada を入力した場合に、パスワード欄への入力で SQL 文の条件がどう変わるかを比較します。 パスワード 組み立てられる SQL 文の条件 結果 通常 pass1234 id = 'yamada' AND password = 'pass1234' パスワードが正しい場合だけログインできる 攻撃 ' OR '1'='1 id = 'yamada' AND password = '' OR '1'='1' '1'='1' は常に成り立つため、条件全体が真になる 攻撃の例では、入力値の先頭の引用符（'）でパスワードの値が閉じられ、その後ろの OR '1'='1' が条件として扱われます。 '1'='1' （1 と 1 は等しい）は常に真で、 OR はどちらかが真なら全体が真になるため、パスワードが一致したかどうかは関係なくなります。その結果、攻撃者は正しいパスワードを知らなくてもログインできてしまいます。 攻撃が成功すると、データベースの情報の窃取、データの改ざんや削除、認証の回避が起こり得ます。データベースの種類によっては、サーバーの OS コマンドを実行される場合もあります。 Cloud Armor では、事前構成 WAF ルールの sqli-v422-stable で SQLi を検知します。このルールには 60 個のシグネチャがあり、感度ごとの内訳は以下のとおりです。 感度 1 2 3 4 合計 シグネチャ数 20 31 7 2 60 感度 3 と 4 には、リクエストの引数に含まれる特殊文字の数が一定数を超えると検知するシグネチャがあります。感度 4 では特殊文字が 2 個を超えるだけで一致するため、通常の入力値でも誤検知が起きやすくなります。 参考 : SQL Injection - OWASP 参考 : SQL injection (SQLi) クロスサイトスクリプティング クロスサイトスクリプティング （以下、XSS）は、信頼されている Web サイトに悪意のあるスクリプトを埋め込み、他の利用者のブラウザで実行させる攻撃です。入力値を検証やエンコードをせずにページへ出力しているアプリケーションが狙われます。 XSS には、リクエストに含まれるスクリプトがそのままレスポンスに返される反射型、掲示板の投稿などとしてサーバーに保存される格納型、ブラウザ上の JavaScript の処理で発生する DOM ベースの 3 種類があります。 格納型を例にすると、攻撃の流れは以下のとおりです。 攻撃が成功すると、図のようなセッション Cookie の窃取によるアカウントの乗っ取りのほか、偽サイトへの誘導やページの改ざんが起こり得ます。 Cloud Armor では、事前構成 WAF ルールの xss-v422-stable で XSS を検知します。図の例では、1 の投稿がロードバランサで検査され、XSS のシグネチャに一致すれば掲示板に届く前に遮断されます。このルールには 33 個のシグネチャがあり、感度ごとの内訳は以下のとおりです。SQLi と異なり、感度 3 と 4 のシグネチャはありません。そのため、感度を 2〜4 のどれに設定しても、評価されるシグネチャは同じ 33 個です。 感度 1 2 3 4 合計 シグネチャ数 25 8 0 0 33 SQLi と XSS のどちらについても、WAF は防御の層を 1 つ増やすものであり、アプリケーション側の対策の代わりにはなりません。WAF のシグネチャをすり抜ける攻撃もあるため、アプリケーション側の対策と組み合わせて使用します。 参考 : Cross Site Scripting (XSS) - OWASP 参考 : Cross-site scripting (XSS) Cloud Armor の基本 Cloud Armor の仕組み Cloud Armor では、防御ルールの集合を セキュリティポリシー と呼びます。セキュリティポリシーは、ロードバランサのバックエンドサービスにアタッチして適用します。 セキュリティポリシー内のルールは、優先度の数値が小さいものから順に評価されます。リクエストが最初に一致したルールのアクションが実行され、以降のルールは評価されません。この仕組みは、後述する評価順の設計の前提になります。 DDoS 攻撃のうち、L3 / L4 のボリューム型攻撃やプロトコルを悪用する攻撃は、セキュリティポリシーの設定がなくても常時緩和されます。HTTP フラッドなどの L7 の DDoS 攻撃には、セキュリティポリシーのルールで対策します。 なお、Cloud Armor には、Standard と Enterprise の 2 つのティアがあります。Standard は、セキュリティポリシー、ルール、リクエストの数に応じた従量課金です。Enterprise は Standard の機能に加えて、脅威インテリジェンス、名前付き IP アドレスリスト、階層型セキュリティポリシー、高度なネットワーク DDoS 保護などを使用できます。 参考 : Security policy overview 参考 : Cloud Armor Enterprise overview セキュリティポリシーの種類 セキュリティポリシーには、適用先によって以下の3種類があります。 種類 適用先 主な機能 バックエンドセキュリティポリシー アプリケーションロードバランサ、プロキシネットワークロードバランサ 事前構成 WAF ルール、レート制限、Bot 管理など エッジセキュリティポリシー Cloud CDN を有効にしたバックエンド、Cloud Storage バケット IP アドレスや地域などによる許可・拒否 ネットワークエッジセキュリティポリシー パススルーネットワークロードバランサ、外部 IP アドレスを持つ VM など L3 / L4 の通信の許可・拒否 エッジセキュリティポリシーは、Cloud CDN のキャッシュから応答する前に評価され、バックエンドセキュリティポリシーと併用できます。 ネットワークエッジセキュリティポリシーは WAF ではなく、L3 / L4 の通信を制御するものです。使用するには、Cloud Armor Enterprise への登録と、高度なネットワーク DDoS 保護の有効化が必要です。 このほか、組織やフォルダの単位でまとめて適用できる階層型セキュリティポリシーもあり、こちらも Cloud Armor Enterprise の機能となります。 参考 : Types of security policies ルールの種類 セキュリティポリシーに設定できるルールには以下の 7 種類があります。以下の表のティア列で Standard もしくはアドオンとしたものは、どちらのティアでも使用できます。 種類 内容 使用例 ティア IP アドレスの許可リスト・拒否リスト 送信元の IP アドレスや CIDR で許可・拒否する ・攻撃元の IP アドレスを拒否する ・脆弱性診断の送信元を許可する Standard 送信元の地域 送信元の国・地域のコードで許可・拒否する サービス対象外の国からの通信を拒否する Standard 事前構成 WAF ルール CRS のシグネチャで SQLi や XSS などを検知する 感度 1 から有効にし、チューニングする Standard マネージドルール（Preview） Google が脅威情報をもとに更新するシグネチャで検知する 事前構成 WAF ルールに追加して使用する アドオン Bot 管理 reCAPTCHA の評価結果で Bot を判定する ログイン画面への自動化されたアクセスを判定する Standard 名前付き IP アドレスリスト CDN 事業者などが公開する IP アドレスのリストで許可・拒否する CDN 経由のアクセスだけを許可する Enterprise レート制限 一定時間内のリクエスト数で制限する ログイン API への総当たり攻撃を抑止する Standard マネージドルール は事前構成 WAF ルールとは別の機能で、2026年10月現在 Preview です。事前構成 WAF ルールが CRS をもとにしているのに対し、マネージドルールは Google の脅威情報をもとに更新され、新しい脆弱性を狙う攻撃への対策を提供します。 ルールの条件は、Common Expression Language（CEL）をもとにしたカスタムルール言語で記述します。IP アドレス、地域、ヘッダー、パスなどの条件を組み合わせて、独自のルールも作成できます。一致したリクエストに対するアクションには、許可、拒否（403、404、502 から応答コードを選択）、リダイレクト、スロットル、レートベースの禁止があります。 参考 : Managed rules overview Cloud NGFW との役割分担 WAF と似た目的を持つ仕組みに、 侵入検知（防止）システム （IDS / IPS）があります。Google Cloud では、Cloud NGFW の Enterprise ティアで IDS / IPS 機能が提供されます。 Cloud Armor と Cloud NGFW Enterprise は検査範囲が異なります。Cloud Armor はロードバランサが受けたリクエストを検査しますが、Cloud NGFW Enterprise はゾーン単位のファイアウォールエンドポイントで、VM や Google Kubernetes Engine（以下、GKE）が送受信するパケットを検査します。 観点 Cloud Armor（WAF） Cloud NGFW Enterprise ティア（IDS / IPS） 検査対象 ロードバランサが受けた HTTP(S) リクエスト VM や GKE が送受信する通信（VPC 内のサーバー間の通信も含む） 主な防御 SQLi や XSS などの L7 の攻撃、L3 / L4 と L7 の DDoS 攻撃 脆弱性を狙う攻撃、マルウェア、スパイウェア、C2（コマンドアンドコントロール）通信の検知・遮断 仕組み セキュリティポリシー Palo Alto Networks の脅威防御テクノロジー 対象外 VPC 内のサーバー間の通信、送信方向の通信 サーバーレスからの送信方向の通信 一般公開の Web サービスであれば、入口の防御は Cloud Armor で行い、VPC 内の通信はファイアウォールルールで制御する構成が一般的です。そのうえで、VPC 内の通信まで攻撃を検査する必要がある場合や、マルウェアの通信を遮断したい場合に、Cloud NGFW Enterprise を追加します。 なお、Cloud NGFW には、Enterprise ティアの他に、IP アドレスやポートでの許可・拒否を行う Essentials ティアと、FQDN や地域を条件にできる Standard ティアもあります。 参考 : Intrusion detection and prevention service overview 参考 : Cloud NGFW tiers ベストプラクティスの全体像 Cloud Armor のベストプラクティスは以下の4カテゴリ・20項目に分けて紹介されています。以降の章でこの順に各項目を説明します。 セキュリティポリシーとルールの作成 項目 内容 ルールをグループ化して並べ替える 拒否・許可・セキュリティのルールを推奨の順序で並べ、評価順を設計する スキャナのクライアント IP アドレスを特定する 脆弱性診断を行う場合に、診断元の IP アドレスの扱いを決める プレビューモードを使用する 新しいルールを適用せずにログだけ（ドライラン）で試し、影響を確認してから適用する ルールのロジックをテストする リクエストが想定どおりのルールに一致するかを確認する Adaptive Protection を有効にする 機械学習で L7 の DDoS 攻撃などの異常を検知し、アラートを受け取る レート制限のしきい値を設定する クライアントごとのリクエスト数に上限を設け、超えた分を制限する 優先度の間隔を空ける 後からルールを追加できるよう、優先度の値を 10 以上空ける ルールの説明を記載する ルールを作成した理由を説明欄に残す JSON の解析を有効にする JSON を受け付けるアプリケーションで、ボディを正しく解析させて誤検知を減らす reCAPTCHA で Bot を管理する Bot による被害がある場合に、reCAPTCHA の評価で Bot を判定する ルールのチューニング 項目 内容 事前構成 WAF ルールの感度レベルを選ぶ 感度を明示して、誤検知を抑える 詳細ログを有効にする チューニングの期間に、ルールに一致した箇所をログに記録する stable と canary のルールを使い分ける 新しいシグネチャを canary で先に検証する ロギングとモニタリング 項目 内容 ログを有効にし、サンプリングレートを選ぶ ロードバランサのログを有効にし、記録する割合を決める Security Command Center の検出結果を確認する Cloud Armor に関する検出結果を確認する Cloud Monitoring のダッシュボードを使用する ダッシュボードで保護の状況を可視化する 全般的な管理 項目 内容 IAM でアクセスを制御する セキュリティポリシーを変更・適用できるユーザーを限定する セキュリティポリシーの数を最小限にする 共通のポリシーを複数のバックエンドサービスで利活用する Terraform で管理する 上記と関連し、セキュリティポリシーを効果的に活用するため、コードで管理する GKE では Ingress や Gateway から構成する GKE を使用する場合に、Ingress や Gateway のリソースから設定する 参考 : Best practices for Cloud Armor セキュリティポリシーとルールの作成 ルールの評価順を設計する Cloud Armor のルールは、 優先度の数値が小さい順に評価され、最初に一致したルールで処理が終わります 。そのため、どのルールをどの順番で並べるかによって、防御の効果が大きく変わります。 公式ドキュメントでは、ルールを以下の 5 つのグループに分け、上から順に並べることを推奨しています。 順番 グループ 主なルールの種類 1 明示的な拒否 攻撃元として既知の IP アドレスや自律システム番号（ASN）、サービス対象外の地域からの通信を拒否する 2 信頼できる送信元の明示的な許可 脆弱性スキャナなど、信頼できるシステムからの通信を許可する 3 セキュリティルール 事前構成 WAF ルール、カスタムルール、レート制限、Bot 管理などで攻撃を検知する 4 明示的な許可 特定の IP アドレスや ASN、特定のヘッダーを持つ通信など、正規の利用者を許可する 5 デフォルトの拒否 どのルールにも一致しない通信を拒否する No.2 の「信頼できる送信元の明示的な許可」は、セキュリティルールより先に評価されます。ここで許可した通信は WAF の検査を受けないため、注意が必要です。脆弱性診断を行う場合は、診断ツールの送信元 IP アドレスを特定し、診断の期間だけこのグループで許可します。こうすると、WAF に遮断されずにアプリケーションそのものを診断できます。 No.5 のデフォルトルールは、すべてのセキュリティポリシーに自動で作成されるルールで、優先度は最も低い 2147483647 です。社内システムや取引先向けのサービスのように利用者が決まっている場合は、No.4 で許可する送信元を指定し、それ以外の通信をデフォルトルールで拒否します。一方、一般公開の Web サービスでは、許可する送信元を事前に指定できません。そのため、デフォルトルールを許可にして、No.3 のセキュリティルールで攻撃だけを遮断する構成がよく使用されます。この場合、No.4 の明示的な許可ルールは不要です。 No.1、No.2、No.4 のルールでは、IP アドレスのリストを条件に使用します。リストの管理を効率化する機能として、複数のセキュリティポリシーで IP アドレスのリストを共通管理するアドレスグループや、CDN 事業者などが公開する IP アドレスのリストを使用できる名前付き IP アドレスリストがあります。どちらも Cloud Armor Enterprise の機能です。 参考 : Group and sort rules in your security policy 参考 : Address groups overview プレビューモードで検証する プレビューモード は、ルールのアクションを実行せず、一致した結果だけをログに記録する機能です。事前構成 WAF ルールを含め、新しいルールが正常な通信にどう影響するかは、実際の通信で試すまで分かりません。そのため、新しいルールはプレビューモードで追加し、ログで正常な通信が一致していないことを確認してから、強制適用に切り替えます。 gcloud コマンドの場合、ルールの作成時に --preview フラグを付けると有効になります。 gcloud compute security-policies rules create 1000 \ --security-policy=POLICY_NAME \ --expression="evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})" \ --action=deny-403 \ --preview ルールのロジックのテストにも、プレビューモードを使用します。たとえば、優先度の高い許可ルールに一致した通信は、その後の拒否ルールでは評価されません。複数のルールを組み合わせるときは、疑似的なリクエストを送り、意図したルールに一致するかをログで確認します。 参考 : Use preview mode 参考 : Test your logic 参考 : gcloud compute security-policies rules create Adaptive Protection を有効にする Adaptive Protection は、バックエンドサービスごとに通常のトラフィックを機械学習で学習し、L7 の DDoS 攻撃などの異常なトラフィックを検知してアラートを出す機能です。有効にしてからアラートが出るようになるまで、最低 1 時間の学習期間があります。 使用できる機能は、ティアによって異なります。 ティア 機能 Standard 基本的なアラート（検知の信頼度と攻撃の規模） Enterprise 基本的なアラートに加え、攻撃のシグネチャと、攻撃を遮断するための推奨ルール アラートは、通知先を設定しないと担当者に届きません。Cloud Monitoring のアラートポリシーを作成し、検知したときの連絡経路を決めておきます。 なお、Adaptive Protection は大量のリクエストによる攻撃の検知に向いており、少量のリクエストで行われる攻撃は検知できない場合があります。そうした攻撃には、リクエストの中身を検査する事前構成 WAF ルールなどで対策します。 参考 : Adaptive Protection overview 参考 : Enable Google Cloud Armor Adaptive Protection レート制限を設定する レート制限は、一定時間内のリクエスト数に上限を設け、上限を超えたリクエストを制限する機能です。ログイン画面への総当たり攻撃や、API の過剰な呼び出しを抑えるときに使用します。 レート制限のアクションには、以下の 2 種類があります。 アクション 動作 スロットル 上限を超えたリクエストだけを拒否（またはリダイレクト）し、上限以内のリクエストは許可し続ける レートベースの禁止 上限を超えたクライアントからのリクエストを、指定した時間（60〜3,600 秒）すべて拒否する 上限は、送信元 IP アドレス、HTTP ヘッダー、Cookie の値、パスなど、キーを指定して数えます。上限を超えたときの応答コードには、429（Too Many Requests）が推奨されています。 適切なしきい値はアプリケーションの通信量によって異なります。まずプレビューモードでルールを追加し、ログから通常時のリクエスト数を把握してから、しきい値を決めます。 以下は /login へのリクエストを IP アドレスごとに 1 分あたり 100 件までに制限する例です。 gcloud compute security-policies rules create 1000 \ --security-policy=POLICY_NAME \ --expression="request.path.matches('/login')" \ --action=throttle \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=60 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key=ip \ --preview 参考 : Rate limiting overview 優先度の間隔とルールの説明 ルールの優先度は、後からルールを追加できるよう、間隔を空けて設定します。公式ドキュメントでは、10 以上の間隔を空けることが推奨されています。また、似たルールは近い優先度にまとめ、グループの間はさらに大きく空けます。たとえば、評価順の No.1 を 1000 番台、No.2 を 2000 番台、No.3 を 3000 番台、No.4 を 4000 番台のように割り当てると、評価順の設計と対応させて管理できます。 ルールには、作成した理由を説明欄に記載します。説明欄は 64 文字までのため、詳しい経緯は構成管理データベース（CMDB）などに記録し、説明欄からその場所が分かるようにしておきます。 参考 : Provide rule descriptions 参考 : Consider priority spacing JSON の解析と Bot 管理 JSON 形式のリクエストボディを受け付けるアプリケーションでは、JSON の解析を有効にします。JSON の解析はデフォルトで無効です。無効のままだと、事前構成 WAF ルールは JSON の構造を解析せずにボディを検査するため、誤検知が増えます。JSON の解析は、セキュリティポリシー単位で設定します。 gcloud compute security-policies update POLICY_NAME \ --json-parsing=STANDARD GraphQL を使用する場合は、 STANDARD_WITH_GRAPHQL を指定します。なお、事前構成 WAF ルールは、リクエストボディの先頭からデフォルトで 64 KB までを検査します。この上限は 8〜64 KB の範囲で変更できます。 Bot による不正なログインや大量アクセスの被害がある場合は、reCAPTCHA と連携した Bot 管理を検討します。Cloud Armor が reCAPTCHA のトークンを評価し、Bot と判定したリクエストを、バックエンドに届く前に拒否やリダイレクトできます。Bot 管理は Standard と Enterprise のどちらでも使用できますが、reCAPTCHA の料金が別途かかります。 参考 : Enable JSON parsing 参考 : Request body content parsing 参考 : gcloud compute security-policies update 参考 : Bot management overview 参考 : Use reCAPTCHA for bot management ルールのチューニング 感度レベルを選ぶ 事前構成 WAF ルールの感度は、0〜4 の値で指定します。指定した感度以下のシグネチャが有効になり、感度 0 ではどのシグネチャも有効になりません。感度を指定しない場合は感度 4 となり、すべてのシグネチャが評価されます。 感度 特徴 1 精度の高いシグネチャだけを評価する。誤検知が少ない 2〜3 検知の範囲が広がる。誤検知も増える 4 すべてのシグネチャを評価する。誤検知が最も多い 公式ドキュメントでは、 多くのアプリケーションで感度 1 から始めることが推奨されています 。前提知識で説明したとおり、SQLi のルールには通常の入力値でも一致しやすいシグネチャが感度 3 と 4 に含まれます。感度を指定せずにルールを追加すると、こうしたシグネチャによる誤検知で正常な通信が遮断されるおそれがあります。 感度は、ルールの条件式で指定します。 evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1}) 感度 1 で運用を始め、ログで誤検知がないことを確認しながら、必要に応じて感度を上げます。誤検知の原因となる特定のシグネチャは、 opt_out_rule_ids で除外できます。特定のパラメータやヘッダーだけを検査の対象から外すこともできます。 なお、CRS 3.0 の書式（ evaluatePreconfiguredExpr('sqli-stable') など）を使用している環境もあります。2026年10月現在、Cloud Armor では CRS 4.22 の使用が推奨されています。ワークロードが許す範囲で、CRS 4.22 のルールへの移行を検討します。 参考 : Tune preconfigured WAF rules 参考 : Choose your preconfigured WAF rule sensitivity level 参考 : Cloud Armor release notes (July 08, 2026) 詳細ログを使う 詳細ログ（verbose logging）を有効にすると、リクエストのどの部分が事前構成 WAF ルールに一致したかがログに記録されます。誤検知の原因を調べるときに役立ちます。 gcloud compute security-policies update POLICY_NAME \ --log-level=VERBOSE 詳細ログには、ルールに一致した部分のリクエストの内容が記録されます。利用者の個人情報が含まれるおそれがあるため、公式ドキュメントでは、本番環境で長期間有効にすることは推奨されていません。チューニングの期間だけ有効にし、終わったら --log-level=NORMAL に戻します。 参考 : Enable verbose logging 参考 : Verbose logging stable と canary を使い分ける 事前構成 WAF ルールには、 stable と canary の 2 つの版があります。新しいシグネチャは、先に canary に反映され、後から stable に反映されます。 シグネチャの追加による影響を事前に確認したい場合は、同じ種類のルールを canary と stable で 1 つずつ作成します。SQLi のルールの例は以下のとおりです。 優先度 ルール 設定 1000 sqli-v422-canary プレビュー（新しいシグネチャの影響をログで確認する） 1010 sqli-v422-stable 強制適用（攻撃を遮断する） プレビューモードのルールはアクションを実行しないため、canary のルールに一致したリクエストも、続けて stable のルールで評価されます。そのため、実際の防御は stable のルールで行いながら、canary に追加された新しいシグネチャが正常な通信に一致しないかを、stable に反映される前にログで確認できます。 参考 : Use stable or canary rules ロギングとモニタリング ログを有効にする Cloud Armor のログは、ロードバランサのログとして Cloud Logging に記録されます。ロードバランサのログはデフォルトで無効のため、バックエンドサービスでログを有効にします。 ログを記録する割合は、ロードバランサのサンプリングレートで決まります。チューニングや導入の期間は サンプリングレートを 1 （すべてのリクエストを記録）にすることが推奨されています。チューニングが終わった後も、すべてのリクエストを記録し続けることが推奨されていますが、ログの量に応じてサンプリングレートを下げることもできます。 gcloud compute backend-services update BACKEND_SERVICE_NAME \ --enable-logging \ --logging-sample-rate=1 \ --global 参考 : Choose a Cloud Logging sampling rate 参考 : Use request logging 参考 : gcloud compute backend-services update Security Command Center と Cloud Monitoring 組織レベルで Security Command Center（以下、SCC）を有効にしている場合、Cloud Armor の検出結果が SCC に表示されます。 検出結果 内容 Allowed Traffic Spike 許可されたリクエストが急増した Increasing Deny Ratio 拒否されたリクエストの割合が増えた これらの検出結果は、L7 の DDoS 攻撃の可能性や、望ましくない通信の増加を示すため、セキュリティ管理者が定期的に確認します。 Cloud Monitoring では、「Cloud Armor policies overview」ダッシュボードで、セキュリティポリシーごとの許可・拒否・プレビューの件数を確認できます。 参考 : Use the Security Command Center 参考 : Security Command Center findings 参考 : Monitoring Cloud Armor security policies 全般的な管理 IAM でアクセスを制御する セキュリティポリシーを変更できるユーザーは IAM で制御します。Cloud Armor の操作に必要な IAM ロールは以下のとおりです。 操作 必要な IAM ロール・権限 セキュリティポリシーの作成・変更・削除 Compute セキュリティ管理者ロール（ roles/compute.securityAdmin ） バックエンドサービスへのセキュリティポリシーの適用 Compute ネットワーク管理者ロール（ roles/compute.networkAdmin ） 例として、ルールを変更する担当者とロードバランサを管理する担当者を分けることで、意図しないルールの変更やセキュリティポリシーの付け外しを防げます。 参考 : Set up Identity and Access Management access control 参考 : Set up IAM permissions for Cloud Armor security policies ポリシーの利活用 セキュリティポリシーは複数のバックエンドサービスに適用できます。同じ要件のアプリケーションには共通のセキュリティポリシーを再利用し、ポリシー数を最小限に抑えます。ポリシーの数が増えると、ルールの変更漏れや設定の差異が起きやすくなるためです。 セキュリティポリシーは Terraform で管理できます。変更履歴が残り、問題があったときに以前の構成へ戻したり、別のプロジェクトで同じ構成を再現したりできます。Cloud Armor の GA 済みの機能は Terraform で設定できます。 参考 : Use Terraform 参考 : google_compute_security_policy GKE での構成 GKE で Ingress や Gateway を使用すると、アプリケーションを公開するためのロードバランサとバックエンドサービスは、GKE が自動で作成・管理します。Cloud Armor で保護する場合は、作成されたバックエンドサービスに直接セキュリティポリシーを設定せず、Kubernetes のリソースから指定します。直接設定した内容は、Kubernetes のリソースでセキュリティポリシーを指定したときに上書きされるためです。 公開方法 特徴 セキュリティポリシーを指定するリソース Ingress 従来からある公開方法。ロードバランサの設定とルーティングの設定を、1 つのリソースにまとめて定義する BackendConfig Gateway Ingress を発展させた新しい公開方法。ロードバランサの設定（Gateway）とルーティングの設定（HTTPRoute）を分けて定義でき、インフラ担当者とアプリケーション開発者で管理を分担できる GCPBackendPolicy Gateway を使用する場合は、先に Cloud Armor のセキュリティポリシーを作成しておき、GCPBackendPolicy から参照します。リージョンの Gateway では、リージョンのセキュリティポリシーを作成する必要があります。 参考 : Configure Cloud Armor with Google Kubernetes Engine 導入の進め方 確認ポイント これから Cloud Armor を導入する場合や、導入済みの設定を見直す場合は、以下の項目を確認します。 確認項目 確認方法の例 ルールを推奨の評価順で並べているか セキュリティポリシーのルールと優先度の一覧 新しいルールをプレビューモードで確認してから適用しているか ルールのプレビューの設定、変更の手順 Adaptive Protection を有効にし、アラートの通知先を設定しているか セキュリティポリシーの設定、Cloud Monitoring のアラートポリシー レート制限のルールを設定しているか スロットル・レートベースの禁止のルールの有無 事前構成 WAF ルールの感度を指定し、CRS 4.22 を使用しているか ルールの条件式（ sensitivity の指定、 v422 の使用） ロードバランサのログを有効にしているか バックエンドサービスのログの設定とサンプリングレート セキュリティポリシーを変更・適用できるユーザーを限定しているか IAM ロールの付与状況 JSON を受け付ける場合に、JSON の解析を有効にしているか セキュリティポリシーの詳細設定 ロードマップ Cloud Armor の導入は、以下の 5 つのステップで進めます。ステップ 2〜4 は、ルールを追加するたびに繰り返します。 ステップ 内容 1. 要件の整理 保護する対象と要件を整理する。導入済みの場合は、前述の確認ポイントで、まだ対応できていない項目を洗い出す 2. プレビューでの導入 必要なルールをプレビューモードで追加し、ログを取得する 3. チューニング 誤検知の原因となるシグネチャを除外し、感度を調整する 4. 強制適用 正常な通信への影響がないことを確認したルールから、順に強制適用に切り替える 5. 追加の対策の検討 Cloud Armor Enterprise や Cloud NGFW Enterprise の要否を判断する ティアと料金 Cloud Armor には Standard と Enterprise の 2 つのティアがあり、Enterprise には Paygo と Annual の 2 つの契約形態があります。2026年10月現在の主な違いは以下のとおりです。 機能 Standard Enterprise Paygo Enterprise Annual 料金 従量課金 月額 $200 / プロジェクト 月額 $3,000 / 請求先アカウント ・事前構成 WAF ルール ・レート制限 ・カスタムルール ◯ ◯ ◯ マネージドルール（Preview） アドオン アドオン アドオン Adaptive Protection アラートのみ ◯ ◯ ・脅威インテリジェンス ・名前付き IP アドレスリスト × ◯ ◯ ・アドレスグループ ・階層型セキュリティポリシー × ◯ ◯ 高度なネットワーク DDoS 保護 × ◯ ◯ ・DDoS 対応サポート ・DDoS 請求保護 × × ◯ Standard は、セキュリティポリシー 1 つあたり月額約 $5、ルール 1 つあたり月額約 $1、リクエスト 100 万件あたり $0.75（グローバル）の従量課金です。 Enterprise では、セキュリティポリシー、ルール、リクエストの料金が月額料金に含まれます。ただし、Standard にはないデータ処理料金がかかります。Paygo は月額料金に 2 つの保護対象リソースが含まれ、3 つ目以降は 1 リソースあたり月額 $200 が追加されます。Annual は 12 か月の契約で、100 リソースまで含まれ、101 個目以降は 1 リソースあたり月額 $30 が追加されます。 DDoS 対応サポートを受けるには、Annual の契約に加えて、カスタマーケアの Premium サポートの契約などの条件があります。また、Annual の契約がない場合、階層型セキュリティポリシーを継承したプロジェクトは、自動的に Paygo に登録されます。 参考 : Cloud Armor Enterprise overview 参考 : Cloud Armor pricing 武井 祐介 (記事一覧) クラウドソリューション部 > 事業開発部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

こんにちは、ブログ運営担当の遠藤です。 11/18(水) 12:00～13:00 当社主催のウェビナー「緊急の脆弱性情報が出たら、まず何をしますか？ ― 影響の確認から封じ込めまで、AWSサービスを使った自社システムの脆弱性対応」を開催します！ 発表概要 2026年10月、PHPの重大な脆弱性が一般のニュースでも大きく報じられ、Webサイトを一時的に停止する組織が相次ぎました。 このニュースを受けて、経営層やセキュリティ部門から「自社のシステムは大丈夫か」と確認を求められたとき、自信をもって答えられる方は少ないのではないでしょうか。答えるためには、次のことを把握しておく必要があります。 該当す…

こんにちは、ソフトクリエイトのサトキチです。 オンプレミス環境からキャリアをスタートし、現在はMicrosoft 365を中心としたクラウドサービスに携わっています。 社内システムを管理していると、Windowsやネットワーク機器、業務アプリケーションなど、さまざまな製品の脆弱性情報が届きます。