Best Practices für Google Cloud Armor

Auf dieser Seite finden Sie Best Practices zum Optimieren und Feinabstimmen von Google Cloud Armor-Deployments.

Google Cloud Armor wird mit externen HTTP(S)-Load-Balancern, TCP-Proxy-Load-Balancern oder SSL-Proxy-Load-Balancern bereitgestellt. Wenn Sie Google Cloud Armor bereitstellen, hängen Sie eine Sicherheitsrichtlinie an den Back-End-Dienst des zu schützenden Load-Balancers an. Eine Sicherheitsrichtlinie besteht aus einer von Ihnen bestimmten Sammlung vorkonfigurierter und benutzerdefinierter Regeln.

Sicherheitsrichtlinie und Regelerstellung

Die folgenden Abschnitte enthalten Best Practices und Empfehlungen für neue Sicherheitsrichtlinien und -regeln.

Regelbeschreibungen bereitstellen

Verwenden Sie Regelbeschreibungen, um zusätzlichen Kontext darüber zu bieten, warum die einzelnen Regeln erstellt wurden und welcher Funktion sie dienen sollen. Das Beschreibungsfeld ist auf 64 Zeichen beschränkt. Verweise auf Datenbanken zur Konfigurationsverwaltung oder andere Repositories sind daher die effizienteste Methode, um Kontext zu aufzunehmen.

Prioritätsabstand berücksichtigen

Behalten Sie bei der anfänglichen Konfiguration von Regeln einen Abstand von mindestens 10 zwischen den Prioritätswerten der einzelnen Regeln bei. Beispielsweise könnten die ersten beiden Regeln in einer Sicherheitsrichtlinie die Prioritäten 20 und 30 haben. So können Sie bei Bedarf weitere Regeln einfügen. Darüber hinaus empfehlen wir, ähnliche Regeln in Blöcken zu gruppieren, sodass größere Abstände zwischen Gruppen verbleiben.

Vorschaumodus verwenden

Sicherheitsrichtlinienregeln, einschließlich Signaturen für das OWASP (Open Web Application Security-Projekt), können unvorhersehbare Auswirkungen auf Ihre Anwendung haben. Verwenden Sie den Vorschaumodus, um zu bewerten, ob sich die Einführung einer Regel negativ auf den Produktionstraffic auswirken wird.

Adaptive Protection von Google Cloud Armor aktivieren

Aktivieren Sie den adaptiven Schutz, um Ihre Anwendungen zusätzlich zu schützen. Der adaptive Schutz überwacht den Traffic und empfiehlt (falls erforderlich) neue Regeln für Ihre Sicherheitsrichtlinien. Darüber hinaus empfehlen wir Ihnen, eine Benachrichtigungsrichtlinie zu erstellen, um sicherzustellen, dass die richtigen Personen über potenzielle Angriffe benachrichtigt werden. Der adaptive Schutz eignet sich am besten zum Schutz vor volumetrischen Angriffen. Angriffe, die nicht volumetrisch sind, lösen den adaptiven Schutz möglicherweise nicht aus.

JSON-Parsing aktivieren

Wenn Ihre Anwendung JSON-Inhalte im Text von POST-Anfragen sendet, achten Sie darauf, dass Sie das JSON-Parsing aktivieren. Wenn Sie das JSON-Parsing nicht aktivieren, parst Google Cloud Armor den JSON-Inhalt der POST-Textkörper für vorkonfigurierte WAF-Regeln nicht. Die Ergebnisse können ungenau sein und falsch positive Ergebnisse generieren. Weitere Informationen finden Sie unter JSON-Parsing.

Logik testen

Eine Regel wird ausgelöst, wenn ihre Übereinstimmungsbedingung als wahr ausgewertet wird. Beispiel: Die Übereinstimmungsbedingung origin.region_code == 'AU' wird als wahr ausgewertet, wenn der Regionscode der Anfrage AU ist. Wird eine Regel mit einer höheren Priorität als wahr ausgewertet, wird die Aktion in Regeln mit niedrigerer Priorität ignoriert. Angenommen, Sie möchten im folgenden Beispiel eine Sicherheitsrichtlinie erstellen, um Nutzer aus der Region AU zu blockieren, wobei Sie Traffic im IP-Adressbereich 10.10.10.0/24 ausnehmen wollen. Betrachten Sie folgende Sicherheitsrichtlinie mit zwei Regeln:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

In diesem Beispiel lässt Rule1 Traffic zu, der aus dem IP-Adressbereich 10.10.10.0/24 stammt. Da Rule1 die Regel mit höherer Priorität ist, ist ein solcher Traffic zulässig, bis er gegen Rule2 ausgewertet wird. Dies bedeutet, dass Google Cloud Armor ihn nicht anhand von Rule2 (oder einer anderen verbleibenden Regel) bewertet.

Testen Sie beim Erstellen von Google Cloud Armor-Richtlinien die Logik Ihrer Regeln, um zu prüfen, ob Sie das gewünschte Verhalten erreichen. Dazu empfehlen wir, dass Sie synthetischen Traffic generieren, um zu verstehen, welche Regeln Traffic blockieren, und prüfen, ob Ihre Ergebnisse mit Ihren Regeldesign-Entscheidungen konsistent sind. Wenn Sie sich nicht sicher sind, wie eine Anfrage das System durchläuft, verwenden Sie den Vorschaumodus, um zu sehen, welche Regel mit der Anfrage übereinstimmt.

Quell-IP-Adressen der Scanner ermitteln

Ihre Sicherheitsscanner können sich innerhalb oder außerhalb von Google befinden. Wenn Sie eine externe und ungefilterte Bewertung Ihrer Anwendung wünschen, können Sie den Traffic basierend auf der IP-Adresse (oder einem anderen Token) explizit zulassen, bevor er anhand anderer Regeln ausgewertet wird.

Regeln in einer Sicherheitsrichtlinie gruppieren und sortieren

Ihre Anwendungen bedienen möglicherweise unterschiedliche Untergruppen Ihrer Kunden. Im folgenden Beispiel möchten Sie Traffic aus bestimmten geografischen Bereichen oder IP-Bereichen ablehnen. Daher konfigurieren Sie die erste Regel in Ihrer Richtlinie, um solchen Traffic abzulehnen. Darüber hinaus möchten Sie einigen Traffic in die Anwendung explizit zulassen, ohne dass er von der Sicherheitsrichtlinie verarbeitet wird. Für dieses Beispiel empfehlen wir folgende Regelprioritätsstruktur, von der höchsten zur geringsten Priorität:

  1. Explizite Ablehnungsregeln (ASN, Region, IP-Bereiche)
  2. Vertrauenswürdige explizite Zulassungsregeln (Scanner, vertrauenswürdige Systeme – mit äußerster Vorsicht verwenden)
  3. Sicherheitsregeln (OWASP, benutzerdefinierte Regeln)
  4. Explizite Zulassungsregeln (ASN, Header-Wert vorhanden, IP-Bereich)
  5. Standard-Ablehnungsregeln

Gegebenenfalls Botverwaltung verwenden

Google Cloud Armor kann in reCAPTCHA Enterprise eingebunden werden. Wenn Sie reCAPTCHA Enterprise verwenden, verschieben Sie den Token-Bewertungsprozess nach Google Cloud Armor. Dadurch wird die Ursprungslast reduziert und die Sicherheitskontrollen werden näher am Endnutzer als an Ihren Back-Ends platziert. Weitere Informationen finden Sie in der Übersicht über die Bot-Verwaltung.

Schwellenwerte für die Ratenbegrenzung festlegen

Die Ratenbegrenzung ist eine flexible und wertvolle Möglichkeit, Missbrauch zu verhindern und Bedrohungen mit hohem Volumen wie Credential Stuffing oder L7 DDoS-Angriffe abzuwenden. Wenn Sie die Ratenbegrenzung zum ersten Mal bereitstellen, ist es wichtig, einen Schwellenwert zu wählen, der für Ihre Anwendung sinnvoll ist. Wir empfehlen, mit der Durchsetzung im Vorschaumodus zu beginnen. Wenn Sie das Trafficprofil analysieren und verstehen, können Sie die Parameter für die Ratenbegrenzung anpassen. Außerdem muss die Priorität berücksichtigt werden, die Sie der Ratenbegrenzungsregel zuweisen. Traffic kann von einer Regel mit höherer Priorität explizit zugelassen oder abgelehnt werden, bevor er gegen die Ratenbegrenzungsregel ausgewertet wird.

Regeloptimierung

Webanwendungen können Anfragen zulassen, die wie Angriffe wirken. Außerdem können sie auch zulassen oder sogar anfordern, dass Nutzer Anfragen senden, die den Signaturen in vorkonfigurierten WAF-Regeln entsprechen. Es ist wichtig, dass Sie die Google Cloud Armor-Regeln für Ihre Anwendung validieren und alle Ergebnisse ansprechen, die für Ihre Anwendung möglicherweise nicht relevant sind, bevor Sie die Regel durch Deaktivieren des Vorschaumodus in einer Produktionsanwendung einsetzen. In folgenden Abschnitten finden Sie Best Practices und Empfehlungen zur Feinabstimmung der vorkonfigurierten WAF-Regeln.

Vorkonfigurierte WAF-Regel-Empfindlichkeitsstufe wählen

Wenn Sie eine der vorkonfigurierten WAF-Regeln implementieren, können Sie je nach Ihren Sicherheitsanforderungen und Zeitachsen eine geeignete Empfindlichkeitsstufe wählen. Wir empfehlen normalerweise, bei Anwendungen, die die Sicherheitsanforderungen Ihrer Organisation erfüllen müssen, mit der Empfindlichkeitsstufe 1 zu beginnen. Regeln, die für Empfindlichkeit 1 konfiguriert sind, verwenden Signaturen mit hoher Genauigkeit und reduzieren potenzielle Störeffekte durch die Regel. Signaturen, die mit höheren Empfindlichkeiten verbunden sind, können eine größere Zahl an Exploit-Versuche erkennen und verhindern, allerdings kommt es dafür zu Störeffekten bei potenziell geschützten Anwendungen. Bei Arbeitslasten, die strengeren Sicherheitsanforderungen unterliegen, kann jedoch die höchste Empfindlichkeitsstufe angemessen sein. In diesen Anwendungsfällen kann es zu sehr vielen Störeffekten oder irrelevanten Meldungen kommen. Dies müssen Sie vor der Übernahme der Sicherheitsrichtlinie ansprechen.

Ausführliche Protokollierung aktivieren

Wenn Sie zusätzliche Informationen dazu benötigen, welche Anfrageattribute und Nutzlasten eine bestimmte WAF-Regel auslösen, aktivieren Sie das ausführliche Logging. Ausführliches Logging enthält Details zu Anfragen, die bestimmte Regeln auslösen, einschließlich eines Snippets des problematischen Teils der Anfrage. Dies ist bei der Fehlerbehebung und Feinabstimmung von Google Cloud Armor hilfreich. Da ausführliches Logging dazu führen kann, dass Anfrageinhalte von Endnutzern in Cloud Logging protokolliert werden, besteht die Möglichkeit, dass personenidentifizierbare Informationen von Endnutzern in Ihre Logs aufgenommen werden. Daher wird empfohlen, bei Produktionsarbeitslasten das ausführliche Logging nicht über längere Zeiträume aktiviert zu lassen.

Stabile oder Canary-Regeln verwenden

Es gibt zwei Typen vorkonfigurierte WAF-Regeln von Google Cloud Armor: Stabile Regeln und Canary-Regeln. Wenn dem aktuellen ModSecurity-CRS (Core Rule Set, Kernregelsatz) neue Regeln hinzugefügt werden, veröffentlichen wir sie in den Canary-Regel-Builds, bevor sie automatisch in den stabilen Regel-Builds veröffentlicht werden. Wir empfehlen, Canary-Regeln in einer Testumgebung bereitzustellen, damit Sie die Auswirkungen von Änderungen und Ergänzungen auf Ihre Umgebung erkennen können. Auf der Seite Feinabstimmung der Google Cloud Armor-WAF-Regeln können Sie prüfen, ob der Canary-Build mit dem stabilen Build synchron ist.

Logging und Monitoring

Folgende Abschnitte enthalten Best Practices und Empfehlungen zum Konfigurieren von Logging und Monitoring.

Security Command Center verwenden

Google Cloud Armor wird automatisch in das Security Command Center eingebunden. Google Cloud Armor exportiert verschiedene Ergebnisse in das Security Command Center:

  • Zulässige Traffic-Spitzen
  • Ablehnungsverhältnis erhöhen

Sorgen Sie dafür, dass Ihre Websicherheitsmitarbeiter diese Ergebnisse untersuchen.

Cloud Logging-Abtastrate wählen

Nach Anfrage aktive Google Cloud Armor-Logs verwenden die Logging-Infrastruktur des externen HTTP(S)-Load-Balancers. Daher unterliegt die Loggenerierung für Google Cloud Armor der Log-Sampling-Rate, die für den Load-Balancer konfiguriert ist. Wir empfehlen, die Abtastrate auf 1 zu halten, wenn Sie Google Cloud Armor aktiv optimieren und implementieren. Nachdem Sie die Abstimmung und Implementierung von Google Cloud Armor abgeschlossen haben, empfehlen wir, das vollständige Anfrage-Logging aktiviert zu lassen. Einige Kunden können aber eine niedrigere Samplerate bevorzugen. Standardmäßig aktiviert der externe HTTP(S)-Load-Balancer das Logging nicht. Daher ist es wichtig, dass Sie es aktivieren.

Cloud Monitoring-Dashboard verwenden

Es ist wichtig, genau zu wissen, was in Ihrer Google Cloud Armor-Konfiguration passiert. Das Sicherheits-Dashboard erleichtert diese Aufgabe. Darüber hinaus können Sie Google Cloud Armor-Logs direkt aus Logging in Ihre eigene Plattform exportieren. Wenn Sie den adaptiven Schutz verwenden, ist es wichtig, einen Eskalationspfad für alle ausgelösten Benachrichtigungen zu haben.

Allgemeine Verwaltung

Im Folgenden finden Sie zusätzliche Best Practices und Empfehlungen zum Konfigurieren von Google Cloud Armor.

Zugriffssteuerung für die Identitäts- und Zugriffsverwaltung einrichten

Sorgen Sie gemäß den allgemeinen Best Practices für Google Cloud IAM dafür, dass die richtigen Personen Zugriff auf Google Cloud Armor haben. Die Rolle „Compute-Sicherheitsadministrator” ist erforderlich, um Google Cloud Armor-Sicherheitsrichtlinien zu konfigurieren, zu ändern, zu aktualisieren und zu löschen. Darüber hinaus ist die Rolle „Compute-Netzwerkadministrator” oder die Berechtigung compute.backendServices.setSecurityPolicy erforderlich, um eine Google Cloud Armor-Sicherheitsrichtlinie an einen Back-End-Dienst anzuhängen.

Anzahl der Richtlinien minimieren

Eine Google Cloud Armor-Richtlinie kann für mehrere Back-End-Dienste wiederverwendet werden. Wir empfehlen Ihnen, ein Set konsistenter, wiederverwendbarer Sicherheitsrichtlinien bereitzuhalten.

Terraform verwenden

Damit Konfigurationen problemlos zurückgesetzt und projektübergreifend reproduziert werden können, empfehlen wir die Verwendung von Terraform. Google Cloud Armor bietet eine vollständige Terraform-Einbindung für GA-Features.

Google Kubernetes Engine-Einbindung

Wenn Sie GKE verwenden, müssen Sie Google Cloud Armor und andere Ingress-Features über BackendConfig-Parameter konfigurieren. Es wird nicht empfohlen, einen externen HTTP(S)-Load-Balancer manuell als Ingress-Punkt zu konfigurieren. Weitere Informationen zum Konfigurieren von Google Cloud Armor mit GKE finden Sie unter Ingress-Features konfigurieren.