Casi d'uso comuni dei 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 liste consentite di indirizzi IP e liste bloccate e regole preconfigurate per scoraggiare attacchi web comuni.

Controllare l'accesso alle applicazioni e ai servizi 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.

Abilitare l'accesso per gli utenti di indirizzi IP specifici con le liste consentite

Un caso d'uso tipico per l'inserimento degli indirizzi IP di un utente in una lista consentita è quando il bilanciatore del carico HTTP(S) esterno globale o il bilanciatore del carico HTTP(S) esterno globale (classico) è accessibile solo da un insieme specifico di utenti. Nel seguente esempio, solo gli utenti della tua organizzazione possono accedere ai servizi protetti dal 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.

Limitazione dell'accesso al bilanciatore del carico con una lista consentita.
Limitazione dell'accesso del bilanciatore del carico a una lista consentita (fai clic per ingrandire)

Puoi controllare l'accesso al bilanciatore del carico HTTP(S) esterno globale o al bilanciatore del carico HTTP(S) esterno globale (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 configurazione viene descritta in dettaglio nella sezione seguente.

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

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 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 servizio di backend HTTP(S) esterno globale o a un bilanciatore del carico HTTP(S) esterno globale (classico)

Se la tua organizzazione utilizza un provider di sicurezza di terze parti per eseguire il scrubbing del traffico, puoi aggiungere l'indirizzo IP del provider di sicurezza a una lista consentita per assicurarti che solo il traffico sottoposto a soffrimento possa accedere al bilanciatore del carico HTTP(S) esterno globale o al bilanciatore del carico HTTP(S) esterno globale (classico) e ai backend.

Nella figura seguente, il provider di terze parti è identificato dall'intervallo CIDR 192.0.2.0/24, che si trova in una lista consentita.

Limitazione dell'accesso al bilanciatore del carico includendo il traffico da un provider di sicurezza di terze parti.
Limitazione dell'accesso del bilanciatore del carico includendo il traffico nella lista consentita dal provider di sicurezza di terze parti (fai clic per ingrandire)

Bloccare l'accesso degli utenti a indirizzi IP specifici con le liste bloccate

Utilizza le liste bloccate per creare criteri di sicurezza di Google Cloud Armor che rifiutano il traffico proveniente da un indirizzo IP o da un intervallo CIDR. Nell'immagine seguente, il criterio di sicurezza di Google Cloud Armor ha una regola deny che blocca il traffico dall'indirizzo IP 198.51.100.1, dove è stato identificato un utente dannoso.

Limitazione dell'accesso del bilanciatore del carico a una lista bloccata.
Limitazione dell'accesso del bilanciatore del carico a una lista bloccata (fai clic per ingrandire)

Regole personalizzate per filtrare in base ai parametri di livello da 3 a 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 è presente una corrispondenza, l'azione della regola viene applicata, che nega o autorizza il traffico in entrata.

Gli esempi riportati di seguito sono espressioni scritte nell'estensione Google Cloud Armor del Common Expression Language (CEL). Per ulteriori informazioni, consulta il riferimento per la lingua per le regole personalizzate.

Per definire le espressioni in una regola, utilizza il flag gcloud --expression o la console Google Cloud. Per ulteriori informazioni, consulta la sezione Creazione di criteri di sicurezza, regole ed espressioni di Google Cloud Armor.

Nell'esempio seguente, le richieste da 2001:db8::/32 (ad esempio gli alpha test) nell'area geografica 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 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, consulta la sezione Espressioni di esempio nel riferimento relativo al linguaggio delle regole personalizzate.

Proteggi il tuo deployment dagli attacchi a livello di applicazione e riduci i rischi 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 script cross-site (XSS). I contenuti di una cache sono statici e presumibilmente non pongono il rischio di un attacco mirato da parte del Web. Tuttavia, il server di origine dei contenuti sottostante potrebbe essere un'applicazione dinamica con vulnerabilità note o potenziali relative alle app. I requisiti di sicurezza o conformità potrebbero richiedere la mitigazione di questi rischi per impedire agli exploit di Internet di attaccare correttamente il server di origine.

Per ridurre i rischi:

  1. Creare o identificare 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 rifiutare gli attacchi L7.
  4. Configura una delle destinazioni del criterio di sicurezza come servizio di backend che hai creato o identificato nel passaggio 1.

Puoi anche utilizzare regole preconfigurate per rilevare e bloccare gli attacchi a livello di applicazione comuni. 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 gcloud --expression o Google Cloud Console. Per ulteriori informazioni, vedi Creazione di criteri di sicurezza, regole ed espressioni.

Per ulteriori informazioni sulle regole preconfigurate, consulta la sezione Regole preconfigurate nel riferimento alla lingua per le regole personalizzate.

L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi 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 regole preconfigurate con altre espressioni. L'esempio seguente utilizza una regola preconfigurata per mitigare gli attacchi SQL nell'intervallo di indirizzi IP 192.0.2.1/24:

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

OWASP Top 10 - mitigazione per i carichi di lavoro ibridi

Google Cloud Armor offre mitigazioni per i seguenti attacchi, sia che venga eseguito il deployment in Google Cloud, on-premise che in un provider di terze parti:

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

Puoi utilizzare queste funzionalità per affrontare alcuni dei rischi per la sicurezza delle applicazioni web più comuni, inclusi i rischi identificati nell'elenco delle primi 10 di OWASP.

Le regole WF preconfigurate di Google Cloud Armor possono essere aggiunte a un criterio di sicurezza per rilevare e rifiutare le richieste di livello 7 indesiderate contenenti tentativi SQLi o XSS. Google Cloud Armor rileva le richieste dannose e le rilascia sul perimetro dell'infrastruttura di Google. Le richieste non vengono trasferite al servizio di backend, a prescindere dalla posizione di deployment del servizio di backend.

Per difendere un carico di lavoro non ospitato su Google Cloud da questi attacchi sul perimetro della rete Google, segui questi passaggi:

  1. Configura un bilanciatore del carico HTTP(S) esterno globale o un bilanciatore del carico HTTP(S) esterno globale (classico) con un servizio di backend che dispone di un NEG Internet come backend.
  2. Crea un criterio di sicurezza di Google Cloud Armor.
  3. Aggiungi le regole SQLi e XSS preconfigurate al criterio.
  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 del server di origine esterna 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 e i filtri del livello 7 di Google Cloud Armor. Utilizzando i NEG Internet, il server di origine può trovarsi on-premise o con un provider di infrastruttura di terze parti.

Google Cloud Armor e il resto dell'infrastruttura perimetrale di Google mitigano e bloccano gli attacchi L3/L4, gli avvisi sulle attività di livello 7 sospette e sono pronti a rifiutare le richieste di livello 7 indesiderate con regole personalizzate. Il logging e la telemetria di Google Cloud Armor su Cloud Logging, Cloud Monitoring e Security Command Center offrono insight strategici per le applicazioni protette, indipendentemente da dove ne viene eseguito il deployment.

Per attivare la protezione Google Cloud Armor per i server di origini esterne CDN, segui questi passaggi:

  1. Configura un bilanciatore del carico HTTP(S) esterno globale o un bilanciatore del carico HTTP(S) esterno globale (classico) con un servizio di backend che dispone di 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 che hai creato nel passaggio 1.
  5. Accedi agli avvisi, ai log e alla telemetria di Google Cloud Armor in Security Command Center, Cloud Logging e Cloud Monitoring.

Inoltre, puoi utilizzare i criteri di sicurezza perimetrali per proteggere i contenuti archiviati nella cache. Per ulteriori informazioni sui criteri di sicurezza perimetrali, consulta la Panoramica dei criteri di sicurezza.

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

A seconda dell'architettura dell'applicazione, puoi configurare un servizio di backend per gestire le richieste di vari URL, inclusi i contenuti memorizzabili e non memorizzabili nella cache. In scenari di deployment di questo tipo, crea criteri di sicurezza di Google Cloud Armor che negano il traffico indesiderato in 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 gestiti in modo efficiente dalla cache, un client dannoso o difettoso potrebbe generare un volume elevato di richieste, causando un fallimento della cache e richiedere al server di origine sottostante di recuperare o generare i contenuti richiesti. Questo può affaticare le risorse limitate e avere un impatto negativo sulla disponibilità dell'applicazione per tutti gli utenti. Puoi creare un criterio di sicurezza di Google Cloud Armor per associare la 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 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 per cui è abilitato Cloud CDN.

Passaggi successivi