Oracle Database Vault provides controls to prevent unauthorized privileged users from accessing sensitive data and to prevent unauthorized database changes.

• About Oracle Database Vault
  The Oracle Database Vault security controls protect application data from unauthorized access, and comply with privacy and regulatory requirements.
• Controls for Privileged Accounts
  Privileged database accounts are one of the most commonly used pathways for gaining access to sensitive applications data in the database.
• Controls for Database Configuration
  Common audit findings are unauthorized changes to database entitlements and grants of the DBA role to too many users.
• Enterprise Applications Protection Policies
  Application-specific Oracle Database Vault protection policies and guidelines are available for major enterprise applications.

Oracle Database Vault provides database roles that enable different users to perform specific tasks, based on separation-of-duty guidelines.

The most commonly used roles are as follows:

• DV_OWNER and DV_ADMIN enable you to create and manage Database Vault policies.

• DV_ACCTMGR enables you to manage user accounts.

When you register Oracle Database Vault, the DV_OWNER role is granted to a user who must exist before you begin the configuration process, and the DV_ACCTMGR role is granted to a second, optional user, who must also exist before configuration. You can grant the Database Vault roles to other users, but ensure that these users are trusted.

During the registration process, you must create backup accounts for the DV_OWNER and DV_ACCTMGR users. As a best practice, Oracle strongly recommends that you keep and maintain these backup accounts.

Oracle Database Vault has a set of components that include PL/SQL packages and other special tools.

• Oracle Database Vault Access Control Components
  Oracle Database Vault enables you to create a set of components to manage security for your database instance.
• Oracle Database Vault DVSYS and DVF Schemas
  Oracle Database Vault database objects and public functions are stored in the DVSYS and DVF schemas, respectively.
• Oracle Database Vault PL/SQL Interfaces and Packages
  Oracle Database Vault provides PL/SQL interfaces and packages for security managers or application developers to configure access control policies.
• Oracle Database Vault Reporting and Monitoring Tools
  You can generate reports on the various activities that Oracle Database Vault monitors.
• Oracle Enterprise Manager Cloud Control Database Vault Administrator Pages
  Oracle Database Vault is pre-installed by default and can be enabled easily.

One of the biggest side benefits resulting from regulatory compliance has been security awareness.

Historically, the focus of the information technology (IT) department has been on high availability and performance. The focus on regulatory compliance has required everyone to take a step back and look at their IT infrastructure, databases, and applications from a security angle. Common questions include:

• Where is the sensitive information stored?

• Who has access to this information?

Regulations such as the Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act (HIPAA), International Convergence of Capital Measurement and Capital Standards: a Revised Framework (Basel II), Japan Privacy Law, Payment Card Industry Data Security Standard (PCI DSS), and the European Union Directive on Privacy and Electronic Communications have common themes that include internal controls, separation of duty, and access control.

While most changes required by regulations such as Sarbanes-Oxley and HIPAA are procedural in nature, the remainder may require technology investments. A common security requirement found in regulations is stringent internal controls. The degree to which Oracle Database Vault helps an organization achieve compliance varies with the regulation. In general, Oracle Database Vault realms, command rules, factors and separation of duty features, help reduce the overall security risks that regulation provisions worldwide address.

Table 1-1 lists regulations that address potential security threats.

Many security breaches, both external and internal, target privileged users database accounts to steal data from databases.

Oracle Database Vault protects against compromised privilege user account attacks by using realms, factors, and command rules. Combined, these provide powerful security tools to help secure access to databases, applications, and sensitive information. You can combine rules and factors to control the conditions under which commands in the database are allowed to execute, and to control access to data protected by a realm. For example, you can create rules and factors to control access to data based on IP addresses, the time of day, and specific programs. These can limit access to only those connections that pass these conditions. This can prevent unauthorized access to application data and access to the database by unauthorized applications.

Oracle Database Vault provides built-in factors that you can use in combination with rules to control access to the database, realm-protected applications, and commands within the database.

You can associate rules and factors with many SQL statements in the database to provide stronger internal controls within the database. You can customize these to meet the operational policies for your site. For example, you could define a rule to limit execution of the ALTER SYSTEM statement to a specific IP address and host name.

Oracle Database Vault helps you design flexible security policies for your database.

For example, any database user who has the DBA role can make modifications to basic parameters in a database. Suppose an inexperienced administrator who has system privileges decides to start a new redo log file but does not realize that doing so at a particular time may cause problems for the database. With Oracle Database Vault, you can create a command rule to prevent this user from making such modifications by limiting his or her usage of the ALTER SYSTEM SWITCH LOGFILE statement. Furthermore, you can attach rule sets to the command rule to restrict activity further, such as limiting the statement's execution in the following ways:

• By time (for example, only during 4 p.m. and 5 p.m. on Friday afternoons)

• By local access only, that is, not remotely

• By IP address (for example, allowing the action to only a specified range of IP addresses)

You can customize Oracle Database Vault separation of duties to fit the requirements of business of any size. For example, large customers with dedicated IT staff and some out sourced back end operations can further fine tune separation of duties to control what out sourced database administrators can do. For smaller organizations with some users handling multiple responsibilities, separation of duties can be tuned down and these users can create separate dedicated accounts for each responsibility. This helps such users keep track of all actions made and prevents intruders from exploiting compromised privileged database accounts to steal sensitive data. In addition, it helps auditors verify compliance.

Consolidation and cloud environments reduce cost but can expose sensitive application data to those without a true need-to-know.

Data from one country may be hosted in an entirely different country, but access to that data must be restricted based on regulations of the country to which the data belongs. Oracle Database Vault controls provide increased security for these environments by preventing database administrators from accessing the applications data. In addition, controls can be used to help block application bypass and enforce a trusted-path from the application tier to the application data.

Oracle Database Vault provides four distinct separation of duty controls for security administration:

• Day-to-day database administrator tasks using the default Oracle Database DBA role

• Security administrator tasks using the DV_OWNER and DV_ADMIN roles

• Account administrator tasks using the DV_ACCTMGR role

• Grants of roles and privileges by a named trusted user

Oracle Database Vault separation of duty controls can be customized and organizations with limited resources can assign multiple Oracle Database Vault responsibilities to the same administrator, but using separate accounts for each separation-of-duty role to minimize damage to the database if any one account is stolen and leveraged.

Oracle customers today still have hundreds and even thousands of databases distributed throughout the enterprise and around the world. However, for database consolidation as a cost-saving strategy in the coming years to be effective, the physical security provided by the distributed database architecture must be available in the consolidated environment. Oracle Database Vault addresses the primary security concerns of database consolidation.

Figure 1-2 illustrates how Oracle Database Vault addresses the following database security concerns:

• Administrative privileged account access to application data: In this case, Oracle Database Vault prevents the database administrator from accessing the schemas that are protected by the Finance realm. Although the database administrator is the most powerful and trusted user, this administrator does not need access to application data residing within the database.

• Separation of duties for application data access: In this case, the HR realm owner, created in Oracle Database Vault, has access to the HR realm schemas.

Database consolidation can result in multiple powerful user accounts residing in a single database. This means that in addition to the overall database administrator, individual application schema owners also may have powerful privileges. Revoking some privileges may adversely affect existing applications. Using Oracle Database Vault realms, you can enforce access to applications through a trusted path, preventing database users who have not been specifically authorized access from using powerful privileges to look at other application data. For example, a database administrator who has the SELECT ANY TABLE system privilege can be prevented from using that privilege to view other application data residing in the same database.

Using Oracle Database Vault in a multitenant environment increases security for consolidation.

Oracle Database Vault can prevent privileged user access inside a pluggable database (PDB) and between the PDB and the common privileged user at the container database. Each PDB has its own Database Vault metadata, such as realms, rule sets, command rules, default policies (such as default realms), and so on. In addition, the objects within the DVSYS and DVF schemas are automatically available to any child PDBs. Both schemas are common user schemas.

You can configure common realms in the application root only, but you can create common rule sets and command rules in either the application root or the CDB root. A common command rule in the application root applies to its associated PDBs, and common command rules in the CDB root apply to all PDBs in the CDB environment. The ability to create common realms and command rules enables you to create policies that use a shared set of realms, rule sets, or command rules throughout the CDB environments, rather than having to create these same components for every PDB in the multitenant environment.

You can create individual local policies for each PDB. When you use Database Vault to protect an object, Database Vault subjects common privileges for common objects to the same enforcement rules as local system privileges.

When you configure a PDB that has Database Vault enabled, the DVSYS schema is a common user schema that is stored in the root. This means that all the objects within the DVSYS schema (tables, data dictionary views, user accounts, PL/SQL packages, default policies, and so on) are subject to the common privileges available for this schema. In other words, you can create realms, factors, and so on in the root to protect the schema in the root. Ensure that you configure Database Vault in the root first, before you configure it in the associated PDBs.

When you enable Oracle Database Vault in the CDB root, you can choose either regular mode or strict mode. The settings propagate throughout the CDB based on the setting you choose. For example, suppose a CDB contains both Database Vault-enabled PDBs and PDBs in which Database Vault is not enabled. If you enable Database Vault using regular mode, then both types of PDBs continue to function normally. If you enable Database Vault using strict mode, then the Database Vault-disabled PDBs operate in restricted mode. If you want to run DBMS_MACADM.ENABLE_DV in an application container, then you must run it in the application container outside of application actions.

Figure 1-3 illustrates how the database in regular mode allows different access for common and local database administrators depending if Database Vault is enabled. In this scenario, neither the common user nor the local users have access to the realms in PDB1 and PDB2. Both the common user and the PDB3 local user have access to the Custom App application in PDB3, where Database Vault is not enabled.