ORACLE LABEL SECURITY Evgeniya Kotzeva VEREO Technologies
Content 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database
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:
Security Policies Rules Data Integrity Rules To ensure that information in the system is consistent Availability Rules To 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.
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:
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
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.
Contents 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database
Oracle Label Security Architecture
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
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.
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 Oracle database or context variables provided by Oracle, such as user name or IP address.
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.
Virtual Private Database Technology
Virtual Private Database Technology • VPD permits access security mechanisms to be removed from applications • VPD is centralized access security mechanisms within Oracle.
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.
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 P 1
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
Virtual Private Database Technology 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
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.
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.
Oracle Label Security Functionality
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
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
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
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.
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.
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
Label Components Levels A single specification of the labeled data's sensitivity within the ordered ranks Established CONFIDENTIAL (1), SENSITIVE (2), HIGHLY SENSITIVE (3)
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.
Label Components
Label Components Label syntax LEVEL: COMPARTMENT 1, . . . , COMPARTMENTn: GROUP 1, . . . , GROUPn Examples: SENSITIVE: FINANCIAL, CHEMICAL: EASTERN_REGION, WESTERN_REGION CONFIDENTIAL: FINANCIAL: VP_GRP SENSITIVE HIGHLY_SENSITIVE: FINANCIAL SENSITIVE: : WESTERN_REGION
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
User access
User, labels and data
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.
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.
Rules for Reading Secured Data
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.
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.
Rules for Writing Secured Data
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
Administration Installation
Administration Configuration in existing database
Administration Setting Up Authorized Levels
Administration Setting Up Authorized Compartments
Contents 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database
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
Oracle 10 g 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
Contents 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database
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.
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
Contents 1. Overview 2. Oracle Label Security Architecture 3. OLS implementation 4. Advantages 5. Label Based Access Control vs. Virtual Private Database
Label Based Access Control vs. Virtual Private Database Criteria Set up Virtual Private Database Oracle Label security - Create a security context to - Create OLS security policies manage application sessions - Create security Levels - Create a procedure or function to - Create security Compartments manage setting of the security - Create security Groups context for users - Create data labels - Write a package to generate the - Create labels for hierarchy (security dynamic access predicates for Level plus Groups) access to each table - Apply security policy labels to Users - Register the policy function / - Apply security policy to appropriate package with Oracle using the tables DBMS_RLS package - Authorize privileges for the schema - Automate the setting of the to maintain data contained within all its security context - DB logon trigger owned objects - Apply appropriate security labels to data stored within tables for which the USER security policy has been applied
Label Based Access Control vs. Virtual Private Database Criteria Virtual Private Database Oracle Label security Physical database model No changes Will 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 Create new labels procedures and Update old data to appropriate new labels function (if necessary) Explain plan Filter based on No indication predicate GUI for manage and view No Oracle Policy manager Oracle version 8 i, 9 i, 10 g
Скачать презентацию ORACLE LABEL SECURITY Evgeniya Kotzeva VEREO Technologies
12be8b190d10cb858b7694ae11784a85.ppt