Panoramica della sicurezza di Cloud Service Mesh

La sicurezza di Cloud Service Mesh ti aiuta a mitigare le minacce interne e a ridurre il rischio di una violazione dei dati garantendo che tutte le comunicazioni tra i carichi di lavoro siano criptate, autenticate reciprocamente e autorizzate.

Tradizionalmente, la micro-segmentazione che utilizza regole basate sull'IP è stata utilizzata per mitigare i rischi legati agli addetti ai lavori. Tuttavia, l'adozione di container, servizi condivisi e ambienti di produzione distribuiti distribuiti su più cloud rende questo approccio più difficile da configurare e ancora più difficile da mantenere.

Con Cloud Service Mesh, puoi configurare un livello di servizio sensibile al contesto e richiedere una sicurezza di rete sensibile al contesto indipendente dalla sicurezza della rete sottostante. Per questo motivo, Cloud Service Mesh ti consente di adottare una strategia di difesa in profondità coerente con i principi di sicurezza Zero Trust. Consente di raggiungere questa postura tramite criteri dichiarativi e senza modificare il codice dell'applicazione.

TLS reciproco

Cloud Service Mesh utilizza il protocollo TLS reciproca (mTLS) per l'autenticazione peer. L'autenticazione si riferisce all'identità: chi è questo servizio, chi è questo utente finale? e posso fidarmi del fatto che sono chi dicono di essere.

mTLS consente ai carichi di lavoro di verificare le identità reciproche e autenticarsi reciprocamente. Probabilmente hai familiarità con il protocollo TLS semplice perché viene utilizzato in HTTPS per consentire ai browser di considerare attendibili i server web e criptare i dati scambiati. Quando si utilizza TLS semplice, il client stabilisce che il server può essere considerato attendibile convalidando il relativo certificato. mTLS è un'implementazione di TLS in cui sia il client che il server si presentano a vicenda e verificano le identità degli altri.

mTLS è il mezzo mediante il quale Cloud Service Mesh implementa sia l'autenticazione sia la crittografia tra i servizi.

In Cloud Service Mesh 1.6 e versioni successive, mTLS automatico è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un file collaterale. Il sidecar del client invia mTLS ai carichi di lavoro con file collaterali e invia testo normale ai carichi di lavoro senza file collaterali. Tuttavia, tieni presente che i servizi accettano sia il traffico in testo normale che mTLS. Per proteggere il tuo mesh di servizi, ti consigliamo di eseguire la migrazione dei servizi per accettare solo traffico mTLS.

Per ulteriori informazioni sull'applicazione solo di mTLS, consulta Cloud Service Mesh ad esempio: mTLS.

Configurazione della suite di crittografia

Il seguente elenco include le suite di crittografia predefinite e conformi a FIPS di Cloud Service Mesh:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Per maggiore sicurezza, la versione TLS minima lato server supportata dai carichi di lavoro di Cloud Service Mesh è 1.2, che supporta la personalizzazione delle suite di crittografia. Tieni presente che Cloud Service Mesh supporta anche TLS v1.3, che supporta le suite di crittografia hardcoded e non supporta la modifica.

Per ulteriori informazioni sulle suite di crittografia, vedi Configurazione TLS comune di Envoy e Autenticazione TLS reciproca di Istio.

Vantaggi per la sicurezza

Cloud Service Mesh offre i seguenti vantaggi in termini di sicurezza:

  • Riduce il rischio di attacchi di ripetizione o di impersonificazione che utilizzano credenziali rubate. Cloud Service Mesh si basa su certificati mTLS per autenticare i peer, anziché sui token di connessione come i token web JSON (JWT). Poiché i certificati mTLS sono associati al canale TLS, un'entità all'interno dell'ambiente di produzione non può impersonare un'altra entità semplicemente riproducendo il token di autenticazione senza accesso alle chiavi private.

  • Garantisce la crittografia in transito. L'uso di mTLS per l'autenticazione garantisce anche che tutte le comunicazioni TCP siano crittografate in transito.

  • Garantisce che solo i client autorizzati possano accedere a un servizio con dati sensibili. Solo i client autorizzati possono accedere a un servizio con dati sensibili indipendentemente dalla località di rete del client e dalle credenziali a livello di applicazione. Puoi specificare che solo i client con identità di servizio autorizzate o negli spazi dei nomi Kubernetes autorizzati possono accedere a un servizio. Puoi anche utilizzare i criteri di accesso basati su IP per concedere l'accesso ai client di cui è stato eseguito il deployment al di fuori dell'ambiente GKE Enterprise.

  • Riduce il rischio di violazione dei dati utente all'interno della tua rete di produzione. Puoi garantire che gli addetti ai lavori possano accedere ai dati sensibili solo tramite client autorizzati. Inoltre, puoi garantire che determinati client possano accedere ai dati utente solo se possono presentare un token utente valido e di breve durata. In questo modo si riduce il rischio che la compromissione di una singola credenziale client conceda a un utente malintenzionato l'accesso a tutti i dati utente.

  • Identifica i client che hanno eseguito l'accesso a un servizio con dati sensibili. Il logging degli accessi di Cloud Service Mesh acquisisce l'identità mTLS del client oltre all'indirizzo IP. In questo modo, puoi capire facilmente quale carico di lavoro ha eseguito l'accesso a un servizio anche se il carico di lavoro è temporaneo e viene eseguito in modo dinamico e si trova in un cluster diverso o in una rete Virtual Private Cloud (VPC).

Funzionalità

Questa sezione descrive le funzionalità offerte da Cloud Service Mesh per usufruire dei vantaggi in termini di sicurezza.

Rotazione automatica del certificato e della chiave

L'uso di mTLS basato sulle identità dei servizi consente di criptare tutte le comunicazioni TCP e fornisce una credenziale più sicura non replicabile per il controllo dell'accesso. Una delle principali sfide dell'utilizzo di mTLS su larga scala è la gestione delle chiavi e dei certificati per tutti i carichi di lavoro di destinazione. Cloud Service Mesh si occupa della rotazione delle chiavi e dei certificati mTLS per i carichi di lavoro di GKE Enterprise senza interrompere le comunicazioni. Per ridurre i rischi, è possibile configurare intervalli di aggiornamento dei certificati più piccoli.

Autorità di certificazione Cloud Service Mesh

Cloud Service Mesh include un'autorità di certificazione privata gestita per più regioni, un'autorità di certificazione Cloud Service Mesh, per l'emissione di certificati per mTLS. L'autorità di certificazione Cloud Service Mesh è un servizio altamente affidabile e scalabile, ottimizzato per carichi di lavoro con scalabilità dinamica su una piattaforma cloud. Con l'autorità di certificazione Cloud Service Mesh, Google gestisce la sicurezza e la disponibilità del backend CA. L'autorità di certificazione Cloud Service Mesh ti consente di affidarti a un'unica radice di attendibilità tra i cluster GKE Enterprise. Quando utilizzi l'autorità di certificazione Cloud Service Mesh, puoi fare affidamento sui pool di identità per i carichi di lavoro per fornire un isolamento granulare. Per impostazione predefinita, l'autenticazione non riesce se il client e il server non si trovano nello stesso pool di identità per i carichi di lavoro.

I certificati dell'autorità di certificazione Cloud Service Mesh includono i seguenti dati sui servizi della tua applicazione:

  • ID del progetto Google Cloud
  • Lo spazio dei nomi GKE
  • Il nome dell'account di servizio GKE

Certificate Authority Service

In alternativa all'autorità di certificazione Cloud Service Mesh, puoi configurare Cloud Service Mesh per l'utilizzo di Certificate Authority Service, che è adatto ai seguenti casi d'uso:

  • Se sono necessarie autorità di certificazione diverse per firmare certificati dei carichi di lavoro su cluster diversi.
  • Se vuoi utilizzare i certificati plug-in CA personalizzati Istiod.
  • Se devi eseguire il backup delle chiavi di firma in un HSM gestito.
  • Se operi in un settore altamente regolamentato e sei soggetto a conformità.
  • Se vuoi collegare la tua CA di Cloud Service Mesh a un certificato radice aziendale personalizzato per firmare i certificati dei carichi di lavoro.

Il costo dell'autorità di certificazione Cloud Service Mesh è incluso nei prezzi di Cloud Service Mesh. Il servizio CA non è incluso nel prezzo base di Cloud Service Mesh e viene addebitato separatamente. Inoltre, il servizio CA è dotato di uno SLA esplicito, al contrario dell'autorità di certificazione di Cloud Service Mesh.

Per questa integrazione, a tutti i carichi di lavoro in Cloud Service Mesh vengono concessi due ruoli IAM:

Criteri di controllo dell'accesso sensibile all'identità (firewall)

Con Cloud Service Mesh, puoi configurare criteri di sicurezza di rete basati sull'identità mTLS anziché sull'indirizzo IP del peer. Ciò consente di creare criteri indipendenti dalla località di rete del carico di lavoro. Al momento sono supportate solo le comunicazioni tra cluster nello stesso progetto Google Cloud.

Richiedi criteri di controllo dell'accesso sensibile alle rivendicazioni (firewall)

Oltre all'identità mTLS, puoi concedere l'accesso in base alle attestazioni delle richieste nell'intestazione JWT delle richieste HTTP o gRPC. Cloud Service Mesh ti consente di affermare che un JWT è firmato da un'entità attendibile. Ciò significa che è possibile configurare criteri che consentono l'accesso da determinati client solo se esiste una richiesta di attestazione o corrisponde a un valore specificato.

Autenticazione degli utenti con Identity-Aware Proxy

Puoi autenticare gli utenti che accedono a qualsiasi servizio esposto su un gateway in entrata di Cloud Service Mesh utilizzando Identity-Aware Proxy (IAP). IAP può autenticare gli utenti che accedono da un browser, integrarsi con provider di identità personalizzati ed emettere un token JWT di breve durata o un RCToken che può essere utilizzato per concedere l'accesso al gateway Ingress o a un servizio downstream (utilizzando una side-car). Per ulteriori informazioni, consulta Integrazione di IAP con Cloud Service Mesh.

Autenticazione degli utenti con il provider di identità esistente

Puoi integrare il tuo provider di identità esistente con Cloud Service Mesh per fornire l'autenticazione degli utenti finali basata su browser e controllo dell'accesso ai carichi di lavoro di cui hai eseguito il deployment. Per ulteriori informazioni, consulta Configurare l'autenticazione utente di Cloud Service Mesh.

Logging e monitoraggio degli accessi

Cloud Service Mesh garantisce la disponibilità di log e metriche di accesso in Google Cloud Observability e fornisce una dashboard integrata per comprendere i pattern di accesso per un servizio o un carico di lavoro in base a questi dati. Puoi anche scegliere di configurare una destinazione privata. Cloud Service Mesh consente di ridurre il rumore nei log degli accessi registrando gli accessi riusciti solo una volta in una finestra temporale configurabile. Le richieste rifiutate da un criterio di sicurezza o che generano un errore vengono sempre registrate. Ciò consente di ridurre notevolmente i costi associati all'importazione, all'archiviazione e all'elaborazione dei log, senza perdere i principali indicatori di sicurezza.

Conforme a FIPS

Tutti i componenti e i proxy del piano di controllo nel cluster sull'architettura x86 utilizzano moduli di crittografia convalidati FIPS 140-2.

Limitazioni

La sicurezza di Cloud Service Mesh attualmente presenta le seguenti limitazioni:

  • L'autenticazione degli utenti che utilizza IAP richiede la pubblicazione di un servizio su internet. IAP e Cloud Service Mesh consentono di configurare criteri per limitare l'accesso a utenti e client autorizzati in un intervallo IP consentito. Se scegli di esporre il servizio solo ai client nella stessa rete, devi configurare un motore dei criteri personalizzati per l'autenticazione degli utenti e l'emissione dei token.

Passaggi successivi