Le sezioni seguenti descrivono in che modo Cloud Armor interagisce con altre Google Cloud funzionalità e prodotti.
Cloud Armor e regole firewall VPC
I criteri di sicurezza Cloud Armor e le regole firewall VPC hanno funzioni diverse:
- I criteri di sicurezza di Cloud Armor forniscono la sicurezza perimetrale e agiscono sul traffico client verso i Google Front End (GFE).
- Le regole firewall VPC consentono o negano il traffico da e verso i tuoi backend. Devi creare regole firewall di autorizzazione in entrata, i cui target sono le VM di backend con bilanciamento del carico e le cui origini sono intervalli IP utilizzati dai bilanciatori del carico delle applicazioni esterni globali o dai bilanciatori del carico delle applicazioni classici. Queste regole consentono ai GFE e ai sistemi di controllo di integrità di comunicare con le tue VM di backend.
Ad esempio, considera uno scenario in cui vuoi consentire il traffico solo dagli intervalli CIDR 100.1.1.0/24 e 100.1.2.0/24 per accedere al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico. Il tuo obiettivo è bloccare il traffico che raggiunge direttamente le istanze con bilanciamento del carico di backend. In altre parole, solo il traffico esterno sottoposto a proxy tramite il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico con un criterio di sicurezza associato può raggiungere le istanze.
Il diagramma precedente mostra la seguente configurazione di deployment:
- Crea due gruppi di istanze, uno nella regione
us-west1
e l'altro nella regioneeurope-west1
. - Esegui il deployment delle istanze dell'applicazione di backend sulle VM nei gruppi di istanze.
- Crea un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico nel tier Premium. Configura una mappa URL
e un singolo servizio di backend i cui backend sono i due gruppi di istanze
che hai creato nel passaggio precedente. La regola di forwarding del bilanciatore del carico deve utilizzare l'indirizzo IP esterno
120.1.1.1
. - Configura un criterio di sicurezza Cloud Armor che consenta il traffico da 100.1.1.0/24 e 100.1.2.0/24 e neghi tutto il resto del traffico.
- Associa questa policy al servizio di backend del bilanciatore del carico. Per istruzioni, consulta la sezione Configurare i criteri di sicurezza di Cloud Armor. I bilanciatori del carico HTTP(S) esterni con mappe URL più complesse possono fare riferimento a più servizi di backend. Puoi associare il criterio di sicurezza a uno o più servizi di backend in base alle esigenze.
- Configura le regole firewall di autorizzazione in entrata per consentire il traffico dal bilanciatore del carico delle applicazioni esterno globale o dal bilanciatore del carico delle applicazioni classico. Per saperne di più, vedi Regole firewall.
Cloud Armor con bilanciatori del carico delle applicazioni esterni e IAP
Identity-Aware Proxy (IAP) verifica l'identità di un utente e poi determina se può accedere a un'applicazione. Per attivare IAP per il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico, utilizza i servizi di backend del bilanciatore del carico. Analogamente, i criteri di sicurezza Cloud Armor perimetrali vengono collegati ai servizi di backend di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico.
Se i criteri di sicurezza di Cloud Armor e IAP sono entrambi attivati per un servizio di backend, l'ordine di valutazione dipende dal tipo di bilanciatore del carico:
Per un servizio di backend di un bilanciatore del carico delle applicazioni esterno globale, la valutazione di Cloud Armor viene eseguita per prima. Se Cloud Armor blocca una richiesta, IAP non la valuta. Se Cloud Armor consente una richiesta, IAP la valuta. La richiesta viene bloccata se IAP non la autentica.
Per un servizio di backend di un bilanciatore del carico delle applicazioni classico, la valutazione IAP viene eseguita per prima. Se IAP autentica una richiesta, Cloud Armor la valuta. Se una richiesta non supera l'autenticazione IAP, Cloud Armor non la valuta.
Per ulteriori informazioni su IAP e sulle configurazioni correlate, consulta la documentazione di Identity-Aware Proxy.
Cloud Armor con deployment ibridi
In un deployment ibrido, un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico delle applicazioni classico deve accedere a un'applicazione o a un'origine dei contenuti che viene eseguita al di fuori di Google Cloud Google Cloud, ad esempio nell'infrastruttura di un altro provider di servizi cloud. Puoi utilizzare Cloud Armor per proteggere questi deployment.
Nel seguente diagramma, il bilanciatore del carico ha due servizi di backend. Uno ha un gruppo di istanze come backend. L'altro servizio di backend ha un NEG internet come backend e il NEG internet è associato a un'applicazione in esecuzione nel data center di un fornitore di terze parti.
Quando colleghi un criterio di sicurezza Cloud Armor al servizio di backend che ha un NEG internet come backend, Cloud Armor esamina ogni richiesta di livello 7 che arriva al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico destinato a quel servizio di backend.
La protezione Cloud Armor per i deployment ibridi è soggetta agli stessi limiti applicati ai NEG internet.
Cloud Armor con Google Kubernetes Engine (GKE)
Le sezioni seguenti descrivono come funziona Cloud Armor con GKE.
GKE Ingress
Dopo aver configurato un criterio di sicurezza Cloud Armor, puoi utilizzare Kubernetes Ingress per abilitarlo con GKE.
Puoi fare riferimento alla tua policy di sicurezza con una risorsa BackendConfig
aggiungendo
il nome della tua policy di sicurezza a BackendConfig
. Il seguente manifest BackendConfig
specifica una policy di sicurezza denominata example-security-policy
:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
namespace: cloud-armor-how-to
name: my-backendconfig
spec:
securityPolicy:
name: "example-security-policy"
Per ulteriori informazioni sulle funzionalità di Ingress, consulta la sezione Configurazione di Ingress.
Gateway GKE
Dopo aver configurato un criterio di sicurezza Cloud Armor, puoi utilizzare l'API Kubernetes Gateway per abilitarlo con GKE.
Puoi fare riferimento alla tua policy di sicurezza aggiungendo il nome della policy di sicurezza a una risorsa policy GCPBackendPolicy
. Il seguente
manifest della risorsa policy GCPBackendPolicy
specifica una policy di sicurezza del backend
denominata example-security-policy
:
Servizio
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: ""
kind: Service
name: lb-service
Servizio multi-cluster
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Per ulteriori informazioni sulla configurazione delle policy di sicurezza del backend Cloud Armor, consulta Configurare la policy di sicurezza del backend Cloud Armor per proteggere i servizi di backend.
Cloud Armor con Cloud CDN
Per proteggere i server di origine CDN, puoi utilizzare Cloud Armor con Cloud CDN. Cloud Armor protegge il server di origine CDN dagli attacchi alle applicazioni, mitiga i 10 principali rischi OWASP e applica i criteri di filtro di livello 7. Esistono due tipi di policy di sicurezza che influiscono sul modo in cui Cloud Armor funziona con Cloud CDN: policy di sicurezza edge e policy di sicurezza del backend.
Policy di sicurezza edge
Puoi utilizzare i criteri di sicurezza perimetrale per i servizi di backend abilitati a Cloud CDN e i bucket di backend Cloud Storage dietro il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico. Utilizza le norme di sicurezza perimetrale per filtrare le richieste prima che i contenuti vengano pubblicati dalla cache.
Policy di sicurezza del backend
Quando i criteri di sicurezza del backend di Cloud Armor vengono applicati ai servizi di backend con Cloud CDN abilitato, si applicano solo alle richieste instradate al servizio di backend. Queste richieste includono richieste di contenuti dinamici e fallimenti della cache, ovvero richieste che non trovano o bypassano la cache Cloud CDN.
Quando i criteri di sicurezza perimetrale e i criteri di sicurezza del backend sono collegati allo stesso servizio di backend, i criteri di sicurezza del backend vengono applicati solo alle richieste di fallimento della cache che hanno superato i criteri di sicurezza perimetrale.
Il seguente diagramma mostra esclusivamente il funzionamento dei criteri di sicurezza del backend con le origini Cloud CDN, dopo che le richieste sono state consentite dai criteri di sicurezza dell'edge.
Per ulteriori informazioni su Cloud CDN, consulta la documentazione di Cloud CDN.
Cloud Armor con Cloud Run, App Engine o Cloud Run Functions
Puoi utilizzare i criteri di sicurezza Cloud Armor con un backend NEG serverless che punta a un servizio Cloud Run, App Engine o Cloud Run Functions.
Tuttavia, quando utilizzi Cloud Armor con NEG serverless, Cloud Run o Cloud Run Functions, tutto l'accesso all'endpoint serverless deve essere filtrato tramite un criterio di sicurezza Cloud Armor.
Gli utenti che hanno l'URL predefinito per un'applicazione serverless possono bypassare il load balancer e andare direttamente all'URL del servizio. In questo modo vengono ignorati i criteri di sicurezza di Cloud Armor. Per risolvere il problema, disattiva l'URL predefinito che Google Cloud viene assegnato automaticamente ai servizi Cloud Run o alle funzioni Cloud Run (2ª generazione.). Per proteggere le applicazioni App Engine, puoi utilizzare i controlli di ingresso.
Se utilizzi i controlli di traffico in entrata per applicare i controlli dell'accesso a tutto il traffico in entrata, puoi utilizzare l'impostazione di traffico in entrata internal-and-gclb
quando configuri Cloud Run Functions o Cloud Run.
L'impostazione di ingresso internal-and-gclb
consente solo il traffico interno e
il traffico inviato a un indirizzo IP esterno esposto dal
bilanciatore del carico delle applicazioni esterno globale o dal bilanciatore del carico delle applicazioni classico. Il traffico inviato a questi URL predefiniti dall'esterno della tua rete privata viene bloccato.
In questo modo, gli utenti non possono aggirare i controlli dell'accesso (ad esempio i criteri di sicurezza di Cloud Armor) configurati tramite il bilanciatore del carico delle applicazioni esterno globale o il bilanciatore del carico delle applicazioni classico.
Per saperne di più sui NEG serverless, consulta Panoramica dei gruppi di endpoint di rete serverless e Configurazione di NEG serverless.
Cloud Armor con Cloud Service Mesh
Puoi configurare i criteri di sicurezza del servizio interno per il mesh di servizi in modo da applicare limitazione di frequenza lato server globale per client, in modo da condividere equamente la capacità disponibile del servizio e ridurre il rischio che client dannosi o con un comportamento anomalo sovraccarichino i servizi. Colleghi un criterio di sicurezza a un criterio endpoint Cloud Service Mesh per applicare la limitazione di frequenza al traffico in entrata sul lato server. Tuttavia, non puoi configurare una policy di sicurezza Google Cloud Armor se utilizzi il routing del traffico TCP. Per saperne di più sull'utilizzo di Cloud Armor con Cloud Service Mesh, consulta Configurare la limitazione di frequenza con Cloud Armor.
Passaggi successivi
- Configurare criteri, regole ed espressioni di sicurezza
- Scopri le funzionalità dei livelli di Cloud Armor Enterprise
- Risolvere i problemi