Swappa : Uni / TAPD 18 Marzo 2009

Torna alla pagina di Tecniche Avanzate per la Protezione dei Dati

:: Tecniche Avanzate per la Protezione dei Dati ::

Lezione 03 del 18 Marzo 2009

Politiche Multilivello

Quando si tratta di sistemi operativi non ci sono grossi problemi perché come livello più fine di granulosità ho solitamente il file.

In Database Multilivello classifico:

• relazioni
• attributi
• tuple
• elementi (celle)

Basi di dati relazionali: Abbiamo schemi composti da attributi, istanze ed un insieme di relazioni. Funziona con una chiave primaria. Ad uno schema corrispondono più istanze, una per ogni vista consentita ad una categoria.

Regole:

• no read up: non posso leggere informazioni appartenenti a classe di livello più alto rispetto a quello di competenza.
• no write down: ognuno scrive al proprio livello.

Il fatto che in un sistema convivino lettori e scrittori è fonte di problemi non banali.

Nonostante ci siano diverse opinioni riguardo la progettazione di sistemi multilivello dei punti fermi sono:

• gli attributi delle chiavi devono essere uniformemente classificati. Potrei non poter accedere al contenuto di una delle chiavi della tupla e quindi potrebbe violare le classiche regole delle basi di dati.
• la classe di appartenenza della chiave deve essere dominata da quelle degli attributi.

Poli-istanziazione:

Presenza multipla di elementi con stesso nome ma classificazione diversa. Nel caso di database:

• stessa chiave ma con classificazione diversa.
• stessa chiave ma diversità di classificazione di qualche attributo.

Poli-instanzazione invisibile Un utente vuole scrivere una tupla con chiave che già esiste ma che lui non vede perché non gli è concesso. Possibilità:

• notificare l'errore (perdo segretezza).
• sostituire la tupla (perdo integrità).
• non dare avvisi e prendere la tupla.

Poli-istanzazione visibile: Un utente di alto livello vuole scrivere una tupla con stessa chiave di una tupla già esistente e di più basso livello. Alternative:

• notificare l'errore (denial of service, è un utente di alto livello).
• sostituire la tupla (gli utenti di livello inferiore vedono la tupla in questione sparire)
• prendere la tupla e fare poli-istanzazione.

Una soluzione al problema: Prendere come chiavi anche le classificazioni (chiave e attributi).

In passato al posto del campo NULL si usava ritornare RESTRICTED come contenuto della cella ritornata. Chiarisce che non è un campo che effettivamente manca ma nei casi in cui la classificazione proviene dal valore del dato stesso si rilascia informazione.

Alla poli-instanzazione è stata data la colpa del mancato successo dei database multilivello.

Cover Story: Valori non corretti ritornati agli utenti di livello inferiore per proteggere il reale valore (che non devono sapere).

Poli-istanzazione per fare cover-story va bene. Quando si va oltre alla situazione del S.O. mi scontro con molti problemi. Ci sono situazioni che un sistema multilivello non riesce a gestire. (es di regola non gestibile: posso sapere la direzione della singola nave ma non quella dell'intera flotta)

Implementazione dei database multilivello

[vedere slide pag. 20]

• Trusted subject: ho database multilivello, S.O. trusted e DBMS trusted.
• Trusted computing base: database distinti per livello (ho problema di dati duplicati da gestire), S.O. trusted, DBMS non trusted per i diversi livelli.

---

Torna alla pagina di Tecniche Avanzate per la Protezione dei Dati