Integrazione di Cloud Armor con altri prodotti Google

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:

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.

Utilizzo del criterio di sicurezza di Cloud Armor con i firewall in entrata
       per limitare l'accesso.
Utilizzo di criteri di sicurezza Cloud Armor con firewall in entrata per limitare l'accesso (fai clic per ingrandire).

Il diagramma precedente mostra la seguente configurazione di deployment:

  1. Crea due gruppi di istanze, uno nella regione us-west1 e l'altro nella regione europe-west1.
  2. Esegui il deployment delle istanze dell'applicazione di backend sulle VM nei gruppi di istanze.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Utilizzo di liste bloccate e consentite di indirizzi IP con IAP.
Utilizzo di liste bloccate e consentite di indirizzi IP con IAP (fai clic per ingrandire).

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.

Cloud Armor per i deployment ibridi.
Cloud Armor per i deployment ibridi (fai clic per ingrandire).

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.

Utilizzo delle policy di sicurezza del backend Cloud Armor con Cloud CDN.
Utilizzo dei criteri di sicurezza di backend di Cloud Armor con Cloud CDN (fai clic per ingrandire).

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