Übersicht über die Sicherheitsrichtlinien

Die 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 oder Ihre Back-End-Buckets 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 nur für Back-End-Dienste hinter einem externen HTTP(S)-Load-Balancer verfügbar. Der Load-Balancer kann sich in der Premium- oder Standard-Stufe befinden.

Die Back-Ends für den Back-End-Dienst können virtuelle Maschinen (VM) in einer Instanzgruppe, zonale Netzwerk-Endpunktgruppen (zonale NEGs) oder Internetnetzwerk-Endpunktgruppen (Internet-NEGs) sein. Wenn Sie Google Cloud Armor verwenden, um eine Hybridbereitstellung oder Multi-Cloud-Architektur zu schützen, müssen die Back-Ends entweder Internet-NEGs sein oder Hybrid-Konnektivitäts-NEGs, wenn Sie Traffic Director in einer lokalen Bereitstellung oder einer Bereitstellung in mehreren Umgebungen verwenden. 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 NEG erreicht, erfahren Sie unter Steuerelemente für eingehenden Traffic.

Edge-Sicherheit mit Google Cloud Armor-Sicherheitsrichtlinien

HTTP(S)-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 HTTP(S)-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 Back-End 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 Google Cloud Armor-Sicherheitsrichtlinien können Sie den Zugriff auf Ihren externen HTTP(S)-Load-Balancer am Google Cloud-Rand so nahe wie möglich an der Quelle des eingehenden Traffics zulassen oder sperren. Dies verhindert, dass unerwünschter Traffic Ressourcen verbraucht oder in Ihre VPC-Netzwerke (Virtual Private Cloud) gelangt.

Das folgende Diagramm zeigt den Standort der externen HTTP(S)-Load-Balancer, des Google-Netzwerks und der Google-Rechenzentren.

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

Anforderungen

Das sind die Anforderungen der Sicherheitsrichtlinien für Google Cloud Armor:

  • Der Load-Balancer muss ein externer HTTP(S)-Load-Balancer sein.
  • Das Load-Balancing-Schema des Back-End-Dienstes muss EXTERNAL sein.
  • Das Protokoll des Back-End-Dienstes muss entweder HTTP, HTTPS oder HTTP/2 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 mit einer Bedingung in einer Sicherheitsrichtlinie übereinstimmt, lässt Google Cloud Armor die Anfrage zu oder lehnt sie ab, je nachdem, ob es sich um eine Zulassungs- oder Ablehnungsregel handelt.

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 derselben Sicherheitsrichtlinie zugeordnet sein.

Wenn eine Google 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.

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-Richtlinie am Netzwerkrand (zum Vergrößern anklicken)

Google Cloud Armor-Sicherheitsrichtlinien haben die folgenden Hauptfeatures:

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

  • Sie können Google Cloud Armor mit externen HTTP(S)-Load-Balancern einer der folgenden Netzwerkdienststufen verwenden:

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

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.

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-Back-End-Dienst gesendet, der Text POST mit potenziell schädlichen Inhalten jedoch blockiert wird.

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 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: 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 "Zulassen" lässt sich aber in "Ablehnen" ändern.

Fingerprint

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, mehrere 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

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 externe HTTP(S)-Load-Balancer zugreift.

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

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

  • IP-Adressregeln, die einzelne Quell-IP-Adressen oder CIDRs blockieren oder zulassen. Sowohl IPv4- als auch IPv6-Quelladressen werden unterstützt, aber IPv6-Adressen müssen Subnetzmasken haben, die nicht größer als /64 sind.

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

Vorkonfigurierte Regeln für XSS, SQLi, LFI, RFI und RCE

Mit vorkonfigurierten Regeln können Sie die folgenden Angriffe minimieren:

  • Cross-Site-Scripting (XSS)
  • SQLi-Angriffe (SQL Injection)
  • LFI-Angriffe (Local File Inclusion)
  • RFI-Angriffe (Remote File Inclusion)
  • RCE-Angriffe (Remote Code Execution)

Diese Regeln basieren auf dem Kernregelsatz Version 3.0.2 von OWASP Modsecurity.

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.

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.

Sie können den Vorschaumodus für eine Regel mit dem gcloud-Befehlszeilentool 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 Cloud Console verwenden.

Logging

Der Name der Google Cloud Armor-Sicherheitsrichtlinie, die Priorität zutreffender Regeln, die zugehörige Aktion und die zugehörigen Informationen werden für HTTP(S)-Anfragen an Ihren externen HTTP(S)-Load-Balancer in Logs erfasst. Damit Sie Google Cloud Armor-Logging-Informationen aufzeichnen können, müssen Sie das Logging für HTTP(S)-Anfragen aktivieren.

Anfrage-Logging für HTTP(S)-Load-Balancing

Jede HTTP(S)-Anfrage wird über Cloud Logging in Logs erfasst. 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 HTTP(S)-Logging aktivieren.

Weitere Informationen finden Sie unter Logging für IP-Sperrliste/Zulassungsliste.

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

Beschränkungen

  • Eine Sperrliste/Zulassungsliste für das HTTP(S)-Load-Balancing wird für Cloud Storage-Back-End-Buckets nicht unterstützt.

  • Sicherheitsrichtlinien werden nur für CDN-Cache-Fehler durchgesetzt. Inhalte werden aus dem Cache bereitgestellt, selbst wenn eine Regel in einer Sicherheitsrichtlinie die Anfrage abgelehnt hätte.

So werden WebSocket-Verbindungen verarbeitet

Das externe HTTP(S)-Load-Balancing bietet 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