Panoramica dei criteri di sicurezza

In questa pagina viene descritto come utilizzare i criteri di sicurezza di Google Cloud Armor per proteggere deployment di Google Cloud.

I criteri di sicurezza di Google Cloud Armor proteggono la tua applicazione fornendo il livello 7 filtrando ed eliminando le richieste in entrata per rilevare attacchi web comuni o altri tipi di attacchi per bloccare potenzialmente il traffico prima che raggiunga il bilanciamento del carico o bucket di backend. Ogni criterio di sicurezza è composto da un insieme regole che filtrano il traffico in base a condizioni come l'indirizzo IP di una richiesta in entrata un indirizzo IP, un intervallo IP, un codice regione o un'intestazione delle richieste.

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

  • Bilanciatore del carico delle applicazioni esterno globale (HTTP/HTTPS)
  • Bilanciatore del carico delle applicazioni classico (HTTP/HTTPS)
  • Bilanciatore del carico delle applicazioni esterno regionale (HTTP/HTTPS)
  • Bilanciatore del carico 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ò trovarsi Livello Premium o Standard.

I backend per il servizio di backend possono essere:

Quando utilizzi Google Cloud Armor per proteggere un deployment ibrido o un multi-cloud , i backend devono essere NEG internet. e Google Cloud Armor protegge i NEG serverless quando il traffico viene instradato tramite un bilanciatore del carico. A assicurati che solo il traffico instradato tramite il bilanciatore del carico raggiunga per il tuo NEG serverless, Controlli in entrata.

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

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

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

I criteri di sicurezza di Google Cloud Armor consentono di consentire, negare, limitare la frequenza o reindirizzare le richieste ai tuoi servizi di backend a livello perimetrale di Google Cloud, il più vicino possibile alla sorgente del traffico in entrata. Questo impedisce traffico proveniente dal consumo di risorse o dall'ingresso nel Virtual Private Cloud (VPC) reti.

Il seguente diagramma illustra la località dei bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico delle applicazioni classici, la rete Google e i data center Google.

Criterio 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 dei seguenti: 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 dal livello 3 al livello 7 per proteggere le applicazioni rivolte all'esterno i servizi di machine learning. 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 un'azione da eseguire quando questa condizione è soddisfatta. Le condizioni possono essere semplici se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP specifico o CIDR (noto anche come regole della lista consentita e della lista bloccata di indirizzi IP). In alternativa, utilizzando Riferimento al linguaggio delle regole personalizzate di Google Cloud Armor, puoi creare condizioni personalizzate che corrispondano 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 richiesta se si tratta di una regola di autorizzazione, di negazione o di reindirizzamento. Possono esserci parametri di azione aggiuntivi da applicare, come l'inserimento di intestazioni delle richieste; questo fa parte della gestione dei bot di Google Cloud Armor. Per ulteriori informazioni sulla gestione dei bot, consulta panoramica sulla gestione dei bot.

Puoi associare un criterio di sicurezza di Google Cloud Armor a uno o più di backend. A un servizio di backend può essere associato un solo criterio di sicurezza ma non tutti i tuoi servizi di backend devono essere associati le stesse norme di sicurezza.

Se un criterio di sicurezza di Google Cloud Armor è associato a un backend non può essere eliminato. Un servizio di backend può essere eliminato indipendentemente se è associato a un criterio di sicurezza.

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

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

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

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

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

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

    • Livello Premium
    • Livello Standard

  • Puoi usare i criteri di sicurezza del backend con GKE e Controller Ingress.

  • Puoi usare un criterio di sicurezza predefinito che limita il traffico una soglia specificata dall'utente quando configuri uno dei seguenti carichi 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 regole WAF preconfigurate di Google Cloud Armor, che sono complesse regole WAF (Application Firewall) con decine di firme compilate da standard di settore open source. Ogni firma corrisponde a un attacco di rilevamento della voce nella serie di regole. Google offre queste regole così come sono. Le regole consentono Google Cloud Armor per valutare decine di firme di traffico distinte fare riferimento a regole con nome pratico, invece di dover definire manualmente ciascuna firma. Per ulteriori informazioni sulle regole WAF preconfigurate, consulta panoramica delle regole WAF preconfigurate.

Tipi di criteri di sicurezza

Le tabelle seguenti mostrano i tipi di criteri di sicurezza e le azioni che puoi intraprendere con loro. Un segno di spunta () indica che il tipo di criterio di sicurezza supporta la caratteristica.

Criteri di sicurezza di backend

I criteri di sicurezza di backend vengono utilizzati con i servizi di backend esposti dal 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

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

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

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

Criteri di sicurezza perimetrale

I criteri di sicurezza perimetrale consentono agli utenti di configurare filtri e controllo dell'accesso i criteri per i contenuti memorizzati nella cache; ciò include endpoint come Servizi di backend abilitati per Cloud CDN e bucket Cloud Storage. Dispositivi periferici i criteri di sicurezza supportano l'applicazione di filtri in base a un sottoinsieme di parametri rispetto a e i criteri di sicurezza del backend. Non puoi impostare un criterio di sicurezza perimetrale come backend . I criteri di sicurezza perimetrale 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 della richiesta viene fornito dalla cache di Google. Viene eseguito il deployment e l'applicazione dei criteri di sicurezza perimetrale vicino al perimetro più esterno della rete Google, a monte del punto in cui La cache di Cloud CDN risiede. I criteri di sicurezza perimetrale possono coesistere con il backend per fornire due livelli di protezione. Possono essere applicati simultaneamente a un servizio di backend, indipendentemente dalle risorse servizio di backend a (ad esempio, gruppi di istanze o endpoint di rete gruppi di utenti). Solo i criteri di sicurezza perimetrali possono essere applicati ai bucket di backend.

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

I criteri di sicurezza perimetrale vengono valutati e applicati prima Identity-Aware Proxy (IAP). Una richiesta bloccata da un criterio di sicurezza perimetrale è negata prima che IAP valuti l'identità del richiedente. Il blocco di una richiesta con una regola nel criterio di sicurezza perimetrale impedisce IAP non pubblicano una pagina di accesso o tentano 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 perimetrale della rete consentono di configurare regole per bloccare il traffico al perimetro della rete Google. L'applicazione dei criteri di sicurezza perimetrale della rete consumare risorse VM o host, il che contribuisce a impedire il traffico di volumi elevati esaurire le risorse sul carico di lavoro di destinazione o causare un rifiuto completamente gestito di Google Cloud. Puoi configurare i criteri di sicurezza sul perimetro della rete per di risorse:

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

I criteri di sicurezza perimetrale della rete supportano i filtri in base ad alcuni come criteri di sicurezza del backend e sono l'unico tipo di criterio di sicurezza per supportare filtro degli offset di byte. Invita alla tabella Tipi di criteri di sicurezza per un elenco completo dei i 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 configurare prima la protezione DDoS avanzata della rete nella regione in cui hanno intenzione di creare i criteri. Per ulteriori informazioni sugli attacchi DDoS avanzati della protezione, consulta Configurare la protezione DDoS di rete avanzata.

Ordine di valutazione delle regole

L'ordine di valutazione delle regole è determinato dalla priorità delle regole, a partire dal numero più basso al numero più alto. La regola con il valore numerico più basso assegnato ha il valore la massima priorità logica e viene valutata prima delle regole con regole le priorità. La priorità numerica minima è 0. La priorità di una regola diminuisce man mano che aumenta il suo numero (1, 2, 3, N+1). Non puoi configurare due o più regole con la stessa priorità. La priorità di ogni regola deve essere impostata su un numero da da 0 a 2147483646 inclusi. Il valore di priorità 2147483647, noto anche come INT-MAX, è riservata alla regola predefinita.

I numeri di priorità possono presentare lacune, il che consente di aggiungere o rimuovere regole nel senza incidere sul resto delle regole. Ad esempio: 1, 2, 3, 4, 5, 9, 12, 16 sono una serie valida di numeri di priorità a cui puoi aggiungere regole numerati da 6 a 8, da 10 a 11 e da 13 a 15 in futuro. Non è necessario modificare le regole esistenti, tranne l'ordine di esecuzione.

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

Per le richieste HTTP POST, Google Cloud Armor riceve l'intestazione della richiesta prima del corpo (payload). Poiché Google Cloud Armor riceve le informazioni dell'intestazione, valuta le regole corrispondenti all'intestazione, non corrisponde ad alcuna regola preconfigurata nel corpo. Se ci sono più parametri di regole basate su intestazioni, Google Cloud Armor le valuta in base alle come previsto. Tieni presente che redirect azioni e l'inserimento di un'intestazione personalizzata funzionano solo durante la fase di elaborazione dell'intestazione. L'azione redirect, se corrispondenti durante la seguente fase di elaborazione del corpo del testo, viene tradotto in un deny un'azione. L'azione dell'intestazione della richiesta personalizzata, se corrispondente nel corpo di elaborazione non ha effetto.

Una volta 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à più bassa che consentono l'intestazione di una richiesta vengono abbinate prima di quelle regole di priorità che bloccano il corpo della richiesta. In questi casi, è possibile che la porzione dell'intestazione HTTP della richiesta viene inviata al backend di destinazione ma il corpo POST con contenuti potenzialmente dannosi viene bloccato. Google Cloud Armor ispeziona i primi 8 kB del corpo POST. Per ulteriori informazioni su questa limitazione, consulta: Limitazioni dell'ispezione del corpo POST.

L'espressione evaluatePreconfiguredExpr() per le regole preconfigurate è è l'unica espressione valutata in base al corpo della richiesta. Tutti gli altri vengono valutate solo in base all'intestazione della richiesta. Tra HTTP tipi di richiesta con un corpo della richiesta, Google Cloud Armor elabora solo POST richieste. L'ispezione è limitata ai primi 8 kB del corpo di POST e vengono decodificati come parametri di ricerca dell'URL. Google Cloud Armor può analizzare e applicare Regole WAF preconfigurate per corpo POST in formato JSON (Content-Type = "application/json"). Tuttavia, Google Cloud Armor supportare altri decoder 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 Campi intestazione IP e HTTP. Tuttavia, se un IP 9.9.9.1 avvia un'XSS attacco nel corpo HTTP POST, solo il corpo viene bloccato (dalla regola 2); HTTP passa attraverso il 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 scansione rispetto a 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 trova una corrispondenza se nessuna delle regole con priorità più elevata corrisponde o se non altre regole del 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 cambiare l'azione in allow.

Impronta

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

L'impronta ti protegge dal fatto che non sia eseguito l'override dell'aggiornamento di un altro utente. Se l'impronta digitale fornita non è aggiornata, vuol dire che il criterio di sicurezza è stata aggiornata dall'ultima volta che hai recuperato l'impronta. Per verificare la presenza di eventuali differenze e per recuperare l'impronta più recente, esegui DESCRIBE .

Linguaggio delle regole e motore di applicazione

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

  • La possibilità di scrivere espressioni di regole personalizzate che possono corrispondere a vari livelli 3 attraverso gli attributi di livello 7 delle richieste in entrata. Google Cloud Armor fornisce linguaggio flessibile per scrivere modelli condizioni di corrispondenza.

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

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

Tipi di regole

Google Cloud Armor prevede i seguenti tipi di regole.

Regole della lista consentita e della lista bloccata di indirizzi IP

Puoi creare regole di inserimento nella lista consentita di indirizzi IP e nella lista bloccata all'interno di un ambiente . Ecco alcuni esempi:

  • Lista bloccata per l'indirizzo IP/CIDR consente di bloccare un indirizzo IP o un intervallo CIDR di origine che accede ai bilanciatori del carico supportati.

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

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

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

  • Il superamento delle regole di azione può restituire un'istruzione HTTP 429 (troppe richieste).

Regole per l'area geografica di origine

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

Google Cloud Armor utilizza il proprio database di geolocalizzazione degli IP per identificare richiedere la posizione geografica. Il database viene aggiornato regolarmente. Anche se non possiamo garantire una particolare cadenza di aggiornamento, durante il normale funzionamento le mappature utilizzati da Google Cloud Armor vengono aggiornati circa una volta a settimana.

Le mappature aggiornate devono essere propagate all'infrastruttura di Google a livello globale. La di implementazione avviene gradualmente, di solito nell'arco di diversi giorni, le zone e le regioni in cui viene eseguito il deployment di Google Cloud Armor. Per questo motivo di implementazione graduale, è possibile vedere le richieste dallo stesso IP di origine gestito in modo incoerente durante un'implementazione, una modifica alla mappatura della geolocalizzazione.

Regole WAF preconfigurate

Google Cloud Armor fornisce un elenco completo di regole WAF preconfigurate in base alla CRS (Set di regole di base OWASP ModSecurity) per aiutarti a rilevare quanto segue:

  • Attacchi SQL injection
  • Attacchi di cross-site scripting (XSS)
  • Attacchi di inclusione locale di file
  • Attacchi di inclusione remota dei file
  • Attacchi di esecuzione di codice da remoto
  • Attacchi di applicazione dei metodi
  • Attacchi di rilevamento dello scanner
  • Attacchi al protocollo
  • Attacchi di tipo PHP injection
  • Attacchi di fissazione della sessione
  • Attacchi Java
  • Attacchi NodeJS

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

Regole per la gestione dei bot

Puoi utilizzare le regole di gestione dei bot per:

  1. Reindirizza le richieste per test reCAPTCHA con un'istanza le sfide manuali.
  2. Valuta i token reCAPTCHA collegati a una richiesta e applicali 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 alle richieste prima di eseguirne il proxy nei backend.

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

Regole preconfigurate per elenchi di indirizzi IP denominati

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

  • Integra i provider di terze parti elenchi di indirizzi IP denominati Google Cloud Armor.

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

  • Sincronizza i provider di terze parti ogni giorno.

  • Aumenta la capacità di configurazione di indirizzi e intervalli IP nella sicurezza perché gli elenchi di indirizzi IP denominati non sono soggetti a limiti 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.
  • Escludi temporaneamente i client che superano la soglia di richiesta impostata per un la durata configurata.

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

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

Per ulteriori informazioni sulla limitazione di frequenza e su come funziona, consulta la Panoramica sulla limitazione di frequenza.

Modalità di anteprima

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

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

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

Se una richiesta attiva un'anteprima, Google Cloud Armor continuerà a valutarla altre regole finché non viene trovata una corrispondenza. Sia la regola corrispondente che quella di anteprima verranno 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 che i bilanciatori del carico o le istanze di backend generati. Inoltre, puoi configurare codici di errore personalizzati per il traffico che Google Cloud Armor nega la richiesta configurando pagine di risposta personalizzate per lo stesso Codici di errore serie 4xx o serie 5xx che indicano che le regole del criterio di sicurezza esistenti per gli utilizzi odierni.

Per ulteriori informazioni sulle risposte di errore personalizzate, consulta Panoramica delle risposte di errore personalizzate. Per la procedura di configurazione, vedi Configura le risposte di errore personalizzate.

Logging

Google Cloud Armor offre un logging esteso e consente di definire il livello di dettaglio del logging. Per informazioni complete sul logging, consulta Utilizza il logging delle richieste. Per ulteriori informazioni registrazione dettagliata, vedi 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 una sicurezza Google Cloud Armor viene registrato tramite Cloud Logging. I log forniscono dettagli quali del criterio di sicurezza applicato, la regola di corrispondenza e se la regola è stata in modo forzato. Il logging delle richieste per le nuove risorse del servizio di backend è stato disabilitato da predefinito. Per assicurarti che le richieste Google Cloud Armor vengano registrate, devi abilitare il logging HTTP(S) per ciascun servizio di backend protetto da un criterio di sicurezza.

Per ulteriori informazioni, vedi Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno

Log 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 come elencato Logging e monitoraggio del bilanciamento del carico del proxy TCP/SSL. Non puoi abilitare il logging per i bilanciatori del carico di rete proxy esterni utilizzando la console Google Cloud.

Limitazioni

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

Limitazione dell'ispezione del corpo POST

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

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

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

Come vengono gestite le connessioni WebSocket

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

Passaggi successivi