Hierarchische Sicherheitsrichtlinien – Übersicht

Hierarchische Sicherheitsrichtlinien sind eine Kategorie von Sicherheitsrichtlinien, die die Reichweite der Google Cloud Armor Web Application Firewall (WAF) und des DDoS-Schutzes über einzelne Projekte hinaus erweitern. Sie werden auf Organisations-, Ordner- oder Projektebene angehängt. Sie unterscheiden sich von Sicherheitsrichtlinien auf Dienstebene, die direkt an Back-End-Dienste oder Back-End-Buckets angehängt werden.

Wenn Sie eine hierarchische Sicherheitsrichtlinie auf Organisations- oder Ordnerebene konfigurieren, wird sie von Projekten auf niedrigeren Hierarchieebenen übernommen. Durch diese Übernahme können Sie Regeln für Sicherheitsrichtlinien einrichten, die auf alle oder mehrere Projekte in Ihrer Organisation angewendet werden sollen. So kann die Sicherheit in Ihrer Google Cloud Umgebung zentral und einheitlich durchgesetzt werden.

Auf dieser Seite wird erläutert, wie sich hierarchische Sicherheitsrichtlinien von Sicherheitsrichtlinien auf Dienstebene unterscheiden. Lesen Sie zuerst die Übersicht über Sicherheitsrichtlinien, um sich mit der Funktionsweise von Sicherheitsrichtlinien vertraut zu machen. Außerdem empfehlen wir Ihnen, sich mit der Ressourcenhierarchie vertraut zu machen.

Anwendungsfälle

In großen Organisationen kann die Verwaltung von Sicherheitsrichtlinien für zahlreiche Projekte komplex und zeitaufwendig sein. Hierarchische Sicherheitsrichtlinien bieten die folgenden Vorteile, um diese Herausforderungen zu meistern:

  • Zentrale Steuerung: Administratoren auf Organisations- und Ordnerebene können Sicherheitsrichtlinien für mehrere Projekte definieren und erzwingen.
  • Konsistenz: Einheitliche Sicherheitslage in der gesamten Organisation, wodurch das Risiko von Fehlkonfigurationen und Sicherheitslücken verringert wird.
  • Effizienz: Die Bereitstellung von Sicherheitsupdates und ‑maßnahmen, z. B. das Blockieren bestimmter IP-Adressbereiche oder das Beheben kritischer Sicherheitslücken, kann gleichzeitig für eine große Anzahl von Ressourcen optimiert werden.
  • Delegierung: Sie können die Sicherheitsverantwortung an verschiedene Teams oder Abteilungen delegieren, indem Sie Richtlinien auf den entsprechenden Ebenen der Hierarchie anwenden.

Sie können diese allgemeinen Grundsätze anwenden und kombinieren, um sie an die Anforderungen Ihrer Organisation anzupassen. Hier einige Beispiele:

  • Organisationsweites Blockieren von IP-Adressen: Sie können Traffic aus bekannten schädlichen IP-Adressbereichen in allen Projekten Ihrer Organisation blockieren.
  • Geografiebasierte Einschränkungen: Sie können den Traffic aus bestimmten geografischen Regionen auf Organisations- oder Ordnerebene einschränken.
  • CVE-Minderung: Sie können schnell WAF-Regeln bereitstellen, um kritische Sicherheitslücken in mehreren Projekten zu beheben.
  • Compliance-Durchsetzung: Sie können die Einhaltung von behördlichen Anforderungen erzwingen, indem Sie einheitliche Sicherheitsrichtlinien in Ihrer gesamten Organisation anwenden.
  • Detaillierte Zugriffssteuerung: Sie können bestimmten IP-Adressbereichen oder geografischen Regionen Zugriff auf alle Ressourcen in einem bestimmten Ordner gewähren.

Features

Hierarchische Sicherheitsrichtlinien unterstützen eine Teilmenge der Funktionen, die von Sicherheitsrichtlinien auf Dienstebene unterstützt werden. In der folgenden Tabelle werden die Google Cloud Armor-Funktionen verglichen, die Sie mit hierarchischen Sicherheitsrichtlinien und Sicherheitsrichtlinien auf Dienstebene verwenden können:

Globale Backend-Sicherheitsrichtlinie auf Serviceebene
Hierarchische Backend-Sicherheitsrichtlinie
Frontend-Typ
  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer
  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer
Anhangspunkt (geschützte Ressource) Backend-Dienst Knoten der Ressourcenhierarchie
Regelaktionen
  • Zulassen
  • Ablehnen
  • Weiterleitung (GOOGLE_RECAPTCHA und EXTERNAL_302)
  • Drosseln
  • Ratenbasierte Sperre
  • Zulassen
  • Ablehnen
  • Weiterleitung (nur EXTERNAL_302)
  • Zu nächster
Quell-IP-Adresse
Quellgeografie
Quell-ASN
Bot-Verwaltung (nur EXTERNAL_302 und Anfrage-Dekoration)
Layer 7-Filterung
WAF
Google Threat Intelligence
reCAPTCHA
Adaptive Protection
Adressgruppen
Adressgruppen auf Organisationsebene
Security Command Center
Cloud Monitoring
Anfrage-Logging

Funktionsweise hierarchischer Sicherheitsrichtlinien

Wenn Sie eine hierarchische Sicherheitsrichtlinie erstellen, tun Sie dies auf Organisations- oder Ordnerebene. Die entsprechende Ressource ist dann Eigentümer der hierarchischen Sicherheitsrichtlinie. Nachdem Sie eine hierarchische Sicherheitsrichtlinie erstellt haben, werden die Regeln für Sicherheitsrichtlinien nicht auf Ihre Ressourcen angewendet.

Als Nächstes verknüpfen Sie die hierarchische Sicherheitsrichtlinie mit einer Organisation, einem Ordner oder einem Projekt. Das kann dieselbe Ressource sein, zu der die Richtlinie gehört. Nachdem Sie eine hierarchische Sicherheitsrichtlinie mit einer Ressource verknüpft haben, werden die Regeln der Sicherheitsrichtlinie auf die geschützten Ressourcen auf und unter diesem Knoten in der Ressourcenhierarchie angewendet. Die folgende Liste enthält grundlegende Anwendungsfälle für jede Ressource, damit Sie entscheiden können, an welche Ressource Sie Ihre hierarchischen Sicherheitsrichtlinien anhängen sollten:

  • Organisation: Hierarchische Sicherheitsrichtlinien auf Organisationsebene sind der Standardtyp von hierarchischen Sicherheitsrichtlinien. Diese Richtlinien haben umfassende IAM-Berechtigungen (Identity and Access Management) und gelten für alle Knoten unter der Organisation. Geben Sie diese Ressourcen bei der Zuordnung mit dem Flag --organization an.
  • Ordner: Verwenden Sie diese hierarchischen Sicherheitsrichtlinien, wenn Sie dieselben Regeln für Sicherheitsrichtlinien auf mehrere Projekte, aber nicht auf Ihre gesamte Organisation anwenden möchten. Geben Sie diese Ressourcen bei der Verknüpfung mit dem Flag --folder an.
  • Projekt: Verwenden Sie diesen Typ von hierarchischer Sicherheitsrichtlinie, wenn Sie dieselben Regeln für Sicherheitsrichtlinien auf alle Ressourcen in einem Projekt anwenden müssen, z. B. eine IP-Adressen-Denylist auf mehrere Back-End-Dienste. Geben Sie diese Ressourcen bei der Zuordnung mit dem Flag --project an.
  • Dienstebene: Verwenden Sie Sicherheitsrichtlinien auf Dienstebene, wenn Sie eindeutige Sicherheitsrichtlinienregeln benötigen, die sich für die einzelnen Dienste unterscheiden. Die Regeln einer Sicherheitsrichtlinie auf Dienstebene werden nur auf die Backend-Richtlinie angewendet, an die sie angehängt ist. Geben Sie diese Ressourcen mit dem Flag --project-number an.

Sie können nur eines dieser Flags pro hierarchischer Sicherheitsrichtlinie verwenden. Die restlichen Flags, z. B. --name oder --type, geben Sie wie bei der Konfiguration einer Sicherheitsrichtlinie auf Dienstebene an. Weitere Informationen zur Funktionsweise hierarchischer Sicherheitsrichtlinien finden Sie in der folgenden Liste:

  • Wenn eine hierarchische Sicherheitsrichtlinie einem Knoten in der Ressourcenhierarchie zugeordnet ist, wird sie von allen geschützten Ressourcen unterhalb dieses Knotens in der Hierarchie übernommen.
  • Sie können die Sicherheitsrichtlinien ansehen, die für jede geschützte Ressource in einem Projekt gelten, und zwar für alle hierarchischen Sicherheitsrichtlinien und Sicherheitsrichtlinien auf Dienstebene. Weitere Informationen finden Sie unter Alle effektiven Google Cloud Armor-Regeln für eine geschützte Ressource ansehen.
  • Sie können hierarchische Sicherheitsrichtlinien von einem Knoten der Ressourcenhierarchie in einen anderen verschieben. Das kann sinnvoll sein, wenn Sie die Ordnerstruktur neu organisieren möchten.
  • Wenn Sie einen Knoten in der Ressourcenhierarchie löschen, z. B. einen Ordner oder ein Projekt, wird die an diesen Knoten angehängte hierarchische Sicherheitsrichtlinie nur gelöscht, wenn Sie sie unter diesem Knoten in der Ressourcenhierarchie erstellt haben.
    • Wenn Sie die Sicherheitsrichtlinie an anderer Stelle erstellt und dann unter den Knoten verschoben haben, wird sie nicht gelöscht.
    • Um ein versehentliches Löschen Ihrer hierarchischen Sicherheitsrichtlinien zu vermeiden, empfehlen wir, alle hierarchischen Sicherheitsrichtlinien, die Sie behalten möchten, in einen anderen Knoten der Ressourcenhierarchie zu verschieben, bevor Sie den vorhandenen Knoten löschen.

Regelauswertungsreihenfolge

Google Cloud Armor wertet Sicherheitsrichtlinien in der folgenden Reihenfolge aus:

  1. Hierarchische Sicherheitsrichtlinien auf Organisationsebene
  2. Hierarchische Sicherheitsrichtlinien auf Ordnerebene (beginnend mit dem übergeordneten Ordner, dann mit jedem Unterordner)
  3. Hierarchische Sicherheitsrichtlinien auf Projektebene
  4. Sicherheitsrichtlinien auf Dienstebene

Diese Reihenfolge der Regelauswertung bedeutet, dass Sie möglicherweise eine hierarchische Sicherheitsrichtlinie mit niedriger Priorität haben, die vor einer Sicherheitsrichtlinie auf Dienstebene mit hoher Priorität ausgewertet wird. Überlegen Sie sich genau, wie sich die vorhandenen Dienstebene-Sicherheitsrichtlinienregeln mit hoher Priorität auswirken, und was passiert, wenn Google Cloud Armor eine Anfrage, die durch eine hierarchische Sicherheitsrichtlinie zugelassen oder abgelehnt wird, nicht anhand dieser Regeln auswertet.

Die Aktion goto_next

Google Cloud Armor hat eine Regelaktion, die ausschließlich für hierarchische Sicherheitsrichtlinien gilt: die Aktion goto_next. Wenn Google Cloud Armor diese Aktion anwendet, werden die Regeln in der aktuellen Sicherheitsrichtlinie nicht mehr ausgewertet und die Auswertung der Regeln in der nächsten Sicherheitsrichtlinie beginnt.

Angenommen, Sie haben eine hierarchische Sicherheitsrichtlinie auf Organisationsebene mit vielen Regeln, mit denen Sie Anfragen in Ihrer gesamten Organisation einschränken möchten. Sie möchten, dass Anfragen aus einem bestimmten IP-Adressbereich die Auswertung dieser organisationsweiten Regeln überspringen. Daher erstellen Sie eine Regel mit höchster Priorität, die mit diesem IP-Adressbereich übereinstimmt und die Aktion goto_next hat. Die Anfragen aus diesem IP-Adressbereich werden zuerst anhand dieser Regel ausgewertet. Da sie die Abgleichsbedingung erfüllen, werden sie nicht anhand anderer Regeln in dieser hierarchischen Sicherheitsrichtlinie auf Organisationsebene ausgewertet.

Wenn Sie im selben Beispiel anstelle der goto_next-Aktion eine allow- oder deny-Aktion verwendet haben, wird die Anfrage zugelassen oder abgelehnt, sobald die Bedingung für die Übereinstimmung erfüllt ist. Diese hierarchische Bewertung bedeutet, dass für diese Anfrage keine zusätzlichen Sicherheitsrichtlinien ausgewertet werden.

Registrierung und Abrechnung von Google Cloud Armor Enterprise

Wenn Sie eine hierarchische Sicherheitsrichtlinie anhängen, muss jedes der Projekte, das die hierarchische Sicherheitsrichtlinie übernimmt, bei Cloud Armor Enterprise registriert sein. Dazu gehören alle Projekte in einer Organisation oder einem Ordner mit einer hierarchischen Sicherheitsrichtlinie, die nicht explizit ausgeschlossen sind, sowie alle Projekte, an die eine hierarchische Sicherheitsrichtlinie direkt angehängt ist.

  • Projekte, die mit einem Cloud-Rechnungskonto mit einem Jahresabo für Cloud Armor Enterprise verknüpft sind, werden automatisch für Cloud Armor Enterprise Annual registriert, sofern sie nicht bereits registriert sind.
  • Ohne ein Cloud Armor Enterprise-Jahresabo werden Projekte automatisch für Cloud Armor Enterprise Paygo registriert, wenn sie eine hierarchische Sicherheitsrichtlinie übernehmen. Wenn Sie das Rechnungskonto für Cloud Armor Enterprise Annual abonnieren, nachdem Ihr Projekt automatisch für Cloud Armor Enterprise Paygo registriert wurde, wird das Projekt nicht automatisch für Annual registriert. Weitere Informationen zu Cloud Armor Enterprise Paygo finden Sie unter Google Cloud Armor Standard im Vergleich zu Cloud Armor Enterprise.
  • Wenn Sie eine hierarchische Sicherheitsrichtlinie aktualisieren, um ein Projekt nach der automatischen Registrierung des Projekts bei Cloud Armor Enterprise auszuschließen, wird die Registrierung des Projekts nicht automatisch aufgehoben. Informationen zum manuellen Abmelden Ihres Projekts finden Sie unter Projekt aus Cloud Armor Enterprise entfernen.
  • Sie können ein Projekt nicht aus Cloud Armor Enterprise entfernen, solange es geerbte hierarchische Sicherheitsrichtlinien hat.

Die automatische Registrierung kann bis zu einer Woche dauern. Während dieser Zeit sind Ihre hierarchischen Sicherheitsrichtlinien wirksam und es fallen keine Cloud Armor Enterprise-Kosten an. Wenn Ihr Projekt registriert ist, werden die Audit-Logs aktualisiert, um den Cloud Armor Enterprise-Status des Projekts widerzuspiegeln. Der neue Projekttarif wird in der Google Cloud Console angezeigt.

Beschränkungen

Für hierarchische Sicherheitsrichtlinien gelten die folgenden Einschränkungen:

  • Hierarchische Sicherheitsrichtlinien sind nicht für Projekte verfügbar, die nicht Teil einer Organisation sind.
  • Bei neuen oder kürzlich wiederhergestellten Projekten kann es einige Stunden dauern, bis alle geerbten Sicherheitsrichtlinien für das Projekt übernommen werden.
  • Bei einem Projekt, für das die Compute Engine API vor Kurzem aktiviert wurde, kann es einige Stunden dauern, bis alle geerbten Sicherheitsrichtlinien für dieses Projekt übernommen werden.
  • Sie können vorkonfigurierte WAF-Regeln in hierarchischen Sicherheitsrichtlinien, die Ihnen gehören, optimieren. Die Inhaber von Diensten, die eine hierarchische Sicherheitsrichtlinie übernehmen, können jedoch keine Regeloptimierung vornehmen.

Nächste Schritte