1 / 27

RBAC and Usage Control

RBAC and Usage Control. System Security. Role Based Access Control. Enterprises organise employees in different roles RBAC maps roles to access rights After Subjects are authenticated they can activate roles Access rights are assigned per active roles. A simple example.

alma
Télécharger la présentation

RBAC and Usage Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RBAC and Usage Control System Security

  2. Role Based Access Control • Enterprises organise employees in different roles • RBAC maps roles to access rights • After Subjects are authenticated they can activate roles • Access rights are assigned per active roles

  3. A simple example

  4. Using ACL for 702 Andrew Robert Patricia Sam …

  5. Using ACL @ Uni Level

  6. Role to Access Rights

  7. User to Role Andrew Robert Patricia Sam

  8. From User to Access Right

  9. Extensions to the Model • A user can be in more than one role • Robert Amor is both Prof. and Head of Department • Roles can be organisedinto Hierarchies • Professor > Assistant Professor > Senior Lecturer > Lecturer • Top Roles inherit access rights of Lower Roles • Constraints to enforce organisation-specific requirements

  10. RBAC Constraints • Separation of Duties (SoD) • Protecting the organisation from frauds • Chinese Wall (CW) • Conflict of interests between different domains

  11. Separation of Duties Details • Used when an activity involves more than one role • Purchase order needs to be prepared by a clerk and then authorized by a manager • To avoid a fraud, the user that prepares the order should not be the same that authorizes it

  12. Static Separation of Duties • The same subject cannot be a member of two mutually exclusive roles • A clerk’s and a manager’s roles are mutually exclusive • Too restrictive: the user might get assigned to both roles as long as they are not working on the same order!

  13. Dynamic Separation of Duties • The same subject can be member of two mutually exclusive roles • However, it requires extra checks that need to be done at runtime to avoid undesired behaviour • Simple DSoD, Object DSoD, Operational DSoD, History DSoD

  14. Controlling the usage of resources • DAC, MAC and RBAC are concerned with checking the access rights of entities • Once the access is granted no more controls are enforced

  15. Examples • Read a file only 5 times • Write data into a directory but only up to 1 GB • Connect to the Internet only if there is enough remaining bandwidth (capping plan) • Withdraw from ATM only if there is enough credit in account

  16. Usage Control Model (UCON) • Focuses on controlling usage and not only access to an object • Addresses Digital Right Management (DRM) concerns • DAC, MAC and RBAC can also be expressed by UCON

  17. UCON Model • Usage control is based on: • Authorizations • Obligations • Conditions • Mutability of Attributes • Continuity of Enforcement • Finer grained control Defined by J. Park and R. Sandhu The UCON Usage Control Model. ACM Trans. on Information and System Security, 7(1), 2004

  18. Usage Control Model (UCON) • Applications • Simple, familiar, usable and effective use cases demonstrate the need for UCON • Automatic Teller Machines • CAPTCHAs at Public web sites • End User License Agreements • Terms of Usage for WiFi in Hotels, Airports • Rate limits on call center worker

  19. UCON (cont’d)

  20. Subjects and Objects • Subjects: entities that perform actions on Objects. Are characterized by Attributes: • Identity • Role • Reputation • Credits • Objects: entities that are used by Subjects. Are characterized by Attributes: • Value • Identity • Status

  21. Mutability of Attributes • Attributes of Subjects and Objects • Can be static (IMMUTABLE) • Can be updated (MUTABLE): • Before the action execution (PRE) • During the action execution (ONGOING) • After the action execution (POST) • Example: A storage service charges its users when they read documents. The credit attribute of an user is updated before he reads a document.

  22. Authorization • Authorization rules are a set of requirements that should be satisfied before allowing subjects’ access to objects or use of objects. • Rights-related Authorization Rules (RAR) and Obligation-related Authorization Rules (OAR). • Functional predicates for usage decisions that evaluate: • Subject Attributes • Object Attributes • Right (Action) • Authorization rules • Example: a computational service exploits a security policy to decide whether the user U can perform the action “read” on the file “a.txt”

  23. Obligations • Conditions are a set of decision factors that the system should verify at authorization process along with authorization rules before allowing usage of rights on a digital object. • Dynamic conditions and Static conditions • Obligations are mandatory requirements that a subject has to perform after obtaining or exercising rights on an object. • Functional predicates that verify mandatory requirements that must have been performed by the subject. • Actions • ........... • Example: the user of a storage service must download the license agreement before downloading any other document.

  24. Conditions • Environmental or system based decision factors • Not directly related with Subjects and Objects • e.g. • Current local time • Current system workload • System status • Example: night-users can submit jobs to a computational resource only from 8pm to 8am

  25. Continuity • Mutable Attributes change their values • The evaluation of a usage right can be performed • Before the action (PRE) • Continuously during the action (ONGOING) • The right could be revoked and the action interrupted • Used for long lived actions (days, months,..)

  26. Resources • Chapter 8 in Mark Stamp, Information Security: Principles and Practice, Wiley 2011. • Matt Bishop, Computer Security: Art and Science, Addison-Wesley 2003. • Sandhu, et al. "Role-based access control models," Computer , vol.29, no.2, pp.38,47, Feb 1996 (doi: 10.1109/2.485845)

  27. Questions?

More Related