5 Configuring Realms

What Are Realms?

Realms enable to protect database objects. A mandatory realm restricts user access to objects within a realm. Realm can protect specific object types.

Topics:

• About Realms

• Using Mandatory Realms to Restrict User Access to Objects within a Realm

• Object Types That Realms Can Protect

Default Realms

Oracle Database Vault provides a set of default realms. These realms are regular realms, not mandatory realms.

Topics:

• Oracle Database Vault Realm

• Database Vault Account Management Realm

• Oracle Enterprise Manager Realm

• Oracle Default Schema Protection Realm

• Oracle System Privilege and Role Management Realm

• Oracle Default Component Protection Realm

Creating a Realm

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

"Guidelines for Designing Realms" provides advice on creating realms.

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

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

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 "Using Mandatory Realms to Restrict User Access to Objects within a Realm" for more information about mandatory realms.

   • Status: Select either Enabled or Disabled to enable or disable the realm. 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 Appendix A, "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.

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

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 attribute is mandatory.

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

11. Click Finish to complete the realm creation.

About Realm-Secured Objects

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

  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.

About Realm Authorization

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. To track configuration information for the authorization of a realm, see "Realm Authorization Configuration Issues Report".

Disabling and Enabling a Realm

You can disable or enable a realm 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 or Enabled.

4. Click Done, and then click Finished.

Deleting a Realm

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.

   See Chapter 22 for more information about these views.

2. In the Oracle Database Vault Administration page, select Realms.

3. In the Realms page, select the realm you want to delete, and then select Remove.

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

How Realms Work

When a database account that has the appropriate privileges issues a SQL statement (that is, DDL, DML, EXECUTE, GRANT, REVOKE, or SELECT) that affects an object within a realm, a special set of activities occur.

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.

   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.

How Authorizations Work in a Realm

Realms authorizations work by checking if users have the privileges that they need to perform a specific task. If the user does not have the correct privileges, then the user cannot access the data.

Topics:

• About Authorizations in a Realm

• Example: Unauthorized User Trying to Create a Table

• Example: Unauthorized User Trying to Use the DELETE ANY TABLE Privilege

• Example: Authorized User Performing DELETE Operation

CREATE TABLE HR.demo2 (col1 NUMBER(1));

ORA-47401: Realm violation for CREATE TABLE on HR.DEMO2

DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002;

ERROR at line 1:
ORA-01031: insufficient privileges

DELETE FROM HR.EMPLOYEES WHERE EMPNO = 8002;

1 row deleted.

Access to Objects That Are Protected by a 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 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.

Example of How Realms Work

Figure 5-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 5-1 How Authorizations Work for Realms and Realm Owners

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

How Realms Affect Other Oracle Database Vault Components

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.

Guidelines for Designing Realms

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;
  /
  

How Realms Affect Performance

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. For more information about Oracle Enterprise Manager, see the Oracle Enterprise Manager documentation set. For information about Cloud Control, refer to its online Help. See Oracle Database Performance Tuning Guide to learn how to monitor database performance, and Oracle Database SQL Tuning Guide to monitor the performance of individual SQL and PL/SQL statements.

Related Reports and Data Dictionary Views

Table 5-1 lists Oracle Database Vault reports that are useful for analyzing realms. See Chapter 24, "Oracle Database Vault Reports," for information about how to run these reports.

Table 5-2 lists data dictionary views that provide information about existing realms.