Übersicht über die Sicherheitsrichtlinien

Auf dieser Seite wird beschrieben, wie Sie Google Cloud Armor-Sicherheitsrichtlinien zum Schutz Ihrer Google Cloud-Bereitstellungen verwenden können.

Google Cloud Armor-Sicherheitsrichtlinien schützen Ihre Anwendung, indem sie Layer-7-Filter bereitstellen und eingehende Anfragen für gängige Webangriffe oder andere Layer-7-Attribute bereinigen, um möglicherweise den Traffic zu blockieren, bevor er Ihre Back-End-Dienste oder Back-End-Buckets mit Load-Balancing erreicht. Jede Sicherheitsrichtlinie setzt sich aus einer Reihe von Regeln zusammen, die Traffic anhand von Bedingungen filtern, z. B. IP-Adresse, IP-Bereich, Regionscode oder Anfrageheader einer eingehenden Anfrage.

Google Cloud Armor-Sicherheitsrichtlinien sind für die folgenden Load-Balancer- und Endpunkttypen verfügbar:

  • Globaler externer Application Load Balancer (HTTP/HTTPS)
  • Klassischer Application Load Balancer (HTTP/HTTPS)
  • Regionaler externer Application Load Balancer (HTTP/HTTPS)
  • Globaler externer Proxy-Network Load Balancer (TCP/SSL)
  • Klassischer Proxy-Network Load Balancer (TCP/SSL)
  • Externer Passthrough-Network Load Balancer (TCP/UDP)
  • Protokollweiterleitung
  • VMs mit öffentlichen IP-Adressen

Der Load-Balancer kann sich in der Premium- oder Standard-Stufe befinden.

Die Backends für den Backend-Dienst können beliebige der folgenden sein:

Wenn Sie Google Cloud Armor zum Schutz einer Hybridbereitstellung oder einer Multi-Cloud-Architektur verwenden, müssen die Back-Ends Internet-NEGs sein. Google Cloud Armor schützt auch serverlose NEGs, wenn der Traffic über einen Load-Balancer geleitet wird. Wie Sie sicherstellen, dass nur Traffic, der über den Load-Balancer geleitet wurde, die serverlose NEG erreicht, erfahren Sie unter Steuerelemente für eingehenden Traffic.

Google Cloud Armor bietet außerdem erweiterten DDoS-Schutz für Netzwerke für externe Passthrough-Network Load Balancer, Protokollweiterleitung und VMs mit öffentlichen IP-Adressen. Weitere Informationen zum erweiterten DDoS-Schutz finden Sie unter Erweiterten DDoS-Schutz konfigurieren.

Google Cloud-Bereitstellungen mit Google Cloud Armor-Sicherheitsrichtlinien schützen

Externes Load-Balancing wird an den weltweiten Edge-Netzwerkstandorten von Google in Google Points of Presence (PoPs) implementiert. In der Premium-Stufe gelangt Traffic, der an einen externen Load-Balancer weitergeleitet wird, in den PoP, der dem Nutzer am nächsten ist. Anschließend wird Load-Balancing für das globale Google-Netzwerk auf dem nächstgelegenen Backend mit ausreichender Kapazität ausgeführt. In der Standard-Stufe gelangt Nutzertraffic über Peering, den ISP oder Transit-Netzwerke in die Google-Netzwerke der Region, in der Sie Ihre Google Cloud-Ressourcen bereitgestellt haben.

Mit den Sicherheitsrichtlinien von Google Cloud Armor können Sie Anfragen an Ihre Back-End-Dienste am Google Cloud-Edge so nahe wie möglich an der Quelle des eingehenden Traffics zulassen, ablehnen, begrenzen oder umleiten. Dies verhindert, dass unerwünschter Traffic Ressourcen verbraucht oder in Ihre VPC-Netzwerke (Virtual Private Cloud) gelangt.

Das folgende Diagramm zeigt den Standort von globalen externen Application Load Balancern, klassischen Application Load Balancern, dem Google-Netzwerk und Google-Rechenzentren.

Google Cloud Armor-Richtlinie am Netzwerkrand
Google Cloud Armor-Richtlinie am Netzwerkrand (zum Vergrößern klicken).

Voraussetzungen

Das sind die Anforderungen der Verwendung der Sicherheitsrichtlinien von Google Cloud Armor:

  • Der Load-Balancer muss ein globaler externer Application Load Balancer, ein klassischer Application Load Balancer, ein regionaler externer Application Load Balancer, ein globaler externer Proxy-Network Load Balancer oder ein klassischer Proxy-Network Load Balancer sein.
  • Das Load-Balancing-Schema des Back-End-Dienstes muss EXTERNAL oder EXTERNAL_MANAGED sein.
  • Das Protokoll des Back-End-Dienstes muss entweder HTTP, HTTPS, HTTP/2, UDP, TCP, SSL oder UNSPECIFIED sein.

Informationen zu Google Cloud Armor-Sicherheitsrichtlinien

Google Cloud Armor-Sicherheitsrichtlinien sind Regeln, die Attribute von Layer 3 zu Layer 7 abgleichen, um externe Anwendungen oder Dienste zu schützen. Jede Regel wird im Hinblick auf den eingehenden Traffic ausgewertet.

Eine Google Cloud Armor-Sicherheitsrichtlinienregel besteht aus einer Abgleichsbedingung und einer Aktion, die ausgeführt werden muss, wenn diese Bedingung erfüllt ist. Die Bedingungen können so einfach sein wie die Frage, ob die Quell-IP-Adresse des eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt (Regeln für Listen zum Zulassen und Sperren von IP-Adressen). Alternativ können Sie mithilfe der Referenz zur Sprache für benutzerdefinierte Regeln für Google Cloud Armor benutzerdefinierte Bedingungen erstellen, die mit verschiedenen Attributen des eingehenden Traffics übereinstimmen, z. B. den Werten für URL-Pfad, Anfragemethode oder Anfrageheader.

Wenn eine eingehende Anfrage eine Bedingung in einer Sicherheitsrichtlinienregel erfüllt, lässt Google Cloud Armor die Anfrage zu, lehnt sie ab oder leitet sie weiter, je nachdem, ob die Regel eine Zulassungsregel, eine Ablehnungsregel oder eine Weiterleitungsregel ist. Es können dabei zusätzliche Aktionsparameter angewendet werden, zum Beispiel Anfrageheader. Dieses Feature ist Teil der Google Cloud Armor-Bot-Verwaltung. Weitere Informationen zur Bot-Verwaltung finden Sie unter Übersicht über die Bot-Verwaltung.

Sie können eine Google Cloud Armor-Sicherheitsrichtlinie einem oder mehreren Back-End-Diensten zuordnen. Einem Back-End-Dienst kann nur eine Sicherheitsrichtlinie zugeordnet sein, aber Ihre Back-End-Dienste müssen nicht alle mit derselben Sicherheitsrichtlinie verknüpft sein.

Wenn eine Google Cloud Armor-Sicherheitsrichtlinie mit einem Back-End-Dienst verknüpft ist, kann sie nicht gelöscht werden. Ein Back-End-Dienst kann unabhängig davon gelöscht werden, ob ihm eine Sicherheitsrichtlinie zugeordnet ist.

Wenn mehrere Weiterleitungsregeln auf einen Back-End-Dienst verweisen, dem eine Sicherheitsrichtlinie zugeordnet ist, werden die Richtlinienregeln für den gesamten Traffic erzwungen, der an jeder IP-Adresse der Weiterleitungsregel eingeht.

In der folgenden Abbildung ist die Google Cloud Armor-Sicherheitsrichtlinie internal-users-policy dem Back-End-Dienst test-network zugeordnet.

Google Cloud Armor-Sicherheitsrichtlinie am Netzwerkrand
Google Cloud Armor-Sicherheitsrichtlinie am Netzwerkrand (zum Vergrößern klicken).

Google Cloud Armor-Sicherheitsrichtlinien haben die folgenden Features:

  • Sie können das QUIC-Protokoll optional mit Load-Balancern verwenden, die Google Cloud Armor nutzen.

  • Sie können Google Cloud Armor mit Load-Balancern verwenden, die sich in einer der folgenden Netzwerkdienststufen befinden:

    • Premium-Stufe
    • Standard-Stufe
  • Sie können Backend-Sicherheitsrichtlinien mit GKE und dem Standard-Ingress-Controller verwenden.

  • Sie können eine Standardsicherheitsrichtlinie verwenden, die den Traffic über einen benutzerdefinierten Schwellenwert drosselt, wenn Sie einen der folgenden Load-Balancer konfigurieren:

    • Globaler externer Application Load Balancer
    • Klassischer Application Load Balancer
    • Regionaler externer Application Load Balancer
    • Globaler externer Proxy-Network Load Balancer
    • Klassischer Proxy-Network Load Balancer
    • Externer Passthrough-Network Load Balancer

Außerdem können Sie mit Google Cloud Armor vorkonfigurierte WAF-Regeln konfigurieren. Dabei handelt es sich um komplexe WAF-Regeln (Web Application Firewall) mit Dutzenden von Signaturen, die aus Open-Source-Branchenstandards zusammengestellt wurden. Jede Signatur entspricht einer Angriffserkennungsregel im Regelsatz. Google bietet diese Regeln wie besehen an. Die Regeln ermöglichen es Google Cloud Armor, Dutzende von unterschiedlichen Traffic-Signaturen auszuwerten. Dabei bezieht sich Google Cloud Armor auf Regeln, die praktischerweise benannt sind, anstatt dass Sie jede Signatur manuell definieren müssen. Weitere Informationen zu vorkonfigurierten WAF-Regeln finden Sie in der Übersicht über die vorkonfigurierten WAF-Regeln.

Arten von Sicherheitsrichtlinien

In den folgenden Tabellen finden Sie die Arten von Sicherheitsrichtlinien und ihre Möglichkeiten. Ein Häkchen () gibt an, dass die Art der Sicherheitsrichtlinie das Feature unterstützt.

Back-End-Sicherheitsrichtlinien

Back-End-Sicherheitsrichtlinien werden mit Back-End-Diensten verwendet, die von den folgenden Load-Balancer-Typen bereitgestellt werden:

  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer
  • Regionaler externer Application Load Balancer
  • Globaler externer Proxy-Network Load Balancer
  • Klassischer Proxy-Network Load Balancer

Sie können verwendet werden, um Anfragen zu filtern und Back-End-Dienste zu schützen, die auf Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) verweisen, z. B. Internet-, zonale, hybride und serverlose NEGs. Nicht alle Load-Balancer unterstützen alle NEG-Typen. Weitere Informationen zu den NEGs, die Ihr Load-Balancer unterstützt, finden Sie in der Übersicht über Netzwerk-Endpunktgruppen.

Wenn Sie globale externe Proxy-Network Load Balancer oder klassische Proxy-Network Load Balancer verwenden, erzwingt Google Cloud Armor die Aktion deny der Sicherheitsrichtlinienregel nur für neue Verbindungsanfragen. Die Aktion deny beendet die TCP-Verbindung. Wenn Sie zusammen mit der Aktion deny einen Statuscode angeben, wird dieser ignoriert.

Backend-Sicherheitsrichtlinien haben den optionalen Flag-Wert type (CLOUD_ARMOR). Wenn Sie das Flag type nicht festlegen, wird der Standardwert CLOUD_ARMOR verwendet.

Edge-Sicherheitsrichtlinien

Mit Edge-Sicherheitsrichtlinien können Nutzer Filter- und Zugriffssteuerungsrichtlinien für Inhalte konfigurieren, die im Cache gespeichert sind. Dazu gehören auch Endpunkte wie Cloud CDN-fähige Back-End-Dienste und Cloud Storage-Buckets. Edge-Sicherheitsrichtlinien unterstützen das Filtern basierend auf einer Teilmenge von Parametern im Vergleich zu Backend-Sicherheitsrichtlinien. Sie können eine Edge-Sicherheitsrichtlinie nicht als Backend-Richtlinie festlegen. Edge-Sicherheitsrichtlinien werden für die folgenden Endpunkte unterstützt:

  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer

Edge-Sicherheitsrichtlinien können so konfiguriert werden, dass Anfragen gefiltert werden, bevor die Anfrage aus dem Cache von Google verarbeitet wird. Edge-Sicherheitsrichtlinien werden in der Nähe des äußersten Perimeters des Google-Netzwerks bereitgestellt und erzwungen, bevor sich der Cloud CDN-Cache befindet. Edge-Sicherheitsrichtlinien können gemeinsam mit Back-End-Sicherheitsrichtlinien für die Bereitstellung von zwei Sicherheitsebenen genutzt werden. Sie lassen sich beide gleichzeitig auf einen Back-End-Dienst anwenden, unabhängig von den Ressourcen, auf die der Back-End-Dienst verweist (z. B. Instanzgruppen oder Netzwerk-Endpunktgruppen). Auf Backend-Buckets können nur Edge-Sicherheitsrichtlinien angewendet werden.

Wenn Edge-Sicherheitsrichtlinien und Backend-Sicherheitsrichtlinien an denselben Backend-Dienst angehängt sind, werden Backend-Sicherheitsrichtlinien nur für Cache-Fehleranfragen erzwungen, die Edge-Sicherheitsrichtlinien bestanden haben.

Edge-Sicherheitsrichtlinien werden vor Identity-Aware Proxy (IAP) ausgewertet und erzwungen. Eine durch eine Edge-Sicherheitsrichtlinie blockierte Anfrage wird abgelehnt, bevor IAP die Identität des Anfragenden auswertet. Das Blockieren einer Anfrage mit einer Regel in der Edge-Sicherheitsrichtlinie verhindert, dass IAP eine Anmeldeseite bereitstellt oder auf andere Weise versucht, den Nutzer zu authentifizieren.

Edge-Sicherheitsrichtlinien haben den type-Flag-Wert CLOUD_ARMOR_EDGE.

Sicherheitsrichtlinien für Netzwerk-Edge

Mit Sicherheitsrichtlinien für Netzwerk-Edges können Sie Regeln konfigurieren, um Traffic am Rand des Google-Netzwerks zu blockieren. Das Erzwingen von Sicherheitsrichtlinien am Netzwerk-Edge verbraucht keine VM- oder Hostressourcen. Dadurch wird verhindert, dass sehr viel Traffic Ressourcen in der Zielarbeitslast erschöpft oder auf andere Weise einen Denial-of-Service verursacht. Sie können Sicherheitsrichtlinien für Netzwerk-Edges für die folgenden Ressourcen konfigurieren:

  • Externe Passthrough-Netzwerk-Load-Balancer
  • Protokollweiterleitung
  • VMs mit öffentlichen IP-Adressen

Sicherheitsrichtlinien für Netzwerk-Edges unterstützen das Filtern basierend auf einigen der gleichen Parameter wie Back-End-Sicherheitsrichtlinien. Sie sind der einzige Sicherheitsrichtlinientyp, der die Byte-Offset-Filterung unterstützt. In der Tabelle Arten von Sicherheitsrichtlinien finden Sie eine vollständige Liste der verfügbaren Parameter.

Sicherheitsrichtlinien des Netzwerk-Edges haben den type-Flag-Wert CLOUD_ARMOR_NETWORK. Zum Konfigurieren von Sicherheitsrichtlinien am Netzwerk-Edge müssen Sie zuerst den erweiterten DDoS-Schutz für Netzwerke in der Region konfigurieren, in der Sie die Richtlinien erstellen möchten. Weitere Informationen zum erweiterten DDoS-Schutz finden Sie unter Erweiterten DDoS-Schutz für Netzwerke konfigurieren.

Regelauswertungsreihenfolge

Die Reihenfolge der Regelauswertung wird anhand der Regelpriorität ermittelt, von der niedrigsten zur höchsten Nummer. Die Regel mit dem niedrigsten zugewiesenen numerischen Wert hat die höchste logische Priorität und wird vor Regeln mit niedrigeren logischen Prioritäten ausgewertet. Die minimale numerische Priorität ist 0. Die Priorität einer Regel nimmt ab, je höher ihre Nummer ist (1, 2, 3, N+1). Jede Priorität kann nur einer Regel zugewiesen werden. Für die Priorität jeder Regel muss ein Wert im Bereich von 0 bis 2147483646 festgelegt werden. Der Prioritätswert 2147483647, auch als INT-MAX bezeichnet, ist für die Standardregel reserviert.

Zwischen den Prioritätswerten dürfen Lücken liegen, sodass Sie auch später noch Regeln einfügen oder entfernen können, ohne dass sich dies auf die übrigen Regeln auswirkt. Beispielsweise ist 1, 2, 3, 4, 5, 9, 12, 16 eine gültige Reihe von Prioritätsnummern, der Sie in Zukunft Regeln mit den Nummern 6 bis 8, 10 bis 11 und 13 bis 15 hinzufügen können. Sie müssen die vorhandenen Regeln nur für die Reihenfolge der Ausführung ändern.

Normalerweise wird die Regel mit der höchsten Priorität angewendet, die der Anfrage entspricht. Es gibt jedoch eine Ausnahme, wenn HTTP POST-Anfragen anhand von vorkonfigurierten Regeln ausgewertet werden, die evaluatePreconfiguredExpr() verwenden. Und zwar folgende:

Bei HTTP POST-Anfragen empfängt Google Cloud Armor den Header der Anfrage vor dem Text (Nutzlast). Da Google Cloud Armor zuerst die Headerinformationen empfängt, werden Regeln ausgewertet, die mit dem Header übereinstimmen. Es werden jedoch keine vorkonfigurierten Regeln für den Text abgeglichen. Wenn es mehrere headerbasierte Regeln gibt, werden diese von Google Cloud Armor auf der Grundlage ihrer Priorität ausgewertet. Beachten Sie, dass redirect-Aktionen und das Einfügen benutzerdefinierter Header-Aktionen nur während der Header-Verarbeitungsphase funktionieren. Die Aktion redirect, wenn sie in der folgenden Textverarbeitungsphase zugeordnet wird, wird in eine deny-Aktion übersetzt. Die benutzerdefinierte Anfrageheaderaktion, die während der Textverarbeitungsphase abgeglichen wird, wird nicht wirksam.

Nachdem Google Cloud Armor den Text HTTP POST erhalten hat, werden die Regeln ausgewertet, die sowohl für den Anfrageheader als auch für den Anfragetext gelten. Infolgedessen ist es möglich, dass Regeln mit niedrigerer Priorität, die den Header einer Anfrage prüfen, vor Regeln mit höherer Priorität abgeglichen werden, die den Text der Anfrage prüfen. In diesem Fall kann es vorkommen, dass der HTTP-Header der Anfrage an den Ziel-Backend-Dienst gesendet, der Text POST mit potenziell schädlichen Inhalten jedoch blockiert wird. Google Cloud Armor prüft die ersten 8 KB des POST-Texts. Weitere Informationen zu dieser Einschränkung finden Sie unter Beschränkung der POST-Textprüfung.

Der Ausdruck evaluatePreconfiguredExpr() für vorkonfigurierte Regeln ist der einzige Ausdruck, der anhand des Anfragetexts ausgewertet wird. Alle anderen Ausdrücke werden nur anhand des Anfrageheaders ausgewertet. Von den HTTP-Anfragetypen mit einem Anfragetext verarbeitet Google Cloud Armor nur POST-Anfragen. Die Prüfung ist auf die ersten 8 KB des POST-Texts beschränkt und wird wie URL-Abfrageparameter decodiert. Google Cloud Armor kann vorkonfigurierte WAF-Regeln für JSON-formatierte POST-Texte (Content-Type = "application/json") parsen und anwenden. Google Cloud Armor unterstützt jedoch keine anderen HTTP Content-Type-/Content-Encoding-basierten Decoder wie XML, Gzip oder UTF-16.

Beispiele

Im folgenden Beispiel werden die Regeln 1, 2 und 3 in der angegebenen Reihenfolge für die Headerfelder IP und HTTP ausgewertet. Wenn jedoch ein IP 9.9.9.1 einen XSS-Angriff im HTTP POST-Text startet, wird nur der Text blockiert (durch Regel 2). Der HTTP-Header wird durch Regel 3 an das Back-End weitergeleitet.

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

Im folgenden Beispiel lässt die Richtlinie IP 9.9.9.1 zu, ohne auf XSS-Angriffe zu prüfen:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Standardregel

Jede Google Cloud Armor-Sicherheitsrichtlinie enthält eine Standardregel, die abgeglichen wird, wenn keine der Regeln mit höherer Priorität übereinstimmt oder keine anderen Regeln in der Richtlinie vorhanden sind. Die Standardregel erhält automatisch die Priorität 2147483647 (INT-MAX) und ist in der Sicherheitsrichtlinie immer vorhanden.

Sie können die Standardregel nicht löschen, aber Sie können sie ändern. Die Standardaktion für die Standardregel ist deny, Sie können sie jedoch in allow ändern.

Fingerabdruck

Jede Google Cloud Armor-Sicherheitsrichtlinie hat ein Feld fingerprint. Dieser Fingerabdruck ist ein Hash der in der Richtlinie gespeicherten Inhalte. Beim Erstellen einer neuen Richtlinie geben Sie den Wert dieses Felds nicht an. Wenn Sie einen Wert angeben, wird dieser ignoriert. Wenn Sie jedoch eine Sicherheitsrichtlinie aktualisieren, müssen Sie den aktuellen Fingerabdruck angeben, den Sie erhalten, wenn Sie die Richtlinie exportieren oder beschreiben (mit EXPORT bzw. DESCRIBE).

Der Fingerabdruck schützt Sie vor dem Überschreiben einer Aktualisierung durch einen anderen Nutzer. Wenn der von Ihnen angegebene Fingerabdruck veraltet ist, wurde die Sicherheitsrichtlinie seit dem letzten Abruf des Fingerabdrucks aktualisiert. Führen Sie den Befehl DESCRIBE aus, um nach Unterschieden zu suchen und den neuesten Fingerabdruck abzurufen.

Modul für Regelsprache und -erzwingung

Das Modul für Regelsprache und die -erzwingung bietet Folgendes:

  • Die Möglichkeit, benutzerdefinierte Regelausdrücke zu schreiben, die mit verschiedenen Attributen der Ebenen 3 bis 7 eingehender Anfragen übereinstimmen können. Google Cloud Armor bietet eine flexible Sprache zum Schreiben benutzerdefinierter Abgleichsbedingungen.

  • Die Möglichkeit, bis zu fünf Unterausdrücke in einer einzigen Regel zu kombinieren.

  • Die Möglichkeit, Anfragen anhand des Regionscodes der eingehenden Anfrage abzulehnen oder zuzulassen. Die Regionscodes basieren auf den Codes gemäß ISO 3166-1 alpha-2. Die Regionscodes beziehen sich manchmal auf bestimmte Länder, einige beziehen sich jedoch auf ein Land und die zugehörigen Gebiete. Beispielsweise enthält der Code US alle Bundesstaaten der USA, einen District und sechs Außengebiete.

Regeltypen

Google Cloud Armor hat die folgenden Regeltypen.

Regeln für Listen zum Zulassen und Sperren von IP-Adressen

Sie können innerhalb einer Sicherheitsrichtlinie Regeln für Listen zum Zulassen und Sperren von IP-Adressen erstellen: Einige Beispiele:

  • Mit Sperrlisten für IP-Adresse/CIDR können Sie verhindern, dass eine Quell-IP-Adresse oder ein CIDR-Bereich auf unterstützte Load-Balancer zugreift.

  • Mit Zulassungslisten für IP-Adresse/CIDR können Sie einer Quell-IP-Adresse oder einem CIDR-Bereich den Zugriff auf unterstützte Load-Balancer ermöglichen.

  • IPv4- und IPv6-Adressen werden in Regeln für Zulassungslisten und Sperrlisten unterstützt.

  • Regeln für das Ablehnen können eine HTTP-Antwort vom Typ 403 (Unauthorized), 404 (Access Denied) oder 502 (Bad Gateway) zurückgeben.

  • Aktionsregeln zum Überschreiten können den HTTP-Fehler 429 (zu viele Anfragen) zurückgeben.

Geografische Quellregeln

Sie können Anfragen aus ausgewählten geografischen Bereichen, die durch den Unicode-Ländercode definiert sind, zulassen oder ablehnen.

Google Cloud Armor verwendet unsere eigene IP-Standortbestimmungsdatenbank, um den geografischen Standort der Anfrage zu identifizieren. Die Datenbank wird regelmäßig aktualisiert. Wir können zwar keinen bestimmten Updaterhythmus garantieren, aber während des normalen Betriebs werden die von Google Cloud Armor verwendeten Zuordnungen etwa einmal pro Woche aktualisiert.

Aktualisierte Zuordnungen müssen global an die Google-Infrastruktur weitergegeben werden. Der Rollout-Prozess erfolgt schrittweise, normalerweise über mehrere Tage, in mehreren Zonen und Regionen, in denen Google Cloud Armor bereitgestellt wird. Aufgrund dieses graduellen Rollout-Prozesses kann es vorkommen, dass Anfragen von derselben Quell-IP-Adresse während eines Rollouts nicht einheitlich behandelt werden, wenn die Quell-IP-Adresse eine Änderung in der Standortzuordnung aufweist.

Vorkonfigurierte WAF-Regeln

Google Cloud Armor bietet eine umfassende Liste vorkonfigurierter WAF-Regeln basierend auf dem OWASP-ModSecurity Core Rule Set (CRS), um Folgendes zu erkennen:

  • SQL-Injection-Angriffe
  • Cross-Site-Scripting-Angriffe
  • Angriffe über Aufnahme lokaler Dateien
  • Angriffe über Aufnahme von Remote-Dateien
  • Angriffe über Codeausführung per Fernzugriff
  • Angriffe über Methodenerzwingung
  • Angriffe über Scannererkennung
  • Protokollangriffe
  • PHP-Injection-Angriffe
  • Angriffe über Sitzungsfixierung
  • Java-Angriffe
  • NodeJS-Angriffe

Weitere Informationen finden Sie in der Übersicht über die vorkonfigurierten WAF-Regeln für Google Cloud Armor.

Regeln für die Bot-Verwaltung

Sie können die Bot-Verwaltungsregeln für Folgendes nutzen:

  1. Leiten Sie Anfragen für die reCAPTCHA Enterprise-Bewertung mit optionalen manuellen Herausforderungen weiter.
  2. Analysieren Sie mit einer Anfrage verknüpfte reCAPTCHA Enterprise-Tokens und wenden Sie die konfigurierte Aktion je nach Tokenattributen an.
  3. Leiten Sie Anfragen an die konfigurierte alternative URL mit einer 302-Antwort weiter.
  4. Fügen Sie benutzerdefinierte Header zu Anfragen hinzu, bevor Sie sie an Ihre Back-Ends weiterleiten.

Weitere Informationen zur Bot-Verwaltung finden Sie unter Übersicht der Bot-Verwaltung.

Vorkonfigurierte Regeln für benannte IP-Adresslisten

Vorkonfigurierte Regeln für benannte IP-Adresslisten bieten Folgendes:

  • IP-Adresslisten von Drittanbietern werden in Google Cloud Armor eingebunden.

  • Die Verwaltung von zugelassenen oder abgelehnten IP-Adressbereichen wird vereinfacht.

  • Die Listen von Drittanbietern werden täglich synchronisiert.

  • Die Kapazität für die Konfiguration von IP-Adressen und Bereichen in Sicherheitsrichtlinien wird erhöht, da benannte IP-Adresslisten keinen Beschränkungen in der Anzahl der IP-Adressen pro Regel unterliegen.

Ratenbegrenzungsregeln

Sie können Regeln zur Ratenbegrenzung für Folgendes verwenden:

  • Anfragen pro Client auf Basis eines von Ihnen konfigurierten Grenzwerts drosseln.
  • Clients, die einen für eine konfigurierte Dauer festgelegten Anfragegrenzwert überschreiten, vorübergehend sperren.

Wenn Sie die Ratenbegrenzung mit globalen externen Proxy-Network Load Balancern oder klassischen Proxy-Network Load Balancern verwenden, gelten die folgenden Einschränkungen:

  • Google Cloud Armor erzwingt nur Ratenbegrenzungsaktionen wie die Drosselung oder das Sperren für neue Verbindungsanfragen von Clients.
  • Es werden nur die Schlüsseltypen ALL und IP unterstützt.
  • Wenn Sie versuchen, den Schlüsseltyp HTTP-HEADER oder HTTP-COOKIE mit TCP/SSL-Load-Balancern zu verwenden, wird der Schlüsseltyp als ALL interpretiert, und ebenso wird XFF-IP als IP interpretiert.

Weitere Informationen zur Ratenbegrenzung und ihrer Funktionsweise finden Sie unter Ratenbegrenzung – Übersicht.

Vorschaumodus

Sie können die Auswirkungen einer Regel in der Vorschau anzeigen lassen, ohne sie zu erzwingen. Im Vorschaumodus werden Aktionen in Cloud Monitoring angegeben. Sie können einzelne Regeln in einer Sicherheitsrichtlinie oder alle Regeln in der Richtlinie in der Vorschau anzeigen lassen. Für Regeln im Vorschaumodus wird Ihnen die normale Gebühr pro Anfrage berechnet.

Sie können den Vorschaumodus für eine Regel mit dem Google Cloud CLI und dem Flag --preview von gcloud compute security-policies rules update aktivieren.

Verwenden Sie das Flag --no-preview, das derzeit nicht dokumentiert ist, um den Vorschaumodus zu deaktivieren. Sie können auch die Google Cloud Console verwenden.

Wenn eine Anfrage eine Vorschau auslöst, wertet Google Cloud Armor die anderen Regeln so lange aus, bis eine Übereinstimmung gefunden wird. Sowohl die übereinstimmende als auch die Vorschauregel sind in den Logs verfügbar.

Logging

Google Cloud Armor bietet ein umfassendes Logging, sodass Sie festlegen können, wie umfangreich das Logging ist. Ausführliche Informationen zum Logging finden Sie unter Anfrage-Logging verwenden.

Informationen zum Aufrufen von Google Cloud Armor-Logs finden Sie unter Logs ansehen.

Anfrage-Logging des externen Application Load Balancers

Jede HTTP(S)-Anfrage, die anhand einer Google Cloud Armor-Sicherheitsrichtlinie ausgewertet wird, wird über Cloud Logging protokolliert. Die Logs enthalten Details wie den Namen der angewendeten Sicherheitsrichtlinie, die Abgleichsregel und ob die Regel erzwungen wurde. Das Anfrage-Logging für neue Back-End-Dienstressourcen ist standardmäßig deaktiviert. Damit Google Cloud Armor-Anfragen protokolliert werden, müssen Sie für jeden durch eine Sicherheitsrichtlinie geschützten Back-End-Dienst das HTTP(S)-Logging aktivieren.

Weitere Informationen finden Sie unter Logging und Monitoring für externes Application Load Balancer.

Anfrage-Logging des externen Proxy-Network Load Balancers

Sie können das Logging für externe Proxy-Network Load Balancer mithilfe der Google Cloud CLI-Befehle konfigurieren, die unter Logging und Monitoring für TCP/SSL-Proxy-Load-Balancing aufgeführt sind. Sie können das Logging für externe Proxy-Network Load Balancer nicht über die Google Cloud Console aktivieren.

Wann sollte die ausführliche Protokollierung verwendet werden?

Möglicherweise können Sie nicht erkennen, warum eine vorkonfigurierte WAF-Regel durch eine bestimmte Anfrage ausgelöst wurde. Die Standard-Ereignislogs von Google Cloud Armor enthalten die ausgelöste Regel sowie die Untersignatur. Möglicherweise müssen Sie jedoch die Details der eingehenden Anfrage identifizieren, die die Regel zur Fehlerbehebung, Regelvalidierung oder Regeloptimierung ausgelöst haben.

Sie können die in Ihren Logs aufgezeichnete Detailebene anpassen. Wir empfehlen, das ausführliche Logging nur zu aktivieren, wenn Sie eine Richtlinie erstellen, Änderungen an einer Richtlinie vornehmen oder Fehler in Richtlinien beheben. Wenn Sie das ausführliche Logging aktivieren, gilt es für Regeln im Vorschaumodus sowie aktive (nicht in der Vorschau angezeigte) Regeln während Standardvorgängen.

Weitere Informationen zum ausführlichen Logging finden Sie unter Ausführliche Protokollierung.

Parsen von POST-Textinhalten

Standardmäßig wertet Google Cloud Armor den gesamten Inhalt eines POST-Texts als einheitlichen String aus (unterliegt Einschränkungen der Textgröße) anhand der Signaturen in Ihren vorkonfigurierten WAF-Regeln. Bei Anfragen mit alternativer Codierung wie JSON können strukturelle Komponenten der Nachricht (nicht vom Nutzer angegeben) Übereinstimmungen mit den vorkonfigurierten WAF-Signaturen auslösen. Um Rauschen zu vermeiden und das Risiko von falsch-positiven Ergebnissen zu verringern, empfehlen wir, dass Sie Google Cloud Armor so konfigurieren, dass ein alternatives Parsing für jeden unterstützten Content-Type möglich ist, wenn Ihre geschützten Arbeitslasten Folgendes tun:

  • REST APIs bereitstellen
  • GraphQL verwenden
  • Alle Anfragen mit JSON-codiertem Inhalt empfangen.

Weitere Informationen zu vorkonfigurierten WAF-Regeln finden Sie unter JSON-Parsing auf benutzerdefinierte Content-Type-Header-Werte anwenden.

Jede HTTP(S)-Anfrage, die anhand einer Google Cloud Armor-Sicherheitsrichtlinie ausgewertet wird, wird über Cloud Logging protokolliert. Die Logs enthalten Details wie den Namen der angewendeten Sicherheitsrichtlinie, die Abgleichsregel und ob die Regel erzwungen wurde. Das Anfrage-Logging für neue Back-End-Dienstressourcen ist standardmäßig deaktiviert. Damit Google Cloud Armor-Anfragen protokolliert werden, müssen Sie für jeden durch eine Sicherheitsrichtlinie geschützten Back-End-Dienst das HTTP(S)-Logging aktivieren.

Weitere Informationen finden Sie unter Logging und Monitoring des globalen externen Application Load Balancers.

Beschränkungen

In den folgenden Abschnitten werden Einschränkungen für Sicherheitsrichtlinien beschrieben.

Einschränkung der POST-Textinspektion

Der evaluatePreconfiguredExpr()-Ausdruck für vorkonfigurierte Regeln ist der einzige Ausdruck, den Google Cloud Armor anhand des Anfragetexts auswertet. Unter den HTTP-Anfragetypen mit einem Anfragetext verarbeitet Google Cloud Armor nur POST-Anfragen.

Die Prüfung ist auf die ersten 8 KB des POST-Texts beschränkt, der wie URL-Suchparameter decodiert wird. Der Rest des POST-Textkörpers könnte schädlichen Code enthalten, den Ihre Anwendung möglicherweise akzeptiert. Informationen zum Reduzieren des Risikos von POST-Texten, die 8 KB überschreiten, finden Sie in der Anleitung zur Fehlerbehebung.

Google Cloud Armor kann vorkonfigurierte WAF-Regeln für standardmäßige URL-codierte und JSON-formatierte POST-Textkörper (Content-Type = "application/json") parsen und anwenden. In diesem Fall werden Regeln unabhängig auf die decodierten Namen und Werte in den Daten angewendet. Bei anderen Inhaltstypen und Codierungstypen decodiert Google Cloud Armor die Daten nicht, sondern wendet die vorkonfigurierten Regeln auf Rohdaten an.

So werden WebSocket-Verbindungen verarbeitet

Globale externe Application Load Balancer haben integrierte Unterstützung für das WebSocket-Protokoll. WebSocket-Kanäle werden über HTTP(S)-Anfragen initiiert. Google Cloud Armor kann beispielsweise die Einrichtung eines WebSocket-Kanals blockieren, wenn eine Sperrliste für IP-Adressen die ursprüngliche IP-Adresse blockiert. Nachfolgende Transaktionen im Kanal entsprechen jedoch nicht dem HTTP-Protokoll und Google Cloud Armor wertet nach der ersten Anfrage keine Nachrichten aus.

Nächste Schritte