Guida alle evidenze di audit per il controllo degli accessi ISO 27001

Sono le 09:10 del giorno dell’audit. Maria, CISO di una FinTech e piattaforma cloud in rapida crescita, ha davanti a sé la politica di controllo degli accessi. Il referente IT sta esportando le impostazioni di accesso condizionale dal provider di identità. HR sta cercando il ticket di cessazione di un analista dell’area finanza che ha lasciato l’azienda sei settimane prima. L’auditor interno alza lo sguardo e pone la domanda che tutti sapevano sarebbe arrivata:

“Mostratemi come l’accesso viene richiesto, approvato, applicato, riesaminato e rimosso per un utente con accesso privilegiato a dati personali.”

Quella singola frase può rivelare se un programma di controllo degli accessi è pronto per l’audit o soltanto pronto sulla carta.

Il team di Maria disponeva di un Sistema di gestione della sicurezza delle informazioni maturo, di un ciclo annuale di ricertificazione ISO/IEC 27001:2022, di autenticazione a più fattori implementata, di controlli degli accessi basati sui ruoli nei sistemi core e di fogli di calcolo trimestrali per il riesame degli accessi. Ma questo audit era diverso. L’elenco delle richieste dell’auditor includeva la preparazione a requisiti normativi emergenti. Per l’organizzazione di Maria, ciò significava NIS2, DORA e GDPR, tutti esaminati attraverso la stessa prospettiva operativa: identità, accesso, autenticazione, privilegio ed evidenze.

Il problema che molti CISO devono affrontare non è l’assenza del controllo degli accessi. Il problema è che le evidenze sono frammentate. Le approvazioni di onboarding risiedono in Jira o ServiceNow. Le impostazioni MFA sono in Microsoft Entra ID, Okta o in un altro provider di identità. Le autorizzazioni AWS, Azure e Google Cloud si trovano in console separate. Le azioni privilegiate possono essere registrate in uno strumento PAM, oppure non esserlo affatto. Lo stato HR è in BambooHR, Workday o in fogli di calcolo. I riesami degli accessi possono essere approvati via e-mail.

Quando un auditor collega IAM, MFA, PAM, eventi Joiner-Mover-Leaver, dati personali, amministrazione cloud e aspettative normative, le evidenze frammentate cedono rapidamente.

Gli audit del controllo degli accessi ISO/IEC 27001:2022 non sono semplici revisioni della configurazione tecnica. Sono verifiche del sistema di gestione. Accertano se i rischi relativi a identità e accessi sono compresi, trattati, attuati, monitorati e migliorati. Quando sono rilevanti anche NIS2, DORA e GDPR, le stesse evidenze devono dimostrare governance degli accessi basata sul rischio, autenticazione forte, approvazioni tracciabili, revoca tempestiva, limitazione dei privilegi, protezione dei dati personali e responsabilità della direzione.

La risposta pratica non è un raccoglitore più grande. È un unico modello di evidenze del controllo degli accessi che parte dal campo di applicazione del SGSI e dal rischio, attraversa la progettazione di policy e controlli, si concretizza negli strumenti IAM e PAM e si mappa in modo chiaro a ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST e COBIT.

Perché il controllo degli accessi è il perno normativo

Il controllo degli accessi è diventato un tema da consiglio di amministrazione e da interlocuzione con le autorità perché la compromissione delle identità è ormai un percorso comune verso interruzioni operative, violazioni dei dati, frodi ed esposizione della supply chain.

Ai sensi di NIS2, gli articoli 2 e 3, letti con l’Allegato I e l’Allegato II, includono nel campo di applicazione molte entità di medie e grandi dimensioni nei settori elencati come entità essenziali o importanti. Ciò comprende l’infrastruttura digitale e i fornitori di gestione dei servizi ICT, quali fornitori di servizi di cloud computing, fornitori di servizi di data center, prestatori di servizi gestiti e prestatori di servizi di sicurezza gestiti. Gli Stati membri erano tenuti a recepire NIS2 entro ottobre 2024 e ad applicare le misure nazionali da ottobre 2024, con elenchi delle entità previsti per aprile 2025. Article 20 rende gli organi di gestione responsabili dell’approvazione delle misure di gestione del rischio di cibersicurezza e della supervisione della loro attuazione. Article 21 richiede misure tecniche, operative e organizzative, comprese politiche di controllo degli accessi, gestione degli asset, igiene informatica, gestione degli incidenti, continuità operativa, sicurezza della supply chain e MFA o autenticazione continua ove appropriato.

DORA aggiunge un livello di resilienza operativa specifico per il settore finanziario per le entità finanziarie e i relativi fornitori terzi di servizi ICT. Gli articoli 1, 2 e 64 stabiliscono DORA come quadro uniforme applicabile dal 17 gennaio 2025. Gli articoli 5 e 6 richiedono governance e un quadro documentato di gestione dei rischi ICT. Article 9 riguarda protezione e prevenzione, comprese politiche, procedure, protocolli e strumenti di sicurezza ICT. Gli articoli da 24 a 30 aggiungono il test della resilienza operativa digitale e la gestione del rischio ICT di terze parti. Per le entità finanziarie, le evidenze del controllo degli accessi diventano evidenze di resilienza, non soltanto evidenze di amministrazione IT.

GDPR introduce la prospettiva dei dati personali. Gli articoli 2 e 3 definiscono un’ampia applicabilità al trattamento nell’UE e alla presenza sul mercato dell’UE. Article 5 richiede integrità, riservatezza e responsabilizzazione dimostrabile. Article 25 richiede protezione dei dati fin dalla progettazione e per impostazione predefinita. Article 32 richiede misure tecniche e organizzative adeguate. In pratica, ciò significa accesso controllato, autenticazione sicura, logging, riesame e rimozione tempestiva per i sistemi che trattano dati personali.

ISO/IEC 27001:2022 fornisce alle organizzazioni il motore del sistema di gestione per unificare questi obblighi. Le clausole da 4.1 a 4.3 richiedono all’organizzazione di comprendere contesto, parti interessate, requisiti legali e contrattuali, interfacce, dipendenze e campo di applicazione del SGSI. Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio per la sicurezza delle informazioni, trattamento del rischio, confronto con l’Allegato A, una Dichiarazione di Applicabilità e l’approvazione dei piani di trattamento e del rischio residuo. La clausola 8.1 richiede controllo operativo, informazioni documentate che dimostrino che i processi si sono svolti come pianificato, controllo delle modifiche e controllo dei processi affidati all’esterno.

La domanda di audit quindi non è “Avete la MFA?” È “Potete dimostrare, per le identità e i sistemi nel campo di applicazione, che il rischio di accesso è governato, trattato, attuato, monitorato e migliorato?”

Costruire la dorsale delle evidenze dal campo di applicazione del SGSI alla prova IAM

Clarysec avvia la preparazione dell’audit sul controllo degli accessi rendendo le evidenze tracciabili a partire dal contesto aziendale. ISO/IEC 27001:2022 si aspetta che il SGSI sia integrato nei processi dell’organizzazione e dimensionato in base alle esigenze dell’organizzazione. Un fornitore SaaS di 30 persone e una banca multinazionale non avranno la stessa architettura degli accessi, ma entrambi hanno bisogno di una catena di evidenze coerente.

ISO/IEC 27005:2022 è utile perché raccomanda di consolidare requisiti legali, normativi, contrattuali, settoriali e interni in un contesto di rischio comune. Le clausole 6.4 e 6.5 enfatizzano criteri di rischio che considerano obiettivi dell’organizzazione, leggi, rapporti con i fornitori e vincoli. Le clausole 7.1 e 7.2 consentono scenari basati su eventi e su asset. Per il controllo degli accessi, ciò significa valutare scenari strategici come “amministratore SaaS privilegiato esporta dati di clienti UE” insieme a scenari relativi agli asset, come “chiave AWS IAM orfana associata allo storage di produzione”.

Nel Zenith Blueprint: roadmap in 30 passaggi per auditor di Clarysec, questa dorsale di evidenze viene costruita durante la fase Controls in Action. Lo Step 19 si concentra sui controlli tecnologici per la gestione degli endpoint e degli accessi, mentre lo Step 22 formalizza il ciclo di vita organizzativo degli accessi.

Il Zenith Blueprint indica ai team di verificare che provisioning e deprovisioning siano strutturati, integrati con HR ove possibile, supportati da workflow di richiesta di accesso e riesaminati trimestralmente. Indica inoltre alle organizzazioni di documentare i tipi di identità, applicare controlli per identità individuali, condivise e di servizio, adottare policy robuste per password e MFA, eliminare gli account inattivi e mantenere vault sicuri o documentazione protetta per le credenziali di servizio.

È esattamente così che gli auditor testano il controllo degli accessi: un’identità, un sistema, un’approvazione, un privilegio, un riesame e una revoca alla volta.

Che cosa raccogliere per evidenze del controllo degli accessi pronte per l’audit

Il pacchetto di evidenze del controllo degli accessi deve consentire a un auditor di campionare qualsiasi utente e ricostruirne il ciclo di vita: richiesta, approvazione, assegnazione, autenticazione, elevazione privilegiata, monitoraggio, riesame e revoca.

Un pacchetto di evidenze solido include:

1. Politica di controllo degli accessi e politica degli account utente
2. Procedura Joiner-Mover-Leaver
3. Matrice dei ruoli o matrice di controllo degli accessi
4. Elenco di applicazioni, piattaforme e repository di dati nel campo di applicazione
5. Configurazione MFA del provider di identità
6. Policy di accesso condizionale ed elenco delle eccezioni
7. Inventario degli account privilegiati
8. Evidenze dei workflow PAM, incluse approvazioni e log di sessione
9. Output recente della campagna di riesame degli accessi
10. Esempi di attestazioni dei manager e azioni di remediation
11. Report HR delle cessazioni riconciliato con i log di disattivazione
12. Inventario degli account di servizio, titolari, registrazioni di rotazione ed evidenze del vault
13. Procedura per account break glass e log di test
14. Evidenze di incidenti o alert riguardanti accessi non riusciti, elevazione dei privilegi o account inattivi
15. Voci della Dichiarazione di Applicabilità per i controlli dell’Allegato A relativi agli accessi

Le policy Clarysec rendono esplicita questa aspettativa. Nella Politica di controllo degli accessi per PMI, il requisito è semplice e orientato all’audit:

“Deve essere mantenuta una registrazione sicura per tutti i provisioning, le modifiche e le rimozioni degli accessi.”

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

La stessa policy per PMI collega inoltre RBAC e MFA direttamente alle responsabilità di ruolo:

“Implementa controlli degli accessi basati sui ruoli (RBAC) e applica l’autenticazione forte (ad es. autenticazione a più fattori (MFA)).”

Dalla sezione “Ruoli e responsabilità”, clausola 4.2.3.

Per le organizzazioni più grandi, la Politica di onboarding e cessazione del personale enterprise richiede che il sistema IAM registri la creazione degli account, l’assegnazione di ruoli e autorizzazioni e gli eventi di disattivazione, supporti modelli di accesso basati sui ruoli e si integri con i sistemi HR per i trigger Joiner-Mover-Leaver. Tale clausola aiuta a raccontare la storia dell’audit in un unico punto: onboarding standardizzato, ciclo di vita dell’identità attivato da HR ed eventi IAM tracciabili.

Mappare IAM, MFA, PAM e riesami ai controlli ISO/IEC 27001:2022

Zenith Controls: la guida alla conformità trasversale di Clarysec tratta il controllo degli accessi come una famiglia di controlli collegata, non come una voce di checklist. Per ISO/IEC 27001:2022, i controlli più rilevanti includono:

• Controllo 5.15, controllo degli accessi
• Controllo 5.16, gestione delle identità
• Controllo 5.17, informazioni di autenticazione
• Controllo 5.18, diritti di accesso
• Controllo 8.2, diritti di accesso privilegiato
• Controllo 8.3, restrizione dell’accesso alle informazioni
• Controllo 8.5, autenticazione sicura
• Controllo 8.15, logging
• Controllo 8.16, monitoraggio delle attività

Per le informazioni di autenticazione, Zenith Controls mappa il controllo 5.17 come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con la capacità operativa di gestione delle identità e degli accessi. Lo collega direttamente a gestione delle identità, autenticazione sicura, ruoli e responsabilità, uso accettabile e conformità alle policy. La sicurezza delle credenziali include ciclo di vita degli autenticatori, emissione sicura, archiviazione, reset, revoca, token MFA, chiavi private e credenziali di servizio.

Per i diritti di accesso, Zenith Controls mappa il controllo 5.18 alla concessione, al riesame, alla modifica e alla revoca formali. Lo collega a controllo degli accessi, gestione delle identità, segregazione dei compiti, diritti di accesso privilegiato e monitoraggio della conformità. Questo è il controllo che trasforma il principio del privilegio minimo in evidenze.

Per i diritti di accesso privilegiato, Zenith Controls mappa il controllo 8.2 al rischio specifico degli account elevati, inclusi amministratori di dominio, utenti root, amministratori di tenant cloud, superuser di database e controller CI/CD. La guida collega l’accesso privilegiato a gestione delle identità, diritti di accesso, restrizione dell’accesso alle informazioni, autenticazione sicura, lavoro da remoto, logging e monitoraggio.

Un unico report di riesame degli accessi ben progettato può supportare ISO/IEC 27001:2022, NIS2, DORA e GDPR se include campo di applicazione, proprietario del sistema, revisore, elenco degli account, giustificazione del ruolo, indicatore di privilegio, decisioni, rimozioni, eccezioni e data di completamento.

Le evidenze MFA sono più di uno screenshot

Un errore comune in audit è presentare uno screenshot con la dicitura “MFA abilitata”. Gli auditor hanno bisogno di più. Devono sapere dove si applica la MFA, chi è escluso, come sono approvate le eccezioni, se gli account privilegiati sono coperti e se la configurazione tecnica corrisponde alla policy.

Dal Zenith Blueprint, fase Controls in Action, Step 19, gli auditor chiederanno come vengono applicate le policy di password e MFA, quali sistemi sono protetti, a chi si applica la MFA e se le applicazioni critiche possono essere testate con un account campione. Le evidenze possono includere configurazione IdP, policy di accesso condizionale, statistiche di registrazione MFA e procedure di reset della password.

Per gli ambienti enterprise, la Politica di gestione degli account utente e dei privilegi di Clarysec stabilisce:

“Ove tecnicamente possibile, l’autenticazione a più fattori (MFA) è obbligatoria per: 6.3.2.1 Account amministrativi e a livello root 6.3.2.2 Accesso remoto (VPN, piattaforme cloud) 6.3.2.3 Accesso a dati sensibili o regolamentati”

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

Questo crea un collegamento diretto per l’audit. Se la MFA è obbligatoria per account amministrativi, accesso remoto e dati regolamentati, il pacchetto di evidenze deve includere elenchi degli account amministrativi e a livello root, configurazione dell’accesso remoto, policy di accesso condizionale delle piattaforme cloud, elenchi delle applicazioni con dati sensibili, report di registrazione MFA, approvazioni delle eccezioni, controlli compensativi ed evidenze recenti di riesame degli alert per accessi non riusciti o tentativi di bypass della MFA.

Per NIST SP 800-53 Rev. 5, ciò si allinea a IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access e AU-2 Event Logging. Per COBIT 2019, supporta DSS05.04 Manage user identity and logical access e le relative pratiche di monitoraggio della sicurezza.

Gli standard ISO di supporto ampliano il quadro. ISO/IEC 27018:2020 estende le aspettative di autenticazione per il cloud pubblico che tratta dati personali. ISO/IEC 24760-1:2019 supporta l’associazione degli autenticatori e la gestione del ciclo di vita. ISO/IEC 29115:2013 introduce i livelli di assurance dell’autenticazione, utili per decidere dove siano necessari token hardware o MFA resistente al phishing. ISO/IEC 27033-1:2015 supporta l’autenticazione di rete forte per l’accesso remoto o tra reti.

Le evidenze PAM sono la via più rapida verso una risultanza rilevante o un audit senza rilievi

L’accesso privilegiato è il punto in cui gli auditor diventano scettici, perché gli account privilegiati possono aggirare i controlli, estrarre dati, creare persistenza e alterare i log. Nel Zenith Blueprint, lo Step 19 afferma:

“In qualsiasi sistema informativo, l’accesso privilegiato è potere e con quel potere arriva il rischio.”

Le indicazioni si concentrano su chi dispone di accesso privilegiato, che cosa consente, come viene gestito e come viene monitorato nel tempo. Raccomandano un inventario aggiornato, principio del privilegio minimo, RBAC, elevazione basata sul tempo o just-in-time, workflow di approvazione, account nominativi univoci, evitamento degli account condivisi, registrazione break glass, sistemi PAM, rotazione delle credenziali, vaulting, registrazione delle sessioni, elevazione temporanea, monitoraggio e riesame periodico.

La Politica di controllo degli accessi enterprise di Clarysec trasforma questo principio in un requisito di controllo:

“L’accesso amministrativo deve essere strettamente controllato mediante: 5.4.1.1 Account privilegiati separati 5.4.1.2 Monitoraggio e registrazione delle sessioni 5.4.1.3 Autenticazione a più fattori 5.4.1.4 Elevazione limitata nel tempo o attivata da workflow”

Dalla sezione “Requisiti di governance”, clausola 5.4.1.

Questa citazione è quasi uno script di test per l’audit. Se la policy prevede account amministrativi separati, mostra l’elenco degli account privilegiati e dimostra che ciascuno è associato a una persona nominativa. Se prevede monitoraggio delle sessioni, mostra le sessioni registrate o i log PAM. Se prevede MFA, mostra l’applicazione su ogni percorso di accesso privilegiato. Se prevede elevazione limitata nel tempo, mostra timestamp di scadenza e ticket di approvazione.

La versione per PMI è altrettanto diretta. La Politica di gestione degli account utente e dei privilegi per PMI stabilisce:

“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 6.2.2.

Per le organizzazioni più piccole, questa è spesso la differenza tra “ci fidiamo del nostro amministratore” e “controlliamo il rischio privilegiato”. L’auditor non richiede strumenti enterprise in ogni PMI, ma richiede evidenze proporzionate al rischio. Un ticket, un’approvazione, un’assegnazione temporanea a un gruppo, l’applicazione della MFA e una registrazione di riesame possono essere sufficienti quando il campo di applicazione è limitato e il rischio è inferiore.

I riesami degli accessi dimostrano che il privilegio minimo è operativo

I riesami degli accessi mostrano se le autorizzazioni si accumulano silenziosamente. Mostrano anche se i manager comprendono gli accessi effettivamente detenuti dai loro team.

La Politica di gestione degli account utente e dei privilegi enterprise richiede:

“Devono essere condotti riesami trimestrali di tutti gli account utente e dei privilegi associati da parte della sicurezza IT in collaborazione con i responsabili di dipartimento.”

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

Per le PMI, la Politica di gestione degli account utente e dei privilegi per PMI stabilisce una cadenza proporzionata:

“Deve essere eseguito un riesame di tutti gli account utente e dei privilegi ogni sei mesi.”

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

Un riesame degli accessi credibile include nome del sistema, campo di applicazione, nome del revisore, data di esportazione, data del riesame, titolare dell’identità, dipartimento, manager, stato occupazionale, ruolo o entitlement, indicatore di privilegio, indicatore di sensibilità dei dati, decisione, ticket di remediation, data di chiusura, titolare dell’eccezione e data di scadenza dell’eccezione.

Per Zenith Controls, i diritti di accesso 5.18 sono il punto in cui tutto questo diventa evidenza di conformità trasversale. La guida mappa i diritti di accesso a GDPR Article 25 perché l’accesso deve essere limitato fin dalla progettazione e per impostazione predefinita. Lo mappa a NIS2 Article 21(2)(i) perché le politiche di controllo degli accessi e la gestione degli asset richiedono assegnazione basata sul rischio, rimozione tempestiva degli accessi non necessari e revoca formale. Lo mappa a DORA perché i sistemi ICT finanziari richiedono accesso basato sui ruoli, monitoraggio e processi di revoca.

Gli auditor orientati a NIST spesso testano questo aspetto tramite AC-2 Account Management, AC-5 Separation of Duties e AC-6 Least Privilege. Gli auditor COBIT 2019 guardano a DSS05.04 Manage user identity and logical access e DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. Gli auditor ISACA ITAF si concentrano sul fatto che le evidenze siano sufficienti, affidabili e complete.

Offboarding e revoca dei token sono facili da campionare

I leaver sono uno dei punti più semplici per dimostrare se il ciclo di vita funziona. Gli auditor spesso selezionano un dipendente cessato di recente e chiedono la registrazione HR della cessazione, il ticket, il log di disabilitazione dell’account, l’evidenza di disattivazione SaaS, la rimozione VPN, la revoca MFA, la rimozione dei token API e la restituzione degli asset.

Nella Politica di onboarding e cessazione del personale per PMI, Clarysec afferma:

“Gli account cessati devono essere bloccati o cancellati e i token di accesso associati devono essere revocati, inclusi accesso remoto (VPN), associazioni ad app MFA e token API.”

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

Questo è importante perché l’accesso moderno non è soltanto nome utente e password. L’accesso può persistere tramite refresh token, chiavi API, chiavi SSH, grant OAuth, account di servizio, diritti di amministratore locale, sessioni mobili e portali di terze parti. Una registrazione HR disattivata senza revoca dei token è un’evidenza incompleta.

Il Zenith Blueprint, fase Controls in Action, Step 16, indica alle organizzazioni di essere pronte con una checklist di cessazione documentata, evidenze relative a un leaver recente, un log di disabilitazione dell’account utente da AD o MDM, un modulo di restituzione degli asset firmato e documentazione di offboarding che includa obblighi di riservatezza.

L’auditor di Maria ha chiesto un senior developer uscente che aveva accesso privilegiato ai database di produzione. Il suo team ha presentato la Politica di onboarding e cessazione del personale per PMI, la checklist di cessazione costruita a partire dallo Step 16 del Zenith Blueprint, il ticket ITSM attivato da HR, il log di disabilitazione della directory, la revoca del certificato VPN, la rimozione dall’organizzazione GitHub, la cancellazione della chiave AWS IAM e il ticket di verifica chiuso e firmato dal responsabile IT. Le evidenze erano complete, tempestive e direttamente ricondotte alla policy.

Eseguire uno sprint di evidenze su tre campioni prima che lo faccia l’auditor

Un esercizio pratico di preparazione consiste nel scegliere tre campioni prima dell’audit:

1. Un nuovo dipendente entrato negli ultimi 90 giorni
2. Un utente privilegiato con accessi amministrativi a cloud, database, produzione o IAM
3. Un leaver o un dipendente che ha cambiato ruolo negli ultimi 90 giorni

Collega quindi ciascun campione alle registrazioni del SGSI: scenario di rischio, decisione di trattamento, selezione del controllo nella Dichiarazione di Applicabilità, clausola di policy, configurazione tecnica, registrazione del riesame e azione correttiva in caso di lacune.

Questo trasforma la preparazione all’audit da raccolta documentale a verifica dei controlli.

Prepararsi a diverse prospettive di audit

Background di audit diversi portano a domande diverse, anche quando le evidenze sono le stesse.

Preparare evidenze che soddisfino tutte queste prospettive dimostra un programma di conformità maturo e riduce il lavoro duplicato.

Risultanze comuni e azioni preventive

Le risultanze sul controllo degli accessi sono prevedibili. Anche le azioni preventive lo sono.

La Politica di controllo degli accessi enterprise aggiunge un requisito di conservazione che previene uno dei fallimenti più comuni delle evidenze:

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

Dalla sezione “Requisiti di governance”, clausola 5.3.2.

Se le approvazioni scompaiono dopo la pulizia delle e-mail, il controllo può anche avere funzionato, ma l’audit non può farvi affidamento. La conservazione fa parte della progettazione del controllo.

La responsabilità della direzione richiede metriche sugli accessi

NIS2 Article 20 e DORA Articles 5 e 6 rendono il controllo degli accessi una responsabilità della direzione perché la compromissione delle identità può trasformarsi in interruzione operativa, segnalazione regolatoria, violazione dei dati e danno ai clienti. Anche ISO/IEC 27001:2022 clausole da 5.1 a 5.3 richiedono all’alta direzione di allineare il SGSI alla strategia aziendale, fornire risorse, comunicare l’importanza, assegnare responsabilità e promuovere il miglioramento continuo.

Metriche utili del controllo degli accessi includono:

• Percentuale di sistemi critici coperti da SSO
• Percentuale di account privilegiati con MFA
• Numero di account privilegiati permanenti rispetto agli account JIT
• Tasso di completamento dei riesami degli accessi
• Numero di autorizzazioni eccessive revocate
• Conformità allo SLA di disattivazione dei leaver
• Numero di account inattivi
• Copertura dei titolari degli account di servizio
• Copertura della registrazione delle sessioni PAM
• Numero ed età delle eccezioni MFA

Queste metriche aiutano la direzione ad approvare il trattamento del rischio e a dimostrare supervisione. Rendono inoltre gli audit più credibili, perché l’organizzazione può dimostrare che il controllo degli accessi è monitorato come rischio attivo, non riscoperto prima di ogni audit.

Trasformare evidenze sparse in fiducia di audit

Se le evidenze del controllo degli accessi ISO/IEC 27001:2022 sono sparse tra HR, ITSM, IAM, PAM, console cloud e fogli di calcolo, il passo successivo non è un’altra riscrittura della policy. Il passo successivo è un’architettura delle evidenze.

Inizia con questa sequenza:

1. Definire sistemi, identità e dati nel campo di applicazione.
2. Mappare NIS2, DORA, GDPR e requisiti contrattuali nel contesto del SGSI.
3. Usare scenari di rischio in stile ISO/IEC 27005:2022 per dare priorità a IAM, MFA, PAM e riesami degli accessi.
4. Aggiornare la Dichiarazione di Applicabilità e il piano di trattamento del rischio.
5. Allineare le clausole di policy ai workflow IAM e PAM effettivi.
6. Eseguire lo sprint di evidenze su tre campioni.
7. Correggere le lacune prima che le trovi l’auditor.
8. Mantenere un pacchetto di evidenze riutilizzabile per certificazione, due diligence dei clienti e riesami normativi.

Clarysec può aiutarti ad attuare questo modello tramite il Zenith Blueprint: roadmap in 30 passaggi per auditor, a mappare trasversalmente i requisiti con Zenith Controls: la guida alla conformità trasversale e a rendere operativi i requisiti con il set di policy Clarysec appropriato, incluse Politica di controllo degli accessi, Politica di gestione degli account utente e dei privilegi e Politica di onboarding e cessazione del personale.

La preparazione agli audit del controllo degli accessi non consiste nel dimostrare di avere acquistato uno strumento IAM. Consiste nel dimostrare che i processi di identità, autenticazione, privilegio e riesame riducono rischi aziendali reali e soddisfano gli standard e le normative rilevanti per la tua organizzazione.

Scarica i toolkit Clarysec, esegui lo sprint di evidenze su tre campioni e trasforma le evidenze del controllo degli accessi da un insieme disperso e ingestibile in un portfolio di audit chiaro, ripetibile e difendibile.