Gestire il ciclo di vita delle identità non umane negli ambienti moderni

Introduzione: perché il ciclo di vita dell'identità non umana merita attenzione

Le identità non umane (NHI) coprono ogni credenziale o costrutto di identità che consente a un sistema, applicazione o processo automatizzato di autenticarsi e interagire con altre risorse senza un account umano direttamente coinvolto. Le NHI includono account di servizio dedicati ad applicazioni o servizi, chiavi API che sono token statici per accedere a servizi esterni, token a breve durata come token OAuth o token JWT, e credenziali di automazione utilizzate in pipeline CI/CD, strumenti di gestione della configurazione o flussi di lavoro RPA. Nelle organizzazioni con infrastrutture diversificate e routine di automazione complesse, le NHI superano di dieci o più volte il numero degli utenti umani. Anche un'organizzazione di medie dimensioni può avere centinaia di NHI, e le grandi imprese possono averne migliaia. Per maggiori informazioni sui tipi di NHI e sulle sfide di sicurezza, consulta il nostro articolo su non-human identity security.

La gestione del ciclo di vita dell'identità umana è ben consolidata e matura, dove i flussi di lavoro guidati dalle risorse umane consentono all'IT di gestire la fornitura e la revoca di accesso per i dipendenti che entrano, si spostano o escono, con ruoli RBAC e revisioni periodiche degli accessi. D'altra parte, le NHI non hanno una struttura di gestione definita. Spesso vengono create in modo ad hoc da sviluppatori o team DevOps, a cui vengono concessi permessi eccessivi o ampi per comodità, lasciate senza una proprietà documentata e configurate con credenziali statiche che raramente vengono ruotate.

Senza una gestione formale del ciclo di vita NHI, le organizzazioni affrontano tre sfide:

• Diffusione incontrollata delle identità: Proliferazione incontrollata di NHIs attraverso l'infrastruttura, rendendo la governance estremamente difficile perché non puoi rivedere e proteggere ciò che non riesci a trovare.
• Credenziali orfane: NHIs che hanno perso il loro legittimo proprietario o scopo ma sono ancora attive. Poiché nessun team le utilizza attivamente, rimangono un rischio nascosto che gli aggressori possono sfruttare.
• Punti ciechi della sicurezza: Gli NHIs rimangono tipicamente fuori dall'ambito di monitoraggio degli strumenti di sicurezza come SIEM o SOAR, che sono configurati per rilevare attività sospette da account umani. Le piattaforme di governance dell'identità si concentrano anch'esse sugli account umani e generalmente non includono gli NHIs, lasciando così una superficie di attacco significativa aperta.

Questo articolo si concentra sulle cinque fasi del ciclo di vita NHI, dalla scoperta e creazione fino al monitoraggio, alla gestione del rischio e alla dismissione sicura.

Definire le identità non umane negli ecosistemi IT odierni

Le identità non umane (NHI) sono identità digitali assegnate a macchine, applicazioni, servizi, container, script e processi automatizzati che operano in modo autonomo. Senza l'interazione umana, si autenticano, ottengono autorizzazioni per determinati permessi, accedono alle risorse ed eseguono azioni in modo programmato all'interno dei sistemi IT. Ad esempio, un'applicazione ospitata su AWS può utilizzare un ruolo IAM per accedere ai file di archiviazione, oppure un microservizio in esecuzione su Kubernetes può usare un account di servizio per comunicare con altri servizi.

Gli NHI si autenticano utilizzando meccanismi adatti alle macchine come chiavi API, segreti condivisi, certificati, token JWT o OAuth e workload identities. A differenza degli account umani, non effettuano il login in modo interattivo, non usano password nel senso tradizionale e spesso si basano su credenziali memorizzate. Poiché operano automaticamente, gli NHI possono eseguire centinaia o migliaia di azioni a velocità molto elevate e devono essere gestiti con gli stessi controlli e standard di sicurezza delle identità umane.

Gli NHI sono essenziali nell'infrastruttura IT complessa di oggi. Le organizzazioni moderne devono adottare architetture di distribuzione cloud-native, e le pratiche di microservizi e DevOps richiedono la comunicazione macchina a macchina come base.

• Interazione API: Le applicazioni moderne si basano fortemente sulle API. Le applicazioni comunicano con database, gateway di pagamento, servizi di archiviazione, strumenti di monitoraggio e piattaforme SaaS di terze parti utilizzando le API. Ognuna di queste interazioni è alimentata da un NHI e richiede l'autenticazione.
• DevOps e pipeline CI/CD: Le pipeline di integrazione continua e deployment continuo automatizzano la compilazione, i test e il rilascio del software. Queste pipeline utilizzano agenti NHI per autenticarsi ai repository del codice sorgente, ai registri degli artifact, alle piattaforme container, agli ambienti cloud per il deployment e agli strumenti di notifica. Ogni interazione richiede l'autenticazione con un NHI distinto, e queste identità spesso hanno permessi elevati.
• Carichi di lavoro cloud: Gli ambienti cloud-native creano e distruggono dinamicamente carichi di lavoro come macchine virtuali, container, funzioni serverless e pod Kubernetes. A questi carichi di lavoro vengono assegnati NHIs per accedere allo storage, interrogare database e accedere ai servizi di messaggistica. Tutti questi NHIs creati, modificati e ritirati richiedono una gestione del ciclo di vita con la dovuta visibilità.
• Attività pianificate e automazione: Oltre al cloud e a DevOps, gli ambienti IT tradizionali dipendono anche da NHI per lavori di elaborazione batch, script programmati, attività di sincronizzazione dati, servizi di backup e agenti di monitoraggio. Queste attività di automazione vengono eseguite con account di servizio con privilegi elevati e spesso non vengono ruotate, monitorate o correttamente limitate.

Tipi comuni di identità non umane gestite dalle organizzazioni

Account di servizio e identità delle applicazioni: Queste identità sono account dedicati e non interattivi creati specificamente per applicazioni, servizi e processi per autenticarsi e accedere alle risorse in modo sicuro. Ad esempio, un'applicazione per la gestione delle buste paga che si connette a un database SQL per accedere ai dati dei dipendenti utilizzando un account di servizio garantisce la continuità indipendentemente dai cambiamenti del personale. Questi sono tipicamente credenziali o chiavi fisse che vengono raramente modificate, spesso accumulano privilegi eccessivi nel tempo e sono frequentemente condivise tra più applicazioni e ambienti.

Chiavi API, token e certificati: Queste identità sono utilizzate nelle interazioni macchina-macchina. Invece di effettuare il login con nome utente e password, applicazioni e servizi usano queste identità per identificarsi in modo sicuro. Le chiavi API sono spesso stringhe segrete statiche emesse da un servizio (come AWS, Entra ID o Stripe) per identificare e autorizzare un'applicazione chiamante. OAuth o JSON Web Tokens (JWT) sono token a breve durata emessi dopo un evento di autenticazione che concedono accesso a chi li possiede senza ulteriori verifiche. I certificati basati su PKI sono usati per l'autenticazione TLS reciproca, la firma del codice e la comunicazione nel service mesh. Sebbene questi certificati abbiano una data di scadenza, i certificati non gestiti sono una delle principali cause di interruzioni del servizio.

Identità di workload cloud e container: Le NHIs sono assegnate dinamicamente a macchine virtuali, container, funzioni serverless e pod Kubernetes. Questi workload interagiscono tra loro e al di fuori del cloud con altre piattaforme cloud o infrastrutture on-premises. Sebbene le managed identities riducano la necessità di segreti hardcoded, i permessi mal configurati associati ai ruoli IAM utilizzati da questi workload sono obiettivi principali per gli attaccanti.

DevOps, CI/CD e identità di automazione: Gli ambienti DevOps si basano fortemente su identità di automazione. Gli strumenti della pipeline CI/CD come Jenkins, GitHub Actions, GitLab CI e CircleCI richiedono credenziali per effettuare il checkout del codice, inviare artefatti, distribuire negli ambienti cloud e aggiornare l'infrastruttura. Gli strumenti Infrastructure-as-code come Terraform e Ansible richiedono credenziali del provider cloud con ampi permessi. Se compromesse, queste identità di automazione possono fornire agli attaccanti il controllo immediato sugli ambienti di produzione.

Agenti AI e identità di sistema autonome: Man mano che le organizzazioni adottano l'automazione guidata dall'AI a un ritmo più rapido, sta emergendo una nuova classe di NHI. Questi agenti AI e identità di sistema autonome rappresentano copiloti AI che interagiscono con i sistemi aziendali, bot intelligenti che eseguono compiti operativi, modelli di machine learning che accedono a pipeline di dati e bot di robotic process automation (RPA) che compilano moduli e trasformano dati. Le organizzazioni devono essere attente nel distribuire questi agenti AI e devono definire un sistema di gestione del ciclo di vita dell'identità che controlli e monitori l'ambito di accesso con una traccia di audit.

Identità umane vs. non umane: un confronto del ciclo di vita

Sia le identità umane che quelle non umane richiedono governance; tuttavia, i loro cicli di vita sono fondamentalmente diversi per struttura, proprietà, profilo di rischio e comportamento operativo. I processi tradizionali di Identity Management sono stati progettati principalmente per utenti umani e, quando vengono applicati così come sono alle NHIs, spesso non riescono a fornire un controllo adeguato.

I flussi di lavoro tradizionali di IAM sono progettati attorno al ciclo di vita dell'impiego umano. Presuppongono una chiara proprietà dell'account e che lo stato delle risorse umane attivi eventi. Le NHI non seguono questi schemi e richiedono una gestione del ciclo di vita appositamente progettata perché non hanno un record HR, nessun manager, nessun evento di login interattivo e nessuna naturale tempistica di offboarding.

Cosa include effettivamente il ciclo di vita dell'identità non umana

Gli NHI richiedono una gestione del ciclo di vita strutturata come gli utenti umani, ma la gestione deve adattarsi a scenari come l'automazione, la comunicazione macchina a macchina e la scalabilità ad alta velocità. Di seguito sono riportate le cinque fasi critiche del ciclo di vita NHI:

Governare gli NHI con un approccio basato sul ciclo di vita garantisce l'assenza di punti ciechi nella sicurezza. Ogni fase funziona come un controllo di sicurezza: nessuna scoperta porta a identità fantasma, una gestione debole porta all'aumento dei privilegi, nessun monitoraggio significa che le compromissioni rimangono inosservate, nessuna rotazione delle credenziali significa che una chiave compromessa garantisce accesso persistente, e nessuna dismissione lascia credenziali orfane creando backdoor persistenti non rilevate.

Fase 1: scoperta e inventario delle identità non umane

La scoperta è il primo passo fondamentale nella gestione delle identità non umane perché la prima regola della sicurezza è "non puoi proteggere ciò che non puoi vedere." Prima che qualsiasi governance, politica o controllo di sicurezza possa essere applicato, le organizzazioni devono stabilire un inventario completo, accurato e continuamente aggiornato di ogni NHI nel loro ambiente.

Ciò che la scoperta richiede

Scansione continua: Le NHIs non sono statiche. Gli sviluppatori forniscono account di servizio su richiesta, le pipeline CI/CD generano token a breve durata e i carichi di lavoro cloud-native creano nuove identità dinamicamente. Un audit puntuale catturerà un'istantanea che diventa obsoleta quasi immediatamente. Una scoperta efficace richiede una scansione continua e automatizzata che venga eseguita su base programmata o in base a eventi, rilevando le identità appena create non appena appaiono.

Copertura cross-ambientale: Le organizzazioni moderne operano in ambienti ibridi e multi-cloud. Discovery deve scansionare continuamente le directory on-premises come Active Directory, i sistemi IAM cloud in AWS, Azure e GCP, le piattaforme SaaS, i sistemi di orchestrazione dei container e i vault dei segreti. Se la scoperta è limitata a uno o due ambienti, una grande parte della superficie di attacco NHI rimarrà invisibile.

Mappatura degli attributi: La scoperta non riguarda solo l'elenco delle identità; deve anche catturare il contesto completo di ogni identità per applicare controlli di sicurezza e governance. Questo include la mappatura degli attributi chiave per ogni NHI, come il team o l'individuo che possiede l'identità, la funzione aziendale che svolge, i sistemi o servizi che ne dipendono e quando le credenziali sono state ruotate l'ultima volta.

Sfide comuni nella scoperta

1. A differenza delle identità umane che sono centralizzate in un sistema HR o in un provider di identità principale, le NHI raramente risiedono in un unico posto. Esistono nelle console IAM nelle piattaforme cloud, nelle configurazioni locali degli account di servizio sui server, nei segreti memorizzati in vault e nelle chiavi API incorporate nei file di configurazione o nei repository di codice. Questa proliferazione di identità rende difficile ottenere un inventario accurato senza strumenti specializzati per la gestione delle NHI.
2. A differenza delle identità umane che si sincronizzano dai sistemi HR in una directory centralizzata, le NHI di solito non hanno un sistema di origine autorevole. Più identità possono svolgere la stessa funzione, le identità orfane rimangono attive dopo il pensionamento delle applicazioni e credenziali duplicate esistono in diversi ambienti. I team di sicurezza devono aggregare e correlare i dati da più fonti per costruire una piattaforma di inventario unificata.
3. Una delle situazioni più impegnative nella scoperta di NHI sono le identità fantasma. Sviluppatori e ingegneri DevOps creano frequentemente identità per soluzioni rapide, test e distribuzioni veloci al di fuori dei processi formali di provisioning. Queste identità mancano di una documentazione e di un ambito adeguati, rendendole ad alto rischio e difficili da scoprire.

Fase 2: provisioning sicuro e assegnazione degli accessi

La prima linea di difesa è la fase di provisioning. Il modo in cui vengono creati gli NHI determina il loro profilo di rischio durante tutto il ciclo di vita. Se un'identità ha permessi eccessivi non documentati e senza una chiara proprietà, diventa un rischio che può persistere per anni senza essere rilevato.

Best practice per il provisioning

Standardizzare i flussi di lavoro per la creazione: Ogni NHI deve essere creato tramite un processo predefinito e ripetibile, e l’accesso deve essere conforme ai modelli di controllo degli accessi basati sui ruoli o sugli attributi. Ciò significa stabilire modelli approvati per tipi comuni di identità come service accounts, API keys e CI/CD pipeline tokens per garantire che nessun NHI entri nell’ambiente al di fuori di una policy di governance.

Applica il principio del minimo privilegio fin dall'inizio: Uno dei rischi maggiori nella fornitura di NHI è concedere un accesso ampio durante la fase di sviluppo che diventa permanente in produzione. Minimo privilegio deve essere applicato al momento della creazione dell'identità: definire esattamente i sistemi e i requisiti API, valutare attentamente quali permessi devono essere concessi, evitare permessi jolly nelle policy IAM cloud e partire dall'accesso minimo.

Assegna la proprietà: Ogni NHI deve essere collegato a un individuo, ruolo o team per stabilire una proprietà chiara. La proprietà deve essere aggiornata regolarmente nel Change Management Database (CMDB) e nelle piattaforme IAM affinché qualsiasi modifica necessaria debba essere consultata e approvata dal proprietario. Se il proprietario lascia l'organizzazione, la proprietà deve essere riassegnata immediatamente.

Imposta le date di scadenza:Molti NHI vengono creati per progetti temporanei, migrazioni, ambienti di test, integrazioni con fornitori e attività di automazione a breve termine, ma raramente vengono disattivati dopo che la necessità è terminata. Assegna un tempo di vita (TTL) a ogni NHI. Quando scade, il proprietario deve rivedere la necessità e, se non approvata, l'NHI deve essere automaticamente rimosso dal sistema.

Errori da evitare nel provisioning

• Permessi eccessivi: Sotto pressione per le consegne, i team spesso concedono permessi eccessivi "solo per far funzionare le cose." I permessi eccessivi raramente vengono ridotti una volta che tutto funziona e creano percorsi nascosti di escalation dei privilegi che possono diventare opportunità per movimenti laterali o gravi violazioni della conformità.
• Copiare le autorizzazioni da NHIs esistenti: Quando si crea una nuova identità, è più facile copiare le autorizzazioni da quelle esistenti, supponendo che sia il metodo approvato. Tuttavia, questo crea problemi come l'eredità di autorizzazioni obsolete o eccessive che non sono mai state formalmente approvate.
• Creazione di NHIs senza documentazione e responsabilità: Quando le NHIs vengono create senza documentazione e l'inventario non viene aggiornato, i team di sicurezza non possono includerle nel loro ambito, le valutazioni del rischio diventano obsolete e non esiste un piano di risposta agli incidenti o di dismissione.

Fase 3: monitoraggio continuo e supervisione comportamentale

Una volta che un NHI è stato fornito, il lavoro di sicurezza non si ferma. Si sposta verso un monitoraggio continuo, non solo revisioni di accesso statiche periodiche, ma il monitoraggio di come vengono utilizzate le autorizzazioni e di come ruoli e autorizzazioni evolvono nel tempo. Il monitoraggio continuo garantisce che ciò che un NHI sta facendo sia allineato a ciò che dovrebbe fare e, se vengono rilevate deviazioni, l'indagine e la correzione possono impedire che la deviazione diventi un incidente.

Cosa monitorare

Modelli di utilizzo: Comprendere e monitorare con quale frequenza e in quale contesto un NHI opera fornisce la base per comprendere i rischi associati. Un NHI è attivo quotidianamente o solo negli ultimi giorni della settimana o del mese? Se sta gestendo 100 richieste all'ora, qual è la causa di un improvviso picco a 10.000 richieste? Un picco nella frequenza di utilizzo o nel volume delle chiamate al di fuori della finestra operativa abituale può indicare compromissione o uso improprio. Se un NHI non è attivo per un periodo prolungato, potrebbe indicare un servizio dismesso le cui credenziali non sono mai state revocate.

Ambito di accesso: Monitorare ciò a cui un NHI accede, come risorse, API, archivi di dati o servizi, è fondamentale per la visibilità e per garantire che il comportamento effettivo in fase di esecuzione corrisponda al design di accesso previsto. Anche se un NHI funziona normalmente, un accesso eccessivo rappresenta un rischio potenziale. La visibilità sull'ambito di accesso deve includere revisioni periodiche degli accessi, assegnazioni di ruoli e valutazioni del rischio basate sulla criticità dell'accesso.

Cambiamenti insoliti: Qualsiasi modifica agli accessi, in particolare quelle inaspettate o non autorizzate, dovrebbe rappresentare un segnale d’allarme per i team di sicurezza. Questo include nuove assegnazioni di ruoli, allegati di policy, modifiche ai membri dei gruppi o concessioni di accesso segreto che non facevano parte di un flusso di lavoro di gestione delle modifiche. Poiché gli NHI non possono auto-iniziare richieste, una modifica inaspettata agli accessi deve essere considerata come possibile attività dannosa, abuso interno o configurazione errata dell’automazione e deve essere indagata prontamente.

Deriva delle autorizzazioni: Nel tempo, gli NHIs tendono ad accumulare autorizzazioni per compiti diversi o progetti temporanei e ad ottenere più accessi di quanto inizialmente previsto. Le cause comuni includono l'espansione dei progetti, accessi temporanei aggiunti per la risoluzione dei problemi che non sono mai stati rimossi e modifiche all'ereditarietà dei ruoli dovute a nidificazioni complesse di gruppi. La deriva delle autorizzazioni deve essere monitorata rigorosamente confrontando le autorizzazioni attuali con i modelli di autorizzazione di base.

Registrazione e conformità

I registri di attività NHI non sono opzionali; sono importanti quanto i registri di attività umane per requisiti di conformità, preparazione all'audit e risposta agli incidenti. Framework come PCI DSS, HIPAA, SOC 2 e GDPR richiedono tracciabilità, responsabilità e tracce di audit degli accessi al sistema, sia che si tratti di un account umano o di un'identità non umana.

• Tracciabilità: Ogni azione automatizzata deve essere attribuibile a un'identità specifica in modo che la proprietà possa essere stabilita.
• Prove di audit: Le organizzazioni devono essere in grado di dimostrare chi ha avuto accesso ai sistemi sensibili, quando è avvenuto l'accesso, quali azioni sono state eseguite e se l'accesso era autorizzato.
• Indagine sull'incidente: Durante le indagini forensi sulle violazioni della sicurezza, i log di identity aiutano a determinare se le credenziali sono state compromesse, a tracciare i movimenti laterali, a stabilire l'ambito dell'esfiltrazione dei dati e a costruire una cronologia chiara per ricostruire gli eventi dell'attacco.

Fase 4: gestione del rischio delle credenziali

I segreti a lunga durata sono uno degli aspetti più pericolosi della sicurezza delle identità non umane e rappresentano un rischio sistemico. A differenza delle credenziali umane, dove i cambiamenti di password sono imposti dalla policy e MFA aggiunge un ulteriore livello di sicurezza, le credenziali NHI spesso rimangono statiche per mesi o addirittura anni. Se queste credenziali vengono divulgate, rimangono attivamente sfruttabili finché i permessi non vengono esplicitamente revocati o l’identità non viene eliminata.

Perché la rotazione è importante

Esposizione non rilevata: Le credenziali possono essere trapelate tramite log, ambienti di sviluppo o tecniche sofisticate senza attivare alcun allarme. Se un segreto viene accidentalmente caricato su Git, esposto tramite un bucket di archiviazione cloud mal configurato o estratto dalla memoria o dai log, gli aggressori ottengono un accesso persistente e le organizzazioni non hanno idea che una compromissione sia già avvenuta.

La rotazione limita il raggio d'azione: La rotazione agisce come un limite temporale sulla possibile compromissione. Cambiando frequentemente le credenziali, gli attaccanti con accesso silenzioso vengono automaticamente revocati. Ad esempio, se una chiave viene ruotata ogni 24 ore, una chiave rubata diventa inutile il giorno successivo. Un token a breve durata valido per 15 minuti limita l'esposizione solo a 15 minuti. Il principio è semplice: più a lungo un segreto rimane valido, maggiore è la probabilità che sia stato esposto tramite qualche vettore di attacco non rilevato.

Conformità e governance: I moderni framework di sicurezza e conformità richiedono esplicitamente controlli per la gestione delle credenziali e non considerano più la rotazione delle credenziali come un'opzione, ma come un controllo obbligatorio. Gli auditor necessitano di prove sulla frequenza con cui le credenziali degli account di servizio vengono ruotate, se la rotazione è automatizzata e cosa succede quando un segreto viene esposto.

Best practice per la rotazione

Definisci le politiche di rotazione: La rotazione manuale delle credenziali non è affidabile per natura perché i team potrebbero dimenticare o non avere una chiara responsabilità. Una politica di rotazione formale dovrebbe definire quali credenziali devono essere ruotate, la durata massima per tipo di credenziale, chi è responsabile della rotazione e quali strumenti devono essere utilizzati. La rotazione basata su policy garantisce coerenza in ambienti diversi e crea una chiara traccia di audit.

Imposta i programmi di rotazione: Non tutte le credenziali comportano lo stesso rischio e la frequenza di rotazione deve essere impostata di conseguenza. Gli account di servizio con privilegi elevati dovrebbero essere ruotati quotidianamente o settimanalmente, le chiavi API cloud con ampie autorizzazioni dovrebbero essere ruotate settimanalmente o mensilmente, e i token di accesso utente dovrebbero avere una durata breve (validi per minuti, non per giorni). L'obiettivo è rendere la rotazione un processo di background piuttosto che un controllo di emergenza periodico.

Rispondere immediatamente alle esposizioni:La rotazione non dovrebbe essere solo basata sul tempo; deve anche essere guidata dagli eventi in base al monitoraggio continuo. Le organizzazioni devono avere un processo definito per la risposta agli incidenti di credenziali che si attiva immediatamente quando si sospetta o si conferma una compromissione. Quando viene rilevata un'esposizione, un processo automatizzato dovrebbe revocare la credenziale compromessa, generare un nuovo segreto, aggiornare tutti i servizi dipendenti e registrare e notificare le parti interessate.

Fase 5: dismissione e offboarding delle identità non umane

La dismissione è spesso la fase più trascurata del ciclo di vita delle non-human identity. Mentre le organizzazioni si concentrano sul provisioning e sul monitoraggio, il pensionamento delle NHI avviene generalmente durante campagne informali o per nulla. Di conseguenza, molte NHI orfane rimangono nel sistema come account fantasma che creano una superficie di attacco nascosta.

Identificazione degli NHI per la dismissione

La dismissione efficace inizia con la visibilità. Le organizzazioni devono rilevare proattivamente le NHIs che non dovrebbero più esistere.

Identità inutilizzate: Molti NHI vengono creati per progetti a breve termine, integrazioni temporanee, ambienti di test o iniziative di migrazione. Una volta terminati questi progetti, questi NHI rimangono nel sistema con credenziali valide. Dovrebbe esserci una politica che valuti quando un NHI non è più in uso, ad esempio nessun evento di autenticazione entro periodi di tempo definiti (30, 60 o 90 giorni).

Identità orfane: Le NHIs diventano orfane quando i loro proprietari o i team responsabili lasciano l'organizzazione, vengono riassegnati ad altri progetti o quando le applicazioni per cui la NHI è stata creata vengono ritirate senza la pulizia della NHI. Senza un proprietario, non c'è nessuno che possa rivedere i diritti di accesso, ruotare le credenziali o monitorare attività anomale. Le identità orfane sono particolarmente pericolose perché appaiono legittime all'interno dei sistemi ma non hanno supervisione.

Identità duplicate: In ambienti DevOps decentralizzati, più team possono creare identità separate per compiti identici, portando a account di servizio ridondanti, chiavi API sovrapposte o più credenziali con diritti di accesso simili. Le identità duplicate aumentano la complessità e il rischio perché le tracce di controllo diventano più difficili da mantenere e revocare l'accesso di un'identità non elimina il rischio di accesso.

Processo di dismissione sicuro

Rimuovere un NHI senza una convalida attenta è di per sé un rischio. Può compromettere applicazioni o servizi dipendenti in produzione. Il processo di dismissione dovrebbe essere eseguito in modo sistematico.

1. Identificare e profilare: Utilizzare strumenti di scoperta automatica per segnalare le identità basate sull'inattività o sulla mancanza di un proprietario valido, sia che l'applicazione o il servizio associato sia dismesso, sia che l'NHI sia confermato come identità duplicata. Le NHI identificate devono essere inviate per la revisione ai proprietari delle applicazioni, ai team di sicurezza e DevOps.
2. Verifica delle dipendenze: Prima di disabilitare o eliminare un NHI, verifica che non stia supportando attivamente processi in background, attività di automazione programmate, integrazioni di terze parti, processi di disaster recovery o sistemi legacy. Le verifiche delle dipendenze richiedono la revisione dei log di autenticazione, il controllo delle configurazioni CI/CD, la scansione dei template infrastructure-as-code e la consultazione con i proprietari delle applicazioni.
3. Disabilita prima di eliminare: Non eliminare mai immediatamente. La migliore pratica è rimuovere in fasi: prima disabilitare la capacità di autenticazione, monitorare eventuali errori o malfunzionamenti del sistema, consentire un periodo di grazia definito (da 7 a 30 giorni) e eliminare definitivamente se non si verificano impatti. Questo permette ai team di convalidare eventuali impatti e consente un rapido rollback.
4. Rimozione del documento a scopo di audit: Una volta completate tutte le fasi di dismissione, eseguire una cancellazione definitiva e assicurarsi che questa azione venga registrata nei log della piattaforma SIEM per la tracciabilità dell'audit. Documentare le informazioni necessarie, inclusi il nome dell'identità con il suo identificatore univoco, i sistemi e i privilegi associati, il motivo della rimozione, i dettagli del flusso di revisione e approvazione e la data di cancellazione.

Errori comuni nella gestione del ciclo di vita NHI

Come Netwrix supporta la gestione del ciclo di vita NHI

Netwrix Identity Manager offre un framework completo di governance e amministrazione dell'identità (IGA) che gestisce account umani e identità non umane in un'unica piattaforma con processi di ciclo di vita automatizzati. Netwrix Identity Manager crea un repository centralizzato delle identità che include tutti i tipi di identità per creare un inventario unificato che funge da base per la gestione del ciclo di vita dell'identità.

Scoperta e inventario: Tutti i tipi di identità, inclusi gli NHI, sono sincronizzati in un repository centralizzato di Identity Management che fornisce visibilità e riduce la dispersione delle identità. I connettori estraggono dati di identità e autorizzazioni da diverse directory (Active Directory, Microsoft Entra ID) e applicazioni aziendali, includendo gli NHI nell’ambito della governance insieme alle identità umane.

Provisioning controllato: Viene definito un flusso di lavoro di provisioning standardizzato per ogni identity, riducendo il provisioning ad hoc con permessi eccessivi. I flussi di lavoro basati su policy vengono attivati quando viene richiesta la creazione di un identity, applicando i principi del minimo privilegio per fornire solo l'accesso richiesto dal ruolo dell'identity. Il controllo degli accessi basato sui ruoli garantisce che gli identity ottengano solo i permessi appropriati alla loro funzione.

Monitoraggio e revisione continui: Netwrix Identity Manager traccia le autorizzazioni, gli eventi di modifica e lo stato di conformità per tutte le identità che gestisce. Offre funzionalità integrate per campagne di certificazione degli accessi con analisi del rischio per rilevare quando le NHIs accumulano permessi eccessivi e monitora i modelli di accesso e l'utilizzo delle risorse. Aiuta a rilevare identità dormienti o orfane, l'aumento dei privilegi e le violazioni della segregazione dei compiti sia per identità umane che non umane.

Rimedi e pulizia degli accessi: Netwrix Identity Manager consente alle organizzazioni di analizzare i permessi di ogni identità rispetto alle regole di policy. Gli NHI che non necessitano più di accesso o che hanno permessi oltre quelli consentiti dalla policy possono essere segnalati per la rimedio. È possibile definire regole per identificare account inutilizzati che non hanno effettuato l'accesso per un periodo stabilito (ad esempio 90 giorni), NHI orfani il cui proprietario non è presente, o permessi eccessivi rilevati durante la certificazione degli accessi.

Chiusura del ciclo di vita: Netwrix Identity Manager automatizza le fasi di provisioning, aggiornamento e deprovisioning con workflow completi che gestiscono i processi joiner-mover-leaver (JML). Quando un'applicazione o un servizio viene ritirato, un progetto termina o un proprietario umano lascia o si sposta al progetto successivo, Netwrix Identity Manager assicura che i NHIs associati perdano i permessi e vengano infine eliminati.

Conclusione: dalla proliferazione delle identità al controllo del ciclo di vita

Nelle infrastrutture IT moderne, le identità non umane sono diventate il tipo di identità dominante e non spariranno. Si stanno moltiplicando esponenzialmente. Ogni nuovo meccanismo di automazione, carico di lavoro cloud e agente AI contribuisce all'impronta NHI in continua crescita. Il passaggio da un design monolitico delle applicazioni a microservizi comporta più identità per ogni sotto-servizio che comunica con altri servizi. I carichi di lavoro cloud come macchine virtuali, funzioni serverless, container e servizi gestiti richiedono tutti più NHI. Le pipeline DevOps si basano fortemente su service principals, token di distribuzione, integrazioni Git, credenziali API e agenti di build. Le NHI ora superano in numero le identità umane con un rapporto di 10 a 1, e il rapporto continua a salire.

La gestione del ciclo di vita NHI trasforma gli NHI da un rischio crescente in una classe di asset governata e consente alle organizzazioni di gestire gli NHI con controlli più efficaci necessari per la scala e l'impatto che comportano. Affrontando ogni fase (scoperta, provisioning, monitoraggio, rotazione e dismissione), le organizzazioni possono ridurre la dispersione delle identità, applicare il principio del minimo privilegio e chiudere le lacune di sicurezza che il tradizionale IAM non può affrontare per gli NHI.