Clark-Wilson model
David Clark e David Wilson
1987
Prof.
Francesca Lanci
Stefano Bistarelli
Modelli sulla sicurezza
FOCUS: integrità e confidenzialità
Confidenzialità: protezione dei dati da utenti non
autorizzati, concerne anche la possibilità che utenti
autorizzati passino le informazioni a utenti non
autorizzati
Ambiente militare
Integrità: richiede che i dati siano protetti da
invalide modifiche, cancellazioni o inserzioni.
I vincoli d’integrità sono regole che definiscono lo
stato corretto di un db e che ne mantengono la
correttezza anche durante le operazioni (integrità
delle transazioni)
Ambiente commerciale
Clark-Wilson
Minimo di sicurezza richiesto
da un IS
Integrità: i vincoli d’integrità esistono per proteggere
IS da maligni o accidentali modifiche dei dati.Le
regole possono essere definite su stati statici del db
o su transazioni (es. prima di poter effettuare un
modifica)
Identificazione,autenticazione: prima di accedere
a un sistema ogni utente deve essere identificato e
autenticato per mantenerne traccia e per dargli
l’accesso
Autorizzazioni(controllo accessi): una serie di
regole per definire chi può eseguire quali tipi di
operazioni su quali dati
Clark-Wilson Integrity Model
Clark-Wilson identifica 2 meccanismi principali per
rafforzare l’integrità e il controllo degli accessi:
1.
Le transazioni ben formate (WFT) che preservano
l’integrità dei dati e prevengono che utenti li manipolino
arbitrariamente
Una transazione ben formata è costituita da una serie
di operazioni che muovono il sistema da uno stato
consistente a un altro stato consistente.
Moderni sistemi informativi mantengono log che registrano le
operazioni e gli utenti che le eseguono in modo che possano essere
scoperte eventuali modifiche.
Il modello richiede che le esecuzioni delle WFT siano
memorizzate in modo da poterle riprendere per revisioni
seguenti o per ricreare lo stato originale (log).
Transazioni ben formate
Definire le
caratteristiche di una
transazione ben
formata è un lavoro
manuale eseguito da
un security officer che
è l’unico che può
specificare il set di
procedure che possono
modificare certi CDI.
2.
Un’operazione completa se eseguita da una sola
persona è più attaccabile da frodi.
Il principio della “separazione dei compiti” richiede di
dividere l’operazione in sottoparti che devono
essere eseguite da persone differenti.
In questo caso per completare un’operazione
illegale tutte le persone coinvolte dovrebbero
cospirare insieme per attuare la frode.
Il principio della separazione dei compiti
Il certificatore di una transazione e colui che la
esegue devono essere persone differenti.
Le transazioni ben formate sono associate con gli
utenti secondo tale principio, gli utenti non possono,
in nessun caso, alterare le associate liste di accessi.
Caratteristiche essenziali
Identificazione e autenticazione degli utenti è essenziale
Assicurare che specifici dati possano essere manipolati
da uno specifico set di procedure che a loro volta
possono essere eseguite solo da utenti autorizzati
Mantenere log con programmi, nomi degli utenti e dati
Meccanismi di protezione non possono essere cambiati
(staticità)
Il security officer è responsabile degli assegnamenti
Sono importanti le regole di sicurezza, non possiamo
affidarci a un firewall perchè non ci protegge da
modifiche non valide compiute da utenti autorizzati;
dobbiamo incorporare la sicurezza nel IS
Il modello formale
Set di dati
CDI: è un set di “constrained data
item”, gli elementi del modello che
devono essere protetti, sono dati
soggetti al controllo d’integrità.
Esempio banca: CDI = saldo dei conti
UDI: è un set di “unconstrained data
item”, sono dati non soggetti ai vincoli
d’integrità.
I dati non possono appartenere ad
entrambe le classi
Due tipi di procedure:
1.Integrity verification procedures
IVP: set di “integrity verification procedures”
Funzioni che verificano se un determinato
set di dati “CDI” soddisfa determinati vincoli di
integrita’
I vincoli d’integrità sono implementati come
vincoli nel linguaggio SQL
• Es. Per la banca un vincolo d’integrità sarà:
(depositi di oggi)+(saldo di chiusura di ieri)
-(prelievi di oggi)= (saldo di chiusura di oggi)
2.Transform procedures
TP: set di “transform procedures”
Ogni procedura di trasformazione è una
funzione da un set di CDI a un set di CDI.
Nota: se l’originale set di CDI soddisfa un
determinato IVP allora anche il set trasformato di
CDI lo soddisferà
TP sono, quindi, “procedure ben formate”
Es. banca:
• Depositi
• Prelievi
• Trasferimenti di denaro, etc
Transazioni e Utenti
IVP hanno verificato se il sistema in passato fosse in
uno stato consistente, TP assicurano che lo sarà in
futuro
Una tipica transazione nel db è composta da TP, di
cui alcune trasformano UDI in CDI e altri aggiornano
CDI.
Le transazioni devono anche implementare IVP
UserID: sono i nomi del set di utenti abilitati ad
utilizzare il sistema
C’è bisogno di specificare il set delle procedure e gli
utenti associati e il sistema deve assicurare che
questi utenti devono eseguire solo quelle procedure;
quindi c’è bisogno nel sistema di un servizio di
autenticazione degli utenti
Nel caso debbano
entrare nel
sistema degli UDI
questi devono
essere processati
solo da WFT per
risultare CDI
Certification rules (1):
assicurano che i dati nel sistema siano validi
C1: tutte le IVP devono assicurare che tutti i CDI siano in
uno stato valido al momento in cui l’IVP è eseguito
C2: tutte le TP devono essere certificate per essere valide.
Per ogni TP e ogni set di CDI che esso può manipolare,
il “security officer” deve specificare una relazione che sarà
del tipo:
(TPi(CDIa,CDIb,CDIc,…))
La lista di CDI definisce un set di argomenti per i quali il TP
è stato certificato.
Un TP può manipolare in modo errato un CDI se non è
certificato a lavorare con questo.
Enforcement rules (1):
prevengono modifiche di CDI in modo non conforme a
IVP
E1: il sistema deve mantenere una lista di relazioni specificate
nella regola C2 e deve assicurare che la manipolazione di CDI
possa avvenire solo da certi TP, come specificato nelle relazioni
E2: il sistema deve mantenere anche una lista di relazioni del
tipo:
(userID,TPi,(CDIa,CDIb,CDIc,..))
Il sistema deve assicurare che solo le esecuzioni descritte in una
delle relazioni possano essere eseguite.
Questa tripla definisce una relazione “permessa”.
Il TP deve accedere a questi CDI dietro richiesta dell’utente
associato
Enforcement rules
E3: il sistema deve autenticare l’identità di ogni
utente che vuole eseguire una TP
Nota: gli utenti non autenticati possono
manipolare gli UDI, perché l’autorizzazione non è
richiesta prima dell’uso del sistema ma prima della
manipolazione dei CDI
E4: solo gli agenti che hanno il permesso di
certificare le entità possono modificare la lista di
entità associate ad altre entità, specificatamente
quelle associate con TP.
Regola E3
Enforcement rules
Certification properties (2)
C3: la relazione “permessa” deve supportare il principio della separazione
dei compiti.
La relazione “permessa” deve essere certificata.
C4: Tutti i TP devono aggiungere sufficienti informazioni al CDI per poter
ricostruire l’operazione.
Questo CDI è il log
Il logging è essenziale all’auditing (processo di analisi del sistema per
determinare quali azioni debbano essere eseguite e chi le deve eseguire)
il logging è alla base dell’auditing, ma mentre il logging è interno al sistema,
l’auditing è esterno e l’auditing è essenziale all’integrità.
Nessun TP può sovrascrivere un log.
C5: TP che prendono un UDI come valore in input devono eseguire solo
valide trasformazioni, dovrà trasformarlo in un CDI o respingerlo.
Certification rules
Applicazione con DBMS
DBMS supportano alcuni dei meccanismi di CW per le
autorizzazioni degli accessi e il controllo
Si può avere accesso ai dati solo attraverso il DBMS
DBMS provvede
Controllo autorizzazioni
Gestione transazioni e dati
Logging
DBMS si appoggia anche sui dati che fornisce il OS
Una transazione tipica dei DB comprende una serie
di TP e deve implementare IVP
Cos’è il DBMS
(4th dimension,DB2,mysql)
Software che gestisce e organizza
un database(organizzazione,
memorizzazione e reperimento dei
dati), controlla anche sicurezza e
integrità del db.
Uno strato che si frappone fra
l’utente e i dati veri e propri. Non
permette agli utenti di entrare in
contatto con i dati così come sono
memorizzati, la loro
rappresentazione fisica, ma ne
vedono solo la rappresentazione
logica(schema del db)
L'amministratore del database puo'
decidere di memorizzare i dati in
maniera differente o anche di
cambiare il DBMS senza che le
applicazioni, e quindi gli utenti, ne
risentano. La cosa importante e' che
non venga cambiata la
rappresentazione logica di quei dati,
che e' la sola cosa che i loro
utilizzatori conoscono.
Caratteristiche
Accetta le richieste dall’applicazione e
richiede al OS di passargli le
informazioni appropriate
(es. per autenticazione utenti)
Il sistema di sicurezza impedisce agli
utenti non autorizzati di visualizzare o
aggiornare il db
E’ progettato per sistemi multi-utente
Perché usare un DBMS
Consentire l’accesso ai dati attraverso
uno schema concettuale anziché
fisico
Controllare l’accesso ai dati
Assicurare la sicurezza e l’integrità
dea dati
Permette la condivisione e
integrazione dei dati fra applicazioni
differenti
Validazione UDI
L’oggetto fuori dal box DBMS è un UDI
C5: i programmi possono invocare
le procedure di “integrity enforcement”
come precondizioni
UDI
CDI
respinti
….continua
Durante la procedura viene stabilita la connessione
al server DBMS e l’utente che la sta eseguendo
riceve l’autorizzazione a livello DBMS
Utente autorizzato
Transazione del database
controlli su integrità dei dati
DBMS integrity enforcement
C4: Logging transazione
Implementazione
enforcement rules su CDI
Avviene il controllo utenti.
E3: autenticazioni del OS
Accesso ai programmi
Accesso alle
transazioni del database
In accordo con le
regole di accesso
E4:
Queste possono essere modificate
solo da specifici utenti:
security officer
DBMS
E3
E4
C5
C4
Autorizzazioni in SQL
GRANT list of privileges
ON objects
TO user
I privilegi relativi ai comandi base di SQL3 sono:
Select
Delete
Update
Insert
…
Esempio
transazione T
BEGIN T
Select * from X
Delete * from X
COMMIT T
Assumiamo che sulla tabella X l’utente U abbia il
privilegio SELECT e DELETE,
mentre l’utente V abbia solo il privilegio SELECT
se T è eseguita da U non ci saranno problemi
perchè nessun vincolo di integrità è violato mentre
se la esegue V la transazione non può avvenire
Altro esempio:
modello degli esami universitari
I professori assegnano i voti in sede di
esame
I voti saranno controllati e inseriti in un
database da un amministratore
Un consiglio controllerà i voti e sarà l’unico a
poterli modificare se riscontrerà delle
irregolarità
Solo alla fine gli studenti potranno avere
l’accesso ai loro dati
Il modello
Ogni link tra un attore e un’azione
rappresenta una tripla d’accesso della forma
(attore,azione,dati)
Il link tra amministratore e inputdati
rappresenta la
tripla(amministratore,inputdati,voto)
Solo le transazioni che rappresentano una di
queste triple potrà avere luogo (E2)
L’implementazione deve controllare i vincoli
d’integrità sui voti prima che diventino CDI
nel database (UDI-CDI)
Separazione delle funzioni
Per essere sicuri che il progetto rispetti il principio
della “separazione dei compiti” richiesta dalla regola
C3, facciamo una lista delle triple di accesso che
riguardano modifiche di CDI
Le triple sono:
(professore,votoesame,voto)
(amministratore,inputdati,voto)
(consiglio,controllo,voto)
La separazione dei compiti è avvenuta visto che
sono coinvolti 3 utenti prima che lo studente abbia
l’accesso ai suoi voti
“Separazione dei compiti”
votoesame
voto
voto
inputdati
controllo
voto
IVP del modello
IVP esistono per tutte le transazioni:
Il professore nel compilare il verbale deve
conformarsi ai criteri stabiliti
Nell’immettere i dati nel database, questi sono
confrontati con i domini dei dati e altri vincoli
Il consiglio controlla anche altri aspetti relativi agli
esami (es. irregolarità, appelli, tempi,
propedeuticità)
Limite principale del modello
Clark-Wilson: staticità
Relazioni autorizzazioni statiche
Statica separazione dei compiti
Autorizzazione sono centralizzate in un
amministratore della sicurezza
Bibliografia
Secure database development and the ClarkWilson security model
• Xiaocheng Ge, Fiona Polack, Règine Laleau
A comparison of commercial and military
computer security policies
• David Clark and David Wilson
Consideration of the chinese wall and the ClarkWilson security policy in the internet
environment
• Prof. Gustaff Neumann
DBMS
• Enciclopedia Wikipedia
