【テクニカル・上級編】 Cloud Armorのセキュリティポリシーにおける事前構成済みWAFルール(ModSecurityベース) – クラウドインフラと仮想化ネットワーク実践ガイド

Cloud Armor事前構成済みWAFルールの深層：ModSecurityの魂を宿すGCPエッジで、パフォーマンスを犠牲にせずに悪意を屠る方法

クラウドネイティブなインフラの最前線に立つ我々SREやアーキテクトにとって、アプリケーションの可用性とセキュリティの両立は、永遠のテーマであり、同時に最もスリリングな領域です。

グローバルなトラフィックがGCPのエッジネットワーク、すなわちGoogleの堅牢なフロントエンド（Global External HTTP(S) Load Balancer）に突入する瞬間を想像してください。クライアントから送出されたパケットは、TCP 3ウェイ・ハンドシェイクを完了させ、TLS 1.3の暗号化スイートを解き放ち、HTTP/2やHTTP/3の多重化されたストリームへと変換されます。このミリ秒単位のドラマの最前線で、悪意あるペイロードを静かに、かつ超高速で迎撃しているのが Google Cloud Armor です。

今回は、Cloud Armorの心臓部とも言える事前構成済みWAFルール（Preconfigured WAF Rules：ModSecurityベース）に焦点を当てます。教科書的な設定手順をなぞるだけでは、本番環境の激しいトラフィックの波にもまれ、誤検知（False Positive）の嵐に直面するか、あるいはレイテンシの悪化という致命的な代償を払うことになります。

パケットの挙動、LinuxカーネルとGCPエッジの境界、そしてModSecurity由来のシグネチャ評価メカニズムの裏側まで、ディープに紐解いていきましょう。

—

1. エッジにおける脅威防御のアーキテクチャ：パケットはどこで検査されるのか？

多くのエンジニアが誤解している点ですが、Cloud ArmorのWAF評価は、Kubernetesクラスター内のPodの直前（サイドカーやイングレスコントローラー）で行われるわけではありません。トラフィックがGCPのグローバル外部HTTP(S)ロードバランサーのフロントエンド（POP: Point of Presence）に到達した、まさにその瞬間、TLSの終端と同時にHTTPリクエストの解析が行われます。

このアーキテクチャには、インフラストラクチャの観点から極めて重要な意味があります。

[Client] ---> (TLS Handshake / QUIC) ---> [GCP Edge POP (Cloud Armor WAF)] ---> (Internal VPC Network) ---> [GKE / Backend]

1. ゼロ・トラスト・エッジ: 悪意あるSQLインジェクションやクロスサイトスクリプティング（XSS）のペイロードは、Googleのバックボーンネットワークに入る前に、クライアントに最も近いエッジロケーションで遮断されます。これにより、不審なリクエストがお客様のVPCネットワークやKubernetesノードのリソースを1バイトたりとも消費させません。
2. TLS終端の最適化: 現代のWebトラフィックの99%以上はTLSで暗号化されています。Cloud Armorは、Googleが独自に最適化しハードウェアアクセラレーションが効いたTLS終端処理とインラインで動作するため、暗号化されたストリームのままであっても、パフォーマンスの劣化を最小限に抑えながらHTTPヘッダーとボディの検査を完遂します。

—

2. ModSecurity由来の事前構成済みルールと「感度レベル（Sensitivity）」のメカニズム

Cloud Armorの事前構成済みWAFルールは、オープンソースのWAFエンジンとして長年デファクトスタンダードとして君臨してきた ModSecurity（CRS: Core Rule Set） のシグネチャ体系をベースに構築されています。

例えば、sqli-v33-m や xss-v33-m といったルールセットは、単に特定の文字列（UNION SELECT や <script> など）を正規表現でブラックリスト方式にマッチさせているわけではありません。これらは「異常値スコアリングモデル（Anomaly Scoring）」を採用しており、リクエストの各構成要素（URI、Query Parameters、Request Headers、Request Body）に対して個別のスコアを付与し、その総和が閾値を超えた段階でブロック判定を下します。

ここで重要になるのが、Cloud Armorにおける感度レベル（Sensitivity Level）のチューニングです。

感度レベルの罠と設計思想

Cloud Armorでは、事前構成済みルールに対して 1 から 9 までの感度レベルを設定可能です（数値が大きいほど高感度、つまり厳格に検知する）。

  • 高感度（例: 7〜9）: わずかな兆候でも検知するため、攻撃を逃さない反面、社内CMSのHTMLリッチエディタから送られる正当なHTMLタグや、多言語環境特有の文字エンコーディングをXSSと誤認（False Positive）するリスクが跳ね上がります。
  • 低感度（例: 1〜3）: 誤検知は激減しますが、高度に難読化されたSQLi（コメントアウトやインラインエンコーディングを駆使したもの）をすり抜けてしまう可能性が高まります。

実務上のベストプラクティスとして、最初はデフォルト（通常は2または3）からスタートし、プレビューモード（後述）を活用しながら徐々に最適値を見極めるアプローチが不可欠です。

—

3. 実践：プレビューモードを活用した安全なポリシー構築とチューニング

本番環境でいきなりWAFルールを deny アクションで有効化するのは、自らDDoS攻撃を引き起こすようなものです。必ず preview モード（監査モード）を経由させ、ログ分析を徹底してください。

以下のGoogle Cloud CLI（gcloud）コマンドは、SQLインジェクション対策の事前構成済みルールを、まずはプレビューモードで既存のセキュリティポリシーに挿入する例です。

# セキュリティポリシーに事前構成済みWAFルール（SQLi）をプレビューモードで追加する
gcloud compute security-policies rules create 1000 \
    --security-policy=my-production-waf-policy \
    --expression="evaluatePreconfiguredWaf('sqli-v33-m', {'sensitivity': 3})" \
    --action=deny-403 \
    --preview \
    --description="SQLインジェクション対策ルール（検証用プレビューモード）"

ログ分析によるチューニング（Cloud Logging）

プレビューモードで稼働させると、Cloud Loggingには実際にブロックされたであろうリクエストが enforceOnKey やプレビューフラグ付きで記録されます。ここを確認するための代表的なLogQL（Cloud Loggingクエリ）を以下に示します。

resource_type="http_load_balancer"
jsonPayload.enforcedSecurityPolicy.name="my-production-waf-policy"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
jsonPayload.enforcedSecurityPolicy.preconfiguredExprSensitivity=3

このログを詳細に精査し、「自社アプリケーション特有の特殊なクエリパラメータ」が誤検知されていないかを確認します。もし正当なリクエストが検知されている場合は、ルール全体を無効化するのではなく、次節で解説するルール除外（Rule Exclusion）を用います。

—

4. 誤検知（False Positive）をスマートに回避する：ルール除外（Rule Exclusion）の極意

全体の感度を下げたり、ルールそのものを切ったりするのはセキュリティ上の敗北を意味します。Cloud Armorでは、特定のURLパスや特定のパラメータに対して、特定のシグネチャID（例: 942100 など、ModSecurityのルールIDに準じた識別子）の評価をピンポイントで除外する機能が提供されています。

例えば、/api/v1/documents/content というエンドポイントの raw_html というリクエストボディのパラメータに限り、XSS関連の一部シグネチャの評価をバイパスさせたい場合の構成イメージは以下のようになります。

# 特定のパラメータに対して特定の事前構成済みルールの一部をバイパスする設定例
gcloud compute security-policies rules update 1000 \
    --security-policy=my-production-waf-policy \
    --update-preconfigured-waf-config=sqli-v33-m=exclusion:REQUEST_PARAMETER_NAME:raw_html

このように、ネットワークインフラストラクチャのコード（IaC）やCLIを駆使して、「全体は守りつつ、ビジネス上必要な例外だけを外科手術的に除外する」というアプローチこそが、一流のクラウドアーキテクトの仕事です。

—

5. パフォーマンスとスループットの極限追求：RTT削減とレイテンシの罠

セキュリティ機能を有効化すると、どうしても懸念されるのが「レイテンシの増加」です。Cloud ArmorはGoogleのC++で書かれた高性能なプロキシコア上で動作するため、ソフトウェアWAFにありがちな深刻なボトルネックは極限まで排除されていますが、アーキテクチャ設計において以下の点に留意する必要があります。

1. リクエストボディのサイズ制限（Inspection Limits）:
Cloud Armorが一度にインスペクションできるリクエストボディのサイズには上限（通常は最大8KB程度、設定により調整可能）があります。もし巨大なファイルアップロードやJSONのバッチ送信を行うエンドポイントがある場合、WAFがボディ全体をスキャンしようとしてCPUサイクルを消費し、結果としてTTFB（Time to First Byte）が劣化する原因になります。

  • 対策: アップロード専用のエンドポイント（例: /api/v1/upload）は、セキュリティポリシーの適用除外（あるいは別ポリシーの割り当て）を行うパスベースのルーティングをロードバランサー側で構成すべきです。

2. TCPバッファとHTTP/2の多重化への配慮:
エッジでのWAF処理はCPUバウンドな処理（パターンマッチング）です。クライアント側のTCPウインドウ制御や、HTTP/2のストリーム制御において、悪意あるスローロリス攻撃（Slowloris）や、極端に細分化されたパケットによるインスペクション回避を狙った攻撃に対しては、Cloud Armorのレートリミット機能（EXCEEDS-RATE-LIMIT）や、ロードバランサー側のタイムアウト設定のチューニングを組み合わせることで、カーネルレベルおよびアプリケーション層の双方で堅牢な防壁を築くことができます。

—

結びにかえて

Cloud Armorの事前構成済みWAFルールは、単なる「スイッチを入れれば安全になる魔法の箱」ではありません。それは、Linuxカーネル、TCP/IPスタック、TLSハンドシェイク、そしてHTTPプロトコルの深淵を理解したエンジニアが使いこなして初めて真価を発揮する、極めて強力な「スナイパーライフル」です。

エッジの特性を熟知し、プレビューモードを通じた綿密なログ分析、そして外科手術的なルール除外とパス最適化を組み合わせることで、「レイテンシゼロの高速なユーザー体験」と「鉄壁のセキュリティ」を高い次元で両立させましょう。

あなたの構築するクラウドインフラストラクチャが、いかなるサイバー脅威の嵐の中でも揺るぎないものでありますように。

スポンサーリンク

コメント

タイトルとURLをコピーしました