Ratenbegrenzung – Übersicht

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.

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 ratenbasierten Sperraktion konfigurieren, können Sie sie später nicht mehr in eine Drosselungsaktion ändern. Wenn Sie jedoch eine Regel mit einer Drosselungsaktion konfigurieren, können Sie sie später in eine ratenbasierte Sperraktion ändern. Weitere Informationen finden Sie unter Drosselungsregel in eine ratenbasierte Sperrregel ändern.

Cloud Armor wendet den Ratenbegrenzungsschwellenwert auf jedes zugehörige Backend an. Wenn Sie beispielsweise zwei Back-End-Dienste haben und eine Ratenbegrenzungsregel mit einem Grenzwert von 1.000 Anfragen pro Minute konfigurieren, kann jeder Back-End-Dienst 1.000 Anfragen pro Minute empfangen, bevor Cloud Armor die Regelaktion anwendet.

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

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 Anfragen, die die Bedingung für den Regelabgleich erfüllen.
  • IP: Ein eindeutiger 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, dessen Name konfiguriert ist. Der Schlüsselwert wird auf die ersten 128 Byte des Headerwerts gekürzt. Der Schlüsseltyp wird standardmäßig auf ALL gesetzt, wenn kein solcher Header vorhanden ist oder wenn 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, d. h. die erste IP-Adresse in der Liste der im HTTP-Header X-Forwarded-For angegebenen IP-Adressen. Der Schlüsseltyp ist standardmäßig die IP-Adresse, wenn kein solcher Header vorhanden ist, wenn der Wert keine gültige IP-Adresse ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden.
  • HTTP_COOKIE: Ein eindeutiger Schlüssel für jeden HTTP-Cookiewert, dessen Name konfiguriert ist. Der Schlüsselwert wird auf die ersten 128 Byte des Cookiewerts gekürzt. Der Schlüsseltyp wird standardmäßig auf ALL gesetzt, wenn kein solches Cookie vorhanden ist oder wenn Sie 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 oder die Region, aus der die Anfrage stammt.
  • TLS_JA4_FINGERPRINT: JA4-TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung über HTTPS, HTTP/2 oder HTTP/3 herstellt. Wenn nicht verfügbar, wird der Schlüsseltyp standardmäßig auf ALLE gesetzt. Weitere Informationen zu JA4 finden Sie in der Referenz zur Sprache für Regeln.
  • TLS_JA3_FINGERPRINT: JA3-TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung über HTTPS, HTTP/2 oder HTTP/3 herstellt. Wenn nicht verfügbar, wird der Schlüsseltyp standardmäßig auf ALLE gesetzt.
  • USER_IP: Die IP-Adresse des ursprünglichen Clients, die in den Headern enthalten ist, die unter userIpRequestHeaders konfiguriert sind und deren Wert von einem Upstream-Proxy eingefügt wird. Wenn keine userIpRequestHeaders-Konfiguration vorhanden ist oder daraus keine IP-Adresse aufgelöst werden kann, wird der Schlüsseltyp standardmäßig auf „IP“ gesetzt. Weitere Informationen finden Sie in der Referenz zur Sprache für Regeln.

Sie können die oben genannten Schlüssel einzeln verwenden oder die Ratenbegrenzung auf einer Kombination aus bis zu drei Schlüsseln basieren. Sie können mehrere HTTP-HEADER- oder HTTP-COOKIE-Schlüssel und nur einen Schlüssel jedes anderen Typs verwenden. Weitere Informationen finden Sie unter Ratenbegrenzung basierend auf mehreren Schlüsseln.

Zwischen ratenbasierten Sperr- und Drosselratenbegrenzungsregeln wählen

Die Regeln für die Ratenbegrenzung von Cloud Armor rate-based ban und throttle unterscheiden sich darin, wie sie Traffic verarbeiten, der den konfigurierten Schwellenwert überschreitet.

  • rate_based_ban: Wenn die Rate der Anfragen den definierten Grenzwert überschreitet, blockiert Cloud Armor alle weiteren Anfragen von der Quelle oder dem Ziel dieser Anfragen für einen bestimmten Zeitraum.
  • throttle: Anstatt den gesamten Traffic zu blockieren, wird durch die Drosselung die Anzahl der Anfragen auf ein definiertes Maximum begrenzt. Durch die Drosselung kann ein Teil des Traffics durchgelassen werden, jedoch mit einer kontrollierten Rate, die eine Überlastung verhindert.

Die am besten geeignete Regel hängt von Ihren spezifischen Anforderungen und dem Traffictyp ab, mit dem Sie es zu tun haben. Wenn Sie beispielsweise mit einer DDoS-Attacke konfrontiert sind, ist ein ratenbasierter Bann möglicherweise besser geeignet, um den schädlichen Traffic schnell zu blockieren. Wenn Sie einen plötzlichen Anstieg des legitimen Traffics feststellen, ist die Drosselung möglicherweise eine bessere Option, um die Dienstverfügbarkeit aufrechtzuerhalten und gleichzeitig eine Überlastung zu verhindern.

Traffic drosseln

Mit der Aktion throttle in einer Regel können Sie pro Client einen Anfragegrenzwert erzwingen, um 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 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 1.000.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 den rate_limit_threshold_count überschreitet, wendet Cloud Armor den konfigurierten exceed_action an. Folgende Werte sind für exceed_action möglich:
    • deny(status): Die Anfrage wird abgelehnt und der angegebene Statuscode wird zurückgegeben. Gültige Werte sind 403 Forbidden, 404 Page Not Found, 429 Too Many Requests und 502 Bad Gateway. Wir empfehlen die Verwendung des Statuscodes 429 Too Many Requests.
    • redirect: Die Anfrage wird entweder für die reCAPTCHA-Prüfung oder anhand des Parameters exceed_redirect_options an eine andere URL weitergeleitet.
  • exceed_redirect_options: Wenn die exceed_action den Wert redirect hat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:
    • type: Typ für die Weiterleitungsaktion, entweder GOOGLE_RECAPTCHA oder EXTERNAL_302.
    • target: URL-Ziel für die Weiterleitungsaktion. Gilt nur, wenn das type EXTERNAL_302 ist.
  • conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter dem rate_limit_threshold_count liegt. Diese Aktion ist immer eine allow-Aktion.

Clients anhand von Anfrageraten sperren

Mit der Aktion rate_based_ban in einer Regel können Sie einen Grenzwert pro Client durchsetzen, um Clients, die das Limit überschreiten, vorübergehend zu sperren. Wenden Sie dazu die konfigurierte exceed_action für alle Anfragen des Clients für einen konfigurierbaren Zeitraum an. 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 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 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 wird der Client nur dann für die konfigurierten ban_duration_sec gesperrt, wenn die Anfragerate den konfigurierten Wert für ban_threshold_count überschreitet. Wenn die Anforderungsrate ban_threshold_count nicht überschreitet, werden die Anfragen weiter auf rate_limit_threshold_count gedrosselt. Für ban_threshold_count wird die Gesamtzahl der Anfragen vom Client gezählt. Diese ergibt sich aus allen eingehenden Anfragen vor der Drosselung.

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 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
  • exceed_action: Wenn eine Anfrage den rate_limit_threshold_count überschreitet, wendet Cloud Armor den konfigurierten exceed_action an. Folgende Werte sind für exceed_action möglich:
    • deny(status): Die Anfrage wird abgelehnt und der angegebene Statuscode wird zurückgegeben. Gültige Werte sind 403 Forbidden, 404 Page Not Found, 429 Too Many Requests und 502 Bad Gateway. Wir empfehlen die Verwendung des Statuscodes 429 Too Many Requests.
    • redirect: Die Anfrage wird entweder für die reCAPTCHA-Prüfung oder anhand des Parameters exceed_redirect_options an eine andere URL weitergeleitet.
  • exceed_redirect_options: Wenn die exceed_action den Wert redirect hat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:
    • type: Geben Sie für die Weiterleitungsaktion entweder GOOGLE_RECAPTCHA oder EXTERNAL_302 ein.
    • target: Das URL-Ziel für die Weiterleitungsaktion. Dieses URL-Ziel gilt nur, wenn das type EXTERNAL_302 ist.
  • conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter dem rate_limit_threshold_count liegt. Diese Aktion ist immer eine allow-Aktion.
  • ban_threshold_count: Die Anzahl der Anfragen pro Client, die innerhalb eines bestimmten Zeitintervalls zulässig sind, über das Cloud Armor Anfragen sperrt. Wenn angegeben, wird der Schlüssel für die konfigurierte Zeit ban_duration_sec gesperrt, wenn die Anzahl der Anfragen, die das Limit rate_limit_threshold_count überschreiten, auch diesen Wert ban_threshold_count überschreitet.
    • ban_threshold_interval_sec: Die Anzahl der Sekunden im Zeitintervall für Ihren ban_threshold_count. Der ban_threshold_interval_sec-Wert muss 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
  • ban_duration_sec: Dies ist die zusätzliche Anzahl an Sekunden, für die ein Client nach Ablauf des Zeitraums von interval_sec gesperrt wird. Der Wert für ban_duration_sec 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:

  1. Aktivieren Sie Cloud Logging und fragen Sie die maximale Anzahl von Anfragen ab, die pro IP-Adresse und pro Minute über einen Tag oder länger bei Ihrem durch Cloud Armor geschützten Backend-Dienst eingehen.

    Angenommen, Sie glauben, dass 99% des eingehenden Netzwerktraffics nicht von der Ratenbegrenzungsregel betroffen sind. In diesem Szenario empfehlen wir, den Schwellenwert für die Ratenbegrenzung auf das 99. Perzentil der maximalen Anzahl von Anfragen pro IP-Adresse und Minute der Verteilung festzulegen, die aus den Cloud Logging-Daten generiert wird.

  2. Wenn Sie weiterhin feststellen, dass Standardregeln für die Ratenbegrenzung legitimen Traffic blockieren, führen Sie die folgenden zusätzlichen Schritte aus:

    1. Aktivieren Sie das Caching (Cloud CDN oder Media CDN).
    2. Erhöhen Sie das Drosselungszeitintervall (Anfragen, die innerhalb mehrerer Minuten statt innerhalb von 60 Sekunden empfangen wurden).
    3. Sie können Clients sperren, um die Auswirkungen von Angriffen nach der ersten Wave weiter zu reduzieren. Mit der Aktion rate_based_ban von Cloud Armor können 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, wendet jede der beiden Regionen den konfigurierten Grenzwert für die Ratenbegrenzung auf jeden Schlüssel an. 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.

Bei der Ratenbegrenzung basierend auf REGION_CODE wird die Region berücksichtigt, aus der die Anfrage stammt, nicht aber die Region der Back-Ends im Back-End-Dienst, unabhängig von ihrem Typ. Back-Ends umfassen Instanzgruppen, alle Arten von Netzwerk-Endpunktgruppen (NEGs), die von den Load-Balancern unterstützt werden, und Cloud Storage-Buckets. Unterstützte Back-Ends finden Sie in der Übersicht über Sicherheitsrichtlinien.

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.

Einbindung in reCAPTCHA

Sie können die Ratenbegrenzung auf einige reCAPTCHA-Ressourcen anwenden, um den Missbrauch von Tokens zu verhindern und die Wiederverwendung von Tokens zu begrenzen. Zu diesen Ressourcen gehören Aktionstokens, Sitzungstokens und Ausnahme-Cookies. Weitere Informationen zur Verwendung der Ratenbegrenzung mit reCAPTCHA finden Sie in der Übersicht zur Bot-Verwaltung.

Benutzerdefinierte Fehlerantworten

Sie können benutzerdefinierte Fehlerantworten auf Cloud Armor-Ratenbegrenzung anwenden, einschließlich throttle- und rate_based_ban-Traffic. Wenn diese Beschränkungen durchgesetzt werden, werden benutzerdefinierte Fehlermeldungen an Endnutzer gesendet. Wenn Sie einen globalen externen Application Load Balancer verwenden, können Sie außerdem benutzerdefinierte Fehlerantworten für bestimmte HTTP-Statuscodes konfigurieren, die von Load Balancern oder Backend-Instanzen generiert werden.

Weitere Informationen zu benutzerdefinierten Fehlerantworten finden Sie in der Übersicht über benutzerdefinierte Fehlerantworten. Informationen zum Konfigurieren benutzerdefinierter Fehlerantworten finden Sie unter Benutzerdefinierte Fehlerantworten konfigurieren.

Cloud Armor mit Cloud Service Mesh

Sie können interne Dienstsicherheitsrichtlinien für Ihr Service Mesh konfigurieren, um die globale serverseitige Ratenbegrenzung pro Client zu erzwingen. So können Sie die verfügbare Kapazität Ihres Dienstes fair aufteilen und das Risiko minimieren, dass böswillige oder fehlerhafte Clients Ihre Dienste überlasten. Sie hängen eine Sicherheitsrichtlinie an eine Cloud Service Mesh-Endpunktrichtlinie an, um die Ratenbegrenzung für eingehenden Traffic auf Serverseite zu erzwingen. Wenn Sie TCP-Traffic-Routing verwenden, können Sie jedoch keine Google Cloud Armor-Sicherheitsrichtlinie konfigurieren. Weitere Informationen zur Verwendung von Cloud Armor mit Cloud Service Mesh finden Sie unter Ratenbegrenzung mit Cloud Armor konfigurieren.

Nächste Schritte