Diapositiva 1 - Dipartimento di Matematica e Informatica

Sicurezza Informatica
Prof. Stefano Bistarelli
[email protected]
http://www.sci.unich.it/~bista/
Chapter 7: Hybrid Policies




Overview
Chinese Wall Model
ORCON
RBAC
Prof. Stefano Bistarelli - Sicurezza
Informatica
2
Overview

Chinese Wall Model


ORCON


Focuses on conflict of interest
Combines mandatory, discretionary access controls
RBAC

Base controls on job function
Prof. Stefano Bistarelli - Sicurezza
Informatica
3
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
4
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
5
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
6
Definitions

Objects: items of information related to a

Company dataset (CD): contains objects
company
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
7
Classificazione
dei
dati
Insieme di tutti gli oggetti
CoI 2
CoI 1
Bank A
Info
Info
Bank B
Info
Info
Info
CoI 3
Gas A
Oil A
Info
Info
Prof. Stefano Bistarelli - Sicurezza
Informatica
Oil B
Info
Info
8
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
9
Condizione di semplice
sicurezza delle CW
Un soggetto s può leggere un oggetto o se
e solo se:

1.
2.


Esiste un oggetto o a cui s ha avuto accesso e
CD(o ) = CD(o), oppure
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
10
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 A
R
R
Gas A
Consultant
R
X
R
Bank B
R
Oil B
Prof. Stefano Bistarelli - Sicurezza
Informatica
11
Regola
= John
diInsieme
lettura
di tutti gli oggetti
CoI 2
COI
CoI 11
Bank A
Info
Info
Info
Bank B
Info
Gas A
COI
CoI 33
Oil A
Prof. StefanoInfo
Bistarelli - Sicurezza Info
Info
Informatica
Oil B
Info
Info
12
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
13
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
14
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
15
In altri termini

Un soggetto può scrivere un oggetto se


Bank B
Bank A
lo può anche leggere E
non può leggere dati di altre compagnie
W
X
R
Consultant
A
Consultant
B
R
X
Oil B
W
Prof. Stefano Bistarelli - Sicurezza
Informatica
16
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
17
Regola
di
scrittura
Insieme
di tutti gli oggetti
= John
COI
CoI 11
Bank A
Info Info
ABC
Info
CoI 2
Gas A
Info
COI
CoI 33
Oil A
ABC Info
Prof. Stefano Bistarelli - Sicurezza
Informatica
18
Regola diInsieme
scrittura
di tutti gli oggetti
= Jane
COI 2
COI 1
Bank B
ABC Info
Gas A
COI 3
Oil A
Info
Info
Prof. StefanoInfo
Bistarelli -ABC
Sicurezza
Informatica
19
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
20
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
21
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
22
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
23
orcon
Prof. Stefano Bistarelli - Sicurezza
Informatica
24
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
25
Requisiti
Il soggetto s  S marca l’oggetto o  O
come ORCON per conto dell’organizzazione
X.
X permette che o sia diffuso ai soggetti che
lavorano per conto dell’organizzazione Y con
le seguenti restrizioni:
1.
2.


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
26
DAC non va bene

Il possessore (owner) può concedere
qualsiasi diritto

La proprietà 2 non sarebbe soddisfatta
Prof. Stefano Bistarelli - Sicurezza
Informatica
27
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
28
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
29
rbac
Prof. Stefano Bistarelli - Sicurezza
Informatica
30
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
31
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
32
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
33
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
34
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ò “policyProf. Stefano Bistarelli - Sicurezza
neutral”
Informatica
35
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
36
Modello NIST

Tre livelli con capacità funzionali
crescenti



Core RBAC – anche chiamato Flat RBAC
RBAC gerarchico
RBAC vincolato
Prof. Stefano Bistarelli - Sicurezza
Informatica
37
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
38
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
39
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
40
Role-Based AC
Individui
Ruoli
Risorse
ruolo 1
Server 1
ruolo 2
Server 2
ruolo 3
Server 3
Gli utenti cambiano frequentemente, i ruoli no
Prof. Stefano Bistarelli - Sicurezza
Informatica
41
Definitions

Role r: collection of job functions


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


trans(r): set of authorized transactions for r
authr(s)
canexec(s, t) iff subject s can execute
transaction t at current time
Prof. Stefano Bistarelli - Sicurezza
Informatica
42
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
43
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
44
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
45
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
46
Esempio di RH
Director
Project Lead 1
Produczione
Engineer 1
Project Lead 2
Qualità
Engineer 1
Produczione
Engineer 2
Engineer 1
Qualità
Engineer 2
Engineer 2
Engineering Dept
Prof. Stefano Bistarelli - Sicurezza
Informatica
47
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
48
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
49
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
50
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
51
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
52
Key Points

Hybrid policies deal with both
confidentiality and integrity


ORCON model neither MAC nor DAC


Different combinations of these
Actually, a combination
RBAC model controls access based on
functionality
Prof. Stefano Bistarelli - Sicurezza
Informatica
53
Discussion:
Prof. Stefano Bistarelli - Sicurezza
Informatica
54