320 likes | 653 Views
Role Based Access Control. Ethan Bliss. Introduction. The need for access control began with multi-user and multi-application computers in the 1970s System administrator must ensure only authorized users can access certain data and resources
E N D
Role Based Access Control Ethan Bliss
Introduction • The need for access control began with multi-user and multi-application computers in the 1970s • System administrator must ensure only authorized users can access certain data and resources • Access Control is a means by which access is enabled or restricted • Who can access • Type of access • Rule Based Access Control (RBAC) introduced in 1992 by Ferraiolo and Kuhn
Terminology • User: person who uses the computer system • Session: an instance of a user’s dialog with a system • Subject: a computer process run by a user • Object: a resource accessible on a computer system • Operation: an active process invoked by a subject • Permission: authorization to perform an action
Role Based Access Control • With Role-Based Access Control (RBAC), access to objects is based on a user’s role in an organization • A role is essentially a collection of permissions
RBAC Rules • Role assignment: • Subject can execute transaction only if subject has been assigned to a role • All users required to have a role • Role authorization: • Subject’s role must be authorized for the subject • Users can only take on a role they are authorized for • Transaction authorization: • Subject can execute transaction only if transaction authorized for subject’s role • Users can only execute transactions they are authorized to
RBAC Security Support • RBAC supports three well-known security principles: • Least Privilege • only those permissions required for tasks conducted by members of the role are assigned to role. • Separation of duties • ensure that mutually exclusive roles must be invoked to complete a sensitive task • Data Abstraction • supported by means of abstract permissions such as credit and debit for an account.
RBAC Implementation • RBAC implementation ranges from simple to complex • Cannot be treated as a single model • Issues of scope and terminology • Wide variety of technology and choices • Many models use different terminology to describe the same concepts • RBAC standardization was proposed by NIST( National Institute of Standards and Technology).
RBAC Standard RBAC Reference Model • Four Components • Core RBAC • Hierarchical RBAC • Limited Hierarchies • General Hierarchies • Static Constrained RBAC • Without Hierarchies • With Hierarchies • Dynamic Constrained RBAC Functional Specification • Set of functional components
RBAC Reference Model • Defined in terms of four model components • Core RBAC • Hierarchical RBAC • Static Separation of Duty Relations • Dynamic Separation of Duty Relations • Provide standard vocabulary • Define broad range of RBAC features
Core RBAC • The essential elements of RBAC • Users • Roles • Permissions, composed of • Operations applied to • Objects • Access policy constructed around role • Users assigned to roles • Permissions associated with roles
Core RBAC Mapping • Static: do not involve a subject • Users assigned to roles • Roles assigned permissions • Dynamic: subject access • Subject mapped to single user • User may be mapped to multiple subjects • Subject mapped to role set
Hierarchical RBAC • Adds requirements for supporting role hierarchies • Inheritance relationship among roles • Parent roles acquire permission of children • Children acquire user membership of parents • Two types • General: allow a role to have more than one immediate ascendant and descendant • Limited: impose restrictions to generate simpler tree structure • 1+ immediate ascendants but one descendent • Vice versa
General Hierarchy • Multiple inheritance • Combine functional and organizational roles
Constrained RBAC • Adds separation of duty (SoD) relations to RBAC model • Critical operations are divided among 2+ people • No single individual can compromise security • Minimize likelihood of collusion • Used to enforce conflict of interest policies • Allows both static and dynamic SoD
Static SoD • Enforce constraints on assignment of users to roles • If a user is assigned to one role, the user is prohibited from being a member of a second role • Roles may be mutually exclusive • Conflicting permissions assigned to these roles • Defined with and without hierarchy • Static SoD with hierarchy: both inherited and directly assigned roles considered
Static SoD Example • Billing clerk and accounts receivable clerk mutually exclusive • Deters fraud
Dynamic SoD • Also limit permissions available to a user • Users may be authorized for conflicting roles • Limitations imposed while the user is logged on • No user may be active in both roles at once • Dynamic SoD prevents applying conflicting privileges in the same session • Assumes a user cannot terminate a session and log on with another role
RBAC Functional Specification • Defines features required of RBAC system Three categories • Administrative Operations • Create, delete, maintain RBAC elements and relations • Administrative Reviews • Query operations on RBAC elements and relations • System level functionality • Creation of user sessions • Role activation/deactivation • Enforcement of role activation constraints
RBAC, MAC, and DAC DAC (Dynamic Access Control) • Creators or owners of files assign access rights • Subject with discretionary access can pass information to another subject MAC (Mandatory Access Control) • Access control system mediates all access to objects • Users cannot give away permissions RBAC • More general • Can implement both MAC and DAC
DAC using RBAC • More theoretical than practical • RBAC is nondiscretionary in nature • Implemented using roles associated with each object • Four roles and eight permissions for each object • Roles: OWN, PARENT, PARENTwithGRANT, READ • Permissions associated to roles: CanRead, DestroyObject, etc. • Allow authorized users to assign other users to roles
MAC using RBAC • Easier than implementing DAC • Combine role hierarchies and constraints • Two role hierarchies, one for read and one for write • High security levels on top of read and bottom of write • Read/Write permissions for objects assigned to roles based on security level