| Oracle® Database Vault Administrator's Guide 10g Release 2 (10.2) Part Number B25166-04 |
|
|
View PDF |
| Oracle® Database Vault Administrator's Guide 10g Release 2 (10.2) Part Number B25166-04 |
|
|
View PDF |
This chapter explains how you can integrate Oracle Database Vault with the following Oracle products:
Integrating Oracle Database Vault with Enterprise User Security
Integrating Oracle Database Vault with Transparent Data Encryption
Integrating Oracle Database Vault with Oracle Label Security
Using Oracle Database Vault with Oracle Recovery Manager (RMAN)
You can integrate Oracle Database Vault with Oracle Enterprise User Security. In general, to do so, you configure the appropriate realms to protect the data that you want to protect in the database.
After you define the Oracle Database Vault roles as needed, you can create a rule set for the Enterprise users to allow or disallow their access.
To configure an Enterprise User authorization:
Create a rule to allow or disallow user access.
Follow the instructions in "Creating a Rule to Add to a Rule Set" to create a new rule. In the Create Rule page, enter the following PL/SQL in the Rule Expression field:
SYS_CONTEXT('USERENV','EXTERNAL_NAME') = 'user_domain_name'
Add this rule to a new rule set.
"Creating a Rule Set" explains how to create a new rule set, including how to add an existing rule to it.
Add this rule set to the realm authorization for the database that you want to protect.
"Defining Realm Authorization" explains how to create realm authorizations. In the Authorization Rule Set list, select the rule set that you created in Step 2.
For more information about Enterprise User Security, see Oracle Database Enterprise User Security Administrator's Guide.
Oracle Database Vault works with Transparent Data Encryption (TDE). Database Vault realms, multi-factor authorization, and command rules all provide security controls around access to databases and applications as well as controlling activity within the database through separation of duty.
With Transparent Data Encryption, an application administrator can use a single one line command to alter a table and encrypt a column. Subsequent inserts into that table column will be written to disk encrypted transparent to the SQL. This means that no SQL modification, database triggers, or views are required.
The first release of Transparent Data Encryption was focused on media protection. Therefore, if a user passes the authentication and authorization checks, Transparent Data Encryption automatically encrypts and decrypts information for the user. This way, you can implement encryption without having to change your applications.
So, if you have TDE enabled, Oracle Database Vault will work with it seemlessly and without any additional configuration. TDE also can be enabled in an Oracle Database Vault environment with any additional configuration.
Figure 8-1 shows how Oracle Database Vault realms handle encrypted data.
Figure 8-1 Encrypted Data and Oracle Database Vault
This section includes the following topics:
How Oracle Database Vault Is Integrated with Oracle Label Security
Requirements for Using Oracle Database Vault with Oracle Label Security
Using an Oracle Database Vault Factor with an Oracle Label Security Policy
Example of Integrating Oracle Database Vault with Oracle Label Security
When you integrate Oracle Database Vault with Oracle Label Security, it means that you can assign an Oracle Label Security label to an Oracle Database Vault factor identity.
You can attach factors to an Oracle Virtual Private Database. To do so, define a policy predicate that is a PL/SQL function or expression. Then, for each function or expression, you can use the DVF.F$ PL/SQL function that is created for each factor.
In Oracle Label Security, you can restrict access to records in database tables or PL/SQL programs. For example, Mary may be able to see data protected by the HIGHLY SENSITIVE label, an Oracle Label Security label on the EMPLOYEE table that includes records that should have access limited to certain managers. Another label can be PUBLIC, which allows less limited access to this data.
In Oracle Database Vault, you can create a factor called Network, for the network on which the database session originates, with the following identities:
Intranet: Used for when an employee is working on site within the intranet for your company.
Remote: Used for when the employee is working at home from a VPN connection.
You then assign a maximum session label to both. For example:
Assign the Intranet identity to the HIGHLY SENSITIVE Oracle Label Security label.
Assign the Remote identity to the PUBLIC label.
This means that when Mary is working at home using her VPN connection, she has access only to the limited table data protected under the PUBLIC identity. But when she is in the office, she has access to the HIGHLY SENSITIVE data, because she is using the Intranet identity. "Example of Integrating Oracle Database Vault with Oracle Label Security" provides an example of how to accomplish this type of integration.
You can audit the Oracle Database Vault-Oracle Label Security integration by using the Label Security Integration Audit Report. See "Label Security Integration Audit Report" for more information.
You can use the Oracle Database Vault APIs to integrate Oracle Database Vault with Oracle Label Security. See Appendix E, "Oracle Database Vault Packages" for more information.
For more information about Oracle Label Security labels, levels, and policies, see Oracle Label Security Administrator's Guide.
You can run reports on the Oracle Database Vault and Oracle Label Security integration. See "Related Reports" for more information.
Have the following requirements in place before you use Oracle Database Vault with Oracle Label Security:
Before you install Oracle Database Vault, you must have already installed Oracle Label Security.
Ensure that you have the appropriate Oracle Label Security policies defined. For more information, see Oracle Label Security Administrator's Guide.
Oracle Database Vault can control the maximum allowable data for a label in a database session by merging the labels of Oracle Database Vault factors that are associated to an Oracle Label Security policy. In brief, a label acts as an identifier for the access privileges of a database table row. A policy is a name associated with the labels, rules, and authorizations that govern access to table rows. See Oracle Label Security Administrator's Guide for more information about row labels and policies.
Use the following steps to define factors that contribute to the maximum allowable data label of an Oracle Label Security policy:
Log in to Oracle Database Vault Administrator using a database account granted with the DV_OWNER role.
At a minimum, you must have the DV_ADMIN role. "Starting Oracle Database Vault Administrator" explains how to log in.
Make the user LBACSYS account an owner of the realm.
The LBACSYS account is created in Oracle Label Security if you installed that product using the custom installation option. Before you can create an Oracle Label Security policy for use with Oracle Database Vault, you must make LBACSYS an owner for the realm you plan to use. See "Defining Realm Authorization" for more information.
In the Administration page, under Database Vault Feature Administration, click Label Security Integration.
In the Label Security Policies page:
To create a new label security policy, click Create.
To edit an existing label security policy, select it from the list and then click Edit.
Enter the following settings and then click OK:
General
Under General, enter the following settings:
Label Security Policy: From the list, select the Oracle Label Security policy that you want to use.
Algorithm: Optionally change the label-merging algorithm for cases when Oracle Label Security has merged two labels. In most cases, you may want to select LII - Minimum Level/Intersection/Intersection. This setting is the most commonly used method that Oracle Label Security administrators use when they want to merge two labels.
For more information on these label-merging algorithms, see Oracle Label Security Administrator's Guide. If you want to use the DVSYS.DBMS_MACADM package to specify a merge algorithm, see Table E-67, "Merge Algorithm Codes" for a full listing of possible merge algorithms.
Label for Initialization Errors: Optionally enter a label for initialization errors. The label specified for initialization errors is set when a configuration error or run-time error occurs during session initialization. You can use this setting to assign the session a data label that prevents access or updates to any data the policy protects until the issue is resolved.
Label Security Policy Factors
To select a factor to associate with an Oracle Label Security policy:
In the Available Factors list under Label Security Policy Factors, select the factor that you want to associate with the Oracle Label Security policy.
Click Move to move the factor to the Selected Factors list.
Note:
You can select multiple factors by holding down the Ctrl key as you click each factor that you want to select.After you associate a factor with an Oracle Label Security policy, you can label the factor identities using the labels for the policy. "Adding an Identity to a Factor" provides detailed information.
Note:
If you do not associate an Oracle Label Security policy with factors, then Oracle Database Vault maintains the default Oracle Label Security behavior for the policy.You can use Oracle Database Vault factors in conjunction with Oracle Label Security and Oracle Virtual Private Database (VPD) technology to restrict access to sensitive data. You can restrict this data so that it is only exposed to a database session when the correct combination of factors exists, defined by the security administrator, for any given database session.
To demonstrate how you can integrate Oracle Database Vault with Oracle Label Security, assume that you must create the following access controls for your company:
Allow access to sensitive accounting data to database sessions that originate from the corporate Intranet
Prevent access to this data to database sessions that originate over the corporate VPN network
To do so, you can create a factor named Network, whose identity values are Intranet and Remote. These values are resolved based on values of a second factor, Client_IP, which stores the IP address of the computer making the connection. Because of the interdependency of the two factors, the Network factor is considered a parent factor and the Client_IP factor is its child factor. You establish this interdependency by creating an identity map. Then finally, you associate an Oracle Label Security label with the Intranet and Remote identities in Network.
To accomplish this, follow these steps:
Step 2: Create Identity Maps for the Network Intranet and Remote Identities
Step 3: Associate the Network Factor with an Oracle Label Security Policy
First, create the Network factor:
In the Oracle Database Vault Administrator home page, select Factors.
In the Factors page, select Create.
In the Create Factors page, enter the following settings:
Name: Network
Description: Example factor for application access through network.
Factor Type: Physical
Factor Identification: By Factors
Evaluation: For Session.
Factor Labeling: By Self
Retrieval Method: Leave this field blank.
Validation Method: Leave this field blank.
Click OK.
The Network factor appears in the Factors page listing. Now you are ready to create its identities, Intranet and Remote.
In the Factors page, select Network and then click Edit.
In the Edit Factor page, go to the Identities section and click Create.
In the Create Identity page, enter the following settings:
Value: Intranet
Trust Level: Select Very Trusted.
Label Identity: EMPLOYEE_POLICY - HIGHLY_SENSITIVE
Click OK.
Repeat Step 6 and Step 7 to create the Remote identity, using the following settings:
Value: Remote
Trust Level: Select Trusted.
Label Identity: EMPLOYEE_POLICY - SENSITIVE
Click OK.
You do not need to create the Client_IP factor; it is supplied with Oracle Database Vault.
Next, you are ready to create an identity map for each of the Network factor Intranet and Remote identities. This map links the Network and Client_IP factors, by identifying the Network as the parent factor and Client_IP as its child factor.
First, create the identity map for the Intranet identity:
In the Factors page in Oracle Database Vault Administrator, select Network and then click Edit.
In the Edit Factor page, under Identities, select Intranet and then click Edit.
In the Edit Identity page, under Map Identity, click Create.
In the Create Identity Map page, enter the following settings:
Contributing Factor: Client_IP
Map Condition: Select Like. Then enter the following values:
Low Value: 192.168.10%
High Value: Leave this field blank.
Click OK.
Create a second mapping by repeating Step 3 and Step 4, using the following settings:
Contributing Factor: Client_IP
Map Condition: Select Is Null. Then enter the following values:
Low Value: NULL
High Value: Leave this field blank.
The second mapping handles situations in which a user logs in from the database host computer, the Client_IP factor will be null.
The settings should appear as follows:
Next, create an identity map for the Remote identity by using the following settings:
Contributing Factor: Client_IP
Map Condition: Select Like. Then enter the following values:
Low Value: 192.168.67%
High Value: Leave this field blank.
Once you have completed this mapping, you can check the values for the Network factor by executing the following statement in SQL*Plus from a corporate and remote/VPN network connection or session:
SQL> SELECT dvf.f$network FROM dual ----------------------------------------------- Remote
Finally, you are ready to associate the Network factor with an Oracle Label Security policy.
Follow these steps:
In the Administration page, under Database Vault Feature Administration, click Label Security Integration.
In the Label Security Policies page, click Create.
In the Create Label Security Policy page, enter the following settings:
Label Security Policy: Select EMPLOYEE_POLICY.
Algorithm: Select LII - Minimum Level/Intersection/Intersection.
Label for Initialization Errors: Leave this setting blank.
Label Security Policy Factors: Select Network and click Move to move it to the Selected Factors list.
Click OK.
To test this configuration, try logging on from both the local Intranet connection and a remote connection.
First, try the connection from the local Intranet connection. As you can see, you have access to all the records in HR.EMPLOYEES:
SQL> SELECT COUNT(*) FROM HR.EMPLOYEES; COUNT(*) ---------------------------------------------------------------------------- 350 SQL> SELECT DVF.F$NETWORK FROM DUAL; F$NETWORK ---------------------------------------------------------------------------- Intranet
Now try it from a remote connection. In this case, you have access only to a limited subset of the HR.EMPLOYEES table records:
SQL> SELECT COUNT(*) FROM HR.EMPLOYEES; COUNT(*) ---------------------------------------------------------------------------- 200 SQL> SELECT DVF.F$NETWORK FROM DUAL; F$NETWORK ---------------------------------------------------------------------------- Remote
Table 8-1 lists Oracle Database Vault reports that are useful for analyzing the Oracle Database Vault and Oracle Label Security integration. See Chapter 9, "Generating Oracle Database Vault Reports" for information about how to run these reports.
Table 8-1 Reports Related to Database Vault and Oracle Label Security Integration
| Report | Purpose |
|---|---|
|
"Factor Configuration Issues Report" |
To find factors in which the Oracle Label Security policy does not exist. |
|
"Identity Configuration Issues Report" |
To find any invalid label identities (the Oracle Label Security label for this identity has been removed and no longer exists). |
|
"Security Policy Exemption Report" |
To find accounts and roles that have the |
As part of securing the Oracle database environment, Oracle Database Vault prevents login as SYSDBA upon installation. However, Oracle Recovery Manager (RMAN) depends on SYSDBA in order to work. (Oracle will work on removing this dependency in a future release of RMAN.) For the time being, you can follow the steps in this section to allow the RMAN log in as SYSDBA where Database Vault is installed. These steps are for the Linux platform.
This section includes the following topics:
To enable the ability to log in using the SYSDBA role:
Log in using the Oracle software owner account (usually oracle) to the computer where Oracle Database is installed.
Go to the following directory, which is the default location for password files:
cd $ORACLE_HOME/dbs
Run the orapwd utility to create two copies of the password file: one with SYSDBA enabled and the second with SYSDBA disabled.
This way, you can enable or disable SYSDBA in the future by simply using the appropriate password file.
First, create a password file that disables SYSDBA:
orapwd file=$ORACLE_HOME/dbs/orapwdSID.sysdba_closed password=pwd nosysdba=y
Do not enter spaces around the equal (=) character.
Next, create a password file that enables SYSDBA:
orapwd file=$ORACLE_HOME/dbs/orapwdSID.sysdba_open password=pwd nosysdba=n
For more information on running orapwd, see "Enable or Disable Connections with the SYSDBA Privilege" in Oracle Database Vault Installation Guide.
Copy the password file to the $ORACLE_HOME/dbs directory, which is where Oracle Database checks for the password file.
cp –p orapwdSID.sysdba_open orapwdSID
When you are ready to disable the SYSDBA, you can enter the following command:
cp –p orapwdSID.sysdba_closed orapwdSID
After you have enabled SYSDBA, you can use Oracle Recovery Manager as you normally would. This section describes how you can create custom RMAN scripts that use secure file permission settings, and how you can avoid exposing the SYSDBA password on the command line or in scripts by using Secure External Password.
If you create custom scripts, Oracle recommends that you set the file permissions on your scripts securely. This section provides an example of creating scripts with secure file permission settings. Login to the machine were you run RMAN as the user who will run these scripts and do the following:
Follow these steps:
Log in to the computer where Oracle Recovery Manager is running.
Log in as the user who normally runs the backup scripts.
Run the following commands to create a directory for the RMAN scripts:
mkdir rman_scripts chmod 700 rman_scripts cd rman_scripts
Changing the directory and file permissions to 700 ensures that only the file owner operating system account can access it, in addition to the root account.
Create a nightly backup script, for example:
vi nightly_backup.sh
In this backup script, enter the backup script code, then save the file and then exit vi.
Now, you can run the script to perform backups.
You should prevent exposing the SYSDBA password on the command line and in clear text within scripts. You can use the Oracle External Password utility to store the password in a wallet to authenticate the database. The following steps explain how to accomplish this. For additional information on this feature, see Chapter 9, "Secure External Password Store," in Oracle Database Security Guide.
Follow these steps:
Edit the tnsnames.ora file on both the server and client computers.
vi tnsnames.ora
In tnsnames.ora, add a second copy of the database entry that you want to connect to, and then rename this entry for Oracle Recovery Manager (for example, RMAN).
ORACLESCOTT = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = full_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = database_service_name) ) ) RMANSYS = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = full_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = database_service_name) ) )
Save and exit the tnsnames.ora file.
Create a wallet.
mkstore -wrl $ORACLE_HOME/network/admin -create
When prompted, enter and then re-enter the password.
This password is the wallet password. You can choose any password that you want.
Enter password: wallet_password Enter password again: wallet_password
This creates two files, ewallet.p12 and cwallet.sso, in the $ORACLE_HOME/network/admin directory.
Go to the admin directory:
cd $ORACLE_HOME/network/admin
Add the RMAN connect string that you created in Step 2 to the wallet by using the following syntax:
mkstore -wrl $ORACLE_HOME/network/admin -createCredential db_connect_string username sys_password
For example:
mkstore -wrl $ORACLE_HOME/network/admin -createCredential "RMANSYS" "SYS" sys_password
The following message should appear, which confirms that the credential has been successfully created:
Create credential oracle.security.client.connect_string1
Add the following entries to the sqlnet.ora file, which is by default located in $ORACLE_HOME/network/admin:
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = full_wallet_location_path)))
SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
Stop and then restart the database listener:
lsnrctl stop listener_name lsnrctl start listener_name
Now you can use the wallet credential to log in as SYS. For example:
sqlplus /@RMANSYS as sysdba
When you have completed the Oracle Recovery Manager backup, you can disable SYSDBA again by simplifying copying the orapwdSID.sysdba_closed file over the orapwdSID file.
cd $ORACLE_HOME/dbs cp –p orapwSID.sysdba_closed orapwSID
