Modello di Controllo dell Accesso basato sui ruoli (RBAC)

Transcript

1 Modello di Controllo dell Accesso basato sui ruoli (RBAC)

2 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

3 POLITICHE RBAC

4 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

5 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 )

6 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

7 LO STANDARD RBAC è stato standardizzato come ANSI/INCITS In questo documento vengono proposti quattro modelli RBAC in modo incrementale

8 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

9 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

10 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

11 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)

12 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

13 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

14 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

15 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 assignement dinamica basata su role-activation

16 RBAC CON VINCOLI SSD

17 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

18 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

19 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

20 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

21 RBAC CON VINCOLI DSD

22 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

23 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.

24 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.

25 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).

26 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.

27 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.

28 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.

29 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).

30 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.

31 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.

32 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.

33 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.

34 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.

35 Some of the Vendors Offering RBAC Products