Übersicht über die Sicherheitsrichtlinien

Auf dieser Seite wird beschrieben, wie Sie mit Google Cloud Armor-Sicherheitsrichtlinien Ihre Trusted Cloud by S3NS Bereitstellungen schützen können.

Google Cloud Armor-Sicherheitsrichtlinien schützen Ihre Anwendung durch Layer-7-Filter und Scrubbing eingehender Anfragen für häufige Webangriffe oder andere Layer-7-Attribute, um den Traffic zu blockieren, bevor er Ihre Back-End-Dienste mit Load-Balancing erreicht. Jede Sicherheitsrichtlinie besteht aus einer Reihe von Regeln, die für Attribute der Ebenen 3 bis 7 konfiguriert werden können. Die Regeln können Traffic anhand von Bedingungen filtern, z. B. IP-Adresse, IP-Bereich, Regionscode oder Anfrageheader einer eingehenden Anfrage.

Cloud Armor-Sicherheitsrichtlinien sind für regionale externe Application Load Balancer verfügbar.

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

Wenn Sie Cloud Armor zum Schutz einer Hybridbereitstellung oder einer Multi-Cloud-Architektur verwenden, müssen die Back-Ends Internet-NEGs oder Hybrid-NEGs sein. Cloud Armor schützt auch serverlose NEGs, wenn der Traffic über einen Load-Balancer geleitet wird. Informationen dazu, wie Sie Traffic über Ihren Load-Balancer leiten, bevor er Ihre serverlose NEG erreicht, finden Sie unter Steuerelemente für eingehenden Traffic.

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

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.

Mit Cloud Armor-Sicherheitsrichtlinien können Sie Anfragen an Ihre Backend-Dienste am Trusted Cloud -Edge so nah wie möglich an der Quelle des eingehenden Traffics zulassen, ablehnen, ratenbegrenzen oder weiterleiten. Dies verhindert, dass unerwünschter Traffic Ressourcen verbraucht oder in Ihre VPC-Netzwerke (Virtual Private Cloud) gelangt.

Voraussetzungen

Das sind die Anforderungen für die Verwendung von Cloud Armor-Sicherheitsrichtlinien:

  • Das Load-Balancing-Schema des Backend-Dienstes muss EXTERNAL_MANAGED sein.
  • Das Protokoll des Backend-Dienstes muss entweder HTTP, HTTPS, HTTP/2, UDP, TCP, SSL oder UNSPECIFIED sein.

Cloud Armor-Sicherheitsrichtlinien

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

Eine Cloud Armor-Sicherheitsrichtlinienregel besteht aus einer Abgleichsbedingung und einer Aktion, die ausgeführt werden muss, wenn diese Bedingung erfüllt ist. Eine Bedingung kann beispielsweise sein, 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 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 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.

Cloud Armor bietet zwei Kategorien von Sicherheitsrichtlinien: hierarchische Sicherheitsrichtlinien und Sicherheitsrichtlinien auf Dienstebene. Hierarchische Sicherheitsrichtlinien werden auf Organisations-, Ordner- oder Projektebene angehängt, während Sicherheitsrichtlinien auf Dienstebene einem oder mehreren Back-End-Diensten zugeordnet werden. Weitere Informationen zu hierarchischen Sicherheitsrichtlinien finden Sie unter Hierarchische Sicherheitsrichtlinien – Übersicht.

Einem Back-End-Dienst können gleichzeitig zwei Sicherheitsrichtlinien auf Dienstebene zugeordnet sein, aber nicht zwei Back-End-Sicherheitsrichtlinien oder zwei Edge-Sicherheitsrichtlinien. Ihre Back-End-Dienste müssen jedoch nicht alle derselben Sicherheitsrichtlinie zugeordnet sein. Informationen zum Anhängen und Entfernen von Sicherheitsrichtlinien aus unterstützten Back-End-Diensten und ‑Funktionen finden Sie unter Sicherheitsrichtlinien anhängen und entfernen.

Wenn eine Cloud Armor-Sicherheitsrichtlinie einem beliebigen Back-End-Dienst zugeordnet 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.

Im folgenden Diagramm ist die Cloud Armor-Sicherheitsrichtlinie internal-users-policy dem Back-End-Dienst test-network zugeordnet.

Cloud Armor-Sicherheitsrichtlinie am Netzwerkrand
Cloud Armor-Sicherheitsrichtlinie am Netzwerkrand (zum Vergrößern anklicken)
Cloud Armor-Sicherheitsrichtlinien haben die folgenden Funktionen:

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

  • 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 regionale externe Application Load Balancer konfigurieren.

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 Cloud Armor, Dutzende von unterschiedlichen Traffic-Signaturen auszuwerten. Dabei bezieht sich 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 vorkonfigurierte WAF-Regeln.

Arten von Sicherheitsrichtlinien

In den folgenden Tabellen sind die verschiedenen Arten von Sicherheitsrichtlinien auf Dienstebene aufgeführt und was sich mit ihnen machen lässt. Ein Häkchen () gibt an, dass der Typ der Sicherheitsrichtlinie das Feature unterstützt.

Back-End-Sicherheitsrichtlinien

Backend-Sicherheitsrichtlinien werden mit Backend-Diensten verwendet, die von regionalen externen Application Load Balancern bereitgestellt werden.

Backend-Sicherheitsrichtlinien haben den optionalen Flag-Wert type CLOUD_ARMOR. Wenn Sie das Flag type nicht festlegen, ist der Standardwert CLOUD_ARMOR.

Sicherheitsrichtlinien für interne Dienste

Mit internen Dienstsicherheitsrichtlinien können Sie die Fairshare-Ratenbegrenzung mit Cloud Service Mesh konfigurieren. Anstatt eine Sicherheitsrichtlinie für interne Dienste an einen Back-End-Dienst oder -Bucket anzuhängen, hängen Sie sie an eine Cloud Service Mesh-Endpunktrichtlinie an. Weitere Informationen zu internen Dienstsicherheitsrichtlinien finden Sie in der Cloud Service Mesh-Dokumentation unter Ratenbegrenzung mit Cloud Armor 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.

Prioritätsnummern müssen nicht aufeinanderfolgen. Durch diese Lücken können Sie auch später noch Regeln einfügen oder entfernen, 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 mit einem Text anhand von vorkonfigurierten Regeln ausgewertet werden, die evaluatePreconfiguredWaf verwenden. Es gibt jedoch eine Ausnahme:

Bei HTTP POST-Anfragen empfängt Cloud Armor den Header der Anfrage vor dem Text (Nutzlast). Da 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 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 Cloud Armor die HTTP POST-Anfrage mit einem Text 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-Back-End-Dienst gesendet, der Textkörper mit potenziell schädlichen Inhalten jedoch blockiert wird. Cloud Armor prüft bis zu den ersten 64 KB des Anfragetexts (entsprechend dem konfigurierten Prüflimit von 8 KB, 16 KB, 32 KB, 48 KB oder 64 KB). Weitere Informationen zu dieser Einschränkung finden Sie unter Beschränkung der POST- und PATCH-Textprüfung.

Der Ausdruck evaluatePreconfiguredWaf() 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 Cloud Armor nur POST- und PATCH-Anfragen. Die Prüfung ist auf das konfigurierte Prüflimit beschränkt, bis zu den ersten 64 KB (entweder 8 KB, 16 KB, 32 KB, 48 KB oder 64 KB) des Anfragetexts, und wird wie URL-Abfrageparameter decodiert. Cloud Armor kann vorkonfigurierte WAF-Regeln für JSON-formatierte POST-Textkörper (Content-Type = "application/json") parsen und anwenden. Cloud Armor unterstützt jedoch keine anderen HTTP-Content-Type-/Content-Encoding-basierten Decodierer wie etwa 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 eine IP-Adresse 9.9.9.1 einen XSS-Angriff im Text HTTP POST 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: evaluatePreconfiguredWaf('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: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Standardregel

Jede 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.

Die Standardregel kann nicht gelöscht, sondern nur bearbeitet werden. Die Standardaktion für die Standardregel ist deny, lässt sich aber in allow ändern.

Fingerabdruck

Jede 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. Cloud Armor bietet Attribute für die Sprache der benutzerdefinierten Regeln zum Schreiben benutzerdefinierter Abgleichsbedingungen.

  • Die Möglichkeit, bis zu fünf Teilausdrü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

Cloud Armor bietet 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:

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

  • Wenn Sie einer Sperrliste eine IP-Adresse oder einen CIDR-Bereich hinzufügen, können Sie verhindern, dass eine Quell-IP-Adresse oder ein CIDR-Bereich auf unterstützte Load-Balancer zugreift.

  • Wenn Sie einer Zulassungsliste eine IP-Adresse oder einen CIDR-Bereich hinzufügen, 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 einen HTTP-Statuscode vom Typ 403 Unauthorized, 404 Access Denied oder 502 Bad Gateway zurückgeben.

  • Aktionsregeln zum Überschreiten können den HTTP-Statuscode 429 Too Many Requests zurückgeben.

Geografische Quellregeln

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

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 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 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 sich die Standortzuordnung für die Quell-IP-Adresse geändert hat.

Vorkonfigurierte WAF-Regeln

Cloud Armor bietet eine umfassende Liste vorkonfigurierter WAF-Regeln basierend auf dem OWASP 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 Cloud Armor.

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:

  • Cloud Armor erzwingt nur Ratenbegrenzungsaktionen wie die Drosselung oder das Sperren für neue Verbindungsanfragen von Clients.
  • Nur die Schlüsseltypen ALL und IP werden 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.

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 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 des Befehls gcloud compute security-policies rules update aktivieren.

Verwenden Sie das Flag --no-preview, um den Vorschaumodus zu deaktivieren. Sie können auch dieTrusted Cloud -Konsole verwenden.

Wenn eine Anfrage eine Vorschau auslöst, wertet 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.

Benutzerdefinierte Fehlerantworten

Wenn Sie einen globalen externen Application Load Balancer verwenden, können Sie benutzerdefinierte Fehlerantworten für HTTP-Statuscodes für Fehler konfigurieren, die von Load Balancern oder Backend-Instanzen generiert werden. Außerdem können Sie benutzerdefinierte Fehlercodes für Traffic konfigurieren, der von Cloud Armor abgelehnt wird. Dazu konfigurieren Sie benutzerdefinierte Antwortseiten für dieselben Statuscodes der 4xx- oder 5xx-Serie, die von Ihren vorhandenen Sicherheitsrichtlinienregeln verwendet werden.

Weitere Informationen zu benutzerdefinierten Fehlerantworten finden Sie in der Übersicht über benutzerdefinierte Fehlerantworten. Eine Anleitung zum Konfigurieren finden Sie unter Benutzerdefinierte Fehlerantworten konfigurieren.

Logging

Cloud Armor bietet ein umfassendes Logging und ermöglicht es Ihnen, festzulegen, wie ausführlich Ihr Logging ist. Cloud Armor-Logs werden basierend auf der ersten Regel (mit der höchsten Priorität) generiert, die mit einer eingehenden Anfrage übereinstimmt, unabhängig davon, ob sich die Sicherheitsrichtlinie im Vorschaumodus befindet. Das bedeutet, dass keine Logs für nicht übereinstimmende Regeln oder für übereinstimmende Regeln mit niedrigeren Prioritäten generiert werden.

Ausführliche Informationen zum Logging finden Sie unter Anfrage-Logging verwenden. Weitere Informationen zum ausführlichen Logging finden Sie unter Ausführliches Logging. Informationen zum Aufrufen von Cloud Armor-Logs finden Sie unter Logs ansehen.

Beschränkungen

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

Einschränkung der POST- und PATCH-Textprüfung

Der evaluatePreconfiguredWaf-Ausdruck für vorkonfigurierte Regeln ist der einzige Ausdruck, den Cloud Armor anhand des Anfragetexts auswertet. Von den HTTP-Anfragetypen mit einem Anfragetext verarbeitet Cloud Armor nur POST- und PATCH-Anfragen.

Die Prüfung ist auf das konfigurierte Prüflimit beschränkt, bis zu den ersten 64 KB (entweder 8 KB, 16 KB, 32 KB, 48 KB oder 64 KB) des POST- oder PATCH-Texts. Weitere Informationen zum Konfigurieren des Prüflimits für den Anfragetextkörper bei Verwendung vorkonfigurierter WAF-Regeln finden Sie unter Prüflimit für vorkonfigurierte WAF-Regeln aktualisieren.

Der Rest des Anfragetexts kann Nutzlasten enthalten, die mit einer WAF-Regelsignatur übereinstimmen und von Ihrer Anwendung akzeptiert werden. Informationen zum Minimieren des Risikos von Anfragetexten, deren Größe das konfigurierte Prüflimit überschreitet (bis zu den ersten 64 KB, entweder 8 KB, 16 KB, 32 KB, 48 KB oder 64 KB), finden Sie unter Risiko für Anfragetext minimieren, der das konfigurierte Prüflimit überschreitet.

Cloud Armor kann vorkonfigurierte WAF-Regeln für standardmäßige URL-codierte und JSON-formatierte POST- und PATCH-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 Cloud Armor die Daten nicht, sondern wendet die vorkonfigurierten Regeln auf Rohdaten an.

So werden WebSocket-Verbindungen verarbeitet

Globale externe Application Load Balancer bieten integrierte Unterstützung für das WebSocket-Protokoll. WebSocket-Kanäle werden über HTTP(S)-Anfragen initiiert. 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 Cloud Armor wertet nach der ersten Anfrage keine Nachrichten aus.

Nächste Schritte