L’evoluzione dell’Amministratore di Sistema tra GDPR, NIS 2 e standard tecnici

Dal 2008 ad oggi, la figura dell’Amministratore di Sistema (AdS) non ha mai smesso di essere un protagonista della compliance nel panorama della Data Protection.

Nonostante ciò, non si può dire che nel corso degli anni non abbia subito una metamorfosi profonda: in effetti, se nel 2008 il Garante per la protezione dei dati personali,  la definiva come un “custode tecnico” focalizzato sulla manutenzione di “impianti di elaborazione”, oggi tale ruolo deve essere riletto alla luce di scenari tecnologici radicalmente mutati, dove la complessità delle infrastrutture e la centralità della security (per non citare la Direttiva (UE) 2022/2555,  NIS 2) impongono un approccio molto più articolato, dinamico e basato sul rischio.

I Provvedimenti dell’Autorità Garante del 2008-2009 nascevano in un’epoca di sistemi prevalentemente on-premise e perimetri fisici ben definiti. L’attuale realtà organizzativa, caratterizzata da cloud computing, architetture IT distribuite e necessità di gestire la threat intelligence (magari in contesti infragruppo), richiede di interpretare i requisiti storici non come meri adempimenti formali, ma come presidi di accountability.

Criteri per l’individuazione dei soggetti che svolgono il ruolo di Amministratore di Sistema

Le mansioni dell’AdS sono oggi intrinsecamente legate alla continuità operativa (ISO 22301) e alla protezione proattiva, ma è importante non confondere tale ruolo con le figure che all’interno di un sistema IT godono di meri accessi privilegiati. Giova dunque ricordare, che i compiti fondamentali dell’AdS includono:

• il presidio delle infrastrutture: gestione di reti informatiche aziendali e sistemi di software complessi;
• la sicurezza dei dati personali: l’attuazione di politiche legate ai backup e alla ridondanza dei sistemi, anche in un’ottica di disaster recovery e business continuity (nel Provvedimento del 2008 indicate come attività relative alla “realizzazione di copie di sicurezza”), e la gestione dei sistemi di autenticazione e autorizzazione, Multi-Factor Authentication (MFA), Identity and Access Management (IAM), etc;
• le attività di vigilanza e audit: l’operato e l’ambito di attività dell’AdS deve essere oggetto di verifiche costanti da parte del Titolare, che deve verificare la conformità delle sue attività ai profili di autorizzazione assegnati.

Mappare ed inserire nell’atto di nomina/designazione lo specifico ambito di operatività dell’Amministratore di Sistema

Sicuramente, questo profilo risulta molto delicato, considerando che in questo passaggio occorre rileggere le indicazioni dei Provvedimenti del garante del 2008-2009 nella prospettiva degli ecosistemi digitali odierni. Ad esempio, è necessario considerare alcune evoluzioni di cui non si può non tenere conto:

• dalle “Misure minime” dell’Allegato B ai Framework ENISA/NIST: mentre la normativa precedente suggeriva la rotazione forzata della password ogni 90 giorni, la realtà tecnologica odierna e la Direttiva NIS 2 rendono tale pratica obsoleta e potenzialmente controproducente. Un esempio pratico è l’adozione dell’Autenticazione a più fattori (MFA) per gli accessi privilegiati: oggi non basta più una credenziale “robusta”, ma occorre un monitoraggio costante delle compromissioni, in linea con gli standard ISO/IEC 27001;
• dal semplice login con attribuzione di ID e PW alle Policy di gestione dell’Identità (IAM): se nel 2008 il focus era sul login al server, oggi l’AdS gestisce complessi sistemi di identity and access management (IAM). Se consideriamo poi che spesso l’AdS si trova ad operare in un contesto infragruppo, ciò significa che la capacità di azione propria dell’AdS si estende a intere “foreste” di domini, rendendo la sua natura fiduciaria ancora più critica, poiché un errore o un abuso può impattare su molteplici società e organizzazioni;
• dal tracciamento dei log alla gestione di security information and event management (SIEM) e log server centralizzati: il requisito della registrazione degli accessi (access log) si è evoluto tecnicamente. Nelle realtà meno complesse si può ancora ricorrere a registrazioni locali, ma per organizzazioni soggette alla NIS 2 o con infrastrutture articolate, è necessario implementare log server centralizzati o SIEM. In ogni caso, resta invariato l’obbligo di garantire l’integrità dei log degli AdS per almeno 6 mesi, presidio fondamentale per la verifica del relativo operato.

Regolare l’assetto dei rapporti in caso di partnership IT, servizi MSP (managed service provider) o gestione delle attività dell’AdS in un perimetro infragruppo

L’evoluzione degli ecosistemi digitali ha un impatto diretto proprio sulla governance dei sistemi IT aziendali. Nelle realtà più articolate, come i Gruppi societari, i sistemi di sicurezza IT sono spesso connotati dal coordinamento centralizzato di alcune funzioni, portando alla necessità di accordi di contitolarità (art. 26 GDPR) che deleghino formalmente le funzioni di AdS, individuando tale ruolo solo in capo ad alcune figure inserite nell’organigramma di una o più delle società del Gruppo. Anche in caso di fornitori di software gestionali in licenza o di managed service provider, il Titolare deve mantenere il controllo conoscendo gli estremi identificativi delle persone fisiche che operano come AdS. Non è sufficiente identificare la società fornitrice: occorre una designazione individuale che definisca analiticamente gli ambiti di operatività, senza dimenticare di inserire clausole contrattuali specifiche che obblighino il fornitore a comunicare i nominativi dei tecnici e a garantire l’inalterabilità dei log (e un vero diritto di audit).