Identità non umane (NHI) spiegate e come proteggerle

La maggior parte delle organizzazioni non può produrre un inventario completo delle identità non umane (NHI) in esecuzione nel proprio ambiente. Gli account di servizio, le chiavi API e le credenziali delle applicazioni si accumulano in Active Directory (AD) e nelle piattaforme cloud, spesso senza una chiara proprietà, uno scopo documentato o un ciclo di revisione definito.

Questa lacuna comporta un rischio reale. Secondo il Rapporto sulle Tendenze della Cybersecurity Netwrix 2025, il 46% delle organizzazioni ha subito compromissioni di account lo scorso anno, rispetto al 16% del 2020. Le identità macchina a macchina, come gli account di servizio e i token, sono un fattore in crescita in questa tendenza, e la maggior parte dei team IT di medie dimensioni non ha la visibilità per gestirle in modo efficace.

Cosa sono le identità non umane nella cybersicurezza e perché sono importanti?

Le identità non umane (NHI) sono credenziali digitali che consentono a macchine, applicazioni e processi automatizzati di autenticarsi e accedere alle risorse senza intervento umano. Gli account di servizio, le chiavi API, le identità gestite, i token OAuth e gli agenti AI rientrano tutti sotto l'ombrello NHI.

I loro numeri stanno crescendo rapidamente. Ogni risorsa cloud, pipeline CI/CD, flusso di lavoro di automazione e integrazione AI crea nuove NHI che necessitano di credenziali e permessi. Nella maggior parte delle organizzazioni, le identità delle macchine superano il numero degli utenti umani di un fattore di 10:1 o più.

Quando il software di backup si connette a un database alle 2 del mattino, non digita una password. Si autentica utilizzando un'account di servizio con credenziali memorizzate. Questo è un NHI. Lo stesso vale per la chiave API che il sistema di ticketing utilizza per estrarre i dati CRM, o per il token OAuth che sincronizza i registri dei dipendenti con Entra ID.

Come ha osservato Jeff Warren, Chief Product Officer di Netwrix, nel Rapporto sulle Tendenze della Cybersecurity 2025, gli attacchi guidati dall'identità probabilmente domineranno ancora di più, con "l'abuso di identità macchina-a-macchina come account di servizio e token" tra i vettori emergenti.

Identità umane vs. identità non umane

Le identità umane e non umane differiscono nel modo in cui vengono possedute, autenticate, gestite e monitorate:

• Proprietà: Le identità umane hanno proprietari chiari. Le NHI spesso hanno una proprietà condivisa o poco chiara, rendendo difficile far rispettare la responsabilità.
• Autenticazione: Gli esseri umani usano password combinate con MFA. Gli NHI usano chiavi, token e certificati, e MFA non si applica.
• Ciclo di vita: Le identità umane seguono processi guidati dalle risorse umane (assunzione, cambiamenti di ruolo, cessazione). Le NHI vengono create ad hoc da sviluppatori e amministratori, senza una gestione del ciclo di vita equivalente.
• Comportamento: L'accesso umano è interattivo e variabile. L'accesso NHI è programmatico e ripetitivo, rendendo la rilevazione delle anomalie più facile da stabilire come base e più difficile da rivedere su larga scala.

Le politiche delle password, MFA, SSO e le revisioni degli accessi non si traducono bene in NHI. Ecco perché le identità delle macchine richiedono un proprio approccio alla governance.

Il termine correlato “identità della macchina” si riferisce specificamente a identità a livello di infrastruttura come server, VM e certificati. NHI è più ampio, coprendo quelli più credenziali a livello di applicazione come chiavi API, token e bot.

Metodi di autenticazione dell'identità non umana

Gli NHIs si autenticano programmaticamente anziché tramite accesso interattivo, utilizzando quattro metodi principali:

• Basato su token: chiavi API, token bearer e token JWT
• Basato su chiave: chiavi SSH e chiavi degli account di servizio
• Basato su certificati: Certificati X.509 e TLS mutuo (mTLS)
• Federazione dell'identità del carico di lavoro: Meccanismi nativi del cloud come i ruoli AWS IAM, le identità gestite di Azure e gli account di servizio GCP

Il rischio critico in tutti e quattro è che MFA e SSO non si applicano. Quando una credenziale è compromessa, non c'è un secondo fattore per prevenire lo sfruttamento e l'attaccante eredita qualsiasi accesso che quell'identità detiene.

Tipi comuni di identità non umane

Comprendere i diversi tipi di NHI nel tuo ambiente è il primo passo per gestirli in modo efficace. Le seguenti categorie rappresentano le identità non umane più comuni che incontrerai in ambienti on-premises e cloud.

1. Account di servizio e identità delle applicazioni

Le account di servizio sono account specializzati che consentono alle applicazioni di eseguire attività senza credenziali umane. Il software di backup utilizza una per accedere ai database di SQL Server e gli strumenti di monitoraggio le utilizzano per raccogliere dati sulle prestazioni. Negli ambienti AD, queste sono identificate dall'attributo ServicePrincipalName (SPN).

La principale sfida di sicurezza è che le password cambiano raramente. La migliore prassi moderna è migrare a Account di Servizio Gestiti da Gruppo (gMSAs), che forniscono gestione automatica delle password tramite Active Directory ed eliminano l'intervento manuale dell'amministratore.

Le identità delle applicazioni estendono questo concetto agli ambienti nativi del cloud, dove le piattaforme cloud assegnano identità dedicate alle applicazioni per accedere a API, database e altre risorse cloud.

2. Chiavi API e segreti

Le chiavi API e i segreti svolgono la stessa funzione di base: consentono a un sistema di autenticarsi con un altro senza l'intervento di un umano. Sono incorporati in strumenti interni, integrazioni SaaS e connessioni a servizi di terze parti per concedere accesso programmatico senza richiedere a qualcuno di accedere.

That third-party category is broader than most teams realize. When a printer communicates with its manufacturer for supply monitoring, or when manufacturing equipment sends telemetry to an OEM for remote maintenance, those connections rely on API keys or embedded credentials that authenticate across organizational boundaries. These vendor-managed NHIs often fall outside standard identity governance because they're provisioned by the vendor, not by your IT team.

La sfida in tutto ciò è la loro natura statica. A differenza delle password legate agli account utente, le chiavi API non scadono per impostazione predefinita nella maggior parte dei sistemi e tendono a finire in file di configurazione, repository di codice, variabili d'ambiente e persino nei log delle chat.

Lo stesso vale per i segreti memorizzati in caveau o file di configurazione, comprese le password, le stringhe di connessione e le chiavi di crittografia. Queste credenziali comportano lo stesso rischio di accesso di qualsiasi chiave API, ma spesso ricevono meno attenzione.

Una volta trapelate, qualsiasi di queste credenziali è immediatamente sfruttabile e le organizzazioni spesso non sanno che una è stata esposta fino a quando non è già stata utilizzata. Quando la credenziale compromessa appartiene a un'integrazione di terze parti, il raggio d'azione si estende oltre il tuo ambiente nelle relazioni con i fornitori governate da framework come NIS2 e DORA, entrambi i quali richiedono controlli sui rischi della catena di fornitura per le dipendenze dei servizi digitali.

3. Identità gestite

Le identità gestite rappresentano l'approccio moderno di Microsoft all'autenticazione NHI in Azure. Le identità gestite assegnate dal sistema sono direttamente collegate a risorse Azure specifiche ed eliminano la necessità di memorizzare completamente le credenziali. Le identità gestite assegnate all'utente possono essere condivise tra più risorse.

Tuttavia, le identità gestite risolvono il problema solo all'interno dell'ecosistema Azure. Le organizzazioni che gestiscono ambienti ibridi hanno ancora bisogno di visibilità sugli account di servizio on-premises e sulle credenziali cross-platform che le identità gestite non coprono.

4. Token OAuth

Token OAuth abilitano l'accesso delegato tra le applicazioni. Quando la tua piattaforma HR sincronizza i dati dei dipendenti con il tuo fornitore di identità, o il tuo strumento di reporting estrae record da un CRM SaaS, quelle connessioni si basano sui token di aggiornamento OAuth per mantenere l'accesso persistente.

Questi token spesso hanno una durata di vita più lunga del previsto e si accumulano nelle tue integrazioni SaaS man mano che i team collegano più strumenti.

5. Identità di carico di lavoro e contenitori nel cloud

Le identità di carico di lavoro comprendono le credenziali assegnate ad applicazioni containerizzate, funzioni serverless e carichi di lavoro cloud. Le tue distribuzioni Kubernetes, Azure Container Instances e funzioni AWS Lambda richiedono tutte credenziali per accedere ad altri servizi.

Le piattaforme cloud assegnano identità a questi carichi di lavoro, inclusi VM, contenitori, funzioni serverless e pod Kubernetes, per accedere a risorse cloud, archiviazione e API. Queste identità di carico di lavoro vengono create e distrutte rapidamente, spesso superando la capacità dei team di sicurezza di tracciarle.

6. Identità di macchine e dispositivi

Le macchine fisiche e virtuali, i dispositivi IoT e i componenti dell'infrastruttura portano tutti le proprie identità. I certificati autenticano frequentemente queste identità di macchina, creando uno strato di governance NHI che si sovrappone ma si estende oltre le credenziali a livello di applicazione. Con la crescita dell'adozione dell'IoT, cresce anche questa popolazione di identità.

7. Bot e agenti AI

I bot e agenti AI rappresentano la categoria più nuova e in più rapida espansione di identità non umane. Ad esempio:

• Microsoft Copilot ha bisogno di accesso ai tuoi file e alla tua email per essere utile
• I bot di automazione dei processi robotici (RPA) necessitano di credenziali per interagire con le applicazioni aziendali
• I bot CI/CD hanno bisogno di accesso per distribuire codice
• Gli strumenti di orchestrazione e gli agenti AI operano come identità non umane, spesso con ampio accesso per abilitare i flussi di lavoro di automazione

Ognuno di essi crea relazioni di identità che richiedono la stessa governance di qualsiasi altro NHI, ma spesso vengono forniti rapidamente dai team aziendali senza revisione della sicurezza.

Il rischio aggiunto è che gli strumenti di intelligenza artificiale interagiscono con i repository di codice e gli ambienti di sviluppo. Questo può esporre involontariamente le credenziali in richieste, output e log, creando vettori di fuga che la scansione tradizionale dei segreti non cattura sempre.

Ognuno di questi tipi di identità richiede approcci di gestione diversi, ma tutti condividono sfide comuni di governance: tracciamento della proprietà, rotazione delle credenziali e disattivazione quando non sono più necessarie.

Come scoprire identità non umane nel tuo ambiente

Prima di poter governare gli NHI, è necessario trovarli. Un processo di scoperta strutturato ti aiuta a comprendere l'ambito del problema, ma la maggior parte delle organizzazioni si rende rapidamente conto che gli approcci manuali toccano solo la superficie.

Inizia con il tuo fornitore di identità

Interroga Active Directory per gli account con Nomi di Principali di Servizio, account di servizio gestiti autonomamente e account di servizio gestiti da gruppo.

Per gli ambienti cloud, estrai un inventario dei service principal, delle registrazioni delle app e delle identità gestite dalla console di amministrazione del tuo fornitore di identità. Concentrati su quattro attributi per ogni identità: quale applicazione la utilizza, quali credenziali detiene, quali risorse può accedere e chi la possiede.

Espandi al tuo livello di codice e automazione

Collabora con il tuo team DevOps per identificare le credenziali memorizzate nelle configurazioni delle pipeline CI/CD, nei modelli di infrastruttura come codice e nelle variabili di ambiente. Gli strumenti di scansione dei repository possono segnalare credenziali hardcoded e chiavi API impegnate nel controllo delle versioni. Questo è spesso il luogo in cui vivono i NHI più non tracciati.

Audita le tue integrazioni SaaS

Esamina le concessioni OAuth e le connessioni API nelle tue applicazioni SaaS. Molte organizzazioni scoprono dozzine di token OAuth attivi da integrazioni che sono state impostate mesi o anni fa da persone che nel frattempo hanno lasciato il team o l'azienda.

Documenta ciò che trovi

Per ogni NHI che scopri, registra il proprietario (una persona, non un team), la giustificazione aziendale, il tipo di credenziale e lo stato di rotazione, e l'ultima volta che qualcuno ha convalidato che è ancora necessario. Questo inventario diventa la base per tutto ciò che segue.

Una importante avvertenza: la scoperta manuale ti offre un'istantanea nel tempo, non un inventario vivo. Gli ambienti cambiano quotidianamente e un'esportazione trimestrale non catturerà l'account di servizio che qualcuno ha creato martedì scorso.

La scoperta continua e automatizzata è ciò che separa le organizzazioni che conoscono la loro popolazione NHI da quelle che pensano di conoscerla.

Come proteggere e governare le identità non umane

La gestione delle identità non umane (NHIM) è la pratica di scoprire, governare e proteggere le identità delle macchine che la gestione delle identità tradizionale (IAM) e il Privileged Access Management (PAM) non erano progettati per gestire.

Ciò significa governare l'accesso senza un attore umano, gestire le credenziali che non possono utilizzare MFA e tracciare la proprietà per le identità create da sviluppatori e automazione piuttosto che dai processi HR.

Una volta identificato ciò che esiste nel tuo ambiente, la governance garantisce che rimanga sotto controllo. Una sicurezza NHI efficace tratta le identità delle macchine come cittadini di prima classe nel tuo programma di sicurezza dell'identità, con politiche definite per ogni fase del loro ciclo di vita.

Ecco come appare in pratica:

• Assegna un proprietario a ogni NHI al momento della creazione: Nessuna identità dovrebbe esistere senza un individuo nominato (non una lista di distribuzione, non un alias di team) responsabile del suo accesso e ciclo di vita. Rendi la proprietà un campo obbligatorio nel tuo processo di provisioning.
• Applica il principio del minor privilegio fin dal primo giorno: Concedi solo i permessi specifici di cui ogni NHI ha bisogno per la propria funzione, limitati al livello di risorsa più ristretto possibile. Evita permessi a livello di abbonamento o di dominio per gli account di servizio che necessitano solo di accesso a una singola applicazione.
• Automatizza la rotazione delle credenziali quando possibile: gMSA gestisce automaticamente questo per i carichi di lavoro AD on-premises. Per i principali servizi cloud e le chiavi API, integra la rotazione nei tuoi pipeline di distribuzione o utilizza una soluzione di gestione dei segreti.

La giusta cadenza dipende dal tipo di credenziale e dal rischio di esposizione, poiché i principali framework come NIST, CIS, e PCI DSS non impongono un periodo di rotazione universale per gli account privilegiati.

• Monitora le anomalie comportamentali: Un account di servizio che improvvisamente accede a risorse al di fuori del suo normale schema, o una chiave API che si autentica da una posizione sconosciuta, dovrebbe attivare un avviso. Concentrati sul monitoraggio delle deviazioni dalle linee di base stabilite piuttosto che cercare di rivedere ogni evento.
• Disattivare aggressivamente: Gli NHI obsoleti sono una delle debolezze più sfruttabili in qualsiasi ambiente. Integra i trigger di disattivazione nel tuo processo: se un'identità non si è autenticata in 90 giorni, segnalala per la revisione. Se il proprietario non può giustificarlo, disattivala. Se nessuno se ne accorge per altri 30 giorni, rimuovila.
• Certificare l'accesso con cadenza ricorrente: Richiedere ai proprietari di NHI di riconvalidare che ogni identità abbia ancora bisogno delle proprie autorizzazioni attuali. Le revisioni annuali sono un punto di partenza, ma quelle trimestrali sono migliori per le identità privilegiate.

Questi controlli si mappano direttamente ai requisiti già incorporati nei principali framework di conformità:

• Il Livello 2 del CMMC richiede il controllo degli accessi e la gestione degli account per tutte le identità, comprese quelle non umane
• I criteri di servizio di fiducia SOC 2 richiedono controlli di accesso che si estendono a identità non umane
• HIPAA richiede registri di audit per tutti gli accessi alle Informazioni Sanitarie Protette, inclusi gli accessi da parte di processi automatizzati e account di servizio
• NIS2 (UE) richiede alle organizzazioni di gestire i rischi della catena di approvvigionamento ICT, comprese le credenziali dei servizi di terze parti e le identità gestite dai fornitori che accedono al proprio ambiente
• DORA (settore finanziario dell'UE) impone la gestione del rischio dei fornitori terzi ICT con requisiti specifici per il monitoraggio e la governance delle dipendenze dai servizi digitali, comprese le identità delle macchine utilizzate da tali servizi

Se stai costruendo la governance NHI, stai contemporaneamente costruendo prove di conformità.

Come Netwrix supporta la sicurezza delle identità non umane

Ogni pratica di governance sopra dipende da una cosa: sapere quali identità non umane esistono nel tuo ambiente e cosa stanno facendo. Questa è la lacuna che la maggior parte delle organizzazioni fatica a colmare da sole, ed è qui che si inserisce Netwrix.

La piattaforma Netwrix 1Secure fornisce visibilità continua sulla postura di identità in Active Directory e negli ambienti cloud. Per le identità non umane in particolare, mette in evidenza gli account inattivi, gli account obsoleti e le configurazioni di accesso eccessivamente permissive che violano la politica organizzativa, fornendo ai team di sicurezza un quadro dello stato attuale piuttosto che un'istantanea trimestrale.

Dove le query manuali ti danno un'esportazione in un momento specifico, 1Secure mantiene una vista continua man mano che vengono create nuove identità e quelle esistenti cambiano.

Per Active Directory specificamente, Netwrix Auditor tiene il compito di tracciare le modifiche agli account di servizio, monitorare gli eventi di autenticazione e auditare le modifiche alle Policy di Gruppo, colmando le lacune di visibilità lasciate aperte dagli strumenti nativi.

Quando qualcuno crea un nuovo account di servizio, cambia la sua appartenenza al gruppo o tenta un accesso interattivo, Auditor lo segnala. I team possono iniziare a rispondere alle domande di audit sull'attività di NHI con report leggibili da esseri umani che si mappano direttamente ai framework di conformità come HIPAA, SOC 2 e CMMC.

Per le identità non umane privilegiate che richiedono accesso elevato, Netwrix Privilege Secure elimina i privilegi permanenti attraverso la fornitura just-in-time con registrazione completa delle sessioni per le tracce di audit. Invece di conti di servizio che detengono accesso amministrativo persistente tutto il giorno, Privilege Secure concede permessi elevati solo quando necessario e li revoca automaticamente quando il compito è completato.

Pronto a chiudere il divario di visibilità sulle identità non umane?Prenota una demo per vedere come Netwrix funziona nel tuo ambiente.