Google Cloud Armor offre funzionalità per aiutarti a proteggere le tue applicazioni Google Cloud da una serie di attacchi di livello 3 e 7. Le regole basate sulle tariffe consentono di proteggere le applicazioni da un volume elevato di richieste che sovraccaricano le istanze e bloccano l'accesso per gli utenti legittimi.
La limitazione di frequenza consente di:
- Impedisci a un determinato client di esaurire le risorse dell'applicazione.
- Proteggi le istanze dell'applicazione da picchi erratici e imprevedibili nella frequenza delle richieste client.
Inoltre, quando una risorsa riceve un volume elevato di traffico da un numero ridotto di client, puoi impedire che gli altri client vengano interessati da picchi di traffico elevati, consentendo alle risorse di gestire il maggior numero possibile di richieste.
Google Cloud Armor dispone di due tipi di regole basate sulla frequenza:
- Limitazione: puoi applicare un limite massimo di richieste per client o per tutti i client impostando una soglia configurata dall'utente per i singoli client.
- Ban basato sulla frequenza: puoi limitare la frequenza delle richieste che corrispondono a una regola su base per client e poi vietare temporaneamente questi client per un periodo di tempo configurato se superano una soglia configurata dall'utente.
Quando configuri una regola con un'azione di divieto basata sulla frequenza, non puoi modificarla in un'azione di limitazione in un secondo momento. Tuttavia, quando configuri una regola con un'azione di limitazione, puoi modificarla in un'azione di esclusione basata sulla frequenza in un secondo momento. Per ulteriori informazioni, consulta Limitazione della frequenza in base a più chiavi.
Google Cloud Armor applica la soglia di limitazione di frequenza a ogni backend associato. Ad esempio, se hai due servizi di backend e configuri una regola di limitazione della frequenza con una soglia di 1000 richieste al minuto, ogni servizio di backend può ricevere 1000 richieste al minuto prima che Google Cloud Armor applichi l'azione della regola.
Puoi visualizzare l'anteprima degli effetti delle regole di limitazione di frequenza in un criterio di sicurezza utilizzando la modalità di anteprima ed esaminando i log delle richieste.
Identificazione dei client per la limitazione di frequenza
Google Cloud Armor identifica i singoli client per limitazione di frequenza utilizzando i seguenti tipi di chiavi per aggregare le richieste e applicare i limiti di velocità:
- ALL: una singola chiave per tutti i client le cui richieste soddisfano la condizione di corrispondenza della regola.
- IP: una chiave univoca per ogni indirizzo IP di origine del client le cui richiestesoddisfano la condizione di corrispondenza della regola.
- HTTP_HEADER: una chiave univoca per ogni valore intestazione HTTP univoco il cui nome è configurato. Il valore della chiave viene troncato ai primi 128 byte del valore dell'intestazione. Il tipo di chiave predefinito è TUTTO se non è presente un'intestazione di questo tipo o se provi a utilizzare questo tipo di chiave con un bilanciatore del carico di rete del proxy esterno.
- XFF_IP: una chiave univoca per ogni indirizzo IP di origine originale del client, ovvero il primo indirizzo IP nell'elenco di IP specificati nell'intestazione HTTP
X-Forwarded-For
. Il tipo di chiave predefinito è indirizzo IP se non è presente un'intestazione di questo tipo, se il valore non è un indirizzo IP valido o se provi a utilizzare questo tipo di chiave con un proxy esterno Network Load Balancer. - HTTP_COOKIE: una chiave univoca per ogni valore del cookie HTTP il cui nome è configurato. Il valore della chiave viene troncato ai primi 128 byte del valore del cookie. Il tipo di chiave predefinito è TUTTI se non è presente un cookie di questo tipo o se provi a utilizzare questo tipo di chiave con un bilanciatore del carico di rete del proxy esterno.
- HTTP_PATH: il percorso dell'URL della richiesta HTTP. Il valore della chiave viene troncato ai primi 128 byte.
- SNI: l'indicazione del nome del server nella sessione TLS della richiesta HTTPS. Il valore della chiave viene troncato ai primi 128 byte. Il tipo di chiave predefinito è ALL in una sessione HTTP.
- REGION_CODE: il paese/la regione da cui proviene la richiesta.
- TLS_JA3_FINGERPRINT: impronta TLS/SSL JA3 se il client si connette utilizzando
HTTPS
,HTTP/2
oHTTP/3
. Se non è disponibile, il tipo di chiave predefinito è ALL. Per ulteriori informazioni su JA3, consulta il riferimento al linguaggio delle regole. - USER_IP: l'indirizzo IP del client di origine, incluso nelle intestazioni configurate in
userIpRequestHeaders
e il cui valore viene inserito da un proxy upstream. Se non è presente una configurazioneuserIpRequestHeaders
o se non è possibile risolvere un indirizzo IP, il tipo di chiave predefinito è IP. Per ulteriori informazioni, consulta il riferimento al linguaggio delle regole.
Puoi utilizzare le chiavi precedenti singolarmente oppure applicare il limitazione di frequenza in base a una combinazione di massimo tre chiavi. Puoi utilizzare più chiavi HTTP-HEADER
o HTTP-COOKIE
e una sola di ogni altro tipo di chiave. Per ulteriori informazioni, consulta Limitazione della frequenza in base a più chiavi.
Limitazione del traffico
L'azione throttle
in una regola consente di applicare una soglia di richieste per client per proteggere i servizi di backend. Questa regola applica la soglia per limitare il traffico di ciascun client che soddisfa le condizioni di corrispondenza nella regola. La
soglia è configurata come un numero specificato di richieste in un intervallo di tempo
specificato.
Ad esempio, puoi impostare la soglia di richieste su 2000 richieste in 1200 secondi (20 minuti). Se un client invia 2500 richieste in un periodo di 1200 secondi, circa il 20% del traffico del client viene limitato finché il volume di richieste consentito non raggiunge o non scende al di sotto della soglia configurata.
Quando il tasso di traffico di un client è inferiore o uguale a rate_limit_threshold_count
,
le richieste seguono conform_action
, che è sempre un'azione allow
. La richiesta viene consentita dal criterio di sicurezza e può raggiungere la destinazione. Quando la frequenza di traffico di un cliente supera il valore rate_limit_threshold_count
specificato, Google Cloud Armor applica il valore exceed_action
, che può essere deny
o redirect
, per le richieste oltre il limite per il resto dell'intervallo di soglia.
Imposta questi parametri per controllare l'azione:
rate_limit_threshold_count
: il numero di richieste per client consentito in un intervallo di tempo specificato. Il valore minimo è 1 e il valore massimo è 1.000.000.interval_sec
: il numero di secondi nell'intervallo di tempo. Il valore deve essere 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
exceed_action
: quando una richiesta supera ilrate_limit_threshold_count
, Google Cloud Armor applica ilexceed_action
configurato. I valori possibili perexceed_action
sono:deny(status)
: la richiesta viene rifiutata e viene restituito il codice di errore specificato (i valori validi sono403
,404
,429
e502
). Ti consigliamo di utilizzare il codice di risposta429 (Too Many Requests)
.redirect
: la richiesta viene reindirizzata per la valutazione di reCAPTCHA o a un URL diverso, in base al parametroexceed_redirect_options
.
exceed_redirect_options
: quandoexceed_action
èredirect
, utilizza questo parametro per specificare l'azione di reindirizzamento:type
: digitaGOOGLE_RECAPTCHA
oEXTERNAL_302
per l'azione di reindirizzamento.target
: URL di destinazione per l'azione di reindirizzamento. Applicabile solo quandotype
èEXTERNAL_302
.
conform_action
: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count
. Si tratta sempre di un'azioneallow
.
Ban dei clienti in base alle frequenze di richiesta
L'azione rate_based_ban
in una regola consente di applicare una soglia per client per vietare temporaneamente i client che superano il limite applicando il valore exceed_action
configurato a tutte le richieste del client per un periodo di tempo configurabile. La soglia è configurata come un numero specificato di richieste in un
intervallo di tempo specificato. Puoi vietare temporaneamente il traffico per un periodo di tempo configurato dall'utente ('ban_duration_sec'
), a condizione che il traffico corrisponda alla condizione di corrispondenza specificata e superi la soglia configurata.
Ad esempio, puoi impostare la soglia di richieste su 2000 richieste in 1200 secondi (20 minuti). Se un client invia 2500 richieste in un periodo di 1200 secondi,
Google Cloud Armor applica il exceed_action
al traffico proveniente da quel client
che supera la soglia di 2000 richieste fino al completamento dei 1200 secondi
e per un numero aggiuntivo di secondi impostato come periodo di durata del divieto.
Ad esempio, se il periodo di durata del divieto è impostato su 3600
, il traffico del
client verrà vietato per 3600 secondi (un'ora) oltre la fine dell'intervallo di
soglia.
Quando tasso di richieste di un client è inferiore alla soglia del limite di frequenza, la richiesta viene immediatamente indirizzata al servizio di backend. Quando la frequenza di traffico di un client supera il valore rate_limit_threshold_count
specificato, Google Cloud Armor applica il valore exceed_action
a tutte le richieste in arrivo dal client per il resto dell'intervallo di soglia e per i successivi ban_duration_sec
secondi, indipendentemente dal fatto che la soglia sia stata superata o meno.
Con questa configurazione, è possibile bandire accidentalmente i client di benvenuto che superano solo occasionalmente la tasso di richieste consentita. Per evitare questo problema e vietare solo i client che superano di frequente la tasso di richieste, puoi facoltativamente monitorare le richieste totali dei client in base a una configurazione di soglia aggiuntiva, preferibilmente più lunga, chiamata ban_threshold_count
. In questa modalità, il client viene vietato per il ban_duration_sec
configurato solo se la tasso di richieste supera il ban_threshold_count
configurato. Se la tasso di richieste
non supera ban_threshold_count
, le richieste continuano a essere limitate
a rate_limit_threshold_count
. Ai fini di ban_threshold_count
, vengono conteggiate le richieste totali del client, costituite da tutte le richieste in entrata prima del throttling.
Questi parametri controllano l'azione di una regola rate_based_ban
:
rate_limit_threshold_count
: il numero di richieste per client consentito in un intervallo di tempo specificato. Il valore minimo è 1 richiesta e il valore massimo è 10.000 richieste.interval_sec
: il numero di secondi nell'intervallo di tempo. Il valore deve essere 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
exceed_action
: quando una richiesta supera ilrate_limit_threshold_count
, Google Cloud Armor applica ilexceed_action
configurato. I valori possibili perexceed_action
sono:deny(status)
: la richiesta viene rifiutata e viene restituito il codice di errore specificato. I valori validi per il codice di errore sono403
,404
,429
e502
. Ti consigliamo di utilizzare il codice di risposta429 (Too Many Requests)
.redirect
: la richiesta viene reindirizzata per la valutazione di reCAPTCHA o a un URL diverso, in base al parametroexceed_redirect_options
.
exceed_redirect_options
: quandoexceed_action
èredirect
, utilizza questo parametro per specificare l'azione di reindirizzamento:type
: digitaGOOGLE_RECAPTCHA
oEXTERNAL_302
per l'azione di reindirizzamento.target
: URL di destinazione per l'azione di reindirizzamento. Applicabile solo quandotype
èEXTERNAL_302
.
conform_action
: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count
. Si tratta sempre di un'azioneallow
.ban_threshold_count
: il numero di richieste per client consentito in un intervallo di tempo specificato, oltre il quale Google Cloud Armor vieta le richieste. Se specificato, la chiave viene vietata per il valoreban_duration_sec
configurato quando il numero di richieste che superano il valorerate_limit_threshold_count
supera anche questo valoreban_threshold_count
.ban_threshold_interval_sec
: il numero di secondi nell'intervallo di tempo per il tuoban_threshold_count
. Il valore deve essere 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
ban_duration_sec
: il numero aggiuntivo di secondi per i quali un client viene bannato al termine del periodointerval_sec
. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
Criterio di sicurezza di limitazione di frequenza predefinito
Quando configuri un
criterio di sicurezza predefinito durante la
creazione del bilanciatore del carico, la soglia predefinita è di 500 richieste durante ogni
intervallo di un minuto (rate_limit_threshold_count
e interval_sec
di 500
e
60
, rispettivamente). Se vuoi selezionare una soglia diversa, ti consigliamo di seguire i passaggi riportati di seguito per ottimizzare i parametri:
Attiva Cloud Logging ed esegui query sul numero massimo di richieste ricevute per indirizzo IP e per minuto nell'arco di un giorno o più sul tuo servizio di backend protetto da Google Cloud Armor.
Ad esempio, supponiamo che tu ritenga che il 99% del traffico di rete che ricevi non debba essere interessato dalla regola di limitazione della frequenza. In questo scenario, consigliamo di impostare la soglia di limite di frequenza sul 99° percentile del numero massimo di richieste per indirizzo IP e per minuto della distribuzione generata dai dati di Cloud Logging.
Se noti ancora che le regole di limite di frequenza predefinite bloccano il traffico legittimo, prendi in considerazione i seguenti passaggi aggiuntivi:
- Attiva la memorizzazione nella cache (Cloud CDN o Media CDN).
- Aumenta l'intervallo di tempo della limitazione (richieste ricevute per diversi minuti anziché per 60 secondi).
- Puoi vietare i client per ridurre ulteriormente l'impatto dell'attacco dopo l'ondata iniziale. L'azione
rate_based_ban
di Google Cloud Armor ti consente di farlo impedendo l'accesso a tutti i client che superano i limiti troppe volte in un periodo di tempo specificato dall'utente. Ad esempio, i client che superano i limiti 10 volte in un minuto possono essere vietati per 15 minuti.
Applicazione della soglia
Le soglie configurate per il throttling e i ban basati sulla frequenza vengono applicate indipendentemente in ciascuna delle regioni Google Cloud in cui sono dipiamente i servizi di backend HTTP(S). Ad esempio, se il servizio viene implementato in due regioni, ciascuna delle due regioni limita la frequenza di ogni chiave alla soglia configurata, pertanto il servizio di backend potrebbe registrare volumi di traffico aggregati tra regioni pari al doppio della soglia configurata. Se la soglia configurata è impostata su 5000 richieste, il servizio di backend potrebbe ricevere 5000 richieste da una regione e 5000 richieste dalla seconda regione.
Tuttavia, per l'indirizzo IP del tipo di chiave, è ragionevole presumere che il traffico proveniente dallo stesso indirizzo IP del client venga indirizzato alla regione più vicina a quella in cui sono implementati i tuoi backend. In questo caso, la limitazione di frequenza può essere considerata applicata a livello di servizio di backend, indipendentemente dalle regioni in cui viene implementata.
È importante notare che i limiti di frequenza applicati sono approssimativi e potrebbero non essere rigorosamente accurati rispetto alle soglie configurate. Inoltre, in rari casi, a causa del comportamento di routing interno, è possibile che il limitazione di frequenza venga applicato in più regioni rispetto a quelle in cui è stato eseguito il deployment, con conseguente impatto sulla precisione. Per questi motivi, ti consigliamo di utilizzare limitazione di frequenza solo per ridurre gli abusi o mantenere la disponibilità di applicazioni e servizi, non per applicare requisiti rigorosi di quota o licenza.
Logging
Cloud Logging registra il nome del criterio di sicurezza, la priorità della regola di limite di frequenza corrispondente, l'ID regola, l'azione associata e altre informazioni nei log delle richieste. Per ulteriori informazioni sul logging, consulta Utilizzare il logging delle richieste.
Integrazione con reCAPTCHA
Puoi applicare la limitazione di frequenza ad alcune risorse reCAPTCHA per mitigare gli abusi dei token e limitarne il riutilizzo. tra cui token di azioni, token di sessione e cookie di esenzione. Per ulteriori informazioni sull'utilizzo limitazione di frequenza con reCAPTCHA, consulta la panoramica della gestione dei bot.