Google Cloud Armor offre funzionalità per aiutarti a proteggere le tue applicazioni Google Cloud contro una varietà di attacchi di livello 3 e 7. Le regole basate sulle tariffe ti aiutano proteggere le tue applicazioni da un grande volume di richieste che inondano istanze e bloccare 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 delle applicazioni da picchi irregolari e imprevedibili nella percentuale di richieste del client.
Inoltre, quando una risorsa presenta un volume elevato di traffico proveniente da una un numero ristretto di clienti, potete evitare che altri clienti ne siano colpiti da grandi picchi di traffico da quel numero ridotto di clienti, consentendo alle tue per gestire il maggior numero possibile di richieste.
Google Cloud Armor ha due tipi di regole basate sulle tariffe:
- Limitazione: puoi applicare un limite massimo di richieste per client o per tutte limitando i singoli client a una soglia configurata dall'utente.
- Esclusione basata sulla frequenza: puoi limitare le richieste che corrispondono a una regola su un singolo cliente per poi escluderli temporaneamente per un periodo di tempo configurato se superano una soglia configurata dall'utente.
Google Cloud Armor applica la soglia di limitazione di frequenza a ogni elemento associato backend. Ad esempio, se hai due servizi di backend e configuri una tariffa regola di limitazione con una soglia di 1000 richieste al minuto, quindi ogni backend può ricevere 1000 richieste al minuto prima di Google Cloud Armor per applicare 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 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 regola. condizione di corrispondenza.
- IP: una chiave univoca per ciascun indirizzo IP di origine del client le cui richieste che 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 dell'intestazione valore. Il tipo di chiave è ALL per impostazione predefinita se questa intestazione non è presente o se tentare di utilizzare questo tipo di chiave con un bilanciatore del carico di rete proxy esterno.
- XFF_IP: una chiave univoca per ogni indirizzo IP di origine originale del client,
ossia il primo indirizzo IP nell'elenco di IP specificati nel
Intestazione HTTP
X-Forwarded-For. In caso contrario, il tipo di chiave è impostato sull'indirizzo IP. è presente, se il valore non è un indirizzo IP valido o se tentare di utilizzare questo tipo di chiave con un bilanciatore del carico di rete proxy esterno. - HTTP_COOKIE: una chiave univoca per ogni valore del cookie HTTP il cui nome è configurato. Il valore della chiave viene troncato ai primi 128 byte del cookie valore. Il tipo di chiave è impostato su ALL se non è presente questo cookie o se tentare di utilizzare questo tipo di chiave con un bilanciatore del carico di rete proxy esterno.
- HTTP_PATH: il percorso dell'URL della richiesta HTTP. Il valore della chiave è troncato a i 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 è TUTTI su una sessione HTTP.
- REGION_CODE: il paese o la regione da cui ha origine la richiesta.
- 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 sul valore predefinito TUTTI. Per ulteriori informazioni su JA3, consulta riferimento al linguaggio di regole. - USER_IP: l'indirizzo IP del client di origine, incluso nelle intestazioni.
configurata in
userIpRequestHeaderse il cui valore è compilato da un proxy upstream. Se non esiste una configurazioneuserIpRequestHeaderso un IP non può essere risolto da questo indirizzo, il tipo di chiave è IP per impostazione predefinita. Per ulteriori informazioni informazioni, consulta riferimento al linguaggio di regole.
Puoi utilizzare le chiavi precedenti singolarmente o applicare una limitazione di frequenza
in base a una combinazione di massimo tre tasti. Puoi utilizzare più HTTP-HEADER
o HTTP-COOKIE chiavi e solo una di ogni altro tipo. Per ulteriori informazioni
le informazioni, vedi
Limitazione di frequenza basata su più chiavi.
Limitazione del traffico
L'azione throttle in una regola ti consente di applicare in modo forzato una richiesta per client
per proteggere i servizi di backend. Questa regola applica la soglia per limitare
traffico proveniente da ciascun client che soddisfa le condizioni di corrispondenza della regola. La
la soglia è configurata come numero specificato di richieste in un determinato periodo di tempo
intervallo di tempo.
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 periodo, circa il 20% del traffico del cliente viene limitato finché volume di richieste consentito è uguale o inferiore alla soglia configurata.
Quando la frequenza di traffico di un cliente è inferiore o uguale al rate_limit_threshold_count,
seguono l'azione conform_action, che è sempre un'azione allow. La richiesta è
consentito attraverso il criterio di sicurezza e a
raggiungere la destinazione. Quando
la frequenza di traffico di un cliente supera il valore specificato per rate_limit_threshold_count,
Google 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 i seguenti parametri per controllare l'azione:
rate_limit_threshold_count: il numero di richieste per client consentito in un all'intervallo di tempo specificato. Il valore minimo è 1 e il valore massimo è 10.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, Google Cloud Armor applica l'exceed_actionconfigurata. Valori possibili perexceed_actionsono i seguenti:deny(status): la richiesta viene rifiutata e il codice di errore specificato è (i valori validi sono403,404,429e502). Ti consigliamo di utilizzare Codice di risposta429 (Too Many Requests).redirect: la richiesta viene reindirizzata per reCAPTCHA o a un URL diverso, in base alleexceed_redirect_options.
exceed_redirect_options: usa questo valore quandoexceed_actionèredirectper specificare l'azione di reindirizzamento:type: digita l'azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: target URL per l'azione di reindirizzamento. Applicabile solo quando il valore ditypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste viene inrate_limit_threshold_count. È sempre un'azioneallow.
Esclusione dei client in base alle percentuali di richieste
L'azione rate_based_ban in una regola consente di applicare in modo forzato un'impostazione per client
per escludere temporaneamente i clienti che superano il limite applicando la
configurato exceed_action per tutte le richieste del client per un
periodo di tempo. La soglia viene configurata come numero specificato di richieste in un
all'intervallo di tempo specificato. Puoi escludere temporaneamente il traffico per una
configurato dall'utente ('ban_duration_sec'), a condizione che il traffico
corrisponda alla condizione di corrispondenza specificata e supera 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,
Google Cloud Armor applica exceed_action al traffico proveniente dal client
il superamento della soglia delle 2000 richieste finché non sono trascorsi tutti i 1200 secondi
e per il numero di secondi aggiuntivo
impostato come periodo di durata dell'esclusione.
Se il periodo di durata dell'esclusione è impostato su 3600, ad esempio, il traffico proveniente da
sarebbe vietato per 3600 secondi (un'ora) dopo la fine del
di soglia.
Quando tasso di richieste di un cliente è al di sotto della soglia del limite di frequenza,
consente alla richiesta di passare al servizio di backend. Quando la frequenza di traffico di un cliente
supera il valore rate_limit_threshold_count specificato, Google Cloud Armor applica
exceed_action a tutte le richieste in entrata dal client per il resto del
di soglia e per i successivi ban_duration_sec secondi, indipendentemente
se la soglia viene superata o meno.
Con questa configurazione, è possibile escludere accidentalmente i client di benvenuto che
solo occasionalmente la percentuale consentita di richieste. Per evitarlo, ed escludi
solo per i client che superano spesso la tasso di richieste, puoi
facoltativamente tenere traccia delle richieste totali del client rispetto a un altro, preferibilmente
più lunga, con una configurazione della soglia denominata ban_threshold_count. In questa modalità,
il client è escluso per l'ban_duration_sec configurata solo se
il tasso di richieste supera il valore configurato per ban_threshold_count. Se il 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, il totale
da parte del client, costituite da tutte le richieste in entrata prima della limitazione,
vengono conteggiate.
Questi parametri controllano l'azione di una regola rate_based_ban:
rate_limit_threshold_count: il numero di richieste per client consentito in un all'intervallo di tempo specificato. Il valore minimo è 1 richiesta e il valore massimo è di 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, Google Cloud Armor applica l'exceed_actionconfigurata. Valori possibili perexceed_actionsono i seguenti:deny(status): la richiesta viene rifiutata e il codice di errore specificato è restituito. I valori validi per il codice di errore sono403,404,429e502. Me consigliamo di utilizzare il codice di risposta429 (Too Many Requests).redirect: la richiesta viene reindirizzata per reCAPTCHA o a un URL diverso, in base alleexceed_redirect_options.
exceed_redirect_options: usa questo valore quandoexceed_actionèredirectper specificare l'azione di reindirizzamento:type: digita l'azione di reindirizzamento,GOOGLE_RECAPTCHAoEXTERNAL_302.target: target URL per l'azione di reindirizzamento. Applicabile solo quando il valore ditypeèEXTERNAL_302.
conform_action: questa è l'azione eseguita quando il numero di richieste viene inrate_limit_threshold_count. È sempre un'azioneallow.ban_threshold_count: il numero di richieste per client consentite in un intervallo di tempo specificato, oltre il quale Google Cloud Armor esclude richieste. Se specificata, la chiave è esclusa per l'istanza configurataban_duration_secquando il numero di richieste superiore a Ancherate_limit_threshold_countsuperano questo limite diban_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 di secondi aggiuntivi per cui un il client viene escluso una volta trascorso il periodointerval_sec. Il valore deve essere 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 secondi.
Criterio di sicurezza per limitazione di frequenza predefinita
Quando configuri
criterio di sicurezza predefinito durante
del bilanciatore del carico, la soglia predefinita è di 500 richieste
intervallo di un minuto (un rate_limit_threshold_count e interval_sec di 500 e
60). Se vuoi selezionare una soglia diversa, ti consigliamo
Per ottimizzare i parametri, segui questi passaggi:
Abilita Cloud Logging ed esegui query sul numero massimo di richieste ricevute per indirizzo IP e al minuto in un giorno più a lungo nel tuo servizio di backend protetto da Google Cloud Armor.
Ad esempio, supponiamo che il 99% del traffico di rete che ricevi non siano interessati dalla regola per la limitazione di frequenza. In questo scenario, ti consigliamo di impostare la soglia di limitazione di frequenza al 99° percentile di il numero massimo di richieste per indirizzo IP e al minuto di distribuzione generato dai dati di Cloud Logging.
Se noti ancora regole di limitazione di frequenza predefinite che bloccano il traffico legittimo, prendi in considerazione i seguenti passaggi aggiuntivi:
- Abilita la memorizzazione nella cache (Cloud CDN o Media CDN).
- Aumenta l'intervallo di tempo per la limitazione (richieste ricevute ogni minuti, invece che per 60 secondi).
- Puoi escludere i clienti per ridurre ulteriormente l’impatto dell’attacco dopo il
un'onda. L'azione Google Cloud Armor
rate_based_banti consente di farlo escludere tutti i client che superano i limiti troppe volte in un specificata dall'utente. Ad esempio, i client che superano limiti 10 volte entro un minuto possono essere esclusi per 15 minuti.
Applicazione della soglia
Vengono applicate le soglie configurate per la limitazione e le esclusioni basate sulla frequenza in modo indipendente in ciascuna delle regioni di Google Cloud in cui dei servizi di backend. Ad esempio, se il deployment del servizio viene eseguito regione, ciascuna delle due regioni limita la frequenza di ogni chiave al soglia, per cui il tuo servizio di backend potrebbe riscontrare dati aggregati tra regioni e volumi di traffico pari al doppio della soglia configurata. Se lo stato la soglia è impostata su 5000 richieste, il servizio di backend potrebbe riceverne 5000 richieste da una regione e 5000 richieste dalla seconda regione.
Tuttavia, per l'indirizzo IP del tipo di chiave, è ragionevole supporre che il traffico dallo stesso indirizzo IP client viene indirizzato alla regione più vicina al regione in cui viene eseguito il deployment dei backend. In questo caso, la limitazione di frequenza può essere considerata applicata in modo forzato a livello di servizio di backend, indipendentemente regioni in cui viene eseguito il deployment.
È importante notare che i limiti di frequenza applicati sono approssimativi e potrebbero non devono essere del tutto accurati rispetto alle soglie configurate. Inoltre, in rari casi casi, a causa del comportamento di routing interno, è possibile che la limitazione di frequenza potrebbe essere applicato in più regioni rispetto a quelle in cui hai eseguito il deployment, che influisce sull'accuratezza. Per questi motivi, ti consigliamo di utilizzare la limitazione di frequenza solo per la mitigazione di abusi o per il mantenimento della disponibilità di applicazioni e servizi, non per imporre requisiti rigorosi per le quote o le licenze.
Logging
Cloud Logging registra il nome del criterio di sicurezza e la regola per il limite di frequenza corrispondente priorità, ID regola, azione associata e altre informazioni nella richiesta logaritmi. Per ulteriori informazioni sul logging, consulta Utilizzo del logging delle richieste.
Integrazione con reCAPTCHA
Puoi applicare la limitazione di frequenza ad alcune risorse reCAPTCHA per limitare l'abuso dei token e limitare il loro riutilizzo. Queste risorse includono token di azione, di sessione e cookie di esenzione. Per ulteriori informazioni utilizzando la limitazione di frequenza con reCAPTCHA, consulta panoramica sulla gestione dei bot.