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 liste consentite e liste vietate di indirizzi IP e regole predefinite 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 esempio, solo gli utenti della tua organizzazione sono autorizzati ad 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 lista consentita in modo che solo questi utenti abbiano accesso al bilanciatore del carico.
Controlla l'accesso all'Application Load Balancer esterno globale o all'Application Load Balancer classico configurando una lista consentita con gli indirizzi IP di origine o gli 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 all'Application Load Balancer esterno globale o all'Application Load Balancer classico. Vuoi che tutto il resto del traffico venga negato.
Per creare questa configurazione:
- Crea un criterio di sicurezza di Google Cloud Armor.
- Nel criterio di sicurezza, aggiungi una regola che aggiunge 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 divieto. 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 ha origine nell'intervallo della lista consentita. - Associa questa regola 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 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 dal livello 3 al livello 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, viene applicata l'azione della regola, che nega o consente il traffico in entrata.
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, consulta
Creare criteri, regole ed espressioni di sicurezza di Google Cloud Armor.
Nell'esempio seguente, le richieste provenienti da 2001:db8::/32 (ad esempio i tuoi beta
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 altri esempi, consulta la sezione 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 rischi elencati nel documento OWASP Top 10
Puoi utilizzare Google Cloud Armor per proteggere un server di origine Cloud CDN dagli attacchi a livello di applicazione (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, il server di origine dei contenuti sottostante potrebbe essere un'applicazione dinamica con vulnerabilità note o potenziali delle app web. I requisiti di sicurezza o conformità potrebbero richiedere di attenuare questi rischi per impedire che gli exploit di vulnerabilità provenienti da internet possano attaccare con successo il server di origine.
Per ridurre 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 uno dei target del criterio di sicurezza come il servizio di backend creato o identificato nel passaggio 1.
Puoi anche utilizzare regole preconfigurate per rilevare e bloccare gli attacchi comuni a livello di applicazione. Le regole preconfigurate sono insiemi di espressioni predefinite che puoi aggiungere a 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, consulta
Creare 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 mitigare gli attacchi di 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 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 i seguenti attacchi, indipendentemente dal fatto che siano 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 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 aggiunte a un criterio di sicurezza per rilevare e rifiutare 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 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:
- 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.
- Crea un criterio di sicurezza di Google Cloud Armor.
- Aggiungi al criterio le regole SQLi e XSS preconfigurate.
- 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 e monitoraggio di livello 7 per i server di origine esterni 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 su 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, volgi i seguenti passaggi:
- 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.
- 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 creato nel passaggio 1.
- Accedi ad avvisi, log e telemetria di Google Cloud Armor in Security Command Center, Cloud Logging e Cloud Monitoring.
Inoltre, puoi utilizzare i criteri di sicurezza di Edge per proteggere i contenuti memorizzati nella cache. Per ulteriori informazioni sui criteri di sicurezza di Edge, consulta la 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 gestire le richieste di vari URL, inclusi contenuti memorizzabili nella cache e non memorizzabili nella cache. 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 ai contenuti statici su un percorso di richiesta diverso.
In altri casi, anche se i contenuti vengono pubblicati in modo efficiente dalla cache, un client dannoso o difettoso potrebbe generare un volume elevato di richieste che generano una fallimento della cache e richiedono al server di origine sottostante di recuperare o generare i contenuti richiesti. Ciò può mettere a dura prova risorse limitate e avere un impatto negativo sulla disponibilità dell'applicazione per tutti gli utenti. Puoi creare un criterio di sicurezza Google Cloud Armor in modo 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.
Per farlo, segui questi passaggi:
- 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 per cui è attivata Cloud CDN.
Passaggi successivi
- Configurare i criteri di sicurezza
- Scopri di più sul linguaggio delle regole personalizzate
- Ottimizzare le regole WAF