Gestione dei segreti delle identità non umane per gli audit del 2026

L’allerta delle 02:13 che nessuno riusciva ad attribuire

Alle 02:13 di un martedì mattina, il canale delle operazioni di sicurezza si attiva. È iniziata un’esportazione da un database di produzione tramite un account interno di automazione. Il percorso di accesso è legittimo. Il token è valido. L’IP sorgente appartiene a un runner cloud utilizzato dal team di ingegneria. Non è visibile alcun malware. Non esiste alcuna segnalazione di phishing.

Il CISO pone la prima domanda ovvia: “Chi è il proprietario di questa identità?”

Silenzio.

Il responsabile DevOps ricorda che il token era stato creato durante una migrazione cliente due anni prima. Il team di piattaforma afferma che potrebbe essere usato da un’integrazione di fatturazione. L’amministratore del database dice che dispone di accesso in lettura perché, una volta, la sua rimozione aveva interrotto un job notturno. La funzione legale chiede se fossero coinvolti dati personali. La conformità chiede se si tratti di un incidente soggetto a notifica ai sensi di NIS2, DORA o GDPR. L’auditor chiede evidenze che account di servizio, chiavi API, certificati e segreti CI/CD siano inventariati, riesaminati, sottoposti a rotazione, monitorati e revocati.

Alle 09:00, la bozza del rilievo di audit sta già prendendo forma. In un microservizio dimenticato è stata trovata una chiave API hardcoded e non sottoposta a rotazione. La chiave concede accesso esteso a un database di produzione contenente transazioni dei clienti. Lo sviluppatore che l’ha creata ha lasciato l’azienda due anni prima. Il sistema non ha un proprietario nominato, non ha una finalità documentata, non ha registrazioni di rotazione e non ha una regola di monitoraggio.

Questo è il problema delle identità non umane nel 2026.

La maggior parte delle organizzazioni ha migliorato il controllo degli accessi umani. Ha MFA, processi joiner-mover-leaver, riesami degli accessi privilegiati e log dei provider di identità. Ma le identità macchina si sono moltiplicate più rapidamente della governance. Account di servizio, identità di workload, chiavi API, token OAuth, chiavi SSH, certificati, segreti Kubernetes, token di integrazione SaaS, account di automazione robotica dei processi e credenziali di deployment CI/CD eseguono oggi azioni aziendali critiche senza essere “utenti” in senso umano.

Per fornitori SaaS, fintech, fornitori di servizi gestiti, operatori cloud e PMI ad alta intensità di dati, le identità non umane non gestite non sono più un tema di igiene tecnica. Sono un rischio di resilienza e conformità a livello di consiglio di amministrazione. NIS2 considera controllo degli accessi, gestione degli asset, sicurezza della catena di fornitura, gestione degli incidenti e igiene informatica come misure essenziali di gestione del rischio di cibersicurezza. DORA pone rischio ICT, resilienza operativa, notifica degli incidenti e rischio ICT di terze parti sotto la responsabilità dell’organo di gestione per le entità finanziarie. GDPR richiede a titolari e responsabili del trattamento di proteggere i dati personali e dimostrare accountability.

La parte difficile non è dimostrare che i segreti esistono. La parte difficile è dimostrare che ogni identità non umana ha un proprietario, una finalità, un ciclo di vita, una valutazione del rischio, un accesso approvato, una modalità di archiviazione sicura, una regola di rotazione, copertura di monitoraggio e un percorso di revoca.

Perché le identità non umane sono diventate il nuovo problema degli accessi privilegiati

Un’identità non umana, o NHI, è qualsiasi identità digitale utilizzata da software, infrastruttura o processi automatizzati anziché da una persona. In pratica, include account di servizio usati dalle applicazioni, chiavi API usate dalle integrazioni SaaS, token OAuth e refresh token usati da applicazioni di terze parti, chiavi SSH usate dall’automazione, certificati TLS e chiavi private, segreti CI/CD, identità di workload cloud, stringhe di connessione ai database, credenziali incorporate, account di bot RPA e credenziali di integrazione gestite dai fornitori.

Queste identità presentano spesso tre caratteristiche che preoccupano gli auditor.

Primo, sono longeve. Un utente umano può ruotare le credenziali, cambiare ruolo e uscire attraverso un processo formale di offboarding. Un token API creato durante una finestra di rilascio può rimanere attivo per anni perché nessuno vuole rischiare di interrompere la produzione.

Secondo, sono potenti. Un token di deployment può modificare l’infrastruttura. Un service principal cloud può creare storage. Un account di database può esportare record dei clienti. Una chiave di firma può compromettere l’integrità della catena di fornitura software.

Terzo, sono difficili da attribuire. Le identità umane sono collegate alle registrazioni HR. Le identità non umane sono spesso collegate a script, pipeline, fornitori, progetti dimenticati o integrazioni non documentate.

Zenith Blueprint: roadmap in 30 passi per l’auditor di Clarysec Zenith Blueprint lo evidenzia direttamente nella fase Controls in Action, Step 22:

E non dimenticare le identità non umane. È qui che gli audit spesso scoprono esposizioni silenti. I token API sono tracciati? Gli account di integrazione sono collegati a persone, oppure restano sospesi nel limbo? Quando è stata l’ultima volta che quella stringa di accesso al database, incorporata in uno script vecchio di decenni, è stata sottoposta a rotazione?

La gestione delle identità non è affascinante, ma è strutturale. Senza di essa, il tuo SGSI è solo una collezione di porte chiuse, senza modo di sapere con certezza chi detenga le chiavi.

Quest’ultima frase è il punto centrale. Un’azienda può avere una politica di controllo degli accessi ben rifinita e comunque non superare un audit se le identità macchina non sono gestite. Un SGSI che non sa spiegare chi possiede un segreto, perché esiste e quando è stato riesaminato l’ultima volta non opera ancora come un sistema sotto controllo.

ISO/IEC 27001:2022 trasforma la gestione dei segreti in evidenze

ISO/IEC 27001:2022 è efficace perché non tratta la gestione dei segreti come un’attività ingegneristica isolata. Richiede un SGSI basato sul rischio con ambito definito, requisiti delle parti interessate, responsabilità della leadership, valutazione del rischio, trattamento del rischio, selezione dei controlli, una Dichiarazione di applicabilità e miglioramento continuo.

Per le identità non umane, l’organizzazione non dovrebbe iniziare acquistando uno strumento. Dovrebbe partire dall’ambito di applicazione e dagli obblighi.

Ai sensi delle clausole ISO/IEC 27001:2022 da 4.1 a 4.4, l’organizzazione determina fattori interni ed esterni, parti interessate, requisiti legali, normativi e contrattuali, interfacce e dipendenze. Nel contesto delle NHI, il campo di applicazione del SGSI dovrebbe identificare ambienti cloud, piattaforme SaaS, sistemi CI/CD, applicazioni di produzione, integrazioni con i clienti, responsabili del trattamento, fornitori di servizi gestiti e servizi crittografici in cui esistono credenziali macchina.

Le clausole da 5.1 a 5.3 rendono la leadership responsabile di politica, risorse, ruoli e rendicontazione delle prestazioni. Questo è rilevante perché la remediation delle NHI spesso crea tensioni operative. Ruotare una credenziale di database di produzione, sostituire un account di servizio condiviso legacy o imporre l’iniezione dei segreti tramite vault può interrompere flussi di lavoro fragili. Senza uno sponsor esecutivo, i team rinviano la bonifica.

Le clausole da 6.1.1 a 6.1.3 e 6.2 costituiscono il motore dei controlli. L’organizzazione definisce i criteri di rischio, identifica i rischi per riservatezza, integrità e disponibilità, assegna i titolari del rischio, valuta probabilità e impatto, sceglie le opzioni di trattamento, seleziona i controlli, produce la Dichiarazione di applicabilità e traccia obiettivi misurabili.

In termini pratici, un piano di trattamento del rischio per le identità non umane dovrebbe rispondere a queste domande:

• Quali sistemi e servizi aziendali dipendono dalle NHI?
• Quali segreti possono accedere a dati personali, servizi finanziari regolamentati, infrastruttura di produzione o servizi critici per i clienti?
• Quali identità sono privilegiate, inattive, condivise, gestite da fornitori o non governate?
• Quali controlli riducono il rischio, ad esempio vaulting, rotazione, principio del privilegio minimo, scadenza, gestione del ciclo di vita dei certificati, scansione CI/CD, monitoraggio e revoca d’emergenza?
• Quali rischi residui richiedono approvazione aziendale?

ISO/IEC 27002:2022 fornisce quindi il catalogo dei controlli dell’Appendice A. I controlli più rilevanti includono 5.9 Inventario delle informazioni e degli altri asset associati, 5.15 Controllo degli accessi, 5.16 Gestione delle identità, 5.17 Informazioni di autenticazione, 5.18 Diritti di accesso, 5.19 Sicurezza delle informazioni nei rapporti con i fornitori, 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori, 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT, 5.23 Sicurezza delle informazioni per l’uso di servizi cloud, 5.24 Pianificazione e preparazione della gestione degli incidenti, 5.28 Raccolta delle evidenze, 8.2 Diritti di accesso privilegiati, 8.3 Restrizione dell’accesso alle informazioni, 8.5 Autenticazione sicura, 8.15 Registrazione, 8.16 Attività di monitoraggio, 8.24 Uso della crittografia, 8.25 Ciclo di vita dello sviluppo sicuro, 8.26 Requisiti di sicurezza delle applicazioni, 8.28 Programmazione sicura e 8.31 Separazione degli ambienti di sviluppo, test e produzione.

Zenith Controls: guida alla conformità trasversale di Clarysec Zenith Controls mappa queste relazioni ISO/IEC 27002:2022 in modo utilizzabile da auditor e proprietari dei controlli. Per il controllo 5.16, Gestione delle identità, Zenith Controls spiega il collegamento tra identità e credenziali:

La gestione delle identità fornisce il “chi”, mentre le informazioni di autenticazione garantiscono il “come”, verificando che la persona che dichiara un’identità sia legittima. 5.16 governa la gestione del ciclo di vita dell’identità, mentre 5.17 garantisce che password, token, certificati e altre credenziali siano associati in modo sicuro a tali identità e gestiti correttamente a supporto dell’autenticazione forte.

Questa relazione è essenziale per le NHI. Un token senza un proprietario dell’identità non è verificabile in audit. Un account di servizio senza riesame degli accessi non rispetta il principio del privilegio minimo. Un certificato senza stato del ciclo di vita non è crittografia sotto controllo. Una credenziale di integrazione di un fornitore senza clausole contrattuali non è gestione efficace del rischio di terze parti.

Il modello di controllo Clarysec: identità, segreto, privilegio, evidenza

Clarysec implementa la gestione delle identità non umane e dei segreti attraverso un modello di controllo ripetibile. Non trattiamo i “segreti” come una sola responsabilità DevOps né gli “account di servizio” come una sola responsabilità IAM. Colleghiamo identità, segreto, privilegio ed evidenza.

Il livello delle politiche è il punto in cui tutto questo diventa applicabile.

Per le PMI, la Politica di gestione degli account utente e dei privilegi-sme di Clarysec Politica di gestione degli account utente e dei privilegi-sme stabilisce:

Gli account di servizio (utilizzati da sistemi o applicazioni) devono essere documentati, limitati a sistemi specifici e mai utilizzati per accessi interattivi.

Questo evita il classico anti-pattern in cui un account di servizio diventa un login amministrativo condiviso. Offre inoltre a un auditor un test chiaro: mostrare l’inventario degli account di servizio, mostrare la restrizione al sistema e dimostrare che l’accesso interattivo è disabilitato o tecnicamente impedito.

La Politica di gestione degli asset-sme di Clarysec Politica di gestione degli asset-sme amplia la definizione di asset includendo:

Credenziali e servizi digitali: nomi di dominio, certificati digitali, chiavi API, account e-mail, accessi cloud

Questo è importante perché molte organizzazioni inventariano solo server, laptop e applicazioni. Nel 2026 una chiave API può essere più sensibile di un laptop. La chiave privata di un certificato può essere un asset di autenticazione di produzione. Un accesso cloud usato dall’automazione può creare esposizione di dati regolamentati. Trattare le credenziali come asset è la base di una gestione dei segreti pronta per l’audit.

Per gli ambienti enterprise, la Politica di gestione degli account utente e dei privilegi di Clarysec Politica di gestione degli account utente e dei privilegi innalza il livello delle evidenze:

L’organizzazione deve mantenere un inventario dettagliato di tutte le credenziali attive e inattive, degli account privilegiati e degli account di servizio a livello di sistema. Tale inventario deve essere aggiornato continuativamente e riesaminato trimestralmente.

Il riesame trimestrale è il momento in cui emergono molte lacune. Credenziali inattive, service principal orfani, vecchi utenti di integrazione, account di fornitori non gestiti e token d’emergenza diventano visibili solo quando qualcuno confronta il registro con le registrazioni effettive di IAM, vault, CI/CD e cloud.

I segreti sono informazioni di autenticazione, non una comodità per gli sviluppatori

La frase più pericolosa nella gestione dei segreti è “chiave temporanea”.

Le chiavi temporanee diventano permanenti. Le credenziali di test arrivano in produzione. Il codice sorgente espone token. I log di build espongono password. I team di supporto condividono certificati tramite ticket. Gli sviluppatori copiano file di ambiente nelle chat. Un contraente crea un service principal cloud e poi lascia l’organizzazione.

Zenith Blueprint, fase Controls in Action, Step 22, descrive le informazioni di autenticazione in senso ampio:

Questo controllo non riguarda solo le password, anche se le password fanno certamente parte del quadro. Riguarda ogni credenziale usata per dichiarare un’identità: password, PIN, chiavi crittografiche, template biometrici, smart card, token, certificati, token OAuth, chiavi SSH, segreti API. Sono le chiavi del regno, e il Controllo 5.17 garantisce che tali chiavi siano trattate con la serietà che meritano.

Sia chiaro: una gestione debole dell’autenticazione resta una delle principali cause radice delle violazioni. Password deboli o condivise. Credenziali hardcoded nel codice sorgente. Accessi di default invariati nei portali di amministrazione. Certificati scaduti o con titolarità sconosciuta. In ciascuno di questi casi, non è l’identità ad aver fallito, ma la mancata protezione e governance del meccanismo usato per provare tale identità.

Le politiche Clarysec traducono questo principio in regole operative.

La Politica sui controlli crittografici-sme Politica sui controlli crittografici-sme stabilisce:

Le chiavi non devono essere archiviate in chiaro né incorporate nel codice sorgente, nei documenti o nelle e-mail

La Politica di sviluppo sicuro-sme Politica di sviluppo sicuro-sme stabilisce:

Nessuna credenziale o segreto hardcoded nel codice sorgente

Per i team enterprise, la Politica di sviluppo sicuro Politica di sviluppo sicuro stabilisce:

I segreti non devono essere hardcoded né archiviati in chiaro nei repository.

E la Politica sui requisiti di sicurezza delle applicazioni Politica sui requisiti di sicurezza delle applicazioni è ancora più esplicita:

L’archiviazione di password o chiavi crittografiche in chiaro è rigorosamente vietata.

Queste clausole di policy creano una chiara traccia di audit. I team di sicurezza possono verificare repository, variabili CI/CD, immagini container, archivi di configurazione, sistemi di gestione degli issue, piattaforme documentali e log rispetto a requisiti espliciti. Supportano inoltre Article 32 GDPR sulla sicurezza del trattamento, perché l’esposizione dei segreti può portare direttamente ad accesso non autorizzato ai dati personali.

Anche la governance crittografica enterprise richiede titolarità. La Politica sui controlli crittografici di Clarysec Politica sui controlli crittografici richiede:

Deve essere mantenuto un registro di gestione delle chiavi centralizzato per registrare tutte le chiavi crittografiche, il relativo stato del ciclo di vita, i custodi assegnati e i contesti d’uso.

Per le identità non umane, tale registro dovrebbe collegare chiavi di certificato, chiavi di firma, chiavi API e chiavi gestite nel cloud al più ampio registro NHI. L’auditor dovrebbe poter tracciare un certificato di produzione dal servizio aziendale, al proprietario, al custode, alla scadenza, alle evidenze di rotazione, fino alla procedura di risposta agli incidenti.

NIS2, DORA e GDPR: un solo modello di evidenze, molti regolatori

La governance delle identità non umane è un problema di conformità trasversale perché lo stesso errore può attivare molteplici obblighi.

Un token API trapelato presso un fornitore SaaS può causare interruzione del servizio ai sensi di NIS2, esposizione di dati personali ai sensi di GDPR e obblighi contrattuali di notifica degli incidenti verso clienti finanziari secondo le aspettative DORA sulla catena di fornitura. Un segreto CI/CD compromesso presso un prestatore di servizi ICT può incidere sulla resilienza dei clienti, sull’integrità del software e sulla continuità operativa. Un account di integrazione di un fornitore dimenticato può creare accesso a sistemi regolamentati senza adeguata due diligence o controlli contrattuali.

NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate. Le aree minime comprendono analisi dei rischi, politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione, sviluppo e manutenzione sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi e gestione degli asset e, ove appropriato, MFA o autenticazione continua. Le identità non umane attraversano quasi tutte queste aree. NIS2 Article 23 introduce inoltre una notifica a fasi degli incidenti significativi, con preallarme entro 24 ore, notifica dell’incidente entro 72 ore e relazione finale non oltre un mese dalla notifica dell’incidente.

DORA si applica dal 17 gennaio 2025 e copre gestione del rischio ICT, notifica degli incidenti gravi connessi all’ICT, test di resilienza operativa, condivisione delle informazioni e rischio ICT di terze parti. Articles 5 e 6 richiedono governance, responsabilità dell’organo di gestione e un quadro documentato di gestione del rischio ICT. Article 8 richiede l’identificazione delle funzioni aziendali supportate dall’ICT, degli asset informativi e delle dipendenze. Articles 17 to 19 richiedono gestione, classificazione e notifica degli incidenti. Articles 28 to 30 richiedono gestione del rischio ICT di terze parti, registri contrattuali, due diligence, standard di sicurezza, diritti di audit, supporto agli incidenti, controlli sul subappalto e strategie di uscita.

GDPR si applica ovunque siano trattati dati personali nel suo ambito territoriale. Article 5 richiede integrità, riservatezza e accountability. Article 32 richiede misure tecniche e organizzative adeguate per la sicurezza del trattamento. Se un account di servizio o una chiave API può accedere a dati personali, i segreti non gestiti diventano una carenza dei controlli privacy, non solo un problema IT.

Le stesse evidenze possono supportare la certificazione ISO/IEC 27001:2022, la vigilanza NIS2, gli esami DORA e l’accountability GDPR quando sono strutturate correttamente.

NIST CSF 2.0 può essere usato come livello di comunicazione per le stesse evidenze. La sua funzione GOVERN copre aspettative degli stakeholder, obblighi legali e contrattuali, propensione al rischio, responsabilità della leadership, policy e vigilanza. I suoi esiti operativi coprono inventari degli asset, servizi forniti dai fornitori, gestione delle identità e delle credenziali, principio del privilegio minimo, sicurezza dei dati, logging, monitoraggio, risposta agli incidenti e ripristino.

COBIT 2019 e i team di assurance in stile ISACA guarderanno di norma alla governance e alla capacità di processo. Chiederanno se la responsabilità è assegnata, se i controlli sono incorporati nei processi operativi, se le eccezioni sono approvate, se le metriche sono rendicontate alla direzione e se le evidenze dimostrano ripetibilità invece di una bonifica una tantum.

Uno sprint pratico per creare un registro delle identità non umane

Un incarico Clarysec pratico inizia spesso con uno sprint mirato, non con un programma di adozione strumenti di sei mesi. L’obiettivo è produrre un registro NHI sostenibile in sede di audit, una classificazione del rischio e un piano di remediation che possano alimentare il Piano di trattamento del rischio ISO/IEC 27001:2022 e la Dichiarazione di applicabilità.

Inizia da un servizio aziendale, ad esempio una piattaforma di fatturazione clienti, un’applicazione di trading, un portale pazienti o un sistema di gestione dei tenant SaaS. Includi produzione, ambiente di staging, CI/CD, infrastruttura cloud, strumenti di monitoraggio, banche dati, integrazioni SaaS e servizi gestiti dai fornitori.

Collega questo lavoro a Zenith Blueprint, fase Risk Management, Step 14, in cui Clarysec allinea le politiche di trattamento ai riferimenti normativi trasversali. In quello step, i controlli di sviluppo sicuro e pipeline includono assenza di segreti hardcoded, peer review, analisi statica automatizzata, scansione delle dipendenze, separazione tra sviluppo, test e produzione, MFA per l’accesso alle pipeline, integrità degli artifact di build e registrazione CI/CD.

Raccogli identità e segreti da provider di identità, IAM cloud, vault dei segreti, Kubernetes, variabili CI/CD, impostazioni dei repository, utenti di database, console amministrative SaaS, strumenti di gestione dei certificati e documentazione dei fornitori.

Attribuisci un punteggio di rischio alle identità che hanno accesso all’ambiente di produzione, diritti privilegiati, accesso a dati personali, dipendenza da funzioni critiche o importanti, controllo da parte del fornitore, token longevi, assenza di proprietario, assenza di rotazione, assenza di monitoraggio o archiviazione hardcoded. Usa i criteri di rischio ISO/IEC 27001:2022 per attribuire punteggi a probabilità e impatto. Usa l’analisi delle funzioni critiche o importanti DORA ove applicabile. Usa considerazioni d’impatto GDPR quando sono accessibili dati personali. Usa l’impatto sul servizio NIS2 quando sono plausibili interruzioni o danni ai clienti.

Per ciascuna NHI ad alto rischio, applica azioni di trattamento. Sposta i segreti da codice sorgente, documenti e variabili CI/CD in chiaro verso un vault o un archivio gestito di segreti. Sostituisci gli account di servizio condivisi con identità di workload univoche. Disabilita l’accesso interattivo per gli account di servizio. Applica il principio del privilegio minimo e credenziali specifiche per ambiente. Configura rotazione, scadenza e revoca d’emergenza. Collega i segreti a proprietari e custodi. Aggiungi registrazione per autenticazione, uso dei token e azioni sensibili. Aggiungi allerte per geografia anomala, orario insolito, volume insolito o accesso a nuove risorse. Aggiorna i contratti dei fornitori per gestione delle credenziali, supporto agli incidenti e diritti di audit. Documenta le eccezioni con approvazione del titolare del rischio e data di scadenza.

La Politica sui dati di test e sugli ambienti di test Politica sui dati di test e sugli ambienti di test supporta la separazione degli ambienti:

L’integrazione con le pipeline CI/CD deve imporre la separazione degli ambienti e delle credenziali di autenticazione.

Questa clausola è spesso decisiva. Se sviluppo, test e produzione condividono segreti, un ambiente a basso rischio può diventare un percorso di compromissione verso la produzione.

Lo sprint dovrebbe concludersi con un pacchetto di evidenze, non solo con un elenco di rilievi. Includi l’esportazione del registro NHI, le voci di valutazione del rischio, il piano di trattamento, la mappatura della Dichiarazione di applicabilità, i riferimenti alle politiche, screenshot del vault, log di rotazione, approvazioni dei riesami degli accessi, risultati della scansione dei segreti CI/CD, definizioni delle regole di monitoraggio, matrice delle responsabilità sulle credenziali dei fornitori, runbook di incidente ed eccezioni con proprietari e date di scadenza.

Logging e rilevamento: dimostrare che l’uso delle identità macchina è visibile

Un’identità macchina ben inventariata ma invisibile nei log resta pericolosa. Il rilevamento fa parte della storia del controllo.

La Politica di registrazione e monitoraggio-sme di Clarysec Politica di registrazione e monitoraggio-sme include evidenze di autenticazione:

Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, uso della MFA

Per le NHI, adatta questo requisito all’autenticazione macchina. Potresti non avere l’uso della MFA per un’identità di workload, ma dovresti avere eventi di autenticazione, uso dei token, uso dei certificati, metadati delle chiamate API, workload sorgente, servizio di destinazione, durata del token, eventi di errore e azioni privilegiate.

In Zenith Controls, il controllo ISO/IEC 27002:2022 8.2, Diritti di accesso privilegiati, è collegato a logging e monitoraggio perché gli account privilegiati richiedono registrazioni dettagliate e vigilanza. Zenith Controls collega inoltre 8.2 a gestione delle identità, diritti di accesso, restrizione dell’accesso alle informazioni e autenticazione sicura. Per gli auditor, questo significa che le identità non umane privilegiate dovrebbero essere riesaminate e monitorate con la stessa serietà degli amministratori umani, talvolta maggiore.

Buone domande di monitoraggio includono:

• Un account di servizio si è autenticato da un workload o da un intervallo IP inatteso?
• Una chiave API ha acceduto a un nuovo endpoint o set di dati?
• Un certificato è stato usato dopo la sostituzione?
• Un token CI/CD ha effettuato un deployment fuori da una pipeline approvata?
• Un account in sola lettura ha tentato operazioni di scrittura?
• Una credenziale inattiva è tornata attiva?
• Un’integrazione di un fornitore ha acceduto a dati fuori dagli orari o dai volumi concordati?

Quando si verifica l’allerta delle 02:13, devi rispondere quale identità è stata usata, quale segreto l’ha autenticata, quali diritti di accesso sono stati esercitati, quali dati o sistemi sono stati interessati, se l’attività era prevista, quale proprietario può validarla e se le soglie di notifica degli incidenti sono soddisfatte.

La prospettiva dell’auditor: stesso processo, domande diverse

La posizione di audit più solida non è “siamo conformi a tutto”. È “operiamo un unico processo controllato che produce evidenze per molteplici obblighi”. Auditor diversi ispezioneranno quel processo in modo diverso.

In queste prospettive, i rilievi ricorrenti sono prevedibili: assenza di un inventario NHI unico, assenza di proprietario per le identità macchina, segreti archiviati nel codice o nella documentazione, credenziali condivise tra ambienti, assenza di rotazione o scadenza, credenziali gestite dai fornitori fuori dai riesami degli accessi, monitoraggio che copre gli esseri umani ma non le macchine e runbook di incidente che ignorano la fuoriuscita di segreti.

Ogni rilievo si mappa naturalmente su controlli, politiche e modelli di remediation Clarysec. Ancora più importante, ciascuno può essere convertito in evidenze misurabili all’interno del SGSI.

Come Clarysec ti aiuta a essere pronto per gli audit

L’approccio di Clarysec è pratico perché parte dalle evidenze che gli auditor richiederanno e procede a ritroso verso controlli, politiche e routine operative.

In Zenith Blueprint, fase Controls in Action, Step 19, Clarysec fornisce indicazioni dirette per l’autenticazione machine-to-machine:

Per l’autenticazione machine-to-machine, come account di servizio o chiamate API, chiavi, certificati e token devono essere protetti con lo stesso rigore. Evita di incorporare credenziali nel codice. Usa sistemi di gestione dei segreti o vault per archiviarli e ruotarli in modo sicuro.

Un tipico flusso di lavoro Clarysec sulle identità non umane include il censimento delle NHI in cloud, SaaS, CI/CD, repository, vault e database, valutazione delle lacune di policy rispetto ai set di politiche Clarysec per PMI o enterprise, valutazione del rischio e mappatura del trattamento ISO/IEC 27001:2022, aggiornamenti della Dichiarazione di applicabilità, mappatura delle evidenze NIS2, DORA, GDPR e NIST CSF, progettazione del registro NHI, allineamento del registro di gestione delle chiavi, scansione dei segreti, processi di riesame degli accessi, matrici di responsabilità sulle credenziali dei fornitori, runbook di incidente e pacchetti di audit con screenshot, esportazioni, log, approvazioni e registrazioni delle eccezioni.

Per le PMI, l’approccio è proporzionato. Un fornitore SaaS di 70 persone non ha bisogno dello stesso perimetro di strumenti di una banca globale, ma ha bisogno di titolarità, policy, trattamento del rischio ed evidenze. Per le entità finanziarie regolamentate e i fornitori terzi di servizi ICT, lo stesso modello scala verso la mappatura delle funzioni critiche DORA, la governance del rischio di terze parti e i test di resilienza.

Se il tuo prossimo audit è nel 2026, non aspettare che sia l’auditor a scoprire le identità non umane per te. Parti da un servizio critico e poni cinque domande:

1. Conosciamo ogni account di servizio, chiave API, token, certificato e segreto CI/CD usato da questo servizio?
2. Ogni NHI ha un proprietario nominato, un custode, una finalità e una valutazione del rischio?
3. I segreti sono archiviati in vault, sottoposti a rotazione e protetti da codice sorgente, documenti, e-mail e archiviazione in chiaro?
4. Le identità macchina privilegiate sono riesaminate, monitorate e limitate rispetto all’uso interattivo?
5. Possiamo produrre evidenze per ISO/IEC 27001:2022, NIS2, DORA e GDPR da un unico processo controllato?

Usa Zenith Blueprint: roadmap in 30 passi per l’auditor Zenith Blueprint per strutturare il tuo percorso di implementazione del SGSI. Usa Zenith Controls: guida alla conformità trasversale Zenith Controls per collegare i controlli ISO/IEC 27002:2022 su identità, autenticazione, privilegi, logging, crittografia, sviluppo sicuro e fornitori alle evidenze normative. Usa la libreria di politiche Clarysec per PMI ed enterprise, inclusa la Politica di gestione degli account utente e dei privilegi-sme Politica di gestione degli account utente e dei privilegi-sme, la Politica sui controlli crittografici Politica sui controlli crittografici, la Politica di sviluppo sicuro Politica di sviluppo sicuro e la Politica sui requisiti di sicurezza delle applicazioni Politica sui requisiti di sicurezza delle applicazioni, per trasformare le buone intenzioni in requisiti applicabili.

L’allerta delle 02:13 accadrà da qualche parte. La domanda è se la tua organizzazione saprà rispondere, con evidenze, chi deteneva la chiave, che cosa apriva, perché esisteva e quanto rapidamente puoi metterla in sicurezza.