Panoramica dei criteri di sicurezza

Questa pagina descrive come utilizzare i criteri di sicurezza di Google Cloud Armor per proteggere le tue Google Cloud implementazioni.

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

• Tutti i bilanciatori del carico delle applicazioni esterni, inclusi i bilanciatori del carico delle applicazioni classici
• Bilanciatore del carico delle applicazioni interno regionale
• 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 esterno
• VM con indirizzi IPv4 esterni o intervalli di indirizzi IPv6 esterni assegnati a un'interfaccia di rete (NIC)

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

I backend del servizio di backend possono essere:

• Gruppi di istanze
• Tutti i tipi di gruppi di endpoint di rete (NEG) supportati dal bilanciatore del carico
• Bucket in Cloud Storage

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

Proteggi le tue Google Cloud implementazioni con i criteri di sicurezza di Google Cloud Armor

I criteri di sicurezza di Google Cloud Armor consentono di consentire, negare, limitare la frequenza o reindirizzare le richieste ai servizi di backend all' Google Cloud edge, il più vicino possibile alla sorgente del traffico in entrata. In questo modo si impedisce che il traffico indesiderato consumi risorse o entri nelle reti Virtual Private Cloud (VPC).

Requisiti

• Lo schema di bilanciamento del carico del servizio di backend deve essere EXTERNAL, EXTERNAL_MANAGED o INTERNAL_MANAGED.
• Il protocollo del servizio di backend deve essere uno tra 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 delle reti di livello 3-7 per proteggere applicazioni o servizi esposti esternamente. Ogni regola viene valutata in relazione al traffico in entrata.

Una regola di un criterio di sicurezza di Google Cloud Armor è costituita 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 specifico o a un intervallo CIDR (noto anche come regole di lista consentita e lista bloccata di indirizzi IP). In alternativa, utilizzando gli attributi del linguaggio delle regole personalizzate, puoi creare condizioni personalizzate che corrispondono a vari attributi del traffico in entrata, come il percorso URL, il metodo di richiesta o i valori dell'intestazione della richiesta.

Quando una richiesta in entrata corrisponde a una condizione in una regola dei criteri di sicurezza, Google Cloud Armor consente, nega o reindirizza la richiesta, a seconda che la regola sia una regola di autorizzazione, una regola di negazione o una regola di reindirizzamento. Possono essere applicati parametri di azione aggiuntivi, come l'inserimento di intestazioni delle richieste. Questa funzionalità fa parte della gestione dei bot di Google Cloud Armor. Per saperne di più sulla gestione dei bot, consulta la panoramica della gestione dei bot.

Puoi associare un criterio di sicurezza Google Cloud Armor a uno o più servizi di backend. A un servizio di backend può essere associato un solo criterio di sicurezza, ma non è necessario che tutti i servizi di backend siano associati allo stesso criterio di sicurezza. Per collegare e rimuovere i criteri di sicurezza dai servizi e dalle funzionalità di backend supportati, consulta Collegare e rimuovere i criteri di sicurezza.

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

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

Nel seguente diagramma, i criteri di sicurezza Google Cloud Armor internal-users-policy sono associati al servizio di backend test-network.

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

• Puoi utilizzare Google Cloud Armor con i bilanciatori del carico che si trovano in uno dei seguentiNetwork Service Tierse:

  • Livello Premium
  • Livello Standard

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

• Puoi utilizzare una policy di sicurezza predefinita che limita il traffico oltre 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 delle applicazioni interno 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 le regole WAF preconfigurate di Google Cloud Armor, che sono regole complesse del web application firewall (WAF) con decine di firme compilate a partire da standard di settore open source. Ogni firma corrisponde a una regola di rilevamento degli attacchi 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 denominate in modo pratico, anziché richiedere di definire manualmente ogni firma. Per saperne di più sulle regole WAF preconfigurate, consulta la panoramica delle regole WAF preconfigurate.

Tipi di policy di sicurezza

Le tabelle seguenti mostrano i tipi di norme di sicurezza e cosa puoi fare con loro. Un segno di spunta () indica che il tipo di policy di sicurezza supporta la funzionalità.

Policy di sicurezza del backend

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

Utilizzi i criteri di sicurezza del backend per filtrare le richieste e proteggere i servizi di backend che fanno riferimento a gruppi di istanze o a uno dei tipi di NEG supportati dietro i tipi di bilanciatori del carico elencati in precedenza. Per ulteriori informazioni sui NEG supportati dal bilanciatore del carico, consulta la panoramica sui gruppi di endpoint di rete.

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

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

Policy di sicurezza edge

I criteri di sicurezza perimetrale consentono agli utenti di configurare criteri di filtro e controllo dell'accesso per i contenuti memorizzati nella cache, inclusi endpoint come i servizi di backend abilitati a Cloud CDN e i bucket Cloud Storage. I criteri di sicurezza perimetrale supportano il filtro 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 edge sono supportati per i seguenti endpoint:

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

I criteri di sicurezza perimetrale possono essere configurati per filtrare le richieste prima che vengano pubblicate dalla cache di Google. I criteri di sicurezza perimetrale vengono implementati e applicati vicino al perimetro più esterno della rete di Google, a monte di dove si trova la cache Cloud CDN. Le policy di sicurezza edge possono coesistere con le policy di sicurezza backend per fornire due livelli di protezione. Possono essere applicate simultaneamente a un servizio di backend indipendentemente 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 perimetrale e i criteri di sicurezza del backend sono collegati allo stesso servizio di backend, i criteri di sicurezza del backend vengono applicati solo alle richieste di fallimento della cache che hanno superato i criteri di sicurezza perimetrale.

Le policy di sicurezza perimetrale vengono valutate e applicate prima di Identity-Aware Proxy (IAP). Una richiesta bloccata da una policy di sicurezza perimetrale viene negata prima che IAP valuti l'identità del richiedente. Il blocco di una richiesta con una regola nel criterio di sicurezza perimetrale impedisce a IAP di mostrare una pagina di accesso o di tentare in altro modo di autenticare l'utente.

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

Policy di sicurezza perimetrale della rete

I criteri di sicurezza perimetrale della rete consentono di configurare regole per bloccare il traffico al perimetro della rete di Google. L'applicazione dei criteri di sicurezza perimetrale della rete non consuma risorse VM o host, il che contribuisce a impedire che il traffico ad alto volume esaurisca le risorse sul workload di destinazione o causi altrimenti un denial of service. Puoi configurare i 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 il filtraggio in base ad alcuni degli stessi parametri dei criteri di sicurezza del backend e sono l'unico tipo di criteri di sicurezza a supportare il filtraggio dell'offset di byte. Per un elenco completo dei parametri disponibili, consulta la tabella Tipi di criteri di sicurezza.

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 saperne di più sulla protezione DDoS avanzata, consulta Configurare la protezione DDoS di rete avanzata.

Ordine di valutazione delle regole

L'ordine di valutazione delle regole è determinato dalla priorità della regola, dal numero più basso al numero più alto. La regola con il valore numerico assegnato più basso ha la priorità logica più elevata e viene valutata prima delle regole con priorità logiche più basse. La priorità numerica minima è 0. La priorità di una regola diminuisce all'aumentare del 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 alla regola predefinita.

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

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

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

Dopo aver ricevuto la richiesta HTTP POST con un corpo, Google Cloud Armor valuta le regole che si applicano sia alle intestazioni che al corpo della richiesta. Di conseguenza, è possibile che le regole con priorità inferiore che consentono l'intestazione di una richiesta vengano abbinate prima delle regole con priorità superiore che bloccano il corpo della richiesta. In questi casi, è possibile che la parte di intestazione HTTP della richiesta venga inviata al servizio di backend di destinazione, ma il corpo contenente contenuti potenzialmente dannosi venga bloccato. Google Cloud Armor esamina fino ai primi 64 kB (in base al limite di ispezione configurato di 8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del corpo della richiesta. Per ulteriori informazioni su questa limitazione, vedi Limitazione dell'ispezione del corpo delle richieste POST e PATCH.

L'espressione evaluatePreconfiguredWaf() per le regole preconfigurate è l'unica espressione valutata rispetto al corpo della richiesta. Tutte le altre espressioni vengono valutate solo rispetto all'intestazione della richiesta. Tra i tipi di richiesta HTTP con un corpo della richiesta, Google Cloud Armor elabora solo le richieste POST e PATCH. L'ispezione è limitata al limite di ispezione configurato, fino ai primi 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del corpo della richiesta e viene decodificata come parametri di ricerca 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 decodificatori basati su Content-Type/Content-Encoding HTTP 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 indirizzo IP 9.9.9.1 lancia un attacco XSS nel corpo HTTP POST, viene bloccato solo il corpo (dalla regola 2); l'intestazione HTTP viene trasmessa al backend (dalla regola 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('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

Nell'esempio seguente, le norme consentono l'indirizzo IP 9.9.9.1 senza scansione per rilevare 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: evaluatePreconfiguredWaf('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 viene corrisposta se nessuna delle regole di priorità più elevata viene corrisposta o se non sono presenti altre regole nel criterio. Alla regola predefinita viene assegnata automaticamente una priorità di 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 un campo fingerprint. L'impronta è un hash dei contenuti archiviati nelle norme. Quando crei una norma, 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 ottieni quando esporti o descrivi il criterio (utilizzando rispettivamente EXPORT o DESCRIBE).

L'impronta ti protegge dalla sostituzione dell'aggiornamento di un altro utente. Se l'impronta che fornisci non è aggiornata, significa che le norme di sicurezza sono state aggiornate dall'ultima volta che hai recuperato l'impronta. Per verificare la presenza di differenze e recuperare l'ultima impronta, esegui il comando DESCRIBE.

Linguaggio delle regole e motore di applicazione

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

• La possibilità di scrivere espressioni di regole personalizzate che possono corrispondere a vari attributi dei livelli 3-7 delle richieste in entrata. Google Cloud Armor fornisce attributi del linguaggio delle regole personalizzate per scrivere condizioni di corrispondenza personalizzate.

• La possibilità di combinare fino a 5 sottoespressioni in un'unica regola.

• La possibilità di negare o consentire le richieste in base al codice regione della richiesta in arrivo. I codici regione si basano sui codici ISO 3166-1 alpha 2. A volte i codici regione corrispondono a paesi specifici, ma alcuni comprendono un paese più 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 ha i seguenti tipi di regole.

Regole per le liste consentite e bloccate di indirizzi IP

Puoi creare regole per le liste consentite e bloccate di indirizzi IP all'interno di un criterio di sicurezza. Ecco alcuni esempi:

• L'utilizzo di una denylist per l'indirizzo IP/CIDR ti consente di bloccare l'accesso di un indirizzo IP di origine o di un intervallo CIDR ai bilanciatori del carico supportati.

• L'utilizzo di una lista consentita per l'indirizzo IP/CIDR ti 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 di allowlist e denylist.

• Le regole della lista bloccata possono restituire un codice di stato HTTP 403 Unauthorized, 404 Access Denied o 502 Bad Gateway.

• Le regole di superamento dell'azione possono restituire un codice di stato HTTP 429 Too Many Requests.

Regole geografiche di origine

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

Google Cloud Armor utilizza il nostro database di geolocalizzazione IP per identificare la posizione geografica della richiesta. Il database viene aggiornato regolarmente. Anche se non possiamo garantire una particolare cadenza di aggiornamento, durante le normali operazioni i mapping utilizzati da Google Cloud Armor vengono aggiornati circa una volta alla settimana.

I mapping aggiornati devono essere propagati all'infrastruttura di Google a livello globale. Il processo di implementazione avviene gradualmente, in genere nell'arco di diversi giorni, in più zone e regioni in cui è implementato Google Cloud Armor. A causa di questo processo di implementazione graduale, è possibile che le richieste provenienti dallo stesso indirizzo IP di origine vengano gestite in modo incoerente durante un'implementazione quando la mappatura della geolocalizzazione per l'indirizzo IP di origine è cambiata.

Regole WAF preconfigurate

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

• Attacchi di SQL injection
• Attacchi di cross-site scripting
• Attacchi di inclusione di file locali
• Attacchi di inclusione di file remoti
• Attacchi di esecuzione di codice da remoto
• Attacchi di applicazione forzata del metodo
• Attacchi di rilevamento dello scanner
• Attacchi di protocollo
• Attacchi di injection PHP
• Attacchi di sessione fissa
• 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. Reindirizza le richieste di test reCAPTCHA con verifiche manuali facoltative.
2. Valuta i token reCAPTCHA allegati a una richiesta e applica l'azione configurata in base agli attributi del token.
3. Reindirizza le richieste all'URL alternativo configurato con un codice di stato 302.
4. Inserisci intestazioni personalizzate nelle richieste prima di inviarle tramite proxy ai tuoi backend.

Per saperne di più sulla gestione dei bot, consulta la panoramica della 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:

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

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

• Sincronizza quotidianamente gli elenchi dei fornitori di terze parti.

• Aumenta la capacità di configurare indirizzi e intervalli IP nelle norme di sicurezza perché gli elenchi di indirizzi IP denominati non sono soggetti a limiti al numero di indirizzi IP per regola.

Regole di limitazione di frequenza

Puoi utilizzare le regole di limitazione di frequenza per:

• Limita le richieste per client in base a una soglia che configuri.
• Blocca temporaneamente i client che superano una soglia di richieste impostata per una durata configurata.

Quando utilizzi limitazione di frequenza con i bilanciatori del carico di rete proxy esterno globali o con i bilanciatori del carico di rete proxy classici, si applicano le seguenti limitazioni:

• Google Cloud Armor applica solo azioni di limitazione di frequenza come la limitazione o il divieto 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 i bilanciatori del carico TCP/SSL, il tipo di chiave viene interpretato come ALL e allo stesso modo XFF-IP viene interpretato come IP.

Per saperne di più sulla limitazione di frequenza e sul suo funzionamento, consulta la panoramica sulla limitazione della 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 in una policy di sicurezza oppure puoi visualizzare l'anteprima di tutte le regole nella policy. Per le regole in modalità anteprima ti viene addebitata la normale tariffa per richiesta.

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

Per disattivare la modalità di anteprima, utilizza il flag --no-preview. Puoi anche utilizzare la consoleGoogle Cloud .

Se una richiesta attiva un'anteprima, Google Cloud Armor continua a valutare altre regole fino a trovare una corrispondenza. Sia la regola corrispondente che quella di anteprima sono disponibili nei log.

Risposte di errore personalizzate

Quando utilizzi un bilanciatore del carico delle applicazioni 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 che Google Cloud Armor nega configurando pagine di risposta personalizzate per gli stessi codici di stato della serie 4xx o della serie 5xx utilizzati dalle regole dei criteri di sicurezza esistenti.

Per saperne di più sulle risposte di errore personalizzate, consulta la Panoramica della risposta di errore personalizzata. Per i passaggi di configurazione, vedi Configurare risposte di errore personalizzate.

Logging

Google Cloud Armor dispone di una registrazione completa e ti consente di definire il livello di dettaglio della registrazione. I log di Google Cloud Armor vengono generati in base alla prima regola (con priorità più alta) che corrisponde a una richiesta in entrata, indipendentemente dal fatto che i criteri di sicurezza siano in modalità di anteprima. Ciò significa che i log non vengono generati per le regole non corrispondenti né per le regole corrispondenti con priorità inferiori.

Per informazioni complete sul logging, vedi Utilizzare il logging delle richieste. Per saperne di più sul logging dettagliato, consulta la sezione Logging dettagliato. 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 Google Cloud Armor viene registrata tramite Cloud Logging. I log forniscono dettagli quali il nome della norma di sicurezza applicata, la regola corrispondente e se la regola è stata applicata. Il logging delle richieste per le nuove risorse del servizio di backend è disattivato per impostazione predefinita. Per registrare le richieste Google Cloud Armor, devi attivare la registrazione HTTP(S) per ogni servizio di backend protetto da un criterio di sicurezza.

Per saperne di più, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno globale.

Logging delle richieste del bilanciatore del carico di rete proxy esterno

Puoi configurare la registrazione per i bilanciatori del carico di rete proxy esterni utilizzando i comandi Google Cloud CLI elencati in Registrazione e monitoraggio del bilanciatore del carico di rete proxy. Non puoi abilitare il logging per i bilanciatori del carico di rete proxy esterni utilizzando la console Google Cloud .

Limitazioni

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

Limitazione dell'ispezione del corpo POST e PATCH

L'espressione evaluatePreconfiguredWaf() per le regole preconfigurate è l'unica espressione che Google Cloud Armor valuta rispetto al corpo della richiesta. Tra i tipi di richieste HTTP con un corpo della richiesta, Google Cloud Armor elabora solo le richieste POST e PATCH.

L'ispezione è limitata al limite di ispezione configurato, fino ai primi 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del corpo di POST o PATCH. Per scoprire di più sulla configurazione del limite di ispezione per il corpo della richiesta quando utilizzi regole WAF preconfigurate, consulta Aggiorna il limite di ispezione per le regole WAF preconfigurate.

Il resto del corpo della richiesta potrebbe contenere payload che corrispondono a una firma di regola WAF, che la tua applicazione potrebbe accettare. Per mitigare il rischio di corpi delle richieste la cui dimensione supera il limite di ispezione configurato, fino ai primi 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB), consulta Mitigare il rischio per il corpo della richiesta che supera il limite di ispezione configurato.

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

Come vengono gestite le connessioni WebSocket

I bilanciatori del carico delle applicazioni esterni globali supportano il protocollo WebSocket. I canali WebSocket vengono avviati dalle richieste HTTP(S). Google Cloud Armor può impedire la creazione di un canale WebSocket, ad esempio se un elenco di indirizzi IP bloccati 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

• Configurare criteri, regole ed espressioni di sicurezza
• Scopri le funzionalità dei livelli di Cloud Armor Enterprise
• Scopri di più sugli elenchi di indirizzi IP denominati
• Risolvere i problemi