Sicurezza dei sistemi informatici Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione Quarta lezione 6/6/2007 Contenuto Classificazione dei livelli di sicurezza di un S.O. Sicurezza su Windows Sicurezza su Unix Sistemi per la Intrusion Detection Sicurezza nei database Classificazione della sicurezza dei sistemi di calcolo Orange Book. Documento pubblicato dal Dipartimento della Difesa americano (D.O.D) Sono specificate quattro categorie di sicurezza:A, B, C, D (in ordine decrescente). Categoria D. Non ha livelli di sicurezza. Esempi MS-DOS, Windows 3.1. Classificazione Categoria C. Suddivisa in C1 e C2: C1. La Trusted Computing Base consente: Esempio: Unix C2. La TCB consente Autenticazione degli utenti (password). I dati di autenticazione sono protetti rendendoli inaccessibili agli utenti non autorizzati. Protezione dei dati e programmi propri di ogni utente. Controllo degli accessi a oggetti comuni per gruppi di utenti definiti oltre a quanto definito per la C1, il controllo degli accessi su una base individuale. Esempio UNIX, Windows NT e 2000. Classificazione Categoria B. Suddivisa in B1, B2 e B3 B1. La TCB consente, oltre a quanto definito in C2, l’introduzione dei livelli di sicurezza (modello Bell-La Padula). Almeno due livelli. B2. La TCB estende l’uso di etichette di riservatezza ad ogni risorsa del sistema, compresi i canali di comunicazione. B3. La TCB consente la creazione di liste di controllo degli accessi in cui sono identificati utenti o gruppi cui non è consentito l’accesso ad un oggetto specificato. Classificazione Categoria A. Suddivisa in A1 e classi superiori A1. E’ equivalente a B3, ma con il vincolo di essere progettato e realizzato utilizzando metodi formali di definizione e verifica. Un sistema appartiene ad una classe superiore ad A1 se è stato progettato e realizzato in un impianto di produzione affidabile da persona affidabile Cronologia di Windows: MS DOS 1981 MS-DOS 1.0 per IBM PC 1983 versione 2.0 1986 versione 3.0 sempre per 16 bits, line-oriented e single-user Windows 2.x/3.x è semplicemente una GUI per MS-DOS Cronologia di Windows: Windows 9x Windows 95 e 98 continuano ad avere molto in comune con MS-DOS molte parti sono a 16 bit hanno lo stesso file system diversità: integrazione del networking nel SO (problemi legali) nessuna sicurezza: condivisione degli spazi di memoria di tutti gli utenti Cronologia di Windows: Windows NT Negli ultimi anni 80 parte windows NT Indipendente da MS-DOS, nasce nel ‘93 fiasco sul mercato, piccolo successo come server NT 4.0 (1996) --> 16 M di codice C e C++ NT 5.0 (Windows 2000) --> 29 M di codice Possiede molte più features di Unix (window e GUI sono nel SO, ha codice per architetture diverse e per versioni diverse....) Libreria Win32 API è una libreria molto vasta di procedure che possono effettuare chiamate di sistema o anche possono operare semplicemente in user mode moltissime API grafiche garantisce la compatibilità con i SO precedenti Per contrasto, Unix definisce un numero esiguo di chiamate che restano fisse nelle diverse versioni Come funzionano le API di Win32 Le invocazioni di procedure Win32 creano oggetti (file, processi, thread ecc) La chiamata restituisce un handle all’oggetto che può essere utilizzato in altre chiamate E’ un po’ object-oriented: c’è l’incapsulamento, l’oggetto è manipolato (solo) con le funzioni previste Il registry E’ un database che contiene tutte le informazioni di configurazione hardware/software/sicurezza che sono necessarie al boot è una specie di file system con directory e file generalmente molto piccoli il registry è diviso in sezioni (ROOT KEYS), che contengono directories (keys) che a loro volta possono contenere subkeys o valori (file di testo) Root keys HKEY_LOCAL_MACHINE HKEY_USERS HKEY_PERFORMANCE DATA HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_CURRENT_CONFIG Manipolare il registry il registry è in formato proprietario, si manipola quindi (solo) con un registry editor, cioè regedit.exe L’integrità del registry è importante hives e keys hanno liste di permessi per i gruppi predefiniti Per default non l’audit non si fa, ma è previsto Procedure per manipolare il registry Esistono procedure win32 API per manipolare il registry: RegCreateKeyEx (crea un nuovo key) RegOpenKeyEx (ottiene un handle) RegEnumKeyEx (enumera le key) RegQueryValueEx (ricerca) Il registry è protetto accuratamente, la sua corruzione implica il reinstallo dell’intero sistema Caratteristiche di sicurezza in NT login sicuro con misure anti-spoofing (al CTRL-ALTDEL è chiamato il driver della tastiera che a sua volta chiama un programma di sistema “genuino”) controllo degli accessi discrezionale accesso privilegiato protezione dello spazio degli indirizzi di ciascun processo prima dell’uso le pagine di memoria vengono azzerate audit Gruppi e permessi Windows NT prevede molti utenti e gruppi predefiniti (i loro permessi di default sono nel Registry) Cio è molto utile per distribuire le responsabilità della gestione del sistema su vari utenti Anche l’insieme dei permessi è più ampio: oltre a read write ed execute, si può concedere take ownership, change permissions, delete,…. Permessi in Windows DELETE The right to delete the object. READ_CONTROL The right to read the information in the object's security descriptor, not including the information in the SACL. SYNCHRONIZE The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right. WRITE_DAC The right to modify the DACL in the object's security descriptor. WRITE_OWNER The right to change the owner in the object's security descriptor. FILE_ADD_FILE For a directory, the right to create a file in the directory. FILE_ADD_SUBDIRECTORY For a directory, the right to create a subdirectory. FILE_ALL_ACCESS All possible access rights for a file. FILE_APPEND_DATA For a file object, the right to append data to the file. For a directory object, the right to create a subdirectory. FILE_CREATE_PIPE_INSTANCE For a named pipe, the right to create a pipe. Permessi in Windows FILE_DELETE_CHILD For a directory, the right to delete a directory and all the files it contains. FILE_EXECUTE For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter. FILE_LIST_DIRECTORY For a directory, the right to list the contents of the directory. FILE_READ_ATTRIBUTES The right to read file attributes. FILE_READ_DATA For a file object, the right to read the corresponding file data. For a directory object, the right to read the corresponding directory data. FILE_READ_EA The right to read extended file attributes. FILE_TRAVERSE For a directory, the right to traverse the directory. By default, users are assigned the BYPASS_TRAVERSE_CHECKING privilege, which ignores the FILE_TRAVERSE access right. FILE_WRITE_ATTRIBUTES The right to write file attributes. FILE_WRITE_DATA For a file object, the right to write data to the file. For a directory object, the right to create a file in the directory. FILE_WRITE_EA The right to write extended file attributes. [...] Vantaggi Questa maggiore ricchezza di permessi di utenti e di gruppi, assieme al meccanismo di incapsulamento delle funzioni di sistema di Win32, rende possibile eseguire molti dei compiti usuali di amministrazione con permessi non di root Architettura Ogni utente (gruppo, host e server) ha un SID : è un numero che consiste di una breve intestazione e di un intero lungo (univoco) quando un utente inizia un processo, riceve un SAT (Security Access Token) SAT Security ID: identifica un utente in maniera univoca. Group SID: Una lista dei gruppi ai quali l’utente appartiene ai fini del controllo degli accessi. Un gruppo è un insieme di ID di utente. Ogni gruppo ha un unico SID. Privilegi: Una lista di servizi di sistema “security sensitive” che l’utente può chiamare. Esempio creare token. Default owner: se l’utente genera un nuovo oggetto può specificare se il proprietario dell’oggetto è l’utente stesso o un gruppo cui l’utente appartiene. Default ACL: lista iniziale di protezione associata agli oggetti che l’utente crea. La lista può essere successivamente modificata Controllo ogni volta che il processo chiede di usare una risorsa, il S.O. usa Il SAT del processo e Il Security Descriptor della risorsa stessa Security Descriptor Flags: definiscono il tipo ed i contenuti di un descrittore. Esempio: se sono contenute o no SACL e DACL. Owner:il proprietario dell’oggetto può essere un individuo o un gruppo. Il proprietario può cambiare i contenuti della DACL. Discretionary Access Control List (DACL): determina quali utenti e con quali operazioni possono accedere all’oggetto. E’ costituita da una lista di access control entries (ACEs). System Access Control List(SACL):specifica quali tipi di operazioni sull’oggetto generano audit messages. ACE Access Control Entry: contiene un SID individuale o di gruppo e una maschera di accesso che definisce i diritti che sono garantiti al SID. La maschera contiene quattro bit per indicare i diritti di accesso di lettura, scrittura, esecuzione e tutti i diritti. Altri bit indicano ulteriori diritti Esempio file SID GSID ACL SACL deny pippo 111111 allow franz 11000 allow everyone 10000 audit franz 111111 Scansione delle ACL La scansione si ferma alla prima ACE in cui corrisponde l’user o il group SID del processo che chiede di usare la risorsa se è DENY allora NO altrimenti ci deve essere ALLOW dell’operazione richiesta I DENY sono sempre all’inizio per successive operazioni rivolte alla stessa risorsa si usa la stessa ACE Per default ACL assente => accesso sempre permesso ACL vuota => accesso sempre negato File cifrati in Windows NT il file system permette di crittare i file mediante una chiave di 128 bit (diversa per ogni file) la chiave è usata per crittare il file (blocco a blocco) la chiave cifrata con la chiave pubblica dell’utente è inserita nel Registry per decrifare il file c’è bisogno della chiave segreta dell’utente Se il file deve essere condiviso, la chiave di cifratura è cifrata con le chiavi pubbliche di tutti gli utenti che vi possono accedere Cronologia di Unix 1960-70 MIT, Bell Labs e GE lavorano al S.O. MULTICS Bell lascia il progetto e Ken Thompson inizia lo sviluppo di Unix Sviluppato in C su PDP-11 ‘74 Portabilità attraverso quella del compilatore C Networking con TCP/IP Cronologia di Unix release 2.0 di Linux in ‘96 0.5M molto software viene portato su Linux esiste una GUI (KDE) Linux simile a Unix, condivide con quest’ultimo circa l’80% delle chiamate di sistema Login e password ogni utente autorizzato ha login e password ed identificato con userID e groupID le password sono criptate con una funzione one-way sono contenute in un file (spesso /etc/passwd) accessibile (rw) solo da root questo file è separato da quello di profilo (spesso /etc/profile) che contiene le azioni specifiche da eseguire al login che è accessibile dall’utente UID e GID UID sono interi a 16 bit (0-65535) UID speciali 0 = root, 1 = daemon (lp) 9 = audit i GID sono simili: 0 = system 1 = daemon per device... Utente Root root può fare quasi tutto, tranne recuperare le password (nessuno lo può fare) può essere qualsiasi utente può montare e smontare file systems decidendo gli accessi consentiti quindi root è anche un punto debole: conviene separare i diversi compiti del system manager usando altri utenti come daemon per il networking Punti importanti sulla sicurezza in Unix la politica degli accessi è espressa tramite ACL semplificate Il metodo per consentire ad un processo di accedere a risorse per cui non avrebbe i permessi è l’invocazione controllata File system in Unix Unix organizza i file in una struttura ad albero, i nodi interni sono folder (comunque file) e le foglie sono i file semplici ogni file nella directory è un puntatore ad un inode che contiene varie informazioni mode, link counter,uid, gid dell’owner, time, block count, posizione fisica ACL in Unix 12 bit ℓ link counter rwx r-- r-- permessi permessi permessi di dell’owner del gruppo tutti gli altri dell’owner Controllo delle ACL quando un processo (UID e GID) chiede di accedere un file: i permessi vengono esaminati da sinistra a destra, se UID è l’owner del file allora valgono i primi 3 bit se il GID è quello dell’owner del file allora vale la seconda terna altrimenti vale la terza terna Directory ogni utente ha una home ed altre directory si creano con mkdir Le directory hanno permessi come i file ma con i seguenti significati: x= è richiesto per entrare (cd) nella directory e per aprire file in essa (non si può fare ls) w= creare e distruggere file r= si può fare ls Invocazione controllata in Unix è possibile specificare che un eseguibile E quando viene invocato da un processo P non prende lo UID e GID di P bensì quelli del creatore di E se questo è root o un utente con privilegi particolari allora questi vengono “prestati” all’utente di P un tale programma si chiama SETUID o SETGID Invocazione controllata l’invocazione controllata è il modo in cui UNIX media TUTTE le richieste di accesso alle risorse Per ogni richiesta avviene l’invocazione di un processo di sistema eseguito come root (o utente speciale) che controlla che la richiesta sia autorizzata e, se lo è, esegue l’azione richiesta e poi ritorna all’utente Esempio gestione di una stampante lp /dev/lp ma se definiamo un programma stampa(lp) che accede alla stampante e tale che: owner un daemon (lp) ACL rw- --- --- nessuno a parte lp può usare la stampante il suo owner sia il daemon lp e sia SETUID, allora ogni utente può usare la stampante e SOLO con stampa(lp) Invocazione ed incapsulamento ogni utente può usare l’invocazione controllata per ottenere incapsulamento se l’utente U ha un file X che vuole proteggere, cioè vuole che venga consultato solo con un dato programma PX, allora può fare così: crea utente UX owner di PX e di X (con permessi rw) e rende PX SETUID poi rende PX eseguibile da Y Y eseguendo PX diventa UX e quindi può accedere a X SETUID Un comando con SETUID root è passwd cambia la password deve accedere al file delle password crittate Un altro è login chmod 4/// nome --> SUID all’esecuzione chmod 2/// nome --> SGID all’esecuzione Processo di login riceve login e passwd codifica la passwd e controlla che sia corretta nel profile trova l’ambiente (sh, csh, ksh…) apre input e output standard esegue setuid e setgid dell’utente esegue la shell e termina la shell continua con UID e GID giuste 1. ogni comando nella shell inizia un processo che eredita la UID e GID della shell 2. ogni file che viene creato riceve quella UID e GID 3. quando un processo tenta di accedere per la prima volta ad un file la UID e GID sono usate per controllare se l’accesso è consentito 4. il processo riceve un file descriptor e nelle successive operazioni, non ci sono più controlli 5. se il modo di un file cambia, il cambiamento entra in effetto dopo la chiusura Protezione delle device sono come files e quindi hanno i loro permessi: /dev/mem mappa della memoria fisica /dev/kmem mappa della memoria virtuale il system manager non deve lasciare permessi pericolosi Possono condurre ad attacchi al livello sottostante mount mount serve per montare file systems: offre opzioni di sicurezza -r = read only nosuid = mettere a 0 tutti i SUID e SGID bit noexec = nessun binario può essere eseguito Auditing ricorda i fatti rilevanti per la sicurezza in un file protetto: per scoprire l’intrusione per rispondere all’intrusione (pericoloso) oltre a restringere l’accesso al file di log, conviene mandarlo su altre macchine o stamparlo Auditing e SETUID i programmi SETUID mettono in crisi l’auditing perchè viene ricordato l’UID del processo che è diverso da quello dell’utente che richiede l’operazione abbiamo visto che ci sono comandi del sistema per risalire alla UID e GID reale uid=getuid(), gid=getgid() // reale uid=geteuid(), gid=getegid() // effettivo Problemi con l’invocazione controllata Il meccanismo dell’invocazione controllata si presta ad un attacco molto pericoloso ed usato di frequente: Stack overflow L’intruder acquisisce i diritti di root e può causare molti danni... Access Control List in Unix Al pari delle ultime versioni di Windows, anche in Unix è possibile usare le ACL, descritte secondo lo standard POSIX Non tutte le versioni di Unix e di Linux supportano tale standard Comunque non tutte le applicazioni controllano le ACL Posix ACL Tipi di ACL entry Owner user::rwx Named user user:name:rwx Owning group group::rwx Named group group:name:rwx Mask mask::rwx Others other::rwx Posix ACL ACL minime Contengono solo tre entry Sono equivalenti ai bit di permesso di UNIX tradizionale ACL estese Hanno più di tre ACL entry Contengono una mask entry Possono contenere qualunque numero di named user e di named group entries Funzionamento delle ACL Le ACL minime funzionano come al solito Le ACL estese hanno il seguente funzionamento Tutti i named user e i named group entrano a far parte della classe group Bisogna distinguire fra: permessi della classe group ACL entry della classe group I permessi della classe group sono contenuti nella maschera e rappresentano un "upper bound" ai permessi che possono essere ottenuti dalle entry della classe gruppo Esempio Con i seguenti permessi user::rw group::r others::r user:jane:rwx mask:rw l’utente jane ha diritti rw ACL di default Come vengono ereditate le default ACL? la default ACL viene copiata nella access ACL dei nuovi file la default ACL viene copiata nella default ACL delle nuove directory Ulteriori dettagli quando un file viene creato possono essere specificati dei diritti di accesso viene effettuata l'intersezione tra questi e la default ACL se una directory non ha default ACL, si utilizza il meccanismo tradizionale UNIX (umask, etc.) Intrusion detection Un meccanismo estremamente importante da utilizzare per controllare la sicurezza di un sistema è quello degli IDS (Intrusion Detection System) Si può fare a livello di host (HIDS) e a livello di network (NIDS) Principi di base Distinguere situazioni normali da quelle anomale L’utente in condizioni normali si comporta in modo più o meno prevedibile non compie azioni atte a violare la sicurezza i propri processi compiono solo azioni permesse Scopi di un IDS Scoprire un ampia gamma di intrusioni, sia già note che non note Scoprirle velocemente, non necessariamente in tempo reale Presentare i report delle analisi in formato semplice e facilmente comprensibile Essere accurato, evitando possibilmente falsi positivi e falsi negativi Modelli per l’IDS Detection di anomalie Detection di uso malevolo Si conosce cosa quali sequenze di azioni possono essere intrusioni Detection in base a specifiche Sequenze di azioni non usuali possono essere intrusioni Si conoscono le situazioni derivanti da intrusioni I modelli possono essere statici o adattivi Modelli per la scoperta di anomalie Si analizzano insiemi di caratteristiche del sistema confrontando i valori con quelli attesi e segnalando quando le statistiche non sono paragonabili a quelle attese Metriche a soglia Momenti statistici Modelli di Markov Metriche a soglie Contare il numero di volte che un evento si presenta Ci si aspetta tra m e n occorrenze Se il numero cade al di fuori, c’è un’anomalia Esempio Windows: blocco dopo k tentativi di login falliti. Il range è (0, k–1). k o più tentativi destano sospetto Problematiche E’ difficile trovare l’intervallo corretto Talvolta si possono creare situazioni in cui l’intervallo diventa molto più grande Esempio utenti francesi che usano una tastiera americana Momenti statistici L’analizzatore calcola la deviazione standard (i primi due momenti) o altre misure di correlazione (momenti di ordine superiore) Se i valori misurati di un certo momento cadono al di fuori di un certo intervallo vi è un’anomalia Problematiche I profili possono evolvere nel tempo, si possono “pesare” opportunamente i dati o alterare le regole di detection Esempio: IDES Developed at SRI International to test Denning’s model Represent users, login session, other entities as ordered sequence of statistics <q0,j, …, qn,j> qi,j (statistic i for day j) is count or time interval Weighting favors recent behavior over past behavior Ak,j sum of counts making up metric of kth statistic on jth day qk,l+1 = Ak,l+1 – Ak,l + 2–rtqk,l where t is number of log entries/total time since start, r factor determined through experience Example: Haystack Let An be nth count or time interval statistic Defines bounds TL and TU such that 90% of values for Ais lie between TL and TU Haystack computes An+1 Then checks that TL ≤ An+1 ≤ TU If false, anomalous Thresholds updated Ai can change rapidly; as long as thresholds met, all is well Modelli di Markov L’ipotesi è che la storia passata influenzi la prossima transizione di stato Le anomalie sono riconosciute da sequenze di eventi, e non sulle occorrenze di singoli eventi Il sistema deve essere addestrato per riconoscere sequenze valide l’addestramento è svolto con utenti non anomali l’addestramento produce migliori risultati con una quantità maggiore di dati i dati dovrebbero coprire tutti le sequenze normali del sistema Esempio: TIM Time-based Inductive Learning Sequence of events is abcdedeabcabc TIM derives the following rules: R1: abc (1.0) R4: de (1.0) R3: ce (0.5) R6: ed (0.5) Seen: abd; triggers alert R2: cd (0.5) R5: ea (0.5) c always follows ab in rule set Seen: acf; no alert as multiple events can follow c May add rule R7: cf (0.33); adjust R2, R3 Sequenze di chiamate di sistema Forrest: definisce il normale andamento in termini di sequenze di chiamate di sistema (tracce) Negli esperimenti è in grado di distinguere sendmail e lpd da altri programmi Si addestra il sistema con un insieme di tracce e si cerca se la traccia corrente è anomala Problematiche ulteriori Modelli statistici spesso si usa la distribuzione gaussiana alternative sono clusterizzazione e tecniche non parametriche Selezione di feature CPU versus I/O selezione automatica Modelli per il misuso Si controlla se una sequenza di istruzioni da eseguire è già nota essere potenzialmente dannosa per la sicurezza del sistema La conoscenza è rappresentata mediante regole e il sistema controlla se la sequenza soddisfa una di queste regole Non si possono scoprire intrusioni non note precedentemente Esempi di IDS a regole IDIOT monitorizza i log cercando sequenze di eventi che corrispondono ad attacchi STAT analizza le transizioni di stato, concentrandosi sul modo come alcuni privilegi sono ottenuti NFR controlla il traffico di rete, analizzando e filtrando i pacchetti Modelli mediante specifiche Si determina se una sequenza di azioni viola una specifica di come un programma o un sistema dovrebbe funzionare Architettura di un IDS E’ essenzialmente un sistema di auditing sofisticato Agente è una sorta di logger; it gathers data for analysis Direttore è un analizzatore; analizza i dati ottenuti dagli agenti secondo regole interne Notificatore ottiene i risultati dal direttore e compie alcune azioni Può semplicemente notificare messaggi agli amministratori Può riconfigurare gli agenti Può attivare meccanismi di risposta Agente Ottiene le informazioni e le invia al direttore Può mettere le informazioni in altre forme Preprocessing dei record per estrarre parti rilevanti Può cancellare informazioni non necessarie Il direttore può richiedere all’agente ulteriori informazioni Si distinguono in agenti host e agenti network Direttore Colleziona le informazioni inviate dagli agenti Analizza le informazioni rimanenti per determinare se si è sotto attacco Elimina i record ridondanti o non necessari Usa le tecniche viste prima Gira su un sistema separato Non influenza le performance dei sistemi monitorati Notificatore Accetta le informazioni dal direttore Prende le decisioni appropriate Notificare messaggi agli amministratori Rispondere all’attacco Spesso usano delle GUI Combining Sources: DIDS I monitoraggi di host e di network non sono generalmente sufficienti da soli a scoprire alcuni tipi di attacchi Un’attaccante prova a fare telnet con vari login: i IDS network lo scoprono, ma non gli IDS host L’attaccante prova entrare senza la password: gli IDS host lo rilevano, ma non quelli di rete DIDS usa gli agenti sugli host da monitorare ed un monitor di rete Risposte alle intrusioni Prevenzione: l’attacco deve essere scoperto prima del completamento Una tecnica è il Jailing: far credere all’attaccante che l’intrusione è andata a buon fine ma confinare le sue azioni in un dominio in cui non può fare danni (o causarne pochi) far scaricare file corrotti o falsi imitare il sistema vero Risposta alle intrusioni Trattamento delle intrusioni preparazione identificazione contenimento (passivo/attivo) eradicazione recupero seguito (apprendimento) Sicurezza nei database La protezione dei dati di un database necessita di strumenti particolari, alcuni dei quali mutuati da quelli usati in altri settori Gli obiettivi sono comunque gli stessi Integrità Confidenzialità Disponibilità Requisiti di sicurezza Integrità fisica del DB: immunità ai guasti di sistema e di dispositivo Integrità logica del DB: preservazione della struttura del database Integrità degli elementi: accuratezza dei dati Auditability: tenere traccia delle operazioni Controllo degli accessi Autenticazione degli utenti Disponibilità Integrità del database E’ garantita in gran parte dal DBMS, oltre che dal S.O. Strumenti fondamentali sono log delle transazioni su memoria stabile copie di backup effettuate regolarmente Update a due fasi Meccanismi standard ripresa a caldo ripresa a freddo Integrità degli elementi Controllo della corrispondenza tra i tipi dei campi e i valori Controllo degli accessi Log dei cambiamenti Auditability Tenere traccia delle operazioni svolte sul DB ha un duplice scopo garantire l’integrità fisica del DB accesso incrementale ai dati Problemi nella granularità delle operazioni da tracciare Controllo degli accessi Normalmente i database relazionali usano sistemi DAC per il controllo degli accessi La primitiva GRANT permette di concedere diritti su tabelle agli utenti I diritti standard sono SELECT INSERT UPDATE DELETE REFERENCES Controllo degli accessi E’ possibile specificare la clausola WITH GRANT OPTION il diritto può essere propagato Il diritto può essere revocato con la primitiva REVOKE I diritti solitamente sono memorizzati (insieme agli altri metadati) nelle tabelle di sistema Controllo degli accessi Come nei SO, anche nei DB esiste il concetto di amministratore: l’utente DBA Ha il diritto di creare e cancellare utenti Ha il diritto di accesso a tutto il database Può concedere e revocare diritti al pari del possessore Controllo degli accessi Alcuni DBMS, tra cui PostgreSQL, consentono l’uso di RBAC E’ possibile creare dei ruoli ruolo utente ruolo gruppo I diritti si assegnano al ruolo Si può assegnare il diritto ad assumere un ruolo Uso delle viste E’ possibile creare delle viste per restringere l’accesso solo ad alcuni dati di una tabella E’ possibile quindi rendere accessibile a determinati utenti solo la vista e non la tabella da cui proviene Autenticazione degli utenti Gli utenti sono autenticati con meccanismi simili a quelli visti per i S.O. I DBMS di solito non si fidano dell’autenticazione del S.O., la effettuano autonomamente Le informazioni degli utenti sono memorizzate nelle tabelle di sistema Disponibilità La disponibilità deve essere garantita disciplinando opportunamente gli accessi concorrenti ed evitando che un processo “maligno” monopolizzi il DB Dati sensibili I database possono contenere dati sensibili, che non dovrebbe essere accessibili al pubblico Un problema sorge quando i dati sensibili sono una parte dei dati, ad esempio alcuni record di una tabella alcuni campi di una tabella Possono esistere vari gradi di sensibilità a seconda del motivo per cui il dato è dichiarato sensibile Accesso ai dati sensibili Livelli in base alla sicurezza e alla precisione Non disclosed Non può essere trovato attraverso altre query Potrebbe essere recuperato da altre query Restituito come risultato Problema dell’inferenza Tipi di disclosure Dato esatto: x vale 12 Limiti inferiori o superiori: x è compreso tra 10 e 15 Risposte negative: x non vale 11 Esistenza: Caio possiede un cellulare Valore probabile: x vale 10 con probabilità 0.25 Problema dell’inferenza E’ possibile ottenere dati sensibili attraverso l’uso di query opportune che non producono dati sensibili Tale problema è sentito nei database statistici fornire pubblicamente dati aggregati a scopi statistici evitare l’accesso ai singoli record Esempio Name Position Salary Age Matt Teacher 50K 33 Leonard Teacher 50K 50 Holly Principal 60K 37 Heidi Aide 20K 20 Celia Teacher 40K 45 Esempio SELECT SUM(SALARY) WHERE POSITION=‘TEACHER’ si può eseguire senza problemi poi SELECT SUM(SALARY) WHERE POSITION=‘TEACHER’ AND AGE > 40 non si può eseguire perchè (per differenza con la prima) troviamo lo stipendio di Matt Soluzione La soluzione è quella di tenere traccia di tutte le interrogazioni effettuate e di proibire le interrogazioni che conducono, tramite i risultati di quelle precedenti, ad accedere ai dati di uno (o pochi) record Esistono metodi per inferire dati da somme, medie, conteggi, mediane, ecc. Altre soluzioni Un altro approccio è quello di usare dati opportunamente modificati prima di calcolare le query esclusione di alcuni dati campionamento casuale perturbazione casuale dei dati Database multilivello Si supera la distinzione binaria tra dati sensibili e non sensibili Ogni singolo dato del DB può avere un grado di sicurezza Una tupla può essere vista come <v1, c1, v2, c2, ..., vn, cn, ct> I ci rappresentano il livello di sicurezza del dato vi e ct il livello di sicurezza dell’intera tupla Esempio Nome Età Rossi U 27 C 10K S A C Verdi U 30 C 20K S C TS Neri U 42 Bond TS 35 C TS 100K 85K TS A TS A C TS Gialli U C 120K TS A C 50 Stip. Cred. Si usa il modello di Bell-La Padula (U<C<S<TS) Esempio La tabella in lettura per un utente C è Nome Rossi U Età 27 C Stip. 10K Verdi U Neri U Gialli U Cred. A S 30 C 20K S TS 42 50 C C TS A TS A C C C Esempio La stessa tabella può essere vista in modi diversi a seconda del grado di sicurezza dell’utente Allo stesso modo si dovranno controllare gli accessi in scrittura (proprietà * del modello di Bell-La Padula): ad esempio un utente TS non può scrivere un dato con sicurezza S, C o U Realizzazione Esistono vari modi per realizzare un database multilivello Partizionamento: le tabelle sono memorizzate (e utilizzate) separatamente Cifratura di campi sensibili Marcatura con lock di integrità