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 sulla frequenza consentono di proteggere le applicazioni da un grande volume di richieste che inondano le istanze e bloccano l'accesso per gli utenti legittimi.
La limitazione di frequenza può:
- Impedisci a un client specifico di esaurire le risorse dell'applicazione.
- Proteggi le istanze delle tue applicazioni da picchi irregolari e imprevedibili nel tasso di richieste client.
Inoltre, quando una risorsa viene presentata con un volume elevato di traffico da un numero ridotto di client, puoi evitare che gli altri tuoi client siano interessati da grandi picchi di traffico da un numero ridotto di client, consentendo alle tue risorse di gestire il maggior numero possibile di richieste.
Google Cloud Armor ha due tipi di regole basate sulle tariffe:
- Limitazione: puoi applicare un limite massimo di richieste per client o per tutti i client limitando i singoli client in base a una soglia configurata dall'utente.
- Esclusione basata sulla frequenza: puoi limitare le richieste che corrispondono a una regola in base ai singoli client e quindi escludere temporaneamente questi client per un periodo di tempo configurato se superano una soglia configurata dall'utente.
Google Cloud Armor applica la soglia di limitazione di frequenza a ciascun 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, ciascun 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 clienti per la limitazione di frequenza
Google Cloud Armor identifica i singoli client per la limitazione di frequenza utilizzando i seguenti tipi di chiavi per l'aggregazione delle richieste e l'applicazione dei limiti di frequenza:
- 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 richieste soddisfano la condizione di corrispondenza della regola.
- HTTP_HEADER: una chiave univoca per ogni valore di 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 è ALL per impostazione predefinita se questa intestazione non è presente o se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico di rete 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 è impostato su Indirizzo IP per impostazione predefinita se questa intestazione non è presente, se il valore non è un indirizzo IP valido o se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico di rete proxy esterno. - 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 è impostato su ALL per impostazione predefinita se non è presente questo cookie o se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico di rete 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. Per impostazione predefinita, il tipo di chiave è ALL in una sessione HTTP.
- REGION_CODE: il paese o la regione da cui ha origine la richiesta.
- TLS_JA3_FINGERPRINT: impronta TLS/SSL JA3 se il client si connette utilizzando
HTTPS,HTTP/2oHTTP/3. Se non è disponibile, il tipo di chiave è impostato su ALL per impostazione predefinita. 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
userIpRequestHeaderse il cui valore è riempito da un proxy upstream. Se non esiste una configurazioneuserIpRequestHeaderso se un indirizzo IP non può essere risolto da tale configurazione, il tipo di chiave è impostato su IP per impostazione predefinita. Per ulteriori informazioni, consulta il riferimento al linguaggio delle regole.
Puoi utilizzare le chiavi precedenti singolarmente o applicare una limitazione di frequenza in base a una combinazione di massimo tre chiavi. Puoi utilizzare più chiavi HTTP-HEADER o HTTP-COOKIE e solo una di ogni altro tipo di chiave. Per ulteriori
informazioni, consulta
Limitazione di frequenza basata su 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 proveniente da ogni client che soddisfa le condizioni di corrispondenza della regola. La soglia è configurata come numero specificato di richieste in un intervallo di tempo specificato.
Ad esempio, puoi impostare la soglia di richiesta su 2000 richieste entro 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 supera la soglia configurata.
Quando la frequenza di traffico di un client è inferiore o uguale al valore rate_limit_threshold_count,
le richieste seguono il conform_action, che è sempre un'azione allow. La richiesta viene
consentita tramite il criterio di sicurezza e può raggiungere la destinazione. Quando la frequenza di traffico di un client supera il valore rate_limit_threshold_count specificato, Google Cloud Armor applica exceed_action, che può essere deny o redirect, per le richieste che superano il limite per il resto dell'intervallo di soglia.
Imposta i seguenti 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 è 10.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 il valore dirate_limit_threshold_count, Google Cloud Armor applica l'elementoexceed_actionconfigurato. I valori possibili perexceed_actionsono i seguenti:deny(status): la richiesta viene rifiutata e il codice di errore specificato viene restituito (i valori validi sono403,404,429e502). Ti consigliamo di utilizzare il codice di risposta429 (Too Many Requests).redirect: la richiesta viene reindirizzata per la valutazione reCAPTCHA o a un URL diverso, in base al parametroexceed_redirect_options.
exceed_redirect_options: se il valore diexceed_actionèredirect, utilizza questo parametro per specificare l'azione di reindirizzamento:type: digita l'azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: target URL per l'azione di reindirizzamento. Applicabile solo quando il valore ditypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count. È sempre un'azioneallow.
Esclusione dei client in base alle percentuali di richieste
L'azione rate_based_ban in una regola consente di applicare una soglia per client
per escludere temporaneamente i client che superano il limite applicando il valore
exceed_action configurato per tutte le richieste da parte del client per un periodo di tempo
configurabile. La soglia è configurata come numero specificato di richieste in un intervallo di tempo specificato. Puoi escludere 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 richiesta su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste entro 1200 secondi, Google Cloud Armor applica exceed_action al traffico proveniente dal client che supera la soglia di 2000 richieste fino a quando non sono trascorsi tutti i 1200 secondi e per il numero di secondi aggiuntivo impostato come periodo di durata dell'esclusione.
Se il periodo di durata dell'esclusione è impostato su 3600, ad esempio, il traffico proveniente dal client verrebbe escluso per 3600 secondi (un'ora) oltre la fine dell'intervallo di soglia.
Quando tasso di richieste di un client è al di sotto della soglia del limite di frequenza, la richiesta può procedere immediatamente al servizio di backend. Quando la frequenza di traffico di un client
supera il valore rate_limit_threshold_count specificato, Google Cloud Armor applica
exceed_action a tutte le richieste in entrata dal client per il resto dell'intervallo di
soglia e per i successivi ban_duration_sec secondi, indipendentemente dal
superamento o meno della soglia.
Con questa configurazione, è possibile escludere accidentalmente i client di benvenuto che superano solo occasionalmente la tasso di richieste consentita. Per evitare questo problema ed escludere
solo i client che superano spesso latasso di richiestee, puoi
facoltativamente monitorare le richieste totali dei client a fronte di un'ulteriore configurazione di soglia, preferibilmente
più lunga, denominata ban_threshold_count. In questa modalità, il client viene escluso per l'elemento ban_duration_sec configurato solo se la tasso di richieste supera il valore 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. Per lo scopo di ban_threshold_count, vengono conteggiate
le richieste totali dal client, incluse tutte le richieste in entrata prima della limitazione.
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 il valore dirate_limit_threshold_count, Google Cloud Armor applica l'elementoexceed_actionconfigurato. I valori possibili perexceed_actionsono i seguenti:deny(status): la richiesta viene rifiutata e il codice di errore specificato viene restituito. I valori validi per il codice di errore sono403,404,429e502. Ti consigliamo di utilizzare il codice di risposta429 (Too Many Requests).redirect: la richiesta viene reindirizzata per la valutazione reCAPTCHA o a un URL diverso, in base al parametroexceed_redirect_options.
exceed_redirect_options: se il valore diexceed_actionèredirect, utilizza questo parametro per specificare l'azione di reindirizzamento:type: digita l'azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: target URL per l'azione di reindirizzamento. Applicabile solo quando il valore ditypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count. È sempre un'azioneallow.ban_threshold_count: il numero di richieste per client consentito in un intervallo di tempo specificato, oltre il quale Google Cloud Armor esclude le richieste. Se specificata, la chiave viene esclusa per l'ban_duration_secconfigurata quando il numero di richieste che superanorate_limit_threshold_countsupera anche questo valore diban_threshold_count.ban_threshold_interval_sec: il numero di secondi nell'intervallo di tempo perban_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 in cui un client viene escluso una volta trascorso il periodo diinterval_sec. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
Criterio di sicurezza per limitazione di frequenza predefinita
Quando configuri un criterio di sicurezza predefinito durante la creazione del bilanciatore del carico, la soglia predefinita è di 500 richieste in ogni intervallo di un minuto (rispettivamente rate_limit_threshold_count e interval_sec di 500 e 60). Se vuoi selezionare una soglia diversa, ti consigliamo di seguire questi passaggi per ottimizzare i parametri:
Abilita Cloud Logging ed esegui query sul numero massimo di richieste arrivate per indirizzo IP e al minuto nell'arco di un giorno o più presso il 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 sia influenzato dalla regola per la limitazione di frequenza. In questo scenario, ti consigliamo di impostare la soglia del limite di frequenza sul 99° percentile del numero massimo di richieste per indirizzo IP e al minuto di distribuzione generata dai dati di Cloud Logging.
Se noti ancora regole di limitazione di frequenza predefinite che bloccano il traffico legittimo, segui questi passaggi aggiuntivi:
- Abilita la memorizzazione nella cache (Cloud CDN o Media CDN).
- Aumenta l'intervallo di tempo della limitazione (richieste ricevute ogni più minuti, anziché ogni 60 secondi).
- Puoi escludere i client per ridurre ulteriormente l'impatto dell'attacco dopo l'ondata iniziale. A tale scopo, l'azione Google Cloud Armor
rate_based_banti consente di escludere tutti i client che superano i limiti troppe volte in una finestra specificata dall'utente. Ad esempio, i client che superano i limiti 10 volte in un minuto possono essere esclusi per 15 minuti.
Applicazione della soglia
Le soglie configurate per la limitazione e le esclusioni basate sulla frequenza vengono applicate in modo indipendente in ciascuna delle regioni di Google Cloud in cui viene eseguito il deployment dei servizi di backend HTTP(S). Ad esempio, se il deployment del tuo servizio viene eseguito in due regioni, la frequenza di ciascuna di esse limita ogni chiave alla soglia configurata, per cui il tuo servizio di backend potrebbe riscontrare 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.
Tuttavia, per l'indirizzo IP del tipo di chiave, è ragionevole presumere che il traffico proveniente dallo stesso indirizzo IP client sia indirizzato alla regione più vicina a quella in cui è stato eseguito il deployment dei backend. In questo caso, la limitazione di frequenza può essere considerata applicata in modo forzato a livello di servizio di backend, indipendentemente dalle regioni in cui viene eseguito il deployment.
È importante notare che i limiti di frequenza applicati sono approssimativi e potrebbero non essere strettamente precisi rispetto alle soglie configurate. Inoltre, in rari casi, a causa del comportamento di routing interno, è possibile che la limitazione di frequenza venga applicata in più regioni rispetto a quelle in cui è stato eseguito il deployment, con ripercussioni sull'accuratezza. Per questi motivi, ti consigliamo di utilizzare la limitazione di frequenza solo per la mitigazione degli abusi o per mantenere la disponibilità di applicazioni e servizi, non per applicare requisiti rigidi per le quote o le licenze.
Logging
Cloud Logging registra il nome del criterio di sicurezza, la priorità delle regole del limite di frequenza abbinato, l'ID regola, l'azione associata e altre informazioni nei log delle richieste. Per ulteriori informazioni sul logging, consulta Utilizzo del logging delle richieste.
Integrazione con reCAPTCHA
Puoi applicare la limitazione di frequenza ad alcune risorse reCAPTCHA per mitigare l'abuso dei token e limitarne il riutilizzo. Queste risorse includono token di azione, token di sessione e cookie di esenzione. Per ulteriori informazioni sull'utilizzo della limitazione di frequenza con reCAPTCHA, consulta la panoramica della gestione dei bot.