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 entweder mit dem globalen externen Application Load Balancer bereitgestellt, den klassischen Application Load Balancer oder den externen Proxy-Network Load Balancer. Wenn Sie Google Cloud Armor bereitstellen, hängen Sie eine Sicherheitsrichtlinie an den Backend-Dienst des Load-Balancers an, den Sie schützen möchten. Eine Sicherheitsrichtlinie besteht aus einer Sammlung vorkonfigurierter und benutzerdefinierter Regeln, die Sie festlegen.

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 ein Intervall von mindestens 10 zwischen den einzelnen Prioritätswerten für Regeln bei. Beispielsweise können 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 Intervalle 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. Adaptive Protection ü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 für den volumetrischen Schutz. Angriffe, die nicht volumetrisch sind, lösen möglicherweise nicht den adaptiven Schutz 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, bevor er gegenüber Rule2 ausgewertet wird. Dies bedeutet, dass Google Cloud Armor den Traffic nicht anhand von Rule2 bewertet (oder einer anderen verbleibenden Regel).

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 den Traffic blockieren, und prüfen, ob Ihre Ergebnisse mit Ihren Entscheidungen zum Regeldesign konsistent sind. Wenn Sie sich nicht sicher sind, wie eine Anfrage durch das System geleitet werden kann, 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 diesen Traffic abzulehnen. Außerdem möchten Sie explizit einen Teil des Traffics in den ohne dass die Sicherheitsrichtlinie sie verarbeitet. Für dieses Beispiel empfehlen wir die folgende Struktur von Regelprioritäten von der höchsten Priorität zur niedrigsten 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

reCAPTCHA für die Bot-Verwaltung verwenden

Google Cloud Armor kann in reCAPTCHA für Bot von Google eingebunden werden in der WAF-Ebene. In dieser Integration Erzeugt reCAPTCHA-Tokens und Google Cloud Armor führt das Token aus statt mit reCAPTCHA. Dadurch wird der Ursprung reduziert zur Senkung Ihrer Kosten. Außerdem werden Sicherheitskontrollen als Ihre Back-Ends. Weitere Informationen finden Sie unter 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 auszuwählen, der für Ihre Anwendung sinnvoll ist. Wir empfehlen Ihnen, mit der Erzwingung 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ührliches Logging 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 Regeln 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 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

Anfragelogs von Google Cloud Armor verwenden den globalen externen Application Load Balancer oder den Logging des klassischen Application Load Balancers und Infrastruktur. 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 Feinabstimmung und Implementierung von Google Cloud Armor abgeschlossen haben, empfehlen wir, das vollständige Anfrage-Logging aktiviert zu lassen. Sie bevorzugen jedoch möglicherweise eine niedrigere Abtastrate. Sowohl die den globalen externen und der klassische Application Load Balancer Logs standardmäßig aktivieren. Daher ist es wichtig, dass Sie das Logging manuell aktivieren.

Hinweis: Adaptive Protection-Logs werden in der Google Cloud Console unter der network_security_policy, die nicht dem globalen externen Application Load Balancer oder dem klassischen Application Load Balancer.

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 in Identity and Access Management 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 Backend-Dienst anzuhängen.

Anzahl der Richtlinien minimieren

Eine Google Cloud Armor-Richtlinie kann für mehrere Backend-Dienste wiederverwendet werden. Wir empfehlen Ihnen, konsistente wiederverwendbare Sicherheitsrichtlinien festzulegen.

Terraform verwenden

Damit Konfigurationen problemlos zurückgesetzt und projektübergreifend reproduziert werden können, empfehlen wir die Verwendung von Terraform. Google Cloud Armor hat voll Terraform-Integration für Google Analytics-Funktionen.

Google Cloud Armor mit Google Kubernetes Engine konfigurieren

Wenn Sie GKE verwenden, müssen Sie Google Cloud Armor und andere Ingress-Features über BackendConfig-Parameter konfigurieren. Wir raten davon ab, Globalen externen Application Load Balancer oder klassischer Application Load Balancer die als Eingangspunkt dienen. Weitere Informationen zum Konfigurieren von Google Cloud Armor mit GKE finden Sie unter Ingress-Features konfigurieren.