1 / 22

Role Based Access Control

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

kadeem
Télécharger la présentation

Role Based Access 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. Role Based Access Control Ethan Bliss

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

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

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

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

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

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

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

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

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

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

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

  13. General Hierarchy • Multiple inheritance • Combine functional and organizational roles

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

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

  16. Static SoD Example • Billing clerk and accounts receivable clerk mutually exclusive • Deters fraud

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

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

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

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

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

  22. Questions?

More Related