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 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 Cloud Armor per controllare l'accesso alle tue applicazioni o ai tuoi servizi.

Attiva 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 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 provider di sicurezza di terze parti per filtrare il traffico, puoi aggiungere l'indirizzo IP del provider 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 policy di sicurezza Cloud Armor che rifiutano il traffico proveniente da un indirizzo IP o da un intervallo CIDR. Nella seguente illustrazione, la policy di sicurezza 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 dei livelli 3-7

Utilizza il linguaggio delle regole personalizzate di Cloud Armor per definire una o più espressioni nella condizione di corrispondenza di una regola. Quando 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 Cloud Armor di 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 --expression di gcloud o la consoleTrusted Cloud . Per saperne di più, vedi Creazione di regole, espressioni e policy di sicurezza di 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 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 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 Cloud Armor. Per aggiungere questi set di espressioni a una regola, utilizza il flag gcloud --expression o la console Trusted 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 saperne di più 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

Cloud Armor offre mitigazioni per i seguenti attacchi, indipendentemente dal fatto che vengano eseguiti in Trusted 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 Cloud Armor possono essere aggiunte a un criterio di sicurezza per rilevare e negare richieste indesiderate di livello 7 contenenti tentativi di SQLi o XSS. Cloud Armor rileva le richieste dannose e le elimina al 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 suTrusted 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 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 Cloud Armor utilizzando Cloud Logging, Cloud Monitoring e i risultati inviati a Security Command Center.

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 di 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 Cloud Armor per trovare la corrispondenza della firma di tutti i client che causano il problema e rifiutare 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 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