DB LEX

Questa paginetta riporta alcuni riferimenti utili sugli aspetti legati alla normativa per i database ed in particolare alle piu' recenti quali il regolamento (UE) 2016/679: il noto GDPR.

La gestione delle basi dati richiede soprattuto competenze tecniche legate all'amministrazione dei prodotti... ma non solo! Sono diventati sempre piu' importanti gli aspetti legati al rispetto delle normative. In questo documento cerchiamo di raccogliere i principali documenti utili per i DBA. La prima parte riporta una panoramica delle principali normative di riferimenti, la seconda parte del documento indica le tecnologie utilizzabili sui database.

Nel seguito sono riportate alcune informazioni di interesse organizzate in paragrafi specifici: Introduzione, Obblighi di legge, GDPR, Autenticazione, Auditing/Logging, Continuita' operativa, Cifratura e pseudonimizzazione, Hardening, Varie ed eventuali.

Introduzione

Questo documento e' rivolto ai DBA (Database Administrator). L'argomento e' complesso ed e' piu' materia per legali e per esperti di organizzazione. Tuttavia gli impatti tecnici sulle basi dati sono molto importanti ed e' quindi utile per i DBA conoscere i dettagli dei requisiti da implementare sulla base dati. Se infatti in alcuni casi le norme sono elestiche (eg. "conto dello stato dell'arte e dei costi di attuazione, nonche' della natura, dell'oggetto, del contesto e delle finalita'...") in altri casi prevedono in modo esplicito algoritmi, lunghezze e durate (eg. "La parola chiave, quando e' prevista dal sistema di autenticazione, e' composta da almeno otto caratteri...").

La prima parte del documento riporta i riferimenti alle principali normative, con un dettaglio maggiore sul GDPR poiche' di recente introduzione.
La seconda parte del documento descrive le tecnologie piu' utili per soddisfare i requisiti di legge. Poiche' vi sono molti e diversi argomenti da trattare anche in queso caso verranno dati alcuni cenni ed i riferimenti per i necessari approfondimenti.

Obblighi di legge

Una premessa... quale legge? Ce ne sono tantissime, vanno applicate a seconda delle condizioni, alcune sono leggi con pesanti risvolti penali, altre leggi senza particolari sanzioni, altre solo raccomandazioni; sono state emanate da un parlamento oppure da un ente oppure da un organismo in qualche modo delegato... Cercheremo di fare qualche esempio ma non sara' facile!

Una legge attualmente in vigore in Italia per la registrazione degli accessi ai sistemi informatici e' il Codice in materia di protezione dei dati personali (d.lg. 30 giugno 2003, n. 196) e, in particolare, gli artt. 31 ss. e 154, comma 1, lett. c) e h), nonche' il disciplinare tecnico in materia di misure minime di sicurezza di cui all'allegato B del medesimo Codice. Tale legge inquadra in modo completo la materia ma, dal punto di vista pratico, sono piu' importanti i provvedimenti del Garante per la protezione dei dati personali. Il provvedimento del Garante del 27 novembre 2008 (Rif. Misure e accorgimenti prescritti ai titolari dei trattamenti...) relativo a "Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema" e' stato pubblicato sulla G.U. n. 300 del 24 dicembre 2008. Tale provvedimento prevede al comma 4.5 "Devono essere adottati sistemi idonei alla registrazione degli accessi logici (autenticazione informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli amministratori di sistema." Sono inoltre definiti i dettagli sulla ritenzione dei log, sulla loro archiviazione, i controlli e la loro frequenza, ... Il provvedimento e' stato ulteriormente modificato con provvedimento del 25 Giugno 2009 (Rif. Modifiche del provvedimento del 27 novembre 2008...) che, al comma c), ne proroga l'adozione alla data definitiva del 15 Dicembre 2009.
Insomma dal 15 Dicembre 2009 vanno registrati tutti gli accessi amministrativi ai sistemi e l'obbligo vale anche per gli amministratori delle basi dati!
Insomma come deve fare il DBA? E' descritto nel paragrafo Auditing/Logging.

Per l'autenticazione il riferimento e' il Disciplinare tecnico in materia di misure minime di sicurezza che riporta in modo esplicito che le utenze sono personali, vanno disattivate se non usate per sei mesi, sono protette da password, lunghe almeno otto caratteri, che debbono essere cambiate al primo accesso e periodicamente ogni tre mesi.
Come deve fare il DBA? E' descritto nel paragrafo Autenticazione.

Per quanto riguarda gli USA i principali obblighi sono previsti dal Sarbanes-Oxley (SOX) Act of 2002: legge federale che specifica come debbono essere gestiti e protetti i dati finanziari e dal Health Insurance Portability and Accountability Act (HIPAA): legge a protezione dei dati personali e sanitari.

E' invece uno standard internazionale il Payment Card Industry Data Security Standard (PCI-DSS): si occupa della protezione dei dati delle carte di credito. Le normative per gli istituti finanziari prevedono, tra le altre cose, la crittografia dei dati ed ambienti di continuita' operativa.

Molta rilevanza hanno assunto per le aziende le ISO 27001:2005 e ISO 27002:2007 [NdA semplificando norma e best practices rispettivamente] [NdE ora aggiornate UNI CEI ISO/IEC 27001:2017, ISO 27002:2022], si tratta pero' di standard che permettono la certificazione e non sono, in generale, obbligatorie.

E' importante sottolineare che i requisiti minimi richiesti dalle normative non si limitano al tipo di password o la generazione di un audit...
I risultati dell'audit vanno anche mantenuti in modo corretto, resi consultabili ed analizzati. Fondamentali sono anche una corretta definizione dei privilegi [NdE improntata al principio del minimo privilegio], la crittografia [NdE sia sui dati che sulla loro trasmissione], l'anomimizzazione, la continuita' operativa, ...
Per rispettare i requisiti di legge e' quindi necessario procedere prima ad un assessment tecnico e funzionale della base dati e quindi a provvedere alla messa in sicurezza del database con tutti gli strumenti necessari, tra cui l'audit e' solo una delle molte funzionalita' da attivare.

Ho citato tutte le normative? Assolutamente no! Proviamo a riportare le principali: Sarbanes-Oxley (SOX), Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability & Accounting Act (HIPAA), Gramm-Leach-Biley (GLBA), ISO 27001, Basilea II, DoD Orange Book, UK Data Protection Act, Student Data and State Data Protection Laws (FERPA), NIS2 (Network and Information Security, Direttiva UE n.2022/2555), DORA (Digital Operational Resilience Act), ... ed da ultimo ma non come ultimo EU General Data Protection Directive (GDPR)!

GDPR

Il 27 aprile 2016 e' stato adottato il regolamento UE 2016/679 del parlamento europeo relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonche' alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati). Tale regolamento, generalmente riferito con l'acronimo inglese GDPR (General Data Protection Regulation) ha validita' di legge (senza bisogno di essere approvato dal Parlamento Italiano) ed entrera' in vigore il 25 Maggio 2018 [NdA per i piu' ritardatari si ricorda che il periodo di rispetto definito dal Garante, in cui difficilmente verranno emesse sanzioni, terminera' il 17 Maggio 2019].

Il GDPR e' molto ampio (cfr. testo ufficiale, link ufficiale) e prevede regole comuni per tutti i paese della comunita' europea, anzi ha validita' extraterritoriale quando i dati riguardano cittadini europei. Oltre all'inasprimento delle sanzioni con il GDPR cambia sopratutto la prospettiva d'insieme e richiede che la protezione dei dati faccia parte del progetto di sviluppo dei processi aziendali per tutti i prodotti ed i servizi offerti dall'azienda.

L'obiettivo del GDPR e' una migliore protezione dei dati personali con norme che prevedono:

Le sanzioni previste [art.83] per chi non ottempera agli obblighi del regolamento sono molto elevate: fino a €20 milioni o il 4% del fatturato totale mondiale. Il GDPR puo' essere un vantaggio per le aziende perche' definisce un unico insieme di regole valide per tutti i cittadini dell'europa da usare come nuovo riferimento. Vediamolo in dettaglio...

Il GDPR e' composto da 173 recitals (motivi) e da 99 articles (articoli) organizzati in 11 chapters (capi) alcuni dei quali suddivisi in sections (sezioni). Sono sicuramente importanti i seguenti articoli:

Per i link agli specifici articoli abbiamo utilizzato il privacy-regulation.eu che e' piu' comodo rispetto al testo ufficiale del GDPR che e' costituito da un solo file; la figura sopra e' del sito del consiglio europeo. Sull'applicazione del GDPR il garante ha pubblicato una utile guida... ma ora passiamo alla parte tecnica.

Fatta la legge, trovato l'...

Abbiamo visto cosa prevedono le leggi, ora vediamo come trovare l'... implementazione.

I prossimi paragrafi sono tecnici e riguardano i seguenti aspetti: Autenticazione, Auditing/Logging, Continuita' operativa, Cifratura e pseudonimizzazione, Hardening, Varie ed eventuali.

Gli esempi che seguiranno saranno molto pratici e semplici ma possono servire come indicazioni di massima per un'implementazione sui principali RDBMS.

Autenticazione ed autorizzazione

Per il principio del minimo privilegio (least privilege) vanno utilizzate le utenze con i diritti minori possibili per svolgere le diverse attivita'. Questo e' particolarmente importante per le utenze applicative che debbono svolgere tipicamente solo operazioni CRUD, a cui non servono i privilegi per operazioni di DDL e sono tipicamente maggiormente soggette ad attacchi e meno protette. E' quindi necessario che le utenze utilizzate dagli Application Server o dai Web Server non siano proprietarie dello schema dati.
Altra distinzione importante e' tra le utenze amministative per evitare la privilege escalation.
Se disponibile sul database utilizzato e' opportuna la definizione di ruoli specifici per le diverse classi di utenti in modo da semplificare le procedure di autorizzazione.

Una volta definite le utenze corrette e assegnati i relativi privilegi e' importante proteggerli con una procedura di autenticazione adeguata.
Da questo punto di vista i dettagli tecnici cambiano a seconda del motore di database utilizzato. Vediamo qualche esempio...

Oracle permette una gestione completa del ciclo di vita delle utenze mediante i PROFILE: 

CREATE PROFILE app_user2 LIMIT
   FAILED_LOGIN_ATTEMPTS 5
   PASSWORD_LIFE_TIME 60
   PASSWORD_REUSE_TIME 60
   PASSWORD_REUSE_MAX 5
   PASSWORD_VERIFY_FUNCTION verify_function
   PASSWORD_LOCK_TIME 1/24
   PASSWORD_GRACE_TIME 10;

La definizione dei profile corretti e la gestione degli account lock/unlock consente una gestione semplice ed efficace di tutte le utenze in Oracle.

PostgreSQL permette la gestione delle abilitazioni delle utenze con la creazione di utenti e ruoli: 

CREATE ROLE scott WITH LOGIN
  PASSWORD 'xxx'
  CONNECTION LIMIT 5
  VALID UNTIL '2018-05-25';

SET LOCAL configuration_parameter = 'value';

In PostgreSQL non e' possibile indicare l'expiration della password ma si puo' solo definire una scadenza.

MySQL, nelle versioni piu' recenti, permette una gestione sofisticata delle abilitazioni delle utenze e la scadenza delle password: 

CREATE USER scott@'ScottIP' IDENTIFIED BY 'xxx'
  WITH MAX_CONNECTIONS_PER_HOUR 5
       MAX_USER_CONNECTIONS 2
  PASSWORD EXPIRE INTERVAL 90 DAY;

ALTER USER scott@'ScottIP' PASSWORD EXPIRE;

Una descrizione piu' completa si trova in questo documento (5.7).

Auditing/Logging

La rilevazione delle attivita' svolte su un database e' molto importante sia per necessita' di logging/tracing che per adempiere agli eventuali requisiti di legge.

L'RDBMS Oracle fornisce diverse funzioni di controllo della sicurezza del sistema. Tra queste e' anche presente una funzione di AUDIT TRAIL che consente di registrare ogni attivita' di interesse svolta sul database. A questo si aggiunge la normale attivita' di logging degli errori/attivita' che su Oracle viene effettuata sui file di alert e, anche a seconda delle versioni, su innumerevoli altri file.
Le possibilita' di controllo di auditing sono molto sofisticate e flessibili, ma e' necessario evitare un controllo eccessivo per non rendere inutilmente pesante gli accessi ed impossibili le verifiche. Le funzionalita' di auditing sono presenti in modo molto completo fino dalle prime releases di Oracle e sono state sempre aggiornate mantenendole in linea alle piu' stringenti normative e standard.
Una descrizione piu' completa si trova in questo documento.

PostgreSQL permette di effettuare un auditing delle attivita' con diversi strumenti che rispondono alle crescenti esigenze di auditing. La modalita' di base con PostgreSQL per registrare gli accessi e le attivita' eseguite sul database e' quella di attivare il logging.
Il logging si abilita impostando gli opportuni parametri nel file di configurazione postgres.conf.
Utile in qualche caso puo' essere l'utilizzo di trigger o di extension specifiche.
Una descrizione piu' completa si trova in PostgreSQL logging ed auditing [NdE di cui esiste anche una versione per AWS]

Su MySQL e' disponibile l'Audit Plugin API che viene utilizzato per raccogliere le attivita' svolte sul DB. L'MySQL Enterprise Audit utilizza tale API ed e' inclusa nella MySQL Enterprise Edition, ma non fa parte della Community Edition. Sono tuttavia disponibili diversi plug-in di terze parti utilizzabili anche con la versione MySQL Community. la configurazione si effettua impostando gli opportuni parametri nel file my.cnf.
Su MySQL e' presente il parametro init_connect che consente di lanciare statement custom al momento della connect va pero' notato che il parametro init_connect non si applica agli utenti DBA, quindi non e' possibile utilizzarlo per tracciare le utenze amministrative.
Utile in qualche caso puo' essere l'utilizzo di trigger.
Una descrizione piu' completa si trova in questi documenti: audit plugin, audit triggers, MySQL Proxy.

I dati raccolti dall'auditing e dal logging dei database (cosi' come quelli del sistema operativo e delle eventuali applicazioni) vanno opportunamente raccolti ed analizzati da un SIEM.

Continuita' operativa

La continuita' operativa e' una componente fondamentale della gestione dati.

Le problematiche di disponibilita' dei dati e di continuita' operativa sono da sempre un aspetto fondamentale di tutti i sistemi di gestione delle basi dati (DBMS). E' quindi naturale che ogni prodotto DBMS consenta un'ampia scelta di possibilita' per realizzare il livello desiderato di disponibilita' dei servizi e dei dati.
L'analisi delle diverse alternative tecniche per l'implementazione di una soluzione dei servizi di IT Service Continuity Management non puo' prescindere da una precedente Business Impact Analysis (BIA) che analizzi l'impatto sull'ente o azienda dei rischi sui diversi servizi erogati (Risk Assessment). Elementi fondamentali nella scelta delle soluzioni sono la determinazione del Recovery Point Objective (RPO) e del Recovery Time Objective (RTO). Altro elemento per l'analisi e' la conoscenza degli SLA declinati sia per il sistema primario che per il sistema secondario.
Nella scelta della soluzione tecnologicamente piu' adatta vanno valutate tutte le alternative, che non necessariamente sono funzionalita' specifiche dell'RDBMS. I sistemi operativi e le infrastrutture di storage offrono infatti molteplici possibilita' per la replicazione di dati. E' quindi importante segnalare tecnologie quali: Storage Replication, Failover Cluster, Load Balancer (sia HW che SW), Volume Replication, ...

Il documento Architetture di Database per la Continuita' Operativa ed il Disaster Recovery riporta le principali architetture e soluzioni per la realizzazione della continuita' operativa (Business Continuity: BC) e dei siti di Disaster Recovery (DR) con una particolare attenzione alle basi dati.

Ultimo ma non da ultimo... i backup!

Cifratura

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. La cifratura e' una delle principali tecniche utilizzate per i database come descritto nel documento Opzioni di crittografia nei database.
Le soluzioni tecniche utilizzate dai DB presentano notevoli differenze: in alcuni casi alcune soluzioni sono nettamente piu' sicure, in altri casi e' molto difficile, anche per gli esperti, indicare quelle piu' sicure.

La cifratura dei dati non e' l'unica tecnica utilizzabile, altrettanto importanti ed efficaci sono da minimizzazione dei dati e la pseudonimizzazione. Da questo punto di vista e' fondamentale un'analisi approfondita.

Diverse funzioni utili per la pseudonimizzazione sono contenute nel package miXen [NdA disponibile anche per MySQL].

Hardening

Una configurazione corretta e' necessaria per mantenere sicure le basi dati.
Le procedure di installazione e configurazione ufficiali dei diversi RDBMS sono ora particolarmente sicuri. Deve pero' essere sottolineato che fino a poco tempo fa, su alcune basi dati, la procedura di installazione standard creava database con evidenti problemi di sicurezza. Questo va tenuto in dovuto conto sulle istanze di database gia' installate o di versioni precedenti che possono presentare problematiche di sicurezza anche molto gravi.
Una volta effettuata una corretta installazione e' comunque necessario eseguire l'hardening della rete, del sistema operativo e delle basi dati.

DBSAT e MySAT sono due tool utili per controllare la corretta configurazione. Altre utili sorgenti di informazioni sono i CIS Benchmark e le STIG.

Varie ed eventuali

Utili sono i seguenti documenti, specifici per RDBMS, che contengono le indicazioni tecniche di dettaglio per la gestione della sicurezza sui database: MySQL, PostgreSQL, Oracle, ...

Titolo: DB LEX
Livello: Medio (2/5)
Data: 14 Febbraio 2018
Versione: 1.0.4 - 14 Febbraio 2023
Autore: mail [AT] meo.bogliolo.name