Questa pagina contiene casi d'uso comuni per i criteri di sicurezza di Google Cloud Armor. I criteri di sicurezza di Google Cloud Armor possono proteggere la tua applicazione con funzionalità come le liste consentite e le liste bloccate di indirizzi IP, nonché con regole preconfigurate per scoraggiare gli attacchi web più comuni.
Controlla l'accesso alle tue applicazioni e ai tuoi servizi web
Questa sezione illustra diversi modi per utilizzare i criteri di sicurezza di Google Cloud Armor per controllare l'accesso alle applicazioni o ai servizi.
Abilita l'accesso per gli utenti di indirizzi IP specifici con liste consentite
Un caso d'uso tipico per inserire indirizzi IP degli utenti in una lista consentita si verifica quando un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico accede solo a un insieme specifico di utenti. Nell'esempio seguente, solo gli utenti della tua organizzazione sono autorizzati ad accedere ai servizi protetti dal bilanciatore del carico. Questi utenti hanno indirizzi IP o blocchi di indirizzi assegnati dalla tua organizzazione. Puoi inserire questi indirizzi IP o intervalli CIDR in una lista consentita in modo che solo questi utenti possano accedere al bilanciatore del carico.
Puoi controllare l'accesso all'Application Load Balancer esterno globale o all'Application Load Balancer classico configurando una lista consentita con indirizzi IP di origine o intervalli CIDR di origine dai quali è consentito l'accesso al bilanciatore del carico. La seguente sezione descrive ulteriormente questa configurazione.
In questa configurazione, vuoi consentire solo agli utenti della tua organizzazione con indirizzi IP appartenenti a un intervallo IP di accedere all'Application Load Balancer esterno globale o al classico Application Load Balancer. vuoi che tutto il resto del traffico venga rifiutato.
Per creare questa configurazione:
- Crea un criterio di sicurezza di Google Cloud Armor.
- Nel criterio di sicurezza, aggiungi una regola che aggiunga l'intervallo alla lista consentita come prima regola. Questa regola ha la descrizione
allow [RANGE], dove[RANGE]è l'intervallo IP desiderato. - Modifica la regola predefinita nel criterio da una regola di autorizzazione a una regola di negazione. La regola predefinita regola il traffico che non corrisponde a nessuna delle regole precedenti. È l'ultima regola del criterio. La modifica della regola da
allowadenyblocca tutto il traffico che non proviene dall'intervallo della lista consentita. - Associa questo criterio al bilanciatore del carico delle applicazioni esterno globale o al servizio di backend classico dell'Application Load Balancer.
Se la tua organizzazione utilizza un provider di sicurezza di terze parti per eseguire lo scrubbing del traffico, puoi aggiungere l'indirizzo IP del provider a una lista consentita per assicurarti che solo il traffico eseguito possa accedere all'Application Load Balancer esterno globale o al bilanciatore del carico delle applicazioni classico e ai backend.
Nella seguente illustrazione, il provider di terze parti è identificato dall'intervallo CIDR 192.0.2.0/24 e questo intervallo è in una lista consentita.
Bloccare l'accesso per gli utenti di indirizzi IP specifici con liste bloccate
Utilizza le liste bloccate per creare criteri di sicurezza di Google Cloud Armor che rifiutano il traffico da un indirizzo IP o da un intervallo CIDR. Nella seguente illustrazione, il criterio di sicurezza di Google Cloud Armor ha una regola deny che blocca il traffico dall'indirizzo IP 198.51.100.1, in cui è stato identificato un utente malintenzionato.
Regole personalizzate per filtrare in base ai parametri di livello 3-7
Utilizza il linguaggio delle regole personalizzate di Google Cloud Armor per definire una o più espressioni nella condizione di corrispondenza di una regola. Quando Google Cloud Armor riceve una richiesta, la valuta in base a queste espressioni. Se viene rilevata una corrispondenza, l'azione della regola viene applicata, rifiutando o consentendo il traffico in entrata.
I seguenti esempi sono espressioni scritte nell'estensione Google Cloud Armor del Common Expression Language (CEL). Per ulteriori informazioni, consulta la sezione Riferimento per il linguaggio delle regole personalizzate.
Per definire le espressioni in una regola, utilizza il flag gcloud --expression o la console Google Cloud. Per ulteriori informazioni, consulta Creazione di criteri, regole ed espressioni di sicurezza di Google Cloud Armor.
Nell'esempio seguente, le richieste di 2001:db8::/32 (come i tuoi alpha tester) nella regione AU corrispondono alla seguente espressione:
origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')
L'esempio seguente corrisponde alle richieste di 192.0.2.0/24 e a uno user agent contenente la stringa WordPress:
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
Per ulteriori esempi, consulta Espressioni di esempio nel riferimento al linguaggio delle regole personalizzate.
Proteggi il tuo deployment dagli attacchi a livello di applicazione e aiuta a mitigare i 10 principali rischi OWASP
Puoi utilizzare Google Cloud Armor per proteggere un server di origine Cloud CDN da attacchi a livello di applicazione (L7) come SQL injection (SQLi) e cross-site scripting (XSS). I contenuti di una cache sono statici e presumibilmente non pongono un rischio di attacco mirato dal web. Tuttavia, il server di origine dei contenuti sottostante potrebbe essere un'applicazione dinamica con vulnerabilità delle app web note o potenziali. I tuoi requisiti di sicurezza o conformità potrebbero richiedere di attenuare questi rischi per evitare che gli exploit di vulnerabilità su internet attacchino con successo il server di origine.
Per mitigare i rischi:
- Crea o identifica un servizio di backend con CDN abilitata.
- Crea un criterio di sicurezza di Google Cloud Armor.
- Crea una o più regole nel criterio di sicurezza per negare gli attacchi L7.
- Configura una delle destinazioni del criterio di sicurezza come servizio di backend che hai creato o identificato nel passaggio 1.
Puoi anche utilizzare regole preconfigurate per rilevare e bloccare attacchi comuni a livello di applicazione. Le regole preconfigurate sono insiemi di espressioni predefiniti che puoi aggiungere a un criterio di sicurezza di Google Cloud Armor. Per aggiungere questi set di espressioni a una regola,
utilizza il flag gcloud --expression o la console Google Cloud.
Per ulteriori informazioni, consulta Creazione di criteri, regole ed espressioni di sicurezza.
Per ulteriori informazioni sulle regole preconfigurate, consulta Regole preconfigurate nella documentazione di riferimento sul linguaggio delle regole personalizzate.
L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi cross-site scripting (XSS):
evaluatePreconfiguredExpr('xss-stable')
L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi SQL injection (SQLi):
evaluatePreconfiguredExpr('sqli-stable')
Puoi anche combinare regole preconfigurate con altre espressioni. L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi SQLi provenienti dall'intervallo di indirizzi IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredExpr('sqli-stable')
Top 10 per la mitigazione OWASP per i carichi di lavoro ibridi
Google Cloud Armor offre mitigazioni per i seguenti attacchi, indipendentemente dal fatto che siano stati distribuiti in Google Cloud, on-premise o da un provider di terze parti:
- SQL injection (SQLi)
- Cross-site scripting (XSS)
- Inclusione di file locali (LFI)
- Inclusione di file remota (RFI)
- RCE (Remote Code Execution)
Puoi utilizzare queste funzionalità per far fronte ad alcuni dei rischi per la sicurezza delle applicazioni web più comuni, compresi quelli identificati nell'elenco OWASP Top 10.
Le regole WAF preconfigurate di Google Cloud Armor possono essere aggiunte a un criterio di sicurezza per rilevare e rifiutare richieste di livello 7 indesiderate contenenti tentativi SQLi o XSS. Google Cloud Armor rileva le richieste dannose e le rilascia a livello perimetrale dell'infrastruttura Google. Le richieste non vengono inviate tramite proxy al servizio di backend, a prescindere da dove viene eseguito il deployment del servizio.
Per difendere un carico di lavoro non ospitato da Google Cloud da questi attacchi sul perimetro della rete Google, segui questi passaggi:
- Configura un Application Load Balancer esterno globale o un Application Load Balancer classico con un servizio di backend che abbia un NEG internet come backend.
- Crea un criterio di sicurezza di Google Cloud Armor.
- Aggiungi regole SQLi e XSS preconfigurate al criterio.
- Collega il criterio di sicurezza al servizio di backend che hai creato nel passaggio 1.
- Monitora l'attività di Google Cloud Armor utilizzando Cloud Logging, Cloud Monitoring e i risultati inviati a Security Command Center.
Difesa DDoS del server di origine esterno di Cloud CDN e monitoraggio di livello 7
I deployment di Cloud CDN con un server di origine esterno possono avere l'infrastruttura perimetrale di Google come frontend per il proxy, la memorizzazione nella cache e il filtro di livello 7 di Google Cloud Armor. Utilizzando i NEG internet, il server di origine può trovarsi on-premise o presso un provider di infrastruttura di terze parti.
Google Cloud Armor e il resto dell'infrastruttura perimetrale di Google mitigano e eliminano gli attacchi L3/L4, segnalano attività sospette di livello 7 e sono pronti a rifiutare richieste indesiderate di livello 7 con regole personalizzate. Il logging e la telemetria di Google Cloud Armor in Cloud Logging, Cloud Monitoring e Security Command Center forniscono insight strategici per le applicazioni protette, indipendentemente da dove viene eseguito il deployment.
Per abilitare la protezione di Google Cloud Armor per i server di origini esterne CDN, segui questi passaggi:
- Configura un Application Load Balancer esterno globale o un Application Load Balancer classico con un servizio di backend che abbia un NEG internet come backend.
- Abilita Cloud CDN per questo servizio di backend.
- Crea un criterio di sicurezza di Google Cloud Armor.
- Collega il criterio di sicurezza al servizio di backend che hai creato nel passaggio 1.
- Accedi agli avvisi, al logging e alla telemetria di Google Cloud Armor in Security Command Center, Cloud Logging e Cloud Monitoring.
Inoltre, puoi utilizzare i criteri di sicurezza perimetrale per proteggere i contenuti archiviati nella cache. Per ulteriori informazioni sui criteri di sicurezza perimetrale, consulta la panoramica dei criteri di sicurezza.
Controlli dell'accesso e attacchi di busting della cache di livello 7
A seconda dell'architettura dell'applicazione, puoi configurare un servizio di backend per gestire le richieste per vari URL, inclusi i contenuti memorizzabili e non memorizzabili nella cache. In questi scenari di deployment, crea criteri di sicurezza di Google Cloud Armor che negano il traffico indesiderato su determinati percorsi di richiesta, ma consentono a tutti i client di accedere a contenuti statici su un percorso di richiesta diverso.
In altre situazioni, anche se i contenuti vengono forniti in modo efficiente dalla cache, un client dannoso o difettoso potrebbe generare un volume elevato di richieste che comportano un fallimento della cache e richiedere al server di origine sottostante di recuperare o generare i contenuti richiesti. Ciò può applicare risorse limitate e avere un impatto negativo sulla disponibilità dell'applicazione per tutti gli utenti. Puoi creare un criterio di sicurezza di Google Cloud Armor che corrisponda alla firma di tutti i client che causano il problema e rifiutare le richieste prima che raggiungano il server di origine e influiscano sulle prestazioni.
A tale scopo, procedi nel seguente modo:
- Crea un criterio di sicurezza di Google Cloud Armor.
Configura una regola. Ad esempio, la seguente regola nega l'accesso a
"/admin":request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')Collega il criterio di sicurezza del passaggio 1 al servizio di backend in cui è abilitato Cloud CDN.
Passaggi successivi
- Configurare i criteri di sicurezza
- Scopri di più sul linguaggio delle regole personalizzate
- Ottimizzare le regole WAF