ORACLE LABEL SECURITY

1. ORACLE LABEL SECURITY Evgeniya Kotzeva VEREO Technologies

2. Content • Overview • Oracle Label Security Architecture • OLS implementation • Advantages • Label Based Access Control vs. • Virtual Private Database

3. Overview Security Policies A database security policy implements an overall system security policy within a broad, organizational security policy. The overall security policy can enforce the following types of rules:

4. Security Policies Rules

5. Access Control Access controldefines a user's ability to read, write, update, insert, or delete information. The following approaches are available to meet access control needs:

6. Access Control • Discretionary Access Control (DAC) • provides on each table • controlling access to information through privileges • (SELECT, INSERT, UPDATE, and DELETE) • controls access to data in a one-dimensional, binary way

7. Access Control • Oracle Label Security • Enable sophisticated access control rules • Add a new column to each data row (will store the label reflecting each row's sensitivity within that policy) • Enable discretionary access control by using data in the row • Level access is determined by comparing the user's identity and label with that of the row • Oracle Label Security access control depends first on the basic DAC policy.

8. Contents • Overview • Oracle Label Security Architecture • OLS implementation • Advantages • Label Based Access Control vs. • Virtual Private Database

9. Oracle Label Security Architecture

10. Virtual Private Database Technology • Virtual Private Database Technology is the access control to data rows • VPD has several other names within the Oracle documentation: • row-level security (RLS) • fine-grained access control (FGAC)

11. Virtual Private Database Technology

12. Virtual Private Database Technology • VPD • supports policy-driven access control VPD policies enforce object-level access control or row-level security • provides an application program interface (API) that allows security policies to be assigned to database tables and views.

13. Virtual Private Database Technology • VPD implementation • Security policies are created with stored procedures. • These procedures can be bound to a table or view by means of a call to an RDBMS package. • Security policies restrict access by using the content of application data stored in the Oracledatabase or context variables provided by Oracle, such as user name or IP address.

14. Virtual Private Database Technology • Data access via Virtual Private Database will perform the following five steps: • User sends SQL to the database server. • The associated table triggers a pre-defined security policy. • The security policy returns a predicate. • The SQL statement is modified according to the security policy. • Secured data returns to user.

15. Virtual Private Database Technology

16. Virtual Private Database Technology • VPD permits access security mechanisms to be removed from applications • VPD is centralized access security mechanismswithin Oracle.

17. Virtual Private Database Technology • At runtime, Oracle performs these near magical feats by dynamically modifying the SQL statement of the end user: • Oracle gathers application context information at user logon time and then calls the policy function, which returns a predicate. A predicate is a where clause that qualifies a particular set of rows within the table. • Oracle dynamically rewrites the query by appending the predicate to users' SQL statements.

18. Virtual Private Database Technology Whenever a query is run against the target tables, Oracle invokes the policy and produces a transient view with a where clause predicate pasted onto the end of the query User’s statement SELECT * FROM book Execution statement SELECT * FROM book WHERE P1

19. Virtual Private Database Technology A VPD security model uses the Oracle dbms_rls package (RLS stands for row-level security) to implement the security policies and application contexts. This requires a policy that is defined to control access to tables and rows

20. Virtual Private Database Technology • Application contextApplication context can be used to store details about the authority of the user like: • application name • the user's name • specific row restriction information • Application context can be set by calling dbms_session.set_context. • Application context can be set at: • sign-on (user’s logon) by database trigger • any time by calling dbms_session package

21. Oracle Label Security Functionality A Label Security administrator defines a set of labels for data and users, along with authorizations for users and program units, that govern access to specified protected objects. A policy is nothing more than a name associated with these labels, rules, and authorizations.

22. Oracle Label Security Functionality When the user executes a SELECT statement, Oracle Label Security evaluates each row selected to determine whether the user can access it. The decision is based on the privileges and access labels assigned to the user by the security administrator. Oracle Label Security can also be configured to perform security checks on UPDATE, DELETE, and INSERT statements.

23. Oracle Label Security Functionality

24. Access Mediation in Oracle Label Security Access mediation is the collection of methods that OLS uses to determine if a user's session has sufficient access to a row in either read or write mode. Row domination is the key to understanding access mediation. Simply put, when a user's session has been granted sufficient access to perform the read or write activity against the row, it is said to dominate a row

25. Access Mediation Factors in Oracle Label Security • The label of the data row to which access is requested • The label of the user session requesting access • The policy privileges for that user session • The policy enforcement options established for that table

26. Oracle Label Security dimensions • Data Labels • Rows of data are labeled to indicate the level and nature of their sensitivity. A label on a row of data specifies the sensitivity of the information in the row and explicitly defines the criteria that must be met for a user to access that row. • Each row of a table can be labeled as to its level of confidentiality. • Every label contains three components: • a single level (sensitivity) ranking • zero or more horizontal compartments • zero or more hierarchical groups

27. Oracle Label Security dimensions User Labels Users are assigned a range of levels, compartments, and groups which indicate their label authorizations. A label assigned to a user determines the user’s access to labeled data. Policy Privileges Certain users may be given rights to perform special operations, and to access data beyond their label authorizations.

28. Oracle Label Security dimensions Policy Enforcement Options In Oracle Label Security you can apply different enforcement options for maximum flexibility in controlling the different Data Manipulation Language operations that users can perform. For each operation (SELECT, INSERT, UPDATE, and DELETE) you can specify a particular type of enforcement of the security policy for each table. In this way you can customize the label-based access controls on each table.

29. Oracle Label Security dimensions When a database table is protected by an Oracle Label Security policy, a column is added to the table. This policy label column contains the label information for each data row. The administrator can choose to display or hide this column

30. Label Components Levels A single specification of the labeled data's sensitivity within the ordered ranks Established CONFIDENTIAL (1), SENSITIVE (2), HIGHLY SENSITIVE (3)

31. Label Components Compartments Zero or more categories associated with the labeled data, Compartments identify areas that describe the sensitivity of the labeled data, providing a finer level of granularity within a level. FINANCIAL, CHEMICAL, OPERATIONAL Groups Zero or more identifiers for organizations owning or accessing the data. Groups are hierarchical: you can label data based upon your organizational infrastructure. A group can thus be associated with a parent group.

32. Label Components

33. Label Components Label syntax LEVEL:COMPARTMENT1,...,COMPARTMENTn:GROUP1,...,GROUPn Examples: SENSITIVE:FINANCIAL,CHEMICAL:EASTERN_REGION,WESTERN_REGION CONFIDENTIAL:FINANCIAL:VP_GRP SENSITIVE HIGHLY_SENSITIVE:FINANCIAL SENSITIVE::WESTERN_REGION

34. User access • A user can only access data within the range of his or her own label authorizations. A user has: • maximum and minimum levels • a set of authorized compartments • a set of authorized groups (and, implicitly, authorization for any subgroups) • a specification of read-only access (or read/write) accessfor each compartment and group

35. User access

36. User, labels and data

37. Rules for Reading Secured Data • When a user submits a query to be parsed for read access, OLS compares the policy label permissions granted to the user's session versus the data label on the target rows based on the following rules: • The user's session levelmust be greater than or equal to the row's level • The user's session group must contain at least one group with read access specified in the row's data label • The user's sessioncompartments must contain all the compartments listed in the row label's compartments.

38. Rules for Reading Secured Data OLS concept reading down When a user session has been granted security levelpermissions, the session cannot read any data above the level The session can read all data at that level and below. Note: If a data label is NULL, or if it is otherwise invalid, OLS will deny access to the row because the user's session cannot dominate the row.

39. Rules for Reading Secured Data

40. Rules for Writing Secured Data • Write access (i.e. INSERT, UPDATE, DELETE, or MERGE • The set of rules that are interrogated insure that a user session cannot write to a row that is outside of the session's permissible security levellimits, groups and compartments: • The row's level must be greater than or equal to the user's minimum level • Тhe row's level must be less than or equal to the user's session level • The user's session labels' group must contain at least one group with write access specified in the row's data label.

41. Rules for Writing Secured Data • The compartments specified in the user's session labels must contain all the compartments in the data label. If no groups are present in the data label, the user must have write access on allcompartments in the data label. • Result of rules • The user cannot write data that is below the user's minimumwrite level • The user cannot write data that is above the user's current session level.

42. Rules for Writing Secured Data

43. Summary • Oracle Label Security provides four aspects of label-based access • control: • A user's label indicates the information that a user is permitted to access, and determines the type of access (read or write) the user is allowed to perform. • A row's label indicates the sensitivity of the information that the row contains, and can also indicate its ownership and its affiliation with similar data. • A user's policy privileges can enable bypassing some aspects of a label-based access control policy. • A table's policy enforcement options determine various aspects of how access controls are enforced for read and write operations

44. Administration Installation

45. Administration Configuration in existing database

46. Administration Setting Up Authorized Levels

47. Administration Setting Up Authorized Compartments

48. Contents • Overview • Oracle Label Security Architecture • OLS implementation • Advantages • Label Based Access Control vs. • Virtual Private Database

49. OLS Implementation Step 1: Create OLS security policies SA_SYSDBA.CREATE_POLICY Step 2: Create security Levels SA_COMPONENTS.CREATE_LEVEL Step 3: Create security Compartments SA_COMPONENTS.CREATE_COMPARTMENT Step 4: Create security Groups SA_COMPONENTS.CREATE_GROUP Step 5: Create data labels SA_LABEL_ADMIN.CREATE_LABEL Step 6 Apply security policy labels to Users SA_USER_ADMIN.SET_USER_LABELS Step 7: Apply Administration security policy to appropriate tables SA_POLICY_ADMIN.APPLY_TABLE_POLICY Step 8: Authorize privileges for the administration schema to maintain data contained within all its owned objects SA_USER_ADMIN.SET_USER_PRIVS Step 9: Apply appropriate security labels to data stored within tables for which the SADM security policy has been applied UPDATE statement

50. Oracle 10g features Column-Level VPD - Virtual Private Database (VPD) is now finer grained. You are now able to enforce VPD rewrite when a query references a particular column VPD Static and Dynamic Policies - Virtual Private Database (VPD) now lets you distinguish between static policies, which are suitable for hosting environments that always need to enforce an unchanging policy, and dynamic policies, which are suitable for time-dependent enforcement, such as time of day, where rows returned must vary at a particular time Fine-Grained Auditing (FGA) on DML - Fine-Grained Auditing (FGA) extends the support to include UPDATE, INSERT, and DELETE statements