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 microsegmentazione che utilizza regole basate su IP è stata utilizzata per mitigare i rischi legati agli addetti ai lavori. Tuttavia, l'adozione di container, servizi condivisi e ambienti di produzione distribuiti su più cloud rende questo approccio più difficile da configurare e ancora più difficile da gestire.

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

TLS reciproco

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

mTLS consente ai carichi di lavoro di verificare le reciproche identità e di autenticarsi tra loro. Potresti conoscere il TLS semplice per il suo utilizzo in HTTPS per consentire ai browser di considerare attendibili i server web e di criptare i dati scambiati. Quando viene utilizzato TLS semplice, il client stabilisce che il server può essere considerato attendibile convalidandone il certificato. mTLS è un'implementazione di TLS in cui sia il client che il server si presentano reciprocamente i certificati e verificano le rispettive identità.

mTLS è il mezzo con cui 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 l'auto mTLS, un proxy sidecar client rileva automaticamente se il server ha un sidecar. Il lato client invia mTLS ai carichi di lavoro con file collaterali e invia testo normale ai carichi di lavoro senza file collaterali. Tieni presente, tuttavia, che i servizi accettano sia il traffico in testo normale sia il traffico mTLS. Per proteggere il tuo service mesh, ti consigliamo di eseguire la migrazione dei servizi in modo che accettino solo il traffico mTLS.

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

Configurazione della suite di crittografia

Il seguente elenco include la crittografia predefinita conforme a FIPS di Cloud Service Mesh suite:

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

Per una maggiore sicurezza, la versione TLS minima lato server supportata dai carichi di lavoro Cloud Service Mesh è 1.2, che supporta la personalizzazione dei pacchetti di crittografia. Tieni presente che Cloud Service Mesh supporta anche TLS 1.3, che codifica in modo rigido le suite di crittografia e non supporta la loro modifica.

Per ulteriori informazioni sulle suite di crittografia, consulta la configurazione TLS comune di Envoy e l'autenticazione TLS reciproca di Istio.

Vantaggi per la sicurezza

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

  • Mitiga il rischio di attacchi di replay o di furto d'identità che utilizzano le credenziali rubate. Cloud Service Mesh si basa sui certificati mTLS per l'autenticazione peer, anziché token di connessione come JSON Web Tokens (JWT). Poiché i certificati mTLS sono associati al canale TLS, non è possibile per un'entità all'interno del tuo ambiente di produzione rubare l'identità di un'altra semplicemente riproducendo il token di autenticazione senza accedere alle chiavi private.

  • Garantisce la crittografia in transito. L'utilizzo di mTLS per l'autenticazione garantisce inoltre che tutte le comunicazioni TCP siano criptate 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 posizione di rete del client e dalle credenziali a livello di applicazione. Puoi specificare che solo i clienti con servizio autorizzato di identità o negli spazi dei nomi Kubernetes autorizzati. 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 rete di produzione. Tu garantire che gli addetti ai lavori possano accedere ai dati sensibili solo tramite clienti. Inoltre, puoi assicurarti che determinati client possano accedere ai dati utente solo se possono presentare un token utente valido e di breve durata. In questo modo si attenua il rischio che la compromissione di una singola credenziale del cliente consenta a un malintenzionato di accedere 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 avuto accesso a un servizio anche se è temporaneo e di cui è stato eseguito il deployment in modo dinamico, nonché in un cluster o una rete Virtual Private Cloud (VPC) diversa.

Funzionalità

Questa sezione descrive le funzionalità che Cloud Service Mesh fornisce per realizzare e i suoi vantaggi in termini di sicurezza.

Rotazione automatica del certificato e della chiave

L'uso di mTLS basato sulle identità di servizio consente di criptare tutti i TCP comunicazioni e fornisce una credenziale più sicura e non riproducibile per l'accesso controllo. Una delle principali sfide dell'uso di mTLS su larga scala è la gestione delle chiavi e certificati per tutti i carichi di lavoro di destinazione. Cloud Service Mesh si occupa di ruotare Chiavi e certificati mTLS per i carichi di lavoro di GKE Enterprise senza interruzioni le comunicazioni. È possibile configurare intervalli di aggiornamento dei certificati più brevi per ridurre i rischi.

L'autorità di certificazione Cloud Service Mesh

Cloud Service Mesh include un certificato privato gestito per più regioni l'autorità di certificazione Cloud Service Mesh, per il rilascio di certificati per mTLS. L'autorità di certificazione Cloud Service Mesh è un servizio altamente affidabile e scalabile ottimizzato per i 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 dell'autorità di certificazione. L'autorità di certificazione Cloud Service Mesh ti consente di fare affidamento su un'unica radice di attendibilità nei cluster GKE Enterprise. Quando utilizzi l'autorità di certificazione Cloud Service Mesh, puoi fare affidamento sui pool di identità di carico di lavoro per fornire un isolamento a livello granulare. Di predefinita, l'autenticazione non riesce se il client e il server non sono nello stesso pool di identità per i carichi di lavoro.

I certificati emessi dall'autorità di certificazione Cloud Service Mesh includono i seguenti dati su dei servizi della tua applicazione:

  • L'ID 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 utilizzare Certificate Authority Service, che è adatto per i seguenti casi d'uso:

  • Se sono necessarie autorità di certificazione diverse su cui firmare i certificati dei carichi di lavoro in diversi cluster.
  • 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 CA Cloud Service Mesh a un certificato radice aziendale personalizzato per firmare i certificati del carico di lavoro.

Il costo dell'autorità di certificazione Cloud Service Mesh è incluso nel prezzo di Cloud Service Mesh. Il servizio CA non è incluso nella configurazione di base Il prezzo di Cloud Service Mesh è addebitato separatamente. Inoltre, CA Service prevede uno SLA (accordo sul livello del servizio) esplicito, al contrario dell'autorità di certificazione 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 rispetto all'indirizzo IP del peer. In questo modo, puoi creare criteri indipendenti dalla posizione di rete del carico di lavoro. Al momento sono disponibili solo le comunicazioni tra i cluster nello stesso progetto Google Cloud supportati.

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

Oltre all'identità mTLS, puoi concedere l'accesso in base alle attestazioni della richiesta nell'intestazione JWT delle richieste HTTP o gRPC. Cloud Service Mesh ti consente di dichiarare che un JWT sia firmato da un'entità attendibile. Ciò significa che puoi configurare Criteri che consentono l'accesso da determinati client solo in caso di rivendicazione di una richiesta 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 di ingresso Cloud Service Mesh utilizzando Identity-Aware Proxy (IAP). IAP può autenticare gli utenti che accedono da un browser, integrarsi con provider di identità personalizzati e emettere un token JWT di breve durata o un token RC che può essere utilizzato per concedere l'accesso al gateway di ingresso o a un servizio a valle (utilizzando un sidecar). Per ulteriori informazioni, vedi 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 autenticazione e controllo dell'accesso degli utenti finali basati su browser ai carichi di lavoro di cui è stato eseguito il deployment. Per ulteriori informazioni, consulta Configurare l'autenticazione utente di Cloud Service Mesh.

Accesso a logging e monitoraggio

Cloud Service Mesh garantisce che le metriche e i log di accesso siano disponibili 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. Tu puoi anche scegliere di configurare una destinazione privata. Cloud Service Mesh consente di ridurre il rumore nei log di accesso registrando solo gli accessi riusciti una volta in una finestra temporale configurabile. Richieste rifiutate da un criterio di sicurezza o dei risultati in un errore vengono sempre registrati. In questo modo, puoi ridurre notevolmente i costi associati all'importazione, allo stoccaggio e all'elaborazione dei log, senza perdere gli indicatori di sicurezza chiave.

Conforme a FIPS

Tutti i componenti del control plane in-cluster e i proxy 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 utente che utilizza IAP richiede che un servizio sia pubblicato su internet. IAP e Cloud Service Mesh ti consentono di configurare criteri che possono limitare l'accesso a utenti e client autorizzati in un intervallo IP consentito. Se scegli di esporre il servizio solo ai client all'interno della stessa rete, devi configurare un motore di criteri personalizzato per l'autenticazione degli utenti e l'emissione di token.

Passaggi successivi