Come gestire gli accessi ai database e l'audit

Introduzione

Nel mondo dei database, la sicurezza e il monitoraggio delle attività che si effettuano sulle basi dati sono aspetti fondamentali che non possono essere trascurati. Questo vale per tutte le realtà in cui ci sono dati personali, ed è una sfida assai più complicata quando sono coinvolti molti database, di diversi engine a cui accedono molte persone appartenenti a diverse Business Unit (e talvolta a diverse aziende).

Nonostante questo, il monitoraggio degli accessi spesso non è configurato e la mancanza di regole comuni nelle modalità di connessione ai database rende difficile la tracciabilità delle azioni effettuate sulle istanze DB.
 

I problemi più comuni

I problemi più comuni che riscontriamo negli accessi ai database sono quelli che abbiamo elencato qui di seguito.

• Non sono definite delle regole generali di accesso ai database per i diversi utenti (interni ed esterni - fornitori).
• Per connettersi tramite client al database, i diversi utenti utilizzano accessi non nominali ma applicativi o generici. Questo comporta un grave problema di sicurezza poiché non consente di identificare chi si sia collegato e che operazioni abbia effettuato sul database.
• Alcune istanze non hanno l'audit abilitato e per altre è abilitato solo per il tracciamento di determinate operazioni nel database (ad esempio creazione di nuove tabelle). Tale disallineamento rende difficile o, in alcuni casi, impossibile il monitoraggio delle attività svolte nell'istanza stessa da parte delle diverse utenze.

Per risolvere problematiche di questo tipo, è necessario eseguire alculne azioni:

• definire delle regole per la gestione delle modalità di connessione ai database; 
• definire chi può accedere alle basi dato e che operazioni può effettuare in base alle necessità;
• trovare un’alternativa all’audit senza abilitarlo direttamente nel DB;
• definire una metodologia di gestione delle credenziali di accesso ai database che sia sicura;
• bloccare gli accessi non autorizzati ai database;
• identificare uno strumento comune per collegarsi ai database con caratteristiche che possano aiutarci a risolvere i problemi sopra elencati.

Un caso. La sua soluzione

Per identificare, tracciare e gestire l’accesso di utenti con permessi standard (non superuser), raccontiamo come, per un nostro cliente, abbiamo portato a completamento l’installazione e la configurazione di Dbeaver Team: uno strumento web centralizzato che consente di connettersi e lavorare su diversi tipi di database. Tra i DBMS più noti ed integrabili con il tool troviamo Oracle, PostgreSql, MySQL e SQL Server. È possibile consultare una lista completa degli engine di database - relazionali e non - supportati da Dbeaver Team.

Dbeaver Team offre numerose feature che possono aiutarci a risolvere questi problemi. Di seguito ne lenchiamo alcune, descrivendo brevemente come queste siano state cruciali per la scelta di tale strumento alla luce delle richieste del cliente.

In primo luogo, Dbeaver Team stesso permette di fare auditing, senza dover abilitare lo stesso nel database, garantendo quindi l’uniformità nella raccolta delle informazioni per tutte le istanze. L’accesso allo strumento è nominale e l’audit interno dello strumento tiene traccia non solo degli accessi ai database cui si è collegato un utente, ma anche delle operazioni e delle query eseguite. In corrispondenza a tali informazioni, troviamo quale utente del tool ha effettuato l’operazione, a che orario e se l’operazione sia andata a buon fine o meno.

Riportiamo di seguito uno screenshot esemplificativo.
 

Successivamente Dbeaver Team consente di gestire in maniera strutturata gli accessi ai database da parte degli utenti. Entrano in gioco infatti i concetti di team, ossia un insieme di utenti definiti all’interno del tool che in questo specifico progetto noi abbiamo declinato come le aziende fornitori, e di progetti, che sono insiemi di connessioni a database relative ad uno specifico applicativo e che possono essere assegnati a uno o più team specifici. 

In questo modo riusciamo anche a gestire le credenziali di accesso tramite il loro salvataggio e la loro condivisione a livello di team, senza che i singoli utenti siano a conoscenza di username e password.  Nella pratica, nel database viene creato un utente dedicato - con grant concordati destinato a Dbeaver, che viene impostato nella connessione del progetto Dbeaver di appartenenza e usufruibile da tutti i membri del team ai quali quel progetto è assegnato. In questo modo i singoli utenti non hanno bisogno di conoscere le password di questo utente perchè la connessione è già pronta all’uso.   

Con l’introduzione di Dbeaver Team, abbiamo quindi ottenuto alcuni benefici:  

• ora il cliente ha uno strumento aziendale comune per consentire il collegamento ai diversi tipi di database da parte dei diversi utilizzatori (interni ed esterni), invece di un proliferare di toad, sql developer, dbeaver, ecc.
• l’audit è attivato dal tool stesso, quindi si riesce a monitorare chi effettua determinate operazioni, a che ora, dove si è connesso e con quale utente su  tutti i database. Tutti i log sono simili, pur essendo relativi a basi dati diverse, quindi è più facile fare comparazioni e analisi. Si hanno benefici anche a livello di storage in quanto non è necessario la creazione di record in tabelle apposite per l’audit o la creazione di file di audit su disco, ma questo è stato centralizzato su un database centrale creato per l’uso;
• i fornitori non possono più collegarsi ai database con l’utente applicativo tramite client locali, ma solo tramite dbeaver a cui accedono nominalmente;
• non vengono più consegnate credenziali ai fornitori, dato che le connessioni sono già impostate su Dbeaver.