Oracle Database Vault Concepts and Overview
Oracle Database Vault enables organizations to transparently increase security without making changes to their application code. Oracle Database Vault provides real-time preventive controls by restricting access to application data from highly privileged users. Oracle Database Vault helps organizations address regulatory compliance, industrial espionage, and insider threats while at the same time enabling the flexibility to deploy IT systems in a cost-effective manner through consolidation and or offshoring.
Once Oracle Database Vault is installed you can protect your business data by creating a realm that encompasses all database objects comprising your business application in a matter of minutes. Once the application’s database objects are protected, you can authorize selected users to access it. You can do this using either the Database Vault Administration web interface (DVA) or the Database Vault Application Programming Interface (API).
Oracle Database Vault provides separation of duty controls and protects the database from unauthorized changes. Oracle Database Vault will block a DBA with the CREATE USER privilege from creating a new user if the DBA doesn’t have the proper user administration role. In addition, command rules can be defined for all SQL commands to provide control over the command execution.
Oracle Database Vault Factors and Rules can be used to significantly tighten application security by limiting who, when, where and how an application is accessed. These features can be used in a flexible and adaptable manner to enforce authorization requirements, without requiring changes to the existing applications. Factors such as time of day, database client’s location on a network, or custom factors specific to the enterprise can control the ability to access the application.
Access Control Components
The following components of Database Vault provide highly configurable access control:
- Realms: A boundary defined around a set of objects in a schema, a whole schema, multiple schemas, or database roles. Specific conditions must be met to gain access.
- Rule sets: A collection of rules that are evaluated for the purpose of granting access.
- Command rules: A set of specific conditions that must be in effect for a given SQL command to be executed on a given object or set of objects. This provides very granular control over what can be done to certain objects and by whom.
- Secure application roles: A role that can be enabeled by a session only under the condition of passing a rule set.
- Factors: Attributes of a user or the system at any given time. Factors contribute to the decision process of granting access, and combinations of several factors may be considered at once. This is multifactored authorization. Identities are specific values that the factors may take on. Of the possible set of values for a given factor, some or all may have been assigned a name, which is an identity.
What Is a Realm?
– A realm is a functional grouping of database schemas and roles that must be secured for a given application. Think of a realm as a zone of protection for your database objects. Realms contain objects such as tables, roles, and packages.
– A realm may also have authorizations given to users or roles as participants or owners. A realm protects the objects in it from users exercising privileges, such as SELECT ANY TABLE and SYSDBA. Therefore, any such privileged user must be defined as a realm participant (or have a realm-participating role that is granted to him or her) to access the protected objects.
– If a user or role already has direct object privileges granted to access the realm-protected objects, the realm has no effect. These users or roles with direct object privileges can access the objects in the same manner as before the realm existed.
What Is a Rule Set?
A rule set is a collection of rules that are evaluated together to produce a result. Each rule is defined as a WHERE clause expression. The rule set specifies whether the results of the rules are to be ANDed or ORed together. After each rule is evaluated, the results are ANDed or ORed together, and the end result is a single value of TRUE or FALSE. Database Vault provides a rule engine to process rule sets.
You can use a rule set to provide dual key security, whereby another separate action must take place for the requested access to be granted. An example is requiring a specific user to be logged in from a specific client machine in order for another user to have access to certain data or packages.
What Is a Command Rule?
A command rule defines the rules that must be followed to perform a SQL command on an object. These commands include most data definition language (DDL) commands, and also SELECT, UPDATE, and DELETE. You can implement a command rule to restrict specific commands from executing on specific objects or groups of objects. The restriction is based on the evaluation to TRUE of a rule set.
What Is a Secure Application Role?
Secure application roles are created to require specific conditions to be true before taking advantage of the permissions or privileges that are granted to the role. The conditions are represented as a single rule set. A secure application role consists entirely of a secure application role name and an associated rule set. Permissions granted to this role can be exercised only if the rule set evaluates to TRUE.
Secure application roles in Database Vault are different from those provided by the Oracle database. The secure application role is still enabled by a procedure in a secure package, but the package is provided by Database Vault. Instead of writing a procedure, the security administrator simply uses a rule set to determine whether an application role should be enabled.
What Is a Factor?
– A factor is a named variable or attribute, such as a user location, database IP address, or session user, that Database Vault can recognize.
– Each factor has a value assigned to it. This value is called an identity.
– Factors are combined in logical ways with other factors in rules and rule sets to provide the basis for access control policies. You can use factors for activities such as authorizing database accounts to connect to the database or creating filtering logic to restrict the visibility and manageability of data.
– You implement multifactored authorization by combining factors. The same concept is used when a customer representative you call on the phone asks for your name, billing address, and the last four digits of your social security number. Those are three factors that contribute to the authorization process.
Factors and Identities
An identity is a value for a factor. The identity of a factor can vary according to the session, application, user, or even the time of the day. Trust levels enable you to assign a numeric value to indicate the measure of trust allowed. A trust value of 1 signifies some trust. A higher value indicates a higher level of trust. A negative value or zero indicates distrust. When the factor identity returned from a factor retrieval method is not defined in the identity, Database Vault automatically assigns the identity a negative trust level.
For example, when a user connects through a machine in the office, the DOMAIN factor identity is set to INTRANET with a TRUSTED trust level. When the same user connects from home, the DOMAIN factor identity is set to INTERNET with an UNTRUSTED trust level. In this example, the DOMAIN factor can be used to determine what data the user is allowed to access and what commands the user is allowed to perform. You can assign Oracle Label Security (OLS) labels to factor identities. A label acts as an identifier for a database table row to assign privileges to the row. A factor can have an identity assigned by a combination of multiple factors. The identity of these factors can in turn be resolved by other factors. Using factors to resolve an identity is called identity mapping.
Component Relationships
The relationship between the Database Vault components is shown in the figure above. Based on the direction of the arrow, you can say that a given component type uses another component type. Realms, command rules, and secure application roles use rule sets to define their behavior. Factors use rule sets and rule sets can refer to factors in their definition. Factors use identities and identities can refer to other factors. Rather than creating “factors” or “identities,” you can simply reference USERENV variables of the SYS_CONTEXT function in the rule set associated to a command rule.
In the figure, the three components at the top are the ones that actually cause security to be enforced. The two components at the bottom of the slide support the enforcement. That is, you can create rule sets and factors with identities, but until you create a realm, a command rule, or a secure application role that refers to them, nothing changes about data access in your database.
Evaluation Sequence
When a session accesses data in Database Vault, it may or may not have to pass through security checks involving the Database Vault components. As shown in the slide, it may or may not require evaluation of any combination of realms or command rules. And if a realm is involved, there may or may not be a rule set defined that further modifies the access requirements. Both secure application roles and command rules must have a rule set defined for them.
The figure illustrates the dynamic data access paths. Before a command is executed, any secure application role checks have already been done, along with the associated rule set, when the role is requested to be enabled. Then when a statement is submitted, all objects are checked to see whether they are in a realm. Next, the command rules are checked to ensure that the particular command being issued is allowed. It is possible that at least one component of each type of component requires evaluation during the execution of a single statement. It is also possible that only a single realm or a single command rule is evaluated. Any permutation of these is possible.
Database Vault Example: Limiting Access to Table Content
This example shows how to prevent privileged users (DBA) from accessing sensitive application data. DBA users typically have the DBA role granted to them. This means that they have the SELECT ANY TABLE system privilege. In this example, a DBA is prevented from accessing a table, All rights reserved.even though the DBA continues to retain the SELECT ANY TABLE privilege.
1. The user with the DBA role is able to select data from the OE.ORDERS table.
SQL> SELECT order_total FROM oe.orders 2 WHERE customer_id = 101; ORDER_TOTAL ----------- 78279.6
2. The security manager protects the OE.ORDERS table with a Database Vault realm.
3. The DBA can no longer access the table.
SQL> SELECT order_total FROM oe.orders 2 WHERE customer_id = 101; SELECT order_total FROM oe.orders * ERROR at line 1: ORA-01031: insufficient privileges
Database Vault: Effects
- Just having the Database Vault option configured does not affect the functionality of the database in any way.
- Applications do not have to be changed and all queries work the same way as before the installation. Even when the Database Vault components are configured, there is no need to modify the applications. Database Vault provides the extra security without changes to applications or how SQL is submitted to the database.
- However, if the new security configurations are there to prevent access to data by an application, that application will be affected accordingly.
- Even if more complex security configurations are created, the performance will not be affected.
Database Vault API
Database Vault provides a schema, DVSYS, which stores the database objects needed to process Oracle data for Database Vault. This schema contains the roles, views, accounts, functions, and other database objects that Database Vault uses. The DVF schema contains public functions to retrieve (at run time) the factor values set in the Database Vault access control configuration.
Database Vault provides a collection of PL/SQL interfaces that enable security managers or application developers to configure the access control policy as required. The PL/SQL procedures and functions allow the general database account to operate within the boundaries of the access control policy in the context of a given database session.
The packages thatare provided include:
- Functions owned by DVF for returning information about factors
- DVSYS.DBMS_MACADM: Procedures for creating and managing Database Vault components
- DVSYS.DBMS_MACSEC_ROLES: Procedures for activating secure application roles
- DVSYS.DBMS_MACUTL: Utility procedures for interrogating various security-related characteristics of the database environment DVSYS CONFIGURE DV: Procedure to configure the initial two Oracle Database user
- DVSYS.CONFIGURE_DV: Procedure to configure the initial two Oracle Database user accounts, which are granted the DV_OWNER and DV_ACCTMGR roles.