Panoramica della limitazione di frequenza

Google Cloud Armor offre funzionalità che ti aiutano a proteggere le tue applicazioni Google Cloud da una varietà di attacchi di livello 3 e 7. Le regole basate sulla tariffa consentono di proteggere le applicazioni da un elevato volume di richieste che inondano le istanze e bloccano l'accesso per gli utenti legittimi.

La limitazione di frequenza può:

  • Impedisci a qualsiasi client specifico di esaurire le risorse dell'applicazione.
  • Proteggi le istanze dell'applicazione da picchi irregolari e imprevedibili nella frequenza delle richieste del client.

Inoltre, quando una risorsa presenta un volume di traffico elevato da un numero ridotto di client, puoi impedire agli altri client di essere interessati da picchi di traffico ridotti da parte di tale numero, consentendo alle risorse di gestire il maggior numero possibile di richieste.

Google Cloud Armor ha due tipi di regole basate sulla tariffa:

  1. Limitazione: puoi applicare un limite di richieste massimo per client o per tutti i client limitando i singoli client a una soglia configurata dall'utente.
  2. Esclusione basata sulle tariffe: puoi limitare le richieste di frequenza che corrispondono a una regola in base al singolo cliente e, successivamente, escludere temporaneamente tali client per un periodo di tempo configurato se superano una soglia configurata dall'utente.

Puoi visualizzare l'anteprima degli effetti delle regole di limitazione della frequenza in un criterio di sicurezza utilizzando la modalità di anteprima ed esaminando i log delle richieste.

Identificare i 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 delle limitazioni 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 dell'origine client le cui richieste soddisfano la condizione di corrispondenza della regola.
  • HTTP-Header: una chiave univoca per ogni valore di intestazione HTTP univoco di cui è stato configurato il nome. La coppia chiave-valore viene troncata ai primi 128 byte del valore dell'intestazione. Il tipo di chiave è Predefinito per tutti se non è presente alcuna intestazione o se si cerca di utilizzare questo tipo di chiave con un bilanciatore del carico proxy TCP o un bilanciatore del carico proxy SSL.
  • XFF-IP: una chiave univoca per ogni indirizzo IP di origine originale del client, ovvero il primo indirizzo IP nell'elenco degli IP specificato nell'intestazione HTTP X-Forwarded-For. Per impostazione predefinita, il tipo di chiave è Indirizzo IP se non è presente tale intestazione, se il valore non è un indirizzo IP valido o se si cerca di utilizzare questo tipo di chiave con un bilanciatore del carico del proxy TCP o un bilanciatore del carico del proxy SSL.
  • HTTP-COOKIE: una chiave univoca per ogni valore di cookie HTTP il cui nome è configurato. La coppia chiave-valore viene troncata ai primi 128 byte del valore del cookie. Il tipo di chiave è predefinito per TUTTO se non è presente questo cookie o se stai tentando di utilizzare questo tipo di chiave con un bilanciatore del carico proxy TCP o un bilanciatore del carico proxy SSL.

Limitazione del traffico

L'azione throttle in una regola consente di applicare una soglia di richiesta per client per proteggere i servizi di backend. Questa regola applica la soglia per limitare il traffico di ogni client che soddisfa le condizioni di corrispondenza nella regola. La soglia è configurata come numero specificato di richieste in un intervallo di tempo specificato.

Ad esempio, puoi impostare la soglia della 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 delle richieste consentito non supera la soglia configurata.

Per controllare l'azione, devi impostare questi parametri:

  • rate_limit_threshold: numero di richieste per client consentite in un intervallo di tempo specificato. Il valore minimo è 1,quello massimo è 10.000.
    • interval_sec: numero di secondi nell'intervallo di tempo. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
  • exceed_action: quando una richiesta supera il rate_limit_threshold, Google Cloud Armor applica il exceed_action configurato. I valori possibili per exceed_action sono i seguenti:
    • deny(status): la richiesta viene rifiutata e il codice di errore specificato viene restituito (i valori validi sono 403, 404, 429 e 502). Ti consigliamo di utilizzare il codice di risposta 429 (Too Many Requests).
    • redirect: la richiesta viene reindirizzata alla valutazione reCAPTCHA Enterprise o a un URL diverso, in base al parametro exceed_redirect_options.
  • exceed_redirect_options: quando exceed_action è redirect, utilizza questo parametro per specificare l'azione di reindirizzamento:
    • type: digita per l'azione di reindirizzamento, GOOGLE_RECAPTCHA o EXTERNAL_302.
    • target: target dell'URL per l'azione di reindirizzamento. Applicabile solo quando type è EXTERNAL_302.
  • conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore a rate_limit_threshold. Questa è sempre un'azione allow.

Quando la percentuale di traffico di un client è inferiore o uguale a rate_limit_threshold, le richieste seguono la conform-action, che è sempre un'azione allow. La richiesta è consentita tramite il criterio di sicurezza e può raggiungere la sua destinazione. Quando la frequenza di traffico di un client supera il valore rate_limit_threshold specificato, Google Cloud Armor applica l'elemento exceed_action, che può essere deny o redirect, per le richieste che superano il limite relativo al resto dell'intervallo di soglia.

Esclusione dei clienti in base alle tariffe per le richieste

L'azione rate_based_ban in una regola consente di forzare l'applicazione di una soglia per client per escludere temporaneamente i client che superano il limite applicando l'elemento exceed_action configurato per tutte le richieste 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 della richiesta su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste in 1200 secondi, Google Cloud Armor applica l'exceed_action al traffico proveniente da tale client, superando la soglia di 2000 richieste finché non sono trascorsi i 1200 secondi e per un numero aggiuntivo di secondi impostato come periodo di esclusione. Se il periodo di durata dell'esclusione è impostato su 3600, ad esempio, il traffico dal client verrà escluso per 3600 secondi (un'ora) oltre la fine dell'intervallo della soglia.

Questi parametri controllano l'azione di una regola rate_based_ban:

  • rate_limit_threshold: numero di richieste per client consentite in un intervallo di tempo specificato. Il valore minimo è 1 richiesta e il valore massimo è 10.000 richieste.
    • interval_sec: numero di secondi nell'intervallo di tempo. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
  • exceed_action: quando una richiesta supera il rate_limit_threshold, Google Cloud Armor applica il exceed_action configurato. I valori possibili per exceed_action sono i seguenti:
    • deny(status): la richiesta viene rifiutata e il codice di errore specificato viene restituito. I valori validi per il codice di errore sono 403, 404, 429 e 502. Ti consigliamo di utilizzare il codice di risposta 429 (Too Many Requests).
    • redirect: la richiesta viene reindirizzata alla valutazione reCAPTCHA Enterprise o a un URL diverso, in base al parametro exceed_redirect_options.
  • exceed_redirect_options: quando exceed_action è redirect, utilizza questo parametro per specificare l'azione di reindirizzamento:
    • type: digita per l'azione di reindirizzamento, GOOGLE_RECAPTCHA o EXTERNAL_302.
    • target: target dell'URL per l'azione di reindirizzamento. Applicabile solo quando type è EXTERNAL_302.
  • conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore a rate_limit_threshold. Questa è sempre un'azione allow.
  • ban_duration_sec: si tratta del numero aggiuntivo di secondi per cui un client è escluso dalla scadenza del periodo di interval_sec. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.

Quando la frequenza di richiesta di un client è inferiore alla soglia del limite di frequenza, la richiesta consente di procedere immediatamente al servizio di backend. Quando la frequenza di traffico di un client supera la rate_limit_threshold specificata, Google Cloud Armor applica l'elemento exceed_action a tutte le richieste in entrata dal client per il resto dell'intervallo della soglia e per i successivi ban-duration_sec secondi, indipendentemente dal fatto che la soglia venga superata.

Con questa configurazione è possibile escludere accidentalmente i client di benvenuto che superano occasionalmente il tasso di richieste consentito. Per evitare questo problema ed escludere solo i client che superano spesso la frequenza di richiesta, puoi monitorare il numero totale di richieste del client rispetto a una configurazione di soglia aggiuntiva, preferibilmente più lunga, chiamata ban_threshold. In questa modalità, il client è escluso per i ban_duration secondi configurati solo se la tariffa della richiesta supera il valore di ban-threshold configurato. Se la percentuale di richiesta non supera ban-threshold, le richieste continuano a essere ridotte a rate_limit_threshold. Nel caso di ban_threshold, vengono conteggiate le richieste totali del client, costituite da tutte le richieste in entrata prima della limitazione.

Applicazione forzata della soglia

Le soglie configurate per la limitazione e l'esclusione basata sulla frequenza vengono applicate in modo indipendente in ogni area geografica Google Cloud in cui viene eseguito il deployment dei servizi di backend HTTP(S). Ad esempio, se il servizio viene implementato in due aree geografiche, ognuna delle due aree geografiche limita ogni chiave alla soglia configurata, quindi il tuo servizio di backend potrebbe riscontrare volumi di traffico aggregati tra aree geografiche superiori al doppio della soglia configurata. Se la soglia configurata è impostata su 5000 richieste, il servizio di backend potrebbe ricevere 5000 richieste da un'area geografica e 5000 richieste dalla seconda area geografica.

Tuttavia, per l'indirizzo IP del tipo di chiave, è ragionevole presumere che il traffico dallo stesso indirizzo IP client sia indirizzato all'area geografica più vicina all'area geografica in cui viene eseguito il deployment dei backend. In questo caso, la limitazione di frequenza può essere considerata applicata a livello di servizio di backend, indipendentemente dalle aree geografiche in cui è stato 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 della frequenza venga applicata in più aree geografiche rispetto a quelle in cui è stato eseguito il deployment, con un conseguente impatto sulla precisione. Per questi motivi, consigliamo di utilizzare la limitazione di frequenza solo per mitigare i comportamenti illeciti o mantenere la disponibilità delle applicazioni e dei servizi, non per applicare requisiti di quota o di licenza rigorosi.

Logging

Cloud Logging registra il nome del criterio di sicurezza, la priorità delle regole per la limitazione di frequenza, 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 Enterprise

Puoi applicare la limitazione di frequenza ad alcune risorse reCAPTCHA Enterprise 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 Enterprise, consulta la panoramica sulla gestione dei bot.

Passaggi successivi