このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。

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

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

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

組織内のすべてのプロジェクトに自動的に適用される Cloud Armor ポリシーを設定し、個々のプロジェクトで独自のルールを追加できるようにする場合は、カスタム制約を使用して Cloud Armor を管理する方法に関するガイドをご覧ください。このアプローチを使えば、組織全体にセキュリティポリシーを一元的に適用しながら、個々のプロジェクトのニーズに合わせて柔軟性を維持できます。

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

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

ルールの説明を提供する

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

優先度の間隔を検討する

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

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

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

JSON 解析を有効にする

アプリケーションで POST リクエストの本文に JSON コンテンツを含めて送信する場合は、必ず JSON 解析を有効にしてください。JSON 解析を有効にしないと、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 に対して評価される前に許可されます。つまり、Cloud Armor はこのトラフィックを Rule2（またはその他の残りのルール）に対して評価しません。

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

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

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

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

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

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

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

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

ルールの調整

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

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

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

詳細ログを有効にする

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

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

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

ロギングとモニタリング

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

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

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

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

Cloud Armor の構成で何が起こっているのかを明確に把握することは不可欠です。これを簡単に行うには、セキュリティダッシュボードを使用します。また、Logging からお客様独自のプラットフォームに Cloud Armor のログを直接エクスポートすることもできます。

全般管理

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

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

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

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

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

Terraform を使用する

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

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

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