Skip Headers
Oracle® Audit Vault Administrator's Guide
Release 10.2.3

Part Number E11059-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

5 Managing Audit Vault Security

Oracle Audit Vault uses the industry leading security capabilities of Oracle Database Vault and Oracle Advanced Security features to protect audit data from the moment it is collected, transmitted, consolidated, and stored in a centralized, protected, audit data repository.

This chapter provides an understanding of how to manage Oracle Audit Vault security. Audit Vault administrators should perform Oracle Audit Vault security tasks in this order of importance:

  1. Secure management communication between Audit Vault Server and Audit Vault Collection Agent (see Oracle Advanced Security – Secure Management Communication).

  2. Manage user authentication metadata (see Oracle Advanced Security – Manage User Authentication Metadata).

This chapter also includes the following additional sections as background information to assist Audit Vault administrators in understanding how Oracle Database Vault protects audit data and provides strong access control:

5.1 Oracle Advanced Security – Secure Management Communication

Audit Vault administrators can further secure management communication between the Audit Vault Server and the Audit Vault Collection Agent by using the HTTPS protocol to encrypt data (see Figure 1-2). In this case, X.509 certificates are provided by the Audit Vault administrator and are used for authentication. This is part of the postinstallation configuration of Oracle Audit Vault. Secure Sockets Layer (SSL) is configured for the mutual authentication between the Audit Vault management service on the server side and each collection agent over HTTPS. A Certificate Authority must provide these certificates to the Audit Vault administrator.

See Also:

Oracle Database Security Guide for more information about PKI-based authentication, digital certificates, and secure external password stores and Oracle Database Advanced Security Administrator's Guide for more information about Oracle wallets.

Once Audit Vault Server and Audit Vault Collection Agent communication is secured using HTTPS, the browser must also use HTTPS to access the Audit Vault Console. There is no longer an HTTP protocol available for the browser user, because the browser to Audit Vault Console communication is also made secure.

Oracle XML Database HTTP server is configured to HTTP. Oracle XML Database HTTP server can be configured to HTTPS using the AVCA secure_av command as described in the next section. However, before you run this command, you must first follow these steps:

  1. Generate a certificate request for Oracle XML Database using the AVCA generate_csr command.

  2. Send this certificate request to a CA and get it signed and then returned to you.

  3. Import this signed certificate into the wallet using the AVCA import_cert command.

Now you can proceed to configure both the Audit Vault Server and Oracle XML Database communication using the AVCA secure_av command as described in the next section.

Setting Up Mutual Authentication Between Audit Vault Server and Its Collection Agents

See Oracle Database Advanced Security Administrator's Guide for information about using Oracle Wallet Manager to obtain X.509 certificates from a Certificate Authority for the Audit Vault Collection Agent and importing them into the wallet. Use the keytool located at $ORACLE_HOME/jdk/bin/keytool to generate the key store if this becomes necessary. Once the key store and certificates are in place at the collection agent side, next set up mutual authentication between Audit Vault Server and its collection agents. To do this, use the AVCA secure_av command from the system where Oracle Audit Vault Server is installed. This operation secures Oracle Audit Vault Server by enabling mutual authentication with Oracle Audit Vault Collection Agent.

The AVCA secure_av command takes the following arguments:

The following AVCA secure_av command secures Oracle Audit Vault Server by enabling mutual authentication with Oracle Audit Vault Collection Agent.

avca secure_av -avkeystore /tmp/avkeystore -avtruststore /tmp/avkeystore 
Enter keystore password: *******

From the system where Oracle Audit Vault Collection Agent is installed, the AVCA secure_agent command secures the Oracle Audit Vault Collection Agent by enabling mutual authentication with Oracle Audit Vault Server.

The AVCA secure_agent command takes the following arguments:

The following AVCA secure_agent command secures the Audit Vault Collection Agent by enabling mutual authentication with Audit Vault.

avca secure_agent -agentkeystore /tmp/agentkeystore
-agentdn "CN=agent1, OU=development, O=oracle, L=redwoodshores, ST=ca, C=us" 
-avdn "CN=av1, OU=development, O=oracle, L=redwoodshores, ST=ca, C=us"
Enter keystore password: *******

5.2 Oracle Advanced Security – Manage User Authentication Metadata

As part of the Oracle Audit Vault Server and the Oracle Audit Vault Collection Agent installation, two wallets are created. One wallet resides on the Audit Vault Server and this one contains the AV_ADMIN user's credentials and is used by the Audit Vault Console to communicate to the Audit Vault database. This Audit Vault Console provides the management service that initiates the communication with collection agents using HTTP. Audit Vault Configuration Assistant (AVCA) modifies the Database Control console server.xml file and other related files to enable Audit Vault management through the Oracle Enterprise Manager Database Control console. The wallet is located in the $ORACLE_HOME/network/admin/avwallet directory.

The other wallet resides on the Audit Vault Collection Agent and contains the AV_AGENT credentials and is used by the collection agent to get configuration data from Oracle Audit Vault. It is located in the $ORACLE_HOME/network/admin/avwallet directory. The collection agent-side wallet also contains the credentials used by the collectors to communicate to the source database, such as Oracle Database or Microsoft SQL Server database. These credentials are used by the three ORCLDB collectors and the MSSQLDB collector to connect to the source and to:

The Oracle wallet is a password-protected container that stores credentials, such as certificates, authentication credentials, and private keys, all of which are used by SSL for strong authentication. Oracle wallets are managed through Oracle Wallet Manager. Oracle Wallet Manager can perform tasks such as wallet creation, certificate request generation, and certificate import into the wallet.

Oracle Audit Vault uses third-party network authentication services, PKI-based authentication, to authenticate its user clients. Authentication systems based on public key infrastructure (PKI) issue digital certificates to user clients, which use them to authenticate directly to servers in the enterprise without directly involving an authentication server. These user certificates, along with the private key of the user and the set of trust points of a user (trusted certificate authorities), are stored in Oracle wallets.

5.3 Oracle Database Vault – Protects Oracle Audit Vault

Oracle Database Vault provides realms, separation of duty, command rules and factors as features that are applicable to reducing the overall risk associated with specific provisions of regulations worldwide. These regulations have common themes that include internal controls, separation of duty, and strong access controls on access to sensitive information. Technical solutions are required to mitigate the risks associated with items such as unauthorized modification of data and unauthorized access.

Oracle Database Vault realms prevent database administrators (DBAs), application owners, and other privileged users from viewing application data using their powerful privileges. Database Vault realms put in place preventive controls, helping reduce the potential impact when a data breach does occur, enabling the DBA to perform his or her job more effectively. Oracle Database Vault realms can be used to protect an entire application or a specific set of tables within an application, providing highly flexible and adaptable security enforcement. Oracle Audit Vault audit data is protected in this way.

Oracle Database Vault prevents highly privileged users (DBAs) from accessing audit data. It enforces a separation of duty by not allowing the same user granted two or more administrator roles to perform different responsibilities in the same session and optimally to have different administrator users be granted respective roles to perform these responsibilities in separate sessions.

Oracle Database Vault provides two roles, DV_ACCTMGR to manage database user accounts and DV_OWNER to manage database roles and configuration. The security administrator granted DV_ACCTMGR role can create, alter, and drop users and this user creates all Audit Vault administrator users. The security administrator granted DV_OWNER role can grant Oracle Database Vault roles. The Audit Vault administrator user granted the AV_ADMIN role grants all Audit Vault roles. Thus, two different highly privileged users are required one to create Audit Vault users and the other to grant these users Audit Vault roles. In this way, Oracle Database Vault and Oracle Audit Vault protect audit data from access, enforce protection of database structures from unauthorized change, and set a variety of access controls to implement dynamic and flexible security requirements. See Section 5.4 for more information about these Database Vault security administrator accounts, Audit Vault administrator accounts, and the core database user accounts.

Using Oracle Database Vault, highly privileged database users can be prevented from accessing application data. In addition, access to applications, databases, and data can be tightly controlled based on such variables as time of day, IP address or subnet.

5.4 Oracle Database Vault – Provides Strong Access Controls

Audit Vault is a secure data warehouse that consolidates audit data across an enterprise. The data is only visible to Audit Vault auditors once it is moved into the Audit Vault data warehouse. No user can access the audit data before it is moved to the Audit Vault data warehouse nor after it is purged from there. Even a SYS user cannot access this secure audit data. The default privilege that a SYS user will have is the ability to lock and unlock the Audit Vault schema. This extremely tight security is necessary to prevent audit trail data, which is extensive, detailed, and sensitive information, from being compromised. Oracle Database Vault features guarantee this level of security.

Audit Vault predefined administrator roles include:

Table 5-1 shows the roles and privileges an administrative user is granted when that user is granted one of the high level Audit Vault or Database Vault roles. Typically, one user is granted an AV_ADMIN role and one user is optionally granted an AV_AUDITOR role as part of installing the Audit Vault Server. The user granted the AV_ADMIN role can be granted the AV_AUDITOR role if that user is not created during the Audit Vault Server installation. Because Oracle Audit Vault is protected by Oracle Database Vault, only the user granted the DV_ACCTMGR role can create, alter, and drop users.

Table 5-1 Roles and Privileges Granted to Administrators Granted a Specific Audit Vault or Database Vault Role

Role Granted to User Roles Granted Privileges Granted

AV_ADMIN

DV_PUBLIC, AV_ADMIN, SELECT_CATALOG_ROLE, HS_ADMIN_ROLE, AQ_ADMINISTRATOR_ROLE, AQ_ADMINISTRATOR_ROLE, AV_AUDITOR, AV_AGENT

CREATE SESSION, CREATE ANY VIEW, GRANT ANY ROLE, MANAGE ANY QUEUE, ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, CREATE EVALUATION CONTEXT, CREATE RULE SET, CREATE RULE

AV_AUDITOR

DV_PUBLIC, AV_AUDITOR, SELECT_CATALOG_ROLE, HS_ADMIN_ROLE

CREATE SESSION

AV_AGENT

DV_PUBLIC, AV_AGENT

CREATE SESSION, CREATE ANY VIEW

AV_SOURCE

DV_PUBLIC, RESOURCE, AV_SOURCE, AV_USER_ROLE

CREATE SESSION, RESTRICTED SESSION, UNLIMITED TABLESPACE, CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE DATABASE LINK, CREATE PROCEDURE, CREATE TRIGGER, CREATE TYPE, CREATE OPERATOR, CREATE INDEXTYPE, MANAGE ANY QUEUE, ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, CREATE EVALUATION CONTEXT, CREATE RULE SET, CREATE ANY RULE SET, ALTER ANY RULE SET, EXECUTE ANY RULE SET, CREATE RULE, CREATE ANY RULE, ALTER ANY RULE, EXECUTE ANY RULE

DV_ACCTMGR

DV_PUBLIC, CONNECT, DV_ACCTMGR

CREATE SESSION, CREATE USER, ALTER USER, DROP USER, CREATE PROFILE, ALTER PROFILE, DROP PROFILE

DV_OWNER

DV_PUBLIC, CONNECT, DV_OWNER, DV_ADMIN, DV_SECANALYST

CREATE SESSION, GRANT ANY ROLE, ALTER ANY TRIGGER, ADMINISTER DATABASE TRIGGER


The Audit Vault roles are granted or revoked through the SQL*Plus interface using the SQL GRANT and REVOKE commands in the following way. All granting or revoking of Audit Vault roles or privileges is done through SQL*Plus by the user who has AV_ADMIN role granted. To add more users, a user must connect having DV_ACCTMGR role to create the users; however, this user cannot also grant these roles to these users. Only the user granted the AV_ADMIN role can then grant the appropriate role (AV_ADMIN and AV_AUDITOR), through SQL*Plus.

An Audit Vault administrator with one of these predefined roles granted can assume only one administrative responsibility at a time in a given session. For instance, if the Audit Vault administrator must perform a different task in another role, the same administrator must begin a new session to start that task.

Note:

Users granted more than one Audit Vault role can only log in to the Audit Vault Console as a single role. They must log out and log in to an Audit Vault system again to use a different role. This security measure maintains a separation of duties within an Audit Vault system for each Audit Vault user.

Table 5-2 shows all other database core accounts created in the default Audit Vault installation. Operating system authentication to the database is allowed, remote authentication to the database "AS SYSDBA" is not allowed, but if needed can be enabled by use of the password file. See "Postinstallation Tasks" in the Oracle Audit Vault installation guides for more information about unlocking and resetting user passwords and enabling or disabling connections with the SYSDBA Privilege.

Table 5-2 Database Core Accounts Created and Privileges In Use

Account Privileges Privilege In Use or Not Password to Use

SYS SYSTEM SYSMAN DBSNMP

Many

Yes

Same password as user granted AV_ADMIN role for basic installation or password may be set separately in advanced installation.

SYS AS or

/ AS

SYSDBA

Yes, allowed

Operating system authentication to the database is enabled by default.

SYS AS

SYSDBA

No, not allowed for remote connection

To use for remote connection, user must create a password file to enable its use. Password is set when password file is created.

SYS AS

SYSOPER

Yes, allowed

Same password as user granted AV_ADMIN role.


The following example shows how to add a new Audit Vault administrator auditor account, grant this new user the AV_AUDITOR role, then check this user's granted roles and privileges.

sqlplus /nolog
SQL> connect avadmindva
Enter password: avadmindvapassword
Connected.
SQL> create user avauditor2 identified by Welcome_99;

User created. 

SQL> connect avadmin
Enter password: avadminpassword
Connected.
SQL> grant AV_AUDITROR to avauditor2;

Grant succeeded.

SQL> connect avauditor2
Enter password: avauditor2password
Connected.
SQL> show user
USER is "AVAUDITOR2"
SQL> select * from session_roles;

ROLE
------------------------------
DV_PUBLIC
AV_AUDITOR
SELECT_CATALOG_ROLE
HS_ADMIN_ROLE

SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION

The following example shows how to connect as the SYS user with SYSOPER privilege (using the clause AS SYSOPER), shut down the Audit Vault database, and then start it up again.

sqlplus /nolog
SQL connect sys as sysoper
Enter password: sysoperpassword
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
Oracle instance shut down.

SQL> startup
Oracle instance started.
Database mounted.
Database opened.
SQL> exit