Chapter 7- RBAC-databases Security.pptx

Security Princ & Practice Course 4 : DAC, MAC & RBAC for Database security Professor Okba Kazar Email: [email protected]/[email protected] File Organization • BIT: Binary Digit (0,1; Y,N; On, Off) • BYTE: Combination of BITS representing a CHARACTER • FIELD: Collection of BYTES representing a...

Security Princ & Practice Course 4 : DAC, MAC & RBAC for Database security Professor Okba Kazar Email: [email protected]/[email protected] File Organization • BIT: Binary Digit (0,1; Y,N; On, Off) • BYTE: Combination of BITS representing a CHARACTER • FIELD: Collection of BYTES representing a DATUM or Fact • RECORD: Collection of FIELDS reflecting a BIT TRANSACTION BYTE FIELD RECORD FILE DATABASE File Organization • FILE: Collection of similar RECORDS • DATABASE: • Organization’s Electronic Library of FILES • Organized to serve business applications • Collection of – interrelated data and – set of programs to access the data • ENTITY: Person, place, thing, event about which data must be kept • ATTRIBUTE: Description of a particular ENTITY • KEY FIELD: Field used to retrieve, update, sort RECORD Key Field • Field in Each Record • Uniquely Identifies THIS Record • For RETRIEVAL UPDATING SORTING Protection of Data Confidentiality  Access control – which data users can access  Information flow control – what users can do with the accessed data  Data Mining 5 Access Control  Ensures that all direct accesses to object are authorized  Protects against accidental and malicious threats by regulating the read, write and execution of data and programs Requires: - Proper user identification - Information specifying the access rights is protected form modification 6 HOW TO SPECIFY ACCESS CONTROL? 7 Access Control  Subject: active entity that requests access to an object -  Object: passive entity accessed by a subject -  e.g., user or program e.g., record, relation, file Access right (privileges): how a subject is allowed to access an object - e.g., subject s can read object o 8 Relation-Level Granularity Confidential relation Personname Companyname Salary Smith BB&C $43,982 Dell Bell $97,900 Black BB&C $35,652 9 Tuple-level Granularity Works Person-name Companyname Salary Smith BB&C $43,982 Public Dell Bell $97,900 Conf. Black BB&C $35,652 Public 10 Attribute-Level Granularity Works PersonCompanyname Publ. name Publ. Salary Smith BB&C $43,982 Dell Bell $97,900 Black BB&C $35,652 Conf. 11 Cell-Level Granularity Works Personname Companyname Salary BB&C P $43,982 C Smith P Dell C Bell C $97,900 C Black P BB&C C $35,652 C Database Security - Farkas 12 Access Control Policies  Discretionary Access Control (DAC)  Mandatory Access Control (MAC)  Role-Based Access Control (RBAC) 13 Discretionary Access Control (DAC)  For each subject access right to the objects are defined  (subject, object, +/- access mode)  (Black, Employee-relation, read)  User based  Grant and Revoke  Problems: - Propagation of access rights - Revocation of propagated access rights 14 DAC by Grant and Revoke GRANT SELECT ON Employee TO Black WITH GRANT OPTION ? Black GRANT SELECT ON Employee TO Red Red Brown revokes grant given to Black ? Brown (owner) GRANT UPDATE(Salary) ON Employee TO White Brown does not want Red to access the Employee relation White 15 Implementation Access Control List (column) (ACL) Capability List (row) File 1 File 2 Joe:Read Joe:Read Joe:Write Sam:Read Joe:Own Sam:Write Sam:Own Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Access Control Triples Subject Joe Joe Joe Joe Sam Sam Sam Access Read Write Own Read Read Write Own Object File 1 File 1 File 1 File 2 File 2 File 2 File 2 16 Access Control Mechanisms     Security through Views Stored Procedures Grant and Revoke Query modification 17 1. Security Through Views  Assign rights to access predefined views CREATE VIEW Outstanding-Student AS SELECT NAME, COURSE, GRADE FROM Student WHERE GRADE > B Problem: Difficult to maintain updates. 18 2. Stored Procedures   Assign rights to execute compiled programs GRANT RUN ON <program> TO <user> Problem: Programs may access resources for which the user who runs the program does not have permission. 19 3. Grant and Revoke GRANT <privilege> ON <relation> To <user> [WITH GRANT OPTION] ------------------------------------------------------------------------------------------------------------------------------------    GRANT SELECT * ON Student TO Matthews GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS GRANT SELECT(NAME) ON Student TO Brown GRANT command applies to base relations as well as views 20 Grant and Revoke REVOKE <privileges> [ON <relation>] FROM <user> -------------------------------------------------------------------------------------------------------------------------    REVOKE SELECT* ON Student FROM Blue REVOKE UPDATE ON Student FROM Black REVOKE SELECT(NAME) ON Student FROM Brown 21 Types of Discretionary Privileges • The account level: – At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database. • The relation level (or table level): – At this level, the DBA can control the privilege to access each individual relation or view in the database. Types of Discretionary Privileges • The privileges at the account level apply to the capabilities provided to the account itself and can include: – the CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base relation; – the CREATE VIEW privilege; – the ALTER privilege, to apply schema changes such adding or removing attributes from relations; – the DROP privilege, to delete relations or views; – the MODIFY privilege, to insert, delete, or update tuples; – and the SELECT privilege, to retrieve information from the database by using a SELECT query. Types of Discretionary Privileges(4) • To control the granting and revoking of relation privileges, each relation R in a database is assigned and owner account, which is typically the account that was used when the relation was created in the first place. – The owner of a relation is given all privileges on that relation. – In SQL2, the DBA can assign and owner to a whole schema by creating the schema and associating the appropriate authorization identifier with that schema, using the CREATE SCHEMA command. – The owner account holder can pass privileges on any of the owned relation to other users by granting privileges to their accounts. Types of Discretionary Privileges(5) • In SQL the following types of privileges can be granted on each individual relation R: – SELECT (retrieval or read) privilege on R: • Gives the account retrieval privilege. • In SQL this gives the account the privilege to use the SELECT statement to retrieve tuples from R. – MODIFY privileges on R: • This gives the account the capability to modify tuples of R. • In SQL this privilege is further divided into UPDATE, DELETE, and INSERT privileges to apply the corresponding SQL command to R. • In addition, both the INSERT and UPDATE privileges can specify that only certain attributes can be updated by the account. Specifying Privileges Using Views • The mechanism of views is an important discretionary authorization mechanism in its own right. For example, – If the owner A of a relation R wants another account B to be able to retrieve only some fields of R, then A can create a view V of R that includes only those attributes and then grant SELECT on V to B. – The same applies to limiting B to retrieving only certain tuples of R; a view V’ can be created by defining the view by means of a query that selects only those tuples from R that A wants to allow B to access. Revoking Privileges • In some cases it is desirable to grant a privilege to a user temporarily. For example, – The owner of a relation may want to grant the SELECT privilege to a user for a specific task and then revoke that privilege once the task is completed. – Hence, a mechanism for revoking privileges is needed. In SQL, a REVOKE command is included for the purpose of canceling privileges. An Example (1) • Suppose that the DBA creates four accounts – A1, A2, A3, A4 • and wants only A1 to be able to create base relations. Then the DBA must issue the following GRANT command in SQL GRANT CREATETAB TO A1; • In SQL2 the same effect can be accomplished by having the DBA issue a CREATE SCHEMA command as follows: CREATE SCHAMA EXAMPLE AUTHORIZATION A1; An Example (2) • User account A1 can create tables under the schema called EXAMPLE. • Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT – A1 is then owner of these two relations and hence all the relation privileges on each of them. • Suppose that A1 wants to grant A2 the privilege to insert and delete tuples in both of these relations, but A1 does not want A2 to be able to propagate these privileges to additional accounts: GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2; An Example (3) An Example (4) • Suppose that A1 wants to allow A3 to retrieve information from either of the two tables and also to be able to propagate the SELECT privilege to other accounts. • A1 can issue the command: GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3 WITH GRANT OPTION; • A3 can grant the SELECT privilege on the EMPLOYEE relation to A4 by issuing: GRANT SELECT ON EMPLOYEE TO A4; – Notice that A4 can’t propagate the SELECT privilege because GRANT OPTION was not given to A4 An Example (5) • Suppose that A1 decides to revoke the SELECT privilege on the EMPLOYEE relation from A3; A1 can issue: REVOKE SELECT ON EMPLOYEE FROM A3; • The DBMS must now automatically revoke the SELECT privilege on EMPLOYEE from A4, too, because A3 granted that privilege to A4 and A3 does not have the privilege any more. An Example (6) • Suppose that A1 wants to give back to A3 a limited capability to SELECT from the EMPLOYEE relation and wants to allow A3 to be able to propagate the privilege. – The limitation is to retrieve only the NAME, BDATE, and ADDRESS attributes and only for the tuples with DNO=5. • A1 then create the view: CREATE VIEW A3EMPLOYEE AS SELECT NAME, BDATE, ADDRESS FROM EMPLOYEE WHERE DNO = 5; • After the view is created, A1 can grant SELECT on the view A3EMPLOYEE to A3 as follows: GRANT SELECT ON A3EMPLOYEE TO A3 WITH GRANT OPTION; An Example (7) • Finally, suppose that A1 wants to allow A4 to update only the SALARY attribute of EMPLOYEE; • A1 can issue: GRANT UPDATE ON EMPLOYEE (SALARY) TO A4; – The UPDATE or INSERT privilege can specify particular attributes that may be updated or inserted in a relation. – Other privileges (SELECT, DELETE) are not attribute specific. 4. Query Modification  GRANT SELECT(NAME) ON Student TO Blue WHERE COURSE=“ITBP 17016”  Blue’s query: SELECT * FROM Student  Modified query: SELECT NAME FROM Student WHERE COURSE=“ITPB 320” 35 DAC Overview  Advantages: Intuitive  Easy to implement   Disadvantages: Maintenance of ACL or Capability lists  Maintenance of Grant/Revoke  Database Security - Farkas 36 Mandatory Access Control (MAC)  Security label -  Objects: security classification -  File 1 is Secret, File 2 is Public Subjects: security clearances -  Top-Secret, Secret, Public Brown is cleared to Secret, Black is cleared to Public Dominance ( ) - Top-Secret  Secret Public 37 MAC  Access rights: defined by comparing the security classification of the requested objects with the security clearance of the subject  If access control rules are satisfied, access is permitted, Otherwise access is rejected  Granularity of access rights 38 MAC – Bell-LaPadula (BLP) Model  Single security property: a subject S is allowed a read access to an object O only if label(S) dominates label(O)  Star-property: a subject S is allowed a write access to an object O only if label(O) dominates label(S) 39 Role-Based Access Control • Role-based access control (RBAC) emerged rapidly in the 1990s as a proven technology for managing and enforcing security in large-scale enterprisewide systems. • Its basic notion is that permissions are associated with roles, and users are assigned to appropriate roles. • Roles can be created using the CREATE ROLE and DESTROY ROLE commands. – The GRANT and REVOKE commands discussed under DAC can then be used to Role-Based AC Individuals Roles Resources Role 1 Server 1 Role 2 Server 2 Role 3 User’s change frequently, Roles don’t Server 3 Background: Role Based Access Control • Non-role-based systems Users: Permissions: Alice DB2 Account Bob Carl WebSphere Account Dave Windows Account Eva Linux Account • Role-Based Access Control Systems (RBAC) Users: Roles: Permissions: Alice DB Admin DB2 Account Bob Carl Web Admin WebSphere Account 42 Dave Eva Software Developer Windows Account Linux Account Role-Based Access Control file system operations: read, write and execute DBMS operations: Insert, delete, append and update Permission Assignment (PA) User Assignment (UA) USERS ROLES OPS OBS PRMS user_sessio n session_role s SESSIONS User is associated with a session Gives roles activated by the session many-to-many relationship one-to-many relationship Role-Based Access Control (2) • RBAC appears to be a viable alternative to traditional discretionary and mandatory access controls; it ensures that only authorized users are given access to certain data or resources. • Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles. • Role hierarchy in RBAC is a natural way Role-Based Access Control (3) • Another important consideration in RBAC systems is the possible temporal constraints that may exist on roles, such as time and duration of role activations, and timed triggering of a role by an activation of another role. • Using an RBAC model is highly desirable goal for addressing the key security requirements of Web-based applications. • In contrast, discretionary access control (DAC) and mandatory access control (MAC) models lack capabilities needed to support the security requirements emerging enterprises and Web-based applications. Role-Based AC (RBAC) • A user has access to an object based on the assigned role. • Roles are defined based on job functions. • Permissions are defined based on job authority and responsibilities within a job function. • Operations on an object are invocated based on the permissions. • The object is concerned with the user’s role and not the user. Why Roles? • Fewer relationships to manage – possibly from O(mn) to O(m+n), where m is the number of users and n is the number of permissions • Organizations operate based on roles • A role may be more stable than – the collection of users and the collection of permissions that are associated with it • Revocation/change of permissions become easier 47 ROLE-BASED ACCESS CONTROL (RBAC) • Motivating Problem: how to administer user-permission relation – Different from DAC and MAC, which deal with processes in operating systems • Roles as a level of indirection – Butler Lampson or David Wheeler: "all problems in Computer Science can be solved by another level of indirection" • RBAC is multi-faceted and open ended – Extensions: ARBAC (administrative), CBRAC (constraint), dRBAC (dynamic), ERBAC (enterprise), fRBAC (flexible), GRBAC (generalized), HRBAC (hierarchical), IRBAC (interoperability), JRBAC (Java), LRBAC (Location), MRBAC (Management), PRBAC (privacy), QRBAC (QoS), RRBAC(Rule), SRBAC(Spatial), TRBAC (temporal), V, W, x. 48 Where is RBAC used • RBAC is currently used in – Database management systems – Security management and network operating system – • !! Solaris 8 !! Uses RBAC – http://www.securityfocus.com/infocus/1391 • Now official standard – approved on Feb. 19 2004 50 Terms and Definitions • Component – refers to one of the major blocks of RBAC features, core RBAC, hierarchical RBAC, Static Separation of Duty (SSD) relations, and Dynamic Separation of Duty (DSD) relations. • Objects – object can be any system resource subject to access control, such as a file, printer, terminal, database record, etc. • Operations - An operation is an executable image of a program, which upon invocation executes some function for the user. • Permissions - Permission is an approval to perform an operation on one or more RBAC protected objects. • Role - A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. • User - A user is defined as a human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this document for simplicity reasons. USERS Process Process Person Intelligent Agent ROLES An organizational job function with a clear definition of inherent responsibility and authority (permissions). Developer Budget Manager Help Desk Representative Director Relation between USERS & PRMS OPERATIONS An execution of an a program specific function that’s invocated by a user.     Database – Update Insert Append Delete Locks – Open Close Reports – Create View Print Applications - Read Write Execute SQL OBJECTS An entity that contains or receives information, or has exhaustible system resources. • • • • • OS Files or Directories DB Columns, Rows, Tables, or Views Printer Disk Space Lock Mechanisms RBAC will deal with all the objects listed in the permissions assigned to roles. Role-Based Access Control Users • The complexity of administration is reduced through – Assigning users to roles – Assigning permissions to roles – Organising roles into a hierarchy Roles Procedures + Types = Permissions Objects Privilege • Roles are engineered based on the principle of least privileged. • A role contains the minimum amount permissions to instantiate an object. of • A user is assigned to a role that allows him or her to perform only what’s required for that role. • No single role is given more permission the same role for another user. than Permission Assignments Mapping of permissions to objects PRMS set Objects Open Close Gives the set of objects associated with the prms BLD1.door2 View Update Append Create Drop SQL DB1.table1 SESSIONS The mapping of user u onto a set of sessions. USERS SESSION est u g User2.FIN1.report1.session USER1 es ok v in admin user SQL User2.DB1.table1.session USER2 User2.APP1.desktop.session SESSIONS SESSION SQL DB1.table1.session ROLES • Admin • User • Guest SESSIONS Permissions available to a user in a session. ROLE PRMS • • • • • DB1.ADMIN View Update Append Create Drop SESSION SQL DB1.table1.session RBAC Framework model • RBAC Framework model components – Core RBAC • introduces the concept of role activation as part of a user’s session within a computer system. • required in any RBAC system, but the other components are independent of each other and may be implemented separately. – Hierarchical RBAC • relations for supporting role hierarchies (inheritance among roles) – Static Separation of Duty Relations • adds exclusivity relations among roles w.r.t. user assignments • potential for inconsistencies w.r.t. static separation of duty relations and inheritance relations of a role hierarchy • defines relations in both the presence and absence of role hierarchies. – Dynamic Separation of Duty Relations • exclusivity relations w.r.t. roles that are activated as part of a user’s session. RBAC96 FAMILY OF MODELS (Sandhu et al.) RBAC3 ROLE HIERARCHIES + CONSTRAINTS RBAC1 ROLE HIERARCHIES RBAC2 CONSTRAINTS RBAC0 BASIC RBAC CS526 63 Topic 22: RBAC RBAC0 USER-ROLE ASSIGNMENT USERS PERMISSION-ROLE ASSIGNMENT ROLES ... SESSIONS 64 PERMISSIONS RBAC0: Formal Model • Vocabulary: U, R, P, S (users, roles, permissions, and sessions) • Static relations: – PA P × R (permission assignment) – UA U × R (user assignment) • Dynamic relations: – user: S Ueach session has one user – roles: S 2R and some activated roles • requires roles(s) { r | (user(s), r) UA } Session s has permissions  r roles(s) { p | (p, r) PA } 65 Hierarchical RBAC Role Hierarchy (PA) USERS (UA) User Assignment Permission Assignment ROLES OPERA TIONS OBJECTS privileges user_sessions Sessions session_roles • Role/role relation defining user membership and privilege inheritance • Reflects organizational structures and functional delineations • Two types of hierarchies: – - Limited hierarchies – HIERARCHICAL ROLES (ex 1) Primary-Care Physician Specialist Physician Physician Health-Care Provider 67 HIERARCHICAL ROLES (ex 2) Supervising Engineer Hardware Engineer Software Engineer Engineer 68 Semantics of Role Hierarchies • User inheritance – r1 r2 means every user that is a member of r1 is also a member of r2 Physician • Permission inheritance – r1 r2 means every permission that is authorized for r2 is also authorized r1 Health-Care Provider • Activation inheritance – r1 r2 means that activating r1 willand also activate r2 Permission Activation inheritance have different effect when there are constraints about activation. 69 RBAC1: Formal Model • U, R, P, S, PA, UA, and user unchanged from RBAC0 • RH R × R : a partial order on R, written as  – When r1 r2, we say r1 is a senior than r2, and r2 is a junior than r1 • roles: S 2R – requires roles(s) { r | r’ [(r’ r) & (user(s), r’) UA] } Session s includes permissions { p | r’’ [(r r’’) & (p, r’’) PA] } 70  r roles(s) RBAC2: RBAC0 + Constraints • No formal model specified • Example constraints – Mutual exclusion – Pre-condition: Must satisfy some condition to be member of some role • E.g., a user must be an undergrad student before being assigned the UTA role – Cardinality 71 References • Role Based Access Control– Draft & Presentation on RBAC standard by Wilfredo Alvarez available at http://csrc.nist.gov/rbac/ • Modeling Role-Based Access Control Using Parameterized UML Models -- Dae-Kyoo Kim, Indrakshi Ray, Robert France, Na Li • Thank you for your attention 73