Google Cloud Armor bietet Funktionen zum Schutz Ihrer Google Cloud-Anwendungen vor einer Vielzahl von Ebene-3- und Ebene-7-Angriffen. Mithilfe von ratenbasierten Regeln können Sie Ihre Anwendungen vor einer zu großen Anzahl an Anfragen schützen, die Ihre Instanzen überlasten und den Zugriff für legitime Nutzer blockieren würden.
Mit der Ratenbegrenzung ist Folgendes möglich:
- Sie verhindert, dass für einen bestimmten Client die Anwendungsressourcen aufgebraucht werden.
- Sie schützt Ihre Anwendungsinstanzen vor unregelmäßigen und unvorhersehbaren Spitzen von Clientanfragen.
Darüber hinaus können Sie damit, wenn eine Ressource ein hohes Trafficvolumen von einer kleinen Anzahl an Clients bewältigen muss, verhindern, dass andere Clients von hohen Trafficspitzen dieser kleinen Anzahl an Clients betroffen sind. Ihre Ressourcen können so beliebig viele Anfragen bewältigen.
Google Cloud Armor bietet zwei Arten von ratenbasierten Regeln:
- Drosselung: Sie können damit ein maximales Anfragelimit pro Client oder für alle Clients erzwingen. Dazu drosseln Sie einzelne Clients auf einen vom Nutzer konfigurierten Grenzwert.
- Ratenbasierte Sperre: Sie können damit für Anfragen, die einer clientspezifischen Regel entsprechen, Ratenbegrenzungen festlegen und diese Clients dann für einen bestimmten konfigurierten Zeitraum vorübergehend sperren, wenn sie einen vom Nutzer konfigurierten Grenzwert überschreiten.
Wenn Sie eine Regel mit einer preisbasierten Sperraktion konfigurieren, kann sie nicht in eine drosseln. Wenn Sie jedoch eine Regel mit einer Drosselungsaktion konfigurieren, können Sie es später in eine preisbasierte Sperraktion ändern. Weitere Informationen finden Sie unter Ratenbegrenzung auf Basis mehrerer Schlüssel:
Google Cloud Armor wendet den Ratenbegrenzungsgrenzwert auf jedes Back-End. Beispiel: Sie haben zwei Backend-Dienste und konfigurieren eine Rate mit einem Grenzwert von 1.000 Anfragen pro Minute, dann jedes Back-End Dienst kann 1.000 Anfragen pro Minute vor Google Cloud Armor empfangen wendet die Regelaktion an.
Die Auswirkungen der Ratenbegrenzungsregeln in einer Sicherheitsrichtlinie lassen sich in der Vorschau prüfen. Dazu rufen Sie den Vorschaumodus auf und werten die Anfragelogs aus.
Clients für die Ratenbegrenzung ermitteln
Google Cloud Armor ermittelt einzelne Clients für die Ratenbegrenzung mithilfe der folgenden Schlüsseltypen zum Aggregieren von Anfragen und zum Erzwingen von Ratenbegrenzungen:
- ALL: Ein einzelner Schlüssel für alle Clients, deren Anfragen die Bedingung der Regel erfüllen.
- IP: Dies ist ein einzelner Schlüssel für jede Quell-IP-Adresse des Clients, deren Anfragen die Bedingung für den Regelabgleich erfüllen.
- HTTP_HEADER: Ein eindeutiger Schlüssel für jeden eindeutigen HTTP-Header-Wert mit dem Namen konfiguriert. Der Schlüsselwert wird auf die ersten 128 Byte des Headerwerts gekürzt. Der Schlüsseltyp ist standardmäßig auf ALL gesetzt, wenn keine solche Kopfzeile vorhanden ist oder Sie versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden.
- XFF_IP: Ein eindeutiger Schlüssel für jede ursprüngliche Quell-IP-Adresse des Clients.
also die erste IP-Adresse in der Liste der in der
X-Forwarded-For-HTTP-Header. Standardmäßig wird als Schlüsseltyp „IP-Adresse“ verwendet, wenn keine vorhanden ist, der Wert keine gültige IP-Adresse ist oder versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden. - HTTP_COOKIE: Ein eindeutiger Schlüssel für jeden HTTP-Cookiewert mit dem Namen konfiguriert. Der Schlüsselwert wird auf die ersten 128 Byte des Cookiewerts gekürzt. Der Schlüsseltyp lautet standardmäßig ALL, wenn kein solches Cookie vorhanden ist oder versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden.
- HTTP_PATH: Der URL-Pfad der HTTP-Anfrage. Der Schlüsselwert wird auf die ersten 128 Byte gekürzt.
- SNI: Die Servernamensangabe (Server Name Indication) in der TLS-Sitzung der HTTPS-Anfrage. Der Schlüsselwert wird auf die ersten 128 Byte gekürzt. Der Schlüsseltyp wird in einer HTTP-Sitzung standardmäßig auf ALL gesetzt.
- REGION_CODE: Das Land bzw. die Region, aus der die Anfrage stammt.
- TLS_JA3_FINGERPRINT: JA3-TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung mithilfe von
HTTPS,HTTP/2oderHTTP/3. Falls nicht verfügbar, wird standardmäßig der Schlüsseltyp verwendet. ALLE Weitere Informationen zu JA3 finden Sie in der Referenz zur Sprache für Regeln - USER_IP: Die IP-Adresse des ursprünglichen Clients, die in den Headern enthalten ist
unter
userIpRequestHeaderskonfiguriert ist und deren Wert mit einem Upstream-Proxy. Wenn keineuserIpRequestHeaders-Konfiguration oder keine IP-Adresse vorhanden ist Adresse nicht aufgelöst werden kann, ist der Schlüsseltyp standardmäßig IP. Weitere Informationen finden Sie in der Referenz zur Sprache für Regeln
Sie können die vorherigen Schlüssel einzeln oder eine Ratenbegrenzung verwenden
basierend auf einer Kombination
von bis zu drei Schlüsseln. Sie können mehrere HTTP-HEADER verwenden
oder HTTP-COOKIE-Schlüssel und nur einer von beiden Schlüsseltypen. Weitere Informationen
finden Sie unter
Ratenbegrenzung auf Basis mehrerer Schlüssel:
Traffic drosseln
Mit der Aktion throttle in einer Regel können Sie eine Anfrage pro Client erzwingen
um die Back-End-Dienste zu schützen. Diese Regel erzwingt den Grenzwert, um den Traffic von allen Clients zu begrenzen, die die Bedingungen in der Regel erfüllen. Als Grenzwert wird eine bestimmte Anzahl an Anfragen in einem festgelegten Zeitintervall festgelegt.
Beispielsweise können Sie den Anfragegrenzwert auf 2.000 Anfragen innerhalb von 1.200 Sekunden (20 Minuten) festlegen. Wenn ein Client dann innerhalb von 1.200 Sekunden 2.500 Anfragen sendet, werden etwa 20 % des Clienttraffics gedrosselt, bis das zulässige Anfragevolumen den konfigurierten Grenzwert erreicht oder übersteigt.
Wenn die Trafficrate eines Clients den rate_limit_threshold_count nicht überschreitet, folgen Anfragen der conform_action, die immer eine allow-Aktion ist. Die Anfrage wird über die Sicherheitsrichtlinie zugelassen und darf ihr Ziel erreichen. Wenn die Trafficrate eines Clients den angegebenen rate_limit_threshold_count überschreitet, wendet Google Cloud Armor für Anfragen, die den Grenzwertintervall überschreiten die exceed_action an, die entweder deny oder redirect sein kann.
Mit den folgenden Parametern steuern Sie die Aktion:
rate_limit_threshold_count: Die Anzahl der Anfragen pro Client, die innerhalb eines bestimmten Zeitintervalls zulässig sind. Der Wert muss zwischen 1 und dem maximalen Wert 10.000 liegen.interval_sec: Die Anzahl der Sekunden im Zeitintervall. Der Wert muss 19, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
exceed_action: Wenn eine Anfrage denrate_limit_threshold_countüberschreitet, wendet Google Cloud Armor den konfiguriertenexceed_actionan. Folgende Werte sind fürexceed_actionmöglich:deny(status): Die Anfrage wurde abgelehnt und der angegebene Fehlercode ist zurückgegeben (gültige Werte sind403,404,429und502). Wir empfehlen die Verwendung des429 (Too Many Requests)-Antwortcode.redirect: Die Anfrage wird entweder für reCAPTCHA weitergeleitet Prüfung oder auf eine andere URL, je nachexceed_redirect_options.
exceed_redirect_options: Wenn dieexceed_actionden Wertredirecthat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:type: Geben Sie für die Weiterleitungsaktion entwederGOOGLE_RECAPTCHAoderEXTERNAL_302ein.target: URL-Ziel für die Weiterleitungsaktion. Gilt nur, wenn dertypeEXTERNAL_302ist.
conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter demrate_limit_threshold_countliegt. Dies ist immer eineallow-Aktion.
Clients anhand von Anfrageraten sperren
Mit der Aktion rate_based_ban in einer Regel können Sie eine pro Client erzwingen
um Kunden vorübergehend zu sperren, die den Grenzwert überschreiten,
konfiguriert exceed_action für alle Anfragen vom Client für ein konfigurierbares
Zeitraum. Als Grenzwert wird eine bestimmte Anzahl an Anfragen in einem festgelegten Zeitintervall festgelegt. Sie können Traffic für einen vom Nutzer konfigurierten Zeitraum ('ban_duration_sec') vorübergehend sperren, sofern der Traffic der angegebenen Übereinstimmungsbedingung entspricht und den konfigurierten Grenzwert überschreitet.
Beispielsweise können Sie den Anfragegrenzwert auf 2.000 Anfragen innerhalb von 1.200 Sekunden (20 Minuten) festlegen. Wenn ein Client innerhalb von 1.200 Sekunden 2.500 Anfragen sendet, wendet Google Cloud Armor die exceed_action auf den Traffic dieses Clients an, der den Grenzwert von 2.000 Anfragen überschreitet, bis die vollen 1.200 Sekunden verstrichen sind und für eine zusätzliche Anzahl von Sekunden, die Sie als Sperrzeit festlegen.
Wenn für die Dauer der Sperre der Wert 3600 festgelegt ist, wird der Traffic vom Client beispielsweise für 3.600 Sekunden (eine Stunde) nach Ablauf des Grenzwertintervalls gesperrt.
Wenn die Anfragerate eines Clients unter dem Grenzwert der Ratenbegrenzung liegt, kann die Anfrage sofort an den Back-End-Dienst weitergeleitet werden. Wenn die Trafficrate eines Clients den angegebenen rate_limit_threshold_count überschreitet, wendet Google Cloud Armor die exceed_action auf alle eingehenden Anfragen des Clients für den Rest des Grenzwertintervalls und für die nächsten ban_duration_sec Sekunden an, unabhängig davon, ob der Grenzwert überschritten wird oder nicht.
Mit dieser Konfiguration besteht die Möglichkeit, dass Begrüßungsclients zufällig gesperrt weren, die nur gelegentlich die zulässige Anfragerate überschreiten. Um dies zu verhindern und um nur Clients zu sperren, die die Anfragerate häufig überschreiten, können Sie optional die gesamten Clientanfragen anhand des zusätzlichen, vorzugsweise größeren Grenzwerts ban_threshold_count verfolgen. In diesem Modus
Der Client ist für die konfigurierte ban_duration_sec nur dann gesperrt, wenn der
Anfragerate überschreitet die konfigurierte ban_threshold_count. Wenn die Anforderungsrate
den ban_threshold_count nicht überschreitet, werden die Anfragen weiterhin gedrosselt.
an rate_limit_threshold_count. Für ban_threshold_count ist die Summe
vom Client, die alle eingehenden Anfragen
vor der Drosselung umfassen,
zählen.
Die folgenden Parameter steuern die Aktion einer rate_based_ban-Regel:
rate_limit_threshold_count: Die Anzahl der Anfragen pro Client, die innerhalb eines bestimmten Zeitintervalls zulässig sind. Der Mindestwert beträgt 1 Anfrage und der Höchstwert 10.000 Anfragen.interval_sec: Die Anzahl der Sekunden im Zeitintervall. Der Wert muss 19, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
exceed_action: Wenn eine Anfrage denrate_limit_threshold_countüberschreitet, wendet Google Cloud Armor den konfiguriertenexceed_actionan. Folgende Werte sind fürexceed_actionmöglich:deny(status): Die Anfrage wird abgelehnt und der angegebene Fehlercode wird zurückgegeben. Gültige Werte für den Fehlercode sind403,404,429und502. Mi. empfehlen, den Antwortcode429 (Too Many Requests)zu verwenden.redirect: Die Anfrage wird entweder für reCAPTCHA weitergeleitet Prüfung oder auf eine andere URL, je nachexceed_redirect_options.
exceed_redirect_options: Wenn dieexceed_actionden Wertredirecthat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:type: Geben Sie für die Weiterleitungsaktion entwederGOOGLE_RECAPTCHAoderEXTERNAL_302ein.target: URL-Ziel für die Weiterleitungsaktion. Gilt nur, wenn dertypeEXTERNAL_302ist.
conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter demrate_limit_threshold_countliegt. Dies ist immer eineallow-Aktion.ban_threshold_count: Dies ist die Anzahl der pro Client zulässigen Anfragen. innerhalb eines bestimmten Zeitintervalls, über das Google Cloud Armor -Anfragen. Wenn angegeben, ist der Schlüssel für die konfigurierteban_duration_sec, wenn die Anzahl der Anfragen, die den Wertrate_limit_threshold_countüberschreiten ebenfalls diesen Wert vonban_threshold_count.ban_threshold_interval_sec: Die Anzahl der Sekunden im Zeitintervall für Deinban_threshold_count. Der Wert muss 10, 30, 60, 120, 180, 240, 300, 600, 900, 1.200, 1.800, 2.700 oder 3.600 Sekunden.
ban_duration_sec: Dies ist die zusätzliche Anzahl an Sekunden, für die ein Client nach Ablauf des Zeitraums voninterval_secgesperrt wird. Der Wert muss 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
Standard-Sicherheitsrichtlinie für die Ratenbegrenzung
Wenn Sie eine Standard-Sicherheitsrichtlinie während der Erstellung des Load-Balancers konfigurieren, beträgt der Standardschwellenwert 500 Anfragen pro 1-Minuten-Intervall (rate_limit_threshold_count und interval_sec von 500 bzw. 60). Wenn Sie einen anderen Schwellenwert auswählen möchten, empfehlen wir die folgenden Schritte zur Feinabstimmung Ihrer Parameter:
Aktivieren Sie Cloud Logging und fragen Sie das Maximum ab Anzahl der pro IP-Adresse und Minute eingegangenen Anfragen innerhalb eines Tages oder durch Google Cloud Armor geschützten Back-End-Dienst zu erreichen.
Angenommen, Sie glauben, dass 99 % des eingehenden Netzwerktraffics nicht von der Ratenbegrenzungsregel betroffen sein sollten. In diesem Szenario empfehlen wir, den Grenzwert für die Ratenbegrenzung auf das 99. Perzentil Die maximale Anzahl der Anfragen pro IP-Adresse und pro Minute der Verteilung der aus den Cloud Logging-Daten generiert wird.
Wenn Sie weiterhin feststellen, dass Standardregeln für die Ratenbegrenzung legitimen Traffic blockieren, führen Sie die folgenden zusätzlichen Schritte aus:
- Aktivieren Sie das Caching (Cloud CDN oder Media CDN).
- Erhöhen Sie das Drosselungszeitintervall (Anfragen, die innerhalb mehrerer Minuten statt innerhalb von 60 Sekunden empfangen wurden).
- Sie können Clients sperren, um die Auswirkungen von Angriffen nach der ersten Wave weiter zu reduzieren. Mit der Aktion
rate_based_banvon Google Cloud Armor können Sie dies erreichen, indem Sie alle Clients sperren, die die Limits innerhalb eines benutzerdefinierten Zeitfensters zu häufig überschreiten. Beispielsweise können Clients, die die Limits innerhalb einer Minute zehnmal überschreiten, für 15 Minuten gesperrt werden.
Erzwingung von Schwellenwerten
Die konfigurierten Grenzwerte für Drosselung und ratenbasierte Sperren werden separat in jeder Google Cloud-Region erzwungen, in der Ihre HTTP(S)-Back-End-Dienste bereitgestellt sind. Wenn Ihr Dienst beispielsweise in zwei Regionen bereitgestellt wird, begrenzt jede der beiden Regionen die Rate für alle Schlüssel auf den konfigurierten Grenzwert. Daher kann Ihr Back-End-Dienst ein regionsübergreifendes, aggregiertes Trafficvolumen erhalten, das doppelt so hoch wie der konfigurierte Grenzwert ist. Wenn der konfigurierte Grenzwert auf 5.000 Anfragen festgelegt ist, erhält der Back-End-Dienst möglicherweise 5.000 Anfragen aus einer Region und 5.000 Anfragen aus der zweiten Region.
Für die IP-Adresse des Schlüsseltyps kann jedoch davon ausgegangen werden, dass Traffic von derselben Client-IP-Adresse an die Region weitergeleitet wird, die Ihrer Region am nächsten liegt. In diesem Fall kann die Ratenbegrenzung auf der Ebene des Back-End-Dienstes erzwungen werden, unabhängig von den Regionen, in denen der Dienst bereitgestellt wird.
Beachten Sie, dass die erzwungenen Ratenbegrenzungen ungefähre Werte sind und im Vergleich mit den konfigurierten Grenzwerten möglicherweise nicht genau sind. Außerdem kann es in seltenen Fällen aufgrund des internen Routingverhaltens vorkommen, dass die Ratenbegrenzung in mehr Regionen als in den Regionen, in denen Sie Bereitstellungen vorgenommen haben, erzwungen wird. Dies hat Einfluss auf die Genauigkeit der Begrenzung. Deshalb empfehlen wir, die Ratenbegrenzung nur zur Minderung des Missbrauchsrisikos oder zur Aufrechterhaltung der Anwendungs- und Dienstverfügbarkeit zu nutzen, jedoch nicht zur Erzwingung strenger Kontingent- oder Lizenzanforderungen.
Logging
Cloud Logging erfasst den Namen der Sicherheitsrichtlinie, die Priorität der Ratenbegrenzungsregel zum Abgleich, die Regel-ID, die zugehörige Aktion und weitere Informationen in Ihren Anfragelogs. Weitere Informationen zum Logging finden Sie unter Anfrage-Logging verwenden.
Integration mit reCAPTCHA
Sie können eine Ratenbegrenzung auf einige reCAPTCHA-Ressourcen anwenden, um den Missbrauch von Tokens zu verringern und die Wiederverwendung von Tokens zu begrenzen. Zu diesen Ressourcen gehören Aktionstokens, Sitzungstokens und Ausnahme-Cookies. Weitere Informationen zu Ratenbegrenzung mit reCAPTCHA verwenden, siehe Bot-Verwaltung.