D Oracle Database Vault Security Guidelines

How Oracle Database Vault Handles Separation of Duty

Separation of duty means that you restrict each user's privileges only to the tasks he or she is responsible for, and no more.

You should assign specific categories of privileges to specific users, rather than granting many privileges to one user. Simply put, separation of duty creates accountability for each task that your organization requires.

Separation of duty has taken on increased importance over the past 10 years. For many organizations, separation of duty is a new concept that continues to evolve. Database consolidation, regulatory compliance, and outsourcing are just a few of the drivers for increased separation of duty. Oracle Database Vault separation of duty strengthens security by separating security-related administration from day-to-day DBA operations. You can tailor your Database Vault separation of duty implementation to easily adapt to current and future business requirements. Small organizations, in particular, need flexibility as they attempt to increase their security profile with limited resources.

Separation of Tasks in an Oracle Database Vault Environment

Oracle Database Vault defines the several main responsibilities.

These responsibilities are as follows:

• Account management. Account management entails creating, modifying, and dropping user accounts. The DV_ACCTMGR role provides these privileges.

• Security administration. Security administration covers basic security tasks such as creating realms and command rules, setting security policies for database users' access, and authorizing database users for jobs they are allowed to perform. Security administrators also run security audit reports. The DV_OWNER and DV_ADMIN roles provide these privileges. (For an in-depth look at how the Oracle Database Vault roles provide for separation of duty, see "Oracle Database Vault Roles".)

  Optionally, you can consolidate the account management and security administrative responsibilities.

• Resource management. Resource management refers to managing the database system but not accessing business data. It includes the following operations:

  • Backup operations require a predefined time to perform the backup using predefined tools.

  • Tuning and monitoring operations require ongoing performance monitoring and analysis.

  • Patching operations require temporary access only during the time the patching takes place

  For resource management, you should create a named account and a backup account for each of these tasks. Use these accounts as the primary resource managers in the database.

You should have separate accounts for database account management, database security administration, and additional named accounts for backup operations. Auditors check for separate database accounts for different responsibilities and being able to track the actions of each account. Less important is the number of users assigned to specific tasks. Remember that Oracle Database Vault audit events are protected and that the Database Vault reports show all attempted violations.

Separation of Duty Matrix for Oracle Database Vault

Before separation of duty can be successful, you must understand who performs basic administration tasks in your environment and what these administration tasks are.

Even if a single database administrator is responsible for managing both new database account provisioning and application patching, it is important to document and plan for each of these tasks.Using separate administration accounts for these types of tasks provides increased accountability and reduces associated risks. In midsize to large organizations, database administrators typically must perform common administration tasks but they do not need access to business data managed by the application. Creating a matrix for your separation of duty can help you plan your Database Vault deployment. As needed, you can include additional tasks and associated users to this list. This information should become part of the overall enterprise security documentation for your organization.

Table D-1 shows an example of a separation of duty matrix.

In some cases, system management tasks may require temporary access to data through specific tools and programs. When this happens, build provisions for this temporary or emergency access into the Oracle Database Vault rules and rule sets.

Identification and Documentation of the Tasks of Users Who Access the Database System

You should document the areas of the tasks that your organization needs.

These areas are as follows:

• The responsibilities of each administrative user

• The kind of access users need. For example, application owners should have data access and developers need access to development instances only.

• Who must manage the system without accessing business data (for example, users who perform backup, patching, tuning, and monitoring operations)

• The duties of each category of tasks (for example, the files that must be backed up, the applications that require patching, what exactly is monitored). Include the alternate user accounts for each of these tasks.

• The databases and applications that must be protected. This includes Oracle applications, partner applications, and custom applications.

• Who must be authorized to access business data, including the following:

  • Application owners through middle tier processes

  • Business users through an application interface

• Emergency "what if" scenarios, such as how to handle a security breach

• Reporting in a production environment, which should include the following:

  • Who runs the reports

  • Which reports must be run

  • The frequency with which each report is run

  • The users who must receive a copy of each report

• In addition to a separation of duty matrix, the creation of the following matrices:

  • An Oracle Database Vault-specific matrix, which can cover the names and tasks of users who have been granted Database Vault roles

  • An application protection matrix, which can cover the applications to be protected and the types of protections you have put in place.

  Table D-2 shows an example of protections Oracle created for PeopleSoft Applications. SYSADM, PSFTDBA, SYSTEM, and DBA have all been authorized for the appropriate rule sets.

  Table D-2 Example Application Protection Maxtrix

  Protection Type	SYSADM	PSFTDBA	SYSTEM	DBA
  PeopleSoft Realm	Owner	Owner	No Access	No Access
  SELECT Command Rule	Not Restricted	Limit PSFTDB Rule Set	No Access	No Access
  CONNECT Command Rule	PeopleSoftAccess Rule Set	Not Restricted	Not Restricted	Not Restricted
  DROP TABLESPACE Command Rule	Disabled Rule Set	Disabled Rule Set	Disabled Rule Set	Disabled Rule Set

  
  

SYSTEM User Account for General Administrative Uses

If you use the SYSTEM account for general database administrative purposes, create named database administrative accounts for your database administrators.

Doing so increases accountability for administrative actions in the database.

SYSTEM Schema for Application Tables

If your site holds application tables in the SYSTEM schema, then you should add the SYSTEM account to your realm authorizations for these tables so that these applications can continue to work normally.

You can place restrictions on the SYSTEM account to increase or fine-tune security for these applications. For example, you can create a Database Vault rule set to restrict the SYSTEM user's access to specific IP addresses.

Limitation of the SYSDBA Administrative Privilege

You should limit the SYSDBA administrative privilege only to users who must connect using this privilege when absolutely necessary and for applications that still require SYSDBA access, such as mandatory patching processes. For all other cases, create named database accounts to perform daily database administration. Members of the OSDBA user group are also given the SYSDBA administrative privilege.

Root and Operating System Access to Oracle Database Vault

For better security, you should carefully monitor root and operating system access to Oracle Database. Vault.

Oracle Database Vault prevents highly privileged database users from accessing sensitive data. In addition, if you are using Oracle Database itself, then you can use Transparent Data Encryption to prevent the most highly privileged operating system users from accessing sensitive data. Transparent data encryption enables you to hide individual table columns. (See Oracle Database Advanced Security Guide for more information about Transparent Data Encryption.) As a best practice, always carefully review and restrict direct access to the operating system.

You should have personalized accounts access the operating system. These personalized accounts should, in the Linux or UNIX environments, login using sudo to the oracle software owner when needed. With sudo, you can control which specific command each personalized user can execute. Be sure to prevent the use of the make, relink, gdb, or other commands that could potentially harm the database, for these users. However, if an administrative user must install a patch or perform some other emergency operation, you can enable the make and relink commands for a limited time, and audit their actions during this period.

Management of Users with Root Access to the Operating System

Users who have root user access have full control over the system.

Activities that these users can perform include the following:

• Reading unencrypted files

• Moving and deleting any files

• Starting or stopping any program on the system

• Logging in as any user, including the user who owns the Oracle Database installation

Oracle Database Vault does not provide protection against the operating system root access. Ensure that you grant root user privileges only to the appropriate people with the appropriate responsibility.

Management of the Oracle Software Owner

Users who have access to a system as the Oracle software owner have control over the Oracle software.

Activities these users can perform include the following:

• Reading unencrypted database files

• Moving and deleting database files

• Starting or stopping Oracle programs in the system

Oracle Database Vault does not provide protection against the operating system access of the Oracle software owner. Ensure that you grant Oracle software owner access only to the appropriate people with the appropriate responsibility.

Management of SYSDBA Access

By default, Oracle Database limits SYSDBA access to administrative users in the OSDBA group and to the user SYS.

The SYSDBA administrative privilege is a trusted privilege in Oracle Database Vault. Grant this privilege to trusted users only.

Management of SYSOPER Access

By default, Oracle Database limits SYSOPER access to operating system users in the OSOPER group and to the user SYS.

This prevents SYSOPER from modifying the Oracle data dictionary directly. The SYSOPER privilege has limited privileges within the database, but individuals with this role can start and shut down the Oracle database. Only grant the SYSOPER privilege to trusted individuals.

Security Considerations for the UTL_FILE and DBMS_FILE_TRANSFER Packages

You should carefully restrict access to the UTL_FILE and DBMS_FILE_TRANSFER PL/SQL packages.

Topics:

• About Security Considerations for the UTL_FILE and DBMS_FILE_TRANSFER Packages

• Securing Access to the DBMS_FILE_TRANFER Package

• Example: Creating a Command Rule to Deny Access to CREATE DATABASE LINK

• Example: Creating a Command Rule to Enable Access to CREATE DATABASE LINK

• Example: Command Rules to Disable and Enable Access to CREATE DIRECTORY

BEGIN 
 DBMS_MACADM.CREATE_COMMAND_RULE (
  command       => 'CREATE DATABASE LINK', 
  rule_set_name => 'Disabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => DBMS_MACUTL.G_YES); 
  END; 
  / 
COMMIT;

BEGIN 
 DBMS_MACADM.UPDATE_COMMAND_RULE (
  command       => 'CREATE DATABASE LINK', 
  rule_set_name => 'Enabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => DBMS_MACUTL.G_YES); 
 END; 
 /  
COMMIT;

-- Disable access to CREATE DIRECTORY
BEGIN
 DBMS_MACADM.CREATE_COMMAND_RULE (
  command       => 'CREATE DIRECTORY', 
  rule_set_name => 'Disabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
 END; 
  / 
COMMIT;

-- Enable access to CREATE DIRECTORY
BEGIN 
 dbms_macadm.update_command_rule (
  command       => 'CREATE DIRECTORY', 
  rule_set_name => 'Enabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
 END; 
 /
COMMIT;

Security Considerations for the Recycle Bin

You should be aware that realm-protected objects that are dropped are not protected in the recycle bin.

Topics:

• About Security Considerations for the Recycle Bin

• Checking the Contents of the Recycle Bin

• Purging the Contents of the Recycle Bin

• Disabling the Recycle Bin

Security Considerations for the CREATE ANY JOB Privilege

The CREATE ANY JOB privilege has been revoked from the DBA and the SCHEDULER_ADMIN roles. Ensure that this change does not affect your applications.

See "Using Oracle Scheduler with Oracle Database Vault" for more information.

Security Considerations for the CREATE EXTERNAL JOB Privilege

The CREATE EXTERNAL JOB privilege was introduced in Oracle Database 10g Release 2 (10.2).

This privilege is required for database users who want to execute jobs that run on the operating system outside the database. By default, the CREATE EXTERNAL JOB privilege is granted to all users who have been granted the CREATE JOB privilege. For greater security, revoke this privilege from users who do not need it and then grant it only to those users who do need it.

Security Considerations for the LogMiner Packages

The role EXECUTE_CATALOG_ROLE no longer has the EXECUTE privilege granted by default on the several LogMiner packages.

These packages are as follows:

• DBMS_LOGMNR

• DBMS_LOGMNR_D

• DBMS_LOGMNR_LOGREP_DICT

• DBMS_LOGMNR_SESSION

You should ensure that this change does not affect your applications.

Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges

You should be aware of ways to secure the powerful ALTER SYSTEM and ALTER SESSION system privileges.

Topics:

• About Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges

• Example: Adding Rules to the Existing ALTER SYSTEM Command Rule

CONNECT bea_dvacctmgr
Enter password: password

BEGIN
 DBMS_MACADM.CREATE_RULE('NO_SYSTEM_DUMP',
 '(INSTR(UPPER(DVSYS.DV_SQL_TEXT),''DUMP'') = 0)');
 END;
/
EXEC DBMS_MACADM.ADD_RULE_TO_RULE_SET
  ('Allow Fine Grained Control of System Parameters','NO_SYSTEM_DUMP');

COMMIT;