Casi d'uso comuni per i criteri di sicurezza

Questa pagina presenta 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 elenchi consentiti e negati di indirizzi IP e regole preconfigurate per scoraggiare gli attacchi web comuni.

Controllare l'accesso ai tuoi servizi e applicazioni web

Questa sezione presenta diversi modi per utilizzare i criteri di sicurezza di Google Cloud Armor per controllare l'accesso alle tue applicazioni o ai tuoi servizi.

Attivare l'accesso per gli utenti a indirizzi IP specifici con le liste consentite

Un caso d'uso tipico per inserire gli indirizzi IP utente in una lista consentita si verifica quando il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico è accessibile solo a un insieme specifico di utenti. Nell'esempio seguente, solo gli utenti della tua organizzazione possono accedere ai servizi dietro il 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 consenti in modo che solo questi utenti abbiano accesso al bilanciamento del carico.

Controlli l'accesso al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico configurando una lista consentita con indirizzi IP di origine o intervalli CIDR di origine da cui è consentito l'accesso al bilanciatore del carico. La sezione seguente descrive ulteriormente questa configurazione.

In questa configurazione, vuoi consentire solo agli utenti della tua organizzazione con indirizzi IP di un intervallo IP di accedere al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico. Vuoi che tutto il resto del traffico venga negato.

Per creare questa configurazione:

1. Crea un criterio di sicurezza di Google Cloud Armor.
2. 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.
3. Modifica la regola predefinita nel criterio da una regola di autorizzazione a una regola di negazione. La regola predefinita gestisce il traffico che non corrisponde a nessuna delle regole precedenti. È l'ultima regola delle norme. Se modifichi la regola da allow a deny, tutto il traffico che non ha origine nell'intervallo della lista consentita viene bloccato.
4. Associa questa policy al bilanciatore del carico delle applicazioni esterno globale o al servizio di backend del bilanciatore del carico delle applicazioni classico.

Se la tua organizzazione utilizza un fornitore di servizi di sicurezza di terze parti per filtrare il traffico, puoi aggiungere l'indirizzo IP del fornitore di servizi di sicurezza a una lista consentita per assicurarti che solo il traffico filtrato possa accedere al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico e ai backend.

Nell'illustrazione seguente, il fornitore di terze parti è identificato dall'intervallo CIDR 192.0.2.0/24 e questo intervallo è presente in una lista consentita.

Bloccare l'accesso per gli utenti a indirizzi IP specifici con le liste nere

Utilizza le liste di negazione per creare criteri di sicurezza di Google Cloud Armor che rifiutano il traffico proveniente da un indirizzo IP o da un intervallo CIDR. Nella seguente illustrazione, il criterio di sicurezza Google Cloud Armor ha una regola deny che blocca il traffico proveniente dall'indirizzo IP 198.51.100.1, in cui è stato identificato un utente malintenzionato.

Regole personalizzate per filtrare in base ai parametri dei livelli 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 esiste una corrispondenza, l'azione della regola ha effetto, negando o consentendo il traffico in entrata.

Gli esempi seguenti sono espressioni scritte nell'estensione Google Cloud Armor del linguaggio Common Expression Language (CEL). Per ulteriori informazioni, consulta il riferimento per il linguaggio delle regole personalizzate.

Per definire le espressioni in una regola, utilizza il flag gcloud --expression o la consoleGoogle Cloud . Per saperne di più, vedi Creare criteri, regole ed espressioni di sicurezza di Google Cloud Armor.

Nel seguente esempio, le richieste provenienti da 2001:db8::/32 (ad esempio i tuoi alpha tester) nella regione AU corrispondono alla seguente espressione:

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

Il seguente esempio corrisponde alle richieste provenienti da 192.0.2.0/24 e a uno user agent che contiene la stringa WordPress:

inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Per altri esempi, vedi Espressioni di esempio nel riferimento al linguaggio delle regole personalizzate.

Proteggi il tuo deployment dagli attacchi a livello di applicazione e contribuisci 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 rappresentano un rischio di attacco mirato dal web. Tuttavia, il server di origine dei contenuti sottostanti potrebbe essere un'applicazione dinamica con vulnerabilità note o potenziali delle app web. I tuoi requisiti di sicurezza o conformità potrebbero richiedere di mitigare questi rischi per impedire che gli exploit delle vulnerabilità di internet attacchino correttamente il server di origine.

Per mitigare i rischi, segui questi passaggi:

1. Crea o identifica un servizio di backend con CDN abilitata.
2. Crea un criterio di sicurezza di Google Cloud Armor.
3. Crea una o più regole nel criterio di sicurezza per negare gli attacchi L7.
4. Configura uno dei target del criterio di sicurezza in modo che sia il 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 --expression di gcloud o la console Google Cloud . Per saperne di più, vedi Creare criteri, regole ed espressioni di sicurezza.

Per impostazione predefinita, una regola preconfigurata ispeziona fino ai primi 8 kB di un corpo della richiesta. Tuttavia, puoi configurare questo limite per criterio. Per ulteriori informazioni sulla configurazione di questo limite di ispezione per il corpo di una richiesta quando utilizzi regole WAF preconfigurate, consulta Limitazione dell'ispezione del corpo delle richieste POST e PATCH.

Per ulteriori informazioni sulle regole preconfigurate, consulta Regole preconfigurate nel riferimento al linguaggio delle regole personalizzate.

L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi cross-site scripting (XSS):

evaluatePreconfiguredWaf('xss-stable')

L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi SQL injection (SQLi):

evaluatePreconfiguredWaf('sqli-stable')

Puoi anche combinare regole preconfigurate con altre espressioni. Il seguente esempio utilizza una regola preconfigurata per mitigare gli attacchi SQLi dall'intervallo di indirizzi IP 192.0.2.1/24:

inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')

Mitigazione dei rischi OWASP Top 10 per i carichi di lavoro ibridi

Google Cloud Armor offre mitigazioni per i seguenti attacchi, indipendentemente dal fatto che vengano eseguiti in Google Cloud, on-premise o in un provider di terze parti:

• SQL injection (SQLi)
• Cross-site scripting (XSS)
• Inclusione di file locali (LFI)
• Inclusione di file remoti (RFI)
• Esecuzione di codice remoto (RCE)

Puoi utilizzare queste funzionalità per affrontare alcuni dei rischi per la sicurezza delle applicazioni web più comuni, inclusi 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 negare le richieste di livello 7 indesiderate contenenti tentativi di SQLi o XSS. Google Cloud Armor rileva le richieste dannose e le elimina sul perimetro dell'infrastruttura di Google. Le richieste non vengono inoltrate tramite proxy al servizio di backend, indipendentemente da dove è stato eseguito il deployment.

Per proteggere un carico di lavoro non ospitato suGoogle Cloudda questi attacchi all'edge della rete di Google, segui questi passaggi:

1. Configura un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico con un servizio di backend che ha un NEG internet come backend.
2. Crea un criterio di sicurezza di Google Cloud Armor.
3. Aggiungi al criterio regole SQLi e XSS preconfigurate.
4. Collega la policy di sicurezza al servizio di backend creato al passaggio 1.
5. Monitora l'attività di Google Cloud Armor utilizzando Cloud Logging, Cloud Monitoring e i risultati inviati a Security Command Center.

Difesa DDoS e monitoraggio di livello 7 del server di origine esterno Cloud CDN

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 con un provider di infrastrutture di terze parti.

Google Cloud Armor e il resto dell'infrastruttura edge di Google mitigano e abbandonano gli attacchi L3/L4, inviano avvisi su attività sospette di livello 7 e sono pronti a negare richieste di livello 7 indesiderate con regole personalizzate. Il logging e la telemetria di Google Cloud Armor in Cloud Logging, Cloud Monitoring e Security Command Center forniscono informazioni utili per le applicazioni protette, indipendentemente dalla loro posizione di deployment.

Per abilitare la protezione Google Cloud Armor per i server di origine esterni CDN, segui questi passaggi:

1. Configura un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico con un servizio di backend che ha un NEG internet come backend.
2. Abilita Cloud CDN per questo servizio di backend.
3. Crea un criterio di sicurezza di Google Cloud Armor.
4. Collega la policy di sicurezza al servizio di backend creato al passaggio 1.
5. 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 memorizzati nella cache. Per ulteriori informazioni sui criteri di sicurezza perimetrale, consulta la Panoramica dei criteri di sicurezza.

Controlli dell'accesso al livello 7 e attacchi di invalidazione della cache

A seconda dell'architettura dell'applicazione, puoi configurare un servizio di backend per gestire le richieste per vari URL, inclusi contenuti memorizzabili e non memorizzabili nella cache. In questi scenari di deployment, crea criteri di sicurezza Google Cloud Armor che negano il traffico indesiderato su determinati percorsi di richiesta, ma consentono a tutti i client di accedere ai 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 richiedono al server di origine sottostante di recuperare o generare i contenuti richiesti. Ciò può mettere a dura prova le risorse limitate e avere un impatto negativo sulla disponibilità dell'applicazione per tutti gli utenti. Puoi creare un criterio di sicurezza Google Cloud Armor che corrisponda alla firma di qualsiasi client che causa il problema e negare le richieste prima che raggiungano il server di origine e influiscano sulle prestazioni.

Per farlo, segui questi passaggi:

1. Crea un criterio di sicurezza di Google Cloud Armor.

2. Configura una regola. Ad esempio, la seguente regola nega l'accesso a "/admin":

   request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')
   

3. Collega il criterio di sicurezza del passaggio 1 al servizio di backend in cui è abilitata Cloud CDN.

Passaggi successivi

• Configurare i criteri di sicurezza
• Scopri di più sul linguaggio delle regole personalizzate
• Ottimizzare le regole WAF