Database administrators can perform a specific set of operations in an Oracle Database Vault environment, such as using Database Vault with products such as Oracle Data Pump and Oracle GoldenGate.
Topics:
Privileges for Using Oracle Streams with Oracle Database Vault
Privileges for Using Oracle GoldenGate in with Oracle Database Vault
Database Vault administrators can perform tasks in Oracle Enterprise Manager Cloud Control (Cloud Control) such as propagate polices to other databases and configuring Cloud Control alerts for Database Vault policies.
Topics:
Propagating Oracle Database Vault Policies to Other Databases
Enterprise Manager Cloud Control Alerts for Oracle Database Vault Policies
Oracle Database Vault-Specific Reports in Enterprise Manager Cloud Control
Changing the DBSNMP Account Password in an Oracle Database Vault Environment
You can propagate Database Vault policies to other Database Vault-protected databases.
From Cloud Control, log into Oracle Database Vault Administrator as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
"Logging into Oracle Database Vault" explains how to log in.
In the Database Vault home page, under Policy Propagation, select Database Vault Policy Propagation.
The Available Policies area in the Policy Propagation subpage lists a summary of the Oracle Database Vault policies that were created for the current database. 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.
Cloud Control generates Oracle Database Vault-specific alerts. To view these alerts, you must be granted the DV_OWNER
, DV_ADMIN
, or DV_SECANALYST
role.
The alerts are as follows:
Database Vault Attempted Realm Violations. This alert helps the Oracle Database Vault security analyst (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.
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 specific types of violations.
These violations are as follows:
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 into Database Vault Administrator as a user who has been granted the DV_OWNER
, DV_ADMIN
, or DV_SECANALYST
role.
Before you can change the password for the 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.)
Log into the database instance using an account that has been granted the DV_OWNER
role.
Revoke the DV_MONITOR
role from the DBSNMP
user account.
Connect as a user who has been granted the DV_ACCTMGR
role and then change the DBSNMP
user account password.
Connect as the DV_OWNER
user and then grant the DV_MONITOR
role back to the DBSNMP
user account.
Database administrators can authorize Oracle Data Pump users to work in a Database Vault environment.
Topics:
Authorizing Users for Oracle Data Pump Regular Export and Import Operations
Authorizing Users for Oracle Data Pump Transportable Export and Import Operations
Guidelines for Exporting or Importing Data in an Oracle Database Vault Environment
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.
If these users want to perform Oracle Data Pump transportable tablespace operations, then they must have special authorization. You can check a user's authorizations for using Data Pump in an Oracle Database Vault environment by querying the DVSYS.DBA_DV_DATAPUMP_AUTH
data dictionary view.
See Also:
Oracle Database Utilities for detailed information about Oracle Data Pump
Oracle Database Administrator's Guide for more information about transportable tablespaces
You can grant a range of different authorization types for administrators who are responsible for performing regular export and import operations in a Database Vault environment.
Topics:
About Authorizing Users for Oracle Data Pump Regular Operations
Levels of Database Vault Authorization for Oracle Data Pump Regular Operations
Authorizing Users for Oracle Data Pump Regular Operations in Database Vault
The Oracle Data Pump authorization that you grant to users enables them to perform regular Oracle Data Pump operations in a Database Vault environment, while full level Data Pump authorization enables them to perform transportable export and import operations as well.
If you want the user only to perform transportable export and import operations, then see "Authorizing Users for Oracle Data Pump Transportable Export and Import Operations".
Table 11-1 describes the levels of authorization required for Oracle Data Pump regular operations in a Database Vault environment.
Table 11-1 Levels of Authorization for Oracle Data Pump Regular Operations
Scenario | Authorization Required |
---|---|
A database administrator wants to import data into another schema. |
You must grant this user the |
A database administrator wants to export or import data in a schema that has no Database Vault protection. |
You only need to grant this user the standard Oracle Data Pump privileges, which are the |
A database administrator wants to export or import data in a protected schema. |
In addition to the If the user wants to import data, also grant this user the |
A database administrator wants to export or import the contents of an entire database. |
In addition to the |
Footnote 1 The BECOME USER
privilege is part of the IMP_FULL_DATABASE
role by default, but in an Oracle Database Vault environment, this privilege is revoked.
You can authorize a database administrator to use Data Pump for regular operations in an Oracle Database Vault environment.
Log into the database instance as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
Ensure that the user to whom you want to grant authorization has been granted the 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%';
Grant this user Oracle Database Vault authorization for Oracle Data Pump regular operations.
For example, to authorize the Data Pump user DP_MGR
to export and import objects for the database table EMPLOYEES
:
EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
To restrict DP_MGR
's activities to a specific schema, you would enter the following procedure:
EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
To authorize the Data Pump user DP_MGR
to export and import objects for the entire database, enter the following:
EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR');
See "AUTHORIZE_DATAPUMP_USER Procedure" for detailed information about this procedure.
After you run the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER
procedure, you can check the user's authorization by querying the DBA_DV_DATAPUMP_AUTH
data dictionary view, described in "DVSYS.DBA_DV_DATAPUMP_AUTH View".
If the user must export the entire database, then grant the user the DV_OWNER
role.
GRANT DV_OWNER TO DP_MGR;
You can revoke authorization from the database administrator who is using Oracle Data Pump for regular operations.
If you granted the user the DV_OWNER
role, then optionally revoke this role.
REVOKE DV_OWNER FROM DP_MGR;
Query the DVSYS.DBA_DV_DATAPUMP_AUTH
data dictionary view to find the users who have been granted Oracle Data Pump authorizations.
SELECT GRANTEE, SCHEMA, OBJECT FROM DVSYS.DBA_DV_DATAPUMP_AUTH;
Use the information you gathered from Step 2 to build the DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER
command.
For example:
EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
Ensure that this unauthorization complements the original authorization action. In other words, if you originally gave DP_MGR
authorization over the entire database, then the following commands will not work:
EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR'); EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
See "UNAUTHORIZE_DATAPUMP_USER Procedure" for more information.
You can grant a variety of authorization levels for users who are responsible for using Oracle Data Pump transportable operations.
Topics:
About Authorizing Users for Oracle Data Pump Transportable Operations
Levels of Database Vault Authorization for Data Pump Transportable Operations
Authorizing Users for Data Pump Transportable Operations in Database Vault
If you want users to only have the authorization to perform transportable export and import operations, then you must grant users the correct authorization, based on their tasks.
If your users must have Oracle Data Pump authorization to perform regular operations in a Database Vault environment, then see "Authorizing Users for Oracle Data Pump Regular Export and Import Operations".
Table 11-2 describes the levels of authorization required for users who want to perform export and import transportable operations in a Database Vault environment.
Table 11-2 Levels of Authorization for Oracle Data Pump Transporatable Operations
Scenario | Authorization Required |
---|---|
A database administrator wants to transportable export a tablespace or table that has no Database Vault protection. |
You only need to grant this user the standard Oracle Data Pump privileges, which are the |
A database administrator wants to transportable export a tablespace where there is Database Vault protection (for example, realm or command rule for a table object residing on that tablespace). |
In addition to the Remember that users who have been granted full database level Oracle Data Pump authorization (through the |
A database administrator wants to transportable export a table within a tablespace where there is Database Vault protection (for example, a realm or command rule for a table object residing on the tablespace that contains the table to be exported). |
In addition to the Remember that users who have been granted full database level Oracle Data Pump authorization (from the |
A database administrator wants to transportable export the contents of an entire database. |
In addition to the |
A database administrator wants to use a network link to transportable import a tablespace or a table that has no Database Vault protection. |
In addition to the |
A database administrator wants to use a network link to transportable import a tablespace where there is Database Vault protection (for example, realm or command rule for a table object residing on that tablespace) |
In addition to the Remember that users who have been granted Database Vault-specific full database level Oracle Data Pump authorization (through the |
A database administrator wants to use a network link to import a table within a transportable tablespace where there is Database Vault protection (for example, realm or command rule for a table object residing on the tablespace that contains the table to be exported) |
In addition to the Remember that users who have been granted Database Vault-specific full database level Oracle Data Pump authorization (through the |
A database administrator wants to use a network link to transportable import the contents of an entire database. |
In addition to the |
You can authorize users to perform Oracle Data Pump transportable export or import operations in a Database Vault environment.
Log into the database instance as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
Ensure that the user to whom you want to grant authorization has been granted the 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%';
If the user wants to transportable export or use a network link to transportable import the contents of an entire database, then grant the full database level Oracle Data Pump authorization by using the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER
procedure. Otherwise, bypass this step.
For example:
EXEC DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR');
If the user must have Database Vault-specific transportable tablespace authorization only, then grant this user this authorization.
For example:
EXEC DBMS_MACADM.AUTHORIZE_TTS_USER('DP_MGR', 'HR_TS');
If the user who wants to perform a transportable import operation wants to use a network link to perform the operation, then grant this user the DV_DATAPUMP_NETWORK_LINK
role.
For example:
GRANT DV_DATAPUMP_NETWORK_LINK TO DP_MGR;
If the user wants to transportable export or use a network link to transportable import the entire database, then grant this user the DV_OWNER
role.
GRANT DV_OWNER TO DP_MGR;
You can revoke authorization from the database administrator who is using Data Pump.
If you granted the user the DV_OWNER
role, then optionally revoke this role.
REVOKE DV_OWNER FROM DP_MGR;
Query the DVSYS.DBA_DV_TTS_AUTH
data dictionary view to find the users who have been granted Oracle Data Pump authorizations.
SELECT GRANTEE, TSNAME FROM DVSYS.DBA_DV_TTS_AUTH;
Use the information you gathered from Step 2 to build the DBMS_MACADM.UNAUTHORIZE_TTS_USER
statement.
For example:
EXEC DBMS_MACADM.UNUTHORIZE_TTS_USER('DP_MGR', 'HR_TS');
See "UNAUTHORIZE_TTS_USER Procedure" for more information.
If the user had transportable exported or used a network link to transportable import the contents of an entire database, then revoke the full database level Oracle Data Pump authorization.
For example:
EXEC DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR');
If the user who had performed a transportable import operation used a network link to perform the operation, then revoke the DV_DATAPUMP_NETWORK_LINK
role from this user.
For example:
REVOKE DV_DATAPUMP_NETWORK_LINK FROM DP_MGR;
After you have granted the database administrator who is using Oracle Data Pump the proper 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, then you easily can revert the database to its previous state. This guideline is especially useful if an intruder had managed to modify Oracle 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 DBMS_MACADM.AUTHORIZE_DATAPUMP_USER
procedure, but you can use either of the following methods to accomplish this task:
Run the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER
procedure 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.
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 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.
Note the following:
You cannot use the legacy EXP
and IMP
utilities with the direct path option (direct=y
) if Oracle Database Vault is enabled.
Users who have been granted Database Vault-specific Oracle Data Pump authorization through the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER
procedure or transportable tablespace authorization through the DBMS_MACADM.AUTHORIZE_TTS_USER
procedure can export and import database objects, but they cannot perform other activities, such as SELECT
queries on schema tables to which they normally do not have access. Similarly, users are not permitted to perform Data Pump operations on objects outside the designated data objects.
You must grant the DV_OWNER
role to users who want to export or import an entire database, because a full database export requires access to the DVSYS
schema, which stores the Oracle Database Vault policies. However, you cannot export the DVSYS
schema itself. Data Pump only exports the protection definitions. The target database must have the DVSYS
schema in it and Database Vault enabled before you can begin the import process.) Conversely, for a Data Pump import operation to apply the imported policies to the target database, it internally uses the DBMS_MACADM
PL/SQL package, which in turn requires the Data Pump user to have the DV_OWNER
role.
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.
Topics:
The level of authorization that you must grant depends on schema in which the administrator wants to perform a task.
Possible scenarios are as follows:
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 "About 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 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.
Later on, you can revoke this authorization by using the DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER
procedure. If the schema is not protected by a realm, then you do not need to run the DBMS_MACADM.AUTHORIZE_SCHEDULER_USER
procedure for the user.
You can authorize a user to schedule database jobs in a Database Vault environment.
Log into the database instance as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
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: 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.
For example:
SELECT GRANTEE, PRIVILEGE FROM DBA_SYS_PRIVS WHERE PRIVILEGE IN ('CREATE JOB', 'CREATE ANY JOB');
Grant this user Oracle Database Vault authorization.
For example, to authorize the user job_mgr
to schedule jobs for any schema in the database:
EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
Optionally, you can restrict job_mgr
's activities to a specific schema, as follows:
EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
See "AUTHORIZE_SCHEDULER_USER Procedure" for detailed information about this procedure.
Ensure that the user has been authorized by querying the DVSYS.DBA_DV_JOB_AUTH
data dictionary view as follows:
SELECT GRANTEE,SCHEMA FROM DVSYS.DBA_DV_JOB_AUTH WHERE GRANTEE = 'user_name';
See "DVSYS.DBA_DV_JOB_AUTH View" for more information about this view.
You can revoke authorization from a user for scheduling database jobs.
Query the DVSYS.DBA_DV_JOB_AUTH
data dictionary view to find the user's authorization.
SELECT GRANTEE, SCHEMA FROM DVSYS.DBA_DV_JOB_AUTH WHERE GRANTEE='username';
Use the information you gathered from Step 1 to build the DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER
command.
For example:
EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');
Ensure that this unauthorization complements the original authorization action. In other words, if you originally gave job_mgr
authorization over the entire database, then the following command will not work:
EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
See "UNAUTHORIZE_SCHEDULER_USER Procedure" for more information.
You can use 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.
See Also:
Oracle Database Backup and Recovery User's Guide
Oracle Database Backup and Recovery Reference
If you want to use Oracle Streams in an Oracle Database Vault environment, then you must have the correct privileges.
The privileges that you must have are as follows:
You must be granted the DV_STREAMS_ADMIN
role in order to configure the Oracle Streams capture process.
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:
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
See Also:
"DV_STREAMS_ADMIN Oracle Streams Configuration Role" for more information about the DV_STREAMS_ADMIN
role
"ADD_AUTH_TO_REALM Procedure" for more information about the DBMS_MACADM.ADD_AUTH_TO_REALM
procedure
If you want to use XStream in an Oracle Database Vault environment, then you must have the appropriate privileges.
These privileges are as follows:
You must be granted the DV_XSTREAM_ADMIN
role in order to configure the XStream.
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:
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
See Also:
"DV_XSTREAM_ADMIN XStream Administrative Role" for more information about the DV_XSTREAM_ADMIN
role
"ADD_AUTH_TO_REALM Procedure" for more information about the DBMS_MACADM.ADD_AUTH_TO_REALM
procedure
If you want to use Oracle GoldenGate in an Oracle Database Vault environment, then you must have the appropriate privileges.
These privileges are as follows:
You must be granted the DV_GOLDENGATE_ADMIN
role in order to configure the Oracle GoldenGate.
You must be granted the DV_GOLDENGATE_REDO_ACCESS
role if you want to use the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER
method to access redo logs.
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:
EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('realm_name','username');
See Also:
"DV_GOLDENGATE_ADMIN Oracle GoldenGate Administrative Role" for more information about the DV_GOLDENGATE_ADMIN
role
"DV_GOLDENGATE_REDO_ACCESS Oracle GoldenGate Redo Log Access Role" for more information about the DV_GOLDENGATE_REDO_ACCESS role
"ADD_AUTH_TO_REALM Procedure" for more information about the DBMS_MACADM.ADD_AUTH_TO_REALM
procedure
You can perform data masking in an Oracle Database Vault environment if you have the correct authorizations the database objects that are being masked.
Topics:
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
See Also:
Oracle Database Testing Guide for more information about data maskingIn 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 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.
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:
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
You can add data masking users to the Oracle Default Component Protection realm to give them data dictionary realm authorizations.
The Oracle Data Dictionary controls access to the Oracle Database catalog schemas, such as 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 Oracle Default Component Protection 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.
To add a user to the Oracle Default Component Protection realm, use the DBMS_MACADM.ADD_AUTH_TO_REALM
procedure.
For example:
BEGIN DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Oracle Default Component Protection Realm', grantee => 'DBA_JSMITH', auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT); END; /
To give users access to tables or schemas that they want to mask, you must authorize them for the appropriate realm.
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.
To authorize users for data masking to a realm that protects the objects they want to data mask, use the DBMS_MACADM.ADD_AUTH_TO_REALM
procedure.
The following example shows how to grant user DBA_JSMITH
authorization for the HR.EMPLOYEES
table, which is protected by a realm called Business Apps Realm:
BEGIN DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Business Apps Realm', grantee => 'DBA_JSMITH', auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT; END; /
For data masking, users must have the 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.
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:
BEGIN DBMS_MACADM.CREATE_RULE( rule_name => 'Is HDRISCOLL or DBA_JSMITH User', rule_expr =>'USER IN(''HDRISCOLL'',''DBA_JSMITH'')'; END; /
Create a rule set and then add the rule to it:
BEGIN 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 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; /
Create a command rule and then add this rule to it:
BEGIN 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; /
You can plug a legacy Database Vault-enabled PDB to a multitenant container database (CDB).
Connect to the root as a user who has been granted the DV_OWNER
role.
For example:
sqlplus c##sec_admin
Enter password: password
Grant the DV_PATCH_ADMIN
role to user SYS
with CONTAINER = CURRENT
.
GRANT DV_PATCH_ADMIN TO SYS CONTAINER = CURRENT;
In the root, connect as user SYS
with the SYSOPER
system privilege.
For example:
CONNECT SYS AS SYSOPER -- Or, CONNECT SYS@hrpdb AS SYSOPER Enter password: password
Restart the database in read-only mode.
For example:
SHUTDOWN IMMEDIATE STARTUP MOUNT ALTER DATABASE OPEN READ ONLY
Connect to the Database Vault-enabled database as a user who has the DV_OWNER
role.
For example:
CONNECT sec_admin@dv_db
Grant the DV_PATCH_ADMIN
role to user SYS
on this database.
GRANT DV_PATCH_ADMIN TO SYS;
Optionally, run the DBMS_PDB.CHECK_PLUG_COMPATIBILITY
function to determine whether the unplugged PDB is compatible with the CDB.
When you run the function, set the following parameters:
pdb_descr_file
: Set this parameter to the full path to the XML file that will contain a description of the PDB.
store_report
: Set this parameter to indicate whether you want to generate a report if the PDB is not compatible with the CDB. Set it to TRUE
to generate a report or FALSE
to not generate a report. A generated report is stored in the PDB_PLUG_IN_VIOLATIONS
temporary table and is generated only if the PDB is not compatible with the CDB.
For example, to determine whether a PDB described by the /disk1/usr/dv_db_pdb.xml
file is compatible with the current CDB, run the following PL/SQL block:
SET SERVEROUTPUT ON DECLARE compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file => '/disk1/usr/dv_db_pdb.xml', store_report => TRUE) WHEN TRUE THEN 'YES' ELSE 'NO' END; BEGIN DBMS_OUTPUT.PUT_LINE(compatible); END; /
If the output is YES
, then the PDB is compatible, and you can continue with the next step.
If the output is NO
, then the PDB is not compatible. You can check the PDB_PLUG_IN_VIOLATIONS
temporary table to see why it is not compatible.
Create an XML file that describes the PDB.
For example:
BEGIN DBMS_PDB.DESCRIBE( pdb_descr_file => '/disk1/oracle/dv_db.xml'); END; /
Run the CREATE PLUGGABLE DATABASE
statement, and specify the XML file in the USING
clause. Specify other clauses when they are required.
For example:
CREATE PLUGGABLE DATABASE dv_db_pdb AS CLONE USING 'dv_db.xml' NOCOPY;
See Oracle Database Administrator's Guide for more information about how to use the CREATE PLUGGABLE DATABASE
statement.
Connect to the PDB that you just created as user SYS
with the SYSDBA
administrative privilege.
CONNECT SYS@dv_db_pdb AS SYSDBA
Execute the noncdb_to_pdb.sql
script.
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
Open this PDB in a read-write restricted mode.
ALTER PLUGGABLE DATABASE dv_db_pdb OPEN READ WRITE RESTRICTED;
Run the following procedure to synchronize the PDB:
EXECUTE DBMS_PDB.SYNC_PDB;
Connect to the root as a user who has been granted the DV_OWNER
role.
sqlplus c##sec_admin
Enter password: password
Revoke the DV_PATCH_ADMIN
role from user SYS
with CONTAINER = CURRENT
.
REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER = CURRENT;
Connect to the legacy Database Vault-enabled database as user SYS
with the SYSOPER
system privilege.
CONNECT SYS@dv_db_pdb AS SYSOPER
Restart this database.
For example:
SHUTDOWN IMMMEDIATE STARUP
Revoke the DV_PATCH_ADMIN
role from user SYS
.
REVOKE DV_PATCH_ADMIN FROM SYS;
The ORADEBUG
utility is used primarily by Oracle Support to diagnose problems that may arise with an Oracle database.
You can control whether users can run the ORADEBUG
utility in an Oracle Database Vault-enabled environment.
Log into the database instance as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
If necessary, find out if ORADEBUG
is already disabled or enabled.
SELECT * FROM DVSYS.DBA_DV_ORADEBUG;
Run one of the following procedures:
To disable the use of ORADEBUG
:
EXEC DBMS_MACADM.DISABLE_ORADEBUG;
To enable the use of ORADEBUG
:
EXEC DBMS_MACADM.ENABLE_ORADEBUG;