Sicurezza nei sistemi di basi dati distribuiti

Sicurezza nei sistemi di basi dati
distribuiti
Dario Firusbakht
22 marzo 2005
1
Prefazione
L’importanza sempre maggiore che la conservazione, il ritrovamento e l’ordinamento delle informazioni assume in tanti settori “delicati” della società
ha comportato, negli ultimi anni, una crescente attenzione alle problematiche legate alla sicurezza nei database. Per quanto riguarda alcuni campi
di utilizzo delle basi dati, possiamo addirittura asserire che la sicurezza dei
dati è da considerarsi un aspetto prioritario rispetto ad altri, infatti mentre
una progettazione errata, che fornisca un database estremamente lento ma
sicuro, potrebbe essere accettata anche da un istituto bancario, una banca dati ben ottimizzata ma che permetta a chiunque di modificarne i dati
sarebbe chiaramente inaccettabile per qualunque impresa.
La sicurezza dei dati include generalmente due aspetti: Protezione dei
dati mediante tecniche di crittografia e controllo sull’accesso ai dati. Mentre
i problemi legati alla crittografia per rendere sicura la conservazione o l’invio
dei dati risultano essere comuni a molti settori dell’informatica, il problema
del controllo sull’accesso ai dati, di cui ci occuperemo, è più specifico ai
database tradizionali e distribuiti.
Possiamo enumerare tre stadi di sicurezza fondamentali per ogni database,
corrispondenti ai primi tre capitoli di questo lavoro:
1. autenticazione degli utenti
2. controllo autorizzazione a visionare i dati
3. prevenzione o riduzione degli attacchi tramite canali di inferenza
I primi due punti possono essere esplicati con una comune situazione per
un database: Quando un utente richiede l’acceso al sistema, primo compito del dbms è quello di autenticarlo positivamente, solitamente tramite la
coppia user-id/password; una volta connesso al sistema, l’utente, presumibilente presenterà delle interrogazioni al database, prima di rispondere è
1
nuovamente compito del dbms di assicurarsi che l’utente sia autorizzato da
parte del db administrator a visualizzare i dati richiesti. L’ultimo punto è
un problema specifico ai database relazionali1 e si basa sulla possibilità , da
parte di utenti non autorizzati, di ottenere informazioni riservate tramite
procedimenti logici senza effettivamente accedere ai dati protetti.
Generalmente possiamo asserire che le problematiche connesse ai tre stadi
presentati possono essere risolti nei tradizionali database con buon senso, esperienza e soprattutto con un’attenta progettazione. Per quanto riguarda le
basi di dati distribuite, invece, lo scenario si complica notevolmente; infatti la
possibilitá di progettare e realizzare una base di dati distribuita in vari modi
(es: grado di autonomia, eterogeneità ) fa si che la risoluzione dei problemi
di sicurezza ponga quesiti concettuali prima ancora che di implementazione.
Proprio su questi problemi concettuali, nonchè sullo studio di alcuni
sistemi commerciali, si concentra il presente lavoro.
2
Autenticazione degli utenti
L’autenticazione degli utenti è un requisito indispensabile per ogni sistema,
una corretta identificazione permette infatti di determinare i privilegi ed il
gruppo di appartenenza dell’utente.
Durante la fase di progettazione di una database distribuito il primo quesito
da porsi, per quanto riguarda la sicurezza, è chi si occuperà dell’autenticazione degli utenti.
In un sistema tradizionale gli unici attori che prendono parte al dramma
sono l’utente 2 e il dbms; sarà quindi compito del db administrator gestire
la creazione e la rimozione degli utenti che hanno diritto a connettersi al
database. Ricordiamo che per permettere lo svolgimento di questo compito,
lo standard SQL mette a disposizione dell’amministratore due comandi:
CREATE USER <nome utente> IDENTIFIED BY ’<password>’
DROP USER <nome utente>
Per la creazione e la rimozione degli utenti. In un database distribuito
invece gli attori sono tre: utente, ddbms e dbms locale, oppure, nel caso
di comunicazione diretta tra diversi siti del database distribuito, utente,
dbms remoto e dbms locale. Questo passaggio intermedio permette, già di
discriminare tra tre implementazioni diverse:
1. L’utente é autenticato dal dbms locale
2. L’utente é autenticato dal ddbms (o al dbms remoto)
3. L’utente è autenticato in entrambi i siti
1
2
gli unici trattati in questo articolo
Sia esso un’applicazione o un utente vero e proprio
2
La scelta della prima opzione implica la mancanza di autenticazione
centralizzata, ovvero la presenza di un ddbms liberamente accessibile per
tutti, condizione che, oltre a permettere a chiunque un parziale accesso al
computer su cui è installato il ddbms, risulterebbe un inutile incremento di
traffico verso i vari siti che compongono il database. Nel caso di un database
distribuito gestito tramite un’amministrazione strettamente centralizzata la
seconda soluzione risulta ovviamente la più auspicabile, la sua realizzazione
non presenta particolare difficoltà (la si puó paragonare alla strategia utilizzata dai database tradizionali). Quello che viene richiesto ai dbms locali è
semplicemente di accettare qualunque connessione proveniente dal ddbms.
Un sistema basato su questa implementazione lascerebbe agli amministratori
locali un livello di autonomia molto limitata ed inoltre la compromissione
del sito centrale avrebbe un effetto disastroso su tutta la basi dati distribuita.
In effetti per assicurare un livello accettabile di sicurezza ad un database
distribuito che lasci un buon grado di autonomia ai dba locali, è necessario
che ogni utente venga autenticato sia in remoto che localmente.
La scelta di questo metodo presenta due ulteriori scelte di realizzazione[2]:
1. Ogni sito possiede informazioni sufficienti per autenticare gli utenti,
inoltre, nel caso di connessione tra siti, il dbms remoto deve fornire al
sito locale l’user id e la password dell’ utente.
2. Ogni sito del database distribuito si identifica presso gli altri siti tramite
una sorta di password di sito (o tramite un meccanismo simile), rendendo superfluo l’autenticazione locale dell’utente.
La replicazione delle informazioni relative agli utenti, come nel primo metodo, implica un alto costo per ciò che riguarda l’aggiornamento o la modifica
dei dati relativi a qualunque utente. D’altra parte la soluzione presentata
al punto 2. presume la conoscenza da parte degli amministratori del sito di
ogni connessione possibile per ogni utente.
Come vedremo successivamente la scelta implementativa del dbms Oracle è
una variante della seconda tecnica di autenticazione.
3
Controllo autorizzazione sui dati
Accertarsi che solo gli utenti autenticati positivamente riescano ad accedere
al database, non esaurisce il compito del db administrator infatti il dbms
è chiamato anche ad assicurarsi che ogni richiesta inoltrata da gli utenti
sia stata propriamente autorizzata dall’amministratore del sistema. Più formalmente potremmo dire che compito del dbms è controllare che la tripla
composta da (nome utente, operazione richiesta, oggetto del db invocato 3 )
3
Sia esso una tabella, vista o tupla
3
sia valida. Utilizzando lo stesso formalismo potremmo dire che il rilascio
di una autorizzazione da parte dell’amministratore della base dati, consiste
nella creazione della tripla (nome utente, operazione richiesta, oggetto del
db invocato) che, intuitivamente, specifica che un certo utente è abilitato ad
eseguire uno specifico comando su un oggetto della banca dati. Per eseguire
questo compito SQL mette a disposizione dei db administrators due appositi
comandi:
GRANT <tipo di privilegio> ON <oggetto> TO <nome utente>
REVOKE <tipo di privilegio> FROM <oggetto> TO <nome utente>
In realtà la sintassi di questi due comandi è piuttosto ampia, a riprova della
grande complessità che le banche dati possono assumere; a titolo di esempio
riportiamo di seguito le specifiche formali del comando GRANT[6]:
GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ...
ON {tbl_name | * | *.* | db_name.*}
TO user [IDENTIFIED BY [PASSWORD] ’password’]
[, user [IDENTIFIED BY [PASSWORD] ’password’]] ...
[REQUIRE
NONE |
[{SSL| X509}]
[CIPHER ’cipher’ [AND]]
[ISSUER ’issuer’ [AND]]
[SUBJECT ’subject’]]
[WITH [GRANT OPTION | MAX_QUERIES_PER_HOUR count |
MAX_UPDATES_PER_HOUR count |
MAX_CONNECTIONS_PER_HOUR count |
MAX_USER_CONNECTIONS count]]
Per comodità è possibile inoltre utilizzare la definizione di gruppi di utenti
cosı́ come previsto dallo standard SQL con il comando:
DEFINE GROUP <nome gruppo> AS <lista degli utenti>
Facciamo inoltre notare come i tipi di privilegi previsti dai dbms più
diffusi siano innumerevoli4 ; per esempio la documentazione di MySQL ne
cita ben 26.
Cosı́ come precedentemente visto per l’autenticazione, nel caso di database
tradizionali, l’assegnazione di autorizzazioni corrette da parte del dba administrator non presenta particolari difficoltà implementative, si tratterà
solo di pianificare accuratamente ed implementare correttamente la politica
di sicurezza che si ritiene più adatta, sfruttando i comandi SQL; una volta
4
A differenza, per esempio, dei sistemi operativi
4
impostati i permessi relativi ad ogni utente, non bisognerà far altro che affidarsi al controllo del dbms5 .
Quando si parla di sistemi di controllo per l’autorizzazione nelle basi dati
distribuite, il problema si complica non poco, e, cosı́ come per l’autenticazione, la scelta di una soluzione invece di un altra è fortemente legata al
livello di autonomia ed etereogeneità che si decide di adottare nel database
distribuito.
Immaginiamo di dover amministrare un sistema che lascia molta autonomia
ai singoli siti, per esempio di tipo federato, il lancio di una query su un sito
prevederà , probabilmente la necessità di andare a recuperare informazioni
in tabelle presenti su altri database. Cosı́ come per il problema dell’autenticazione, il quesito che dobbiamo porci è :“chi deve assicurarsi che l’utente
abbia i necessari privilegi per visualizzare i dati?”
Se il dbms presente sul sito di iniziale fosse già a conoscenza delle autorizzazioni che ogni utente gode ad ogni sito avremmo certamente una maggior
efficienza computazionale; infatti per il dbms di partenza l’autorizzazione
di questa richiesta risulterebbe del tutto analoga a quella per le richieste
locali.
Per poter utilizzare una stategia del genere è necessario una replicazione
completa delle tabelle relative alle autorizzazioni, procedimento delicato e
anch’esso costoso.
Generalmente anche la scelta riguardo a chi gestisce l’autorizzazione sui
vari oggetti presenti nel database distribuito può essere un motivo di incertezza, per assicurare una gestione della base dati distribuita risulta comunque auspicabile un certo livello di collaborazione tra gli amministratori
locali e l’amministratore globale.
4
Attacchi tramite canali di inferenza
La classificazione del livello di riservatezza delle informazioni non è un problema banale, in [3] viene esposta la dimensione del problema mostrando tre
possibili livelli di classificazione dei dati:
1. I dati possono essere ritenuti sensibili
2. L’esistenza dei dati può essere ritenuta un’informazione sensibile
3. Il motivo per voler proteggere i dati può essere a sua volta un’informazione riservata
La 1. può essere facilmente ottenuta utilizzando le strategie e i comandi
SQL presentati nei capitoli precedenti. Mentre gli ultimi due punti pongono
molte problematiche di sicurezza, infatti la semplice negazione dell’accesso
5
Vedremo nel prossimo capitolo che talvolta le cose sono più complesse
5
ai dati6 non può ritenersi sufficiente.
Per capire meglio il concetto immaginiamo una compagnia il cui database
mantenga le seguenti tabelle accessibili a tutti i dipendenti:
Prog.
A001
A002
A003
Costo
2000
1500
1600
Responsabile
Rossi
Bianchi
Verdi
Impiegato
Rossi
Bianchi
Verdi
Specialità
esplosivi
vernici
fertilizzanti
e la seguente tabella, al cui contenuto non è permesso l’accesso alla maggior
parte dei dipendenti per la potenziale segretezza delle informazioni.
Prog.
A001
A002
A003
Argomento
sviluppo esplosivi
sviluppo vernici
sviluppo fertilizzanti
Questa schema non presenta particolari anomalie: Infatti è plausibile che,
all’interno della compagnia, sia necessario rendere pubbliche le prime due
tabelle, magari per motivi di contabilità o per eseguire ricerche statistiche
sugli studi svolti dai dipendenti, mentre l’argomento dei progetti in corso
potrebbe aiutare la concorrenza se rivelato, o come nel nostro caso, potrebbe
trattarsi di un oggetto altamente confidenziale.
Purtroppo, anche in presenza di una perfetta gestione dei permessi per l’accesso ai dati, non sarebbe difficile per un utente non autorizzato dedurre
(inferire) che il progetto A001 si occupa dello sviluppo di esplosivi mentre il
progetto A002 si occupa dello sviluppo di vernici. Quello che questo schema
rende possibile fare è infatti la creazione di un canale di inferenza.
Al fine di mostrare quanti tipi diversi di canali di inferenza è possibile
creare mostriamo un esempio che sfrutta l’aggiramento di un particolare
tipo di sicurezza7 previsto nei database relazionali; le ultime versioni di
molti database commerciali (come i due che presentiamo di seguito) infatti
prevedono la possibilità da parte dell’amministratore di specificare diversi
livelli di accesso per ogni singola tupla, indubbiamente un valido strumento
aggiuntivo. Prendiamo la seguente situazione:
Camion
C123
C123
C123
C124
6
7
Comparto
1
2
3
...
Contenuto
Matite
Diamanti
Scarpe
...
Tramite il comando REVOKE
Row level access
6
livello accesso
pubblico
riservato
pubblico
...
Immaginiamo che il fatto che a bordo del camion C123 vengano trasportati
diamanti sia noto solo ai dirigenti più fidati della compagnia.
Se un addetto ai trasporti eseguisse una query sul contenuto del camion
C123 otterebbe la seguente tabella, conforme ai permessi a lui assegnati:
Camion
C123
C123
Comparto
1
3
Contenuto
Matite
Scarpe
Il problema è che, una volta notato lo spazio vuoto, l’addetto ai trasporti
potrebbe tentare di inserire un nuovo record nel comparto 2 per evitare che
il camion resti parzialmente vuoto. La violazione del vincolo di unicità del
campo Comparto comporterebbe un fallimento nell’inserimento che permetterebbe all’addetto in questione di “inferire” che il camion C123 contiene
al suo interno qualcosa di prezioso.
Formalmente possiamo affermare che i canali di inferenza sono creati quando informazioni ad un basso livello di classificazione permettono di derivare
informazioni ad un più alto livello di classificazione. L’esistenza di questo
problema è dovuta al fatto che che le tecniche di controllo presentate precedentemente proteggono i dati dai tentativi di accesso (non autorizzato) diretto mentre falliscono la protezione rispetto ad accesso indiretto.
Per quanto riguarda i database tradizionali, la difficoltà di prevenire la
creazione di canali di inferenza ha stimolato una ampia ricerca sullo stesso,
testimoniata dalla numerosa letteratura sull’argomento.
Generalmente gli studi che si sono occupati della risoluzione di questo problema si sono basati su due punti distinti:
• Accurato controllo delle informazione da divulgare (data sanitization);
• Creazione di appositi “motori di inferenza” che si occupano di controllare che almeno uno dei dati utilizzati per la derivazione sia classificato
allo stesso livello di confidenzialità del dato derivato.
Sfortunatamente il costo computazionale legato all’utilizzo dei motori di
inferenza risulta essere molto elevato. Nel campo delle basi dati distribuite
lo studio svolto per la ricerca di una soluzione accettabile risulta essere molto
scarsa. A riprova di ciò riportiamo la frase di apertura delle conclusioni di
L. Chang, I. S. Moskowitz 8 , pubblicato nel 2002:
Il problema dell’inferenza rispetto ai database distribuiti è essenzialmente una nuova area di ricerca.
Ciò che viene evidenziato è che la risoluzione del problema, per i database
distribuiti, lungo le linee guida presentate precedentemente incontra due
8
Vedi [5] nei rifrimenti bibliografici
7
grossi problemi:
La presenza di dati distribuiti su vari siti con la presenza di dati replicati, o
talvolta con le stesse informazioni utilizzate per fini diversi9 , potrebbe rendere logisticamente impossibile un efficente data sanitization.
L’utilizzo di motori di inferenza su ogni sito del database porterebbe un
costo computazionale eccessivamente elevato.
Anche se la questione dei canali di inferenza può apparire come un problema
secondario rispetto alle questioni presentate nei precedenti capitoli, in realtà
se si tiene conto del reale utilizzo che solitamente viene fatto dei database, è
forse il più importante: Un’agenzia di marketing, interessata ad ottenere più
informazioni possibili sulla popolazione al fine di condurre campagne pubblicitarie mirate, non tenterebbe mai di introdursi illecitamente all’interno
di un database della pubblica amministrazione, ma cercherebbe di collegare
insieme i dati pubblicamente disponibili su vari siti al fine di inferire informazioni utili per il proprio fine. A causa di questo sua caratteristica di essere
una sorta di “intrusione senza scasso” la questione dei canali di inferenza
tende spesso ad essere accomunata ai problemi di privacy che tanta importanza hanno assunto negli ultimi anni. A riprova di quanto appena detto
facciamo notare che il primo studio del problema è stato commissionato
proprio dall’ US Census Bureau preoccupato per il possibile rilascio non intenzionale di informazioni personali da parte di database di tipo statistico 10 .
5
Oracle Distributed Database Systems
Parlare di sicurezza nei database relazionali senza nominare Oracle è pressochè impossibile; infatti ormai da tempo questo dbms è riuscito a primeggiare nel mercato dei dbms anche dal punto di vista della sicurezza. Al fine
di mantenere la leadership nel settore ogni nuova versione di Oracle tende
ad inglobare gli ultimi ritrovati tecnologici, rendendo il prodotto sempre più
complesso. Per ovviare a questo problema si è deciso di analizzare una versione del database non recentissima ma che ha comunque tracciato le linee
guida rispetto all’approccio generale di Oracle al problema della sicurezza
nei database distribuiti.
L’implementazione distribuita del dbms Oracle permette di implementare
sistemi di basi dati distribuite eterogenee in cui i singoli nodi godono di un elevato grado di autonomia. In pratica Oracle offre ai suoi utenti la possibilità
di continuare ad usare gli strumenti e le peculirità del dbms tradizionale anche in caso si desideri creare un database distribuito.
9
Si pensi all’utilizzo dei dati anagrafici dei cittadini all’interno della pubblica
amministrazione
10
database che permettono esclusivamente il ritrovamento di informazioni tramite
funzioni aggregate come COUNT, AVG e SUM
8
Lo strumento principale messo a disposizione da Oracle per la sicurezza nei
database distribuiti è l’Oracle Security Server (OSS), il quale, in linea di
principio, permette di gestire centralmente le autorizzazioni e di gestire in
modo distribuito le autenticazioni.
Inizialmente Oracle permette di stabilire sull’OSS degli utenti globali (global users), al fine di semplificare ed uniformare l’amministrazione tramite il
comando:
CREATE USER <nome utente> IDENTIFIED GLOBALLY AS ’<nome globale>’
e delle autorizzazioni globali (global roles) tramite il comando:
CREATE ROLE .... IDENTIFIED GLOBALLY
Prima di connettersi ad un sito del database ogni utente è tenuto ad
autenticarsi presso l’Oracle Security Server che gli fornisce un certificato
digitale. Questo certificato dovrà essere presentato ad ogni sito a cui l’utente desiderà connettersi, i quali potranno verificarne l’autenticità ancora
tramite il Security Server. Una volta verificata l’autenticità del certificato
digitale il dbms che ha ricevuto la richiesta di connessione si occuperà di ottenere dall’OSS l’elenco delle autorizzazioni globali che riguardano l’utente.
Questo tipo di implementazione permette di rendere trasparente, per esempio, all’utente l’eventuale connessione a vari siti del database nel corso di
una query. Al tempo stesso l’utilizzo del Security Server elimina anche il
problema della replicazione delle tabelle relative ai permessi degli utenti.
Per quanto riguarda la connessione diretta tra diversi siti del database, anche in questo caso l’Oracle Security Server fornisce ad ogni sito un certificato
digitale di cui gli altri siti potranno verificarne l’autenticità sempre tramite
il Security Server.
6
IBM DB2 Universal Database
Sviluppato dalla IBM e degno rivale del dbms Oracle, con cui compete ormai da anni sia dal punto di vista commerciale che dal punto di vista delle
prestazioni, questo ‘peso massimo’ tra i database, è rimasto più legato alle
specifiche originali dei primi database relazionali; come conseguenza, a differenza di Oracle, nella sua implementazione distribuita lascia molta più
libertà implementativa al db administrator.
Riguardo il problema dell’autenticazione degli utenti in ambiente distribuito
ed etereogeneo è possibile stabilire a seconda delle necessità chi, tra il sito
locale e il sito remoto, si occupi della corretta autenticazione.
DB2 prevede quattro distinti metodi:
• Server: L’utente si connette a DB2 tramite la coppia user/password
rendendo cosı́ possibile inviare ad ogni sito le informazioni necessarie
per autenticare l’utente;
9
• Client: L’autenticazione è eseguita su DB2 utilizzando le credenziali offerte dal sistema operativo. Come conseguenza non è possibile
inviare ai siti remoti alcuna password.
• DCS: Specifica che i siti con dbms locali propri (non DB2) hanno
in gestione propria l’autenticazione degli utenti, DB2 si deve limitare
ad inviarli le informazioni sull’utente by-passando la sua routine di
autenticazione.
• DCE: In questo caso sono l’user id è disponibile per l’invio ai vari siti
del database distribuito.
Nel caso siano implementati i metodi Server o DCE è possibile creare una
sorta di utenti globali11 tramite il comando:
CREATE USER MAPPING FOR "<nome utente>" SERVER <server DB2>
OPTIONS (REMOTE_AUTHID <nome utente remoto>,
REMOTE_PASSWORD <password utente>)
Dove si specifica a DB2 di creare un alias per l’utente remoto al fine di semplificare l’amministrazione attraverso i vari siti.
Per l’autorizzazione delle richieste degli utenti, l’approccio adottato dagli
sviluppatori di DB2 Universal Database è diametralmente opposto a quello scelto da Oracle: Ogni sito mantiene pieno controllo sugli oggetti che
possiede, di conseguenza, sarà compito dei vari database assicurarsi che le
richieste provengano da utenti autorizzati. A seguito di questa scelta implementativa, a differenza di Oracle, non sono previsti comandi SQL-like per
specificare i permessi in ambiente distribuito.
7
Conclusioni
Quello che si è cercato di mettere in luce con questo lavoro sono le principali
problematiche legate alla sicurezza nei sistemi di basi dati distribuiti. Abbiamo cercato di rendere evidente come la complessità del problema sia legata
intrinsicamente alle possibilità di implementare in vario modo un database
distribuito. Lo studio, sebbene parziale, di due sistemi commerciali tra i
più diffusi ed apprezzati, ci ha confermato che non esiste una ricetta unica
per assicurare un adeguato livello di sicurezza ai dati in ambiente distribuito.
Considerazioni a parte vanno fatte riguardo al problema degli attacchi tramite
canali di inferenza presentati nel quarto capitolo; la ricerca di articoli specifici all’argomento, sia sul sito del DB2 che su quello di Oracle, non ha ritornato
nessun risultato rilevante. Riprova del fatto che ancora molta strada deve
essere percorsa per ovviare a questi problema, il quale, ad onor del vero,
riguardano più la sfera dell’organizzazione delle informazioni da parte del
progettatore.
11
Cosı́ come previsto da Oracle
10
Riferimenti bibliografici
[1]
S. De Capitani di Vimercati, P. Samarati Access Control in Federated System Proceedings of the 1996 workshop on New Security
Paradigms
[2]
M. Tamer Özsu P. Valduriez Principles of Distributed Database
Systems, Prentice Hall 1999
[3]
S. P. Coy Security Implications of the Choice of Distributed Database
Management System Model: Relational vs. Object-Oriented
[4]
S. Jajodia, C. Meadows Inference Problems in Multilevel Secure
Database Management Systems
[5]
L. Chang, I. S. Moskowitz A study of inference problems in distributed
databases, 2002
[6]
Reference manual for the MySQL Database System
[7]
Reference manual for the Oracle 8i Distributed Database Systems
[8]
Oracle Security Server Guide
[9]
M. Morgenstern Security and inference in multilevel database and
knowledge-base systems Proceedings of the 1987 ACM SIGMOD
international conference on Management of data, Vol. 16 Issue 3
[10]
C. Farkas, S. Jajodia The inference problem: a survey December
2002 ACM SIGKDD Explorations Newsletter, Volume 4 Issue 2
[11]
IBM DB2 Universal Database Administration Guide Version 6
11