Best practice per la sicurezza di Cloud Service Mesh

Questo documento descrive le best practice per stabilire e gestire una configurazione sicura di Cloud Service Mesh in esecuzione su Google Kubernetes Engine (GKE). Le indicazioni contenute nel documento vanno oltre le impostazioni utilizzate per configurare e installare Cloud Service Mesh e descrivono come utilizzare Cloud Service Mesh con altri Google Cloud prodotti e funzionalità per proteggere dalle minacce alla sicurezza che le applicazioni in un mesh potrebbero affrontare.

Il pubblico di destinazione di questo documento include gli amministratori che gestiscono le policy in Cloud Service Mesh e gli utenti che eseguono i servizi in Cloud Service Mesh. Le misure di sicurezza descritte qui sono utili anche per le organizzazioni che devono migliorare la sicurezza dei propri mesh di servizi per soddisfare i requisiti di conformità.

Il documento è organizzato come segue:

Introduzione

Cloud Service Mesh fornisce funzionalità e strumenti che ti aiutano a osservare, gestire e proteggere i servizi in modo unificato. Adotta un approccio incentrato sulle applicazioni e utilizza identità di applicazioni attendibili anziché un approccio incentrato sull'IP di rete. Puoi eseguire il deployment di un mesh di servizi in modo trasparente senza dover modificare il codice dell'applicazione esistente. Cloud Service Mesh fornisce un controllo dichiarativo sul comportamento della rete, che aiuta a separare il lavoro dei team responsabili della fornitura e del rilascio delle funzionalità dell'applicazione dalle responsabilità degli amministratori responsabili della sicurezza e della rete.

Cloud Service Mesh si basa sul mesh di servizi Istio open source , che consente configurazioni e topologie sofisticate. A seconda della struttura della tua organizzazione, uno o più team o ruoli potrebbero essere responsabili dell'installazione e della configurazione di un mesh. Le impostazioni predefinite di Cloud Service Mesh vengono scelte per proteggere le applicazioni, ma in alcuni casi potrebbe essere necessario utilizzare configurazioni personalizzate o concedere eccezioni escludendo determinate app, porte o indirizzi IP dalla partecipazione a un mesh. È importante disporre di controlli per gestire le configurazioni mesh e le eccezioni di sicurezza.

Vettori di attacco e rischi per la sicurezza

Vettori di attacco

La sicurezza di Cloud Service Mesh segue il modello di sicurezza Zero Trust, che presuppone che le minacce alla sicurezza provengano sia dall'interno che dall'esterno del perimetro di sicurezza di un'organizzazione. Di seguito sono riportati alcuni esempi di tipi di attacchi alla sicurezza che potrebbero minacciare le applicazioni in un mesh di servizi:

  • Attacchi di esfiltrazione di dati. Ad esempio, attacchi che intercettano dati o credenziali sensibili dal traffico da servizio a servizio.
  • Attacchi man in the middle. Ad esempio, un servizio dannoso che si spaccia per un servizio legittimo per ottenere o modificare la comunicazione tra i servizi.
  • Attacchi di escalation dei privilegi. Ad esempio, attacchi che utilizzano l'accesso illecito a privilegi elevati per eseguire operazioni in una rete.
  • Attacchi Denial of Service (DoS).
  • Attacchi botnet che tentano di compromettere e manipolare i servizi per lanciare attacchi ad altri servizi.

Gli attacchi possono anche essere classificati in base ai target di attacco:

  • Attacchi alla rete interna del mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione interna da servizio a servizio o da servizio a control plane del mesh.
  • Attacchi al control plane. Attacchi volti a causare il malfunzionamento del control plane (ad esempio un attacco DoS) o a esfiltrare dati sensibili dal control plane.
  • Attacchi perimetrali del mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione in entrata o in uscita dal mesh.
  • Attacchi alle operazioni mesh. Attacchi volti alle operazioni mesh. Gli aggressori potrebbero tentare di ottenere privilegi elevati per eseguire operazioni dannose in un mesh, ad esempio modificare le policy di sicurezza e le immagini dei workload.

Rischi per la sicurezza

Oltre agli attacchi alla sicurezza, un mesh deve affrontare anche altri rischi per la sicurezza. Il seguente elenco descrive alcuni possibili rischi per la sicurezza:

  • Protezione di sicurezza incompleta. Un mesh di servizi non è stato configurato con policy di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, non sono state definite policy di autenticazione o autorizzazione per i servizi in un mesh.
  • Eccezioni alle policy di sicurezza. Per soddisfare i loro casi d'uso specifici, gli utenti possono creare eccezioni alle policy di sicurezza per escludere determinati traffici (interni o esterni) dalle policy di sicurezza di Cloud Service Mesh. Per gestire in modo sicuro questi casi, consulta la sezione Gestire in modo sicuro le eccezioni alle policy.
  • Trascurare gli upgrade delle immagini. Potrebbero essere rilevate vulnerabilità per le immagini utilizzate in un mesh. Devi mantenere aggiornate le immagini dei componenti mesh e dei workload con le ultime correzioni delle vulnerabilità.
  • Mancanza di manutenzione (nessuna competenza o risorsa). Il software mesh e le configurazioni delle policy richiedono una manutenzione regolare per sfruttare i meccanismi di protezione della sicurezza più recenti.
  • Mancanza di visibilità. Le configurazioni errate o non sicure delle policy mesh e il traffico/le operazioni mesh anomali non vengono portati all'attenzione degli amministratori mesh.
  • Deriva della configurazione. La configurazione delle policy in un mesh si discosta dalla fonte di verità.

Misure per proteggere un mesh di servizi

Questa sezione presenta un manuale operativo per proteggere i mesh di servizi.

Architettura di sicurezza

La sicurezza di un mesh di servizi dipende dalla sicurezza dei componenti nei diversi livelli del sistema mesh e delle relative applicazioni. L'intenzione di alto livello della strategia di sicurezza di Cloud Service Mesh proposta è quella di proteggere un mesh di servizi integrando più meccanismi di sicurezza a diversi livelli, che insieme raggiungono la sicurezza complessiva del sistema nel modello di sicurezza Zero Trust. Il seguente diagramma mostra la strategia di sicurezza di Cloud Service Mesh proposta.

postura di sicurezza di Cloud Service Mesh

Cloud Service Mesh fornisce sicurezza a più livelli, tra cui:

  • Sicurezza perimetrale del mesh
    • La sicurezza in entrata di Cloud Service Mesh fornisce il controllo dell'accesso per il traffico esterno e protegge l'accesso esterno alle API esposte dai servizi nel mesh.
    • La sicurezza in uscita di Cloud Service Mesh regola il traffico in uscita dai workload interni.
    • L'autenticazione utente di Cloud Service Mesh si integra con l'infrastruttura Google per autenticare le chiamate esterne dai browser web ai servizi che eseguono applicazioni web.
    • La gestione dei certificati del gateway di Cloud Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati dai gateway in entrata e in uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • Cloud Armor può difendersi dagli attacchi Distributed Denial of Service (DDoS) esterni e di livello 7. Funge da Web Application Firewall (WAF) per proteggere il mesh dagli attacchi alla rete. Ad esempio, attacchi di iniezione ed esecuzione di codice da remoto.
    • VPC e Controlli di servizio VPC proteggono il perimetro del mesh tramite i controlli di accesso alla rete privata.
  • Sicurezza del cluster
    • Mutual TLS (mTLS) di Cloud Service Mesh applica la crittografia e l'autenticazione del traffico da workload a workload.
    • Le CA gestite, come l'autorità di certificazione Cloud Service Mesh e Certificate Authority Service, eseguono il provisioning e la gestione sicuri dei certificati utilizzati dai workload.
    • L'autorizzazione di Cloud Service Mesh applica il controllo dell'accesso per i servizi mesh in base alle loro identità e ad altri attributi.
    • La dashboard per la sicurezza di GKE Enterprise fornisce il monitoraggio delle configurazioni delle policy di sicurezza e delle policy di rete di Kubernetes per i workload.
    • Il criterio di rete di Kubernetes applica il controllo dell'accesso ai pod in base a indirizzi IP, etichette dei pod, spazi dei nomi e altro ancora.
    • La sicurezza del control plane protegge dagli attacchi al control plane. Questa protezione impedisce agli aggressori di modificare, sfruttare o divulgare i dati di configurazione del servizio e del mesh.
  • Sicurezza dei workload
    • Mantieni aggiornate le release di sicurezza di Cloud Service Mesh per assicurarti che i file binari di Cloud Service Mesh in esecuzione nel mesh non contengano vulnerabilità note pubblicamente.
    • Workload Identity Federation for GKE consente ai workload di ottenere le credenziali per chiamare in modo sicuro i servizi Google.
    • Kubernetes CNI (Container Network Interface) impedisce gli attacchi di escalation dei privilegi eliminando la necessità di un container init con privilegi di Cloud Service Mesh.
  • Sicurezza dell'operatore
    • Il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e limita le autorizzazioni dell'operatore per mitigare gli attacchi provenienti da operatori dannosi o l'impersonificazione dell'operatore.
    • Policy Controller di GKE Enterprise convalida ed esegue l'audit delle configurazioni delle policy nel mesh per evitare configurazioni errate.
    • Google Cloud L'autorizzazione binaria garantisce che le immagini dei workload nel mesh siano quelle autorizzate da gli amministratori.
    • Google Cloud L'audit logging esegue l'audit delle operazioni mesh.

Il diagramma seguente mostra i flussi di comunicazione e configurazione con le soluzioni di sicurezza integrate in Cloud Service Mesh.

diagramma di sicurezza del flusso di traffico

Sicurezza del cluster

Abilita mutual TLS restrittivo

Un attacco man in the middle (MitM) tenta di inserire un'entità dannosa tra due parti comunicanti per intercettare o manipolare la comunicazione. Cloud Service Mesh si difende dagli attacchi MitM e di esfiltrazione di dati applicando l'autenticazione e la crittografia mTLS per tutte le parti comunicanti. La modalità permissiva utilizza mTLS quando entrambe le parti lo supportano, ma consente le connessioni senza mTLS. Al contrario, mTLS restrittivo richiede che il traffico sia criptato e autenticato con mTLS e non consente il traffico in testo normale.

Cloud Service Mesh consente di configurare la versione TLS minima per le connessioni TLS tra i workload per soddisfare i requisiti di sicurezza e conformità.

Per saperne di più, consulta Cloud Service Mesh tramite esempi: mTLS | Applicazione di mTLS a livello di mesh.

Abilita i controlli di accesso

Le policy di sicurezza di Cloud Service Mesh (come le policy di autenticazione e autorizzazione) devono essere applicate a tutto il traffico in entrata e in uscita dal mesh, a meno che non vi siano giustificazioni valide per escludere un servizio o un pod dalle policy di sicurezza di Cloud Service Mesh. In alcuni casi, gli utenti potrebbero avere motivi legittimi per bypassare le policy di sicurezza di Cloud Service Mesh per alcune porte e intervalli IP. Ad esempio, per stabilire connessioni native con servizi non gestiti da Cloud Service Mesh. Per proteggere Cloud Service Mesh in questi casi d'uso, consulta Gestire in modo sicuro le eccezioni alle policy di Cloud Service Mesh.

Il controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato ai servizi. L'applicazione di mTLS cripta e autentica una richiesta, ma un mesh ha comunque bisogno delle policy di autorizzazione di Cloud Service Mesh per applicare il controllo dell'accesso ai servizi. Ad esempio, rifiutare una richiesta non autorizzata proveniente da un client autenticato.

Le policy di autorizzazione di Cloud Service Mesh forniscono un modo flessibile per configurare i controlli di accesso per proteggere i servizi dall'accesso non autorizzato. Le policy di autorizzazione di Cloud Service Mesh devono essere applicate in base alle identità autenticate derivate dai risultati dell'autenticazione: le autenticazioni basate su mTLS o JSON Web Token (JWT) devono essere utilizzate insieme come parte delle policy di autorizzazione di Cloud Service Mesh.

Applica le policy di autenticazione di Cloud Service Mesh

JSON Web Token (JWT)

Oltre all'autenticazione mTLS, gli amministratori mesh possono richiedere a un servizio di autenticare e autorizzare le richieste in base a JWT. Cloud Service Mesh non funge da provider JWT, ma autentica i JWT in base agli endpoint JWKS (JSON Web Key Set) configurati. L'autenticazione JWT può essere applicata ai gateway in entrata per il traffico esterno o ai servizi interni per il traffico in-mesh. L'autenticazione JWT può essere combinata con l'autenticazione mTLS quando un JWT viene utilizzato come credenziale per rappresentare il chiamante finale e il servizio richiesto richiede la prova che venga chiamato per conto del chiamante finale. L'applicazione dell'autenticazione JWT protegge dagli attacchi che accedono a un servizio senza credenziali valide e per conto di un utente finale reale.

Autenticazione utente di Cloud Service Mesh

L'autenticazione utente di Cloud Service Mesh è una soluzione integrata per l'autenticazione e il controllo dell'accesso degli utenti finali basati su browser ai workload. Integra un mesh di servizi con i provider di identità (IdP) esistenti per implementare un flusso di accesso e consenso OpenID Connect (OIDC) standard basato sul web e utilizza le policy di autorizzazione di Cloud Service Mesh per il controllo dell'accesso.

Applica le policy di autorizzazione

Le policy di autorizzazione di Cloud Service Mesh controllano:

  • Chi o cosa è autorizzato ad accedere a un servizio.
  • A quali risorse è possibile accedere.
  • Quali operazioni possono essere eseguite sulle risorse consentite.

Le policy di autorizzazione sono un modo versatile per configurare il controllo dell'accesso in base alle identità effettive con cui vengono eseguiti i servizi, alle proprietà del livello di applicazione (livello 7) del traffico (ad esempio le intestazioni delle richieste) e alle proprietà del livello di rete (livello 3 e livello 4) come intervalli IP e porte.

Le policy di autorizzazione di Cloud Service Mesh devono essere applicate in base alle identità autenticate derivate dai risultati dell'autenticazione per proteggere dall'accesso non autorizzato a servizi o dati.

Per impostazione predefinita, l'accesso a un servizio deve essere negato a meno che non sia definita esplicitamente una policy di autorizzazione per consentire l'accesso al servizio. Consulta Best practice per le policy di autorizzazione per esempi di policy di autorizzazione che negano le richieste di accesso.

Le policy di autorizzazione devono limitare il più possibile l'attendibilità. Ad esempio, l'accesso a un servizio può essere definito in base ai singoli percorsi URL esposti da un servizio in modo che solo un servizio A possa accedere al percorso /admin di un servizio B.

Le policy di autorizzazione possono essere utilizzate insieme alle policy di rete di Kubernetes, che operano solo a livello di rete (livello 3 e livello 4) e controllano l' accesso alla rete per indirizzi IP e porte su pod e spazi dei nomi Kubernetes.

Applica lo scambio di token per accedere ai servizi mesh

Per proteggere dagli attacchi di riproduzione dei token che rubano i token e li riutilizzano per accedere ai servizi mesh, un token in una richiesta proveniente dall'esterno del mesh deve essere scambiato con un token interno al mesh di breve durata sul perimetro del mesh.

Una richiesta proveniente dall'esterno del mesh per accedere a un servizio mesh deve includere un token, ad esempio JWT o cookie, per essere autenticata e autorizzata dal servizio mesh. Un token proveniente dall'esterno del mesh potrebbe avere una lunga durata. Per proteggere dagli attacchi di riproduzione dei token, un token proveniente dall'esterno del mesh deve essere scambiato con un token interno al mesh di breve durata con un ambito limitato in entrata nel mesh. Il servizio mesh autentica un token interno al mesh e autorizza la richiesta di accesso in base al token interno al mesh.

Passaggi successivi