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 di indirizzi IP, come liste consentite e bloccate di indirizzi IP, e applicazioni per scoraggiare gli attacchi web più comuni.

Controllare 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 tue applicazioni o ai tuoi servizi.

Consentire l'accesso agli utenti con indirizzi IP specifici con le liste consentite

Un caso d'uso tipico per inserire gli indirizzi IP degli utenti in una lista consentita è quando il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico è accessibile solo da un insieme specifico di utenti. Nel seguente Ad esempio, solo gli utenti della tua organizzazione possono accedere ai servizi mediante del 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 abbiano accesso al bilanciatore del carico.

Puoi controllare l'accesso al bilanciatore del carico delle applicazioni esterno globale o all'Application Load Balancer classico e configurare una lista consentita indirizzi IP di origine o intervalli CIDR di origine da cui accedere al tuo è consentito utilizzare un bilanciatore. La sezione seguente descrive ulteriormente questa configurazione.

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

Per creare questa configurazione, segui questi passaggi:

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 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 allow a deny blocca tutto il traffico che non ha origine nell'intervallo della lista consentita.
4. Associa questo criterio al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico il servizio di backend del bilanciatore del carico delle applicazioni classico.

Se la tua organizzazione utilizza un provider di sicurezza di terze parti per eseguire la pulizia del traffico, puoi aggiungere l'indirizzo IP del provider di sicurezza a una lista consentita per assicurarti che solo il traffico sottoposto a pulizia 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, che è presente in una lista consentita.

Bloccare l'accesso degli utenti con indirizzi IP specifici con le liste di blocco

Utilizza le liste di rifiuto per creare criteri di sicurezza di Google Cloud Armor che rifiutano il traffico proveniente da un indirizzo IP o da un intervallo CIDR. Nell'illustrazione seguente, il criterio di sicurezza Google Cloud Armor contiene 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 del livello 3 al livello 7

Utilizza il linguaggio delle regole personalizzate di Google Cloud Armor per definire una o più expression nella condizione di corrispondenza di una regola. Quando Google Cloud Armor riceve una richiesta, la valuta in base a queste espressioni. Se esiste un corrispondenza, l'azione della regola diventa effettiva, rifiutando o consentendo la richiesta in entrata per via del traffico.

I seguenti esempi 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 console Google Cloud. Per ulteriori informazioni, vedi Creazione di criteri, regole ed espressioni di sicurezza di Google Cloud Armor.

Nell'esempio seguente, le richieste da 2001:db8::/32 (come il tuo 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 provenienti da 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 la sezione Esempio espressioni nel riferimento al linguaggio di regole personalizzate.

Proteggi il tuo deployment dagli attacchi a livello delle applicazioni e contribuisci a mitigare i rischi OWASP Top 10

Puoi utilizzare Google Cloud Armor per proteggere un server di origine Cloud CDN dagli attacchi a livello delle applicazioni (L7), come SQL injection (SQLi) e cross-site scripting (XSS). I contenuti in una cache sono statici e presumibilmente non rappresentano un rischio di attacco mirato dal web. Tuttavia, i contenuti sottostanti il server di origine potrebbe essere un'applicazione dinamica con app web le vulnerabilità. I requisiti di sicurezza o conformità potrebbero richiederti mitigare questi rischi per prevenire gli exploit delle vulnerabilità da parte di internet attaccare correttamente il server di origine.

Per ridurre i rischi:

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 una delle destinazioni del criterio di sicurezza come backend che hai creato o identificato nel passaggio 1.

Puoi anche utilizzare regole preconfigurate per rilevare e bloccare il livello di applicazione comune attacchi informatici. Le regole preconfigurate sono set di espressioni predefiniti che puoi aggiungere un criterio di sicurezza di Google Cloud Armor. Per aggiungere questi insiemi di espressioni a una regola, utilizza il flag gcloud --expression o la console Google Cloud. Per ulteriori informazioni, vedi Creazione di criteri, regole ed espressioni di sicurezza.

Per saperne di più sulle regole preconfigurate, consulta Preconfigurate regole personalizzate nel al linguaggio di riferimento delle regole.

L'esempio seguente utilizza una regola preconfigurata per ridurre il traffico tra siti attacchi di scripting (XSS):

evaluatePreconfiguredExpr('xss-stable')

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

evaluatePreconfiguredExpr('sqli-stable')

Puoi anche combinare le regole preconfigurate con altre espressioni. L'esempio seguente 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') && evaluatePreconfiguredExpr('sqli-stable')

Mitigazione delle vulnerabilità OWASP Top 10 per i carichi di lavoro ibridi

Google Cloud Armor offre mitigazioni per gli attacchi riportati di seguito, che Viene eseguito il deployment in Google Cloud, on-premise o presso un provider di terze parti:

• SQL injection (SQLi)
• Cross-site scripting (XSS)
• Inclusione di file locali (LFI)
• Inclusione di file remoto (RFI)
• RCE (Remote Code Execution)

Puoi utilizzare queste funzionalità per risolvere 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 aggiunto a un criterio di sicurezza per rilevare e rifiutare le richieste indesiderate di livello 7. che contiene tentativi SQLi o XSS. Google Cloud Armor rileva le richieste dannose e le elimina sul perimetro dell'infrastruttura di Google. Le richieste non vengono proxy al servizio di backend, indipendentemente da dove viene eseguito il deployment del servizio di backend.

Per difendere un carico di lavoro non ospitato su Google Cloud da 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 di servizio di backend con una connessione NEG come backend.
2. Crea un criterio di sicurezza di Google Cloud Armor.
3. Aggiungi al criterio le regole SQLi e XSS preconfigurate.
4. Collega il criterio di sicurezza al servizio di backend che hai creato nel 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 a 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 a livello 7 di Google Cloud Armor. Se utilizzi NEG di internet, il server di origine può trovarsi on-premise o presso un fornitore di infrastrutture di terze parti.

Google Cloud Armor e il resto dell'infrastruttura di confine di Google mitigano e bloccano gli attacchi L3/L4, inviano avvisi su attività di livello 7 sospette e sono pronti a negare le 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 strategiche per le applicazioni protette, indipendentemente da dove vengono implementate.

Per attivare la protezione di Google Cloud Armor per i server di origini esterni della 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 il criterio di sicurezza al servizio di backend creato nel passaggio 1.
5. Accedi ad avvisi, logging e 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 . Per ulteriori informazioni sui criteri di sicurezza perimetrale, consulta Panoramica dei criteri di sicurezza.

Controlli dell'accesso di livello 7 e attacchi di busting della cache

A seconda dell'architettura dell'applicazione, puoi configurare un servizio di backend per soddisfare richieste per vari URL, inclusi memorizzabili e non memorizzabili nella cache contenuti. In questi scenari di implementazione, crea criteri di sicurezza di Google Cloud Armor che neghino il traffico indesiderato su determinati percorsi di richiesta, ma consentano a tutti i client di accedere a contenuti statici su un percorso di richiesta diverso.

In altre situazioni, anche se i contenuti vengono pubblicati in modo efficiente da , un client dannoso o guasto potrebbe generare un volume elevato di richieste che comportano un fallimento della cache e richiedono che il server di origine sottostante recuperi o per generare i contenuti richiesti. Questo può affaticare le risorse limitate e avere un impatto negativo sulla disponibilità dell'applicazione per tutti gli utenti. Puoi crea un criterio di sicurezza di Google Cloud Armor corrispondente alla firma i client che causano il problema e rifiutano le richieste prima che raggiungano il server di origine, oltre a influire sulle prestazioni.

Per farlo, segui questi passaggi:

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

2. Configurare 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 che ha Cloud CDN abilitato.

Passaggi successivi

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