Al momento dell’adozione di nuovi software o comunque nella (ri)strutturazione di nuove o preesistenti attività aziendali è utile partire da due punti fermi: la centralità (leggi “protezione”) dei dati acquisiti in azienda e la protezione dell’azienda stessa, gestendone la sicurezza infrastrutturale informatica: potremmo riassumere questi due perni chiamandoli con i rispettivi nomi: privacy by design e Privileged Access Management (PAM).
Indice degli argomenti
Privacy by design e Privileged Access Management: proteggere gli asset
Tralascio le ovvie premesse di qualunque trattamento dati, quali l’applicazione del principio di minimizzazione, principi di liceità e trasparenza e le altre premesse necessarie alla luce del GDPR: mi interessa focalizzarmi sugli aspetti di proattività e di protezione dati per default.
Quando in un sistema PAM si vanno ad individuare, impostare o proteggere gli account amministrativi, si va ad individuare chi ha accesso a cosa, per quale scopo, se questo accesso sia necessario e per quanto tempo questo accesso debba essere garantito.
Non solo tutto ciò viene fatto e strutturato centralmente, intendo in maniera centralizzata, ma si adottano soluzioni “proattive” in modo tale che alcune situazioni non possano accadere.
Tutto ciò ricorda qualcosa?
Nell’interagire con i dati personali, ad esempio dei clienti dell’azienda, non si agisce forse individuando chi può consultare o lavorare i dati? Non si fa forse in modo che si possa interagire solo con i dati necessari ad espletare il compito specifico? Non si tiene traccia, anche storica degli autorizzati, nel registro dei trattamenti?
Bene, in un sistema sicuro, che utilizzi un software PAM, si agisce esattamente in questo modo, per proteggere gli asset aziendali più critici.
In realtà non è sufficiente stabilire chi e magari per quanto tempo (intendo un’ora, un giorno ecc.) possa avere accesso ad una risorsa informatica aziendale, è bene stabilire per esempio da dove (solo ad esempio da macchine o IP specifici); è bene dotarsi di procedure automatiche di verifica della liceità dell’esistenza in vita di account aziendali, soprattutto se con poteri amministrativi.
Nell’ultimo caso, non è possibile e conveniente affidarsi unicamente al controllo e verifica “umana” della eventuale esistenza di account attivi, associati magari ad utenti che non abbiano più esigenze o motivazioni all’accesso.
Vanno previste una o più procedure automatizzate che verifichino la congruenza tra gli account attivi e l’attuale abilitazione dell’utente ad essi associato, magari richiedendo un’azione attiva di conferma di un amministratore su base temporale ciclica.
Vanno quindi implementati sistemi che facciano un’analisi dei file di log e, nel caso, innalzino degli alert in base a frequenze anomale di connessione a servizi o a macchine aziendali, anche in base alla variazione degli IP di provenienza.
Privacy by design e Privileged Access Management: analisi dei rischi
Oltre ad una approccio per molti versi comune, tra un’impostazione secondo i principi di privacy by design e protezione delle aree critiche aziendali con sistemi PAM, molte tipologie di rischio sono in qualche modo comuni e vanno previste e protette in fase di strutturazione, non a posteriori, e nell’approccio che suggerisco, spesso utilizzando gli stessi sistemi e paradigmi di riferimento.
Pensate per esempio agli accessi concessi a fornitori di tecnologia, ad esempio dei software e degli stessi database aziendali. È molto più arduo tenere in sicurezza questo tipo di accessi, perché i tecnici che accedono non sono dipendenti diretti dell’azienda che curiamo, ma dipendenti (che possono variare nel tempo), di una azienda esterna che è il nostro fornitore.
Se la politica di protezione del fornitore non è strutturata a dovere, un tecnico che cessi di lavorare per lui potrebbe mantenere i dati di accesso ad uno o più client, mettendo a serio rischio i dati che proteggiamo ed incrinando seriamente il perimetro di sicurezza informatica aziendale.
Essendo un sistema PAM comunque un insieme di strumenti e tecnologie, caso per caso potrebbero essere prevenute ed in ogni caso monitorate criticità degli accessi implementando le One Time Password, oltre all’equivalente per gli accessi aziendali del concetto di privacy by default, il default deny, in un approccio a “fiducia zero”, nella stessa modalità in cui si può impostare, per esempio, nelle regole di un firewall.
Considerazioni finali
A fronte di richieste di indicazioni “pratiche” da parte di aziende rispetto all’innalzamento dei livelli di sicurezza, rispondo spesso con un falso paradosso: l’indicazione che trovo di maggior validità pratica è fare passare innanzitutto dei concetti chiave legati alla sicurezza degli accessi privilegiati.
Può sembrare scontato per alcuni che ad esempio un account amministrativo, che possa ad esempio creare, impostare o eliminare caselle di posta aziendale, debba essere associato a persona/e perfettamente identificate e fidate; in ogni caso questi account debbono essere monitorati e controllati.
Tenete conto che più una azienda cresce e maggiore sarà la presenza di account con privilegi, legati alle molteplici necessità e aree aziendali, si può arrivare ad avere un numero di account amministrativi superiore in quantità al numero dei dipendenti. Ciò si traduce in un aumento esponenziale del rischio di accessi non autorizzati, sia che questi avvengano dall’interno che da personale estraneo.
Ci saranno account autorizzati, o con privilegi di “root” che, senza un sistema PAM, potrebbero coprire le tracce di quanto compiuto in una specifica sessione, o comunque accedere a dati protetti non di loro pertinenza.
Acquisita coscienza reale delle problematiche in gioco, la implementazione di un software PAM sarà soltanto una logica conseguenza.
