Applied Oracle Security: Developing Secure Database and Middleware Environments- P14 doc

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 Oracl

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.

■

■

■

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

■

■

■

■

■

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

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

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

■

■

■

■

■

■

■

■

■

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

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

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:

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

■

■

■

■

■

■

■

■

■

■

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

■

■

■

■

■

■

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

■

■

■

■

■

■

■

■

■

■