PAM e account di emergenza per ISO 27001 nel 2026

Alle 02:14 di una domenica mattina, il responsabile della gestione dell’incidente riceve il messaggio che ogni CISO teme: “L’autenticazione in produzione non funziona. La console amministrativa non è raggiungibile. Il failover del database è bloccato.”

L’ingegnere cloud reperibile vede il problema, ma non può risolverlo. Il suo normale ruolo privilegiato dipende dallo stesso provider di identità che ora è degradato. Il responsabile operativo chiede la credenziale amministrativa di emergenza. Il responsabile della conformità chiede se l’account di emergenza sia mai stato testato. Il DPO chiede se l’accesso al database di produzione possa esporre dati personali. Il CISO pone la domanda che determina se l’evento diventerà un ripristino controllato o un incubo in sede di audit:

“Possiamo dimostrare chi ha utilizzato l’accesso di emergenza, perché, cosa ha fatto e che l’account è stato reimpostato dopo l’uso?”

Un’altra organizzazione può affrontare lo stesso problema in una sala più tranquilla. Il CISO di una FinTech siede davanti agli auditor esterni dopo una configurazione errata di un database cloud. L’incidente è stato risolto rapidamente, ma la causa radice non era rassicurante. Uno sviluppatore di terze parti disponeva di privilegi amministrativi permanenti. Quando l’amministratore principale non era disponibile, lo sviluppatore ha utilizzato un account di emergenza basato su una password condivisa archiviata in una nota “sicura” disponibile al team DevOps.

Gli auditor non si sono concentrati solo sulla configurazione errata. Hanno chiesto se l’accesso fosse limitato nel tempo, se esistesse una responsabilità individuale, se i comandi fossero registrati nei log, se i dati personali fossero protetti ai sensi dell’articolo 32 GDPR, se gli obblighi DORA in materia di rischio ICT fossero soddisfatti e se le aspettative NIS2 di igiene cibernetica fossero dimostrabili.

Questo è il vero punto di pressione della Gestione degli accessi privilegiati e degli account di emergenza nel 2026. La PAM non è più un progetto specialistico di sicurezza delle identità. È il punto in cui convergono ransomware, compromissione cloud, rischio dei fornitori, protezione dei dati, resilienza operativa ed evidenze di audit.

L’accesso privilegiato è il punto in cui gli attaccanti cercano di vincere. L’accesso di emergenza è il punto in cui i difensori cercano di ripristinare. Entrambi si fondano sulla stessa capacità pericolosa: un accesso elevato che può eludere i controlli, modificare configurazioni, leggere dati sensibili, ruotare chiavi, disabilitare il logging, ripristinare backup, distribuire codice o distruggere evidenze.

La posizione operativa di Clarysec è semplice: l’accesso di emergenza è necessario, ma l’accesso di emergenza non governato è rischio non governato. La risposta corretta non è “nessun account di emergenza”. La risposta corretta è un modello governato di Gestione degli accessi privilegiati, con inventario, approvazione, limiti temporali, autenticazione forte, registrazione delle sessioni, riesame post-utilizzo, reimpostazione delle credenziali ed evidenze di audit.

Perché l’accesso privilegiato è un tema di conformità a livello di consiglio di amministrazione

Negli ambienti a minore maturità, l’accesso privilegiato è spesso trattato come un’attività di amministrazione IT. Qualcuno ha bisogno di diritti amministrativi, viene aperto un ticket, viene assegnato un ruolo e l’attività prosegue. Questo modello non regge di fronte a ransomware moderni, infrastrutture cloud-native, responsabilità NIS2, resilienza operativa DORA o analisi delle violazioni ai sensi del GDPR.

La direttiva NIS2 porta la governance della cybersecurity nel consiglio di amministrazione. L’articolo 20 richiede agli organi di gestione delle entità essenziali e importanti di approvare le misure di gestione del rischio di cybersecurity, vigilare sulla loro attuazione e seguire formazione sulla cybersecurity. L’articolo 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, comprese analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, efficacia dei controlli, igiene cibernetica, sicurezza HR, controllo degli accessi, gestione degli asset e MFA o autenticazione continua, ove appropriato.

Per provider SaaS, fornitori di servizi gestiti, provider di Managed Security Services, servizi cloud, data center e altre organizzazioni di infrastruttura digitale, l’applicabilità di NIS2 dipende da settore, dimensioni, ruolo, impatto transfrontaliero e stabilimento nell’UE. La lezione operativa è diretta: il controllo degli accessi non è più sepolto in un allegato tecnico. È parte della baseline di igiene cibernetica che la direzione deve approvare, monitorare e correggere.

Per le entità finanziarie, il Digital Operational Resilience Act cambia il linguaggio, ma non il rischio sottostante. DORA si applica dal 17 gennaio 2025 e istituisce un quadro di riferimento uniforme per la gestione del rischio ICT, la segnalazione degli incidenti rilevanti connessi all’ICT, i test di resilienza operativa digitale e la gestione del rischio ICT di terze parti. L’articolo 5 richiede assetti di governance e controllo per il rischio ICT, con l’organo di gestione che definisce, approva, vigila ed è responsabile degli assetti di rischio ICT. L’articolo 6 richiede un quadro documentato di gestione del rischio ICT con politiche, procedure, protocolli e strumenti per proteggere gli asset ICT. L’articolo 17 richiede un processo di gestione degli incidenti connessi all’ICT che rilevi, registri, classifichi, segnali e ripristini operazioni sicure.

Il GDPR aggiunge la prospettiva della tutela della privacy e della responsabilizzazione. L’articolo 5(1)(f) richiede che i dati personali siano trattati con integrità e riservatezza. L’articolo 5(2) richiede responsabilizzazione. L’articolo 25 richiede protezione dei dati fin dalla progettazione e per impostazione predefinita. L’articolo 32 richiede misure tecniche e organizzative adeguate per la sicurezza del trattamento. Se un utente privilegiato può esportare registrazioni dei clienti, accedere a categorie particolari di dati, disabilitare i log di audit o modificare le impostazioni di conservazione senza riesame, l’organizzazione non ha semplicemente commesso un errore IAM. Potrebbe non essere in grado di dimostrare una sicurezza adeguata.

ISO/IEC 27001:2022 è la struttura portante del sistema di gestione che consente di gestire questi obblighi tramite un programma integrato. La clausola 4.2 richiede all’organizzazione di comprendere le parti interessate e i relativi requisiti, inclusi obblighi legali, normativi e contrattuali. La clausola 5.1 richiede leadership e impegno. La clausola 6.1.2 richiede la valutazione del rischio per la sicurezza delle informazioni. La clausola 6.1.3 richiede il trattamento del rischio. La clausola 8 richiede pianificazione e controllo operativi.

Per l’accesso privilegiato, questo sposta la conversazione da “quale strumento PAM dobbiamo acquistare?” a “quali rischi stiamo trattando, quali controlli sono selezionati, chi ne è il proprietario, come sono gestiti operativamente e quali evidenze dimostrano che funzionano?”

La PAM non è un singolo controllo, è una catena di evidenze

Uno strumento PAM può custodire password in un vault, mediare sessioni, registrare sequenze di tasti, ruotare credenziali e applicare accesso just-in-time. Queste capacità sono importanti. Tuttavia, se l’organizzazione non ha definito i ruoli privilegiati, approvato l’accesso di emergenza, mappato gli accessi agli asset, riesaminato i diritti, protetto i log e formato gli amministratori, lo strumento diventa un controllo parziale con debole sostenibilità in sede di audit.

Il modo più utile per governare l’accesso privilegiato è ragionare in termini di esiti dei controlli, non di nomi degli strumenti.

La Zenith Controls: The Cross-Compliance Guide Zenith Controls considera il controllo ISO/IEC 27002:2022 8.2, Diritti di accesso privilegiato, come il baricentro della PAM. Classifica questo controllo come preventivo, a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cybersecurity Protect, alla capacità operativa Gestione delle identità e degli accessi e al dominio di sicurezza Protection.

Il controllo 8.2 è potente perché si collega ai controlli circostanti che rendono verificabile l’accesso privilegiato:

Per questo motivo un auditor raramente si ferma alla domanda: “Avete un sistema PAM?” Le domande di audit più solide sono: avete un inventario degli account privilegiati? I ruoli privilegiati sono approvati? I diritti sono limitati nel tempo? Le credenziali di emergenza sono protette? Potete dimostrare chi le ha utilizzate? I comandi sono registrati nei log? Gli amministratori dei fornitori sono inclusi? I diritti di accesso sono riesaminati? Le credenziali sono state reimpostate? Le eccezioni sono state accettate a rischio?

La mappatura dei diritti di accesso di Zenith Controls lo esprime direttamente: la gestione dei diritti di accesso rende operativi i principi di controllo degli accessi quali principio del privilegio minimo, principio del need-to-know e autorizzazione, mentre gli account privilegiati richiedono un controllo speciale e una revoca tempestiva quando non sono più necessari.

Requisiti di policy per un accesso di emergenza affidabile

Un account di emergenza non è una password amministrativa condivisa in una busta sigillata. Nel 2026, quel modello è troppo debole per cloud, fintech, SaaS, sanità, servizi gestiti e operazioni digitali regolamentate.

Un modello di emergenza difendibile richiede sette regole minime di policy:

1. L’account deve essere documentato.
2. L’account deve essere approvato.
3. L’uso deve essere attribuibile in modo univoco ove tecnicamente possibile.
4. L’uso deve essere limitato a emergenze reali.
5. L’uso deve essere registrato nei log e riesaminato.
6. Le credenziali o i fattori di autenticazione devono essere reimpostati o ruotati dopo l’uso.
7. L’account deve essere testato e incluso nell’ambito di audit.

La libreria di policy Clarysec traduce questi principi in linguaggio di governance utilizzabile.

La User Account and Privilege Management Policy-sme Politica di gestione degli account utente e dei privilegi - SME stabilisce:

“L’accesso di emergenza, ad esempio gli account amministrativi di emergenza, deve essere chiaramente documentato, protetto e utilizzato solo quando assolutamente necessario.”

Dalla sezione “Trattamento del rischio ed eccezioni”, clausola di policy 7.3.1.

La stessa policy SME prosegue:

“Tali account devono essere registrati nei log, riesaminati dopo l’uso e reimpostati dopo ogni evento di emergenza.”

Dalla sezione “Trattamento del rischio ed eccezioni”, clausola di policy 7.3.2.

Per l’elevazione quotidiana dei privilegi, la policy SME richiede inoltre:

“I privilegi elevati o amministrativi richiedono un’ulteriore approvazione da parte del Direttore generale o del Referente IT e devono essere documentati, limitati nel tempo e soggetti a riesame periodico.”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.2.2.

Per le organizzazioni più grandi, l’insieme di policy enterprise approfondisce ulteriormente. La User Account and Privilege Management Policy Politica di gestione degli account utente e dei privilegi richiede che:

“Le sessioni privilegiate devono essere registrate integralmente nei log, compresi i comandi impartiti e le azioni eseguite. I log devono essere riesaminati periodicamente da revisori designati.”

Dalla sezione “Requisiti di applicazione della policy”, clausola di policy 6.4.2.

La stessa policy richiede che gli account temporanei o di emergenza per l’accesso privilegiato seguano una procedura di emergenza documentata nella clausola 6.2.5, mentre la clausola 7.4 definisce i requisiti di tale procedura.

La Access Control Policy Politica di controllo degli accessi rafforza la conservazione ai fini di audit:

“Le decisioni di approvazione devono essere registrate nei log e conservate ai fini di audit per un minimo di 2 anni.”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.2.

La Logging and Monitoring Policy-sme Politica di logging e monitoraggio - SME identifica le aspettative di logging dell’autenticazione:

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

Dalla sezione “Requisiti di governance”, clausola di policy 5.4.2.

Nel loro insieme, queste clausole trasformano l’accesso di emergenza da soluzione eroica a evento controllato. L’account è eccezionale, ma la governance non lo è.

L’approccio Zenith Blueprint all’attuazione della PAM

La Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint tratta l’accesso privilegiato come un problema pratico di attuazione, non come una dichiarazione teorica di controllo. Nella fase Controls in Action, Step 19, Technological Controls I, afferma:

“In qualsiasi sistema informativo, l’accesso privilegiato è potere e a tale potere si accompagna il rischio.”

Dalla fase Controls in Action, Step 19: Technological Controls I.

Lo Step 19 richiede alle organizzazioni di identificare gli account privilegiati in ambienti on-premises, cloud, SaaS, di sviluppo e infrastrutturali. Include amministratori di dominio, utenti root, amministratori dei tenant cloud, superuser di database e controller delle pipeline CI/CD. Sottolinea inoltre la necessità di minimizzare l’accesso privilegiato tramite Controllo degli accessi basato sui ruoli (RBAC), elevazione just-in-time e flussi di approvazione.

Questo è importante perché molti incidenti gravi non iniziano con l’account formale di emergenza. Iniziano con un privilegio permanente. Un ingegnere cloud mantiene diritti di proprietario “per ogni evenienza”. Un amministratore di database conserva l’accesso all’ambiente di produzione dopo un trasferimento di team. Un account di servizio CI/CD dispone di autorizzazioni estese su più ambienti. Un account di un fornitore di servizi gestiti è esentato dalla MFA perché “serve accesso rapido”.

Lo Step 20 della Zenith Blueprint estende lo stesso ragionamento alle utilità privilegiate. Indica alle organizzazioni di creare o aggiornare un inventario delle utilità privilegiate, limitarne l’esecuzione agli amministratori autorizzati, verificare che l’uso sia registrato nei log e generi alert, e considerare la registrazione degli script, ad esempio la registrazione PowerShell tramite criteri di gruppo. Questo è critico perché un account privilegiato è spesso solo il punto di ingresso. Il danno si verifica quando l’attaccante esegue strumenti che disabilitano controlli, estraggono credenziali o consentono movimento laterale.

Lo Step 22 formalizza il ciclo di vita del controllo degli accessi. Richiede provisioning e deprovisioning strutturati, idealmente integrati con HR e supportati da flussi di richiesta di accesso, con riesami degli accessi trimestrali documentati. Lo Step 16 collega il ciclo di vita all’offboarding richiedendo una checklist di cessazione del dipendente utilizzata congiuntamente da HR e IT, comprendente disabilitazione degli account, restituzione degli asset e promemoria NDA.

La Zenith Blueprint rende la PAM un modello operativo connesso: identità, HR, utilità privilegiate, logging, risposta agli incidenti, riesami degli accessi ed evidenze di audit si rafforzano reciprocamente.

Un modello pratico di governance dell’accesso di emergenza per il 2026

Un processo di emergenza ben progettato deve funzionare durante il guasto. Se dipende dallo stesso provider di identità, dalla stessa piattaforma di ticketing e dallo stesso servizio di chat non disponibili durante l’interruzione, è solo una simulazione.

Allo stesso tempo, l’accesso di emergenza non può diventare un canale di bypass per comodità. Clarysec progetta normalmente la governance dell’accesso di emergenza su quattro livelli: prevenzione, attivazione, osservazione e ripristino.

Per gli ambienti cloud, includere amministratori a livello di tenant, account root cloud, amministratori di emergenza del provider di identità, account di servizio privilegiati, utenti master dei database, ruoli cluster-admin Kubernetes, chiavi di deployment CI/CD, amministratori dei vault dei segreti e account di supporto di terze parti.

Per gli ambienti ibridi, includere amministratori di dominio, amministratori dei backup, amministratori degli hypervisor, amministratori dei firewall, amministratori della console EDR e utenti di utilità privilegiate.

Per gli ambienti sensibili alla privacy, includere gli amministratori che possono accedere a banche dati contenenti dati personali, log contenenti identificativi, registrazioni HR, dati biometrici di verifica dell’identità, sistemi di monitoraggio delle frodi o strumenti di assistenza clienti.

Lo stato obiettivo è semplice da descrivere e difficile da simulare: ogni percorso di emergenza è noto, approvato, protetto, osservabile, reversibile e riesaminato.

Un’esercitazione di 60 minuti sulle evidenze dell’accesso di emergenza

Un CISO o un responsabile della conformità può eseguire questa settimana un’esercitazione utile sull’accesso di emergenza senza acquistare un nuovo strumento. L’obiettivo non è solo confermare che l’account funzioni. L’obiettivo è dimostrare che il controllo produce evidenze.

Scenario

Si assuma che il provider di identità principale sia degradato. L’elevazione just-in-time ordinaria non è disponibile. Un cluster di database di produzione necessita di modifiche di configurazione di emergenza per ripristinare il servizio. L’account amministratore cloud di emergenza deve essere attivato.

Step 1: confermare che l’account sia nell’inventario privilegiato

Utilizzare la Zenith Blueprint, fase Controls in Action, Step 19, per validare che l’account compaia nell’inventario degli account privilegiati. Registrare nome dell’account e ambiente, titolare dell’attività, proprietario tecnico, sistemi raggiungibili, impatto sui dati personali, metodo di autenticazione, posizione del vault, metodo di rotazione e data dell’ultimo test.

Se l’account manca, trattarlo come una lacuna nei controlli e aggiungerlo al Registro dei rischi.

Step 2: verificare l’allineamento alle policy

Mappare l’evento ai requisiti della Politica di gestione degli account utente e dei privilegi per le procedure di emergenza documentate e la registrazione delle sessioni privilegiate. Se siete una PMI, utilizzare le clausole 7.3.1 e 7.3.2 della User Account and Privilege Management Policy-sme come baseline minima: documentato, protetto, necessario, registrato nei log, riesaminato e reimpostato.

Mappare la conservazione delle approvazioni alla clausola 5.3.2 della Politica di controllo degli accessi, che richiede che le decisioni di approvazione siano registrate nei log e conservate per almeno 2 anni.

Step 3: aprire una registrazione di accesso di emergenza

Creare un ticket o una registrazione di incidente prima dell’attivazione o al momento dell’attivazione. Includere:

• Motivo dell’emergenza
• Servizio interessato
• Account richiesto
• Richiedente
• Approvatore
• Ora di inizio
• Ora di fine prevista
• Impatto sul cliente o normativo
• Impatto GDPR sui dati personali
• Flag di attenzione per la segnalazione NIS2 o DORA

Non attendere la fine per ricostruire la storia. Il valore ai fini di audit è più forte quando la registrazione inizia prima che l’accesso venga utilizzato.

Step 4: attivare e osservare

Attivare l’account di emergenza. Confermare che siano utilizzati MFA o autenticazione compensativa, che la sessione sia registrata, che i comandi o le azioni amministrative siano registrati nei log, che i log siano inoltrati alla piattaforma di logging centralizzata, che la sincronizzazione temporale supporti la ricostruzione della cronologia e che venga generato un alert per l’uso dell’account di emergenza.

Questo è allineato con Zenith Controls per 8.15 Logging, che descrive il logging come livello dati fondamentale per il monitoraggio e rileva che gli utenti privilegiati e l’esecuzione di utilità privilegiate devono essere registrati nei log in modo completo.

Step 5: chiudere, reimpostare e riesaminare

Dopo l’attività di emergenza, disabilitare l’account o riportarlo allo stato sigillato, ruotare le credenziali o reimpostare il fattore di autenticazione, riesaminare i log di sessione, documentare comandi e modifiche di configurazione, confermare che non si sia verificato accesso non necessario ai dati, aggiornare la registrazione dell’incidente, registrare le lezioni apprese e decidere se siano attivate le soglie di notifica NIS2, DORA o GDPR.

Se sono stati consultati dati personali, coinvolgere il DPO. Se l’evento ha causato un’interruzione del servizio o potrebbe causare un impatto materiale, coinvolgere il responsabile della segnalazione NIS2 o DORA. Se l’account di emergenza ha fallito, documentarlo come risultanza di resilienza operativa, non semplicemente come problema IAM.

Mappatura di conformità incrociata per controlli PAM e di accesso di emergenza

Il modello di governance più solido non duplica i controlli per ogni regolamento. Costruisce una catena unica di evidenze che supporta più obblighi.

NIST CSF 2.0 è particolarmente utile quando si traduce la PAM in un Current Profile e in un Target Profile. Il suo metodo basato sui profili parte dall’ambito di applicazione, quindi raccoglie policy, priorità di rischio, registri, requisiti, pratiche e ruoli lavorativi, prima di creare un piano d’azione prioritizzato. Per l’accesso privilegiato, ciò significa circoscrivere il profilo alla sicurezza delle identità, all’amministrazione cloud, alla resilienza al ransomware, ai sistemi finanziari critici o all’accesso dei fornitori.

Per le entità finanziarie soggette a DORA, DORA funge da regime settoriale dell’UE per la resilienza cibernetica in relazione a obblighi equivalenti NIS2 su rischio e incidenti. Ciò non rende NIS2 irrilevante. Significa che l’entità finanziaria deve utilizzare DORA come regime di riferimento per i requisiti di rischio ICT e di incidente, mantenendo il coordinamento con le strategie nazionali di cybersecurity, le autorità competenti e i CSIRT ove applicabile.

Come gli auditor testano le evidenze dell’accesso privilegiato

Gli auditor non valutano la PAM solo leggendo la policy. Triangolano policy, configurazione, log, ticket, interviste e prassi osservata.

La metodologia di audit di Zenith Controls per i diritti di accesso privilegiato richiama le pratiche di audit ISO/IEC 19011:2018. Gli auditor riesaminano le policy che definiscono diritti elevati, procedure di provisioning, monitoraggio e revoca. Esaminano inventari degli account utente, registrazioni delle assegnazioni di privilegi e log. Corroborano le evidenze tramite interviste, strumenti PAM, servizi di directory e campioni di log.

Per i diritti di accesso, Zenith Controls osserva che gli auditor campionano le richieste di accesso degli utenti, verificano le approvazioni documentate e confermano che l’IT abbia assegnato solo gli accessi approvati. Confrontano inoltre i ruoli degli utenti con i diritti effettivi, verificando se il principio del privilegio minimo sia applicato. Per il logging, gli auditor esaminano ambito della registrazione, tipi di evento, periodi di conservazione, protezioni e voci di log effettive. Valutano se accessi non riusciti, accesso a dati sensibili e modifiche di configurazione siano rilevati e riesaminati.

Un buon pacchetto di evidenze per l’accesso di emergenza include:

• Richiesta di accesso di emergenza approvata
• Contesto dell’incidente o dell’interruzione
• Identità dell’utente che attiva l’accesso
• Identità dell’approvatore
• Ora di inizio e di fine
• Evidenza MFA o di autenticazione
• Registrazione della sessione o log dei comandi
• Log di sistema e alert SIEM
• Modifiche effettuate
• Conferma della reimpostazione delle credenziali
• Riesame post-utilizzo
• Valutazione dell’accesso ai dati
• Valutazione della notifica normativa
• Azioni correttive se qualcosa non ha funzionato

Se la vostra esercitazione non può produrre questo pacchetto, il controllo non è pronto per l’audit.

Il fallimento nascosto: accesso privilegiato di terze parti

Molte organizzazioni governano gli amministratori dipendenti meglio degli amministratori dei fornitori. Per ambienti cloud, SaaS, fintech e servizi gestiti, è l’opposto di ciò che serve.

L’articolo 21 NIS2 include sicurezza della catena di fornitura e rapporti con fornitori diretti e prestatori di servizi. Gli articoli 28 to 30 DORA vanno oltre per le entità finanziarie, richiedendo strategia di rischio ICT di terze parti, registri dei contratti di servizi ICT, due diligence, valutazione del rischio di concentrazione, diritti di audit, diritti di risoluzione, strategie di uscita e misure di sicurezza contrattuali.

L’accesso privilegiato dei fornitori deve rientrare nell’ambito PAM se il fornitore può amministrare la produzione, supportare funzioni critiche o importanti, accedere a dati personali, modificare configurazioni di sicurezza, gestire backup, distribuire codice o operare strumenti di monitoraggio.

Clarysec si aspetta normalmente che i controlli sugli accessi privilegiati dei fornitori includano:

• Utenti dei fornitori nominativi, non account condivisi dei fornitori
• Requisiti contrattuali di sicurezza per l’accesso privilegiato
• MFA e accesso remoto sicuro
• Finestre di accesso limitate nel tempo
• Approvazione del cliente per l’accesso di emergenza
• Registrazione delle sessioni o tracce di audit equivalenti
• Revoca immediata in caso di cambiamento del personale
• Obblighi di cooperazione sugli incidenti
• Conservazione delle evidenze allineata alle esigenze di audit del cliente
• Piano di uscita per rimuovere l’accesso del fornitore

Gli esiti NIST CSF 2.0 relativi alla catena di fornitura sono fortemente allineati. Richiedono ruoli e responsabilità dei fornitori, prioritizzazione dei fornitori per criticità, requisiti nei contratti, due diligence, monitoraggio continuo, coinvolgimento dei fornitori nella pianificazione degli incidenti e piani di rischio post-contratto.

Se un account di un fornitore di servizi gestiti è esentato dal vostro flusso PAM interno, non è una comodità. È un’eccezione ad alto rischio che deve stare nel Registro dei rischi, nel Registro dei fornitori e nel riesame degli accessi.

Risultanze PAM e di accesso di emergenza comuni nel 2026

Negli incarichi Clarysec, le risultanze raramente sorprendono. Di solito sono combinazioni di buone intenzioni, pressione operativa ed evidenze incomplete.

Le risultanze più comuni sono:

• Gli account di emergenza esistono ma non sono elencati nell’inventario degli account privilegiati.
• Gli account di emergenza sono esclusi dai riesami ordinari degli accessi.
• L’organizzazione non può dimostrare chi ha utilizzato un account di emergenza.
• L’account non è stato reimpostato dopo l’uso.
• Le sessioni privilegiate sono registrate nei log, ma i comandi no.
• I log esistono localmente ma non sono protetti dagli utenti privilegiati.
• Gli account root cloud non sono testati.
• I processi di recupero MFA non sono documentati.
• L’accesso privilegiato per pipeline CI/CD e account di servizio è ignorato.
• L’accesso di supporto di terze parti bypassa l’approvazione interna.
• L’approvazione dell’accesso esiste in messaggi di chat ma non è conservata come evidenza di audit.
• L’offboarding rimuove e-mail e VPN ma non i diritti di amministratore SaaS.
• Il DPO non è coinvolto quando l’accesso privilegiato può esporre dati personali.
• I playbook di incidente non includono punti decisionali di notifica NIS2, DORA o GDPR.

Ogni risultanza può essere gestita tramite il trattamento del rischio ISO/IEC 27001:2022. Identificare il rischio, assegnare un proprietario, selezionare i controlli, aggiornare la Dichiarazione di Applicabilità, attuare il piano di trattamento e conservare evidenze documentate. Questo è il valore di utilizzare un SGSI invece di una serie dispersa di attività di sicurezza.

Come si presenta un buon modello

Un modello operativo maturo di PAM e accesso di emergenza prevede cinque routine ricorrenti.

Primo, inventariare l’accesso privilegiato mensilmente o in modo continuo. Includere amministratori umani, account di servizio, account di emergenza, ruoli cloud, identità CI/CD, utenti di database, utilità privilegiate e amministratori di terze parti.

Secondo, applicare il principio del privilegio minimo tramite ruoli, elevazione just-in-time e approvazioni. I privilegi permanenti devono essere rari, giustificati e riesaminati più frequentemente degli accessi utente standard.

Terzo, monitorare il comportamento privilegiato. Registrare autenticazione, durata della sessione, uso della MFA, comandi, modifiche di configurazione, esportazioni di dati, tentativi non riusciti, elevazione dei privilegi ed esecuzione di utilità privilegiate.

Quarto, testare gli account di emergenza prima dell’emergenza. Un account di emergenza mai testato è un’ipotesi, non un controllo.

Quinto, riferire alla direzione. NIS2 e DORA elevano entrambe la cybersecurity e il rischio ICT a responsabilità dell’organo di gestione. Il Consiglio di amministrazione non ha bisogno di ogni log dei comandi, ma ha bisogno di metriche: numero di account privilegiati, riesami scaduti, attivazioni di emergenza, account amministrativi dei fornitori, test falliti, eccezioni critiche e stato della remediation.

È qui che il toolkit Clarysec diventa pratico. La libreria di policy fornisce il linguaggio di governance. La Zenith Blueprint fornisce la sequenza di attuazione. Zenith Controls fornisce la mappatura di conformità incrociata, le relazioni tra controlli, gli standard di supporto e la metodologia di audit.

Prossimi passi: trasformare l’accesso di emergenza in resilienza pronta per l’audit

Se la vostra organizzazione non ha testato l’accesso di emergenza negli ultimi 90 giorni, iniziate da lì. Non iniziate con un workshop di selezione degli strumenti. Iniziate dalle evidenze.

1. Costruite o aggiornate il vostro inventario degli account privilegiati.
2. Identificate ogni account di emergenza e ogni percorso amministrativo di emergenza.
3. Mappate ogni account al titolare dell’attività, al proprietario del sistema e all’impatto sui dati.
4. Confermate la copertura delle policy utilizzando la Politica di gestione degli account utente e dei privilegi Politica di gestione degli account utente e dei privilegi di Clarysec oppure la User Account and Privilege Management Policy-sme Politica di gestione degli account utente e dei privilegi - SME.
5. Utilizzate la Zenith Blueprint Zenith Blueprint, fase Controls in Action, Step 19, 20, 22 e 16, per collegare accesso privilegiato, utilità privilegiate, riesami del ciclo di vita e offboarding.
6. Utilizzate Zenith Controls Zenith Controls per mappare i controlli ISO/IEC 27002:2022 8.2, 5.18 e 8.15 alle aspettative di evidenza di NIS2, DORA, GDPR e NIST.
7. Eseguite un’esercitazione sulle evidenze dell’accesso di emergenza e registratene i risultati.
8. Aggiungete le lacune al Piano di trattamento del rischio e tracciate la remediation fino alla chiusura.

L’accesso privilegiato è potere. L’accesso di emergenza è potere di emergenza. Nel 2026, le organizzazioni che si riprenderanno in modo pulito da ransomware, indisponibilità cloud e guasti delle identità saranno quelle in grado di dimostrare che l’accesso di emergenza era controllato prima, durante e dopo la crisi.

Clarysec può aiutarvi a costruire questa dimostrazione, dalla policy alla mappatura dei controlli fino alle evidenze pronte per l’audit. Iniziate con la Zenith Blueprint, affiancatela alla Politica di gestione degli account utente e dei privilegi e alla Politica di controllo degli accessi, quindi utilizzate Zenith Controls per mostrare in che modo il vostro programma PAM supporta ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.