Una visione sulla governance delle identità non umane

Può esistere un’identità senza essere referenziata da un’altra identità? Come potremmo saperlo?

Questo potrebbe sembrare un po’ filosofico per un articolo tecnico sulla sicurezza, ma è un punto importante da tenere presente quando si affronta il tema delle identità non umane. Una domanda migliore in ambito di sicurezza sarebbe in realtà, “Dovrebbe esistere un’identità se non può interagire con qualcun altro?” Potremmo non essere in grado di rispondere alla prima domanda, poiché dimostrare la natura della realtà esce un po’ dal campo della scienza informatica. Tuttavia, molte persone hanno lavorato duramente alla creazione degli strumenti di governance NHI per determinare se un’identità di macchina esiste, perché esiste e rispondere alla domanda se dovrebbe esistere. 

Il futuro dell’eliminazione della proliferazione dei segreti significa avere il controllo sui cicli di vita e sulle interdipendenze delle identità non umane che dipendono dai segreti. Ma perché ora? Fermiamoci un attimo e riesaminiamo alcune delle nostre ipotesi sulle NHIs e sulla loro esistenza.

Cosa Sono le Identità Non Umane?

Prima di procedere, definiamo NHI nel contesto di questa conversazione.

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

Questo potrebbe essere un pod Kubernetes che deve interagire con una fonte di dati e inviare i dati elaborati a un sistema di reportistica. Questo potrebbe essere un sensore dell’Internet delle cose (IoT) che invia dati a un server centrale. Questo potrebbe essere un chatbot basato su Slack. Se dopo la creazione iniziale l’entità può svolgere il proprio lavoro senza bisogno di input umano diretto, allora dovremmo considerare quell’identità ‘non umana’.

L’unica cosa che tutti questi esempi hanno in comune è che interagiscono con un altro sistema. Se vogliamo che comunichino con l’intero mondo, è facile, poiché semplicemente puntiamo ad altre identità non umane e descriviamo programmaticamente come dovrebbero interagire. Tuttavia, molto probabilmente vogliamo che questi sistemi comunichino in modo sicuro, autorizzando solo identità specifiche in circostanze specifiche. Questo ha guidato l’evoluzione dei segreti per la gestione degli accessi, da semplici coppie di nome utente/password a chiavi API fino a certificati.

Ammettiamolo, questa è una definizione ampia di NHI. Tuttavia, possiamo restringere ciò che ci interessa riguardo le identità delle macchine facendo un passo indietro e considerando come queste entità si relazionano tra loro attraverso il prisma dei loro segreti, consentendo accesso e comunicazione.

Tutti gli NHI si connettono ad altri sistemi

Puoi costruire un’applicazione autonoma che non riceve input, non produce output e non ha un’interfaccia indirizzabile? Esiste un’applicazione del genere al di fuori di un esperimento mentale? Sebbene sia divertente pensarci, la realtà è che tutti gli NHI che ci interessano esistono per comunicare con altre identità.

Gli NHI richiedono intrinsecamente connessioni ad altri sistemi e servizi per adempiere al loro scopo. Questa interconnettività significa che ogni NHI diventa un nodo in una rete di interdipendenze. Da una prospettiva di governance degli NHI, ciò richiede di mantenere un inventario accurato e dinamico di queste connessioni per gestire i rischi associati. Ad esempio, se un singolo NHI viene compromesso, a cosa si collega e cosa potrebbe accedere un attaccante per spostarsi lateralmente?

Una corretta governance dell’NHI deve includere strumenti per mappare e monitorare queste relazioni. Sebbene ci siano molti modi per farlo manualmente, ciò che vogliamo effettivamente è un modo automatizzato per capire cosa è collegato a cosa, cosa viene utilizzato per cosa e da chi. Quando si tratta di garantire la sicurezza dei nostri sistemi, possiamo sfruttare un altro fatto importante su tutti gli NHI in un’applicazione sicura per costruire quella mappatura, essi, necessariamente, hanno segreti. 

Tutti gli NHI sicuri devono avere un segreto

Per stabilire una comunicazione affidabile tra due NHI, deve esistere un segreto univoco, come una chiave API, un token o un certificato, affinché tali entità possano autenticarsi. Possiamo utilizzare il segreto per dimostrare l’identità di un NHI e mapparlo nell’ecosistema. La domanda diventa: dove cerchiamo questi segreti? 

Nell’azienda moderna, specialmente nelle più grandi, ci sono essenzialmente solo due luoghi in cui un segreto può risiedere. La prima opzione è la pratica migliore e più sicura: un sistema di gestione dei segreti, come Conjur di CyberArk, Vault di HashiCorp o AWS Secrets Manager. L’altra opzione è molto meno sicura ma, sfortunatamente, troppo comune: al di fuori di un vault, nel codice o nella configurazione in chiaro.

Le piattaforme di gestione dei segreti aziendali, spesso chiamate vault, sono fondamentali per memorizzare e proteggere i segreti utilizzati dagli NHIs. I vault possono fornire una singola fonte di verità per tutti i segreti, garantendo che siano crittografati a riposo, strettamente controllati nell’accesso e monitorati per tentativi non autorizzati di accesso. Ciò presuppone che tu abbia standardizzato su una singola piattaforma di gestione dei segreti aziendali. La maggior parte delle organizzazioni in realtà ha molti vault in uso contemporaneamente, rendendo la sincronizzazione tra tutti i vault una sfida aggiuntiva.

I team possono mappare tutte le identità delle macchine esistenti in base all’esistenza di questi segreti. Per le imprese con più soluzioni di gestione dei segreti in atto, è necessario sapere quali vault contengono o non contengono un segreto e ridurre il sovraccarico di memorizzare la stessa chiave in modo ridondante su diversi vault.

Tutti i Segreti NHIs Hanno una Storia di Origine

Le macchine non possono concedersi permessi e accessi. Ogni identità di macchina è stata creata da o rappresenta un’identità umana. La governance degli NHIs deve includere il tracciamento della creazione dei segreti per garantire che ogni segreto sia rintracciabile alla sua origine, distribuito in modo sicuro e collegato a un’identità legittima. Sebbene questo aspetto potrebbe essere considerato con l’uso corretto di una piattaforma di gestione dei segreti, i nostri dati continuano a dirci che una certa percentuale di segreti viene rivelata anno dopo anno perché non stiamo utilizzando in modo coerente queste soluzioni di vault.

Sappiamo dall’esperienza pluriennale nell’aiutare i team a gestire gli incidenti che il creatore di un segreto sarà quasi sempre la persona che per prima introduce le credenziali in un ecosistema. Possiamo anche capire dalla cronologia del codice o da altre informazioni temporali di sistema quando questo è stato visto per la prima volta, che è il momento più probabile per la creazione o almeno per l’avvento in modo significativo.

Questo è un dettaglio critico che potrebbe non essere mai stato correttamente registrato o documentato altrove. Una volta compreso chi ha creato un segreto per essere in grado di sfruttare un NHI, allora si comprende veramente l’inizio del nostro ciclo di vita NHI.

Tutti i Segreti NHI Devono Concedere un Determinato Insieme di Autorizzazioni

Quando creato, ogni segreto NHI deve essere dotato di un determinato insieme di autorizzazioni. Il campo di applicazione determina quali azioni un’identità può svolgere e su quali sistemi. Ciò rende essenziali lo scoping e l’applicazione delle autorizzazioni come componenti cruciali della governance.

In sostanza, due rischi rendono fondamentale per la sicurezza aziendale la comprensione del campo di applicazione di un segreto. In primo luogo, che segreti mal configurati o sovra-privilegiati possono concedere involontariamente l’accesso a dati sensibili o sistemi critici, aumentando significativamente la superficie di attacco. Immagina di dare accidentalmente privilegi di scrittura a un sistema che può accedere ai dati personali dei tuoi clienti. È un conto alla rovescia in attesa che un attore minaccioso lo trovi ed lo sfrutti.

Inoltre, è preoccupante che quando un segreto viene trapelato o compromesso, un team non possa sostituirlo finché non comprende prima come sono state configurate quelle autorizzazioni. Ad esempio, supponiamo che tu sappia che il segreto di un microservizio mission-critical è stato accidentalmente caricato su un repository pubblico di GitHub. In quel caso, è solo una questione di tempo prima che venga scoperto e utilizzato da qualcuno al di fuori della tua organizzazione. Nel nostro recente rapporto Voice of the Practitioner, i decisori IT hanno ammesso che ci sono voluti, in media, 27 giorni per ruotare questi segreti critici. I team dovrebbero essere in grado di agire in secondi o minuti, non in giorni.

Strumenti che forniscono ulteriori contesti sui segreti rilevati, comprese le loro funzioni e autorizzazioni, sono necessari. Comprendere rapidamente quali asset sono esposti quando si verifica una fuga e quale danno potenziale può essere inflitto da un attore di minaccia è molto utile nella risposta a un incidente. Sapere esattamente come sostituirlo da una vista di dashboard o da una chiamata API può fare la differenza tra una violazione e un attaccante frustrato che scopre che la chiave che possiede è non valida.

Tutti i segreti NHI devono essere ruotati

Un’identità macchina può, e probabilmente dovrebbe, avere molti segreti durante la sua vita. Se le credenziali vengono lasciate attive per mesi o anni, o nel peggiore dei casi, per sempre, l’esposizione o il compromesso dei segreti NHI diventa sempre più probabile. La rotazione manuale è soggetta a errori ed è gravosa dal punto di vista operativo, soprattutto in ambienti con migliaia di NHI. Automatizzare il processo di rotazione dei segreti è un pilastro della governance NHI, garantendo che i segreti vengano aggiornati prima che scadano o vengano divulgati.

Per qualsiasi segreto nei tuoi archivi, la rotazione dovrebbe essere una semplice questione di scripting. La maggior parte delle piattaforme di gestione dei segreti forniscono script o alcun altro meccanismo per gestire il delicato processo di sostituzione e revoca del vecchio segreto.

Ma cosa succede con i segreti NHI che si trovano al di fuori di questi archivi, o forse lo stesso segreto che è distribuito su più archivi? Una buona piattaforma di scansione dei segreti ha bisogno di un’integrazione fluida con questi archivi in modo che il tuo team possa trovare più facilmente e salvare in modo sicuro questi segreti nel gestore dei segreti e preparare la strada per la rotazione automatizzata. L’implementazione di riferimento di GitGuardian con Conjur di CyberArk fornisce maggiori dettagli su come è possibile automatizzare completamente l’intero processo di archiviazione e rotazione.

Identificando tutti gli NHI e sapendo quando sono stati creati, possiamo anche prevedere quando devono essere ruotati. Mentre ogni team giudicherà esattamente quanto tempo ciascun segreto dovrebbe rimanere attivo, qualsiasi segreto che non è mai stato ruotato dopo la creazione è maturo per essere sostituito. Qualsiasi segreto più vecchio di un anno, o per alcuni sistemi mission-critical, di pochi giorni, dovrebbe inoltre essere prioritario per la rotazione il prima possibile.

Tutti gli NHI avranno una scadenza

Gli NHI, come i loro omologhi umani, hanno cicli di vita finiti. Possono essere disattivati quando un servizio viene ritirato, sostituito o non è più necessario. Senza affrontare la disattivazione e la pulizia degli NHI per prevenire la persistenza di segreti non utilizzati o connessioni obsolete, stiamo creando punti ciechi di sicurezza. Ma come sappiamo quando siamo alla fine del percorso per un NHI, soprattutto se il suo segreto rimane valido?

Una risposta è che non dovrebbe più esistere quando un NHI non si connette più a un altro sistema attivo. Questo assicura che gli attaccanti non possano sfruttare i segreti NHI obsoleti per ottenere un accesso nel tuo ambiente. Ricorda che gli attaccanti non si preoccupano di come un segreto dovrebbe essere utilizzato correttamente; si preoccupano solo di cosa possono farne.

Mappando tutte le relazioni che i segreti di un NHI consentono, puoi identificare quando un sistema non è più connesso a nessun’altra identità. Una volta che non ci sono più modi per un’identità di comunicare, allora essa e i suoi segreti non dovrebbero più esistere. Significa anche che il segreto non deve più essere memorizzato nei tuoi gestori di segreti, dandoti una cosa in meno da memorizzare e gestire.

Comprendere il mondo intorno ai tuoi NHI è fondamentale per la sicurezza.

Nel 2022, la ricerca di CyberArk ha mostrato che per ogni identità umana in un ambiente, è necessario gestire almeno 45 identità non umane. Oggi quel rapporto è probabilmente più vicino a 1 a 100 ed è in costante aumento. Il momento migliore per affrontare la governance e la gestione del ciclo di vita delle identità non umane era anni fa. Il secondo momento migliore è proprio adesso.

È giunto il momento di adottare un approccio a ciclo completo per la sicurezza delle identità non umane, tracciando non solo dove si trovano i segreti delle identità non umane, ma, altrettanto importante, quali altre identità non umane sono collegate. Siamo in ritardo, in tutti i settori, nell’implementare la governance delle identità non umane su larga scala. Trovare e memorizzare correttamente i tuoi segreti è solo l’inizio della storia. Dobbiamo documentare meglio e comprendere l’ambito dei segreti delle identità non umane, la loro età, chi li ha implementati e altre informazioni di contesto, come quando dovrebbero essere ruotati.

Anche se le identità delle macchine superano in numero gli esseri umani, non c’è motivo di lavorare da soli per risolvere questo problema; siamo tutti coinvolti nella stessa situazione.