Diese Seite enthält Informationen zum Konfigurieren von Google Cloud Armor-Regeln um Ratenbegrenzungen pro Kunde durchzusetzen, indem Sie eine Drosselung oder eine preisbasierte Verbot konfigurieren Aktion ausführen. Bevor Sie die Ratenbegrenzung konfigurieren, sollten Sie sich mit den Informationen in der Übersicht zur Ratenbegrenzung vertraut machen.
Hinweise
In den folgenden Abschnitten werden alle IAM-Rollen (Identity and Access Management) und
Berechtigungen, die zum Konfigurieren von Google Cloud Armor-Sicherheitsrichtlinien erforderlich sind. Für die Anwendungsfälle in diesem Dokument benötigen Sie nur die Berechtigung compute.securityPolicies.create
.
IAM-Berechtigungen für Google Cloud Armor-Sicherheitsrichtlinien einrichten
Für die folgenden Vorgänge ist die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) erforderlich
Rolle „Compute-Sicherheitsadministrator“ (roles/compute.securityAdmin
):
- Google Cloud Armor-Sicherheitsrichtlinien konfigurieren, ändern, aktualisieren und löschen
- Mithilfe der folgenden API-Methoden:
SecurityPolicies insert
SecurityPolicies delete
SecurityPolicies patch
SecurityPolicies addRule
SecurityPolicies patchRule
SecurityPolicies removeRule
Einen Nutzer mit der Rolle „Compute-Netzwerkadministrator“ (roles/compute.networkAdmin
)
kann folgende Vorgänge ausführen:
- Google Cloud Armor-Sicherheitsrichtlinie für einen Back-End-Dienst festlegen
- Mithilfe der folgenden API-Methoden:
BackendServices setSecurityPolicy
BackendServices list
(nurgcloud
)
Nutzer mit der Rolle „Sicherheitsadministrator“ (roles/iam.securityAdmin
)
und die Rolle „Compute Network Admin“ kann die Google Cloud Armor-Sicherheit ansehen
mithilfe der SecurityPolicies
API-Methoden get
, list
und
getRule
IAM-Berechtigungen für benutzerdefinierte Rollen einrichten
In der folgenden Tabelle sind die grundlegenden Berechtigungen der IAM-Rollen und die zugehörigen API-Methoden aufgeführt.
IAM-Berechtigung | API-Methoden |
---|---|
compute.securityPolicies.create |
SecurityPolicies insert |
compute.securityPolicies.delete |
SecurityPolicies delete |
compute.securityPolicies.get |
SecurityPolicies get SecurityPolicies getRule |
compute.securityPolicies.list |
SecurityPolicies list |
compute.securityPolicies.use |
BackendServices setSecurityPolicy |
compute.securityPolicies.update |
SecurityPolicies patch SecurityPolicies addRule SecurityPolicies patchRule SecurityPolicies removeRule |
compute.backendServices.setSecurityPolicy |
BackendServices setSecurityPolicy |
Regeln für ratenbasierte Drosselung
Regeln für die ratenbasierte Drosselung haben in der Google Cloud CLI folgendes Format:
gcloud compute security-policies rules create PRIORITY \ --security-policy=SECURITY_POLICY \ {--expression=EXPRESSION | --src-ip-ranges=SRC_IP_RANGE} \ --action "throttle" \ --rate-limit-threshold-count=RATE_LIMIT_THRESHOLD_COUNT \ --rate-limit-threshold-interval-sec=RATE_LIMIT_THRESHOLD_INTERVAL_SEC \ --conform-action=[allow] \ --exceed-action=[deny-403|deny-404|deny-429|deny-502|redirect] \ --exceed-redirect-type=[google-recaptcha|external-302] \ --exceed-redirect-target=REDIRECT_URL \ --enforce-on-key=[IP | ALL | HTTP-HEADER | XFF-IP | HTTP-COOKIE | HTTP-PATH | SNI | REGION-CODE] \ --enforce-on-key-name=[HTTP_HEADER_NAME|HTTP_COOKIE_NAME]
Ratenbegrenzung für einzelne Schlüssel
Mit dem folgenden gcloud CLI-Befehl wird beispielsweise eine throttle
-Regel mit der Priorität 105
und einer Ratenbegrenzung von 100 Anfragen pro 60 Sekunden für jede IP-Adresse in 1.2.3.0/24
erstellt. Anfragen, die das Drosselungslimit überschreiten, geben den Fehlercode 429
zurück.
gcloud compute security-policies rules create 105 \ --security-policy SECURITY_POLICY \ --src-ip-ranges="1.2.3.0/24" \ --action=throttle \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=60 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key=IP
Beispiel: Mit dem folgenden gcloud CLI-Befehl wird eine throttle
-Regel mit der Priorität 110
und einer Ratenbegrenzung von 10 Anfragen pro 60 Sekunden für jeden eindeutigen Wert des HTTP-Headers User-Agent
für alle Anfragen erstellt, die von IP-Adressen in 1.2.3.0/24
stammen. Anfragen, die das Drosselungslimit überschreiten, geben den Fehlercode 429
zurück.
gcloud compute security-policies rules create 110 \ --security-policy SECURITY_POLICY \ --src-ip-ranges="1.2.3.0/24" \ --action=throttle \ --rate-limit-threshold-count=10 \ --rate-limit-threshold-interval-sec=60 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key=HTTP-HEADER \ --enforce-on-key-name='User-Agent'
Außerdem können Sie ratenbasierte Sperrungen für Nutzer ausgeben, die ein gültiges reCAPTCHA-Ausnahme-Cookie haben. Der folgende gcloud CLI-Befehl erstellt beispielsweise eine throttle
-Regel mit der Priorität 115
und einem Ratenlimit von 20 Anfragen pro 5 Minuten für jedes einzelne reCAPTCHA-Ausnahme-Cookie für alle Anfragen, die ein gültiges reCAPTCHA-Ausnahme-Cookie haben. Anfragen, die die
Drosselungslimits werden zur reCAPTCHA-Bewertung weitergeleitet. Weitere Informationen zu Ausnahme-Cookies und der reCAPTCHA-Bewertung finden Sie in der Übersicht über die Bot-Verwaltung.
gcloud compute security-policies rules create 115 \ --security-policy SECURITY_POLICY \ --expression="token.recaptcha_exemption.valid" \ --action=throttle \ --rate-limit-threshold-count=20 \ --rate-limit-threshold-interval-sec=300 \ --conform-action=allow \ --exceed-action=redirect \ --exceed-redirect-type=google-recaptcha \ --enforce-on-key=HTTP-COOKIE \ --enforce-on-key-name="recaptcha-ca-e"
Ratenbegrenzung auf Basis von JA3-Fingerabdrücken
Sie können JA3-Fingerabdrücke als Schlüssel für die Ratenbegrenzung verwenden. Im folgenden Beispiel wird eine throttle
-Regel mit der Priorität 1000
und einem Ratenlimit von 20 Anfragen pro 5 Minuten erstellt, die Anfragen mit dem Pfad /login
basierend auf dem JA3-Fingerabdruck des Clients abgleicht. Anfragen, die das Drossellimit überschreiten, werden abgelehnt.
gcloud compute security-policies rules create 1000 \ --security-policy SECURITY_POLICY \ --expression "request.path.matches('/login')" \ --action throttle \ --rate-limit-threshold-count 20 \ --rate-limit-threshold-interval-sec 300 \ --conform-action allow \ --exceed-action deny-429 \ --enforce-on-key-configs tls-ja3-fingerprint
Ratenbegrenzung basierend auf der IP-Adresse des Nutzers
Wenn Sie Anfragen über einen Upstream-Proxy erhalten, können Sie die Ratenbegrenzung basierend auf der IP-Adresse des ursprünglichen Clients anwenden. Im folgenden Beispiel wird eine throttle
-Regel mit der Priorität 1000
und einem Ratenlimit von 20 Anfragen pro 5 Minuten erstellt, die Anfragen mit dem Pfad /login
basierend auf der IP-Adresse des ursprünglichen Clients abgleicht. Anfragen, die die Drosselung überschreiten
Limit abgelehnt wurde.
gcloud compute security-policies rules create 1000 \ --security-policy SECURITY_POLICY --expression "request.path.matches('/login')" --action throttle --rate-limit-threshold-count 20 --rate-limit-threshold-interval-sec 300 --conform-action allow --exceed-action deny-429 --enforce-on-key-configs user-ip
Weitere Informationen zur Unterstützung von Nutzer-IP-Adressen finden Sie in der Referenz zur Sprache für Regeln.
Ratenbegrenzung basierend auf mehreren Schlüsseln
Sie können den Traffic auch basierend auf mehreren Ratenbegrenzungsschlüsseln drosseln, indem Sie die Methode
Flag enforce-on-key-configs
. Dieses Flag ersetzt sowohl das Flag enforce-on-key
und das Flag enforce-on-key-name
. Für das Flag enforce-on-key-configs
ist ein
durch Kommas getrennte Liste von KEY=NAME
-Paaren; Sie müssen jedoch keine
Namen für einige Schlüssel ein.
Im folgenden Beispiel wird eine throttle
-Regel für die Richtlinie erstellt
POLICY_NAME mit der Priorität 105
mit einer Ratenbegrenzung von jeweils 100 Anfragen
60 Sekunden für jede Kombination aus HTTP-PATH
und site_id
bei allen Anfragen
die von IP-Adressen in 1.2.3.0/24
stammen. Anfragen, die das Drosselungslimit überschreiten, geben den Fehlercode 429
zurück.
gcloud compute security-policies rules create 105 \ --security-policy=POLICY_NAME \ --src-ip-ranges="1.2.3.0/24" \ --action=throttle \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=60 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key-configs="HTTP-PATH,HTTP-COOKIE=site_id"
Regeln für ratenbasierte Sperren
Regeln für ratenbasierte Sperren haben in der gcloud CLI folgendes Format:
gcloud compute security-policies rules create PRIORITY \ --security-policy=SECURITY_POLICY \ {--expression=EXPRESSION | --src-ip-ranges=SRC_IP_RANGE} \ --action "rate-based-ban" \ --rate-limit-threshold-count=RATE_LIMIT_THRESHOLD_COUNT \ --rate-limit-threshold-interval-sec=RATE_LIMIT_THRESHOLD_INTERVAL_SEC \ --ban-duration-sec=BAN_DURATION_SEC \ --ban-threshold-count=BAN_THRESHOLD_COUNT \ --ban-threshold-interval-sec=BAN_THRESHOLD_INTERVAL_SEC \ --conform-action=[allow] \ --exceed-action=[deny-403|deny-404|deny-429|deny-502|redirect] \ --exceed-redirect-type=[google-recaptcha|external-302] \ --exceed-redirect-target=REDIRECT_URL \ --enforce-on-key=[IP | ALL | HTTP-HEADER | XFF-IP | HTTP-COOKIE | HTTP-PATH | SNI | REGION-CODE] \ --enforce-on-key-name=[HTTP_HEADER_NAME|HTTP_COOKIE_NAME]
Der folgende gcloud CLI-Befehl erstellt beispielsweise eine ratenbasierte Sperrregel mit der Priorität 100
für jede IP-Adresse, deren Anfragen einem fish
-Header mit dem Wert tuna
entsprechen, und sperrt sie für 300 Sekunden, wenn ihre Rate ein Limit von 50 Anfragen pro 120 Sekunden überschreitet. Bei gesperrten Anfragen wird ein Fehlercode zurückgegeben
von 404
.
gcloud compute security-policies rules create 100 \ --security-policy=sec-policy \ --expression="request.headers['fish'] == 'tuna'" \ --action=rate-based-ban \ --rate-limit-threshold-count=50 \ --rate-limit-threshold-interval-sec=120 \ --ban-duration-sec=300 \ --conform-action=allow \ --exceed-action=deny-404 \ --enforce-on-key=IP
Der folgende gcloud-Befehl erstellt beispielsweise eine ratenbasierte Sperrregel mit der Priorität 101
, um alle Anfragen mit dem Regionscode US
auf 10 Anfragen pro 60 Sekunden zu begrenzen. Die Regel sperrt außerdem Anfragen aus der Region US
für 300 Sekunden, wenn ihre Rate ein Limit von 1.000 Anfragen pro 600 Sekunden überschreitet.
Gesperrte Anfragen geben den Fehlercode 403
zurück.
gcloud compute security-policies rules create 101 \ --security-policy sec-policy \ --expression "origin.region_code == 'US'" \ --action rate-based-ban \ --rate-limit-threshold-count 10 \ --rate-limit-threshold-interval-sec 60 \ --ban-duration-sec 300 \ --ban-threshold-count 1000 \ --ban-threshold-interval-sec 600 \ --conform-action allow \ --exceed-action deny-403 \ --enforce-on-key ALL
Der folgende Befehl der gcloud CLI erstellt beispielsweise eine ratenbasierte Sperrregel mit der Priorität 102
, um alle Anfragen aus einem Quell-IP-Adressbereich auf 20 Anfragen pro 60 Sekunden zu beschränken. Außerdem sind mit der Regel Anfragen aus beliebigen Quellen ausgeschlossen.
IP-Adressbereich für 600 Sekunden, wenn die Anfragerate den Grenzwert von
500 Anfragen pro 400 Sekunden. Bei gesperrten Anfragen wird der Fehlercode 429
zurückgegeben.
gcloud compute security-policies rules create 102 \ --security-policy sec-policy \ --src-ip-ranges="*" \ --action rate-based-ban \ --rate-limit-threshold-count 20 \ --rate-limit-threshold-interval-sec 60 \ --ban-duration-sec 600 \ --ban-threshold-count 500 \ --ban-threshold-interval-sec 400 \ --conform-action allow \ --exceed-action deny-429 \ --enforce-on-key ALL
Drosselungsregel in preisbasierte Blockregel ändern
Mit dem folgenden Befehl können Sie die Aktion einer vorhandenen Regel von einer Drosselungsaktion in eine ratenbasierte Sperrung ändern.
gcloud compute security-policies rules update 105 \ --action=rate-based-ban \ --security-policy=sec-policy \ --ban-duration-sec=600
Sie können die Aktion einer vorhandenen Regel nicht von einer ratenbasierten Sperre in eine Drosselaktion ändern.