Panoramica dei criteri di sicurezza

Questa pagina descrive come utilizzare i criteri di sicurezza di Google Cloud Armor per proteggere i deployment Google Cloud.

I criteri di sicurezza di Google Cloud Armor proteggono la tua applicazione applicando il filtro di livello 7 ed eseguendo lo scrubbing delle richieste in entrata per gli attacchi web comuni o altri attributi di livello 7 in modo da bloccare potenzialmente il traffico prima che raggiunga i servizi di backend o i bucket di backend con bilanciamento del carico. Ogni criterio di sicurezza è composto da un insieme di regole che filtrano il traffico in base a condizioni come l'indirizzo IP, l'intervallo IP, il codice regione o le intestazioni della richiesta di una richiesta in entrata.

I criteri di sicurezza di Google Cloud Armor sono disponibili per i seguenti tipi di bilanciatore del carico ed endpoint:

  • Bilanciatore del carico delle applicazioni esterno globale (HTTP/HTTPS)
  • Bilanciatore del carico delle applicazioni classico (HTTP/HTTPS)
  • Bilanciatore del carico delle applicazioni esterno regionale (HTTP/HTTPS)
  • Bilanciatore del carico di rete proxy esterno globale (TCP/SSL)
  • Bilanciatore del carico di rete proxy classico (TCP/SSL)
  • Bilanciatore del carico di rete passthrough esterno (TCP/UDP)
  • Forwarding del protocollo
  • VM con indirizzi IP pubblici

Il bilanciatore del carico può essere nel livello Premium o Standard.

I backend del servizio di backend possono essere:

Quando utilizzi Google Cloud Armor per proteggere un deployment ibrido o un'architettura multi-cloud, i backend devono essere NEG internet. Google Cloud Armor protegge anche i NEG serverless quando il traffico viene instradato tramite un bilanciatore del carico. Per assicurarti che solo il traffico instradato tramite il bilanciatore del carico raggiunga il NEG serverless, consulta Controlli in entrata.

Google Cloud Armor fornisce inoltre protezione DDoS avanzata sulla rete per bilanciatori del carico di rete passthrough esterni, inoltro del protocollo e VM con indirizzi IP pubblici. Per maggiori informazioni sulla protezione DDoS avanzata, consulta Configurare la protezione DDoS di rete avanzata.

Proteggi i tuoi deployment Google Cloud con i criteri di sicurezza di Google Cloud Armor

Il bilanciamento del carico esterno è implementato sul perimetro della rete Google, nei punti di presenza (PoP) di Google in tutto il mondo. Nel livello Premium, il traffico degli utenti indirizzato a un bilanciatore del carico esterno entra nel punto di presenza (POP) più vicino all'utente. Viene quindi bilanciato il carico sulla rete globale di Google verso il backend più vicino con capacità disponibile sufficiente. Nel livello Standard, il traffico degli utenti entra nella rete di Google tramite reti di peering, ISP o in transito nella regione in cui hai eseguito il deployment delle risorse Google Cloud.

I criteri di sicurezza di Google Cloud Armor consentono di consentire, negare, limitare la frequenza o reindirizzare le richieste ai tuoi servizi di backend a livello perimetrale di Google Cloud, il più vicino possibile all'origine del traffico in entrata. In questo modo, il traffico indesiderato non consuma risorse o entra nelle reti Virtual Private Cloud (VPC).

Il seguente diagramma illustra la posizione dei bilanciatori del carico delle applicazioni esterni globali, degli Application Load Balancer classici, della rete Google e dei data center di Google.

Criterio di Google Cloud Armor sul perimetro della rete.
Criterio di Google Cloud Armor sul perimetro della rete (fai clic per ingrandire).

Requisiti

Di seguito sono riportati i requisiti per l'utilizzo dei criteri di sicurezza di Google Cloud Armor:

  • Il bilanciatore del carico deve essere un Application Load Balancer esterno globale, un Application Load Balancer classico, un Application Load Balancer esterno regionale, un bilanciatore del carico di rete proxy esterno globale o un bilanciatore del carico di rete proxy classico.
  • Lo schema di bilanciamento del carico del servizio di backend deve essere EXTERNAL o EXTERNAL_MANAGED.
  • Il protocollo del servizio di backend deve essere HTTP, HTTPS, HTTP/2, UDP, TCP, SSL o UNSPECIFIED.

Informazioni sui criteri di sicurezza di Google Cloud Armor

I criteri di sicurezza di Google Cloud Armor sono insiemi di regole che corrispondono agli attributi dal livello 3 al livello 7 per proteggere le applicazioni o i servizi rivolti all'esterno. Ogni regola viene valutata in relazione al traffico in entrata.

Una regola del criterio di sicurezza di Google Cloud Armor è composta da una condizione di corrispondenza e da un'azione da intraprendere quando la condizione è soddisfatta. Le condizioni possono essere semplici, ad esempio se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifico (note anche come regole della lista consentita di indirizzi IP e della lista bloccata). In alternativa, utilizzando il riferimento per il linguaggio delle regole personalizzate di Google Cloud Armor, puoi creare condizioni personalizzate corrispondenti a vari attributi del traffico in entrata, ad esempio il percorso dell'URL, il metodo della richiesta o i valori dell'intestazione della richiesta.

Quando una richiesta in entrata corrisponde a una condizione di una regola del criterio di sicurezza, Google Cloud Armor consente, nega o reindirizza la richiesta a seconda che si tratti di una regola di autorizzazione, di negazione o di reindirizzamento. Potrebbero essere applicati parametri di azione aggiuntivi da applicare, ad esempio l'inserimento delle intestazioni delle richieste. Questa funzionalità fa parte della gestione dei bot di Google Cloud Armor. Per scoprire di più sulla gestione dei bot, consulta la panoramica sulla gestione dei bot.

Puoi associare un criterio di sicurezza di Google Cloud Armor a uno o più servizi di backend. Un servizio di backend può avere un solo criterio di sicurezza associato, ma non tutti i servizi di backend devono essere associati allo stesso criterio di sicurezza.

Se un criterio di sicurezza di Google Cloud Armor è associato a un servizio di backend, non può essere eliminato. Un servizio di backend può essere eliminato a prescindere dal fatto che sia associato a un criterio di sicurezza.

Se più regole di forwarding puntano a un servizio di backend a cui è associato un criterio di sicurezza, le regole del criterio vengono applicate per tutto il traffico in entrata a ciascuno degli indirizzi IP della regola di forwarding.

Nell'illustrazione seguente, il criterio di sicurezza di Google Cloud Armor internal-users-policy è associato al servizio di backend test-network.

Criterio di sicurezza di Google Cloud Armor sul perimetro della rete.
Criterio di sicurezza di Google Cloud Armor sul perimetro della rete (fai clic per ingrandire).

I criteri di sicurezza di Google Cloud Armor hanno le seguenti funzionalità:

  • Facoltativamente, puoi utilizzare il protocollo QUIC con bilanciatori del carico che utilizzano Google Cloud Armor.

  • Puoi utilizzare Google Cloud Armor con bilanciatori del carico che si trovano in uno dei seguenti Network Service Tiers:

    • Livello Premium
    • Livello Standard

  • Puoi utilizzare i criteri di sicurezza del backend con GKE e il controller Ingress predefinito.

  • Puoi utilizzare un criterio di sicurezza predefinito che limita il traffico su una soglia specificata dall'utente quando configuri uno dei seguenti bilanciatori del carico:

    • Bilanciatore del carico delle applicazioni esterno globale
    • Bilanciatore del carico delle applicazioni classico
    • Bilanciatore del carico delle applicazioni esterno regionale
    • Bilanciatore del carico di rete proxy esterno globale
    • Bilanciatore del carico di rete proxy classico
    • Bilanciatore del carico di rete passthrough esterno

Inoltre, puoi configurare regole WAF preconfigurate di Google Cloud Armor, ovvero regole WAF complesse con decine di firme compilate da standard di settore open source. Ogni firma corrisponde a una regola di rilevamento di attacco nel set di regole. Google offre queste regole così come sono. Le regole consentono a Google Cloud Armor di valutare decine di firme di traffico distinte facendo riferimento a regole con nomi appropriati, anziché richiedere la definizione manuale di ogni firma. Per ulteriori informazioni sulle regole WAF preconfigurate, consulta la panoramica delle regole WAF preconfigurate.

Tipi di criteri di sicurezza

Le seguenti tabelle mostrano i tipi di criteri di sicurezza e il loro funzionamento. Un segno di spunta () indica che il tipo di criterio di sicurezza supporta la funzionalità.

Criteri di sicurezza del backend

I criteri di sicurezza di backend vengono utilizzati con i servizi di backend esposti dai seguenti tipi di bilanciatore del carico:

  • Bilanciatore del carico delle applicazioni esterno globale
  • Bilanciatore del carico delle applicazioni classico
  • Bilanciatore del carico delle applicazioni esterno regionale
  • Bilanciatore del carico di rete proxy esterno globale
  • Bilanciatore del carico di rete proxy classico

Possono essere utilizzate per filtrare le richieste e proteggere i servizi di backend che fanno riferimento a gruppi di istanze o gruppi di endpoint di rete (NEG), tra cui NEG internet, di zona, ibridi e serverless. Non tutti i bilanciatori del carico supportano tutti i tipi di NEG. Per ulteriori informazioni sui NEG supportati dal bilanciatore del carico, consulta la panoramica dei gruppi di endpoint di rete.

Quando utilizzi bilanciatori del carico di rete con proxy esterno globale o bilanciatori del carico di rete con proxy classico, Google Cloud Armor applica l'azione deny della regola del criterio di sicurezza solo alle nuove richieste di connessione. L'azione deny termina la connessione TCP. Inoltre, se fornisci un codice di stato insieme all'azione deny, il codice di stato viene ignorato.

I criteri di sicurezza di backend hanno il valore facoltativo del flag type CLOUD_ARMOR. Se non imposti il flag type, il valore predefinito è CLOUD_ARMOR.

Criteri di sicurezza perimetrali

I criteri di sicurezza perimetrali consentono agli utenti di configurare criteri di filtro e controllo dell'accesso per i contenuti archiviati nella cache, tra cui endpoint come i servizi di backend abilitati per Cloud CDN e i bucket Cloud Storage. I criteri di sicurezza perimetrale supportano i filtri in base a un sottoinsieme di parametri rispetto ai criteri di sicurezza di backend. Non puoi impostare un criterio di sicurezza perimetrale come criterio di backend. I criteri di sicurezza perimetrali sono supportati per i seguenti endpoint:

  • Bilanciatore del carico delle applicazioni esterno globale
  • Bilanciatore del carico delle applicazioni classico

I criteri di sicurezza perimetrali possono essere configurati in modo da filtrare le richieste prima che la richiesta venga fornita dalla cache di Google. Il deployment dei criteri di sicurezza perimetrali viene eseguito vicino al perimetro più esterno della rete Google, a monte del punto in cui si trova la cache di Cloud CDN. I criteri di sicurezza perimetrali possono coesistere con i criteri di sicurezza del backend per fornire due livelli di protezione. Possono essere applicati contemporaneamente a un servizio di backend, a prescindere dalle risorse a cui punta il servizio di backend (ad esempio gruppi di istanze o gruppi di endpoint di rete). Solo i criteri di sicurezza perimetrale possono essere applicati ai bucket di backend.

Quando i criteri di sicurezza perimetrali e i criteri di sicurezza del backend sono collegati allo stesso servizio di backend, i criteri di sicurezza del backend vengono applicati solo per le richieste di fallimento della cache che hanno superato i criteri di sicurezza perimetrale.

I criteri di sicurezza perimetrali vengono valutati e applicati prima di Identity-Aware Proxy (IAP). Una richiesta bloccata da un criterio di sicurezza perimetrale viene rifiutata prima che IAP valuti l'identità del richiedente. Se blocchi una richiesta con una regola a livello del criterio di sicurezza perimetrale, IAP non potrà pubblicare una pagina di accesso o tentare in altro modo di autenticare l'utente.

I criteri di sicurezza perimetrali hanno il valore del flag type CLOUD_ARMOR_EDGE.

Criteri di sicurezza perimetrale della rete

I criteri di sicurezza perimetrale della rete consentono di configurare regole per bloccare il traffico sul perimetro della rete Google. L'applicazione di criteri di sicurezza perimetrale della rete non consuma risorse della VM o dell'host, il che aiuta a evitare che il traffico ad alto volume esaurisca le risorse sul carico di lavoro di destinazione o causi in altro modo un denial of service. Puoi configurare criteri di sicurezza perimetrale della rete per le seguenti risorse:

  • Bilanciatori del carico di rete passthrough esterni
  • Forwarding del protocollo
  • VM con indirizzi IP pubblici

I criteri di sicurezza perimetrale della rete supportano i filtri in base ad alcuni degli stessi parametri dei criteri di sicurezza del backend e sono l'unico tipo di criterio di sicurezza a supportare il filtro dell'offset dei byte. Consulta la tabella Tipi di criteri di sicurezza per un elenco completo dei parametri disponibili.

I criteri di sicurezza perimetrale della rete hanno il valore del flag type CLOUD_ARMOR_NETWORK. Per configurare i criteri di sicurezza perimetrale della rete, devi prima configurare la protezione DDoS di rete avanzata nella regione in cui intendi creare i criteri. Per maggiori informazioni sulla protezione DDoS avanzata, consulta la pagina Configurare la protezione DDoS avanzata di rete.

Ordine di valutazione delle regole

L'ordine di valutazione delle regole è determinato dalla priorità delle regole, dal numero più basso al numero più alto. La regola con il valore numerico più basso assegnato ha la priorità logica più alta e viene valutata prima delle regole con priorità logiche inferiori. La priorità numerica minima è 0. La priorità di una regola diminuisce all'aumento del suo numero (1, 2, 3, N+1). Non puoi configurare due o più regole con la stessa priorità. La priorità di ogni regola deve essere impostata su un numero compreso tra 0 e 2147483646 inclusi. Il valore di priorità 2147483647, noto anche come INT-MAX, è riservato per la regola predefinita.

I numeri di priorità possono avere intervalli vuoti, che ti consentono di aggiungere o rimuovere regole in futuro senza influire sulle altre regole. Ad esempio, 1, 2, 3, 4, 5, 9, 12, 16 è una serie valida di numeri di priorità a cui potresti aggiungere regole numerate da 6 a 8, da 10 a 11 e da 13 a 15 in futuro. Non è necessario modificare le regole esistenti, ad eccezione dell'ordine di esecuzione.

In genere viene applicata la regola con priorità più alta corrispondente alla richiesta. Tuttavia, esiste un'eccezione quando le richieste HTTP POST vengono valutate in base a regole preconfigurate che utilizzano evaluatePreconfiguredExpr(). L'eccezione è la seguente.

Per le richieste HTTP POST, Google Cloud Armor riceve l'intestazione della richiesta prima del corpo (payload). Poiché Google Cloud Armor riceve prima le informazioni di intestazione, valuta le regole che corrispondono all'intestazione, ma non a nessuna regola preconfigurata nel corpo. Se sono presenti più regole basate su intestazioni, Google Cloud Armor le valuta in base alla loro priorità come previsto. Tieni presente che le azioni redirect e l'inserimento di quelle di intestazione personalizzate funzionano solo durante la fase di elaborazione dell'intestazione. L'azione redirect, se viene trovata durante la seguente fase di elaborazione del corpo, viene tradotta in un'azione deny. L'azione di intestazione della richiesta personalizzata, se trovata durante la fase di elaborazione del corpo, non avrà effetto.

Dopo aver ricevuto il corpo HTTP POST, Google Cloud Armor valuta le regole che si applicano sia alle intestazioni che al corpo della richiesta. Di conseguenza, è possibile che le regole di priorità inferiore che consentono l'intestazione di una richiesta vengano abbinate prima delle regole di priorità più alta che bloccano il corpo della richiesta. In questi casi, è possibile che la parte dell'intestazione HTTP della richiesta venga inviata al servizio di backend di destinazione, ma il corpo POST che include contenuti potenzialmente dannosi sia bloccato. Google Cloud Armor ispeziona i primi 8 kB del corpo POST. Per ulteriori informazioni su questa limitazione, consulta Limitazioni relative all'ispezione del corpo POST.

L'espressione evaluatePreconfiguredExpr() per le regole preconfigurate è l'unica espressione valutata in base al corpo della richiesta. Tutte le altre espressioni vengono valutate solo in base all'intestazione della richiesta. Tra i tipi di richiesta HTTP con un corpo del messaggio, Google Cloud Armor elabora solo richieste POST. L'ispezione è limitata ai primi 8 kB del corpo POST e viene decodificata come parametri di ricerca dell'URL. Google Cloud Armor può analizzare e applicare regole WAF preconfigurate per i corpi POST in formato JSON (Content-Type = "application/json"). Tuttavia, Google Cloud Armor non supporta altri decoder HTTP basati su Content-Type/Content-Encoding come XML, Gzip o UTF-16.

Esempi

Nell'esempio seguente, le regole 1, 2 e 3 vengono valutate in questo ordine per i campi di intestazione IP e HTTP. Tuttavia, se un IP 9.9.9.1 lancia un attacco XSS nel corpo HTTP POST, solo il corpo viene bloccato (dalla regola 2); l'intestazione HTTP passa al backend (con la regola 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

Nel seguente esempio, il criterio consente l'accesso a IP 9.9.9.1 senza analisi degli attacchi XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regola predefinita

Ogni criterio di sicurezza di Google Cloud Armor contiene una regola predefinita che ha una corrispondenza se non viene soddisfatta nessuna delle regole con priorità più elevata o se non ci sono altre regole nel criterio. Alla regola predefinita viene assegnata automaticamente la priorità 2147483647 (INT-MAX) ed è sempre presente nel criterio di sicurezza.

Non puoi eliminare la regola predefinita, ma puoi modificarla. L'azione predefinita per la regola predefinita è deny, ma puoi modificarla in allow.

Impronta

Ogni criterio di sicurezza di Google Cloud Armor ha il campo fingerprint. Il fingerprint è un hash dei contenuti archiviati nel criterio. Quando crei un nuovo criterio, non fornire il valore di questo campo. Se fornisci un valore, questo viene ignorato. Tuttavia, quando aggiorni un criterio di sicurezza, devi specificare l'impronta attuale che ricevi quando esporti o descrivi il criterio (rispettivamente utilizzando EXPORT o DESCRIBE).

L'impronta ti impedisce di ignorare l'aggiornamento di un altro utente. Se l'impronta digitale che fornisci non è aggiornata, significa che il criterio di sicurezza è stato aggiornato dall'ultima volta che hai recuperato l'impronta. Per verificare la presenza di eventuali differenze e recuperare l'ultima fingerprint, esegui il comando DESCRIBE.

Linguaggio delle regole e motore di applicazione delle regole

Il linguaggio delle regole e il motore di applicazione delle regole offrono quanto segue:

  • Possibilità di scrivere espressioni di regole personalizzate che possano corrispondere su vari attributi di livello 3 a livello 7 delle richieste in entrata. Google Cloud Armor fornisce un linguaggio flessibile per la scrittura di condizioni di corrispondenza personalizzate.

  • È possibile combinare fino a 5 sottoespressioni in una singola regola.

  • La possibilità di rifiutare o consentire le richieste in base al codice regione della richiesta in entrata. I codici regione sono basati sui codici ISO 3166-1 alpha 2 I codici regione talvolta corrispondono a paesi specifici, ma alcuni comprendono un paese e le aree associate. Ad esempio, il codice US include tutti gli stati degli Stati Uniti, un distretto e sei aree periferiche.

Tipi di regole

Google Cloud Armor prevede i tipi di regole seguenti.

Regole della lista bloccata e degli indirizzi IP

Puoi creare regole per la lista consentita di indirizzi IP e la lista bloccata all'interno di un criterio di sicurezza. Tra gli esempi di tali prodotti o servizi figurano:

  • La lista bloccata per indirizzo IP/CIDR consente di impedire a un indirizzo IP o a un intervallo CIDR di origine di accedere ai bilanciatori del carico supportati.

  • La lista consentita per indirizzo IP/CIDR consente di consentire a un indirizzo IP o a un intervallo CIDR di origine di accedere ai bilanciatori del carico supportati.

  • Gli indirizzi IPv4 e IPv6 sono supportati nelle regole della lista consentita e della lista bloccata.

  • Le regole di negazione possono restituire una risposta HTTP 403 (non autorizzato), 404 (accesso negato) o 502 (gateway non valido).

  • Le regole di azione di superamento possono restituire un 429 HTTP (troppe richieste).

Regole geografiche di origine

Puoi consentire o rifiutare le richieste provenienti da aree geografiche selezionate definite dal codice paese Unicode.

Google Cloud Armor utilizza il proprio database di geolocalizzazione degli IP per identificare la località geografica della richiesta. Il database viene aggiornato regolarmente. Anche se non possiamo garantire una particolare frequenza di aggiornamento, durante le normali operazioni le mappature utilizzate da Google Cloud Armor vengono aggiornate circa una volta alla settimana.

Le mappature aggiornate devono essere propagate nell'infrastruttura di Google a livello globale. Il processo di implementazione avviene gradualmente, di solito nell'arco di diversi giorni, in più zone e regioni in cui viene eseguito il deployment di Google Cloud Armor. A causa di questo processo di implementazione graduale, è possibile vedere che le richieste provenienti dallo stesso indirizzo IP di origine vengono gestite in modo incoerente durante un'implementazione, quando l'indirizzo IP di origine cambia la mappatura della geolocalizzazione.

Regole WAF preconfigurate

Google Cloud Armor fornisce un elenco completo di regole WAF preconfigurate basate sul set di regole base OWASP ModSecurity Core Rule Set (CRS) per aiutarti a rilevare quanto segue:

  • Attacchi SQL injection
  • Attacchi cross-site scripting
  • Attacchi di inclusione di file locali
  • Attacchi da remoto per l'inclusione di file
  • Attacchi di esecuzione di codice da remoto
  • Attacchi con applicazione forzata del metodo
  • Attacchi di rilevamento dello scanner
  • Attacchi protocollo
  • Attacchi iniezione PHP
  • Attacchi di correzione delle sessioni
  • Attacchi Java
  • Attacchi NodeJS

Per maggiori dettagli, consulta la panoramica delle regole WAF preconfigurate di Google Cloud Armor.

Regole di gestione dei bot

Puoi utilizzare le regole di gestione dei bot per:

  1. Richieste di reindirizzamento per la valutazione di reCAPTCHA Enterprise con verifiche manuali facoltative.
  2. Valuta i token reCAPTCHA Enterprise associati a una richiesta e applica l'azione configurata in base agli attributi dei token.
  3. Reindirizza le richieste al tuo URL alternativo configurato con una risposta 302.
  4. Inserisci intestazioni personalizzate alle richieste prima di eseguirne il proxy ai tuoi backend.

Per ulteriori informazioni sulla gestione dei bot, consulta la panoramica sulla gestione dei bot.

Regole preconfigurate per gli elenchi di indirizzi IP denominati

Le regole preconfigurate per gli elenchi di indirizzi IP denominati forniscono quanto segue:

  • Integrare gli elenchi di indirizzi IP denominati di provider di terze parti con Google Cloud Armor.

  • Semplifica la manutenzione degli intervalli di indirizzi IP consentiti o negati.

  • Sincronizza quotidianamente gli elenchi di fornitori di terze parti.

  • Aumenta la capacità per la configurazione di indirizzi e intervalli IP nei criteri di sicurezza poiché gli elenchi di indirizzi IP denominati non sono soggetti a limiti relativi al numero di indirizzi IP per regola.

Regole per la limitazione di frequenza

Puoi utilizzare le regole di limitazione di frequenza per:

  • Limita le richieste per client in base a una soglia da te configurata.
  • Escludi temporaneamente i client che superano una soglia di richiesta impostata per una durata configurata.

Quando utilizzi la limitazione di frequenza con bilanciatori del carico di rete proxy esterni globali o bilanciatori di rete proxy classici, si applicano le seguenti restrizioni:

  • Google Cloud Armor applica solo azioni di limitazione di frequenza come la limitazione o l'esclusione di nuove richieste di connessione dai client.
  • Sono supportati solo i tipi di chiave ALL e IP.
  • Se tenti di utilizzare il tipo di chiave HTTP-HEADER o HTTP-COOKIE con bilanciatori del carico TCP/SSL, il tipo di chiave viene interpretato come ALL e allo stesso modo XFF-IP viene interpretato come IP.

Per ulteriori informazioni sulla limitazione di frequenza e sul suo funzionamento, consulta la Panoramica della limitazione di frequenza.

Modalità di anteprima

Puoi visualizzare l'anteprima degli effetti di una regola senza applicarla. In modalità di anteprima, le azioni vengono annotate in Cloud Monitoring. Puoi scegliere di visualizzare l'anteprima delle singole regole di un criterio di sicurezza oppure di ogni regola del criterio. Ti viene addebitata la normale tariffa per richiesta per le regole in modalità anteprima.

Puoi abilitare la modalità di anteprima per una regola utilizzando Google Cloud CLI e il flag --preview di gcloud compute security-policies rules update.

Per disattivare la modalità di anteprima, utilizza il flag --no-preview, che al momento non è documentato. Puoi anche utilizzare la console Google Cloud.

Se una richiesta attiva un'anteprima, Google Cloud Armor continuerà a valutare altre regole fino a quando non trova una corrispondenza. Sia la regola corrispondente sia quella di anteprima saranno disponibili nei log.

Risposte di errore personalizzate

Quando utilizzi un Application Load Balancer esterno globale, puoi configurare risposte di errore personalizzate per i codici di stato HTTP per gli errori generati dai bilanciatori del carico o dalle istanze di backend. Inoltre, puoi configurare codici di errore personalizzati per il traffico negato da Google Cloud Armor configurando pagine di risposta personalizzate per gli stessi codici di errore delle serie 4xx o 5xx utilizzati dalle regole dei criteri di sicurezza esistenti.

Per ulteriori informazioni sulle risposte di errore personalizzate, consulta la panoramica delle risposte di errore personalizzate. Per la procedura di configurazione, consulta Configurare risposte di errore personalizzate.

Logging

Google Cloud Armor offre il logging completo e consente di definire il livello di dettaglio del logging. Per informazioni complete sul logging, consulta Utilizzare il logging delle richieste.

Per visualizzare i log di Google Cloud Armor, consulta Visualizzazione dei log.

Logging delle richieste del bilanciatore del carico delle applicazioni esterno

Ogni richiesta HTTP(S) valutata in base a un criterio di sicurezza di Google Cloud Armor viene registrata tramite Cloud Logging. I log forniscono dettagli quali il nome del criterio di sicurezza applicato, la regola di corrispondenza e se la regola è stata applicata. Il logging delle richieste per le nuove risorse del servizio di backend è disabilitato per impostazione predefinita. Per assicurarti che le richieste Google Cloud Armor vengano registrate, devi abilitare il logging HTTP(S) per ogni servizio di backend protetto da un criterio di sicurezza.

Per maggiori informazioni, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno.

Logging delle richieste del bilanciatore del carico di rete proxy esterno

Puoi configurare il logging per bilanciatori del carico di rete proxy esterni utilizzando i comandi Google Cloud CLI come elencato in Logging e monitoraggio del bilanciamento del carico del proxy TCP/SSL. Non puoi abilitare il logging per i bilanciatori del carico di rete proxy esterni utilizzando la console Google Cloud.

Quando utilizzare il logging dettagliato

Potresti non riuscire a capire perché una regola WAF preconfigurata è stata attivata da una determinata richiesta. I log eventi predefiniti di Google Cloud Armor contengono la regola che è stata attivata, nonché la sottofirma. Tuttavia, potrebbe essere necessario identificare i dettagli della richiesta in entrata che ha attivato la regola per la risoluzione dei problemi, la convalida o l'ottimizzazione delle regole.

Puoi regolare il livello di dettaglio registrato nei log. Ti consigliamo di attivare il logging dettagliato solo quando crei un criterio, apporti modifiche a un criterio o ne risolvi i problemi. Se abiliti il logging dettagliato, saranno valide sia per le regole in modalità di anteprima sia per le regole attive (non visualizzate in anteprima) durante le operazioni standard.

Per ulteriori informazioni sul logging dettagliato, consulta Logging dettagliato.

Analisi dei contenuti del corpo POST

Per impostazione predefinita, Google Cloud Armor valuta l'intero contenuto di un corpo POST come stringa uniforme (soggetto a limitazioni relative alle dimensioni del corpo) a fronte delle firme nelle regole WAF preconfigurate. Per le richieste che contengono codifica alternativa come JSON, i componenti strutturali del messaggio (non specificati dall'utente) potrebbero attivare corrispondenze con le firme WAF preconfigurate. Per evitare rumori e ridurre il rischio di falsi positivi, ti consigliamo di configurare Google Cloud Armor per abilitare l'analisi alternativa per qualsiasi Content-Type supportato se i tuoi carichi di lavoro protetti:

  • Gestisci le API REST
  • Utilizza GraphQL
  • Ricevi eventuali richieste con contenuti con codifica JSON.

Per maggiori informazioni sulle regole WAF preconfigurate, consulta Applicare l'analisi JSON sui valori di intestazione Content-Type personalizzati.

Ogni richiesta HTTP(S) valutata in base a un criterio di sicurezza di Google Cloud Armor viene registrata tramite Cloud Logging. I log forniscono dettagli, come il nome del criterio di sicurezza applicato, la regola di corrispondenza e se la regola è stata applicata. Il logging delle richieste per le nuove risorse del servizio di backend è disabilitato per impostazione predefinita. Per assicurarti che le richieste Google Cloud Armor vengano registrate, devi abilitare il logging HTTP(S) per ogni servizio di backend protetto da un criterio di sicurezza.

Per maggiori informazioni, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno globale.

Limitazioni

Le seguenti sezioni descrivono nel dettaglio le limitazioni per i criteri di sicurezza.

Limitazione dell'ispezione del corpo POST

L'espressione evaluatePreconfiguredExpr() per le regole preconfigurate è l'unica espressione valutata da Google Cloud Armor in base al corpo della richiesta. Tra i tipi di richieste HTTP con un corpo della richiesta, Google Cloud Armor elabora solo POST richieste.

L'ispezione è limitata ai primi 8 kB del corpo POST, che vengono decodificati come parametri di ricerca dell'URL. La parte rimanente del corpo di POST potrebbe contenere codice dannoso, che la tua applicazione potrebbe accettare. Per ridurre il rischio di corpi POST le cui dimensioni superano gli 8 kB, consulta la guida alla risoluzione dei problemi.

Google Cloud Armor può analizzare e applicare regole WAF preconfigurate per i corpi POST (Content-Type = "application/json") predefiniti con codifica URL e JSON. In questo caso le regole vengono applicate in modo indipendente ai nomi e ai valori decodificati nei dati. Per gli altri tipi di contenuti e di codifica, Google Cloud Armor non decodifica i dati, ma applica regole preconfigurate ai dati non elaborati.

Come vengono gestite le connessioni WebSocket

I bilanciatori del carico delle applicazioni esterni globali supportano il protocollo WebSocket incorporato. I canali WebSocket vengono avviati da richieste HTTP(S). Google Cloud Armor può bloccare la creazione di un canale WebSocket, ad esempio se una lista bloccata di indirizzi IP blocca l'indirizzo IP di origine. Tuttavia, le transazioni successive nel canale non sono conformi al protocollo HTTP e Google Cloud Armor non valuta alcun messaggio dopo la prima richiesta.

Passaggi successivi