Best practice per la sicurezza di Cloud Service Mesh

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

Il pubblico di destinazione di questo documento include gli amministratori che gestiscono i criteri in un Cloud Service Mesh e gli utenti che eseguono servizi in un 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 difendere i servizi in modo unificato. Adotta un approccio incentrato sulle applicazioni e utilizza identità delle 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, il che consente di disaccoppiare il lavoro dei team responsabili della pubblicazione e del rilascio delle funzionalità dell'applicazione dalle responsabilità degli amministratori responsabili della sicurezza e del networking.

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 una mesh. Vengono scelte le impostazioni predefinite di Cloud Service Mesh ma in alcuni casi potrebbe essere necessario configurazioni personalizzate o di concedere eccezioni escludendo determinate app, porte o indirizzi IP che partecipano 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 assume che le minacce alla sicurezza provengano sia dall'interno che dall'esterno del perimetro di sicurezza di un'organizzazione. Esempi di tipi di attacchi alla sicurezza che possono le applicazioni in un mesh di servizi includono:

  • Attacchi di esfiltrazione di dati. Ad esempio, attacchi che intercettano dati sensibili o credenziali dal traffico tra servizi.
  • Attacchi man in the middle. Ad esempio, un servizio dannoso che maschera la maschera come servizio legittimo per ottenere o modificare la comunicazione tra i servizi di machine learning.
  • 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 avviarli ad altri servizi.

Gli attacchi possono essere classificati anche in base ai target:

  • Attacchi di rete interna mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione service-to-service o service-to-control-plane interna del mesh.
  • Attacchi al piano di controllo. Attacchi volti a causare il malfunzionamento del piano di controllo (ad esempio un attacco DoS) o a esfiltrare dati sensibili dal piano di controllo.
  • Attacchi a spillo della rete mesh. Attacchi finalizzati a manomissioni, intercettazioni o spoofing le comunicazioni alla rete mesh in entrata o in uscita.
  • Attacchi alle operazioni del mesh. Attacchi mirati alle operazioni del mesh. Gli aggressori potrebbero cercano di ottenere privilegi elevati per condurre operazioni dannose in un mesh, come la modifica dei criteri di sicurezza e delle immagini dei carichi di lavoro.

Rischi per la sicurezza

Oltre agli attacchi alla sicurezza, una rete mesh presenta anche altri rischi per la sicurezza. L'elenco seguente descrive alcuni possibili rischi per la sicurezza:

  • Protezione della sicurezza incompleta. Non è stato configurato un mesh di servizi con criteri di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, non sono definiti criteri di autenticazione o autorizzazione per i servizi in un mesh.
  • Eccezioni ai criteri di sicurezza. Per venire incontro ai loro casi d'uso specifici, possono creare eccezioni alle norme di sicurezza per determinati tipi di traffico (interni esterne) per essere escluse dai criteri di sicurezza di Cloud Service Mesh. A gestire questi casi in modo sicuro, consulta la sezione Gestire in modo sicuro le eccezioni ai criteri.
  • Trascurato gli upgrade delle immagini. Potrebbero essere scoperte le vulnerabilità delle immagini utilizzata in una mesh. Devi mantenere aggiornate le immagini del componente mesh e del carico di lavoro con le correzioni di vulnerabilità più recenti.
  • Mancanza di manutenzione (nessuna competenza o risorsa). Il software e le configurazioni dei criteri della rete mesh richiedono una manutenzione regolare per sfruttare i meccanismi di protezione della sicurezza più recenti.
  • Mancanza di visibilità. Errori di configurazione o configurazioni non sicure del mesh del traffico e le operazioni/attività di rete mesh anormali non vengono l'attenzione degli amministratori della rete mesh.
  • Spostamento della configurazione. La configurazione dei criteri in una mesh si discosta dalla fonte attendibile.

Misure per proteggere un mesh di servizi

Questa sezione presenta un manuale operativo per la protezione dei mesh di servizi.

Architettura di sicurezza

La sicurezza di un mesh di servizi dipende dalla sicurezza dei componenti diversi livelli del sistema mesh e delle sue applicazioni. La configurazione di alto livello la strategia di sicurezza di Cloud Service Mesh proposto è proteggere una mesh di servizi attraverso l'integrazione di più meccanismi di sicurezza in diversi che insieme garantiscono la sicurezza complessiva del sistema nell'ambito del modello Zero Trust un modello di sicurezza. Il seguente diagramma mostra la postura di sicurezza proposta di Cloud Service Mesh.

la postura di sicurezza di Cloud Service Mesh

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

  • Sicurezza perimetrale del mesh
    • La sicurezza di Cloud Service Mesh Ingress fornisce il controllo dell'accesso per il traffico esterno e protegge l'accesso esterno alle API esposte dai servizi nella rete mesh.
    • La sicurezza in uscita di Cloud Service Mesh regola il traffico in uscita dai carichi di lavoro interni.
    • L'autenticazione utente di Cloud Service Mesh si integra con l'infrastruttura di Google per autenticare le chiamate esterne dai browser web ai servizi che eseguono applicazioni web.
    • La gestione dei certificati dei gateway di Cloud Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati dai gateway di ingresso e di uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • Cloud Armor può difendere da attacchi DDoS (Distributed Denial of Service) esterni e di livello 7. it funge da web application firewall (WAF) per proteggere il mesh di attacchi di rete. Ad esempio, attacchi di esecuzione di codice remoto e di attacco di inserimento.
    • Controlli di servizio VPC e VPC il perimetro della rete mesh tramite i controlli di accesso alla rete privata.
  • Sicurezza del cluster
    • TLS reciproco (mTLS) di Cloud Service Mesh applica l'autenticazione e la crittografia del traffico da carico di lavoro a carico di lavoro.
    • L'autorità di certificazione gestita, come l'autorità di certificazione Cloud Service Mesh e il servizio Certificate Authority, esegue il provisioning e gestisce in modo sicuro i certificati utilizzati dai carichi di lavoro.
    • L'autorizzazione Cloud Service Mesh applica il controllo dell'accesso per i servizi mesh in base alle loro identità e ad altri attributi.
    • Dashboard per la sicurezza di GKE Enterprise monitora le configurazioni dei criteri di sicurezza e i criteri di rete Kubernetes per i carichi di lavoro.
    • Il criterio di rete di Kubernetes applica il controllo dell'accesso ai pod in base all'IP indirizzi IP, etichette pod, spazi dei nomi e altro ancora.
    • La sicurezza del piano di controllo protegge dagli attacchi al piano. Questa protezione impedisce agli utenti malintenzionati di modificare, sfruttare o divulgare i dati di configurazione del servizio e del mesh.
  • Sicurezza dei carichi di lavoro
    • Tieniti al passo con le release di sicurezza di Cloud Service Mesh per assicurarti che i binari di Cloud Service Mesh in esecuzione nel tuo mesh siano privi di vulnerabilità note pubblicamente.
    • Workload Identity Federation for GKE consente ai carichi di lavoro di ottenere le credenziali per chiamare in modo sicuro i servizi Google.
    • CNI (Container Network Interface) di Kubernetes impedisce gli attacchi di escalation dei privilegi eliminando la necessità di un contenitore di inizializzazione Cloud Service Mesh con privilegi.
  • Sicurezza dell'operatore
    • Il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e confina le autorizzazioni degli operatori per mitigare gli attacchi provenienti da operatori malintenzionati o da furti d'identità di operatori.
    • Controller dei criteri di GKE Enterprise convalida e verifica le configurazioni dei criteri nel mesh per evitare configurazioni errate.
    • Autorizzazione binaria di Google Cloud garantisce che le immagini del carico di lavoro nel mesh siano quelle autorizzate dagli amministratori.
    • L'audit logging di Google Cloud controlla le operazioni del mesh.

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

flusso di traffico del diagramma di sicurezza

Sicurezza del cluster

Attiva TLS reciproco rigoroso

Un attacco man in the middle (MitM) tenta di inserire un'entità dannosa tra due parti in comunicazione per intercettare o manipolare la comunicazione. Cloud Service Mesh si difende dagli attacchi MitM ed esfiltrazione di dati applicazione forzata Autenticazione e crittografia mTLS per tutte le parti comunicative. La modalità permissiva utilizza mTLS se entrambe le parti lo supportano, ma consente le connessioni senza mTLS. Al contrario, la modalità mTLS restrittiva richiede il traffico deve essere criptato e autenticato con mTLS e non consente il testo normale per via del traffico.

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

Per ulteriori informazioni, vedi Cloud Service Mesh ad esempio: mTLS | Applicazione di mTLS a livello di mesh.

Attiva i controlli dell'accesso

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

Il controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato i servizi di machine learning. L'applicazione forzata di mTLS cripta e autentica una richiesta, ma la rete mesh esigenze Criteri di autorizzazione di Cloud Service Mesh per applicare il controllo dell'accesso ai servizi. Ad esempio, il rifiuto di una richiesta non autorizzata proveniente da un client autenticato.

I criteri di autorizzazione di Cloud Service Mesh offrono un modo flessibile per configurare i controlli di accesso in modo da proteggere i tuoi servizi da accessi non autorizzati. I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate derivate dai risultati di autenticazione. Le autenticazioni basate su mTLS o JWT (JSON Web Token) devono essere utilizzate insieme nell'ambito dei criteri di autorizzazione di Cloud Service Mesh.

Applica i criteri di autenticazione di Cloud Service Mesh

JSON Web Token (JWT)

Oltre all'autenticazione mTLS, gli amministratori del mesh possono richiedere un servizio per autenticare e autorizzare le richieste in base al JWT. Cloud Service Mesh non funge da provider JWT, ma autentica i JWT in base agli endpoint del set di chiavi web JSON (JWKS) configurati. 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 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 degli utenti Cloud Service Mesh

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

Applicare i criteri di autorizzazione

Controllo dei criteri di autorizzazione di Cloud Service Mesh:

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

I criteri 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 (livelli 3 e 4) come intervalli IP e porte.

I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle di identità derivate dai risultati dell'autenticazione per difendersi accesso non autorizzato a servizi o dati.

Per impostazione predefinita, l'accesso a un servizio deve essere negato, a meno che non sia definito esplicitamente un criterio di autorizzazione per consentire l'accesso al servizio. Consulta le best practice per i criteri di autorizzazione per esempi di criteri di autorizzazione che rifiutano le richieste di accesso.

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

I criteri di autorizzazione possono essere utilizzati insieme Criteri di rete di Kubernetes, che operano esclusivamente a livello di rete (livello 3 e 4) e che controllano accesso di rete per indirizzi IP e porte sui pod Kubernetes e Kubernetes spazi dei nomi.

Applicare lo scambio di token per accedere ai servizi mesh

Per difendersi dagli attacchi di replay dei token che rubano i token e li riutilizzano per accedere ai servizi del mesh, un token in una richiesta dall'esterno del mesh deve essere scambiato con un token interno al mesh di breve durata all'estremità del mesh.

Una richiesta 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 esterno alla mesh potrebbe essere di lunga durata. Per difendersi dagli attacchi di ripetizione dei token, un token esterno al mesh deve essere scambiato con un token interno al mesh di breve durata con un ambito limitato all'ingresso del 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