Panoramica della limitazione di frequenza

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

La limitazione di frequenza consente di:

  • Impedisci a un particolare client di esaurire le risorse dell'applicazione.
  • Proteggi le istanze delle tue applicazioni da picchi irregolari e imprevedibili nella frequenza delle richieste client.

Inoltre, quando una risorsa presenta 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 quel numero ridotto di client, consentendo alle tue risorse di gestire il maggior numero di richieste possibile.

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

  1. Limitazione: puoi applicare un limite massimo di richieste per ogni cliente o per tutti i client limitando la quantità di singoli client a una soglia configurata dall'utente.
  2. Esclusione basata sulle tariffe: puoi limitare le richieste in base alla tariffa per ogni regola client per cliente e poi 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 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 è stato configurato. Il valore della chiave viene troncato ai primi 128 byte del valore dell'intestazione. Per impostazione predefinita, il tipo di chiave è TUTTE se non è presente alcuna intestazione 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.
  • 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 alcuna intestazione, se il valore non è un indirizzo IP valido o se cerchi 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. Per impostazione predefinita, il tipo di chiave è TUTTO se non è presente alcun 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: 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 per una sessione HTTP.
  • REGION-CODE: il paese o l'area geografica in cui ha origine la richiesta.

Puoi utilizzare le chiavi precedenti singolarmente oppure 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 tipo di chiave. Per scoprire di più, consulta Limitazione della frequenza basata su più chiavi.

Limitazione del traffico

L'azione throttle in una regola ti consente di applicare la soglia di richieste per client per proteggere i servizi di backend. Questa regola applica la soglia per limitare il traffico da 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 delle 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 traffico del client viene limitato fino a quando il volume delle richieste consentite non supera la soglia configurata.

Per controllare l'azione, imposta questi parametri:

  • rate_limit_threshold: il numero di richieste per client consentito entro 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 pari a 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
  • exceed_action: quando una richiesta supera rate_limit_threshold, Google Cloud Armor applica il exceed_action configurato. I valori possibili per exceed_action sono i seguenti:
    • deny(status): la richiesta è stata 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 per la 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 URL per l'azione di reindirizzamento. Valido solo quando type è EXTERNAL_302.
  • conform_action: 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 velocità di traffico di un client supera il valore rate_limit_threshold specificato, Google Cloud Armor applica il exceed_action, che può essere deny o redirect, per le richieste che superano il limite dell'intervallo della soglia.

Esclusione dei clienti in base alle tariffe per le 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 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 delle richieste su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste entro 1200 secondi, Google Cloud Armor applica il exceed_action da traffico da quel client oltre la soglia di 2000 richieste fino a quando non sono trascorsi i 1200 secondi completi e per un numero aggiuntivo di secondi impostato come periodo di durata del ban. Se il periodo di durata del divieto è impostato su 3600, ad esempio, il traffico dal client verrebbe vietato per 3600 secondi (un'ora) oltre la fine dell'intervallo di soglia.

Questi parametri controllano l'azione di una regola rate_based_ban:

  • rate_limit_threshold: il numero di richieste per client consentito entro 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 pari a 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
  • exceed_action: quando una richiesta supera rate_limit_threshold, Google Cloud Armor applica il exceed_action configurato. I valori possibili per exceed_action sono i seguenti:
    • deny(status): la richiesta è stata 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 per la 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 URL per l'azione di reindirizzamento. Valido solo quando type è EXTERNAL_302.
  • conform_action: azione eseguita quando il numero di richieste è inferiore a rate_limit_threshold. Questa è sempre un'azione allow.
  • ban_duration_sec: numero di secondi durante il quale 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 di frequenza, questa consente immediatamente alla richiesta di procedere al servizio di backend. Quando la frequenza di traffico di un client supera il valore rate_limit_threshold specificato, Google Cloud Armor applica il 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 occasionalmente il tasso di richiesta consentito. Per evitare questo problema ed escludere solo i client che spesso superano la percentuale di richieste, puoi monitorare facoltativamente le richieste totali dei client utilizzando una configurazione di soglia aggiuntiva, preferibilmente più lunga, chiamata ban_threshold. In questa modalità, il client viene escluso per i ban_duration secondi configurati solo se la frequenza di richiesta supera la configurazione ban-threshold. Se la percentuale di richieste non supera ban-threshold, le richieste continuano a essere limitate a rate_limit_threshold. Ai fini di ban_threshold, vengono conteggiate le richieste totali dal client, costituite da tutte le richieste in entrata prima della limitazione.

Criterio di sicurezza limitazione di frequenza predefinito

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

  1. Abilita Cloud Logging ed esegui query sulle richieste massime che arrivano per IP e al minuto nell'arco di un giorno o più al tuo servizio di backend protetto da Google Cloud Armor.

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

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

    1. Abilitare la memorizzazione nella cache (Cloud CDN o Media CDN).
    2. Aumentare l'intervallo di tempo (le richieste ricevute per diversi minuti anziché per 60 secondi).
    3. Puoi escludere i client per ridurre ulteriormente l'impatto degli attacchi dopo la prima ondata. L'azione rate_based_ban di Google Cloud Armor ti consente di escludere tutti i client che superano i limiti troppe volte all'interno di una finestra specificata dall'utente. Ad esempio, i client che superano i limiti di 10 volte al minuto possono essere esclusi per 15 minuti.

Applicazione della soglia

Le soglie configurate per la limitazione e la limitazione basata sulla frequenza vengono applicate in modo indipendente in ogni regione di Google Cloud in cui viene eseguito il deployment dei servizi di backend HTTP(S). Ad esempio, se il servizio viene eseguito in due regioni, ognuna delle due regioni limita la frequenza di ciascuna chiave alla soglia configurata, quindi il servizio di backend potrebbe riscontrare volumi di traffico aggregati tra regioni che sono il 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 dallo stesso indirizzo IP client sia indirizzato alla 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 ricordare 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 la limitazione di frequenza possa essere applicata in più aree geografiche rispetto alle aree geografiche in cui esegui il deployment, con un conseguente impatto sulla precisione. Per questi motivi, ti consigliamo di utilizzare la limitazione di frequenza solo per mitigare gli abusi o mantenere la disponibilità di applicazioni e servizi, non per applicare requisiti di licenza o delle quote rigorosi.

Logging

Cloud Logging registra il nome del criterio di sicurezza, la priorità della regola per la limitazione di frequenza, l'ID della regola associata, 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 limitare il riutilizzo dei token. 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 della gestione dei bot.

Passaggi successivi