280 likes | 467 Views
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.
E N D
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
Using ACL for 702 Andrew Robert Patricia Sam …
User to Role Andrew Robert Patricia Sam
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
RBAC Constraints • Separation of Duties (SoD) • Protecting the organisation from frauds • Chinese Wall (CW) • Conflict of interests between different domains
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
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!
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
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
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
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
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
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
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
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.
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”
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.
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
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,..)
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)