| Oracle® Audit Vault Administrator's Guide Release 10.2.3.2 Part Number E14459-11 |
|
|
View PDF |
| Oracle® Audit Vault Administrator's Guide Release 10.2.3.2 Part Number E14459-11 |
|
|
View PDF |
Managing Authentication Metadata Using Oracle Advanced Security
Changing Oracle Audit Vault User Passwords on a Regular Basis
Configuring HTTPS and SSL Communication for Oracle Audit Vault
This chapter explains how to manage Oracle Audit Vault security. You should perform Oracle Audit Vault security tasks in this order of importance:
Secure management communication between the Oracle Audit Vault Server and collection agent, described in Section 5.6.
Manage user authentication metadata, described in Section 5.3.
Section 5.5 explains how Oracle Database Vault protects audit data and provides strong access control.
During the Oracle Audit Vault installation process, you created the following two system-generated user accounts:
Audit Vault administrator account. This user account is responsible for the administrative tasks described in this manual, and is granted the AV_ADMIN role.
Audit Vault auditor account. This user account is responsible for the auditing tasks described in Oracle Audit Vault Auditor's Guide, and is granted the AV_AUDITOR role.
As a best practice, you should use these two user accounts only as back-up accounts, and grant the appropriate Audit Vault role to the users who are responsible for the day-to-day Oracle Audit Vault operations. Each user account must have its own user name and password. For example, if your site requires two Audit Vault administrators and six auditors, then grant the administrators the AV_ADMIN role and the auditors the AV_AUDITOR role. Or, for example, if all your administrators are granted SEC_ADMIN role and everyone who has the SEC_ADMIN role must also administer Oracle Audit Vault, then grant the AV_ADMIN role to the SEC_ADMIN role.
This way, if an Audit Vault administrator or auditor leaves the department or your company, then you only need to revoke the role from this user. If all the users who have been granted a particular role leave your company, then you can use the back-up Audit Vault user account that you created during installation to grant the role to new users. The danger of relying on the default user accounts that you created during installation is that if multiple users use the account, then they all can log in using the same user account and password. Shared passwords make your system less secure.
Similarly, you should grant the DV_OWNER and DV_ACCTMGR roles to individual users, and only use the DV_OWNER and DV_ACCTMGR accounts that you created during installation as back-up accounts. This is particularly important in the case where a user must have his or her password reset, because only a user who has been granted the DV_ACCTMGR role or the ALTER USER privilege can set passwords.
In addition to the AV_ADMIN and AV_AUDITOR roles, a default Oracle Audit Vault installation provides a set of administrative roles that you can use to manage Oracle Audit Vault. These roles provide separation-of-duty tasks. See Table 5-1 for more information.
To create user accounts for use with Oracle Audit Vault:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
If you must create new user accounts, then log in to SQL*Plus as a user who has been granted the CREATE USER privilege or the DV_ACCTMGR role, and create the user accounts.
For example:
sqlplus avadmindva Enter password: password Connected. SQL> CREATE USER tjones IDENTIFIED BY password; -- The AV_ADMIN user SQL> CREATE USER psmith IDENTIFIED BY password; -- The AV_AUDITOR user
Connect as a user who has been granted the AV_ADMIN role and then grant the AV_ADMIN and AV_AUDITOR roles to these users.
For example:
SQL> CONNECT avadmin
Enter password: password
Connected.
SQL> GRANT AV_ADMIN TO tjones; -- The AV_ADMIN user
SQL> GRANT AV_AUDITOR TO psmith; -- The AV_AUDITOR user
Repeat these steps to create individual accounts to be granted the DV_OWNER and DV_ACCTMGR roles.
For the role grants, do the following:
When you are ready to grant the DV_OWNER role to the user, connect as a user who has been granted the DV_OWNER role.
When you are ready to grant the DV_ACCTMGR role to the user, connect as a user who has been granted the DV_ACCTMGR role.
See Table 1-7 for more information about these roles.
Optionally, audit the actions of the user who has been granted the AV_ADMIN role.
As part of the Audit Vault Server and the Oracle Audit Vault collection agent installation, two wallets are created. One wallet resides on the Audit Vault Server and this one contains the credentials of the AV_ADMIN. The Audit Vault Console uses this wallet to communicate with the Oracle Audit Vault database. The Audit Vault Console provides the management service that initiates the communication with collection agents using HTTP. Audit Vault Configuration Assistant (AVCA) modifies the Database Control console server.xml file and other related files to enable Oracle Audit Vault management through the Oracle Enterprise Manager Database Control console. The wallet is located in the $ORACLE_HOME/network/admin/avwallet directory.
The other wallet resides on the Audit Vault collection agent and contains the AV_AGENT credentials. The collection agent uses this wallet to get configuration data from Oracle Audit Vault. This wallet is located in the $ORACLE_HOME/network/admin/avwallet directory. This wallet also contains the credentials used by the collectors to communicate with the source database (Oracle Database, Microsoft SQL Server database, Sybase ASE, or IBM DB2 database). The three ORCLDB collectors, the MSSQLDB collector, the SYBDB collector, and the DB2 collector all use these credentials to connect to the source database and to:
Open a connection to the source database to read, extract, and send audit records to the Audit Vault repository
Obtain metadata and metrics for all the collectors
Start and stop the collectors
Obtain audit settings as part of Audit Settings management for ORCLDB collectors
Obtain user entitlement information for ORCLDB collectors
The Oracle wallet is a password-protected container that stores credentials, such as certificates, authentication credentials, and private keys, all of which are used by SSL for strong authentication. You can manage Oracle wallets by using Oracle Wallet Manager. Oracle Wallet Manager can perform tasks such as wallet creation, certificate request generation, and importing certificates into the wallet.
Oracle Audit Vault uses third-party network authentication services (PKI-based authentication) to authenticate its user clients. Authentication systems based on public key infrastructure (PKI) issue digital certificates to user clients, which use them to authenticate directly to servers in the enterprise without involving an authentication server. These user certificates, along with the private key of the user and the set of trust points of a user (trusted certificate authorities), are stored in Oracle wallets.
This section contains:
You should have a policy in place for changing passwords for the Oracle Audit Vault user accounts. For example, you may require that users change their passwords on a regular basis, such as every 120 days, and that they create passwords that are not easily guessed.
Table 5-1 summarizes guidelines that you must follow when you change passwords for the Oracle Audit Vault user accounts.
Table 5-1 Storage Location of Audit Vault and Source User Name Passwords
| Audit Vault Role | Is Password Stored in Wallet? | How Do I Change the Password? |
|---|---|---|
|
|
Yes |
Use the If the system-generated See Section 5.4.2. |
|
|
Yes |
Use the You must also change the password of this user in the database. To do so, use the See Section 5.4.3. |
|
Source user on source database |
Yes |
For an Oracle Database source user account, use the Use the See Section 5.4.3 |
|
|
No |
Use the See Section 5.4.5. |
After you have updated the AV_ADMIN user account using the ALTER USER SQL statement, you must update the password credentials of this user.
To change the password of a user who has been granted the AV_ADMIN role:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
Log in to SQL*Plus as the user whose password you must change, another user who has been granted the ALTER_USER privilege, or a user with the DV_ACCTMGR role, and then change the password.
For example:
sqlplus dvsmith Enter password: password Connected. SQL> ALTER USER avsmith IDENTIFIED BY password;
Exit SQL*Plus.
If this user was granted the AV_ADMIN role after the Oracle Audit Vault installation, then you have completed this procedure. Otherwise, if the AV_ADMIN user account had been created during the Audit Vault installation, then go to Step 4.
Run the avca create_credential command to change the password credentials of the AV_ADMIN user.
For example:
avca create_credential -wrl $ORACLE_HOME/network/admin/avwallet -dbalias orcl AVCA started Storing user credentials in wallet... Enter source user username: avadminuser Enter source user password: password Re-enter source user password: password Create credential Modify credential Modify 2 done.
In this example, the dbalias parameter specifies the Audit Vault Server SID in the Audit Vault Server home. You can find this information by running the lsnrctl status command on the computer where you installed the source database. For detailed information about using the avca create_credential command, see Section 6.4.
When you change the AV_AGENT user password, you must also update this user's credentials for each agent that connects to the Audit Vault Server as the AV_AGENT user account.
To change the password credentials for the AV_AGENT user account:
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the collection agent ORACLE_HOME\bin directory.
Log in to SQL*Plus and use the ALTER USER SQL statement to change the password of the AV_AGENT user.
For example:
sqlplus dvsmith Enter password: password Connected. SQL> ALTER USER avagent_usr IDENTIFIED BY password;
Access the shell or command prompt used for the Audit Vault collection agent.
For each agent that connects to the server as the AV_AGENT user account, run the avca create_credential command to update the locally cached credentials with the new password.
For example:
avca create_credential -wrl $ORACLE_HOME/network/admin/avwallet -dbalias av AVCA started Storing user credentials in wallet... Enter source user username: avagentuser Enter source user password: password Re-enter source user password: password Create credential Modify credential Modify 2 done.
For detailed information about using the avca create_credential command, see Section 6.4.
After you have updated the source database stored password credential, you must update the password credentials of this account.
To change the password credentials for the source user account:
In the source database, change the password for the source database user.
For an Oracle Database source, use the ALTER USER SQL statement to change the password.
For example:
sqlplus dvsmith Enter password: password Connected. SQL> ALTER USER srcuser_ora IDENTIFIED BY password;
For source user accounts created for Microsoft Windows, Sybase ASE, and IBM DB2, log in to the appropriate source database and then change the password there.
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the collection agent ORACLE_HOME\bin directory.
Run the avorcldb setup command.
For example:
avorcldb setup -srcname hrdb.example.com
Enter Source user name: srcuser_ora
Enter Source password: password
adding credentials for user srcuser_ora for connection [SRCDB1]
Storing user credentials in wallet...
Create credential oracle.security.client.connect_string3
done.
updated tnsnames.ora with alias [SRCDB1] to source database
verifying SRCDB1 connection using wallet
For detailed information about using the avorcldb setup command, see Section 8.9. Depending on where you created the source user account, see the following sections:
Microsoft SQL Server: Section 9.9
Sybase ASE: Section 10.9
IBM DB2: The avdb2db utility has no setup command. For IBM DB2 databases, you only need to change the password of the designated user account.
To change the password of a user who has been granted the AV_AUDITOR role, you must change the passwords in both the Audit Vault Server home in the Audit Vault database by using the SQL ALTER_USER command. Log in as the user with the role of Database Vault Account Manager.
For example:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
Log in to SQL*Plus as the Database Vault Account Manager (that is, a user who has been granted the DV_ACCTMGR role).
For example:
sqlplus dvsmith
Enter password: password
Connected.
SQL>
Use the ALTER USER SQL statement to change the AV_AUDITOR user account.
For example:
SQL> ALTER USER avauditorusr-name IDENTIFIED BY password;
To test the changed passwords for users who have been granted the AV_ADMIN and AV_AUDITOR roles, log in to the Audit Vault Console as the Audit Vault administrator and then as the Audit Vault auditor. See Section 3.2.3 for instructions on logging in to the Audit Vault Console. If the login is not successful, repeat the procedures described in this section to re-create the passwords, and then retest them.
For the AV_ADMIN role, you must also test that the credentials were stored correctly in the wallet.
Follow these steps:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
In SQL*Plus, log in to the Audit Vault Server.
For example, assuming the SID of the Audit Vault Server is av:
sqlplus /@av
To test the AV_AGENT and source database user account passwords, stop the collection agents, and then restart the collection agent and each collector. See Chapter 7 for information about the commands you use to perform this test. If you are able to collect new audit records, then the AV_AGENT and source database user account passwords are working. If you cannot collect audit records, then check the log files (see Appendix A for more information) to determine which user name password might be the cause of the problem. If necessary, re-create the passwords and then retest them.
By default, Oracle Database Vault is enabled in the Audit Vault Server. Oracle Database Vault restricts access to the data in the Audit Vault Server from any user, including users who have administrative access. For Oracle Audit Vault, Oracle Database Vault protects the Audit Vault Server by using a realm. To ensure that the data in the Audit Vault Server is protected, do not disable Oracle Database Vault.
The inclusion of Oracle Database Vault provides the DV_OWNER and DV_ACCTMGR roles. The DV_OWNER role manages the database roles and configuration, and the DV_ACCTMGR role manages user accounts. As with all Oracle Database roles, grant these roles only to those users who are responsible for the tasks associated with the role.
Be aware that Oracle Database Vault revokes some privileges from several roles supplied by the Oracle database roles, including SYS and SYSTEM. Oracle Database Vault Administrator's Guide describes roles and privileges that Oracle Database Vault affects. Remember that only the user who has been granted the DV_ACCTMGR role can create, alter, and drop users. However, the DV_ACCTMGR user cannot grant these roles to these users. Only the user who has been granted the AV_ADMIN role can grant the AV_ADMIN and AV_AUDITOR roles to another user.
Table 5-2 shows the roles and privileges an administrative user is granted when that user is granted and Oracle Audit Vault or Oracle Database Vault roles. For detailed information about the Oracle Audit Vault or Oracle Database Vault roles, see Section 1.5.
Table 5-2 Roles and Privileges Granted to Audit Vault or Database Vault Administrators
| Role Granted to User | Roles Granted to This Role | Privileges Granted |
|---|---|---|
|
|
|
|
|
|
|
|
|
No additional roles granted |
|
|
|
|
|
|
|
|
|
Footnote 1 The AV_ADMIN role is granted the AV_AUDITOR role only if you did not create the AV_AUDITOR user during installation.
Table 5-3 shows other database core accounts that are created in the default Oracle Audit Vault installation. Oracle Audit Vault permits operating system authentication to the database. It disables remote authentication to the database if you try to use the SYSDBA privilege, but if it is needed, you can enable it by using a password file. See the sections that discuss postinstallation tasks in the Oracle Audit Vault Installation Guide for more information about unlocking and resetting user passwords and enabling or disabling connections with the SYSDBA privilege.
Table 5-3 Database Core Accounts Created and Privileges Use
| Account | Privileges | Privilege In Use | Password to Use |
|---|---|---|---|
|
ManyFoot 1 |
Yes |
Use same password as user granted |
|
|
|
|
Yes, allowed |
Operating system authentication to the database is enabled by default. |
|
|
|
No, not allowed for remote connection |
To use for remote connection, user must create a password file to enable its use. Password is set when password file is created. |
|
|
Yes, allowed |
Use same password as user granted |
Footnote 1 To find the privileges associated with the user account, log in to SQL*Plus as the user and then run the following query: SELECT * FROM SESSION_ROLES;
About Configuring HTTPS and SSL Communication for Oracle Audit Vault
Step 2: Create an Audit Vault Agent Keystore by Using the keytool Utility
You can secure management communication between the Oracle Audit Vault Server and collection agent by using the HTTPS protocol to encrypt data. In this case, you provide X.509 certificates for authentication. This section explains how to configure Secure Sockets Layer (SSL) for the mutual authentication between Oracle Audit Vault on the server side and each collection agent over HTTPS. A certificate authority (CA) must provide these certificates to you, the Oracle Audit Vault administrator.
To accomplish this, you secure the following services on the Audit Vault Server side:
Oracle Audit Vault Web application, which you secure by using the avca secure_av command.
XDB services, which you secure by using the avca generate_crs and avca import commands.
For the Audit Vault agent side, you secure OC4J by using the avca secure_agent command.
After you secure the Audit Vault Server and Audit Vault collection agent communication to use HTTPS, you must enable the browser to use HTTPS to access the Audit Vault Console. At this stage, HTTP will no longer be available for the browser user because the browser to the Audit Vault Console communication is also made secure.
Before you follow the procedures described in this section, you must understand how to use keystores, which are in JKS (Java Keystore) format from Sun Microsystems. You can create and manage keystores by using the keystore application from Sun Microsystems. See the following URLs for more information:
http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html
http://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html
See Also:
Oracle Database Advanced Security Administrator's Guide for more information about PKI-based authentication, digital certificates, secure external password stores, and Oracle wallets.To generate the keystore:
Create a keystore to secure the Audit Vault Console.
The following example uses the name avkeystore to denote the Audit Vault Server keystore:
oracle:/home/oracle> $ORACLE_HOME/jdk/bin/keytool -genkey -v -alias avkey -keyalg RSA -keysize 1024 -dname "CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us" -validity 365 -keypass welcome -keystore /tmp/certs/avkeystore -storepass password
Output similar to the following appears:
Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA) for: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us [Saving /tmp/certs/avkeystore]
List the contents, and ensure that the keystore has valid keys and components.
At this stage, you should have a new keystore with an Audit Vault Server private key/certificate pair.
For example:
oracle:/home/oracle> $ORACLE_HOME/jdk/bin/keytool -list -v -keystore /tmp/certs/avkeystore
Enter keystore password: password
Output similar to the following appears:
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: avkey Creation date: Feb 18, 2010 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us Serial number: 4b7e19da
Generate the certificate request.
For example:
oracle:/home/oracle> $ORACLE_HOME/jdk/bin/keytool -certreq -alias avkey -keystore /tmp/certs/avkeystore -file /tmp/mycsr.csr
Enter keystore password: password
Send this certificate request file to a CA to be signed and then returned to you.
In the preceding steps, this request file is called mycsr.csr and was created in the tmp directory.
Import the CA root certificate.
For example:
oracle:/home/oracle> $ORACLE_HOME/jdk/bin/keytool -keystore /tmp/certs/avkeystore -import -alias CAcert -trustcacerts -file /tmp/cacert.pem
Enter keystore password: password
Output similar to the following appears; answer the prompts as needed.
Owner: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Issuer: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleSC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 0 Valid from: Mon Feb 08 23:54:23 MST 2010 until: Tue Feb 08 23:54:23 MST 2011 Certificate fingerprints: MD5: 1C:D7:51:31:81:14:39:F3:CC:E0:24:86:9C:8A:69:08 SHA1: 6C:A4:35:1F:82:57:BF:DB:DC:D9:2B:82:A2:AC:F6:15:BD:8C:A6:99 Trust this certificate? [no]: yes Certificate was added to keystore
Import the signed certificate to keystore.
For example:
oracle:/tmp> $ORACLE_HOME/jdk/bin/keytool -keystore /tmp/certs/avkeystore -import -file /tmp/mycert.cer
Enter keystore password: password
Certificate was added to keystore
Check the keystore to ensure that the certificate chain is complete.
For example:
oracle:/tmp> $ORACLE_HOME/jdk/bin/keytool -list -v -keystore /tmp/certs/avkeystore
Enter keystore password: password
Output similar to the following appears:
Keystore type: jks Keystore provider: SUN Your keystore contains 3 entries Alias name: avkey Creation date: Feb 18, 2010 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us Serial number: 4b7e19da Valid from: Thu Feb 18 21:55:54 MST 2010 until: Fri Feb 18 21:55:54 MST 2011 Certificate fingerprints: MD5: 89:AF:A3:3E:3C:91:B6:41:9C:26:D3:95:6C:AF:24:17 SHA1: 69:04:B2:16:95:69:38:9D:0F:D1:7B:4F:1B:EE:F3:E4:FA:A2:72:78 ******************************************* ******************************************* Alias name: cacert Creation date: Feb 18, 2010 Entry type: trustedCertEntry Owner: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Issuer: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 0 Valid from: Mon Feb 08 23:54:23 MST 2010 until: Tue Feb 08 23:54:23 MST 2011 Certificate fingerprints: MD5: 1C:D7:51:31:81:14:39:F3:CC:E0:24:86:9C:8A:69:08 SHA1: 6C:A4:35:1F:82:57:BF:DB:DC:D9:2B:82:A2:AC:F6:15:BD:8C:A6:99 ******************************************* ******************************************* Alias name: mykey Creation date: Feb 18, 2010 Entry type: trustedCertEntry Owner: CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: EMAILADDRESS=sunil.shetty@examplecom, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 4 Valid from: Thu Feb 18 21:37:12 MST 2010 until: Fri Feb 18 21:37:12 MST 2011 Certificate fingerprints: MD5: 87:82:9F:09:11:40:62:9E:FA:63:68:92:E2:7C:AA:57 SHA1: 47:41:0E:BE:05:49:2C:A5:55:3A:3E:F5:14:47:04:6E:85:40:F0:9F ******************************************* *******************************************
To create an Audit Vault Agent keystore using the keytool utility:
Create the keystore that you will use to secure the Audit Vault agent.
For example:
oracle:/tmp/certs> $ORACLE_HOME/jdk/bin/keytool -genkey -v -alias agkey -keyalg RSA -keysize 1024 -dname "CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us" -validity 365 -keypass password -keystore /tmp/certs/agkeystore -storepass password
Output similar to the following appears:
Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA) for: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us [Saving /tmp/certs/agkeystore]
List the contents to ensure that the keystore has valid keys and components.
At this stage, you should have a new keystore with an Audit Vault agent private key/certificate pair.
For example:
oracle:/tmp/certs> $ORACLE_HOME/jdk/bin/keytool -list -v -keystore /tmp/certs/agkeystore
Enter keystore password: password
Output similar to the following appears:
Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: agkey Creation date: Feb 18, 2010 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us Serial number: 4b7e211b Valid from: Thu Feb 18 22:26:51 MST 2010 until: Fri Feb 18 22:26:51 MST 2011 Certificate fingerprints: MD5: D4:EE:B1:EC:D2:DA:02:07:20:8C:01:C8:36:FE:2C:0B SHA1: CF:1F:9D:BF:6C:65:FD:4D:15:54:0C:27:F3:5F:63:E8:39:90:D4:EA ******************************************* *******************************************
Generate the certificate request.
For example:
oracle:/tmp/certs> $ORACLE_HOME/jdk/bin/keytool -certreq -alias agkey -keystore /tmp/certs/agkeystore -file /tmp/mycsr_agent.csr
Enter keystore password: password
Send this certificate request file to a CA to be signed and then returned to you.
Import the CA root certificate to the agent keystore.
For example:
oracle:/tmp> $ORACLE_HOME/jdk/bin/keytool -keystore /tmp/certs/agkeystore -import -alias CAcert_agent -trustcacerts -file /tmp/cacert.pem
Enter keystore password: password
Output similar to the following appears; answer the prompts as needed.
Owner: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Issuer: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 0 Valid from: Mon Feb 08 23:54:23 MST 2010 until: Tue Feb 08 23:54:23 MST 2011 Certificate fingerprints: MD5: 1C:D7:51:31:81:14:39:F3:CC:E0:24:86:9C:8A:69:08 SHA1: 6C:A4:35:1F:82:57:BF:DB:DC:D9:2B:82:A2:AC:F6:15:BD:8C:A6:99 Trust this certificate? [no]: yes Certificate was added to keystore
Import the signed certificate of the Audit Vault agent to keystore.
For example:
oracle:/tmp> $ORACLE_HOME/jdk/bin/keytool -keystore /tmp/certs/agkeystore -import -trustcacerts -file /tmp/mycert_agent.cer
Enter keystore password: password
Certificate was added to keystore
Ensure that the Audit Vault agent keystore has proper certificate chain.
For example:
oracle:/tmp> $ORACLE_HOME/jdk/bin/keytool -list -v -keystore /tmp/certs/agkeystore
Enter keystore password: password
Output similar to the following appears:
Keystore type: jks Keystore provider: SUN Your keystore contains 3 entries Alias name: agkey Creation date: Feb 18, 2010 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us Serial number: 4b7e211b Valid from: Thu Feb 18 22:26:51 MST 2010 until: Fri Feb 18 22:26:51 MST 2011 Certificate fingerprints: MD5: D4:EE:B1:EC:D2:DA:02:07:20:8C:01:C8:36:FE:2C:0B SHA1: CF:1F:9D:BF:6C:65:FD:4D:15:54:0C:27:F3:5F:63:E8:39:90:D4:EA ******************************************* ******************************************* Alias name: cacert_agent Creation date: Feb 18, 2010 Entry type: trustedCertEntry Owner: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Issuer: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=Example eISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 0 Valid from: Mon Feb 08 23:54:23 MST 2010 until: Tue Feb 08 23:54:23 MST 2011 Certificate fingerprints: MD5: 1C:D7:51:31:81:14:39:F3:CC:E0:24:86:9C:8A:69:08 SHA1: 6C:A4:35:1F:82:57:BF:DB:DC:D9:2B:82:A2:AC:F6:15:BD:8C:A6:99 ******************************************* ******************************************* Alias name: mykey Creation date: Feb 18, 2010 Entry type: trustedCertEntry Owner: CN=agent, OU=st, O=example, L=nomadcity, ST=ca, C=us Issuer: EMAILADDRESS=sunil.shetty@example.com, CN=Sathya, OU=ExampleISC, O=Support, L=Bangalore, ST=Karnataka, C=IN Serial number: 5 Valid from: Thu Feb 18 21:57:09 MST 2010 until: Fri Feb 18 21:57:09 MST 2011 Certificate fingerprints: MD5: E5:19:D5:F8:95:37:C5:F3:91:AB:CB:F1:C9:26:E1:30 SHA1: 16:4A:63:6A:84:9A:CC:2A:8E:6D:28:46:65:48:CA:31:D0:80:DA:3D ******************************************* *******************************************
To secure the XDB services:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
Create a certificate request that will be stored in the Oracle wallet.
oracle:/tmp> avca generate_csr -certdn \"cn=oel5upd1,OU=DBSEC,O=Example,ST=CA,C=US\" -out /tmp/cert.out Generating Certificate request... Certificate request generated successfully.
See Section 6.12 for detailed information about the avca generate_csr command.
Send this certificate request file to a CA to be signed and then returned to you.
Import the CA certificate into the Oracle wallet as a trusted CA.
For example:
oracle:/tmp> avca import_cert -cert /tmp/cacert.pem -trusted Importing Certificate... Certificate imported successfully.
See Section 6.14 for detailed information about the avca import_cert command.
Import the user certificate.
For example:
oracle:/tmp> avca import_cert -cert /tmp/newcert.pem Importing Certificate... Certificate imported successfully.
To secure Audit Vault Server:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
Run the avca secure_av command.
For example:
oracle:/tmp> avca secure_av -avkeystore /tmp/certs/avkeystore -avtruststore /tmp/certs/avkeystore
See Section 6.20 for detailed information about the avca secure_av command.
Output similar to the following appears:
Checking for SSL Certificate... done. Enter Audit Vault Server keystore password: Stopping OC4J... OC4J stopped successfully. Securing XDB services... Identified XDB http(s) Port... Stopping Listeners... done. Starting Listeners... done. done. Starting OC4J... OC4J started successfully. TZ set to US/MountainOracle Audit Vault 10g Database Control Release 10.2.3.2.0 Copyright (c) 2006, 2009 Oracle Corporation. All rights reserved. https://oel5upd1:5700/av Oracle Audit Vault 10g is running. ------------------------------------ Logs are generated in directory /home/oracle/product/10.2.3/av_1/av/log
To secure the Audit Vault agent:
Open a shell or command prompt for the Audit Vault collection agent.
UNIX: Set the environment variables, as described in Section 2.2.3.
Microsoft Windows: Go to the Audit Vault Server or collection agent ORACLE_HOME\bin directory.
Run the avca secure_agent command.
For example:
oracle:/tmp> avca secure_agent -agentkeystore /tmp/certs/agkeystore -avdn \"CN=avserver, OU=st, O=example, L=nomadcity, ST=ca, C=us\" -agentdn \"CN=agent, OU=st, O=example,L=nomadcity, ST=ca, C=us\"
See Section 6.19 for detailed information about the avca secure_agent command.
Output similar to the following appears; answer the prompts as needed.
Enter Audit Vault Agent keystore password: password
Stopping agent...
Agent stopped successfully.
Starting agent...
Agent started successfully.
If you need to update the XDB certificate that you obtained from running the avca generate_csr command, then follow these steps to ensure that the Oracle wallet uses the updated XDB certificate:
Open a shell or command prompt for the Audit Vault Server.
UNIX: Set the environment variables, as described in Section 2.2.2.
Microsoft Windows: Go to the Audit Vault Server ORACLE_HOME\bin directory.
Run the avca remove_certificate command with the -certdn parameter set to the DN of the XDB certificate.
For example:
avca remove_cert -certdn -hrdb.example.com \"CN=AV_Server_host_DN,OU=DBSEC,O=Oracle,ST=CA,C=US\"
Shut down the Audit Vault Web application.
avctl stop_av
Stop the listener for the Audit Vault database.
lsnrctl stop
Log in to SQL*Plus and then shut down the Audit Vault database.
For example:
sqlplus sys as sysoper
Enter password: password
Connected.
SQL> SHUTDOWN IMMEDIATE
Restart the Audit Vault database listener.
lsnrctl start
Restart the Audit Vault database.
SQL> STARTUP
Start the Audit Vault Web application
avctl start_av
Generate a new certificate.
For example:
avca generate_csr -certdn \"CN=AV_Server_host_DN,OU=DBSEC,O=Oracle,ST=CA,C=US\" -out user_certificate.cer
Import the new certificate.
For example:
avca import_cert -cert user_certificate.cer
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|