Anteprima
Vedrai una selezione di 4 pagine su 14
Sicurezza delle basi di dati Pag. 1 Sicurezza delle basi di dati Pag. 2
Anteprima di 4 pagg. su 14.
Scarica il documento per vederlo tutto.
Sicurezza delle basi di dati Pag. 6
Anteprima di 4 pagg. su 14.
Scarica il documento per vederlo tutto.
Sicurezza delle basi di dati Pag. 11
1 su 14
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Capitolo 8

Sicurezza delle basi di dati

Questo capitolo tratta le tecniche usate per proteggere le basi di dati da persone che non sono autorizzate ad accedere a tutta la base o ad alcune sue parti. Verranno affrontate le principali problematiche di sicurezza e le minacce alle basi di dati. Verranno descritti i meccanismi, spesso definiti come controllo dell'accesso discrezionale, utilizzati per accordare e revocare i privilegi nei sistemi di basi di dati relazionali e in SQL. Verranno inoltre descritti i meccanismi per l'attuazione della sicurezza multilivello, un aspetto più recente della sicurezza delle basi di dati noto come controllo di accesso mandatorio. Inoltre, verrà spiegato il controllo dell'accesso basato sui ruoli di recente sviluppo. I lettori interessati solamente ai meccanismi base relativi alla sicurezza possono limitarsi alla consultazione dei paragrafi 8.1 e 8.2.

8.1 Introduzione alle problematiche di sicurezza delle basi di dati

8.1.1 Tipi di sicurezza

La sicurezza delle basi di dati è un'area molto ampia che tratta diverse problematiche tra cui:

  • questioni etiche e legali relative ai diritti di accesso ai dati, nonché le questioni di quali possono essere ritenuti dati riservati e quali no, e chi può e non possono accedere legalmente. Nonostante queste siano regolate da numerose leggi che regolano la riservatezza;
  • questioni riguardanti le politiche a livello istituzionale e non che determinano la determinazione di quali informazioni non devono essere diffuse pubblicamente (per esempio, gli indici di reddito e l'età delle cliniche dei pazienti);

questioni relative al sistema, come i livelli di sistema a cui dovrebbero essere applicate le varie funzioni di sicurezza (per esempio, se una funzione di sicurezza debba essere gestita a livello hardware, del sistema operativo o del DBMS);

L'esigenza di alcune organizzazioni di identificare molteplici livelli di sicurezza con cui classificare i dati e gli utenti (per esempio, top secret, secret, confidenziale e unclassified). È necessario fare osservare la politica di sicurezza dell'organizzazione nella definizione dei permessi di accesso alle varie categorie di dati.

Minacce per le basi di dati.

Perdita di integrità: l'integrità della base di dati si riferisce al fatto che le informazioni devono essere protette da modifiche improprie. Le modifiche dei dati includono la creazione, l'inserimento, l'aggiornamento, il cambiamento dello stato dei dati e la cancellazione. L'integrità si perde se alla base di dati vengono apportate modifiche non autorizzate intenzionali oppure accidentali. Se non si pone rimedio alla perdita di integrità del sistema o dei dati, il proseguimento dell'utilizzo del sistema contaminato o dei dati corrotti può portare a conseguenze quali imprecisione, frodi e decisioni errate.

Perdita di disponibilità: la disponibilità si riferisce al fatto che gli oggetti della base di dati devono essere resi disponibili agli utenti o ai programmi che sono legittimamente autorizzati ad accedervi.

Perdita di riservatezza: la riservatezza delle basi di dati si riferisce alla protezione dei dati da rivelazione (disclosure) non autorizzata. Le conseguenze della rivelazione non autorizzata di informazioni riservate possono variare dalla violazione della legislazione vigente a minacce alla sicurezza nazionale. Una rivelazione non autorizzata, il nostro esempio implica una perdita portata di fiducia, imbarazzo o perdita di vantaggio competitivo.

m meccanismi di sicurezza discrezionali: sono utilizzati per concedere privilegi agli utenti, compresa la capacità di accedere a specifici file di dati o a campi in una particolare modalità, quali: lettura, inserimento, cancellazione o aggiornamento (v. Paragrafo 8.2);

meccanismi di sicurezza mandatori: sono usati per realizzare la sicurezza multilivello mediante la classificazione dei dati e degli utenti secondo varie classi (o livelli) e implementando l'opportuna politica di sicurezza dell'organizzazione. Per esempio, una tipica politica di sicurezza consiste nel permettere agli utenti con un certo livello di classificazione di vedere solamente i dati classificati a quello stesso livello di sicurezza oppure ad un livello inferiore. Un'estensione a ciò è la sicurezza basata su ruoli, che implementa le politiche e i privilegi basandosi sul concetto di ruolo (v. Paragrafo 8.3).

Un secondo problema relativo alla sicurezza comune a tutti i sistemi di elaborazione consiste nell'evitare che persone non autorizzate possano accedere al sistema stesso, o per ottenere informazioni oppure per apportare cambiamenti dolosi all'interno della base di dati. Il meccanismo di sicurezza di un DBMS deve comprendere funzionalità per limitare gli accessi al sistema di basi di dati nel suo complesso. Questa funzione è chiamata controllo degli accessi e viene gestita mediante la creazione di account utente e delle relative password in modo che i DBMS possano controllare il processo di connessione (login) degli utenti (v. Sottoparagrafo 8.1.3).

Un terzo problema consiste nel controllare l'accesso alle basi di dati statistiche utilizzate per fornire informazioni sui dati in base a vari criteri. Per esempio, una base di dati sulla popolazione può fornire statistiche base sui gruppi per età, fasce di età, dimensioni delle famiglie, livelli di istruzione, etc. Gli utenti (per esempio, utenti commerciali o agenzie di marketing) possono avere accesso a questa base di dati, e sono in grado di preparare informazioni statistiche su dati non necessariamente sensibili per singoli individui, quali la riservatezza può essere garantita. A volte è possibile però estrarre altre informazioni individuali integrando le risposte statistiche a una propria interrogazione statistica su più gruppi. Anche altre basi di dati che contengono dati sensibili, possono essere generate illusioni che dati noti o statistiche, v. Paragrafo 8.4.

Per poter gestire la sicurezza delle basi di dati attendibilità delle risorse richieste per esso, deve essere assolutamente che non soltanto chi mangia fuori, ma che esso stesso possa essere invocato sicura;- persone disinteressate ai supporti. Gli attacchi che pretendo e il diritto; digitalizzazione al server ed ai suoi dispositivi esecutivi tali da impegnareun altro modo i rigidi controlli di applicazioni (v. meccanica particolari, lungamente due programmi dalle varie clienti. Esso è, esaminazione della sicurezza compreso.

Considerando la natura della struttura di database non autorizzato, ci sono due direttamente una la crittografia con cui la decodifica in assenza di un chiave risulta molto difficile sono state

Successivamente, A1 può concedere il privilegio di SELECT sulla vista di A3 nel modo seguente:

GRANT SELECT ON ANTICIPAMENTO TO A3 WITH GRANT OPTION;

Infine, supponiamo che A1 desideri che A4 possa aggiornare solamente l’attributo STIPENDIO di IMPIEGATO. A1 potrebbe eseguire il seguente comando:

GRANT UPDATE ON IMPIEGATO (STIPENDIO) TO A4;

I privilegi di UPDATE o INSERT possono specificare particolari attributi di una relazione su cui eseguire aggiornamenti o inserimenti. Gli altri privilegi (SELECT, DELETE) non definiscono attributi, poiché la specificità necessaria è facilmente ottenibile mettendo le righe in opportune viste contenenti unicamente gli attributi desiderati e concedendo i privilegi corrispondenti su di esse. Tuttavia, poiché l’aggiornamento di viste non è sempre possibile (si veda il Capitolo 9, nel 1o vol.), i privilegi di UPDATE e INSERT può essere associata l’opzione di specifica dei particolari attributi di una relazione base che possono essere aggiornati.

8.2.6 Specifica di limiti sulla propagazione di privilegi

Sono state sviluppate delle tecniche per limitare la propagazione dei privilegi, sebbene nella maggior parte del DBMS non siano state ancora implementate e non facciano ancora parte di SQL. Limitare la propagazione orizzontale a un numero intero j significa che un account che possiede la GRANT OPTION può concedere il privilegio in questione a j o più account. La propagazione verticale è più complicata; essa limita la possibilità della concessione del privilegio. Concedere il privilegio con propagazione verticale significa che un account può concedere il privilegio senza GRANT OPTION. Se un account con GRANT OPTION concede il privilegio con la propagazione verticale impostata a un numero intero j > 0, significa che b può concedere la GRANT OPTION su tale privilegio solo a sua volta concederli ad altri account imponendo stringenti restrizioni (propagazione inferiore di A. Può ad esempio accadere che limitata la sequenza di GRANT OPTION che a tale account sia impostata dall’all’altro in base a una singola concessione singola concessione di tale D.

Esistono tecniche miste, che consentono la propagazione orizzontale e verticale (che non possono essere implementati in SQL o in sistemi relazionali) con un esempio sulla. Dopo che il concedere il privilegio di SELECT ad A2 sulla relazione IMPIEGATO con propagazione orizzontale per limitare la propagazione verticale solo a 2. A2 può concedere il privilegio di SELECT ad al massimo due account, fissando il livello di propagazione verticale a 1 ai 2 account. In tale, A2 non può concederli il privilegio se non con propagazione verticale pari a 0 (senza GRANT OPTION); questo perché Abc deve concederle a sua volta account a citato la possibilità ad altri account. Come esempio comune, le tecniche di propagazione orizzontale e verticale sono progettate per limitare la propagazione dei privilegi.

8.3 Controllo dell’accesso mandatorio e controllo dell’accesso basato su ruoli per la sicurezza multilivello2

Il controllo dell’accesso discrezionale basato sulla concessione e revoca dei privilegi su relazioni è stato tradizionalmente il principale meccanismo di sicurezza dei sistemi di basi di dati relazionali. Si tratta di un metodo di tipo “tutto-o-niente”: un utente possiede o non possiede un certo privilegio. In molti applicazioni è necessaria un’ulteriore politica di sicurezza che classifichi i dati e gli utenti in base a classi di sicurezza. Questo approccio, noto come controllo dell’accesso mandatorio, sarebbe tipicamente contubernalon con i meccanismi di controllo di accesso discrezionale descritti nel Paragrafo 8.2. È importante notare che attualmente la maggior parte dei DBMS commerciali fornisce solo meccanismi per il controllo di accesso discrezionale. Tuttavia, in ambito governativo, militare e dei servizi segreti, così come in varie applicazioni industriali, esiste, però, la necessità di sicurezza multilivello.

Le classi di sicurezza tipiche sono top secret (TS), secret (S), confidential (C) e unclassified (U), dove TS è il livello massimo mentre U è quello minimo. Esistono altri schemi di classificazione più complessi in cui le classi sono organizzate in una gerarchia. Per semplicità, per illustrare la nostra discussione utilizziamo un modello lineare di classificazione di sicurezza, con TS ≥ S ≥ C ≥ U. Il modello comunemente utilizzato ebbe i dati di sicurezza a livello, noto come modello Bell-LaPadula, classifica oggeti (utenze, documenti, programmi) e compiti oggetto (relazione). Un esempio di organizzazione in una, alcuni classi di sicurezza TS, S, C oppure U. Denoteremo la classificazione (clearance) dei soggetti con class [...]2 Si ringrazia Fariborz Farahmand per il contributo relativo a questo paragrafo e ai seguenti.

Dettagli
Publisher
A.A. 2012-2013
14 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher valeria0186 di informazioni apprese con la frequenza delle lezioni di Basi di Dati II e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli studi di Napoli Federico II o del prof Picariello Antonio.