階層型セキュリティ ポリシーは、Google Cloud Armor ウェブ アプリケーション ファイアウォール（WAF）と DDoS 保護を個々のプロジェクトを超えて拡張するセキュリティ ポリシーのカテゴリです。これらのロールは、組織、フォルダ、プロジェクトのレベルで接続されます。これは、バックエンド サービスまたはバックエンド バケットに直接接続されるサービスレベルのセキュリティ ポリシーとは異なります。
組織またはフォルダレベルで階層型セキュリティ ポリシーを構成すると、階層の下位レベルにあるプロジェクトはそのセキュリティ ポリシーを継承します。この継承により、組織内のすべてのプロジェクトまたは一部のプロジェクトに適用するセキュリティ ポリシー ルールを設定できます。これにより、 Google Cloud 環境全体で一元化された一貫したセキュリティの適用が可能になります。
このページでは、階層型セキュリティ ポリシーとサービスレベルのセキュリティ ポリシーの違いについて説明します。続行する前に、セキュリティ ポリシーの概要をお読みいただき、セキュリティ ポリシーの仕組みを理解してください。また、リソース階層についてよく理解しておくことをおすすめします。
ユースケース
大規模な組織では、多数のプロジェクトにわたるセキュリティ ポリシーの管理が複雑で時間がかかることがあります。階層型セキュリティ ポリシーには、これらの課題の解決に役立つ次の利点があります。
- 一元管理: 組織レベルとフォルダレベルの管理者に、複数のプロジェクトのセキュリティ ポリシーを定義して適用する機能を提供します。
- 一貫性: 組織全体で一貫したセキュリティ ポスチャーを確立し、構成ミスやセキュリティ ギャップのリスクを軽減します。
- 効率性: 特定の IP アドレス範囲のブロックや重大な脆弱性への対応など、セキュリティ アップデートと緩和策を多数のリソースに同時に効率的にデプロイできます。
- 委任: 階層の適切なレベルでポリシーを適用することで、さまざまなチームや部門にセキュリティ責任を委任できます。
これらの一般的な原則は、組織のニーズに合わせて適用し、組み合わせることができます。次のユースケースの例について考えてみましょう。
- 組織全体の IP アドレスのブロック: 組織内のすべてのプロジェクトで、既知の不正な IP アドレス範囲からのトラフィックをブロックできます。
- 地域ベースの制限: 特定の地理的地域からのトラフィックを組織レベルまたはフォルダレベルで制限できます。
- CVE の軽減: WAF ルールをすばやくデプロイして、複数のプロジェクトの重大な脆弱性を軽減できます。
- コンプライアンスの適用: 組織全体で一貫したセキュリティ ポリシーを適用することで、規制要件の遵守を徹底できます。
- きめ細かいアクセス制御: 特定の IP アドレス範囲または地理的リージョンに、特定のフォルダ内のすべてのリソースへのアクセス権を付与できます。
機能
階層型セキュリティ ポリシーは、サービスレベルのセキュリティ ポリシーがサポートする機能のサブセットをサポートしています。次の表は、階層型セキュリティ ポリシーとサービスレベルのセキュリティ ポリシーで使用できる Google Cloud Armor の機能を比較したものです。
| フロントエンド タイプ |
|
|
| 接続ポイント（保護されたリソース） | バックエンド サービス | リソース階層ノード |
| ルール アクション |
|
|
| 送信元 IP アドレス | ||
| 送信元の地理的情報 | ||
| 送信元の ASN | ||
| bot 管理 | （EXTERNAL_302 とリクエストのデコレーションのみ） |
|
| レイヤ 7 フィルタリング | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| 適応型保護 | ||
| アドレス グループ | ||
| 組織レベルのアドレス グループ | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| リクエストのロギング |
階層型セキュリティ ポリシーの仕組み
階層型セキュリティ ポリシーを作成する場合は、組織レベルまたはフォルダレベルで作成します。そのリソースには、階層型セキュリティ ポリシーに対する所有権があります。階層型セキュリティ ポリシーを作成しても、セキュリティ ポリシーのルールはリソースに適用されません。
次に、階層型セキュリティ ポリシーを組織、フォルダ、またはプロジェクトに関連付けます。これは、ポリシーを所有するリソースと同じにできます。階層型セキュリティ ポリシーをリソースに関連付けると、リソース階層内のそのノードとその下の保護されたリソースにセキュリティ ポリシー ルールが適用されます。階層型セキュリティ ポリシーをどのリソースに接続するかを決定するには、以下の各リソースの基本的なユースケースのリストをご覧ください。
- 組織: 組織レベルの階層型セキュリティ ポリシーは、階層型セキュリティ ポリシーのデフォルト タイプと見なします。これらのポリシーには幅広い Identity and Access Management（IAM）権限があり、組織内のすべてのノードに適用されます。これらのリソースは、関連付け時に
--organizationフラグを使用して指定します。 - フォルダ: 組織全体ではなく、複数のプロジェクトに同じセキュリティ ポリシー ルールを適用する場合は、これらの階層型セキュリティ ポリシーを使用します。これらのリソースは、関連付け時に
--folderフラグを使用して指定します。 - プロジェクト: 複数のバックエンド サービスに IP アドレス拒否リストを適用するなど、プロジェクト内のすべてのリソースに同じセキュリティ ポリシー ルールを適用する必要がある場合は、このタイプの階層型セキュリティ ポリシーを使用します。これらのリソースは、関連付け時に
--projectフラグを使用して指定します。 - サービスレベル: サービスごとに異なる一意のセキュリティ ポリシー ルールが必要な場合は、サービスレベルのセキュリティ ポリシーを使用します。サービスレベルのセキュリティ ポリシーは、接続されているバックエンド ポリシーにのみルールを適用します。これらのリソースは
--project-numberフラグを使用して指定します。
階層型セキュリティ ポリシーごとに使用できるフラグは 1 つだけです。--name や --type などの残りのフラグは、サービスレベルのセキュリティ ポリシーを構成する場合と同様に指定します。階層型セキュリティ ポリシーの仕組みの詳細については、次のリストをご覧ください。
- 階層型セキュリティ ポリシーがリソース階層ノードに関連付けられている場合、階層内のそのノードより下にあるすべての保護されたリソースがポリシーを継承します。
- プロジェクト内の保護対象リソースに適用されるセキュリティ ポリシーは、すべての階層型セキュリティ ポリシーとサービスレベルのセキュリティ ポリシーで確認できます。詳細については、保護されたリソースに有効なすべての Google Cloud Armor ルールを表示するをご覧ください。
- 階層型セキュリティ ポリシーは、リソース階層のノード間で移動できます。これは、フォルダ構造を再編成する場合に行うことがあります。
- フォルダやプロジェクトなどのリソース階層ノードを削除すると、そのノードに接続されている階層型セキュリティ ポリシーは、そのリソース階層ノードの下に作成されている場合にのみ削除されます。
- セキュリティ ポリシーを別の場所で作成してからノードに移動した場合、セキュリティ ポリシーは削除されません。
- 階層型セキュリティ ポリシーが誤って削除されないようにするには、既存のノードを削除する前に、保持する階層型セキュリティ ポリシーを別のリソース階層ノードに移動することをおすすめします。
ルールの評価順序
Google Cloud Armor は、セキュリティ ポリシーを次の順序で評価します。
- 組織レベルの階層型セキュリティ ポリシー
- フォルダレベルの階層型セキュリティ ポリシー（親フォルダから各サブフォルダに進む）
- プロジェクト レベルの階層型セキュリティ ポリシー
- サービスレベルのセキュリティ ポリシー
このルールの評価順序では、優先度の低い階層型セキュリティ ポリシーが、優先度の高いサービスレベル セキュリティ ポリシーの前に評価される場合があります。既存の優先度の高いサービスレベルのセキュリティ ポリシー ルールについて慎重に検討し、階層型セキュリティ ポリシーによって許可または拒否されたリクエストが Google Cloud Armor によって評価されない場合にどうなるかを検討してください。
goto_next アクション
Google Cloud Armor には、階層型セキュリティ ポリシー専用のルール アクション（goto_next アクション）があります。Google Cloud Armor がこのアクションを適用すると、現在のセキュリティ ポリシー内のルールの評価が停止し、次のセキュリティ ポリシー内のルールの評価が開始されます。
組織全体でリクエストを制限するために使用する多くのルールを含む、組織レベルの階層型セキュリティ ポリシーがある場合について考えてみましょう。特定の IP アドレス範囲からのリクエストで、これらの組織全体のルールの評価をスキップできるようにするには、アクション goto_next を使用して、その IP アドレス範囲に一致する最優先ルールを作成します。その IP アドレス範囲からのリクエストは、まずこのルールに対して評価されます。一致条件を満たしているため、この組織レベルの階層型セキュリティ ポリシーの他のルールに対しては評価されません。
同じ例で、goto_next アクションの代わりに allow アクションまたは deny アクションを使用した場合、一致条件が満たされるとすぐにリクエストが許可または拒否されます。この階層型評価では、そのリクエストに対して追加のセキュリティ ポリシーが評価されません。
Google Cloud Armor Enterprise の登録と課金動作
階層型セキュリティ ポリシーを接続する場合、階層型セキュリティ ポリシーを継承する各プロジェクトは Cloud Armor Enterprise に登録されている必要があります。これには、明示的に除外されていない階層型セキュリティ ポリシーが適用されている組織またはフォルダ内のすべてのプロジェクトと、階層型セキュリティ ポリシーがプロジェクトに直接接続されているすべてのプロジェクトが含まれます。
- Cloud Armor Enterprise Annual のサブスクリプションがある Cloud 請求先アカウントにリンクされているプロジェクトは、まだ登録されていない場合、Cloud Armor Enterprise Annual に自動的に登録されます。
- Cloud Armor Enterprise Annual サブスクリプションがない場合、プロジェクトは階層型セキュリティ ポリシーを継承すると、Cloud Armor Enterprise Paygo に自動的に登録されます。プロジェクトが Cloud Armor Enterprise Paygo に自動的に登録された後に、請求先アカウントを Cloud Armor Enterprise Annual に登録しても、プロジェクトは自動的に Annual に登録されません。Cloud Armor Enterprise Paygo の詳細については、Google Cloud Armor Standard と Cloud Armor Enterprise の比較をご覧ください。
- プロジェクトが Cloud Armor Enterprise に自動的に登録された後に、階層型セキュリティ ポリシーを更新してプロジェクトを除外しても、プロジェクトは自動的に登録解除されません。プロジェクトを手動で登録解除するには、Cloud Armor Enterprise からプロジェクトを削除するをご覧ください。
- 継承された階層型セキュリティ ポリシーが存在する間は、Cloud Armor Enterprise からプロジェクトを削除できません。
制限事項
階層型セキュリティ ポリシーには次の制限があります。
- 階層型セキュリティ ポリシーは、組織に属していないプロジェクトでは使用できません。
- 新規または最近復元されたプロジェクトの場合、プロジェクトで継承されたセキュリティ ポリシーが反映されるまでに数時間かかることがあります。
- Compute Engine API を最近有効にしたプロジェクトでは、このプロジェクトの継承されたセキュリティ ポリシーが伝播されるまでに数時間かかることがあります。
- 所有する階層型セキュリティ ポリシーで事前構成された WAF ルールをチューニングできますが、階層型セキュリティ ポリシーを継承するサービスのオーナーはルールのチューニングを実行できません。