Google Cloud Armor のベストプラクティス

このページでは、Google Cloud Armor のデプロイを最適化および調整するためのベストプラクティスについて説明します。

Google Cloud Armor は、グローバル外部アプリケーションロードバランサ、従来のアプリケーションロードバランサ、外部プロキシネットワークロードバランサのいずれかと一緒にデプロイされます。Google Cloud Armor をデプロイする場合は、保護するロードバランサのバックエンドサービスにセキュリティポリシーを接続します。セキュリティポリシーは、ユーザーが決定する事前構成済みのルールとカスタムルールの集合で構成されます。

セキュリティポリシーとルールの作成

以降のセクションでは、新しいセキュリティポリシーとルールに対するベストプラクティスと推奨事項について説明します。

ルールの説明を提供する

ルールの説明を使用して、各ルールが作成された理由とルールの目的の機能について追加のコンテキストを提供します。[説明] フィールドは 64 文字以内に制限されているため、構成管理のデータベースや他のリポジトリを参照すると、最も効率的な方法でコンテキストを収集できます。

優先度の間隔を検討する

最初にルールを構成するときは、ルールの優先度値の間隔を 10 以上空けます。たとえば、セキュリティポリシーの最初の 2 つのルールの優先度を 20 と 30 にします。これにより、必要に応じてルールを追加できます。また、類似したルールをブロックにまとめて、グループ間の間隔を広げることをおすすめします。

プレビューモードを使用する

Open Web Application Security Project（OWASP）署名などのセキュリティポリシールールは、アプリケーションに予期しない影響を与える可能性があります。プレビューモードを使用して、ルールの導入が本番環境のトラフィックに悪影響を及ぼすかどうか評価してください。

Google Cloud Armor Adaptive Protection を有効にする

Adaptive Protection を有効にすると、アプリケーションの保護を強化できます。Adaptive Protection はトラフィックをモニタリングし、必要に応じてセキュリティポリシーの新しいルールを推奨します。また、潜在的な攻撃の発生を適切な担当者に警告するように、アラートポリシーを設定することをおすすめします。Adaptive Protection はボリューム保護に最適です。ボリューム型攻撃でない場合は、Adaptive Protection がトリガーされない場合があります。

JSON 解析を有効にする

アプリケーションで、POST リクエストの本文に含めて JSON コンテンツを送信する場合は、必ず JSON 解析を有効にしてください。JSON 解析を有効にしない場合、Google Cloud Armor は事前構成の WAF ルールに対して POST 本文の JSON コンテンツを解析しません。その結果、ノイズが発生し、誤検出が発生する可能性があります。詳細については、JSON 解析をご覧ください。

ロジックをテストする

一致条件が true と評価されると、ルールがトリガーされます。たとえば、リクエストのリージョンコードが AU の場合、一致条件 origin.region_code == 'AU' は true と評価されます。優先度の高いルールが true と評価された場合、優先度の低いルールのアクションは無視されます。次の例では、IP アドレス範囲 10.10.10.0/24 内のトラフィックを除いて、AU リージョンからのユーザーをブロックするセキュリティポリシーを作成します。次の 2 つのルールを含むセキュリティポリシーについて考えてみましょう。

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

この例では、Rule1 は、IP アドレス範囲 10.10.10.0/24 から発信されたトラフィックを許可します。Rule1 は優先度の高いルールであるため、このようなトラフィックは Rule2 に対して評価される前に許可されます。つまり、Google Cloud Armor は Rule2（またはその他の残りのルール）に対して評価を実行しません。

Google Cloud Armor ポリシーを作成する場合は、ルールのロジックをテストして、意図したとおりに動作することを確認します。これを行うには、トラフィックをブロックしているルールを把握し、結果がルール設計の決定と一致していることを確認するために、合成トラフィックを生成することをおすすめします。リクエストがシステムを通過する方法がわからない場合は、プレビューモードを使用して、リクエストに一致するルールを確認します。

スキャナの送信元 IP アドレスを特定する

セキュリティスキャナは Google の内部または外部に設置できます。外部にいて、アプリケーションでフィルタされていない評価が必要な場合は、他のルールを評価する前に、IP アドレス（またはその他のトークン）に基づいて明示的にトラフィックを許可できます。

セキュリティポリシーのルールをグループ化して並べ替える

アプリケーションは、ユーザーのサブセットごとに異なる可能性があります。次の例では、特定の地理的エリアまたは IP 範囲からのトラフィックを拒否するため、このようなトラフィックを拒否するようにポリシーの最初のルールを構成しています。また、セキュリティポリシーによって処理されていないアプリケーションへのトラフィックを明示的に許可したい場合があります。この例では、優先度の高い順にルールの優先度を構成することをおすすめします。

明示的な拒否ルール（ASN、リージョン、IP 範囲）
信頼できる明示的な許可ルール（スキャナ、信頼できるシステム - 慎重に使用）
セキュリティルール（OWASP、カスタムルール）
明示的な許可ルール（ASN、ヘッダー値の有無、IP 範囲）
デフォルトの拒否ルール

bot 管理に reCAPTCHA Enterprise を使用する

Google Cloud Armor は Google の reCAPTCHA Enterprise と統合されており、WAF レイヤでボット検出を行います。この統合では、reCAPTCHA Enterprise は reCAPTCHA トークンを生成し、Google Cloud Armor は reCAPTCHA Enterprise ではなくトークン評価プロセスを実行します。これにより、送信元の負荷が削減され、コストが削減される可能性があります。また、バックエンドよりもエンドユーザーに近い場所でセキュリティ制御が行われるようになります。詳細については、bot 管理の概要をご覧ください。

レート制限しきい値を設定する

レート制限は、不正行為を防止し、クレデンシャルスタッフィングや L7 DDoS 攻撃などの大量の脅威を軽減する柔軟で、付加価値の高い機能です。レート制限を初めてデプロイする場合は、アプリケーションに適したしきい値を選択することが重要です。プレビューモードで適用することをおすすめします。トラフィックプロファイルを分析して把握する際に、レート制限パラメータを調整できます。また、レート制限ルールに割り当てる優先度を検討することも重要です。トラフィックは、レート制限ルールで評価される前に、優先度の高いルールによって明示的に許可または拒否される場合があります。

ルールの調整

ウェブアプリケーションが攻撃のように見えるリクエストを許可する場合があります。また、事前構成された WAF ルールのシグネチャと一致するリクエストをユーザーが送信することを許可（または要求）する場合があります。本番環境のアプリケーションでプレビューモードを無効にしてから、ルールをプロモートする前に、アプリケーションで Google Cloud Armor ルールを検証し、アプリケーションに関係のない結果に対処することが重要です。以降のセクションでは、事前構成された WAF ルールを調整するためのベストプラクティスと推奨事項について説明します。

事前構成された WAF ルールの感度レベルを選択する

事前構成された WAF ルールを実装する場合、セキュリティ要件とタイムラインに基づいて適切な感度レベルを選択できます。組織のセキュリティ要件を満たす必要のあるアプリケーションは、感度レベル 1 から開始することをおすすめします。感度 1 用に構成されたルールでは、忠実度の高いシグネチャを使用して、ルールから生じるノイズを抑えます。高感度に関連付けられたシグネチャを使用すると、一部の保護されたアプリケーションで潜在的なノイズが発生する可能性がありますが、大規模な悪用の試みを検出して、攻撃を未然に防ぐことができるかもしれません。ただし、より厳格なセキュリティ要件が求められるワークロードの場合、最高感度レベルが優先される場合があります。これらのユースケースでは、大量のノイズや無関係な検出結果が生じる可能性があり、セキュリティポリシーを本番環境に移行する前に、チューニングを実行して調整する必要があります。

詳細ログを有効にする

特定の WAF ルールをトリガーしているリクエスト属性とペイロードに関する追加情報が必要な場合は、詳細ログを有効にします。詳細ログにより、特定のルールをトリガーするリクエストの詳細が提供されます。たとえば、リクエストの不適切な箇所のスニペットは、Google Cloud Armor のトラブルシューティングと調整に役立ちます。詳細ログによってエンドユーザーのリクエストコンテンツが Cloud Logging に記録されることがあり、エンドユーザー PII がログに残される可能性があります。そのため、詳細ログを長期間有効にして本番環境のワークロードを実行することはおすすめしません。

安定ルールまたはカナリアルールを使用する

Google Cloud Armor の事前構成の WAF ルールには、安定版とカナリアの 2 種類があります。現在の ModSecurity Core Rule Set（CRS）に新しいルールが追加されると、それらを安定したルールのビルドに自動的に公開する前に、カナリアルールのビルドに公開します。カナリアルールをテスト環境にデプロイして、環境内の変更や追加の影響を確認することをおすすめします。カナリアビルドが安定版ビルドと同期しているかどうかを確認するには、Google Cloud Armor WAF ルールのチューニングページでルール名を確認してください。

ロギングとモニタリング

以降のセクションでは、ロギングとモニタリングを構成するためのベストプラクティスと推奨事項について説明します。

Security Command Center を使用する

Google Cloud Armor は Security Command Center と自動的に統合されます。Google Cloud Armor は、さまざまな検出結果を Security Command Center にエクスポートします。

許可されるトラフィックの急増
拒否率の増加

これらの検出結果は、ウェブセキュリティ担当者が必ず確認してください。

Cloud Logging のサンプリングレートを選択する

Google Cloud Armor のリクエストごとのログは、グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサのロギングインフラストラクチャを使用します。その結果、Google Cloud Armor のログの生成には、ロードバランサで構成されたログサンプリングレートが適用されます。Google Cloud Armor を積極的に調整して実装する場合は、サンプリングレートを 1 にしておくことをおすすめします。Google Cloud Armor の調整と実装が完了したら、完全なリクエストロギングを有効にしておくことをおすすめします。ただし、低いサンプリングレートまでダウンサンプリングすることを選択する場合もあります。グローバル外部アプリケーションロードバランサと従来のアプリケーションロードバランサのどちらでも、デフォルトではログが有効になっていないため、手動でロギングを有効にすることが重要です。

Cloud Monitoring ダッシュボードを使用する

Google Cloud Armor の構成で、何が行われているのかを明確に把握することは不可欠です。これを簡単に行うには、セキュリティダッシュボードを使用します。また、Logging から独自のプラットフォームに Google Cloud Armor のログを直接エクスポートすることもできます。Adaptive Protection を使用している場合、トリガーされる Adaptive Protection 保護アラートのエスカレーションパスがあることが重要です。

全般管理

次に、Google Cloud Armor を構成するための追加のベストプラクティスと推奨事項を示します。

Identity and Access Management のアクセス制御を設定する

Google Cloud IAM の一般的なベストプラクティスに従って、適切なユーザーが Google Cloud Armor にアクセスできるようにします。Google Cloud Armor セキュリティポリシーを構成、変更、更新、削除するには、Compute セキュリティ管理者のロールが必要です。また、Google Cloud Armor セキュリティポリシーをバックエンドサービスに接続するには、Compute ネットワーク管理者のロールまたは compute.backendServices.setSecurityPolicy 権限が必要です。

ポリシーの数を最小限に抑える

Google Cloud Armor ポリシーは複数のバックエンドサービスで再利用できます。再利用可能なセキュリティポリシーのセットを用意することをおすすめします。

Terraform を使用する

構成をロールバックしやすく、プロジェクト間で再現できるように、Terraform を使用することをおすすめします。Google Cloud Armor には、一般提供機能用に完全な Terraform 統合が用意されています。

Google Cloud Armor と Google Kubernetes Engine を構成する

GKE を使用している場合は、BackendConfig パラメータで Google Cloud Armor とその他の Ingress 機能を構成する必要があります。グローバル外部アプリケーションロードバランサや従来のアプリケーションロードバランサを上り（内向き）ポイントとして機能するように手動で構成しないことをおすすめします。GKE を使用して Google Cloud Armor を構成する方法については、Ingress 機能の構成をご覧ください。