Role Based Access Control (RBAC) Nicola Zannone

Transcription

1 Role Based Access Control (RBAC) Nicola Zannone 1

2 DAC and MAC Discretionary Access Control (DAC) Access control determined by the owner of an object Oner can delegate access rights to other users Access matrix Mandatory Access Control (MAC) Security labels associated to subjects and objects Access control determined by the system Access control on a per user basis Lack of flexibility No scalable 2

3 Homework Construct a lattice of security classes for security levels public < secret < top-secret and compartments army, politics, business. 1 Which objects are visible to a subject with security label (secret, {army})? 2 How many security classes can be constructed with n security levels and m compartments? 3

4 Homework Solution (1) Security levels: public (P), secret (s) top-secret (TS) Compartments: army (A), politics (P), business (B) 4

5 Homework Solution (2) and (3) Questions 1 Which objects are visible to a subject with security label (secret, {army})? 2 How many security classes can be constructed with n security levels and m compartments? Solution 1 (secret, {army}), (secret, {}), (public, {army}), (public, {}) 2 Lattice nodes N = n 2 m (if n = m = 3, N = = 24) 5

6 Outline Limitations of DAC and MAC Role-Based Access Control (RBAC) Applications of RBAC RBAC Reference Models Base Model (RBAC 0 ) Role Hierarchy (RBAC 1 ) Separation of Duty (RBAC 2 ) 6

7 Motivations Organizations are constantly changing Changes in the organizational structure Users change job function within the organization Required flexible solution to meet changing needs Number of users and applications is increasing within most organizations Required scalable solution to manage accesses 7

8 Question Suppose you want to add a photo to your wall How to set permissions in DAC? Using capability list: Using access control list: 8

9 Answer Suppose you want to add a photo to your wall How to set permissions in DAC? Using capability list: For each user, add permission to view the photo Using access control list: List all users that are allowed to view the photo 9

10 Beyond Identity-based Access Control Access depends on job function, not on identity Example: Bob, bookkeeper for Computer Science Dept, has access to financial records He leaves Sally hired as the new bookkeeper, so she now has access to those records Role of bookkeeper dictates access, not identity of individual Idea: associate access with the particular job of the user 10

11 Role Based Access Control (RBAC) Goals Describe organizational access control policies Based on job function Delegation of authority Separation of duties Increase flexibility in policy administration Easy to modify to meet new security requirements Reduce errors in administration Reduce cost of administration 11

12 RBAC: Intuition 12

13 RBAC Roles defined based on job functions e.g., bookkeeper Permissions defined based on job authority and responsibilities within a role e.g., bookkeeper is allowed to read financial records Users have access to objects based on the assigned role e.g., Sally is the bookkeeper 13

14 Three well-known security principles supported by RBAC Least privilege No more privilege than is necessary to perform assigned job Require identifying the user s job functions, determining minimum set of privileges required to perform that function, and restricting user to a domain with those privileges (nothing more) Separation of duties Mutually exclusive roles e.g., requiring an accounting clerk and account manager to participate in issuing a check. These two roles must be mutually exclusive. Data abstraction Permission defined at a higher level, rather than on read/write/execute In contrast to process of administering lower-level access control mechanisms directly (e.g., access control lists, capabilities) on an object-by-object basis 14

15 Least Privilege Problem: an individual having the ability to perform unnecessary and potentially harmful actions as a side effect of granting the ability to perform desired functions Least Privilege: Administrative practice of assigning permission to users such that user is given no more permission than it is necessary to perform his or her job function Roles are engineered based on the principle of least privilege A role contains the minimum amount of permissions to perform assigned duties A user is assigned to a role that allows him or her to perform only what is required for his/her job function. No single role is given more permission than the same role for another user 15

16 RBAC: Summary Simplify definitions and administration of access control policies Policies based on duty and responsibility assignments Assignment of permissions to users Permission associated with roles Users assigned to appropriate roles Updates for roles instead of updating privileges for every user 16

17 RBAC: Summary Simplify definitions and administration of access control policies Policies based on duty and responsibility assignments Assignment of permissions to users Permission associated with roles Users assigned to appropriate roles Updates for roles instead of updating privileges for every user User changes job function? Add/remove permission for a job function? 16

18 Where RBAC is used RBAC is currently used in Database management systems Security management and network operating system Applications (using some form of RBAC) Microsoft Active Directory Microsoft SQL Server SELinux FreeBSD Solaris Oracle DBMS PostgreSQL

19 SELinux Linux uses DAC as access control model Enable use of MAC in Linux Processes run in a security context User Identity: user identity within SELinux environment (not be confused with the standard Linux user accounts) Role: define a set of permissions granted to a user Domain and Type: define what a process can do ( domain refers to processes and type refers to objects) Category/level: set category and/or level for Multi Level Security A process in one domain transitions to another domain (i.e. runs under a different security context) RBAC as a boundary of domain transitions 18

20 Four Reference Models RBAC 3 RBAC 1 RBAC 2 RBAC 0 RBAC 0 : base model RBAC 1 : RBAC 0 + role hierarchies RBAC 2 : RBAC 0 + constraints RBAC 3 : RBAC 1 + RBAC 2 19

21 RBAC 0 concepts User a human being or intelligent autonomous agent Role job function within the context of organization associated semantics regarding its authority and responsibility Permission an operation that can be exercised on objects objects and operations are domain dependent Example: DBs objects are tables, columns, and rows operations are insert, delete, and update Session instance of a connection of a user to the system define the subset of activated roles different sessions for the same user can be active at each time 20

22 RBAC 0 Model 21

23 Notation U Users R Roles OPS Operations OBS Objects P OPS OBS Permissions SE Session UA U R User Assignment PA P R Permission Assignment A subject can have multiple roles A role can have multiple subjects A role can have many permissions A permission can be assigned to many roles 22

24 Exercise Given the following User Assignment and Permission Assignment, define the corresponding access control matrix. User Alice Alice Bob Charlie David Role Radiologist GP GP Radiologist Nurse Role Nurse GP GP GP Radiologist Radiologist Permission (read,prescription) (read,prescription) (write,prescription) (read,history) (read,history) (insert, image scan) 23

25 Solution Prescription history Image scan Alice read read insert write Bob read read write Charlie read insert David read What happens if the job function of a user changes? e.g., Charlie becomes a GP What happens if permissions are added/removed from a role? e.g., Radiologist can also delete image scans 24

26 RBAC 1 : Role Hierarchy Some roles subsume others: many operations are common to a large number of roles a GP can perform all actions of a physician, as well as others This suggests a hierarchy of roles Reflect an organization s role structure RBAC 3 RBAC 1 RBAC 0 Inheritance among roles Instead of specifying the permission for each role, one specifies it for a more generalized role Granting access to role R implies that access is granted for all specialized roles of R RBAC 2 25

27 Role Hierarchy Structuring roles Partial order : x y we say x is specialization of y Inheritance of permission from generalized role y (top) to specialized role x (bottom) Members of x are also implicitly members of y if x y then role x inherits permissions of role y Partial order Reflexive (i.e., x x) Transitive (i.e., x y and y z then x z) Anti-symmetric (i.e., x y and y x then x = y) 26

28 Role Hierarchy Examples 27

29 RBAC 1 Model 28

30 Exercise Let UA = {(u 1, r 2 ), (u 2, r 3 ), (u 3, r 4 ), (u 4, r 5 )} and PA = {(r 1, p 1 ), (r 2, p 2 ), (r 3, p 3 ), (r 4, p 4 ), (r 5, p 5 )}. Given the following role hierarchy, determine the permissions that users have. r 1 r 3 r 2 r 4 inheritance r 5 29

31 Solution p 1 p 2 p 3 p 4 p 5 u 1 u 2 u 3 u 4 30

32 Solution p 1 p 2 p 3 p 4 p 5 u 1 u 2 u 3 u 4 30

33 Remark Here used reversed role hierarchical Dominance relation instead of specialization Inheritance from bottom to top What is the problem of inheritance with respect to dominance? manager senior engineer engineer project member 31

34 RBAC 2 Constraints Mutually exclusive roles/permissions Define conflicting roles RBAC 3 RBAC 1 RBAC 2 RBAC 0 Cardinality constraints Number of users that can be assigned to a role simultaneously Number of roles that can be assigned to a user Prerequisite roles User can be assigned to role A only if the user is already a member of role B 32

35 Conflicts of Interest User gains advantages because Access information about competitors (Chinese Wall) Abuse his position within the organization (RBAC) Ensure that two or more people must be involved in executing critical operations Restrict combinations of privileges made available to users 33

36 Question Buying and paying for goods (O) order the goods and record the details of the order; (I) record the arrival of the invoice and verify that the details on the invoice match the details of the order; (G) verify that the goods have been received, and the features of the goods match the details on the invoice; and (P) authorize the payment to the supplier against the invoice What can go wrong? 34

37 Question Buying and paying for goods (O) order the goods and record the details of the order; (I) record the arrival of the invoice and verify that the details on the invoice match the details of the order; (G) verify that the goods have been received, and the features of the goods match the details on the invoice; and (P) authorize the payment to the supplier against the invoice What can go wrong? How can we solve it? 34

38 Question Buying and paying for goods (O) order the goods and record the details of the order; (I) record the arrival of the invoice and verify that the details on the invoice match the details of the order; (G) verify that the goods have been received, and the features of the goods match the details on the invoice; and (P) authorize the payment to the supplier against the invoice Requirements (SoD) at least three users cooperation is needed two different users perform steps (O) and (P) i.e., no single user can order goods and authorize payment for them 34

39 Separation of Duty Principle: collaboration of multiple users needed to perform sensitive tasks Static Separation of Duty (SSoD) user cannot be assigned to both roles SSoD prevent fraud by placing constrains on administrative actions Dynamic Separation of Duty (DSoD) user cannot act simultaneously in both roles DSoD prevent fraud by placing constrains on the roles that can be activated in a session 35

40 Static Separation of Duty (SSoD) Static enforcement of SoD: multiple users together have all permissions to perform sensitive tasks SSoD policies Static Separation of Duty constraint ssod(ps, n) n users are needed to cover all permissions in the permission set ps Statically Mutually Exclusive Roles constraint smer(rs, n) Any user cannot be assigned to n or more roles in the role set rs Enforced by carefully (manually?) assigning permissions/roles to users without maintaining a history of sessions 36

41 In our example... 4 permissions: (O) ordering (I) verifying invoice (G) verifying goods (P) authorizing payment At least 3 users are required to perform all four permissions? no user can have both O and P? 37

42 In our example... 4 permissions: (O) ordering (I) verifying invoice (G) verifying goods (P) authorizing payment At least 3 users are required to perform all four permissions ssod({o, I, G, P}, 3) no user can have both O and P ssod({o, P}, 2) 37

43 RBAC 2 Model with SSoD 38

44 Exercise Let ({r 1, r 2, r 3, r 4 }, 3) SMER. Which of the following UA sets are valid? 1 UA 1 = {(u 1, r 1 ), (u 2, r 1 ), (u 3, r 1 ), (u 1, r 2 ), (u 4, r 2 ), (u 5, r 2 ), (u 1, r 3 ), (u 2, r 3 ), (u 3, r 3 ), (u 4, r 4 )} 2 UA 2 = {(u 1, r 1 ), (u 3, r 1 ), (u 5, r 1 ), (u 1, r 2 ), (u 2, r 2 ), (u 3, r 2 ), (u 5, r 2 ), (u 2, r 3 ), (u 4, r 3 ), (u 4, r 3 )} Provide reasons for your answer. 39

45 Solution 1 UA 1 is NOT valid u 1 covers 3 roles (u 1, r 1 ), (u 1, r 2 ), (u 1, r 3 ) 2 UA 2 is valid No users cover 3 or more roles 40

46 Dynamic Separation of Duty (DSoD) Static Separation of Duty can be too restrictive In our example: We may only want to avoid a user authorizes the payment for his own orders Multiple roles can be activated in one session DSoD used to restrict concurrent activation of some roles Dynamically Mutually Exclusive Roles constraint dmer(rs, n) no users can simultaneously activate n or more roles from rs in one session 41

47 RBAC 2 Model with DSoD DSoD place constraints on the roles that can be activated in a user s session. If one role that takes part in a DSoD is activated, the user cannot activate the related (conflicting) role in the same session 42

48 RBAC 3 Consolidated model Combine RBAC 1 and RBAC 2 Support RBAC 0 Constraints Role Hierarchies RBAC 3 RBAC 1 RBAC 2 RBAC 0 43

49 Summary Limitations of DAC and MAC Lack of flexibility No scalable Role-Based Access Control (RBAC) RBAC References Models RBAC 0 : Base model RBAC 1 : RBAC 0 + Role hierarchy RBAC 2 : RBAC 0 + Separation of duty RBAC 3 : RBAC 1 + RBAC 2 44

50 References R. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman Role-Based Access Control Models, IEEE Computer 29(2): (obligatory) Ninghui Li, Mahesh V. Tripunitara, and Ziad Bizri On mutually exclusive roles and separation-of-duty. ACM Trans. Inf. Syst. Secur. 10(2) (recommended) Pierangela Samarati and Sabrina De Capitani di Vimercati Access Control: Policies, Models, and Mechanisms. In FOSAD 00. Springer-Verlag, (suggested) 45

51 Assignment Assignment(s) is mandatory Also available in the repository Deadline: 11 November 2011 How to submit it By (n.zannone at tue dot nl) Mail box (HG, 9th floor, north side) 46