Panoramica delle policy di sicurezza

Questa pagina descrive come utilizzare le policy di sicurezza di Google Cloud Armor per proteggere i tuoi deployment Google Cloud .

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

Le policy di sicurezza di Cloud Armor sono disponibili per i seguenti tipi di bilanciatori del carico ed 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 di livello Premium o Standard.

I backend del servizio di backend possono essere:

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

Cloud Armor fornisce anche una protezione DDoS avanzata della rete per i bilanciatori del carico di rete passthrough esterni, il forwarding del protocollo e le VM con indirizzi IP pubblici. Per saperne di più sulla protezione DDoS avanzata, consulta Configura la protezione DDoS di rete avanzata.

Proteggi i tuoi deployment Google Cloud con le policy di sicurezza di 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. Quindi, il carico viene bilanciato sulla rete Google globale e indirizzato verso il backend più vicino con capacità disponibile sufficiente. Nel livello Standard, il traffico utente entra nella rete Google tramite peering, ISP o reti di transito nella regione in cui hai eseguito il deployment delle risorse Google Cloud.

Le policy di sicurezza di Cloud Armor permettono di consentire, negare, limitare la frequenza o reindirizzare le richieste ai servizi di backend sul perimetro di Google Cloud , il più vicino possibile all'origine del traffico in entrata. In questo modo è possibile impedire al traffico indesiderato di utilizzare risorse o di penetrare nelle reti VPC (Virtual Private Cloud).

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

Policy di Cloud Armor sul perimetro di rete.
Policy di Cloud Armor sul perimetro di rete (fai clic per ingrandire).

Requisiti

Di seguito sono riportati i requisiti per l'utilizzo delle policy di sicurezza di 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 sulle policy di sicurezza di Cloud Armor

Le policy di sicurezza di 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 una policy di sicurezza di Cloud Armor è costituita da una condizione di corrispondenza e da un'azione da intraprendere quando la condizione è soddisfatta. Ad esempio, una condizione può essere se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP specifico o a un intervallo CIDR (queste sono note anche come regole di lista consentita e lista bloccata di indirizzi IP). In alternativa, utilizzando il riferimento per il linguaggio delle regole personalizzate di Cloud Armor, 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 delle policy di sicurezza, 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 Cloud Armor. Per saperne di più sulla gestione dei bot, consulta la panoramica della gestione dei bot.

Cloud Armor fornisce due categorie di policy di sicurezza: policy di sicurezza gerarchiche e policy di sicurezza a livello di servizio. Le policy di sicurezza gerarchiche vengono associate a livello di organizzazione, cartella o progetto, mentre le policy di sicurezza a livello di servizio sono associate a uno o più servizi di backend. Per saperne di più sulle policy di sicurezza gerarchiche, consulta Panoramica delle policy di sicurezza gerarchiche.

A un servizio di backend possono essere associate contemporaneamente due policy di sicurezza a livello di servizio, ma non due policy di sicurezza del backend o due policy di sicurezza perimetrale. Tuttavia, non è necessario che tutti i servizi di backend siano associati alle stesse policy di sicurezza. Per collegare e rimuovere le policy di sicurezza dalle funzionalità di backend e dai servizi supportati, consulta Collega e rimuovi le policy di sicurezza.

Se una policy di sicurezza di Cloud Armor è associata a un servizio di backend, non può essere eliminata. Un servizio di backend può essere eliminato indipendentemente dal fatto che abbia una policy di sicurezza associata.

Se più regole di forwarding puntano a un servizio di backend a cui è associata una policy di sicurezza, le regole della policy vengono applicate a tutto il traffico in entrata a ciascuno degli indirizzi IP delle regole di forwarding.

Nel seguente diagramma, la policy di sicurezza di Cloud Armor internal-users-policy è associata al servizio di backend test-network.

Policy di sicurezza di Cloud Armor sul perimetro di rete.
Policy di sicurezza di Cloud Armor sul perimetro di rete (fai clic per ingrandire).
Le policy di sicurezza di Cloud Armor hanno le seguenti funzionalità:

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

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

    • Livello Premium
    • Livello Standard

  • Puoi utilizzare le policy 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 (TCP/SSL)
    • Bilanciatore del carico di rete proxy classico (TCP/SSL)

Inoltre, puoi configurare le regole WAF preconfigurate di Google Cloud Armor, che sono regole web application firewall (WAF) complesse 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 Cloud Armor di valutare decine di firme di traffico distinte facendo riferimento a regole con nomi pratici, 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 policy di sicurezza a livello di servizio cosa ti permettono di fare. Un segno di spunta () indica che il tipo di policy di sicurezza supporta la funzionalità.

Policy di sicurezza del backend

Le policy di sicurezza del backend vengono utilizzate 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 delle applicazioni interno regionale
  • Bilanciatore del carico di rete proxy esterno globale
  • Bilanciatore del carico di rete proxy classico

Le policy di sicurezza del backend servono 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 saperne di più sui NEG supportati dal tuo bilanciatore del carico, consulta la panoramica dei gruppi di endpoint di rete.

Quando utilizzi bilanciatori del carico di rete proxy esterni globali o bilanciatori del carico di rete proxy classici, Cloud Armor applica l'azione deny della regola delle policy 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.

Per le policy di sicurezza del backend, il valore del flag facoltativo type è CLOUD_ARMOR. Se non imposti il flag type, il valore predefinito è CLOUD_ARMOR.

Policy di sicurezza perimetrale

Le policy di sicurezza perimetrale consentono agli utenti di configurare le policy di filtro e controllo dell'accesso per i contenuti archiviati nella cache, inclusi endpoint come i servizi di backend e i bucket Cloud Storage con Cloud CDN abilitato. Le policy di sicurezza perimetrale supportano filtri basati su un sottoinsieme di parametri rispetto alle policy di sicurezza del backend. Non puoi impostare una policy di sicurezza perimetrale come policy del backend. Le policy di sicurezza perimetrale sono supportate per i seguenti endpoint:

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

Le policy di sicurezza perimetrale possono essere configurate per filtrare le richieste prima che vengano gestite dalla cache di Google. Le policy di sicurezza perimetrale vengono implementate e applicate vicino al perimetro più esterno della rete di Google, a monte di dove si trova la cache Cloud CDN. Le policy di sicurezza perimetrale possono coesistere con le policy di sicurezza del backend per fornire due livelli di protezione. Possono essere applicate simultaneamente a un servizio di backend indipendentemente dalle risorse a cui punta il servizio, ad esempio gruppi di istanze o gruppi di endpoint di rete. Ai bucket di backend è possibile applicare solo le policy di sicurezza perimetrale.

Quando le policy di sicurezza perimetrale e le policy di sicurezza del backend sono collegate allo stesso servizio di backend, le policy di sicurezza del backend vengono applicate solo alle richieste con fallimento della cache che hanno superato le policy 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 nella policy di sicurezza perimetrale impedisce a IAP di mostrare una pagina di accesso o di tentare in altro modo di autenticare l'utente.

Per le policy di sicurezza perimetrale, il valore del flag type è CLOUD_ARMOR_EDGE.

Policy di sicurezza perimetrale della rete

Le policy di sicurezza perimetrale della rete consentono di configurare regole per bloccare il traffico sul perimetro della rete di Google. L'applicazione delle policy di sicurezza perimetrale della rete non consuma risorse VM o host, il che contribuisce a impedire che alti volumi di traffico esauriscano le risorse sul workload di destinazione o causino altrimenti un denial of service. Puoi configurare policy di sicurezza perimetrale della rete per le seguenti risorse:

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

Le policy di sicurezza perimetrale della rete supportano filtri basati su alcuni parametri in comune con le policy di sicurezza del backend e sono l'unico tipo di policy di sicurezza a supportare il filtro offset di byte. Per un elenco completo dei parametri disponibili, consulta la tabella Tipi di policy di sicurezza.

Per le policy di sicurezza perimetrale della rete, il valore del flag type è CLOUD_ARMOR_NETWORK. Per configurare le policy di sicurezza perimetrale della rete, devi prima configurare la protezione DDoS di rete avanzata nella regione in cui intendi creare le policy. Per saperne di più sulla protezione DDoS avanzata, consulta Configura la protezione DDoS di rete avanzata.

Policy di sicurezza dei servizi interni

Le policy di sicurezza dei servizi interni ti consentono di configurare la limitazione di frequenza di condivisione "fairshare" con Cloud Service Mesh. Anziché collegare una policy di sicurezza dei servizi interni a un servizio di backend o a un bucket di backend, la colleghi a una policy endpoint Cloud Service Mesh. Per scoprire di più sulle policy di sicurezza dei servizi interni, consulta Configura la limitazione di frequenza con Cloud Armor nella documentazione di Cloud Service Mesh.

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. Il valore di priorità numerica minimo è 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.

Puoi lasciare intervalli vuoti tra i numeri di priorità. Questi 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 in futuro puoi 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 con corpo vengono valutate in base a regole preconfigurate che utilizzano evaluatePreconfiguredWaf. L'eccezione è la seguente:

Per le richieste con corpo, Cloud Armor riceve l'intestazione della richiesta prima del corpo (payload). Poiché Cloud Armor riceve prima le informazioni dell'intestazione, valuta le regole che corrispondono all'intestazione, ma non applica alcuna regola preconfigurata al corpo. Se sono presenti più regole basate sull'intestazione, Cloud Armor le valuta in base alla priorità come previsto. Tieni presente che le azioni redirect e le azioni di inserimento di intestazioni personalizzate funzionano solo durante la fase di elaborazione dell'intestazione. In caso di corrispondenza durante la successiva fase di elaborazione del corpo, l'azione redirect 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 il corpo della richiesta, Cloud Armor valuta le regole che si applicano sia alle intestazioni che al corpo delle richieste. Di conseguenza, è possibile che le regole con priorità inferiore che consentono l'intestazione di una richiesta vengano applicate 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 elementi potenzialmente dannosi venga bloccato. Cloud Armor ispeziona 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 saperne di più su questa limitazione, consulta Limitazione dell'ispezione per il corpo della richiesta.

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. L'ispezione del corpo si applica solo fino al limite di ispezione configurato e al massimo 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 query URL. Cloud Armor può analizzare e applicare regole WAF preconfigurate per i corpi in formato JSON (Content-Type = "application/json"). Tuttavia, Cloud Armor non supporta altri decodificatori basati sul tipo/la codifica del contenuto 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, 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, la policy consente IP 9.9.9.1 senza una scansione contro 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: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regola predefinita

Ogni policy di sicurezza di Cloud Armor contiene una regola predefinita che viene applicata se nessuna delle regole con priorità più alta corrisponde o se non sono presenti altre regole nella policy. Alla regola predefinita viene assegnata automaticamente la priorità 2147483647 (INT-MAX) ed è sempre presente nella policy di sicurezza.

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

Fingerprint

Ogni policy di sicurezza di Cloud Armor ha un campo fingerprint. La fingerprint è un hash dei contenuti archiviati nella policy. Quando crei una nuova policy, non specificare il valore di questo campo. Se fornisci un valore, viene ignorato. Tuttavia, quando aggiorni una policy di sicurezza, devi specificare la fingerprint attuale, che puoi ottenere esportando o descrivendo la policy (utilizzando rispettivamente EXPORT o DESCRIBE).

La fingerprint ti protegge dall'override dell'aggiornamento di un altro utente. Se la fingerprint che fornisci è obsoleta, significa che la policy di sicurezza è stata aggiornata dall'ultima volta che hai recuperato la fingerprint. Per verificare la presenza di differenze e recuperare l'ultima fingerprint, esegui il comando DESCRIBE.

Linguaggio delle regole e motore di applicazione

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

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

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

  • Possibilità di negare o consentire le richieste in base al codice regione della richiesta in entrata. 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

Di seguito sono riportati i tipi di regole di Cloud Armor.

Regole di lista consentita e lista bloccata di indirizzi IP

Puoi creare regole di lista consentita e lista bloccata di indirizzi IP all'interno di una policy di sicurezza. Ecco alcuni esempi:

Puoi creare regole di lista consentita e lista bloccata di indirizzi IP all'interno di una policy di sicurezza. Ecco alcuni esempi:

  • L'aggiunta di un indirizzo IP o di un intervallo CIDR a una lista bloccata ti consente di impedire a un indirizzo IP o a un intervallo CIDR di origine di accedere ai bilanciatori del carico supportati.

  • L'aggiunta di un indirizzo IP o di un intervallo CIDR a una lista consentita ti consente di autorizzare un indirizzo IP o un intervallo CIDR di origine ad accedere ai bilanciatori del carico supportati.

  • Le regole di lista consentita e lista bloccata supportano indirizzi IPv4 e IPv6.

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

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

Regole per l'area geografica di origine

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

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 particolare cadenza di aggiornamento, durante il normale funzionamento le mappature utilizzate da 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 è eseguito il deployment di 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

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 (XSS)
  • Attacchi di local file inclusion (LFI)
  • Attacchi di remote file inclusion (RFI)
  • Attacchi di remote code execution (RCE)
  • Attacchi di applicazione forzata del metodo
  • Attacchi di rilevamento scanner
  • Attacchi di protocollo
  • Attacchi di PHP injection
  • Attacchi di session fixation
  • Attacchi Java
  • Attacchi NodeJS

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

Regole di gestione dei bot

Puoi utilizzare le regole di gestione dei bot per:

  1. Reindirizzare le richieste di test reCAPTCHA con verifiche manuali facoltative.
  2. Valutare i token reCAPTCHA allegati a una richiesta e applicare l'azione configurata in base agli attributi del token.
  3. Reindirizzare le richieste all'URL alternativo configurato con un codice di stato 302.
  4. Inserire 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:

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

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

  • Sincronizzano quotidianamente gli elenchi dei provider di terze parti.

  • Aumentano la capacità di configurare indirizzi e intervalli IP nelle policy 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:

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

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

  • Cloud Armor applica solo azioni di limitazione di frequenza come la limitazione o il blocco delle 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, analogamente, XFF-IP viene interpretato come IP.

Per saperne di più 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 in una policy di sicurezza oppure di 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, 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 negato da Cloud Armor configurando pagine di risposta personalizzate per gli stessi codici di stato delle serie 4xx o 5xx utilizzati dalle regole delle policy di sicurezza esistenti.

Per saperne di più sulle risposte di errore personalizzate, consulta la panoramica delle risposte di errore personalizzate. Per i passaggi di configurazione, consulta Configura risposte di errore personalizzate.

Logging

Cloud Armor dispone di un logging completo e ti consente di definire il livello di dettaglio del logging. I log di Cloud Armor vengono generati in base alla prima regola (con priorità più alta) che corrisponde a una richiesta in entrata, indipendentemente dal fatto che la policy di sicurezza sia in modalità di anteprima. Ciò significa che non vengono generati log per le regole non corrispondenti né per le regole corrispondenti con priorità inferiori.

Per informazioni complete sul logging, consulta Utilizza il logging delle richieste. Per saperne di più sul logging dettagliato, consulta Logging dettagliato. Per visualizzare i log di Cloud Armor, consulta Visualizza i log.

Logging delle richieste del bilanciatore del carico delle applicazioni esterno

Ogni richiesta HTTP(S) valutata in base a una policy di sicurezza di Cloud Armor viene registrata tramite Cloud Logging. I log forniscono dettagli come il nome della policy di sicurezza applicata, la regola corrispondente e se l'applicazione della regola è stata forzata. Il logging delle richieste per le nuove risorse dei servizi di backend è disattivato per impostazione predefinita. Per creare log delle richieste di Cloud Armor, devi attivare il logging HTTP(S) per ogni servizio di backend protetto da una policy di sicurezza.

Per saperne di più, 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 proxy TCP/SSL. 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 le policy di sicurezza.

Limitazione dell'ispezione del corpo della richiesta

L'espressione evaluatePreconfiguredWaf per le regole preconfigurate è l'unica espressione valutata da Cloud Armor rispetto al corpo della richiesta. Tra i tipi di richieste HTTP con un corpo della richiesta, Cloud Armor elabora solo le richieste con corpo.

L'ispezione si applica solo fino al limite di ispezione configurato e al massimo ai primi 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del corpo della richiesta. Per saperne 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 alla firma di una 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 Mitiga il rischio per un corpo della richiesta che supera il limite di ispezione configurato.

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

Modalità di gestione delle connessioni WebSocket

I bilanciatori del carico delle applicazioni esterni globali supportano il protocollo WebSocket. I canali WebSocket vengono avviati dalle richieste HTTP(S). Cloud Armor può impedire 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 Cloud Armor non valuta alcun messaggio dopo la prima richiesta.

Modalità di gestione delle connessioni gRPC

I bilanciatori del carico delle applicazioni esterni globali supportano il protocollo gRPC, un framework open source che utilizza HTTP/2 come protocollo sottostante. Le chiamate gRPC vengono avviate dalle richieste HTTP(S). Puoi configurare Cloud Armor in modo da impedire l'esecuzione di chiamate gRPC, ad esempio utilizzando una lista bloccata di indirizzi IP che blocca l'indirizzo IP di origine. Tuttavia, potresti notare che il bilanciatore del carico continua a segnalare risposte con codice di stato HTTP 200 OK nei log e nelle metriche. Questo non significa che Cloud Armor non funzioni come previsto.

Passaggi successivi