Access Control RBAC: Bài giảng Chương 4 về Role-based Models

Chapter 4 Access Control Rolebased models RBAC

Agenda

Rolebased models Administrative rolebased access control model

https://books.google.com.vn/books? id=_O7xBwAAQBAJ&pg=PA171&lpg=PA171 &dq=Open/close+policy+in+database+security &source=bl&ots=4cH6efHzHp&sig=eO6djffm piyvB0L6hmWAbPPeZow&hl=vi&sa=X&ei= F2PVb YOcaJuATyvIHQAw&redir_esc=y#v=onepage &q&f=false

Rolebased models

Many organizations base access control decisions on “the roles that individual users take on as part of the organization”.

They prefer to centrally control and maintain access rights that reflect the organization’s protection guidelines.

With RBAC, rolepermission relationships can be predefined, which makes it simple to assign users to the predefined roles.

The combination of users and permissions tend to change over time, the permissions associated with a role are more stable.

RBAC concept supports three wellknown security principles: – Least privilege – Separation of duties – Data abstraction

Roles Hierarchies

User Role Assignment

Role Permission Assignment

Users

Roles

Permissions

Role Based Access Control (RBAC) Access control in organizations is based on “roles that individual users take on as part of the organization” A role is “is a collection of permissions”

Constraints

Role Based Access Control (RBAC)

RBAC

Access depends on role/function, not identity – Example: Allison is bookkeeper for Math

Dept. She has access to financial records. If she leaves and Betty is hired as the new bookkeeper, Betty now has access to those records. The role of “bookkeeper” dictates access, not the identity of the individual.

RBAC

Users

Permission

Permissions

Manager

Senior Engineer

Senior Administrator

Role r

Administrator

Engineer

Employee

n (cid:0) m assignments

n + m assignments

(b)

(a)

RBAC (cont’d)

Is RBAC a discretionary or mandatory access control? – RBAC is policy neutral; however individual RBAC configurations

can support a mandatory policy, while others can support a discretionary policy.

Role Hierarcies

Role Administration

Project Supervisor

Test engineer

Programmer

Project Member

RBAC (NIST Standard)

PA UA

Users Roles Operations Objects

Permissions

user_sessions (one-to-many) role_sessions (many-to-many)

Sessions

An important difference from classical models is that Subject in other models corresponds to a Session in RBAC

Core RBAC (relations)

⊆ Users x Roles ⊆ Permissions x Roles

2Users

2Permissions

2Sessions Users 2Roles

UA)}

Permissions = 2Operations x Objects UA PA assigned_users: Roles (cid:0) assigned_permissions: Roles (cid:0) Op(p): set of operations associated with permission p Ob(p): set of objects associated with permission p user_sessions: Users (cid:0) session_user: Sessions (cid:0) session_roles: Sessions (cid:0) – session_roles(s) = {r | (session_user(s), r) (cid:0) avail_session_perms: Sessions (cid:0)

2Permissions

RBAC with General Role Hierarchy

RH (role hierarchy)

PA UA

Users Roles Operations Objects

Permissions

user_sessions (one-to-many)

role_sessions (many-to-many)

Sessions

RBAC with General Role Hierarchy

authorized_users: Roles(cid:0)

2Users

authorized_users(r) = {u | r’ ≥ r &(r’, u) (cid:0)

UA)

authorized_permissions: Roles(cid:0)

authorized_users(r) = {p | r’ ≥ r &(p, r’) (cid:0)

2Permissions PA)

RH Roles x Roles is a partial order – called the inheritance relation – written as ≥.

(r1 ≥ r2) (cid:0)

authorized_users(r1)

⊆ authorized_users(r2) &

authorized_permisssions(r2)

⊆ authorized_permisssions(r1)

(cid:0)

px, pye10

Example

Manager

e8, e9 px, py

px, pye5

Senior Engineer

Senior Administrator

e3, e4 px, py pp

e6, e7 px, py

Administrator

Engineer

Employee

po pa, pb e1, e2 px, py

pm, pn px, py

p1, p2

authorized_users(Employee)? authorized_users(Administrator)?

authorized_permissions(Employee)? authorized_permissions(Administrator)?

Constrained RBAC

RH (role hierarchy)

Static Separation of Duty

PA UA

Users Roles Operations Objects

Permissions

user_sessions (one-to-many)

Dynamic Separation of Duty Sessions

Separation of Duties

No user should be given enough privileges to misuse the system on their own.

Statically: defining the conflicting roles

Dynamically: Enforcing the control at access time

Role vs. Types Data Structures

RBAC – U: set of users – P: set of permissions – R: set of roles Type Enforcement – E: set of subjects or objects – Permission Assignment ST: set of subject types OT: set of object types O: set of operations

Role vs. Types Data Structures

Users: U Permissions: P Roles: R Assignments: Userrole, permrole, role role Sessions: S Function: user(S), roles(S) Constraints: C

RBAC Family of Models

RBAC0 contains all but hierarchies and constraints RBAC1 contains RBAC0 and hierarchies RBAC2 contains RBAC0 and constraints RBAC3 contains all The RBAC family idea has always been more a NIST initiative The RBAC families are present in the NIST RBAC standard [NIST2001] with slight modifications: – RBAC0, RBAC1 (options), RBAC3 (SSD) , RBAC3

(DSD)

Advantages of RBAC

Allows Efficient Security Management – Administrative roles, Role hierarchy Principle of least privilege allows minimizing damage Separation of Duties constraints to prevent fraud Allows grouping of objects Policyneutral Provides generality Encompasses DAC and MAC policies

RBAC’s Benefits

Cost Benefits

Saves about 7.01 minutes per employee, per year in administrative functions – Average IT admin salary $59.27 per hour – The annual cost saving is:

• $6,924/1000; $692,471/100,000

Reduced Employee downtime – if new transitioning employees receive their system privileges

faster, their productivity is increased

– 26.4 hours for nonRBAC; 14.7 hours for RBAC – For average employee wage of $39.29/hour, the annual productivity cost savings yielded by an RBAC system:

• $75000/1000; $7.4M/100,000

RBAC Products

SUN Solaris Sybase SQL Server BMC INCONTROL for Security Management Systor Security Administration Manager Tivoli TME Security Management Computer Associates Protect IT Siemens rbacDirX