Bài giảng Bảo mật CSDL - Chap 5: Access Control Role-based models RBAC

Access Control Role-based modelsRBACChapter 4AgendaRole-based modelsAdministrative role-based access control modelhttps://books.google.com.vn/books?id=_O7xBwAAQBAJ&pg=PA171&lpg=PA171&dq=Open/close+policy+in+database+security&source=bl&ots=4cH6efHzHp&sig=eO6djffmpiyvB0L6hmWAbPPeZow&hl=vi&sa=X&ei=-F2PVb-YOcaJuATyvIHQAw&redir_esc=y#v=onepage&q&f=falseRole-based modelsMany 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, role-permission 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 well-known security principles:Least privilegeSeparation of dutiesData abstractionRole 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”Role Based Access Control (RBAC)RBACAccess depends on role/function, not identityExample: 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.RBACRBAC (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 HierarciesRole AdministrationProject SupervisorTest engineerProgrammerProject MemberPermissionsRBAC (NIST Standard)UsersRolesOperationsObjectsSessionsUAuser_sessions(one-to-many)role_sessions(many-to-many)PAAn important difference from classical models is thatSubject in other models corresponds to a Session in RBACCore RBAC (relations)Permissions = 2Operations x Objects UA ⊆ Users x RolesPA ⊆ Permissions x Rolesassigned_users: Roles  2Users assigned_permissions: Roles  2PermissionsOp(p): set of operations associated with permission pOb(p): set of objects associated with permission puser_sessions: Users  2Sessionssession_user: Sessions  Userssession_roles: Sessions  2Rolessession_roles(s) = {r | (session_user(s), r)  UA)}avail_session_perms: Sessions  2PermissionsPermissionsRBAC with General Role HierarchyUsersRolesOperationsObjectsSessionsUAuser_sessions(one-to-many)role_sessions(many-to-many)PARH(role hierarchy)RBAC with General Role Hierarchyauthorized_users: Roles 2Users authorized_users(r) = {u | r’ ≥ r &(r’, u)  UA)authorized_permissions: Roles 2Permissions authorized_users(r) = {p | r’ ≥ r &(p, r’)  PA) RH Roles x Roles is a partial ordercalled the inheritance relation written as ≥. (r1 ≥ r2)  authorized_users(r1) ⊆ authorized_users(r2) &authorized_permisssions(r2) ⊆ authorized_permisssions(r1)Examplepx, pyp1, p2pa, pbpx, pye1, e2px, pye3, e4px, pye5px, pye6, e7px, pye8, e9px, pye10pm, pnpoppauthorized_users(Employee)?authorized_users(Administrator)?authorized_permissions(Employee)? authorized_permissions(Administrator)?Constrained RBACPermissionsUsersRolesOperationsObjectsSessionsUAuser_sessions(one-to-many)PARH(role hierarchy)StaticSeparation of DutyDynamicSeparation of DutySeparation 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 timeRole vs. Types Data StructuresRBACU: set of usersP: set of permissionsR: set of rolesType EnforcementE: set of subjects or objectsPermission AssignmentST: set of subject typesOT: set of object typesO: set of operationsRole vs. Types Data StructuresUsers: UPermissions: PRoles: RAssignments: User-role, perm-role, role-roleSessions: SFunction: user(S), roles(S)Constraints: CRBAC Family of ModelsRBAC0 contains all but hierarchies and constraintsRBAC1 contains RBAC0 and hierarchiesRBAC2 contains RBAC0 and constraintsRBAC3 contains allThe RBAC family idea has always been more a NIST initiativeThe RBAC families are present in the NIST RBAC standard [NIST2001] with slight modifications:RBAC0, RBAC1 (options), RBAC3 (SSD) , RBAC3 (DSD)Advantages of RBACAllows Efficient Security ManagementAdministrative roles, Role hierarchyPrinciple of least privilege allows minimizing damageSeparation of Duties constraints to prevent fraudAllows grouping of objectsPolicy-neutral - Provides generalityEncompasses DAC and MAC policiesRBAC’s BenefitsCost BenefitsSaves about 7.01 minutes per employee, per year in administrative functionsAverage IT admin salary - $59.27 per hourThe annual cost saving is: $6,924/1000; $692,471/100,000Reduced Employee downtime if new transitioning employees receive their system privileges faster, their productivity is increased26.4 hours for non-RBAC; 14.7 hours for RBACFor average employee wage of $39.29/hour, the annual productivity cost savings yielded by an RBAC system: $75000/1000; $7.4M/100,000RBAC ProductsSUN SolarisSybase SQL ServerBMC INCONTROL for Security ManagementSystor Security Administration ManagerTivoli TME Security ManagementComputer Associates Protect ITSiemens rbacDirX