Best Practices für Cloud Armor

Sie können Ihre Google Cloud Armor-Bereitstellungen optimieren und abstimmen, um Ihre Dienste vor DoS-Angriffen (Denial of Service) und Webangriffen zu schützen. In diesem Dokument werden Best Practices beschrieben, mit denen Sie die Sicherheit Ihrer Anwendung verbessern, die Leistung steigern und Bedrohungen effizienter abwehren können. Dabei werden die globale Infrastruktur und die Sicherheitssysteme von Google genutzt.

Cloud Armor lässt sich in Cloud de Confiance by S3NS Load-Balancer einbinden. Wenn Sie Cloud Armor bereitstellen, erstellen Sie Sicherheitsrichtlinien, die aus vorkonfigurierten und benutzerdefinierten Regeln bestehen. Anschließend hängen Sie diese Richtlinien an die Backend-Dienste Ihrer Load-Balancer an, um die Backend-Dienste zu schützen.

Informationen zu Best Practices für die zentrale Verwaltung von Cloud Armor Richtlinien in Ihrer Organisation und die Zulassung projektspezifischer Regeln finden Sie unter Cloud Armor mit benutzerdefinierten Einschränkungen verwalten.

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.

JSON-Parsing aktivieren

Wenn Ihre Anwendung JSON-Inhalte im Anfragetext sendet, achten Sie darauf, dass Sie das JSON-Parsing aktivieren. Wenn Sie das JSON-Parsing nicht aktivieren, parst Cloud Armor den JSON-Inhalt der Anfragetexte 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 Cloud Armor den Traffic nicht anhand von Rule2 bewertet (oder einer anderen verbleibenden Regel).

Um eine ähnliche Ausnahme innerhalb einer einzelnen Regel zu erreichen, können Sie Übereinstimmungsbedingungen mit logischen Operatoren kombinieren. Dieser Ansatz unterscheidet sich vom Beispiel mit zwei Regeln in der Art und Weise, wie nachfolgende Regeln ausgewertet werden. Der folgende Ausdruck verwendet beispielsweise eine einzelne Regel, die Traffic aus AU ablehnt, es sei denn, er stammt aus dem spezifischen IP-Bereich 10.10.10.0/24:

expr: origin.region_code == 'AU' && !inIpRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1

Diese Bedingung wird nur dann als wahr ausgewertet (und löst eine Ablehnungsaktion aus), wenn die Region AU ist und die IP-Adresse nicht im Bereich 10.10.10.0/24 liegt.

Testen Sie beim Erstellen von 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.

Client-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. Darüber hinaus möchten Sie einigen Traffic in die Anwendung explizit zulassen, ohne dass sie von der Sicherheitsrichtlinie verarbeitet wird. 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

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 DDoS-Angriffe (Distributed Denial of Service) auf Ebene 7 (L7) 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 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 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 Cloud Armor: Stabile Regeln und Canary-Regeln. Neue Regeln oder Regelaktualisierungen aus dem OWASP Core Rule Set (CRS) werden zuerst über Canary-Regelsätze zur Verfügung gestellt und nach einer Testphase, in der die Stabilität sichergestellt wird, in den stabilen Regelsatz übernommen.

Als Best Practice sollten Sie Canary-Regelsätze im Vorschaumodus mit einer höheren Priorität und stabile Regelsätze im erzwungenen Modus mit einer niedrigeren Priorität verwenden. Mit diesem Ansatz können Sie Regeländerungen gründlich validieren, bevor sie sich auf Ihre Produktionsumgebung auswirken. Prüfen Sie auf der Seite Feinabstimmung der Cloud Armor-WAF Regeln, ob die Canary Regeln mit dem stabilen Regelsatz synchron sind.

Logging und Monitoring

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

Cloud Logging-Abtastrate wählen

Cloud Armor-Anfragelogs verwenden die Logging-Infrastruktur des globalen externen Application Load Balancers oder des klassischen Application Load Balancers. Daher unterliegt die Loggenerierung für Cloud Armor der Log-Sampling-Rate, die für den Load-Balancer konfiguriert ist. Wir empfehlen, die Abtastrate auf 1 zu halten, wenn Sie Cloud Armor aktiv optimieren und implementieren. Nachdem Sie die Feinabstimmung und Implementierung von Cloud Armor abgeschlossen haben, empfehlen wir, das vollständige Anfrage-Logging aktiviert zu lassen. Sie bevorzugen jedoch möglicherweise eine niedrigere Abtastrate. Sowohl der globale externe Application Load Balancer als auch der klassische Application Load Balancer aktivieren standardmäßig keine Logs. Daher ist es wichtig, dass Sie das Logging manuell aktivieren.

Cloud Monitoring-Dashboard verwenden

Es ist wichtig, genau zu wissen, was in Ihrer Cloud Armor-Konfiguration passiert. Das Sicherheits-Dashboarderleichtert diese Aufgabe. Darüber hinaus können Sie Cloud Armor-Logs direkt aus Logging in Ihre eigene Plattform exportieren.

Allgemeine Verwaltung

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

Zugriffssteuerung in Identity and Access Management einrichten

Sorgen Sie gemäß den allgemeinen Cloud de Confiance Best Practices für IAM dafür, dass die richtigen Personen Zugriff auf Cloud Armor haben. Die Rolle „Compute-Sicherheitsadministrator” ist erforderlich, um 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 Cloud Armor-Sicherheitsrichtlinie an einen Backend-Dienst anzuhängen.

Anzahl der Richtlinien minimieren

Eine 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. Cloud Armor bietet eine vollständige Terraform-Einbindung für GA-Features.