Download presentation
Presentation is loading. Please wait.
1
Introduction to Oracle Audit Vault
2
Oracle Database 10g: Implementing Audit Vault 1 - 2
Objectives After completing this lesson, you should be able to describe: Audit Vault features that help you meet security compliance requirements Benefits of using Audit Vault Audit Vault architecture Audit Vault users Audit Vault interfaces Oracle Database 10g: Implementing Audit Vault
3
Responding to Compliance Regulations
Business and personal data for customers, employees, and partners must be secured. Users, activities, and data must be audited to demonstrate compliance. Compliance regulations include: U.S. Sarbanes-Oxley Act of 2002 (SOX) U.S. Gramm-Leach-Bliley Act (GLBA) U.S. Healthcare Insurance Portability and Accountability Act (HIPAA) Payment Card Industry (PCI) Data Security Standard Japanese Personal Information Protection Law EU privacy directives Responding to Compliance Regulations Compliance regulations and laws require businesses to secure business and personal data for customers, employees, and partners. Businesses must demonstrate compliance with the regulations by auditing users, activities, and associated data. The regulations that Oracle Audit Vault helps to provide compliance with include: U.S. Sarbanes-Oxley Act of 2002: Mandates a number of reforms to enhance corporate responsibility, enhance financial disclosures, and combat corporate and accounting fraud. The U.S. Sarbanes-Oxley Act of 2002 created the “Public Company Accounting Oversight Board” to oversee the activities of the auditing profession. U.S. Gramm-Leach-Bliley Act (GLB Act): Includes provisions to protect consumers’ personal financial information held by financial institutions. There are three principal parts to the privacy requirements: the Financial Privacy Rule, the Safeguards Rule, and pretexting provisions. U.S. Healthcare Insurance Portability and Accountability Act (HIPPA): Requires the Department of Health and Human Services (HHS) to establish national standards for electronic health care transactions and national identifiers for providers, health plans, and employers. It also addresses the security and privacy of health data. Oracle Database 10g: Implementing Audit Vault
4
Problems with In-House Auditing Implementations
In-house auditing implementations may present the following issues: Distributed audit data makes it difficult to perform analysis and issue alerts. Database administrator (DBA) or system administrator could potentially modify audit data. Large amount of audit data can burden production systems. Processing of audit data can affect production systems. Enterprise-wide audit policies are often complicated to administer. Problems with In-House Auditing Implementations Many organizations attempt to comply with the various compliance regulations through the implementation of in-house auditing solutions. Due to the inherent nature of distributed systems and data, it is often difficult to perform a comprehensive analysis of the information and issue alerts in a timely fashion. In some implementations, it may be possible for the database administrator or the system administrator to have easy access to the audit data and modify it to suit specific needs. Significant amounts of audit information may be collected, and there may not be an efficient way to process and manage the data. Oracle Database 10g: Implementing Audit Vault
5
Oracle Audit Vault: “Trust but verify”
Collect and consolidate audit data Oracle9i Release 2 and higher Simplify compliance reporting Built-in reports Custom reports Detect and prevent insider threats Scale and security Database Vault Advanced Security Partitioning Centrally manage and provision audit settings Monitor Policies Reports Security (Future) Other sources and databases Oracle9i R2 10g R2 Oracle Audit Vault: “Trust but verify” Key benefits of Oracle Audit Vault include the following: Oracle Audit Vault transparently collects and consolidates audit data from Oracle databases, beginning with Oracle9i Database Release 2. Oracle Audit Vault helps organizations simplify compliance reporting with built-in reports and custom reports. In addition, Oracle Audit Vault provides an open audit warehouse schema that can be accessed from Oracle BI Publisher, Oracle Application Express, or any third-party reporting tools. Oracle Audit Vault helps detect and prevent insider threats by alerting you to suspicious activity. Central to Oracle Audit Vault is a secure and scalable audit warehouse built on Oracle’s data warehousing technology and secured with Oracle’s database security products, including Oracle Database Vault and Oracle Advanced Security. Oracle Audit Vault includes Oracle Partitioning to improve manageability and performance. Oracle Audit Vault helps organizations lower IT costs with centralized management of database audit settings (policies), making it easier for IT security officers and internal auditors to do their jobs. 10g R1 Oracle Database 10g: Implementing Audit Vault
6
Oracle Audit Vault Reports: Overview
Out-of-the-box reports Privileged user activity Access to sensitive data Role granting DDL activity Log in and log out Oracle Audit Vault Reports: Overview Oracle Audit Vault provides reports for activities associated with privileged user activity, access to sensitive data, roles and privileges, object management, and log in/log out activities across the enterprise databases. Oracle Database 10g: Implementing Audit Vault
7
Oracle Audit Vault Reports: Overview
User-defined reports What actions did privileged users perform on the financial database? What actions did user A perform across multiple databases? Who accessed sensitive data? Custom reports Oracle BI Publisher and Application Express Third-party tools Oracle Audit Vault Reports: Overview (continued) Oracle Audit Vault also enables you to generate user-defined reports. For example, a report can be generated that tracks the activities of privileged users on the financial database. A report could be created to show user activity across multiple databases. Another report might be defined to help support an internal investigation to see who accessed sensitive data. Oracle Audit Vault provides an open audit warehouse schema that can be accessed from Oracle BI Publisher, Oracle Application Express, or any third-party reporting tools. Access to the audit warehouse enables you to generate custom reports for compliance and security requirements. Oracle Audit Vault reporting capabilities are discussed in the lesson titled “Using Audit Vault Reports.” Oracle Database 10g: Implementing Audit Vault
8
Oracle Audit Vault Security: Protecting Audit Data
Protected with built-in security Encrypted audit data transmission Separation of duty: Audit Vault Administrator and Audit Vault Auditor Protected using: Oracle Database Vault Oracle Advanced Security Oracle Audit Vault Security: Protecting Audit Data Oracle Audit Vault Security is a very important feature. Enterprise audit data is an important and critical record of business activity and, therefore, is as sensitive as actual business data. Oracle Audit Vault is protected with built-in security. Oracle Audit Vault protects audit data during transfer with network encryption, preventing anyone from reading or tampering with data during transmission. This is important because audit data needs to be protected against modification so that reports and investigations based on audit data have a high level of integrity. “Separation of duty” is strictly enforced. Access to audit data in Oracle Audit Vault is strictly controlled. IT security managers and auditors can be given access for review purposes only. Privileged DBA users cannot view or modify the audit data in the Oracle Audit Vault audit warehouse. Oracle Audit Vault protects audit data by using Oracle Database Vault and Oracle Advanced Security. Oracle Audit Vault security is discussed in detail in the lesson titled “Administering Audit Vault Security.” Oracle Database 10g: Implementing Audit Vault
9
Oracle Audit Vault Alerts: Early Detection with Alerting
Alerts can be defined for: Viewing sensitive columns Creating users Granting of roles DBA grants on all systems Failed application logins Alerts are evaluated on incoming audit data. Alert reports can be generated for suspicious activity. Oracle Audit Vault Alerts: Early Detection with Alerting Security alerts can be used to enable you to quickly address compliance, privacy, and insider threat issues across the enterprise. Oracle Audit Vault’s interface can be used to monitor alerts and audited events across the business. Alerts can be defined on such database activities as: Viewing of sensitive columns by users Creating users on sensitive systems by DBAs Granting of roles on sensitive systems Granting of DBA privileges on all systems Failed application user logins An alert can be created for almost any condition that you want to define. Oracle Audit Vault continuously monitors the audit data collected, evaluating the activity against defined alert conditions. Oracle Audit Vault’s alerting capability is discussed in detail in the lesson titled “Configuring Alerts.” Oracle Database 10g: Implementing Audit Vault
10
Oracle Audit Vault Data Warehouse: Scalable and Flexible Warehouse
Audit data warehouse Enables business intelligence and analysis Enables reporting Audit data warehouse dimensions Time, host, source, user, and event Schema documented and published Allows third-party reporting tools Performance and scalability Built-in partitioning Scales to terabytes Oracle RAC certified Oracle Audit Vault Data Warehouse: Scalable and Flexible Warehouse Oracle Audit Vault has been developed on a flexible data warehouse infrastructure that enables the use of business intelligence and analysis tools as well as sophisticated reporting capabilities. The Oracle Audit Vault audit warehouse schema can be accessed from Oracle BI Publisher, Oracle Application Express, or any third-party reporting tools. This provides the ability to generate custom reports for compliance and security requirements. Oracle Audit Vault provides performance and scalability with a secure data warehouse environment designed for the storage and analysis of large amounts of audit data. Oracle Audit Vault includes Oracle Partitioning to enhance manageability and performance, enabling audit data to be physically partitioned based on business requirements. Oracle Audit Vault can scale to store terabytes of data in the audit warehouse. Oracle Audit Vault can optionally be deployed with Oracle Real Application Clusters (RAC), enabling even greater scalability, high availability, and flexibility at low cost. Oracle RAC allows Oracle Audit Vault to scale out by adding additional server machines to accommodate additional audit sources or audit records rather than having to scale up by replacing the existing machine with a more powerful machine. The Oracle Audit Vault data warehouse is discussed in detail in the lesson titled “Managing the Audit Vault Data Warehouse.” Oracle Database 10g: Implementing Audit Vault
11
Oracle Audit Vault Policies: Centralized Management of Audit Policies
HR database Financial database Customer database Audit policies: Collection of database audit settings Compare against existing audit settings on source Provision audit settings centrally Demonstrate compliance Privilege user audit settings SoX audit settings Privacy audit settings Oracle Audit Vault Policies: Centralized Management of Audit Policies Oracle Audit Vault provides centralized management of database audit settings or policies, simplifying the job of IT security officers and internal auditors. Oracle Audit Vault features a policy mechanism that allows businesses to define specific audit policies. Oracle Audit Vault compares the defined audit policy to the defined audit setting on the source database to see if there are any differences. Oracle Audit Vault’s policy mechanism can alert administrators to potential differences by generating a record of the events. You can use Oracle Audit Vault to centrally provision audit settings. This eliminates the need for manual scripting of audit settings and reduces the associated maintenance costs. Oracle Audit Vault policy administration is discussed in detail in the lesson titled “Managing Audit Settings.” Audit Vault Administrator Oracle Database 10g: Implementing Audit Vault
12
Oracle Audit Vault Components
Oracle Audit Vault consists of: Audit Vault Server Oracle Database repository for audit events Audit Vault Console Services Audit Vault Agent Oracle Database client Oracle Application Server Container for J2EE (OC4J) Audit Vault Agent management services Audit data collectors for Oracle Database Oracle Audit Vault Components Audit Vault Server: An Oracle Database instance and set of services Audit Vault Agent: An Oracle Database client and services installed on the source database host, the Audit Vault Server host, or another host system Oracle Database 10g: Implementing Audit Vault
13
Audit Vault Architecture: Overview
Audit Vault Server Management and Monitoring Audit Settings Management Security Infrastructure Audit Data Collection AV Admin Data Warehouse Reports Alerts Administration Audit data Configuration metrics AV Auditor Audit Vault Agent Collectors REDO, DBAUD, OSAUD Reporting and alerts Audit Vault Architecture: Overview The Audit Vault architecture comprises a set of services and its collection system. The collection infrastructure includes audit collectors that retrieve audit data from an audit source. The set of services facilitates storage management, policy enforcement, alerting, analysis, and reporting. Audit sources Oracle Database 10g: Implementing Audit Vault
14
Oracle Database 10g: Implementing Audit Vault 1 - 15
Deploying Audit Vault Audit Vault Server Host 1 Agent Agent DBAUD DBAUD DBAUD Source 1 Source 2 Source 3 OSAUD OSAUD OSAUD Deploying Audit Vault You can deploy the Audit Vault components in a number of ways. The diagram illustrates a configuration with three source databases. Two of the source databases are on one host machine. One Audit Vault agent is installed on the host machine with the two source databases. Each source database has its own set of collectors. On a second host machine, there is another source database. An Audit Vault agent is also installed on this machine. Collectors are configured for this source database. REDO REDO REDO Host 2 Host 3 Oracle Database 10g: Implementing Audit Vault
15
Audit Vault Services: Overview
The Audit Vault Server includes the following services: Management and monitoring Reporting Analysis Alert Data warehouse Audit Policy Configuration Audit Vault Services: Overview The Audit Vault Server includes the following services: Management and monitoring: Assist in managing all collectors, starting and stopping them, and monitoring and storing metrics about each collector in a management repository Reporting: Assists in creating and managing reports Analysis: Assists in analyzing audit data in the data warehouse Alert: Assists in handling alert evaluation of records and raising alerts when an alert condition is satisfied Data warehouse: Assists in scheduling and populating the data warehouse with audit data Audit: Assists audit collectors in sending audit data to the raw audit trail and receiving configuration data Policy: Assists in setting policies about what activity is audited and what type of activity raises alerts. Policies (audit settings) can be provisioned to the various systems in the enterprise. This provides the ability to efficiently create and apply audit settings for compliance and security requirements. Configuration: Assists in defining information about audit sources to be consolidated Oracle Database 10g: Implementing Audit Vault
16
Audit Vault Framework Audit Vault Agent Audit Vault Server OC4J OC4J
AV Web Application Audit Vault Console Agent HTTP Listener Stop/start agent Stop/start collector Collect metrics Management Service Management Service Policy Service Policy Service Audit Service EM Database Control Collector Manager Database Audit data repository Collectors Configuration data DBAUD OSAUD REDO Alert service/alert queue Audit Vault Framework The Audit Vault Server has two components: the Audit Vault Server database and the Audit Vault Web application. The Audit Vault Web application contains: Audit Vault Console Management service: Handles management commands from the Audit Vault Console and the AVCTL utility and takes appropriate action Policy service: Directs the Audit Vault agent to retrieve audit settings from a source database, provisions audit settings back to the source database, and performs other audit settings-related operations The OC4J that contains the Web application also hosts Enterprise Manager Database Control for the Audit Vault Server database instance. The Audit Vault Server database contains: Audit data repository (including the audit data warehouse) Audit Vault configuration data Alert service Alert queue Apply module for REDO Collector Source Redo logs Apply module for REDO Audit trail records Oracle Database 10g: Implementing Audit Vault
17
Audit Vault Users: Overview
Audit Vault Administrator Configures sources Configures agents and collectors Audit Vault auditor (auditor, compliance officer, security) Configures audit settings Configures alerts Views reports Analyzes data in the data warehouse AV Administrator AV auditor Audit Vault Users: Overview The Oracle Audit Vault system, including the Audit Vault Server, Audit Vault Agent(s), and Collectors, is managed by the Audit Vault Administrator. The data that is retrieved from the source databases and stored in the Audit Vault repository is reviewed and analyzed by the Audit Vault auditor (auditors, compliance officers, and other security personnel). Oracle Database 10g: Implementing Audit Vault
18
Oracle Database Vault: Enforcing Separation of Duties
Oracle Database Vault includes the following roles, which separate the database administration and account management duties from the traditional DBA role: DV_OWNER: Oracle Database Vault owner DV_ACCTMGR: Oracle Database Vault account manager During the installation of Audit Vault, two users are created; they are granted the DV_OWNER and DV_ACCTMGR roles. Database Vault: Enforcing Separation of Duties Oracle Audit Vault includes a restricted-use license of Oracle Database Vault. Oracle Database Vault is used to secure the data in the Audit Vault Server database and provide separation of duties. Oracle Database Vault prevents the SYS user and other users with the DBA role and other system privileges from designated protected areas of the database called realms. Database Vault includes the DV_OWNER and DV_ACCTMGR database roles. These roles separate the database administration and the account management duties from the traditional DBA role. When you install Oracle Audit Vault, two users are created and granted the DV_OWNER and DV_ACCTMGR roles. The DV_ACCTMGR role is used for creating and altering users in the Audit Vault server database. Note: For more information on Oracle Database Vault, attend the Oracle Database 10g: Implementing Database Vault course and refer to the Oracle Database Vault documentation. Oracle Database 10g: Implementing Audit Vault
19
Audit Vault Data Warehouse: Overview
Auditor Raw audit data table Data warehouse Analysis Reporting Mining Overview of the Audit Vault Data Warehouse The Audit Vault data warehouse facilitates the analysis of collected audit data. Audit data is stored in a raw audit data table that is optimized for INSERT performance. A staging area is used for the data extraction, transformation, and loading (ETL) process to prepare the raw data for loading into the data warehouse. The data warehouse contains raw data and materialized views (summary data). Oracle Database 10g: Implementing Audit Vault
20
Audit Vault Interfaces
Command-line interfaces: Audit Vault Configuration Assistant (AVCA) Audit Vault Control (AVCTL) Audit Vault Oracle Database (AVORCLDB) GUI interfaces: Enterprise Manager Database Control: <host:port>/em Audit Vault Console: <host:port>/av Audit Vault Interfaces The Audit Vault Configuration Assistant (AVCA) is a command-line utility that enables the Audit Vault Administrator to manage Audit Vault components. You must be granted the AV_ADMIN role to execute AVCA commands. AVCA is used to configure and manage agents and wallets, manage mutual authentication between the Audit Vault agent and the Audit Vault server, and configure the data warehouse refresh schedule and retention time. Use the Audit Vault Control (AVCTL) command-line utility to control Audit Vault components. You can use it to start and stop agents and collectors and to manage data warehouse data. Audit Vault Oracle Database (AVORCLDB) is a command-line utility that is used to verify that an Oracle Database source database supports the named collector. In addition, it is used to configure the Oracle Database collectors (DBAUD, OSAUD, and REDO) on a named source database. Enterprise Manager can be used to manage the Audit Vault Server database instance. The Audit Vault Console is the GUI interface used to manage the Audit Vault system. The Audit Vault Console will be discussed in detail throughout the course. Oracle Database 10g: Implementing Audit Vault
21
Oracle Database 10g: Implementing Audit Vault 1 - 23
Summary In this lesson, you should have learned how to describe: Audit Vault features that help you meet security compliance requirements Benefits of using Audit Vault Audit Vault architecture Audit Vault users Audit Vault interfaces Oracle Database 10g: Implementing Audit Vault
22
Installing Oracle Audit Vault
23
Oracle Database 10g: Implementing Audit Vault 1 - 25
Objectives After completing this lesson, you should be able to: Describe types of Audit Vault installations Install the Audit Vault Server Install the Audit Vault Agent Oracle Database 10g: Implementing Audit Vault
24
Oracle Audit Vault Components
Audit Vault Server Uses an Oracle Database database Includes Audit Vault–specific files Includes restricted-use license of Oracle Database Vault Supports RAC and single-instance (SI) options for installation Audit Vault Agent Oracle Database client Lightweight client with additional components to support Audit Vault features Oracle Audit Vault Components The Audit Vault Server includes an Oracle Database database and a restricted use license of Oracle Database Vault. The Audit Vault Agent is an Oracle Database client and includes components to support Audit Vault features. The Audit Vault Agent must be installed on the same machine as the OSAUD collector. Oracle Database 10g: Implementing Audit Vault
25
Types of Audit Vault Server Installations
Oracle Database 10g Release 2 ( ) single-instance installation Oracle Database 10g Release 2 ( ) Clustered/ Oracle Real Application Clusters (RAC) installation Types of Audit Vault Server Installations The Oracle Audit Vault Server can be installed as follows: Single-instance installation of Oracle Database 10g Release 2 ( ) Oracle Database 10g Release 2 ( ) Clustered/Oracle Real Application Clusters (RAC) installation Note: Refer to “Certify – Oracle’s Certification Matrices, Desupport Notices & Product Availability” on MetaLink for specific information about certified platforms. Oracle Database 10g: Implementing Audit Vault
26
Audit Vault Server Hardware Requirements for Linux
At least 1,024 MB of available physical RAM Swap space as described below: 1.5 times the size of RAM Between 1,024 MB and 2,048 MB 0.75 times the size of RAM More than 8,192 MB Between 2,049 MB and 8,192 MB Available RAM Equal to the size of RAM Required Swap Space Audit Vault Server Hardware Requirements for Linux Hardware requirements for installation of the Oracle Audit Vault Server on Linux are described in the slide. Refer to the Oracle Audit Vault Server Installation Guide for your operating system for specific information. Oracle Database 10g: Implementing Audit Vault
27
Audit Vault Server Hardware Requirements for Linux
Audit Vault Server disk space requirements: 400 MB of disk space in the /tmp directory 1.4 GB of disk space for the Oracle Audit Vault Server software 700 MB of additional disk space for the Audit Vault server database files (initial requirement) Audit Vault Agent disk space requirements (platform dependent) 450 MB of disk space for the Audit Vault Agent software on Linux 1 GB on AIX Audit Vault Server Hardware Requirements for Linux (continued) The Audit Vault Server requires disk space as described in the slide. Additional space will be required for the database files as audit data is collected. Oracle Database 10g: Implementing Audit Vault
28
Included Oracle Options
Installation of Oracle Audit Vault includes a restricted-use license of the following options: Oracle Advanced Security Oracle Database Vault Oracle Label Security Oracle Partitioning Included Oracle Options When you install the Audit Vault Server, the following Oracle Database options are installed in the Oracle Audit Vault Server Oracle home: Oracle Advanced Security: Oracle Advanced Security provides transparent data encryption of data stored in the database, the encryption of disk-based backups of the database, and network encryption for data traveling across the network between the database and client or mid-tier applications. Oracle Database Vault: Enforcing separation of duties, even among administrators, Oracle Database Vault additionally serves as a powerful preventive control to help comply with today’s stringent compliance and privacy requirements. Oracle Label Security: Oracle Label Security enables row-level access control based on the Virtual Private Database technology of Oracle Database 10g Release 2 (10.2) Enterprise Edition. It controls access to the contents of a row by comparing that row’s label with a user’s label and privileges. Oracle Partitioning: Oracle Partitioning enables you to store large tables as individually managed smaller pieces while retaining a single application-level view of the data. Note: The installation of Oracle Audit Vault includes a restricted-use license of the options in this list. Oracle Database 10g: Implementing Audit Vault
29
Oracle Database 10g: Implementing Audit Vault 1 - 31
Installation Methods Interactive using Oracle Universal Installer (OUI) Automated installation using a response file <AV installer location>/response/av.rsp response file template Can be used in silent mode for advanced installation Installation Methods The interactive method of installing Audit Vault uses Oracle Universal Installer (OUI), which steps you through a series of pages on which you specify the required installation information. You can also use OUI with a response file to automate the Oracle Audit Vault Server installation. Oracle Database 10g: Implementing Audit Vault
30
Installing the Audit Vault Server
Use Oracle Universal Installer to perform one of the following types of Audit Vault Server installations: Basic: Uses standard configuration options and requires minimal input Audit Vault SID Audit Vault Server Home location Audit Vault Administrator and Auditor names and passwords Advanced: Offers additional options for installation Database Vault user names and passwords Database storage information Backup and recovery options Installing the Audit Vault Server OUI is used to install the Audit Vault Server. There are two types of installations to choose from: Basic: Simplified installation process with prompting for minimal information. Certain installation parameters will default to a value and cannot be changed by the user. Advanced: Provides greater control over installation parameters. You must use this option to install Audit Vault on a cluster. You can specify the following during an advanced installation: Database storage: Specify how the database files should be stored File system: Files are created in a directory on a file system mounted on the computer. Automatic Storage Management (ASM) Raw devices Automated backups: Schedules a daily RMAN job to back up all of the database files to the Flash Recovery Area. The first backup is a full backup of the database. Subsequent backups are incremental backups. Database schema passwords: Passwords for SYS, SYSTEM, SYSMAN, and DBSNMP Database Vault user credentials: Specify a user name and password for the the Database Vault owner and a separate, optional Database Vault account manager, respectively. Oracle Database 10g: Implementing Audit Vault
31
Selecting the Installation Type
After logging in as the oracle user, change your current directory to the directory that contains the Oracle Audit Vault installation files. Invoke OUI. The following example shows how to invoke OUI in a Linux or UNIX environment: ./runInstaller Select the installation type on the Select Installation Type page, and then click Next. Oracle Database 10g: Implementing Audit Vault
32
Providing Input During Audit Vault Server Installation
Provide the following information during installation: Audit Vault Name: Unique SID for the Audit Vault Server database instance Audit Vault Home: Location for the Audit Vault software Audit Vault Administrator user and password: Administers, configures, and manages Audit Vault Granted the AV_ADMIN role Audit Vault Auditor user and password (optional): Accesses Audit Vault reporting and analysis services Granted the AV_AUDITOR role Providing Input During Audit Vault Server Installation During the installation of the Audit Vault Server, you are prompted for the following: Audit Vault Name: Unique SID for the Audit Vault database; also used as part of the service name Audit Vault Home: Installation location for the Audit Vault software Audit Vault Administrator username: Granted the AV_ADMIN role Manages postinstallation configuration Accesses Audit Vault services to administer, configure, and manage Audit Vault The username is used to generate <AV Administrator>dva and <AV Administrator>dvo Oracle Database Vault users during Basic installation. Audit Vault Administrator password: This password is also used for the SYS, SYSTEM, SYSMAN, and DBSNMP database users during Basic installation. Audit Vault Auditor username and password (optional): Granted the AV_AUDITOR role Accesses Audit Vault services to monitor components, detect security risks, create and evaluate alert scenarios, create detail and summary reports, and manage reports Configures parameters for Data Warehouse population Oracle Database 10g: Implementing Audit Vault
33
Specifying Advanced Installation Details
After you select Advanced Installation on the Select Installation Type page, the Advanced Installation Details page appears. Provide the requested information (as described in the previous slide and notes). After entering information on the Advanced Installation Details page, click Next. Note: The Basic Installation Details page requires the same input. Oracle Database 10g: Implementing Audit Vault
34
Specifying Database Vault User Credentials
On the Database Vault User Credentials page, provide a name for the Database Vault Owner (granted the DV_OWNER role) and password. Optionally, specify a name for the Database Vault Account Manager (granted the DV_ACCTMGR role) and password. Note: This page does not appear during a Basic installation. The Database Vault Owner and Database Vault Account Manager names are derived from the name you specify for the Audit Vault Administrator. Oracle Database 10g: Implementing Audit Vault
35
Performing Product-Specific Prerequisite Checks
OUI performs several prerequisite checks to ensure that your machine meets the minimum requirements for the Audit Vault software. Oracle Database 10g: Implementing Audit Vault
36
Specifying Database Storage Options
On the Specify Database Storage Option page, specify the type of storage to be used for the database files. After entering information on the Specify Database Storage Option page, click Next to view the Specify Backup and Recovery Options page. Note: This page does not appear in a Basic installation. Oracle Database 10g: Implementing Audit Vault
37
Specifying Backup and Recovery Options
On the Specify Backup and Recovery Options page, you can specify that automatic backups of the database should be made. If you choose File System, specify the destination in the Recovery Area Location field. When you choose ASM for the storage location, additional pages are displayed to enable you to provide ASM configuration information. Enter an operating system username and password in the Backup Job Credentials section. After entering information on the Specify Backup and Recovery Options page, click Next to view the Specify Database Schema Passwords page. Note: This page does not appear in a Basic installation. Oracle Database 10g: Implementing Audit Vault
38
Specifying Database Schema Passwords
The Specify Database Schema Passwords page is displayed. On this page, you can specify different passwords for the SYS, SYSTEM, SYSMAN, and DBSNMP users. After entering information on the Specify Database Schema Passwords page, click Next to view the Summary page. Note: This page does not appear in a Basic installation. Oracle Database 10g: Implementing Audit Vault
39
Reviewing Audit Vault Server Installation Summary Information
After reviewing the installation information, click Install to begin the installation procedure. Oracle Database 10g: Implementing Audit Vault
40
Monitoring the Installation
Monitor the progress of the installation on the Install page. Take note of the installation session log location provided on this page. Oracle Database 10g: Implementing Audit Vault
41
Monitoring the Configuration Assistants
Each configuration assistant executes in turn. Execution information can be viewed in the scrollable window on the page. Oracle Database 10g: Implementing Audit Vault
42
Monitoring the Database Configuration Assistant
During installation of the Audit Vault Server, the Database Configuration Assistant is invoked to create the Audit Vault Server database. Oracle Database 10g: Implementing Audit Vault
43
Responding to the Database Configuration Assistant
During the installation, click Password Management to view locked accounts and unlock the accounts as necessary for your installation. If you do not want to view the locked accounts, click OK. You can unlock the accounts at a later time using SQL commands or Enterprise Manager. Oracle Database 10g: Implementing Audit Vault
44
Executing the root.sh Script
Open a terminal window and log in as the root user. Execute the root.sh script as directed. An example follows: av_1]# ./root.sh Running Oracle 10g root.sh script... The following environment variables are set as: ORACLE_OWNER= oracle ORACLE_HOME= /u01/app/oracle/product/10.2.0/av_1 Enter the full pathname of the local bin directory: [/usr/local/bin]: The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n)[n]: Entries will be added to the /etc/oratab file as needed by Database Configuration Assistant when a database is created Finished running generic part of root.sh script. Now product-specific root actions will be performed. Oracle Database 10g: Implementing Audit Vault
45
Performing an Advanced Installation of the Audit Vault Server
After the installation finishes, the “End of Installation” page appears. Take note of the Enterprise Manager Database Control and Audit Vault Console URLs that are displayed. Oracle Database 10g: Implementing Audit Vault
46
Understanding Audit Vault Users and Configuration Information
Database Vault Account Manager dbvacct1/dbvoracle_1 Audit Vault Server Audit Vault Administrator avadmin1/oracle_1 Database Vault Owner dbvowner1/dbvoracle_1 Audit Vault auditor avaudit1/oracle_1 Source Understanding Audit Vault Users and Configuration Information After the installation of the Audit Vault Server is complete, the Audit Vault Administrator and (optionally) the Audit Vault auditor have been defined in the Audit Vault Server database. In addition, the Database Vault Owner and Database Vault Account Manager users have been created. The information in the slide shows the users that have been created based on the input provided in the installation described in this lesson. Oracle Database 10g: Implementing Audit Vault
47
Installing the Audit Vault Agent
Audit Vault Agent and source database on same host Audit Vault Agent and Audit Vault Server on same host Agent Source Source Agent Audit Vault Agent, source database, and Audit Vault Server on different hosts Installing the Audit Vault Agent The Audit Vault Agent includes Oracle Application Server Containers for J2EE (OC4J) and Instant Client components, and is deployed within its own directory. The agent can be installed on the same system as the Audit Vault Server, on the same system that hosts the source database, or on a separate independent system. As a best practice, the Oracle Audit Vault Agent should be installed on each host system to be audited. The OSAUD collector requires local access to the audit trail files. Therefore, if you will be using the OSAUD collector, the Audit Vault Agent must be installed on the same host as the source database. The DBAUD and REDO collectors do not have this requirement. Source Agent Oracle Database 10g: Implementing Audit Vault
48
Performing Audit Vault Agent Preinstallation Tasks
Use SQL commands to create an Audit Vault Agent user in the Audit Vault Server database: Use the Audit Vault Configuration Assistant (AVCA) to add the Audit Vault Agent user to the Audit Vault Server: SQL> CREATE USER <avagent username> > IDENTIFIED BY <avagent password>; avca add_agent –agentname <avagent name> [-agentdesc <agent description>] -agenthost <hostname> -agentusr <avagent user name> Performing Audit Vault Agent Preinstallation Tasks Before installing the Audit Vault Agent, you must create a user in the Audit Vault Server database that is used to preauthorize the agent for installation. Set environment variables (appropriate to your operating system) for the Audit Vault Server and log in to SQL*Plus as the Database Vault Account Manager to perform these tasks. 1. Create an Audit Vault Agent user in the Audit Vault Server database, as shown in the following example: SQL> CREATE USER avagentuser IDENTIFIED BY avagentpass; User created. 2. Use the Audit Vault Configuration Assistant (AVCA) add_agent command to add the Audit Vault Agent user to the Audit Vault Server, as shown in the following example: av_1]$ avca add_agent \ > -agentname avagent1 \ > -agenthost EDRSR2P1.us.oracle.com \ > -agentusr avagentuser AVCA started Adding agent... Agent added successfully. av_1]$ Oracle Database 10g: Implementing Audit Vault
49
Understanding Audit Vault Users and Configuration Information
Database Vault Account Manager dbvacct1/dbvoracle_1 Audit Vault Server Audit Vault Administrator avadmin1/oracle_1 Database Vault Owner dbvowner1/dbvoracle_1 Audit Vault auditor avaudit1/oracle_1 Audit Vault Agent user avagentuser/avagentpass Source Agent name avagent1 Agent Understanding Audit Vault Users and Configuration Information When you execute the SQL CREATE USER <avagent username> IDENTIFIED BY <avagent password> command, you create a user in the Audit Vault Server database. You specify a name for the agent that will be used during the installation of the agent when you execute the avca add_agent command (as shown on the previous page). Oracle Database 10g: Implementing Audit Vault
50
Providing Input During Audit Vault Agent Installation
Provide the following information during installation: Audit Vault Agent name: Name of the agent as specified in the AVCA add_agent command Audit Vault home: Location for the Audit Vault Agent software Audit Vault Agent user and password: User-created before installation using SQL commands User-managed agents and collectors Granted the AV_AGENT role Audit Vault Server connect string: hostname:port:service name Providing Input During Audit Vault Agent Installation During the installation of the Audit Vault Agent, provide the following input: Audit Vault Agent name: Required name that can be a maximum of 255 characters. This is the name that you specified in the AVCA add_agent command. Audit Vault Agent home: Location for the installation of the Audit Vault Agent Audit Vault Agent user and password: Username and password of user created in the Audit Vault Server database Audit Vault Server connect string: Host name for the host on which the Audit Vault Server is installed Port number for the listener that is listening for the Audit Vault Server database instance Service name: <db_name>.<db_domain> for the Audit Vault Server database instance Oracle Database 10g: Implementing Audit Vault
51
Installing an Audit Vault Agent
On the “Oracle Data Vault Agent Installation: Agent Details” page, provide the Audit Vault Agent name and the Oracle home location for the Agent software installation. You must use the same agent name that you specified in the avca add_agent command. In the Agent User Name field, enter the name of the user that you created on the Audit Vault Server database. Supply the password for that user in the Agent User Password field. Click the Next button to view the Server Connection Details page. Oracle Database 10g: Implementing Audit Vault
52
Performing Product-Specific Prerequisite Checks
The Product-Specific Prerequisite Checks page is displayed. After the checks are finished, click Next to view the Summary page. Oracle Database 10g: Implementing Audit Vault
53
Viewing Audit Vault Agent Installation Summary Information
Review the installation summary information. Click Install to proceed with the installation. Oracle Database 10g: Implementing Audit Vault
54
Viewing the Installation Page
The Install page displays information about the progress of the installation. Take note of the installation session log location displayed on the page. Oracle Database 10g: Implementing Audit Vault
55
Monitoring the Configuration Assistants
The Oracle Audit Vault Configuration Assistant executes. When it finishes, click Next. Oracle Database 10g: Implementing Audit Vault
56
Installing an Audit Vault Agent
After the Audit Vault Agent is installed, the Audit Vault Agent port number is displayed. Oracle Database 10g: Implementing Audit Vault
57
Understanding Audit Vault Users and Configuration Information
Audit Vault Administrator avadmin1/oracle_1 Audit Vault auditor avaudit1/oracle_1 Audit Vault Agent user avagentuser/avagentpass Database Vault Account Manager dbvacct1/dbvoracle_1 Database Vault Owner dbvowner1/dbvoracle_1 Audit Vault Server Source Agent name avagent1 Agent Understanding Audit Vault Users and Configuration Information When you install the Audit Vault Agent, you provide the agent name that you specified in the AVCA add_agent command. Oracle Database 10g: Implementing Audit Vault
58
Viewing Agent Information
AV Administrator Viewing Agent Information The user with the AV_ADMIN role can view information about the Agent through the Audit Vault Console. The following information is displayed: Name: The name of the agent as specified in the AVCA add_agent command and Agent installation Host: The name or IP address of the host system where the agent resides Port: The port number for this agent User: The name of the Audit Vault Agent user as defined in the Audit Vault Server database and specified in the AVCA add_agent command Oracle Database 10g: Implementing Audit Vault
59
Altering the Agent Attributes
Use the AVCTL alter_agent command to modify the attributes of an agent: avca alter_agent -agentname <agent name> [-newagentname <new agent name>] [-agentdesc <desc>] [-agenthost <host name>] [-agentport <port>] [-agentusr <usr>/<pwd>] Altering the Agent Attributes The AVCTL alter_agent command can be used to modify the attributes of an agent. Oracle Database 10g: Implementing Audit Vault
60
Installing Audit Vault in a RAC Configuration: Overview
Install Oracle Clusterware. Install Audit Vault by using Advanced Installation mode: The Audit Vault name is used to derive the Oracle RAC database SID of each Oracle RAC node. Specify the nodes on which to install Audit Vault. Installing Audit Vault in a RAC Configuration: Overview When you install Audit Vault in a RAC configuration, you must use Advanced Installation mode. In a RAC installation, the Audit Vault name is used to derive the Oracle RAC database SID of each Oracle RAC node and is the DB_NAME value used in the database service name. When you install on a clustered system, the Node Selection page is displayed during the installation. Specify the nodes on which Audit Vault is to be installed. Oracle Database 10g: Implementing Audit Vault
61
Performing Postinstallation Security Tasks
Perform the following security tasks after installing the Audit Vault Server and Audit Vault Agent: Unlock and reset user passwords. Basic installation: SYS, SYSTEM, SYSMAN, and DBSNMP are given the same password as the Audit Vault Administrator. Basic installation: <AV Administrator>DVO and <AV Administrator>DVA are given the same password as the Audit Vault Administrator. Enable SYSDBA connections if appropriate for your configuration. Performing Postinstallation Security Tasks These topics are discussed in detail in the lesson titled “Administering Audit Vault Security.” Oracle Database 10g: Implementing Audit Vault
62
Postinstallation Tasks: Configuring the Audit Vault Components
Perform the following tasks after installing the Audit Vault Server and Audit Vault Agent: Use the AVORCLDB utility to set up Oracle Database sources and collectors. Use the AVCTL utility to start the collectors. Use the AVCTL utility or Enterprise Manager Database Control to manage and monitor the Audit Vault system. Postinstallation Tasks: Configuring the Audit Vault Components After installing the Audit Vault Server and Audit Vault Agent(s), use the Audit Vault utilities to configure sources and collectors. These topics are discussed in the lesson titled “Configuring Sources and Collectors.” Use the AVCTL utility where appropriate to manage and monitor the Audit Vault Server and Audit Vault Agents. The Audit Vault Server database instance can be managed and monitored with Enterprise Manager. Refer to the lesson titled “Managing Your Audit Vault Configuration” for additional information. Oracle Database 10g: Implementing Audit Vault
63
Managing the Audit Vault Console
Use the following AVCTL commands to manage the Audit Vault Console: Description Command Shut down the Audit Vault Console. avctl stop_av Start the Audit Vault Console. avctl start_av View the status of the Audit Vault Console. avctl show_av_status Managing the Audit Vault Console Use the AVCTL stop_av command to shut down the Audit Vault Console. Use the AVCTL start_av command to start the Audit Vault Console. To check the status of the Audit Vault Console, execute the AVCTL show_av_status command, as shown in the following example: av_1]$ avctl show_av_status AVCTL started TZ set to Etc/GMT-7Oracle Audit Vault 10g Database Control Release Oracle Audit Vault 10g is running. Logs are generated in directory /u01/app/oracle/product/10.2.0/av_1/av/log Oracle Database 10g: Implementing Audit Vault
64
Managing the Audit Vault Agent OC4J
Use the following AVCTL commands to manage the Audit Vault Agent OC4J: Description Command Shut down the Audit Vault Agent OC4J. avctl stop_oc4j Start the Audit Vault Agent OC4J. avctl start_oc4j Managing the Audit Vault Agent OC4J Execute the AVCTL start_oc4j and stop_oc4j commands on the Audit Vault Agent location. Agent Oracle Database 10g: Implementing Audit Vault
65
Managing the Audit Vault Agent
Use the following AVCTL commands to manage the Audit Vault Agent: Description Command Stop the Audit Vault Agent. avctl stop_agent Start the Audit Vault Agent. avctl start_agent Check the status of the Audit Vault Agent. avctl show_agent_status Managing the Audit Vault Agent Use the AVCTL stop_agent command to stop the agent and all its collectors. Specify the agent name as an argument to the command: avctl stop_agent -agentname avagent1 Use the AVCTL start_agent command to start the agent when necessary. You must supply the agent name as an argument to the command: avctl start_agent -agentname avagent1 Use the AVCTL show_agent_status command to check the status of the agent: avctl show_agent_status -agentname avagent1 Note: Execute the AVCTL commands to manage the agent from the Audit Vault Server location. Oracle Database 10g: Implementing Audit Vault
66
Starting the Components in an Audit Vault Configuration
Source database host: Start the listener. Start the source database instance. Audit vault agent host: Start the agent OC4J: avctl start_oc4j. Audit Vault Server host: Start the Audit Vault Server database instance. Start the Audit Vault Server: avctl start_av. Start the Audit Vault Agent: avctl start_agent. Start the collectors: avctl start_collector. Starting the Components in an Audit Vault Configuration If you experience a failure on your host systems, restart the listeners, database instances, and Audit Vault components as described in the slide. If components need to be shut down, shut them down in the reverse order. Oracle Database 10g: Implementing Audit Vault
67
Oracle Database 10g: Implementing Audit Vault 1 - 69
Summary In this lesson, you should have learned how to: Describe types of Audit Vault installations Install the Audit Vault Server Install the Audit Vault Agent Oracle Database 10g: Implementing Audit Vault
68
Oracle Database 10g: Implementing Audit Vault 1 - 70
Practice 2: Overview This practice covers the following topics: Installing the Audit Vault Server Installing the Audit Vault Agent Oracle Database 10g: Implementing Audit Vault
69
Administering Audit Vault Security
70
Oracle Database 10g: Implementing Audit Vault 1 - 72
Objectives After completing this lesson, you should be able to: Manage users and roles in the Audit Vault Server database Manage user authentication metadata Secure Audit Vault Server and Audit Vault Agent communication Use Oracle Advanced Security encryption Oracle Database 10g: Implementing Audit Vault
71
Oracle Audit Vault: Security Components
Audit Vault Agent Audit Vault Server OC4J OC4J HTTP policy settings and management commands Database client Database client Configuration/management tools Config/management tools Logs Logs Collectors Audit repository DBAUD OSAUD SQL*Net Audit trail data Collector attributes Oracle Audit Vault: Security Components Oracle Audit Vault includes Oracle Database Vault and Advanced Security. As described in this lesson, there are additional measures that you can take to further secure your Audit Vault system. Source SQL*Net Policy provision Wallet password: Agent user password Wallet password: AV admin password Oracle Database 10g: Implementing Audit Vault
72
Integration with Oracle Database Vault
The Audit Vault Server database is protected by Oracle Database Vault features. Database Vault is used to: Prevent access to audit data by privileged users Prevent unauthorized changes to the Audit Vault Server database Set access controls Integration with Oracle Database Vault Database Vault is used to protect data in the Audit Vault Server database from access by a database administrator (DBA) and any other privileged user, to enforce protection of database structures from unauthorized change, and to set a variety of access controls to implement dynamic and flexible security requirements. Oracle Database 10g: Implementing Audit Vault
73
Managing Users and Roles in the Audit Vault Server
Manage Oracle Database users in Audit Vault Manage Audit Vault Server users and roles AV Admin Managing Users and Roles in the Audit Vault Server The next section includes the following topics: Managing Oracle Database users in an Audit Vault Server database instance Managing Audit Vault Server users Understanding Audit Vault Server roles AV Auditor Oracle Database 10g: Implementing Audit Vault
74
Unlocking and Resetting User Passwords
Passwords are set as follows: Basic installation: SYS, SYSTEM, SYSMAN, and DBSNMP have the same password as the Audit Vault Administrator user. Advanced Installation: SYS, SYSTEM, SYSMAN, and DBSNMP passwords are specified during installation. The password that is specified for the Audit Vault Administrator is assigned to <AV Administrator>DVA and <AV Administrator>DVO users during a Basic installation. Change passwords per your company policies. Unlock accounts. Unlocking and Resetting User Passwords Evaluate your organization’s password requirements. During a Basic installation of the Audit Vault Server, a password is provided for the Audit Vault Administrator user. This same password is assigned to the SYS, SYSTEM, SYSMAN, and DBSNMP users. During an Advanced installation of the Audit Vault Server, you are given an opportunity to change the passwords for these users. If your organization requires that passwords should be reset, you can use SQL commands or Enterprise Manager to change the passwords. During an Advanced installation of the Audit Vault Server, you are prompted for passwords for the Database Vault owner and Database Vault account manager users. The passwords default to the same password that is used for the Audit Vault Administrator during a Basic installation. Again, consider the requirements of your organization for resetting these passwords. In addition, many of the other users are locked after installation and must be unlocked before use. Oracle Database 10g: Implementing Audit Vault
75
Enabling SYSDBA Privilege Connections
The password file is created with SYS granted only the SYSOPER privilege and not the SYSDBA privilege. NOSYSDBA flag is set in the password file. Use the orapwd utility to create a new password file to enable SYSDBA connections. orapwd file=orapwav password=oracle entries=5 Enabling SYSDBA Privilege Connections Because the Audit Vault Server installation includes the installation of Database Vault, the password file contains the NOSYSDBA flag. You cannot log in to the Audit Vault Server database instance using the SYS account or any account with SYSDBA privilege using the AS SYSDBA clause. The following Oracle products and utilities that use the SYSDBA privilege may be affected: Oracle Data Guard and Oracle Data Guard Broker command-line utilities Oracle Recovery Manager (RMAN) command-line utility Oracle Real Application Clusters svrctl utility Oracle Data Pump utilities Automatic Storage Management (ASM) command-line utilities Oracle Enterprise Manager Database Control You can reenable the ability to connect with the SYSDBA privilege by re-creating the password file with the NOSYSDBA flag set to N. Refer to the Oracle Database Vault Administrator’s Guide for additional information. Oracle Database 10g: Implementing Audit Vault
76
Oracle Database 10g: Implementing Audit Vault 1 - 78
Audit Vault Roles Role Name Role Description AV_ADMIN Configures and manages an Oracle Audit Vault installation. Granted to a named user during installation of the Audit Vault Server. AV_AGENT Manages agents and collectors. AVCA add_agent grants this role to a user created in the Audit Vault Server database. AV_ARCHIVER Archives and deletes audit data from the Audit Vault Server database. Can be granted to a specified user for manual archiving. AV_AUDITOR Manages audit settings and alerts. Reviews audit reports. Granted to a named user during installation of the Audit Vault Server. AV_SOURCE Used by the collector to send audit data to the AV Server for a given source. AVORCLDB add_source grants this role. Audit Vault Roles When you install the Audit Vault Server, five roles are created in the Audit Vault Server database: AV_ADMIN: The user granted this role has the ability to configure and manage an Oracle Audit Vault installation. The AV_ADMIN role is granted the AV_AGENT and AV_AUDITOR roles. During installation of the Audit Vault Server, a user is created and granted the AV_ADMIN role. AV_AGENT: This role enables a user to manage agents and collectors. Prior to the installation of the Audit Vault Agent, you must create the Audit Vault Agent user in the Audit Vault Server database. When you execute the AVCA add_agent command, the Audit Vault Agent user is granted the AV_AGENT role. AV_ARCHIVER: This role enables the user to archive raw audit data. You can create a user and grant this role for manual archiving of audit data. AV_AUDITOR: This role enables the user to manage audit settings and alerts. In addition, this role contains the privileges that are required to manage the data warehouse objects. When you install the Audit Vault Server, you can specify a username for the Audit Vault Auditor. This user is granted the AV_AUDITOR role. AV_SOURCE: This role contains the privileges that are needed to configure sources for the collection of audit data. Oracle Database 10g: Implementing Audit Vault
77
Audit Vault Database Users
Audit Vault Administrator Name specified during installation Granted AV_ADMIN role Audit Vault Auditor Granted AV_AUDITOR role Database Vault account manager Default (basic install): <AV Administrator name>DVA Granted DV_ACCTMGR role Database Vault owner Default (basic install): <AV Administrator name>DVO Granted DV_OWNER role Audit Vault Database Users During installation of the Audit Vault Server, you provide a name and password for the Audit Vault Administrator. This user is granted the AV_ADMIN role to configure and manage Audit Vault Server components. As an option during installation, you can specify a username and password for the Audit Vault auditor. This user is granted the AV_AUDITOR role to manage the audit settings and analyze the audit information. The Database Vault account manager is created during installation of Audit Vault. The name for this user is created automatically during a Basic installation by appending “DVA” to the name that you specify for the Audit Vault Administrator user. When you perform an Advanced installation, you specify the name for the Database Vault account manager. The Database Vault owner is also created automatically during a Basic installation by appending “DVO” to the name that you specify for the Audit Vault Administrator user. When you perform an Advanced installation, you specify the name for the Database Vault owner. Oracle Database 10g: Implementing Audit Vault
78
Audit Vault Database Users
AVSYS user Created during installation of the Audit Vault Server Owns all Audit Vault objects Default tablespace: SYSAUX Should not be unlocked Audit Vault Database Users (continued) The AVSYS user is created when the Audit Vault Server is installed. AVSYS owns all of the Audit Vault objects, including the audit repository tables and the data warehouse tables. The objects are stored in the SYSAUX tablespace. Oracle Database 10g: Implementing Audit Vault
79
Understanding Audit Vault Usage
Auditor (internal) Audit Admin AV reports AV alerts AV audit policies Audit archiver AV archival Monitor, detect, alert and report (AV_AUDITOR) Audit Vault Archive (AV_ARCHIVER) AV Audit Collection AV Admin AV Admin Collect (AV_SOURCE) AV Admin Understanding Audit Vault Usage Audit Vault has the following uses: Monitoring, detecting, alerting, and reporting: An auditor sets and views audit policies and alerts. An auditor who has been granted the AV_AUDITOR role creates, views, and manages detail and summary reports for compliance purposes. A security officer may inspect and further evaluate Audit Vault alerts logged that are raised due to the occurrence of events that meet specific alert conditions. Archiving: The Audit Vault Administrator can create a user and grant the AV_ARCHIVER role to that user so that the user can manually archive the data. Collecting: A source user is created and granted the AV_SOURCE role. The Audit Vault Administrator who has been granted the AV_ADMIN role can add the source and collector to the Audit Vault Server. Administrating and managing: The Audit Vault Administrator (granted the AV_ADMIN role) monitors and manages the audit data consolidation operation. This user also configures collectors and monitors overall Audit Vault system security. AV Security Administration and management (AV_ADMIN) Oracle Database 10g: Implementing Audit Vault
80
Managing User Authentication Metadata: Audit Vault Server Wallet
The Audit Vault Console uses a wallet in the $ORACLE_HOME/network/admin/avwallet directory of the Audit Vault Server. This wallet is: Created during installation of the Audit Vault Server Used to store the Audit Vault Administrator credentials Used by the management service in the Audit Vault Console to communicate with the Audit Vault Server database instance Managing User Authentication Metadata: Audit Vault Server Wallet When you install the Audit Vault Server, the Advanced Security option is installed. Oracle Advanced Security includes the following features: Oracle wallets: Stores public key infrastructure (PKI) credentials Oracle Wallet Manager: Manages your Oracle wallets The Oracle wallet is a password-protected container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by the secure sockets layer (SSL). The Oracle Wallet Manager can perform tasks such as wallet creation, certificate request generation, and certificate import into the wallet. During installation of the Audit Vault Server, a wallet is created in the $ORACLE_HOME/network/admin/avwallet directory. The wallet contains the Audit Vault Administrator credentials (username and password). This username is used by the Audit Vault Console to communicate with the Audit Vault Server. Oracle Database 10g: Implementing Audit Vault
81
Managing User Authentication Metadata: Audit Vault Agent Wallet
The Audit Vault Agent uses a wallet in its $ORACLE_HOME/network/admin/avwallet directory. This wallet is: Created during installation of the Audit Vault Agent Used to store the Audit Vault Agent user credentials Used to store the source database user credentials Used by the Audit Vault Agent to obtain configuration data from the source database Used by collectors to communicate with the source database Managing User Authentication Metadata: Audit Vault Agent Wallet During installation of the Audit Vault Agent, a wallet is created in the $ORACLE_HOME/network/admin/avwallet directory. The wallet contains the Audit Vault Agent user credentials and is used by the Audit Vault Agent to obtain configuration data from the source database. The wallet also contains the source database user credentials used by the collectors to communicate with the source database. The credentials are used by the collectors to connect to the source, retrieve metadata, and retrieve audit settings. In addition, the DBAUD collector uses the credentials to obtain audit records. The credentials are also used for starting and stopping the REDO collector. Oracle Database 10g: Implementing Audit Vault
82
Securing Audit Vault Server and Audit Vault Agent Communication
There are two communication channels between the Audit Vault Server and the Audit Vault Agent: HTTP-based: Used for management communication OCI-based: Used to retrieve configuration information and to send audit records Use the HTTPS protocol on the HTTP channel to encrypt data for additional security: SSL is configured for the mutual authentication between the Audit Vault Server management service and the Audit Vault Agent(s). X.509 certificates that are provided by a certificate authority are used for authentication. Encrypt the OCI channel by using OCI over TCPS. Securing Audit Vault Server and Audit Vault Agent Communication You can secure the HTTP communication channel between the Audit Vault Server and the Audit Vault Agent by using the HTTPS protocol to encrypt data. The OCI-based channel can be encrypted by using OCI over TCPS. This is a feature of Advanced Security and is included with Audit Vault. Oracle Database 10g: Implementing Audit Vault
83
Securing the HTTP-Based Communication Channel
Use the AVCA secure_av command on the Audit Vault Server host to configure mutual authentication between the Audit Vault Server and the Audit Vault Agent: Use the AVCA secure_av command with the remove argument to disable mutual authentication: avca secure_av -avkeystore <key store location> -avkeystorepwd <key store password> -avtruststore <trust store location> avca secure_av -remove Securing the HTTP-Based Communication Channel The AVCA secure_av command secures the Audit Vault Server by enabling mutual authentication with the Audit Vault Agent. This command converts the HTTP channel to HTTPS. The secure_av command arguments are as follows: avkeystore: Key store location for Audit Vault avkeystorepwd: Key store password for Audit Vault avtruststore: Trust store location for Audit Vault The key store is a repository that includes: Certificates identifying trusted entities. A private key and the matching certificate The trust store is a key store that contains certificates of trusted entities only. Note: The key store and certificate must exist on the Audit Vault Server host before you execute this command. You can use the $ORACLE_HOME/jdk/bin/keytool command to generate a key store. Oracle Database 10g: Implementing Audit Vault
84
Securing the HTTP-Based Communication Channel
Use the AVCA secure_agent command on the Audit Vault Agent host to enable mutual authentication with the Audit Vault Server: Use the AVCA secure_agent command with the remove argument to disable mutual authentication: avca secure_agent -agentkeystore <key store location> -agentkeystorepwd <key store password> -avdn <Audit Vault distinguished name> -agentdn <Audit Vault Agent distinguished name> avca secure_agent -remove Securing the HTTP-Based Communication Channel (continued) The AVCA secure_agent command secures the Audit Vault Agent by enabling mutual authentication with the Audit Vault Server. The secure_agent command arguments are as follows: agentkeystore: Key store location for this agent agentkeystorepwd: Key store password for this agent avdn: Distinguished name (DN) of Audit Vault agentdn: DN of this Audit Vault Agent Note: The key store and certificate must exist on the Audit Vault Agent host before you execute this command. You can use the $ORACLE_HOME/jdk/bin/keytool command to generate a key store. Agent Oracle Database 10g: Implementing Audit Vault
85
Using Oracle Advanced Security Option Encryption
Encrypt the data that travels across the network from the Audit Vault database sources and the Audit Vault Server. Source Agent Using Oracle Advanced Security Option Encryption When you install the Audit Vault Server, the Advanced Security option is installed. You can use Oracle Advanced Security encryption to encrypt the audit data as it travels across the network from the system on which the Audit Vault Agent is installed to the Audit Vault Server database instance. Oracle Database 10g: Implementing Audit Vault
86
Setting Encryption Parameters on the Audit Vault Server Host
Set the following parameters in the $ORACLE_HOME/network/admin/sqlnet.ora file: SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED SQLNET.ENCRYPTION_SERVER = REQUIRED SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA-1) SQLNET.ENCRYPTION_TYPES_SERVER = (AES256) SQLNET.CRYPTO_SEED = "<10-70 random characters>" Setting Encryption Parameters on the Audit Vault Server Host To encrypt the data, set the following parameters in the $ORACLE_HOME/network/admin/sqlnet.ora file on the Audit Vault Server host: SQLNET.CRYPTO_CHECKSUM_SERVER: Specifies the desired data integrity behavior when a client (or another server acting as a client) connects to this server. Set the value to REQUIRED. SQLNET.ENCRYPTION_SERVER: Specifies the desired encryption behavior when a client (or a server acting as a client) connects to this server. Set the value to REQUIRED. SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER: Specifies a list of data integrity algorithms that this server (or client to another server) uses, in the order of intended use. Refer to the Oracle Database Advanced Security Administrator’s Guide for a complete list of values. SQLNET.ENCRYPTION_TYPES_SERVER: Specifies a list of encryption algorithms used by this server in the order of intended use. Refer to the Oracle Database Advanced Security Administrator’s Guide for a complete list of values. SQLNET.CRYPTO_SEED: Used to seed the random key generator. Set this parameter by entering from 10 to 70 random characters. Oracle Database 10g: Implementing Audit Vault
87
Setting Encryption Parameters on the Audit Vault Agent Host
Set the following parameters in the $ORACLE_HOME/network/admin/sqlnet.ora file: SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUIRED SQLNET.ENCRYPTION_CLIENT = REQUIRED SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA-1) SLQNET.ENCRYPTION_TYPES_CLIENT = (AES256) SQLNET.CRYPTO_SEED = "<10-70 random characters>" Setting Encryption Parameters on the Audit Vault Agent Host To encrypt the data, set the following parameters in the $ORACLE_HOME/network/admin/sqlnet.ora file on the Audit Vault Agent host: SQLNET.CRYPTO_CHECKSUM_CLIENT: Specifies the desired data integrity behavior when this client (or server acting as a client) connects to a server. Set the value to REQUIRED. SQLNET.ENCRYPTION_CLIENT: Specifies the desired encryption behavior when this client (or server acting as a client) connects to a server. Set the value to REQUIRED. SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT: Specifies a list of data integrity algorithms that this client (or server acting as a client) uses. Refer to the Oracle Database Advanced Security Administrator’s Guide for a complete list of values. SLQNET.ENCRYPTION_TYPES_CLIENT: Specifies a list of encryption algorithms used by this client (or server acting as a client). Refer to the Oracle Database Advanced Security Administrator’s Guide for a complete list of values. SQLNET.CRYPTO_SEED: Used to seed the random key generator. Set this parameter by entering from 10 to 70 random characters. Agent Oracle Database 10g: Implementing Audit Vault
88
Oracle Database 10g: Implementing Audit Vault 1 - 90
Summary In this lesson, you should have learned how to: Manage users and roles in the Audit Vault Server database Manage user authentication metadata Secure Audit Vault Server and Audit Vault Agent communication Use Oracle Advanced Security encryption Oracle Database 10g: Implementing Audit Vault
89
Oracle Database 10g: Implementing Audit Vault 1 - 91
Practice 3: Overview This practice covers the following topics: Creating a new password file to allow SYSDBA connections Using Oracle Advanced Security encryption Oracle Database 10g: Implementing Audit Vault
90
Configuring Sources and Collectors
91
Oracle Database 10g: Implementing Audit Vault 1 - 93
Objectives After completing this lesson, you should be able to: Configure audit sources Configure collectors for an Oracle database Start agents and collectors Oracle Database 10g: Implementing Audit Vault
92
Oracle Database Collectors
DBAUD: Retrieves audit records from: Database audit trail stored in SYS.AUD$ Fine-grained audit trails stored in SYS.FGA_LOG$ OSAUD: Retrieves audit records from the OS audit file REDO: Uses Oracle LogMiner and Streams to retrieve logical change records (LCRs) from the redo log files Oracle Database Collectors There are three collectors for an Oracle database. Each collector retrieves audit records from a different location in the Oracle database or from a file used by the Oracle database instance. Oracle Database 10g: Implementing Audit Vault
93
Using the DBAUD Collector
Collects audit records from the audit trail when AUDIT_TRAIL is set to DB,EXTENDED Collects data from the SYS.AUD$ and SYS.FGA_LOG$ tables Collects: DDL and DML statements SQL text Successes and/or failures as specified in audit settings Can be remote from the source database and the Audit Vault Server Using the DBAUD Collector The DBAUD collector retrieves records from the Oracle Database audit trail that is written to when the AUDIT_TRAIL initialization parameter is set to DB, EXTENDED. Note: Setting AUDIT_TRAIL to DB, EXTENDED enables the population of the SQLBIND and SQLTEXT columns of the SYS.AUD$ table. Audit records are retrieved from the database audit trail (SYS.AUD$) and from the fine-grained auditing trail (SYS.FGA_LOG$). Oracle Database 10g: Implementing Audit Vault
94
Oracle Database Collectors: DBAUD
Audit Vault Agent Audit Vault Server OC4J OC4J Database client Database client Configuration/management tools Config/management tools Logs Logs Collectors DBAUD OSAUD Audit repository Oracle Database Collectors: DBAUD The DBAUD collector retrieves audit records through an Oracle Call Interface (OCI) connection to the source database and sends them to the Audit Vault Server. Source AUD$ Audit trail records FGA_LOG$ Oracle Database 10g: Implementing Audit Vault
95
Using the OSAUD Collector
Collects audit records from the audit trail when AUDIT_TRAIL is set to AUDIT_TRAIL = OS Collects mandatory audit records from the operating system audit trail Collects: DDL and DML statements SYS privilege usage Successes and/or failures as specified in audit settings Independent process running on source host Using the OSAUD Collector The OSAUD collector is an independent process that must execute on the source database host. Mandatory audit records are written by the source Oracle database to operating system files and are retrieved by the OSAUD collector. Additionally, when the database audit trail and fine-grained audit trail audit events are written to operating system audit files, the OSAUD collector retrieves the records. Note: In a RAC configuration, each instance should save its audit trail to a disk that is local to the machine. You configure multiple OSAUD collectors (one for each instance). Oracle Database 10g: Implementing Audit Vault
96
Oracle Database Collectors: OSAUD
Audit Vault Agent Audit Vault Server OC4J OC4J Database client Database client Configuration/management tools Config/management tools Logs Logs Collectors DBAUD OSAUD Audit repository Oracle Database Collectors: OSAUD The OSAUD collector reads and parses the operating system audit files and sends the audit records to the Audit Vault Server. Source OS files Audit trail records Oracle Database 10g: Implementing Audit Vault
97
Oracle Database Collectors: REDO
Uses Streams technology to retrieve logical change records (LCRs) from the redo log files Collects: Committed DDL and DML statements SYS privilege usage Before-and-after values (successes only) Oracle Database Collectors: REDO The REDO collector uses Oracle Streams technology to retrieve logical change records (LCRs) from the redo logs. It converts the LCRs into audit records and sends them to the Audit Vault Server. Oracle Database 10g: Implementing Audit Vault
98
Oracle Database Collectors: REDO
Audit Vault Agent Audit Vault Server OC4J OC4J Database client Database client Configuration/management tools Config/management tools Logs Logs Collectors Audit repository Streams capture Streams apply Source LCRs Oracle Database Collectors: REDO (continued) On the source database, a Streams capture process uses LogMiner to extract new LCRs from the REDO logs based on capture rules that are defined by the user. A Streams propagate process sends the LCRs to the Audit Vault Server. A Streams apply handler converts these LCRs into audit records and stores them in the Audit Vault Server audit repository. Redo logs Streams propagate Oracle Database 10g: Implementing Audit Vault
99
Setting Initialization Parameters for REDO Collectors
Set parameters as suggested for the REDO collector: ANY_VALUE SGA_MAX_SIZE SGA_TARGET ANY_VALUE UNDO_RETENTION TRUE GLOBAL_NAMES 5000 _SPIN_COUNT 4 - ANY_VALUE JOB_QUEUE_PROCESSES _JOB_QUEUE_INTERVAL Parameter Recommended Value Setting Initialization Parameters for REDO Collectors When you execute the AVORCLDB verify command for the REDO collector, initialization parameters are checked for appropriate values. You receive a message indicating that the parameters should be changed if they do not meet the minimum values as described in the slide. Note: The setting of _SPIN_COUNT and _JOB_QUEUE_INTERVAL is required due to the use of Streams. Oracle Database 10g: Implementing Audit Vault
100
Basic Steps to Configure Sources and Deploy Collectors
Create a user in the source database that will be used by the Audit Vault collectors. Execute the zarsspriv.sql script to grant privileges to the source user you created in the previous step. Create a user in the Audit Vault Server database to be used to insert data from the source database. Grant proxy connect privileges to the Audit Vault Source user through the Audit Vault Agent user. Use the AVORCLDB add_source command to add the source database to the Audit Vault Server. Use the AVORCLDB add_collector command to add each collector to the Audit Vault Server. Basic Steps to Configure Sources and Deploy Collectors Follow the steps listed in the slide to configure the source databases and deploy the collectors. Each step is reviewed in detail on the pages that follow. Oracle Database 10g: Implementing Audit Vault
101
Basic Steps to Configure Sources and Deploy Collectors
Use the AVORCLDB setup command to set up the source. Use the AVCTL start_agent command to start the Audit Vault Agent (if it is not started). Use the AVCTL start_collector command to start the collectors. Oracle Database 10g: Implementing Audit Vault
102
Creating the Source User in the Source Database
Create a user in the Oracle source database: Grant privileges to the user: SQL> CREATE USER <srcusr> IDENTIFIED BY <password>; > <srcusr> <mode> Creating the Collector User in the Source Database You must create a user on the source database for the collectors, as shown in the following example: SQL> CREATE USER avcolluser IDENTIFIED BY avcollpass; Use the $ORACLE_HOME/av/scripts/streams/source/zarsspriv.sql script to grant the user the necessary privileges. This script is available in the Audit Vault Server and Audit Vault Agent ORACLE_HOME directories. The script requires the following arguments: srcusr: User that will be granted the privileges mode: Keyword indicating the type of collector SETUP: OSAUD and DBAUD collectors REDO_COLL: REDO collectors Note: You must execute the script twice to set up all three types of collectors. Specify SETUP for the OSAUD and DBAUD collectors. Specify REDO_COLL for the REDO collector. Source Oracle Database 10g: Implementing Audit Vault
103
Understanding Audit Vault Users and Configuration Information
Database Vault Account Manager dbvacct1/dbvoracle_1 Audit Vault Server Audit Vault Administrator avadmin1/oracle_1 Database Vault Owner dbvowner1/dbvoracle_1 Audit Vault Auditor avaudit1/oracle_1 Audit Vault Agent user avagentuser/avagentpass Audit Vault source user avcolluser/avcollpass Agent name avagent1 Source Agent Understanding Audit Vault Users and Configuration Information As described on the previous page, you must create a user for the collectors on the source database. In the example, the avcolluser user is created with the password avcollpass. Oracle Database 10g: Implementing Audit Vault
104
Creating the Audit Vault Server Source User
Create a user in the Audit Vault Server database: Grant the proxy connect privilege to the user: SQL> CREATE USER <avsrcusr> IDENTIFIED BY <password>; SQL> ALTER USER <avsrcusr> > GRANT CONNECT THROUGH <agentusr>; Creating the Audit Vault Server Source User Create a user in the Audit Vault Server database that will be used to insert data for the source database, as shown in the following example: SQL> CREATE USER avsrc1user IDENTIFIED BY avsrc1pass; Grant the proxy connect privilege through the Audit Vault Agent user to the Audit Vault Server source user: SQL> ALTER USER avsrc1user GRANT CONNECT THROUGH avagentuser; Note: You must perform this task as the Database Vault Account Manager user. Oracle Database 10g: Implementing Audit Vault
105
Understanding Audit Vault Users and Configuration Information
Source Agent Audit Vault Server Audit Vault Administrator avadmin1/oracle_1 Audit Vault Auditor avaudit1/oracle_1 Audit Vault Agent user avagentuser/avagentpass Audit Vault source user avcolluser/avcollpass Audit Vault Server source user avsrc1user/avsrc1pass Agent name avagent1 Database Vault Account Manager dbvacct1/dbvoracle_1 Database Vault Owner dbvowner1/dbvoracle_1 Understanding Audit Vault Users and Configuration Information As described on the previous page, you must create a user in the Audit Vault Server database that will be used to insert data for the source database. In the example, the AVSRC1USER is created with the password AVSRC1PASS. Oracle Database 10g: Implementing Audit Vault
106
Verifying the Source Database
Use AVORCLDB to verify that the source database is compatible with the type of collector you are configuring: Source database is automatically verified when you add the collector. avorcldb verify -src <host:port:service> -srcusr <username>/<password> -colltype <type of collectors> Verifying the Source Database Use the AVORCLDB verify command to verify that the source database is compatible with the collectors that you are configuring. The verify command accepts the following arguments: src <host:port:service>: Source database host name, listener port number, and Oracle Net service name (separated by colons) srcusr <usr>/<pwd>: Username and password of a user on the source database that has the SYSDBA role colltype: Comma-separated list of Oracle collectors: DBAUD, OSAUD, REDO, ALL Note: Do not insert a space after the collector name. Oracle Database 10g: Implementing Audit Vault
107
Adding the Source Database
Use the AVORCLDB add_source command to add the source database to the Audit Vault Server: avorcldb add_source -src <host:port:service> -srcusr <usr>/<pwd> -avsrcusr <usr> -agentname <agentname> [-srcname <srcname>] [-desc <desc>] Adding the Source Database You must provide information about the source database to the Audit Vault Server. The AVORCLDB add_source command requires the following arguments: src: Source database connection information, including the host name, listener port, and service name srcusr: Username and password of the user defined in the source database that is used to collect audit data avsrcusr: User defined in the Audit Vault Server database that is used to send audit data agentname: Agent name that is used to configure policy management. The following arguments to the add_source command are optional: srcname: Source database name (if not specified, defaults to the global database name) desc: Source database description The output of the add_source command includes the “source name,” as in the following sample output: Source name (srcname): ORCL.ORACLE.COM The source name is used as input to other Audit Vault utility commands such as: avorcldb add_collector avctl start_collector Oracle Database 10g: Implementing Audit Vault
108
Configuring Collectors
Use the AVORCLDB add_collector command to add collectors to the Audit Vault Server: avorcldb add_collector -srcname <srcname> -srcusr <usr>/<pwd> -agentname <agentname> -colltype [OSAUD|DBAUD|REDO] [-collname <collname>] [-desc <desc>] [-avsrcusr <usr>/<pwd>] [-av <host:port:service>] [-instname <instname>] Configuring and Starting Collectors The AVORCLDB add_collector command requires the following arguments: srcname: Source name (must be specified in uppercase) srcusr: Source username and password agentname: Audit Vault Agent name colltype: OSAUD, DBAUD or REDO The following argument is required if the collector type is REDO: avsrcusr: Audit Vault source user av: Connection information for the DB link from the source database to Audit Vault in the form <host:port:service> The following arguments to the add_collector command are optional: collname: Collector name (defaults to <colltype>_Collector) desc: Collector description instname: Instance name for a RAC configuration Oracle Database 10g: Implementing Audit Vault
109
Setting Up the Source Database for the Audit Vault Agent
Use the AVORCLDB setup command to update the tnsnames.ora file, store credentials in the wallet, and verify the connection using the wallet: avorcldb setup -srcname <srcname> -srcusr <usr>/<pwd> -wpwd <pwd> Setting Up the Source Database for the Audit Vault Agent On the Audit Vault Agent host, execute the AVORCLDB setup command to update the tnsnames.ora file, store credentials in the wallet, and verify the connection using the wallet. The AVORCLDB setup command accepts the following arguments: srcname: Source name srcusr: Source database username and password wpwd: Wallet password of the agent user who is granted the AV_AGENT role Execute the setup command, as shown in the following example: av_agent_1]$ avorcldb setup \ > -srcname ORCL.ORACLE.COM \ > -srcusr avcolluser/avcollpass \ > -wpwd avagentpass updated tnsnames.ora with alias [SRCDB1] to source database adding credentials for user avcolluser for connection[SRCDB1] Storing user credentials in wallet... Create credential oracle.security.client.connect_string2 done. verifying SRCDB1 connection using wallet av_agent_1]$ Agent Oracle Database 10g: Implementing Audit Vault
110
Starting the Audit Vault Agent
Use the AVCTL start_agent command to start the Audit Vault Agent: avctl start_agent -agentname <agent name> Starting the Audit Vault Agent Use the AVCTL start_agent command to start the Audit Vault Agent. Provide the agent name as an argument to the command. Oracle Database 10g: Implementing Audit Vault
111
Oracle Database 10g: Implementing Audit Vault 1 - 113
Starting Collectors Use the AVCTL start_collector command to start the collectors: avctl start_collector -collname <collector name> -srcname <source name> Starting Collectors The AVCTL start_collector command requires the following arguments: collname: Collector name srcname: Source name Oracle Database 10g: Implementing Audit Vault
112
Viewing Collector Information
The user with the AV_ADMIN role can view information about the collectors through the Audit Vault Console. A list of the collectors and general information about each collector is displayed on the Collector Configuration Management page. You can access detailed information about each collector by selecting the collector and then clicking View. The View Collector Details page displays the attributes of the collector. You can modify the attributes through the Audit Vault Console or by using the AVORCLDB alter_collector command (as described later in the lesson). AV Administrator Oracle Database 10g: Implementing Audit Vault
113
Viewing DBAUD Collector Details
The attributes for the DBAUD collector are as follows: AUDAUDIT_ACTIVE_SLEEP_TIME: Sleep time between retrieval if there are new records. Default value is 1000. AUDAUDIT_AUDIT_VAULT_ALIAS: Alias for the Audit Vault Server database. This attribute cannot be changed. AUDAUDIT_DELAY_TIME: Delay time for time-based retrieval of records from the database specified in seconds (9.2 FGA_LOG$ and 9.2 RAC AUD$). Default value is 20. AUDAUDIT_MAX_PROCESS_RECORDS: Batch size of audit records sent to Audit Vault at one time. Default value is This attribute should be changed only according to directions from Oracle Support. AUDAUDIT_SLEEP_TIME: Sleep time between retrieval if there are no new records. Default value is 5000. AUDAUDIT_SORT_POLICY: Set to always, never, or start. AUDAUDIT_SOURCE_ALIAS: Alias for the source database. This attribute cannot be changed. AV Administrator Oracle Database 10g: Implementing Audit Vault
114
Viewing OSAUD Collector Details
AV Administrator Viewing OSAUD Collector Details The attributes for the OSAUD collector are as follows: OSAUDIT_AUDIT_VAULT_ALIAS: Audit Vault Server alias name that is required to start OSAUD collector by Collection Manager. This attribute cannot be changed. OSAUDIT_CHANNEL_TYPE: Channel type of OSAUD or EVTLOG. This attribute cannot be changed. OSAUDIT_DEFAULT_FILE_DEST: Default location of audit files, given as absolute path OSAUDIT_FILE_DEST: Current location of audit files, given as absolute path OSAUDIT_LOG_LEVEL: Level of logging in the collector log OSAUDIT_MAX_PROCESS_RECORDS: Maximum records to be parsed at one time in one OS collector channel OSAUDIT_MAX_PROCESS_TIME: Maximum processing time to spend on one OS collector channel OSAUDIT_NLS_CHARSET: NLS setting of source database OSAUDIT_NLS_LANGUAGE: NLS setting of source database OSAUDIT_NLS_TERRITORY: NLS setting of source database Oracle Database 10g: Implementing Audit Vault
115
Viewing REDO Collector Details
The attributes for the REDO collector are as follows: AV.DATABASE.NAME: Audit Vault Server global database name. This attribute cannot be changed. STRCOLL_DBPORT: Streams source database port number STRCOLL_DBSERVICE: Streams source database instance name. This attribute cannot be changed. STRCOLL_HEARTBEAT_TIME: Heartbeat time to keep the capture process alive STRCOLL_SRCADM_ALIAS: Streams admin alias at source. This attribute cannot be changed. STRCOLL_SRCADM_NAME: Streams admin name at source. This attribute cannot be changed. AV Administrator Oracle Database 10g: Implementing Audit Vault
116
Altering the Collector Attributes
Use the AVORCLDB alter_collector command to modify the attributes of a collector: avorcldb alter_collector -srcname <srcname> -collname <collname> [<attrname>=<attrvalue>...<attrname>=<attrvalue>] Altering the Collector Attributes You can modify the attributes of each collector by using the AVORCLDB alter_collector command. Oracle Database 10g: Implementing Audit Vault
117
Oracle Database 10g: Implementing Audit Vault 1 - 119
Summary In this lesson, you should have learned how to: Configure audit sources Configure collectors for an Oracle database Start agents and collectors Oracle Database 10g: Implementing Audit Vault
118
Oracle Database 10g: Implementing Audit Vault 1 - 120
Practice 4: Overview This practice covers the following topics: Creating an Audit Vault user in the source database Creating a source user in the Audit Vault Server database Verifying that the source database will support the collectors Adding the source database to the Audit Vault Server Configuring Oracle Database collectors Oracle Database 10g: Implementing Audit Vault
119
Managing Audit Settings
120
Oracle Database 10g: Implementing Audit Vault 1 - 122
Objectives After completing this lesson, you should be able to: Describe database auditing Use the Audit Vault Console to retrieve audit settings Use the Audit Vault Console to define and provision audit settings Oracle Database 10g: Implementing Audit Vault
121
Using Audit Vault to Collect Audit Data
Audit Vault supports the collection of the following types of audit information: Oracle Database audit records stored in the audit trail: Statement Object Privilege Oracle Database fine-grained auditing records Before-and-after values stored in the redo log files AV Auditor Using Audit Vault to Collect Audit Data The Audit Vault Server supports collection of audit data from several Oracle Database sources. Each of these sources are reviewed in detail in this lesson. Oracle Database 10g: Implementing Audit Vault
122
Oracle Database Auditing
Oracle Database 10g includes the following audit features: Database auditing Fine-grained auditing (FGA) Value-based auditing implemented through triggers Oracle Database Auditing Oracle Database 10g provides three different types of auditing. The administrator can audit all actions that take place in the database. It is important to remember that capturing and storing information about what is happening in the system increases the amount of work the system must do. Auditing should be focused so that only those events that are of interest are captured. Properly focused auditing has minimal impact on system performance. Improperly focused auditing can significantly affect performance. Standard database auditing captures several pieces of information about an audited event, including whether the event occurred, when it occurred, which user caused the audited event, and which client machine the user was on when the event happened. Use fine-grained auditing (FGA) to audit SQL statements. FGA extends standard database auditing, capturing the actual SQL statement that was issued rather than only the fact that the action occurred. FGA is discussed in detail later in this lesson. Use value-based auditing to audit changes (INSERTs, UPDATEs, or DELETEs) to data. Value-based auditing extends standard database auditing, capturing not only the fact that the audited event occurred, but the actual values that were inserted, updated, or deleted. Value-based auditing is implemented through database triggers. Oracle Database 10g: Implementing Audit Vault
123
Comparing Types of Auditing
Fixed set of data, including the SQL statement SQL statements (INSERT, UPDATE, DELETE, and SELECT) based on content Fine-grained auditing (FGA) Administrator defined Data changed by DML statements Value-based auditing Fixed set of data Statement execution Privilege use Standard database auditing What is in the audit trail? What is audited? Type of auditing Comparing Types of Auditing The table in the slide defines the Oracle Database auditing features and identifies what type of information is stored in the audit trail. Oracle Database 10g: Implementing Audit Vault
124
Database Auditing Enable database auditing. 1
Initialization parameter file DBA User Execute command. 2 Specify audit options. Database Server process Audit options Generate audit trail. 3 Review audit information. Audit trail Database Auditing After you enable database auditing and specified auditing options (login events, exercise of system and object privileges, or the use of SQL statements), the database server begins collecting audit information. When the AUDIT_TRAIL initialization parameter is set to OS, the audit records are stored in the operating system’s audit system. In a Windows environment, this is the event log. In a UNIX or Linux environment, audit records are stored in a file. The location of that file is specified with the AUDIT_FILE_DEST initialization parameter. When AUDIT_TRAIL is set to DB or to DB,EXTENDED, audit records are written to the database audit trail, SYS.AUD$. There are several views that you can use to view the audit records, including DBA_AUDIT_TRAIL. If AUDIT_TRAIL is set to XML or to XML,EXTENDED, the audit records are written to XML files in the directory that is specified by the AUDIT_FILE_DEST initialization parameter. The V$XML_AUDIT_TRAIL view enables you to view all the XML files in this directory. Note: You must set AUDIT_TRAIL to DB,EXTENDED or to OS for use in an Audit Vault configuration. 4 Maintain audit trail. OS audit trail Oracle Database 10g: Implementing Audit Vault
125
Oracle Database 10g: Implementing Audit Vault 1 - 127
Enabling Auditing Set the nondynamic AUDIT_TRAIL initialization parameter on the source database to one of the following values for use in an Audit Vault configuration: DB,EXTENDED: Directs all audit records to the database audit trail. Populates the SQLBIND and SQLTEXT CLOB columns of SYS.AUD$. OS: Directs all audit records to the operating system audit trail. Enabling Auditing To use database auditing, you must first set the nondynamic AUDIT_TRAIL initialization parameter to point to a storage location for audit records. Oracle Database 10g: Implementing Audit Vault
126
Enabling Auditing on the Source Database
Set AUDIT_TRAIL either to DB_EXTENDED or to OS: Enabling Auditing on the Source Database You must enable database auditing before you specify audit settings. Setting AUDIT_TRAIL=DB,EXTENDED enables you to use the Audit Vault DBAUD collector. Setting AUDIT_TRAIL=OS enables you to use the Audit Vault OSAUD collector. ALTER SYSTEM SET audit_trail=db,extended SCOPE=SPFILE; Oracle Database 10g: Implementing Audit Vault
127
Performing Database Auditing
Statement auditing Selective auditing of related groups of DDL/DML statements regarding a particular type of database structure or schema object Can be specified for all users or for only a select list Privilege auditing Auditing of statements that require the use of a system privilege Schema object auditing Auditing of all SELECT and DML statements that require the use of schema object privileges For all users; cannot be set for a specific list of users Performing Database Auditing There are three Oracle Database auditing methods: Statement: This method of auditing is broad in nature and enables you to audit several types of related actions with one setting. Statement auditing can be restricted to specific users or can be specified for all users. Privilege: This method enables you to audit the use of system privileges. Privilege auditing can be restricted to specific users or can be specified for all users. Schema object: This method of auditing is very focused and enables you to audit specific statements for a particular schema object. Schema object auditing cannot be restricted to specific users. Instead, it always applies to all users of the database. Oracle Database 10g: Implementing Audit Vault
128
Focusing Database Auditing: Statement Execution
WHENEVER SUCCESSFUL: Successful statement execution WHENEVER NOT SUCCESSFUL: Unsuccessful statement execution Both successful and unsuccessful execution Focusing Database Auditing: Statement Execution For statement, privilege, and schema object auditing, you can selectively audit the execution of statements. You can specify that statements should be audited only when the execution attempt is successful or unsuccessful, or both. This gives you the ability to monitor actions when the audited statements do not complete successfully. When you specify auditing options through the SQL AUDIT command, the WHENEVER SUCCESSFUL and WHENEVER NOT SUCCESSFUL clauses are used to control when the audit information is recorded. The default is both successful and unsuccessful statements. Note: This setting can also be specified through the Audit Vault Console and Enterprise Manager Database Control. Oracle Database 10g: Implementing Audit Vault
129
Specifying WHENEVER SUCCESSFUL
AUDIT SELECT ON hr.employees WHENEVER SUCCESSFUL; DBA sets audit options. DBA Audit record SELECT * FROM hr.employees; 198 Donald Oconnell DOCONNEL JUN-99 SH_CLERK … Audit trail SELECT * FROM hr.employees; ERROR at line 1: ORA-00942: table or view does not exist Specifying WHENEVER SUCCESSFUL When you specify the WHENEVER SUCCESSFUL clause, an audit record is written to the audit trail only when the audited option execution is successful. Oracle Database 10g: Implementing Audit Vault
130
Specifying WHENEVER NOT SUCCESSFUL
AUDIT SELECT ON hr.employees WHENEVER NOT SUCCESSFUL; DBA sets audit options. DBA SELECT * FROM hr.employees; 198 Donald Oconnell DOCONNEL JUN-99 SH_CLERK … Audit trail Audit record SELECT * FROM hr.employees; ERROR at line 1: ORA-00942: table or view does not exist Specifying WHENEVER NOT SUCCESSFUL When you specify the WHENEVER NOT SUCCESSFUL clause, an audit record is written to the audit trail only when the audited option execution is unsuccessful. Oracle Database 10g: Implementing Audit Vault
131
Focusing Database Auditing: Number of Audit Records Generated
BY ACCESS: Records audit information each time the statement is executed BY SESSION: Records audit information only once for each session Focusing Database Auditing: Number of Audit Records Generated You can control how many audit records are recorded for a specified audit option through the BY SESSION and BY ACCESS clauses of the AUDIT command. When you specify BY ACCESS, each execution of an auditable operation generates a separate audit record. BY SESSION specifies that a single audit record will be recorded for each session for each auditable operation. Note: This setting can also be specified through the Audit Vault Console and Enterprise Manager Database Control. Oracle Database 10g: Implementing Audit Vault
132
Oracle Database 10g: Implementing Audit Vault 1 - 134
Specifying BY SESSION AUDIT SELECT ON hr.employees BY SESSION; DBA sets audit options. DBA SELECT * FROM hr.employees; 198 Donald Oconnell DOCONNEL JUN-99 SH_CLERK … … Audit trail Specifying BY SESSION When you specify BY SESSION, only one audit record is written to the audit trail regardless of how many times the auditable operation is executed. Oracle Database 10g: Implementing Audit Vault
133
Oracle Database 10g: Implementing Audit Vault 1 - 135
Specifying BY ACCESS AUDIT SELECT ON hr.employees BY ACCESS; DBA sets audit options. DBA SELECT * FROM hr.employees; 198 Donald Oconnell DOCONNEL JUN-99 SH_CLERK … … Audit trail Specifying BY ACCESS When you specify BY ACCESS, an audit record is written to the audit trail for each execution of the auditable operation. Oracle Database 10g: Implementing Audit Vault
134
Fine-Grained Auditing
Monitors data access on the basis of content Audits SELECT, INSERT, UPDATE, DELETE, and MERGE Can be linked to one or more columns in a table or view May fire a procedure Is administered with the DBMS_FGA package and through the Audit Vault Console Fine-Grained Auditing Database auditing records that an operation has occurred, but does not capture information about the statement that caused the operation. Fine-grained auditing extends that capability to allow the capture of actual SQL statements that query or manipulate data. Fine-grained auditing also allows auditing to be more narrowly focused than standard or value-based database auditing. Fine-grained auditing audit options can be focused by individual columns in a table or view, and can even be conditional so that audits are captured only if certain administrator-defined specifications are met. More than one relevant column is supported for a fine-grained auditing policy. By default, if any one of these columns is present in the SQL statement, it is audited. DBMS_FGA.ALL_COLUMNS and DBMS_FGA.ANY_COLUMNS are provided to audit on the basis of whether any or all of the relevant columns are used in the statement. Use the DBMS_FGA PL/SQL package to create an audit policy on the target table or view. If any of the rows returned from a query block match the audited column and the specified audit condition, then an audit event causes an audit record to be created and stored in the audit trail. Optionally, the audit event can also execute a procedure. Fine-grained auditing automatically focuses auditing at the statement level; as a result, a SELECT statement that returns thousands of rows generates only one audit record. Note: Implementation of fine-grained auditing policies through Audit Vault Console is described later in the lesson. Oracle Database 10g: Implementing Audit Vault
135
Creating a Fine-Grained Auditing Policy
DBMS_FGA.ADD_POLICY ( object_schema => 'HR', object_name => 'EMPLOYEES', policy_name => 'audit_emps_salary', audit_condition => 'department_id=10', audit_column => 'SALARY, COMMISION_PCT', handler_schema => 'secure', handler_module => 'log_emps_salary', enable => TRUE, statement_types => 'SELECT' ); SELECT name, job_id FROM employees; SELECT name, salary FROM employees WHERE department_id=10; Creating a Fine-Grained Auditing Policy The example in the slide shows the use of the DBMS_FGA.ADD_POLICY procedure to create a fine-grained auditing policy. The procedure accepts the following arguments: Policy name: You assign each fine-grained auditing policy a name when you create it. The example in the slide names the policy AUDIT_EMPS_SALARY by using the following argument: policy_name => 'audit_emps_salary‘ Audit condition: The audit condition is a SQL predicate that defines when the audit event must fire. In the slide example, all rows in department 10 are audited by using the following condition argument: audit_condition => 'department_id = 10‘ Audit column: The audit column defines the data that is audited. An audit event occurs if this column is included in the SELECT statement or if the audit condition allows the selection. The example in the slide audits two columns by using the following argument: audit_column => 'SALARY,COMMISION_PCT‘ This argument is optional. If it is not specified, only the AUDIT_CONDITION argument determines whether an audit event must occur. SECURE.LOG_EMPS_SALARY EMPLOYEES Oracle Database 10g: Implementing Audit Vault
136
Audited DML Statement: Considerations
Records are audited if the FGA predicate is satisfied and the relevant columns are referenced. DELETE statements are audited regardless of any specified columns. MERGE statements are audited with the underlying INSERT or UPDATE generated statements. UPDATE hr.employees SET salary = 10 WHERE commission_pct = 90; UPDATE hr.employees SET salary = 10 WHERE employee_id = 111; Audited DML Statement: Considerations With a fine-grained auditing policy defined for DML statements, a DML statement is audited if data rows (both new and old) being manipulated meet the policy predicate criteria. However, if relevant columns are also specified in the policy definition, the statement is audited when the data meets the fine-grained auditing policy predicate and the statement references the relevant columns that are defined. For DELETE statements, specifying relevant columns during policy definition is not useful because all columns in a table are touched by a DELETE statement. Therefore, a DELETE statement is always audited regardless of the relevant columns. MERGE statements are supported by fine-grained auditing. The underlying INSERT or UPDATE statements are audited if they meet any defined INSERT or UPDATE fine-grained auditing policies. Using the previously defined fine-grained auditing policy, the first statement is audited whereas the second one is not. Oracle Database 10g: Implementing Audit Vault
137
Fine-Grained Auditing Guidelines
To audit all statements, use a null condition. Policy names must be unique. The audited table or view must already exist when you create the policy. If the audit condition syntax is invalid, an ORA error is raised when the audited object is accessed. If the audited column does not exist in the table, no rows are audited. If the event handler does not exist, no error is returned and the audit record is still created. Fine-Grained Auditing Guidelines For the SELECT statements, fine-grained auditing captures the statement itself and not the actual rows. However, when fine-grained auditing is combined with Flashback Query, the rows can be reconstructed as they existed at that point in time. For more information about the DBMS_FGA package, see the Oracle Database, PL/SQL Packages and Types Reference. Oracle Database 10g: Implementing Audit Vault
138
Maintaining the Audit Trail
The audit trail should be maintained. Use the following best-practice guidelines: Review and store old records. Prevent storage problems. Avoid loss of records. Maintaining the Audit Trail Each type of audit trail must be maintained. Basic maintenance must include reviewing the audit records and removing older records from the database or operating system. Audit trails can grow to fill the available storage. If the file system is full, the system may crash or just cause performance problems. If the database audit trail fills the tablespace, audited actions do not complete. If the audit trail fills the system tablespace, the performance of other operations is affected before audit operations stop. The audit trail for standard auditing is stored in the SYS.AUD$ table. The audit trail for fine-grained auditing is the SYS.FGA_LOG$ table. Both tables are created in the SYSTEM tablespace by default. Oracle Database 10g: Implementing Audit Vault
139
Auditing SYSDBA and SYSOPER Operations
Users with the SYSDBA or SYSOPER privilege can connect when the database is closed. The audit trail must be stored outside the database. Connections as SYSDBA or SYSOPER are always audited. Enable additional auditing of SYSDBA or SYSOPER actions with the AUDIT_SYS_OPERATIONS initialization parameter. Control the audit trail location with the AUDIT_FILE_DEST initialization parameter. Auditing SYSDBA and SYSOPER Operations The SYSDBA and SYSOPER users have privileges to start up and shut down the database. Because they may make changes while the database is closed, the audit trail for these privileges must be stored outside the database. The Oracle Database server captures login events by the SYSDBA and SYSOPER users automatically. This provides a way to track authorized or unauthorized SYSDBA and SYSOPER actions. The Oracle Database server does not capture anything other than the login events unless auditing is specifically enabled. Enable auditing of the SYSDBA and SYSOPER users by setting the AUDIT_SYS_OPERATIONS initialization parameter to TRUE. If the SYS operations are audited, the AUDIT_FILE_DEST initialization parameter controls the storage location of the audit records. On a Windows platform, the audit trail defaults to the Windows event log. On UNIX or Linux platforms, audit records are stored in the following location: $ORACLE_HOME/rdbms/audit Oracle Database 10g: Implementing Audit Vault
140
Collecting Data from the Redo Log Files
Audit repository Streams capture Streams apply Source LCRs Redo logs Streams propagate Collecting Data from the Redo Log Files On the source database, a Streams capture process uses LogMiner to extract new logical change records (LCRs) from the redo log files based on capture rules that are defined by the user. A Streams propagate process sends the LCRs to the Audit Vault Server. A Streams apply handler converts these LCRs into audit records and stores them in the Audit Vault Server audit repository. Oracle Database 10g: Implementing Audit Vault
141
Understanding the Streams Capture Process
Streams events can be enqueued in two ways. Implicitly: Log-based capture of DML and DDL Explicitly: Direct enqueue of user messages Events are enqueued in a staging area. SGA Streams pool Rules Understanding the Streams Capture Process The capture process is a background process that looks for the occurrence of specific events in the redo stream. These events can be DML or DDL events: Rows inserted, updated, or deleted in particular tables Changes to the table structure Object creation statements All events for Oracle Streams (database changes and application-generated messages) are placed in a staging area. These events can be enqueued in two ways. Implicitly: A capture process mines DML and DDL events from the redo logs. The capture process then uses the rules in its positive and negative rule sets to determine which events to put in the buffer queue in memory and which events to discard. Explicitly: Applications explicitly generate events and enqueue them in the staging queue in the database. Additionally, events can be explicitly enqueued that may (or may not) be associated with particular data events. These events, often referred to as messages, can be placed in the same staging queues as DML and DDL events and can be routed through the Oracle Streams environment in the same manner as data change events. Enqueue Capture Oracle Database 10g: Implementing Audit Vault
142
Using Audit Vault Console to Manage Audit Settings
Use the Audit Vault Console to define audit settings: Statement Object Privilege FGA Capture rules Use the Audit Vault Console to provision the audit settings to the source databases. Create a script containing the audit settings and execute it on the source databases. AV Auditor Using Audit Vault Console to Manage Audit Settings The Audit Vault Auditor can use the Audit Vault Console to easily define audit settings and provision them to the source databases. Oracle Database 10g: Implementing Audit Vault
143
Retrieving Audit Settings
Log in to the Audit Vault Console as the user who is granted the AV_AUDITOR role. On the Audit Settings page, click “Retrieve from Source” to retrieve the existing audit settings from the selected source database. AV Auditor Oracle Database 10g: Implementing Audit Vault
144
Defining Audit Settings
On the Create Privilege Audit page, select the system privileges to be audited. In the Audited By field, specify whether the audit setting is for all users or for only specific users. The Statement Execution Condition drop-down list enables you to select whether the audit setting is for successful or unsuccessful execution of the selected privileges or both. Select Access or Session in the DML Audit Granularity drop-down list to control how many audit records are written for each execution of the selected privileges. AV Auditor Oracle Database 10g: Implementing Audit Vault
145
Applying Audit Settings to the Source Database
On the Apply Audit Settings page, click Verify to request that Audit Vault verify that the specified audit settings (such as usernames and object names) are correct for the selected source database. Because the Audit Vault Agent is used for verification, you do not need to supply the username and password for the Verify operation. Provide a username and password to log on to the source database and provision the audit settings. You cannot provision audit settings as the SYS user. AV Auditor Oracle Database 10g: Implementing Audit Vault
146
Exporting Audit Settings to a File
The “Export as SQL” feature enables you to create a SQL file containing all the commands for the audit settings that you have selected through the Audit Vault Console. You can then execute the script on your source databases. This provides an easy method to provision audit settings to a large number of source databases. AV Auditor Oracle Database 10g: Implementing Audit Vault
147
Reconciling Retrieved Settings and Settings Specified in Audit Vault
If audit settings have been set in your source database through Enterprise Manager Database Control or SQL commands, you can retrieve the audit settings. When you view the audit settings, they will be flagged as “in use” and a red “x” will appear in the Needed column. If you want to maintain these audit settings, you must indicate so by clicking a red “x” to change it to a green check mark. AV Auditor Oracle Database 10g: Implementing Audit Vault
148
Copying Audit Settings from a Source Database
When you have more than one source database, you can copy audit settings from one of the source databases and then provision the same audit settings to other databases. Click Load to retrieve the settings. Then save the settings and provision them to other source databases. AV Auditor Oracle Database 10g: Implementing Audit Vault
149
Viewing Audit Event Category Information
The user with the AV_ADMIN role can view information about the Audit Event Categories through the Audit Vault Console. The Audit Event Categories are listed on the Audit Event Category Management page. Detailed information about each Audit Event Category can be obtained by selecting the Audit Event Category and then clicking View. Activity Reports, which can be viewed in the Audit Vault Console by the Audit Vault Auditor, are also organized by the audit event categories. Activity Reports are discussed in the lesson titled “Using Audit Vault Reports.” AV Administrator Oracle Database 10g: Implementing Audit Vault
150
Viewing Audit Event Category Detail
Detailed information (including a list of audit events) is visible on the View Audit Event Category page. AV Admin Oracle Database 10g: Implementing Audit Vault
151
Oracle Database 10g: Implementing Audit Vault 1 - 154
Summary In this lesson, you should have learned how to: Understand database auditing Use the Audit Vault Console to retrieve audit settings Use the Audit Vault Console to define and provision audit settings Oracle Database 10g: Implementing Audit Vault
152
Oracle Database 10g: Implementing Audit Vault 1 - 155
Practice 5: Overview This practice covers the following topics: Enabling auditing on the source database Defining audit settings Provisioning audit settings Oracle Database 10g: Implementing Audit Vault
153
Configuring Alerts
154
Oracle Database 10g: Implementing Audit Vault 1 - 157
Objectives After completing this lesson, you should be able to: Enable alert processing Define and register alerts View alert information Oracle Database 10g: Implementing Audit Vault
155
Alert Processing Audit Vault Server Audit alerts Defines
Audit Policy System AV Auditor Evaluates audit record Collectors Audit trail records Audit Repository Alert queue DBAUD OSAUD Meets alert criteria REDO Subscribes Alert Processing Through the Audit Vault Console, you can specify conditions under which you want an alert to be raised when user actions violate specific audit policies. When an audit record is placed in the audit repository, it is evaluated against the specified alert conditions. If the record meets the specified criteria, an alert is raised. The alert information can be viewed through the Audit Vault Console by the Audit Vault Auditor. The alert is also written to an output queue in the Audit Vault Server database. You can write a subscriber to process this alert. AV Auditor Audit Vault Console Oracle Database 10g: Implementing Audit Vault
156
Specifying Audit Vault Event Categories
Creation and management of data items and resource elements OBJECT MANAGEMENT Collection of an invalid audit record INVALID AUDIT RECORD Error conditions or exceptional events EXCEPTION Association with a data item or resource for its content or services DATA ACCESS Management of user/service accounts and profiles ACCOUNT MANAGEMENT Management of Audit service AUDIT COMMAND Management of applications or code on a system Description APPLICATION MANAGEMENT Event Category Name Specifying Audit Vault Event Categories Audit events are organized into audit event categories (as described in the slide). On the Audit Vault Console Overview page (Dashboard), you can view alert information by audit event category. You can also request audit reports by using an audit event category as a filter. Oracle Database 10g: Implementing Audit Vault
157
Specifying Audit Vault Event Categories
Anything that does not belong to the other categories UNKNOWN Creation and use of user sessions on the system USER SESSION Management of services that are system level SYSTEM MANAGEMENT Management of association with peer systems (DBLINKs) PEER ASSOCIATION Use of services or applications SERVICE AND APPLICATION ACCESS Management of roles and privileges granted to users or services Description ROLE AND PRIVILEGE MANAGEMENT Event Category Name Oracle Database 10g: Implementing Audit Vault
158
Enabling and Disabling Alert Processing
The Audit Vault Administrator enables and disables alert processing on the Alerts Settings page. AV Administrator Oracle Database 10g: Implementing Audit Vault
159
Oracle Database 10g: Implementing Audit Vault 1 - 162
Creating an Alert Rule Creating an Alert Rule The Audit Vault Auditor defines alert rules by using the Audit Vault Console. Access the Audit Alerts page by clicking the Audit Policy tab and then clicking Alerts. Click Create to access the Create Alert Rule page. Provide the following information: Alert: Alert name Description: Alert description Alert Severity: Critical or warning Audit Source Type: Audit source type (ORCLDB) Audit Source: Source database; can be set to null for all sources Audit Event Category: Audit event category for this alert Additional alert conditions can be specified by selecting Advanced. AV Auditor Oracle Database 10g: Implementing Audit Vault
160
Specifying the Basic Alert Condition
When you specify Basic on the Create Alert Rule page, continue your alert creation by specifying the following in the Basic Alert Condition section: User: Username (schema) for the object owner Table: Table name Audit Event: Select an audit event from the drop-down menu. Audit Event Status: Specify whether the alert should be raised when the audit event is successful, unsuccessful, or either successful or unsuccessful. AV Auditor Oracle Database 10g: Implementing Audit Vault
161
Specifying an Advanced Alert Condition
In the Advanced Alert Condition section, you can specify a Boolean condition for the alert. The fields on this page are context sensitive. You choose the event from the “Select an event to insert it in the condition” drop-down list. In addition, you select additional attributes from the “Select an attribute to insert it in the condition” drop-down list. The selected event and attribute(s) are then placed in the Condition box. Refer to the Oracle Audit Vault Auditor’s Guide for detailed information about audit event attributes and source event IDs that are used in the Boolean condition. AV Auditor Oracle Database 10g: Implementing Audit Vault
162
Viewing Alert information About the Overview Page
When you log in to the Audit Vault Console as the Audit Vault Auditor (the user who is granted the AV_AUDITOR role), the Overview page is displayed. The Overview page provides the following information about alerts: Alert Severity Summary Summary of Alert Activity Top Five Audit Sources by Number of Alerts Alerts by Audit Event Category AV Auditor Oracle Database 10g: Implementing Audit Vault
163
Oracle Database 10g: Implementing Audit Vault 1 - 166
Viewing Audit Alerts Viewing Audit Alerts To retrieve specific information about defined alerts, specify filter criteria on the Audit Alerts page. AV Auditor Oracle Database 10g: Implementing Audit Vault
164
Oracle Database 10g: Implementing Audit Vault 1 - 167
Summary In this lesson, you should have learned how to: Enable alert processing Define and register alerts View alert information Oracle Database 10g: Implementing Audit Vault
165
Oracle Database 10g: Implementing Audit Vault 1 - 168
Practice 6: Overview This practice covers the following topics: Enabling alert processing Defining and registering alerts Viewing alert information Oracle Database 10g: Implementing Audit Vault
166
Managing the Audit Vault Data Warehouse
167
Oracle Database 10g: Implementing Audit Vault 1 - 170
Objectives After completing this lesson, you should be able to: Configure the data warehouse refresh schedule Configure the data warehouse retention time Manage the loading and purging of data in the data warehouse Monitor data warehouse loading, refreshing, and purging operations Oracle Database 10g: Implementing Audit Vault
168
Audit Vault Data Warehouse: Overview
AV Auditor Raw audit data table Analysis Reporting Mining Audit warehouse Audit Vault Server database Audit Vault Data Warehouse: Overview The Audit Vault data warehouse facilitates data analysis of collected audit data. Audit data is stored in a raw audit data table that is optimized for INSERT performance. A staging area is used for the data extraction, transformation, and loading (ETL) process that prepares the raw data for loading into the data warehouse. The data warehouse contains raw data and materialized views (summary data). Oracle Database 10g: Implementing Audit Vault
169
Audit Vault Data Warehouse: Schema
EVENT_DIM TIME_DIM CLIENT_HOST_DIM CONTEXT_DIM CLIENT_TOOL_DIM AUDIT_EVENT_FACT SOURCE_DIM USER_DIM TARGET_DIM Audit Vault Data Warehouse: Schema The Audit Vault data warehouse is implemented as a star schema. The most natural way to model a data warehouse is as a star schema, in which only one join establishes the relationship between the fact table and any one of the dimension tables. The AUDIT_EVENT_FACT fact table, in the center of the star, is further described by its attributes (dimensions) that form its points. In the audit data warehouse, each fact represents an audit record and each dimension represents unique information about that audit record that further describes the audit record. The AUDIT_EVENT_FACT fact table is linked to each dimension table by its foreign key. The fact table contains the audit record ID, some attributes of the audit record for report generation, and the foreign keys to the dimensions. The AUDIT_EVENT_FACT fact table is partitioned by time, with each partition containing data for one day. Note: All data warehouse objects are owned by the AVSYS user and are stored in the SYSAUX tablespace. PRIVILEGES_DIM Oracle Database 10g: Implementing Audit Vault
170
Understanding Dimensions
Dimensions (composed of one or more hierarchies) categorize data to enable analysis. Dimensions represent 1:n relationships between columns or column groups as hierarchy levels. A dimension hierarchy shows level relationships. SOURCETYPE SOURCE Understanding Dimensions A dimension is a structure (comprising one or more hierarchies) that categorizes data to enable analysis. Dimensions represent natural 1-to-n relationships between columns or column groups (the levels of a hierarchy) that cannot be represented with constraint conditions. Rolling up refers to moving up a level in the hierarchy; drilling down refers to moving down a level in the hierarchy. Level relationships specify top-to-bottom ordering of information, from the most general (the root) to the most specific. A dimension hierarchy shows the parent-child relationship defined between the levels in a hierarchy. As an example, the source dimension (SOURCE_DIM) has two levels: the source type (SOURCETYPE) and the source (SOURCE). SOURCE is the child of its parent, SOURCETYPE. In Oracle Database, the dimensional information is stored in a dimension table. The dimension database object helps organize and group dimensional information into hierarchies. All the information about each level is stored in one row. Refer to the Oracle Database Data Warehousing Guide for detailed information about data warehousing structures. SOURCE_DIM Oracle Database 10g: Implementing Audit Vault
171
Audit Vault Data Warehouse: Dimensions
Dimension Name Description CLIENT_HOST_DIM Machine information (IP address, subnet, domain) CLIENT_TOOL_DIM Information about tools used to connect to source CONTEXT_DIM Context information related to the audit event EVENT_DIM Events performed on the source; category of events forms the hierarchy PRIVILEGES_DIM Information about privileges used during audit event SOURCE_DIM List of sources sending audit data TARGET_DIM Information about the object of the audit event TIME_DIM Hierarchy based on calendar year USER_DIM Information about user associated with the event Audit Vault Data Warehouse: Dimensions The Audit Vault data warehouse schema contains the following dimensions: CLIENT_HOST_DIM: Information about machines used by clients. The CLIENT_HOST_DIM table is the dimension table. CLIENT_TOOL_DIM: Information about tools used by the clients to connect to the source. The CLIENT_TOOL_DIM table is the dimension table. CONTEXT_DIM: Represents context information related to the audit event; provides multilevel context for an event. The CONTEXT_DIM table is the dimension table. EVENT_DIM: Various events that occur in any of the sources. The EVENT_DIM table is the dimension table. PRIVILEGES_DIM: Privileges that are used when an event occurred. The PRIVILEGES_DIM table is the dimension table. SOURCE_DIM: List of sources that send data to the Audit Vault Server. The SOURCE_DIM table is the dimension table. TARGET_DIM: Information about the object on which the audit event is performed. The TARGET_DIM table is the dimension table. TIME_DIM: Tracks actions over time. The TIME_DIM table is the dimension table. USER_DIM: Information about the user that performed the audit event. The USER_DIM table is the dimension table. Oracle Database 10g: Implementing Audit Vault
172
Oracle Database 10g: Implementing Audit Vault 1 - 175
Scheduling Data Warehouse Operations and Viewing Historical Information The Audit Vault Administrator performs the following tasks to manage the data warehouse: Manages the data warehouse refresh schedule Manages the retention period for data in the data warehouse Performs one-time operations: Load Refresh Purge Views historical information about data warehouse loading, refreshing, and purging Scheduling Data Warehouse Operations and Viewing Historical Information The Audit Vault Administrator schedules data warehouse operations and views historical information about the data warehouse operations. These topics are described in detail on the next few pages. AV Administrator Oracle Database 10g: Implementing Audit Vault
173
Configuring the Data Warehouse Refresh Schedule
Audit data is moved into the data warehouse fact table according to a specified schedule. The predefined schedule is named DW_REFRESH_WAREHOUSE. Specify a schedule for refreshing data in the data warehouse by using the following: AVCA set_warehouse_schedule command Audit Vault Console Configuring the Data Warehouse Refresh Schedule Data is moved from the raw audit data table into the data warehouse objects on a scheduled basis. When you install Audit Vault, a schedule is created to refresh the data warehouse once a day. You can specify a new schedule by using the AVCA set_warehouse_schedule command or by providing information through the Audit Vault Console interface. AV Admin Oracle Database 10g: Implementing Audit Vault
174
Viewing the Default Refresh Schedule
When you install the Audit Vault Server, a schedule named DW_REFRESH_SCHEDULE is created to refresh the data warehouse once a day. AV Admin Oracle Database 10g: Implementing Audit Vault
175
Using AVCA to Configure the Data Warehouse Refresh Schedule
Specify a predefined schedule: Specify a start date and repeat interval: avca set_warehouse_schedule -schedulename <schedule name> avca set_warehouse_schedule -startdate <start date> -rptintrv <repeat interval> Using AVCA to Configure the Data Warehouse Refresh Schedule The AVCA set_warehouse_schedule command can be used to specify a predefined schedule that you have created with Enterprise Manager Database Control or with the DBMS_SCHEDULER.CREATE_SCHEDULE procedure. DBMS_SCHEDULER.CREATE_SCHEDULE is defined as follows: DBMS_SCHEDULER.CREATE_SCHEDULE ( schedule_name IN VARCHAR2, start_date IN TIMESTAMP WITH TIMEZONE DEFAULT NULL, repeat_interval IN VARCHAR2, end_date IN TIMESTAMP WITH TIMEZONE DEFAULT NULL, comments IN VARCHAR2 DEFAULT NULL); Refer to the Oracle Database PL/SQL Packages and Types Reference for detailed information about using the DBMS_SCHEDULER.CREATE_SCHEDULE procedure. You can also create a refresh schedule by using the AVCA set_warehouse_schedule command and supplying the following arguments: startdate: Start date for a warehouse refresh job using the DD-MON-YY default format. Specify the –dateformat argument to use a different format. rptintrv: Repeat interval for the schedule expressed in calendaring syntax dateformat: Optional argument that is used to specify the date format for the -startdate argument AV Admin Oracle Database 10g: Implementing Audit Vault
176
Oracle Database 10g: Implementing Audit Vault 1 - 179
Using the Audit Vault Console to Configure the Data Warehouse Refresh Schedule Using the Audit Vault Console to Configure the Data Warehouse Refresh Schedule To configure the data warehouse refresh schedule, you must log in to the Audit Vault Console as a user with the AV_ADMIN role. After logging in to the Audit Vault Console, perform the following steps: 1. Click the Configuration tab. 2. Click the Warehouse tab to display the Warehouse Settings page, where you can specify a predefined schedule for refreshing the data warehouse. Note: You must create the schedule by using Enterprise Manager Database Control or the DBMS_SCHEDULER.CREATE_SCHEDULE procedure. 3. Select the schema name and the schedule name. 4. Click Apply. AV Admin Oracle Database 10g: Implementing Audit Vault
177
Oracle Database 10g: Implementing Audit Vault 1 - 180
Using the Audit Vault Console to Configure the Data Warehouse Refresh Schedule Using the Audit Vault Console to Configure the Data Warehouse Refresh Schedule (continued) As an alternative to specifying a predefined schedule, you can create a schedule by selecting Standard on the Warehouse Settings page and entering the required information. Note that the page will change based on the selected Frequency Type. After entering the required information for the schedule, click Apply. AV Administrator Oracle Database 10g: Implementing Audit Vault
178
Controlling the Data Warehouse Retention Time
Audit data is retained in the data warehouse for a specified length of time. Default length of time: one year Control the retention time of the fact table in the data warehouse by using the following: AVCA set_warehouse_duration command Audit Vault Console Controlling the Data Warehouse Retention Time Audit data is retained in the data warehouse fact table for a specified length of time. By default, the data is retained for one year. You can change the retention time by using the AVCA set_warehouse_duration command or the Audit Vault Console. AV Administrator Oracle Database 10g: Implementing Audit Vault
179
Configuring the Data Warehouse Retention Time
Use the AVCA set_warehouse_duration command: In the Audit Vault Console, specify retention time on the Warehouse Settings page: avca set_warehouse_retention -intrv <year-month interval> Configuring the Data Warehouse Retention Time Use the AVCA set_warehouse_retention command to control the amount of data kept online in the data warehouse fact table. The interval specified in the intrv argument specifies the lifetime of the partitions in the AUDIT_EVENT_FACT fact table. Partitions that are older than the specified time are removed during the next refresh of the fact table. AV Administrator Oracle Database 10g: Implementing Audit Vault
180
Loading Additional Data into the Data Warehouse
Use the AVCTL load_warehouse command: avctl load_warehouse -startdate <start date> -numofdays <num of days> Loading Additional Data into the Data Warehouse Use the AVCTL load_warehouse command to load data from the audit repository into the data warehouse tables. You may need to analyze data from a specific time period. The load_warehouse command enables you to load data from a time period of interest. The load_warehouse command accepts the following arguments: startdate: Specifies the start date for the data to be loaded into the data warehouse tables using the default format DD-MON-YY numofdays: Specifies the amount of data to load (expressed as the number of days) dateformat: (Optional) Specifies the date format for the startdate argument wait: (Optional) Specifies that the command should wait for the job to complete. If this argument is not specified, a job is started and the command returns control immediately. As described earlier in the lesson, the AUDIT_EVENT_FACT table is partitioned by time. When the load_warehouse command is executed, all of the updated partitions are flagged in an internal metadata table as being filled using the “load” operation. AV Admin Oracle Database 10g: Implementing Audit Vault
181
Refreshing the Data Warehouse
Use the AVCTL refresh_warehouse command: Click the Refresh Now button on the “History of Refreshing” page: avctl refresh_warehouse Refreshing the Data Warehouse The data warehouse tables are refreshed based on the schedule that is specified by using the AVCTL set_warehouse_schedule command or the Audit Vault Console. In addition, you can refresh the data warehouse tables with the data in the audit repository at any time by using the AVCTL refresh_warehouse command. The refresh_warehouse command accepts the optional wait argument. To use the Audit Vault Console to refresh the data warehouse: 1. Log in to the Audit Vault Console as the AV_ADMIN user. 2. Click Warehouse on the Management tab. 3. Click Refresh Now on the “Warehouse Load History: History of Refreshing” page. AV Administrator Oracle Database 10g: Implementing Audit Vault
182
Purging the Data Warehouse
Use the AVCTL purge_warehouse command: avctl purge_warehouse -startdate <start date> -numofdays <num of days> Purging the Data Warehouse Data is removed automatically from the data warehouse based on the retention setting (as described earlier in the lesson). The AVCTL purge_warehouse command can be used to remove data that is loaded with the load_warehouse command. The purge_warehouse command accepts the following arguments: startdate: Specifies the start date for the data to be removed using the default format DD-MON-YY numofdays: Specifies the amount of data to remove (express as the number of days) dateformat: (Optional) Specifies the date format for the startdate argument wait: (Optional) Specifies that the command should wait for the job to complete. If this argument is not specified, a job is started and the command returns control immediately. Note: The purge_warehouse command removes only data that was loaded by using the AVCTL load_warehouse command. Data that was loaded by using the AVCTL refresh_warehouse command is removed automatically based on the warehouse retention setting. AV Administrator Oracle Database 10g: Implementing Audit Vault
183
Monitoring Data Warehouse Operations
View the history of refresh, load, and purge operations: Monitoring Data Warehouse Operations In the Audit Vault Console, you can view historical information about the warehouse refresh, warehouse load, and warehouse purge operations. AV Administrator Oracle Database 10g: Implementing Audit Vault
184
Oracle Database 10g: Implementing Audit Vault 1 - 187
Summary In this lesson, you should have learned how to: Configure the data warehouse refresh schedule Configure the data warehouse retention time Manage loading and purging of data in the data warehouse Monitor data warehouse loading, refreshing, and purging operations Oracle Database 10g: Implementing Audit Vault
185
Oracle Database 10g: Implementing Audit Vault 1 - 188
Practice 7: Overview This practice covers the following topics: Configuring the refresh schedule Refreshing the data warehouse Oracle Database 10g: Implementing Audit Vault
186
Using Audit Vault Reports
187
Oracle Database 10g: Implementing Audit Vault 1 - 190
Objectives After completing this lesson, you should be able to: Use the Audit Vault Overview page (Dashboard) for reporting View activity reports and activity details View alert reports and alert details Oracle Database 10g: Implementing Audit Vault
188
Using the Audit Vault Overview Page (Dashboard)
The Overview page, also referred to as the Dashboard, is visible when you log in to the Audit Vault Console as a user with the AV_AUDITOR role. In the View Data For section, select the increment of time for which you want to view data. The default is the display of data from the last 24 hours. The Overview page contains a number of graphs and charts that provide summary information. In addition, you can drill down to more detailed information by clicking specific links in the graphs and charts. The Alert Severity Summary pie chart displays the distribution of alerts by severity level across all audit sources. You can click a section in the pie chart to drill down to a more detailed alert severity level report. The “Summary of Alert Activity” pie chart displays the distribution of alert activity by audit sources with alerts and by audit sources without alerts. Click a section in the pie chart to drill down to see the affected sources for all alert activity. Click the “Sources with alerts” link to view alerts that were raised as a result of audited activity. AV Auditor Oracle Database 10g: Implementing Audit Vault
189
Using the Audit Vault Overview Page
Using the Audit Vault Overview Page (continued) The “Top Five Audit Sources by Number of Alerts” bar graph displays the top five sources with the highest number of alerts and the distribution of alerts by severity level. Click a bar in the graph to drill down to view the alerts for a severity level for a particular source. The “Alerts by Audit Event Category” bar graph displays the number of alerts by audit event category. You can drill down on each event category for more detailed information. Click an audit event category link to the left of the graph to drill down to view all the alerts for that category. AV Auditor Oracle Database 10g: Implementing Audit Vault
190
Using the Audit Vault Overview Page
Using the Audit Vault Overview Page (continued) The “Activity by Audit Event Category” bar graph displays the frequency of events by audit event category. Click an audit event category link to the left of the graph to drill down to view all audit events for that category. AV Auditor Oracle Database 10g: Implementing Audit Vault
191
Viewing Activity Reports
The Activity Reports page is visible when you log in as the Audit Vault Auditor. On this page, you can access the Activity Overview report and the detailed activity reports. AV Auditor Oracle Database 10g: Implementing Audit Vault
192
Viewing the Activity Overview Report
The Activity Overview report displays all audit records created for the specified source. The data is sorted in descending order by time. You can specify selection criteria or filter information before generating the report. In the Activity Overview report, you can select a particular audit record and then click the Detail icon to view additional information. AV Auditor Oracle Database 10g: Implementing Audit Vault
193
Viewing Details from the Activity Overview Report
When you click the Detail icon on the Activity Overview report (shown on the previous page), the Detail report is displayed. The Detail report includes information from the audit record. Refer to the Audit Vault Console online help for a description of each of the displayed fields. AV Auditor Oracle Database 10g: Implementing Audit Vault
194
Viewing Specific Activity Reports
Predefined reports are based on audit event categories: Account Management Application Management Audit Command Data Access Exception Invalid Audit Record Object Management Peer Association Role and Privilege Management Viewing Specific Activity Reports You can view reports for specific activities as follows: Account Management Activity: Displays audit events for account management operations such as CREATE USER, ALTER USER, and ALTER PROFILE Application Management Activity: Displays audit events for application management operations such as ALTER FUNCTION and ALTER PACKAGE Audit Command Activity: Displays audit events for operations such as AUDIT DEFAULT, AUDIT OBJECT, and NOAUDIT DEFAULT Data Access Activity: Displays audit events for data manipulation operations such as DELETE, INSERT, and SELECT. You can also view the Data Trace report, which shows before and after values. Exception Activity: Displays audit events for errors and exceptions (such as network errors) Object Management Activity: Displays audit events for operations such as ALTER DIMENSION, ALTER INDEX, and ALTER MATERIALIZED VIEW Peer Association Activity: Displays audit events for operations such as CREATE DATABASE LINK and DROP DATABASE LINK Role and Privilege Management Activity: Displays audit events for operations such as CREATE ROLE, DROP ROLE, and GRANT OBJECT Oracle Database 10g: Implementing Audit Vault
195
Viewing Specific Activity Reports
Service and Application Access System Management Uncategorized User Session Viewing Specific Activity Reports (continued) Service and Application Access Activity: Displays audit events for operations such as CALL METHOD and EXECUTE PROCEDURE System Management Activity: Displays audit events for operations such as ALTER SYSTEM, ALTER TABLESPACE, and ANALYZE CLUSTER Uncategorized Activity: Displays audit events for uncategorized operations such as COMMENT and CREATE SUMMARY User Session Activity: Displays audit events for operations such as ALTER SESSION, COMMIT, and CREATE RESTORE POINT The Audit Vault Administrator can view information about the audit event categories through the Audit Vault Console. Detailed information (including a list of audit events for each category) is visible on the View Audit Event Category page. Oracle Database 10g: Implementing Audit Vault
196
Viewing Account Management Activity
The slide shows the Account Management Activity report, which displays audit events for account management operations such as CREATE USER, ALTER USER, and ALTER PROFILE. AV Auditor Oracle Database 10g: Implementing Audit Vault
197
Viewing User Session Activity
The slide shows the User Session Activity report, which displays audit events for operations such as logging on, ALTER SESSION, COMMIT, and CREATE RESTORE POINT. AV Auditor Oracle Database 10g: Implementing Audit Vault
198
Oracle Database 10g: Implementing Audit Vault 1 - 201
Viewing Alert Reports Viewing Alert Reports On the Alert Report page, specify criteria to filter alert information and display the specific information that you want to view. You can select values by clicking the flashlight icon or selecting a value from the drop-down menu. To display the report, click Go after providing the selection criteria. After the report is generated, you can click “Save as CSV” to save the report as a comma-separated values (CSV) file. The CSV file format is a delimited data format with fields separated by comma characters and records separated by new-line characters. You can also click the Detail icon to view an alert detail report. AV Auditor Oracle Database 10g: Implementing Audit Vault
199
Viewing Alert Report Details
The Detail report is accessed from the Alert Report as described on the previous page. The Detail report displays detailed information from the audit record. AV Auditor Oracle Database 10g: Implementing Audit Vault
200
Creating Custom Reports
Use Oracle reporting tools such as the following to create custom reports: Oracle Business Intelligence Suite Enterprise Edition Oracle BI Publisher Creating Custom Reports You can use Oracle tools such as Oracle Business Intelligence Suite Enterprise Edition to create custom reports. Oracle Business Intelligence Suite Enterprise Edition is a comprehensive suite of enterprise business intelligence (BI) products, delivering the full range of BI capabilities including: Interactive dashboards Full ad hoc Proactive intelligence and alerts Enterprise reporting Real-time predictive intelligence Disconnected analytics Oracle Business Intelligence Suite Enterprise Edition includes Oracle BI Publisher, which offers an efficient, scalable reporting solution. Oracle BI Publisher report formats can be designed using familiar tools such as Microsoft Word and Adobe Acrobat. Oracle BI Publisher can be used as a stand-alone reporting tool or integrated with Oracle Business Intelligence Suite Enterprise Edition. AV Auditor Oracle Database 10g: Implementing Audit Vault
201
Oracle Database 10g: Implementing Audit Vault 1 - 204
Summary In this lesson, you should have learned how to: Use the Audit Vault Dashboard for reporting View activity reports and activity details View alert reports and alert details Oracle Database 10g: Implementing Audit Vault
202
Oracle Database 10g: Implementing Audit Vault 1 - 205
Practice 8: Overview This practice covers the following topics: Viewing activity reports Viewing alert reports Oracle Database 10g: Implementing Audit Vault
203
Managing Your Audit Vault Configuration
204
Oracle Database 10g: Implementing Audit Vault 1 - 207
Objectives After completing this lesson, you should be able to: Monitor the Audit Vault Server SYSAUX tablespace Archived redo log destination Monitor the status of Audit Vault components Identify Audit Vault Server error and log files Identify Audit Vault Agent error and log files Update the wallet credentials AV Administrator Oracle Database 10g: Implementing Audit Vault
205
Monitoring the SYSAUX Tablespace
Audit Vault Server database objects are stored in SYSAUX: Monitoring the SYSAUX Tablespace Each Oracle database contains a SYSTEM tablespace and a SYSAUX tablespace. They are automatically created when the database is created. The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. One data file is associated with the SYSAUX tablespace when it is created. The data file is enabled for automatic extension in 10,240 KB increments up to a size of 32,767 MB. You should regularly monitor the use of space in the SYSAUX tablespace and add additional data files as appropriate for your configuration. Oracle Database 10g: Implementing Audit Vault
206
Monitoring the Archived Redo Log Destination
The Audit Vault Server database is in ARCHIVELOG mode by default. The Flash Recovery Area is used by default for archived redo log files. Increase size of the Flash Recovery Area. Monitor space usage. Monitoring the Archived Redo Log Destination The Audit Vault Server database is in ARCHIVELOG mode and uses the Flash Recovery Area for archived redo log files. The default size of the Flash Recovery Area is 2 GB. You must monitor the space usage in the Flash Recovery Area and increase it as appropriate to your configuration. Oracle Database 10g: Implementing Audit Vault
207
Viewing Flash Recovery Area Usage Information
Use Enterprise Manager to monitor the Flash Recovery Area: Viewing Flash Recovery Area Usage Information Review the Flash Recovery Area usage information on the Recovery Settings page of Enterprise Manager Database Control. Increase the size of the Flash Recovery Area if you are running out of space for archived redo log files. Oracle Database 10g: Implementing Audit Vault
208
Using AVCTL to View the Status of Audit Vault Components
View the status of the Audit Vault Agent: View the status of the Audit Vault Console: View the status of collectors: avctl show_agent_status -agentname <agent name> avctl show_av_status avctl show_collector_status -collname <collector name> -srcname <source name> Using AVCTL to View the Status of Audit Vault Components View the status of the Audit Vault Agent, as shown in the following example: av_1]$ avctl show_agent_status -agentname avagent1 AVCTL started Getting agent metrics... Agent is running Metrics retrieved successfully. View the status of the Audit Vault Console, as shown in the following example: av_1]$ avctl show_av_status TZ set to Etc/GMT-7Oracle Audit Vault 10g Database Control Release Oracle Audit Vault 10g is running. Logs are generated in directory /u01/app/oracle/product/10.2.0/av_1/av/log Oracle Database 10g: Implementing Audit Vault
209
Managing Audit Vault Server Log Files
Log and error files are located in the Audit Vault Server $ORACLE_HOME/av/log directory. File Name Contents Maintenance avca.log Information about creation of collectors, starting and stopping of agents and collectors Delete when Audit Vault Server is shut down avorcldb.log AVORCLDB commands Delete at any time av_client-%g.log.n Collection metrics from the agent Managing Audit Vault Server Log Files The Audit Vault Server generates log files that provide current status and diagnostic information. The log files should be monitored and periodically deleted to control the amount of used disk space. The Audit Vault Server generates the following log files: avca.log: Contains information about the creation of the collectors. It also contains a record of the starting and stopping of agents and collectors. avorcldb.log: Contains a record of the AVORCLDB commands that have executed av_client-%g.log.n: Contains agent collection metrics. %g is a generation number that starts at 0 and increases when the file size reaches a 10 MB limit. Files that contain an extension of .log.n can be deleted at any time. Oracle Database 10g: Implementing Audit Vault
210
Managing Audit Vault Agent Log and Error Files
Log and error files are located in the Audit Vault Agent $ORACLE_HOME/av/log directory. File Name Contents Maintenance agent.err Errors in agent initialization and operation Delete at any time agent.out Agent-related operations Delete after agent is stopped avca.log AVCA commands avorcldb.log AVORCLDB commands <Cname><Sname><SID>.log DBAUD and OSAUD operations av_client-%g.log.n Agent operations Viewing Audit Vault Agent Log and Error Files The Audit Vault Agent generates log files that provide current status and diagnostic information. The log files should be monitored and periodically deleted to control the amount of used disk space. The Audit Vault Agent generates the following files: agent.err: Contains errors incurred in agent initialization and operation agent.out: Contains primary agent-related operations and activity avca.log: Contains a record of the execution of AVCA commands avorcldb.log: Contains a record of the execution of AVORCLDB commands <Cname><Sname><SID>.log: Contains a log of DBAUD and OSAUD collection operations. Cname is the collector name. Sname is the source name. SID is the source ID. av_client-%g.log.n: Contains a record of agent operations. %g is a generation number that starts at 0 and increases when the file size reaches a 10 MB limit. Files that contain an extension of .log.n can be deleted at any time. Oracle Database 10g: Implementing Audit Vault
211
Oracle Database 10g: Implementing Audit Vault 1 - 215
Updating the Wallets When user passwords are changed, the wallets must be updated as follows: Audit Vault Administrator (granted AV_ADMIN) password changes => Update the Audit Vault Server wallet Audit Vault Agent user in the Audit Vault Server database (granted AV_AGENT) password changes => Update the Audit Vault Agent wallet Source user password changes => Update the Audit Vault Agent wallet Updating the Wallets Many organizations have a policy to change database passwords on a regular basis. When you change passwords in your source database and the Audit Vault Server database, you must also update the password credentials in the wallets as follows: If you change the password of the Audit Vault Administrator user (created during the installation of the Audit Vault Server and granted the AV_ADMIN role), you must update the wallet stored on the Audit Vault Server host. If you change the password of the Audit Vault Agent user created in the Audit Vault Server database (granted the AV_AGENT role), you must update the wallet stored on the Audit Vault Agent host. If you change the password of the source user (used by the agent and the collectors) on the source database, you must update the wallet stored on the Audit Vault Agent host. Oracle Database 10g: Implementing Audit Vault
212
Updating the Audit Vault Server Wallet: Step 1
Use the mkstore –listCredential command to list the wallet entries: mkstore -wrl <wallet location> -listCredential Updating the Audit Vault Server Wallet: Step 1 The password of the Audit Vault Administrator is stored in the wallet on the Audit Vault Server host. When you change the Audit Vault Administrator password, you must update the wallet. Perform the following steps to update the wallet: 1. Use the mkstore –listCredential command in the Audit Vault Server Oracle Home to list all the entries in the wallet, as shown in the following example: av_1]$ mkstore > -wrl $ORACLE_HOME/network/admin/avwallet -listCredential Enter password: <password of the wallet–specified for the Audit Vault Administrator during Audit Vault Server installation> List credential (index: connect_string username) 1: av avadmin1 av_1]$ Note that the connect_string in the output is the service name as defined in the tnsnames.ora file. Oracle Database 10g: Implementing Audit Vault
213
Updating the Audit Vault Server Wallet: Step 2
Use the mkstore –modifyCredential command to update the password in the wallet: mkstore -wrl <wallet_location> -modifyCredential <dbase_alias> <username> <password> Updating the Audit Vault Server Wallet: Step 2 2. Use the mkstore –modifyCredential command to update the password: av_1]$ mkstore > -wrl $ORACLE_HOME/network/admin/avwallet \ > -modifyCredential av avadmin1 oracle_1 Enter password:<password of the wallet–specified for the Audit Vault Administrator during Audit Vault Server installation> Modify credential Modify 1 av_1]$ Oracle Database 10g: Implementing Audit Vault
214
Updating the Audit Vault Agent Wallet: Step 1
Use the mkstore –listCredential command to list the wallet entries: mkstore -wrl <wallet location> -listCredential Updating the Audit Vault Agent Wallet: Step 1 Use the mkstore –listCredential command in the Audit Vault Agent Oracle Home to list all the entries in the Agent wallet: ~]$ mkstore -wrl $ORACLE_HOME/network/admin/avwallet \ > -listCredential Enter password:<password of the wallet–specified for the Audit Vault Agent User created prior to Audit Vault Agent installation> List credential (index: connect_string username) 1: AV avagentuser 2: SRCDB1 avcolluser Agent Oracle Database 10g: Implementing Audit Vault
215
Updating the Audit Vault Agent Wallet: Step 2
Use the mkstore –modifyCredential command to update the password in the wallet: mkstore -wrl <wallet_location> -modifyCredential <dbase_alias> <username> <password> Updating the Audit Vault Agent Wallet: Step 2 Execute the mkstore –modifyCredential command for the entry you need to modify. If you change the password of the Audit Vault Agent user in the Audit Vault Server database, you update the wallet credentials as shown in the following example: av_1]$ mkstore > -wrl $ORACLE_HOME/network/admin/avwallet \ > -modifyCredential AV avagentuser newavagentpass Enter password:<password of the wallet–specified for the Audit Vault Agent User created prior to Audit Vault Agent installation> If you change the password of the Audit Vault user in the source database, you update the wallet credentials as shown in the following example: av_1]$ mkstore > -modifyCredential SRCDB1 avcolluser newavcollpass Agent Oracle Database 10g: Implementing Audit Vault
216
Oracle Database 10g: Implementing Audit Vault 1 - 220
Summary In this lesson, you should have learned how to: Monitor the Audit Vault Server database SYSAUX tablespace Archived redo log destination Monitor the status of Audit Vault components Identify Audit Vault Server error and log files Identify Audit Vault Agent error and log files Update credentials in the wallets Oracle Database 10g: Implementing Audit Vault
217
Oracle Database 10g: Implementing Audit Vault 1 - 221
Practice 9: Overview This practice covers the following topics: Verifying that the DBAUD collector is collecting data from the SYS.AUD$ table Verifying that the OSAUD collector is collecting data from the operating system file Updating credentials in the Audit Vault Server wallet Oracle Database 10g: Implementing Audit Vault
218
Practices and Solutions
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.