Hierarchische Sicherheitsrichtlinien sind eine Kategorie von Sicherheitsrichtlinien, die die Reichweite der Web Application Firewall (WAF) und des DDoS-Schutzes von Google Cloud Armor über einzelne Projekte hinaus erweitern. Sie werden auf Organisations-, Ordner- oder Projektebene angehängt. Diese unterscheiden sich von Sicherheitsrichtlinien auf Dienstebene, die direkt an Backend-Dienste oder Backend-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. Dies ermöglicht eine zentrale und konsistente Sicherheitserzwingung in Ihrer Google Cloud -Umgebung.
Auf dieser Seite wird erläutert, wie sich hierarchische Sicherheitsrichtlinien von Sicherheitsrichtlinien auf Dienstebene unterscheiden. Bevor Sie fortfahren, lesen Sie die Übersicht über Sicherheitsrichtlinien, um zu verstehen, wie Sicherheitsrichtlinien funktionieren. Außerdem empfehlen wir, 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 bewältigen:
- Zentralisierte Kontrolle: Administratoren auf Organisations- und Ordnerebene können Sicherheitsrichtlinien für mehrere Projekte definieren und erzwingen.
- Konsistenz: Sie sorgen für einen einheitlichen Sicherheitsstatus im gesamten Unternehmen und reduzieren so das Risiko von Fehlkonfigurationen und Sicherheitslücken.
- Effizienz: Optimieren Sie die Bereitstellung von Sicherheitsupdates und Maßnahmen, z. B. das Blockieren bestimmter IP-Adressbereiche oder das Beheben kritischer Sicherheitslücken, für eine große Anzahl von Ressourcen gleichzeitig.
- Delegierung: Ermöglicht die Delegierung von Sicherheitsverantwortlichkeiten an verschiedene Teams oder Abteilungen, indem Richtlinien auf den entsprechenden Ebenen der Hierarchie angewendet werden.
Sie können diese allgemeinen Prinzipien anwenden und kombinieren, um sie an die Anforderungen Ihrer Organisation anzupassen. Hier einige Beispiele für Anwendungsfälle:
- Organisationsweite Blockierung von IP-Adressen: Sie können Traffic von bekannten bösartigen IP-Adressbereichen in allen Projekten Ihrer Organisation blockieren.
- Geografische Einschränkungen: Sie können Traffic aus bestimmten geografischen Regionen auf Organisations- oder Ordnerebene einschränken.
- CVE-Risikominderung: Sie können schnell WAF-Regeln bereitstellen, um kritische Sicherheitslücken in mehreren Projekten zu minimieren.
- Compliance-Erzwingung: Sie können die Einhaltung gesetzlicher Anforderungen erzwingen, indem Sie in Ihrer gesamten Organisation einheitliche Sicherheitsrichtlinien 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 Cloud Armor-Features verglichen, die Sie mit hierarchischen Sicherheitsrichtlinien und Sicherheitsrichtlinien auf Dienstebene verwenden können:
| Frontend-Typ |
|
|
| Anhangspunkt (geschützte Ressource) | Backend-Dienst | Knoten der Ressourcenhierarchie |
| Regelaktionen |
|
|
| Client-IP-Adresse | ||
| Geografische Region des Clients | ||
| ASN des Clients | ||
| Ratenbegrenzung | ||
| TLS-Fingerprinting (JA3 und JA4) | ||
| Bot-Verwaltung | (nur EXTERNAL_302 und Anfragegestaltung) |
|
| HTTP-Filterung | ||
| Körperfilterung | ||
| WAF | ||
| Verwaltete Regeln | ||
| 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, erstellen Sie sie auf Organisations- oder Ordnerebene. Diese Ressource ist dann Inhaber der hierarchischen Sicherheitsrichtlinie. Nachdem Sie eine hierarchische Sicherheitsrichtlinie erstellt haben, werden die Regeln der Sicherheitsrichtlinie auf keine Ihrer Ressourcen angewendet.
Als Nächstes verknüpfen Sie die hierarchische Sicherheitsrichtlinie mit einer Organisation, einem Ordner oder einem Projekt. Dies kann dieselbe Ressource sein, die die Richtlinie besitzt. 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. In der folgenden Liste finden Sie grundlegende Anwendungsfälle für jede Ressource, die Ihnen bei der Entscheidung helfen, an welche Ressource Sie Ihre hierarchischen Sicherheitsrichtlinien anhängen sollten:
- Organisation: Betrachten Sie hierarchische Sicherheitsrichtlinien auf Organisationsebene als Standardtyp für hierarchische Sicherheitsrichtlinien.
Diese Richtlinien haben umfassende IAM-Berechtigungen (Identity and Access Management) und gelten für alle Knoten unter der Organisation. Geben Sie diese Ressourcen mit dem Flag
--organizationwährend der Verknüpfung an. - Ordner: Verwenden Sie diese hierarchischen Sicherheitsrichtlinien, wenn Sie dieselben Sicherheitsrichtlinienregeln auf mehrere Projekte, aber nicht auf Ihre gesamte Organisation anwenden möchten. Geben Sie diese Ressourcen mit dem Flag
--folderwährend der Verknüpfung an. - Projekt: Verwenden Sie diesen Typ von hierarchischer Sicherheitsrichtlinie, wenn Sie dieselben Sicherheitsrichtlinienregeln auf alle Ressourcen in einem Projekt anwenden müssen, z. B. eine IP-Adressen-Sperrliste auf mehrere Backend-Dienste.
Geben Sie diese Ressourcen mit dem Flag
--projectwährend der Verknüpfung an. - Dienstebene: Verwenden Sie Sicherheitsrichtlinien auf Dienstebene, wenn Sie eindeutige Sicherheitsrichtlinienregeln benötigen, die sich von Ihren Diensten unterscheiden. Bei jeder Sicherheitsrichtlinie auf Dienstebene werden die Regeln nur auf die Backend-Richtlinie angewendet, an die sie angehängt ist. Geben Sie diese Ressourcen mit dem Flag
--project-numberan.
Sie können pro hierarchischer Sicherheitsrichtlinie nur eines dieser Flags verwenden. Die restlichen Flags wie --name oder --type geben Sie wie bei der Konfiguration einer Sicherheitsrichtlinie auf Dienstebene an. In der folgenden Liste finden Sie weitere Informationen zur Funktionsweise hierarchischer Sicherheitsrichtlinien:
- Wenn eine hierarchische Sicherheitsrichtlinie mit einem Knoten in der Ressourcenhierarchie verknüpft ist, übernehmen alle geschützten Ressourcen, die sich in der Hierarchie unter diesem Knoten befinden, die Richtlinie.
- Sie können die Sicherheitsrichtlinien aufrufen, 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 wirksamen Cloud Armor-Regeln für eine geschützte Ressource ansehen.
- Sie können hierarchische Sicherheitsrichtlinien von einem Ressourcenhierarchieknoten zu einem anderen verschieben. Dies kann sinnvoll sein, wenn Sie Ihre 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.
- Damit Ihre hierarchischen Sicherheitsrichtlinien nicht versehentlich gelöscht werden, empfehlen wir, alle hierarchischen Sicherheitsrichtlinien, die Sie behalten möchten, in einen anderen Ressourcenhierarchieknoten zu verschieben, bevor Sie den vorhandenen Knoten löschen.
Regelauswertungsreihenfolge
Cloud Armor wertet Sicherheitsrichtlinien in der folgenden Reihenfolge aus:
- Hierarchische Sicherheitsrichtlinien auf Organisationsebene
- Hierarchische Sicherheitsrichtlinien auf Ordnerebene (beginnend mit dem übergeordneten Ordner, dann weiter zu jedem Unterordner)
- Hierarchische Sicherheitsrichtlinien auf Projektebene
- 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, welche Sicherheitsrichtlinienregeln auf Dienstebene mit hoher Priorität Sie haben und was passiert, wenn Cloud Armor eine Anfrage, die durch eine hierarchische Sicherheitsrichtlinie zugelassen oder abgelehnt wird, nicht anhand dieser Regeln auswertet.
Die Aktion goto_next
Cloud Armor hat eine Regelaktion, die nur für hierarchische Sicherheitsrichtlinien gilt: die Aktion goto_next. Wenn Cloud Armor diese Aktion anwendet, wird die Auswertung von Regeln innerhalb der aktuellen Sicherheitsrichtlinie beendet und die Auswertung von Regeln in der nächsten Sicherheitsrichtlinie gestartet.
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, die aus einem bestimmten IP-Adressbereich stammen, die Auswertung dieser organisationsweiten Regeln überspringen. Daher erstellen Sie eine Regel mit höchster Priorität, die mit der Aktion goto_next auf diesen IP-Adressbereich angewendet wird. Die Anfragen aus diesem IP-Adressbereich werden zuerst anhand dieser Regel ausgewertet. Da sie die Übereinstimmungsbedingung erfüllen, werden sie nicht anhand anderer Regeln in dieser hierarchischen Sicherheitsrichtlinie auf Organisationsebene ausgewertet.
Wenn Sie im selben Beispiel eine allow- oder deny-Aktion anstelle der goto_next-Aktion verwendet haben, wird die Anfrage zugelassen oder abgelehnt, sobald die Übereinstimmungsbedingung erfüllt ist. Diese Bewertung auf Organisationsebene bedeutet, dass keine zusätzlichen Sicherheitsrichtlinien für diese Anfrage ausgewertet werden.
Registrierung und Abrechnung für Google Cloud Armor Enterprise
Wenn Sie eine hierarchische Sicherheitsrichtlinie anhängen, muss jedes Projekt, 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 mit einer hierarchischen Sicherheitsrichtlinie, die direkt an das Projekt angehängt ist.
- Projekte, die mit einem Cloud-Rechnungskonto mit einem Abo für Cloud Armor Enterprise Annual verknüpft sind, werden automatisch für Cloud Armor Enterprise Annual registriert, wenn sie nicht bereits registriert sind.
- Ohne ein Cloud Armor Enterprise-Jahresabo werden Projekte automatisch bei 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 Cloud Armor Standard im Vergleich zu Cloud Armor Enterprise.
- Wenn Sie eine hierarchische Sicherheitsrichtlinie aktualisieren, um ein Projekt nach der automatischen Registrierung in Cloud Armor Enterprise auszuschließen, wird das Projekt nicht automatisch abgemeldet. 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, wenn es geerbte hierarchische Sicherheitsrichtlinien hat.
Die automatische Registrierung kann bis zum nächsten Arbeitstag 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. Die neue Projektstufe wird auch in derGoogle Cloud Console angezeigt.
Projekte werden nur dann automatisch registriert, wenn mindestens ein Backend-Dienst für globale externe Load Balancer HTTP, HTTPS, HTTP2, H2C oder GRPC verwendet.
Beschränkungen
Für hierarchische Sicherheitsrichtlinien gelten die folgenden Einschränkungen:
- Hierarchische Sicherheitsrichtlinien sind für Projekte, die sich nicht in einer Organisation befinden, nicht verfügbar.
- Bei neuen oder kürzlich wiederhergestellten Projekten kann es einige Stunden dauern, bis alle übernommenen Sicherheitsrichtlinien für das Projekt wirksam werden.
- Bei einem Projekt, für das die Compute Engine API vor Kurzem aktiviert wurde, kann es einige Stunden dauern, bis alle übernommenen Sicherheitsrichtlinien für dieses Projekt wirksam werden.
- Sie können vorkonfigurierte WAF-Regeln in hierarchischen Sicherheitsrichtlinien optimieren, deren Inhaber Sie sind. Die Inhaber von Diensten, die eine hierarchische Sicherheitsrichtlinie übernehmen, können jedoch keine Regeloptimierung vornehmen.