Panoramica dei criteri di sicurezza

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

I criteri di sicurezza di Google Cloud Armor proteggono la tua applicazione fornendo il filtraggio di livello 7 e analizzando le richieste in entrata per rilevare attacchi web comuni o altri attributi di livello 7 al fine di bloccare potenzialmente il traffico prima che raggiunga i servizi di backend o i bucket di backend con bilanciamento del carico. Ogni criterio di sicurezza è costituito da un insieme di regole che possono essere configurate sugli attributi dal livello 3 al livello 7. Le regole possono filtrare il traffico in base a condizioni quali l'indirizzo IP, l'intervallo IP, il codice regione o le intestazioni della richiesta di una richiesta in arrivo.

I criteri di sicurezza di Google Cloud Armor sono disponibili per i seguenti tipi di bilanciatori del carico e 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 delle applicazioni interno 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 di internet. Google Cloud Armor protegge anche le NEG serverless quando il traffico viene indirizzato tramite un bilanciatore del carico. Per assicurarti che solo il traffico instradato tramite il bilanciatore del carico raggiunga il tuo NEG serverless, consulta Controlli di ingresso.

Google Cloud Armor fornisce inoltre una protezione DDoS di rete avanzata per i bilanciatori del carico di rete passthrough esterni, il forwarding del protocollo e le VM con indirizzi IP pubblici. Per ulteriori informazioni sulla protezione DDoS avanzata, consulta Configurare la protezione DDoS di rete avanzata.

Proteggi le implementazioni di 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 utente indirizzato a un bilanciatore del carico esterno entra nel POP più vicino all'utente. Il carico viene poi bilanciato sulla rete globale di Google e indirizzato verso il backend più vicino con capacità disponibile sufficiente. Nel livello standard, il traffico degli utenti entra nella rete di Google tramite peering, ISP o reti di transito nella regione in cui hai implementato le risorse Google Cloud.

I criteri di sicurezza di Google Cloud Armor ti consentono di consentire, negare, limitare la frequenza o reindirizzare le richieste ai tuoi servizi di backend sul perimetro di Google Cloud, 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 VPC (Virtual Private Cloud).

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

Criterio di Google Cloud Armor sul perimetro della rete.
Criterio 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:

  • 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 dal livello 3 al livello 7 per proteggere le applicazioni o i servizi rivolti all'esterno. Ogni regola viene valutata in base 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 eseguire quando la condizione è soddisfatta. Le condizioni possono essere semplici come verificare se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifico (noto anche come regole di lista consentita e lista vietata di indirizzi IP). In alternativa, utilizzando il riferimento al linguaggio delle regole personalizzate di Google Cloud Armor, puoi creare condizioni personalizzate che corrispondono a vari attributi del traffico in entrata, ad esempio il percorso dell'URL, il metodo di richiesta o i valori dell'intestazione della richiesta.

Quando una richiesta in entrata corrisponde a una condizione in una regola del criterio di sicurezza, Google Cloud Armor consente, nega o reindirizza la richiesta, a seconda che la regola sia una regola di tipo Consenti, una regola di tipo Nega o una regola di tipo Reindirizza. 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.

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

Se più regole di inoltro rimandano a un servizio di backend con un criterio di sicurezza associato, le regole del criterio vengono applicate a tutto il traffico in entrata su ciascun indirizzo IP della regola di forwarding.

Nell'illustrazione seguente, il criterio di sicurezza 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 all'edge 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 i bilanciatori del carico che utilizzano Google Cloud Armor.

  • Puoi utilizzare Google Cloud Armor con i bilanciatori del carico appartenenti a uno dei seguenti Network Service Tiers:

    • Livello Premium
    • Livello Standard

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

  • Puoi utilizzare un criterio di sicurezza predefinito 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, ovvero 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 dozzine di firme di traffico distinte facendo riferimento a regole denominate in modo pratico, 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 cosa puoi fare con questi. 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 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

Possono essere utilizzati 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, zonali, 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 della regola deny del criterio di sicurezza solo alle nuove richieste di connessione. L'azione deny termina la connessione TCP. Inoltre, se fornisci un codice di stato con la tua 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 perimetrale

I criteri di sicurezza Edge 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 per Cloud CDN e i bucket Cloud Storage. I criteri di sicurezza di Edge 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 Edge possono essere configurati per filtrare le richieste prima che vengano pubblicate dalla cache di Google. I criteri di sicurezza perimetrale vengono implementati e applicati nei pressi del perimetro più esterno della rete di Google, a monte della posizione della cache Cloud CDN. I criteri di sicurezza perimetrali possono coesistere con i criteri di sicurezza di backend per fornire due livelli di protezione. Possono essere applicati contemporaneamente a un servizio di backend, indipendentemente dalle risorse a cui il servizio di backend fa riferimento (ad esempio gruppi di istanze o gruppi di endpoint di rete). Solo i criteri di sicurezza perimetrali possono essere applicati ai bucket di backend.

Quando i criteri di sicurezza perimetrali e i criteri di sicurezza di backend sono associati allo stesso servizio di backend, i criteri di sicurezza di backend vengono applicati solo alle richieste con fallimento della cache che hanno superato i criteri di sicurezza perimetrali.

I criteri di sicurezza di Edge vengono valutati e applicati prima di Identity-Aware Proxy (IAP). Una richiesta bloccata da un criterio di sicurezza perimetrale viene rifiutata prima che l'IAP valuti l'identità del richiedente. Il blocco di una richiesta con una regola nel criterio di sicurezza perimetrale impedisce all'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.

Criteri di sicurezza perimetrale della rete

I criteri di sicurezza del perimetro della rete ti consentono di configurare regole per bloccare il traffico sul perimetro della rete di Google. L'applicazione dei criteri di sicurezza perimetrale della rete non consuma risorse VM o host, il che contribuisce a evitare che il traffico ad alto volume esaurisca le risorse del workload di destinazione o causi un rifiuto di servizio. 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 perimetrali della rete supportano il filtro 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 in byte. Fai riferimento alla 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 ulteriori informazioni 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 prioritaria 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 con l'aumentare del numero (1, 2, 3, N+1). Non puoi configurare due o più regole con la stessa priorità. La priorità per 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, il che ti consente 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 in futuro potresti aggiungere regole numerate da 6 a 8, da 10 a 11 e da 13 a 15. Non è necessario 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 vengono valutate in base a regole predefinite 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 dell'intestazione, valuta le regole che corrispondono all'intestazione, ma non corrisponde a nessuna regola preconfigurata nel corpo. Se sono presenti più regole basate sugli intestazioni, 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 corrispondente durante la fase di elaborazione del corpo che segue, viene tradotta in un'azione deny. L'azione dell'intestazione della richiesta personalizzata, se trovata una corrispondenza durante la fase di elaborazione del corpo, non viene applicata.

Dopo aver ricevuto il corpo HTTP POST, Google Cloud Armor valuta le regole che si applicano sia alle intestazioni sia al corpo della richiesta. Di conseguenza, è possibile che le regole con priorità inferiore che consentono l'intestazione di una richiesta vengano associate prima delle regole con priorità superiore 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 che il corpo POST contenente contenuti potenzialmente dannosi venga bloccato. Google Cloud Armor ispeziona i primi 8 KB del corpo del messaggio POST. Per ulteriori informazioni su questa limitazione, consulta Limitazione di ispezione del corpo del POST.

L'espressione evaluatePreconfiguredExpr() per le regole preconfigurate è l'unica espressione valutata in base al corpo della richiesta. Tutte le altre expression vengono valutate solo in base all'intestazione della richiesta. Tra i HTTP tipi di richieste con un corpo della richiesta, Google Cloud Armor elabora solo le richieste POST. Il controllo è limitato ai primi 8 KB del corpo di POST e viene decodificato 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 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 intestazione IP e HTTP. Tuttavia, se un IP 9.9.9.1 lancia un attacco XSS nel corpo di HTTP POST, viene bloccato solo il corpo (in base alla regola 2); l'header HTTP viene trasmesso al backend (in base alla 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

Nell'esempio seguente, il criterio consente IP 9.9.9.1 senza eseguire la scansione per gli 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 viene abbinata se non viene abbinata nessuna delle regole con priorità più elevata 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 impostarla su allow.

Impronta

Ogni criterio di sicurezza di Google Cloud Armor ha un campo fingerprint. La impronta è 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 corrente, che ottieni quando esporti o descrivi il criterio (utilizzando rispettivamente EXPORT o DESCRIBE).

L'impronta ti protegge dall'override dell'aggiornamento di un altro utente. Se la impronta che fornisci non è aggiornata, significa che il criterio di sicurezza è stato aggiornato dall'ultima volta che hai recuperato l'impronta. Per verificare eventuali differenze e recuperare l'impronta più recente, 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 del livello 3 tramite il livello 7 delle richieste in entrata. Google Cloud Armor fornisce un linguaggio flessibile 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 includono 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 dispone dei seguenti tipi di regole.

Regole per le liste consentite e bloccate di indirizzi IP

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

  • La lista negativa per 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.

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

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

  • Le regole di rifiuto possono restituire una risposta HTTP 403 (Non autorizzato), 404 (Accesso negato) o 502 (Bad Gateway).

  • Le regole di azioni per il superamento possono restituire un codice HTTP 429 (Troppe richieste).

Regole di geografia dell'origine

Puoi consentire o negare le richieste provenienti da aree geografiche selezionate che sono 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. Sebbene non possiamo garantire una determinata cadenza di aggiornamento, durante il normale funzionamento le mappature utilizzate da Google Cloud Armor vengono aggiornate circa una volta alla settimana.

Le mappature aggiornate devono essere propagate 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 l'indirizzo IP di origine ha una modifica nella mappatura della geolocalizzazione.

Regole WAF preconfigurate

Google Cloud Armor fornisce un elenco completo di regole WAF preconfigurate basato sul set di regole di base ModSecurity di OWASP (CRS) 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 remoto
  • Attacchi di applicazione forzata del metodo
  • Attacchi di rilevamento dello scanner
  • Attacchi di protocollo
  • Attacchi di iniezione di codice PHP
  • Attacchi di fissazione della sessione
  • Attacchi Java
  • Attacchi Node.js

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 per 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 una risposta 302.
  4. Inserisci intestazioni personalizzate nelle richieste prima di eseguirne il 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 di fornitori 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 IP e intervalli nei criteri di sicurezza perché gli elenchi di indirizzi IP denominati non sono soggetti a limiti sul numero di indirizzi IP per regola.

Regole di limitazione di frequenza

Puoi utilizzare le regole di limitazione di frequenza per:

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

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

  • Google Cloud Armor applica solo azioni di limitazione di frequenza, come il throttling o il divieto di nuove richieste di connessione da parte dei client.
  • Sono supportati solo i tipi di chiavi ALL e IP.
  • Se provi a 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 ulteriori informazioni sul limitazione di frequenza e sul suo funzionamento, consulta la Panoramica del limite di frequenza.

Modalità di anteprima

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

Puoi attivare 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. Puoi anche utilizzare la console Google Cloud.

Se una richiesta attiva un'anteprima, Google Cloud Armor continuerà a valutare altre regole finché non ne troverà una corrispondente. Sia la regola di corrispondenza sia la regola di anteprima saranno disponibili nei log.

Risposte agli errori 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 rifiutato da Google Cloud Armor configurando pagine di risposta personalizzate per gli stessi codici di errore della serie 4xx o 5xx utilizzati dalle regole dei criteri di sicurezza esistenti.

Per saperne di più sulle risposte di errore personalizzate, consulta la Panoramica delle risposte di errore personalizzate. Per la procedura di configurazione, consulta Configurare le risposte agli errori personalizzate.

Logging

Google Cloud Armor dispone di un'ampia registrazione 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 la priorità più alta) che corrisponde a una richiesta in entrata, indipendentemente dal fatto che il criterio di sicurezza sia in modalità di anteprima o meno. Ciò significa che i log non vengono generati per le regole che non corrispondono né per le regole di corrispondenza con priorità inferiori.

Per informazioni complete sul logging, consulta Utilizzare il logging delle richieste. Per ulteriori informazioni sulla registrazione dettagliata, consulta Registrazione dettagliata. 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 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 di servizio di backend è disattivato per impostazione predefinita. Per assicurarti che le richieste di Google Cloud Armor vengano registrate, devi attivare la registrazione HTTP(S) per ogni servizio di backend protetto da un criterio di sicurezza.

Per ulteriori 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 i bilanciatori del carico di rete proxy esterni utilizzando i comandi Google Cloud CLI elencati in Logging e monitoraggio del bilanciamento del carico del proxy TCP/SSL. Non puoi attivare la registrazione 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 expression che Google Cloud Armor valuta in base 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.

Il controllo è limitato ai primi 8 KB del corpo di POST o PATCH, che viene decodificato come parametri di ricerca dell'URL. Il resto del corpo della richiesta potrebbe contenere codice dannoso, che la tua applicazione potrebbe accettare. Per ridurre il risico di corpi di richiesta di dimensioni superiori a 8 KB, consulta la guida alla risoluzione dei problemi.

Google Cloud Armor può analizzare e applicare regole WAF predefinite per i valori predefiniti POST e PATCH codificati in URL e in formato JSON (Content-Type = "application/json"). In questo caso, le regole vengono applicate in modo indipendente ai nomi e ai valori decodificati nei dati. Per altri tipi di contenuti e tipi di codifica, Google Cloud Armor non decodifica i dati, ma applica le regole predefinite 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 l'instaurazione di un canale WebSocket, ad esempio se una lista di divieto 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