104 Part II: Oracle Database Vault against unauthorized grant (or revoke) operations on the roles. This is where you can see DBV protecting the security infrastructure—that is, securing the components that enforce the security for the database and data itself. In practice, realms are flexible and transparent. The applications know nothing of the realms. When implemented correctly, the standard security and application capabilities remain functioning. This transparency is essential to an effective implementation so that well-behaved applications won’t be negatively affected once the security capabilities are enabled. Command Rules Earlier in the chapter, we discussed the idea of applying conditional security to commands to create some context-based or rules-based mechanism for database commands. The commands can be used for objects on which the user has direct object privileges or for system commands, such as CREATE USER, that do not apply to a specific object or schema. The notion is similar to the conditional security checks that you would perform for SARs, but this time it’s applied to basic commands. DBV’s command rules offer another new security layer that allows the authorization of a database command—such as SELECT or CREATE USER—for custom-defined rules. The rules may, and often do, use rules and factors. The result is that you derive the same conditional security capabilities that you might otherwise get from enabling a role with SARs. The decision to allow a command to execute is based on an existing privilege and a rule that must be passed. An important differentiation exists between SARs and command rules. With SARs, the user does not have the privileges to perform the action. The privileges are granted to the role, and when the role is enabled, the user can perform the action. Conditional security was performed to enable the role, thus giving the user privileges. With command rules, and for DBV in general, the user must already have the base database privileges. DBV acts as an additional security monitor after the basic database privileges have been verified. These privileges can be obtained in one of three ways: They may be logged into the schema that owns the objects. We call this the object owner model. They may have direct object grants to the object. For example, for a user logged into the SR_ADMIN schema, an appropriate grant can be made to allow the user to access the PRODUCTS table in the SH schema by having the user SH issue a GRANT SELECT ON PRODUCTS to SR_ADMIN, which is a specific object-level privilege. They may be able to perform an action based on a system or system ANY privileges. With command rules, the user must already have the privilege. Command rules pertain to commands that do not need to have relevance to any DBV realms and as such can overrule a command that is allowed by a realm’s policy. This makes sense when you consider the many system commands that are irrelevant to any data object (such as CREATE USER). This makes DBV transparent and allows it to work for existing applications. If the existing application security model prevented a user from performing an action, DBV does not and cannot undo the existing security. NOTE DBV adds a layer of security that is called at runtime to mediate actions and access. Access = DB privilege + DBV rule. ■ ■ ■ Chapter 4: Database Vault Introduction 105 Installing Oracle Database Vault Now that you understand the problems DBV addresses, what it consists of and why, it’s time to get started using DBV. This section reviews the DBV installation. We describe and highlight important aspects of the installation process and resulting configuration. DBV is installed using the Oracle Database Configuration Assistant (DBCA) that comes with Oracle Database Enterprise Edition. During the installation, you will be prompted to create up to two additional end user administration accounts in the database. These accounts will be used to manage DBV policies. Here is important point number one: The DBV accounts are separate from the traditional Oracle accounts (such as the user SYSTEM) that have similar function. Why? Because traditional accounts use roles and system privileges that will henceforth be constrained, thereby rendering the accounts incapable of managing the policies. The separation of the new DBV accounts also facilitates a separation of duty capability in that you will be able to separate the ability to issue system commands. Installed DBV Administration Roles The core administration roles provided with DBV are categorized as follows: Security Policy Administration and Reporting The DBV install creates three new roles related to DBV policy reporting and administration: o DV_SECANALYST This role can read (SELECT) from DBV configuration and audit information. It must use the Database Vault Administrator (DVA) web application in a read-only mode. o DV_ADMIN This role can execute the DVA package, DVSYS.DBMS_MACADM. It also can use the DVA web application to manage DBV security configuration. The DV_ADMIN role is granted the DV_SECANALYST role, so it inherits all of the read privileges from this role. o DV_OWNER The initial account that is granted to this role at install time can grant the DV_SECANALYST, DV_ADMIN, and DV_OWNER roles to other accounts. This role is granted the DV_ADMIN role, so it inherits the ability to manage security configuration. It also can read the DBV configuration through the privileges obtained via the DV_SECANALYST role, which is granted to the DV_ADMIN role. Account Administration A single database account administration role, DV_ACCTMGR, is created in DBV. After DBV installation, this role has the system privileges and exclusive ability to create, alter, and drop database accounts (Oracle USER object types) as well as database profiles (Oracle PROFILE object types). Note that any account can still change its own password, but the new DV_ACCTMGR role is responsible for password reset responsibilities. DBV also installs two template roles used for realm administration and realm-based object owning accounts: DV_REALM_OWNER and DV_REALM_RESOURCE. These roles are covered in detail in Chapter 6. The DBCA prompts you for up to two additional end user administration accounts in the database. The first account name is used to define the initial DBV “owner” who will be granted the DV_OWNER role at the end of the installation. The second account name is optional and is ■ ■ ■ ■ ■ 106 Part II: Oracle Database Vault used to define the “account administrator” who will be granted the DV_ACCTMGR role at the end of the installation. If no account administrator account is specified at install time, the owner account specified will be granted both the DV_OWNER and DV_ACCTMGR roles. NOTE For the examples used in this book, the DV_OWNER role was granted to an account named DBVOWNER that was created at install time, so you will see the use of this account for many of the DBV policy configuration examples. The account DBVACCTMGR was created at install time for the account administrator, so this account was granted the DV_ACCTMGR role and will be used for many of the database account management examples in this book. Managing Oracle DBV Configuration Configuring DBV policy can be accomplished either by using PL/SQL scripts that leverage the DVSYS.DBMS_MACADM PL/SQL package or by using the DVA web application. The DVSYS. DBMS_MACADM PL/SQL package can be used by any database account that is granted the DV_ADMIN or DV_OWNER role. Most of the DBV policy configuration examples used in this book use the DVSYS.DBMS_MACADM PL/SQL package and the DBVOWNER account that was created during installation. DVA Web Application The DVA web application is deployed into an existing Oracle Enterprise Manager Database Console (OEM dbconsole) Oracle Containers for J2EE (OC4J) installation for each database into which the DBV option is installed. You must start the OEM dbconsole software to access the DVA. Before starting the OEM dbconsole, make sure you have set the appropriate environment variables for the installation—for example PATH, LD_LIBRARY_PATH, ORACLE_HOME, and ORACLE_SID on UNIX systems—and type the following command: [oracle@node1 ~]$ emctl status dbconsole Oracle Enterprise Manager 11g Database Control Release 11.1.0.6.0 Copyright (c) 1996, 2007 Oracle Corporation. All rights reserved. https://node1.us.oracle.com:1158/em/console/aboutApplication Oracle Enterprise Manager 11g is not running. Logs are generated in directory /opt/oracle/db11/node1_aosdb/sysman/log Once the OEM dbconsole is started, you can access the DVA at https://host:port/dva The host and port are output from the command emctl status dbconsole. As you can see in Figure 4-1, you can log into the DVA with the credentials of the DV_OWNER account—for example, DBVOWNER—and the database connection parameters specific to the environment. The database connection parameters can typically be found in the file $ORACLE_HOME/network/ admin/tnsnames.ora for the database being used. Chapter 4: Database Vault Introduction 107 Once the login process is complete, the main menu page for the DVA is displayed. The Administration tab (Figure 4-2) provides navigation links to the pages that allow for the configuration of the core DBV components. FIGURE 4-1 DBV administrator login page FIGURE 4-2 DBV Administrator tab 108 Part II: Oracle Database Vault Accounts that have been granted the DV_OWNER or DV_ADMIN role can make configuration modifications using these navigation links. The DVA uses the DBMS_MACADM PL/SQL package, under the covers, to change the configuration. The Administration tab allows the accounts with the DV_OWNER or DV_ADMIN role to change the configuration for the following DBV components: Realms Command rules Rule sets Factors Secure application roles Oracle Label Security (OLS) integration Accounts that have been granted the DV_SECANALSYT role can view the DBV configuration of these components but cannot modify the configuration. The three remaining tabs provide navigation links to the reporting and monitoring features provided by the DVA: Database Vault Reports These reports can be used to validate the DBV configuration and view the DBV audit trail for each of the core DBV components. The reports are intended to be used to verify the configuration of a DBV-enabled database and to provide a quick mechanism to display recent DBV policy violations. General Security Reports These reports describe core Oracle database security configurations—for example, in the area of privilege management. These reports are intended for use in compliance reporting and/or reporting against industry standard database hardening profiles. Monitor This allows the security administrator to monitor for security policy changes, security violations, and database structural changes that have occurred in a recent time frame. The monitor displays recent changes in DBV configuration, OLS configuration, database audit policy, database privilege management, database role management, and database account management with visual charts. You would expect no activity in these areas for a production system. If a change in any one of these configuration areas were to occur, the monitor provides a visual alert to this fact so that the change can be investigated in more detail with the other reports provided by DBV. This feature queries the Oracle RDBMS audit trail for many of the statistics presented and requires the database initialization parameter AUDIT_TRAIL to be set to ‘DB’ or ‘DB, EXTENDED’. DBV Administrator PL/SQL Package and Configuration Views The DVSYS.DBMS_MACADM PL/SQL package allows you to script the DBV configuration for deployment in an automated way and to make changes in an ad hoc manner using a database client tool such SQL*Plus. DBV also includes a number of database views that are owned by the DVSYS account and can be used to query this configuration. Table 4-1 depicts the configuration procedures in the DBMS_MACADM package and associated configuration views organized by their intended configuration usage. ■ ■ ■ ■ ■ ■ ■ ■ ■ Chapter 4: Database Vault Introduction 109 Configuration Usage DBMS_MACADM Procedure(s) DVSYS View(s) Configuring DBV realm name, description, enabled status, and default auditing options CREATE_REALM RENAME_REALM UPDATE_REALM UPDATE_REALM_AUTH DELETE_REALM DELETE_REALM_CASCADE DBA_DV_REALM Configuring DBV realm secured objects and roles ADD_OBJECT_TO_REALM DELETE_OBJECT_FROM_REALM DBA_DV_REALM_OBJECT Configuring DBV realm authorization grantee and authorization rule set ADD_AUTH_TO_REALM DELETE_AUTH_FROM_REALM DBA_DV_REALM_AUTH Configuring DBV command rule command, object owner, object name, rule set, and enabled status CREATE_COMMAND_RULE UPDATE_COMMAND_RULE DELETE_COMMAND_RULE DBA_DV_COMMAND_RULE Configuring DBV rule names and logical expressions CREATE_RULE RENAME_RULE UPDATE_RULE DELETE_RULE DBA_DV_RULE Configuring DBV rule set name, description, enabled status, evaluation option, audit options, failure processing options, and custom handler CREATE_RULE_SET DELETE_RULE_SET RENAME_RULE_SET UPDATE_RULE_SET DBA_DV_RULE_SET Configuring the association of DBV rules to DBV rule sets ADD_RULE_TO_RULE_SET DELETE_RULE_FROM_RULE_SET DBA_DV_RULE_SET_RULE Validating the logical expressions for DBV rules SYNC_RULES N/A Configuring DBV factor types CREATE_FACTOR_TYPE RENAME_FACTOR_TYPE UPDATE_FACTOR_TYPE DELETE_FACTOR_TYPE DBA_DV_FACTOR_TYPE TABLE 4-1 Configuration Procedures in the DBMS_MACADM Package and Associated Configuration Views 110 Part II: Oracle Database Vault Configuration Usage DBMS_MACADM Procedure(s) DVSYS View(s) Configuring DBV factor name, description, factor type, identification options, retrieval method, audit options, validation expression, assignment of DBV rule set, and failure options CREATE_FACTOR RENAME_FACTOR UPDATE_FACTOR DELETE_FACTOR DBA_DV_FACTOR Configuring DBV identity value and trust level CREATE_IDENTITY UPDATE_IDENTITY DELETE_IDENTITY CHANGE_IDENTITY_FACTOR CHANGE_IDENTITY_VALUE DBA_DV_IDENTITY Configuring DBV identity maps CREATE_IDENTITY_MAP DELETE_IDENTITY_MAP ADD_FACTOR_LINK DELETE_FACTOR_LINK DBA_DV_IDENTITY_MAP DBA_DV_FACTOR_LINK Configuring DBV Secure Application Role name, enabling DBV Rule Set and enabled status CREATE_ROLE RENAME_ROLE UPDATE_ROLE DELETE_ROLE DBA_DV_ROLE Configuring an OLS policy as integrated with DBV factors CREATE_MAC_POLICY UPDATE_MAC_POLICY DELETE_MAC_POLICY_CASCADE DBA_DV_MAC_POLICY Configuring a DBV factor as linked to an OLS policy ADD_POLICY_FACTOR DELETE_POLICY_FACTOR DBA_DV_MAC_POLICY_FACTOR Configuring the OLS label for a DBV identity CREATE_POLICY_LABEL DELETE_POLICY_LABEL DBA_DV_POLICY_LABEL TABLE 4-1 Configuration Procedures in the DBMS_MACADM Package and Associated Configuration Views (continued) Default Separation of Duty Once DBV is installed, a number of differences in security policy exist between the database and a standard Oracle database. In the preceding section, we described the new roles that are created for managing the DBV configuration (DV_OWNER and, DV_ADMIN) and for managing database accounts (DV_ACCTMGR). The DBV installation creates a default security configuration for realms and command rules that is also based on separation of duty principles to provide the following responsibilities: Chapter 4: Database Vault Introduction 111 Security administrator Database account administrator Operational database administrator Security Administrator DBV stores most configuration data for realms, command rules, rule sets, and factors in tables owned by an object owner account named DVSYS. Direct DML (INSERT, UPDATE, and DELETE) against these configuration tables can be done only by the DVSYS account or definer’s rights PL/SQL code owned by the DVSYS account. The DVSYS.DBMS_MACADM package is the only means of updating these tables—even the DVA web application uses this package. The ability to execute this package is granted to the DV_ADMIN role (and indirectly to DV_OWNER role) so that when DBV is installed, the account granted the DV_OWNER role is your security administrator. The DBV installation creates a DBV realm called Database Vault (how thoughtful) to enforce the concept of a security administrator responsibility. This realm protects the following database objects: Objects owned by the DVSYS object owner account Includes the DBV configuration tables and the DBV audit trail, DVSYS.AUDIT_TRAIL$. Objects owned by the DVF object owner account DVF is an additional object owning account that stores DBV factor PL/SQL functions. Objects owned by the LBACSYS object owner account LBACSYS contains the OLS option’s configuration tables and PL/SQL code. The Oracle VPD administration package (DBMS_RLS) DBV roles DV_SECANALYST, DV_ADMIN, DV_OWNER, and DV_PUBLIC DV_ PUBLIC is granted privileges to execute utility packages that a database session may use to get DBV factor values or to set a DBV secure application role. The OLS administration role LBAC_DBA The RDBMS audit trail table SYSTEM.AUD$ As you can see, security-relevant configuration data for statement-level security (SLS) functionality, such as DBV, and row-level security (RLS) functionality, such as VPD and OLS, are protected by the installed realm. This realm not only protects the DBV audit trail, but it also protects the core RDBMS audit trail. The realm is “owned” by the DV_OWNER role, and only accounts with this role can manage the granting of the roles protected by this realm. This realm offers a secure mechanism to provide and delegate the security administrator responsibilities to other accounts. The installed DBV policy also includes a command rule for both the GRANT and REVOKE commands on the DBMS_RLS (VPD) administration package that limits these commands to accounts that have been granted the DV_OWNER role. The Database Vault realm and the two DBV command rules enforce the Security administrator concept as the one responsible the security-relevant configuration data and managing the provisioning of additional security administrators. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 112 Part II: Oracle Database Vault Database Account Administrator The DBV installation creates a Database Vault Account Management realm to help enforce the concept of a database account administrator responsibility. This realm protects the DV_ACCTMGR role. This role is also the “owner” of the realm so that accounts with the DV_ACCTMGR role can also manage the delegation of this responsibility to other accounts. The account granted the DV_ACCTMGR role during the DBV installation is therefore the default database account administrator. The installed DBV policy includes a collection of command rules that restrict commands related to database account management and enforces the concept of a database account administrator. DBV command rules restrict the following commands to accounts that have been granted the DV_ACCTMGR role: CREATE USER ALTER USER DROP USER CREATE PROFILE ALTER PROFILE DROP PROFILE The Database Vault Account Management realm and the six DBV command rules enforce the database account administrator concept as the one responsible for managing not only the initial provisioning of named user accounts to a database but also the locking and unlocking of object- owner accounts and shared accounts, as defined in Chapter 1. The DBV command rules for PROFILE database objects establish this role as the steward for all password policies for the database accounts they manage. Operational Database Administrator The database account administrator can perform the initial provisioning (establish or create) a database account, but the operational database administrator is responsible for granting the account the necessary system privileges such as CREATE SESSION, CREATE TABLE, CREATE PROCEDURE, or system ANY privileges, such as CREATE ANY TABLE or SELECT ANY TABLE, for the type of account being created. (See Chapter 1.) Control over the granting of these system privileges depends on the default Oracle Data Dictionary realm that is created during DBV installation. The “owner” of this realm is the only one allowed to grant these types system privileges. After DBV installation, the SYS account is the only owner of this realm. The database account administrator should create a named user account and the security administrator should modify the DBV realm authorizations to make this named user account the owner of the Oracle Data Dictionary realm to create named accounts for each responsibility. We will present a working example of this type of setup in Chapter 6. The security design concept with this management ■ ■ ■ ■ ■ ■ Chapter 4: Database Vault Introduction 113 aspect of system privileges is that one user can create accounts while another user is responsible for granting privileges to execute any commands not automatically available to the Oracle PUBLIC role. The Oracle Data Dictionary realm protects several standard Oracle database roles, such as DBA and RESOURCE, so this realm owner is responsible for the provisioning and management of these roles as well. Several Oracle database system privileges are affected, including the following: BECOME USER CREATE ANY JOB CREATE EXTERNAL JOB DEQUEUE ANY QUEUE ENQUEUE ANY QUEUE EXECUTE ANY CLASS EXECUTE ANY PROGRAM MANAGE ANY QUEUE MANAGE SCHEDULER SELECT ANY TRANSACTION PL/SQL execute privileges on the Log Miner packages and the UTL_FILE package also operate in a manner that could reduce the assurances offered by this separation of duty model. These system and execution privileges for these packages are revoked from the standard roles such as DBA, IMP_FULL_ DATABASE, EXECUTE_CATALOG_ROLE, and SCHEDULER_ADMIN by the DBV installation. If your application requires privileges to create jobs, for example, a more secure design approach would grant the limited privilege CREATE JOB (versus CREATE ANY JOB) to each object owner account that has to create jobs. Operational DBAs should collaborate with application developers to avoid the use of these privileges whenever possible. The operational DBA is not entirely focused on privilege management, however. The realm also protects the standard Enterprise Edition object owner accounts such as SYS, MDSYS (Spatial), CTXSYS (Text), and many more. The operational DBA is responsible for maintaining the objects and data in these accounts for such procedures as application deployment, patching, and upgrades. The design concept for the operational DBA extends into such areas as storage management (such as tablespaces) and backup/recovery management (such as archive log maintenance). DBV installs a command rule for the ALTER SYSTEM command that prevents an operational DBA from modifying security sensitive database initialization parameters, such as disabling the auditing of commands ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ . PATH, LD_LIBRARY_PATH, ORACLE_ HOME, and ORACLE_ SID on UNIX systems and type the following command: [oracle@ node1 ~]$ emctl status dbconsole Oracle Enterprise Manager 11g Database Control Release. command rule command, object owner, object name, rule set, and enabled status CREATE_COMMAND_RULE UPDATE_COMMAND_RULE DELETE_COMMAND_RULE DBA_DV_COMMAND_RULE Configuring DBV rule names and. the Oracle PUBLIC role. The Oracle Data Dictionary realm protects several standard Oracle database roles, such as DBA and RESOURCE, so this realm owner is responsible for the provisioning and