Google Cloud Armor offre funzionalità per proteggere le tue Trusted Cloud by S3NS applicazioni da una serie di attacchi di livello 3 e 7. Le regole basate sulle tariffe 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ò:
- Impedisci a un client specifico di esaurire le risorse dell'applicazione.
- Proteggi 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 vengano interessati da picchi elevati di traffico 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.
- Ban basato sulla frequenza: puoi limitare la frequenza delle richieste che corrispondono a una regola in base al client e poi bloccare temporaneamente questi client per un periodo di tempo configurato se superano una soglia configurata dall'utente.
Quando configuri una regola con un'azione di blocco basata 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'azione di esclusione basata sulla frequenza in un secondo momento. Per ulteriori informazioni, vedi Limitazione della frequenza basata su più chiavi.
Cloud Armor applica la soglia di limitazione di frequenza a ogni 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, ogni servizio di backend può ricevere 1000 richieste al minuto prima che 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 client per limitazione di frequenza
Cloud Armor identifica i singoli client per limitazione di frequenza utilizzando i seguenti tipi di chiavi 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 di origine 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 su ALL per impostazione predefinita se non è presente un'intestazione di questo tipo o se tenti di utilizzare questo tipo di chiave con un bilanciatore del carico di rete del proxy esterno.
- XFF_IP: una chiave univoca per ogni indirizzo IP di origine originale del client,
ovvero il primo indirizzo IP nell'elenco degli IP specificati nell'intestazione HTTP
X-Forwarded-For. Il tipo di chiave viene impostato per impostazione predefinita sull'indirizzo 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 su ALL per impostazione predefinita 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 per impostazione predefinita su ALL in una sessione HTTP.
- REGION_CODE: il paese o la regione da cui ha origine la richiesta.
- TLS_JA4_FINGERPRINT: impronta TLS/SSL JA4 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 JA4, consulta il riferimento al linguaggio delle regole. - 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. - USER_IP: l'indirizzo IP del client di origine, incluso nelle intestazioni
configurate in
userIpRequestHeaderse il cui valore viene compilato da un proxy upstream. Se non è presente alcuna configurazioneuserIpRequestHeaderso se non è possibile risolvere un indirizzo IP, il tipo di chiave viene impostato per impostazione predefinita su IP. Per ulteriori informazioni, consulta il riferimento al linguaggio delle regole.
Puoi utilizzare le chiavi precedenti singolarmente o applicare limitazione di frequenza
in base a una combinazione di un massimo di tre chiavi. Puoi utilizzare più tasti HTTP-HEADER
o HTTP-COOKIE e un solo tasto per ogni altro tipo. Per ulteriori
informazioni, vedi
Limitazione della frequenza basata su più chiavi.
Scegliere tra regole di limitazione della frequenza basate sulla frequenza e sulla limitazione della frequenza
Le regole di limitazione di frequenza di Cloud Armor rate-based ban e throttle differiscono per la gestione del 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 massimo definito. In questo modo, una parte del traffico può passare, ma a una velocità controllata che impedisce il sovraccarico.
La regola più appropriata dipende dalle tue esigenze specifiche e dal tipo di traffico che stai gestendo. Ad esempio, se stai subendo un attacco DDoS, un ban basato sulla frequenza potrebbe essere più appropriato per bloccare rapidamente il traffico dannoso. D'altra parte, se si verifica un aumento improvviso del traffico legittimo, la limitazione potrebbe essere un'opzione migliore per mantenere la disponibilità del servizio ed evitare 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 finché il volume di richieste consentito non raggiunge 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 conform_action, che è sempre un'azione allow. La richiesta è
consentita tramite il criterio di sicurezza e può raggiungere la destinazione. Quando
la velocità del traffico di un client supera il rate_limit_threshold_count specificato,
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 questi 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 è 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 superarate_limit_threshold_count, Cloud Armor applicaexceed_actionconfigurato. I valori possibili perexceed_actionsono i seguenti:deny(status): la richiesta viene rifiutata e viene restituito il codice di errore specificato (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: quandoexceed_actionèredirect, utilizza questo parametro per specificare l'azione di reindirizzamento:type: il tipo di azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: URL di destinazione per l'azione di reindirizzamento. Applicabile solo quandotypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count. Questa è sempre un'azioneallow.
Divieto di accesso per i 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 il
valore 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 vietare 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, 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 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 ban.
Se il periodo di durata del ban è impostato su 3600, ad esempio, il traffico del
client verrà bloccato per 3600 secondi (un'ora) oltre la fine dell'intervallo
di soglia.
Quando tasso di richieste di un client è inferiore alla soglia del limite di frequenza, la richiesta può procedere immediatamente al servizio di backend. Quando la velocità del traffico di un client
supera il rate_limit_threshold_count specificato, 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 fatto che la soglia sia superata o meno.
Con questa configurazione, è possibile vietare accidentalmente i client di benvenuto che
superano solo occasionalmente latasso di richiestee consentita. Per evitare questo problema e bloccare
solo i client che superano frequentemente la tasso di richieste, puoi
facoltativamente 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 bannato per il ban_duration_sec configurato solo se
la tasso di richiestete supera il 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. Ai fini di ban_threshold_count, vengono conteggiate 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 superarate_limit_threshold_count, Cloud Armor applicaexceed_actionconfigurato. I valori possibili perexceed_actionsono i seguenti:deny(status): La richiesta viene negata e viene restituito il codice di errore specificato. 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: quandoexceed_actionèredirect, utilizza questo parametro per specificare l'azione di reindirizzamento:type: il tipo di azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: URL di destinazione per l'azione di reindirizzamento. Applicabile solo quandotypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste è inferiore arate_limit_threshold_count. Questa è sempre un'azioneallow.ban_threshold_count: il numero di richieste per client consentito in un intervallo di tempo specificato, oltre il quale Cloud Armor vieta le richieste. Se specificata, la chiave viene vietata per il valoreban_duration_secconfigurato quando il numero di richieste che superano il valorerate_limit_threshold_countsupera anche questo valoreban_threshold_count.ban_threshold_interval_sec: il numero di secondi nell'intervallo di tempo per il tuoban_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 per cui un client viene bannato dopo la scadenza del periodointerval_sec. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
Policy di sicurezza predefinita per limitazione di frequenza
Quando configuri un criterio di sicurezza predefinito durante la creazione del bilanciatore del carico, la soglia predefinita è di 500 richieste durante ogni intervallo di un minuto (un rate_limit_threshold_count e un interval_sec di 500 e 60, rispettivamente). Se vuoi selezionare una soglia diversa, ti consigliamo
di seguire questi passaggi per ottimizzare i parametri:
Attiva Cloud Logging ed esegui query sul numero massimo di richieste arrivate per indirizzo IP e al minuto per un giorno o più a lungo nel servizio di backend protetto da Cloud Armor.
Ad esempio, supponiamo che tu ritenga che il 99% del traffico di rete che ricevi non debba essere interessato dalla regola di limitazione della 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.
Se noti ancora che le regole di limitazione della frequenza predefinite bloccano il traffico legittimo, valuta la possibilità di eseguire i seguenti passaggi aggiuntivi:
- Abilita la memorizzazione nella cache (Cloud CDN o Media CDN).
- Aumenta l'intervallo di tempo di limitazione (richieste ricevute in diversi minuti anziché ogni 60 secondi).
- Puoi vietare i client per ridurre ulteriormente l'impatto dell'attacco dopo l'ondata iniziale. L'azione
rate_based_bandi Cloud Armor ti consente di farlo vietando a 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 bannati per 15 minuti.
Applicazione delle soglie
Le soglie configurate per la limitazione e i ban basati sulla frequenza vengono applicate in modo indipendente in ciascuna delle Trusted Cloud regioni in cui sono implementati i tuoi servizi di backend HTTP(S). Ad esempio, se il tuo servizio viene implementato in due regioni, ciascuna delle due regioni limita la frequenza di ogni chiave alla soglia configurata, pertanto il tuo 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 il tipo di chiave indirizzo IP, è ragionevole presumere che il traffico dallo stesso indirizzo IP client venga indirizzato alla regione più vicina alla regione in cui sono implementati i backend. In questo caso, la limitazione di frequenza può essere considerata applicata a livello di servizio di backend, indipendentemente dalle regioni in cui viene implementata.
È importante notare 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 venga applicata in più regioni rispetto a quelle in cui è stato eseguito il deployment, il che influisce sulla precisione. Per questi motivi, ti consigliamo di utilizzare limitazione di frequenza solo per la mitigazione degli abusi o per mantenere la disponibilità di applicazioni e servizi, non per applicare quote rigorose o requisiti di licenza.
Logging
Cloud Logging registra il nome della policy di sicurezza, la priorità della regola di limitazione della frequenza corrispondente, l'ID regola, l'azione associata e altre informazioni nei log delle richieste. Per ulteriori informazioni sulla registrazione, consulta Utilizzare la registrazione delle richieste.
Cloud Armor con Cloud Service Mesh
Puoi configurare i criteri di sicurezza del servizio interno per il mesh di servizi in modo da applicare limitazione di frequenza lato server globale per client, in modo da condividere equamente la capacità disponibile del servizio e ridurre il rischio che client dannosi o con un comportamento anomalo sovraccarichino i servizi. Colleghi un criterio di sicurezza a un criterio endpoint Cloud Service Mesh per applicare la limitazione di frequenza al traffico in entrata sul lato server. Tuttavia, non puoi configurare una policy di sicurezza Google Cloud Armor se utilizzi il routing del traffico TCP. Per saperne di più sull'utilizzo di Cloud Armor con Cloud Service Mesh, consulta Configurare la limitazione di frequenza con Cloud Armor.