Un approccio al role engineering basato sui costi di amministrazione

 Capitolo 1. Breve panoramica sul controllo degli accessi
1.1 Politiche, modelli e meccanismi di controllo
degli accessi
La storia del controllo d’accesso e` piuttosto recente e puo` essere fatta risali-
re attorno agli inizi degli anni ‘70. In quegli anni iniziavano a diffondersi i
primi grandi sistemi di condivisione dati per applicazioni governative, com-
merciali e militari, che avevano la necessita` di garantire la sicurezza delle
informazioni da esse gestite. In tutti gli studi sul controllo degli accessi
proposti nel tempo si riescono sempre individuare tre livelli di astrazione:
Politiche Rappresentano i requisiti di alto livello, che specificano come ge-
stire gli accessi e chi e in quale circostanza puo` accedere a quali infor-
mazioni. Solitamente una politica non e` specifica di un sistema, ma si
applica ad una unita` organizzativa o all’intera organizzazione. E` diffi-
cile che due organizzazioni diverse adottino la stessa politica (policy)
di controllo degli accessi, anche all’interno di uno stesso dominio di
business. Inoltre le politiche sono dinamiche per propria natura, in
quanto seguono le evoluzioni dei vari fattori di business, normative e
condizioni al contorno del business.
Meccanismi Le politiche di controllo degli accessi sono solitamente raf-
forzate da opportuni meccanismi, che molto spesso traducono le ri-
chieste di accesso degli utenti in termini di accesso “autorizzato” o
“negato”. Indipendentemente dal particolare meccanismo di control-
lo degli accessi adottato, e` sempre necessario mantenere da qualche
parte le informazioni di sicurezza circa gli utenti (es.: user-id, gruppi,
ruoli, ecc.) e le risorse (es.: etichette, tipi, liste di accesso, ecc.). Una
delle caratteristiche che deve offrire un buon meccanismo e` dunque
la possibilita` di revisionare e gestire tali informazioni. E` interessante
notare come molto spesso le varie applicazioni offrono gia` dei mec-
canismi di controllo degli accessi (es.: DBMS, sistemi operativi, ecc.)
per cui e` essenziale fornire un ulteriore meccanismo di controllo degli
accessi sopra ai suddetti meccanismi.
Modelli Piuttosto che tentare di analizzare e valutare singolarmente i vari
meccanismi di controllo degli accessi, solitamente si ricorre a modelli
che descrivono il loro comportamento e le loro proprieta`. Tali mo-
delli consentono un certo grado di liberta` nell’implementazione dei
meccanismi, fornendo pero` un framework concettuale che giustifichi
1.2. Confidenzialita`, Integrita` e Disponibilita` 
le politiche che essi supportano. In questo senso, la bonta` di un mo-
dello viene stabilita sulla base della possibilita` di supportare o meno
certe politiche di controllo degli accessi, oltre che sulla realizzabilita`
di meccanismi che aderiscano a tale modello.
1.2 Confidenzialita`, Integrita` e Disponibilita`
Il controllo degli accessi e` soltanto uno degli aspetti di una soluzione di
sicurezza IT, anche se e` probabilmente il piu` evidente agli utenti. Coeren-
temente con gli obiettivi canonici della gestione della sicurezza, anche po-
litiche, modelli e meccanismi di controllo degli accessi devono preservare
le seguenti caratteristiche delle informazioni:
Confidenzialita` Questo requisito si occupa di proteggere l’accesso alle in-
formazioni o alle risorse all’interno dei sistemi, in maniera tale che
persone, processi o risorse non autorizzate non possano accedere a
tali informazioni. Nel requisito di confidenzialita` (confidentiality) so-
no centrali i concetti di segretezza e di privacy. Si parla di attacco
alla confidenzialita` quando una entita` (persona, processo o risorsa)
accede in maniera non autorizzata a informazioni protette, nell’istan-
te in cui queste sono memorizzate, oppure durante l’elaborazione, o
durante una comunicazione. Il requisito si applica anche alla mera
esistenza o meno di informazioni, che a volte puo` essere piu` indi-
catrice delle informazioni stesse; in tal caso si parla di information
hiding, anch’esso fornito dai sistemi di controllo degli accessi.
Integrita` La proprieta` si riferisce alla credibilita` (trustworthiness) dei da-
ti o delle risorse (inclusi i programmi e processi per manipolarli) ed
e` spesso formulata in termini di prevenzione dagli accessi non auto-
rizzati. Si ha un attacco alla integrita` (integrity) quando una entita`
(persona, processo o risorsa), in maniera non autorizzata, accede al
sistema e ne altera le risorse, oppure inserisce oggetti nel sistema,
oppure essendo un utente autorizzato del sistema ne esegue una mo-
difica non autorizzata. Due aspetti chiave dell’integrita` sono il content
integrity (i dati vanno protetti da alterazioni non autorizzate che pos-
sono avvenire durante la memorizzazione, elaborazione o trasmissio-
ne) e il system integrity (un sistema deve eseguire le funzioni per le
quali e` preposto, esente da alterazioni non autorizzate). Identificazio-
ne (riconoscimento dell’utente), autenticazione (associazione di una
 Capitolo 1. Breve panoramica sul controllo degli accessi
identita` ad un soggetto) e autorizzazione (cosa e` possibile fare e cosa
no sulle risorse di sistema) rappresentano i principali meccanismi di
prevenzione dell’integrita`.
Disponibilita` Si riferisce alla abilita` di accedere alle informazioni o alle
risorse desiderate, da parte dei legittimi utilizzatori, ogni volta che
questo e` necessario. Si ha un attacco alla disponibilita` (availability)
quando i dati oppure un sistema (in parte o per intero) sono distrutti,
resi indisponibili oppure non usabili, anche temporaneamente.
1.3 Terminologia di base
Nel corso degli anni si e` sviluppata una terminologia abbastanza consoli-
data per descrivere gli elementi che compongono un modello di control-
lo d’accesso. La quasi totalita` dei modelli si basa sulle nozioni di uten-
ti, soggetti, oggetti, operazioni e permessi, oltre che sulle relazioni che
intercorrono tra esse. In particolare:
I Un utente (user) e` una persona fisica che accede al sistema. In mol-
te architetture un utente puo` effettuare login multipli, anche con
identificativi (user-id) differenti.
I Una sessione (session) e` una singola istanza di interazione tra un
utente ed il sistema.
I Un soggetto (subject) e` un processo che interagisce con il sistema per
conto di un utente, come se fosse quest’ultimo. Un utente puo` quindi
avere piu` soggetti in esecuzione, anche se ha effettuato un solo login.
In generale, ogni programma aperto dall’utente per il sistema e` un
soggetto differente.
I Un oggetto (object) e` una qualsiasi risorsa del sistema accessibile da
parte degli utenti. Ad esempio sono oggetti i files, le periferiche, i
database, ma lo possono essere anche i singoli record contenuti in
questi ultimi, subordinatamente alla grana che si vuole utilizzare e
alla specifica applicazione.
I Un’operazione (operation) e` un processo invocato da un soggetto.
1.4. I principi fondamentali 
I Un permesso1 (permission) e` l’autorizzazione ad attivare una certa
azione sul sistema. Un permesso non e` altro che il legame tra un og-
getto ed una operazione su di esso; una stessa operazione applicata a
due oggetti differenti rappresenta dunque due permessi distinti.
1.4 I principi fondamentali
Un modello di controllo d’accesso ben strutturato deve facilitare il compi-
to dell’amministratore di sistema, rispecchiando il piu` possibile la realta`
organizzativa da gestire. Tuttavia, a prescindere dalla particolare realta`,
esistono principi fondamentali di cui ogni modello dovrebbe tener conto:
Least privilege Il principio del “minimo privilegio” afferma che si devono
assegnare ad ogni utente solamente i permessi strettamente necessa-
ri per lo svolgimento dei suoi compiti all’interno dell’organizzazione.
Consiste nell’assegnare in maniera selettiva i permessi agli utenti, in
modo da evitare che un singolo individuo possa avere la possibilita`
di compiere azioni non necessarie per il proprio lavoro e al contempo
potenzialmente dannose per il sistema. La stretta aderenza al prin-
cipio del minimo privilegio vorrebbe anche che uno stesso individuo
avesse differenti livelli di privilegi in istanti diversi, a seconda del-
la compito che sta svolgendo. E` inoltre altrettanto importante che i
permessi assegnati ad un utente non persistano al di la` del tempo du-
rante il quale sono necessari. Ovviamente una gestione dinamica dei
privilegi aggiunge ulteriore complessita` al sistema e lavoro aggiuntivo
per l’amministratore.
Separation of duty Lo scopo della “separazione dei compiti” e` quello di
evitare che all’interno di un’organizzazione un’unica persona possa
recare danno a quest’ultima perseguendo i propri interessi personali.
Si vuole fare in modo che l’unica evenienza in cui cio` possa accadere
sia in corrispondenza di una collusione tra diversi individui. Il princi-
pio afferma che non si devono assegnare ad una stessa persona tutti i
permessi necessari per svolgere particolari compiti che potrebbero re-
care danno all’intera organizzazione. Per rendere meglio l’idea si puo`
1Spesso invece di parlare di permessi ci si riferisce in senso piu` ampio ai privilegi o
talvolta ai profili di accesso, riferendosi alle modalita` di accesso alle risorse offerte dalle
applicazioni. Poiche´ la letteratura sul controllo degli accessi il piu` delle volte si riferisce ai
permessi e non ai profili, d’ora in avanti si utilizzera` sempre il termine permesso.
 Capitolo 1. Breve panoramica sul controllo degli accessi
affermare che un particolare set di transazioni non deve poter essere
eseguito per intero da un solo individuo, ma deve essere suddiviso
su almeno due persone distinte. La separazione dei compiti permet-
te quindi di definire politiche di controllo d’accesso nelle quali sono
contemplate nozioni di conflitti d’interesse. E` possibile individuare
due tipi di separazione dei compiti, quella statica e quella dinamica.
Nel primo caso e` semplicemente necessario assegnare a priori ad ogni
individuo un insieme di permessi, in modo da rispettare i vincoli im-
posti dal principio di separation of duty. Il secondo tipo e` invece piu`
complesso, in quanto la verifica di queste regole non e` fatta a priori,
bens`ı durante tutto l’arco di funzionamento del sistema. Il vantaggio
e` ovviamente quello di introdurre una maggiore flessibilita`, che in
certi casi applicativi puo` essere auspicabile se non indispensabile.
Questi due concetti verranno ripresi e trattati con maggiore dettaglio nei
prossimi capitoli, quando si parlera` in maniera approfondita del modello
RBAC.
2Il modello RBAC
N el 1992 Ferraiolo e Kuhn [Fer92], due studiosi del NIST (NationalInstitute of Standards and Technology), presentarono uno studio incui si prospettava un utilizzo differente dei concetti di utenti e ope-
razioni. In particolare venne introdotto un nuovo elemento, il “ruolo”, co-
me intermediario tra utenti e operazioni. Si tratto` di fatto del primo mo-
dello RBAC (Role-Based Access Control) proposto nella storia del controllo
d’accesso. Secondo questo modello, l’accesso ai sistemi e` regolato sulla ba-
se del ruolo che un utente ha all’interno dell’organizzazione, ovvero dalle
mansioni previste. I ruoli, con differenti privilegi e responsabilita`, sono
sempre esistiti nelle organizzazioni. Un ruolo dunque esiste a prescinde-
re dagli utenti a cui sara` assegnato. I paragrafi che seguono formalizzano
questi concetti.
2.1 Utenti, ruoli ed operazioni
Prima di entrare nel dettaglio del funzionamento del modello di controllo
d’accesso basato su ruoli, e` opportuno dare una definizione dei termini
chiave che verranno utilizzati da qui in avanti, in accordo con [Fer92]:
I Un utente e` un soggetto (fisico) facente parte di un’organizzazione.
I Un ruolo e` un insieme di operazioni che un utente (o un insieme di
utenti) puo` eseguire nel contesto dell’organizzazione di cui fa parte.
I Una transazione e` una procedura, alla quale viene associato un certo
“set di dati”, che viene definito con il termine oggetto. Una transazio-
ne ha senso solo se e` riferita ad un particolare oggetto1.
1Nello standard ANSI/INCITS 359-2004 (vedi il capitolo 3 a pagina 19) il concetto di

 Capitolo 2. Il modello RBAC
Le operazioni sono allocate ai diversi ruoli dall’amministratore di siste-
ma, che si preoccupa anche di assegnare gli utenti ai diversi ruoli presenti
all’interno dell’organizzazione. Allo stesso modo l’amministratore puo` re-
vocare in qualsiasi momento l’appartenenza (membership) di un utente ad
un ruolo e puo` aggiornare il set di transazioni associate a quest’ultimo.
Il modello RBAC prevede delle relazioni molti-a-molti tra utenti, ruoli,
transazioni ed oggetti del sistema. In particolare:
I ad un utente possono essere assegnati piu` ruoli;
I un ruolo puo` essere ricoperto da diversi utenti;
I ad ogni ruolo possono essere associate diverse transazioni;
I una transazione puo` essere eseguita da diversi ruoli;
I una transazione puo` operare su piu` oggetti;
I un oggetto puo` essere manipolato per mezzo di diverse transazioni.
La figura 2.1 nella pagina successiva schematizza entita` e relazioni del mo-
dello. Notare che tutte le transazioni che un utente puo` eseguire possono
essere ottenute solo attraverso l’assegnazione ad un ruolo. Questo risulta
conveniente in una tipica organizzazione, dove i ruoli sono relativamen-
te stabili, mentre gli utenti sono molto numerosi e possono cambiare nel
tempo. Inoltre, un simile modello consente di rispondere facilmente alla
domanda “quali sono gli oggetti a cui un utente puo` accedere?”; infatti in
mancanza di RBAC sarebbe necessario effettuare una scansione di tutti gli
oggetti su ogni sistema, analizzando le relative liste di accesso, con una
evidente complessita` che in alcuni casi puo` richiedere anche molte ore di
elaborazione.
2.2 Gerarchie di ruoli
Spesso all’interno di un’organizzazione ci sono delle operazioni che pos-
sono essere svolte da tutti gli utenti. In questo caso sarebbe necessario
replicare le corrispondenti transazioni in tutti i ruoli definiti nel sistema.
Ovviamente cio` non e` auspicabile, in quanto complicherebbe di molto la
gestione da parte dell’amministratore, mentre lo scopo di RBAC e` quello di
semplificarla al massimo. Per venire incontro a questa esigenza, nel model-
lo RBAC si e` deciso di rendere possibile un’organizzazione gerarchica dei
ruoli, che permette a ruoli piu` specializzati di ereditare da altri ruoli tutte
transazione viene rimpiazzato dal piu` generico concetto di permesso, ricollegandosi quindi
con la terminologia introdotta nel precedente capitolo.
2.3. Considerazioni sul modello 
Server 1
Ruolo A
Utente X
Server 2Ruolo B
Utente Y Server 3
Ruolo C
Server 4
Appartenenza Transazioni
Figura 2.1 Relazioni tra utenti, ruoli, transazioni ed oggetti di sistema nel mo-
dello RBAC. Ad un utente non vengono mai abilitate direttamente le
transazioni su risorse di sistema, ma solo un loro “raggruppamento”
in ruoli.
le loro transazioni. Cos`ı facendo si semplifica notevolmente la gestione di
quelle attivita` che sono accomunabili a tutti gli utenti dell’organizzazione.
Quello che accade quando un ruolo discende da un altro e` mostrato nella
figura 2.2 nella pagina seguente. Un esempio di gerarchia, preso dal do-
cumento originale di Ferraiolo e Kuhn [Fer92], e` mostrato nella figura 2.3
a pagina 13, in cui vengono mostrate le dipendenze tra le diverse figure
professionali presenti all’interno di un ospedale.
2.3 Considerazioni sul modello
Il modello RBAC e` universalmente riconosciuto come uno dei pochi modelli
“neutrali” rispetto alle politiche di controllo degli accessi, in quanto consen-
te una grande espressivita`. Per evidenziare questa caratteristica peculiare
di RBAC, seguono ora alcune osservazioni sul modello che lo contraddi-
 Capitolo 2. Il modello RBAC
Ruolo A
(padre)
Set di transazioni
del padre
Ruolo B
(figlio)
Set di transazioni
specifiche del figlio +
Set di transazioni
del figlio
Figura 2.2 Schematizzazione del concetto di gerarchia di ruoli. Un ruolo figlio
aggiunge al ruolo padre un set di transazioni specifiche.
stinguono rispetto agli altri modelli di controllo degli accessi proposti in
letteratura.
2.3.1 Il principio del minimo privilegio
Come visto nel paragrafo 1.4 a pagina 7 il principio del minimo privilegio e`
essenziale per garantire l’integrita` delle informazioni. Esso afferma che ad
ogni utente non bisogna dare maggiori privilegi di quelli strettamente ne-
cessari ad eseguire i compiti che deve svolgere. Per applicare correttamente
questo principio e` necessario innanzitutto indagare su quali sono effettiva-
mente i compiti che devono essere svolti da un utente, e in seconda istanza
determinare qual e` il minimo insieme di transazioni da assegnare all’utente
affinche´ possa svolgere questi compiti. Un sistema RBAC favorisce il rispet-
to del principio del minimo privilegio in quanto e` possibile assegnare un
utente ad un ruolo, al quale sono associate le sole transazioni indispensabili
allo svolgimento del suo lavoro all’interno dell’organizzazione.
2.3.2 Separazione dei compiti
Il modello RBAC puo` essere usato per rinforzare la politica di separazione
dei compiti [Nya99, Sim97, Kuh97]. Il set di transazioni da gestire oppor-
tunamente per rispettare i vincoli introdotti da questa politica di controllo
d’accesso variano a seconda della singola realta` organizzativa. La separa-
zione dei compiti, come si e` accennato nel paragrafo 1.4, puo` essere statica
o dinamica. Il primo caso e` quello piu` semplice, e puo` essere gestito a
2.3. Considerazioni sul modello 
Object 1
Object 2
Healer
User 1
User 2
User 3
Object 3
Object 4
Intern
User 4
User 5
User 6
Object 5
Object 6
Doctor
User 7
User 8
User 9
trans a
trans b
memb
er o
f
member of
member of
trans c
trans d
memb
er o
f
member of
member of
trans e
trans f
memb
er o
f
member of
member of
Figura 2.3 Esempio di gerarchia tra ruoli
priori assegnando ad ogni individuo un insieme di ruoli e ad ogni ruolo un
set di transazioni possibili tali da rispettare le regole di “separation of du-
ty”. Il secondo caso e` invece piu` complesso, in quanto la verifica di queste
regole puo` essere fatta solamente durante il funzionamento del sistema,
introducendo pero` una maggiore flessibilita`. In realta` il documento origi-
nale di Ferraiolo e Kuhn non spiega nel dettaglio come un sistema RBAC
possa essere configurato per supportare la separazione dinamica dei com-
piti, ma lascia comunque intendere che cio` puo` avvenire assegnando ad
uno stesso utente anche ruoli che generano conflitti di interesse e verifi-
 Capitolo 2. Il modello RBAC
cando poi run-time che questo utente non ricopra entrambi i ruoli con-
temporaneamente. Tale aspetto viene invece formalizzato nello standard
ANSI/INCITS 359-2004 [ANS04] descritto nel prossimo capitolo.
2.3.3 Differenza tra ruoli e gruppi
Leggendo le definizioni fornite nel paragrafo precedente, puo` non essere
del tutto chiaro quale sia la differenza tra “ruoli” e “gruppi di utenti”, do-
ve questi ultimi non sono altro che l’unita` di controllo piu` frequentemente
adottata in molti dei sistemi di controllo degli accessi comunemente utiliz-
zati. Ad una prima analisi, i ruoli possono essere considerati equivalenti ai
gruppi; un ruolo puo` rappresentare un insieme di utenti e un utente puo` es-
sere membro di differenti ruoli. Tuttavia esiste una differenza importante:
nella maggior parte delle implementazioni esistenti, i gruppi sono sempli-
cemente trattati come una collezione di utenti e non come un insieme di
transazioni. Un ruolo invece e` entrambe le cose, ovvero racchiude in se´
anche le transazioni abilitate agli utenti, alle quali questi ultimi vengono
assegnati in modo indiretto.
La principale differenza fra queste due entita` e quindi sia di tipo se-
mantico che implementativo. Le caratteristiche dei gruppi cambiano da
implementazione a implementazione. Ad esempio, nei sistemi Unix ad un
file puo` essere assegnato uno ed un solo gruppo, mentre altri sistemi di
controllo degli accessi consentono l’associazione di piu` gruppi contempo-
raneamente. Nel modello RBAC, invece, un ruolo e` definito con un certo
insieme di proprieta`, che sono ben definite a prescindere dalla particolare
implementazione, che non sempre si ritrovano nei gruppi, come il lega-
me molti-a-molti fra utenti e permessi. Inoltre RBAC e` un modello, non
un meccanismo, per cui la conformita` dell’implementazione al modello
garantisce le sue proprieta` principali.
Un’altra grande differenza tra ruoli e gruppi risiede nel grado di facilita`
con la quale e` possibile determinare l’elenco degli utenti e delle transa-
zioni appartenenti all’insieme (ruolo o gruppo) in questione. Infatti, per
poter parlare di ruolo, deve essere facile determinare il relativo insieme di
utenti ed il relativo insieme di transazioni. Il controllo dell’appartenenza
di un utente o di una transazione ad un ruolo deve essere un’operazione
centralizzata, limitatamente ad un numero ristretto di utenti rispetto alle
dimensioni globali del sistema che si deve gestire. Si pensi al solito ad un si-
stema Unix. Per determinare l’appartenenza dei diversi utenti ai vari gruppi
e` sufficiente guardare i file /etc/passwd ed /etc/group. L’informazione
2.4. Vantaggi del modello RBAC nelle grandi organizzazioni 
circa i permessi di accesso assegnati ai diversi gruppi e` invece dispersa su
tutto il filesystem. Inoltre l’assegnamento dei permessi di accesso ai gruppi
e` altamente decentralizzato.
2.4 Vantaggi del modello RBAC nelle grandi or-
ganizzazioni
Come descritto in [Fer07, §1.4], il modello RBAC ha il potenziale per poter
offrire diversi benefici all’interno di una organizzazione, alcuni dei quali
sono analizzati nelle pagine che seguono.
2.4.1 Vantaggi economici
Sicuramente uno dei principali vantaggi legati a RBAC e` rappresentato da
un aumento della produttivita` nelle attivita` di amministrazione e gestione
delle autorizzazioni. Con queste funzioni intendiamo l’assegnazione dei
permessi di accesso a risorse informatiche a nuovi utenti, la revisione e
rimozione selettiva dei permessi non piu` necessari e/o potenzialmente pe-
ricolosi a seguito di un cambio di funzione aziendale dell’utente, oppure
la completa e istantanea rimozione di tutti i permessi ad un utente che
abbandona l’azienda. Da questo punto di vista, anche la produttivita` del-
l’utente finale aumenta, in quanto diminuisce il gap temporale fra gli eventi
amministrativi, durante il quale solitamente l’utente non puo` accedere ai
sistemi.
Risulta quindi evidente che c’e` un legame diretto fra i costi di ammi-
nistrazione e il numero di “associazioni” utente-transazione che devono
essere gestite al fine di attuare una politica di controllo degli accessi: mag-
giore sara` il numero di associazioni da gestire e maggiori saranno i costi e
le possibilita` di errore da parte di un amministratore di sistema. Un sem-
plice modello economico e` proposto in [Fer99]. Il modello si basa sul fatto
che le funzioni aziendali sono solitamente ricoperte da piu` utenti e molte
funzioni richiedono piu` transazioni al fine di poter svolgere correttamente
le mansioni previste per quella particolare posizione. E` possibile descrivere
queste associazioni in termini di coppie ordinate fra transazioni e utenti. In
particolare, dati i seguenti insiemi:
I Ui come insieme di tutti gli utenti che ricoprono una data posizione i
all’interno dell’organizzazione;