Realms enable you to protect database objects, including specific object types.

• About Realms
  A realm is a grouping of database schemas, database objects, and database roles that must be secured for a given application.
• Mandatory Realms to Restrict User Access to Objects within a Realm
  By default, users who own or have object privileges are allowed to access realm-protected objects without explicit realm authorization.
• Realms in a Multitenant Environment
  In a multitenant environment, you can create a realm to protect common objects in the application root.
• Object Types That Realms Can Protect
  You can create realms around all objects in a schema of certain object types.

Oracle Database Vault provides default realms, which are regular realms, not mandatory realms.

• Oracle Database Vault Realm
  The Oracle Database Vault realm protects configuration and role information in the Oracle Database Vault DVSYS, DVF, and LBACSYS schemas.
• Database Vault Account Management Realm
  The Database Vault Account Management realm defines the realm for the administrators who manage and create database accounts and database profiles.
• Oracle Enterprise Manager Realm
  Oracle Database Vault provides a realm specifically for Oracle Enterprise Manager accounts.
• Oracle Default Schema Protection Realm
  Oracle Default Schema Protection Realm protects roles and schemas that are used with Oracle features such as Oracle Text.
• Oracle System Privilege and Role Management Realm
  Oracle System Privilege and Role Management Realm protects sensitive roles that are used to export and import data in an Oracle database.
• Oracle Default Component Protection Realm
  Oracle Default Component Protection Realm protects the SYSTEM and OUTLN schemas.

To enable realm protection, you create the realm and configure it to include realm-secured objects, roles, and authorizations.

1. Log in to Oracle Database Vault Administrator from Cloud Control as a user who has been granted the DV_OWNER or DV_ADMIN role and the SELECT ANY DICTIONARY privilege. Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control explains how to log in.
2. In the Administration page, under Database Vault Components, click Realms.
3. In the Realms page, click Create to display the Create Realm page.
   
   
   Description of the illustration create_realm122.png
   
4. In the Create Realm page, enter the following settings:

   • 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, hr_app for an human resources application).

   • 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 for 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.

   • Mandatory Realm: Select this check box to create the realm as a mandatory realm. See Mandatory Realms to Restrict User Access to Objects within a Realm for more information about mandatory realms.

   • Status: Select either Enabled, Disabled, or Simulation. This attribute is mandatory.

   • Audit Options: Select one of the following:

     • Audit Disabled: Does not create an audit record.

     • Audit on Success: Creates an audit record for authorized activities.

     • Audit on Failure: 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.

     In a non-unified auditing environment, Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ table. See Auditing Oracle Database Vault for more information. If you have enabled unified auditing, then this setting does not capture audit records. Instead, you must create audit policies to capture this information, as described in Oracle Database Security Guide. Oracle Database also provides a default policy, ORA_DV_AUDPOL, that audits all actions that are performed on the Oracle Database Vault DVSYS and DVF schema objects and the Oracle Label Security LBACSYS schema objects.

5. Click Next to display the Realm secured objects page.

   See About Realm-Secured Objects for conceptual information about the settings for this page.

6. Click the Add button, and in the Add Secured Object dialog box, enter the following information:

   • Object Owner: From the list, select the name of the database schema owner. You can enter the % character if the object you want to secure with the realm is a role. This attribute is mandatory.

   • Object Type: From the list, select the type of the database object, such as TABLE, INDEX, or ROLE. This attribute is mandatory.

     You can add as many objects of any type as you want to the realm.

     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 % to specify all objects (except roles) for the object owner that you have specified. If you enter %, then it can encompass all objects in the schema if % is also used for the Object Type setting. But if Object Type is set to Tables, then using % for the Object Name refers to all tables in the schema. This attribute is mandatory.

     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.

     If you enter % in the Object Name field, then it encompasses all objects in the schema if you also enter % in the Object Type field. However, if you set Object Type to a specific object type, such as Tables, then the setting of % in Object Type refers to all objects of that type (in this case, tables) in the schema.

7. Click Next to display the Realm authorizations page.

   See About Realm Authorization for conceptual information about the settings for this page.

8. Click the Add button, and in the Add Authorizations dialog box, enter the following information:

   • Realm Authorization Grantee: From the list, select the database account or role to whom you want to grant the realm authorization.

     This list shows all accounts and roles in the system, not just accounts with system privileges.

   • Realm Authorization Type: Select either of the following settings. This attribute is mandatory.

     • Participant: This account or role can exercise system privileges to access, manipulate, and create objects protected by the realm, provided that these privileges 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 rights as the realm participant, plus the authorization to grant or revoke realm-secured database roles. The realm owner can grant or revoke privileges on realm-protected objects to other users. A realm can have multiple owners.

   • Realm 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.

9. Click Next to display the Review page.
10. In the Review page, check the settings you have created.

    For example:

    
    
    Description of the illustration realm_creation122.png
    
11. Click Finish to complete the realm creation.

Realm-secured objects define the territory—a set of schema and database objects and roles—that a realm protects.

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 the proper authorization. For 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, then the commands that 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. Schema owners can perform DML operations on objects that are protected by multiple regular realms.

  If one of the realms is a mandatory realm, then the user who wants to access the object must be a realm owner or participant in the mandatory realm. During the authorization checking process, the non-mandatory realms are ignored. If there are multiple mandatory realms that protect the object, then the user who wants to access the object must be authorized in all of the mandatory realms.

• SYS-owned objects are already protected by data dictionary protection and are not protected separately by Oracle Database Vault.

Realm authorizations establish the set of database accounts and roles that manage or access objects protected in realms.

You can grant a realm authorization to an account or role to allow the use of 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:

• Realm owners cannot add other users to their realms as owners or participants. Only users who have the DV_OWNER or DV_ADMIN role are allowed to add users as owners or participants to a realm.

• Users who have been granted the DV_OWNER role can add themselves to a realm authorization.

• A realm owner, but not a realm participant, can grant or revoke realm secured roles or grant or revoke object privileges on realm secured objects 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 types of existing realm authorizations.

Use the Edit Realm page to manage realm authorizations. You can create, edit, and remove realm authorizations.

You can disable or enable a realm, or set the realm to use simulation mode, from Enterprise Manager Cloud Control.

1. In the Oracle Database Vault Administration page, select Realms.
2. In the Realms page, select the realm you want to disable or enable, and then select Edit.
3. In the Edit Realm page, under Status in the General section, select either Disabled, Enabled, or Simulation.
4. Click Done, and then click Finished.

You can use Enterprise Manager Cloud Control to delete realms.

1. Locate the various references to the realm that you want to delete by querying the realm-related Oracle Database Vault data dictionary views.
2. If the Realm is part of a policy, then remove the realm from the policy.
   1. In the Oracle Database Vault Administration page, select Policies.
   2. Select the policy that contains the realm and then click Edit.
   3. Expand the Realms area.
   4. Select the realm and then click Remove.
   5. Click Next, then Finish.
3. In the Administration page, under Database Vault Components, select Realms.
4. In the Realms page, select the realm you want to delete, and then select Remove.
5. In the Confirmation window, click Yes.

   Oracle Database Vault deletes the configuration for the realm, including realm authorizations. It does not delete the rule sets used for realm authorizations.

When an appropriately privileged database account issues a SQL statement that affects an object within a realm, a special set of activities occur.

These privileges include DDL, DML, EXECUTE, GRANT, REVOKE, or SELECT privileges.

1. Does the SQL statement affect objects secured by a realm?

   If yes, then go to Step 2. If no, then realms do not affect the SQL statement. Go to Step 7. If the object affected by the command is not secured in any realms, then realms do not affect the SQL statement being attempted.

2. Is the realm a mandatory realm or regular realm?

   If yes, then go to Step 4. If it is regular realm, then go to Step 3.

3. Is the database account using a system privilege to execute the SQL statement?

   If yes, then go to Step 4. If no, then go to Step 6. If the session has object privileges on the object in question for SELECT, EXECUTE, and DML statements 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. Even users with object privileges for objects that are protected by regular realms are prevented from performing DDL operations.

   Remember that if the 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.

4. Is the database account a realm owner or realm participant?

   If yes, then go to Step 5. Otherwise, a realm violation occurs and the statement is not allowed to succeed. If the command is a 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, then the session must be authorized as the realm owner directly or indirectly through roles.

5. Is the realm authorization for the database account conditionally based on a rule set?

   If yes, then go to Step 6. If no, then go to Step 7.

6. Does the rule set evaluate to TRUE?

   If yes, then go to Step 7. If no, then there is a realm violation, so the SQL statement is not allowed to succeed.

7. 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, then there is no realm or command rule violation, so the command succeeds.

   For example, the 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 object privileges and are evaluated after the realm checks.

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 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.

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.

• Be aware that realm protection does not protect a table if access to the table has been granted to PUBLIC. For example, if SELECT ON table_name is granted to PUBLIC, then every user has access to table_name (unless the table is protected by a mandatory realm), even if this table is protected by a realm. As a best practice, revoke unnecessary privileges from PUBLIC.

Realm authorizations prevent users from performing activities if the users do not have the correct privileges.

• About Authorizations in a Realm
  Realms protect data from access through system privileges.
• Examples of Realm Authorizations
  You can create realms that protect objects from users who have system privileges and other powerful privileges, for example.

You can 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 CREATE INDEX ON table privilege to the user who must create the index.

• 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 CREATE ANY INDEX privilege alone is not sufficient for a non-realm participant to create an index in a realm-protected table.)

• 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.

Realms can provide protection in which two users who each have the same privileges must have separate access levels for an object.

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, OE_ADMIN and HR_ADMIN, can be protected by a realm as a secured object and be configured as the owner of a realm.

Further, only a realm owner, such as 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 System Privilege and Role Management 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.

Figure 4-1 How Authorizations Work for Realms and Realm Owners

Description of "Figure 4-1 How Authorizations Work for Realms and Realm Owners"

Realms have no effect on factors, identities, or rule sets, but they do affect command rules.

With command rules, 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.

Oracle provides a set of guidelines for 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 ANY-style system privileges are already in use. A model using the principle of least privilege is ideal for any database application.

• 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 EMPLOYEES table in the HR schema), or roles protected by a realm, create a new realm with just the minimum required objects and authorizations.

• 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 GRANT ANY ROLE system privilege, such as the SYSTEM user account, from granting the role to themselves.

• If you want to add the SYS user account to a realm authorization, you must add user SYS explicitly and not through a role (such as the DBA role).

• 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 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.

• Sometimes you must temporarily relax realm protections for an administrative task. Rather than disabling the realm, have the Security Manager (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.

• If you want to grant ANY privileges to new users, Oracle recommends that you add a database administrative user to the Oracle System Privilege and Role Management 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.

• If you drop a table, index, or role that has been protected by a realm and then recreate it using the same name, the realm protection is not restored. You must re-create the realm protection for the new table, index, or role. However, you can automatically enforce protection for all future tables, indexes, and roles within a specified schema. For example, to enforce protection for all future tables:

  BEGIN
   DBMS_MACADM.ADD_OBJECT_TO_REALM('realm_name', 'schema_name', '%', 'TABLE');
  END;
  /

• You can test the development phase of a realm by using simulation mode, which enables the realm but writes detailed information about violations to a log file.

Realms can affect database performance in a variety situations, such as with DDL and DML operations.

• 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.

• Periodically check the system performance. You can do so by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Cloud Control, which is installed by default with Oracle Database), Automatic Workload Repository (AWR), and TKPROF.

Oracle Database Vault provides reports and data dictionary views that are useful for analyzing realms.