Mutual TLS: perché dovrebbe essere utilizzato in Kubernetes

In questo articolo vedremo come Mutual TLS (o mTLS) dovrebbe essere utilizzato per Kubernetes, uno degli strumenti più usati per la gestione delle applicazioni containerizzate. 

Secondo il sondaggio annuale della Cloud Native Computing Foundation relativo al 2021 il 96% degli oltre 2300 intervistati utilizza o sta valutando Kubernetes. Inoltre, il sondaggio ha messo in evidenza come gli utenti Kubernetes siano arrivati a quota 5,6 milioni con un incremento del 70% rispetto al 2020. 

Dati significativi, che fanno di Kubernetes uno dei bersagli più ambiti di moltissimi cybercriminali. In un recente  sondaggio di Veritas Technologies, il 94% degli intervistati  ha espresso preoccupazione per gli attacchi ransomware agli ambienti Kubernetes e il 56% ne ha già subito almeno uno. 

Sfortunatamente, molte aziende si stanno affrettando con le implementazioni di Kubernetes prima di comprendere appieno tutti i problemi di sicurezza che possono interessarle. 

Ci sono molte buone pratiche che queste organizzazioni possono implementare per proteggere i propri carichi di lavoro. Una delle migliori, consigliata dalla stessa Kubernetes è l’utilizzo di Transport Layer Security (TLS), che aiuta a prevenire lo sniffing del traffico in una connessione, verificando il server e crittografando il traffico tra il client e il server.

Un’opzione ancora migliore, che gli sviluppatori dovrebbero applicare ovunque sia possibile, è il cosiddetto mutual TLS  (mTLS). In questo articolo del nostro blog vedremo i vantaggi di mutual TLS e come gli sviluppatori possono utilizzarlo per proteggersi da eventuali attacchi.

Mutual TLS porta Transport Layer Security al livello maggiore di sicurezza, autenticando entrambi i lati della connessione client-server prima di avviare una comunicazione. Può sembrare un approccio basato sul buon senso, ma ci sono molte situazioni in cui l’identità del cliente è irrilevante per la connessione.

Quando conta solo l’identità del server, il TLS è l’approccio più efficiente. TLS utilizza la crittografia a chiave pubblica, che richiede una coppia di chiavi privata e pubblica per le comunicazioni crittografate. 

Per verificare l’identità del server, il client invia un messaggio crittografato utilizzando la chiave pubblica (ottenuta dal certificato TLS del server) al server. Solo un server in possesso della chiave privata corretta può decriptare il messaggio e quindi autenticarsi.  

Per avere l’autenticazione bidirezionale sarebbe necessario che tutti i client dispongano anche di certificati TLS, che provengono da un’autorità di certificazione (CA). A causa dell’enorme numero di potenziali client (ad esempio browser che navigano e accedono a siti internet), generare e gestire così tanti certificati digitali sarebbe estremamente complesso.

Tuttavia, per alcune applicazioni e servizi, l’utilizzo di mutual TLS è caldamente consigliato se non imprescindibile. Mutual TLS, infatti, aggiunge un’autenticazione separata del client dopo la verifica del server. Solo dopo aver verificato entrambe le parti della connessione le due possono comunicare e scambiarsi informazioni. Attraverso mTLS, il server sa che una fonte attendibile sta tentando di accedervi.

Mutual TLS è utile per prevenire un’ampia casistica di attacchi Tra i principali che mutual TLS può respingere abbiamo:

• Attacchi brute force: anche se gli hacker possono utilizzare questo metodo per compromettere le credenziali degli utenti, non possono invadere le connessioni protette con mutual TLS.
• Tentativi di phishing: gli hacker possono compromettere le credenziali, tuttavia, non possono utilizzarle per accedere ai server, poichè non dispongono del certificato TLS necessario e della chiave privata associata per una connessione protetta mutual TLS. I dati e i sistemi sensibili rimangono così al sicuro.
• Richieste API dannose: molti cybercriminali tentano di utilizzare le chiamate API per danneggiare i sistemi aziendali. Le chiamate API dannose possono essere un vettore efficace per iniettare malware, ransomware o persino avviare attacchi DDoS. Ma se la connessione API richiede l’autenticazione reciproca mTLS, gli aggressori avranno maggiori difficoltà a ottenere l’accesso.
• Attacchi Man-in-the-middle: in un attacco di questo tipo, l’hacker si frappone tra il server e il client, intercettando o addirittura alterando il flusso comunicativo tra i due. Sebbene TLS fornisca una certa sicurezza contro gli attacchi MitM, spesso non riesce a scongiurarli. Mutual TLS, al contrario, aggiunge un ulteriore livello di autenticazione che complica ulteriormente gli sforzi degli aggressori e riduce ulteriormente le loro possibilità di successo.

Con Kubernetes, sono molti i percorsi di comunicazione che possono trarre vantaggio da mutual TLS, in particolare, le comunicazioni tra microservizi e le comunicazioni tra microservizi e server API. L’utilizzo di mTLS, infatti, è in grado di proteggere questo tipo di comunicazioni senza la necessità di alcun processo di verifica o gestione dell’identità specifico a livello di applicazione.

Le applicazioni containerizzate possono includere molti microservizi diversi che scambiano dati, inclusi i dati sensibili dei clienti. Mutual TLS impedisce ai cybercriminali di intercettare queste comunicazioni e di violare questi dati.

Sebbene l’utilizzo di mutual TLS nel tuo ambiente Kubernetes possa garantire una maggiore sicurezza, ha un costo, che deriva dalla necessità di un efficace sistema di fornitura e gestione dei certificati digitali.

Quando mutual TLS viene utilizzato in una distribuzione di container Kubernetes, ricorda che molti client sono servizi individuali. Ognuno di questi servizi avrà bisogno del proprio certificato TLS e ce ne saranno molti.

Inoltre, i servizi Kubernetes, per loro stessa natura, sono temporanei. Con le repliche dei servizi Kubernetes create e distrutte in modo dinamico, la sfida della gestione dei certificati TLS può essere scoraggiante.

Il tuo sistema di gestione dei certificati digitali deve anche essere sufficientemente potente da gestire il de-provisioning e il re-provisioning dei certificati in base alle tue politiche di sicurezza interne. Se, come molti, fai affidamento sulla rotazione dei certificati (concedendo ai certificati TLS una durata limitata ed emettendo nuovi certificati alla scadenza) per ridurre al minimo le possibilità che un cybercriminale possa sfruttarli, devi essere in grado di assegnare rapidamente nuovi certificati a tutti i servizi interessati.

Fortunatamente, sono disponibili molti strumenti diversi per aiutarti a gestire facilmente i certificati , anche se hai un numero enorme di certificati per i tuoi servizi Kubernetes. Top SSL, rivenditore ufficiale GlobalSign, offre tutti gli strumenti e i prodotti SSL per le imprese e i privati che vogliono garantire la sicurezza dei propri utenti, rispondere alle minacce e gestire in maniera efficiente i costi relativi alla gestione dei certificati SSL / TLS. Cosa stai aspettando? Inizia oggi stesso, contattaci!