Modello di Controllo dell’Accesso

basato sui ruoli

(RBAC)
 POLITICHE RBAC
 Sistemi di tipo Role Based Access Control (RBAC)
assegnano i privilegi non agli utenti, ma alla funzione che
questi possono svolgere nel contesto di una certa
organizzazione

 L’utente acquista quindi privilegi assumendo uno o più ruoli

POLITICHE RBAC
 RBAC
 RBAC consente di supportare facilmente i ben conosciuti
principi di sicurezza:
 minimo privilegio (Least Privilege )
 separazione dei compiti (Separation of duties): l’utilizzo di
ruoli mutuamente esclusivi potrebbe essere necessario in
certe situazioni critiche (evitare che il “controllato” sia anche il
“controllore”)
Inoltre RBAC permette di avere:
 astrazione dei dati (Data abstraction): invece dei tipici
permessi “read”, “write”, “execute” utilizzati nei sistemi
operativi, possono essere stabiliti permessi astratti come per
esempio “crediti” e “debiti”
 RUOLO
 In RBAC un ruolo è visto come un costrutto semantico
attorno al quale vengono formulate le politiche di controllo
d’accesso
 Il concetto di ruolo ha diversi significati:
 rappresenta la competenza nel compiere una specifica attività
(per esempio “farmacista” o “fisico”)
 incorpora sia l’autorità che la responsabilità (per esempio
“responsabile di progetto”)
 RBAC
 Un sistema RBAC correttamente amministrato fornisce una
grande flessibilità agli amministratori di sistema con il
minimo sforzo:
 i ruoli nell’organizzazione sono praticamente fissi, o variano
molto raramente
 stabiliti inizialmente i permessi per ogni ruolo...
 tutto quello che deve fare l’amministratore è gestire
l’assegnazione degli utenti ai ruoli

 Questo si traduce in un grande vantaggio rispetto alle

politiche DAC e MAC
 LO STANDARD
 RBAC è stato standardizzato come ANSI/INCITS 359-2004
 In questo documento vengono proposti quattro modelli
RBAC in modo incrementale
 CORE RBAC
 In questo primo modello vengono definiti solo gli elementi
essenziali senza i quali non è possibile implementare un
controllo d’accesso.
relazione
many-to-many
 CORE RBAC: DETTAGLI
 Utente: tipicamente è un umano ma potrebbe per esempio
essere anche un agente software
 Ruolo: è una “funzione lavorativa” all’interno di un sistema
(organizzazione) che descrive le autorità e le responsabilità
conferite al “membro” del ruolo
 Permesso: è l’approvazione di un particolare modo di accesso
ad uno o più oggetti (risorse) del sistema (organizzazione)
 Sessione: l’utente stabilisce una sessione durante la quale può
attivare un sottoinsieme dei ruoli che gli appartengono. Ogni
sessione mappa un utente sui possibili ruoli che può attivare
 CORE RBAC: DETTAGLI
 Se per un dato utente esiste una relazione con un ruolo, non
vuol dire che l'utente appartenga a quel ruolo sempre, ma solo
che in generale gli è permesso di farne parte
 L’utente assumerà quel ruolo solo attivando la corrispondente
sessione (e lo abbandonerà disattivandola)
 Un utente può creare una o più sessioni, all'interno di ognuna
delle quali può attivare uno o più ruoli, scegliendo tra quelli che
gli sono stati messi a disposizione
 I permessi disponibili all’utente sono l’unione dei permessi
associati ai ruoli che sono attualmente attivi nella sessione
 CORE RBAC: DETTAGLI
 Non esiste il permesso di compiere un'operazione in
generale, ma, per ogni risorsa, esiste un permesso per ogni
singola operazione che è possibile eseguire su di essa
 È evidente che la stessa operazione può essere associata a
risorse diverse
 Implementare un modello Core RBAC vuol dire fornire un
sistema con cui è possibile interagire mediante:
 funzioni di amministrazione (creare e rimuovere utenti, ruoli,
risorse permessi...)
 funzioni di supporto (creare sessioni, aggiungere/rimuovere ruoli
attivi)
 funzioni di monitoraggio (controllare il sistema)
 RBAC GERARCHICO
 Una gerarchia è un modo naturale di strutturare i ruoli
all'interno di una organizzazione che rispecchia l'effettiva
responsabilità e autorità di ognuno

 A questa gerarchia di ruoli corrisponde di solito una

effettiva ereditarietà di permessi, ovvero, salendo nella
gerarchia, i vari ruoli possiedono tutti i permessi dei ruoli
sottoposti, oltre ai propri
 RBAC GERARCHICO
 Per tenere conto di queste situazioni molto comuni è stato
introdotto il modello RBAC Gerarchico che estende il Core
RBAC introducendo una relazione gerarchica tra ruoli
 RBAC GERARCHICO: DETTAGLI
 Il significato di tale relazione è:
 dati due ruoli r1 ed r2, r1 “eredita” il ruolo r2 se ogni
permesso del ruolo r2 è anche un permesso del ruolo r1
 La relazione è di tipo molti-a-molti per cui
 un ruolo può ereditare i permessi da più ruoli
 un ruolo può essere ereditato da più ruoli
 Lo standard non specifica nulla sul tipo di gerarchia
ammessa, qualsiasi ordine parziale imposto sull’insieme
dei ruoli è valido (gerarchia limitata o generale)
 Vengono estese le funzioni viste in precedenza al fine di
poter gestire le relazioni gerarchiche

inheritance vs. activation hierarchies

 RBAC CON VINCOLI SSD
 In organizzazioni in cui gli utenti possono assumere ruoli
diversi è possibile che sorgano problemi di conflitti di
interessi
 Esempio: un utente può assumere sia il ruolo di controllore
che di controllato su una certa transazione
 Spesso vengono quindi imposti a priori dei vincoli di
separazione dei compiti (SSD- Static Separation of Duty)

SSD

statica basata su user-role dinamica basata su role-activation

assignement
RBAC CON VINCOLI SSD
 RBAC CON VINCOLI SSD

 In RBAC è possibile definire vincoli SSD sia sulla relazione

utente-ruolo che sulla relazione gerarchica tra ruoli: è
possibile escludere a priori dei ruoli sia tra quelli assegnabili
direttamente ad un certo utente, sia tra quelli da cui può
ereditare dei permessi
 Un vincolo SSD è espresso come un insieme di coppie
(rs,n)
 rs: è un sottoinsieme di ruoli
 n: è un numero intero maggiore di 1
 Una coppia di questo tipo specifica che nessun utente può
essere assegnato (direttamente o tramite ereditarietà) a n o
più ruoli nel sottoinsieme rs
 VINCOLI TIPICI

 Ruoli Mutuamente esclusivi

 allo stesso utente deve essere assegnato al massimo un
ruolo di quelli presenti in un insieme mutuamente esclusivo
 questo supporta il principio della “Separazione dei compiti”

 Esiste anche il vincolo duale che riguarda i permessi

 lo stesso permesso deve essere assegnato ad al massimo
un ruolo di quelli presenti in un insieme mutuamente esclusivo
 questo permette di limitare la distribuzione del “potere”
 VINCOLI TIPICI
 Cardinalità
 riguarda il massimo numero di membri appartenenti ad un
ruolo
 la cardinalità minima in genere non viene considerata poiché
è molto difficile da controllare
 Ruoli Prerequisiti
 ad un utente può essere assegnato il ruolo A se gli è già stato
assegnato il ruolo B
 questo vincolo è basato sulla competenza e appropriatezza
 Dualmente per i permessi
 il permesso P può essere assegnato ad un ruolo solo se
questo ruolo è già in possesso del permesso Q
 RBAC CON VINCOLI DSD
 Spesso i vincoli imposti staticamente sono troppo restrittivi
per il sistema...
 Non si vuole limitare a priori il numero di ruoli che i vari
utenti possono assumere, ma solo quelli che posso essere
attivati contemporaneamente
 Oppure, i vincoli imposti staticamente potrebbero non
bastare ed occorre introdurne altri in fase di esecuzione
 Per questo è stata introdotta una versione di RBAC con
vincoli dinamici di separazione dei compiti (DSD- Dynamic
Separation of Duty)
 Questi coinvolgono ovviamente il concetto di sessione,
unico elemento che lega l’utente al ruolo che assume
RBAC CON VINCOLI DSD
 RBAC CON VINCOLI DSD

 Questa versione di RBAC supporta pienamente il principio

del “minimo privilegio”
 Attraverso vincoli dinamici è possibile impedire che un
utente attivi contemporaneamente più ruoli (e quindi
acquisisca più privilegi) di quelli che gli sono strettamente
necessari al momento
Functional Specification of Core RBAC
Administrative Functions

– Creation and Maintenance of Element Sets

• The basic element sets in Core RBAC are USERS, ROLES, OPERATIONS, and
OBJECTS. Of these element sets, OPERATIONS and OBJECTS are considered
predefined by the underlying information system for which RBAC is deployed.
Administrators create and delete USERS and ROLES, and establish relationships
between roles and existing operations and objects. Required administrative
functions for USERS are AddUser and DeleteUser, and for ROLES are AddRole
and DeleteRole.
– Creation and Maintenance of Relations.
• The main relations of Core RBAC are (a) user-to-role assignment relation (UA) and
(b) permission-to-role assignment relation (PA). Functions to create and delete
instances of UA relations are AssignUser and DeassignUser. For PA the required
functions are Grant- Permission and RevokePermission.
 Functional Specification of Core RBAC
Supporting System Functions

• Supporting system functions are required for session management and in

making access control decisions.
• An active role is necessary for regulating access control for a user in a
session. The function that creates a session establishes a default set of
active roles for the user at the start of the session. The composition of this
default set can then be altered by the user during the session by adding or
deleting roles.
• Functions relating to the adding and dropping of active roles and other
auxiliary functions are:
—CreateSession: creates a User Session and provides the user with a default set of
active roles;
—AddActiveRole: adds a role as an active role for the current session;
—DropActiveRole: deletes a role from the active role set for the current session
—CheckAccess: determines if the session subject has permission to perform the
requested operation on an object.
 Functional Specification of Core RBAC
Review Functions

• When user-to-role assignment and permission to-role relation instances have

been created, it should be possible to view the contents of those relations from
both the user and role perspectives.
• It should be possible to view the results of the supporting system functions to
determine some session attributes such as the active roles in a given session or
the total permission domain for a given session.
– —AssignedUsers (M): returns the set of users assigned to a given role;
– —AssignedRoles (M): returns the set of roles assigned to a given user;
– —RolePermissions (O): returns the set of permissions granted to a given role;
– —UserPermissions (O): returns the set of permissions a given user gets through his or
her assigned roles;
– —SessionRoles(O): returns the set of active roles associated with a session;
– —SessionPermissions (O): returns the set of permissions available in the session
– —RoleOperationsOnObject (O): returns the set of operations a given role may perform
on a given object
– —UserOperationsOnObject (O): returns the set of operations a given user may perform
on a given object (obtained either directly or through his or her assigned roles).
 Functional Specification for
Hierarchical RBAC
Administrative Functions

• The administrative functions required for hierarchical RBAC include all

the administrative functions that were required for Core RBAC.
• The additional administrative functions required for the Hierarchical
RBAC model pertain to creation and maintenance of the partial order
relation (RH) among roles.
• —AddInheritance: establish a new immediate inheritance relationship between
two existing roles;
• —DeleteInheritance: delete an existing immediate inheritance relationship
between two roles;
• —AddAscendant: create a new role and add it as an immediate ascendant of
an existing role;
• —AddDescendant: create a new role and add it as an immediate descendant of
an existing role.
 Functional Specification for Hierarchical
RBAC
Supporting System Functions
• The Supporting System Functions for Hierarchical RBAC are the same as for
Core RBAC and provide the same functionality.
• Due to the presence of a role hierarchy, the functions CreateSession and
AddActiveRole have to be redefined.
• In a role hierarchy, a given role may inherit one or more of the other roles.
• CreateSession function, the active role set created as a result of the new
session shall include not only roles directly assigned to a user but also some
or all of the roles inherited by those ―directly assigned roles‖ (that were
previously included in the default Active Role Set) as well.
• AddActiveRole function, a user can activate a directly assigned role or one
or more of the roles inherited by the ―directly assigned role.‖
 Functional Specification for
Hierarchical RBAC
Review Functions
• In addition to the review functions mentioned in Core RBAC, the user
membership set for a given role includes not only users directly assigned
to that given role but also those users assigned to roles that inherit the
given role.
• To capture this expanded ―User Memberships for Roles‖ and ―Role
Memberships for a User‖ the following functions are defined.
• —AuthorizedUsers: returns the set of users directly assigned to a given role as
well as those who were members of those ―roles that inherited the given role.‖
• —AuthorizedRoles: returns the set of roles directly assigned to a given user as
well as those ―roles that were inherited by the directly assigned roles.‖
 Functional Specification for
Hierarchical RBAC
Review Functions
• Because of the presence of partial order among the roles, the permission
set for a given role includes not only the permissions directly assigned to a
given role but also permissions obtained from the roles that the given role
inherited.
• ―Permissions Review‖ functions are listed below:
• —RolePermissions: returns the set of all permissions either directly granted to
or inherited by a given role;
• —UserPermissions: returns the set of permissions of a given user through his
or her authorized roles (union of directly assigned roles and roles inherited by
those roles);
• —RoleOperationsOnObject: returns the set of operations a given role may
perform on a given object (obtained either directly or by inheritance); and
• —UserOperationsOnObject: returns the set of operations a given user may
perform on a given object (obtained directly or through his or her assigned
roles or through roles inherited by those roles).
 Functional Specification for SSD
Relation
Administrative Functions

• —CreateSSDSet: creates a named instance of an SSD relation;

• —DeleteSSDSet: deletes an existing SSD relation;
• —AddSSDRoleMember: adds a role to a named SSD role set;
• —DeleteSSDRoleMember: deletes a role from a named SSD role set; and
• —SetSSDCardinality: sets the cardinality of the subset of roles from the named
SSD role set for which common user membership restriction applies.

Supporting System Functions.

• The Supporting System Functions for an SSD RBAC Model are the same as
those for the Core RBAC Model.
 Functional Specification for SSD
Relation
Review Functions

• All the review functions for the Core RBAC model are needed for
implementation of the SSD RBAC model.

• —SSDRoleSets: returns the set of named SSD relations created for the SSD
RBAC model;
• —SSDRoleSetRoles: returns the set of roles associated with a named SSD role
set; and
• —SSDRoleSetCardinality: returns the cardinality of the subset within the
named SSD role set for which common user membership restriction applies.
 Functional Specification for DSD
Relation

Administrative Functions
• The semantics of creating an instance of a DSD relation are identical to
that of an SSD relation.
• While constraints associated with an SSD relation are enforced during user
assignments, the constraints associated with DSD are typically enforced
only at the time of role activation within a user session.
• —CreateDSDSet: creates a named instance of a DSD relation;
• —DeleteDSDSet: deletes an existing DSD relation;
• —AddDSDRoleMember: adds a role to a named DSD role set;
• —DeleteDSDRoleMember: deletes a role from a named DSD role set;
• —SetDSDCardinality: sets the cardinality of the subset of roles from the
named DSD role set for which user activation restriction within the same
session applies.
Functional Specification for DSD Relation
Supporting System Functions

• The additional functionality required of these functions in the DSD RBAC

model context is that they should enforce the DSD constraints.
– —CreateSession: creates a user session and provides the user with a default set of
active roles;
– —AddActiveRole: adds a role as an active role for the current session;
– —DropActiveRole: deletes a role from the active role set for the current session.
• The semantics of the Supporting System Functions for a DSD RBAC model
with role hierarchies are the same as those for corresponding functions for
hierarchical RBAC
– —CreateSession: creates a user session and provides the user with a default set
of active roles;
– —AddActiveRole: adds a role as an active role for the current session;
– —DropActiveRole: deletes a role from the active role set for the current
session.
 Functional Specification for DSD
Relation
Review Functions

• All the review functions for the Core RBAC model are needed for
implementation of the DSD RBAC model. In addition, functions to view
the results of administrative functions shall also be provided.

– —DSDRoleSets: returns the set of named SSD relations created for the
DSD RBAC model;
– —DSDRoleSetRoles: returns the set of roles associated with a named
DSD role set; and
– —DSDRoleSetCardinality: returns the cardinality of the subset within the
named DSD role set for which user activation restriction within the same
session applies.
Some of the Vendors Offering
RBAC Products