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.
Controlla l'accesso alle applicazioni e ai servizi web
Questa sezione illustra i diversi modi per utilizzare i criteri di sicurezza di Google Cloud Armor per controllare l'accesso alle tue applicazioni o ai tuoi servizi.
Abilita l'accesso per gli utenti in indirizzi IP specifici con liste consentite
Un tipico caso d'uso 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 un gruppo specifico di utenti. Nel seguente Ad esempio, solo gli utenti della tua organizzazione possono accedere ai servizi mediante del bilanciatore del carico. A questi utenti sono stati assegnati indirizzi IP o blocchi di indirizzi dell'organizzazione. Puoi inserire questi indirizzi IP o intervalli CIDR in una 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 seguente sezione descrive ulteriormente questo argomento 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 tutto il resto del traffico da rifiutare.
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
di negazione. La regola predefinita regola il traffico che non corrisponde a nessuno di
le regole precedenti. È l'ultima regola del criterio. Modifica della regola
da
allowadenyblocca tutto il traffico che non proviene dal incluso nella lista consentita. - Associa questo criterio 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 eseguire lo scrubbing del traffico, puoi aggiungere l'indirizzo IP del provider di sicurezza a una lista consentita per garantire che il traffico sottoposto a scrubbing può accedere al bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni e i backend classici.
Nella illustrazione seguente, il fornitore di terze parti è identificato dal simbolo Intervallo CIDR 192.0.2.0/24, incluso in una lista consentita.
Bloccare l'accesso per gli utenti in indirizzi IP specifici mediante liste bloccate
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. 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, nel quale è 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ù nella condizione di corrispondenza di una regola. Quando Google Cloud Armor riceve richiesta, viene valutata 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.
Gli esempi riportati di seguito sono espressioni scritte nell'editor Estensione Google Cloud Armor del Common Expression Language (CEL). Per ulteriori informazioni, consulta Riferimento al linguaggio delle regole personalizzate.
Per definire le espressioni in una regola, utilizza il flag --expression di gcloud o
nella console Google Cloud. Per ulteriori informazioni, consulta
Creare 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 di 192.0.2.0/24 e di un utente
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 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 di una cache sono statici e presumibilmente non rischiano di subire un 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 alle vulnerabilità da parte di internet attaccare correttamente 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 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 ulteriori informazioni sulle regole preconfigurate, consulta Regole preconfigurate nel riferimento al linguaggio delle regole personalizzate.
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. Le seguenti
di esempio utilizza una regola preconfigurata per mitigare gli attacchi SQLi
Intervallo di indirizzi IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredExpr('sqli-stable')
OWASP Top 10 per la mitigazione dei 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)
- Esecuzione di codice remoto (RCE)
Puoi usare queste funzionalità per risolvere alcuni dei problemi più comuni per la sicurezza delle applicazioni, inclusi i rischi identificati Top 10 di OWASP dall'elenco di lettura.
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 richieste dannose e le rilascia 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 da questi attacchi un carico di lavoro non ospitato su Google Cloud sul perimetro della rete Google, svolgi i seguenti passaggi:
- 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.
- 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 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 Cloud CDN con un server di origine esterno possono avere l'infrastruttura perimetrale di Google come frontend per il proxy, la memorizzazione nella cache Filtro di Google Cloud Armor livello 7. Utilizzando i NEG internet, l'origine può trovarsi on-premise o con un'infrastruttura di terze parti o il provider di servizi di terze parti.
Google Cloud Armor e il resto dell'infrastruttura perimetrale di Google mitigano e blocca gli attacchi L3/L4, gli avvisi su attività sospette di livello 7 e blocca e pronto a rifiutare le richieste indesiderate di livello 7 con regole personalizzate. Google Cloud Armor logging e telemetria su Cloud Logging, Cloud Monitoring e Security Command Center fornisce insight strategici per le applicazioni indipendentemente da dove ne viene eseguito il deployment.
Per abilitare la protezione di Google Cloud Armor per i server di origini esterne CDN, segui questi passaggi:
- 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.
- 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 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 di accesso a livello 7 e attacchi cache-busting
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 scenari di deployment di questo tipo, crea la sicurezza di Google Cloud Armor criteri che negano il traffico indesiderato su determinati percorsi di richiesta, ma consentono per 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:
- Crea un criterio di sicurezza di Google Cloud Armor.
Configurare 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 che ha Cloud CDN abilitato.
Passaggi successivi
- Configurare i criteri di sicurezza
- Scopri di più sul linguaggio delle regole personalizzate
- Ottimizzazione delle regole WAF