This chapter contains:
A rule set is a collection of one or more rules that you can associate with a realm authorization, factor assignment, command rule, or secure application role. The rule set evaluates to true or false based on the evaluation of each rule it contains and the evaluation type (All True or Any True). A rule within a rule set is a PL/SQL expression that evaluates to true or false. You can create a rule and add the rule to multiple rule sets.
You can use rule sets to accomplish the following activities:
As a further restriction to realm authorization, to define the conditions under which realm authorization is active
To define when to allow a command rule
To enable a secure application role
To define when to assign the identity of a factor
When you create a rule set, Oracle Database Vault makes it available for selection when you configure the authorization for a realm, command rule, factor, or secure application role.
You can run reports on the rule sets that you create in Oracle Database Vault. See "Related Reports and Data Dictionary Views" for more information.
This chapter explains how to configure rule sets by using Oracle Database Vault Administrator. To configure rule sets by using the PL/SQL interfaces and packages provided by Oracle Database Vault, refer to the following chapters:
Oracle Database Vault provides a set of default rules sets that you can customize for your needs. The default rule sets are as follows:
Allow Sessions: Controls the ability to create a session in the database. This rule set enables you to add rules to control database logins using the CONNECT command rule. The CONNECT command rule is useful to control or limit SYSDBA access to programs that require its use. This rule set is not populated.
Allow System Parameters: Controls the ability to set system initialization parameters. For Oracle Database 11g Release 2 (11.2), the Allow Fine Grained Control of System Parameters rule set replaces this rule set, but it is still supported for backward compatibility. The Allow System Parameters rule set is not associated with any commands, but its rules are still available and can be used with any custom rule set. Oracle recommends that you use the Allow Fine Grained Control of System Parameters rule set.
Allow Fine Grained Control of System Parameters: Provides a very flexible, fine-grained control over initialization parameters that manage system security, dump or destination location, backup and restore settings, optimizer settings, PL/SQL debugging, and security parameters. It affects the following initialization parameters: AUDIT_FILE_DEST, AUDIT_SYS_OPERATIONS, AUDIT_TRAIL, BACKGROUND_DUMP_DEST, BLOCK_SYSTEM_TRIG_ENABLED, CORE_DUMP_DEST, CONTROL_FILES, DB_CREATE_ONLINE_LOG_DEST, DB_RECOVERY_FILE_DEST, DUMP_DATAFILE, O7_DICTIONARY_ACCESSIBILITY, OPTIMIZER_SECURE_VIEW_MERGING, OS_ROLES, PLSQL_DEBUG, RECYCLEBIN (but does not prevent disabling the recycle bin), REMOTE_OS_ROLES, SQL92_SECURITY, USER_DUMP. See Oracle Database Reference for detailed information about initialization parameters.
Can Grant VPD Administration: Controls the ability to grant the GRANT EXECUTE or REVOKE EXECUTE privileges on the Oracle Virtual Private Database DBMS_RLS package, with the GRANT and REVOKE statements.
Allow Oracle Data Pump Operation: Contains rules that describe each user authorization that was created by the DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure. The rule includes the user login account and the level of access the user is allowed: the entire database, a schema within the database, or a table within this schema. When a user attempts to perform an Oracle Data Pump export or import operation, Oracle Database Vault checks the authorizations defined in this rule set. If the user's authorizations are not defined here, then he or she is not permitted to perform the export or import operation.
See "Using Oracle Data Pump in an Oracle Database Vault Environment" for more information.
Allow Scheduler Job: Contains rules that describe each user authorization that was created by the DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure. If you do not define the user's authorizations here, then he or she still can create a job. But if the user runs a job under another schema, the job will fail when this job accesses Oracle Database Vault-protected objects. The rule includes the user login account and the level of access the user is allowed: the entire database or a schema within the database. When a user attempts to schedule a database job, Oracle Database Vault checks the authorizations defined in this rule set. If the user's authorizations are not defined here, then he or she is not permitted to create the job.
See "Scheduling Database Jobs in an Oracle Database Vault Environment" for more information.
Can Maintain Accounts/Profiles: Controls the roles that manage user accounts and profiles, through the CREATE USER, DROP USER, CREATE PROFILE, ALTER PROFILE, or DROP PROFILE statements.
Can Maintain Own Account: Allows the accounts with the DV_ACCTMGR role to manage user accounts and profiles with the ALTER USER statement. Also allows individual accounts to change their own password using the ALTER USER statement. See "DV_ACCTMGR Database Vault Account Manager Role" for more information about the DV_ACCTMGR role.
Disabled: Convenience rule set to quickly disable security configurations like realms, command rules, factors, and secure application roles.
Enabled: Convenience rule set to quickly enable system features.
In general, to create a rule set, you first create the rule set itself, and then you edit the rule set to associate it with one or more rules. You can associate a new rule with the rule set, add existing rules to the rule set, or delete a rule association from the rule set.
See also the following sections:
"Guidelines for Designing Rule Sets" for advice on designing rule sets
"Oracle Database Vault PL/SQL Rule Functions" for a set of functions that you can use in rule expressions
"Rule Set Configuration Issues Report" to check the configuration of the rule sets for your database
To create a rule set:
Log in to Oracle Database Vault Administrator as a user who has been granted the DV_OWNER or DV_ADMIN role.
"Starting Oracle Database Vault" explains how to log in.
In the Administration page, under Database Vault Feature Administration, click Rule Sets.
In the Rule Sets page, click Create.
In the Create Rule Set page, enter the following settings, and then click OK:
General
Enter the following settings:
Name: Enter a name for the rule set. It can contain up to 90 characters in mixed-case. Spaces are allowed. This attribute is mandatory.
Oracle suggests that you start the name with a noun and complete it with the realm or command rule name to which the rule set is attached. For example:
Limit SQL*Plus access
Description: Enter a description of the functionality for the rule set. It can have up to 1024 characters in mixed-case. This attribute is optional.
You may want to document the business requirement of the rule set. For example:
Rule to limit access to SQL*Plus
Status: Select either Enabled or Disabled to enable or disable the rule set during run time. Rule sets are enabled by default. This attribute is mandatory.
Evaluation Options: If you plan to assign multiple rules to a rule set, select one of the following settings:
All True: Default. All rules in the rule set must evaluate to true for the rule set itself to evaluate to true.
Any True: At least one rule in the rule set must evaluate to true for the rule set itself to evaluate to true.
If you want to determine how often a rule set is evaluated when it is accessed by a command rule, then you can use the is_static parameter of the DVSYS.DBMS_MACADM.CREATE_RULE_SET procedure. See "CREATE_RULE_SET Procedure" for more information.
Audit Options
Select from the following options to generate an audit record for the rule set. Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ system file, described in Appendix A, "Auditing Oracle Database Vault."
This attribute is mandatory. The settings are:
Audit Disabled: Does not create an audit record under any circumstances.
Audit On Failure: Default. Creates an audit record when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression.
Audit On Success or Failure: Creates an audit record whenever a rule set is evaluated.
For additional audit options, see "CREATE_RULE_SET Procedure".
The Oracle Database Vault audit trail, written to the DVSYS.AUDIT_TRAIL$ system table, contains the fields RULE_SET_NAME and RULE_SET_ID. These fields are populated when a rule set is associated with a realm authorization and a command authorization, and the rule set is configured to audit under some circumstances. See Appendix A, "Auditing Oracle Database Vault," for more information.
Error Handling Options
Enter the following settings to control the messaging to the database session when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression:
Fail Options: Select either Show Error Message (the default) or Do Not Show Error Message.
An advantage of selecting Do Not Show Error Message and then enabling auditing is that you can track the activities of a potential intruder. The audit report reveals the activities of the intruder, yet the intruder is unaware that you are doing this because he or she does not see any error messages.
Fail Code: Enter a number in the ranges of -20000 to -20999 or 20000 to 20999. The error code is displayed with the Fail Message (created next) when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression. If you omit this setting, then Oracle Database Vault displays the following error code:
ORA-01031: Insufficient privileges
Fail Message: Enter a message, up to 80 characters in mixed-case, to associate with the fail code you specified under Fail Code. The error message is displayed when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression. If you do not specify an error message, then Oracle Database Vault displays a generic error message.
Custom Event Handler Option: Select one of the following options to determine when to run the Custom Event Handler Logic (created next).
Handler Disabled: Default. Does not run any custom event method.
Execute On Failure: Runs the custom event method when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression.
Execute On Success: Runs the custom event method when the rule set evaluates to true.
You can create a custom event method to provide special processing outside the standard Oracle Database Vault rule set auditing features. For example, you can use an event handler to initiate a workflow process or send event information to an external system.
Custom Event Handler Logic: Enter a PL/SQL expression up to 255 characters in mixed-case. An expression may include any package procedure or standalone procedure. You can create your own expression or use the PL/SQL interfaces described in Chapter 15, "Using the Oracle Database Vault PL/SQL Interfaces."
Write the expression as a fully qualified procedure (such as schema.procedure_name). Do not include complete SQL statements. If you are using application package procedures or standalone procedures, you must provide DVSYS with the EXECUTE privilege on the object. The procedure signature can be in one of the following two forms:
PROCEDURE my_ruleset_handler(p_ruleset_name IN VARCHAR2, p_ruleset_rules IN BOOLEAN): Use this form when the name of the rule set and its return value are required in the handler processing.
PROCEDURE my_ruleset_handler: Use this form when the name of the rule set and its return value are not required in the handler processing.
When you define the expression in the user interface that uses one of these two formats, put the expression in the following form:
myschema.my_ruleset_handler
After you create a rule set, you are ready to create rules to attach to the rule set. To do so, you edit the new rule set, and then define its rules.
To configure or edit a rule set:
In the Oracle Database Vault Administration page, select Rule Sets.
In the Rule Set page, select the rule set that you want to edit.
Click Edit.
Modify the rule set as necessary, and then click OK.
|
See Also:
|
After you create a new rule set, you can associate it with one or more rules. When you create a new rule, it is automatically added to the current rule set. You also can add existing rules to the rule set. Alternatively, you can omit adding rules to the rule set and use it as a template for rule sets you may want to create in the future.
The rule set evaluation depends on the evaluation of its rules using the Evaluation Options (All True or Any True). If a rule set is disabled, Oracle Database Vault evaluates the rule set to true without evaluating its rules.
See "How Rule Sets Work" for information on how rules are evaluated, how to nest rules, and how to create rules that exclude a particular user, such as a privileged user.
To create and add a rule to a rule set:
In the Oracle Database Vault Administration page, select Rule Sets.
In the Rule Sets page, select the rule set to which you want to create and add a rule, and then select Edit.
In the Edit Rule Set Page, scroll down to Rules Associated To The Rule Set and select Create.
In the Create Rule page, enter the following settings:
Name: Enter a name for the rule. Use up to 90 characters in mixed-case.
Oracle suggests that you start the name with a verb and complete the name with the purpose of the rule. For example:
Prevent non-admin access to SQL*Plus
Because rules do not have a Description field, make the name explicit but be sure to not exceed over 90 characters.
Rule Expression: Enter a PL/SQL expression that fits the following requirements:
It is valid in a SQL WHERE clause.
It can be a freestanding and valid PL/SQL Boolean expression such as the following:
TO_CHAR(SYSDATE,'HH24') = '12'
It must evaluate to a Boolean (TRUE or FALSE) value.
It must be no more than 255 characters long.
It can contain existing and compiled PL/SQL functions from the current database instance. Ensure that these are fully qualified functions (such as schema. function_name). Do not include complete SQL statements.
If you want to use application package functions or standalone functions, you must grant the DVSYS account the EXECUTE privilege on the function. Doing so reduces the chances of errors when you add new rules.
Ensure that the rule works. You can test the syntax by running the following statement in SQL*Plus:
SELECT rule_expression FROM DUAL;
For example, suppose you have created the following the rule expression:
SYS_CONTEXT('USERENV','SESSION_USER') != 'TSMITH'
You could test this expression as follows:
SELECT SYS_CONTEXT('USERENV','SESSION_USER') FROM DUAL;
See the following sections for functions that you can use in the rule set expression:
For additional examples of expressions, see the rule defined in the rule sets provided with Oracle Database Vault. "Default Rule Sets" lists these rule sets.
Click OK.
The Edit Rule Set page appears. By default, the new rule is added to the rule set.
Editing a Rule
The changes you make to a rule apply to all rule sets that include the rule.
To edit a rule:
In the Edit Rule Set page, scroll to Rules Associated To The Rule Set.
Select the rule you want to edit and click Edit.
In the Edit Rule page, modify the rule as necessary.
Click OK.
Removing a Rule from a Rule Set
Before you remove a rule from a rule set, you can locate the various references to it by querying the rules-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information.
To remove a rule from a rule set:
In the Edit Rule Set page, scroll to Rules Associated To The Rule Set.
Select the rule you want to delete and click Remove.
In the Confirmation page, click Yes.
After you remove the rule from the rule set, it still exists. If you want, you can associate it with other rule sets. If you want to delete the rule, use the DVSYS.DBMS_MACADM.DELETE_RULE function, described in "Rule Set Procedures Within DVSYS.DBMS_MACADM". For example, to delete the rule Night Shift, log in to SQL*Plus as the Database Vault Owner and enter the following statement:
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Night Shift');
To add existing rules to a rule set:
In the Rule Sets page, select the rule set that you want to add rules to, and then select Edit.
Under Rules Associated To The Rule Set, select Add Existing Rules.
In the Add Existing Rules page, select the rules you want, and then click Move (or Move All, if you want all of them) to move them to the Selected Rules list.
You can select multiple rules by holding down the Ctrl key as you click each rule.
Click OK.
Before you delete a rule set, you can locate the various references to it by querying the rules-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information.
If other Database Vault objects, such as command rules, reference the rule set, then remove the reference.
You can delete a rule set only if no other Database Vault objects are referencing it.
In the Oracle Database Vault Administration page, select Rule Sets.
In the Rule Set page, select the rule set that you want to remove.
Click Remove.
In the Confirmation page, click Yes.
The rule set is deleted. However, the rules associated with the rule set are not deleted.
This section describes how rule sets work in the following ways:
Oracle Database Vault evaluates the rules within a rule set as a collection of expressions. If you have set Evaluation Options to All True and if a rule fails the evaluation, then the evaluation stops at that point, instead of attempting to evaluate the rest of the rules in the rule set. Similarly, if Evaluation Options is set to Any True and if a rule evaluates to true, the evaluation stops at that point. If a rule set is disabled, Oracle Database Vault evaluates it to true without evaluating its rules.
You can nest one or more rules within the rule set. For example, suppose you want to create a nested rule, Is Corporate Network During Maintenance, that performs the following two tasks:
It limits table modifications only when the database session originates within the corporate network.
It restricts table modifications during the system maintenance window scheduled between 10:00 p.m. and 10:59 p.m.
The rule definition would be as follows:
DVF.F$NETWORK = 'Corporate' AND TO_CHAR(SYSDATE,'HH24') between '22' AND '23'
You can create it using a factor function. See "Oracle Database Vault PL/SQL Factor Functions" for more information. Chapter 7 explains how to create facto rs.
You can also create rules to apply to everyone except one user (for example, a privileged user). The rule definition for this type of rule can be as follows:
SYS_CONTEXT('USERENV','SESSION_USER') = 'SUPERADMIN_USER' OR additional_rule
If the current user is a privileged user, then the system evaluates the rule to true without evaluating additional_rule. If the current user is not a privileged user, then the evaluation of the rule depends on the evaluation of additional_rule.
This section contains:
Step 3: Configure an Access Control List File for Network Services
Step 4: Create a Rule Set and a Command Rule to Use the Email Security Alert
In the following tutorial, you create an email alert that is sent when a user attempts to alter a table outside a maintenance period. To do this, you must create a rule to set the maintenance period hours, attach this rule to a rule set, and then create a command rule to allow the user to alter the table. You then associate the rule set with this command rule, which then sends the email alert when the user attempts to use the ALTER TABLE SQL statement outside the maintenance period.
Log in to SQL*Plus as SYS using the SYSDBA privilege, and then install the UTL_MAIL package.
sqlplus sys as sysdba
Enter password: password
@$ORACLE_HOME/rdbms/admin/utlmail.sql
@$ORACLE_HOME/rdbms/admin/prvtmail.plb
The UTL_MAIL package enables you to manage email. See Oracle Database PL/SQL Packages and Types Reference for more information about UTL_MAIL. However, be aware that currently, the UTL_MAIL PL/SQL package do not support SSL servers.
Check the current value of the SMTP_OUT_SERVER parameter, and make a note of this value so that you can restore it when you complete this tutorial.
For example:
SHOW PARAMETER SMTP_OUT_SERVER
Output similar to the following appears:
NAME TYPE VALUE ----------------------- ----------------- ---------------------------------- SMTP_OUT_SERVER string some_value.example.com
Issue the following ALTER SYSTEM statement:
ALTER SYSTEM SET SMTP_OUT_SERVER="imap_mail_server.example.com";
Replace imap_mail_server.example.com with the name of your SMTP server, which you can find in the account settings in your email tool. Enclose these settings in quotation marks. For example:
ALTER SYSTEM SET SMTP_OUT_SERVER="my_imap_mail_server.example.com"
Connect as SYS using the SYSOPER privilege and then restart the database.
CONNECT SYS/AS SYSOPER
Enter password: password
SHUTDOWN IMMEDIATE
STARTUP
Ensure that the SMTP_OUT_SERVER parameter setting is correct.
CONNECT SYS AS SYSDBA
Enter password: password
SHOW PARAMETER SMTP_OUT_SERVER
Output similar to the following appears:
NAME TYPE VALUE ----------------------- ----------------- ---------------------------------- SMTP_OUT_SERVER string my_imap_mail_server.example.com
Ensure that you are connected as SYS using the SYSDBA privilege, and then grant the following privileges to a user who has been granted the DV_OWNER role.
(Alternatively, you can select a user who has been granted the DV_ADMIN role, but for this tutorial, you will select a user who has the DV_OWNER role.)
For example:
CONNECT SYS AS SYSDBA
Enter password: password
GRANT CREATE PROCEDURE, DROP ANY PROCEDURE TO lbrown_dvowner;
GRANT EXECUTE ON UTL_TCP TO lbrown_dvowner;
GRANT EXECUTE ON UTL_SMTP TO lbrown_dvowner;
GRANT EXECUTE ON UTL_MAIL TO lbrown_dvowner;
GRANT EXECUTE ON DBMS_NETWORK_ACL_ADMIN TO lbrown_dvowner;
The UTL_TCP, UTL_SMTP, UTL_MAIL, and DBMS_NETWORK_ACL_ADMIN PL/SQL packages will be used by the email security alert that you create.
Connect to SQL*Plus as the DV_OWNER user.
For example:
CONNECT lbrown_dvowner
Enter password: password
Create the following procedure:
CREATE OR REPLACE PROCEDURE email_alert AS
msg varchar2(20000) := 'Realm violation occurred for the ALTER TABLE Command Security Policy rule set. The time is: ';
BEGIN
msg := msg||to_char(SYSDATE, 'Day DD MON, YYYY HH24:MI:SS');
UTL_MAIL.SEND (
sender => 'youremail@example.com',
recipients => 'recipientemail@example.com',
subject => 'Table modification attempted outside maintenance!',
message => msg);
END email_alert;
/
Replace youremail@example.com with your email address, and recipientemail@example.com with the email address of the person you want to receive the notification.
Grant the EXECUTE permission on this procedure to DVSYS.
GRANT EXECUTE ON email_alert TO DVSYS;
Before you can use PL/SQL network utility packages such as UTL_MAIL, you must configure an access control list (ACL) file that enables fine-grained access to external network services. For detailed information about this topic, see Oracle Database Security Guide.
To configure an access control list for the email alert:
As the DV_OWNER user, in SQL*Plus, create the following access control list and its privilege definitions.
BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'mail_server_permissions.xml', description => 'Enables network permissions for the mail server', principal => 'LBROWN_DVOWNER', is_grant => TRUE, privilege => 'connect'); END; /
Ensure that you enter your exact user name for the principal setting, in upper-case letters. For this tutorial, enter the name of the Database Vault Owner account (for example, LBROWN_DVOWNER).
Assign the access control list to the outgoing SMTP network host for your email server.
BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'mail_server_permissions.xml', host => 'SMTP_OUT_SERVER_setting', lower_port => port); END; /
In this example:
SMTP_OUT_SERVER_setting: Enter the SMTP_OUT_SERVER setting that you set for the SMTP_OUT_SERVER parameter in "Step 1: Install and Configure the UTL_MAIL PL/SQL Package". This setting should match exactly the setting that your email tool specifies for its outgoing server.
port: Enter the port number that your email tool specifies for its outgoing server. Typically, this setting is 25. Enter this value for both the lower_port and upper_port settings. (Currently, the UTL_MAIL package does not support SSL. If your mail server is an SSL server, then enter 25 for the port number, even if the mail server uses a different port number.)
Commit your changes to the database.
COMMIT;
Test the settings that you have created so far.
EXEC EMAIL_ALERT; COMMIT;
SQL*Plus should display a PL/SQL procedure successfully completed message, and in a moment, depending on the speed of your email server, you should receive the email alert.
If you receive an ORA-24247: network access denied by access control list (ACL) error followed by ORA-06512: at stringline string errors, then check the settings in the access control list file.
As the DV_OWNER user, create the following rule set:
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE_SET(
rule_set_name => 'ALTER TABLE Command Security Policy',
description => 'This rule set allows ALTER TABLE only during the
maintenance period.',
enabled => 'Y',
eval_options => 1,
audit_options => DBMS_MACUTL.G_RULESET_AUDIT_FAIL,,
fail_options => DBMS_MACUTL.G_RULESET_FAIL_SILENT,
fail_message => '',
fail_code => NULL,
handler_options => DBMS_MACUTL.G_RULESET_HANDLER_FAIL,
handler => 'dbavowner.email_alert');
END;
/
Create a rule similar to the following.
For now, set the rule expression to be during the time you test it. For example, if you want to test it between 2 p.m. and 3 p.m., create the rule as follows:
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Restrict Access to Maintenance Period', rule_expr => 'TO_CHAR(SYSDATE,''HH24'') BETWEEN ''14'' AND ''15'''); END; /
Ensure that you use two single quotation marks instead of double quotation marks for HH24, 14, and 15.
You can check the system time on your computer by issuing the following SQL statement:
SELECT TO_CHAR(SYSDATE,'HH24') FROM DUAL;
Output similar to the following appears:
TO -- 14
Later on, when you are satisfied that the rule works, you can update it to a time when your site typically performs maintenance work (for example, between 7 p.m. and 10 p.m), as follows:
BEGIN DVSYS.DBMS_MACADM.UPDATE_RULE( rule_name => 'Restrict Access to Maintenance Period', rule_expr => 'TO_CHAR(SYSDATE,''HH24'') BETWEEN ''19'' AND ''22'''); END; /
Add the Restrict Access to Maintenance Period rule to the ALTER TABLE Command Security Policy rule set.
BEGIN DBMS_MACADM.ADD_RULE_TO_RULE_SET( rule_set_name => 'ALTER TABLE Command Security Policy', rule_name => 'Restrict Access to Maintenance Period'); END; /
Create the following command rule:
BEGIN DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE( command => 'ALTER TABLE', rule_set_name => 'ALTER TABLE Command Security Policy', object_owner => 'SCOTT', object_name => '%', enabled => 'Y'); END; /
Commit these updates to the database.
COMMIT;
Connect to SQL*Plus as user SCOTT.
For example:
CONNECT SCOTT
Enter password: password
If the SCOTT account is locked and expired, then a user with the DV_ACCTMGR role can unlock this account and create a new password as follows:
ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
Replace password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
As the user SCOTT, create a test table.
CREATE TABLE mytest (col1 number);
Change the system time on your computer to a time when the ALTER TABLE Command Security Policy rule set takes place (for example, between 2 p.m. and 3 p.m).
UNIX: Log in as root and use the date command to set the time. For example, assuming the date today is December 14, 2011, you would enter the following:
su root
Password: password
date --set="14 DEC 2011 14:00:00"
Windows: Double-click the clock icon, which is typically at the lower right corner of the screen. In the Date and Time Properties window, set the time to 2 p.m., and then click OK.
Try altering the my_test table.
ALTER TABLE mytest ADD (col2 number); Table altered.
SCOTT should be able to alter the mytest table during this time.
Reset the system time to a time outside the Restrict Access to Maintenance Period time.
Log in as SCOTT and try altering the my_test table again.
CONNECT SCOTT
Enter password: password
ALTER TABLE mytest ADD (col3 number);
The following output should appear:
ORA-47400: Command Rule violation for ALTER TABLE on SCOTT.MYTEST
SCOTT cannot alter the mytest table. In a moment, you should receive an email with the subject header Table modification attempted outside maintenance! and with a message similar to the following:
Realm violation occurred for the ALTER TABLE Command Security Policy rule set. The time is: Wednesday 06 MAY, 2009 14:24:25
Reset the system time to the correct time.
Connect to SQL*Plus as the DV_OWNER user, and then in the order shown, drop the Oracle Database Vault rule components.
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('ALTER TABLE Command Security Policy', 'Restrict Access to Maintenance Period');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Restrict Access to Maintenance Period');
EXEC DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE('ALTER TABLE', 'SCOTT', '%');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('ALTER TABLE Command Security Policy');
Drop the email_alert PL/SQL procedure.
DROP PROCEDURE email_alert;
Remove the access control list.
EXEC DBMS_NETWORK_ACL_ADMIN.DROP_ACL ('email_alert_permissions.xml');
Connect as user SCOTT and remove the mytest table.
CONNECT SCOTT
Enter password: password
DROP TABLE mytest;
Connect as SYS using the SYSDBA privilege and then revoke the EXECUTE privilege on the UTL_TCP, UTL_SMTP, and UTL_MAIL PL/SQL packages from the DV_OWNER user.
For example:
REVOKE EXECUTE ON UTL_TCP FROM lbrown_dvowner; REVOKE EXECUTE ON UTL_SMTP FROM lbrown_dvowner; REVOKE EXECUTE ON UTL_MAIL FROM lbrown_dvowner; REVOKE EXECUTE ON DBMS_NETWORK_ACL_ADMIN from lbrown_dvowner;
Set the SMTP_OUT_SERVER parameter to its original value.
For example:
ALTER SYSTEM SET SMTP_OUT_SERVER="some_value.example.com";
Connect as SYS using the SYSOPER privilege and then restart the database.
CONNECT SYS/AS SYSOPER
Enter password: password
SHUTDOWN IMMEDIATE
STARTUP
This section contains:
Step 2: Create a Function to Check if User patch_boss Is Logged In
Step 3: Create Rules, a Rule Set, and a Command Rule to Control the Users' Access
In this tutorial, you configure a rule set that defines two-person integrity (TPI), also called dual key security, dual key connection, and two-man rule security. In this type of security, two users are required to authorize an action instead of one user. The idea is that one user provides a safety check for the other user before that user can proceed with a task. Two-person integrity provides an additional layer of security for actions that potentially can be dangerous. This type of scenario is often used for tasks such as database patch updates, which is what this tutorial will demonstrate. One user, patch_user must log in to perform a database patch upgrade, but the only way that he can do this is if his manager, patch_boss is already logged in. You will create a function, rules, a rule set, and a command rule to control patch_user's ability to log in.
You must create the following two users for this tutorial:
patch_boss acts in a supervisory role: If patch_boss is not logged in, then the patch_user user cannot log in.
patch_user is the user who is assigned to perform the patch upgrade. However, for this tutorial, user patch_user does not actually perform a patch upgrade. He only attempts to log in.
To create the users:
Connect to SQL*Plus as a user who has been granted the DV_ACCTMGR role.
For example:
CONNECT amalcolm_dvacctmgr
Enter password: password
Create the following users.
CREATE USER patch_boss IDENTIFIED BY password; CREATE USER patch_user IDENTIFIED BY password;
Replace password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
Connect as user SYS with the SYSDBA privilege and grant privileges to the patch_boss and patch_user users.
CONNECT SYS AS SYSDBA
Enter password: password
GRANT CREATE SESSION TO patch_boss, patch_user;
Grant the following privileges to the DV_OWNER or DV_ADMIN user.
For example:
GRANT CREATE PROCEDURE TO lbrown_dvowner; GRANT SELECT ON V_$SESSION TO lbrown_dvowner;
The V_$SESSION table is the underlying table for the V$SESSION dynamic view.
In a real-world scenario, you also would log in as the DV_OWNER user and grant the DV_PATCH_ADMIN role to user patch_user (but not to patch_boss). But because you are not really going to perform a database patch upgrade in this tutorial, you do not need to grant this role to user patch_user.
The function that you must create, check_boss_logged_in, does just that: When user patch_user tries to log in to SQL*Plus, it checks if user patch_boss is already logged in by querying the V$SESSION data dictionary view.
To create the check_boss_logged_in function:
As the DV_OWNER or DV_ADMIN user, create the check_boss_logged_in function as follows:
CREATE OR REPLACE FUNCTION check_boss_logged_in return varchar2 authid definer as v_session_number number := 0; v_allow varchar2(10) := 'TRUE'; v_deny varchar2(10) := 'FALSE'; BEGIN SELECT COUNT(*) INTO v_session_number FROM SYS.V_$SESSION WHERE USERNAME = 'PATCH_BOSS'; -- Enter the user name in capital letters. IF v_session_number > 0 THEN RETURN v_allow; ELSE RETURN v_deny; END IF; END check_boss_logged_in; /
Grant the EXECUTE privilege on the check_boss_logged_in function to the DVSYS schema.
GRANT EXECUTE ON check_boss_logged_in to DVSYS;
Next, you must create two rules, a rule set to which you will add them, and a command rule. The rule set triggers the check_boss_logged_in function when user patch_user tries to logs in to the database.
To create the rules and rule set:
Connect as a user who has been granted the DV_OWNER or DV_ADMIN role.
For example:
CONNECT lbrown_dvowner
Enter password: password
Create the Check if Boss Is Logged In rule, which checks that the patch_user user is logged in to the database. In the definition, replace lbrown_dvowner with the name of the DVOWNER or DV_ADMIN user who created the check_boss_logged_in function.
If the check_boss_logged_in function returns TRUE (that is, patch_boss is logged in to another session), then patch_user can log in.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check if Boss Is Logged In',
rule_expr => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''PATCH_USER'' and lbrown_dvowner.check_boss_logged_in = ''TRUE'' ');
END;
/
Enter the user name, PATCH_USER, in upper-case letters, which is how the SESSION_USER parameter stores it.
Create the Allow Connect for Other Database Users rule, which ensures that the user logged in (patch_user) is not user patch_boss. It also enables all other valid users to log in.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Allow Connect for Other Database Users',
rule_expr => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''PATCH_USER''');
END;
/
COMMIT;
Create the Dual Connect for Boss and Patch rule set, and then add the two rules to it.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE_SET(
rule_set_name => 'Dual Connect for Boss and Patch',
description => 'Checks if both boss and patch users are logged in.',
enabled => 'Y',
eval_options => 2,
audit_options => DBMS_MACUTL.G_RULESET_AUDIT_FAIL,
fail_options => DBMS_MACUTL.G_RULESET_FAIL_SILENT,
fail_message =>'',
fail_code => NULL,
handler_options => DBMS_MACUTL.G_RULESET_HANDLER_OFF,
handler => ''
);
END;
/
BEGIN
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET(
rule_set_name => 'Dual Connect for Boss and Patch',
rule_name => 'Check if Boss Is Logged In'
);
END;
/
BEGIN
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET(
rule_set_name => 'Dual Connect for Boss and Patch',
rule_name => 'Allow Connect for Other Database Users'
);
END;
/
Create the following CONNECT command rule, which permits user patch_user to connect to the database only if patch_boss is already logged in.
BEGIN
DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE(
command => 'CONNECT',
rule_set_name => 'Dual Connect for Boss and Patch',
object_owner => '%',
object_name => '%',
enabled => 'Y');
END;
/
COMMIT;
Exit SQL*Plus.
EXIT
Create a second shell, for example:
xterm &
In the first shell, try to log in as user patch_user.
sqlplus patch_user
Enter password: password
ERROR:
ORA-47400: Command Rule violation for CONNECT on LOGON
Enter user-name:
User patch_user cannot log in until user patch_boss is already logged in. (Do not try the Enter user-name prompt yet.)
In the second shell, log in as user patch_boss.
sqlplus patch_boss
Enter password: password
Connected.
User patch_boss can log in.
Go back to the first shell, and then try logging in as user patch_user again.
Enter user_name: patch_user
Enter password: password
This time, user patch_user is deemed a valid user, so now he can log in.
In the session for the user patch_boss, exit SQL*Plus and then close the shell.
EXIT
In the first shell, connect the DV_ACCTMGR user and remove the users you created.
CONNECT amalcolm_dvacctmgr
Enter password: password
DROP USER patch_boss;
DROP USER patch_user;
Connect as user SYS with the SYSDBA privilege and revoke the privileges that you had granted to the DV_OWNER or DV_ADMIN user.
CONNECT SYS AS SYSDBA
Enter password: password
REVOKE CREATE PROCEDURE FROM lbrown_dvowner;
REVOKE SELECT ON V_$SESSION FROM lbrown_dvowner;
Connect as the DV_OWNER or DV_ADMIN user and drop the rules, rule set, and command rule, in the order shown.
CONNECT lbrown_dvowner
Enter password: password
DROP FUNCTION check_boss_logged_in;
EXEC DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE('CONNECT', '%', '%');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('Dual Connect for Boss and Patch', 'Check if Boss Is Logged In');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('Dual Connect for Boss and Patch', 'Allow Connect for Other Database Users');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check if Boss Is Logged In');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Allow Connect for Other Database Users');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('Dual Connect for Boss and Patch');
COMMIT;
Follow these guidelines for designing rule sets:
You ca0#n share rules among multiple rule sets. This lets you develop a library of reusable rule expressions. Oracle recommends that you design such rules to be discrete, single-purpose expressions.
You can design a rule set so that its evaluation is static, that is, it is evaluated only once during a user session. Alternatively, it can be evaluated each time the associated command rule accesses the rule set. If the rule set is evaluated only once, then the evaluated value is reused throughout the user session each time the command rule accesses the rule set. Using static evaluation is useful in cases where the rule set must be accessed multiple times but the conditions on which the rule set depend do not change during that session. An example would be a SELECT command rule associated with a rule set when the same SELECT statement occurs multiple times and if the evaluated value is acceptable to use again, rather than evaluating the rule set each time the SELECT occurs.
To control the static evaluation of the rule set, set the is_static parameter of the CREATE_RULE_SET or UPDATE_RULE_SET procedures of the DVSYS.DBMS_MACADM PL/SQL package. See "Rule Set Procedures Within DVSYS.DBMS_MACADM" for more information.
Use Oracle Database Vault factors in your rule expressions to provide reusability and trust in the values used by your rule expressions. Factors can provide contextual information to use in your rules expressions.
You can use custom event handlers to extend Oracle Database Vault security policies to integrate external systems for error handling or alerting. Using Oracle utility packages such as UTL_TCP, UTL_HTTP, UTL_MAIL, UTL_SMTP, or DBMS_AQ can help you to achieve this type of integration.
Test rule sets thoroughly for various accounts and scenarios either on a test database or on a test realm or command rule for nonsensitive data before you apply them to realms and command rules that protect sensitive data. You can test rule expressions directly with the following SQL statement:
SQL> SELECT SYSDATE from DUAL where rule expression
You can nest rule expressions inside a single rule. This helps to achieve more complex situations where you would need a logical AND for a subset of rules and a logical OR with the rest of the rules. See the definition for the Is Corporate Network During Maintenance rule set under "Tutorial: Creating an Email Alert for Security Violations" for an example.
You cannot use invoker's rights procedures with rule expressions. Only use definer's rights procedures with rule expressions.
In general, the more rules and more complex the rules, the more performance overhead the performance for execution of certain operations governed by these rule sets. For example, if you have a very large number of rules in a rule set governing a SELECT statement, performance could degrade significantly.
If you have rule sets that require many rules, performance improves if you move all the rules to logic defined in a single PL/SQL standalone or package function. However, if a rule is used by other rule sets, there is little performance effect on your system.
If possible, consider setting the rule set to use static evaluation, assuming this is compatible with the associated command rule's usage. See "Guidelines for Designing Rule Sets" for more information.
You can check system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Database Control, which is installed by default with Oracle Database), Statspack, and TKPROF. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Database Control, refer to its online Help. Oracle Database Performance Tuning Guide describes the Statspack and TKPROF utilities.
Table 5-1 lists Oracle Database Vault reports that are useful for analyzing rule sets and the rules within them. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports.
Table 5-1 Reports Related to Rule Sets
| Report | Description |
|---|---|
|
"Rule Set Configuration Issues Report" |
Lists rule sets that have no rules defined or enabled |
|
"Secure Application Configuration Issues Report" |
Lists secure application roles that have incomplete or disabled rule sets |
|
"Command Rule Configuration Issues Report" |
Lists rule sets that are incomplete or disabled |
Table 5-2 lists data dictionary views that provide information about existing rules and rule sets.
|
See Also: Appendix D, "Oracle Database Vault Security Guidelines," for guidelines on managing security in the Oracle Database configuration |
When you install Oracle Database Vault, the installation process modifies several database initialization parameter settings to better secure your database configuration. If these changes adversely affect your organizational processes or database maintenance procedures, then contact Oracle Support for help in resolving the issue.
Table 2-1 describes the initialization parameter settings that Oracle Database Vault modifies. Initialization parameters are stored in the init.ora initialization parameter file, located in $ORACLE_HOME/srvm/admin. For more information about this file, see Oracle Database Administrator's Guide.
Table 2-1 Modified Database Initialization Parameter Settings
| Parameter | Default Value in Database | New Value Set by Database Vault | Impact of the Change |
|---|---|---|---|
|
|
|
Enables the auditing of top-level operations directly issued by user For more information about | |
|
Not configured. |
|
Disables the operating system to completely manage the granting and revoking of roles to users. Any previous grants of roles to users using For more information about | |
|
|
|
Controls whether the Flashback Drop feature is turned on or off. If See Also:
| |
|
|
|
Specifies whether Oracle Database checks for a password file. The For more information about | |
|
|
|
Ensures that users have been granted the For more information about |
During installation of Oracle Database Vault, the installer prompts for several additional database account names. In addition, several database roles are created. These accounts are part of the separation of duties provided by Oracle Database Vault. One common audit problem that has affected several large organizations is the unauthorized creation of new database accounts by a database administrator within a production instance. Upon installation, Oracle Database Vault prevents anyone other than the Oracle Database Vault account manager or a user granted the Oracle Database Vault account manager role from creating users in the database.
For guidelines on managing separation of duty, see "Separation of Duty Guidelines".
To meet regulatory, privacy and other compliance requirements, Oracle Database Vault implements the concept of separation of duty. Oracle Database Vault makes clear separation between the account management responsibility, data security responsibility, and database resource management responsibility inside the database. This means that the concept of a superprivileged user (for example, DBA) is divided among several new database roles to ensure no one user has full control over both the data and configuration of the system. Oracle Database Vault prevents the SYS user and other accounts with the DBA role and other system privileges from designated protected areas of the database called realms. It also introduces new database roles called the Oracle Database Vault Owner (DV_OWNER) and the Oracle Database Vault Account Manager (DV_ACCTMGR). These new database roles separate the data security and the account management from the traditional DBA role. You should map these roles to distinct security professionals within your organization.
|
See Also:
|
When you install Oracle Database Vault, it revokes a set of privileges from several Oracle Database-supplied roles, as part of the separation of duty enhancement.
Table 2-2 lists privileges that Oracle Database Vault revokes from existing users and roles. Be aware that if you disable Oracle Database Vault, these privileges remain revoked. If your applications depend on these privileges, then grant them to application owner directly.
Table 2-2 Privileges Oracle Database Vault Revokes
| User or Role | Privilege That Is Revoked |
|---|---|
| |
| |
| |
| |
|
Footnote 1 To authorize users to export and import data using Oracle Data Pump, see "Using Oracle Data Pump in an Oracle Database Vault Environment".
Footnote 2 To authorize users to schedule database jobs, see "Scheduling Database Jobs in an Oracle Database Vault Environment".
Table 2-3 lists privileges that Oracle Database Vault prevents. When Oracle Database Vault is enabled, users who have the Database Vault Account Manager role (DV_ACCTMGR) have the privileges listed in this table. If you disable Oracle Database Vault, users SYS and SYSTEM have these privileges.
Table 2-3 Privileges Oracle Database Vault Prevents
| User or Role | Privilege That Is Prevented |
|---|---|
|
|
|
|
|
|
Footnote 1 For better security and to maintain separation-of-duty standards, do not enable SYS or SYSTEM users the ability to create or manage user accounts.
This section contains:
In an Oracle Database Vault environment, when Oracle Label Security is enabled, the AUD$ table is moved from the SYS schema to the SYSTEM schema. The synonym SYS.AUD$ is created to refer to the SYSTEM.AUD$ table.
|
Tip: For greater security, create a realm around theSYSTEM.AUD$ and SYS.FGA_LOG$ tables. See Chapter 4, "Configuring Realms," for more information about realms. |
When you install Oracle Database Vault, it configures several AUDIT statement settings in the database. See "Oracle Database Audit Settings Created for Oracle Database Vault" for more information.
This section describes new features in Oracle Database Vault for this release of Oracle Database.
This section contains:
New Oracle Database Vault Features in Oracle Database 11g Release 2 (11.2.0.3)
Changed Oracle Database Vault Features in Oracle Database 11g Release 2 (11.2.0.2)
New Oracle Database Vault Features in Oracle Database 11g Release 2 (11.2.0.2)
New Oracle Database Vault Features in Oracle Database 11g Release 2 (11.2.0.1)
This section contains:
New Role to Support the XStream in an Oracle Database Vault Environment
New Roles to Support Oracle GoldenGate in an Oracle Database Vault Environment
Users who want to use XStream in an Oracle Database Vault environment must now be granted the DV_XSTREAM_ADMIN role.
See "DV_XSTREAM_ADMIN XStream Administrative Role" for more information.
Users who want to use Oracle GoldenGate in an Oracle Database Vault environment must be granted one of the following roles, depending on how they plan to use Oracle GoldenGate:
DV_GOLDENGATE_ADMIN role if they want to configure Oracle GoldenGate
DV_GOLDENGATE_REDO_ACCESS role if they want to use the GoldenGate TRANLOGOPTIONS DBLOGREADER method to access redo logs
See the following sections for more information:
Database Vault Configuration Assistant (DVCA) has been deprecated starting with this release. The functionality for DVCA to add languages to Database Vault has been replaced with the DVSYS.DBMS_MACADM.ADD_NLS_DATA procedure.
See "Adding Languages to Oracle Database Vault" for more information.
This section contains:
Starting with this release, the Oracle Data Pump EXP and IMP utilities cannot be used in an Oracle Database Vault environment.
See "Using Oracle Data Pump in an Oracle Database Vault Environment" for more information about using Oracle Data Pump with Oracle Database Vault.
This section contains:
Default settings for some of the values for the following DVSYS.DBMS_MACADM PL/SQL package procedures are now based on their previous settings:
DVSYS.DBMS_MACADM.UPDATE_REALM
DVSYS.DBMS_MACADM.UPDATE_REALM_AUTH
DVSYS.DBMS_MACADM.UPDATE_RULE_SET
DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE
DVSYS.DBMS_MACADM.UPDATE_FACTOR
DVSYS.DBMS_MACADM.UPDATE_ROLE
For example, suppose you created or updated a realm to have realm checking enabled. When you use the DVSYS.DBMS_MACADM.UPDATE_REALM procedure to modify the realm, the enabled parameter default is set to enable realm checking.
For more information, see Chapter 12, "Using the DVSYS.DBMS_MACADM Package."
This section contains:
You now can perform a set of Oracle Database Vault functions from both Oracle Database Enterprise Manager Database Control Release 11.2 and Grid Control Release 10.2.0.5. This integration also applies to Releases 9.2.0.8, 10.2.0.4, and 11.1.0.7 of Oracle Database Vault.
From Database Control, you now can perform the following tasks:
Monitor the Database Vault-enabled database
Access Oracle Database Vault reports
From Grid Control, you can perform these tasks:
Propagate Oracle Database Vault security policies across multiple database servers to help ensure consistent policies across the enterprise
Administer and monitor all Oracle Database Vault-protected servers from a single centralized management console
Automate alerts when unauthorized attempts are made to access Oracle Database Vault-protected databases
Access Oracle Database Vault reports
See the following sections for more information:
"Accessing the Oracle Database Vault Pages from Oracle Enterprise Manager"
"Using Oracle Database Vault with Oracle Enterprise Manager"
Oracle Data Pump users now can export and import data in an Oracle Database Vault environment.
See "Using Oracle Data Pump in an Oracle Database Vault Environment" for more information.
Users who are responsible for scheduling database jobs now can do so in an Oracle Database Vault environment.
See "Scheduling Database Jobs in an Oracle Database Vault Environment" for more information.
Oracle Database Vault includes the following new roles:
DV_MONITOR
DV_STREAMS_ADMIN
DV_PATCH_ADMIN
See the following sections for more information:
Oracle Database Vault now provides the following additional rule sets:
Allow Fine Grained Control of System Parameters
Allow Oracle Data Pump Operation
Allow Scheduler Job
See "Default Rule Sets" for more information.
You are no longer restricted to negative numbers when you specify a fail code for the creation of a rule set. You can enter a number the ranges of -20999 to -20000 or 20000 to 20999.
See "Error Handling Options" for more information.
The DBMS_MACADM and DBMS_MACSEC_ROLES PL/SQL packages have changed as follows:
The DBMS_MACADM.CREATE_RULE_SET and UPDATE_RULE_SET procedure have a new parameter, is_static. The is_static parameter determines how often a rule set is evaluated when a SQL statement accesses it. See "CREATE_RULE_SET Procedure" and "UPDATE_RULE_SET Procedure" for more information.
The DBMS_MACADM package has the following new procedures:
AUTHORIZE_DATAPUMP_USER authorizes an Oracle Database Pump user perform Oracle Data Pump operations when Oracle Database Vault is enabled. See "AUTHORIZE_DATAPUMP_USER Procedure" for more information.
UNAUTHORIZE_DATAPUMP_USER revokes the authorization that was granted by the AUTHORIZE_DATAPUMP_USER procedure. See "UNAUTHORIZE_DATAPUMP_USER Procedure" for more information.
AUTHORIZE_SCHEDULER_USER grants a user authorization to schedule database jobs when Oracle Database Vault is enabled. See "AUTHORIZE_SCHEDULER_USER Procedure" for more information.
UNAUTHORIZE_SCHEDULER_USER revokes the authorization that was granted by the AUTHORIZE_SCHEDULER_USER procedure. See "UNAUTHORIZE_SCHEDULER_USER Procedure" for more information.
The DBMS_MACSEC_ROLES.SET_ROLE procedure has been enhanced. You now can specify multiple roles with the p_role parameter. See "SET_ROLE Procedure" for more information.
Database Vault Configuration Assistant (DVCA) has the following changes:
Addition of the dbuniquename parameter. The dbuniquename parameter enables you to specify a globally unique name for an Oracle database. See "Adding Languages to Oracle Database Vault" for more information.
Removal of the optionrac parameter. The optionrac parameter was used for configuring Oracle Database Vault on Oracle Real Application Clusters (Oracle RAC) nodes. The new procedure for configuring Oracle Database Vault on Oracle RAC nodes is simpler. See "Configuring Oracle Database Vault on Oracle RAC Nodes" for more information.
You now can use Oracle Recovery Manager (RMAN) in an Oracle Database Vault environment.
See "Using Oracle Database Vault with Oracle Recovery Manager".
In previous releases of Oracle Database Vault, the SYS user was prevented from granting or revoking the EXECUTE privilege on the DBMS_RLS PL/SQL package to other users. Starting with this release, user SYS can resume granting and revoking EXECUTE on DBMS_RLS to other users.
To keep DVSYS as a protected schema, you can no longer drop its objects, even if the recycle bin is disabled. For better security for other realms, you should disable the recycle bin.
See "Security Considerations for the Recycle Bin".
Oracle Database Vault no longer modifies the OS_AUTHENT_PREFIX initialization parameter during installation. The default value for the OS_AUTHENT_PREFIX parameter is OPS$.
See Oracle Database Reference for more information about this parameter.
The NOSYSDBA parameter of the ORAPWD utility has been deprecated in this release. It is no longer necessary in Oracle Database Vault. As part of this deprecation, the lockout parameter of the DVCA utility has been deprecated as well.
Administrator's Guide
11g Release 2 (11.2)
E23090-05
March 2012
Oracle Database Vault Administrator's Guide 11g Release 2 (11.2)
E23090-05
Copyright © 2006, 2012, Oracle and/or its affiliates. All rights reserved.
Primary Author: Patricia Huey
Contributors: Priya Badnar, Tammy Bednar, Tom Best, Ji-won Byun, Ben Chang, Martin Cheng, Chi Ching Chui, Scott Gaetjen, Viksit Gaur, Lijie Heng, Sumit Jeloka, Dominique Jeunot, Terri Keller, Peter Knaggs, Chon Lee, Frank Lee, Paul Needham, Deborah Owens, Yi Ouyang, Hozefa Palitanawala, Robert Pang, Rupa Parameswaran, Gayathri Sairamkrishnan, Vipin Samar, Javed Samuel, James Spiller, Ashwini Supur, Srividya Tata, Kamal Tbeileh, Sudheesh Varma, Peter Wahl, Rodney Ward, Daniel Wong, Aravind Yalamanchi
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
This chapter contains:
This section describes how to start Oracle Database Vault Administrator. This section contains:
This section contains:
From Database Control, you can use the Oracle Database Vault pages to monitor a Database Vault-enabled database and view Database Vault reports.
However, you cannot create policies or perform other Database Vault Administrator-related actions from Database Control. If you want to perform these tasks, use Database Vault Administrator, described under "Starting Oracle Database Vault Administrator". If you want to propagate Database Vault policies to other Database Vault-enabled databases, see "Accessing Oracle Database Vault Pages from Grid Control".
To access the Oracle Database Vault pages from Database Control:
If necessary, register Oracle Database Vault.
If you have just installed Oracle Database Vault, you must register it with the database. See "Registering (Enabling) Oracle Database Vault" for more information.
Start Database Control.
For example:
https://myserver.example.com:1158/em
See Oracle Database 2 Day DBA for more information on logging in to Oracle Enterprise Manager.
Log in to Database Control with the following information:
Username: Enter the name of a user who has been granted the appropriate Oracle Database Vault role:
Creating and propagating Database Vault policies: DV_OWNER or DV_ADMIN
Viewing Database Vault alerts and reports: DV_OWNER, DV_ADMIN, or DV_SECANALYST
Creating and managing user accounts and roles: DV_ACCTMGR
The Oracle Database Vault roles do not need any additional privileges (such as SELECT ANY DICTIONARY) to use Database Control.
See "About Oracle Database Vault Roles" for more information about these roles.
Password: Enter your password.
Connect As: Select Normal from the list.
Save as Preferred Credential check box: Select this check box if you want these credentials to be automatically filled in for you the next time that this page appears
In the Home page, click Server to display the Server subpage.
Under Security, select Database Vault.
The Oracle Database Vault home page appears.
From Grid Control, you can use the Oracle Database Vault pages to propagate Database Vault policies to other Database Vault-protected databases, administer and monitor Database Vault-protected databases from a centralized console, automate alerts, and view Database Vault reports.
However, you cannot create policies or perform other Database Vault Administrator-related actions from Grid Control. If you want to perform these tasks, use Database Vault Administrator, described under "Starting Oracle Database Vault Administrator".
To access the Oracle Database Vault pages from Grid Control:
Ensure that you have configured the Grid Control target databases that you plan to use with Database Vault.
See the Oracle Enterprise Manager online help and Oracle Enterprise Manager Advanced Configuration for more information about configuring target databases.
If necessary, register Oracle Database Vault.
If you have just installed Oracle Database Vault, you must register it with the database. See "Registering (Enabling) Oracle Database Vault" for more information.
Start Grid Control.
For example:
https://myserver.example.com:1158/em
See Oracle Database 2 Day DBA for more information on logging in to Oracle Enterprise Manager.
Log in to Oracle Enterprise Manager as user SYSMAN and connect as Normal.
In the Oracle Enterprise Manager Database Home page (Database Home page), select the Targets subpage.
Select the Databases subpage.
In the Databases page, select the link for the Oracle Database Vault-protected database to which you want to connect.
The home page for the database instance appears.
In the Home page, click Server to display the Server subpage.
Under Security, select Database Vault.
The Database Login page appears.
Enter the following information:
Username: Enter the name of a user who has been granted the appropriate Oracle Database Vault role:
Creating and propagating Database Vault policies: DV_OWNER or DV_ADMIN
Viewing Database Vault alerts and reports: DV_OWNER, DV_ADMIN, or DV_SECANALYST
Creating and managing user accounts and roles: DV_ACCTMGR
The Oracle Database Vault roles do not need any additional privileges (such as SELECT ANY DICTIONARY) to use Grid Control.
See "About Oracle Database Vault Roles" for more information.
Password: Enter your password.
Connect As: Select Normal from the list.
Save as Preferred Credential check box: Select this check box if you want these credentials to be automatically filled in for you the next time that this page appears
Click the Login button.
The Database Vault home page appears.
If you are not using Oracle Enterprise Manager Database Control or Grid Control, or if you want to connect to Oracle Database Vault from a different computer, follow these steps to start Oracle Database Vault Administrator.
If necessary, register Oracle Database Vault.
If you have just installed Oracle Database Vault, you must register it with the database. See "Registering (Enabling) Oracle Database Vault" for more information.
From a browser, enter the following URL:
https://host_name:port/dva
In this specification:
host_name: The server where you installed Oracle Database Vault
port: The Oracle Enterprise Manager Console HTTPS port number
For example:
https://myserver:1158/dva
If you are unsure of the port number, open the $ORACLE_HOME/host_sid/sysman/config/emd.properties file and search for REPOSITORY_URL. In most cases, the host name and port number are the same as Oracle Enterprise Database Control.
If you cannot start Oracle Database Vault Administrator, check that the Oracle database console process is running.
UNIX: Go to the $ORACLE_HOME/bin directory and run the following command:
./emctl status dbconsole
If you must start the dbconsole process, then run the following command:
./emctl start dbconsole
Windows: In the Administrative Services, select the Services utility, and then right-click the OracleDBConsolesid service. If necessary, select Start from the menu to start the database console.
Log files for the database are in the following directory:
$ORACLE_HOME/sysman/log
Log in by using the Oracle Database Vault Owner account that you created during installation.
To log in, you must enter the full connect string. This enables you to manage multiple Oracle Database instances with Oracle Database Vault.
By default, you cannot log in to Oracle Database Vault Administrator by using the SYS, SYSTEM, or other administrative accounts. You can log in if you have the DV_ADMIN or DV_OWNER roles.
Enter the following values:
User Name: Enter the name of a user who has been granted the appropriate Oracle Database Vault role:
Creating and managing Database Vault policies: DV_OWNER or DV_ADMIN
Viewing Database Vault reports: DV_OWNER, DV_ADMIN, or DV_SECANALYST
Creating and managing user accounts and roles: DV_ACCTMGR
See "About Oracle Database Vault Roles" for more information.
Password: Enter your password.
Host: Enter the host name of the computer of the Oracle Database Vault installation you want. Use the following format:
server.domain
For example:
myserver-pc.us.example.com
Port: Enter the port number for Oracle Database. The default port number is 1521. If you are unsure of the port number, check the tnsnames.ora file.
For example:
1521
SID/Service: Select either SID or Service. You can find these values in the tnsnames.ora file. By default, this file is located in $ORACLE_HOME/network/admin.
SID: Enter the name of the Oracle Database instance. For example:
orcl
Service: Enter the service name of the database instance, in the following format:
service_name.domain
For example:
orcl.us.example.com
Figure 3-1 shows the Oracle Database Vault Administrator home page, which appears after you log in.
Figure 3-1 Oracle Database Vault Administrator Home Page
This section contains:
In this tutorial, you create a simple security configuration for the HR sample database schema. In the HR schema, the EMPLOYEES table has information such as salaries that should be hidden from most employees in the company, including those with administrative access. To accomplish this, you add the HR schema to the secured objects of the protection zone, which in Oracle Database Vault is called a realm, inside the database. Then you grant limited authorizations to this realm. Afterward, you test the realm to make sure it has been properly secured. And finally, to see how Oracle Database Vault provides an audit trail on suspicious activities like the one you will try when you test the realm, you will run a report.
Before you can use this tutorial, ensure that the HR sample schema is installed. See Oracle Database Sample Schemas for information on installing the sample schemas.
In this tutorial, the SYSTEM user grants the ANY privilege to a new user account, SEBASTIAN. To do this, you must include SYSTEM in the Oracle Data Dictionary realm.
To include SYSTEM in the Oracle Data Dictionary realm:
Log in to Oracle Database Vault Administrator as a user who has been granted the DV_OWNER or DV_ADMIN role.
"Starting Oracle Database Vault" explains how to log in.
In the Administration page, under Database Vault Feature Administration, click Realms.
In the Realms page, select Oracle Data Dictionary from the list and then click Edit.
In the Edit Realm: Oracle Data Dictionary page, under Realm Authorizations, click Create.
In the Create Realm Authorization Page, from the Grantee list, select SYSTEM [USER].
For Authorization Type, select Owner.
Leave Authorization Rule Set at <Non Selected>.
Click OK.
In the Edit Realm: Oracle Data Dictionary page, SYSTEM should be listed as an owner under the Realm Authorizations.
Click OK to return to the Realms page.
To return to the Administration page, click the Database Instance instance_name link over Realms.
Log in to SQL*Plus as user SYSTEM and access the HR schema.
sqlplus system
Enter password: password
SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM < 10;
Output similar to the following appears:
FIRST_NAME LAST_NAME SALARY -------------------- ------------------------- ---------- Donald OConnell 2600 Douglas Grant 2600 Jennifer Whalen 4400 Michael Hartstein 13000 Pat Fay 6000 Susan Mavris 6500 Hermann Baer 10000 Shelley Higgins 12000 William Gietz 8300 9 rows selected.
If the HR schema is locked and expired, log in to SQL*Plus as the DV_ACCTMGR user and unlock and unexpire the account. For example:
sqlplus amalcolm_dvacctmgr Enter password: password ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password
Replace password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
As you can see, SYSTEM has access to the salary information in the EMPLOYEES table of the HR schema. This is because SYSTEM is automatically granted the DBA role, which includes the SELECT ANY TABLE system privilege.
Realms can protect one or more schemas, individual schema objects, and database roles. Once you create a realm, you can create security restrictions that apply to the schemas and their schema objects within the realm. Your first step is to create a realm for the HR schema.
In the Realms page of Oracle Database Vault Administrator, click Create.
In the Create Realm page, under General, enter HR Realm after Name.
After Status, ensure that Enabled is selected so that the realm can be used.
Under Audit Options, ensure that Audit On Failure is selected so that you can create an audit trial later on.
Click OK.
The Realms Summary page appears, with HR Realm in the list of realms.
At this stage, you are ready to add the EMPLOYEES table in the HR schema to the secured objects of the HR realm.
In the Realms page, select HR Realm from the list and then click Edit.
In the Edit Realm: HR Realm page, scroll to Realm Secured Objects and then click Create.
In the Create Realm Secured Object page, enter the following settings:
Object Owner: Select HR from the list.
Object Type: Select TABLE from the list
Object Name: Enter EMPLOYEES.
Click OK.
In the Edit Realm: HR Realm page, click OK.
At this stage, there are no database accounts or roles authorized to access or otherwise manipulate the database objects the realm will protect. So, the next step is to authorize database accounts or database roles so that they can have access to the schemas within the realm. You will create the SEBASTIAN user account. After you authorize him for the realm, SEBASTIAN can view and modify the EMPLOYEES table.
In SQL*Plus, connect as the Database Vault Account Manager, who has the DV_ACCTMGR role, and create user SEBASTIAN.
For example:
CONNECT amalcolm_dvacctmgr Enter password: password CREATE USER SEBASTIAN IDENTIFIED BY password;
Replace password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
Connect as SYSTEM privilege, and then grant SEBASTIAN the following additional privileges.
CONNECT SYSTEM
Enter password: password
GRANT CREATE SESSION, SELECT ANY TABLE TO SEBASTIAN;
Do not exit SQL*Plus; you will need it for Step 6: Test the Realm, when you test the realm.
At this stage, even though SEBASTIAN has the SELECT ANY TABLE privilege, he cannot select from the HR.EMPLOYEES table because it is protected by a realm.
Next, authorize user SEBASTIAN to have access to the HR Realm as follows:
In the Realms page of Database Vault Administrator, select the HR Realm in the list of realms, and then click Edit.
In the Edit Realm: HR Realm page, scroll down to Realm Authorizations and then click Create.
In the Create Realm Authorization page, under Grantee, select SEBASTIAN[USER] from the list.
If SEBASTIAN does not appear in the list, select the Refresh button in your browser.
SEBASTIAN is the only user who has access to the EMPLOYEES table in the HR schema.
Under Authorization Type, select Participant.
The Participant authorization allows the user SEBASTIAN in the HR realm to manage access, manipulate, and create objects protected by the HR realm. In this case, the HR user and SEBASTIAN are the only users allowed to view the EMPLOYEES table.
Under Authorization Rule Set, select <Not Assigned>, because rule sets are not needed to govern this realm.
Click OK.
To test the realm, try accessing the EMPLOYEES table as a user other than HR. The SYSTEM account normally has access to all objects in the HR schema, but now that you have safeguarded the EMPLOYEES table with Oracle Database Vault, this is no longer the case.
In SQL*Plus, connect as SYSTEM, and then try accessing the salary information in the EMPLOYEES table again:
sqlplus system
Enter password: password
SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM <10;
The following output should appear:
Error at line 1: ORA-01031: insufficient privileges
SYSTEM no longer has access to the salary information in the EMPLOYEES table. However, user SEBASTIAN does have access to this information. Try the following:
CONNECT SEBASTIAN
Enter password: password
SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM <10;
Output similar to the following appears:
FIRST_NAME LAST_NAME SALARY -------------------- ------------------------- ---------- Donald OConnell 2600 Douglas Grant 2600 Jennifer Whalen 4400 Michael Hartstein 13000 Pat Fay 6000 Susan Mavris 6500 Hermann Baer 10000 Shelley Higgins 12000 William Gietz 8300 9 rows selected.
Because you enabled auditing on failure for the HR Realm, you can generate a report to find any security violations such as the one you attempted in Step 6: Test the Realm.
In the Oracle Database Vault Administrator home page, click Database Vault Reports.
Before you can run the report, you must log in using an account that has the DV_OWNER, DV_ADMIN, or DV_SECANALYST role. Note that user SEBASTIAN cannot run the report, even if it affects his own realm. "Oracle Database Vault Roles" describes these roles in detail. Currently, you should be logged in as the Database Vault Owner (DV_OWNER) account.
In the Database Vault Reports page, scroll down to Database Vault Auditing Reports and select Realm Audit.
Click Run Report.
Oracle Database Vault generates a report listing the type of violation (in this case, the SELECT statement entered in the previous section), when and where it occurred, the login account who tried the violation, and what the violation was.
Remove the SYSTEM account from the Data Dictionary Realm.
Ensure that you are logged on to Oracle Database Vault Administrator using a database account that has been granted the DV_OWNER role.
From the Administration page, select Realms.
From the list of realms, select Oracle Data Dictionary, and then click Edit.
Under Realm Authorizations, select SYSTEM.
Click Remove, and in the Confirmation window, click Yes.
Delete the HR Realm.
In the Realms page, select HR Realm from the list of realms.
Click Remove, and in the Confirmation window, click Yes.
Drop user SEBASTIAN.
In SQL*Plus, log on as the Oracle Database Vault account manager (for example, amalcolm_dvacctmgr) you created when you installed Oracle Database Vault, and then drop SEBASTIAN as follows:
sqlplus amalcolm_dvacctmgr
Enter password: password
DROP USER SEBASTIAN;
If necessary, lock and expire the HR account.
ALTER USER HR ACCOUNT LOCK PASSWORD EXPIRE;
This chapter contains:
Oracle Database Vault provides a set of procedural interfaces to administer various Database Vault security options and manage Database Vault security enforcements. There are also procedures and functions that expose the logic to validate a DDL command for realm violations and command authorizations. Additional procedures and functions are provided to set the value of a factor (assuming their associated rule sets evaluate to true) (for example, from a Web application), to retrieve the trust level for a session or specific factor identity, and to get the label for a factor identity. These procedures and functions are provided so that a database administrator does not grant the EXECUTE privilege on all DVSYS package procedures to the general database account population. The procedures and functions expose only the minimum methods that are required. All of these functions and procedures are publicly available for applications that need them.
Table 15-1 lists the default run-time PL/SQL procedures and functions.
Table 15-1 DVSYS Functions
| Procedure or Function | Parameter |
|---|---|
|
|
Sets a factor |
|
|
Retrieves a factor |
|
|
Retrieves the trust level assigned to a factor |
|
GET_TRUST_LEVEL_FOR_IDENTITY Function |
Retrieves the trust level for a specified factor and an identity |
|
|
Checks whether the specified database role is enabled |
|
|
Retrieves the label for the specified factor when the factor has a label assigned to it for the specified Oracle Label Security policy |
The SET_FACTOR procedure can be exposed to an application that requires the ability to set factor identities dynamically. It wraps the package procedure DVSYS.DBMS_MACADM.SET_FACTOR. When a factor has a rule set associated with it for assignment and if the rule set returns true, then the value is set. Normal rule set handling occurs, and the factor value (identity) validation method is called. This procedure is available (to execute) to the general database account population.
Syntax
DVSYS.SET_FACTOR( p_factor IN VARCHAR2, p_value IN VARCHAR2);
Parameters
Table 15-2 SET_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
|
|
Identity value, up to 1024 characters in mixed case. To find the identities for each factor in the current database instance, query the |
Example
EXECUTE DVSYS.SET_FACTOR(''Sector2_ClientID'', ''identity'');
The GET_FACTOR function is exposed to the DVF schema to allow the public factor functions to resolve the identity of a factor. This enables the F$ functions in the DVF schema. This function is available (to execute) to the general database account population.
Syntax
DVSYS.GET_FACTOR( p_factor IN VARCHAR2) RETURN VARCHAR2;
Parameter
Table 15-3 GET_FACTOR Parameter
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Get Client ID Factor Identity',
rule_expr => 'DVSYS.GET_FACTOR(''Sector2_ClientID'')');
END;
/
The GET_TRUST_LEVEL function returns the trust level of the current session identity for the factor requested. This function is available (to execute) to the general database account population. See "Creating and Configuring a Factor Identity" for a listing of the available trust levels.
Syntax
DVSYS.GET_TRUST_LEVEL( p_factor IN VARCHAR2) RETURN VARCHAR2;
Parameter
Table 15-4 GET_TRUST_LEVEL Parameter
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Get Client ID Trust Level',
rule_expr => 'DVSYS.GET_TRUST_LEVEL(''Sector2_ClientID'')');
END;
/
The GET_TRUST_LEVEL_FOR_IDENTITY function returns the trust level for the factor and identity requested. This function is available (to execute) to the general database account population. See "Creating and Configuring a Factor Identity" for a listing of the available trust levels.
Syntax
DVSYS.GET_TRUST_LEVEL_FOR_IDENTITY( p_factor IN VARCHAR2, p_identity IN VARCHAR2) RETURN VARCHAR2;
Parameters
Table 15-5 GET_TRUST_LEVEL_FOR_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
|
|
Identity value. To find the identities for each factor in the current database instance, use the |
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Get Client ID Identity Trust Level',
rule_expr => 'DVSYS.GET_TRUST_LEVEL_FOR_IDENTITY(''Sector2_ClientID'', ''identity'')');
END;
/
The ROLE_IS_ENABLED function returns a boolean value that specifies whether a database role has been enabled. This function is available (to execute) to the general database account population.
Syntax
DVSYS.ROLE_IS_ENABLED( p_role IN VARCHAR2) RETURN BOOLEAN;
Parameter
Table 15-6 ROLE_IS_ENABLED Parameter
| Parameter | Description |
|---|---|
|
|
Database role name to check. To find existing roles, use the following data dictionary views:
|
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check if SYSADM Role Is Enabled',
rule_expr => 'DVSYS.ROLE_IS_ENABLED(''SYSADM'')');
END;
/
The GET_FACTOR_LABEL function returns the label for the specified factor when the factor has a label assigned to it for the specified Oracle Label Security policy. The function returns a label that is merged with the maximum session label for the policy if the policy is configured with Oracle Label Security. The function is available (to execute) to the general database population. See "Label Identity" for more information about factor labels.
Syntax
DVSYS.GET_FACTOR_LABEL( p_factor IN VARCHAR2, p_policy_name IN VARCHAR2) RETURN VARCHAR2;
Parameters
Table 15-7 GET_FACTOR_LABEL Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find the available factors in the current database instance, query the See "DBA_DV_FACTOR View" and "DBA_DV_MAC_POLICY_FACTOR View". |
|
|
Oracle Label Security policy name. Use the following data dictionary views to find information about policies and factors in the current database instance:
|
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Get the ClientID Factor Label',
rule_expr => 'DVSYS.GET_FACTOR_LABEL(''Sector2_ClientID'', ''Access Locations'')');
END;
/
In addition to the functions and procedures made available from the DVSYS schema, the DVF schema contains a single function for each factor defined in the system. Oracle Database Vault maintains these functions when you use the DVSYS.DBMS_MACADM PL/SQL package to manage the various factors. The functions are then available to the general database account population through PL/SQL functions and standard SQL. This enables factors to be used in Oracle Label Security, Oracle Virtual Private Database (VPD), and so on.
Typically, you can incorporate these functions into rule expressions. For example:
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Not Internal DBA',
rule_expr => 'DVF.F$SESSION_USER NOT IN (''JSMTIH'', ''TBROWN'')');
END;
/
To find the value of a factor function, select from the DUAL system table. For example:
SELECT DVF.F$SESSION_USER FROM DUAL; F$SESSION_USER ------------------------------------------------ LBROWN_DVOWNER
The name of the factor itself is case-insensitive. For example, the following statements return the same result
select dvf.f$session_user from dual; SELECT DVF.F$SESSION_USER FROM DUAL;
Table 15-8 lists the default factor functions.
Table 15-8 Installed Oracle Database Vault Factor Functions
| DVF Factor Function | Description |
|---|---|
|
F$AUTHENTICATION_METHOD Function |
Returns the method of authentication in |
|
|
Returns the IP address of the computer from which the client is connected |
|
|
Returns the domain of the database as specified in the |
|
|
Returns the host name of the computer on which the database instance is running |
|
|
Returns the database instance identification number of the current database instance |
|
|
Returns the IP address of the computer on which the database instance is running |
|
|
Returns the name of the database as specified in the |
|
|
Returns a named collection of physical, configuration, or implementation-specific factors in the run-time environment (for example, a networked IT environment or subset of it) that operates at a specific sensitivity level |
|
F$ENTERPRISE_IDENTITY Function |
Returns the enterprise-wide identity for a user |
|
F$IDENTIFICATION_TYPE Function |
Returns the way the schema of a user was created in the database. Specifically, it reflects the |
|
|
Returns the ISO abbreviation for the language name, a shorter form than the existing |
|
|
Returns the language and territory currently used by your session, in |
|
|
Returns the computer (host) name for the database client that established the database session. |
|
|
Returns the network protocol being used for communication, as specified in the |
|
F$PROXY_ENTERPRISE_IDENTITY Function |
Returns the Oracle Internet Directory distinguished name (DN) when the proxy user is an enterprise user |
|
|
Returns the database user name by which the current user is authenticated |
The F$AUTHENTICATION_METHOD function returns the method of authentication in VARCHAR2 data type. In the list that follows, the type of user is followed by the method returned:
Password-authenticated enterprise user, local database user, or SYSDBA/SYSOPER using Password File; proxy with user name using password: PASSWORD
Kerberos-authenticated enterprise or external user: KERBEROS
SSL-authenticated enterprise or external user: SSL
Radius-authenticated external user: RADIUS
Operating system-authenticated external user or SYSDBA/SYSOPER: OS
DCE-authenticated external user: DCE
Proxy with certificate, distinguished name (DN), or user name without using password: NONE
You can use IDENTIFICATION_TYPE to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL.
Syntax
DVF.F$AUTHENTICATION_METHOD () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check SSL Authentication Method', rule_expr => 'DVF.F$AUTHENTICATION_METHOD = ''SSL'''); END; /
The F$CLIENT_IP function returns the IP address of the computer from which the client is connected, in VARCHAR2 data type.
Syntax
DVF.F$CLIENT_IP () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Client IP Address', rule_expr => 'DVF.F$CLIENT_IP BETWEEN ''192.0.2.10'' AND ''192.0.2.20'''); END; /
The F$DATABASE_DOMAIN function returns the domain of the database as specified in the DB_DOMAIN initialization parameter, in sVARCHAR2 data type.
Syntax
DVF.F$DATABASE_DOMAIN () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check Client Database Domain',
rule_expr => 'DVF.F$DATABASE_DOMAIN NOT IN (''EXAMPLE'', ''YOURDOMAIN'')');
END;
/
The F$DATABASE_HOSTNAME function returns the host name of the computer on which the instance is running, in VARCHAR2 data type.
Syntax
DVF.F$DATABASE_HOSTNAME () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check Host Name',
rule_expr => 'DVF.F$DATABASE_HOSTNAME IN (''SHOBEEN'', ''MAU'')');
END;
/
The F$DATABASE_INSTANCE function returns the instance identification number of the current database instance, in VARCHAR2 data type.
Syntax
DVF.F$DATABASE_INSTANCE () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Database Instance ID', rule_expr => 'DVF.F$DATABASE_INSTANCE = ''SALES_DB'''); END; /
The F$DATABASE_IP function returns the IP address of the computer on which the database instance is running, in VARCHAR2 data type.
Syntax
DVF.F$DATABASE_IP () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Database IP address', rule_expr => 'DVF.F$DATABASE_IP = ''192.0.2.5'''); END; /
The F$DATABASE_NAME function returns the name of the database as specified in the DB_NAME initialization parameter, in VARCHAR2 data type.
Syntax
DVF.F$DATABASE_NAME () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Database DB_NAME Name', rule_expr => 'DVF.F$DATABASE_NAME = ''ORCL'''); END; /
The F$DOMAIN function returns a named collection of physical, configuration, or implementation-specific factors in the run-time environment (for example, a networked IT environment or subset of it) that operates at a specific sensitivity level. The return type is VARCHAR2.
You can identify a domain using factors such as host name, IP address, and database instance names of the Oracle Database Vault nodes in a secure access path to the database. Each domain can be uniquely determined using a combination of the factor identifiers that identify the domain. You can use these identifying factors and possibly additional factors to define the Maximum Security Label within the domain. This restricts data access and commands, depending on the physical factors about the Oracle Database Vault session. Example domains of interest may be Corporate Sensitive, Internal Public, Partners, and Customers.
Syntax
DVF.F$DOMAIN () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Domain', rule_expr => 'DVF.F$DOMAIN = ''EXAMPLE.COM'''); END; /
The F$ENTERPRISE_IDENTITY function returns the enterprise-wide identity for a user, in VARCHAR2 data type:
For enterprise users: the Oracle Internet Directory DN.
For external users: the external identity (Kerberos principal name, Radius and DCE schema names, operating system user name, certificate DN).
For local users and SYSDBA/SYSOPER logins: NULL.
The value of the attribute differs by proxy method:
For a proxy with DN: the Oracle Internet Directory DN of the client.
For a proxy with certificate: the certificate DN of the client for external users; the Oracle Internet Directory DN for global users.
For a proxy with user name: the Oracle Internet Directory DN if the client is an enterprise user; NULL if the client is a local database user.
Syntax
DVF.F$ENTERPRISE_IDENTITY () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check User Enterprise Identity',
rule_expr => 'DVF.F$ENTERPRISE_IDENTITY NOT IN (''JSMITH'', ''TSMITH'')');
END;
/
The F$IDENTIFICATION_TYPE function returns the way the schema of a user was created in the database. Specifically, it reflects the IDENTIFIED clause in the CREATE/ALTER USER syntax. The return type is VARCHAR2. In the list that follows, the syntax used during schema creation is followed by the identification type returned:
IDENTIFIED BY password: LOCAL
IDENTIFIED EXTERNALLY: EXTERNAL
IDENTIFIED GLOBALLY: GLOBAL SHARED
IDENTIFIED GLOBALLY AS DN: GLOBAL PRIVATE
Syntax
DVF.F$IDENTIFICATION_TYPE () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check User Schema Creation Type', rule_expr => 'DVF.F$IDENTIFICATION_TYPE = ''GLOBAL SHARED'''); END; /
The F$LANG function returns the ISO abbreviation for the language name, a shorter form than the existing LANGUAGE parameter, for the session of the user. The return type is VARCHAR2.
See Oracle Database Globalization Support Guide for a listing of supported languages for Oracle Database.
Syntax
DVF.F$LANG () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check ISO Abbreviated Language Name',
rule_expr => 'DVF.F$LANG IN (''EN'', ''DE'', ''FR'')');
END;
/
The F$LANGUAGE function returns the language and territory currently used by a user session, in VARCHAR2 data type, along with the database character set, in the following form:
language_territory.characterset
See Oracle Database Globalization Support Guide for a listing of supported languages and territories for Oracle Database.
Syntax
DVF.F$LANGUAGE () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Session Language and Territory', rule_expr => 'DVF.F$LANGUAGE = ''AMERICAN_AMERICA.WE8ISO8859P1'''); END; /
The F$MACHINE function returns the computer (host) name for the database client that established the database session. The return type is VARCHAR2.
Syntax
DVF.F$MACHINE () RETURN VARCHAR2;
Parameter
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check Client Computer Host Name',
rule_expr => 'DVF.F$MACHINE NOT IN (''SHOBEEN'', ''SEBASTIAN'')');
END;
/
The F$NETWORK_PROTOCOL function returns the network protocol being used for communication, as specified in the PROTOCOL=protocol portion of the connect string. The return type is VARCHAR2.
Syntax
DVF.F$NETWORK_PROTOCOL () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Network Protocol', rule_expr => 'DVF.F$NETWORK_PROTOCOL = ''TCP'''); END; /
The F$PROXY_ENTERPRISE_IDENTITY function returns the Oracle Internet Directory distinguished name (DN) when the proxy user is an enterprise user. The return type is VARCHAR2.
Syntax
DVF.F$PROXY_ENTERPRISE_IDENTITY () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Get OID DN of Enterprise User', rule_expr => 'DVF.F$PROXY_ENTERPRISE_IDENTITY = ''cn=Provisioning Admins'''); END; /
The F$SESSION_USER function returns the database user name by which the current user is authenticated. This value remains the same throughout the session. The return type is VARCHAR2.
Syntax
DVF.F$SESSION_USER () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check Database User Name',
rule_expr => 'DVF.F$SESSION_USER IN (''JSMITH'', ''TSMITH'')');
END;
/
Oracle Database Vault provides a set of functions that you can use in rule sets to inspect the SQL statement that you want the rule set to protect. For example, if a rule set protects SELECT ON HR.EMPLOYEES under a command rule, then you could use these functions to make more informed decisions in the rule expression.
Table 15-9 lists the default rule functions.
Table 15-9 Installed Oracle Database Vault PL/SQL Rule Set Functions
| Rule Set Function | Description |
|---|---|
|
|
Returns the system event firing the rule set |
|
|
Returns the login user name |
|
|
Returns the database instance number |
|
|
Returns the database name |
|
|
Returns the type of the dictionary object on which the database operation occurred (for example, table, procedure, view) |
|
|
Returns the owner of the dictionary object on which the database operation occurred |
|
|
Returns the name of the dictionary object on which the database operation occurred |
|
|
Returns the first 4000 characters of SQL text of the database statement used in the operation |
The DV_SYSEVENT function returns the system event firing the rule set, in VARCHAR2 data type. The event name is the same as that in the syntax of the SQL statement (for example, INSERT, CREATE.)
Syntax
DVSYS.DV_SYSEVENT () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Get System Event Firing the Maintenance Rule Set', rule_expr => 'DVSYS.DV_SYSEVENT = ''CREATE'''); END; /
The DV_LOGIN_USER function returns the login user name, in VARCHAR2 data type.
Syntax
DVSYS.DV_LOGIN_USER () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check System Login User Name', rule_expr => 'DVSYS.DV_LOGIN_USER = ''SEBASTIAN'''); END; /
The DV_INSTANCE_NUM function returns the database instance number, in NUMBER data type.
Syntax
DVSYS.DV_INSTANCE_NUM () RETURN NUMBER;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Database Instance Number', rule_expr => 'DVSYS.DV_INSTANCE_NUM BETWEEN 6 AND 9'); END; /
The DV_DATABASE_NAME function returns the database name, in VARCHAR2 data type.
Syntax
DVSYS.DV_DATABASE_NAME () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Database Name', rule_expr => 'DVSYS.DV_DATABASE_NAME = ''ORCL'''); END; /
The DV_DICT_OBJ_TYPE function returns the type of the dictionary object on which the database operation occurred (for example, table, procedure, or view). The return type is VARCHAR2.
Syntax
DVSYS.DV_DICT_OBJ_TYPE () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check Dictionary Object Type',
rule_expr => 'DVSYS.DV_DICT_OBJ_TYPE IN (''TABLE'', ''VIEW'')');
END;
/
The DV_DICT_OBJ_OWNER function returns the name of the owner of the dictionary object on which the database operation occurred. The return type is VARCHAR2.
Syntax
DVSYS.DV_DICT_OBJ_OWNER () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Dictionary Object Owner', rule_expr => 'DVSYS.DV_DICT_OBJ_OWNER = ''JSMITH'''); END; /
The DV_DICT_OBJ_NAME function returns the name of the dictionary object on which the database operation occurred. The return type is VARCHAR2.
Syntax
DVSYS.DV_DICT_OBJ_NAME () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check Dictionary Object Name', rule_expr => 'DVSYS.DV_DICT_OBJ_NAME = ''SALES'''); END; /
The DV_SQL_TEXT function returns the first 4000 characters of SQL text of the database statement used in the operation The return type is VARCHAR2.
Syntax
DVSYS.DV_SQL_TEXT () RETURN VARCHAR2;
Parameters
None.
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE( rule_name => 'Check SQL Text', rule_expr => 'DVSYS.DV_SQL_TEXT = ''SELECT SALARY FROM HR.EMPLOYEES'''); END; /
Oracle Database Vault provides a collection of PL/SQL package APIs to support the maintenance and run-time behavior of Oracle Database Vault. Table 15-10 lists these packages. Chapter 12, "Using the DVSYS.DBMS_MACADM Package," describes these packages in detail.
Table 15-10 Oracle Database Vault Administrator and Run-Time PL/SQL Packages
| Package | Description |
|---|---|
|
|
Provides for the administration of all aspects of the secure and access control configuration data. The realm owner of the Oracle Database Vault realm can grant the ability to run this package. See Chapter 12, "Using the DVSYS.DBMS_MACADM Package," for more information. |
|
|
Provides the The API also provides a method to issue the See Chapter 13, "Using the DVSYS.DBMS_MACSEC_ROLES Package," for more information. |
|
|
Defines several constants and utility methods that are commonly used by other Oracle Database Vault packages, such as code/message lookup, error handling, data conversion, and privilege checks. This package can be run by the general database account population. This allows for security developers to leverage the constants in scripted configuration files. Utility methods such as See Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for more information. |
|
Note: There are several procedures in theDVSYS.DBMS_MACADM package that are not exposed in the Oracle Database Vault Administration Web application. The procedures that are not exposed include:
|
Oracle Database Vault Administrator's Guide explains how to configure access control-based security in an Oracle Database environment by using Oracle Database Vault.
This preface contains the following topics:
This document is intended for security managers, audit managers, label administrators, and Oracle database administrators (DBAs) who are involved in the configuration of Oracle Database Vault.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
For more information refer to the following documents:
Oracle Documentation Search Engine
To access the database documentation search engine directly, visit:
Oracle Technology Network (OTN)
You can download free release notes, installation documentation, updated versions of this guide, white papers, or other collateral from the Oracle Technology Network (OTN). Visit
http://www.oracle.com/technetwork/index.html
For security-specific information on OTN, visit
http://www.oracle.com/technetwork/topics/security/whatsnew/index.html
For the latest version of the Oracle documentation, including this guide, visit
http://www.oracle.com/technetwork/documentation/index.html
Oracle Database Vault-Specific Sites
For OTN information specific to Oracle Database Vault, visit
http://www.oracle.com/technetwork/database/options/database-vault/index-085211.html
For frequently asked questions about Oracle Database Vault, visit
http://www.oracle.com/technetwork/database/security/dbv-faq-083210.html
Oracle Store
Printed documentation is available for sale in the Oracle Store at:
My Oracle Support (formerly OracleMetaLink)
You can find information about security patches, certifications, and the support knowledge base by visiting My Oracle Support at:
The following text conventions are used in this document:
| Convention | Meaning |
|---|---|
| boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. |
| italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
After you install Oracle Database, you must register (that is, enable) Oracle Database Vault. Oracle Database includes Database Vault by default, but you must register it before you can use it. As part of the registration process, you create the Database Vault administrative accounts. The registration process also creates the Database Vault DVSYS and DVF schemas. This procedure applies to both single-instance and Oracle RAC installations. To check if Database Vault has already been enabled, see "Checking if Oracle Database Vault Is Enabled or Disabled".
Ensure that the computer on which you want to register Oracle Database Vault has the Oracle Enterprise Manager Database Console available.
You can check the status of the Database Console by running the emctl status dbconsole command. For example:
./emctl status dbconsole
Stop the database, Database Control console process, and listener.
UNIX: Log in to SQL*Plus as user SYS with the SYSOPER privilege and shut down the database. Then from the command line, stop the Database Console process and listener.
For example:
sqlplus sys as sysoper Enter password: password SQL> SHUTDOWN IMMEDIATE SQL> EXIT $ emctl stop dbconsole $ lsnrctl stop [listener_name]
For Oracle RAC installations, shut down each database instance as follows:
$ srvctl stop database -d db_name
Windows: Stop the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Oracle.
Enable Oracle Database Vault as follows:
UNIX: Run the following commands. The make command enables both Oracle Database Vault (dv_on) and Oracle Label Security (lbac_on). You must enable Oracle Label Security before you can use Database Vault.
$ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk dv_on lbac_on ioracle
Windows: In the ORACLE_BASE\ORACLE_HOME\bin directory, rename the oradvll.dll.dbl file to oradvll.dll. Ensure that the name of the Oracle Label Security executable is oralbacll.dll (and not oralbacll.dll.dbl or some other backup name). You must enable Oracle Label Security before you can use Database Vault.
Restart the database and listener. (Do not restart the Database Control console process yet.)
UNIX: Log in to SQL*Plus as user SYS with the SYSOPER privilege and restart the database. Then from the command line, restart the listener.
For example:
sqlplus sys as sysoper Enter password: password SQL> STARTUP SQL> EXIT $ lsnrctl start [listener_name]
For Oracle RAC installations, restart each database instance as follows:
$ srvctl start database -d db_name
Windows: Restart the database and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Oracle.
Start Database Configuration Assistant.
UNIX: Enter the following command at a terminal window:
dbca
By default, dbca is in the $ORACLE_HOME/bin directory.
Windows: From the Start menu, click All Programs. Then, click Oracle - ORACLE_HOME, Configuration and Migration Tools, and then Database Configuration Assistant.
Alternatively, you can start Database Configuration Assistant at a command prompt:
dbca
As with UNIX, typically, dbca is in the ORACLE_BASE\ORACLE_HOME\bin directory.
In the Welcome page, click Next.
The Operations page appears.
Select Configure Database Options, and then click Next.
The Database page appears.
From the list, select the database where you installed Oracle Database and then click Next.
The Database Content page appears.
Perform one of the following actions:
If Oracle Label Security is already enabled: Select the Oracle Database Vault option, and then click Next.
If Oracle Label Security is not enabled: Select the Oracle Label Security option so that the Oracle Database Vault option becomes available for selection. Select the Oracle Database Vault option as well, and then click Next.
The Oracle Database Vault Credentials page appears.
Specify the name and password for the Database Vault Owner account (for example, DBVOWNER) and the Database Vault Account Manager (for example, DBVACCTMGR).
Enter any password that is secure, according to the password guidelines described in Oracle Database Security Guide. Oracle Database Vault has additional password requirements, which are displayed if you try to create an incorrect password.
Click Next.
The Connection Mode page appears.
Select either Dedicated Server Mode or Shared Server Mode (depending on the selection you made when you created this database), click Finish, and then click OK in the confirmation prompts.
Database Configuration Assistant registers Oracle Database Vault, and then restarts the database instance.
Exit Database Configuration Assistant.
Restart the Database Control console process.
UNIX: Run the following command:
$ emctl start dbconsole
Windows: Restart the Database Control console process (for example, OracleDBConsoleorcl if the name of the database is orcl) from the Services tool in the Control Panel.
After you have registered Oracle Database Vault with an Oracle database, you can start Oracle Database Vault Administrator. See "Starting Oracle Database Vault" for more information.
Ensure that the value of the NLS_LANGUAGE initialization parameter matches the locale and NLS settings (either the NLS_LANG or LANG environment variables) used by the operating system of the computer on which Oracle Database is installed. If these values are inconsistent, then Database Vault Administrator does not display the default realms, command rules, rule sets, or factors.
For example, if the operating system locale (the variable $LANG) setting is en_US.UTF-8, then you must set the corresponding NLS_LANG environment variable to AMERICAN_AMERICA.AL32UTF8 and the database NLS_LANGUAGE initialization parameter value to be AMERICAN. The database NLS_LANGUAGE parameter is derived from the operating system NLS_LANG environment variable.
For more information about checking and configuring locale and NLS settings, see the appendix that covers globalization support in the Oracle Database Installation Guide for your platform.
If you have created an Oracle database manually, and have configured Oracle Enterprise Manager Database Control by using Enterprise Manager Configuration Assistant, you must manually deploy Oracle Database Vault Administrator. This procedure deploys Database Vault Administrator in the same OC4J container as the current Enterprise Manager, rather than creating a new application.
This section contains:
Deploying Database Vault Administrator to a Standalone OC4J Container
Deploying Database Vault Administrator to the Database Console OC4J Container
You can manually deploy Database Vault Administrator to the Oracle Application Server Containers for J2EE (OC4J) home, which by default is in the $ORACLE_HOME/oc4j/j2ee/home directory.
To manually deploy Database Vault Administrator:
Edit the file $ORACLE_HOME/oc4j/j2ee/home/config/server.xml. Enter the following line just before the last line that reads, </application-server>:
<application name="dva" path="Oracle_home_dir/dv/jlib/dva_webapp.ear" auto-start="true" />
Replace Oracle_home_dir with the relative or direct path to the Oracle home directory. (You cannot enter the $ORACLE_HOME environment variable.)
For example:
<application name="dva" path="/u00/app/oracle/oracle/product/dv12/dv/jlib/dva_webapp.ear" auto-start="true" />
Edit the file $ORACLE_HOME/oc4j/j2ee/home/config/http-web-site.xml. Enter the following line just above the last line that reads, </web-site>:
<web-app application="dva" name="dva_webapp" root="/dva" />
Edit the file $ORACLE_HOME/oc4j/j2ee/home/config/global-web-application.xml. Search for <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>. Uncomment the following lines after this:
<init-param> <param-name>main_mode</param-name> <param-value>justrun</param-value> </init-param>
Create the following directory:
mkdir -p $ORACLE_HOME/dv/jlib/sysman/config
Create the database connection configuration file, emoms.properties, in the configuration directory that you just created. Add the following lines to the file:
oracle.sysman.emSDK.svlt.ConsoleMode=standalone oracle.sysman.eml.mntr.emdRepRAC=FALSE oracle.sysman.eml.mntr.emdRepDBName=oracle_sid oracle.system.eml.mntr.emdRepConnectDescriptor=TNS_connection_string
Follow these instructions:
For an Oracle RAC environment, set oracle.sysman.eml.mntr.emdRepRAC to TRUE.
For oracle.sysman.eml.mntr.emdRepConnectDescriptor, you can use an alias from $ORACLE_HOME/network/admin/tnsnames.ora. Alternatively, you can use the following syntax:
oracle.sysman.eml.mntr.emdRepConnectDescriptor=
(DESCRIPTION\=
(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP) (HOST\=HOSTNAME)(PORT\=PORT)))
(CONNECT_DATA\=
(SERVICE_NAME\=ORACLE_SID))
Ensure that the correct environment variables are set.
For example:
ORACLE_SID=orcl export ORACLE_SID ORACLE_HOME=/u00/app/oracle/product/11.2/dv export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/jdbc/lib export LD_LIBRARY_PATH PATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:$PATH export PATH
Set the LD_LIBRARY_PATH variable to use the OCI-based JDBC libraries.
Start OC4J using the following syntax:
$ORACLE_HOME/jdk/bin/java -Djava.awt.headless=true -DEMDROOT=$ORACLE_HOME/dv/jlib -jar $ORACLE_HOME/oc4j/j2ee/home/oc4j.jar -userThreads -config $ORACLE_HOME/oc4j/j2ee/home/config/server.xml
After you complete these steps, you can start Database Vault Administrator. The HTTP port defaults to 8888 for this environment. Use the following syntax for the URL:
http://hostname:8888/dva
To manually deploy Database Vault Administrator to the Database Console OC4J container:
Stop Oracle Database Console.
UNIX: Go to the $ORACLE_HOME/bin directory and run the following command:
./emctl stop dbconsole
Windows: In the Administrative Services, select the Services utility, and then right-click the OracleDBConsolesid service. Select Stop from the menu.
Create a backup copy and then open the $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_service_name/config/server.xml file.
Add the following line before the </application-server> element:
<application name="dva" path="$ORACLE_HOME/dv/jlib/dva_webapp.ear" parent="default" start="true" />
On Windows systems, replace $ORACLE_HOME with the absolute path to your Oracle Database home.
Create a backup copy and then open the $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_service_name/config/http-web-site.xml file.
Add the following line before the </web-site> element:
<web-app application="dva" name="dva_webapp" load-on-startup="true" root="/dva" shared="true"/>
Restart Oracle Database Console.
UNIX: Go to the $ORACLE_HOME/bin directory and run the following command:
./emctl start dbconsole
Windows: In the Administrative Services, select the Services utility, and then right-click the OracleDBConsolesid service. Select Start from the menu.
After you complete these steps, you can start Oracle Database Vault Administrator by using the following URL:
https://hostname:port/dva
For example:
https://myserver:1158/dva
If you are unsure of the port number, open the ORACLE_HOME/host_sid/sysman/config/emd.properties file and search for REPOSITORY_URL. In most cases, the host name and port number are the same as Oracle Enterprise Manager Database Control.
By default, an Oracle Database Vault session lasts 35 minutes. If you want the session to last for a different time, follow the steps in this section.
To set the session time for Oracle Database Vault Administrator:
Back up the web.xml file, which by default is in the $ORACLE_HOME/dv/jlib/dva_webapp/dva_webapp/WEB-INF directory.
In a text editor, open the web.xml file.
Search for the following setting:
<session-config> <session-timeout>35</session-timeout> </session-config>
Change the <session-timeout> setting to the amount of time in minutes that you prefer.
Save and close the web.xml file.
Stop and restart the Database Vault Administrator.
UNIX: Go to the $ORACLE_HOME/bin directory and run the following command:
./emctl stop dbconsole ./emctl start dbconsole
Windows: In the Administrative Services, select the Services utility, and then right-click the OracleDBConsolesid service. Select Stop from the menu. After the console stops, select Start.
You can configure Database Vault Administrator to make data accessible and usable to the disabled community. The following sections explain how to enable Database Vault Administrator for full accessibility.
Enabling Oracle Database Vault Administrator Accessibility Mode
Providing Textual Descriptions of Database Vault Administrator Charts
Oracle Database Vault Administrator takes advantage of user interface development technologies that improve the responsiveness of some user operations. For example, when you navigate to a new record set in a table, Oracle Database Vault Administrator does not redisplay the entire HTML page. However, this performance-improving technology is generally not supported by screen readers. To disable this feature, and as a result, make the Database Vault Administrator HTML pages more accessible for disabled users, use the following procedure.
To enable the display of an entire HTML page:
Locate the uix-config.xml configuration file.
By default, the uix-config.xml file is in the following directory:
$ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/WEB-INF
Open the uix-config.xml file using a text editor and locate the following entry:
<!-- An alternate configuration that disables accessibility features --> <default-configuration> <accessibility-mode>inaccessible</accessibility-mode> ... </default-configuration>
Change the value of the accessibility-mode property from inaccessible to accessible.
Save and close the uix-config.xml file.
Restart Database Vault Administrator.
The Monitor page of Database Vault Administrator displays security policy data in a chart. However, charts do not convey information in a manner that can be read by a screen reader. To remedy this problem, you can configure Database Vault Administrator to provide a complete textual representation of each chart. By default, support for the textual representation of charts is disabled. When textual description for charts is enabled, Database Vault Administrator displays a textual representation of the chart data.
To enable the textual representation of charts:
Locate the web.xml configuration file.
To locate the web.xml file in a Oracle Database 10g installation, change directory to the following location in the Oracle home:
$ORACLE_HOME/dv/jlib/dva_webapp/dva_webapp/WEB-INF/
Open the web.xml file with your favorite text editor and locate the following six lines of the file:
<!-- Uncomment this to enable textual chart descriptions <context-param> <param-name>enableChartDescription</param-name> <param-value>true</param-value> </context-param> -->
Remove comments from this section by deleting the first line and the last line of this section so that the section consists of only these four lines:
<context-param> <param-name>enableChartDescription</param-name> <param-value>true</param-value> </context-param>
Save and exit the web.xml file.
Restart Database Vault Administrator.
After you install Oracle Database Vault for an Oracle Real Application Clusters (Oracle RAC) instance, complete the following procedure for each Oracle RAC node. This procedure assumes that you have a separate Oracle home for each node.
Log in to SQL*Plus as user SYS with the SYSDBA privilege.
sqlplus sys as sysdba
Enter password: password
Run the following ALTER SYSTEM statements:
ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE; ALTER SYSTEM SET OS_ROLES=FALSE SCOPE=SPFILE; ALTER SYSTEM SET RECYCLEBIN='OFF' SCOPE=SPFILE; ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' SCOPE=SPFILE; ALTER SYSTEM SET SQL92_SECURITY=TRUE SCOPE=SPFILE;
Restart Oracle Database.
CONNECT SYS/AS SYSOPER
Enter password: password
SHUTDOWN IMMEDIATE
STARTUP
By default, Oracle Database Vault loads only the English language tables. You can add more languages by running the DVSYS.DBMS_MACADM.ADD_NLS_DATA procedure for each new language that you want to add. You can add more than one language to Database Vault.
To add a new language to Oracle Database Vault:
Log into SQL*Plus as a user who has been granted the DV_OWNER or DV_ADMIN role.
Run the following procedure:
EXEC DVSYS.DBMS_MACADM.ADD_NLS_DATA('language');
You can specify the language setting using any case. For example:
EXEC DVSYS.DBMS_MACADM.ADD_NLS_DATA('french');
EXEC DVSYS.DBMS_MACADM.ADD_NLS_DATA('JAPANESE');
Replace language with one of the following supported languages:
The following procedure removes Oracle Database Vault from an Oracle Database installation. It applies to both single-instance and Oracle RAC installations. The deinstallation process does not affect the initialization parameter settings, even those settings that were modified during the installation process.
To deinstall Oracle Database Vault:
Stop the database, Database Control console process, and listener.
For example:
sqlplus sys as sysoper Enter password: password Connected. SQL> SHUTDOWN IMMEDIATE SQL> EXIT $ emctl stop dbconsole $ lsnrctl stop [listener_name]
For Oracle RAC installations, shut down each database instance as follows:
$ srvctl stop database -d db_name
On Windows, you can stop the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Oracle.
Run the following commands to turn off Oracle Database Vault and Oracle Label Security:
$ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk dv_off lbac_off ioracle
Log in to SQL*Plus and then restart the database, Database Control console process, and listener.
For example:
SQL> STARTUP
SQL> EXIT
$ emctl stop dbconsole
$ lsnrctl start [listener_name]
For each instance in an Oracle RAC installation:
$ srvctl start database -d db_name
On Windows, you can restart the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Oracle.
In SQL*Plus, log in as user SYS with the SYSDBA privilege.
Disable the recycle bin.
To check if the recycle bin is enabled, enter the following command:
SQL> SHOW PARAMETER RECYCLEBIN
If the recycle bin is enabled, then disable it as follows:
SQL> ALTER SYSTEM SET RECYCLEBIN = OFF SCOPE=SPFILE; SQL> SHUTDOWN IMMEDIATE SQL> STARTUP
Disabling the recycle bin does not purge or otherwise affect objects that are already in the recycle bin. For better security, keep the recycle bin disabled. See "Security Considerations for the Recycle Bin".
Run the following SQL script:
SQL> @$ORACLE_HOME/rdbms/admin/dvremov.sql
Manually drop the DV_OWNER and DV_ACCTMGR user accounts and the DV_REALM_RESOURCE and DV_REALM_OWNER roles.
SQL> DROP DBV_OWNER CASCADE; SQL> DROP DBV_ACCTMGR CASCADE; SQL> DROP DV_REALM_RESOURCE; SQL> DROP DV_REALM_OWNER;
Enable Oracle Label Security.
$ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk lbac_on ioracle
Afterward, you can double-check that Oracle Dadtabase Vault is truly deinstalled by logging in to SQL*Plus and entering the following statement:
SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';
If Oracle Database Vault is deinstalled, the following output appears:
PARAMETER VALUE ----------------------------- ----------------------- Oracle Database Vault FALSE
To reinstall Oracle Database Vault, follow the procedure under "Registering (Enabling) Oracle Database Vault".
This chapter contains:
Oracle Label Security Policy Procedures Within DVSYS.DBMS_MACADM
General System Maintenance Procedures Within DVSYS.DBMS_MACADM
The procedures and functions within the DVSYS.DBMS_MACADM package allow you to write applications that configure the realms, factors, rule sets, command rules, secure application roles, and Oracle Label Security policies normally configured in Oracle Database Vault Administrator.
The DVSYS.DBMS_MACADM package is available only for users who have been granted the DV_ADMIN or DV_OWNER role.
Many of the parameters used in the procedures and functions in the DVSYS.DBMS_MACADM package can use the constants available in the DVSYS.DBMS_MACUTL package. See "DVSYS.DBMS_MACUTL Constants" for more information.
Oracle Database Vault also provides a set of PL/SQL interfaces that you can use with the DVSYS.DBMS_MACADM package. See Chapter 15, "Using the Oracle Database Vault PL/SQL Interfaces," for more information.
Table 12-1 lists procedures within the DVSYS.DBMS_MACADM package that you can use to configure realms. For constants that you can use with these procedures, see Table 14-1 for more information.
Chapter 4, "Configuring Realms," describes realms in detail. See also Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for a set of general purpose utility procedures that you can use with the realm procedures.
Table 12-1 DVSYS.DBMS_MACADM Realm Configuration Procedures
| Procedure | Description |
|---|---|
|
|
Authorizes a user or role to access a realm as an owner or a participant |
|
| |
|
|
Creates a realm |
|
DELETE_AUTH_FROM_REALM Procedure |
Removes the authorization of a user or role to access a realm |
|
DELETE_OBJECT_FROM_REALM Procedure |
Removes a set of objects from realm protection |
|
|
Deletes a realm and its related Database Vault configuration information |
|
DELETE_REALM_CASCADE Procedure |
Deletes a realm its related Database Vault configuration information |
|
|
Renames a realm. The name change takes effect everywhere the realm is used. |
|
| |
|
|
Updates the authorization of a user or role to access a realm |
The ADD_AUTH_TO_REALM procedure authorizes a user or role to access a realm as an owner or a participant. For detailed information about realm authorization, see "Defining Realm Authorization".
Optionally, you can specify a rule set that must be checked before allowing the authorization to proceed.
Syntax
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name IN VARCHAR2, grantee IN VARCHAR2, rule_set_name IN VARCHAR2, auth_options IN NUMBER);
Parameters
Table 12-2 ADD_AUTH_TO_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
User or role name to authorize as an owner or a participant. To find the existing users and roles in the current database instance, query the To find the authorization of a particular user or role, query the To find existing secure application roles used in privilege management, query the |
|
|
Optional. Rule set to check before authorizing. If the rule set evaluates to To find the available rule sets, query the |
|
|
Optional. Specify one of the following options to authorize the realm:
You can also use the following
See "Defining Realm Authorization" for more information on participants and owners. |
Examples
The following example authorizes user SYSADM as a participant in the Performance Statistics Realm.
BEGIN DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Performance Statistics Realm', grantee => 'SYSADM'); END; /
This example sets user SYSADM as the owner of the Performance Statistics Realm.
BEGIN DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Performance Statistics Realm', grantee => 'SYSADM', auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER); END; /
The next example triggers the Check Conf Access rule set before allowing user SYSADM to be made the owner of the Performance Statistics Realm.
BEGIN DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Performance Statistics Realm', grantee => 'SYSADM', rule_set_name => 'Check Conf Access', auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER); END; /
The ADD_OBJECT_TO_REALM procedure registers a set of objects for realm protection.
Syntax
DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM( realm_name IN VARCHAR2, object_owner IN VARCHAR2, object_name IN VARCHAR2, object_type IN VARCHAR2);
Parameters
Table 12-3 ADD_OBJECT_TO_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
The owner of the object that is being added to the realm. If you add a role to a realm, the object owner of the role is shown as To find the available users, query the To find the authorization of a particular user or role, query the |
|
|
Object name. (The wildcard % is allowed. See "Object Name" under "Creating Realm-Secured Objects" for exceptions to the wildcard %.) You can also use the To find the available objects, query the To find objects that are secured by existing realms, query the |
|
|
Object type, such as You can also use the |
Example
BEGIN DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM( realm_name => 'Performance Statistics Realm', object_owner => '%', object_name => 'GATHER_SYSTEM_STATISTICS', object_type => 'ROLE'); END; /
The CREATE_REALM procedure creates a realm. After you create the realm, use the following procedures to complete the realm definition:
ADD_OBJECT_TO_REALM procedure registers one or more objects for the realm.
ADD_AUTH_TO_REALM procedures authorize users or roles for the realm.
Syntax
DVSYS.DBMS_MACADM.CREATE_REALM( realm_name IN VARCHAR2, description IN VARCHAR2, enabled IN VARCHAR2, audit_options IN NUMBER);
Parameters
Table 12-4 CREATE_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name, up to 90 characters in mixed-case. To find the existing realms in the current database instance, query the |
|
|
Description of the purpose of the realm, up to 1024 characters in mixed-case. |
|
|
You can also use the following
|
|
|
Specify one of the following options to audit the realm:
You can also use the following
|
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_REALM( realm_name => 'Performance Statistics Realm', description => 'Realm to measure performance', enabled => DBMS_MACUTL.G_YES, audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL + DBMS_MACUTL.G_REALM_AUDIT_SUCCESS); END; /
The DELETE_AUTH_FROM_REALM procedure removes the authorization of a user or role to access a realm.
Syntax
DVSYS.DBMS_MACADM.DELETE_AUTH_FROM_REALM( realm_name IN VARCHAR2, grantee IN VARCHAR2);
Parameters
Table 12-5 DELETE_AUTH_FROM_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
User or role name. To find the authorization of a particular user or role, query the |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_AUTH_FROM_REALM( realm_name => 'Performance Statistics Realm', grantee => 'SYS'); END; /
The DELETE_OBJECT_FROM_REALM procedure removes a set of objects from realm protection.
Syntax
DVSYS.DBMS_MACADM.DELETE_OBJECT_FROM_REALM( realm_name IN VARCHAR2, object_owner IN VARCHAR2, object_name IN VARCHAR2, object_type IN VARCHAR2);
Parameters
Table 12-6 DELETE_OBJECT_FROM_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
The owner of the object that was added to the realm. To find the available users, query the |
|
|
Object name. (The wildcard % is allowed. See "Object Name" under "Creating Realm-Secured Objects" for exceptions to the wildcard %.) You can also use the To find objects that are secured by existing realms, query the |
|
|
Object type, such as You can also use the |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_OBJECT_FROM_REALM( realm_name => 'Performance Statistics Realm', object_owner => 'SYS', object_name => 'GATHER_SYSTEM_STATISTICS', object_type => 'ROLE'); END; /
The DELETE_REALM procedure deletes a realm, including its related Database Vault configuration information that specifies who is authorized (DVSYS.DBA_DV_REALM_AUTH view) and what objects are protected (DVSYS.DBA_DV_REALM_OBJECT view). It does not delete the actual database objects or users. To find a listing of the realm-related objects, query the DVSYS.DBA_DV_REALM view. To find its authorizations, query DVSYS.DBA_DV_REALM_AUTH. Both are described under "Oracle Database Vault Data Dictionary Views".
If you want to remove the associated objects and authorizations and the realm, see "DELETE_REALM_CASCADE Procedure".
Syntax
DVSYS.DBMS_MACADM.DELETE_REALM( realm_name IN VARCHAR2);
Parameters
Table 12-7 DELETE_REALM Parameter
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_REALM('Performance Statistics Realm');
The DELETE_REALM_CASCADE procedure deletes a realm, including its related Database Vault configuration information that specifies who is authorized (DVSYS.DBA_DV_REALM_AUTH view) and what objects are protected (DVSYS.DBA_DV_REALM_OBJECT view). It does not delete the actual database objects or users. To find a listing of the realm-related objects, query the DVSYS.DBA_DV_REALM view. To find its authorizations, query DVSYS.DBA_DV_REALM_AUTH. Both are described under "Oracle Database Vault Data Dictionary Views".
Syntax
DVSYS.DBMS_MACADM.DELETE_REALM_CASCADE( realm_name IN VARCHAR2);
Parameters
Table 12-8 D ELETE_REALM_CASCADE Parameter
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_REALM_CASCADE('Performance Statistics Realm');
The RENAME_REALM procedure renames a realm. The name change takes effect everywhere the realm is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_REALM( realm_name IN VARCHAR2, new_name IN VARCHAR2);
Parameters
Table 12-9 RENAME_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Current realm name. To find the existing realms in the current database instance, query the |
|
|
New realm name, up to 90 characters in mixed-case. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_REALM( realm_name => 'Performance Statistics Realm', new_name => 'Sector 2 Performance Statistics Realm'); END; /
The UPDATE_REALM procedure updates a realm.
Syntax
DVSYS.DBMS_MACADM.UPDATE_REALM( realm_name IN VARCHAR2, description IN VARCHAR2, enabled IN VARCHAR2, audit_options IN NUMBER DEFAULT NULL);
Parameters
Table 12-10 UPDATE_REALM Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
Description of the purpose of the realm, up to 1024 characters in mixed-case. |
|
|
You can also use the following
The default for |
|
|
Specify one of the following options to audit the realm:
You can also use the following
The default for |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_REALM( realm_name => 'Sector 2 Performance Statistics Realm', description => 'Realm to measure performance for Sector 2 applications', enabled => 'Y', audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL + G_REALM_AUDIT_SUCCESS); END; /
The UPDATE_REALM_AUTH procedure updates the authorization of a user or role to access a realm.
Syntax
DVSYS.DBMS_MACADM.UPDATE_REALM_AUTH( realm_name IN VARCHAR2, grantee IN VARCHAR2, rule_set_name IN VARCHAR2, auth_options IN NUMBER);
Parameters
Table 12-11 UPDATE_REALM_AUTH Parameters
| Parameter | Description |
|---|---|
|
|
Realm name. To find the existing realms in the current database instance, query the |
|
|
User or role name. To find the available users and roles, query the To find the authorization of a particular user or role, query the To find existing secure application roles used in privilege management, query the |
|
|
Optional Rule set to check before authorizing. If the rule set evaluates to To find the available rule sets, query the |
|
|
Optional. Specify one of the following options to authorize the realm:
You can also use the following
The default for |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_REALM_AUTH( realm_name => 'Sector 2 Performance Statistics Realm', grantee => 'SYSADM', rule_set_name => 'Check Conf Access', auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER); END; /
Table 12-12 lists procedures within the DVSYS.DBMS_MACADM package that you can use to configure rule sets.
|
See Also:
|
Table 12-12 DVSYS.DBMS_MACADM Rule Set Configuration Procedures
| Procedure | Description |
|---|---|
|
ADD_RULE_TO_RULE_SET Procedure |
Adds a rule to a rule set |
|
|
Creates a rule |
|
|
Creates a rule set |
|
|
Deletes a rule |
|
DELETE_RULE_FROM_RULE_SET Procedure |
Deletes a rule from a rule set |
|
|
Deletes a rule set |
|
|
Renames a rule. The name change takes effect everywhere the rule is used. |
|
|
Renames a rule set. The name change takes effect everywhere the rule set is used. |
|
|
Synchronizes the rules |
|
|
Updates a rule |
|
|
Updates a rule set |
The ADD_RULE_TO_RULE_SET procedure adds rule to a rule set, and lets you specify whether to have the rule be checked when the rule set is evaluated.
Syntax
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET( rule_set_name IN VARCHAR2, rule_name IN VARCHAR2, rule_order IN NUMBER, enabled IN VARCHAR2);
Parameters
Table 12-13 ADD_RULE_TO_RULE_SET Parameters
| Parameter | Description |
|---|---|
|
|
Rule set name. To find existing rule sets in the current database instance, query the |
|
|
Rule to add to the rule set. To find existing rules, query the To find rules that have been associated with rule sets, use |
|
|
Does not apply to this release, but you must include a value for the |
|
|
Optional. Determines whether the rule should be checked when the rule set is evaluated. Possible values are:
You can also enter the following
See Table 14-1 for more information. |
Examples
The following example adds a rule to a rule set, and by omitting the enabled parameter, automatically enables the rule to be checked when the rule set is evaluated.
BEGIN DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET( rule_set_name => 'Limit_DBA_Access', rule_name => 'Restrict DROP TABLE operations', rule_order => 1); END; /
This example adds the rule to the rule set but disables rule checking.
BEGIN DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET( rule_set_name => 'Limit_DBA_Access', rule_name => 'Check UPDATE operations', rule_order => 1, enabled => DBMS_MACUTL.G_NO); END; /
The CREATE_RULE procedure creates a rule. After you create a rule, you can add it to a rule set.
Syntax
DVSYS.DBMS_MACADM.CREATE_RULE( rule_name IN VARCHAR2, rule_expr IN VARCHAR2);
Parameters
Table 12-14 CREATE_RULE Parameters
| Parameter | Description |
|---|---|
|
|
Rule name, up to 90 characters in mixed-case. Spaces are allowed. To find existing rules in the current database instance, query the To find rules that have been associated with rule sets, query |
|
|
PL/SQL If the expression contains quotation marks, do not use double quotation marks. Instead, use two single quotation marks. Enclose the entire expression within single quotation marks. For example: 'TO_CHAR(SYSDATE,''HH24'') = ''12''' See "Creating a New Rule" for more information on rule expressions. |
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Check UPDATE operations',
rule_expr =>'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''SYSADM''');
END;
/
The CREATE_RULE_SET procedure creates a rule set. After you create a rule set, you can use the CREATE_RULE and ADD_RULE_TO_RULE_SET procedures to create and add rules to the rule set.
Syntax
DVSYS.DBMS_MACADM.CREATE_RULE_SET( rule_set_name IN VARCHAR2, description IN VARCHAR2, enabled IN VARCHAR2, eval_options IN NUMBER, audit_options IN NUMBER, fail_options IN NUMBER, fail_message IN VARCHAR2, fail_code IN NUMBER, handler_options IN NUMBER, handler IN VARCHAR2, is_static IN BOOLEAN DEFAULT FALSE);
Parameters
Table 12-15 CREATE_RULE_SET Parameters
| Parameter | Description |
|---|---|
|
|
Rule set name, up to 90 characters in mixed-case. Spaces are allowed. To find existing rule sets in the current database instance, query the |
|
|
Description of the purpose of the rule set, up to 1024 characters in mixed-case. |
|
|
You can also use the following
|
|
|
If you plan to assign multiple rules to the rule set, enter one of the following settings:
You can also use the following
|
|
|
Select one of the following settings:
You can also use the following
See "Audit Options" for more information. |
|
|
Options for reporting factor errors:
You can also use the following
See "Error Handling Options" for more information. |
|
|
Enter an error message for failure, up to 80 characters in mixed-case, to associate with the fail code you specify for |
|
|
Enter a number in the range of -20000 to -20999 or 20000 to 20999 to associate with the |
|
|
Select one of the following settings:
You can also use the following
See "Error Handling Options" for more information. |
|
|
Name of the PL/SQL function or procedure that defines the custom event handler logic. See "Error Handling Options" for more information. |
|
|
Optional. Determines how often a rule set is evaluated when it is accessed. The default is
|
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_RULE_SET( rule_set_name => 'Limit_DBA_Access', description => 'DBA access through predefined processes', enabled => 'Y', eval_options => 2, audit_options => DBMS_MACUTL.G_RULESET_AUDIT_FAIL + DBMS_MACUTL.G_RULESET_AUDIT_SUCCESS, fail_options => 2, fail_message => '', fail_code => 20461, handler_options => DBMS_MACUTL.G_RULESET_HANDLER_FAIL, handler => 'dbavowner.email_alert', is_static => TRUE); END; /
The DELETE_RULE procedure deletes a rule.
Syntax
DVSYS.DBMS_MACADM.DELETE_RULE( rule_name IN VARCHAR2);
Parameter
Table 12-16 DELETE_RULE Parameter
| Parameter | Description |
|---|---|
|
|
Rule name. To find existing rules in the current database instance, query the To find rules that have been associated with rule sets, query |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check UPDATE operations');
The DELETE_RULE_FROM_RULE_SET procedure deletes a rule from a rule set.
Syntax
DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET( rule_set_name IN VARCHAR2, rule_name IN VARCHAR2);
Parameters
Table 12-17 DELETE_RULE_FROM_RULE_SET Parameters
| Parameter | Description |
|---|---|
|
|
Rule set name. To find existing rule sets in the current database instance, query the |
|
|
Rule to remove from the rule set. To find existing rules in the current database instance, query the To find rules that have been associated with rule sets, query |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET( rule_set_name => 'Limit_DBA_Access', rule_name => 'Check UPDATE operations'); END; /
The DELETE_RULE_SET procedure deletes a rule set.
Syntax
DVSYS.DBMS_MACADM.DELETE_RULE_SET( rule_set_name IN VARCHAR2);
Parameters
Table 12-18 DELETE_RULE_SET Parameter
| Parameter | Description |
|---|---|
|
|
Rule set name. To find existing rule sets in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('Limit_DBA_Access');
The RENAME_RULE procedure renames a rule. The name change takes effect everywhere the rule is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_RULE( rule_name IN VARCHAR2, new_name IN VARCHAR2);
Parameters
Table 12-19 RENAME_RULE Parameters
| Parameter | Description |
|---|---|
|
|
Current rule name. To find existing rules in the current database instance, query the To find rules that have been associated with rule sets, query |
|
|
New rule name, up to 90 characters in mixed-case. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_RULE( rule_name => 'Check UPDATE operations', new_name => 'Check Sector 2 Processes'); END; /
The RENAME_RULE_SET procedure renames a rule set. The name change takes effect everywhere the rule set is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_RULE_SET( rule_set_name IN VARCHAR2, new_name IN VARCHAR2);
Parameters
Table 12-20 RENAME_RULE_SET Parameters
| Parameter | Description |
|---|---|
|
|
Current rule set name. To find existing rule sets in the current database instance, query the |
|
|
New rule set name, up to 90 characters in mixed-case. Spaces are allowed. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_RULE_SET( rule_set_name => 'Limit_DBA_Access', new_name => 'Limit Sector 2 Access'); END; /
The SYNC_RULES procedure synchronizes the rules in Oracle Database Vault and Advanced Queuing Rules engine. You must perform this operation immediately after you roll back an ADD_RULE_TO_RULESET, a DELETE_RULE, or an UPDATE_RULE operation.
Syntax
DVSYS.DBMS_MACADM.SYNC_RULES();
Parameters
None.
Example
EXEC DVSYS.DBMS_MACADM.SYNC_RULES();
The UPDATE_RULE procedure updates a rule.
Syntax
DVSYS.DBMS_MACADM.UPDATE_RULE( rule_name IN VARCHAR2, rule_expr IN VARCHAR2);
Parameters
Table 12-21 UPDATE_RULE Parameters
| Parameter | Description |
|---|---|
|
|
Rule name. To find existing rules in the current database instance, query the To find rules that have been associated with rule sets, query |
|
|
PL/SQL If the expression contains quotation marks, do not use double quotation marks. Instead, use two single quotation marks. Enclose the entire expression within single quotation marks. For example: 'TO_CHAR(SYSDATE,''HH24'') = ''12''' See "Creating a New Rule" for more information on rule expressions. To find existing rule expressions, query the |
Example
BEGIN
DVSYS.DBMS_MACADM.UPDATE_RULE(
rule_name => 'Check UPDATE operations',
rule_expr =>'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''SYSADM'' AND
(
UPPER(SYS_CONTEXT(''USERENV'',''MODULE'')) LIKE ''APPSRVR%'' OR
UPPER(SYS_CONTEXT(''USERENV'',''MODULE'')) LIKE ''DBAPP%'' )'
);
END;
/
The UPDATE_RULE_SET procedure updates a rule set.
Syntax
DVSYS.DBMS_MACADM.UPDATE_RULE_SET( rule_set_name IN VARCHAR2, description IN VARCHAR2, enabled IN VARCHAR2, eval_options IN NUMBER, audit_options IN NUMBER, fail_options IN NUMBER, fail_message IN VARCHAR2, fail_code IN NUMBER, handler_options IN NUMBER, handler IN VARCHAR2, is_static IN BOOLEAN DEFAULT FALSE);
Parameters
Table 12-22 UPDATE_RULE_SET Parameters
| Parameter | Description |
|---|---|
|
|
Rule set name. To find existing rule sets in the current database instance, query the |
|
|
Description of the purpose of the rule set, up to 1024 characters in mixed-case. |
|
|
You can also use the following
The default for the |
|
|
If you plan to assign multiple rules to the rule set, enter one of the following settings:
You can also use the following
The default for |
|
|
Select one of the following settings:
You can also use the following
The default for See "Audit Options" for more information. |
|
|
Options for reporting factor errors:
You can also use the following
The default for See "Error Handling Options" for more information. |
|
|
Error message for failure, up to 80 characters in mixed-case, to associate with the fail code you specify for |
|
|
Enter a number in the range of -20000 to -20999 or 20000 to 20999 to associate with the |
|
|
Select one of the following settings:
You can also use the following
The default for See "Error Handling Options" for more information. |
|
|
Name of the PL/SQL function or procedure that defines the custom event handler logic. See "Error Handling Options" for more information. |
|
|
Optional. Determines how often a rule set is evaluated when it is accessed by a SQL statement.
|
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_RULE_SET( rule_set_name => 'Limit_DBA_Access', description => 'DBA access through predefined processes', enabled => 'Y', eval_options => 2, audit_options => DBMS_MACUTL.G_RULESET_AUDIT_FAIL, fail_options => DBMS_MACUTL.G_RULESET_FAIL_SHOW, fail_message => 'Access denied!', fail_code => 20900, handler_options => DBMS_MACUTL.G_RULESET_HANDLER_OFF, handler => '', is_static = TRUE); END; /
Table 12-23 lists procedures within the DVSYS.DBMS_MACADM package that you can use to configure command rules.
Chapter 6, "Configuring Command Rules," describes command rules in detail. See also Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for a set of general-purpose utility procedures that you can use with the command rule procedures.
Table 12-23 DVSYS.DBMS_MACADM Command Rule Configuration Procedures
| Procedure | Description |
|---|---|
|
|
Creates a command rule, associates it with a rule set, and lets you enable the command rule for rule checking with a rule set |
|
|
Drops a command rule declaration |
|
|
Updates a command rule declaration |
The CREATE_COMMAND_RULE procedure creates a command rule, associates it with a rule set, and lets you enable the command rule for rule checking with a rule set.
Syntax
DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE( command IN VARCHAR2, rule_set_name IN VARCHAR2, object_owner IN VARCHAR2, object_name IN VARCHAR2, enabled IN VARCHAR2);
Parameters
Table 12-24 CREATE_COMMAND_RULE Parameters
| Parameter | Description |
|---|---|
|
|
SQL statement to protect. See also the following:
|
|
|
Name of rule set to associate with this command rule. To find existing rule sets in the current database instance, query the |
|
|
Database schema to which this command rule will apply. The wildcard To find the available users, query the See also "Object Owner" in "Creating and Editing a Command Rule" for more information. |
|
|
Object name. (The wildcard % is allowed. See "Object Name" in "Creating and Editing a Command Rule" for more information about objects protected by command rules.) To find the available objects, query the |
|
|
You can also use the following
|
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE( command => 'SELECT', rule_set_name => 'Limit Sector 2 Access', object_owner => 'SYSADM', object_name => 'EMP_DATA', enabled => DBMS_MACUTL.G_YES); END; /
The DELETE_COMMAND_RULE procedure drops a command rule declaration.
Syntax
DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE( command IN VARCHAR2, object_owner IN VARCHAR2, object_name IN VARCHAR2);
Parameters
Table 12-25 DELETE_COMMAND_RULE Parameters
| Parameter | Description |
|---|---|
|
|
SQL statement the command rule protects. To find available command rules, query the |
|
|
Database schema to which this command rule applies. To find the available users in the current database instance, query the See also "Object Owner" in "Creating and Editing a Command Rule" for more information. |
|
|
Object name. (The wildcard % is allowed. See "Object Name" in "Creating and Editing a Command Rule" for more information about objects protected by command rules.) To find the available objects, query the |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE( command => 'SELECT', object_owner => 'SYSADM', object_name => 'EMP_DATA'); END; /
The UPDATE_COMMAND_RULE procedure updates a command rule declaration.
Syntax
DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE( command IN VARCHAR2, rule_set_name IN VARCHAR2, object_owner IN VARCHAR2, object_name IN VARCHAR2, enabled IN VARCHAR2);
Parameters
Table 12-26 UPDATE_COMMAND_RULE Parameters
| Parameter | Description |
|---|---|
|
|
SQL statement to protect. See also the following:
|
|
|
Name of rule set to associate with this command rule. To find existing rule sets in the current database instance, query the |
|
|
Database schema to which this command rule applies. To find the available users, query the |
|
|
Object name. (The wildcard % is allowed. See "Object Name" in "Creating and Editing a Command Rule" for more information about objects protected by command rules.) To find the available objects, query the |
|
|
You can also use the following
The default for |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE( command => 'SELECT', rule_set_name => 'Limit Sector 2 Access', object_owner => 'SYSADM', object_name => '%', enabled => DBMS_MACUTL.G_NO); END; /
Table 12-27 lists procedures and functions within the DVSYS.DBMS_MACADM package that you can use to configure factors.
|
See Also:
|
Table 12-27 DVSYS.DBMS_MACADM Factor Configuration Procedures
| Procedure | Description |
|---|---|
|
|
Specifies a parent-child relationship for two factors |
|
|
Specifies that the label for a factor contributes to the Oracle Label Security label for a policy. |
|
CHANGE_IDENTITY_FACTOR Procedure |
Associates an identity with a different factor |
|
CHANGE_IDENTITY_VALUE Procedure |
Updates the value of an identity |
|
CREATE_DOMAIN_IDENTITY Procedure |
Adds an Oracle Real Application Clusters (Oracle RAC) database node to the domain factor identities and labels it according to the Oracle Label Security policy. |
|
|
Creates a factor |
|
|
Creates a factor type |
|
|
Creates an identity |
|
|
Defines a set of tests that are used to derive the identity of a factor from the value of linked child factors (subfactors) |
|
|
Deletes a factor |
|
|
Removes a parent-child relationship for two factors |
|
|
Deletes a factor type |
|
|
Removes an identity |
|
|
Removes an identity map from a factor |
|
DROP_DOMAIN_IDENTITY Procedure |
Removes an Oracle RAC database node from a domain |
|
|
Returns information from the |
|
|
Returns information from the |
|
|
Renames a factor. The name change takes effect everywhere the factor is used. |
|
|
Renames a factor type. The name change takes effect everywhere the factor type is used. |
|
|
Updates a factor |
|
|
Updates the description of a factor type |
|
|
Updates the trust level of a factor identity |
The ADD_FACTOR_LINK procedure specifies a parent-child relationship for two factors.
Syntax
DVSYS.DBMS_MACADM.ADD_FACTOR_LINK( parent_factor_name IN VARCHAR2, child_factor_name IN VARCHAR2, label_indicator IN VARCHAR2);
Parameters
Table 12-28 ADD_FACTOR_LINK Parameters
| Parameter | Description |
|---|---|
|
|
Parent factor name. To find existing parent and child factors in the current database instance, query the |
|
|
Child factor name. |
|
|
Indicates that the child factor being linked to the parent factor contributes to the label of the parent factor in an Oracle Label Security integration. Specify either You can also use the following
To find the Oracle Label Security policies and labels associated with factors, query the following views, described in "Oracle Database Vault Data Dictionary Views":
|
Example
BEGIN DVSYS.DBMS_MACADM.ADD_FACTOR_LINK( parent_factor_name => 'HQ_ClientID', child_factor_name => 'Div1_ClientID', label_indicator => 'Y'); END; /
The ADD_POLICY_FACTOR procedure specifies that the label for a factor contributes to the Oracle Label Security label for a policy.
Syntax
DVSYS.DBMS_MACADM.ADD_POLICY_FACTOR( policy_name IN VARCHAR2, factor_name IN VARCHAR2);
Parameters
Table 12-29 ADD_POLICY_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Oracle Label Security policy name. To find the policies defined in the current database instance, query the To find factors that are associated with Oracle Label Security policies, query |
|
|
Factor name. To find existing factors, query the |
Example
BEGIN DVSYS.DBMS_MACADM.ADD_POLICY_FACTOR( policy_name => 'AccessData', factor_name => 'Sector2_ClientID'); END; /
The CHANGE_IDENTITY_FACTOR procedure associates an identity with a different factor.
Syntax
DVSYS.DBMS_MACADM.CHANGE_IDENTITY_FACTOR( factor_name IN VARCHAR2, value IN VARCHAR2, new_factor_name IN VARCHAR2);
Parameters
Table 12-30 CHANGE_IDENTITY_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Current factor name. To find existing factors, query the |
|
|
Value of the identity to update. To find existing identities for each factor in the current database instance, query the To find current identity mappings, query the |
|
|
Name of the factor to associate with the identity, which you can find by querying the |
Example
BEGIN DVSYS.DBMS_MACADM.CHANGE_IDENTITY_FACTOR( factor_name => 'Sector2_ClientID', value => 'intranet', new_factor_name => 'Sector4_ClientID'); END; /
The CHANGE_IDENTITY_FACTOR procedure updates the value of an identity.
Syntax
DVSYS.DBMS_MACADM.CHANGE_IDENTITY_VALUE( factor_name IN VARCHAR2, value IN VARCHAR2, new_value IN VARCHAR2);
Parameters
Table 12-31 CHANGE_IDENTITY_VALUE Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors, query the |
|
|
Current value associated with the identity. To find existing identities for each factor in the current database instance, query the To find current identity mappings, query the |
|
|
New identity value, up to 1024 characters in mixed-case. |
Example
BEGIN DVSYS.DBMS_MACADM.CHANGE_IDENTITY_VALUE( factor_name => 'Sector2_ClientID', value => 'remote', new_value => 'intranet'); END; /
The CREATE_DOMAIN_IDENTITY procedure adds an Oracle Real Application Clusters (Oracle RAC) database node to the domain factor identities and labels it according to the Oracle Label Security policy.
Syntax
DVSYS.DBMS_MACADM.CREATE_DOMAIN_IDENTITY( domain_name IN VARCHAR2, domain_host IN VARCHAR2, policy_name IN VARCHAR2 DEFAULT NULL, domain_label IN VARCHAR2 DEFAULT NULL);
Parameters
Table 12-32 CREATE_DOMAIN_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Name of the domain to which to add the host. To find the logical location of the database within the network structure within a distributed database system, run the |
|
|
Oracle Real Application Clusters host name being added to the domain. To find host name of a database, run the |
|
|
Oracle Label Security policy name. If you omit the policy name, then the domain is not associated with any policy. To find the available policies, query the |
|
|
Name of the domain to which to add the Oracle Label Security policy. |
Examples
BEGIN DVSYS.DBMS_MACADM.CREATE_DOMAIN_IDENTITY( domain_name => 'example', domain_host => 'mydom_host', policy_name => 'AccessData', domain_label => 'sensitive'); END; /
The CREATE_FACTOR procedure creates a factor. After you create a factor, you can give it an identity by using the CREATE_IDENTITY procedure, described in "CREATE_IDENTITY Procedure".
Syntax
DVSYS.DBMS_MACADM.CREATE_FACTOR( factor_name IN VARCHAR2, factor_type_name IN VARCHAR2, description IN VARCHAR2, rule_set_name IN VARCHAR2, get_expr IN VARCHAR2, validate_expr IN VARCHAR2, identify_by IN NUMBER, labeled_by IN NUMBER, eval_options IN NUMBER, audit_options IN NUMBER, fail_options IN NUMBER);
Parameters
Table 12-33 CREATE_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Factor name, up to 28 characters in mixed-case, without spaces. To find existing factors in the current database instance, query the |
|
|
Type of the factor, up to 30 characters in mixed-case, without spaces. To find existing factor types, query the |
|
|
Description of the purpose of the factor, up to 1024 characters in mixed-case. |
|
|
Rule set name if you want to use a rule set to control when and how a factor identity is set. To find existing rule sets, query the |
|
|
Valid PL/SQL expression that retrieves the identity of a factor. It can use up to 255 characters in mixed-case. See "Retrieval Method" for more information. See also the |
|
|
Name of the procedure to validate the factor. This is a valid PL/SQL expression that returns a Boolean value ( |
|
|
Options for determining the identity of a factor, based on the expression set for the
You can also use the following
See "Factor Identification" for more information. |
|
|
Options for labeling the factor:
You can also use the following
See "Factor Labeling" for more information. |
|
|
Options for evaluating the factor when the user logs on:
You can also use the following
See "Evaluation" for more information. |
|
|
Options for auditing the factor if you want to generate a custom Oracle Database Vault audit record.
You can also use the following
See "Audit Options" for more information. |
|
|
Options for reporting factor errors:
You can also use the following
See "Error Options" for more information. |
Example
BEGIN
DVSYS.DBMS_MACADM.CREATE_FACTOR(
factor_name => 'Sector2_DB',
factor_type_name => 'Instance',
description => ' ',
rule_set_name => 'Limit_DBA_Access',
get_expr => 'UPPER(SYS_CONTEXT(''USERENV'',''DB_NAME''))',
validate_expr => 'dbavowner.check_db_access',
identify_by => 2,
labeled_by => 0,
eval_options => DBMS_MACUTL.G_EVAL_ON_SESSION,
audit_options => DBMS_MACUTL.G_AUDIT_OFF,
fail_options => DBMS_MACUTL.G_FAIL_SILENTLY);
END;
/
The CREATE_FACTOR_TYPE procedure creates a user-defined factor type.
Syntax
DVSYS.DBMS_MACADM.CREATE_FACTOR_TYPE( name IN VARCHAR2, description IN VARCHAR2);
Parameters
Table 12-34 CREATE_FACTOR_TYPE Parameters
| Parameter | Description |
|---|---|
|
|
Factor type name, up to 30 characters in mixed-case, without spaces. To find existing factor types, query the |
|
|
Description of the purpose of the factor type, up to 1024 characters in mixed-case. |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_FACTOR_TYPE( name => 'Sector2Instance', description => 'Checks DB instances used in Sector 2'); END; /
The CREATE_IDENTITY procedure assigns an identity and an associated trust level for a given factor. After you create a factor, you must assign it an identity.
Syntax
DVSYS.DBMS_MACADM.CREATE_IDENTITY( factor_name IN VARCHAR2, value IN VARCHAR2, trust_level IN NUMBER);
Parameters
Table 12-35 CREATE_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors, query the |
|
|
The actual value of the factor, up to 1024 characters in mixed-case. For example, the identity of an IP_Address factor could be the IP address of 192.0.2.12. |
|
|
Number that indicates the magnitude of trust relative to other identities for the same factor. In general, the higher the trust level number is set, the greater the trust. A trust level of 10 indicates "very trusted." Negative trust levels are not trusted. See "Creating and Configuring a Factor Identity" for more information about trust levels and label security. |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_IDENTITY( factor_name => 'Sector2_ClientID', value => 'intranet', trust_level => 5); END; /
The CREATE_IDENTITY_MAP procedure defines a set of tests that are used to derive the identity of a factor from the value of linked child factors (subfactors).
Syntax
DVSYS.DBMS_MACADM.CREATE_IDENTITY_MAP( identity_factor_name IN VARCHAR2, identity_factor_value IN VARCHAR2, parent_factor_name IN VARCHAR2, child_factor_name IN VARCHAR2, operation IN VARCHAR2, operand1 IN VARCHAR2, operand2 IN VARCHAR2);
Parameters
Table 12-36 CREATE_IDENTITY_MAP Parameters
| Parameter | Description |
|---|---|
|
|
Factor the identity map is for. To find existing factors in the current database instance, query the |
|
|
Value the factor assumes if the identity map evaluates to To find existing factor identities, query the To find current factor identity mappings, use |
|
|
The parent factor link to which the map is related. To find existing parent-child factor mappings, query the |
|
|
The child factor link to which the map is related. |
|
|
Relational operator for the identity map (for example, <, >, =, and so on). |
|
|
Left operand for the relational operator; refers to the low value you enter. |
|
|
Right operand for the relational operator; refers to the high value you enter. |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_IDENTITY_MAP( identity_factor_name => 'Sector2_ClientID', identity_factor_value => 'intranet', parent_factor_name => 'HQ_ClientID', child_factor_name => 'Div1_ClientID', operation => '<', operand1 => '192.0.2.50', operand2 => '192.0.2.100'); END; /
The DELETE_FACTOR procedure deletes a factor.
Syntax
DVSYS.DBMS_MACADM.DELETE_FACTOR( factor_name IN VARCHAR2);
Parameters
Table 12-37 DELETE_FACTOR Parameter
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_FACTOR('Sector2_ClientID');
The DELETE_FACTOR_LINK procedure removes a parent-child relationship for two factors.
Syntax
DVSYS.DBMS_MACADM.DELETE_FACTOR_LINK( parent_factor_name IN VARCHAR2, child_factor_name IN VARCHAR2);
Parameters
Table 12-38 DELETE_FACTOR_LINK Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find factors that are used in parent-child mappings in the current database instance, query the |
|
|
Factor name. |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_FACTOR_LINK( parent_factor_name => 'HQ_ClientID', child_factor_name => 'Div1_ClientID'); END; /
The DELETE_FACTOR_TYPE procedure deletes a factor type.
Syntax
DVSYS.DBMS_MACADM.DELETE_FACTOR_TYPE( name IN VARCHAR2);
Parameters
Table 12-39 DELETE_FACTOR_TYPE Parameters
| Parameter | Description |
|---|---|
|
|
Factor type name. To find existing factor types, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_FACTOR_TYPE('Sector2Instance');
The DELETE_IDENTITY procedure removes an identity from an existing factor.
Syntax
DVSYS.DBMS_MACADM.DELETE_IDENTITY( factor_name IN VARCHAR2, value IN VARCHAR2);
Parameters
Table 12-40 DELETE_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
|
|
Identity value associated with the factor. To find the identities for each factor in the current database instance, query the |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_IDENTITY( factor_name => 'Sector2_ClientID', value => 'intranet'); END; /
The DELETE_IDENTITY_MAP procedure removes an identity map for a factor.
Syntax
DVSYS.DBMS_MACADM.DELETE_IDENTITY_MAP( identity_factor_name IN VARCHAR2, identity_factor_value IN VARCHAR2, parent_factor_name IN VARCHAR2, child_factor_name IN VARCHAR2, operation IN VARCHAR2, operand1 IN VARCHAR2, operand2 IN VARCHAR2);
Parameters
Table 12-41 DELETE_IDENTITY_MAP Parameters
| Parameter | Description |
|---|---|
|
|
Factor the identity map is for. To find existing factors in the current database instance, query the |
|
|
Value the factor assumes if the identity map evaluates to To find existing factor identities, query the To find current factor identity mappings, query |
|
|
The parent factor link to which the map is related. To find existing parent-child factors, query the |
|
|
The child factor to which the map is related. |
|
|
Relational operator for the identity map (for example, <, >, =, and so on). |
|
|
Left (low value) operand for the relational operator. |
|
|
Right (high value) operand for the relational operator. |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_IDENTITY_MAP( identity_factor_name => 'Sector2_ClientID', identity_factor_value => 'intranet', parent_factor_name => 'HQ_ClientID', child_factor_name => 'Div1_ClientID', operation => '<', operand1 => '192.0.2.10', operand2 => '192.0.2.15'); END; /
The DROP_DOMAIN_IDENTITY procedure removes an Oracle Real Application Clusters database node from a domain.
Syntax
DVSYS.DBMS_MACADM.DROP_DOMAIN_IDENTITY( domain_name IN VARCHAR2, domain_host IN VARCHAR2);
Parameters
Table 12-42 DROP_DOMAIN_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Name of the domain to which the host was added. To find the domain of a database as specified by the |
|
|
Oracle Real Application Clusters host name being that was added to the domain. To find the host name for a specified database, run the |
Example
BEGIN DVSYS.DBMS_MACADM.DROP_DOMAIN_IDENTITY( domain_name => 'example', domain_host => 'mydom_host'); END; /
The GET_INSTANCE_INFO function returns information from the SYS.V_$INSTANCE system table about the current database instance. The V$INSTANCE data dictionary view also contains database instance information from this table. See Oracle Database Reference for more information.
Syntax
DVSYS.DBMS_MACADM.GET_INSTANCE_INFO( p_parameter IN VARCHAR2) RETURN VARCHAR2;
Parameters
Table 12-43 GET_INSTANCE_INFO Parameter
| Parameter | Description |
|---|---|
|
|
Column name in the |
Example
DECLARE
instance_var varchar2 := null;
BEGIN
instance_var = DVSYS.DBMS_MACADM.GET_INSTANCE_INFO('INSTANCE_NAME');
END;
/
The GET_SESSION_INFO function returns information from the SYS.V_$SESSION system table for the current session. The V$SESSION data dictionary view also contains session information from this table. See Oracle Database Reference for more information.
Syntax
DVSYS.DBMS_MACADM.GET_SESSION_INFO( p_parameter IN VARCHAR2) RETURN VARCHAR2;
Parameters
Table 12-44 GET_SESSION_INFO Parameter
| Parameter | Description |
|---|---|
|
|
Column name in the |
Example
DECLARE
session_var varchar2 := null;
BEGIN
session_var = DVSYS.DBMS_MACADM.GET_SESSION_INFO('PROCESS');
END;
/
The RENAME_FACTOR procedure renames a factor. The name change takes effect everywhere the factor is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_FACTOR( factor_name IN VARCHAR2, new_factor_name IN VARCHAR2);
Parameters
Table 12-45 RENAME_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Current factor name. To find existing factors in the current database instance, query the |
|
|
New factor name, up to 28 characters in mixed-case, without spaces. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_FACTOR( factor_name => 'Sector2_ClientID', new_factor_name => 'Sector2_Clients'); END; /
The RENAME_FACTOR procedure renames a factor type. The name change takes effect everywhere the factor type is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_FACTOR_TYPE( old_name IN VARCHAR2, new_name IN VARCHAR2);
Parameters
Table 12-46 RENAME_FACTOR_TYPE Parameters
| Parameter | Description |
|---|---|
|
|
Current factor type name. To find existing factor types in the current database instance, query the |
|
|
New factor type name, up to 30 characters in mixed-case, without spaces. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_FACTOR_TYPE( old_name => 'Sector2Instance', new_name => 'Sector2DBInstance'); END; /
The UPDATE_FACTOR procedure updates the description of a factor type.
Syntax
DVSYS.DBMS_MACADM.UPDATE_FACTOR( factor_name IN VARCHAR2, factor_type_name IN VARCHAR2, description IN VARCHAR2, rule_set_name IN VARCHAR2, get_expr IN VARCHAR2, validate_expr IN VARCHAR2, identify_by IN NUMBER, labeled_by IN NUMBER, eval_options IN NUMBER, audit_options IN NUMBER, fail_options IN NUMBER);
Parameters
Table 12-47 UPDATE_FACTOR
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the |
|
|
Factor type name. To find existing factor types, query the |
|
|
Description of the purpose of the factor, up to 1024 characters in mixed-case. |
|
|
Name of the rule set used to control when and how a factor identity is set. To find existing rule sets, query the See also "Assignment Rule Set" for more information about assigning rule sets to factors. |
|
|
Valid PL/SQL expression that retrieves the identity of a factor. It can use up to 255 characters in mixed-case. See "Retrieval Method" for more information. See also the |
|
|
Name of the procedure to validate factor. This is a valid PL/SQL expression that returns a Boolean value ( |
|
|
Options for determining the identity of a factor, based on the expression set for the
You can also use the following
See "Factor Identification" for more information. |
|
|
Options for labeling the factor:
You can also use the following
The default for See "Factor Labeling" for more information. |
|
|
Options for evaluating the factor when the user logs on:
You can also use the following
The default for See "Evaluation" for more information. |
|
|
Options for auditing the factor if you want to generate a custom Oracle Database Vault audit record.
You can also use the following
The default for See "Audit Options" for more information. |
|
|
Options for reporting factor errors:
You can also use the following
The default for See "Error Options" for more information. |
Example
BEGIN
DVSYS.DBMS_MACADM.UPDATE_FACTOR(
factor_name => 'Sector2_DB',
factor_type_name => 'Instance',
description => ' ',
rule_set_name => 'Limit_DBA_Access',
get_expr => 'UPPER(SYS_CONTEXT(''USERENV'',''DB_NAME''))',
validate_expr => 'dbavowner.check_db_access',
identify_by => 2,
labeled_by => 0,
eval_options => DBMS_MACUTL.G_EVAL_ON_ACCESS,
audit_options => DBMS_MACUTL.G_AUDIT_ALWAYS,
fail_options => DBMS_MACUTL.G_FAIL_WITH_MESSAGE);
END;
/
The UPDATE_FACTOR_TYPE procedure updates a factor type.
Syntax
DVSYS.DBMS_MACADM.UPDATE_FACTOR_TYPE( name IN VARCHAR2, description IN VARCHAR2);
Parameters
Table 12-48 UPDATE_FACTOR_TYPE Parameters
| Parameter | Description |
|---|---|
|
|
Factor type name. To find existing factor types in the current database instance, query the |
|
|
Description of the purpose of the factor type, up to 1024 characters in mixed case. |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_FACTOR_TYPE( name => 'Sector2DBInstance', description => 'Checks DB instances used in Sector 2'); END; /
The UPDATE_IDENTITY procedure updates the trust level of a factor identity.
Syntax
DVSYS.DBMS_MACADM.UPDATE_IDENTITY( factor_name IN VARCHAR2, value IN VARCHAR2, trust_level IN NUMBER);
Parameters
Table 12-49 UPDATE_IDENTITY Parameters
| Parameter | Description |
|---|---|
|
|
Factor name. To find existing factors in the current database instance, query the To find factors that have identities, query |
|
|
New factor identity, up to 1024 characters in mixed-case. For example, the identity of an IP_Address factor could be the IP address of 192.0.2.12. |
|
|
Number that indicates the magnitude of trust relative to other identities for the same factor. In general, the higher the trust level number is set, the greater the trust. A trust level of 10 indicates "very trusted." Negative trust levels are not trusted. See "Creating and Configuring a Factor Identity" for more information about trust levels and label security. |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_IDENTITY( factor_name => 'Sector2_ClientID', value => 'intranet', trust_level => 10); END; /
Table 12-50 lists procedures within the DVSYS.DBMS_MACADM package that you can use to configure Oracle Database Vault secure application roles.
Chapter 8, "Configuring Secure Application Roles for Oracle Database Vault," describes secure application roles in detail. See also Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for a set of general-purpose utility procedures that you can use with the secure application role procedures.
Table 12-50 DVSYS.DBMS_MACADM Secure Application Role Configuration Procedures
| Procedure | Description |
|---|---|
|
|
Creates an Oracle Database Vault secure application role |
|
|
Deletes an Oracle Database Vault secure application role |
|
|
Renames an Oracle Database Vault secure application role. The name change takes effect everywhere the role is used. |
|
|
Updates a Oracle Database Vault secure application role |
The CREATE_ROLE procedure creates an Oracle Database Vault secure application role.
Syntax
DVSYS.DBMS_MACADM.CREATE_ROLE( role_name IN VARCHAR2, enabled IN VARCHAR2, rule_set_name IN VARCHAR2);
Parameters
Table 12-51 CREATE_ROLE Parameters
| Parameter | Description |
|---|---|
|
|
Role name, up to 30 characters, with no spaces. Preferably, enter the role name in upper case letters, though you are not required to do so. To find existing secure application roles in the current database instance, query the |
|
|
You can also use the following
|
|
|
Name of rule set to determine whether a user can set this secure application role. To find existing rule sets in the current database instance, query the |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_ROLE( role_name => 'Sector2_APP_MGR', enabled => 'Y', rule_set_name => 'Check App2 Access'); END; /
The DELETE_ROLE procedure deletes an Oracle Database Vault secure application role.
Syntax
DVSYS.DBMS_MACADM.DELETE_ROLE( role_name IN VARCHAR2);
Parameters
Table 12-52 DELETE_ROLE Parameter
| Parameter | Description |
|---|---|
|
|
Role name. To find existing secure application roles in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_ROLE('SECT2_APP_MGR');
The RENAME_ROLE procedure renames an Oracle Database Vault secure application role. The name change takes effect everywhere the role is used.
Syntax
DVSYS.DBMS_MACADM.RENAME_ROLE( role_name IN VARCHAR2, new_role_name IN VARCHAR2);
Parameters
Table 12-53 RENAME_ROLE Parameters
| Parameter | Description |
|---|---|
|
|
Current role name. Preferably, enter the role name in upper case letters, though you are not required to do so. To find existing secure application roles in the current database instance, query the |
|
|
Role name, up to 30 characters, in uppercase, with no spaces. Ensure that this name follows the standard Oracle naming conventions for role creation described in Oracle Database SQL Language Reference. |
Example
BEGIN DVSYS.DBMS_MACADM.RENAME_ROLE( role_name => 'SECT2_APP_MGR', new_role_name => 'SECT2_SYSADMIN'); END; /
The UPDATE_ROLE procedure updates a Oracle Database Vault secure application role.
Syntax
DVSYS.DBMS_MACADM.UPDATE_ROLE( role_name IN VARCHAR2, enabled IN VARCHAR2, rule_set_name IN VARCHAR2);
Parameters
Table 12-54 UPDATE_ROLE Parameters
| Parameter | Description |
|---|---|
|
|
Role name. To find existing secure application roles in the current database instance, query the |
|
|
You can also use the following
The default for |
|
|
Name of rule set to determine whether a user can set this secure application role. To find existing rule sets in the current database instance, query the |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_ROLE( role_name => 'SECT2_SYSADMIN', enabled => 'Y', rule_set_name => 'System Access Controls'); END; /
Table 12-55 lists procedures within the DVSYS.DBMS_MACADM package that you can use to configure Oracle Label Security policies for Oracle Database Vault.
Chapter 9, "Integrating Oracle Database Vault with Other Oracle Products," describes Oracle Label Security policies in detail. See also Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for a set of general-purpose utility procedures that you can use with the Oracle Label Security policy procedures.
Table 12-55 DVSYS.DBMS_MACADM Oracle Label Security Configuration Procedures
| Procedure | Description |
|---|---|
|
|
Specifies the algorithm that is used to merge labels when computing the label for a factor, or the Oracle Label Security Session label |
|
|
Labels an identity within an Oracle Label Security policy |
|
DELETE_MAC_POLICY_CASCADE Procedure |
Deletes all Oracle Database Vault objects related to an Oracle Label Security policy. |
|
DELETE_POLICY_FACTOR Procedure |
Removes the factor from contributing to the Oracle Label Security label |
|
|
Removes the label from an identity within an Oracle Label Security policy |
|
|
Specifies the algorithm that is used to merge labels when computing the label for a factor, or the Oracle Label Security Session label |
The CREATE_MAC_POLICY procedure specifies the algorithm that is used to merge labels when computing the label for a factor, or the Oracle Label Security Session label.
Syntax
DVSYS.DBMS_MACADM.CREATE_MAC_POLICY( policy_name IN VARCHAR2, algorithm IN VARCHAR2);
Parameters
Table 12-56 CREATE_MAC_POLICY Parameters
| Parameter | Description |
|---|---|
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
|
|
Merge algorithm for cases when Oracle Label Security has merged two labels. Enter the code listed in Table 12-57 that corresponds to the merge algorithm you want. For example, enter For more information on label-merging algorithms, see Oracle Label Security Administrator's Guide. |
Table 12-57 Oracle Label Security Merge Algorithm Codes
| Code | Value |
|---|---|
|
|
Maximum Level/Union/Union |
|
|
Maximum Level/Intersection/Union |
|
|
Maximum Level/Minus/Union |
|
|
Maximum Level/Null/Union |
|
|
Maximum Level/Union/Intersection |
|
|
Maximum Level/Intersection/Intersection |
|
|
Maximum Level/Minus/Intersection |
|
|
Maximum Level/Null/Intersection |
|
|
Maximum Level/Union/Minus |
|
|
Maximum Level/Intersection/Minus |
|
|
Maximum Level/Minus/Minus |
|
|
Maximum Level/Null/Minus |
|
|
Maximum Level/Union/Null |
|
|
Maximum Level/Intersection/Null |
|
|
Maximum Level/Minus/Null |
|
|
Maximum Level/Null/Null |
|
|
Minimum Level/Union/Union |
|
|
Minimum Level/Intersection/Union |
|
|
Minimum Level/Minus/Union |
|
|
Minimum Level/Null/Union |
|
|
Minimum Level/Union/Intersection |
|
|
Minimum Level/Intersection/Intersection |
|
|
Minimum Level/Minus/Intersection |
|
|
Minimum Level/Null/Intersection |
|
|
Minimum Level/Union/Minus |
|
|
Minimum Level/Intersection/Minus |
|
|
Minimum Level/Minus/Minus |
|
|
Minimum Level/Null/Minus |
|
|
Minimum Level/Union/Null |
|
|
Minimum Level/Intersection/Null |
|
|
Minimum Level/Minus/Null |
|
|
Minimum Level/Null/Null |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_MAC_POLICY( policy_name => 'Access Locations', algorithm => 'HUU'); END; /
The CREATE_POLICY_LABEL procedure labels an identity within an Oracle Label Security policy.
Syntax
DVSYS.DBMS_MACADM.CREATE_POLICY_LABEL( identity_factor_name IN VARCHAR2, identity_factor_value IN VARCHAR2, policy_name IN VARCHAR2, label IN VARCHAR2);
Parameters
Table 12-58 CREATE_POLICY_LABEL Parameters
| Parameter | Description |
|---|---|
|
|
Name of the factor being labeled. To find existing factors in the current database instance, query the To find factors that are associated with Oracle Label Security policies, use See also "Label Security Policy Factors" for more information. |
|
|
Value of identity for the factor being labeled. To find the identities of existing factors in the current database instance, query the |
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
|
|
Oracle Label Security label name. To find existing policy labels for factor identifiers, query the |
Example
BEGIN DVSYS.DBMS_MACADM.CREATE_POLICY_LABEL( identity_factor_name => 'App_Host_Name', identity_factor_value => 'Sect2_Fin_Apps', policy_name => 'Access Locations', label => 'Sensitive'); END; /
The DELETE_MAC_POLICY_CASCADE procedure deletes all Oracle Database Vault objects related to an Oracle Label Security policy.
Syntax
DVSYS.DBMS_MACADM.DELETE_MAC_POLICY_CASCADE( policy_name IN VARCHAR2);
Parameters
Table 12-59 DELETE_MAC_POLICY_CASCADE Parameter
| Parameter | Description |
|---|---|
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
Example
EXEC DVSYS.DBMS_MACADM.DELETE_MAC_POLICY_CASCADE('Access Locations');
The DELETE_POLICY_FACTOR procedure removes the factor from contributing to the Oracle Label Security label.
Syntax
DVSYS.DBMS_MACADM.DELETE_POLICY_FACTOR( policy_name IN VARCHAR2, factor_name IN VARCHAR2);
Parameters
Table 12-60 DELETE_POLICY_FACTOR Parameters
| Parameter | Description |
|---|---|
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
|
|
Name of factor associated with the Oracle Label Security label. To find factors that are associated with Oracle Label Security policies, query |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_POLICY_FACTOR( policy_name => 'Access Locations', factor_name => 'App_Host_Name'); END; /
The DELETE_POLICY_LABEL procedure removes the label from an identity within an Oracle Label Security policy.
Syntax
DVSYS.DBMS_MACADM.DELETE_POLICY_LABEL( identity_factor_name IN VARCHAR2, identity_factor_value IN VARCHAR2, policy_name IN VARCHAR2, label IN VARCHAR2);
Parameters
Table 12-61 DELETE_POLICY_LABEL Parameters
| Parameter | Description |
|---|---|
|
|
Name of the factor that was labeled. To find existing factors in the current database instance that are associated with Oracle Label Security policies, query See also "Label Security Policy Factors" for more information. |
|
|
Value of identity for the factor that was labeled. To find the identities of existing factors in the current database instance, query the |
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
|
|
Oracle Label Security label name. To find existing policy labels for factor identifiers, query the |
Example
BEGIN DVSYS.DBMS_MACADM.DELETE_POLICY_LABEL( identity_factor_name => 'App_Host_Name', identity_factor_value => 'Sect2_Fin_Apps', policy_name => 'Access Locations', label => 'Sensitive'); END; /
The UPDATE_MAC_POLICY procedure specifies the algorithm that is used to merge labels when computing the label for a factor, or the Oracle Label Security Session label.
Syntax
DVSYS.DBMS_MACADM.UPDATE_MAC_POLICY( policy_name IN VARCHAR2, algorithm IN VARCHAR2);
Parameters
Table 12-62 UPDATE_MAC_POLICY
| Parameter | Description |
|---|---|
|
|
Name of an existing policy. To find existing policies in the current database instance, query the |
|
|
Merge algorithm for cases when Oracle Label Security has merged two labels. See Table 12-57 for listing of the available algorithms. For more information on label-merging algorithms, see Oracle Label Security Administrator's Guide. |
Example
BEGIN DVSYS.DBMS_MACADM.UPDATE_MAC_POLICY( policy_name => 'Access Locations', algorithm => 'LUI'); END; /
Table 12-63 lists the procedures within the DVSYS.DBMS_MACADM PL/SQL package that you can use to perform general maintenance activities that require the protection of the DV_OWNER or DV_ADMIN role.
Table 12-63 DVSYS.DBMS_MACADM Disable/Enable Procedures
| Procedure | Description |
|---|---|
|
|
Adds a new language to Oracle Database Vault |
|
AUTHORIZE_DATAPUMP_USER Procedure |
Authorizes a user to perform Oracle Data Pump operations when Oracle Database Vault is enabled |
|
AUTHORIZE_SCHEDULER_USER Procedure |
Authorizes a user to schedule database jobs when Oracle Database Vault is enabled |
|
UNAUTHORIZE_DATAPUMP_USER Procedure |
Revokes the authorization that was granted by the |
|
UNAUTHORIZE_SCHEDULER_USER Procedure |
Revokes authorization that was granted by the |
The ADD_NLS_DATA procedure adds a new language to Oracle Database Vault.
Syntax
DVSYS.DBMS_MACADM.ADD_NLS_DATA( language IN VARCHAR );
Parameters
Table 12-64 ADD_NLS_DATA
| Parameter | Description |
|---|---|
|
|
Enter one of the following settings. (This parameter is case insensitive.)
|
Examples
EXEC DVSYS.DBMS_MACADM.ADD_NLS_DATA('french');
The AUTHORIZE_DATAPUMP_USER procedure authorizes a user to perform Oracle Data Pump operations when Oracle Database Vault is enabled. It applies to both the expdp and impdp utilities. See "Granting a Database Administrator Authorization to Use Oracle Data Pump" for full usage information, including the levels of additional authorization the user must have to use Oracle Data Pump in an Oracle Database Vault environment.
Syntax
DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER( user_name IN VARCHAR2, schema_name IN VARCHAR2 DEFAULT NULL, table_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 12-65 AUTHORIZE_DATAPUMP_USER
| Parameter | Description |
|---|---|
|
|
Name of the Oracle Data Pump user to whom you want to grant authorization. To find a list of users who have privileges to use Oracle Data Pump (that is, the SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE LIKE '%FULL%' |
|
|
Name of the database schema that the Oracle Data Pump user must export or import. If you omit this parameter, then the user is granted global authorization to export and import any schema in the database. In this case, ensure the user has been granted the |
|
|
Name of the table within the schema specified by the |
Examples
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR');
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
The AUTHORIZE_SCHEDULER_USER procedure grants a user authorization to schedule database jobs when Oracle Database Vault is enabled. This authorization applies to anyone who has privileges to schedule database jobs. These privileges include any of the following: CREATE JOB, CREATE ANY JOB, CREATE EXTERNAL JOB, EXECUTE ANY PROGRAM, EXECUTE ANY CLASS, MANAGE SCHEDULER. See "Scheduling Database Jobs in an Oracle Database Vault Environment" full usage information, including the levels of authorization the user must have to schedule database jobs in an Oracle Database Vault environment.
Syntax
DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER( user_name IN VARCHAR2, schema_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 12-66 AUTHORIZE_SCHEDULER_USER
| Parameter | Description |
|---|---|
|
|
Name of the user to whom you want to grant authorization. To find a list of users who have privileges to schedule jobs, query the |
|
|
Name of the database schema for which a job will be scheduled. If you omit this parameter, then the user is granted global authorization to schedule a job for any schema in the database. |
Examples
The following example authorizes the user JOB_MGR to run a job under any schema.
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
This example authorizes user JOB_MGR to run a job under the HR schema only.
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
The UNAUTHORIZE_DATAPUMP_USER procedure revokes the authorization that was granted by the AUTHORIZE_DATAPUMP_USER procedure. When you run this procedure, ensure that its settings correspond exactly to the equivalent AUTHORIZE_DATAPUMP_USER procedure.
For example, the following two procedures will work because the parameters are consistent:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR');
However, because the parameters in the following procedures are not consistent, the UNAUTHORIZE_DATAPUMP_USER procedure will not work:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('JSMITH');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('JSMITH', 'HR');
Syntax
DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER( user_name IN VARCHAR2, schema_name IN VARCHAR2 DEFAULT NULL, table_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 12-67 UNAUTHORIZE_DATAPUMP_USER
| Parameter | Description |
|---|---|
|
|
Name of the Oracle Data Pump user from whom you want to revoke authorization. To find a list of users and authorizations from the SELECT RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET WHERE RULE_SET_NAME = 'Allow Oracle Data Pump Operation'; |
|
|
Name of the database schema that the Oracle Data Pump user is authorized to export or import. |
|
|
Name of the table within the schema specified by the |
Examples
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('JSMITH');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('JSMITH', 'HR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('JSMITH', 'HR', 'SALARY');
The UNAUTHORIZE_SCHEDULER_USER procedure revokes the authorization that was granted by the AUTHORIZE_SCHEDULER_USER procedure. When you run this procedure, ensure that its settings correspond exactly to the equivalent AUTHORIZE_SCHEDULER_USER procedure.
For example, the following two procedures will work because the parameters are consistent:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');
However, because the parameters in the following procedures are not consistent, the UNAUTHORIZE_SCHEDULER_USER procedure will not work:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
Syntax
DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER user_name IN VARCHAR2, schema_name IN VARCHAR2 DEFAULT NULL);
Parameters
Table 12-68 UNAUTHORIZE_SCHEDULER_USER
| Parameter | Description |
|---|---|
|
|
Name of the job scheduling user from whom you want to revoke authorization. To find a list of users and authorizations from the SELECT RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET WHERE RULE_SET_NAME = 'Allow Scheduler Job'; |
|
|
Name of the database schema for which the user is authorized to schedule jobs. |
Examples
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
f.orA
A
A$& &"r-" H~ FS8"ĵ* trj*.٪ 1^p! L
m$1,2(" tWr0c
[/.Ɓ)mr( rE!۲2#$o /sKxg03Y:y272'r3vªY80?r9ZmGmPFǟ
cs2/r^73N/K,K2C?"cD_!E^tf40sQ#`䬅4mrז*B4jG_{&!F1UC/4٪4^\ æ*OG @r$Cb!\ .5u'w-x j^E'_1@-F 6(`up3l`GvO$
n$5]142_&v6^`iǵvo umwkhCct2F;s p
wq[7 wno Bwx'u1 uN 3Z,7Q77xwùA| ^vzqf/oiYt}#8Y@pu i[3wā'xS}{mgwm7Q|[8ַZUvﱝw_ xxK[k7x˸e n3I|E;ӷ+9i3u8mF'3jk9qR8GO9o#xpy$ d8빕yY8F6IsQ;+z[D[KSz[czk_:彀:=K '
`[zz:啶 ;h )3{;C{KG;95lA{;{{{{㻽g{#A ||WA+3|'@|K<ďA[|A Ds |!bRmO % Mtps KjPk-k\(0֍ FWR~ =.'#
s@Q͖r
@3 `
k}-;L01# E| ڷO wpD p=h`JN.a . !p ~
k-b`xF[ i T. @aTz1 BTkc[PsM
|Grx@ 0 S DP
$,ŇcYp2?c4+V@
f0 r aPSP
_P$`> t M4PΛ$HE;
80b
nmm&HZywDPxjV0Y2 ~ O
>v&fN\ \@g S # !q?_0L` 2uggާ=/?irNt. 0e@ y 1.@ F Z`
ys 0g[ԛ0 m@& ,]_@Q^V7# `. 6
Qr|; |K.u4T"
rC 3lAF1 j`
8Dv# 5 `u yl!NAΥrh~B@$y%ͥv$D eD iMg B*!1Qp7}ٍpM@/-)a qøv%ڌݍJhChl߈vv
XpуTD
jq9bkE@`s5:鈵 AG(p7xDȀE
,aA Ёa CZ (n .P.HAX@64!{[ 6!`A Vd*w$ (8j`@ڊ
n
, 0 X $ q
4Mz@)5h=@`m$ [
mZ z'X?dA `h!4 9{ 0XBІ2;6m5|P2 0 | (K= FE֙ =`@w͓iL遝C,)a9@ zJrҗL ل a@B01 ؓ '6prdY?b:`Fp\@D&Z"'Tx
F .kjaӶa IO!
IAҪtr1 · ^lT5% !2TKfXPA"agPA?EZT p1 #DaC |ZY ' @ J9px:ceBu*o+[aT3ke!ST sb "` Z0 B ,hsv
B8~@ %P~p
f!A
Pj.pJ%U g@ v4=m80m
36(Ё? TЄ3 A /6T`j28*
*H
Tp= hwݨ7h `m_r ^@ <0 gg!Fp l.# [Y0i&2-` @MBЈNF;ѐ'bC8ESӂ" 6A"PAf@ 2w 6o m 8 a *@uLF675ʍR$DMrNv~ŁiMw D@`AJ@"k,g@hr͍lh8D
ȀOAI 2 qGٖ z 4O ^२b0
2-
I@j49=%30Ou Oɉz
5`[U*K l05W
`gmgb"w r*
hxjꆁj%P0 pj> m`Щ Z-q plw0_(,I e?@aR ʺ/e6WF!sruox
lN)~
M"!t&@ C0oȹNK P#
A IpPr{l!P"n FK 9+먱JƱF{Z
~p5P7 2 p` J]ie20\
R*õ2!C$ {
$
0 "ER*e0[ EPi@5Y 2&BG`SNʻۼ;[{[:@oe+- n(E?W\Dp۾+#Z{[}_jŵ* kt[_lia',
,t[dLa" s [ ,c!|GA\1o 'p %P=,j`x:
,1` >>rJ|n*DS;p>(sYZ+l[-_/ C!ÐJ&
xq{! %,O@xD ^ #a| 9"X <Ѫ!'
QpǏDik,Xm_o ! me J0 [ ($h)X@U?k@6$˓r X!p0:F`7!] 9 f & %, %
5)h NW\_ؠ˕t#G *~h^7= 1Rp(QsM5g9]0`t$p %} 0
ۧYм5DF}HJLNP R=TM}& m@7 ٩6)\}uq܄$Tև8T"pa q7 <OJ8
WB[Sٞ٠ ڢ=ڤ]ڦ}ڨڪVY͚s 9b8IDkP.`~ڴ XПE? TԐvtMfpg
d nson ["b "E". R G<
5 PY+T+& @˵6l{o0ؾʐ% <5q؇ _pZ.ggo ,
e
0
! L jU\B;Kpt_gf _ h?s礡k`ЙWse5%dEplXdZ$fm& 6`p _
Gр( Y ^ _U;op_`[J P.r2HsMzg ;> ! hX(X & @Fj> 8O*wN%M 66 M%ŗ 'fLҽپXX^A"vS4>J-J C* BL3ؠd0R4 !:L.AÙ`P'E6WdѲK/p8sꌆ-H4I[H*⦴a n]v PԂl)C ,*PᅁDaL7h qD)5:0PMZ(jbA &QQ GH3d%\v9 MZOci,RG_6tmVs:IZi
Rv BhO FFɏ4kT Ά&0Fm>~ă"
K%ftg6C
"> ! ` 4<< >;
n|qI>`e4pqb+HC IlÄ+iР 6Zl^ Kmb6G x,*U4@ 5pB <P2R"0p$eЗD!`0"*l
7@=p
"
>LC*`h7!xцd4KIA<dO!
.&*`l}XF"|Ep@!>F%\K!ȰΞ`ܰn: I2ig21.+q^4e\8/oxMW"ok TS6S0O?N,CC:U4!E1!H'5F#\NB!M48[kSTSO*0/TEVBX
K 5GKa O[q3:i=tP:i}PT6ګTYWQ 4LM]m`mVT<3/wWZyw)jyv[Wo O]s%'u4w]7~ct_^/{T6_M}ܑd%m;nLS]&C8^3gON3Bwe? 4믺2 9Y:3.fY.VQyan1F;mTUTV;n:(%,ܻoFĚpwHUgq 9oosAM*t AЋV0,
YQֻaC ӠGpXF
>iov"WIp@?F0BmD#b30Y5('<sH0юk"طupt$!3X Using Oracle Data Pump in an Oracle Database Vault Environment Scheduling Database Jobs in an Oracle Database Vault Environment Using Oracle Streams in an Oracle Database Vault Environment Using Oracle GoldenGate in an Oracle Database Vault Environment Setting the Database Vault Administrator URL in Oracle Enterprise Manager Propagating Oracle Database Vault Policies to Other Databases Using Enterprise Manager Grid Control Alerts for Oracle Database Vault Policies Using Oracle Database Vault-Specific Reports in Enterprise Manager Grid Control Changing the DBSNMP Account Password in an Oracle Database Vault Environment You can configure Database Control or Grid Control to use a specific Database Vault Administrator URL. Access Oracle Database Vault Home page from Oracle Enterprise Manager. See "Accessing the Oracle Database Vault Pages from Oracle Enterprise Manager". If you want to save the Database Vault URL: For Database Control: Ensure that in addition to being granted the For Grid Control: Ensure that you have been granted the Access the Database Vault Administrator URL page. From the Database Vault Home page, click the Administration tab, and then under Policy Administration, click the Launch Database Vault Administrator link. The Database Vault Administrator URL page appears. In the Database Vault Administrator URL field, enter the Database Vault Administrator URL that you want to use. For example: To test the URL, click the Launch to test URL button. Click the Save button. If you have Oracle Database Vault installed in an Oracle Enterprise Manager Grid Control Release 10.2.0.5 environment, then you can propagate Database Vault policies to other Database Vault-protected databases. Note that you cannot use Grid Control to create Database Vault policies or perform the actions normally provided for in Database Vault Administrator. If you want to perform these functions, then use Database Vault Administrator. To propagate Database Vault policies to other databases: Access Oracle Database Vault Administrator from Oracle Enterprise Manager, and log in to Database Vault as a user who has been granted the Ensure that you select the database that contains the policies that you want to propagate. See "Accessing the Oracle Database Vault Pages from Oracle Enterprise Manager". From the Database Vault home page, select the Administration subpage. In the Administration page, under Policy Propagation, select the Database Vault Policy Propagation link. The Available Policies area in the Policy Propagation subpage lists a summary of the Oracle Database Vault policies that were created for the database that you selected in Step 1. From here, you can propagate these policies to another database. Under Available Policies, select each policy that you want to propagate to another database. By default, all policies are selected. Under Destination Databases, click the Add button. Under Search and Select: Database Vault Enabled Destination Databases, search for the destination databases, and then select each database to which you want to propagate the policies. Then click the Select button. Under Destination Databases, do the following: Under Apply credentials across destination database(s), enter the user name and password of the administrator of the Database Vault database that contains the policies you want to propagate. This feature applies the Database Vault administrator's user name and password to all of the selected destination databases. Select each database to which you want to propagate the policies. Enter the Database Vault administrator user name and password for each database. Click the Apply button. In the Propagate Options page, select from the following options. Any changes made to the seeded realms, command rules, rule sets, and so on will not be propagated to the destination databases. Only custom-created data are propagated. Restore on failure: If the policy propagation encounters errors, then the propagation is rolled back. That is, the original policies on the destination database are restored. If you do not select this option, then the policy propagation on the destination database continues and ignores any errors. Skip propagation if user defined policies exist: If the destination databases already have the user-defined policies, then the policy propagation is not attempted. If you do not select this option, then regardless of whether user-defined policies exist on the destination database, all the existing policies are cleared, and the policies from the source database are applied to the destination database. Propagate Enterprise Manager metric thresholds for database vault metrics: If the source database has Oracle Database Vault metric thresholds set, then these thresholds are also propagated to the destination databases. If you do not select this option, then only policies are propagated and not the Oracle Database Vault thresholds. Click the OK button. In the Confirmation window, click OK. A message indicating success or failure appears. If the propagation succeeds, then the policies are active right away in their destination databases. Grid Control generates Oracle Database Vault-specific alerts. To view these alerts, you must be granted the Database Vault Attempted Realm Violations. This alert helps the Oracle Database Vault security analyst ( Database Vault Attempted Command Rule Violations. The functionality for this alert is the same as for Database Vault Attempted Realm Violations, except that it focuses on violations on command rules. Database Vault Realm Configuration Issues. This metric tracks and raises an alert if users misconfigure realms. This metric is enabled when you install Oracle Database vault, and by default it collects data every one hour. Database Vault Command Rule Configuration Issues. This functionality for this alert is that same as Database Vault Realm Configuration Issues, except that it focuses on configuration changes to command rules. Database Vault Policy Changes. This metric raises an alert on any change to any Database Vault policy, such as policies for realms and command rules. It provides a detailed policy changes report. From the Database Vault home page, you can find information about the following types of violations: Top five attempted violations on realm and command rule Top five attempted violations by database users and client host Time series-based graphical reports on attempted violations for more detailed analysis To have full access to the Database Vault reports, you must log in to Database Vault Administrator as a user who has been granted the Before you can change the password for the To change the Log in to SQL*Plus using an account that has been granted the Revoke the Connect as a user who has been granted the Connect as the Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the This section contains: About Using Oracle Data Pump in an Oracle Database Vault Environment Granting a Database Administrator Authorization to Use Oracle Data Pump Guidelines for Exporting or Importing Data in an Oracle Database Vault Environment Revoking Authorization from Databases Administrators Who Are Using Data Pump Database administrators who want to use Oracle Data Pump must have Oracle Database Vault-specific authorization, in addition to the standard Oracle Data Pump privileges, if they want to export and import data in an Oracle Database Vault environment. (Note that you cannot use the legacy The level of authorization that you must grant depends on the following scenarios: A database administrator wants to export or import data in a schema that has no realm protection. In this case, this user only needs the standard Oracle Data Pump privileges, not the Oracle Database Vault authorization. A database administrator wants to export or import data in a protected schema. You must grant this user Database Vault-specific authorization by using the A database administrator wants to export or import the contents of an entire database. In addition to the authorization granted by the To authorize a database administrator to use Data Pump in an Oracle Database Vault environment: Log in to SQL*Plus as a user who has been granted the Ensure that the user to whom you want to grant authorization has been granted the Grant this user Oracle Database Vault authorization. For example, to authorize the Data Pump user Optionally, you can restrict See "AUTHORIZE_DATAPUMP_USER Procedure" for detailed information about this procedure. After you run the If the objects that this user wants to import are associated with other objects that are protected by a realm, then authorize the user to have access to that realm. For example, suppose user First, ensure that this user is a realm participant. For example: Next, run the following procedure to authorize the user for Oracle Data Pump operations: If the user must export the entire database, then grant the user the Ensure that the Allow Oracle Data Pump Operation rule set has been enabled by querying the After you have granted the database administrator who is using Data Pump the necessary authorization, this user is ready to perform any export or import operations that are necessary. Before this user begins work, he or she should follow these guidelines: Create a full backup of the database datafiles. This way, if you or other users do not like the newly-imported data, you easily can revert the database to its previous state. This guideline is especially useful if an intruder had managed to modify Data Pump exported data to use his or her own policies. Decide how to handle exporting and importing multiple schemas or tables. You cannot specify multiple schemas or tables in the Run individual Perform a full database export or import operation. If so, see the next guideline. When performing an export or import operation for an entire database, set the expdp or impdp FULL option to Y. Remember that this setting will capture the To revoke authorization from the database administrator who is using Data Pump: If you granted the user the Query the For example, if you had authorized user Use the information you gathered from Step 2 to build the For example: Ensure that this unauthorization complements the original authorization action. In other words, if you originally gave See "UNAUTHORIZE_DATAPUMP_USER Procedure" for more information. If you needed to make the user a realm participant (for example, to access the For example: This section contains: About Scheduling Database Jobs in an Oracle Database Vault Environment Granting a Job Scheduling Administrator Authorization for Oracle Database Vault Users who are responsible for scheduling database jobs must have Oracle Database Vault-specific administration, in addition to the standard system privileges required for scheduling database jobs. The level of authorization that you must grant depends on the following scenarios: An administrator wants to schedule a job in his or her own schema. An administrator who has been granted privileges to schedule database jobs can continue to do so without any Oracle Database Vault-specific authorizations, unless this schema is protected by a realm. In that case, ensure that this user is authorized to access the realm. See "Defining Realm Authorization" for instructions on granting a user realm authorization. An administrator wants to run a job in another schema, but this job does not access any Oracle Database Vault realm or command rule protected object. In this case, this user only needs job related system privileges, not the Oracle Database Vault privileges. An administrator wants to run a job under the schema of another user, including any schema in the database or a remote database. If this job accesses an Oracle Database Vault realm or command rule protected object, then you must grant this user Database Vault-specific authorization by using the Later on, you can revoke this authorization by using the To authorize a user to schedule database jobs: Log in to SQL*Plus as a user who has been granted the Only a user who has been granted either of these roles can grant the necessary authorization. Ensure that the user to whom you want to grant authorization has been granted system privileges to schedule database jobs. These privileges include any of the following: For example: Grant this user Oracle Database Vault authorization. For example, to authorize the user Optionally, you can restrict See "AUTHORIZE_SCHEDULER_USER Procedure" for detailed information about this procedure. After you run the Ensure that the user has been authorized by querying the To revoke authorization from a user for scheduling database jobs. Query the For example, if you had authorized user Use the information you gathered from Step 1 to build the For example: Ensure that this unauthorization complements the original authorization action. In other words, if you originally gave See "UNAUTHORIZE_SCHEDULER_USER Procedure" for more information. You can +ouse Recovery Manager (RMAN) in an Oracle Database Vault environment. The functionality of RMAN with Oracle Database Vault is the same as its functionality in a standard Oracle Database environment. For more information about RMAN, see the following documentation: If you want to use Oracle Streams in an Oracle Database Vault environment, then you must have the following privileges: You must be granted the Before you can apply changes to any tables that are protected by a realm, you must be authorized to have access to that realm. For example: See "ADD_AUTH_TO_REALM Procedure" for more information about the If you want to use XStream in an Oracle Database Vault environment, then you must have the following privileges: You must be granted the Before you can apply changes to any tables that are protected by a realm, you must be authorized to have access to that realm. For example: See "ADD_AUTH_TO_REALM Procedure" for more information about the If you want to use Oracle GoldenGate in an Oracle Database Vault environment, then you must have the following privileges: You must be granted the You must be granted the Before you can apply changes to any tables that are protected by a realm, you must be authorized to have access to that realm. For example: See "ADD_AUTH_TO_REALM Procedure" for more information about the This section contains: About Data Masking in an Oracle Database Vault Enabled Database Adding Data Masking Users to the Data Dictionary Realm Authorizations Giving Users Access to Tables or Schemas That They Want to Mask In an Oracle Database Vault-enabled database, only users who have Database Vault authorizations can mask data in Database Vault-protected database objects. In a non-Database Vault environment, users who have been granted the If users do not have the correct privileges, then the following errors can occur while creating the masking definition or when the job is executing: The Oracle Data Dictionary controls access to the Oracle Database catalog schemas, such as For example: If the table or schema of a table that is to be data masked is in a realm, then you must add the user responsible for data masking to the realm authorization as a participant or owner. If the table or schema has dependent objects that are in other realm-protected tables, then you must grant the user participant or owner authorization for those realms as well. The following example shows how to grant user For data masking, users must have the You can create command rules to control data masking privileges at a granular level. To do so, create a command rule that can either prevent or allow the user access to objects that must have to be data masked. For example, you can create a command rule called Allow Data Masking that checks if the user is in a list of users who are responsible for data masking. If the user logging in is one of these users, then the command rule evaluates to true and the user is permitted to create the data mask for the protected object. To create this type of command rule: Create the rule set rule. For example: Create a rule set and then add the rule to it: Create a command rule and then add this rule to it: This screen shows the Security Policy Changes Detail area with sample data. Categories are as follows: Timestamp, User Name, User Host, Action Name, Return Code, Action Object Name, Rule Set Name, Action Command. This screenshot focuses on the Destination Databases area of the Database Vault Policy Management page. Under "Destination Databases" is this legend: "Select the databases to which these policies need to be applied. Database Vault administrator credentials are required for each of the destination databases to successfully propagate the policies. "The table below shows the list of database targets to which these database policies will be applied." Following the legend are Add and Remove buttons, which are followed by the table columns Select, Database Name, Database Type, Database Vault Administrator User Name, Database Vault Administrator Password. There are no databases listed yet in this screenshot. Following the table is the Propagate Options area, which is described in the following steps of this procedure. This figure shows the Security Policy Changes By Category. X axis displays the time period; the Y axis shows the number of changes. This screen shows the Database Vault Policy Management page, and focuses on the Available Policies area. Under "Database Vault Policy Management" is the following text : "The Database Vault Policy Management feature enables the propagation of database vault policies like Realms, Command Rules, Secure Application roles, Factors and Rulesets from a source database to multiple destination databases.This allows to propagate database security policies across an enterprise." Following this text is the Available Policies area, which has the legend "The following is the list of all the available database vault policies. Select the policies that need to be propagated to the destination databases." From left to right under it are the links Select All, Select None, Expand All, Collapse All. In the table that follows are these columns: Select, Name, and Status. Under Name is a Policies list, which contains the different categories of Database Vault components: Realms, Command Rules, Secure Application Roles, and Rule Sets. This screenshot shows the Secure Application Roles link expanded, with two roles displayed. Following Available Policies is the Destination Databases area, which isdescribed in the next step. This figure shows a set of realms with data automatically being encrypted and decrypted through SQL. It also shows sensitive data encrypted on backup files. This figure shows the Database Configuration and Structural Changes table. Columns are: Timestamp, User Name, User Host, Action Name, Return Code, Owner, Object Name, and Comment Text. Surrounding text describes this figure. This screen shows the Security Violation Attempts area with sample data. Categories are as follows: Timestamp, User Name, User Host, Action Name, Return Code, Action Object Name, Rule Set Name, Action Command. This figure illustrates how realm authorization works for two realm owners, the Order Entry realm owner and the Human Resources realm owner. The Order Entry realm owner has the OE_ADMIN role, and the Human Resources realm own has HR_ADMIN role. Both of these realm owners have the following database privileges: CREATE ANY TABLE DROP ANY TABLE SELECT ANY TABLE GRANT/REVOKE When these realm owners perform an action in their respective schemas—OE schema for the Order Entry realm owner and the HR schema for the Human Resources realm owner—the Oracle Database Vault realm authorizations allow them to perform any of the database privileges to which they are assigned. However, they are not permitted to perform these actions in each other's realm. For example, the Order Entry realm owner cannot create tables in the HR schema, nor can the Human Resource realm owner drop tables from the OE schema. This figure illustrates how Oracle Database Vault roles are categorized. The roles fall into four categories, which are as follows, from top to bottom: Security administrative roles: DV_OWNER, DV_ADMIN, DV_MONITOR, DV_SECANALYST, DV_PATCH_ADMIN, DV_STREAMS_ADMIN, DV_XSTREAMS_ADMIN, DV_GOLDENGATE_ADMIN, DV_GOLDENGATE_REDO_ACCESS Account management responsibility role: DV_ACCTMGR Resource management roles: DV_REALM_OWNER (for application management and granted to realm owners); DV_REALM_RESOURCE (for application access and granted to realm participants) All responsibilities: DV_PUBLIC (granted by default to all database users to give access to the Oracle Database Vault public functions) This figure shows the Database Vault home page, right after you log in. The Administration tab displays by default, which lists links to the following components so that you can start to configure them: Realms Command Rules Factors Rule Sets Secure Application Roles Label Security Integration Other tabs are Database Vault Reports, General Security Reports, and Monitor. Accounts and Roles That Should be Limited to Trusted Individuals Guidelines for Using Oracle Database Vault in a Production Environment This section contains: Defining Separate Tasks in an Oracle Database Vault Environment Identifying and Documenting the Tasks of Users Who Access the Database System Separation of duty means that you restrict each user's privileges only to the tasks he or she is responsible for, and no more. You should assign specific categories of privileges to specific users, rather than granting many privileges to one user. Simply put, separation of duty creates accountability for each task that your organization requires. Separation of duty has taken on increased importance over the past 10 years. For many organizations, separation of duty is a new concept that continues to evolve. Database consolidation, regulatory compliance, and outsourcing are just a few of the drivers for increased separation of duty. Oracle Database Vault separation of duty strengthens security by separating security-related administration from day-to-day DBA operations. You can tailor your Database Vault separation of duty implementation to easily adapt to current and future business requirements. Small organizations, in particular, need flexibility as they attempt to increase their security profile with limited resources. Oracle Database Vault defines the following main responsibilities: Account management. Account management entails creating, modifying, and dropping user accounts. The Security administration. Security administration covers basic security tasks such as creating realms and command rules, setting security policies for database users' access, and authorizing database users for jobs they are allowed to perform. Security administrators also run security audit reports. The Optionally, you can consolidate the account management and security administrative responsibilities. Resource management. Resource management refers to managing the database system but not accessing business data. It includes the following operations: Backup operations require a predefined time to perform the backup using predefined tools. Tuning and monitoring operations require ongoing performance monitoring and analysis. Patching operations require temporary access only during the time the patching takes place For resource management, you should create a named account and a backup account for each of these tasks. Add these accounts as owners of the Data Dictionary realm. Use these accounts as the primary resource managers in the database. You should have separate accounts for database account management, database security administration, and additional named accounts for backup operations. Auditors check for separate database accounts for different responsibilities and being able to track the actions of each account. Less important is the number of users assigned to specific tasks. Remember that Oracle Database Vault audit events are protected and that the Database Vault reports show all attempted violations. Before separation of duty can be successful, you must understand who performs basic administration tasks in your environment and what these administration tasks are. Even if a single database administrator is responsible for managing both new database account provisioning and application patching, it is important to document and plan for each of these tasks.Using separate administration accounts for these types of tasks provides increased accountability and reduces associated risks. In midsize to large organizations, database administrators typically must perform common administration tasks but they do not need access to business data managed by the application. Creating a matrix for your separation of duty can help you plan your Database Vault deployment. As needed, you can include additional tasks and associated users to this list. This information should become part of the overall enterprise security documentation for your organization. Table D-1 shows an example of a separation of duty matrix. Table D-1 Example Separation of Duty Matrix X X X X X X EBS patching X X In some cases, system management tasks may require temporary access to data through specific tools and programs. When this happens, build provisions for this temporary or emergency access into the Oracle Database Vault rules and rule sets. You should document the following areas of the tasks your organization needs: The responsibilities of each administrative user The kind of access users need. For example, application owners should have data access and developers need access to development instances only. Who must manage the system without accessing business data (for example, users who perform backup, patching, tuning, and monitoring operations) The duties of each category of tasks (for example, the files that must be backed up, the applications that require patching, what exactly is monitored). Include the alternate user accounts for each of these tasks. The databases and applications that must be protected. This includes Oracle applications, partner applications, and custom applications. Who must be authorized to access business data, including the following: Application owners through middle tier processes Business users through an application interface Emergency "what if" scenarios, such as how to handle a security breach Reporting in a production environment, which should include the following: Who runs the reports Which reports must be run The frequency with which each report is run The users who must receive a copy of each report In addition to a separation of duty matrix, the creation of the following matrices: An Oracle Database Vault-specific matrix, which can cover the names and tasks of users who have been granted Database Vault roles An application protection matrix, which can cover the applications to be protected and the types of protections you have put in place. Table D-2 shows an example of protections Oracle created for PeopleSoft Applications. You can download the scripts to create these security policies from the following URL: Table D-2 Example Application Protection Maxtrix PeopleSoft Realm Owner Owner No Access No Access SELECT Command Rule Not Restricted Limit PSFTDB Rule Set No Access No Access CONNECT Command Rule PeopleSoftAccess Rule Set Not Restricted Not Restricted Not Restricted DROP TABLESPACE Command Rule Disabled Rule Set Disabled Rule Set Disabled Rule Set Disabled Rule Set This section contains: If you use the If your site holds application tables in the Limit the Oracle Database Vault prevents highly privileged database users from accessing sensitive data. In addition, if you are using Oracle Database itself, you can use transparent data encryption to prevent the most highly privileged operating system users from accessing sensitive data. Transparent data encryption enables you to hide individual table columns. (See Oracle Database Advanced Security Administrator's Guide for more information about transparent data encryption.) As a best practice, always carefully review and restrict direct access to the operating system. You should have personalized accounts access the operating system. These personalized accounts should, in the Linux or UNIX environments, login using Oracle Database Vault restricts access to application data from many privileged users and roles in the database. However, in some cases, Oracle Database Vaults trusts certain roles and privileges. Table D-3 lists the trusted roles and privileges that are created when you install Oracle Database Vault. Table D-3 Trusted Oracle Database Vault Roles and Privileges Open Role created during installation and used for creating new database accounts Open Role created during installation and used for managing realms, factors and command rules. This user cannot add himself or herself to realm authorizations, nor can users who have the Enabled Privilege created during Oracle Database installation. Required by some Oracle features. See "Managing SYSDBA Access" for guidelines on managing Enabled Privilege created during Oracle Database installation. Database startup and shutdown. Granted to Several accounts and roles have very powerful privileges in a default Oracle Database installation. You should limit these accounts and roles only to trusted individuals. Users who have root user access have full control over the system, including the following activities: Reading unencrypted files Moving and deleting any files Starting or stopping any program on the system Logging in as any user, including the user who owns the Oracle Database installation Oracle Database Vault does not provide protection against the operating system root access. Ensure that you grant root user privileges only to the appropriate people with the appropriate responsibility. Users who have access to a system as the Oracle software owner have control over the Oracle software, including the following activities: Disabling Oracle Database Vault in the given system Reading unencrypted database files Moving and deleting database files Starting or stopping Oracle programs in the system Oracle Database Vault does not provide protection against the operating system access of the Oracle software owner. Ensure that you grant Oracle software owner access only to the appropriate people with the appropriate responsibility. The By default, Oracle Database limits Follow these guidelines when running Oracle Database Vault in a production environment: Run a full test of your applications to ensure that the Database Vault policies you have created are working as expected Monitor the performance of your applications, and if necessary, tune your rule expressions Assign responsibilities to the appropriate production support and security groups, as follows: Assign security responsibilities to the database security administrator. Assign account management to the database account manager. Assign resource management tasks to database administrators. Back up your Database Vault API scripts to a secure server. Follow these configuration and security guidelines: Security Considerations for the UTL_FILE and DBMS_FILE_TRANSFER Packages Security Considerations for the CREATE EXTERNAL JOB Privilege Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges The The To secure the Revoke the Create command rules to control the Alternatively, Example D-1 and Example D-2 show how you can use the Oracle Database Vault Example D-1 Creating a Command Rule to Deny Access to CREATE DATABASE LINK When a valid user must use the Example D-2 Creating a Command Rule to Enable Access to CREATE DATABASE LINK Similarly, Example D-3 shows command rules that disable and enable access to Example D-3 Command Rules to Disable and Enable Access to CREATE DIRECTORY In Oracle Database Vault, the In SQL*Plus, you can check the contents of the recycle bin as follows: To purge the contents of the recycle bin, use the To disable the recycle bin: Log in to SQL*Plus as Ensure that the recycle bin is disabled. If the recycle bin is on, then disable it. Restart Oracle Database. The See "Scheduling Database Jobs in an Oracle Database Vault Environment" for more information. The In this release of Oracle Database Vault, the role Ensure that this change does not affect your applications. Be aware that trace and debug commands have the potential to show Oracle database memory information. Oracle Database Vault does not protect against these commands. To help secure the Oracle database memory information, Oracle recommends that you strictly control access to the Oracle also recommends that you add rules to the existing command rule for Example D-4 shows how you can create this type of rule. This rule prevent users with Example D-4 Adding Rules to the Existing ALTER SYSTEM Command Rule Alternatively, you can use Oracle Database Vault Administrator to create and add this rule to the rule set. See "Creating a Rule to Add to a Rule Set" for more information. This chapter contains: A command rule is a rule that you create to protect A command rule has the following attributes, in addition to associating a command rule to a command: SQL statement the command rule protects Owner of the object the command rule affects Database object the command rule affects Whether the command rule is enabled An associated rule set For more information about SQL statements and operations, refer to Oracle Database SQL Language Reference. See also "SQL Statements That Can Be Protected by Command Rules". Command rules can be categorized as follows: Command rules that have a system-wide scope. With this type, you can only create one command rule for each database instance. Examples are command rules for the Command rules that are schema specific. An example is creating a command rule for the Command rules that are object specific. An example is creating a command rule for the When a user executes a statement affected by a command rule, Oracle Database Vault checks the realm authorization first. If it finds no realm violation and if the associated command rules are enabled, then Database Vault evaluates the associated rule sets. If all the rule sets evaluate to TRUE, then the statement is authorized for further processing. If any of the rule sets evaluate to FALSE, then the statement is not authorized and a command rule violation is created. Chapter 5, "Configuring Rule Sets," describes rule sets in detail. You can define a command rule that uses factors for the For example, you can configure a command rule that allows DDL statements such as You can run reports on the command rules that you create in Oracle Database Vault. See "Related Reports and Data Dictionary View" for more information. This chapter explains how to configure command rules by using Oracle Database Vault Administrator. To configure command rules by using the PL/SQL interfaces and packages provided by Oracle Database Vault, refer to the following chapters: Table 6-1 lists default command rules that Oracle Database Vault provides. Table 6-1 Default Command Rules - Can Maintain Accounts/Profiles - Allow Fine Grained Control of System Parameters - Can Maintain Own Account - Can Maintain Accounts/Profiles - Can Maintain Accounts/Profiles - Can Maintain Accounts/Profiles - Can Maintain Accounts/Profiles The following set of command rules helps you to achieve separation of duty for user management: To grant a user the ability to use these commands, you can grant the user the role that the rule set checks. For example, the You can protect the following SQL statements by using command rules: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, under Database Vault Feature Administration, click Command Rules. In the Command Rules page: To create a new command rule, click Create. To edit an existing command rule, select it from the list and then click Edit. In the Create (or Edit) Command Rule page, enter the following settings, and then click OK. General Enter the following settings: Command: Select the SQL statement or operation for which you want to create a command rule. This attribute is mandatory. Status: Select either Enabled or Disabled to enable or disable the command rule during run time. The default is Enabled. This attribute is mandatory. Applicability Enter the following settings: Object Owner: From the list, select the owner of the object the command rule affects. You can use wildcard character Note that the Object Name: Enter the name of the database object that the command rule affects, or specify % to select all database objects. However, you cannot use wildcard characters with text (for example, You can run Oracle Database Vault reports on objects that the command rule affects. See the "Related Reports and Data Dictionary View" for more information. Rule Set From the list, select the rule set that you want to associate with the command rule. This attribute is mandatory. If the rule set evaluates to true, then the SQL statement succeeds. If it evaluates to false, the statement fails, and then Oracle Database Vault raises a command rule violation. (You can track rule violations by using the Command Rule Configuration Issues Report, discussed in Chapter 17.) Any auditing and custom event handling associated with the rule set occurs as a part of the command rule processing. See Chapter 5, "Configuring Rule Sets," for more information about rule sets. Before you delete a command rule, you can locate the various references to it by querying the command rule-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information. In the Oracle Database Vault Administration page, select Command Rules. In the Command Rules page, select the command rule that you want to remove. Click Remove. In the Confirmation page, click Yes. "How Realms Work" describes what happens when a database account issues a The following actions take place when Oracle Database Vault queries all the command rules that need to be applied. For You can associate rule sets with both command rules and realm authorizations. Oracle Database Vault evaluates the realm authorization rule set first, and then it evaluates the rule sets that apply to the command type being evaluated. For each command rule that applies, Oracle Database Vault evaluates its associated rule set. If the associated rule set of any of the applicable command rules returns false or errors, Oracle Database Vault prevents the command from executing. Otherwise, the command is authorized for further processing. The configuration of the rule set with respect to auditing and event handlers dictates the auditing or custom processing that occurs. Command rules override object privileges. You can disable (or set the Disabled setting for) either a command or a rule set of a command. If a command rule is disabled, then the command rule is not allowed to run regardless of its associated rule set. That is, the command rule itself is disabled. However, if you disable a rule set of a command rule, then the rule set is not checked. In that case, the command rule is allowed to run without any condition. If the command rule has been set to the Disabled setting, then you are prevented from querying the table even though you have the This section contains: See Also: In this tutorial, you create a simple command rule that disables and then enables the ability of user Log in to SQL*Plus as user If the Replace As user Now drop the table. At this stage, user Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Oracle Database Vault Administrator Administration page, click Command Rules. The Command Rules page appears. Click Create. The Create Command Rule page appears. Enter the following settings: Command list: Select CREATE TABLE Status: Set to Enabled so that the command rule is active. Object Owner: Select SCOTT. Object Name: Set to % so that it applies to all objects in the Rule Set: Select Disabled so that user Click OK. Do not exit Database Vault Administrator Command rules take effect immediately. Right away, user In SQL*Plus, ensure that you are logged on as user Try to create a table. The following output should appear: As you can see, In Oracle Database Vault Administrator, do the following: In the Command Rules page, select the CREATE TABLE command rule and then click Edit. In the Edit Command Rule page, select Enabled from the Rule Set list. Click OK. In SQL*Plus, as user Now that the CREATE TABLE command rule is set to Enabled, user In Oracle Database Vault Administrator, remove the CREATE TABLE command rule as follows: Return to the Command Rules page. Select the CREATE TABLE command rule and then click Remove. In the Confirmation page, click Yes. Log in to SQL*Plus as user If you no longer need the Follow these guidelines to design command rules: Create finer-grained command rules, because they are far easier to maintain. For example, if you want to prevent When designing rules for the If the account has been locked out, you can disable Oracle Database Vault, correct the rule that is causing the lock-out problem, and then reenable Oracle Database Vault. Even when Oracle Database Vault is disabled, you still can use Database Vault Administrator and the Database Vault PL/SQL packages. See Appendix B, "Disabling and Enabling Oracle Database Vault," for instructions on disabling and reenabling Database Vault. Sometimes you must temporarily relax an enabled command rule for an administrative task. Rather than disabling the command rule, have the Security Manager (the account with the When designing command rules, be careful to consider automated processes such as backup where these procedures may be inadvertently disabled. You can account for these tasks by creating rules that allow the command when a series of Oracle Database Vault factors is known to be true (for example, the program being used), and the account being used or the computer or network on which the client program is running. The performance of a command rule depends on the complexity of the rules in the rule set associated with the command rule. For example, suppose a rule set invokes a PL/SQL function that takes 5 seconds to run. In this case, a command rule that uses that rule set would take 5 seconds to grant access for the command statement to run. You can check the system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Database Control, which is installed by default with Oracle Database), Table 6-2 lists Oracle Database Vault reports that are useful for analyzing command rules. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports. Table 6-2 Reports Related to Command Rules Lists audit records generated by command rule processing operations "Command Rule Configuration Issues Report" Tracks rule violations, in addition to other configuration issues the command rule may have Lists object privileges that the command rule affects Lists objects that the command rule affects "Rule Set Configuration Issues Report" Lists rules sets that have no rules defined or enabled, which may affect the command rules that use them You can use the This chapter contains: The This section contains: Table 14-1 summarizes constant (that is, fields) descriptions for the Table 14-1 DVSYS.DBMS_MACUTL Listing of Constants Example 14-1 shows how to use the Example 14-1 Creating a Realm Using DVSYS.DBMS_MACUTL Constants Example 14-2 shows how to use several Example 14-2 Creating a Rule Set Using DVSYS.DBMS_MACUTL Constants Example 14-3 shows how to use constants when creating a factor. Example 14-3 Creating a Factor Using DVSYS.DBMS_MACUTL Constants Table 14-2 lists the procedures and functions in the Table 14-2 DVSYS.DBMS_MACUTL Utility Functions CHECK_DVSYS_DML_ALLOWED Procedure Verifies that public-packages are not being bypassed by users updating the Oracle Database Vault configuration Returns the seconds in Oracle SS format (00-59). Useful for rule expressions based on time data Returns the minute in Oracle MI format (00–59). Useful for rule expressions based on time data Returns the month in Oracle HH24 format (00–23). Useful for rule expressions based on time data Returns the day in Oracle DD format (01–31). Useful for rule expressions based on time data Returns the month in Oracle MM format (01–12). Useful for rule expressions based on time data Returns the year in Oracle YYYY format (0001–9999). Useful for rule expressions based on time data Checks whether the character is alphabetic Checks whether the character is numeric Determines whether a user is authorized to manage the Oracle Database Vault configuration Returns an indicator regarding whether Oracle Label Security is installed IS_OLS_INSTALLED_VARCHAR Function Returns an indicator regarding whether Oracle Label Security is installed Checks whether a user has a role privilege, directly or indirectly (through another role) USER_HAS_ROLE_VARCHAR Function Checks whether a user has a role privilege, directly or indirectly (through another role) USER_HAS_SYSTEM_PRIVILEGE Function Checks whether a user has a system privilege, directly or indirectly (through a role) The Syntax Parameter Table 14-3 CHECK_DVSYS_DML_ALLOWED Parameter User performing the operation. To find existing users in the current database instance, query the following views: Example User User The Syntax Parameters Table 14-4 GET_CODE_VALUE Parameters Code group (for example, To find available code groups in the current database instance, query the ID of the code. This ID is listed when you run the Example The Syntax Parameter Table 14-5 GET_SECOND Parameter Date in SS format (for example, If you do not specify a date, then Oracle Database Vault uses the Oracle Database Example This example, which uses a fixed date and time, returns the following: The Syntax Parameter Table 14-6 GET_MINUTE Parameter Date in MI format (for example, If you do not specify a date, then Oracle Database Vault uses the Oracle Database Example Output similar to the following appears: The Syntax Parameter Table 14-7 GET_HOUR Parameter Date in HH24 format (for example, If you do not specify a date, then Oracle Database Vault uses the Oracle Database Example Output similar to the following appears: The Syntax Parameter Table 14-8 GET_DAY Parameter Date in DD format (for example, If you do not specify a date, then Oracle Database Vault uses the Oracle Database Example Output similar to the following appears: The Syntax Parameter Table 14-9 GET_MONTH Parameter Date in MM format (for example, If you do not specify a date, then Oracle Database Vault uses the Oracle Database Example Output similar to the following appears: The Syntax Parameter Table 14-10 GET_YEAR Parameter Date in YYYY format (for example, If you do not specify a date, then Oracle Database Vault uses the Example The Syntax Parameter Example The Syntax Parameter Example The Syntax Parameter Table 14-13 IS_DVSYS_OWNER Parameter User to check. To find existing users, query the following views: Example The Syntax Parameters None. Example The Syntax Parameters None. Example See "IS_OLS_INSTALLED Function" for an example. The Syntax Parameters Table 14-14 USER_HAS_ROLE Parameters Role privilege to check. To find existing roles, query the following views: User to check. To find existing users, query the following views: Example The Syntax Parameters Table 14-15 USER_HAS_ROLE_VARCHAR Parameters Role to check. To find existing roles, query the following views: User to check. To find existing users, query the following views: The Syntax Parameters Table 14-16 USER_HAS_SYSTEM_PRIVILEGE Parameters System privilege to check for. To find privileges for a database account excluding To find all privileges for a database account, use User to check. To find existing users, query the following views: Example This chapter contains: A realm is a functional grouping of database schemas and roles that must be secured for a given application. Think of a realm as zone of protection for your database objects. A schema is a logical collection of database objects such as tables, views, and packages, and a role is a collection of privileges. By classifying schemas and roles into functional groups, you can control the ability of users to use system privileges against these groups and prevent unauthorized data access by the database administrator or other powerful users with system privileges. Oracle Database Vault does not replace the discretionary access control model in the existing Oracle database. It functions as a layer on top of this model for both realms and command rules. After you create a realm, you can register a set of schema objects or roles (secured objects) for realm protection and authorize a set of users or roles to access the secured objects. For example, after you install Oracle Database Vault, you can create a realm to protect all existing database schemas that are used in an accounting department. The realm prohibits any user who is not authorized to the realm to use system privileges to access the secured accounting data. You can run reports on realms that you create in Oracle Database Vault. See "Related Reports and Data Dictionary Views" for more information. This chapter explains how to configure realms by using Oracle Database Vault Administrator. To configure realms by using the PL/SQL interfaces and packages provided by Oracle Database Vault, refer to the following chapters: Oracle Database Vault provides the following default realms: Database Vault Account Management: Defines the realm for the administrators who manage and create database accounts and database profiles. Oracle Data Dictionary: Defines the realm for the following Oracle Catalog schemas. This realm also controls the ability to grant system privileges and database administrator roles. Oracle Database Vault: Defines the realm for the Oracle Database Vault schemas ( Oracle Enterprise Manager: Defines the realm for Oracle Enterprise Manager accounts ( In general, to enable realm protection, you first create the realm itself, and then you edit the realm to include realm-secured objects, roles, and authorizations. "Guidelines for Designing Realms" provides advice on creating realms. To create a realm: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, under Database Vault Feature Administration, click Realms. In the Realms page, click Create. In the Create Realm page, enter the following settings: Under General: Name: Enter a name for the realm. It can contain up to 90 characters in mixed-case. This attribute is mandatory. Oracle suggests that you use the name of the protected application as the realm name (for example, Description: Enter a brief description of the realm. The description can contain up to 1024 characters in mixed-case. This attribute is optional. You may want to include a description the business objective of the given application protection and document all other security policies that compliment the realm's protection. Also document who is authorized to the realm, for what purpose, and any possible emergency authorizations. Status: Select either Enabled or Disabled to enable or disable the realm. A realm is enabled by default. This attribute is mandatory. Under Audit Options, select one of the following: Audit Disabled: Does not create an audit record. Audit On Failure: Default. Creates an audit record when a realm violation occurs (for example, when an unauthorized user tries to modify an object that is protected by the realm). Audit On Success or Failure: Creates an audit record for any activity that occurs in the realm, including both authorized and unauthorized activities. For additional audit options, see "CREATE_REALM Procedure". Oracle Database Vault writes the audit trail to the Click OK. The Realms Summary page appears, listing the new realm that you created. After you create a new realm, you are ready to add schema and database objects to the realm for realm protection, and to authorize users and roles to access the realm. To do so, you edit the new realm and then add its objects and its authorized users. In the Oracle Database Vault Administration page, select Realms. In the Realm page, select the realm that you want to edit. Click Edit. Modify the realm as necessary, and then click OK. See Also: "Creating a Realm" to modify the settings created for a new realm "Creating Realm-Secured Objects" to add or modify realm secured objects "Defining Realm Authorization" to add or modify the realm authorizations Realm-secured objects define the territory that a realm protects. The realm territory is a set of schema and database objects and roles. You can create the following types of protections: Objects from multiple database accounts or schemas can be under the same realm. One object can belong to multiple realms. If an object belongs to multiple realms, then Oracle Database Vault checks the realms for permissions. For You can manage the objects secured by a realm from the Edit Realm page, which lets you create, edit, and delete realm secured objects. To create a realm secured object: In the Oracle Database Vault Administration page, select Realms. In the Realms page, select the realm you want, and then select Edit. In the Edit Realm page, under Realm Secured Objects, do one of the following: To create a new realm-secured object, select Create. To modify an existing object, select it from the list and then select Edit. In the Create Realm Secured Object page, enter the following settings: Object Owner: From the list, select the name of the database schema owner. This attribute is mandatory. If you are creating a realm around the Object Type: From the list, select the object type of the database object, such as By default, the Object Type box contains the % wildcard character to include all object types for the specified Object Owner. However, it does not include roles, which do not have specific schema owners in the database and must be specified explicitly. Object Name: Enter the name of the object in the database that the realm must protect, or enter By default, the Object Name field contains the % wildcard character to encompass the entire schema specified for Object Type and Object Owner. Note that the % wildcard character applies to objects that do not yet exist and currently existing objects. Note also that the % wildcard character does not apply to roles. If you want to include multiple roles, you must specify each role separately. Click OK. For example, to secure the Object Owner: Object Type: Object Name: Editing a Realm-Secured Object To edit a realm-secured object: Select the object under Realm Secured Objects in the Edit Realm page. Click Edit. In the Edit Realm Secured Object page, edit the attributes as required. Click OK. Deleting a Realm-Secured Object To delete a realm-secured object: Select the object under Realm Secured Objects in the Edit Realm page. Click Remove. A confirmation page is displayed. Click Yes. This dissociates the object from the realm and unsecures it. (The regular database protections still apply.) However, it does not remove the object from the database. Realm authorizations establish the set of database accounts and roles that manage or access objects protected in realms. A realm authorization can be an account or role that is authorized to use its system privileges in the following situations: When the user must create or access realm-secured objects When a user must grant or revoke realm-secured roles A user who has been granted realm authorization as either a realm owner or a realm participant can use its system privileges to access secured objects in the realm. Note the following: The authorization that you set up here does not affect regular users who have normal direct object privileges to the database objects that are protected by realms. Realm owners cannot add other users to their realms as owners or participants. Only users who have the A realm owner, but not a realm participant, can grant or revoke realm secured database roles to anyone. A user can be granted either as a realm owner or a realm participant, but not both. However, you can update the authorization options of a realm authorization. Use the Edit Realm page to manage realm authorizations. You can create, edit, and remove realm authorizations. To track configuration information for the authorization of a realm, see "Realm Authorization Configuration Issues Report". To create a realm authorization: In the Oracle Database Vault Administration page, select Realms. In the Realms page, select the realm you want, and then select Edit. In the Edit Realm page, under Realm Authorizations, do one of the following: To create a new realm authorization, select Create. To modify an existing realm authorization, select it from the list and then select Edit. Click Create under Realm Authorizations in the Edit Realm page. In the Create Realm Authorization page, enter the following settings: Grantee: From the list, select the Oracle database account or role to whom you want to grant the realm authorization. This attribute is mandatory. This list shows all accounts and roles in the system, not just accounts with system privileges. You cannot select yourself (that is, the user logged in) or any account that has been granted the Authorization Type: Select either of the following. This attribute is mandatory. Participant: Default. This account or role provides system or direct privileges to access, manipulate, and create objects protected by the realm, provided these rights have been granted using the standard Oracle Database privilege grant process. A realm can have multiple participants. Owner: This account or role has the same privileges as the realm participant, plus the authorization to grant or revoke realm-secured database roles. The realm owner can grant privileges on realm-protected objects to other users. A realm can have multiple owners. Authorization Rule Set: Select from the available rule sets that have been created for your site. You can select only one rule set, but the rule set can have multiple rules. See "Creating a Rule to Add to a Rule Set" for more information about defining rules to govern the realm authorization. Any auditing and custom event handling associated with the rule set occurs as part of the realm authorization processing. Click OK. Editing a Realm Authorization To edit a realm authorization: Select the realm authorization under Realm Authorizations in the Edit Realm page. Click Edit. The Edit Realm Authorization page is displayed. Edit the attributes as required. Click OK. Deleting a Realm Authorization To delete a realm authorization: Select the realm authorization under Realm Authorizations in the Edit Realm page. Click Remove. A confirmation page is displayed. Click Yes. By default, when you create a realm, it is enabled. You can disable a realm (for example, for system maintenance such as patch updates), and then enable it again afterward. To disable or enable a realm: In the Oracle Database Vault Administration page, select Realms. In the Realms page, select the realm you want to disable or enable, and then select Edit. In the Edit Realm page, under Status in the General section, select either Disabled or Enabled. Click OK. Before you delete a realm, you can locate the various references to it by querying the realm-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information. In the Oracle Database Vault Administration page, select Realms. In the Realms page, select the realm you want to delete, and then select Remove. In the Confirmation page, click Yes. Oracle Database Vault deletes the configuration for a realm (header, secure objects, and authorizations). It does not delete the rule sets within the realm. When a database account that has the appropriate privileges issues a SQL statement (that is, DDL, DML, Is the database account using a system privilege to execute the SQL statement? If yes, then go to Step 2. If no, then go to Step 6. If the session has object privileges on the object in question for Remember that if the Does the SQL statement affect objects secured by a realm? If yes, then go to Step 3. If no, then realms do not affect the SQL statement; go to Step 6. If the object affected by the command is not secured in any realms, then realms do not affect the SQL statement being attempted. Is the database account a realm owner or realm participant? If yes, and if the command is a Is the realm authorization for the database account conditionally based on a rule set? Does the rule set evaluate to true? If yes, then go to Step 6. If no, then there is a realm violation, so the SQL statement is not allowed to succeed. Does a command rule prevent the command from executing? If yes, then there is a command rule violation and the SQL statement fails. If no, there is no realm or command rule violation, so the command succeeds. For example, the In addition, because a session is authorized in a realm, it does not mean the account has full control on objects protected by the realm. Realm authorization does not implicitly grant extra privileges to the account. The account still must have system privileges or object privileges to access the objects. For example, an account or role may have the Note the following: Protecting a table in a realm does not protect the view by default. Any view that must be protected should be added to the realm regardless of whether the view was created before or after the table was added to the realm. For invoker's right procedures that access realm protected objects, the invoker of the procedure must be authorized to the realm. The execution of PL/SQL procedures that are owned by Be aware that realm protection does not protect a table if access to the table has been granted to Realms protect data from access through system privileges; realms do not give additional privileges to its owner or participants. The realm authorization provides a run-time mechanism to check logically if a user's command is allowed to access objects specified in the command and to proceed with its execution. System privileges are sweeping database privileges such as Example 4-1 shows what happens when an unauthorized user who has the The following output should appear As you can see, the attempt by the unauthorized user fails. Unauthorized use of system privileges such as Example 4-2 shows what happens when an unauthorized database account tries to use his Example 4-2 Unauthorized User Trying to Use the DELETE ANY TABLE Privilege The following output should appear: Realms do not affect direct privileges on objects. For example, a user granted delete privileges to the Example 4-3 shows how an authorized user can perform standard tasks allowed within the realm. There are situations in which you may want to protect an object by a realm, but still enable access to objects that are part of this realm-protected object. For example, suppose you create a realm around a specific table. However, you want users to be able to create an index on this table. You can accomplish this as follows, depending on the following scenarios. The user does not have the CREATE ANY INDEX privilege. As the realm owner of the table, grant the The user has the CREATE ANY INDEX privilege. In this case, create another realm and make all index types as the secured objects and grant that user participant authorization to the realm. (Remember that having the You want all of your database administrators to be able to create an index and they have the CREATE ANY INDEX privilege. In your data protection realm, specify all object types to be protected except the index types. This permits all of your administrators to create indexes for the protected table. Figure 4-1 illustrates how data within a realm is protected. In this scenario, two users, each in charge of a different realm, have the same system privileges. The owner of a realm can be either a database account or a database role. As such, each of the two roles, Further, only a realm owner, such as Figure 4-1 How Authorizations Work for Realms and Realm Owners See Also: Realms have no effect on factors, identities, or rule sets. They have an effect on command rules, in a sense, in that Oracle Database Vault evaluates the realm authorization first when processing SQL statements. "How Realms Work" explains the steps that Oracle Database Vault takes to process SQL statements that affect objects in a realm. "How Command Rules Work" describes how command rules are processed. Follow these guidelines when designing realms: Create realms based on the schemas and roles that form a database application. Define database roles with the minimum and specific roles and system privileges required to maintain the application objects and grant the role to named accounts. You then can add the role as an authorized member of the realm. For object-level privileges on objects protected by the realm and required by an application, create a role and grant these minimum and specific object-level privileges to the role, and then grant named accounts this role. In most cases, these types of roles do not need to be authorized in the realm unless A database object can belong to multiple realms and an account or role can be authorized in multiple realms. To provide limited access to a subset of a database schema (for example, just the If you want to add a role to a realm as a grantee, create a realm to protect the role. Doing so prevents users who have been granted the If you want to add the Be mindful of the privileges currently allowed to a role that you plan to add as a realm authorization. Realm authorization of a role can be accidentally granted and not readily apparent if an account such as Sometimes you must temporarily relax realm protections for an administrative task. Rather than disabling the realm, have the Security Manager ( If you want to grant DDL and DML operations on realm-protected objects do not have a measurable effect on Oracle Database. Oracle recommends that you create the realm around the entire schema, and then authorize specific users to perform only specific operations related to their assigned tasks. For finer-grained control, you can define realms around individual tables and authorize users to perform certain operations on them, and also have a realm around the entire schema to protect the entire application. Be aware, however, that this type of configuration may slow performance, but it does enable you to grant realm authorization to some of the objects in a schema. Auditing affects performance. To achieve the best performance, Oracle recommends that you use fine-grained auditing rather than auditing all operations. You can check the system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Database Control, which is installed by default with Oracle Database), Table 4-1 lists Oracle Database Vault reports that are useful for analyzing realms. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports. Table 4-1 Reports Related to Realms Audits records generated by the realm protection and realm authorization operations "Realm Authorization Configuration Issues Report" Lists authorization configuration information, such as incomplete or disabled rule sets, or nonexistent grantees or owners that may affect the realm "Rule Set Configuration Issues Report" Lists rule sets that do not have rules defined or enabled, which may affect the realms that use them Lists object privileges that the realm affects "Privilege Management - Summary Reports" Provides information about grantees and owners for a realm Lists objects that the command rule affects Table 4-2 lists data dictionary views that provide information about existing realms. Table 4-2 Data Dictionary Views Used for Realms Lists the realms created in the current database instance. lists the authorization of a named database user account or database role ( Lists the database schemas, or subsets of schemas with specific database objects contained therein, that are secured by the realms This section contains: Oracle Database Vault uses audit events to track the following activities: Realm Audit. You can audit both successful and failed actions, based on the auditing option that you set when you created the realm. The exception to this is actions performed by the schema owner. Rule Set Audit. Audits the rule set processing results. You can audit both successful and failed processing. Realm authorizations can be managed using rule sets. You can audit the rule set processing results. Factor assignments and secure application roles audits can be managed using a rule set. Factor Audit. You can audit both successful and failed factor processing. For failed factor processing, you can audit on all or any of the following events: Retrieval Error, Retrieval Null, Validation Error, Validation False, Trust Level Null, or Trust Level Less Than Zero. Oracle Label Security Session Initialization Failed. Audits instances where the Oracle Label Security session fails to initialize. Oracle Label Security Attempt to Upgrade Session Label Failed. Audits instances where the Oracle Label Security component prevents a session from setting a label that exceeds the maximum session label. See Also: "Audit Options" (for factors) "Audit Options" (for rule sets) Chapter 17, "Oracle Database Vault Reports," for information about viewing the audit reports The Oracle Database Vault audit event records are stored in the Users who have been granted the Note: Table A-1 describes the format of the audit trail, which you must understand if you plan to create custom reports that use the Table A-1 Oracle Database Vault Audit Trail Format Numeric identifier for the audit record Operating system login user name of the user whose actions were audited Name of the database user whose actions were audited Client computer name Identifier for the user's terminal Date and time of creation of the audit trail entry (in the local database session time zone) Creator of the object affected by the action, always Name of the object affected by the action. Expected values are: Numeric action type code. The corresponding name of the action type is in the Name of the action type corresponding to the numeric code in the The unique identifier of the record in the table specified under The unique name or natural key of the record in the table specified under The SQL text of the command procedure that was executed that resulted in the audit event being triggered The labels for all audit options specified in the record that resulted in the audit event being triggered. For example, a factor set operation that is supposed to audit on get failure and get The unique identifier of the rule set that was executing and caused the audit event to trigger The unique name of the rule set that was executing and caused the audit event to trigger Not used Not used An XML document that contains all of the factor identifiers for the current session at the point when the audit event was triggered Text comment on the audit trail entry, providing more information about the statement audited Numeric identifier for each Oracle session Same as the value in the Numeric identifier for the statement invoked that caused the audit event to be generated. This is empty for most Oracle Database Vault events. Oracle error code generated by the action. The error code for a statement or procedure invoked that caused the audit event to be generated. This is empty for most Oracle Database Vault events. Time stamp of creation of the audit trail entry (time stamp of user login for entries) in UTC (Coordinated Universal Time) time zone Proxy session serial number, if an enterprise user has logged in through the proxy mechanism Global user identifier for the user, if the user has logged in as an enterprise user Instance number as specified by the Operating system process identifier of the Oracle process Database login user name of the user whose actions were audited Date on which the action occurred, based on the Same as Same as You can create an archive of the Oracle Database Vault audit trail by exporting the To archive and purge the Oracle Database Vault audit trail: Ensure that you or the user performing the export operation has been granted the appropriate authorization. See "Using Oracle Data Pump in an Oracle Database Vault Environment" for more information. Disable Oracle Database Vault. At the operating system command prompt, create a directory for the Oracle Database Vault audit trail (for example, in You may want to keep this directory in the same location as the operating system audit trail directories for Oracle Database, which by default is in the Output similar to the following appears: In SQL*Plus, create a directory object in which to generate the Oracle Database Vault audit trail. To do so, connect as For example: Enclose the directory path in single quotation marks, not double quotation marks. In SQL*Plus, grant read and write privileges on the directory object to user For example: At the operating system command prompt, enter a command similar to the following to export the In this specification: In SQL*Plus, purge the Oracle Database Vault audit trail table, now that you have archived it. For example, if you archived all audit trail records that are less than the To completely purge the audit trail and remove the extents allocated to the audit trail table, enter the following statement: Exit SQL*Plus. Re-enable Oracle Database Vault. When you install Oracle Database Vault, it creates several If the Table A-2 lists the Table A-2 Audit Policy Settings Oracle Database Vault Adds to Oracle Database System Audit Settings/System Privilege Usage System Audit Settings/Object Management System Audit Settings/Intrusive Commands System Audit Settings/Administration Commands System Audit Settings/Audit Commands System Audit Settings/Access Control User Audit Settings for User Audit Settings for See Table 11-2, "Database Accounts Used by Oracle Database Vault" for more information about these accounts. See also these sections for detailed information on the This appendix contains: You can monitor your Oracle Database Vault database instance for server and background process events by checking the database instance trace files. Trace files reveal events such as the logic that the Oracle Database Vault security enforcement engine executes, and internal errors, block corruption errors, deadlock errors, administrative actions that may have occurred, values of parameters that had nondefault settings when the database instance started, and other information. Be careful about enabling trace files, however. Doing so can increase the overhead of the database instance operation, which could decrease performance. Contact Oracle Support before you decide to enable tracing. The To enable tracing, log in to SQL*Plus as a user who has the For example, suppose you have an account that is trying to use a statement that is protected by a command rule, but the statement is not working as expected. You can diagnose the enforcement logic for this account by granting it the You can disable tracing by issuing the following statement: For more information about how to manage trace files, see Oracle Database Administrator's Guide. Follow these general tips for diagnosing problems in realms, factors, and rule sets: For realm protections, verify that a user has the underlying system or object privileges (granted directly or through a role) that might affect the command. If a realm authorization is not working, verify that the account roles are set correctly. For PL/SQL expressions used in factors and rule sets, grant the Use the auditing reports to diagnose problems in general. See "Oracle Database Vault Auditing Reports" for more information. If you suspect problems with the configuration of realms, command rules, factors, rule sets, or secure application roles, you can run the appropriate configuration report. See the following sections for more information: To run these reports, see "How to Run Oracle Database Vault Reports". See Also: You can check for security violations, such as realm or command rule violations. This feature displays data such as the user name of the person committing the violation, the action they committed, and a time stamp of the activity. Before you can view these events, you must ensure that the To check for security violations: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, click Monitor. At the top of the Monitor page, set a period for the monitoring action by selecting from the Show Records For list and clicking Go. This section of the Monitor page also indicates the last time the data on the page was refreshed. In the Monitor page, click Security Violation Attempts. A table appears, listing security policy changes. You can view structural changes to the database or database schema objects. This feature also audits statements such as Before you can view these events, you must ensure that the Follow these steps: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, click Monitor. At the top of the Monitor page, set a period for the monitoring action by selecting from the Show Records For list and clicking Go. This section of the Monitor page also indicates the last time the data on the page was refreshed. In the Monitor page, click Database Configuration and Structural Changes. A table similar to the following appears: This section contains: You can check the number of policy changes for the categories in the following list. These categories reflect changes to the database security policy (that is, its configuration) in any given environment. If something changes that is security related, you can use the chart and tables to drill down to find unexpected changes that should be investigated. Before you can view these events, you must ensure that the Database Vault policy: Shows changes made through the Oracle Database Vault administrative packages or user interface, indicating Oracle Database Vault configuration or policy changes. Label Security policy: Shows changes made through the Oracle Database Vault administrative packages or user interface, indicating Oracle Label Security policy or privilege changes. Audit Policy: Shows changes to the database audit policy coming from Privilege Grants: Shows changes to system or object privilege Privilege Revokes: Shows changes to system or object privilege Database Account: Shows changes to Database Role: Shows changes to To monitor security policy changes by category: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log on. In the Administration page, click Monitor. At the top of the Monitor page, set a period for the monitoring action by selecting from the Show Records For list and clicking Go. This section of the Monitor page also indicates the last time the data on the page was refreshed. In the Monitor page, check the graph under Security Policy Changes by Category. A graph similar to the following appears, which shows the number of security policy changes based on the following categories: Oracle Database Vault policy, Oracle Label Security policy, audit policy, privilege grants and revokes, database accounts, and database roles. You can check the details of security policy changes, such the user who made the change, the action that occurred, the time stamp of the change, and so on. Before you can view these events, you must ensure that the To monitor security policy changes by detail: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, click Monitor. At the top of the Monitor page, set a period for the monitoring action by selecting from the Show Records For list and clicking Go. This section of the page also indicates the last time the data on the page was refreshed. In the Monitor page, click Security Policy Changes by Detail. A table appears, listing the details for security policy changes. Copyright © 1994-2012, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065. This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications. This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services. If this document is in prerelease status: This documentation is in prerelease status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation. This chapter contains: You can modify your applications to use the procedures within the Chapter 8, "Configuring Secure Application Roles for Oracle Database Vault," describes secure application roles in detail. See also Chapter 14, "Using the DVSYS.DBMS_MACUTL Package," for a set of general-purpose utility procedures that you can use with the secure application role procedures. Table 13-1 lists the Table 13-1 DVSYS.DBMS_MACSEC_ROLES Oracle Label Security Configuration Procedures Checks whether the user invoking the method is authorized to use the specified Oracle Database Vault secure application role. Returns a Issues the The Syntax Parameters Table 13-2 CAN_SET_ROLE Parameter Role name. To find existing secure application roles in the current database instance, query the Example The Syntax Parameters Table 13-3 SET_ROLE Parameter Role names. You can enter multiple roles, including secure application roles and regular roles. To find existing secure application roles in the current database instance, query the To find all of the existing roles in the database, query the Example You can enter the name of the role in any case (for example, This chapter contains: A factor is a named variable or attribute, such as a user location, database IP address, or session user, that Oracle Database Vault can recognize. You can use factors for activities such as authorizing database accounts to connect to the database or creating filtering logic to restrict the visibility and manageability of data. Oracle Database Vault provides a selection of factors that lets you set controls on such components as the domain for your site, IP addresses, databases, and so on. "Default Factors" describes the default factors in detail. You also can create custom factors, using your own PL/SQL retrieval methods. You can use factors in combination with rules in rule sets. The Factors have values (identities) and are further categorized by their factor types. "Factor Identification" explains more about factor identities. See "Factor Type" under "General" for information about factor types. You also can integrate factors with Oracle Label Security labels. "Integrating Oracle Database Vault with Oracle Label Security" explains how. See "Tutorial: Integrating Oracle Database Vault with Oracle Label Security" for more information. You can run reports on the factors that you create in Oracle Database Vault. See "Related Reports and Data Dictionary Views" for more information. This chapter explains how to configure factors by using Oracle Database Vault Administrator. To configure factors by using the PL/SQL packages and interfaces provided by Oracle Database Vault, refer to the following chapters: Oracle Database Vault provides a set of default factors. For each of these factors, there is an associated function that retrieves the value of the factor. See "Oracle Database Vault PL/SQL Factor Functions" for a listing of these functions. You can create custom factors by using your own PL/SQL retrieval methods. A useful PL/SQL function you can use (which is used for many of the default factors) is the See Oracle Database SQL Language Reference for more information about the You can use the default factors in your own security configurations. If you do not need them, you can remove them. (That is, they are not needed for internal use by Oracle Database Vault.) The default factors are as follows: Authentication_Method: Is the method of authentication. In the list that follows, the type of user is followed by the method returned: Password-authenticated enterprise user, local database user, or Kerberos-authenticated enterprise or external user: SSL-authenticated enterprise or external user: Radius-authenticated external user: Operating system-authenticated external user or DCE-authenticated external user: Proxy with certificate, distinguished name (DN), or user name without using password: You can use Client_IP: Is the IP address of the machine from which the client is connected. Database_Domain: Is the domain of the database as specified in the Database_Hostname: Is the host name of the computer on which the instance is running. Database_Instance: Is the instance identification number of the current instance. Database_IP: Is the IP address of the computer on which the instance is running. Database_Name: Is the name of the database as specified in the Domain: Is a named collection of physical, configuration, or implementation-specific factors in the run-time environment (for example, a networked IT environment or subset of it) that operates at a specific sensitivity level. You can identify a domain using factors such as host name, IP address, and database instance names of the Database Vault nodes in a secure access path to the database. Each domain can be uniquely determined using a combination of the factor identifiers that identify the domain. You can use these identifying factors and possibly additional factors to define the Maximum Security Label within the domain. This restricts data access and commands, depending on the physical factors about the Database Vault session. Example domains of interest may be Corporate Sensitive, Internal Public, Partners, and Customers. Enterprise_Identity: Is the enterprise-wide identity for the user: For enterprise users: the Oracle Internet Directory-distinquished name (DN). For external users: the external identity (Kerberos principal name, Radius and DCE schema names, operating system user name, certificate DN). For local users and The value of the attribute differs by proxy method: For a proxy with DN: the Oracle Internet Directory DN of the client. For a proxy with certificate: the certificate DN of the client for external users; the Oracle Internet Directory DN for global users. For a proxy with user names: the Oracle Internet Directory DN if the client is an enterprise user; NULL if the client is a local database user. Identification_Type: Is the way the user schema was created in the database. Specifically, it reflects the Lang: Is the ISO abbreviation for the language name, a shorter form than the existing Language: Is the language and territory your session currently uses, along with the database character set, in the following form: For example: Refer to Oracle Database Globalization Support Guide for more information about languages, territories, and character sets. Machine: Is the host name for the database client that established the current session. If you must find out whether the computer was used for a client or server session, then you can compare this setting with the Database_Hostname factor to make the determination. Network_Protocol: Is the network protocol being used for communication, as specified in the Proxy_Enterprise_Identity: Is the Oracle Internet Directory DN when the proxy user is an enterprise user. Proxy_User: Is the name of the database user who opened the current session on behalf of Session_User: Is the database user name by which the current user is authenticated. This value remains the same throughout the session. In general, to create a factor, you first create the factor itself, and then you edit the factor to include its identity. "Guidelines for Designing Factors" provides advice on designing factors. To create a factor: Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, under Database Vault Feature Administration, click Factors. In the Factors page, click Create. In the Create Factor page, enter the following settings, and then click OK: General In the General area, enter the following information: Name: Enter a name up to 28 characters in mixed-case, without spaces. Oracle Database Vault creates a valid Oracle identifier for the factor function to be created in the Oracle suggests that you start the name with a noun and complete the name with a brief description of the derived value. "Oracle Database Vault PL/SQL Factor Functions" describes the Description: Enter a text description of the factor. It can have up to 1024 characters in mixed-case. This attribute is optional. Factor Type: From the list, select the type or category of the factor. This attribute is mandatory. Factor types have a name and description and are used only to help classify factors. A factor type is the category name used to classify the factor. The default physical factor types include authentication method, host name, host IP address, instance identifiers, database account information, and others. You can create user-defined factor types, such as application name, certificate information, and so on in addition to the installed factor types, such as time and authentication method. You can find the factors that are associated with a particular factor type by querying the The output is: Note: Factor Identification Under Factor Identification, select how to resolve the identity of a factor. This attribute is mandatory. The values are as follows: By Method: Default. Sets the factor identity by executing the PL/SQL expression specified in the Retrieval Method field. For example, suppose the expression retrieves the system date: On December 6, 2009, the By Method option would return the following value: By Constant: Resolves the factor identity by retrieving the constant value found in the Retrieval Method field. By Factors: Determines the factor identity by mapping the identities of the child factor to its parent factor. A parent factor is a factor whose values are resolved based on a second factor, called a child factor. To establish their relationship, you map their identities. (You do not need to specify a Retrieval Method expression for this option.) See "Using Identity Mapping to Configure an Identity to Use Other Factors" for more information about mapping identities. A factor identity is the actual value of a factor (for example, the IP address for a factor that uses the IP_Address type). A factor can have several identities depending on its retrieval method or its identity mapping logic. For example, a factor such as Database_Hostname could have multiple identities in an Oracle Real Application Clusters environment; a factor such as Client_IP can have multiple identities in any RDBMS environment. The retrieval method for these types of factors may return different values because the retrieval method is based on the database session. Several reports allow you to track the factor identity configuration. See "Related Reports and Data Dictionary Views" for more information. You can configure the assignment of a factor in the following ways: Assign the factor at the time a database session is established. Configure individual requests to retrieve the identity of the factor. With the Oracle Label Security integration, you can label identities with an Oracle Label Security label. You can also assign an identity trust levels, which are numbers that indicate the magnitude of trust relative to other identities for the same factor. In general, the higher the trust level number is set, the greater the trust. Negative trust levels are not trusted. Within a database session, a factor assigned identity is available to Oracle Database Vault and any application with a publicly accessible PL/SQL function that exists in the This allows the identifier for a factor to be accessed globally from within the Oracle database (using PL/SQL, SQL, Oracle Virtual Private Database, triggers, and so on). For example, in SQL*Plus: Output similar to the following appears: You can also use the The following output appears: Evaluation Under Evaluation, select how you want the factor to be evaluated and assigned an identity. See "How Factors Affect Performance" for the performance effect of session factors. This attribute is mandatory. The values are as follows: By Session: Default. Evaluates the factor when a database session is created. By Access: Evaluates the factor each time it is accessed (for example, referenced by an application) and when the database session is first created. Factor Labeling Under Factor Labeling, select how you want the factor identity to retrieve an Oracle Label Security (OLS) label. This setting applies if you plan to use the Oracle Label Security integration. This attribute is mandatory if you want to use an OLS label. (See also "Integrating Oracle Database Vault with Oracle Label Security" for information on integrating OLS labels with a factors. The values are as follows: By Self: Default. Labels the identities for the factor directly from the labels associated with an Oracle Label Security policy. By Factors: If there are multiple child factor labels, then Oracle Database Vault merges the labels by using the Oracle Label Security algorithm that is associated with the applicable Oracle Label Security policy. For each applicable Oracle Label Security policy, a factor identity can have an assigned label. Retrieval Method Under Retrieval Method, enter a PL/SQL expression that retrieves the identity of a factor or a constant. It can use up to 255 characters in mixed-case. The Retrieval Method identifies factors where the factor identification is by method or constant. If the factor identification is by factors, Oracle Database Vault identifies it by its identity mappings. You can create your own PL/SQL retrieval methods, or use the functions supplied with Oracle Database Vault. See the following sections for factor-specific and general utility functions that you can use to build the retrieval method: The following retrieval method sets a value of the DB_NAME factor by retrieving the database name (DB_NAME) from the See also the default factors provided with Oracle Database Vault for examples of retrieval methods. "Default Factors" describes these factors. The Retrieval Method field is mandatory if you have selected the following settings under Factor Identification: By Method: Enter a method in the Retrieval Method field. By Constant: Enter a constant in the Retrieval Method field. The value returned as the factor identity must be a You can include any package function or standalone function in the expression. Ensure that the expression is a fully qualified function, such as Write the function signature using the following format: Validation Method Under Validation Method, enter a PL/SQL expression that returns a Boolean value ( You can include any package function or standalone function in the expression. Ensure that the expression is a fully qualified function, such as Write the function using one of the following formats: In this form, you can use the In this form, the factor value is passed to the validation function directly. This is more appropriate for factors that are evaluated by access. It is also valid for factors evaluated by session. See the following sections for factor-specific and general utility functions that you can use to build the validation method: Assignment Rule Set Under Assignment Rule Set, select a rule set from the list if you want to use a rule set to control when and how a factor identity is set. For example, you can use a rule set to determine when a database session originates from a known application server or program. Chapter 5, "Configuring Rule Sets," explains how to create rule sets. This attribute is particularly useful for situations where database applications, such as a Web application using a JDBC connection pool, must dynamically set a factor identity for the current database session. For example, a Web application may want to assign the geographic location for a database account logging in to the Web application. To do so, the Web application can use the JDBC Callable Statement, or Oracle Data Provider for .NET (ODP.NET) to execute the PL/SQL function Then you can create an assignment rule for the GEO_STATE factor to allow or disallow the setting of the GEO_STATE factor based on other factors or rule expressions. See "How Factors Are Set" for more information. Audit Options Under Audit Options, select from the settings to generate an audit trail. Oracle Database Vault writes the audit trail to the You can use the Factor Audit Report to display the generated audit records. (See "Related Reports and Data Dictionary Views" for more information.) In addition, you can select multiple audit options at a time. Each option is converted to a bit mask and added to determine the aggregate behavior. Note that there is little performance impact in auditing, unless the factor has errors. This attribute is mandatory. The values are as follows: Never: Does not audit. Always: Always creates an audit record when a factor is evaluated. You can select from the conditions, described next. Sometimes: Creates an audit record based on one or more conditions. When you select Sometimes, by default the Retrieval Error and Retrieval NULL options are selected. You can select from the following conditions listed next. Conditions that you can select for the Always and Sometimes options are as follows: Retrieval Error: Creates an audit record when the identity of a factor cannot be resolved and assigned, due to an error (such as Retrieval NULL: Creates an audit record when the identity of a factor is resolved to Validation Error: Creates an audit record when the validation method (if provided) returns an error. Validation False: Creates an audit record when the validation method (if provided) returns Trust Level NULL: Creates an audit record when the resolved identity of a factor has an assigned trust level of See "Creating and Configuring a Factor Identity" for more information about trust levels. Trust Level Less Than Zero: Creates an audit record when the resolved identity of a factor has an assigned trust level less than zero. Error Options Under Error Options, select from the following to specify the processing that occurs when a factory identity cannot be resolved. This attribute is mandatory. The values are as follows: Show Error Message: Default. Displays an error message to the database session. Do Not Show Error Message: Does not display the error message. An advantage of selecting Do Not Show Error Message and then enabling auditing is that you can track the activities of a potential intruder. The audit report reveals the activities of the intruder, yet the intruder is unaware that you are doing this because he or she does not see any error messages. After you have created a new factor, you are ready to configure its identity. To do so, edit the factor and then add its identity. In the Oracle Database Vault Administration page, select Factors. In the Factors page, select the factor that you want to edit. Click Edit. Modify the factor as necessary, and then click OK. See Also: "Creating a Factor" to modify the settings created for a new factor "Adding an Identity to a Factor" to add or modify an identity for the factor After you create a new factor, you optionally can add an identity to it. An identity is the actual value of the factor. For example, the identity of an IP_Address factor could be the IP address of 192.0.2.4. This section contains: A factor identity for a given database session is assigned at run time using the Factor Identification and Retrieval Method fields described in "Creating a Factor". You can further configure the identity for the following reasons: To define the known identities for a factor To add a trust level to a factor identity To add an Oracle Label Security label to a factor identity To resolve a factor identity through its child factors, by using Identity Mapping See Also: "How Factors Work" for more information about how a factor behaves during a database session "Tutorial: Restricting User Activities Based on Session Data" for an example of how to create and use factor identities To create and configure an identity: In the Oracle Database Vault Administration page, select Factors. In the Factors page, select the factor to which you want to add the identity. Click Edit. In the Edit Factor page, scroll down to Identities and click Create. In the Create Identity page, enter the following settings and then click OK: General Enter the following values: Value: Enter the value of the identity, up to 1024 characters in mixed-case. This attribute is mandatory. Trust Level: Select one of the following trust levels: Very Trusted: Assigns a trust level value of 10 Trusted: Assigns a trust level value of 5 Somewhat Trusted: Assigns a trust level value of 1 Untrusted: Assigns a trust level value of -1 Trust Level Not Defined: Assigns a trust level value of Trust levels enable you to assign a numeric value to indicate the measure of trust allowed. A trust value of 1 signifies some trust. A higher value indicates a higher level of trust. A negative value or zero indicates distrust. When the factor identity returned from a factor retrieval method is not defined in the identity, Oracle Database Vault automatically assigns the identity a negative trust level. To determine the trust level of a factor identity at run time, you can use the For example, suppose you have created a factor named Network. You can create the following identities for the Network factor: Intranet, with a trust level of 10 VPN (virtual private network), with a trust level of 5 Public, with a trust level of 1 You then can create rule expressions (or custom application code) that base policy decisions on the trust level. For example, you can use Or, you can use a Output similar to the following appears: In the preceding example, Network factor identity for VPN is trusted (value equals 5), and the identity for the INTRANET domain is 10, which implies a greater trust. See Chapter 15, "Using the Oracle Database Vault PL/SQL Interfaces," for more information about the Oracle Database Vault functions. Label Identity You can assign Oracle Label Security (OLS) labels to factor identities. (In brief, a label acts as an identifier for a database table row to assign privileges to the row. For more information about labels, see Oracle Label Security Administrator's Guide.) The Factor Labeling attribute for a factor determines whether a factor is labeled By Self or By Factors. If you set the Factor Labeling attribute to By Self, then you can associate OLS labels with the factor identities. If you set the Factor Labeling attribute to By Factors, then Oracle Database Vault derives the factor identity labels from the labeling of child factor identities. When there are multiple child factor identities with labels, Oracle Database Vault merges the labels using the OLS algorithm associated with the applicable factor Oracle Label Security policy. In the Create Identity page, under Label Identity, select the OLS label from the Available OLS Labels list. The list shows data labels from the Oracle Label Security installation for your site. For more information, refer to Oracle Label Security Administrator's Guide. Note: Click Move to move the OLS label to the Selected OLS Labels list. Repeat Step 1 and Step 2 to select more OLS labels. You can select only one label for each OLS policy. Click OK to finish labeling the identity. Editing a Factor Identity In the Edit Factor page, scroll down to Identities and select the identity you want to edit. Click Edit. In the Edit Identity page, modify the identity as necessary. Click OK. Deleting a Factor Identity Before you delete a factor identity, you can locate the various references to it by querying the factor-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information. In the Edit Factor page, scroll down to Identities and select the identity you want to remove. Click Remove. In the Confirmation page, click Yes. After you create, edit, and save the factor identity, you can map it. Identity mapping is the process of identifying a factor by using other (child) factors. This is a way to transform combinations of factors into logical identities for a factor or to transform continuous identity values (for example, temperature) or large discrete identity values (for example, IP address ranges) into logical sets. To check configuration issues in the mapping for an identity, see "Identity Configuration Issues Report". See also "Tutorial: Restricting User Activities Based on Session Data" for an example of how to use identity mapping. To map an identity to a factor: Create a parent factor and set the attribute Factor Identification to By Factors. "Creating a Factor" describes how to create factors. For the parent factor, create a new factor identity. "Creating and Configuring a Factor Identity" describes how to create an identity. Map the factor-identity pair of the parent to the factor-identity pairs of its children. Use the following process: In the Factors page, select the parent factor from the Factors page and then click Edit. In the Edit Factor page, under Identities, select the parent factor identity and then click Edit. In the Edit Identity page, click Create under Map Identity. In the Create Identity Map page, select a factor name from the Contributing Factor list. This is the child factor to which you want to map the parent factor. Select a Map Condition. This setting lets you select an operator to compare the contributing (child) factor values. Enter a value for the Low Value and High Value (optional) fields. For example, consider a scenario where the Contributing Factor to the Factor Network is set to Client_IP, the Map Condition is set to Click OK to map the parent factor-identity to the child factor-identity. You can map different identities of a parent factor to different identities of the contributing factor. For example, the INTRANET identity maps to an IP address range of 192.0.2.1 to 192.0.2.24. The REMOTE identity can map to an IP address range that excludes the address range 192.0.2.1 to 192.0.2.24. Based on identity mapping, you can create a security policy. For example, you can define a reduced set of privileges for an employee connecting over VPN (with REMOTE), as opposed to an employee connecting from within the corporate network (with INTRANET). Repeat Step c to Step g to add more contributing factors for a parent factor identity. For example, you can configure the Network factor to resolve to a value ACCOUNTING-SENSITIVE, when the Program factor resolves to "Oracle General Ledger" and the Client_IP is in between 192.0.2.1 and 192.0.2.24. So, if an authorized accounting financial application program, running on a client with IP address 192.0.2.12 accesses the database, then the Network factor is resolved to ACCOUNTING-SENSITIVE. A database session with the ACCOUNTING-SENSITIVE Network value would have more access privileges than one with the INTRANET Network value. Before you delete a factor, you can locate the various references to the factor and its identities by querying the factor-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information. Delete any references to the factor, such as factor identities, and Oracle Label Security policy associations. You cannot delete a factor that has references. In the Oracle Database Vault Administration page, select Factors. In the Factors page, select the factor that you want to remove. Click Remove. In the Confirmation page, click Yes. The following topics in this section explain how Oracle Database Vault processes factors: When a database session is established, the following actions occur: At the start of each database session, Oracle Database Vault begins to evaluate all default and user-created factors in the database instance. This evaluation occurs after the normal database authentication of the session and the initialization of the Oracle Label Security session information, if applicable. In the factor evaluation stage, the factor initialization process executes the retrieval method for all factors that are identified by methods or constants, to resolve the factor identity for the session. The factor error options setting has no effect on the factor initialization process. If a factor has a validation method defined, Oracle Database Vault validates the identity (value) of the factor by executing this validation method. If the validation method fails or returns false, the identity of the factor is undefined ( If a factor has any identities defined for it, Oracle Database Vault resolves the trust level of the factor based on the identities defined. If an identity of the factor is defined in this list of defined identities, then Oracle Database Vault assigns the trust level as configured; otherwise it sets it to -1. If there are no identities defined for the factor, the trust level is undefined ( Depending on the outcome of this factor evaluation, factor validation, and trust level resolution, Database Vault audits the details of the evaluation as dictated by the factor audit configuration. When the evaluation of all factors that are identified by method or constant completes, Oracle Database Vault resolves the factors that are identified by other factors by using the identity maps that are defined for the factor configured identities. The evaluation order of the factor-configured identities is by ASCII sort on the identity values: Oracle Database Vault uses the first alphabetically sorted identity mapping that it evaluates. For example, suppose factor TEST has identities X and Y. Furthermore, identities X and Y have identity maps that are dependent on identities for factors A, B, and C. The following mapping occurs: X is mapped when A=1 and B=1 Y is mapped when A=1, B=1, and C=2 In this case, the first one evaluated is X. Y is not evaluated, but what if its C mapping meets the criteria that is needed for the TEST factor's success? You would need to reverse the mapping, that is, map Y before X so that A, B, and C can be evaluated first. To reverse the mapping, rename Y to V (or some alphabetic value that sorts before X) so that it can be correctly resolved. This algorithm works if the ASCII sort ordering is correct and the identities map the same number factors at some level. When the factor initialization completes, the Oracle Database Vault integration with Oracle Label Security occurs. After this process completes, Oracle Database Vault checks to see if a command rule is associated with the Note: If you do inadvertently lock out users, then you should temporarily disable Oracle Database Vault, disable the CONNECT command rule, reenable Oracle Database Vault, and then fix the factor code that is causing the problem. "If the Test Fails" provides an example of how to accomplish this. You can retrieve a factor in a database session at any time by using the Example 7-1 shows an example of using the You can use the factor values retrieved from the Oracle Database Vault rule expressions Custom application code that is available to all database sessions in an Oracle Database Vault environment "Oracle Database Vault PL/SQL Factor Functions" describes If you had set the factor evaluation to By Session, then Oracle Database Vault retrieves the value from the session context established, as described under "How Factors Are Processed When a Session Is Established". If you had set the factor evaluation to By Access, then Oracle Database Vault performs Step 2 through Step 5 (or Step 6), as described under "How Factors Are Processed When a Session Is Established", whenever the factor is retrieved. If you had defined error options for the factor and if an error occurs, then Oracle Database Vault displays the error message. You can have a factor identity assigned at any time during a database session, but only if you have defined a factor assignment rule set and that rule set evaluates to true. You can do this in the application code by using the Applications that can execute Oracle PL/SQL functions can use this procedure (for example, applications written using Oracle Data Provider for .NET (ODP.NET)). This concept is similar to the standard Oracle If you have not associated a assignment rule set for the factor or if the rule set returns false (or returns errors), then Oracle Database Vault sends an error message if you attempt to set the factor using the In this section: See Also: "Tutorial: Restricting User Activities Based on Session Data" for an example of using factor identity mapping "Tutorial: Integrating Oracle Database Vault with Oracle Label Security" for an example of integrating an Oracle Database Vault factor with an Oracle Label Security label Many database applications contain features to explicitly control the actions of a user. However, an ad hoc query tool, such as SQL*Plus, may not have these controls. As a result, a user could use an ad hoc tool to perform actions in the database that he or she would normally be prevented from performing in a regular database application. You can use a combination of Oracle Database Vault factors, rule sets, and command rules to prevent unauthorized access to the database by ad hoc query tools. In the following tutorial, you limit the use of SQL*Plus to only four users: the Database Vault Owner, the Database Vault Account Manager, You must use the Log in to SQL*Plus as a user who has been granted the For example: Check the status of the If the Replace The Module factor uses the Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, select Factors. The Factors page appears. Click Create to display the Create Factor page. Enter the following information: Name: Enter Description: Enter Factor Type: From the list, select Application. Factor Identification: Select By Method. Evaluation: Select By Access. Factor Labeling: Select By Self. Retrieval Method: Enter the following retrieval method: Validation Method: Leave blank. Assignment Rule Set: From the list, select <Non Selected>. Audit Options: Select Never. Error Options: Select Show Error Message. Click OK. Oracle Database Vault creates the factor. You now can query for the factor using the same syntax you would use to query the default factors, described "Oracle Database Vault PL/SQL Factor Functions". In SQL*Plus, perform a quick test of the Module factor. For example: The following output should appear: Do not exit SQL*Plus. You must use it later on when you test the factor components. In Oracle Database Vault Administrator, return to the Administration page. Under Administration, select Rule Sets. The Rule Sets page appears. Click Create to display the Create Rule Set page. Enter the following settings: Name: Enter Description: Enter Status: Select Enabled. Evaluation Options: Select All True. Audit Options: Select Audit Disabled. Error Handling Options: Select Show Error Message. Fail Code, Fail Message: Leave blank. Custom Event Handler Option: Select Handler Disabled. Custom Event Handler Logic: Leave blank. Click OK. The Rule Sets page appears. Select the Limit SQL*Plus rule set and then click Edit. The Edit Rule Set page appears. Under Rules Associated To The Rule Set, click Create. The Create Rule page appears. Enter the following settings: Name: Enter Rule Expression: Enter the following rule expression: Replace This expression tells Oracle Database Vault only to allow these four users to use SQL*Plus. Another way to write the expression is to tell Database Vault to simply exclude certain users from using SQL*Plus. That way, everyone else has access to SQL*Plus. For example, to exclude users However, for this tutorial, use the first expression, in which only the four administrative users are allowed to use SQL*Plus. Ensure that you have entered this rule expression exactly as shown in Step 8. If you enter it incorrectly, you cannot log in to SQL*Plus. Click OK. The CONNECT command rule controls the In Oracle Database Vault, return to the Administration page. Select Command Rules. The Command Rules page appears. Click Create to display the Create Command Rule page. Enter the following settings: Command: Select CONNECT from the list. Status: Select Enabled. Object Owner, Object Name: Set to % so that the command rule applies to anyone who logs in. Rule Set: Select Limit SQL*Plus Access from the list. Click OK. You have been logged in to SQL*Plus all along, but note that you do not need to restart your SQL*Plus session in order for the Oracle Database Vault changes to take effect. They take effect right away. In SQL*Plus, try to connect as user The following output should appear: User Now try to connect as user User If the Test Fails If you cannot log in to SQL*Plus as Temporarily disable Oracle Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for instructions on disabling Oracle Database Vault. After you disable Oracle Database Vault, you can log in to SQL*Plus. Log in to SQL*Plus as a user who has been granted the For example: Enter the following statement to drop the CONNECT command rule. Even though you have disabled Oracle Database Vault, you still can use its PL/SQL Packages and Database Vault Administrator. Exit SQL*Plus. Reenable Oracle Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for instructions on enabling Oracle Database Vault. In Oracle Database Vault Administrator, check the rule expression for any errors and then correct them. Recreate the CONNECT command rule, and then test it. In Database Vault Administrator, return to the Administrator page. Select Command Rules. In the Command Rules page, select the CONNECT command rule, and then click Remove. Select Yes in the Confirmation page. In the Administrator page, select Rule Sets. In the Rule Sets page, select the Limit SQL*Plus Access rule set and click Remove. Select Yes in the Confirmation page. In the Administration page, select Factors. In the Factors page, select the Module factor, and then click Remove. Select Yes in the Confirmation page. As the Database Vault Owner, log in to SQL*Plus and then remove the Prevent Non-admin access to SQL*Plus rule. For example: If necessary, connect as the Oracle Database Vault Account Manager and then lock and expire the For example: This section contains: Step 3: Map the Domain Factor Identities to the Client_IP Factor Step 4: Create a Rule Set to Set the Hours and Select the Factor Identity You can use factor identity mapping to set session-based user restrictions for database activities. For example, suppose you wanted to restrict administrative access to a database using the following criteria: Ensure that the administrator is accessing the database from the correct IP address. Limit the database access to the standard business hours of the administrator. This type of configuration is useful for restricting different types of administrators: not only local, internal administrators, but offshore and contract administrators as well. In this tutorial, you modify the Domain factor to include identities for a secure and non-secure network access, which are based on the IP address of the computer the administrator is using. If the administrator tries to perform an action outside the standard working hours or from a different IP address, then Oracle Database Vault prevents him from doing so. In SQL*Plus, log in as a user who has been granted the For example: Replace Connect as Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, select Factors. The Factors page appears. Select the Domain factor and then select Edit. The Domain factor is the parent factor. Under Identities, select Create. In the Create Identity page, enter the following information: Value: Enter Trust Level: Select Very Trusted Click OK. In the Edit Factor:Domain page, create a second identity called NOT SECURE, and then set its trust level to Untrusted. In Oracle Database Vault Administrator, in the Edit Factor: Domain page, select the HIGHLY SECURE INTERNAL NETWORK identity and then select Edit. Under Map Identity, select Create. In the Create Identity Map page, enter the following information: Contributing Factor: Select Client_IP to be the child factor. Map Condition: Select Equal, and then in the Low Value box, enter the IP address for the Virtual Machine (for example, Click OK, and then click OK again to return to the Edit Factor: Domain page. Create the following two identity maps for the NOT SECURE identity: The identity maps in the NOT SECURE identity are in a range of IP addresses outside the IP address that user This identity mapping creates the following condition: If the user logs in from the correct IP address, then Oracle Database Vault decides that the connection is secure, through the HIGHLY SECURE INTERNAL NETWORK identity. However, if the user logs in from an IP address that is less than 192.0.2.5 or greater than 192.0.2.20, then the connection is deemed not secure, through the NO SECURE identity. Click OK to return to the Edit Factor: Domain page, then click OK again to return to the Factors page. Test the factor identities. First, in SQL*Plus, connect as user The following output should appear: Next: The following output should appear: Because user Now connect to SQL*Plus by specifying the database instance (for example, The following output should appear: Next: The following output should appear: Now that user In Oracle Database Vault, return to the Administration page. Select Rule Sets. In the Rule Sets page, select Create. In the Create Rule Set page, enter the following settings: Name: Enter Status: Select Enabled. Evaluation Options: Select All True. Leave the remaining settings at their defaults. Click OK. In the Rule Sets page, select the Internal DBA Standard Working Hours rule set, and then select Edit. In the Edit Rule Set: Internal DBA Standard Working Hours page, under Rules Associated To The Rule Set, select Create. In the Create Rule page, create the following rules: Name: Rule Expression: (When you create an expression with a user name, enter the user name in upper case letters, because that is how the database stores user names.) Name: Rule Expression: Name: Rule Expression: Name: Rule Expression: Click OK to return to the Rule Sets page. In Oracle Database Vault Administrator, return to the Administration page. Select Command Rules, and in the Command Rules page, select Create. In the Create Command Rule page, enter the following settings: Command: Select CREATE TABLE from the list. Rule Set: Select Internal DBA Standard Working Hours from the list. Leave the remaining settings at their defaults. Click OK. Test the settings by resetting the system clock, logging in as the Set the system time to 9 p.m. UNIX: Log in as root and use the date command to set the time. For example, assuming the date today is December 14 2011, you would enter the following: Windows: Double-click the clock icon, which is typically at the lower right corner of the screen. In the Date and Time Properties window, set the time to 9 p.m., and then click OK. In SQL*Plus, connect as user The following output should appear: Because user Reset the system time back to the local time. In SQL*Plus, as user Now that user Reconnect as user The following output should appear: Even though user Log in to SQL*Plus as the Remove the CREATE TABLE command rule. Return the Administration page and select Command Rules. Select the CREATE TABLE command rule and then select Remove. In the Confirmation page, select Yes. Remove the Internal DBA Standard Working Hours rule set. In Oracle Database Vault Administrator, select Rule Sets in the Administration page. In the Rule Sets page, select the Internal DBA Standard Working Hours rule set, and then select Remove. In the Confirmation page, select Yes. In SQL*Plus, delete the rules associated with the Internal DBA Standard Working Hours rule set. Remove the HIGHLY SECURE INTERNAL NETWORK and NOT SECURE factor identities from the Domain factor. Return to the Administration page and select Factors. Select the Domain factor, select Edit, and under Identities, remove the HIGHLY SECURE INTERNAL NETWORK and NOT SECURE factor identities. In the Confirmation page, select Yes. Follow these guidelines for designing factors: You can use the Oracle utility packages such as Do not specify a retrieval method if the factor identification is set to Identified By Factors. Retrieval methods are only needed if you set the factor to By Method or By Constant. Consider using a validation method if a factor has an assignment rule set. Doing so helps to verify that invalid identities are not submitted. Use the client-supplied factors such as Program, OS User, and others with caution, because the values that are supplied can only be trusted when the client software is trusted and the communications channel from the client software is known to be secure. Only specify an evaluation option of By Access if the value returned by the retrieval method could change from one invocation to the next in the same session (for example, v'time-based factors). Optimize the internal logic of a function used for the factor retrieval method using traditional SQL and PL/SQL optimization techniques. For more information about performance and optimization, see Oracle Database Performance Tuning Guide. If the discrete values returned by the retrieval method are known, be sure to define identities for each value so that you can assign trust levels for them. Trust levels add value to factors as you also can use the trust level in application logic based on factors. A security policy based on more factors is generally considered stronger than one based on fewer factors. You can create a new factor that is identified by other factors to store combinations of factors into logical grouping using identity maps. This also makes it easier to label the parent factor when you integrate the factors with the Oracle Label Security labels. (See "Integrating Oracle Database Vault with Oracle Label Security" for more information.) It is generally easier to configure and debug a factor that is labeled By Self than one labeled By Factors when integrating the Oracle Label Security. You can design a database client application to pass one or more security, end-user, or environmental attributes so that they are available to an associated database session. To do this, create a single factor for each attribute and then use an assignment rule set to control when these attributes can be assigned (for example only when using a specific Web application on specified named application server computers). Oracle Database Vault factors used in this fashion are very much like the Oracle procedure Each factor has elements that are processed, such as its validation method, trust level, and so on. For factors that are evaluated by the session, such as Database_Hostname and The 17 default factors listed in "Default Factors" are cached because they are likely candidates for a typical security policy. However, if you only use five factors (for example, in rule sets or other components), then the other factors consume resources that could otherwise be used elsewhere. In this case, you should remove the unnecessary factors by deleting them. (Oracle Database Vault does not use any of these factors internally, so you can remove them if you do not need them.) If you have a large number of users or if your application server frequently must create and destroy connections, the resources used can affect system performance. You can delete the unnecessary factors. You can check system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Database Control, which is installed by default with Oracle Database), Table 7-1 lists Oracle Database Vault reports that are useful for analyzing factors and their identities. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports. Table 7-1 Reports Related to Factors and Their Identities Audits factors (for example, to find factors that failed to be evaluated) "Factor Configuration Issues Report" Lists configuration issues, such as disabled or incomplete rule sets, or to audit issues that may affect the factor "Factor Without Identities Report" Lists factors that have had no identities assigned yet "Identity Configuration Issues Report" Lists factors that have invalid label identities or no map for the identity "Rule Set Configuration Issues Report" Lists rule sets that have no rules defined or enabled, which may affect the factors that use them Table 7-2 lists data dictionary views that provide information about existing factors and factor identities. Table 7-2 Data Dictionary Views Used for Factors and Factor Identities Lists the existing factors in the current database instance Shows the relationships of each factor whose identity is determined by the association of child factors Lists the names and descriptions of factor types used in the system Lists the identities for each factor Lists the mappings for each factor identity This chapter contains: Oracle Database Vault provides a selection of reports that display security-related information from the database. These reports also show custom Oracle Database Vault audit event information. The reports are in two categories: Database Vault Reports. These reports allow you to check configuration issues with realms, command rules, factors, factor identities, rule sets, and secure application roles. These reports also reveal realm violations, auditing results, and so on. General Security Reports. These reports allow you to check the status of object privileges, database account system privileges, sensitive objects, privilege management, powerful database accounts and roles, initialization parameters, profiles, account passwords, security audits, and other security vulnerability reports. You must log on using an account that has the To run Oracle Database Vault reports: Log in to Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. Select either Database Vault Reports or General Security Reports. These report categories are described in the following sections: Select a report and click Run Report to run the report. You can run many of the reports without any input parameters. For example, if you select the Audit Privileges Report, and click Run Report, then you can immediately see the report results. However, some of the available reports require at least one input parameter before the results can be displayed. The Report Results page displays the report content in a tabular fashion with the column headings shown at the top of the report. The page displays the report title and the date and time when the report was run. Click Return to Reports Menu to return to the Reports page, so that you can select and run a different report if you want. Some of the reports require at least one input parameter to be provided before they can be run. For example, when you select Object Dependencies Report and click Run Report, the Report Parameters page is displayed. The Owner box enables you to select the database account that owns the object. The Object Name field specifies the name of the object. You can use wildcard characters like the percentage sign (%), which defaults to all object names. The Result Set Size parameter determines the maximum number of result rows that are displayed. If you want all records to be displayed, then select All.The parameters that you enter on this page are passed directly to the SQL query that generates the report results. Click Run Report to display the report results based on the specified parameters. To generate Oracle Database Vault reports, click the Database Vault Reports tab, and then select from the following categories of reports: The configuration issues reports are: The Command Rule Configuration Issues Report displays command rules for which the following configuration issues exist: The Factor Configuration Issues Report displays Oracle Database Vault factors for which the following configuration issues exist: No factor retrieval method or constant exists. No subfactors (that is, child factors) are linked to a factor identity. The Factor Without Identities Report displays Oracle Database Vault factors that have no identities defined in the access control configuration. For some factors such as The Identity Configuration Issues Report displays Oracle Database Vault factor identities where the following configuration issues exist: The Realm Authorization Configuration Issues Report displays Oracle Database Vault realm information where the following configuration issues exist. Grantee does not exist for a realm authorization. Owner does not exist for a realm-secured object. This can happen when the user account has been dropped. In most cases, however, these types of issues are caught when you configure the realm and during validation. The Rule Set Configuration Issues Report displays Oracle Database Vault rule set information when no rules are defined or enabled for a rule set. The Realm Audit Report shows audit records generated by the realm protection and realm authorization operations. You can manage realm authorizations by using rule sets, and then audit the rule set processing results. A realm violation occurs when the database account, performing an action on a realm-protected object, is not authorized to perform that action. Oracle Database Vault audits the violation even if you do not specify any rule sets attached to the realm. When you configure a realm, you can set it to audit instances of realm violations. You can use this information to investigate attempts to break security. The Command Rule Audit Report shows audit records generated by command rule processing operations. When you configure a command rule, you can set it to audit the rule set processing results. The Factor Audit Report shows factors that failed to evaluate or were set to create audit records under various conditions. It also shows failed attempts to set factors. You can audit instances where a factor identity cannot be resolved and assigned (such as No data found or Too many rows). A factor can have an associated rule set that assigns an identity to the factor at run time. When you configure a factor, you can set it to audit the rule set processing results. The Label Security Integration Audit Report shows audit records generated by the session initialization operation and the session label assignment operation of label security. You can audit instances where the label security session fails to initialize, and where the label security component prevents a session from setting a label that exceeds the maximum session label. The Core Database Vault Audit Trail Report shows audit records generated by the core access security session initialization operation. You can audit instances where the access security session fails to initialize. It displays the following data: To generate general security reports, click the General Security Reports tab, and then select from the following reports: The object privilege reports are: The Object Access By PUBLIC Report lists all objects whose access has been granted to Note: The Object Access Not By PUBLIC Report describes all the object access the database accounts that you specify on the Report Parameters page, through grants to the account directly or through a role, but excluding the grants to Note: The Direct Object Privileges Report shows the direct object privileges granted to nonsystem database accounts. The following database accounts are excluded from the report: The Object Dependencies Report describes all dependencies in the database between procedures, packages, functions, package bodies, and triggers, including dependencies on views created without any database links. It can help you develop a security policy using the principle of least privilege for existing applications. If a database object, such as a The Report Results page shows the dependent object and object type and the source object name and type. This report shows where the potentially sensitive object is being used. By looking at several accounts, you might be able to see patterns that can help you develop restricted roles. These restricted roles can replace The database account system privileges reports are: The Direct System Privileges By Database Account Report displays all system privileges that have been directly granted to the database account selected on the Report Parameters page. It also shows whether a privilege has been granted the The Direct and Indirect System Privileges By Database Account Report displays all the system privileges for the database account selected on the Report Parameters page. The system privileges may have been granted directly or granted through a database role that has the The Hierarchical System Privileges by Database Account Report displays a hierarchical breakdown of role-based system privileges and direct system privileges granted to the database account specified on the Report Parameters page. The ANY System Privileges for Database Accounts Report shows all The sensitive objects reports are: The Execute Privileges to Strong SYS Packages Report shows the database accounts and roles that have the The Access to Sensitive Objects Report shows the database accounts and roles that have object privileges on system tables or views that contain sensitive information. It includes the following system tables and views: The Public Execute Privilege to SYS PL/SQL Procedures Report shows all database accounts and roles that have execute privileges on packages owned by The Accounts with SYSDBA/SYSOPER Privilege Report displays database accounts that have The privilege management summary reports are: See Also: The Privileges Distribution By Grantee Report displays the count of privileges granted to a database account or role. This provides insight into accounts and roles that may have powerful privileges. The Privileges Distribution By Grantee, Owner Report displays a count of privileges based on the grantee and the owner of the object. This provides insight into accounts or roles that may have powerful privileges. You can use this report if you suspect potential intruders or insider threats are looking for accounts that have powerful privileges as accounts to attack or compromise. If intruders can compromise the account (for example, by guessing the password), they can get more privileges than they already have. The Privileges Distribution By Grantee, Owner, Privilege Report displays a count of privileges based on the privilege, the grantee, and the owner of the object. This provides insight into the accounts or roles that may have powerful privileges. The powerful database accounts and roles reports are: The WITH ADMIN Privileges Grants Report shows all database accounts and roles that have been granted privileges with the The Accounts With DBA Roles Report shows all database accounts that have the For guidelines on deciding who should have privileged roles, see Appendix D, "Oracle Database Vault Security Guidelines." The Security Policy Exemption Report shows database (but not Oracle Database Vault) accounts and roles that have the The BECOME USER Report shows all database accounts roles that have the The ALTER SYSTEM or ALTER SESSION Report shows all database accounts and roles that have the For guidelines on using the The Password History Access Report shows database accounts that have access to the The WITH GRANT Privileges Report shows all database accounts that have been granted privileges with the This report displays the database accounts and roles to which a role has been granted. This report is provided for dependency analysis. The Database Accounts With Catalog Roles Report displays all database accounts and roles that have the following roles granted to them: These catalog-based roles have a very large number of powerful privileges. They should be granted with caution, much like the The AUDIT Privileges Report displays all database accounts and roles that have the The initialization parameters and profiles reports are: The Security Related Database Parameters Report displays database parameters that can cause security vulnerabilities, if not set correctly. This report can be used to compare the recommended settings with the current state of the database parameter values. The Resource Profiles Report provides a view of resource profiles, such as The System Resource Limits Report provides insight into the current system resource usage by the database. This helps determine whether any of these resources are approaching their limits under the existing application load. Resources that show large increases over a short period may point to a denial-of-service (DoS) attack. You might want to reduce the upper limit for the resource to prevent the condition in the future. The database account password reports are: The Database Account Default Password Report lists the database accounts that have default passwords. Default passwords are provided during the Oracle Database installation. You should change the passwords for accounts included in this report to nondefault, complex passwords to help secure the database. The Database Account Status Report provides a quick view of existing database accounts. The report shows the account status for each account, which helps you identify accounts that must be locked. Lock and expiry dates provide information that helps determine whether the account was locked as a result of password aging. If a special password and resource secure profile is used, then you can identify accounts that are not using them. Accounts not using organizationally defined default tablespaces also can be identified, and the temporary tablespace for accounts can be determined. This report also identifies accounts that use external passwords. The Core Database Audit Report returns audit records for the audit policy defined in Appendix A, "Auditing Oracle Database Vault," and any auditing records that are generated for audit statements you have defined. This report only displays audit records that are captured if the database initialization parameter The other security vulnerability reports are: The Java Policy Grants Report shows the Java policy permissions stored in the database. It helps reveal violations to the principle of least privilege. Look for Note: The OS Directory Objects Report shows all directory objects that exist in the database, whether they are available to The Objects Dependent on Dynamic SQL Report shows objects that leverage dynamic SQL. Potential intruders have a greater chance of using this channel if parameter checking or bind variables are not used. The report helps by narrowing the scope of where to look for problems by pointing out who is using dynamic SQL. Such objects can be a target for a SQL injection attack and must be secured to avoid this type of attack. After determining the objects that use dynamic SQL, do the following: Check the privileges that client applications (for example, a Web application) have over the object. Check the access granted for the object to Validate parameters. Use bind variables where possible. The Unwrapped PL/SQL Package Bodies Report displays PL/SQL package procedures that are not wrapped. Oracle provides a wrap utility that obfuscates code to the point where it cannot be read in the data dictionary or from the data dictionary views. This helps reduce the ability of an intruder to circumvent data protection by eliminating the ability to read source code that manipulates data. The Username/Password Tables Report helps to identify application tables in the database that store user names and password strings. You should examine these tables to determine if the information is encrypted. (Search for column names such as The Tablespace Quotas Report shows all database accounts that have quotas on one or more tablespaces. These tablespaces can become potential targets for denial-of-service (DoS) attacks. The Non-Owner Object Trigger Report lists triggers that are owned by a database account that is different from the account that owns the database object on which the trigger acts. If the trigger is not part of a trusted database application, then it can steal sensitive data, possibly from tables protected through Oracle Label Security or Virtual Private Database (VPD), and place it into an unprotected table for subsequent viewing or export. Integrating Oracle Database Vault with Enterprise User Security Integrating Oracle Database Vault with Transparent Data Encryption Integrating Oracle Database Vault with Oracle Label Security You can integrate Oracle Database Vault with Oracle Enterprise User Security. Enterprise User Security enables you to centrally manage database users and authorizations in one place. It is combined with Oracle Identity Management and is available in Oracle Database Enterprise Edition. In general, to integrate Oracle Database Vault with Oracle Enterprise User Security, 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: Replace 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. Afterward, the realm authorization applies to all users. For more information about Enterprise User Security, see Oracle Database Enterprise User Security Administrator's Guide. Transparent Data Encryption complements Oracle Database Vault in that it provides data protection when the data leaves the secure perimeter of the database. With Transparent Data Encryption, a database administrator or database security administrator can simply encrypt columns with sensitive content in application tables, or encrypt entire application tablespaces, without any modification to the application. For detailed information about Transparent Data Encryption, see Oracle Database Advanced Security Administrator's Guide. 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. Before you can use Oracle Database Vault with Transparent Data Encryption, you must enable the Once you have granted the Transparent Data Encryption user the appropriate privileges, then Transparent Data Encryption can be managed as usual and be used complimentary to Database Vault. Figure 9-1 shows how Oracle Database Vault realms handle encrypted data. Figure 9-1 Encrypted Data and Oracle Database Vault 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 For more information about Oracle Virtual Private Database, see Oracle Database Security Guide. 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 Oracle Database Vault Factors with Oracle Label Security Policies Tutorial: 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. 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 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. "Tutorial: Integrating Oracle Database Vault with Oracle Label Security" provides an example of how to accomplish this type of integration. You can audit the integration with Oracle Label Security by using the Label Security Integration Audit Report. See "Label Security Integration Audit Report" for more information. Oracle Database Vault writes the audit trail to the You can use the Oracle Database Vault APIs to integrate Oracle Database Vault with Oracle Label Security. See Chapter 12, "Using the DVSYS.DBMS_MACADM Package," 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 and Data Dictionary Views" for more information. You must have the following requirements in place before you use Oracle Database Vault with Oracle Label Security: Oracle Label Security is licensed separately. Ensure that you have purchased a license to use it. Before you install Oracle Database Vault, you must have already installed Oracle Label Security. The installation process for Oracle Label Security creates the Replace If you plan to use the Ensure that you have the appropriate Oracle Label Security policies defined. For more information, see Oracle Label Security Administrator's Guide. Oracle Database Vault controls the maximum security clearance for a database session by merging the maximum allowable data for each 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 as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. Make the user This enables the The Authorize the schema owner (on which the label security policy has been applied) as either a realm participant or a realm owner. In the Administration page, under Database Vault Feature Administration, click Label Security Integration. In the Label Security Policies page: To register 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. This setting provides optimum flexibility when your applications must determine the resulting label that is required when combining two data sets that have different labels. It is also necessary for situations in which you must perform queries using joins on rows with different data labels. For more information on these label-merging algorithms, see Oracle Label Security Administrator's Guide. If you want to use the 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: 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: This section contains: Step 3: Create Oracle Database Vault Rules to Control the OLS Authorization Step 4: Update the ALTER SYSTEM Command Rule to Use the Rule Set You can use Oracle Database Vault factors 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. This tutorial shows how you can integrate Oracle Database Vault with Oracle Label Security to grant two administrative users who normally have the same privileges different levels of access. Log in to SQL*Plus as a user who has been granted the For example: Create the following users: Replace Connect as user At this stage, users In SQL*Plus, connect as the Oracle Label Security administrator, If user For example: Create a new Oracle Label Security policy: Create the following levels for the Create the PII compartment. Grant users User Connect to SQL*Plus as the Database Vault Owner. For example: Create the following rule set: Create a rule for the PII Rule Set. Ensure that you use single quotes, as shown in this example, and not double quotes. Add the Check OLS Factor rule to the PII Rule Set. Synchronize the Check OLS factor rule. As the Database Vault Owner, check the current value of the ALTER SYSTEM command rule, which is one of the default command rules when you install Oracle Database Vault. Make a note of these settings so that you can revert them to their original values later on. In a default installation, the ALTER SYSTEM command rule uses the Allow System Parameters rule set, has no object owner or name, and is enabled. Update the ALTER SYSTEM command rule to include the PII Rule Set. This command adds the PII Rule Set to the ALTER SYSTEM command rule, applies it to all object owners and object names, and enables the command rule. In SQL*Plus, log on as user Check the current setting for the Make a note of this setting, so that you can revert it to its original setting later on. As user Because user Set the Log in as user The following output should appear: Because user Now log in as user The following output should appear: Connect as the Oracle Label Security administrator and remove the label policy and its components. Connect as the Oracle Database Vault Owner and issue the following commands in the order shown, to set the ALTER SYSTEM command rule back to its previous setting and remove the rule set. For example: Connect as the Database Vault Account Manager and remove users Table 9-1 lists Oracle Database Vault reports that are useful for analyzing the integration of Oracle Database Vault and Oracle Label Security. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports. Table 9-1 Reports Related to Database Vault and Oracle Label Security Integration "Factor Configuration Issues Report" Lists factors in which the Oracle Label Security policy does not exist. "Identity Configuration Issues Report" Lists invalid label identities (the Oracle Label Security label for this identity has been removed and no longer exists). "Security Policy Exemption Report" Lists accounts and roles that have the Table 9-2 lists data dictionary views that provide information about existing Oracle Label Security policies used with Oracle Database Vault. Table 9-2 Data Dictionary Views Used for Oracle Label Security Lists the Oracle Label Security policies defined "DBA_DV_MAC_POLICY_FACTOR View" Lists the factors that are associated with Oracle Label Security policies Lists the Oracle Label Security label for each factor identifier in the This chapter contains: How Oracle Database Vault Allows for Flexible Security Policies How Oracle Database Vault Addresses Database Consolidation Concerns Oracle Database Vault restricts access to specific areas in an Oracle database from any user, including users who have administrative access. For example, you can restrict administrative access to employee salaries, customer medical records, or other sensitive information. This enables you to apply fine-grained access control to your sensitive data in a variety of ways. It hardens your Oracle Database instance and enforces industry standard best practices in terms of separating duties from traditionally powerful users. Most importantly, it protects your data from super-privileged users but still allows them to maintain your Oracle databases. Oracle Database Vault is an integral component of your enterprise. With Oracle Database Vault, you address the most difficult security problems remaining today: protecting against insider threats, meeting regulatory compliance requirements, and enforcing separation of duty. You configure Oracle Database Vault to manage the security of an individual Oracle Database instance. You can install Oracle Database Vault on standalone Oracle Database installations, in multiple Oracle homes, and in Oracle Real Application Clusters (Oracle RAC) environments. For frequently asked questions about Oracle Database Vault, visit For Oracle Technology Network (OTN) information specific to Oracle Database Vault, visit Oracle Database Vault has the following components: Oracle Database Vault enables you to create the following components to manage security for your database instance: Realms. A realm is a functional grouping of database schemas, objects, and roles that must be secured. For example, you can group a set of schemas, objects, and roles that are related to accounting, sales, or human resources. After you have grouped these into a realm, you can use the realm to control the use of system privileges to specific accounts or roles. This enables you to provide fine-grained access controls for anyone who wants to use these schemas, objects, and roles. Chapter 4, "Configuring Realms," discusses realms in detail. Command rules. A command rule is a special rule that you can create to control how users can execute almost any SQL statement, including Factors. A factor is a named variable or attribute, such as a user location, database IP address, or session user, which Oracle Database Vault can recognize and secure. You can use factors for activities such as authorizing database accounts to connect to the database or creating filtering logic to restrict the visibility and manageability of data. Each factor can have one or more identities. An identity is the actual value of a factor. A factor can have several identities depending on the factor retrieval method or its identity mapping logic. Chapter 7, "Configuring Factors," discusses factors in detail. Rule sets. A rule set is a collection of one or more rules that you can associate with a realm authorization, command rule, factor assignment, or secure application role. The rule set evaluates to true or false based on the evaluation of each rule it contains and the evaluation type (All True or Any True). The rule within a rule set is a PL/SQL expression that evaluates to true or false. You can have the same rule in multiple rule sets. Chapter 5, "Configuring Rule Sets," discusses rule sets in detail. Secure application roles. A secure application role is a special Oracle Database role that can be enabled based on the evaluation of an Oracle Database Vault rule set. Chapter 8, "Configuring Secure Application Roles for Oracle Database Vault," discusses secure application roles in detail. To augment these components, Oracle Database Vault provides a set of PL/SQL interfaces and packages. "Oracle Database Vault PL/SQL Interfaces and Packages" provides an overview. In general, the first step you take is to create a realm composed of the database schemas or database objects that you want to secure. You can further secure the realm by creating rules, command rules, factors, identities, rule sets, and secure application roles. In addition, you can run reports on the activities these components monitor and protect. Chapter 3, "Getting Started with Oracle Database Vault," provides a simple tutorial that will familiarize you with basic Oracle Database Vault functionality. Chapter 17, "Oracle Database Vault Reports," provides more information about how you can run reports to check the configuration and other activities that Oracle Database Vault performs. Oracle Database Vault Administrator (DVA) is a Java application that is built on top of the Oracle Database Vault PL/SQL application programming interfaces (API). This application allows security managers who may not be proficient in PL/SQL to configure the access control policy through a user-friendly interface. Oracle Database Vault Administrator provides an extensive collection of security-related reports that assist in understanding the baseline security configuration. These reports also help point out deviations from this baseline. Chapter 4 through Chapter 9 explain how to use Oracle Database Vault Administrator to configure access control policy defined in realms, command rules, factors, rule sets, secure application roles, and how to integrate Oracle Database Vault with other Oracle products. Chapter 17, "Oracle Database Vault Reports," explains Oracle Database Vault reporting. Oracle Database Vault provides a schema, Chapter 11, "Oracle Database Vault Objects," describes these schemas in detail. Oracle Database Vault provides a collection of PL/SQL interfaces and packages that allow security managers or application developers to configure the access control policy as required. The PL/SQL procedures and functions allow the general database account to operate within the boundaries of access control policy in the context of a given database session. See Chapter 15, "Using the Oracle Database Vault PL/SQL Interfaces," and Chapter 12, "Using the DVSYS.DBMS_MACADM Package," for more information. Oracle Database Vault provides access control capabilities that can be integrated with Oracle Label Security. The Oracle Label Security database option is integrated with Oracle Enterprise Manager Database Control, which enables the security manager to define label security policy and apply it to database objects. Oracle Label Security also provides a collection of PL/SQL packages that can be used by a database application developer to provide label security policy and protections. See "Integrating Oracle Database Vault with Oracle Label Security" for more information on how Oracle Database Vault works with Oracle Label Security. See also Oracle Label Security Administrator's Guide for more information about Oracle Policy Manager. You can generate reports on the various activities that Oracle Database Vault monitors. In addition, you can monitor policy changes, security violation attempts, and database configuration and structural changes. See Chapter 17, "Oracle Database Vault Reports," for more information about the reports that you can generate. Chapter 16, "Monitoring Oracle Database Vault," explains how to monitor Oracle Database Vault. One of the biggest side benefits resulting from regulatory compliance has been security awareness. Historically, the focus of the information technology (IT) department has been on high availability and performance. The focus on regulatory compliance has required everyone to take a step back and look at their IT infrastructure, databases, and applications from a security angle. Common questions include: Who has access to this information? Where is the sensitive information stored? Regulations such as the Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act (HIPAA), International Convergence of Capital Measurement and Capital Standards: a Revised Framework (Basel II), Japan Privacy Law, Payment Card Industry Data Security Standard (PCI DSS), and the European Union Directive on Privacy and Electronic Communications have common themes that include internal controls, separation of duty, and access control. While most changes required by regulations such as Sarbanes-Oxley and HIPAA are procedural, the remainder may require technology investments. A common security requirement found in regulations is stringent internal controls. The degree to which Oracle Database Vault helps an organization achieve compliance varies with the regulation. In general, Oracle Database Vault realms, separation of duty features, command rules, and factors help reduce the overall security risks that regulation provisions worldwide address. Table 1-1 lists regulations that address potential security threats. Table 1-1 Regulations That Address Potential Security Threats Sarbanes-Oxley Section 302 Unauthorized changes to data Sarbanes-Oxley Section 404 Modification to data, unauthorized access Sarbanes-Oxley Section 409 Denial of service, unauthorized access Gramm-Leach-Bliley Unauthorized access, modification, or disclosure Health Insurance Portability and Accountability Act (HIPAA) 164.306 Unauthorized access to data HIPAA 164.312 Unauthorized access to data Basel II – Internal Risk Management Unauthorized access to data CFR Part 11 Unauthorized access to data Japan Privacy Law Unauthorized access to data EU Directive on Privacy and Electronic Communications Unauthorized access to data Payment Card Industry Data Security Standard (PCI DSS) Unauthorized changes to data For many years, worms, viruses, and the external intruder (hacker) have been perceived as the biggest threats to computer systems. Unfortunately, what is often overlooked is the potential for trusted users or privileged users to steal or modify data. Oracle Database Vault protects against insider threats by using realms, factors, and command rules. Combined, these provide powerful security tools to help secure access to databases, applications, and sensitive information. You can combine rules and factors to control the conditions under which commands in the database are allowed to execute, and to control access to data protected by a realm. For example, you can create rules and factors to control access to data based on IP addresses, the time of day, and specific programs. These can limit access to only those connections pass these conditions. This can prevent unauthorized access to the application data and access to the database by unauthorized applications. Oracle Database Vault provides built-in factors that you can use in combination with rules to control access to the database, realm-protected applications, and commands within the database. You can associate rules and factors with dozens of commands within the database to provide stronger internal controls within the database. You can customize these to meet the operational policies for your site. For example, you could define a rule to limit execution of the Oracle Database Vault helps you design flexible security policies for your database. For example, any database user, such as By time (for example, only during 4 p.m. and 5 p.m. on Friday afternoons) By local access only, that is, not remotely By IP address (for example, allowing the action to only a specified range of IP addresses) In this way, you can carefully control and protect your system. You can disable and reenable command rules when you need to, and easily maintain them from one central location using Oracle Database Vault Administrator. Oracle customers today still have hundreds and even thousands of databases distributed throughout the enterprise and around the world. However, database consolidation will continue as a cost-saving strategy in the coming years. The physical security provided by the distributed database architecture must be available in the consolidated environment. Oracle Database Vault addresses the primary security concerns of database consolidation. Figure 1-1 illustrates how Oracle Database Vault addresses the following database security concerns: Administrative privileged account access to application data: In this case, Oracle Database Vault prevents the DBA from accessing the schemas that are protected by the FIN Realm. Although the DBA is the most powerful and trusted user, the DBA does not need access to application data residing within the database. Separation of duties for application data access: In this case, the FIN Realm Owner, created in Oracle Database Vault, has access to the FIN Realm schemas. Figure 1-1 Oracle Database Vault Security Database consolidation can result in multiple powerful user accounts residing in a single database. This means that in addition to the overall database DBA, individual application schema owners also may have powerful privileges. Revoking some privileges may adversely affect existing applications. Using Oracle Database Vault realms, you can enforce access to applications through a trusted path, preventing database users who have not been specifically authorized access from using powerful privileges to look at application data. For example, a DBA who has the This chapter contains: In Oracle Database Vault, you can create a secure application role that you enable with an Oracle Database Vault rule set. Regular Oracle Database secure application roles are enabled by custom PL/SQL procedures. You use secure application roles to prevent users from accessing data from outside an application. This forces users to work within the framework of the application privileges that have been granted to the role. The advantage of basing database access for a role on a rule set is that you can store database security policies in one central place, as opposed to storing them in all your applications. Basing the role on a rule set provides a consistent and flexible method to enforce the security policies that the role provides. In this way, if you must update the security policy for the application role, you do it in one place, the rule set. Furthermore, no matter how the user connects to the database, the result is the same, because the rule set is bound to the role. All you need to do is to create the role and then associate it with a rule set. The associated rule set validates the user who is trying to enable the role. You can run reports on secure application roles that you create in Oracle Database Vault. See "Related Reports and Data Dictionary View" for more information. This chapter explains how to configure secure application roles by using Oracle Database Vault Administrator. To configure secure application roles by using the PL/SQL interfaces and packages provided by Oracle Database Vault, refer to the following chapters: Create a rule set that contains at least one rule to set the conditions for allowing or disallowing the user to enable the role. When you create the underlying rule for the rule set, remember that the rule should validate the user who is trying to enable the role. The rule should validate the user who is trying to log in. See Chapter 5, "Configuring Rule Sets," for more information about rule sets. Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, under Database Vault Feature Administration, click Secure Application Roles. In the Secure Application Roles page: To create a new secure application role, click Create. To edit an existing secure application role, select it from the list and then click Edit. Remember that you can modify an existing secure application role only if it has been created in Oracle Database Vault. You cannot modify secure application roles or database roles that have been created outside of Oracle Database Vault. If you want to modify an existing Oracle Database role so that it can work with Oracle Database Vault, create a new secure application role in Oracle Database Vault and then grant the existing role to the secure application role. For example, in SQL*Plus: After you create a new secure application role, you must modify your code to use this new role. You can use In the Create (or Edit) Role page, enter the following settings and then click OK. General Enter the following settings: Role: Enter the name using no more than 30 characters, with no spaces. Preferably, enter the role name in upper case letters, though you are not required to do so. Ensure that this name follows the standard Oracle naming conventions for role creation using the Status: Select either Enabled or Disabled to enable or disable the secure application role during run time. The default is Enabled. This attribute is mandatory. Enabled: Enables the role to be available for use. That is, users are allowed to call the See "SET_ROLE Procedure" for more information about this function. Disabled: Disables the role from being available for use. The See "Oracle Database Vault PL/SQL Packages" for more information about the Rule Set From the list, select the rule set that you want to associate with the secure application role. This attribute is mandatory. When calling See Chapter 5, "Configuring Rule Sets," for more information about rule sets. Users who have database administrative privileges may try to use the Whenever an Oracle Database Vault secure application role has been created, Database Vault adds the secure application role to the Database Vault realm. This prevents the database administrator from deleting the secure application role. Before you delete a secure application role, you can locate the various references to it by querying the role-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information. To delete a secure application role: Check and modify any applications that may be using the secure application role that you want to delete. In the Oracle Database Vault Administration page, select Secure Application Roles. In the Secure Application Roles page, select the role that you want to remove. Click Remove. In the Confirmation page, click Yes. The process flow for a secure application role that is managed by Oracle Database Vault is as follows: Create or update the role either in Oracle Database Vault Administrator or by using the secure application role-specific functions in the See "Secure Application Role Procedures Within DVSYS.DBMS_MACADM" for more information. Modify your application to call the role, by using the See "SET_ROLE Procedure" for more information. Oracle Database Vault then evaluates the rule set associated with the secure application role. If the rule set evaluates to true, then Oracle Database Vault enables the role for the current session. If the rule set evaluates to false, the role is not enabled. In either case, Oracle Database Vault processes the associated auditing and custom event handlers for the rule set associated with the secure application role. This section contains: In this tutorial, you restrict the Log in to SQL*Plus as a user who has been granted the For example: Create the following user accounts: Replace Connect as In SQL*Plus, connect as the For example: Check the account status of the If the Log in to Oracle Database Vault Administrator as a user who has been granted the "Starting Oracle Database Vault" explains how to log in. In the Administration page, select Rule Sets. The Rule Sets page appears. Click Create. The Create Rule Set page appears. Enter the following information: Name: Description: Leave the remaining settings and their defaults, and then click OK. In the Rule Sets page, select the Can Modify Orders rule set, and then click Edit. The Edit Rule Set: Can Modify Orders page appears. Scroll to the bottom of the page and under Rules Associated To The Rule Set, click Create. Create the following two rules: For the Check IP Address rule, replace 123.45.67.89 with the IP address for your own computer. In a real-world scenario, you would create an expression that includes all the IP addresses for the users who should be allowed access. Both of these rules use the default factors Client_IP and Session_User. See "Default Factors" for more information about these factors. If these factors have been removed or modified, you can use the following rule expressions instead: Check IP Address: Check Session User: Ensure that the Status setting for the Can Modify Orders table is set to Enabled and Evaluation Options is set to All True. Click OK. In Oracle Database Vault, return to the Administration page. Under Administration, select Secure Application Roles. The Secure Application Roles page appears. Click Create. The Create Role page appears. In the Role box, enter Under Rule Set, select Can Modify Orders. Click OK. At this stage, the Database Vault secure application role and its associated rule set are created, though the role does not yet have any privileges. In SQL*Plus, connect as user Grant the In SQL*Plus, connect directly to the database as user Replace Set the Typically, you would embed this call in the application that the user logs in to. Select from the The following output should appear: Because user Reconnect as user The following output should appear: Next: The following output should appear: Even though user Connect as user Because user Log into SQL*Plus as the For example: Delete the Enter the following commands in the order shown to remove the Can Modify Orders rule set. Connect as the Database Vault Account Manager and drop the users. For example: If uneccessary, lock and expire the You can check system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Database Control, which is installed by default with Oracle Database), Table 8-1 lists Oracle Database Vault reports that are useful for analyzing Oracle Database Vault secure application roles. See Chapter 17, "Oracle Database Vault Reports," for information about how to run these reports. Table 8-1 Reports Related to Secure Application Roles "Secure Application Role Audit Report" Lists audit records generated by the Oracle Database Vault secure application role-enabling operation. To generate this type of audit record, enable auditing for the rule set associated with the role. "Secure Application Configuration Issues Report" Lists secure application roles that have nonexistent database roles, or incomplete or disabled rule sets "Rule Set Configuration Issues Report" Lists rule sets that have no rules defined or enabled, which may affect the secure application roles that use them "Powerful Database Accounts and Roles Reports" Provides information about powerful database accounts and roles You can use the The Oracle Database Vault objects include two schemas with database tables, sequences, views, triggers, roles, packages, procedures, functions, and contexts that support the administration and run-time processing of Oracle Database Vault. Oracle Database Vault has the following schemas: DVSYS Schema: Owns the Oracle Database Vault schema and related objects DVF Schema: Owns the Oracle Database Vault functions that are created to retrieve factor identities The Oracle Database Vault secures the Oracle Database Vault protects and secures the The Statements such as The powerful Object privileges in the Only the protected schema account Only the protected schema account The Note: The This section describes the default roles Oracle Database Vault provides. It includes the following topics: DV_GOLDENGATE_REDO_ACCESS Oracle GoldenGate Redo Log Access Role DV_REALM_RESOURCE Database Vault Application Resource Owner Role Oracle Database Vault provides a set of roles that are required for managing Oracle Database Vault. Figure 11-1 illustrates how these roles are designed to implement the first level of separation of duties within the database. How you use these roles depends on the requirements that your company has in place. Figure 11-1 How Oracle Database Vault Roles Are Categorized Note: Table 11-1 summarizes the privileges available with Oracle Database Vault roles. (The Table 11-1 Privileges of Oracle Database Vault Roles YesFoot 1 YesFoot 2 No No No No No No Yes Yes No No No No No No Yes Yes Yes Yes, on some Database Vault viewsFoot 3 No No No NoFoot 4 No No No No No No No No Yes No No No No No No No No No No Yes No No No No Monitor Database Vault Yes Yes Yes Yes No No No No Run Database Vault reports Yes Yes No Yes No No No No Yes No Yes Yes, on the same system views as No No No No No No No Yes, portions of No No No No No No No No Yes No No No Manage objects in schemas that define a realmFoot 6 No No No No No YesFoot 7 No No No No No No No No Yes No Footnote 1 Includes the Footnote 2 Includes the Footnote 3 Footnote 4 Footnote 5 This privilege does not include the ability to drop or alter the Footnote 6 This privilege includes Footnote 7 The user with this role also must be the realm participant or owner to exercise his or her system privileges Footnote 8 The Use the Privileges Associated with the DV_OWNER Role The Tip: To find the full list of system and object privileges associated with the When you install and register Oracle Database Vault, the How Are GRANT and REVOKE Operations Affected by the DV_OWNER Role? Anyone with the Managing Password Changes for Users Who Have the DV_OWNER Role Before you can change the password for another user who has been granted the To change the Log in to SQL*Plus using an account that has been granted the Revoke the Connect as a user who has been granted the Connect as the Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. The Privileges Associated with the DV_ADMIN Role The To find the full list of system and object privileges associated with the How Are GRANT and REVOKE Operations Affected by the DV_ADMIN Role? Accounts such as Managing Password Changes for Users Who Have the DV_ADMIN Role Before you can change the password for a user who has been granted the To change the Log in to SQL*Plus using an account that has been granted the Revoke the Connect as a user who has been granted the Connect as the Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. The Privileges Associated with the DV_MONITOR Role There are no system privileges associated with the How Are GRANT and REVOKE Operations Affected by the DV_MONITOR Role? By default, this role is granted to the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Use the Privileges Associated with the DV_SECANALYST Role There are no system privileges associated with the How Are GRANT and REVOKE Operations Affected by the DV_SECANALYST Role? Any account, such as Managing Password Changes for Users Who Have the DV_SECANALYST Role Before you can change the password for a user who has been granted the To change the Log in to SQL*Plus using an account that has been granted the Revoke the Connect as a user who has been granted the Connect as the Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Grant the Privileges Associated with the DV_STREAMS_ADMIN Role There are no system privileges associated with the Be aware that the How Are GRANT and REVOKE Operations Affected by the DV_STREAMS_ADMIN Role? You cannot grant the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Grant the Privileges Associated with the DV_XSTREAM_ADMIN Role There are no privileges associated with the Be aware that the How Are GRANT and REVOKE Operations Affected by the DV_XSTREAM_ADMIN Role? You cannot grant the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Grant the Privileges Associated with the DV_GOLDENGATE_ADMIN Role There are no privileges associated with the Be aware that the How Are GRANT and REVOKE Operations Affected by the DV_GOLDENGATE_ADMIN Role? You cannot grant the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Grant the Privileges Associated with the DV_GOLDENGATE_REDO_ACCESS Role There are no privileges associated with the Be aware that the How Are GRANT and REVOKE Operations Affected by the DV_GOLDENGATE_REDO_ACCESS Role? You cannot grant the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Temporarily grant the Privileges Associated with the DV_PATCH_ADMIN Role This role does not provide access to any secured data. How Are GRANT and REVOKE Operations Affected by the DV_OWNER Role? Only a user who has the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Use the Privileges Associated with the DV_ACCTMGR Role A user who has been granted this role can use the Change passwords for users who have been granted the To find the full list of system and object privileges associated with the Tips: Oracle recommends that you add the user who has the If you want the Consider creating a separate, named account for the How Are GRANT and REVOKE Operations Affected by the DV_ACCTMGR Role? Any account, such as What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Use the Privileges Associated with the DV_REALM_OWNER Role A user who has been granted this role can use powerful system privileges like There are no object privileges granted to the How Are GRANT and REVOKE Operations Affected by the DV_REALM_OWNER Role? The realm owner of the Oracle Data Dictionary realm, such as If you want to attach this role to a specific realm, then you must assign it to an account or business-related role, then authorize that account or role in the realm. What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Use the Privileges Associated with the DV_REALM_RESOURCE Role The There are no object privileges granted to the Though this role has system privilege grants that How Are GRANT and REVOKE Operations Affected by the DV_REALM_RESOURCE Role? You can grant the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Use the Privileges Associated with the DV_PUBLIC Role The following Oracle Database Vault objects are accessible through PL/SQL procedures and functions, described in "Oracle Database Vault Run-Time PL/SQL Procedures and Functions". These enable access control and Oracle Label Security processing in an Oracle database. PL/SQL factor functions, described in "Oracle Database Vault PL/SQL Factor Functions". For the There are no system privileges granted to the How Are GRANT and REVOKE Operations Affected by the DV_PUBLIC Role? Oracle Database Vault does not enable you to directly grant object privileges in the What Happens When Oracle Database Vault Security Is Disabled? The granting and revoking of all protected schema roles, including Appendix B, "Disabling and Enabling Oracle Database Vault," explains how disable and enable Oracle Database Vault. Oracle Database Vault prompts for two accounts during installation: Oracle Database Vault Owner and Oracle Database Vault Account Manager. You must supply an account name and password for the Oracle Database Vault Owner account during installation. Creating an Oracle Database Vault Account Manager is optional. The Oracle Database Vault Owner account is granted the The Oracle Database Vault Account Manager account is granted the If you choose not to create the Oracle Database Vault Account Manager account during installation, then both the Table 11-2 lists the Oracle Database Vault database accounts that are needed in addition to the accounts that you create during installation. Table 11-2 Database Accounts Used by Oracle Database Vault Several system and object privileges are provided to support Oracle Database Vault. The ability to create a session with this account is revoked at the end of the installation, and the account is locked. Owner of Oracle Database Vault schema and related objects A limited set of system privileges are provided to support Oracle Database Vault. The ability to create a session with this account is revoked at the end of the installation, and the account is locked. Owner of the Oracle Database Vault functions that are created to retrieve factor identities This account is created when you install Oracle Label Security by using the Oracle Universal Installer custom installation option. (It is not created when you install Oracle Database Vault.) Do not drop or re-create this account. If you plan to integrate a factor with an Oracle Label Security policy, you must assign this user as the owner of the realm that uses this factor. See "Using Oracle Database Vault Factors with Oracle Label Security Policies" for more information. Owner of the Oracle Label Security schema You can create different database accounts to implement the separation of duties requirements for Oracle Database Vault. Table 11-3 lists some model database accounts that can act as a guide. (The accounts listed in Table 11-3 serve as a guide to implementing Oracle Database Vault roles. These are not actual accounts that are created during installation.) Table 11-3 Model Oracle Database Vault Database Accounts Account that is the realm owner for the Run Have Grant privileges on the Select objects in the schema Monitor Oracle Database Vault activity Run reports on the Oracle Database Vault configuration Account for administration of database accounts and profiles. This account can: Create, alter, or drop users Create, alter, or drop profiles Grant the Grant the Note: This account cannot create roles, or grant the Account to serve as the access control administrator. This account can: Execute Have Monitor Oracle Database Vault activity Run reports on the Oracle Database Vault configuration Note: This account cannot directly update the Account for running Oracle Database Vault reports in the Oracle Database Vault Administration application. Oracle Database Vault provides a set of This section contains: The For example: Output similar to the following appears: See Adding Languages to Oracle Database Vault for a list of supported languages. The For example: Output similar to the following appears: The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears, assuming you have created only one factor identity: Related Views The You can use this view to resolve the identity for factors that are identified by other factors (for example, a domain) or for factors that have continuous domains (for example, Age or Temperature). For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The You can use this view to determine what factors contribute to the maximum session label for each policy using the For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: To find the rule sets that use specific rules, query the Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views The For example: Output similar to the following appears: Related Views You may need to disable Oracle Database Vault to perform upgrade tasks or correct erroneous configurations. You can reenable Oracle Database Vault after you complete the corrective tasks. Note: The following situations require you to disable Oracle Database Vault: The Oracle Database Vault user accounts have been inadvertently locked or their passwords forgotten. (See the tip under "Oracle Database Vault Accounts" for a guideline for avoiding this problem in the future.) A rule set associated with the You must perform maintenance tasks on Oracle Database Vault. You must install any of the Oracle Database optional products or features, such as Oracle Spatial, or Oracle Multimedia, by using Database Configuration Assistant (DBCA). You are about to install a third-party product, install an Oracle product, or perform an Oracle patch update whose installation may be prevented if Oracle Database Vault is running. You must archive the Oracle Database Vault audit trail. You can check if Oracle Database Vault is enabled or disabled by querying the Remember that the If Oracle Database Vault is enabled, the following output appears: To disable Oracle Database Vault: Stop the database, Database Control console process, and listener. UNIX: Ensure that the environment variables, For example: For Oracle RAC installations, shut down each database instance as follows: Windows: Stop the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Disable Oracle Database Vault as follows: UNIX: Run the following commands: Windows: In the Restart the database, Database Control console process, and listener. UNIX: Log in to SQL*Plus as user For example: For Oracle RAC installations, restart each database instance as follows: Windows: Restart the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with For Oracle RAC installations, repeat these steps for each node on which the database is installed. At this stage, Oracle Database Vault is disabled. You can perform the following types of activities: Use the Oracle Database Vault PL/SQL packages and functions. For example, to correct a login or Use the SYSTEM or SYS accounts to perform tasks such as creating or changing passwords, or locking and unlocking accounts. In addition to modifying regular database and administrative user accounts, you can modify passwords and the lock status of any of the Oracle Database Vault-specific accounts, such as users who have been granted the Perform the installation, upgrade, or other tasks that require security protections to be disabled. To enable Oracle Database Vault: Stop the database, Database Control console process, and listener. UNIX: Ensure that the environment variables, For example: For Oracle RAC installations, shut down each database instance as follows: Windows: Stop the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with Enable Oracle Database Vault as follows: UNIX: Run the following commands. The Windows: In the Restart the database, Database Control console process, and listener. UNIX: Log in to SQL*Plus as user For example: For Oracle RAC installations, restart each database instance as follows: Windows: Restart the database, Database Control console process, and listener from the Services tool in the Control Panel. The names of Oracle Database services begin with For Oracle RAC installations, repeat these steps for each node on which the database is installed.x @;yj Af`'s]jW` |0"rp0@`'3TІ
j`s@`z01PV H/EhDz-&HeE9eRG 0[Ǘ~p}t uYճ:' ^vYsktPP0#_5y*+gk` +@ 0\<0[{蛾껾{% { ~80zvO0I pO8df C =iBI@-{q UKo9
@& jZmr7 F ʀ8P;9P"Ps4@.6i8@[A $ 0Qg0YvN ^5dXǺM[dLP`VP*+@
%8v|xz|v|qmwC`wODllP7
j@{Lz;zp\@P0. y , $G&;<)Z{<+y ˾偺 `NVe Þpk>\+ .Bz E|lLeRPs
P!| I`Q6ȋG c@@K,z@6 ˕x }[C Zjq !@5i/<-s 7Z{ fIa! -Ng kj2푘baX [pRP|b /L l.+`f QPT`C ^;'yɖ;19,`tq ɡA11R{tYA7P
7,(-X,^1< t6 * Om{A a Y@V} c3PS @z`jg`zp /s 4Y 5RAYe:wY
689
\PŲMsI]I0k[ `p y?<` hpUm ߡ]@:"I N~m) fPN n,0EG~4 T@ b]GB6 rm%|VTpz ݢuZ5% ``p Z{-ʴ>( -7Ps-9e
@P׆t dNPx}8|~Zg˩pPZ 6g s !A MO~r=1md۩.
f pz4T@
.{Y`>}j > Ru^7~ ,ePi / v` 0 5 lR:XNM{5#M;Ti_~ S0Qig9p $01t}0SCQ|+*OCx&8$fN*0s`Z*9\I wJ jQ 6DPxW=_Cx`s \ КDUa{ uAu
fl.1Y@ ]㬟Wa_eoA
@
@i.YepVkc j` *FT Ib{)u5a 8 OE@x_>_C+` j@
85<0,P \D
C
4+ $f
~G
OsCj^~SV+ MV_I@y8d86@cCc
`Z%>ݿ+ eyTCCfy8@pIsI_6,%fʄv 0W!k0e͙ɓPk ֭#TB Ȩ9y ɲZhR/o ؓA"\i@. b d) Χ jA` S_VH%wyJ2tGH4 Q" 0c1 Kfe
ժ͊0J_͞;G,YEk3k̮ ̻V+v$aπ{+_)2*N ߕr3N ' x;ܦmϿh F_|~c,04$-Hm.6$h(,h"PF .b,P-KȠB6Lc
d+ . N\ %p HpG,8 p%=! 7z R<%Dj[H j @9rcU)̀X(P m <@ Rp`Cl hv ! @YP ( B &[ c E0]01 ZR8
5>pFYD2 A}Ja}U}}}PB s@m8 x !1guexc8&(HJL,RH1SQtZx\x^(`hGb8 .XTqFQ+Ԇ@pHr8tv>x
z2чBOAAbMA epHb` s
Zp؊(=iALP@8i #qVڐrc !d2zȄcEP؍QLihA@aKXF0%P``^5P' D H)^ 5\@fӸ}
MtXfpJ0 %9r"q F
n( 6
1;P=`'-Q s' VR`rXuUc 3 ;b X S< P ` @0yc 2c6 "8p& ! Zjr `B&p!Ѓ p JlP8|4Ŕ r GP GQpِ@pL@:` h2c1ޠQ6 6.
!PUH5.pgykH 21""С @I*p p4ӁQDHP0k]=1`D j) mi):)}rm 0S
QW'P7 FP!OF m0
|5~b g &FSl [2^L L ^`Be J , eRf0qёk=HR.ܰ U58 WRy5B'0`0ȶc@B
h
XLNbyW@
S@e
`xjZlʖy= tFDCd$IgLִܻ)h>~ ]nJ 9(䅛K*əHr\}w[fTh>s%dq~.Sr(S wی8pO
fȳgH'. ]3O{^r<1Pb7y s_3;
PKNR{ PK )A , OEBPS/img_text/sec_policy_changes_detail.htmg
10 DBA Operations in an Oracle Database Vault Environment
Using Oracle Database Vault with Oracle Enterprise Manager
Setting the Database Vault Administrator URL in Oracle Enterprise Manager
DV_OWNER or DV_ADMIN role, that you are also an Enterprise Manager administrator.OPERATOR privilege on the target database.
https://myserver.us.example.com:1148/dva
Propagating Oracle Database Vault Policies to Other Databases
DV_OWNER or DV_ADMIN role.
Description of the illustration dv_oem.gif
Description of the illustration dv_oem2.gif
Using Enterprise Manager Grid Control Alerts for Oracle Database Vault Policies
DV_OWNER, DV_ADMIN, or DV_SECANALYST role. The alerts are as follows:DV_SECANALYST role) to monitor violation attempts on the Database Vault database. This user can select the realms to be affected by the alert and filter these realms based on the different types of attempts by using error codes. You can enable this metric from the Metrics and Policy Settings page. By default, the attempted realm violations are collected every 24 hours.
Using Oracle Database Vault-Specific Reports in Enterprise Manager Grid Control
DV_OWNER, DV_ADMIN, or DV_SECANALYST role.
Changing the DBSNMP Account Password in an Oracle Database Vault Environment
DBSNMP user account, you must revoke the DV_MONITOR role from this account. In an Oracle Database Vault environment, the DBSNMP user account is granted the DV_MONITOR role. (The DBSNMP user can change his or her own password directly, without having to have the DV_MONITOR role revoked first.)DBSNMP user password:DV_OWNER role.DV_MONITOR role from the DBSNMP user account.DV_ACCTMGR role and then change the DBSNMP user account password.DV_OWNER user and then grant the DV_MONITOR role back to the DBSNMP user account.ALTER USER privilege, and then modify the DBSNMP password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.
Using Oracle Data Pump in an Oracle Database Vault Environment
About Using Oracle Data Pump in an Oracle Database Vault Environment
EXP and IMP utilities if Oracle Database Vault is enabled.)DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure. This authorization applies to both the EXPDP and IMPDP utilities. Later on, you can revoke this authorization by using the DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER procedure.DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, you must grant this user the DV_OWNER role.
Granting a Database Administrator Authorization to Use Oracle Data Pump
DV_OWNER or DV_ADMIN role.EXP_FULL_DATABASE and IMP_FULL_DATABASE roles, which are required for using Oracle Data Pump.
SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS
WHERE GRANTED_ROLE LIKE '%FULL%';
dp_mgr to export and import objects for an entire database:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('dp_mgr');
dp_mgr's activities to a specific schema or even a table, as shown in the following examples:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, the authorization is stored as a rule in the Allow Oracle Data Pump Operation rule set, described in "Default Rule Sets". You can refer to this rule set by querying the DVSYS.DBA_DV_RULE_SET view if you want to check the user's authorizations.dp_mgr wants to export the SCOTT schema. However, the SCOTT schema is associated with the SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S table, and the SYSMAN schema is protected by a realm. So, before user dp_mgr can export the SCOTT schema, he must be authorized as follows:
BEGIN
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'SYSMAN Realm',
grantee => 'DP_MGR',
auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT);
END;
/
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR','SYSMAN');
DV_OWNER role.
GRANT DV_OWNER TO dp_mgr;
DVSYS.DBA_DV_RULE_SET data dictionary view as follows:
SELECT ENABLED FROM DVSYS.DBA_DV_RULE_SET
WHERE RULE_SET_NAME = 'Allow Oracle Data Pump Operation';
Guidelines for Exporting or Importing Data in an Oracle Database Vault Environment
DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, but you can use either of the following methods to accomplish this task:DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedures for each schema or table, and then specify the list of these objects in the SCHEMAS or TABLES parameter of the expdp and impdp utilities.DVSYS schema, so ensure that the user has been granted the DV_OWNER role. For detailed information about Oracle Data Pump, see Oracle Database Utilities.
Revoking Authorization from Databases Administrators Who Are Using Data Pump
DV_OWNER role, optionally revoke this role.
REVOKE DV_OWNER FROM dp_mgr;
DVSYS.DBA_DV_RULE_SET data dictionary view and then make a note of the user's authorizations that have been defined in the Allow Oracle Data Pump Operation rule set.
SELECT RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET_RULE
WHERE RULE_SET_NAME = 'Allow Oracle Data Pump Operation';
dp_mgr to perform export and import operations on the entire database, a rule defining this authorization appears in the list of rule expressions in the Allow Oracle Data Pump Operation rule set.DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER command.
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR');
dp_mgr authorization over the entire database, then the following commands will not work:
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
SYSMAN.AQ$_MGMT_NOTIFY_QTABLE_S table objects, as described in Step 4 under "Granting a Database Administrator Authorization to Use Oracle Data Pump"), then remove the realm authorization for this user.
BEGIN
DVSYS.DBMS_MACADM.DELETE_AUTH_FROM_REALM(
realm_name => 'SYSMAN Realm',
grantee => 'DP_MGR');
END;
/
Scheduling Database Jobs in an Oracle Database Vault Environment
About Scheduling Database Jobs in an Oracle Database Vault Environment
DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure. This authorization applies to both background and foreground jobs. For background jobs, the authorization applies to the last user who created or modified the job. In addition, ensure that the schema owner (the protected schema in which the job is created) authorized to the realm.DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER procedure. If the schema is not protected by a realm, then you do not need to run the DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure for the user.
Granting a Job Scheduling Administrator Authorization for Oracle Database Vault
DV_OWNER or DV_ADMIN role.CREATE JOB, CREATE ANY JOB, CREATE EXTERNAL JOB, EXECUTE ANY PROGRAM, EXECUTE ANY CLASS, MANAGE SCHEDULER. The DBA and SCHEDULER_ADMIN roles provide these privileges; however, when Oracle Database Vault is enabled, the privileges are revoked from these roles.
SELECT GRANTEE, PRIVILEGE FROM DBA_SYS_PRIVS
WHERE PRIVILEGE IN ('CREATE JOB', 'CREATE ANY JOB');
job_mgr to schedule jobs for any schema in the database:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
job_mgr's activities to a specific schema, as follows:
EXEC DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure, the authorization is stored as a rule in the Allow Scheduler Job rule set, described in "Default Rule Sets". You can refer to this rule set by querying the DVSYS.DBA_DV_RULE_SET view if you want to check the user's authorizations.DVSYS.DBA_DV_JOB_AUTH data dictionary view as follows:
SELECT GRANTEE,OBJECT_OWNER FROM DVSYS.DBA_DV_JOB_AUTH
WHERE GRANTEE = 'user_name';
Revoking Authorization from Job Scheduling Administrators
DVSYS.DBA_DV_JOB_AUTH data dictionary view and then make a note of the user's authorizations that have been defined in the Allow Scheduler Job rule set.
SELECT GRANTEE FROM DVSYS.DBA_DV_JOB_AUTH;
job_mgr to perform schedule database jobs for the entire database, a rule defining this authorization appears in the list of rule expressions in the Allow Scheduler Job rule set.DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER command.
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');
job_mgr authorization over the entire database, then the following command will not work:
EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
Using Oracle Database Vault with Oracle Recovery Manager
Using Oracle Streams in an Oracle Database Vault Environment
DV_STREAMS_ADMIN role in order to configure the Oracle Streams capture process. See "DV_STREAMS_ADMIN Oracle Streams Configuration Role" for more information.
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
DBMS_MACADM.ADD_AUTH_TO_REALM procedure.
Using XStream in an Oracle Database Vault Environment
DV_XSTREAM_ADMIN role in order to configure the XStream. See "DV_XSTREAM_ADMIN XStream Administrative Role" for more information.
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
DBMS_MACADM.ADD_AUTH_TO_REALM procedure.
Using Oracle GoldenGate in an Oracle Database Vault Environment
DV_GOLDENGATE_ADMIN role in order to configure the Oracle GoldenGate. See "DV_GOLDENGATE_ADMIN Oracle GoldenGate Administrative Role" for more information.DV_GOLDENGATE_REDO_ACCESS role if you want to use the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER method to access redo logs. See "DV_GOLDENGATE_REDO_ACCESS Oracle GoldenGate Redo Log Access Role" for more information.
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
DBMS_MACADM.ADD_AUTH_TO_REALM procedure.
Using Data Masking in an Oracle Database Vault Environment
About Data Masking in an Oracle Database Vault Enabled Database
SELECT_CATALOG_ROLE and DBA roles can perform data masking. However, with Database Vault, users must have additional privileges. This section describes three ways that you can use to enable users to mask data in Database Vault-protected objects.
ORA-47400: Command Rule violation for string on string
ORA-47401: Realm violation for string on string.
ORA-47408: Realm violation for the EXECUTE command
ORA-47409: Command Rule violation for the EXECUTE command
ORA-01301: insufficient privileges
Adding Data Masking Users to the Data Dictionary Realm Authorizations
SYS and SYSTEM. (See "Default Realms" for a full list of these schemas.) It also controls the ability to grant system privileges and database administrator roles. If you add users to the Data Dictionary realm, and assuming these users already have the privileges associated with the Oracle Data Dictionary, then these users will have these same privileges in a Database Vault environment. Therefore, if you do add a user to this realm, ensure that this user is a trusted user.
BEGIN
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'Data Dictionary Realm',
grantee => 'DBA_JSMITH',
auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT);
END;
/
Giving Users Access to Tables or Schemas That They Want to Mask
DBA_JSMITH authorization for the HR.EMPLOYEES table, which is protected by a realm called Business Apps Realm:
BEGIN
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'Business Apps Realm',
grantee => 'DBA_JSMITH',
auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT;
END;
/
Creating a Command Rule to Enable Data Masking Privileges
CREATE TABLE, SELECT TABLE, ALTER TABLE, and DROP TABLE privileges for the masking objects and if there are any dependent objects to be created, the user must have the appropriate privileges such as CREATE PACKAGE, CREATE TRIGGER, and so on.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Is HDRISCOLL or DBA_JSMITH User',
rule_expr =>'USER IN(''HDRISCOLL'',''DBA_JSMITH'')';
END;
/
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE_SET(
rule_set_name => 'Allow Data Masking',
description => 'Allows users HDRISCOLL and DBA_JSMITH access',
enabled => 'Y',
eval_options => 1,
audit_options => 1,
fail_options => 1,
fail_message => 'You do not have access to this object.',
fail_code => 20461,
handler_options => 0,
is_static => TRUE);
END;
/
BEGIN
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET(
rule_set_name => 'Allow Data Masking',
rule_name => 'Is HDRISCOLL or DBA_JSMITH User'),
rule_order => 1);
END;
/
BEGIN
DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE(
command => 'CREATE TABLE',
rule_set_name => 'Allow Data Masking',
object_owner => 'HR',
object_name => 'EMPLOYEES',
enabled => DBMS_MACUTL.G_YES);
END;
/
PK PK )A OEBPS/img_text/home_page.htma
PKQڛȹ PK )A OEBPS/cfcmdaut.htm
D Oracle Database Vault Security Guidelines
Separation of Duty Guidelines
How Oracle Database Vault Handles Separation of Duty
Defining Separate Tasks in an Oracle Database Vault Environment
DV_ACCTMGR role provides these privileges.DV_OWNER and DV_ADMIN roles provide these privileges. (For an in-depth look at how the Oracle Database Vault roles provide for separation of duty, see "Oracle Database Vault Roles".)
Creating a Separation of Duty Matrix
User, Process or Application Account Creation Database Administration Security Administrator SYSDBA Backup Tuning Patching Monitoring
...
JSMITH
SHARDY
PKESTNER
RTYLER
SANDERSON
SYSTEM
RMAN
Identifying and Documenting the Tasks of Users Who Access the Database System
http://www.oracle.com/technetwork/database/options/database-vault/index-085211.html
Protection Type Authorized with Rule Set SYSADM PSFTDBA SYSTEM DBA
Managing Oracle Database Administrative Accounts
Using the SYSTEM User Account for General Administrative Uses
SYSTEM account for general database administrative purposes, create named database administrative accounts for your database administrators. Doing so increases accountability for administrative actions in the database.
Using the SYSTEM Schema for Application Tables
SYSTEM schema, then you should add the SYSTEM account to your realm authorizations for these tables so that these applications can continue to work normally. You can place restrictions on the SYSTEM account to increase or fine-tune security for these applications. For example, you can create a Database Vault rule set to restrict the SYSTEM user's access to specific IP addresses.
Limiting the SYSDBA Privilege
SYSDBA privilege only to users who must connect using this privilege when absolutely necessary and for applications that still require SYSDBA access, such as Oracle Recovery Manager (RMAN) and mandatory patching processes. For all other cases, create named database accounts to perform daily database administration.
Managing Root and Operating System Access
sudo to the oracle software owner when needed. With sudo, you can control which specific command each personalized user can execute. Be sure to prevent the use of the make, relink, gdb, or other commands that could potentially harm the database, for these users. However, if an administrative user must install a patch or perform some other emergency operation, you can enable the make and relink commands for a limited time, and audit their actions during this period.
Accounts and Roles Trusted by Oracle Database Vault
Role or Privilege Status Description
DV_ACCTMGR role
DV_OWNER role
DV_ACCTMGR role alter this user.
SYSDBA privilege
SYSDBA.
SYSOPER privilege
SYS only by default. See "Managing SYSOPER Access" for guidelines on managing SYSOPER.
<9A/a>
Accounts and Roles That Should be Limited to Trusted Individuals
Managing Users with Root Access to the Operating System
Managing the Oracle Software Owner
Managing SYSDBA Access
SYSDBA privilege is a trusted privilege in Oracle Database Vault. Grant this privilege to trusted users only.
Managing SYSOPER Access
SYSOPER access to operating system users in the SYSOPER group and the user SYS. It prevents SYSOPER from modifying the Oracle data dictionary directly. The SYSOPER privilege has limited privileges within the database, but individuals with this role can start and shut down the Oracle database. Only grant the SYSOPER privilege to trusted individuals.
Guidelines for Using Oracle Database Vault in a Production Environment
Secure Configuration Guidelines
Security Considerations for the UTL_FILE and DBMS_FILE_TRANSFER Packages
UTL_FILE package is owned by SYS and granted to PUBLIC. However, a user must have access to the directory object to manipulate the files in that operating system directory. You can configure the UTL_FILE package securely; see Oracle Database PL/SQL Packages and Types Reference for more information.DBMS_FILE_TRANSFER package is owned by SYS and granted to the EXECUTE_CATALOG_ROLE. Users with EXECUTE access on this package can move files from one location to another on the same file system. They also can move files between database instances, including databases on remote systems.DBMS_FILE_TRANSFER package, do the following:EXECUTE privilege from the DBMS_FILE_TRANSFER package and grant the EXECUTE privilege only to trusted users who need it.CREATE DATABASE LINK and CREATE DIRECTORY SQL statements. See "Creating and Editing a Command Rule" for information on creating command rules by using Oracle Database Vault Administrator.DVSYS.DBMS_MACADM package to create command rules that limit and enable access to the CREATE DATABASE LINK statement, which is used to establish connections to remote databases. To use this method, log in to SQL*Plus using the Oracle Database Vault Owner account.
BEGIN
DBMS_MACADM.CREATE_COMMAND_RULE (
command => 'CREATE DATABASE LINK',
rule_set_name => 'Disabled',
object_owner => '%',
object_name => '%',
enabled => DBMS_MACUTL.G_YES);
END;
/
COMMIT;
CREATE DATABASE LINK statement, the Oracle Database Vault owner can reenable it from Oracle Database Vault Administrator or issue the following commands in SQL*Plus.
BEGIN
DBMS_MACADM.UPDATE_COMMAND_RULE (
command => 'CREATE DATABASE LINK',
rule_set_name => 'Enabled',
object_owner => '%',
object_name => '%',
enabled => DBMS_MACUTL.G_YES);
END;
/
COMMIT;
CREATE DIRECTORY.
-- Disable access to CREATE DIRECTORY
BEGIN
DBMS_MACADM.CREATE_COMMAND_RULE (
command => 'CREATE DIRECTORY',
rule_set_name => 'Disabled',
object_owner => '%',
object_name => '%',
enabled => dbms_macutl.g_yes);
END;
/
COMMIT;
-- Enable access to CREATE DIRECTORY
BEGIN
dbms_macadm.update_command_rule (
command => 'CREATE DIRECTORY',
rule_set_name => 'Enabled',
object_owner => '%',
object_name => '%',
enabled => dbms_macutl.g_yes);
END;
/
COMMIT;
Security Considerations for the Recycle Bin
ALTER SYSTEM command rule prevents the recycle bin feature from being enabled, but if the recycle bin is already enabled, it cannot prevent you from disabling it. When the recycle bin feature is enabled, realm-protected objects that are dropped go into the recycle bin. Once there, the objects are no longer protected by the realm. The exception is objects in the DVSYS schema: To keep DVSYS as a protected schema, you cannot drop its objects, even if the recycle bin is disabled. For better security for other realms, you should disable the recycle bin.
SELECT * FROM RECYCLEBIN;
SELECT * FROM USER_RECYCLEBIN;
PURGE SQL statement:
PURGE RECYCLEBIN;
PURGE USER_RECYCLEBIN;
SYS using the SYSDBA privilege.
sqlplus sys as sysdba
Enter password: password
SHOW PARAMETER RECYCLEBIN
ALTER SYSTEM SET RECYCLEBIN=OFF SCOPE=SPFILE;
SHUTDOWN IMMEDIATE
STARTUP
Security Considerations for the CREATE ANY JOB Privilege
CREATE ANY JOB privilege has been revoked from the DBA and the SCHEDULER_ADMIN roles. Ensure that this change does not affect your applications.
Security Considerations for the CREATE EXTERNAL JOB Privilege
CREATE EXTERNAL JOB privilege was introduced in Oracle Database 10g Release 2 (10.2). It is required for database users who want to execute jobs that run on the operating system outside the database. By default, this privilege is granted to all users who have been granted the CREATE JOB privilege. For greater security, revoke this privilege from users who do not need it and then grant it only to those users who do need it.
Security Considerations for the LogMiner Packages
EXECUTE_CATALOG_ROLE no longer has the EXECUTE privilege granted by default on the following LogMiner packages:DBMS_LOGMNRDBMS_LOGMNR_DDBMS_LOGMNR_LOGREP_DICTDBMS_LOGMNR_SESSION
Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges
ALTER SYSTEM and ALTER SESSION privileges. These privileges can be granted by the user SYS when connected as SYSDBA and by any user granted the DBA role.ALTER SYSTEM statement. You can use Oracle Database Vault Administrator to create a rule and add it to a rule set. You should grant the ALTER SESSION privilege only to trusted users. (For example, the ALTER SESSION statement can enable tracing.)ALTER SYSTEM privilege from issuing the command ALTER SYSTEM DUMP. Log in to SQL*Plus as the Oracle Database Vault Owner when you create this command rule.
CONNECT amalcolm_dvacctmgr
Enter password: password
BEGIN
DBMS_MACADM.CREATE_RULE('NO_SYSTEM_DUMP',
'(INSTR(UPPER(DVSYS.DV_SQL_TEXT),''DUMP'') = 0)');
END;
/
EXEC DBMS_MACADM.ADD_RULE_TO_RULE_SET
('Allow Fine Grained Control of System Parameters','NO_SYSTEM_DUMP');
COMMIT;
PK{z p PK )A OEBPS/apis_dbms_macutl.htm
6 Configuring Command Rules
What Are Command Rules?
SELECT, ALTER SYSTEM, database definition language (DDL), and data manipulation language (DML) statements that affect one or more database objects. To customize and enforce the command rule, you associate it with a rule set, which is a collection of one or more rules. The command rule is enforced at run time. Command rules affect anyone who tries to use the SQL statements it protects, regardless of the realm in which the object exists. If you want to protect realm-specific objects, see "Defining Realm Authorization".ALTER SYSTEM and CONNECT statements.DROP TABLE statement.DROP TABLE statement with a specific table included in the command rule definition.CONNECT event to permit or deny sessions after the usual steps–user authentication process, factor initialization, and Oracle Label Security integration–are complete.CREATE TABLE, DROP TABLE, and ALTER TABLE in the BIZAPP schema to be authorized after business hours, but not during business hours.
Default Command Rules
SQL Statement Object Name Rule Set Name
ALTER PROFILE
ALTER SYSTEM
ALTER USER
CREATE PROFILE
CREATE USER
DROP PROFILE
DROP USER
ALTER PROFILEALTER USERCREATE PROFILECREATE USERDROP PROFILEDROP USERCREATE USER command rule ensures that a user who tries to run a CREATE USER statement has the DV_ACCTMGR role.
SQL Statements That Can Be Protected by Command Rules
ALTER CLUSTERCREATE CONTEXTDROP DIRECTORYALTER DIMENSIONCREATE DATABASE LINKDROP FUNCTIONALTER FUNCTIONCREATE DIMENSIONDROP INDEXALTER INDEXCREATE DIRECTORYDROP INDEXTYPEALTER INDEXTYPECREATE FUNCTIONDROP JAVAALTER JAVACREATE INDEXDROP LIBRARYALTER OPERATORCREATE INDEXTYPEDROP OPERATORALTER OUTLINECREATE JAVADROP OUTLINEALTER PACKAGECREATE LIBRARYDROP PACKAGEALTER PACKAGE BODYCREATE OPERATORDROP PACKAGE BODYALTER PROCEDURECREATE OUTLINEDROP PROCEDUREALTER PROFILECREATE PACKAGEDROP PROFILEALTER RESOURCE COSTCREATE PACKAGE BODYDROP ROLEALTER ROLECREATE PROCEDUREDROP ROLLBACK SEGMENTALTER ROLLBACK SEGMENTCREATE PROFILEDROP SEQUENCEALTER SEQUENCECREATE ROLEDROP SNAPSHOTALTER SNAPSHOTCREATE ROLLBACK SEGMENTDROP SNAPSHOT LOGALTER SNAPSHOT LOGCREATE SCHEMADROP TABLEALTER SYNONYMCREATE SEQUENCEDROP TABLESPACEALTER SYSTEMCREATE SNAPSHOTDROP TRIGGERALTER TABLECREATE SNAPSHOT LOGDROP TYPEALTER TABLESPACECREATE SYNONYMDROP TYPE BODYALTER TRIGGERCREATE TABLEDROP USERALTER TYPECREATE TABLESPACEDROP VIEWALTER TYPE BODYCREATE TRIGGEREXECUTEALTER USERCREATE TYPEGRANTALTER VIEWCREATE TYPE BODYINSERTANALYZE CLUSTERCREATE USERNOAUDITANALYZE INDEXCREATE VIEWRENAMEANALYZE TABLEDELETEREVOKEASSOCIATE STATISTICSDISASSOCIATE STATISTICSSELECTAUDITDROP CLUSTERTRUNCATE CLUSTERCOMMENTDROP CONTEXTTRUNCATE TABLECONNECTDROP DATABASE LINKUPDATECREATE CLUSTERDROP DIMENSION
Creating and Editing a Command Rule
DV_OWNER or DV_ADMIN role.% to select all owners. (However, you cannot use wildcard characters with text, such as EM% to select all owners whose names begin in EM.) This attribute is mandatory for all SQL statements that operate on objects within a specific schema. See "SQL Statements That Can Be Protected by Command Rules" for a list of supported SQL statements.SELECT, INSERT, UPDATE, DELETE, and EXECUTE statements are not allowed for a selection of all (%) or the SYS and DVSYS schemas.EMP_% to specify all tables beginning with the characters EMP_). This attribute is mandatory, if you selected an object owner from the Object Owner list.
Deleting a Command Rule
How Command Rules Work
SELECT, DDL, or DML statement that affects objects within a realm.SELECT, DDL, or DML statement is issued:SELECT, DDL, and DML statements, multiple command rules may apply because the object owner and object name support wildcard notation.SELECT privilege on the table. (Only the rule set has been disabled, not the command rule itself.)
Tutorial: Using a Command Rule to Control Table Creations by a User
About This Tutorial
SCOTT to create tables.
Step 1: Connect as User SCOTT and Create a Table
SCOTT.
sqlplus scott
Enter password: password
SCOTT account is locked and expired, then log in as the Database Vault Account Manager and unlock SCOTT and create a new password. For example:
sqlplus amalcolm_dvacctmgr
Enter password: password
ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
CONNECT SCOTT
Enter password: password
SCOTT, create a table.
CREATE TABLE t1 (num NUMBER);
DROP TABLE t1;
SCOTT can create and drop tables. Do not exit SQL*Plus yet, and remain connected as SCOTT. You must use it later on when SCOTT tries to create another table.
Step 2: Connect Using the DVOWNER or DV_ADMIN Role and Create a Command Rule
DV_OWNER or DV_ADMIN role.SCOTT schema.SCOTT is prevented from creating tables.SCOTT is prevented from creating tables, even though he is still in the same user session he wasp% in a moment ago, before you created the CREATE TABLE command rule.
Step 3: Test the Command Rule
SCOTT.
CONNECT SCOTT
Enter password: password
CREATE TABLE t1 (num NUMBER);
ORA-47400: Command Rule violation for create table on SCOTT.T1
SCOTT is no longer allowed to create tables, even in his own schema.SCOTT, try creating the table again.
CREATE TABLE t1 (num NUMBER);
Table created.
SCOTT is once again permitted to create tables. (Do not exit SQL*Plus.)
Step 4: Remove the Components for this Tutorial
SCOTT and remove the t1 table.
DROP TABLE t1;
SCOTT account to be available, then connect as the Database Vault Account Manager and enter the following ALTER USER statement:
CONNECT amalcolm_dvacctmgr
Enter password: password
ALTER USER SCOTT ACCOUNT LOCK PASSWORD EXPIRE;
Guidelines for Designing Command Rules
SELECT statements from occurring on specific schema objects, then design multiple command rules to stop the SELECT statements on those specific schema objects, rather than creating a general command rule to prevent SELECT statements in the schema level.CONNECT event, be careful to include logic that does not inadvertently lock out the Oracle Database Vault Owner or Administrator.DV_ADMIN or DV_OWNER role) log in, set the rule set to Enabled, turn on Auditing on Success or Failure for the default rule set named Enabled, and then set the command rule back to its original rule set when the task is complete.
How Command Rules Affect Performance
Statspack, and TKPROF. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Database Control, refer to its online Help. Oracle Database Performance Tuning Guide describes the Statspack and TKPROF utilities.
Related Reports and Data Dictionary View
Report Description
DBA_DV_COMMAND_RULE data dictionary view to find the SQL statements that are protected by command rules. See "DBA_DV_COMMAND_RULE View" for more information.
PKp PK )A OEBPS/cfrealms.htm
14 Using the DVSYS.DBMS_MACUTL Package
About the DVSYS.DBMS_MACUTL Package
DVSYS.DBMS_MACUTL package provides a set of general purpose utility procedures and functions that you can use throughout the application code you write for Oracle Database Vault. This package is available to all users.
DVSYS.DBMS_MACUTL Constants
DVSYS.DBMS_MACUTL Listing of Constants
DVSYS.DBMS_MACUTL package. You can use these constants with any of the Oracle Database Vault PL/SQL packages. Many of these constants have equivalents in the Oracle Database Vault package. For example, the enabled parameter, which is available in several procedures, can accept either Y (for Yes) or the constant G_YES. Choosing one over the other is a matter of personal preference. They both have the same result.
Examples of Using the DVSYS.DBMS_MACUTL Constants
G_YES and G_REALM_AUDIT_FAIL DBMS_MACUTL constants when creating a realm.
BEGIN
DVSYS.DBMS_MACADM.CREATE_REALM(
realm_name => 'Performance Statistics Realm',
description => 'Realm to measure performance',
enabled => DVSYS.DBMS_MACUTL.G_YES,
audit_options => DVSYS.DBMS_MACUTL.G_REALM_AUDIT_FAIL);
END;
/
DVSYS.DBMS_MACUTL constants when creating a rule set.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE_SET(
rule_set_name => 'Limit_DBA_Access',
description => 'DBA access through predefined processes',
enabled => 'Y',
eval_options => DBMS_MACUTL.G_RULESET_EVAL_ALL,
audit_options => DBMS_MACUTL.G_RULESET_AUDIT_FAIL,
fail_options => DVSYS.DBMS_MACUTL.G_RULESET_FAIL_SHOW,
fail_message => 'Rule Set Limit_DBA_Access has failed.',
fail_code => 20000,
handler_options => DBMS_MACUTL.G_RULESET_HANDLER_FAIL,
handler => 'dbavowner.email_alert');
END;
/
BEGIN
DVSYS.DBMS_MACADM.CREATE_FACTOR(
factor_name => 'Sector2_DB',
factor_type_name => 'Instance',
description => ' ',
rule_set_name => 'DB_access',
get_expr => 'UPPER(SYS_CONTEXT(''USERENV'',''DB_NAME''))',
validate_expr => 'dbavowner.check_db_access',
identify_by => DBMS_MACUTL.G_IDENTIFY_BY_FACTOR,
labeled_by => DVSYS.DBMS_MACUTL.G_LABELED_BY_SELF,
eval_options => DVSYS.DBMS_MACUTL.G_EVAL_ON_SESSION,
audit_options => DBMS_MACUTL.G_AUDIT_ALWAYS,
fail_options => DVSYS.DBMS_MACUTL.G_FAIL_SILENTLY);
END;
/
Procedures and Functions Within the DVSYS.DBMS_MACUTL Package
DVSYS.DBMS_MACUTL package. You can use these procedures or functions as standalone code, or within rule expressions. The examples in this section show a mixture of using both.
Procedure or Function Descriptions
CHECK_DVSYS_DML_ALLOWED Procedure
CHECK_DVSYS_DML_ALLOWED procedure verifies that public packages are not being bypassed by users updating the Oracle Database Vault configuration.
DVSYS.DBMS_MACUTL.CHECK_DVSYS_DML_ALLOWED(
p_user IN VARCHAR2 DEFAULT USER);
Parameter Description
p_user
DBA_USERS: Finds available users for the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".DVSYS.DBA_DV_ROLE: Finds existing secure application roles used in privilege management. See "DBA_DV_ROLE View".SYSTEM fails the check:
EXEC DVSYS.DBMS_MACUTL.CHECK_DVSYS_DML_ALLOWED('system');
ERROR at line 1:
ORA-47920: Authorization failed for user system to perform this operation
ORA-06512: at "DVSYS.DBMS_MACUTL", line 23
ORA-06512: at "DVSYS.DBMS_MACUTL", line 372
ORA-06512: at "DVSYS.DBMS_MACUTL", line 508
ORA-06512: at "DVSYS.DBMS_MACUTL", line 572
ORA-06512: at line 1
lbrown_dvowner, who has the DV_OWNER role, passes the check:
EXEC DVSYS.DBMS_MACUTL.CHECK_DVSYS_DML_ALLOWED('lbrown_dvowner');
PL/SQL procedure successfully completed.
GET_CODE_VALUE Function
GET_CODE_VALUE function finds the value for a code within a code group, and then returns a VARCHAR2 value.
DVSYS.DBMS_MACUTL.GET_CODE_VALUE(
p_code_group IN VARCHAR2,
p_code IN VARCHAR2)
RETURN VARCHAR2;
Parameter Description
p_code_group
AUDIT_EVENTS or BOOLEAN).DVSYS.DBA_DV_CODE view, described in "DBA_DV_CODE View".
p_code
DVSYS.DBA_DV_CODE view.
BEGIN
DVSYS.DBMS_MACADM.CREATE_RULE(
rule_name => 'Get Label Algorithm for Maximum Level/Union/Null',
rule_expr => 'DVSYS.DBMS_MACUTL.GET_CODE_VALUE(''LABEL_ALG'', ''HUN'') = ''Union''');
END;
/
GET_SECOND Function
GET_SECOND function returns the seconds in Oracle SS (seconds) format (00–59), and then returns a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_SECOND(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
59).SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
seconds number;
BEGIN
seconds := DVSYS.DBMS_MACUTL.GET_SECOND(TO_DATE('03-APR-2009 6:56 PM',
'dd-mon-yyyy hh:mi PM'));
DBMS_OUTPUT.PUT_LINE('Seconds: '||seconds);
END;
/
Seconds: 56
GET_MINUTE Function
GET_MINUTE function returns the minute in Oracle MI (minute) format (00–59), in a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_MINUTE(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
30, as in 2:30).SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
minute number;
BEGIN
minute := DVSYS.DBMS_MACUTL.GET_MINUTE(SYSDATE);
DBMS_OUTPUT.PUT_LINE('Minute: '||minute);
END;
/
Minute: 17
GET_HOUR Function
GET_HOUR function returns the hour in Oracle HH24 (hour) format (00–23), in a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_HOUR(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
14 for 2:00 p.m.)SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
hours number;
BEGIN
hours := DVSYS.DBMS_MACUTL.GET_HOUR(SYSDATE);
DBMS_OUTPUT.PUT_LINE('Hour: '||hours);
END;
/
Hour: 12
GET_DAY Function
GET_DAY function returns the day in Oracle DD (day) format (01–31), in a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_DAY(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
01 for the first day of the month).SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
day number;
BEGIN
day := DVSYS.DBMS_MACUTL.GET_DAY(SYSDATE);
DBMS_OUTPUT.PUT_LINE('Day: '||day);
END;
/
Day: 3
GET_MONTH Function
GET_MONTH function returns the month in Oracle MM (month) format (01–12), in a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_MONTH(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
08 for the month of August).SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
month number;
BEGIN
month := DVSYS.DBMS_MACUTL.GET_MONTH(SYSDATE);
DBMS_OUTPUT.PUT_LINE('Month: '||month);
END;
/
Month: 4
GET_YEAR Function
GET_YEAR function returns the year in Oracle YYYY (year) format (0001–9999), in a NUMBER value. It is useful for rule expressions based on time data.
DVSYS.DBMS_MACUTL.GET_YEAR(
p_date IN DATE DEFAULT SYSDATE)
RETURN NUMBER;
Parameter Description
p_date
1984).SYSDATE function to retrieve the current date and time set for the operating system on which the database resides.
SET SERVEROUTPUT ON
DECLARE
year number;
BEGIN
year := DVSYS.DBMS_MACUTL.GET_YEAR(SYSDATE);
DBMS_OUTPUT.PUT_LINE('Year: '||year);
END;
/
IS_ALPHA Function
IS_ALPHA function checks whether the character is alphabetic, and then returns a BOOLEAN value. IS_ALPHA returns TRUE if the character is alphabetic.
DVSYS.DBMS_MACUTL.IS_ALPHA(
c IN VARCHAR2)
RETURN BOOLEAN;
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.IS_ALPHA('z')
THEN DBMS_OUTPUT.PUT_LINE('The alphabetic character was found');
ELSE
DBMS_OUTPUT.PUT_LINE('No alphabetic characters today.');
END IF;
END;
/
IS_DIGIT Function
IS_DIGIT function checks whether the character is numeric, and then returns a BOOLEAN value. IS_DIGIT returns TRUE if the character is a digit.
DVSYS.DBMS_MACUTL.IS_DIGIT(
c IN VARCHAR2)
RETURN BOOLEAN;
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.IS_DIGIT('7')
THEN DBMS_OUTPUT.PUT_LINE('The numeric character was found');
ELSE
DBMS_OUTPUT.PUT_LINE('No numeric characters today.');
END IF;
END;
/
IS_DVSYS_OWNER Function
IS_DVSYS_OWNER function determines whether a user is authorized to manage the Oracle Database Vault configuration, and then returns a BOOLEAN value. IS_DVSYS_OWNER returns TRUE if the user is authorized.
DVSYS.DBMS_MACUTL.IS_DVSYS_OWNER(
p_user IN VARCHAR2 DEFAULT USER)
RETURN BOOLEAN;
Parameter Description
p_user
DBA_USERS: Finds available users for the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".DVSYS.DBA_DV_ROLE: Finds existing secure application roles used in privilege management. See "DBA_DV_ROLE View".
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.IS_DVSYS_OWNER('PSMITH')
THEN DBMS_OUTPUT.PUT_LINE('PSMITH is authorized to manage Database Vault.');
ELSE
DBMS_OUTPUT.PUT_LINE('PSMITH is not authorized to manage Database Vault.');
END IF;
END;
/
IS_OLS_INSTALLED Function
IS_OLS_INSTALLED function returns an indicator regarding whether Oracle Label Security is installed, and then returns a TRUE or FALSE BOOLEAN value. If Oracle Label Security is installed, IS_OLS_INSTALLED returns TRUE.
DVSYS.DBMS_MACUTL.IS_OLS_INSTALLED()
RETURN BOOLEAN;
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.IS_OLS_INSTALLED()
THEN DBMS_OUTPUT.PUT_LINE('OLS is installed');
ELSE
DBMS_OUTPUT.PUT_LINE('OLS is not installed');
END IF;
END;
/
IS_OLS_INSTALLED_VARCHAR Function
IS_OLS_INSTALLED_VARCHAR function returns an indicator regarding whether Oracle Label Security is installed, and then returns a Y or N VARCHAR2 value. If Oracle Label Security is installed, then IS_OLS_INSTALLED_VARCHAR returns Y.
DVSYS.DBMS_MACUTL.IS_OLS_INSTALLED_VARCHAR()
RETURN VARCHAR2;
USER_HAS_ROLE Function
USER_HAS_ROLE function checks whether a user has a role privilege, directly or indirectly (through another role), and then returns a BOOLEAN value. If the user has a role privilege, then USER_HAS_ROLE returns TRUE.
DVSYS.DBMS_MACUTL.USER_HAS_ROLE(
p_role IN VARCHAR2,
p_user IN VARCHAR2 DEFAULT USER)
RETURN BOOLEAN;
Parameter Description
p_role
DBA_ROLES: Finds available roles in the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".DVSYS.DBA_DV_ROLE: Finds existing secure application roles used in privilege management. See "DBA_DV_ROLE View".
p_user
DBA_USERS: Finds available users for the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "Oracle Database Vault Data Dictionary Views".
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.USER_HAS_ROLE('SECTOR2_APP_MGR', 'PSMITH')
THEN DBMS_OUTPUT.PUT_LINE('User PSMITH has the SECTOR2_APP_MGR role');
ELSE
DBMS_OUTPUT.PUT_LINE('User PSMITH does not have the SECTOR2_APP_MGR role.');
END IF;
END;
/
USER_HAS_ROLE_VARCHAR Function
USER_HAS_ROLE_VARCHAR function checks whether a user has a role privilege, directly or indirectly (through another role), and then returns a VARCHAR2 value. If the user has the role privilege specified, then USER_HAS_ROLE_VARCHAR returns Y.
DVSYS.DBMS_MACUTL.USER_HAS_ROLE_VARCHAR(
p_role IN VARCHAR2,
p_user IN VARCHAR2 DEFAULT USER)
RETURN VARCHAR2;
Parameter Description
p_role
DBA_ROLES: Finds available roles in the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".DVSYS.DBA_DV_ROLE: Finds existing secure application roles used in privilege management. See "DBA_DV_ROLE View".
p_user
DBA_USERS: Finds available users for the current database instance. See DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".
USER_HAS_SYSTEM_PRIVILEGE Function
USER_HAS_SYSTEM_PRIVILEGE function checks whether a user has a system privilege, directly or indirectly (through a role), and then returns a BOOLEAN value. If the user has the system privilege specified, then USER_HAS_SYSTEM_PRIVILEGE returns TRUE.
DVSYS.DBMS_MACUTL.USER_HAS_SYSTEM_PRIVILEGE(
p_privilege IN VARCHAR2,
p_user IN VARCHAR2 DEFAULT USER)
RETURN BOOLEAN;
Parameter Description
p_privilege
PUBLIC privileges, query the DVSYS.DBA_DV_USER_PRIVS view, described in "DBA_DV_USER_PRIVS View".DVSYS.DBA_DV_USER_PRIVS_ALL, described in "DBA_DV_USER_PRIVS_ALL View".
p_user
DBA_USERS: Finds available users for the current database instance. See Oracle Database Reference.DVSYS.DBA_DV_REALM_AUTH: Finds the authorization of a particular user or role. See "DBA_DV_REALM_AUTH View".
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACUTL.USER_HAS_SYSTEM_PRIVILEGE('EXECUTE', 'PSMITH')
THEN DBMS_OUTPUT.PUT_LINE('User PSMITH has the EXECUTE ANY PRIVILEGE privilege.');
ELSE
DBMS_OUTPUT.PUT_LINE('User PSMITH does not have the EXECUTE ANY PRIVILEGE privilege.');
END IF;
END;
/
PK^_ PK )A OEBPS/audplcy.htm
4 Configuring Realms
What Are Realms?
Default Realms
ANONYMOUSDBSNMPMDSYSSYSBIEXFSYSMGMT_VIEWSYSMANCTXSYSMDDATAOUTLNSYSTEMDVSYS, DVF, and LBACSYS), such as configuration and roles information.SYSMAN and DBSNMP) to access database information
Creating a Realm
DV_OWNER or DV_ADMIN role.hr_app for an human resources application).DVSYS.AUDIT_TRAIL$ system file, described in Appendix A, "Auditing Oracle Database Vault."
Editing a Realm
Creating Realm-Secured Objects
SELECT, DDL, and DML statements, as long as a user is a participant in one of the realms, and if the command rules permit it, the commands the user enters are allowed. For GRANT and REVOKE operations of a database role in multiple realms, the person performing the GRANT or REVOKE operation must be the realm owner.AUD$ system table, then specify SYSTEM as the object owner. In an Oracle Database Vault environment, the AUD$ table is moved to the SYSTEM schema.TABLE, INDEX, or ROLE. This attribute is mandatory.% to specify all objects (except roles) for the object owner that you have specified. However, you cannot use wildcard characters with text such to specify multiple object names (for example, EMP_% to specify all tables beginning with the characters EMP_). Nor can you use the wildcard character to select multiple roles; you must enter role names individually. This attribute is mandatory.EMPLOYEES table in the HR schema, you would enter the following settings in the Create Realm Secured Object page:HRTABLEEMPLOYEES
Defining Realm Authorization
DV_OWNER or DV_ADMIN role are allowed to add users as owners or participants to a realm.DV_ADMIN, DV_OWNER, or DV_SECANALYST roles from this list.
Disabling and Enabling a Realm
Deleting a Realm
How Realms Work
EXECUTE, GRANT, REVOKE, or SELECT) that affects an object within a customer-defined realm, the following actions occur:SELECT, EXECUTE, and DML only, then the realm protection is not enforced. Realms protect against the use of any system privilege on objects or roles protected by the realm.O7_DICTIONARY_ACCESSIBILITY initialization parameter has been set to TRUE, then non-SYS users have access to SYS schema objects. For better security, ensure that O7_DICTIONARY_ACCESSIBILITY is set to FALSE.GRANT or REVOKE of a role that is protected by the realm, or the GRANT or REVOKE of an object privilege on an object protected by the realm, the session must be authorized as the realm owner directly or indirectly through roles. Remember that a role protected by realm is not the same as an authorized role in the realm. Then go to Step 4. Otherwise, realm violation occurs and the statement is not allowed to succeed. Note that SYS is the only realm owner in the default Oracle Data Dictionary Realm, and only SYS can grant system privileges to a database account or role.HR account may have the DROP ANY TABLE privilege and may be the owner of the HR realm, but a command rule can prevent HR from dropping any tables in the HR schema unless it is during its monthly maintenance window. Command rules apply to the use of the ANY system privileges and direct object privileges and are evaluated after the realm checks.SELECT ANY table privilege and be a participant in the HR realm. This means the account or the account granted the role could query the HR.EMPLOYEES table. Being a participant in the realm does not mean the account or role can DROP the HR.EMPLOYEES table. Oracle Database Vault does not replace the discretionary access control model in the existing Oracle database. It functions as a layer on top of this model for both realms and command rules.SYS are subject to the Oracle Data Dictionary realm enforcement. (The Oracle Data Dictionary realm is one of the default realms provided by Oracle Database Vault. See "Default Realms" for more information.) However, the session must have EXECUTE privilege on the procedure as normally required in the Oracle database.PUBLIC. For example, if SELECT ON table_name is granted to PUBLIC, then every user has access to table_name, even if this table is protected by a realm. As a best practice, revoke unnecessary privileges from PUBLIC.
How Authorizations Work in a Realm
CREATE ANY TABLE and DELETE ANY TABLE. These privileges typically apply across schemas and bypass the need for direct privileges. Data dictionary views such as DBA_SYS_PRIVS, USER_SYS_PRIVS, and ROLE_SYS_PRIVS list the system privileges for database accounts and roles. Database authorizations work normally for objects not protected by a realm. However, a user must be authorized as a realm owner or participant to successfully use his or her system privileges on objects secured by the realm. A realm vDiolation prevents the use of system privileges and can be audited.CREATE ANY TABLE system privilege tries to create a table in a realm where the HR schema is protected by a realm.
ORA-47401: Realm violation for CREATE TABLE on HR.DEMO2
SELECT ANY TABLE, CREATE ANY TABLE, DELETE ANY TABLE, UPDATE ANY TABLE, INSERT ANY TABLE, CREATE ANY INDEX, and others results in failure.DELETE ANY TABLE system privilege to delete an existing record, the database session returns the following error.
DELETE FROM HR.employees WHERE empno = 8002;
ERROR at line 1:
ORA-01031: insufficient privileges
HR.EMPLOYEES table can successfully delete records without requiring realm authorizations. Therefore, realms should minimally affect normal business application usage for database accounts.
Enabling Access to Objects That Are Protected by a Realm
CREATE INDEX ON table privilege to the user who must create the realm.CREATE ANY INDEX privilege alone is not sufficient for a non-realm participant to create an index in a realm-protected table.)
Example of How Realms Work
OE_ADMIN and HR_ADMIN, can be protected by a realm as a secured object and be configured as the owner of a realm.OE_ADMIN, can grant or revoke database roles that are protected by the realm. The realm owner cannot manage roles protected by other realms such as the DBA role created by SYS in the Oracle Data Dictionary realm. Any unauthorized attempt to use a system privilege to access realm-protected objects raises a realm violation, which can be audited. The powers of each realm owner are limited within the realm itself. For example, OE_ADMIN has no access to the Human Resources realm, and HR_ADMIN has no access to the Order Entry realm.
Description of "Figure 4-1 How Authorizations Work for Realms and Realm Owners"
How Realms Affect Other Oracle Database Vault Components
Guidelines for Designing Realms
ANY-style system privileges are already in use. A model using the principle of least privilege is ideal for any database application.EMPLOYEES table in the HR schema), or roles protected by a realm, create a new realm with just the minimum required objects and authorizations.GRANT ANY ROLE system privilege, such as the SYSTEM user account, from granting the role to themselves.SYS user account to a realm authorization, you must add user SYS explicitly and not through a role (such as the DBA role).SYS or SYSTEM creates a role for the first time and the Oracle Database Vault administrator adds this role as a realm authorization. This is because the account that creates a role is implicitly granted the role when it is created.DV_ADMIN or DV_OWNER) log in, add the named account to the authorized accounts for the realm, and set the authorization rule set to Enabled. Then in the enabled rule set, turn on all auditing for the rule set. You can remove the realm authorization when the administrative task is complete.ANY privileges to new users, Oracle recommends that you add a database administrative user to the data dictionary realm so that this user can grant other users ANY privileges, if they need them. For example, using a named account to perform the GRANT of the ANY operations enables you to audit these operations, which creates an audit trail for accountability.
How Realms Affect Performance
Statspack, and TKPROF. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Database Control, refer to its online Help. Oracle Database Performance Tuning Guide describes the Statspack and TKPROF utilities.
Related Reports and Data Dictionary Views
Report Purpose
Data Dictionary View Description
GRANTEE) to access realm objects in a particular realm
PKGp ~ PK )A
OEBPS/toc.ncx1
A Auditing Oracle Database Vault
Oracle Database Vault Specific Audit Events
Oracle Database Vault Audit Events
Format of the Oracle Database Vault Audit Trail
AUDIT_TRAIL$ table, which is part of the DVSYS schema. These audit records are not part of the Oracle Database audit trail, and how auditing is enabled in the database has no effect how Oracle Database Vault collects its audit data in the AUDIT_TRAIL$ table. In fact, even if auditing has been disabled in Oracle Database, then the Oracle Database Vault audit functionality continues to write to the AUDIT_TRAIL$ table. Users who have been granted the DV_OWNER, DV_ADMIN, or DV_SECANALYST role can directly query the DVYS.AUDIT_TRAIL$ table.DV_OWNER, DV_ADMIN, DV_SECANALYST or DV_MONITOR role can directly query the DVYS.AUDIT_TRAIL$ table.
AUDIT_TRAIL$ table.
Column Datatype Null Description
ID#
NUMBER
NOT NULL
OS_USERNAME
VARCHAR2(255)
USERNAME
VARCHAR2(30)
USERHOST
VARCHAR2(128)
TERMINAL
VARCHAR2(255)
TIMESTAMP
DATE
OWNER
VARCHAR2(30)
DVSYS (because DVSYS is where objects are created)
OBJ_NAME
VARCHAR2(128)
ROLE$REALM$CODE$FACTOR$
ACTION
NUMBER
NOT NULL
ACTION_NAME column. Expected ACTION and ACTION_NAME values are:10000: Factor Evaluation Audit10001: Factor Assignment Audit10002: Factor Expression Audit10003: Realm Violation Audit10004: Realm Authorization Audit10005: Command Authorization Audit10006: Secure Role Audit10007: Access Control Session Initialization Audit10008: Access Control Command Authorization Audit10009: Oracle Label Security Session Initialization Audit10010: Oracle Label Security Attempt to Upgrade Label Audit
ACTION_NAME
VARCHAR2(128)
ACTION column
ACTION_OBJECT_ID
NUMBER
OBJ_NAME
ACTION_OBJECT_NAME
VARCHAR2(128)
OBJ_NAME
ACTION_COMMAND
VARCHAR2(4000)
AUDIT_OPTION
VARCHAR2(4000)
NULL would indicate these two options.
RULE_SET_ID
NUMBER
RULE_SET_NAME
VARCHAR2(30)
RULE_ID
NUMBER
RULE_NAME
VARCHAR2(30)
FACTOR_CONTEXT
VARCHAR2(4000)
COMMENT_TEXT
VARCHAR2(4000)
SESSIONID
NUMBER
NOT NULL
ENTRYID
NUMBER
NOT NULL
ID# column
STATEMENTID
NUMBER
NOT NULL
RETURNCODE
NUMBER
NOT NULL
EXTENDED_TIMESTAMP
TIMESTAMP(6) WITH TIME ZONE
PROXY_SESSIONID
NUMBER
GLOBAL_UID
VARCHAR2(32)
INSTANCE_NUMBER
NUMBER
INSTANCE_NUMBER initialization parameter
OS_PROCESS
VARCHAR2(16)
CREATED_BY
VARCHAR2(30)
CREATE_DATE
DATE
SYSDATE date
UPDATED_BY
VARCHAR2(30)
CREATED_BY column value
UPDATE_DATE
DATE
UPDATED_BY column value
Archiving and Purging the Oracle Database Vault Audit Trail
AUDIT_TRAIL$ system table, which is owned by DVSYS, to a dump file. You should periodically archive and then purge the audit trail to prevent it from growing too large.$ORACLE_BASE/admin/$DB_UNIQUE_NAME/dvaudit).$ORACLE_BASE/admin/$DB_UNIQUE_NAME/adump directory. In SQL*Plus, you can check the location of the audit trail directory as follows:
SHOW PARAMETER AUDIT_FILE_DEST
NAME TYPE VALUE
------------------- ------- ---------------------------------------
audit_file_dest string /opt/oracle/app/oracle/admin/orcl/adump
SYS or as any user who has the CREATE ANY DIRECTORY privilege.
CREATE DIRECTORY dv_audit_dir AS '/opt/oracle/app/oracle/admin/orcl/dvaudit';
DVSYS.
GRANT READ, WRITE ON DIRECTORY dvaudit TO dvsys;
DVSYS.AUDIT_TRAIL$ audit table into a new dump file.
EXPDP DVSYS
Enter password: password
DIRECTORY=dvaudit \
TABLES=DVSYS.AUDIT_TRAIL$ \
QUERY=DVSYS.AUDIT_TRAIL$:"WHERE timestamp < 2009-08-03:19:34:59"
DUMPFILE=dv_audit_031607.dmp
DIRECTORY: Enter the directory object that you created in Step 5. Ensure that that the user who is running EXPDP (DVSYS in this example) has read and write permissions on this directory object. If you created the directory object, then you automatically have read and write permissions on it.TABLES: Enter DVSYS.AUDIT_TRAIL$, the name of the audit trail table.QUERY: Optional. This setting writes a subset of the audit table contents to the dump file, in this case, audit records that are less than the timestamp column value of 2009-08-03:19:34:59.DUMPFILE: Enter the name of the dump file that you want to create. The default extension is .dmp, but you can use any extension. Ensure that the file name you specify is unique.timestamp column value of 2009-08-03:19:34:59, enter the following statement:
DELETE FROM DVSYS.AUDIT_TRAIL$ WHERE TIMESTAMP < 2009-08-03:19:34:59;
TRUNCATE TABLE DVSYS.AUDIT_TRAIL$;
Oracle Database Audit Settings Created for Oracle Database Vault
AUDIT settings in the database. However, in order for these audit settings to take place, auditing must be enabled in this database. You can check if auditing is enabled by using the SHOW PARAMETER command to find the value of the AUDIT_TRAIL initialization parameter. By default, auditing is disabled in Oracle Database.AUDIT_TRAIL parameter is set to NONE, then auditing is not enabled, so you must set AUDIT_TRAIL. For detailed information about the AUDIT_TRAIL parameter settings, see Oracle Database Security Guide and Oracle Database Reference.AUDIT settings that Oracle Database Vault adds to the database.
Audit Setting Type Audited Statements (BY ACCESS and on Success or Failure Unless Otherwise Noted)
ALTER ANYCREATE ANYDELETE ANYDROP ANYEXECUTE ANY (WHENEVER NOT SUCCESSFUL)FORCE ANYGRANT ANYINSERT ANYUPDATE ANY
ALTER DATABASE, PROFILE, ROLLBACK SEGMENT, SESSION, SYSTEM, TABLE, TABLESPACE, USERCREATE CLUSTER, DATABASE LINK, INDEXTYPE, LIBRARY, OPERATOR, PUBLIC SYNONYM, PROCEDURE, PROFILE, ROLE, ROLLBACK ~SEGMENT, SEQUENCE, SESSION, SNAPSHOT, SYNONYM, TABLE, TABLESPACE, TRIGGER, TYPE, USER, VIEWTRUNCATE
ALTER SESSIONBECOME USERCREATE SESSIONDEBUG CONNECT SESSIONRESTRICTED SESSION
ADMINISTER DATABASE TRIGGERBACKUP ANY TABLEEXEMPT ACCESS POLICYMANAGE TABLESPACE
AUDIT ANYAUDIT SYSTEM
GRANT ANY PRIVILEGE/ANY OBJECT PRIVILEGE/ROLEGRANT DIRECTORYGRANT SEQUENCEGRANT TABLEGRANT TYPE
DVSYS/DVFLBACSYSDVSYS and DVF schemas:
ADMINISTER DATABASE TRIGGERALTER objectAUDIT SYSTEMBECOME USERCLUSTERCOMMENTCONTEXTCREATE objectDATABASE LINKDEBUGDIRECTORYDROP objectEXECUTE LIBRARY (WHENEVER NOT SUCCESSFUL)EXECUTE PROCEDURE (WHENEVER NOT SUCCESSFUL)EXEMPT ACCESS POLICYEXPORT FULL DATABASEGRANT objectIMPORT FULL DATABASEINDEXMANAGE SCHEDULERMANAGE TABLESPACEMATERIALIZED VIEW (audits both accessing and creating materialized views)SELECT SEQUENCE (WHENEVER NOT SUCCESSFUL)SELECT TABLE (WHENEVER NOT SUCCESSFUL)
AUDIT PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/TABLECOMMENT TABLE/VIEWDELETE TABLE/VIEWEXECUTE PACKAGE/PROCEDURE/FUNCTION (WHENEVER NOT SUCCESSFUL)GRANT PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/TABLERENAME PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/VIEW/TABLESELECT SEQUENCE/TABLE/VIEW (WHENEVER NOT SUCCESSFUL)
AUDIT PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/TABLECOMMENT TABLE/VIEWDELETE TABLE/VIEWEXECUTE PACKAGE/PROCEDURE/FUNCTION (WHENEVER NOT SUCCESSFUL)GRANT PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/TABLEINSERT TABLE/VIEWRENAME PACKAGE/PROCEDURE/FUNCTION/SEQUENCE/VIEW/TABLESELECT SEQUENCE/TABLE/VIEW (WHENEVER NOT SUCCESSFUL)
PK{\ PK )A OEBPS/monitoring.htmE3
E Troubleshooting Oracle Database Vault
Using Trace Files to Diagnose Events in the Database
USER_DUMP_DEST initialization parameter specifies the current location of the trace files. You can find the value of this parameter by issuing SHOW PARAMETER USER_DUMP_DEST in SQL*Plus.ALTER SESSION privilege and then issue the following statement:
ALTER SESSION SET EVENTS '47998 trace name context forever, level 12'
ALTER SESSION privilege, issuing the ALTER SESSION statement, and then retrying the statement. Afterward, check the trace files to determine what is going on.
ALTER SESSION SET EVENTS '47998 trace name context off'
General Diagnostic Tips
EXECUTE privilege on the PL/SQL package functions used in these expressions directly to the account and determine if the results appear to be correct.
Configuration Problems with Oracle Database Vault Components
PKuJ3 E3 PK )A OEBPS/content.opf-
16 Monitoring Oracle Database Vault
Security Violation Attempts
AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED. For detailed information about the AUDIT_TRAIL parameter settings, see Oracle Database Security Guide.DV_OWNER, DV_ADMIN, DV_MONITOR, or DV_SECANALYST role.
Description of the illustration security_violation_attempts.gif
Database Configuration and Structural Changes
CREATE TABLE, ALTER TABLE, DROP TABLE, and ALTER DATABASE. It audits all commands, not just commands that are used in command rules. For example, if someone has unexpectedly altered a table on a production system, you can use this feature to determine what is happening.AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED. For detailed information about the AUDIT_TRAIL parameter settings, see Oracle Database Security Guide.DV_OWNER, DV_ADMIN, DV_MONITOR, or DV_SECANALYST role.
Description of the illustration config_struct_changes.gif
Security Policy Changes by Category
About Monitoring Security Policy Changes by Category
AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED. For detailed information about the AUDIT_TRAIL parameter settings, see Oracle Database Security Guide.AUDIT or NOAUDIT statements.GRANT statements.REVOKE statements.CREATE USER, ALTER USER, or DROP USER statements.CREATE ROLE, ALTER ROLE, or DROP ROLE statements.
Procedure for Monitoring Security Policy Changes by Category
DV_OWNER, DV_ADMIN, DV_MONITOR, or DV_SECANALYST role.
Description of the illustration sec_policy_changes.gif
Security Policy Changes Detail
AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED. For detailed information about the AUDIT_TRAIL parameter settings, see Oracle Database Security Guide.DV_OWNER, DV_ADMIN, DV_MONITOR, or DV_SECANALYST role.
Description of the illustration sec_policy_changes_detail.gif
PK8p PK )A OEBPS/dcommon/prodbig.gif GIF87a !!!)))111BBBZZZsss{{ZRRcZZ!!1!91)JB9B9)kkcJJB991ssc絽Zcc!! {祽BZc!9B!c{ !)c{9{Z{{cZB1)s Jk {{Z{kBsZJ91)Z{!{ BcsRsBc{ 9Z Zk甽k Bk R!BZ 9c )JJc{!))BZks{BcR{JsBk9k)Zck ! !B Z1k!ZcRBZc ZJkBk1Z9c!R!c9kZRZR B Z9{ 9 9 !R 1{ 99R{ 1!1)c 1 J)1B ! B J Rkk{ƽ絵ތkk絵RRs{{{{JJsssBBkkk!!9ss{{ZZssccJJZZRRccRRZZ))cBBJJ99JJ!!c11991199Z11!c!!))Z!! ! 1 B R c k { )!cJBkZRZ , HP)XRÇEZ֬4jJ0 @ "8p YҴESY3CƊ @* U:lY0_0#
5tX1E: C_xޘeK TList of Figures
g C)rr9+c:b Жf*s^ fKS7^}
*{zq_@8# p F~
[VPe(nw0MW=3#kȵ z晨cy PpG#W:% drMh] 3HH<\]ԁ |_ W
HHҡb}P >k {ZErxMX@8C&qs kLۙOnO^sCk7ql2XCw5VG.S~ H 8=(s 1~ cV5z
%v|U2QF=NoW]ո?<`~}=ӬfԵ,=; "~Iy7K#g{ñJ?5$y`
zz @-~ m7 mG宝Gٱ>G&K#]y1$$t>wqjstX.b̐{Wej)Dxfc:8)=$y|L`xV8ߙ~E)HkwW$J0uʟk>6S gp~;4W+חc"=|ř9bc5 > *r g {~cj1rnI#G|8v4wĿhFb><^ pJLm[Dl1;Vx5IZ: 1* p)إ1Z bAK(1ׅ|S& 5{^
KG ^ 5r>;X K^?
s fk^8O/"J)3K]N)iLOracle Legal Notices
Copyright Notice
Trademark Notice
License Restrictions Warranty/Consequential Damages Disclaimer
Warranty Disclaimer
Restricted Rights Notice
Hazardous Applications Notice
Third-Party Content, Products, and Services Disclaimer
Alpha and Beta Draft Documentation Notice
PK7 ! ! PK )A OEBPS/cfgfact.htm
13 Using the DVSYS.DBMS_MACSEC_ROLES Package
About the DVSYS.DBMS_MACSEC_ROLES Package
DVSYS.DBMS_MACSEC_ROLES package to check the authorization for a user or to set an Oracle Database Vault secure application role. The DVSYS.DBMS_MACSEC_ROLES package is available to all users.DVSYS.DBMS_MACSEC_ROLES package function and procedure.
Function or Procedure Description
BOOLEAN value.
SET ROLE statement for an Oracle Database Vault secure application role.
CAN_SET_ROLE Function
CAN_SET_ROLE function checks whether the user invoking the method is authorized to use the specified Oracle Database Vault secure application role.
DVSYS.DBMS_MACSEC_ROLES.CAN_SET_ROLE(
p_role IN VARCHAR2)
RETURN BOOLEAN;
Parameter Description
p_role
DVSYS.DBA_DV_ROLE view, described in "DBA_DV_ROLE View".
SET SERVEROUTPUT ON
BEGIN
IF DVSYS.DBMS_MACSEC_ROLES.CAN_SET_ROLE('SECTOR2_APP_MGR')
THEN DBMS_OUTPUT.PUT_LINE('''SECTOR2_APP_MGR'' can be enabled.');
END IF;
END;
/
SET_ROLE Procedure
SET_ROLE procedure issues the SET ROLE PL/SQL statement for specified roles, including both Oracle Database Vault secure application roles and regular Oracle Database roles. This procedure sets an Oracle Database Vault secure application role only if the rule set that is associated with the role evaluates to true.
DVSYS.DBMS_MACSEC_ROLES.SET_ROLE(
p_role IN VARCHAR2);
Parameter Description
p_role
DVSYS.DBA_DV_ROLE view, described in "DBA_DV_ROLE View".DBA_ROLES data dictionary view, described in Oracle Database Reference.
EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('SECTOR2_APP_MGR, APPS_MGR');
Sector2_APP_MGR).
PKӊ v PK )A
OEBPS/toc.htm
7 Configuring Factors
What Are Factors?
DVF factor functions described in "Oracle Database Vault PL/SQL Factor Functions" are factor-specific functions that you can use in rule expressions.
Default Factors
SYS_CONTEXT SQL function, which retrieves data about the user session. After you create the custom factor, you can query its values similar to the functions used to query the default factors. "Tutorial: Preventing Ad Hoc Tool Access to the Database" shows an example of how to create and query a custom factor.SYS_CONTEXT function.SYSDBA/SYSOPER using Password File; proxy with user name using password: PASSWORDKERBEROSSSLRADIUSSYSDBA/SYSOPER: OSDCENONEIDENTIFICATION_TYPE to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL.DB_DOMAIN initialization parameter.DB_NAME initialization parameter.SYSDBA and SYSOPER logins: NULL.IDENTIFIED clause in the CREATE/ALTER USER syntax. In the list that follows, the syntax used during schema creation is followed by the identification type returned:IDENTIFIED BY password: LOCALIDENTIFIED EXTERNALLY: EXTERNALIDENTIFIED GLOBALLY: GLOBAL SHAREDIDENTIFIED GLOBALLY AS DN: GLOBAL PRIVATELANGUAGE parameter.
language_territory.characterset
AMERICAN_AMERICA.WE8MSWIN1252
PROTOCOL=protocol portion of the connect string.SESSION_USER.
Creating a Factor
DV_OWNER or DV_ADMIN role.DVF schema based on the name of the factor chosen. For example, if you create a factor named GetNetworkIP, Oracle Database Vault creates the DVF.F$GETNETWORKIP function. This attribute is mandatory.DVF factor functions.DBA_DV_FACTOR data dictionary view. For example:
SELECT NAME
FROM DVSYS.DBA_DV_FACTOR
WHERE FACTOR_TYPE_NAME='Authentication Method';
NAME
------------------------------
Network_Protocol
Authentication_Method
Identification_Type
DVSYS.DBMS_MACADM package, use the CREATE_FACTOR_TYPE procedure, described in "CREATE_FACTOR_TYPE Procedure".
to_char(sysdate,'yyyy-mm-dd')
2009-12-06
DVF schema (which contains functions that retrieve factor values) as follows:dvf.f$factor_name
CONNECT lbrown_dvowner
Enter password: password
SELECT DVF.F$DATABASE_IP FROM DUAL;
SELECT DVF.F$DATABASE_IP FROM DUAL;
F$DATABASE_IP
-------------------------------------------------------------
192.0.2.1
DVSYS.GET_FACTOR function to find the identity of a factor that is made available for public access. For example:
SELECT GET_FACTOR('DATABASE_IP') FROM DUAL;
GET_FACTOR('DATABASE_IP')
-------------------------------------------------------------
192.0.2.1
USERENV namespace in a user's session.
UPPER(SYS_CONTEXT('USERENV','DB_NAME'))
VARCHAR2 string or otherwise convertible to one.schema.function_name. Do not include complete SQL statements. If you are using application packages or functions, you must provide DVSYS with the GRANT EXECUTE privilege on the object.
FUNCTION GET_FACTOR RETURN VARCHAR2
TRUE or FALSE) to validate the identity of a factor being retrieved (with the DVSYS.GET_FACTOR function) or the value to be assigned to a factor (with the DVSYS.SET_FACTOR function). If the method is evaluated to false for the value being retrieved or to be assigned, then the factor identity is set to null. This optional feature provides an additional level of assurance that the factor is properly retrieved and set. This field can have up to 255 characters in mixed-case.schema.function_name. Do not include complete SQL statements. If you are using application packages or functions, you must provide DVSYS with the GRANT EXECUTE privilege on the object.FUNCTION IS_VALID RETURN BOOLEANDVF.F$factor_name function inside the function logic. This is more appropriate for factors that are evaluated by session.FUNCTION IS_VALID(p_factor_value VARCHAR2) RETURN BOOLEANDVSYS.SET_FACTOR, for example:
BEGIN
DVSYS.SET_FACTOR('GEO_STATE','VIRGINIA');
END;
DVSYS.AUDIT_TRAIL$ system file, described in Appendix A, "Auditing Oracle Database Vault."No data found or Too many rows).NULL.FALSE.NULL.
Editing a Factor
Adding an Identity to a Factor
About Factor Identities
Creating and Configuring a Factor Identity
NULL (default)GET_TRUST_LEVEL and GET_TRUST_LEVEL_FOR_IDENTITY functions in the DVSYS schema.DVSYS.GET_TRUST_LEVEL to find trust levels greater than 5:
DVSYS.GET_TRUST_LEVEL('Network') > 5
SELECT statement on the DVSYS.DBA_DV_IDENTITY data dictionary view to find trust levels for the Network factor greater than or equal to 5:
SELECT VALUE, TRUST_LEVEL FROM DVSYS.DBA_DV_IDENTITY
WHERE TRUST_LEVEL >= 5
AND FACTOR_NAME='Network'
F$NETWORK GET_TRUST_LEVEL('NETWORK')
------------------------------------
VPN 5
INTRANET 10
Using Identity Mapping to Configure an Identity to Use Other Factors
Between, the Low Value is set to 192.0.2.1 and the High Value is set to 192.0.2.24. This means that whenever the client IP address lies in the specified address range of 192.0.2.1 to 192.0.2.24, the parent factor evaluates to a predefined identity (for example, INTRANET).
Deleting a Factor
How Factors Work
How Factors Are Processed When a Session Is Established
NULL).NULL).CONNECT event. If a rule set associated with the CONNECT event, then Oracle Database Vault evaluates the rule set. If the rule set evaluates to false or results in an error, then the session is terminated. Oracle Database Vault executes any auditing or call handlers associated with the rule set before the session is terminated.
CONNECT event, because you can inadvertently lock out other users from of the database. In general, if you create a command rule for CONNECT, set its evaluation option of the associated rule set to Any True.
How Factors Are Retrieved
DVF factor function or the DVSYS.GET_FACTOR function. To find a listing of available factors, query the DVS.DBA_DV_FACTOR data dictionary view, described in"DBA_DV_FACTOR View".DVSYS.GET_FACTOR function.DVF factor function or the DVSYS.GET_FACTOR in the following ways:DVF factor functions in detail.
How Factors Are Set
DVSYS.SET_FACTOR function. In Java code, you can use the JDBC class java.sql.CallableStatement to set this value. For example:
java.sql.Connection connection ;
...
java.sql.CallableStatement statement =
connection.prepareCall("{call DVSYS.SET_FACTOR('FACTOR_X', ?)}");
statement.setString(1, "MyValue");
boolean result = statement.execute();
...
DBMS_SESSION.SET_IDENTIFIER procedure with an added feature that a rule set controls when a factor value can be set. If the rule set evaluates to true, Steps 2 through 5 under "How Factors Are Processed When a Session Is Established" occur.DVSYS.SET_FACTOR function.
Tutorial: Preventing Ad Hoc Tool Access to the Database
About This Tutorial
SYSTEM, and SYS. To accomplish this, you must create a factor to find the applications on your system and a rule and rule set to limit SQL*Plus to these four users. Then you create a command rule for the CONNECT SQL statement, which is associated with the rule set. When you successfully complete this tutorial, then only the administrative users you specify should be able to connect to the database using SQL*Plus.
Step 1: Enable the SCOTT User Account
SCOTT account later on when you test the Oracle Database Vault components for this tutorial, so ensure that this account is active.DV_ACCTMGR role.
sqlplus amalcolm_dvacctmgr
Enter password: password
SCOTT account.
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'SCOTT';
SCOTT account is expired and locked, then enter the following statement to make it active:
ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.
Step 2: Create the Module Factor
SYS_CONTEXT SQL function to find the names of the applications that are used to access the current instance of Oracle Database. As described previously, the SYS_CONTEXT SQL function provides many useful methods for finding the state of a user session. SYS_CONTEXT is a valuable tool for creating custom factors. See Oracle Database SQL Language Reference for more information ab out the SYS_CONTEXT function.
DV_OWNER or DV_ADMIN role.Module.Factor to find applications that can access Oracle Database.
UPPER(SYS_CONTEXT('USERENV', 'MODULE'))
sqlplus lbrown_dvowner
Enter password: password
SELECT DVF.F$MODULE FROM DUAL;
F$MODULE
-----------------------------
SQLPLUS.EXE
Step 3: Create the Limit SQL*Plus Access Rule and Rule Set
Limit SQL*Plus Access.Rule set to limit access to SQL*Plus.Prevent non-admin access to SQL*Plus.
DVF.F$MODULE != 'SQL*PLUS' AND DVF.F$SESSION_USER IN ('LBROWN_DVOWNER', 'AMALCOLM_DVACCTMGR', 'SYS', 'SYSTEM')
LBROWN_DVOWNER and AMALCOLM_DVACCTMGR with the user account names that you use for the Database Vault Owner and Database Vault Account Manager accounts. You must enter the user account names in upper case letters, because that is how the database stores user account names.JSMITH and TSMITH from using SQL*Plus, you would create this expression:
DVF.F$MODULE != 'SQL*PLUS' AND DVF.F$SESSION_USER NOT IN ('JSMITH', 'TSMITH')
Step 4: Create the CONNECT Command Rule
CONNECT SQL statement. It also applies to logging into SQL*Plus from the command line or other tools your site may use to access SQL*Plus.
Step 5: Test the Ad Hoc Tool Access Restriction
SCOTT:
CONNECT SCOTT
Enter password: password
ERROR:
ORA-47400: Command Rule violation for CONNECT on LOGON
Warning: You are no longer connected to ORACLE.
SCOTT should be prevented from using SQL*Plus.SYSTEM:
CONNECT SYSTEM
Enter password: password
Connected.
SYSTEM should be able to log in to SQL*Plus. So should SYS, the Database Vault Owner account, and the Database Vault Account Manager account.SYSTEM (or as any of the other administrative users listed in your rule expression), then you are prevented from using both SQL*Plus and Oracle Database Vault Administrator. But do not fear, you can remedy the problem as follows:DV_OWNER or DV_ADMIN role.
CONNECT lbrown_dvowner
Enter password: password
EXEC DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE ('CONNECT', '%', '%');
Step 6: Remove the Components for This Tutorial
CONNECT lbrown_dvowner
Enter password: password
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Prevent non-admin access to SQL*Plus');
SCOTT account.
CONNECT amalcolm_dvacctmgr
Enter password: password
ALTER USER SCOTT ACCOUNT LOCK PASSWORD EXPIRE;
Tutorial: Restricting User Activities Based on Session Data
About This Tutorial
Step 1: Create an Administrative User
DV_ACCTMGR role, and then create the user account mwaldron.
sqlplus amalcolm_dvacctmgr
Enter password: password
CREATE USER mwaldron IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.SYS using the SYSDBA privilege, and then grant user mwaldron DBA privileges.
CONNECT SYS AS SYSDBA
Enter password: password
GRANT CREATE SESSION, DBA TO mwaldron;
Step 2: Add Identities to the Domain Factor
DV_OWNER or DV_ADMIN role.HIGHLY SECURE INTERNAL NETWORK
Step 3: Map the Domain Factor Identities to the Client_IP Factor
192.0.2.12). (This is the computer that user maldron uses. For this tutorial, you can enter the IP address of your own computer. If you are using Microsoft Windows, use the IP address assigned to the Loopback Adapter.)
Child Factor Name Operation Value Operand 1 Operand 2 Client_IPLess192.0.2.5(Leave blank) Client_IPGreater192.0.2.20(Leave blank) mwaldron uses (192.0.2.12). The IP addresses here must be in any range outside mwaldron's IP address.mwaldron but do not specify a database instance.
CONNECT mwaldron
Enter password: password
SELECT DVF.F$CLIENT_IP FROM DUAL;
F$CLIENT_IP
-------------------------------------
SELECT DVF.F$DOMAIN FROM DUAL;
F$DOMAIN
-------------------------------------
NOT SECURE
mwaldron is not connecting directly to the database instance, Oracle Database Vault does not recognize the IP address from which he is connecting. In this case, Oracle Database uses the IPC protocol to perform the connection, which sets the IP value to null. Therefore, the identity for this connection is set to NOT SECURE.orcl), and then check the factor identities again:
CONNECT mwaldron@orcl
Enter password: password
SELECT DVF.F$CLIENT_IP FROM DUAL;
F$CLIENT_IP
-------------------------------------
192.0.2.12
SELECT DVF.F$DOMAIN FROM DUAL;
F$DOMAIN
-------------------------------------
HIGHLY SECURE INTERNAL NETWORK
mwaldron is connecting to the orcl database instance, his IP address is recognized. This is because the database uses the TCP protocol, so now the host IP value can be populated appropriately. Because the IP address is within the correct range, the factor identity is set to HIGHLY SECURE INTERNAL NETWORK.
Step 4: Create a Rule Set to Set the Hours and Select the Factor Identity
Internal DBA Standard Working Hours.Internal DBADVF.F$SESSION_USER='MWALDRON'Internal Network OnlyDVF.F$DOMAIN='HIGHLY SECURE INTERNAL NETWORK'Week DayTO_CHAR(SYSDATE, 'D') BETWEEN '2' AND '6'Week Working Day HoursTO_CHAR(SYSDATE, 'HH24') BETWEEN '08' AND '19'
Step 5: Create a Command Rule That Uses the Rule Set
Step 6: Test the Factor Identity Settings
mwaldron administrative user, and then trying to create a table.
su root
Password: password
date --set="14 DEC 2011 21:00:00"
mwaldron and try to create a table. In the following, replace orcl with the name of your database instance.
CONNECT mwaldron@orcl
Enter password: password
CREATE TABLE TEST (num number);
ORA-47400: Command Rule violation for create table on MWALDRON.TEST
mwaldron is create a table outside working hours, Database Vault prevents him.mwaldron, try to create the table again.
CREATE TABLE TEST (num number);
Table created.
DROP TABLE TEST;
Table dropped.
maldron is working during his local hours and from the IP address associated with the HIGHLY SECURE INTERNAL NETWORK identity, he can create tables.mwaldron but without adding the database instance name to the connection command, and then try to select from the OE.ORDERS table again.
CONNECT mwaldron
Enter password: password
CREATE TABLE TEST (num number);
ORA-47400: Command Rule violation for create table on MWALDRON.TEST
mwaldron is trying to create a table during the correct time, he cannot because is not directly logged in to the orcl database instance. Oracle Database Vault deems him to be using the NOT SECURE identity, and then denies him access.
Step 7: Remove the Components for This Tutorial
DV_ACCTMGR user and drop user mwaldron.
sqlplus amalcolm_dvacctmgr
Enter password: password
DROP USER mwaldron CASCADE;
CONNECT lbrown_dvowner
Enter password: password
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Internal DBA');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Internal Network Only');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Week Day');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Week Day Working Hours');
COMMIT;
Guidelines for Designing Factors
UTL_TCP, UTL_HTTP, DBMS_LDAP, and DBMS_PIPE to integrate security or other contextual information about the session from external systems.DBMS_SESSION.SET_IDENTIFIER but also include a capability to control when they can be set. For more information about the DBMS_SESSION package, see Oracle Database PL/SQL Packages and Types Reference.
How Factors Affect Performance
Proxy_User, Oracle Database Vault performs this processing during session initialization, and then caches the results for subsequent requests for that value.Statspack, and TKPROF. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Database Control, refer to its online Help. Oracle Database Performance Tuning Guide describes the Statspack and TKPROF utilities.
Related Reports and Data Dictionary Views
Report Description
Data Dictionary View Description
PK_q PK )A OEBPS/reports.htm
Contents
List of Examples
List of Figures
List of Tables
Title and Copyright Information
Preface
What's New in Oracle Database Vault?
1 Introducing Oracle Database Vault
2 What to Expect After You Install Oracle Database Vault
3 Getting Started with Oracle Database Vault
4 Configuring Realms
5 Configuring Rule Sets
6 Configuring Command Rules
7 Configuring Factors
8 Configuring Secure Application Roles for Oracle Database Vault
9 Integrating Oracle Database Vault with Other Oracle Products
10 DBA Operations in an Oracle Database Vault Environment
11 Oracle Database Vault Objects
12 Using the DVSYS.DBMS_MACADM Package
13 Using the DVSYS.DBMS_MACSEC_ROLES Package
14 Using the DVSYS.DBMS_MACUTL Package
15 Using the Oracle Database Vault PL/SQL Interfaces
16 Monitoring Oracle Database Vault
17 Oracle Database Vault Reports
A Auditing Oracle Database Vault
B Disabling and Enabling Oracle Database Vault
C Postinstallation Oracle Database Vault Procedures
D Oracle Database Vault Security Guidelines
E Troubleshooting Oracle Database Vault
Index
PKk PK )A OEBPS/dv_ols.htm
17 Oracle Database Vault Reports
Categories of Oracle Database Vault Reports
Who Can Run the Oracle Database Vault Reports?
DV_OWNER, DV_ADMIN, or DV_SECANALYST role before you can run the Oracle Database Vault reports. For more information about these roles, see the following sections:
How to Run Oracle Database Vault Reports
DV_OWNER, DV_ADMIN, or DV_SECANALYST role.
Generating Oracle Database Vault Reports
Oracle Database Vault Configuration Issues Reports
Command Rule Configuration Issues Report
Factor Configuration Issues Report
Factor Without Identities Report
Background_Job_Id, this may not be a real problem, but the report can help you determine whether your access control configuration is complete and whether you have accounted for all factor configuration.
Identity Configuration Issues Report
Realm Authorization Configuration Issues Report
Rule Set Configuration Issues Report
Oracle Database Vault Auditing Reports
Realm Audit Report
Command Rule Audit Report
Factor Audit Report
Label Security Integration Audit Report
Core Database Vault Audit Trail Report
Violation Attempt Instance Number Timestamp Object Name Return Code Rule Set Account Command User Host
Generating General Security Reports
Object Privilege Reports
Object Access By PUBLIC Report
PUBLIC. It details all the object access the database accounts that you specify on the Report Parameters page, through object grants to PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, the object owner, or the object name.
Object Access Not By PUBLIC Report
PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, the object owner or the object name.
Direct Object Privileges Report
CTXSYSLBACSYSSYSWMSYSDMSYSMDSYSSYSMANDVSYSORDSYSSYSTEMEXFSYSPUBLICWKSYS
Object Dependencies Report
UTL_FILE package, has privileges granted to PUBLIC or some other global role, then you can use the Object Dependencies Report to determine an account that may depend on the object and to determine how the account uses the object. To run the report, enter the database account you are inspecting for dependency and the object it may be dependent on, in the Report Parameters page.PUBLIC grants on widely used sensitive objects.
Database Account System Privileges Reports
Direct System Privileges By Database Account Report
WITH ADMIN option.
Direct and Indirect System Privileges By Database Account Report
WITH ADMIN status.
Hierarchical System Privileges by Database Account Report
ANY System Privileges for Database Accounts Report
ANY system privileges granted to the specified database account or role. ANY system privileges are very powerful and should be judiciously assigned to accounts and roles.
Sensitive Objects Reports
Execute Privileges to Strong SYS Packages Report
EXECUTE privilege on system packages that can be used to access operating system resources or other powerful system packages. The following system PL/SQL packages are included:
DBMS_ALERTDBMS_RANDOMDBMS_BACKUP_RESTOREDBMS_REPAIRDBMS_CAPTURE_ADMDBMS_REPCATDBMS_DDLDBMS_REPCAT_ADMINDBMS_DISTRIBUTED_TRUST_ADMINDBMS_RESOURCE_MANAGERDBMS_FGADBMS_RESOURCE_MANAGER_PRIVSDBMS_JOBDBMS_RLSDBMS_LDAPDBMS_SESSIONDBMS_LOBDEBUG_EXTPROCDBMS_LOGMNRUTL_FILEDBMS_LOGMNR_DUTL_HTTPDBMS_OBFUSCATION_TOOLKITUTL_SMTPDBMS_ORACLE_TRACE_AGENTUTL_TCPDBMS_PIPE
Access to Sensitive Objects Report
ALL_SOURCEPROFILE$ALL_USERSPROXY_ROLE_DATA$APPROLE$PROXY_ROLE_INFO$AUD$ROLE_ROLE_PRIVSAUDIT_TRAIL$SOURCE$DBA_ROLE_PRIVSSTATS$SQLTEXTDBA_ROLESSTATS$SQL_SUMMARYDBA_TAB_PRIVSSTREAMS$_PRIVILEGED_USERDBMS_BACKUP_RESTORESYSTEM_PRIVILEGE_MAPDEFROLE$TABLE_PRIVILEGE_MAPFGA_LOG$TRIGGER$LINK$USER$OBJ$USER_HISTORY$OBJAUTH$USER_TAB_PRIVSOBJPRIV$SYSTEM_PRIVILEGE_MAP
Public Execute Privilege To SYS PL/SQL Procedures Report
SYS. This can be used to determine which privileges can be revoked from PUBLIC, or from other accounts and roles. This reduces vulnerabilities as part of an overall security policy implementation using the principle of least privilege.
Accounts with SYSDBA/SYSOPER Privilege Report
SYS-privileged connection privileges. It also shows whether the accounts use an external password. However, note that this report does not include operating system users who can become SYSDBA.
Privilege Management - Summary Reports
Privileges Distribution By Grantee Report
Privileges Distribution By Grantee, Owner Report
Privileges Distribution By Grantee, Owner, Privilege Report
Powerful Database Accounts and Roles Reports
WITH ADMIN Privilege Grants Report
WITH ADMIN clause. This privilege can be misused to give another account more system privileges than required.
Accounts With DBA Roles Report
DBA role granted to them. The DBA role is a privileged role that can be misused. It is often granted to a database account to save time and to avoid having to determine the least number of privileges an account really needs. This report can help you to start applying a policy using the principle of least privilege to an existing database.
Security Policy Exemption Report
EXEMPT ACCESS POLICY system privilege granted to them. Accounts that have this privilege can bypass all Virtual Private Database (VPD) policy filters and any Oracle Label Security policies that use Oracle Virtual Private Database indirectly. This is a powerful system privilege that should be granted only if absolutely necessary, as it presents a target to gain access to sensitive information in tables that are protected by Oracle Virtual Private Database or Oracle Label Security. You can use the auditing policies described in Appendix A, "Auditing Oracle Database Vault," to audit the use of this privilege.
BECOME USER Report
BECOME USER system privilege. This is a very powerful system privilege: it enables the IMP_FULL_DATABASE and EXP_FULL_DATABASE roles for use with Oracle Data Pump. Accounts that possess this privilege can be misused to get sensitive information or to compromise an application.
ALTER SYSTEM or ALTER SESSION Report
ALTER SYSTEM or ALTER SESSION privilege. Oracle recommends that you restrict these privileges only to those accounts and roles that truly need them (for example, the SYS account and the DV_ADMIN role). The ALTER SYSTEM statement can be used to change the security-related database initialization parameters that are set to recommended values as part of the Oracle Database Vault security strengthening service. Both the ALTER SYSTEM and ALTER SESSION statements can be used to dump database trace files, potentially containing sensitive configuration information, to the operating system.ALTER SYSTEM and ALTER SESSION privileges, see "Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges".
Password History Access Report
USER_HISTORY$ table that stores hashed passwords that were previously used by each account. Access to this table can make guessing the existing password for an account easier for someone hacking the database.
WITH GRANT Privileges Report
WITH GRANT clause. Remember that WITH GRANT is used for object-level privileges: An account that has been granted privileges using the WITH GRANT option can be misused to grant object privileges to another account.
Roles/Accounts That Have a Given Role Report
Database Accounts With Catalog Roles Report
DBA role, which uses them.
AUDIT Privileges Report
AUDIT ANY or AUDIT SYSTEM privilege. This privilege can be used to disable auditing, which could be used to eliminate the audit trail record of a intruder who has compromised the system. The accounts that have this privilege could be targets for intruders.
Initialization Parameters and Profiles Reports
Security Related Database Parameters Report
Resource Profiles Report
CPU_PER_SESSION and IDLE_TIME, that may be allowing unlimited resource consumption. You should review the profiles that might need a cap on the potential resource usage.
System Resource Limits Report
Database Account Password Reports
Database Account Default Password Report
Database Account Status Report
Security Audit Report: Core Database Audit Report
AUDIT_TRAIL has been set to DB. For more information about the AUDIT_TRAIL parameter, see Oracle Database SQL Language Reference.
Other Security Vulnerability Reports
Java Policy Grants Report
GRANT, READ, or WRITE privileges to PUBLIC or other accounts and roles that do not necessarily need the privilege. It is advisable to disable Java loading privileges from PUBLIC, if Java is not required in the database.
OS Directory Objects Report
PUBLIC, and what their privileges are. Directory objects should exist only for secured operating system (OS) directories, and access to them within the database should be protected. You should never use the root operating system directory on any storage device (for example, /), because it allows remote database sessions to look at all files on the device.
Objects Dependent on Dynamic SQL Report
PUBLIC or a wider account base.
Unwrapped PL/SQL Package Bodies Report
Username/Password Tables Report
%USER%NAME% or %PASSWORD%.) If it is not, modify the code and applications using these tables to protect them from being visible to database sessions.
Tablespace Quotas Report
Non-Owner Object Trigger Report
PK^ޕ PK )A OEBPS/dvintro.htmaE
9 Integrating Oracle Database Vault with Other Oracle Products
Integrating Oracle Database Vault with Enterprise User Security
SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') = 'user_domain_name'
user_domain_name with the domain, for example:
SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') = 'myserver.us.example.com'
Integrating Oracle Database Vault with Transparent Data Encryption
SYSTEM user (or other user with privileges to manage Transparent Data Encryption) as at minimum a participant of the Database Dictionary Realm. See "ADD_AUTH_TO_REALM Procedure" for more information about adding a user to a realm.
Description of "Figure 9-1 Encrypted Data and Oracle Database Vault"
Attaching Factors to an Oracle Virtual Private Database
DVF.F$ PL/SQL function that is created for each factor.
Integrating Oracle Database Vault with Oracle Label Security
How Oracle Database Vault Is Integrated with Oracle Label Security
EMPLOYEE table that includes records that should have access limited to certain managers. Another label can be PUBLIC, which allows more open access to this data.DVSYS.AUDIT_TRAIL$ system file, described in Appendix A, "Auditing Oracle Database Vault."
Requirements for Using Oracle Database Vault with Oracle Label Security
LBACSYS user account. As a user who has been granted the DV_ACCTMGR role, unlock this account and grant it a new password. For example:
sqlplus amalcolm_dvacctmgr
Enter password: password
ALTER USER LBACSYS ACCOUNT UNLOCK IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.LBACSYS user account in Oracle Enterprise Manager, then log in to Enterprise Manager as user SYS with the SYSDBA privilege, and grant this user the SELECT ANY DICTIONARY and SELECT_CATALOG_ROLE system privileges.
Using Oracle Database Vault Factors with Oracle Label Security Policies
DV_OWNER or DV_ADMIN role.LBACSYS account an owner of the realm that contains the schema to which a label security policy has been applied.LBACSYS account to have access to all the protected data in the realm, so that it can properly classify the data.LBACSYS account is created in Oracle Label Security using the Oracle Universal Installer 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.DVSYS.DBMS_MACADM package to specify a merge algorithm, see Table 12-57, "Oracle Label Security Merge Algorithm Codes" for a full listing of possible merge algorithms.
Tutorial: Integrating Oracle Database Vault with Oracle Label Security
About This Tutorial
Step 1: Create Users for This Tutorial
DV_ACCTMGR role.
sqlplus amalcolm_dvacctmgr
Enter password: password
CREATE USER mdale IDENTIFIED BY password;
CREATE USER jsmith IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.SYS with the SYSDBA privilege and then grant administrative privileges to users mdale and jsmith.
CONNECT SYS AS SYSDBA
Enter password: password
GRANT CREATE SESSION, DBA TO mdale, jsmith;
mdale and jsmith have identical administrative privileges.
Step 2: Create the Oracle Label Security Policy
LBACSYS.
CONNECT LBACSYS
Enter password: password
LBACSYS is locked and expired, connect as the Database Vault Account Manager, unlock and unexpire the LBACSYS account, and then log back in as LBACSYS.
CONNECT amalcolm_dvacctmgr
Enter password: password
ALTER USER LBACSYS ACCOUNT UNLOCK IDENTIFIED BY password;
CONNECT LBACSYS
Enter password: password
EXEC SA_SYSDBA.CREATE_POLICY('PRIVACY','PRIVACY_COLUMN','NO_CONTROL');
PRIVACY policy:
EXEC SA_COMPONENTS.CREATE_LEVEL('PRIVACY',2000,'S','SENSITIVE');
EXEC SA_COMPONENTS.CREATE_LEVEL('PRIVACY',1000,'C','CONFIDENTIAL');
EXEC SA_COMPONENTS.CREATE_COMPARTMENT('PRIVACY',100,'PII','PERS_INFO');
mdale and jsmith the following labels:
EXEC SA_USER_ADMIN.SET_USER_LABELS('PRIVACY','mdale','S:PII');
EXEC SA_USER_ADMIN.SET_USER_LABELS('PRIVACY','jsmith','C');
mdale is granted the more sensitive label, Sensitive, which includes the PII compartment. User jsmith gets the Confidential label, which is less sensitive.
Step 3: Create Oracle Database Vault Rules to Control the OLS Authorization
CONNECT lbrown_dvowner
Enter password: password
EXEC DVSYS.DBMS_MACADM.CREATE_RULE_SET('PII Rule Set',
'Protect PII data from privileged users','Y',1,0,2,NULL,NULL,0,NULL);
EXEC DVSYS.DBMS_MACADM.CREATE_RULE('Check OLS Factor',
'dominates(sa_utl.numeric_label(''PRIVACY''),
char_to_label(''PRIVACY'',''S:PII'')) = ''1''');
EXEC DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET('PII Rule Set',
'Check OLS Factor');
EXEC DVSYS.DBMS_MACADM.SYNC_RULES;
COMMIT;
Step 4: Update the ALTER SYSTEM Command Rule to Use the Rule Set
SELECT * FROM DVSYS.DBA_DV_COMMAND_RULE WHERE COMMAND = 'ALTER SYSTEM';
EXEC DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE('ALTER SYSTEM', 'PII Rule Set', '%', '%', 'Y');
Step 5: Test the Authorizations
mdale.
CONNECT mdale
Enter password: password
AUDIT_TRAIL initialization parameter.
SHOW PARAMETER AUDIT_TRAIL
NAME TYPE VALUE
------------------------------------ ----------- ----------------------
audit_trail string DB
mdale, use the ALTER SYSTEM statement to modify the AUDIT_TRAIL parameter.
ALTER SYSTEM SET AUDIT_TRAIL=OS, EXTENDED SCOPE=SPFILE;
System altered.
mdale was assigned the Sensitive label with the PII compartment, he can use the ALTER SYSTEM statement to modify the AUDIT_TRAIL system parameter.AUDIT_TRAIL parameter back to its original value, for example:
ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;
jsmith and then issue the same ALTER SYSTEM statement:
CONNECT jsmith
Enter password: password
ALTER SYSTEM SET AUDIT_TRAIL=OS, EXTENDED SCOPE=SPFILE;
ERROR at line 1:
ORA-01031: insufficient privileges
jsmith was assigned only the Confidential label, he cannot perform the ALTER SYSTEM statement.SYSTEM, who normally has the ALTER SYSTEM privilege, and issue the same ALTER SYSTEM statement:
CONNECT SYSTEM
Enter password: password
ERROR at line 1:
ORA-01031: insufficient privileges
SYSTEM no longer has sufficient privileges needed to perform an ALTER SYSTEM statement. Only users who have been assigned the Sensitive label, as with user mdale, can use the ALTER SYSTEM statement.
Step 6: Remove the Components for This Tutorial
CONNECT LBACSYS
Enter password: password
EXEC SA_SYSDBA.DROP_POLICY('PRIVACY', TRUE);
CONNECT lbrown_dvowner
Enter password: password
EXEC DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE('ALTER SYSTEM', 'Allow System Parameters','%', '%', 'Y');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('PII Rule Set', 'Check OLS Factor');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check OLS Factor');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('PII Rule Set');
COMMIT;
mdale and jsmith.
CONNECT amalcolm_dvacctmgr
Enter password: password
DROP USER mdale;
DROP USER jsmith;
Related Reports and Data Dictionary Views
Report Description
EXEMPT ACCESS POLICY system privilege granted to them. Accounts that have this privilege can bypass all Virtual Private Database policy filters and any Oracle Label Security policies that use Oracle Virtual Private Database indirectly.
Data Dictionary View Description
DBA_DV_IDENTITY view for each policy
PK
;a a PK )A
OEBPS/lot.htm."
1 Introducing Oracle Database Vault
What Is Oracle Database Vault?
http://www.oracle.com/technetwork/database/focus-areas/security/dbv-faq-083210.htmlhttp://www.oracle.com/technetwork/database/options/database-vault/index-085211.html
Components of Oracle Database Vault
Oracle Database Vault Access Control Components
SELECT, ALTER SYSTEM, database definition language (DDL), and data manipulation language (DML) statements. Command rules must work with rule sets to determine whether the statement is allowed. Chapter 6, "Configuring Command Rules," discusses command rules in detail.
Oracle Database Vault Administrator
Oracle Database Vault DVSYS and DVF Schemas
DVSYS, which stores the database objects needed to process Oracle data for Oracle Database Vault. This schema contains the roles, views, accounts, functions, and other database objects that Oracle Database Vault uses. The DVF schema contains public functions to retrieve (at run time) the factor values set in the Oracle Database Vault access control configuration.
Oracle Database Vault PL/SQL Interfaces and Packages
Oracle Database Vault and Oracle Label Security PL/SQL APIs
Oracle Database Vault Reporting and Monitoring Tools
How Oracle Database Vault Addresses Compliance Regulations
Regulation Potential Security Threat
How Oracle Database Vault Addresses Insider Threats
ALTER SYSTEM statement to a specific IP address and host name.
How Oracle Database Vault Allows for Flexible Security Policies
SYSTEM, who has the DBA role, can make modifications to basic parameters in a database. Suppose an inexperienced administrator who has system privileges decides to start a new redo log file but does not realize that doing so at a particular time may cause problems for the database. With Oracle Database Vault, you can create a command rule to prevent this user from making such modifications by limiting his or her usage of the ALTER SYSTEM SWITCH LOGFILE statement. Furthermore, you can attach rules to the command rule to restrict activity further, such as limiting the statement's execution in the following ways:
How Oracle Database Vault Addresses Database Consolidation Concerns
Description of "Figure 1-1 Oracle Database Vault Security"
SELECT ANY TABLE privilege can be prevented from using that privilege to view application data.
PKM. . PK )A OEBPS/cfseappr.htmvm
List of Tables
PKŅvv v PK )A OEBPS/db_objects.htm
8 Configuring Secure Application Roles for Oracle Database Vault
What Are Secure Application Roles in Oracle Database Vault?
Creating and Editing Secure Application Roles
DV_OWNER or DV_ADMIN role.
GRANT myExistingDBrole TO myDVrole;
DVSYS.DBMS_MACSEC_ROLES.SET_ROLE in your application code to accomplish this. See "SET_ROLE Procedure" for more information about the SET_ROLE function.CREATE ROLE statement, described in Oracle Database SQL Language Reference. This attribute is mandatory.DVSYS.DBMS_MACSEC_ROLES.SET_ROLE function to try to enable the role. Note that whether or not the role will be enabled depends on the evaluation result of the associated rule set.DVSYS.DBMS_MACSEC_ROLES.SET_ROLE function will not be able to enable the role.DVSYS.DBMS_MACSEC_ROLES.SET_ROLE function.DVSYS.DBMS_MACSEC_ROLES.SET_ROLE, if the rule set evaluates to true, then Oracle Database Vault sets the role for the database session. If the rule set evaluates to false, then the role is not set.
Securing a Secure Application Role
DROP ROLE SQL statement to delete secure application roles that were created using Oracle Database Vault.
Deleting a Secure Application Role
How Secure Application Roles Work
DVSYS.DBMS_MACADM package.DVSYS.DBMS_MACSEC_ROLES.SET_ROLE function.
Tutorial: Granting Access with Database Vault Secure Application Roles
About This Tutorial
SELECT SQL statement on the ORDERS table in the OE schema to a specific set of users. Furthermore, these users can only perform these statements on the OE.ORDERS table from within the office, not from a remote connection. To accomplish this, you create an Oracle Database Vault secure application role that is enabled for the user only if the user passes the checks enforced by the rule set that you associate with the secure application role.
Step 1: Create Users for This Tutorial
DV_ACCTMGR role.
sqlplus amalcolm_dvacctmgr
Enter password: password
CREATE USER eabel IDENTIFIED BY password;
CREATE USER ahutton IDENTIFIED BY password;
CREATE USER ldoran IDENTIFIED BY password;
password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.SYS using the SYSDBA privilege, and then grant these users the CREATE SESSION privilege.
CONNECT SYS AS SYSDBA
Enter password: password
GRANT CREATE SESSION TO eabel, ahutton, ldoran;
Step 2: Enable the OE User Account
DV_ACCTMGR user.
CONNECT amalcolm_dvacctmgr
Enter password: password
OE account.
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'OE';
OE account is locked and expired, unlock it and assign it a new password.
ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY password;
Step 3: Create the Rule Set and Its Rules
DV_OWNER or DV_ADMIN role.Can Modify OrdersRule set to control who can modify orders in the OE.ORDERS table
Rule Name Rule Expression Check IP AddressDVF.F$CLIENT_IP = '192.0.2.12'Check Session UserDVF.F$SESSION_USER IN ('EABEL', 'AHUTTON')UPPER(SYS_CONTEXT('USERENV','IP_ADDRESS')) = '192.0.2.12'UPPER(SYS_CONTEXT('USERENV','SESSION_USER')) IN ('EABEL', 'AHUTTON')
Step 4: Create the Database Vault Secure Application Role
ORDERS_MGMT to name the role.
Step 5: Grant the SELECT Privilege to the Secure Application Role
OE.
CONNECT OE
Enter password: password
SELECT privilege to the ORDERS_MGMT Database Vault Secure application role.
GRANT SELECT ON ORDERS TO ORDERS_MGMT;
Step 6: Test the Database Vault Secure Application Role
eabel.
CONNECT eabel@orcl
Enter password: password
orcl with the name of your database instance.ORDERS_MGMT role.
EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('ORDERS_MGMT');
OE.ORDERS table.
SELECT COUNT(*) FROM OE.ORDERS;
COUNT(*)
----------
105
eabel is logging directly into the database from the correct IP address and is listed as a valid session user, she can select from the OE.ORDERS table. If user ahutton logs in to SQL*Plus in the same manner, she also can select from the OE.ORDERS table.eabel without specifying the database instance, and then try to select from the OE.ORDERS table again.
CONNECT eabel
Enter password: password
EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('ORDERS_MGMT');
Error at line 1:
ORA-47305: Rule Set Violation on SET ROLE (Can Modfiy Orders)
...
SELECT COUNT(*) FROM OE.ORDERS;
ERROR at line 1:
ORA-00942: table or view does not exist
eabel is a valid user, she has violated the Check IP Address rule in the rule set, so she is not granted the ORDERS_MGMT role. The only way for the IP address to be recognized is to connect by specifying the database instance, as user eabel did in Step 1. (For an explanation about how this works, see Step 7 in "Step 3: Map the Domain Factor Identities to the Client_IP Factor", in Chapter 7.)ldoran and then enter the following statements:
EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('ORDERS_MGMT');
SELECT COUNT(*) FROM OE.ORDERS;
ldoran is not a valid user, she is not granted the ORDERS_MGMT role. Therefore, she cannot select from the OE.ORDERS table.
Step 7: Remove the Components for This Tutorial
DV_OWNER or DV_ADMIN user.
CONNECT lbrown_dvowner
Enter password: password
ORDERS_MGMT secure application role.
EXEC DVSYS.DBMS_MACADM.DELETE_ROLE('ORDERS_MGMT');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('Can Modify Orders', 'Check IP Address');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('Can Modify Orders', 'Check Session User');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check IP Address');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check Session User');
EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('Can Modify Orders');
COMMIT;
CONNECT amalcolm_dvacctmgr
Enter password: password
DROP USER eabel;
DROP USER ahutton;
DROP USER ldoran;
OE user account.
ALTER USER OE ACCOUNT LOCK PASSWORD EXPIRE;
How Secure Application Roles Affect Performance
Statspack, and TKPROF. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Database Control, refer to its online Help. Oracle Database Performance Tuning Guide describes the Statspack and TKPROF utilities.
Related Reports and Data Dictionary View
Report Description
DBA_DV_ROLE data dictionary view to find the Oracle Database Vault secure application roles used in privilege management. See "DBA_DV_ROLE View" for more information.
PK*U, PK )A OEBPS/dvdisabl.htm2
11 Oracle Database Vault Objects
Oracle Database Vault Schemas
DVSYS Schema
DVSYS schema contains Oracle Database Vault database objects, which store Oracle Database Vault configuration information and support the administration and run-time processing of Oracle Database Vault. In a default installation, the DVSYS schema is locked. The DVSYS schema also owns the AUDIT_TRAIL$ table.DVSYS schema by using a protected schema design. A protected schema design guards the schema against improper use of system privileges (for example, SELECT ANY TABLE, CREATE ANY VIEW, or DROP ANY).DVSYS schema in the following ways:DVSYS protected schema and its administrative roles cannot be dropped. By default, the DVSYS account is locked.CREATE USER, ALTER USER, DROP USER, CREATE PROFILE, ALTER PROFILE, and DROP PROFILE can only be issued by a user with the DV_ACCTMGR role. SYSDBA can issue these statements only if it is allowed to do so by modifying the Can Maintain Accounts/Profiles rule set.ANY system privileges for database definition language (DDL) and data manipulation language (DML) commands are blocked in the protected schema. This means that the objects in the DVSYS schema must be created by the schema account itself. Also, access to the schema objects must be authorized through object privilege grants.DVSYS schema can only be granted to administrative roles in the schema. This means that users can access the protected schema only through predefined administrative roles.DVSYS can issue ALTER ROLE statements on predefined administrative roles of the schema. "Oracle Database Vault Roles" describes Oracle Database Vault administrative roles in detail.DVSYS can grant predefined roles to users along with the ADMIN OPTION. This means that a grantee with the ADMIN OPTION can grant the role to another user without the ADMIN OPTION.SYS.DBMS_SYS_SQL.PARSE_AS_USER procedure cannot be used to run SQL statements on behalf of the protected schema DVSYS.
DV_ADMIN and DV_OWNER, for example) provided they have sufficient privileges to do so.
DVF Schema
DVF schema is the owner of the Oracle Database Vault DBMS_MACSEC_FUNCTION PL/SQL package, which contains the functions that retrieve factor identities. After you install Oracle Database Vault, the installation process locks the DVF account to better secure it. When you create a new factor, Oracle Database Vault creates a new retrieval function for the factor and saves it in this schema.
Oracle Database Vault Roles
About Oracle Database Vault Roles
Description of "Figure 11-1 How Oracle Database Vault Roles Are Categorized"
SYSDBA can grant object privileges to an Oracle Database Vault role as long as the object is not in the DVSYS schema or realm.DV_PATCH_ADMIN, DV_STREAMS_ADMIN, DV_XSTREAM, DV_GOLDENGATE_ADMIN, and DV_GOLDENGATE_REDO_ACCESS roles are not included because they have no system privileges.)
Privilege DV_OWNER DV_ADMIN DV_MONITOR DV_SECANALYST DV_ACCTMGR DV_REALM_OWNER DV_REALM_RESOURCE DV_PUBLIC
DVSYS schema, EXEC
DVSYS packages, EXECUTE
DVSYS schema, SELECT
DVSYS schema, grant privileges on objects
DVF schema, EXECUTE
DVF schema, SELECT
SYS schema, SELECT
DV_OWNER and DV_ADMIN
SYSMAN schema, SELECT
CREATE, ALTER, DROP user accounts and profilesFoot 5
RESOURCE role privilegesFoot 8
EXECUTE privilege on all Oracle Database Vault PL/SQL packages.EXECUTE privilege on all Oracle Database Vault PL/SQL packages.DV_SECANALYST can query DVSYS schema objects through Oracle Database Vault-supplied views only.DV_PUBLIC can query DVSYS schema objects through Oracle Database Vault-supplied views only.DVSYS account, nor change the DVSYS password.ANY privileges, such as CREATE ANY, ALTER ANY, and DROP ANY.RESOURCE role provides the following system privileges: CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE.
DV_OWNER Database Vault Owner Role
DV_OWNER role to manage the Oracle Database Vault roles and its configuration. In this guide, the example account that uses this role is lbrown_dvowner.DV_OWNER role has the administrative capabilities that the DV_ADMIN role provides, and the reporting capabilities the DV_SECANALYST role provides. It also provides privileges for monitoring Oracle Database Vault. It is created when you install Oracle Database Vault, and has the most privileges on the DVSYS schema. In addition to DV_ADMIN role, the DV_OWNER role has the GRANT ANY ROLE, ADMINISTER DATABASE TRIGGER, and ALTER ANY TRIGGER privileges.
DV_OWNER user. This way, if the user is no longer available (for example, he or she left the company), then you can easily recreate this user account and then grant this user the DV_OWNER role.DV_OWNER role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_OWNER';
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_OWNER';
DV_OWNER account is created. The user who is granted this role is also granted the ADMIN option and can run any Oracle Database Vault roles (except DV_ACCTMGR) without the ADMIN OPTION to any account. Users granted this role also can run Oracle Database Vault reports and monitor Oracle Database Vault.DV_OWNER role can grant the DV_OWNER and DV_ADMIN roles to another user. The account granted this role can revoke any granted protected schema role from another account. Accounts such as SYS or SYSTEM, with the GRANT ANY ROLE system privilege alone (directly granted or indirectly granted using a role) do not have the right to grant or revoke the DV_OWNER role to or from any other database account. Note also that a user with the DV_OWNER role cannot grant or revoke the DV_ACCTMGR role.DV_OWNER role, you must revoke the DV_OWNER role from that user account. However, be cautious about revoking the DV_OWNER role. At least one user on your site must have this role granted. If another DV_OWNER user has been granted this role and needs to have his or her password changed, then you can temporarily revoke DV_OWNER from that user. Note also that if you have been granted the DV_OWNER role, then you can change your own password without having to revoke the role from yourself.DV_OWNER user password:DV_OWNER role.DV_OWNER role from the user account whose password needs to change.DV_ACCTMGR role and then change the password for this user.DV_OWNER user and then grant the DV_OWNER role back to the user whose password you changed.ALTER USER privilege, and then modify the DV_OWNER user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_ADMIN Database Vault Configuration Administrator Role
DV_ADMIN role controls the Oracle Database Vault PL/SQL packages.DV_ADMIN role has the EXECUTE privilege on the DVSYS packages (DBMS_MACADM, DBMS_MACSECROLES, and DBMS_MACUTL). DV_ADMIN also has the capabilities provided by the DV_SECANALYST role, which allow the user to run Oracle Database Vault reports and monitor Oracle Database Vault. During installation, the DV_ADMIN role is granted to the DV_OWNER role with the ADMIN OPTION during installation.DV_ADMIN role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_ADMIN';
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_ADMIN';
SYS or SYSTEM, with the GRANT ANY ROLE system privilege alone do not have the rights to g rant or revoke DV_ADMIN from any other database account. The user with the DV_OWNER or DV_ADMIN role can grant or revoke this role to and from any database account.DV_ADMIN role, you must revoke the DV_ADMIN role from this account. If you have been granted the DV_ADMIN role, then you can change your own password without having to revoke the role from yourself.DV_ADMIN user password:DV_OWNER role.DV_ADMIN role from the user account whose password needs to change.DV_ACCTMGR role and then change the password for this user.DV_OWNER user and then grant the DV_ADMIN role back to the user whose password you changed.ALTER USER privilege, and then modify the DV_ADMIN user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_MONITOR Database Vault Monitoring Role
DV_MONITOR role enables the Oracle Enterprise Manager Grid Control agent to monitor Oracle Database Vault for attempted violations and configuration issues with realm or command rule definitions. This enables Grid Control to read and propagate realm definitions and command rule definitions between databases.DV_MONITOR role, but it does have some the SELECT privilege on some SYS and DVSYS objects. To find the full list of DV_MONITOR object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_MONITOR';
DV_OWNER role, the DV_ADMIN role, the DV_SECANALYST role, and the DBSNMP user. Only a user who has been granted the DV_OWNER privilege can grant or revoke the DV_MONITOR role to another user. You cannot grant this role with the ADMIN option.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_SECANALYST Database Vault Security Analyst Role
DV_SECANALYST role to run Oracle Database Vault reports and monitor Oracle Database Vault. This role is also used for database-related reports. In addition, this role enables you to check the DVSYS configuration by querying the DVSYS views described in "Oracle Database Vault Data Dictionary Views".DV_SECANALYST role, but it does have the SELECT privilege for the DVSYS object schema and portions of the SYS and SYSMAN schema objects for reporting on DVSYS- and DVF-related entities. To find the full list of DV_SECANALYST object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_SECANALYST';
SYS or SYSTEM, with the GRANT ANY ROLE system privilege alone does not have the rights to grant this role to or revoke this role from any other database account. Only the user with the DV_OWNER role can grant or revoke this role to and from another user.DV_SECANALYST role, you must revoke the DV_SECANALYST role from this account. If you have been granted the DV_SECANALYST role, then you can change your own password without having to revoke the role from yourself.DV_SECANALYST user password:DV_OWNER role.DV_SECANALYST role from the user account whose password needs to change.DV_ACCTMGR role and then change the password for this user.DV_OWNER user and then grant the DV_SECANALYST role back to the user whose password you changed.ALTER USER privilege, and then modify the DV_SECANALYST user password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_STREAMS_ADMIN Oracle Streams Configuration Role
DV_STREAMS_ADMIN role to any user who is responsible for configuring Oracle Streams in an Oracle Database Vault environment. This enables the management of Oracle Streams processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle Streams.DV_STREAMS_ADMIN role, but it does have the SELECT privilege on DVSYS objects. To find the full list of DV_STREAMS_ADMIN object privileges, log in to SQL*Plus with administrative privileges and then enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_STREAMS_ADMIN';
DV_STREAMS_ADMIN role does not provide a sufficient set of database privileges for configuring Oracle Streams. Rather, the DV_STREAMS_ADMIN role is an additional requirement (that is, in addition to the privileges that Oracle Streams currently requires) for database administrators to configure Oracle Streams in an Oracle Database Vault environment.DV_STREAMS_ADMIN role with ADMIN OPTION. Only users who have been granted the DV_OWNER role can grant or revoke the DV_STREAMS_ADMIN role to or from other users.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_XSTREAM_ADMIN XStream Administrative Role
DV_XSTREAM_ADMIN role to any user who is responsible for configuring XStream in an Oracle Database Vault environment. This enables the management of XStream processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure XStream.DV_XSTREAM_ADMIN role.DV_XSTREAM_ADMIN role does not provide a sufficient set of database privileges for configuring XStream. Rather, the DV_XSTREAM_ADMIN role is an additional requirement (that is, in addition to the privileges that XStream currently requires) for database administrators to configure XStream in an Oracle Database Vault environment.DV_XSTREAM_ADMIN role with ADMIN OPTION. Only users who have been granted the DV_OWNER role can grant or revoke the DV_XSTREAM_ADMIN role to or from other users.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_GOLDENGATE_ADMIN Oracle GoldenGate Administrative Role
DV_GOLDENGATE_ADMIN role to any user who is responsible for configuring Oracle GoldenGate in an Oracle Database Vault environment. This enables the management of Oracle GoldenGate processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle GoldenGate.DV_GOLDENGATE_ADMIN role.DV_GOLDENGATE_ADMIN role does not provide a sufficient set of database privileges for configuring Oracle GoldenGate. Rather, the DV_GOLDENGATE_ADMIN role is an additional requirement (that is, in addition to the privileges that Oracle GoldenGate currently requires) for database administrators to configure XStream in an Oracle Database Vault environment.DV_GOLDENGATE_ADMIN role with ADMIN OPTION. Only users who have been granted the DV_OWNER role can grant or revoke the DV_GOLDENGATE_ADMIN role to or from other users.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_GOLDENGATE_REDO_ACCESS Oracle GoldenGate Redo Log Access Role
DV_GOLDENGATE_REDO_ACCESS role to any user who is responsible for using the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER method to access redo logs in an Oracle Database Vault environment. This enables the management of Oracle GoldenGate processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle GoldenGate.DV_GOLDENGATE_REDO_ACCESS role.DV_GOLDENGATE_REDO_ACCESS role does not provide a sufficient set of database privileges for configuring Oracle GoldenGate. Rather, the DV_GOLDENGATE_REDO_ACCESS role is an additional requirement (that is, in addition to the privileges that Oracle GoldenGate currently requires) for database administrators to configure Oracle Streams in an Oracle Database Vault environment.DV_GOLDENGATE_REDO_ACCESS role with ADMIN OPTION. Only users who have been granted the DV_OWNER role can grant or revoke the DV_GOLDENGATE_REDO_ACCESS role to or from other users.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_PATCH_ADMIN Database Vault Database Patch Role
DV_PATCH_ADMIN role to any database administrator who is responsible for performing database patching or adding languages to Database Vault. After the patch operation or language addition is complete, you should immediately revoke this role.DV_OWNER role can grant or revoke the DV_PATCH_ADMIN role to and from another user. You cannot grant the DV_PATCH_ADMIN role with the ADMIN option.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_ACCTMGR Database Vault Account Manager Role
DV_ACCTMGR role to create and maintain database accounts and database profiles. In this manual, the example DV_ACCTMGR role is assigned to a user named amalcolm_dvacctmgr.CREATE, ALTER, and DROP statements for users or profiles. However, a person who has been granted the DV_ACCTMGR role cannot perform the following operations:ALTER or DROP statements on the DVSYS accountALTER or DROP statements on users who have been granted the DV_ADMIN, DV_OWNER, DV_SECANALYST, and DV_MONITOR rolesDV_ADMIN, DV_OWNER, DV_SECANALYST, and DV_MONITOR rolesDV_ACCTMGR role, log in to SQL*Plus with administrative privileges and then enter the following queries:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_ACCTMGR';
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_ACCTMGR';
DV_ACCTMGR role to the data dictionary realm. See "Step 1: Adding the SYSTEM User to the Data Dictionary Realm" for an example.DV_ACCTMGR user to be able to grant other users ANY privileges, then log in as user SYS with the SYSDBA privilege and grant this user the GRANT ANY PRIVILEGE privilege.DV_ACCTMGR user. This way, if this user forgets his or her password, you can log in as the original DV_ACCTMGR account when you recreate the user's password. Otherwise, you must disable Oracle Database Vault, log in as SYS or SYSTEM to recreate the password, and then re-enable Database Vault.SYS or SYSTEM, with the GRANT ANY ROLE system privilege alone does not have the rights to grant this role to or revoke this role from any other database account. The account with the DV_ACCTMGR role and the ADMIN OPTION can grant this role without the ADMIN OPTION to any given database account and revoke this role from another account.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_REALM_OWNER Database Vault Realm DBA Role
DV_REALM_OWNER role to manage database objects in multiple schemas that define a realm. Grant this role to the database account owner who is responsible for managing one or more schema database accounts within a realm and the roles associated with the realm.CREATE ANY, ALTER ANY, and DROP ANY within the realm. However, before this user can exercise these privileges, you must make this user either a participant or an owner for the realm. See "Defining Realm Authorization" for instructions.DV_REALM_OWNER role, but it does have some system privileges. To find the full list of DV_REALM_OWNER system privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_REALM_OWNER';
SYS, can grant this role to any given database account or role. Note that though this role has system privilege grants that SYS controls, it does not have the DV_OWNER or DV_ADMIN roles.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_REALM_RESOURCE Database Vault Application Resource Owner Role
DV_REALM_RESOURCE role for operations such as creating tables, views, triggers, synonyms, and other objects that a realm would typically use.DV_REALM_RESOURCE role provides the same system privileges as the Oracle RESOURCE role. In addition, both CREATE SYNONYM and CREATE VIEW are granted to this role.DV_REALM_RESOURCE role, but it does have some system privileges. To find the full list of DV_REALM_RESOURCE system privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'DV_REALM_RESOURCE';
SYS controls, it does not have the DV_OWNER or DV_ADMIN role.DV_REALM_RESOURCE role to a database account that owns database tables, objects, triggers, views, procedures, and so on that are used to support any database application. This is a role designed for a schema type database account. The realm owner of the Oracle Data Dictionary realm, such as SYS, can grant this role to any database account or role.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
DV_PUBLIC Database Vault PUBLIC Role
DV_PUBLIC role to grant privileges on specific objects in the DVSYS schema. (Remember that in a default installation, the DVSYS schema is locked.)DV_PUBLIC:DVF schema, these are functions for each factor defined. These are functions that you can use in rule sets to inspect the SQL statement that you want the rule set to protect.DVSYS.DBMS_MACSEC_ROLES package, described in Chapter 13, "Using the DVSYS.DBMS_MACSEC_ROLES Package." This package enables you to check the authorization for a user or to set an Oracle Database Vault secure application role.DVSYS.DBMS_MACUTL package, described in Chapter 14, "Using the DVSYS.DBMS_MACUTL Package." This package is a set of general purpose utilit y functions that you can use throughout the application code you write for Oracle Database Vault.DV_PUBLIC role, but it does have some object privileges. To find the full list of DV_PUBLIC object privileges, log in to SQL*Plus with administrative privileges and enter the following query:
SELECT TABLE_NAME, OWNER, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'DV_PUBLIC';
DVSYS schema to PUBLIC. You must grant the object privilege on the DVSYS schema object the DV_PUBLIC role, and then grant DV_PUBLIC to PUBLIC. However, if you do this, it is important that you do not add more object privileges to the PUBLIC role. Doing so may undermine Oracle Database Vault security.DV_OWNER, is enforced only if Oracle Database Vault is enabled. If Oracle Database Vault is disabled, then any account with the GRANT ANY ROLE system privilege can perform GRANT and REVOKE operations on protected schema roles.
Oracle Database Vault Accounts
DV_OWNER role. This account can manage Oracle Database Vault roles and configuration. (See "DV_OWNER Database Vault Owner Role" for detailed information about this role.)DV_ACCTMGR role. This account is used to manage database user accounts to facilitate separation of duties. (See "DV_ACCTMGR Database Vault Account Manager Role" for detailed information about this role.)DV_OWNER and DV_ACCTMGR roles are granted to the Oracle Database Vault Owner user account.
Database Account Roles and Privileges Description
Database Account Roles and Privileges Description
EBROWN
DV_OWNER (with DV_ADMIN and DV_SECANALYST)
DVSYS realm. This account can:DVSYS packagesEXECUTE privileges in the DVSYS schemaDVSYS schema objects
JGODFREY
DV_ACCTMGR
DV_ACCTMGR roleCONNECT roleRESOURCE or DBA roles.
RLAYTON
DV_ADMIN (with DV_SECANALYST)
DVSYS packagesEXECUTE privileges in the DVSYS schemaDVSYS tables.
PSMYTHE
DV_SECANALYST
Oracle Database Vault Data Dictionary Views
DBA-style data dictionary views that can be accessed through the DV_SECANALYST role or the DV_ADMIN role. (Alternatively, you can run reports on Oracle Database Vault. See Chapter 17, "Oracle Database Vault Reports," for more information.) These views provide access to the various underlying Oracle Database Vault tables in the DVSYS and LBACSYS schemas without exposing the primary and foreign key columns that may be present. These views are intended for the database administrative user to report on the state of the Oracle Database Vault configuration without having to perform the joins required to get the labels for codes that are stored in the core tables or from the related tables.
DBA_DV_CODE View
DBA_DV_CODE data dictionary view lists generic lookup codes for the user interface, error messages, constraint checking, and so on. These codes are used for the user interface, views, and for validating input in a translatable fashion.
SELECT CODE, VALUE FROM DVSYS.DBA_DV_CODE WHERE CODE_GROUP = 'BOOLEAN';
CODE VALUE
------- --------
Y True
N False
Column Datatype Null Description CODE_GROUPVARCHAR(30)NOT NULLDisplays one of the following code groups:
AUDIT_EVENTS: Contains the action numbers and action names that are used for the custom event audit trail recordsBOOLEAN: A simple Yes or No or True or False lookupDB_OBJECT_TYPE: The database object types that can be used for realm objects and command authorizationsSQL_CMDS: The DDL commands that can be protected through command rulesFACTOR_AUDIT: The auditing options for factor retrieval processingFACTOR_EVALUATE: The evaluation options (by session or by access) for factor retrievalFACTOR_FAIL: The options for propagating errors when a factor retrieval method failsFACTOR_IDENTIFY: The options for determining how a factor identifier is resolved (for example, by method or by factors)FACTOR_LABEL: The options for determining how a factor identifier is labeled in the session establishment phaseLABEL_ALG: The algorithms that can be used to determine the maximum session label for a database session for each policy. See Table 12-57, "Oracle Label Security Merge Algorithm Codes" for a listing of the Oracle Label Security merge algorithm codes.OPERATORS: The Boolean operators that can be used for identity mapsREALM_AUDIT: The options for auditing realm access or realm violationsREALM_OPTION: The options for ownership of a realmRULESET_AUDIT: The options for auditing rule set execution or rule set errorsRULESET_EVALUATE: The options for determining the success or failure of a rule set based on all associated rules being true or any associated rule being trueRULESET_EVENT: The options to invoke a custom event handler when a rule set evaluates to Succeeds or FailsRULESET_FAIL: The options to determine the run-time visibility of a rule set failingCODEVARCHAR(30)NOT NULLBoolean code used; either Y (yes) or N (no).VALUEVARCHAR(4000)Boolean value used; either True if the Boolean code is Y or False if the Boolean code is N.LANGUAGEVARCHAR(3)NOT NULLLanguage for this installation of Oracle Database Vault.
DESCRIPTIONVARCHAR(1024)Brief description of the code group.
DBA_DV_COMMAND_RULE View
DBA_DV_COMMAND_RULE data dictionary view lists the SQL statements that are protected by command rules. See Chapter 6, "Configuring Command Rules," for more information about command rules.
SELECT COMMAND, RULE_SET_NAME FROM DVSYS.DBA_DV_COMMAND_RULE;
COMMAND RULE_SET_NAME
--------------- -----------------------------
GRANT Can Grant VPD Administration
REVOKE Can Grant VPD Administration
ALTER SYSTEM Allow System Parameters
ALTER USER Can Maintain Own Account
CREATE USER Can Maintain Account/Profiles
DROP USER Can Maintain Account/Profiles
CREATE PROFILE Can Maintain Account/Profiles
DROP PROFILE Can Maintain Account/Profiles
ALTER PROFILE Can Maintain Account/Profiles
Column Datatype Null Description COMMANDVARCHAR(30)NOT NULLName of the command rule. For a list of default command rules, see Default Command Rules. RULE_SET_NAMEVARCHAR(90)NOT NULLName of the rule set associated with this command rule. OBJECT_OWNERVARCHAR(30)NOT NULLThe owner of the object that the command rule affects. OBJECT_NAMEVARCHAR(128)NOT NULLThe name of the database object the command rule affects (for example, a database table). ENABLEDVARCHAR(1)NOT NULLY indicates the command rule is enabled; N indicates it is disabled.
DBA_DV_FACTOR View
DBA_DV_FACTOR data dictionary view lists the existing factors in the current database instance.
SELECT NAME, GET_EXPR FROM DVSYS.DBA_DV_FACTOR WHERE NAME = 'Session_User';
NAME GET_EXPR
------------- ---------------------------------------------
Session_User UPPER(SYS_CONTEXT('USERENV', 'SESSION_USER'))
Column Datatype Null Description NAMEVARCHAR2(30)NOT NULLName of the factor. See "Default Factors" for a list of default factors. DESCRIPTIONVARCHAR2(4000)Description of the factor. FACTOR_TYPE_NAMEVARCHAR2(90)NOT NULLCategory of the factor, which is used to classify the purpose of the factor. ASSIGN_RULE_SET_NAMEVARCHAR2(90)Rule set used to control the identify of the factor. GET_EXPRVARCHAR2(1024)PL/SQL expression that retrieves the identity of a factor. VALIDATE_EXPRVARCHAR2(1024)PL/SQL expression used to validate the identify of the factor. It returns a Boolean value. IDENTIFIED_BYNUMBERNOT NULLDetermines the identity of a factor, based on the expression listed in the GET_EXPR column. Possible values are:
0: By constant1: By method2: By factorsIDENTIFIED_BY_MEANINGVARCHAR2(4000)Provides a text description for the corresponding value in the IDENTIFIED_BY column. Possible values are:
By Constant: If IDENTIFIED_COLUMN is 0By Method: If IDENTIFIED_COLUMN is 1By Factors: If IDENTIFIED_COLUMN is 2LABELED_BYNUMBERNOT NULLDetermines the labeling the factor:
0: Labels the identities for the factor directly from the labels associated with an Oracle Label Security policy1: Derives the factor identity label from the labels of its child factor identities.LABELED_BY_MEANINGVARCHAR2(4000)Provides a text description for the corresponding value in the LABELED_BY column. Possible values are:
By Self: If LABELED_BY column is 0By Factors: If LABELED_BY column is 1EVAL_OPTIONSNUMBERNOT NULLDetermines how the factor is evaluated when the user logs on:
0: When the database session is created1: Each time the factor is accessed2: On start-upEVAL_OPTIONS_MEANINGVARCHAR2(4000)Provides a text description for the corresponding value in the EVAL_OPTIONS column. Possible values are:
For Session: If EVAL_OPTIONS is 0By Access: If EVAL_OPTIONS is 1On Startup: If EVAL_OPTIONS is 2AUDIT_OPTIONSNUMBERNOT NULLOption for auditing the factor if you want to generate a custom Oracle Database Vault audit record. Possible values are:
0: No auditing set1: Always audits2: Audits if get_expr returns an error4: Audits if get_expr is null8: Audits if the validation procedure returns an error16: Audits if the validation procedure is false32: Audits if there is no trust level set64: Audits if the trust level is negative.FAIL_OPTIONSNUMBERNOT NULLOptions for reporting factor errors:
1: Shows an error message.2: Does not show an error message.FAIL_OPTIONS_MEANINGVARCHAR2(4000)Provides a text description for the corresponding value in the FAIL_OPTIONS column. Possible values are:
Show Error MessageDo Not Show Error Message:
DBA_DV_FACTOR_LINK View
DBA_DV_FACTOR_LINK data dictionary view shows the relationships of each factor whose identity is determined by the association of child factors. The view contains one entry for each parent factor and child factor. You can use this view to resolve the relationships from the factor links to identity maps.
SELECT PARENT_FACTOR_NAME, CHILD_FACTOR_NAME FROM DVSYS.DBA_DV_FACTOR_LINK;
PARENT_FACTOR_NAME CHILD_FACTOR_NAME
------------------------------ ------------------------------
Domain Database_Instance
Domain Database_IP
Domain Database_Hostname
Column Datatype Null Description PARENT_FACTOR_NAMEVARCHAR(30)NOT NULLName of the parent factor. CHILD_FACTOR_NAMEVARCHAR(30)NOT NULLName of the child factor of the parent factor. LABEL_INDVARCHAR(1)NOT NULLIndicates whether the child factor that is linked to the parent factor contributes to the label of the parent factor in an Oracle Label Security integration. Possible values are:
Y (for Yes)N (for No)
DBA_DV_FACTOR_TYPE View
DBA_DV_FACTOR_TYPE data dictionary view lists the names and descriptions of factor types used in the system.
SELECT * FROM DVSYS.DBA_DV_FACTOR_TYPE WHERE NAME = 'Hostname';
NAME DESCRIPTION
--------- ----------------------------------------------------------------------
Time Time-based factor
Column Datatype Null Description NAMEVARCHAR(90)NOT NULLName of the factor type. DESCRIPTIONVARCHAR(1024)Description of the factor type.
DBA_DV_IDENTITY View
DBA_DV_IDENTITY data dictionary view lists the identities for each factor.
SELECT * FROM DVSYS.DBA_DV_IDENTITY WHERE VALUE = 'GLOBAL SHARED';
FACTOR_NAME VALUE TRUST_LEVEL
---------------- -------------- ------------
Identification_Type GLOBAL SHARED 1
Column Datatype Null Description FACTOR_NAMEVARCHAR(30)NOT NULLName of the factor. VALUEVARCHAR(1024)NOT NULLValue of the factor. TRUST_LEVELNUMBERNOT NULLNumber that indicates the magnitude of trust relative to other identities for the same factor.
DBA_DV_IDENTITY_MAP View
DBA_DV_IDENTITY_MAP data dictionary view lists the mappings for each factor identity. The view includes mapping factors that are identified by other factors to combinations of parent-child factor links. For each factor, the maps are joined by the OR operation, and for different factors, the maps are joined by the AND operation.
SELECT FACTOR_NAME, IDENTITY_VALUE FROM DVSYS.DBA_DV_IDENTITY_MAP;
FACTOR_NAME IDENTITY_VALUE
---------------- --------------------
Sector2_Program Accounting-Sensitive
Column Datatype Null Description FACTOR_NAMEVARCHAR(30)NOT NULLFactor the identity map is for. IDENTITY_VALUEVARCHAR(1024)NOT NULLValue the factor assumes if the identity map evaluates to TRUE.OPERATION_VALUEVARCHAR(4000)Relational operator for the identity map (for example, <, >, =, and so on) OPERAND1VARCHAR(1024)Left operand for the relational operator; refers to the low value you enter. OPERAND2VARCHAR(1024)Right operand for the relational operator; refers to the high value you enter. PARENT_FACTOR_NAMEVARCHAR(30)The parent factor link to which the map is related. CHILD_FACTOR_NAMEVARCHAR(30)The child factor link to which the map is related. LABEL_INDVARCHAR(1)Indicates whether the child factor being linked to the parent factor contributes to the label of the parent factor in an Oracle Label Security integration. Possible values are:
Y (for Yes)N (for No)
DBA_DV_MAC_POLICY View
DBA_DV_MAC_POLICY data dictionary view lists the Oracle Label Security policies defined for use with Oracle Database Vault.
SELECT POLICY_NAME, ALGORITHM_CODE, ALGORITHM_MEANING
FROM DVSYS.DBA_DV_MAC_POLICY;
POLICY_NAME ALGORITHM_CODE ALGORITHM_MEANING
--------------- ----------------- -----------------------
ACCESS_DATA LUI Minimum Level/Union/Intersection
Column Datatype Null Description POLICY_NAMEVARCHAR(30)NOT NULLName of the policy. ALGORITHM_CODEVARCHAR(30)NOT NULLMerge algorithm code used for the policy. See Table 12-57 for a listing of algorithm codes. ALGORITHM_MEANINGVARCHAR(4000)Provides a text description for the corresponding value in the ALGORITHM_CODE column. See Table 12-57 for a listing of algorithm code descriptions.ERROR_LABELVARCHAR(4000)Label specified for initialization errors, to be set when a configuration error or run-time error occurs during session initialization.
DBA_DV_MAC_POLICY_FACTOR View
DBA_DV_MAC_POLICY data dictionary view lists the factors that are associated with Oracle Label Security policies.DBA_DV_MAC_POLICY view.
SELECT * FROM DVSYS.DBA_DV_MAC_POLICY_FACTOR;
FACTOR_NAME MAC_POLICY_NAME
-------------- ------------------
App_Host_Name Access Locations
Column Datatype Null Description FACTOR_NAMEVARCHAR(30)NOT NULLName of the factor. MAC_POLICY_NAMEVARCHAR(30)NOT NULLName of the Oracle Label Security policy associated with this factor.
DBA_DV_POLICY_LABEL View
DBA_DV_POLICY_LABEL data dictionary view lists the Oracle Label Security label for each factor identifier in the DBA_DV_IDENTITY view for each policy.
SELECT * FROM DVSYS.DBA_DV_POLICY_LABEL;
IDENTITY_VALUE FACTOR_NAME POLICY_NAME LABEL
---------------- -------------- ---------------- ---------
App_Host_Name Sect2_Fin_Apps Access Locations Sensitive
Column Datatype Null Description IDENTITY_VALUEVARCHAR(1024)NOT NULLName of the factor identifier. FACTOR_NAMEVARCHAR(30)NOT NULLName of the factor associated with the factor identifier. POLICY_NAMEVARCHAR(30)NOT NULLName of the Oracle Label Security policy associated with this factor. LABELVARCHAR(4000)NOT NULLName of the Oracle Label Security label associated with the policy.
DBA_DV_PUB_PRIVS View
DBA_DV_PUB_PRIVS data dictionary view lists data reflected in the Oracle Database Vault privilege management reports used in the Oracle Database Vault Administrator (DV_ADMIN). See also "Privilege Management - Summary Reports".
SELECT USERNAME, ACCESS_TYPE FROM DVSYS.DBA_DV_PUB_PRIVS WHERE USERNAME = 'OE';
USERNAME ACCESS_TYPE
----------- -----------------
OE PUBLIC
Column Datatype Null Description USERNAMEVARCHAR(30)NOT NULLDatabase schema in the current database instance.acces ACCESS_TYPEVARCHAR(30)Access type granted to the user listed in the USERNAME column (for example, PUBLIC).PRIVILEGEVARCHAR(40)NOT NULLPrivilege granted to the user listed in the USERNAME column.OWNERVARCHAR(30)NOT NULLOwner of the database schema to which the USERNAME user has been granted privileges.OBJECT_NAMEVARCHAR(30)NOT NULLName of the object within the schema listed in the OWNER column.
DBA_DV_REALM View
DBA_DV_REALM data dictionary view lists the realms created in the current database instance.
SELECT NAME, AUDIT_OPTIONS, ENABLED FROM DVSYS.DBA_DV_REALM
WHERE AUDIT_OPTIONS = 'N';
NAME AUDIT_OPTIONS ENABLED
----------------------------- ---------------- --------
Performance Statistics Realm N 1
Column Datatype Null Description NAMEVARCHAR(90)NOT NULLNames of the realms created. See"Default Realms" for a listing of default realms. DESCRIPTIONVARCHAR(1024)NOT NULLDescription of the realm created. AUDIT_OPTIONSNUMBERNOT NULLSpecifies whether auditing is enabled. Possible values are:
0: No auditing for the realm.1: Creates an audit record when a realm violation occurs (for example, when an unauthorized user tries to modify an object that is protected by the realm).2: Creates an audit record for authorized activities on objects protected by the realm.3: Creates an audit record for both authorized and unauthorized activities on objects protected by the realm.ENABLEDVARCHAR(1)NOT NULLSpecifies whether realm checking is enabled. Y (yes) indicates it is enabled; N (no) indicates it is not.
DBA_DV_REALM_AUTH View
DBA_DV_REALM_AUTH data dictionary view lists the authorization of a named database user account or database role (GRANTEE) to access realm objects in a particular realm. See Defining Realm Authorization for more information.
SELECT REALM_NAME, GRANTEE, AUTH_RULE_SET_NAME FROM DVSYS.DBA_DV_REALM_AUTH;
REALM_NAME GRANTEE AUTH_RULE_SET_NAME
---------------------------- --------- ---------------------
Performance Statistics Realm SYSADM Check Conf Access
Column Datatype Null Description REALM_NAMEVARCHAR(90)NOT NULLName of the realm. GRANTEEVARCHAR(30)NOT NULLUser or role name to authorize as owner or participant. AUTH_RULE_SET_NAMEVARCHAR(90)Rule set to check before authorizing. If the rule set evaluates to TRUE, then the authorization is allowed.AUTH_OPTIONSVARCHAR(4000)Type of realm authorization: either Participant or Owner.
DBA_DV_REALM_OBJECT View
DBA_DV_REALM_OBJECT data dictionary view lists the database schemas, or subsets of schemas with specific database objects contained therein, that are secured by the realms. See "Creating Realm-Secured Objects" for more information.
SELECT REALM_NAME, OWNER, OBJECT_NAME FROM DVSYS.DBA_DV_REALM_OBJECT;
REALM_NAME OWNER OBJECT_NAME
---------------------------- -------- -----------
Performance Statistics Realm OE ORDERS
Column Datatype Null Description REALM_NAMEVARCHAR(90)NOT NULLName of the realm. OWNERVARCHAR(90)NOT NULLDatabase schema owner who owns the realm. OBJECT_NAMEVARCHAR(90)NOT NULLName of the object the realm protects. OBJECT_TYPEVARCHAR(90)NOT NULLType of object the realm protects, such as a database table, view, index, or role.
DBA_DV_ROLE View
DBA_DV_ROLE data dictionary view lists the Oracle Database Vault secure application roles used in privilege management.
SELECT ROLE, RULE_NAME FROM DVSYS.DBA_DV_ROLE;
ROLE RULE_NAME
------------------ --------------------
Sector2_APP_MGR Check App2 Access
Sector2_APP_DBA Check App2 Access
Column Datatype Null Description ROLEVARCHAR(30)NOT NULLName of the secure application role. RULE_NAMEVARCHAR(90)NOT NULLName of the rule set associated with the secure application role. ENABLEDVARCHAR(1)NOT NULLIndicates whether the secure application role is enabled. Y (yes) enables the role; N (no) disables it.
DBA_DV_RULE View
DBA_DV_RULE data dictionary view lists the rules that have been defined.
SELECT * FROM DVSYS.DBA_DV_RULE WHERE NAME = 'Maintenance Window';
NAME RULE_EXP
------------------- ----------------------------------------------
Maintenance Window TO_CHAR(SYSDATE,'HH24') BETWEEN '10' AND '12'
DBA_DV_RULE_SET_RULE view.
Column Datatype Null Description NAMEVARCHAR(90)NOT NULLName of the rule. RULE_EXPRVARCHAR(1024)NOT NULLPL/SQL expression for the rule.
DBA_DV_RULE_SET View
DBA_DV_RULE_SET data dictionary view lists the rules sets that have been created.
SELECT RULE_SET_NAME, HANDLER_OPTIONS, HANDLER FROM DVSYS.DBA_DV_RULE_SET
WHERE RULE_SET_NAME = 'Maintenance Period';
RULE_SET_NAME HANDLER_OPTIONS HANDLER
------------------- ---------------- ----------------------
Maintenance Period 1 dbavowner.email_alert
Column Datatype Null Description RULE_SET_NAMEVARCHAR(90)NOT NULLName of the rule set. DESCRIPTIONVARCHAR(1024)Description of the rule set. ENABLEDVARCHAR(1)NOT NULLIndicates whether the rule set has been enabled. Y (yes) enables the rule set; N (no) disables it.EVAL_OPTIONS_MEANINGVARCHAR(4000)For rules sets that contain multiple rules, determines how many rules are evaluated. Possible values are:
All True: All rules in the rule set must evaluate to true for the rule set itself to evaluate to TRUE.Any True: At least one rule in the rule set must evaluate to true for the rule set itself to evaluate to TRUE.AUDIT_OPTIONSNUMBERNOT NULLIndicates when auditing is used. Possible values are:
0: No auditing1: Audit on failure2: Audit on success3: Audit on both failure and successFAIL_OPTIONS_MEANINGVARCHAR(4000)Determines when an audit record is created for the rule set. Possible values are:
Do Not Show Error Message.Show Error MessageFAIL_MESSAGEVARCHAR(80)Error message for failure that is associated with the fail code listed in the FAIL_CODE column.FAIL_CODEVARCHAR(10)The error message number associated with the message listed in the FAIL_MESSAGE column. Possible values are in the ranges of -20000 to -20999 or 20000 to 20999.HANDLER_OPTIONSNUMBERNOT NULLDetermines how error handling is used. Possible values are:
0: Disables error handling.1: Call handler on rule set failure.2: Call handler on rule set success.HANDLERVARCHAR(1024)Name of the PL/SQL function or procedure that defines the custom event handler logic. IS_STATICVARCHAR2(5)Indicates how often the rule set is evaluated during a user session. Possible values are:
TRUE: The rule set is evaluated once, and result of the rule set is reused throughout the user session.FALSE (default): The rule set is evaluated each time it is accessed during the user session.
DBA_DV_RULE_SET_RULE View
DBA_DV_RULE_SET_RULE data dictionary view lists rules that are associated with existing rule sets.
SELECT RULE_SET_NAME, RULE_NAME, RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET_RULE
WHERE RULE_NAME = 'Is Security Officer';
RULE_SET_NAME RULE_NAME RULE_EXP
---------------------------- ------------------ ---------------------------------
Can Grant VPD Administration Is Security Owner DVSYS.DBMS_MACUTL.USER_HAS_ROLE_
VARCHAR('DV_OWNER',dvsys.dv_
login_user) = 'Y'
Column Datatype Null Description RULE_SET_NAMEVARCHAR(90)NOT NULLName of the rule set that contains the rule. RULE_NAMEVARCHAR(90)NOT NULLName of the rule. RULE_EXPRVARCHAR(1024)NOT NULLPL/SQL expression that defines the rule listed in the RULE_NAME column.ENABLEDVARCHAR(1)Indicates whether the rule is enabled or disabled. Y (yes) enables the rule set; N (no) disables it.RULE_ORDERNUMBERNOT NULLThe order in which rules are used within the rule set. Does not apply to this release.
DBA_DV_USER_PRIVS View
DBA_DV_USER_PRIVS data dictionary view lists the privileges for a database user account excluding privileges granted through the PUBLIC role.
SELECT USERNAME, ACCESS_TYPE, PRIVILEGE FROM DVSYS.DBA_DV_USER_PRIVS;
USERNAME ACCESS_TYPE PRIVILEGE
--------- -------------------- ------------
DVSYS DV_PUBLIC EXECUTE
DVOWNER DV_ADMIN SELECT
SYS SELECT_CATALOG_ROLE SELECT
...
Column Datatype Null Description USERNAMEVARCHAR(30)NOT NULLName of the database schema account in which privileges have been defined.</td> ACCESS_TYPEVARCHAR(30)Role the database user account listed in the USERNAME column uses to access the database. Oracle Database Vault accounts have direct access.PRIVILEGEVARCHAR(40)NOT NULLPrivilege granted to the user listed in the USERNAME column.OWNERVARCHAR(30)NOT NULLName of the database user account. OBJECT_NAMEVARCHAR(30)NOT NULLName of the PL/SQL function or procedure used to define privileges.
DBA_DV_USER_PRIVS_ALL View
DBA_DV_USER_PRIVS_ALL data dictionary view lists the privileges for a database account including privileges granted through PUBLIC.
SELECT USERNAME, ACCESS_TYPE, PRIVILEGE FROM DVSYS.DBA_DV_USER_PRIVS;
USERNAME ACCESS_TYPE PRIVILEGE
------------------- ------------ -----------------
AMALCOLM_DVACCTMGR CONNECT CREATE_SESSION
LBROWN_DVOWNER DIRECT CREATE PROCEDURE
...
Column Datatype Null Description USERNAMEVARCHAR(30)Name of the database schema account in which privileges have been defined. ACCESS_TYPEVARCHAR(30)Role the database user account listed in the USERNAME column uses to access the database. Oracle Database Vault accounts have direct access.PRIVILEGEVARCHAR(40)Privilege granted to the user listed in the USERNAME column.OWNERVARCHAR(30)Name of the database user account. OBJECT_NAMEVARCHAR(30)Name of the PL/SQL function or procedure used to define privileges.
PKA@ְ2 2 PK
)Aoa, mimetypePK )AUFV Q : iTunesMetadata.plistPK )AYu META-INF/container.xmlPK )A3gCf?# 0# OEBPS/cfrulset.htmPK )A΄/
X X |) OEBPS/dv_impact.htmPK )A[pT O ǁ OEBPS/cover.htmPK )Ay$AA A X OEBPS/whatsnew.htmPK )A;i Q OEBPS/title.htmPK )AFܻP K
4 OEBPS/loe.htmPK )AٔNh OEBPS/getting_started.htmPK )A" h OEBPS/plsql_interfaces.htmPK )A8B Disabling and Enabling Oracle Database Vault
When You Must Disable Oracle Database Vault
CONNECT role has been configured incorrectly. This is resulting in failed database logins for all accounts, including those with the DV_OWNER or DV_ADMIN role, who could correct this problem.
Checking if Oracle Database Vault Is Enabled or Disabled
V$OPTION data dictionary view. Any user can query this view. If Oracle Database Vault is enabled, the query returns TRUE. Otherwise, it returns FALSE.PARAMETER column value is case sensitive. For example:
SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';
PARAMETER VALUE
----------------------------- -----------------------
Oracle Database Vault TRUE
Step 1: Disable Oracle Database Vault
ORACLE_HOME, ORACLE_SID, and PATH are correctly set. Log in to SQL*Plus as user SYS with the SYSOPER privilege and shut down the database. Then from the command line, stop the Database Control console process and listener.
sqlplus sys as sysoper
Enter password: password
SQL> SHUTDOWN IMMEDIATE
SQL> EXIT
$ emctl stop dbconsole
$ lsnrctl stop [listener_name]
$ srvctl stop database -d db_name
Oracle.
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dv_off ioracle
ORACLE_HOME\bin directory, rename the oradvll.dll file to another name, such as oradvll.dll.dbl.SYS with the SYSOPER privilege and restart the database. Then from the command line, restart the Database Control process and listener.
sqlplus sys as sysoper
Enter password: password
SQL> STARTUP
SQL> EXIT
$ emctl start dbconsole
$ lsnrctl start [listener_name]
$ srvctl start database -d db_name
Oracle.
Step 2: Perform the Required Tasks
CONNECT rule set error, use the DBMS_MACADM PL/SQL package or the Oracle Database Vault Administrator interface.DV_ADMIN or DV_ACCTMGR roles. (See the tip under "Oracle Database Vault Accounts" for a guideline for avoiding this problem in the future.)
Step 3: Enable Oracle Database Vault
ORACLE_HOME, ORACLE_SID, and PATH are correctly set. Log in to SQL*Plus as user SYS with the SYSOPER privilege and shut down the database. Then from the command line, stop the Database Control console process and listener.
sqlplus sys as sysoper
Enter password: password
SQL> SHUTDOWN IMMEDIATE
SQL> EXIT
$ emctl stop dbconsole
$ lsnrctl stop [listener_name]
$ srvctl stop database -d db_name
Oracle.make command enables both Oracle Database Vault (dv_on) and Oracle Label Security (lbac_on). You must enable Oracle Label Security before you can use Database Vault.
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk dv_on lbac_on ioracle
ORACLE_HOME\bin directory, rename the backed up copy of the oradvll.dll file (for example, oradv11.dll.dbl) to oradvll.dll. Ensure that the name of the Oracle Label Security executable is oralbacll.dll (and not oralbacll.dll.dbl or some other backup name). You must enable Oracle Label Security before you can use Database Vault.SYS with the SYSOPER privilege and restart the database. Then from the command line, restart the Database Control console process and listener.
sqlplus sys as sysoper
Enter password: password
SQL> STARTUP
SQL> EXIT
$ emctl start dbconsole
$ lsnrctl start [listener_name]
$ srvctl start database -d db_name
Oracle.
