Prof. Stefano Bistarelli - Sicurezza Informatica
2
Chapter 7: Hybrid Policies
Overview Chinese Wall Model ORCON RBAC
Prof. Stefano Bistarelli - Sicurezza Informatica
3
Overview Chinese Wall Model
Focuses on conflict of interest ORCON
Combines mandatory, discretionary access controls
RBAC Base controls on job function
Prof. Stefano Bistarelli - Sicurezza Informatica
4
Chinese Wall Model
Problem: Tony advises American Bank about
investments He is asked to advise Toyland Bank
about investments Conflict of interest to accept,
because his advice for either bank would affect his advice to the other bank
Prof. Stefano Bistarelli - Sicurezza Informatica
5
Politica della Chinese Wall Introdotto da Brewer and Nash nel 1989
Il motivo per questo lavoro è stato quello di evitare che informazioni sensibili concernenti una compagnia siano passate a compagnie rivali per mezzo di consulenti finanziari
Si stabiliscono dinamicamente i diritti di accesso di utente in base a quello a cui l’utente ha già avuto accesso
Prof. Stefano Bistarelli - Sicurezza Informatica
6
Organization Organize entities into “conflict of
interest” classes Control subject accesses to each
class Control writing to all classes to
ensure information is not passed along in violation of rules
Allow sanitized data to be viewed by everyone
Prof. Stefano Bistarelli - Sicurezza Informatica
7
Definitions Objects: items of information related to
a company Company dataset (CD): contains objects
related to a single company Written CD(O)
Conflict of interest class (COI): contains datasets of companies in competition Written COI(O) Assume: each object belongs to exactly one
COI class
Prof. Stefano Bistarelli - Sicurezza Informatica
8
Classificazione dei dati
InfoInfoInfo InfoInfo Info InfoInfoInfo
Bank ABank A Bank BBank B Gas AGas A Oil AOil A Oil BOil B
CoI 1CoI 1 CoI 2CoI 2 CoI 3CoI 3
Insieme di tutti gli oggettiInsieme di tutti gli oggetti
Prof. Stefano Bistarelli - Sicurezza Informatica
9
Evoluzione dei diritti Se un consulente legge un oggetto
appartenente ad un CD in una data COI, non può più leggere oggetti di altri CD in quella COI E’ possibile che le informazioni apprese
prima possano consentirgli di prendere decisioni “migliori” dopo (ovviamente in modo sleale)
Indichiamo con PR(S) l’insieme degli oggetti che S ha già letto
Prof. Stefano Bistarelli - Sicurezza Informatica
10
Condizione di semplice sicurezza delle CW Un soggetto s può leggere un oggetto o se
e solo se:1. Esiste un oggetto o a cui s ha avuto accesso
e CD(o ) = CD(o), oppure
2. Per ogni o O, o PR(s) COI(o) ≠ COI(o) Ignoriamo per ora i dati “sanitized” Inizialmente, PR(s) = , quindi qualunque
cosa può essere letta all’inizio
Prof. Stefano Bistarelli - Sicurezza Informatica
11
In altri termini Un soggetto può leggere un oggetto se:
l’oggetto è in un dataset di cui il soggetto ha già letto qualcosa oppure
l’oggetto appartiene a una COI di cui il soggetto non ha letto ancora niente
Bank ABank AC
on
sulta
nt
Co
nsu
ltan
tBank BBank B
Gas AGas A Oil BOil B
RR
RR
RR
RR
XX RR
Prof. Stefano Bistarelli - Sicurezza Informatica
12
Regola di lettura
InfoInfoInfo Info Info
Bank ABank A Gas AGas A Oil AOil A
InfoInfo
Bank BBank B
Info Info
Oil BOil B
COI 1COI 1 CoI 2CoI 2 COI 3COI 3
Insieme di tutti gli oggettiInsieme di tutti gli oggetti= John= John
Info
Oil AOil A
CoI 3CoI 3
Info
Bank ABank A
CoI 1CoI 1
Prof. Stefano Bistarelli - Sicurezza Informatica
13
Confronto con Bell-LaPadula La politica Chinese Wall è una
combinazione di libera scelta e MAC Inizialmente un soggetto è libero di
accedere a ciò che vuole Una volta fatta la scelta, per quell’utente
è creata una Muraglia Cinese attorno al dataset a cui l’oggetto appartiene
Si noti che la Chinese Wall può essere combinata con le politiche DAC
Prof. Stefano Bistarelli - Sicurezza Informatica
14
Scrittura Anthony e Susan lavorano per la stessa
azienda di consulenza Anthony può leggere i CD di Bank A e di Gas A Susan può leggere i CD di Bank B e di Gas A Se Anthony potesse scrivere sul CD di Gas A,
Susan potrebbe leggerlo Perciò, indirettamente, potrebbe acquisire
informazioni su Bank B, un chiaro conflitto di interesse La regola per la lettura non è in grado di
prevenire “fughe di notizie”
Prof. Stefano Bistarelli - Sicurezza Informatica
15
Proprietà * delle CW Un soggetto s può scrivere un oggetto o
se e solo se entrambe le condizioni valgono La condizione di sicurezza semplice consente
a s di leggere o Per ogni oggetto non “sanitized” o, se s può
leggere o, allora CD(o) = CD(o) In pratica s può scrivere un oggetto se
tutti gli oggetti (non “sanitized”) che può leggere sono nello stesso dataset
Prof. Stefano Bistarelli - Sicurezza Informatica
16
In altri termini
Un soggetto può scrivere un oggetto se
lo può anche leggere E non può leggere dati di altre compagnie
ConsultantConsultantAA
ConsultantConsultantBB
WW
WW
RR
RR
XXOil BOil B
Bank BBank B
Bank ABank A XX
Prof. Stefano Bistarelli - Sicurezza Informatica
17
Conclusioni e critiche
Perciò secondo questa regola: Il flusso di informazioni è
confinato all’interno della compagnia Però un utente che ha letto da più
dataset non può scrivere nessuno oggetto
Inoltre, una volta che ha scritto in un dataset, può scrivere solo lì
Prof. Stefano Bistarelli - Sicurezza Informatica
18
Regola di scrittura
InfoInfoInfo Info Info
Bank ABank A Gas AGas A Oil AOil A
COI 1COI 1 CoI 2CoI 2 COI 3COI 3
Insieme di tutti gli oggettiInsieme di tutti gli oggetti= John= John
Info
Oil AOil A
CoI 3CoI 3
InfoInfo
Bank ABank A
CoI 1CoI 1
ABCABCABCABC
Prof. Stefano Bistarelli - Sicurezza Informatica
19
Regola di scrittura
Info Info
Gas AGas A Oil AOil A
InfoInfo
Bank BBank B
COI 1COI 1 COI 2COI 2 COI 3COI 3
Insieme di tutti gli oggettiInsieme di tutti gli oggetti= Jane= Jane
Info
Oil AOil A
COI 3COI 3
Info
Bank BBank B
COI 1COI 1
ABCABCABCABC
Prof. Stefano Bistarelli - Sicurezza Informatica
20
Informazioni “Sanitized” Alcune informazioni pubbliche possono
appartenere ad un CD Essendo pubbliche, non generano conflitti
di interesse Tipicamente, tutti i dati sensibili sono
rimossi prima che tale informazione sia resa pubblica (l’informazione è “sanitized”)
Una terza opzione per la Condizione di sicurezza semplice è quindi:
3. o è un oggetto “sanitized”
Prof. Stefano Bistarelli - Sicurezza Informatica
21
Confronto con Bell-LaPadula Sono fondamentalmente differenti
CW non ha etichette di sicurezza, B-LP sì CW si basa sugli accessi passati, B-LP no
Bell-LaPadula può simulare CW istante per istante Ogni coppia di (COI, CD) è una categoria Due livelli di sicurezza, S (sanitized) and U (non
sanitized) S dom U
I livelli di sicurezza dei soggetti comprendono al massimo una sola categoria per ogni classe COI
Ma B-LP non è in grado di modellare i cambiamenti nel tempo
Prof. Stefano Bistarelli - Sicurezza Informatica
22
Compare to Bell-LaPadula Bell-LaPadula cannot track changes
over time Susan becomes ill, Anna needs to take over
C-W history lets Anna know if she can No way for Bell-LaPadula to capture this
Access constraints change over time Initially, subjects in C-W can read any object Bell-LaPadula constrains set of objects that
a subject can access
Prof. Stefano Bistarelli - Sicurezza Informatica
23
Confronto con Clark-Wilson Il modello di Clark-Wilson si occupa
dell’integrità Se i “soggetti” e i “processi” sono la stessa
cosa, una singola persona potrebbe usare più processi e violare la condizione di semplice sicurezza in CW
Ma rispetterebbe il modello di Clark-Wilson Se il “soggetto” è una specifica persona che
comprende anche tutti i processi eseguiti, allora CW è consistente con Clark-Wilson Model
Prof. Stefano Bistarelli - Sicurezza Informatica
24
orcon
Prof. Stefano Bistarelli - Sicurezza Informatica
25
ORCON Problema: un’organizzazione vuole
controllare la diffusione dei propri documenti
Esempio: Il Ministro delle politiche agricole scrive documento da distribuire per i propri impiegati e concede il permesso un’ulteriore ridistribuzione. Ciò si indica con il nome di “originator controlled” (in questo caso, l’ “originator” è una persona).
Prof. Stefano Bistarelli - Sicurezza Informatica
26
Requisiti
1. Il soggetto s S marca l’oggetto o O come ORCON per conto dell’organizzazione X.
2. X permette che o sia diffuso ai soggetti che lavorano per conto dell’organizzazione Y con le seguenti restrizioni:
o non può essere rilasciato a soggetti che lavorano per conto di altre organizzazioni senza il permesso di X e
Ogni copia di o deve avere le stesse restrizioni.
Prof. Stefano Bistarelli - Sicurezza Informatica
27
DAC non va bene
Il possessore (owner) può concedere qualsiasi diritto La proprietà 2 non sarebbe
soddisfatta
Prof. Stefano Bistarelli - Sicurezza Informatica
28
MAC non va bene Primo problema: esplosione del numero delle categorie
Ogni categoria C contiene o, X, Y. Se un soggetto y Y vuole leggere o ne fa una copia o. Nota che o ha categoria C. Se y vuole dare a z Z una copia, z deve essere in Y ma per definizione non vi è. Se x vuole concedere a w W di vedere il documento, deve creare una nuova categoria C contenente o, X, W.
Secondo problema: astrazione In MAC la classificazione e le categorie sono controllate
centralmente e l’accesso è controllato da una politica centralizzata
ORCON è controllato localmente
Prof. Stefano Bistarelli - Sicurezza Informatica
29
Combinare DAC e MAC Il possessore dell’oggetto non ne può
cambiare i controlli di accesso. Quando l’oggetto è copiato, le restrizioni di
accesso sono copiate dalla sorgente e legate alla copia.
Ciò è MAC (l’owner non può controllarlo) Il creatore del documento (originator) può
alterare le restrizioni di accesso in base al soggetto e all’oggetto.
Ciò è DAC (l’originator/owner può controllarlo)
Prof. Stefano Bistarelli - Sicurezza Informatica
30
rbac
Prof. Stefano Bistarelli - Sicurezza Informatica
31
RBAC: Motivazioni Un problema importante
nell’organizzazione di grandi sistemi è la complessità dell’amministrazione della sicurezza
Quando il numero dei soggetti e degli oggetti è alto, il numero di autorizzazioni può diventare molto grande
Inoltre, se la popolazione di utenti è molto dinamica, il numero di concessioni e di revoche di permessi diventa eccessivamente elevato
Prof. Stefano Bistarelli - Sicurezza Informatica
32
RBAC: Motivazioni Gli utenti finali spesso non “possiedono” le
informazioni a cui hanno accesso. Le aziende o gli enti sono i reali possessori degli oggetti
Il controllo di accesso è quindi basato sulle mansioni delle persone e non sul semplice possesso
RBAC è stato quindi proposto come alternativa al DAC e al MAC per semplificare la gestione degli accessi e per supportare direttamente il controllo basato sulle mansioni (ruoli)
Prof. Stefano Bistarelli - Sicurezza Informatica
33
RBAC I diritti di accesso dipendono dal ruolo,
non dall’identità Esempio:
Anna, segreteria del dipartimento, ha accesso ai dati finanziari.
Anna cambia impiego e non ha più diritti di accesso.
Barbara prende il suo posto e adesso è lei che può accedere a quei dati
E’ il ruolo che stabilisce i diritti e non l’identità del singolo individuo.
Prof. Stefano Bistarelli - Sicurezza Informatica
34
RBAC e ruoli
I ruoli rappresentano le mansioni all’interno di un’organizzazione
Le autorizzazioni sono concesse ai ruoli anzichè ai singoli utenti
Gli utenti sono perciò autorizzati semplicemente ad assumere ruoli appropriati, acquisendo le autorizzazioni assegnate a quei ruoli
Prof. Stefano Bistarelli - Sicurezza Informatica
35
Vantaggi del RBAC Poichè i ruoli rappresentano le funzioni
dell’organizzazione, un modello RBAC può direttamente supportare le politiche di sicurezza proprie dell’organizzazione
Concedere e revocare autorizzazioni alle categorie di utenti è grandemente semplificato
I modelli RBAC sono perciò “policy-neutral”
Prof. Stefano Bistarelli - Sicurezza Informatica
36
RBAC I produttori di DBMS hanno visto l’importanza e i
vantaggi di RBAC, e oggi molti DBMS commerciali supportano in vario modo RBAC
Esiste un certo consenso su un modello standard di RBAC
Il modello NIST [Sandhu,Ferraiolo,Kuhn 00] è stato il primo passo verso la definizione di uno standard
Una recente definizione è data dall’ ANSI: Role based access control. ANSI INCITS 359-2004, February 2004
Prof. Stefano Bistarelli - Sicurezza Informatica
37
Modello NIST
Tre livelli con capacità funzionali crescenti Core RBAC – anche chiamato Flat
RBAC RBAC gerarchico RBAC vincolato
Prof. Stefano Bistarelli - Sicurezza Informatica
38
RBAC- Concetti di base
Utente – un essere umano, una macchina, un processo, o un agente intelligente autonomo, ecc.
Ruolo – una funzione nel contesto di un’organizzazione con una semantica associata secondo l’autorità e la responsibilità del ruolo
Prof. Stefano Bistarelli - Sicurezza Informatica
39
RBAC- Concetti di base Permesso – Modo di accesso che può
essere esercitato sugli oggetti nel sistema.
Sia gli oggetti e i modi di accesso sono dipendenti dal dominio.
Per esempio, nel caso dei database, tra gli oggetti si trovano tabelle, colonne e righe e tra i modi di accesso le operazioni di insert, delete e update.
Prof. Stefano Bistarelli - Sicurezza Informatica
40
RBAC- Concetti di base Sessione – E’ una particolare istanza di una
connessione di un utente al sistema e definisce un sottoinsieme di ruoli attivati.
Ad ogni istante, possono essere attive più sessioni differenti per ciascun utente.
Quando un utente entra nel sistema, stablisce una sessione e durante tale sessione può attivare un sottoinsieme dei ruoli che è autorizzato ad assumere.
L’utente ottiene i permessi associati al ruolo che ha attivato nella sessione.
Prof. Stefano Bistarelli - Sicurezza Informatica
41
Role-Based ACIndividui Ruoli Risorse
ruolo 1
ruolo 2
ruolo 3
Server 1
Server 3
Server 2
Gli utenti cambiano frequentemente, i ruoli no
Prof. Stefano Bistarelli - Sicurezza Informatica
42
Definitions Role r: collection of job functions
trans(r): set of authorized transactions for r Active role of subject s: role s is
currently in actr(s)
Authorized roles of a subject s: set of roles s is authorized to assume authr(s)
canexec(s, t) iff subject s can execute transaction t at current time
Prof. Stefano Bistarelli - Sicurezza Informatica
43
Axioms Let S be the set of subjects and T the set of
transactions. Rule of role assignment:
(s S)(t T) [canexec(s, t) actr(s) ≠ ].
If s can execute a transaction, it has a role This ties transactions to roles
Rule of role authorization:(s S) [actr(s) authr(s)].
Subject must be authorized to assume an active role (otherwise, any subject could assume any role)
Prof. Stefano Bistarelli - Sicurezza Informatica
44
Axiom
Rule of transaction authorization:(s S)(t T)
[canexec(s, t) t trans(actr(s))]. If a subject s can execute a
transaction, then the transaction is an authorized one for the role s has assumed
Prof. Stefano Bistarelli - Sicurezza Informatica
45
RBAC gerarchico - Motivazioni
Le gerarchia tra ruoli sono un modo naturale per strutturare i ruoli in modo da riflettere le linee di autorità e responsibilità di un’organizzazione
Prof. Stefano Bistarelli - Sicurezza Informatica
46
Containment of Roles
Trainer can do all transactions that trainee can do (and then some). This means role r contains role r (r > r). So:(s S)[ r authr(s) r > r r
authr(s) ]
Prof. Stefano Bistarelli - Sicurezza Informatica
47
Esempio di RH
ProduczioneEngineer 1
Engineer 1
Qualità Engineer 1
Engineering Dept
ProduczioneEngineer 2
Engineer 2
Qualità Engineer 2
Project Lead 1
Director
Project Lead 2
Prof. Stefano Bistarelli - Sicurezza Informatica
48
Semantica del RBAC gerarchico Ereditarietà di utente (UI): Tutti gli utenti
autorizzati ad un ruolo r sono anche autorizzati ad un ruolo r’, ove r > r’
Eredità di permessi (PI): Un ruolo r è autorizzato a tutti i permessi per i quali ogni ruolo r’, tale che r > r’, è autorizzato
Eredità di attivazione (AI): Attivando un ruolo r automaticamente si attivano tutti i ruoli r’, tali che r > r’. Da usare solo con sessioni MRA
Prof. Stefano Bistarelli - Sicurezza Informatica
49
RBAC vincolato Il RBAC vincolato è un modello RBAC
con la capacità di supportare le politiche di Separazione dei compiti (Separation of Duty)
Evita conflitti di interesse e collisioni tra mansioni
Due categorie principali: SoD statici SoD dinamici
Prof. Stefano Bistarelli - Sicurezza Informatica
50
Separation of Duty Let r be a role, and let s be a subject
such that r auth(s). Then the predicate meauth(r) (for mutually exclusive authorizations) is the set of roles that s cannot assume because of the separation of duty requirement.
Separation of duty:(r1, r2 R) [ r2 meauth(r1)
[ (s S) [ r1 authr(s) r2 authr(s) ] ] ]
Prof. Stefano Bistarelli - Sicurezza Informatica
51
RBAC –SoD statici
SoD statici restringono l’insieme dei ruoli and in particolare la possobilità ad entrare nella relazione RA
Nessun utente può assumere più di t ruoli in un insieme di m ruoli
Evita che una persona sia autorizzata a usare troppi ruoli
Prof. Stefano Bistarelli - Sicurezza Informatica
52
RBAC –SoD Dinamici Questi vincoli limitano il numero di ruoli che
un utente può attivare in una singola sessione
Esempi di vincoli: Nessun utente può attivare più di t ruoli nel
corso di una sessione. se l’utente ha usato il ruolo r1 in una sessione,
non può usare il ruolo r2 nella stessa sessione E’ necessario mantenere una storia dei ruoli
attivati da ciascun utente
Prof. Stefano Bistarelli - Sicurezza Informatica
53
Key Points
Hybrid policies deal with both confidentiality and integrity Different combinations of these
ORCON model neither MAC nor DAC Actually, a combination
RBAC model controls access based on functionality
Prof. Stefano Bistarelli - Sicurezza Informatica
54
Discussion: