Panoramica della limitazione di frequenza

Google Cloud Armor offre funzionalità per proteggere le tue applicazioni Google Cloud da diversi attacchi di livello 3 e 7. Le regole basate sulla frequenza ti 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 può:

• Impedire a un client specifico di esaurire le risorse dell'applicazione.
• Proteggere le istanze dell'applicazione da picchi irregolari 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 subiscano gli effetti dei picchi di traffico elevati provenienti da quel numero ridotto di client, consentendo alle tue risorse di gestire il maggior numero possibile di richieste.

Cloud Armor ha due tipi di regole basate sulla frequenza:

• Limitazione. Puoi applicare un limite massimo di richieste per client o per tutti i client limitando i singoli client a una soglia configurata dall'utente.
• Blocco basato sulla frequenza. Puoi limitare la frequenza delle richieste che corrispondono a una regola in base al client e poi bloccare temporaneamente l'accesso dei client per un periodo configurato se superano una soglia specificata dall'utente.

Quando configuri una regola con un'azione di blocco basato 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 secondo momento in un'azione di blocco basato sulla frequenza. Per saperne di più, consulta Modifica una regola di limitazione in una regola di blocco basato sulla frequenza.

Cloud Armor applica la soglia della limitazione di frequenza a ogni backend associato. Ad esempio, se hai due servizi di backend e configuri una regola di limitazione di frequenza con una soglia di 1000 richieste al minuto, ogni servizio di backend può ricevere 1000 richieste al minuto prima che Cloud Armor applichi l'azione della regola.

Puoi osservare un'anteprima degli effetti delle regole di limitazione di frequenza in una policy di sicurezza utilizzando la modalità di anteprima ed esaminando i log delle richieste.

Identificazione dei client per la limitazione di frequenza

Cloud Armor identifica i singoli client per la limitazione di frequenza utilizzando i seguenti tipi di chiave per aggregare le richieste e applicare i limiti di frequenza:

• ALL: una singola chiave per tutte le richieste che soddisfano la condizione di corrispondenza della regola.
• IP: una chiave univoca per ogni indirizzo IP client le cui richieste soddisfano la condizione di corrispondenza della regola.
• HTTP_HEADER: una chiave univoca per ogni valore univoco dell'intestazione HTTP il cui nome è configurato. Il valore della chiave viene troncato ai primi 128 byte del valore dell'intestazione. Il tipo di chiave è impostato sul valore predefinito "ALL" se non è presente un'intestazione di questo tipo 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 client originale, ovvero il primo indirizzo IP nell'elenco degli IP specificati nell'intestazione HTTP X-Forwarded-For. Il tipo di chiave è impostato sul valore predefinito "IP" se non è presente un'intestazione di questo tipo, 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 di 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 sul valore predefinito "ALL" se non è presente alcun cookie o se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico di rete proxy 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. Il tipo di chiave è impostato sul valore predefinito "ALL" per una sessione HTTP.
• REGION_CODE: il paese o la regione da cui ha origine la richiesta.
• TLS_JA4_FINGERPRINT: fingerprint TLS/SSL JA4 se il client si connette utilizzando HTTPS, HTTP/2 o HTTP/3. Se non è disponibile, il tipo di chiave è impostato sul valore predefinito "ALL". Per saperne di più su JA4, consulta il riferimento per il linguaggio delle regole.
• TLS_JA3_FINGERPRINT: fingerprint TLS/SSL JA3 se il client si connette utilizzando HTTPS, HTTP/2 o HTTP/3. Se non è disponibile, il tipo di chiave è impostato sul valore predefinito "ALL".
• 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 alcuna configurazione userIpRequestHeaders o se non è possibile risolvere un indirizzo IP, il tipo di chiave è impostato sul valore predefinito "IP". Per saperne di più, consulta il riferimento per il linguaggio delle regole.

Puoi utilizzare le chiavi precedenti singolarmente o applicare la limitazione di frequenza in base a una combinazione di un massimo di tre chiavi. Puoi utilizzare più chiavi HTTP-HEADER o HTTP-COOKIE e una sola chiave di ogni altro tipo. Per saperne di più, consulta Limitazione di frequenza basata su più chiavi.

Nota: i dati delle chiavi per la limitazione di frequenza sono classificati come dati di servizio e vengono trattati come descritto nell'Google Cloud Informativa sulla privacy. I dati delle chiavi per la limitazione di frequenza non vengono trattati come dati dei clienti. Se il tuo workload è soggetto a regimi normativi o ad altri requisiti di conformità che richiedono la trasparenza o l'approvazione degli accessi, esamina i tipi di chiave i cui valori potrebbero contenere informazioni sensibili.

Scegli tra regole di blocco basato sulla frequenza e di limitazione di frequenza

Le regole di limitazione di frequenza di Cloud Armor rate-based ban e throttle gestiscono in modo diverso il traffico che supera la soglia configurata.

• rate_based_ban: quando la frequenza delle richieste supera la soglia definita, Cloud Armor blocca tutte le richieste successive provenienti dall'origine o dalla destinazione di queste richieste per un periodo di tempo specificato.
• throttle: anziché bloccare tutto il traffico, la limitazione controlla la frequenza delle richieste fino a un numero massimo definito. La limitazione consente il passaggio di parte del traffico, ma con una frequenza controllata che impedisce il sovraccarico.

La regola più adatta dipende dalle tue esigenze specifiche e dal tipo di traffico che stai gestendo. Ad esempio, se stai subendo un attacco DDoS, un blocco basato sulla frequenza potrebbe essere più adeguato per bloccare rapidamente il traffico dannoso. In alternativa, se stai osservando un picco improvviso di traffico legittimo, la limitazione potrebbe essere un'opzione migliore per mantenere la disponibilità del servizio e prevenire il sovraccarico.

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 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, potresti 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 che il volume di richieste consentite non corrisponde o non è inferiore alla soglia configurata.

Quando la frequenza del traffico di un client è inferiore o uguale a rate_limit_threshold_count, le richieste seguono l'azione conform_action, che è sempre un'azione allow. La richiesta è consentita tramite la policy di sicurezza e può raggiungere la destinazione. Quando la frequenza del traffico di un client supera il valore di rate_limit_threshold_count specificato, Cloud Armor applica l'azione exceed_action, che può essere deny o redirect, per le richieste che superano il limite per il resto dell'intervallo di soglia.

Per controllare l'azione devi impostare questi parametri:

• rate_limit_threshold_count: il numero di richieste per client consentite in un intervallo di tempo specificato. Il valore minimo è 1, 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 il valore di rate_limit_threshold_count, Cloud Armor applica l'azione exceed_action configurata. I valori possibili per exceed_action sono:
  • deny(status): la richiesta viene rifiutata e viene restituito il codice di stato specificato. I valori validi sono 403 Forbidden, 404 Page Not Found, 429 Too Many Requests e 502 Bad Gateway. Ti consigliamo di utilizzare il codice di stato 429 Too Many Requests.
  • redirect: la richiesta viene reindirizzata per il test reCAPTCHA o a un URL diverso, in base al parametro exceed_redirect_options.
• exceed_redirect_options: quando l'azione exceed_action è redirect, utilizza questo parametro per specificare l'azione di reindirizzamento:
  • type: il tipo di azione di reindirizzamento, GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: l'URL di destinazione per l'azione di reindirizzamento. Applicabile solo quando type è EXTERNAL_302.
• conform_action: l'azione eseguita quando il numero di richieste è inferiore a rate_limit_threshold_count. Questa è sempre un'azione allow.

Blocco dei client in base alle frequenze delle richieste

L'azione rate_based_ban in una regola consente di applicare una soglia per client per bloccare temporaneamente i client che superano il limite applicando l'azione exceed_action configurata 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 bloccare temporaneamente il traffico che soddisfa la condizione di corrispondenza specificata e supera la soglia configurata per un periodo configurato dall'utente ('ban_duration_sec').

Ad esempio, potresti impostare la soglia delle richieste su 2000 richieste entro 1200 secondi (20 minuti). Se un client invia 2500 richieste entro 1200 secondi, Cloud Armor applica l'azione exceed_action al traffico proveniente da quel client che supera la soglia di 2000 richieste fino al termine dei 1200 secondi e per un numero aggiuntivo di secondi che imposti come periodo di durata del blocco. Ad esempio, se il periodo di durata del blocco è impostato su 3600, il traffico del client verrà bloccato per 3600 secondi (un'ora) dopo la fine dell'intervallo di soglia.

Quando la frequenza delle richieste di un client è inferiore alla soglia del limite di frequenza, la richiesta può procedere immediatamente al servizio di backend. Quando la frequenza del traffico di un client supera il valore rate_limit_threshold_count specificato, Cloud Armor applica l'azione 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 bloccare accidentalmente client legittimi che superano solo occasionalmente la frequenza di richieste consentita. Per evitare questo problema e bloccare solo i client che superano spesso la frequenza delle richieste, facoltativamente puoi monitorare le richieste totali del client rispetto a una configurazione di soglia aggiuntiva, preferibilmente più lunga, chiamata ban_threshold_count. In questa modalità, il client viene bloccato per la durata ban_duration_sec configurata solo se la frequenza delle richieste supera il valore ban_threshold_count configurato. Se la frequenza delle richieste non supera il valore ban_threshold_count, le richieste continuano a essere limitate al valore rate_limit_threshold_count. Per ban_threshold_count, vengono conteggiate tutte le richieste in entrata prima dell'applicazione della limitazione.

Questi parametri controllano l'azione di una regola rate_based_ban:

• rate_limit_threshold_count: il numero di richieste per client consentite in un intervallo di tempo specificato. Il valore minimo è 1 richiesta, 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 di rate_limit_threshold_count, Cloud Armor applica l'azione exceed_action configurata. I valori possibili per exceed_action sono:
  • deny(status): la richiesta viene rifiutata e viene restituito il codice di stato specificato. I valori validi sono 403 Forbidden, 404 Page Not Found, 429 Too Many Requests e 502 Bad Gateway. Ti consigliamo di utilizzare il codice di stato 429 Too Many Requests.
  • redirect: la richiesta viene reindirizzata per il test reCAPTCHA o a un URL diverso, in base al parametro exceed_redirect_options.
• exceed_redirect_options: quando l'azione exceed_action è redirect, utilizza questo parametro per specificare l'azione di reindirizzamento:
  • type: il tipo di azione di reindirizzamento, GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: l'URL di destinazione per l'azione di reindirizzamento. Questo URL di destinazione è applicabile solo quando type è EXTERNAL_302.
• conform_action: l'azione eseguita quando il numero di richieste è inferiore a rate_limit_threshold_count. Questa è sempre un'azione allow.
• ban_threshold_count: il numero di richieste per client consentite in un intervallo di tempo specificato, oltre il quale Cloud Armor blocca le richieste. Se specificato, la chiave viene bloccata per il tempo configurato in ban_duration_sec quando il numero di richieste che superano rate_limit_threshold_count supera anche questo valore ban_threshold_count.
  • ban_threshold_interval_sec: il numero di secondi nell'intervallo di tempo per ban_threshold_count. Il valore di ban_threshold_interval_sec 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 cui un client viene bloccato dopo la scadenza del periodo interval_sec. Il valore di ban_duration_sec deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.

Policy di sicurezza predefinita per la limitazione di frequenza

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

1. Attiva Cloud Logging e fai query per conoscere il numero massimo di richieste arrivate al servizio di backend protetto da Cloud Armor, per indirizzo IP e al minuto, nell'arco di uno o più giorni.

   Ad esempio, supponiamo che tu ritenga che il 99% del traffico di rete che ricevi non sia interessato dalla regola di 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 della distribuzione generata dai dati di Cloud Logging.

2. Se noti ancora che le regole di limitazione di frequenza predefinite bloccano il traffico legittimo, valuta la possibilità di eseguire questi passaggi aggiuntivi:

   1. Abilita la memorizzazione nella cache (Cloud CDN o Media CDN).
   2. Aumenta l'intervallo di tempo di limitazione (richieste ricevute per diversi minuti anziché ogni 60 secondi).
   3. Puoi bloccare i client per ridurre ulteriormente l'impatto degli attacchi dopo l'ondata iniziale. L'azione rate_based_ban di Cloud Armor ti consente di bloccare tutti i client che superano i limiti troppe volte in un intervallo specificato dall'utente. Ad esempio, i client che superano i limiti 10 volte in un minuto possono essere bloccati per 15 minuti.

Applicazione delle soglie

Le soglie configurate per la limitazione e il blocco basato sulla frequenza vengono applicate in modo indipendente in ciascuna delle regioni Google Cloud in cui hai eseguito il deployment dei tuoi servizi di backend HTTP(S). Ad esempio, se hai eseguito il deployment del tuo servizio in due regioni, ciascuna delle due regioni applica la soglia di limite di frequenza configurata a ogni chiave, pertanto 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 regione.

Tuttavia, per il tipo di chiave indirizzo IP, è ragionevole presumere che il traffico dallo stesso indirizzo IP client sia indirizzato verso la regione più vicina alla regione di deployment dei backend. In questo caso, la limitazione di frequenza può essere considerata applicata a livello di servizio di backend, indipendentemente dalle regioni in cui hai eseguito il deployment del servizio.

È importante notare che i limiti di frequenza applicati sono approssimativi e potrebbero non essere rigorosamente 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 conseguenze sull'accuratezza. Per questi motivi, ti consigliamo di utilizzare la limitazione di frequenza solo per mitigare gli abusi o per mantenere la disponibilità di applicazioni e servizi, non per applicare quote rigorose o requisiti di licenza.

La limitazione di frequenza basata su REGION_CODE considera la regione da cui ha origine la richiesta e non considera la regione dei backend nel servizio di backend, indipendentemente dal tipo. I backend includono gruppi di istanze, qualsiasi tipo di gruppo di endpoint di rete (NEG) supportato dai bilanciatori del carico e bucket Cloud Storage. I backend supportati sono disponibili nella panoramica delle policy di sicurezza.

Logging

Cloud Logging registra il nome della policy 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 informazioni complete sul logging, consulta Utilizza il logging delle richieste.

Integrazione con reCAPTCHA

Puoi applicare la limitazione di frequenza ad alcune risorse reCAPTCHA per mitigare l'abuso e limitare il riutilizzo dei token. Queste risorse includono token di azione, token di sessione e cookie di esenzione. Per saperne di più sull'utilizzo della limitazione di frequenza con reCAPTCHA, consulta la panoramica della gestione dei bot.

Risposte di errore personalizzate

Puoi applicare risposte di errore personalizzate alla limitazione di frequenza di Cloud Armor, incluso il traffico con throttle e rate_based_ban. Quando questi limiti vengono applicati, agli utenti finali vengono inviati messaggi di errore personalizzati. Inoltre, quando utilizzi un bilanciatore del carico delle applicazioni esterno globale, puoi configurare risposte di errore personalizzate per specifici codici di stato HTTP generati dai bilanciatori del carico o dalle istanze di backend.

Per saperne di più sulle risposte di errore personalizzate, consulta la panoramica delle risposte di errore personalizzate. Per configurare risposte di errore personalizzate, consulta Configura risposte di errore personalizzate.

Cloud Armor con Cloud Service Mesh

Nota: l'azione di limitazione di frequenza fairshare è disponibile solo per le regole nelle policy di sicurezza dei servizi interni.

Puoi configurare le policy di sicurezza dei servizi interni per il tuo mesh di servizi in modo da forzare l'applicazione della limitazione di frequenza globale lato server per client, che contribuisce a condividere equamente la capacità disponibile del tuo servizio e mitigare il rischio che client dannosi o con un comportamento anomalo sovraccarichino i tuoi servizi. Puoi collegare una policy di sicurezza a una policy endpoint Cloud Service Mesh per forzare l'applicazione della limitazione di frequenza al traffico in entrata sul lato server. Tuttavia, non puoi configurare una policy di sicurezza di Google Cloud Armor se utilizzi il routing del traffico TCP. Per saperne di più sull'utilizzo di Cloud Armor con Cloud Service Mesh, consulta Configura la limitazione di frequenza con Cloud Armor.

Passaggi successivi

• Configura la limitazione di frequenza