Panoramica della limitazione di frequenza

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

La limitazione di frequenza può:

  • Impedisci a qualsiasi client specifico di esaurire le risorse dell'applicazione.
  • Proteggi le tue istanze di 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 evitare che gli altri tuoi client siano interessati da picchi di traffico elevati da quel piccolo numero di client, consentendo alle tue risorse di gestire il maggior numero di richieste possibile.

Google Cloud Armor ha due tipi di regole basate sulle tariffe:

  1. Limitazione: puoi applicare un limite di richieste massimo per cliente o per tutti i client limitando i singoli client a una soglia configurata dall'utente.
  2. Esclusione basata sulla tariffa: puoi limitare il numero di richieste che soddisfano una regola in base al cliente e, quindi, escludere temporaneamente i client per un periodo di tempo configurato se superano una soglia configurata dall'utente.

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.

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 di limiti di frequenza:

  • ALL: un'unica 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 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. L'impostazione predefinita per il tipo di chiave è TUTTO se non è presente tale intestazione oppure se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico del proxy TCP esterno o un bilanciatore del carico del proxy SSL esterno.
  • 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 è l'indirizzo IP se non è presente tale intestazione, se il valore non è un indirizzo IP valido o tenti di utilizzare questo tipo di chiave con un bilanciatore del carico del proxy TCP esterno o un bilanciatore del carico del proxy SSL esterno.
  • HTTP-COOKIE: una chiave univoca per ogni valore 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 TUTTI se non è presente tale cookie o se si cerca di utilizzare questo tipo di chiave con un bilanciatore del carico del proxy TCP esterno o un bilanciatore del carico del proxy SSL esterno.
  • HTTP-PATH: il percorso URL della richiesta HTTP. Il valore della chiave viene troncato ai primi 128 byte.
  • SNI: 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 o l'area geografica in cui ha origine la richiesta.

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 un numero specificato di richieste in un intervallo di tempo specificato.

Ad esempio, puoi impostare la soglia di richieste su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste in un periodo di 1200 secondi, circa il 20% del suo traffico viene limitato fino a quando il volume delle richieste consentite non supera la soglia configurata.

Per controllare l'azione devi impostare i seguenti parametri:

  • rate_limit_threshold: numero di richieste per client consentite in un intervallo di tempo specificato. Il valore minimo è 1 e il valore massimo è 10.000.
    • interval_sec: 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 rate_limit_threshold, Google Cloud Armor applica il valore 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 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 di allow.

Quando la tariffa 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 destinazione. Quando la tariffa di traffico di un client supera il valore rate_limit_threshold 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.

Esclusione dei clienti in base alle tariffe delle 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 l'elemento exceed_action configurato per 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 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 richieste su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste in un periodo di 1200 secondi, Google Cloud Armor applica il exceed_action per il traffico da quel client superando la soglia di 2000 finché non sono trascorsi 1200 secondi e per un numero aggiuntivo di secondi impostato come periodo di durata dell'esclusione. Se il periodo di durata dell'esclusione è impostato su 3600, ad esempio, il traffico dal client viene vietato 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 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
  • exceed_action: quando una richiesta supera il valore rate_limit_threshold, Google Cloud Armor applica il valore 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 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 di allow.
  • ban_duration_sec: numero aggiuntivo di secondi per cui un client viene escluso dopo la scadenza del periodo interval_sec. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.

Quando la tariffa di richiesta di un client è inferiore alla soglia di limitazione, questa consente immediatamente alla richiesta di passare al servizio di backend. Quando la velocità di traffico di un client supera il valore rate_limit_threshold specificato, Google Cloud Armor applica il valore exceed_action a tutte le richieste in entrata dal client per il resto dell'intervallo della soglia e per i prossimi ban_duration_sec secondi, indipendentemente dal fatto che la soglia venga superata o meno.

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

Criterio di sicurezza della limitazione di frequenza predefinita

Quando configuri un criterio di sicurezza predefinito durante la creazione del bilanciatore del carico, la soglia predefinita è 500 richieste in ogni intervallo di un minuto (rate_limit_threshold e interval_sec rispettivamente di 500 e 60). Se vuoi selezionare una soglia diversa, ti consigliamo di seguire questi passaggi per perfezionare i parametri:

  1. Abilita Cloud Logging ed esegui query per il numero massimo di richieste che arrivano per IP e al minuto in un giorno o più nel tuo servizio di backend protetto da Google Cloud Armor.

    Ad esempio, supponi che il 99% del traffico di rete che ricevi non debba essere interessato dalla regola sul limite di frequenza. In questo scenario, ti consigliamo di impostare la soglia del limite di frequenza al 99° percentile delle richieste al minuto per IP massimo della distribuzione generata dai dati di Cloud Logging.

  2. Se noti ancora regole predefinite per la limitazione di frequenza che bloccano il traffico legittimo, consulta i seguenti passaggi aggiuntivi:

    1. Abilita memorizzazione nella cache (Cloud CDN o Media CDN).
    2. Aumenta l'intervallo di tempo della limitazione (le richieste vengono ricevute ogni diversi minuti, anziché ogni 60 secondi).
    3. Puoi escludere i client per ridurre ulteriormente l'impatto dell'attacco dopo la prima ondata. L'azione rate_based_ban di Google Cloud Armor consente di farlo escludendo tutti i client che superano i limiti troppe volte in una finestra specificata dall'utente. Ad esempio, i client che superano il limite di 10 volte in un minuto possono essere esclusi per 15 minuti.

Applicazione della soglia

Le soglie configurate per la limitazione e i divieti basati sulla frequenza vengono applicati in modo indipendente in ciascuna delle regioni Google Cloud in cui viene eseguito il deployment dei servizi di backend HTTP(S). Ad esempio, se viene eseguito il deployment del servizio in due regioni, ciascuna delle due regioni limita ogni chiave alla soglia configurata, quindi il servizio di backend potrebbe riscontrare volumi di traffico aggregato tra regioni due volte superiori alla 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 sia diretto verso la regione più vicina alla regione 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 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ù aree geografiche rispetto a quelle in cui viene eseguito il deployment, con un conseguente impatto negativo sulla precisione. 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, e non per applicare requisiti di quota o licenze rigorosi.

Logging

Cloud Logging registra il nome del criterio di sicurezza, la priorità della regola per la limitazione di frequenza, l'ID della regola, l'azione associata e altre informazioni nei log delle richieste. Per saperne di più 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 azione, token 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