1. ORACLE LABEL SECURITY Evgeniya Kotzeva VEREO Technologies

2. 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database Content

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 Data Integrity RulesTo ensure that information in the system is consistent Availability RulesTo ensure that information in the system is available Access Control Rules To prevent unauthorized disclosure of information Oracle Label Security provides a default policy for information access control, and also enables you to define other, more customized policies for use at any given site.

5. Access Control Access control defines 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. 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database Contents

9. Oracle Label Security Architecture

10. 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) Virtual Private Database Technology

12. 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. Virtual Private Database Technology

13. 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 Oracle database 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: 1.User sends SQL to the database server. 2.The associated table triggers a pre-defined security policy. 3.The security policy returns a predicate. 4.The SQL statement is modified according to the security policy. 5.Secured data returns to user.

15. Virtual Private Database Technology

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

17. 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. 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 Virtual Private Database Technology

19. 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 context Application 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 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) access for 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 level must 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 session compartments 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 level permissions, 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 level limits, 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 all compartments in the data label. Result of rules The user cannot write data that is below the user's minimum write 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. 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database Contents

49. 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 OLS Implementation

50. 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 Oracle 10g features

51. 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database Contents

52. Advantages Dynamic security — No need to maintain complex roles and grants. Multiple security — You can place more than one policy on each object, as well as stack them on other base policies. This makes VPD perfect for Web applications that are deployed for many companies. No back doors — Users no longer bypass security policies embedded in applications, because the security policy is attached to the data. Complex access rules may be defined — With VPD, you can use data values to specify complex access rules that would be difficult to create with grant security. You can easily restrict access to rows.

53. Disadvantages Hard to audit — It is hard to write an audit script that defines the exact access for each specified user. This problem becomes even more acute for shops that mix security methods

54. 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database Contents

55. Label Based Access Control vs. Virtual Private Database CriteriaVirtual Private DatabaseOracle Label security Set up - Create a security context to manage application sessions - Create a procedure or function to manage setting of the security context for users - Write a package to generate the dynamic access predicates for access to each table - Register the policy function / package with Oracle using the DBMS_RLS package - Automate the setting of the security context - DB logon trigger - Create OLS security policies - Create security Levels - Create security Compartments - Create security Groups - Create data labels - Create labels for hierarchy (security Level plus Groups) - Apply security policy labels to Users - Apply security policy to appropriate tables - Authorize privileges for the schema to maintain data contained within all its owned objects - Apply appropriate security labels to data stored within tables for which the USER security policy has been applied

56. Label Based Access Control vs. Virtual Private Database CriteriaVirtual Private Database Oracle Label security Physical database model No changesWill be added policy label column to each secure table Bitmap index on policy label column Change user privileges Dynamic, based on function Dynamic, based on the user labels Change administrative structure Change procedures and function Create new labels Update old data to appropriate new labels (if necessary) Explain planFilter based on predicate No indication GUI for manage and view NoOracle Policy manager Oracle version8i,9i, 10g9i,10g