Introduction.

Introduction

Oracle Database 10g: Implementing Database Vault 1 - 2
Objectives After completing this lesson, you should be able to do the following: Identify the features and benefits of Oracle Database Vault List the components of Database Vault and their relationship to one another Explain the purpose of Database Vault Administrator (DVA) Describe the types of scenarios where Database Vault helps with compliance Describe how to display the reporting and monitoring pages of DVA List the tasks that can be performed by using the Database Vault API Oracle Database 10g: Implementing Database Vault

Suggested Schedule 1: Introduction 2: Installing Database Vault 3: Configuring Realms 4: Defining Factors 5: Defining Identities 6: Defining Rule Sets 7: Configuring Command Rules 8: Configuring Secure Application Roles 9: Viewing Reports 10: Implementing Best Practices Oracle Database 10g: Implementing Database Vault

What Is Database Vault? What Is Database Vault? Database Vault is a database security option that you use to protect application data from access by a database administrator (DBA) and any other privileged user, to enforce protection of database structures from unauthorized change, and to set a variety of access controls to implement dynamic and flexible security requirements. These features help you to adhere to standards for separation of duties, regulatory compliance, and internal control. Typical applications of Database Vault are for protecting application data from being viewed by a DBA or for defining specific conditions as to when and how certain data can be accessed. Because Database Vault provides flexible rules for modifying and enhancing data access conditions, you can configure it to meet the specific needs of your environment, personnel, business practices, and compliance. You configure Database Vault to manage the security for an individual Oracle database instance. You can use Database Vault on stand-alone Oracle database installations, in multiple Oracle homes, and in Oracle Real Application Clusters (RAC) environments. Database Vault is part of the database kernel, and thus is a more secure implementation than the one implemented in PL/SQL on top of the database. Oracle Database 10g: Implementing Database Vault

Database Vault Option $ sqlplus hr/hr SQL*Plus: Release Production on Mon May 1 14:36: Copyright (c) 1982, 2005, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Database Vault options Database Vault Option Database Vault is installed as an option in an existing Oracle database, in an existing Oracle home. Installation entails relinking the core files that run the instance and updating the files associated with the database. After the option is installed, the SQL*Plus banner displays the Database Vault option string, as shown in the slide. This option must be installed in an Oracle database version or later. Database Vault requires Oracle Label Security (OLS), even if labels are not used in your database. It is purely a technical requirement, not a license one. So having OLS installed and configured for the sole purpose of supporting Database Vault does not require that OLS be licensed, unless you are actually implementing secure labels. Oracle Database 10g: Implementing Database Vault

Benefits of Database Vault
Protection from insider threat Compliant separation of duties Benefits of Database Vault Database Vault provides the following benefits: Compliant separation of duties: A security compliance issue is to have separation of duties. This means that for certain sets of transactions, a given user is not able to perform all of the steps in the set. The steps are shared among more than one user to provide accountability. In a database, DBAs are typically given system privileges that allow them to break that rule, by the very fact that they can view and modify any table in the database. Database Vault provides compliance in this area by allowing you to give DBAs the privileges required for them to do their job, but not privileges needed to view or modify data. For example, they can alter a tablespace, but cannot select data from the tables in that tablespace. Protection from insider threat: When users can see application data that they should not be able to, there is the potential for unauthorized modification or sharing of that data. Database Vault enables you to be very specific in your definition of the conditions under which a given user can view or modify data, and also provides an audit trail of access to that data. Customized control of data access conditions Consolidation of applications Oracle Database 10g: Implementing Database Vault

Benefits of Database Vault (continued) Customized control of data access conditions: Rules defining who can access what data can also be further modified to specify conditions such as time, machine, and network path. This enables you to deny access to data when the database is being accessed during insecure or unorthodox conditions, such as performing an export while logging in from home or reading a table after normal work hours. Consolidation of applications: In systems where there are multiple DBAs (one for each application), the simplest way to protect each application area from each of the other DBAs is to separate the applications into different databases. Because Database Vault enables you to protect each of the application areas from the other DBAs, that is no longer necessary. Each DBA can be restricted to the application for which he or she is responsible. This can prove to simplify management of databases and resources, and can also reduce your investment in hardware and other supporting infrastructure. Oracle Database 10g: Implementing Database Vault

Database Vault: Effects
The installation of the Database Vault option: Is transparent to applications Does not affect access paths for queries May affect what data is accessible for a given session under certain circumstances May or may not affect performance of queries, depending on the configuration of Database Vault components May require more personnel to take full and proper advantage of the features Database Vault: Effects Just having the Database Vault option installed does not affect the functionality of the database in any way. Applications do not have to be changed, and all queries work in the same way they as before the installation. Even when Database Vault components are configured, there is no need to modify applications. The extra security is provided by Database Vault without changes to applications or how SQL is submitted to the database. Of course, if those new security configurations are there to prevent access to data by an application, that application will be affected accordingly. Also, if more complex security configurations are created, it is possible that performance will be affected. This is addressed in greater detail in the lesson titled “Implementing Best Practices.” Because separation of duties requires involvement of more people to execute some tasks, the Database Vault option may require more personnel in an organization to take full advantage of the security features. Oracle Database 10g: Implementing Database Vault

Database Vault Versus VPD and OLS
Virtual Private Database (VPD): Restricts access to certain rows for a user by modifying the WHERE clause Oracle Label Security (OLS): Mediates access to a given row, based on the label on the row and the security level of the user VPD and OLS restrict access at the row level, whereas Database Vault restricts access at the object and command levels. Database Vault Versus VPD and OLS VPD and OLS restrict which rows a given user can access. VPD generates additional conditions on the WHERE clause to implement this. This causes possibly fewer rows to be returned. OLS uses VPD to restrict row access on the basis of the security labels on the rows and the security level of the user making the request. Neither VPD nor OLS prohibits access to data at the object level or command level, which is what Database Vault does, regardless of what system privileges the user has. By putting entire schemas or objects into protective realms, you can prevent access to them entirely, except for specific users. Even if DBAs have the SELECT ANY TABLE system privilege, they cannot access objects that are protected from them. Additionally, Database Vault prohibits certain commands from being executed on specific objects, unless a set of conditions exists. Database Vault also makes it impossible for users to grant themselves any privilege that they want, including SYSDBA. With VPD and OLS, if privileged users grant themselves EXEMPT ACCESS POLICY, then they are exempt from any enforced policies, and can see all data. There is no way to prohibit SYS users, for example, from granting this to themselves or others. Oracle Database 10g: Implementing Database Vault

Access Control Components
Database Vault provides the following components for securing a database: Realms Factors Identities Rule sets Command rules Secure application roles Access Control Components The following components of Database Vault provide highly configurable access control: Realms: A boundary set up around a set of objects in a schema. Specific conditions must exist to gain access. Factors: Attributes of a user or the system at any given time. Factors contribute to the decision process of granting access, and combinations of several factors may be considered at once. This is multifactored authentication. Identities: Specific values that factors may take on. Of the possible set of values for a given factor, some or all may have been assigned a name, which is an identity. Rule sets: A collection of rules that are evaluated for purposes of granting access Command rules: A specification of specific conditions that must be in effect in order for a given command to be executed on a given object or set of objects. This provides very granular control over what can be done to certain objects, and by whom. Secure application roles: A role that can be activated by a session only under the condition of passing a rule set Oracle Database 10g: Implementing Database Vault

Realms: Introduction Realms: Contain protected objects Reference users who are allowed to access the objects Object privileges or Realm participation Realms: Introduction Realms contain objects, such as tables, roles, and packages. The realm may also have users or roles defined as participants. The realm protects those objects that it contains from users exercising system privileges such as SELECT ANY TABLE. So, any user privileged as such must be defined as a realm participant (or have a realm-participating role that has been granted to him or her) in order to access the protected objects. If a user or role already has direct object privileges granted to access the realm-protected objects, then the realm has no effect; those users and users with that role can access the objects in the same manner as before the realm existed. Realms are covered in detail in the lesson titled “Configuring Realms.” Oracle Database 10g: Implementing Database Vault

Factors: Introduction
A factor: Is an attribute of a database session Can have a value, which can be labeled as an identity Can easily be referenced in other Database Vault components to discern access Can be combined with other factors to provide for multifactored authentication + + Factors: Introduction A Database Vault factor is a building block for the configuration access control and overall database security. Each factor is named much like a variable in an algebraic equation. Each factor has a value assigned to it. This value is called an identity. Factors are combined in logical ways with other factors in rules and rule sets to provide the basis for access control policies. You implement multifactored authentication by combining factors together. It is the same concept used when a customer representative you call on the phone asks for your name, billing address, and the last four digits of your social security number. Those are three factors that contribute to the authentication process. Factors are covered in detail in the lesson titled “Defining Factors.” Oracle Database 10g: Implementing Database Vault

Identities: Introduction
An identity: Is a value Is associated to a factor Has a trust level Can have a label Can be resolved from other factors INTERNET identity INTRANET identity SECURE identity Identities: Introduction An identity is a value that is associated with a factor. The identity of a factor can vary according to the session, application, user, or even time of day. For example, when a user connects though a machine in the office, the DOMAIN factor identity is set to INTRANET with a TRUSTED trust level. When the same user connects from home, the DOMAIN factor identity is set to INTERNET with an UNTRUSTED trust level. In this example, the DOMAIN factor can be used to determine what data the user is allowed to access, and what commands the user is allowed to perform. A factor can have an identity assigned by a combination of multiple factors. The identity of these factors can in turn be resolved by other factors. Using factors to resolve an identity is called an identity mapping. Identities are covered in detail in the lesson titled “Defining Identities.” DOMAIN factor Oracle Database 10g: Implementing Database Vault

Rule Sets: Introduction
TRUE or FALSE AND/OR Rule 2 TRUE or FALSE AND/OR AND/OR Rule n TRUE or FALSE Rule Sets: Introduction A rule set is a collection of rules that are evaluated together to produce a result. Each rule is defined as a WHERE clause expression. The rule set specifies whether the results of the rules are to be ANDed or ORed together. After each rule is evaluated, those results are ANDed or ORed together, and the result is a single value of TRUE or FALSE. Database Vault provides a rule engine to process rule sets. You can use a rule set to provide dual key security, whereby another separate action must be taking place for the requested access to be granted. An example of this is to require a specific user to be logged in from a specific client machine in order for some other user to have access to certain data or packages. Rule sets are covered in detail in the lesson titled “Defining rule sets.” Rule set result TRUE or FALSE Oracle Database 10g: Implementing Database Vault

Command Rules: Introduction
Command type To perform this command Object On this object Owner Which is owned by this user Rule set This rule set must evaluate to TRUE. Command rule Command Rules: Introduction A command rule defines the rules that must be followed to perform a command on an object. These commands include most data definition language (DDL) commands, and also SELECT, UPDATE, and DELETE. You can implement a command rule to restrict specific commands to specific objects or groups of objects. The restriction is based on the evaluation of a rule set to TRUE. Command rules are covered in detail in the lesson titled “Configuring Command Rules.” Oracle Database 10g: Implementing Database Vault

Secure Application Roles: Introduction
Role not enabled Role enabled Secure Application Roles: Introduction Secure application roles are created to require specific conditions to be true before taking advantage of permissions or privileges that are granted to the role. The conditions are represented as a single rule set. So, a secure application role consists entirely of a secure application role name and an associated rule set. Permissions granted to that role can only be exercised if the rule set evaluates to TRUE. Secure application roles in Database Vault are different from those that are provided by the Oracle database. The secure application role is still enabled by a procedure in a secure package, but the package is provided by Database Vault. Instead of writing a procedure, the security administrator simply uses a rule set to determine whether an application role should be enabled. Secure application roles are covered in detail in the lesson titled “Configuring Secure Application Roles.” Oracle Database 10g: Implementing Database Vault

Component Relationships: Static
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Component Relationships: Static The relationship between Database Vault components is shown in the slide. On the basis of the direction of the arrow, you can say that a given component type uses another component type. So, realms, command rules, and secure application roles use rule sets to define their behavior. Factors use rule sets, rule sets can refer to factors in their definition, and factors use identities. Also, identities can refer to other factors. The three components at the top of the slide are the ones that actually cause security to be enforced. The bottom three support that enforcement. That is, you can create rule sets, factors, and identities, but until you create a realm, command rule, or secure application role that refers to them, nothing changes regarding data access in your database. Oracle Database 10g: Implementing Database Vault

Component Relationships: Dynamic
Secure application role Identity Realm Factor Command rule Rule set Component Relationships: Dynamic When a session accesses data in Database Vault, it may or may not have to pass through security checks involving Database Vault components. As shown in the slide, it may or may not require evaluation of any combination of realms or command rules. And if a realm is involved, there may or may not be a rule set defined, that further modifies the access requirements. Both secure application roles and command rules must have a rule set defined for them. And rule sets may or may not reference factors, which may or may not reference identities. This diagram illustrates the dynamic data access paths. Before a command is executed, any secure application role checks have already been done, along with the associated rule set, when the role is requested to be activated. Then, when the statement is submitted, all objects are checked to see whether they are in a realm. After that, command rules are checked to ensure that the particular command being issued is allowed. It is possible that at least one component of each type of component requires evaluation during the execution of a single statement. It is also possible that only a single realm or that a single command rule is evaluated. Any permutation of these is possible. Note: When reading this flow chart, consider that at the end of each branch, the flow returns to the main path to continue. The secure application role path goes to its end, and then flow returns to check realms, including its applicable flow path. Then the flow returns to check command rules, and so on. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Scenarios At 3:00 p.m. Monday CREATE USER … HR DBA
SELECT * FROM OE.CUSTOMERS HR DBA Scenarios In the slide three scenarios are shown where Database Vault would prohibit certain database actions and, thus, provide greater security policy compliance. In the first scenario, a user is attempting to create a user. But it is the afternoon of a workday, and it has been decided that no new users should be created during work hours. So, the CREATE USER command fails. The second scenario shows that the DBA in charge of the HR application data is attempting to read the data in the OE.CUSTOMERS table. Normally, because the DBA has the SELECT ANY TABLE privilege, the DBA would be able to do this. But because of the Database Vault protections defined, the DBA is unable to see the data outside of his application. The third scenario simply shows that Database Vault can additionally prevent connecting as SYSDBA. By default, Database Vault prohibits connecting as SYSDBA, although this can be changed using the orapwd utility. This is covered in detail in the lesson titled “Implementing Best Practices.” CONNECT AS SYSDBA SYS Oracle Database 10g: Implementing Database Vault

Database Vault Example: Separation of Duties
1 The DBA can view the ORDERS table data. SQL> SELECT order_total FROM oe.orders 2 WHERE customer_id = 101; ORDER_TOTAL 2 The security manager protects the OE.ORDERS table with a realm. 3 The DBA can no longer view the ORDERS table data. SQL> SELECT order_total FROM oe.orders 2 WHERE customer_id = 101; ERROR at line 1: ORA-01031: insufficient privileges Database Vault Example: Separation of Duties DBA users typically have the DBA role granted to them. This means that they have the SELECT ANY TABLE system privilege. In this example, a DBA is prevented from accessing a table, even though the DBA continues to retain the SELECT ANY TABLE privilege. The user with the DBA role is able to select data from the OE.ORDERS table. This could be a user who has been granted the DBA role to administer the HR schema, and not the OE schema. The security manager protects the OE.ORDERS table in a Database Vault realm. The DBA can no longer access the table. The specifics of how to set up a realm to provide this protection is covered in detail in the lesson titled “Configuring Realms.” Oracle Database 10g: Implementing Database Vault

Database Vault Administrator (DVA)
Database Vault Administrator (DVA) is a Web-based application that enables a security administrator to create, configure, and maintain Database Vault components, and also to monitor and report on any activity. The URL for accessing it is: name>:1158/dva Although this is the same port number as that which is used by Oracle Enterprise Manager, the applications are not related or connected in any way. DVA cannot be invoked or linked to from an Enterprise Manager browser session, nor vice versa. Oracle Database 10g: Implementing Database Vault

Database Vault Configuration Assistant (DVCA)
The Database Vault Configuration Assistant (DVCA) is run as part of the installation steps to: Create the Database Vault specific accounts Disable Database Vault security for installing other database options Enable Database Vault security after installing database options Database Vault Configuration Assistant (DVCA) DVCA is run for you during the installation process for the purpose of creating the Database Vault accounts. You can run it manually in either a command line or graphical mode, by running the dvca command at the operating system prompt. When you are installing database options such as Oracle Spatial or Java, you must run DVCA to disable the Database Vault security. After that, install the option. Then, you must run DVCA again to re-enable security. $ dvca Oracle Database 10g: Implementing Database Vault

Reporting Reporting You can generate 13 Database Vault reports and 40 general database security reports. Reporting is covered in more detail in the lesson titled “Viewing Reports.” Oracle Database 10g: Implementing Database Vault

Monitoring Monitoring Using the Monitoring page, you can monitor policy changes, security violation attempts, and database configuration and structural changes that are happening in your database. Monitoring is covered in more detail in the lesson titled “Viewing Reports.” Oracle Database 10g: Implementing Database Vault

Database Vault API The Database Vault application program interface (API) provides the following functionalities: Create, modify, and delete Database Vault components Allow a session to define its security environment Query the state and values of components Administer and configure systemwide Database Vault parameters Database Vault API Database Vault provides a collection of PL/SQL interfaces that enable security managers or application developers to configure the access control policy as required. The PL/SQL procedures and functions allow the general database account to operate within the boundaries of the access control policy in the context of a given database session. The provided packages are: DVF: Functions for returning information about factors DVSYS.DBMS_MACADM: Procedures for creating and managing Database Vault components DVSYS.DBMS_MACSEC: Procedures for activating secure application roles DVSYS.DBMS_MACUTL: Utility procedures for interrogating various security-related characteristics of the database environment Note: These APIs are covered where appropriate in this course. Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Identify the features and benefits of Database Vault List the components of Database Vault and their relationship to one another, both static and dynamic Explain the purpose of Database Vault Administrator (DVA) Describe the types of scenarios where Database Vault helps with compliance List the tasks that can be performed by using the Database Vault API Oracle Database 10g: Implementing Database Vault

Installing Database Vault

Objectives After completing this lesson, you should be able to do the following: Identify the different type of installations List the requirements for an Oracle Database Vault installation Explain the accounts and schemas that are created during installation Install Database Vault Oracle Database 10g: Implementing Database Vault

Installation Requirements
The additional hardware requirements for a Database Vault installation are: 270 MB of disk space for the Database Vault software 10 MB of additional disk space for database files Operating system and software requirements are identical to those for an Oracle Database installation, except that Oracle Label Security (OLS) must be installed. System Requirements The baseline requirements include, of course, those that are necessary for installing Oracle Database Additionally, for Database Vault, you need 270 MB of disk space to contain the Database Vault software and 10 MB of disk space for new database files. Oracle Database 10g: Implementing Database Vault

Installation Method Installation Method Database Vault may be installed in a single existing database instance or in a Real Application Clusters (RAC) environment. In this course, you work with a single instance. Oracle Database 10g: Implementing Database Vault

Performing a Clustered Installation
To install Database Vault in a RAC environment, perform the following steps: 1. Stop all RAC instances on all nodes. 2. Shut down all ASM instances on all nodes. 3. Stop all node applications on all nodes. 4. Choose the RAC option in the Installation Method window. 5. Set Database Vault instance parameters on each node. Performing a Clustered Installation Database Vault can be installed in a RAC environment by selecting the RAC option in the Installation Method window when running the installer. Before running the installer, however, you need to perform more steps, unlike when installing Database Vault in a stand-alone database. You must perform the following steps: 1. Stop all database instances on all nodes. An example is: $ORACLE_HOME/bin/srvctl stop database -d db_name \ -c "SYS/password AS SYSDBA" 2. Shut down all Automatic Storage Management (ASM) instances on all nodes. An example is: $ORACLE_HOME/bin/srvctl stop asm -n node \ 3. Stop all node applications. An example is: $ORACLE_HOME/bin/srvctl stop nodeapps -n node \ 4. Choose the RAC installation option when running the Database Vault installer. 5. Run the Database Vault Configuration Assistant (DVCA) to enable the enhanced security features of Database Vault. The command syntax for this is: dvca -action optionrac -oh oracle_home -jdbc_str \ jdbc_connection_string -sys_passwd sys_password \ [-logfile ./dvca.log] [-silent] [-nodecrypt] [-lockout] Oracle Database 10g: Implementing Database Vault

Performing a Clustered Installation (continued) where: action: The action to perform. optionrac performs the action of updating the instance parameters for the RAC instance and optionally disabling SYSDBA operating system access for the instance. oh: The Oracle home for the RAC instance jdbc_str: The Java Database Connectivity (JDBC) connection string used to connect to the database. For example: sys_password: The password for the SYS user logfile: Optionally, specify a log file name and location. You can enter an absolute path or a path that is relative to the location of the $ORACLE_HOME/bin directory. silent: Required if you are not running DVCA at the operating system prompt nodecrypt: Reads plaintext passwords as passed on the command line lockout: Used to disable SYSDBA operating system authentication Oracle Database 10g: Implementing Database Vault

Performing a Stand-Alone Installation
Stop all Oracle database processes: Shut down the database. Stop the listener. Stop the Oracle Enterprise Manager Database Control console. Stop the iSQL*Plus application server. Run the Database Vault installer software. Restart Oracle database processes: Start up the database. Start the listener. Start the Oracle Enterprise Manager Database Control console. Start the iSQL*Plus application server. Performing a Stand-Alone Installation To install Database Vault, you must perform the following steps: Shut down all database and listener processes, and the Database Control and iSQL*Plus applications. Run the Database Vault installer, and perform the installation steps. Database Vault has its own installer program, which is also called “runInstaller.” Start processes that are stopped in the previous steps. You can also perform a silent installation by preparing a response file. Refer to the help provided with the runInstaller program by entering: runInstaller -help Oracle Database 10g: Implementing Database Vault

Specifying Installation Details
During the process of installing Database Vault in an existing database, you must specify the following: The existing SYS password Destination path. This defaults to the Oracle home directory. User ID and password for the Database Vault Owner account User ID and password for the Database Vault Account Manager account. This is optional; you are not required to create this account. The implications surrounding the decision of whether or not to create a separate account manager user are covered later in this lesson. Oracle Database 10g: Implementing Database Vault

Installation Summary Installation Summary The installation summary shows you what is about to be installed and how much space it requires. The new installations are: Database Vault Database Vault J2EE Application Database Vault One-Off Patch Database Vault Scripts Oracle Database 10g: Implementing Database Vault

Configuration Assistants
The last step of the automated installation process is to run the configuration assistants. When the step is completed, the Details window displays a message such as this: The "/u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/configToolAllCommands" script contains all commands to be executed by the configuration assistants. This file may be used to run the configuration assistants outside of OUI. Note that you may have to update this script with passwords (if any) before executing the same. Make a note of the script file name, in case you need to rerun it at any time. Oracle Database 10g: Implementing Database Vault

Logging In to Database Vault Administrator (DVA)
After Database Vault is installed, you can configure it by using Database Vault Administrator (DVA). DVA has a browser-based interface, and is the means by which you administer Database Vault. Using it, you create, view, modify, and delete objects related to Database Vault. Log in using the Database Vault Owner account and password. In this course, the user is DVO. The URL is the same as that for Oracle Enterprise Manager Database Control, except that it ends with “dva” instead of “em.” An example of the URL for DVA is: Note: DVA is a separate application from Oracle Enterprise Manager. You cannot access one from another. They can coexist on the same machine and share the same port number. Oracle Database 10g: Implementing Database Vault

Database Vault Roles Grants DV_OWNER (e.g. the DVO user) DV_OWNER
PUBLIC Runs DVA to configure access control DV_ADMIN DV_PUBLIC Has EXECUTE on benign procedures DV_SECANALYST Views reports Creates and alters accounts Grants CONNECT, DV_ACCTMGR (e.g. the DVAM user) DV_ACCTMGR DV_REALM_RESOURCE DV_REALM_OWNER Database Vault Roles Database Vault creates seven new roles to support its functionality. To support public permissions, there is: DV_PUBLIC: The only permissions granted to this upon installation are several execute permissions on Database Vault procedures. These particular procedures are benign in that they do nothing to reconfigure the system without appropriate checks being done. Most of them are simple interrogation routines to retrieve information about components or the environment. For more information about the procedures this role is able to execute, refer to the Oracle Database Vault Administration Guide. Users with the following roles are able to perform various tasks in Database Vault Administrator: DV_SECANALYST: This role allows monitoring and running of reports in the DVA. It does not allow execution of any other tasks in DVA. DV_ADMIN: This role allows the running of all functionality in DVA, including monitoring and viewing of reports. It has the DV_SECANALYST role. DV_OWNER: This role represents a version of the DV_ADMIN role that is able to grant itself to others. It has the DV_ADMIN role. Has CREATE system privileges Has ANY system privileges Oracle Database 10g: Implementing Database Vault

Database Vault Roles (continued) For managing accounts, the following role is created: DV_ACCTMGR: This role is the only role that allows creation and altering of users and profiles. This role is granted to the user you specify as the Database Vault Account Manager during installation. That is optional. So, if you do not specify a user, then this role is granted to the Database Vault Owner user, effectively making that user the one that manages accounts. In addition to maintaining users and profiles, this role can grant CONNECT and itself (the DV_ACCTMGR role). In this course, the DVAM user has this role. For establishing users who manage realms, you can use the following roles: DV_REALM_OWNER: This role is used for managing database objects in multiple schemas that define an application or a realm. This role should be granted to the database account owner who would manage several schema database accounts within a realm and the roles associated with the realm. A user granted with this role can use powerful privileges such as CREATE ANY, ALTER ANY, and DROP ANY system privileges within the realm. The realm owner of the Oracle Data Dictionary realm, such as SYS, can grant this role to any given database account or role. Note that though this role has system privileges that the SYS user controls, it does not have the DV_OWNER or DV_ADMIN privileges, which means it cannot change the Database Vault configuration. DV_REALM_RESOURCE: This role provides system privileges similar to those that exist in the Oracle RESOURCE role (which allows users to create objects in their own schema). This role can be granted to a database account that will own database tables, objects, triggers, views, procedures, and so on that are used to support any database application. This is a role geared toward a schema type database account. As with the DV_REALM_OWNER role, this role does not have the DV_OWNER or DV_ADMIN privileges. The SYS user is the only one who can grant this role. Note: Scenarios describing how these two REALM roles are used are discussed in the lesson titled “Configuring Realms.” Oracle Database 10g: Implementing Database Vault

Database Vault Accounts
The following database accounts are set up in a Database Vault installation: Database Vault Owner account is: Any valid database account name Granted the DV_OWNER role Granted the DV_ACCTMGR role if there is no Database Vault Account Manager account created Required for Database Vault The Database Vault Account Manager account is: Granted the DV_ACCTMGR role Optional Database Vault Accounts You must create the Database Vault Owner account while installing Database Vault. You can name it as you choose, as long as you follow already established rules for naming database users. This account is granted the DV_OWNER role. This allows the Owner account to perform administration tasks to configure Database Vault components. This is the user that logs in to Database Vault Administrator, which is covered later in this lesson. The Database Vault Account Manager account is optional. It is granted the DV_ACCTMGR role, so it can be used to create and manage database accounts. The Database Vault Owner account is also granted the DV_ACCTMGR role if you choose not to establish a Database Vault Account Manager account. If you do define separate accounts for the Owner and the Administrator, you can provide a better separation of duties, where the person who is able to create and drop database accounts is not the same person who is able to define, enable, and disable Database Vault security features. Oracle Database 10g: Implementing Database Vault

DV_OWNER Versus DV_ACCTMGR
DV_OWNER can: Log in to Database Vault Administrator Modify Database Vault security configurations Disable security components and/or auditing DV_ACCTMGR can: Create new users Modify existing users' passwords Without separation of duties between these two roles, the DV_OWNER role could create new users temporarily and add them to database vault components to allow access temporarily, and then drop those users. DV_OWNER Versus DV_ACCTMGR These two roles are very different. The DV_OWNER role is able to change the Database Vault configuration, thus affecting what users can access what data. If there is a separate user who is the only one who is able to create new users, then that provides a separation of duties. In that case, the user who is granted the DV_OWNER role is not able to create new users that can be added to security configurations, used to perform some suspect task, and then dropped. To do that, there would have to be cooperation between two people, if there are separate users assigned to the DV_OWNER and DV_ACCTMGR roles. Note: Because of the delivered configuration of Database Vault, the SYS user can no longer create users. It can grant system privileges, and can only grant those roles that are listed in the Oracle Data Dictionary realm. Oracle Database 10g: Implementing Database Vault

Database Vault Schemas
The following database accounts are set up in a Database Vault installation: DVSYS: Owns: Database Vault Views Procedures making up the Database Vault API DVF: Owns: Factor definitions Database Vault Schemas Two other accounts are created in a Database Vault installation that are locked and not intended to be connected in a session. They are the holding schemas for Database Vault specific objects. The DVSYS schema contains all of the views that show information about all Database Vault objects. It also contains the packages that provide the Database Vault API functionality. The DVF schema contains all the Database Vault factors. Factors are covered in the lesson titled “Defining Factors.” Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Identify the different types of installations List the requirements for a Database Vault installation Explain the accounts and schemas that are created during installation Install Database Vault Invoke Database Vault Administrator (DVA) Oracle Database 10g: Implementing Database Vault

Practice 2 Overview: Installing Database Vault
This practice covers the following topics: Installing Database Vault Setting up database accounts for course practices Oracle Database 10g: Implementing Database Vault

Configuring Realms

Objectives After completing this lesson, you should be able to do the following: List the attributes of a realm Identify the uses of a realm List the ways in which realms provide separation of duties Create and update realms that protect database objects Create and update realms that prevent unauthorized granting of privileges List the steps in the algorithm for realm processing Match the columns of the realm views to the realm user interface elements Maintain realms by using the realm API Oracle Database 10g: Implementing Database Vault

Realms: Concepts Realms: Concepts A realm is a collection of roles and database objects that are, as a group, protected from access by users on the basis of a participant list. Even though certain users may have been granted the SELECT ANY TABLE system privilege, they have to be listed as realm participants in order to select data from a table that is protected by the realm. Oracle Database 10g: Implementing Database Vault

Realms: Static Component Context
Command rule Secure application role Uses Uses Uses Rule set Factor Identity Realms: Static Component Context The relationship between Oracle Database Vault components is shown in the slide. Realms use rule sets, and rule sets may help define the behavior of realms in certain configurations. Oracle Database 10g: Implementing Database Vault

Realms: Dynamic Component Relationships
Secure application role Identity Realm Factor Command rule Rule set Realms: Dynamic Component Relationships Realm access is evaluated when a SQL statement is requested to be executed. It may or may not involve a rule set evaluation. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Realms: Concepts R E A L M S Using system privileges SYS schema SYSTEM
HR data HR_DBA Realms: Concepts Users that commonly have powerful system privileges are those that serve as database administrators (DBAs) for at least part of the database in question. These users usually have the DBA role. Any database user with the DBA role can normally access objects in any schema at all. Realms provide protection for those objects, restricting access to only the users who are members of the realm that protects the object. This provides a database of databases, without sacrificing the privileges that users need when working with their own application data. This also creates separation of duties; different users have only the privileges that are necessary for them to do their job. SALES_DBA Sales data Oracle Database 10g: Implementing Database Vault

Effect of Realms on Nonmembers
Realms prevent access to database objects, except when object privileges have been granted to provide access, such as: SELECT ON HR.EMPLOYEES EXECUTE ON HR.GIVE_RAISE Therefore, system privileges such as these do not provide access to realm-secured objects: SELECT ANY TABLE EXECUTE ANY PROCEDURE CREATE TABLE Even nonmember schema owners cannot access their own objects unless they have been granted object privileges. Effect of Realms on Nonmembers If a user is not a member of a realm, then the only way for that user to access realm-secured objects is to have the relevant object privileges granted to the user. A user cannot rely on system privileges such as SELECT ANY TABLE to access objects, if those objects are secured in a realm. Also, users cannot rely on the fact that they own the schema being accessed. Schema owners cannot select from, alter, or create objects in their own schema if that schema is protected in a realm, and the schema owners are not members of that realm. There are two ways to provide this access. One, and the most common one, is to make the schema owner a member of the realm. Another is to grant object-level privileges on the schema’s objects to the schema owner. The grant would have to be done by a user who is already a member (specifically an owner) in the realm. Oracle Database 10g: Implementing Database Vault

Benefits of Using Realms
A realm provides protected areas of your database, besides already granted privileges. A realm: Defines what users or roles can exercise their system privileges against what objects Protects against the insider threat of the all-powerful DBA Limits which users can grant privileges on protected objects Benefits of Using Realms Use realms to protect a set of database objects or roles from otherwise sys-privileged users. For instance, DBAs have sweeping privileges such as SELECT ANY TABLE or DROP ANY TABLE. Those users can read or destroy data that they may not necessarily require access to. It would be better to limit access to that data to application users and application DBAs. A realm can be defined to enforce this. You define the realm, add the objects to it that are protected, and add the users who are allowed to access the objects that are under the realm. Realms can also limit the set of users who can grant privileges on the objects inside the realm. This would apply to, for example, granting EXECUTE on packages, SELECT on views, and GRANT on roles. Oracle Database 10g: Implementing Database Vault

Realm Attributes When creating a realm, you define: The realm name and description Its status: Enabled or Disabled Audit options A list of secured objects, qualified by the object: Owner Type, which can be a wildcard, meaning all types Name, which can be a pattern string A list of authorizations, including: Authorized user Authorization type indicating participant or owner Authorization rule set (optional) Realm Attributes The following are the attributes of a realm: Name: The name of the realm. This is used to refer to it later. It is case sensitive. Description: A description of the realm Status: Either Enabled or Disabled. If it is disabled, it has no effect. Audit Options: Audit options for a realm can be set to one of these values: Audit Disabled Audit on Failure Audit on Success or Failure Realm Secured Objects: The list of schema objects and roles that are protected by the schema Realm Authorizations: The list of authorized users or roles. This defines what users are able to access the objects that are secured by the realm. Oracle Database 10g: Implementing Database Vault

Creating Realms You have to create the realm before adding objects.
To manage realms by using Database Vault Administrator, click the Realms link on the Administration tabbed page. Click the Create button to create a new realm. The Create Realm page enables you to set only the name, description, status, and audit options for the realm. The secured objects and authorizations lists must be set by editing the realm definition, after it is first created. Oracle Database 10g: Implementing Database Vault

Editing Realms Add objects and authorizations to the realm.
On the Realms page, you can select one of the existing realms and click Edit to edit it. This allows you to change anything that is already defined for the realm. This is also the method for securing objects under the realm. In the Realm Secured Objects region, click Create to go to the page for adding secured objects. Also, in the Realm Authorizations region, you can add authorized users and roles to the realm by clicking Create. Oracle Database 10g: Implementing Database Vault

Adding Objects to Realms
Result after adding three objects: Adding Objects to Realms When you create a realm-secured object, you put the object under the protection of the realm. The parameters for defining the object or objects are: Object Owner: The owner of the object or objects to be added Object Type: The type of the object or objects to be added. Either it can be “%”, which means all types, or it can be a specific type, such as TABLE or CLUSTER. Object Name: The name of the object. This can be a literal name of one of the objects of the type specified above, or it can be a pattern string containing one or more occurrences of the “%” wildcard character. Objects belonging to different users, of different types, can all be under the same realm. Note: If you protect a table with a realm, any views that refer to that table are also protected. Oracle Database 10g: Implementing Database Vault

Adding Authorizations to Realms
Result after adding two authorizations: Adding Authorizations to Realms To add authorizations to a realm, specify the following: Grantee: The user or role name that is being authorized Authorization Type: Participant: The grantee is able to access the realm-secured objects. Owner: The grantee has all the access rights that a participant has, and can also grant privileges to others on any of the objects in the realm. This is comparable to the WITH ADMIN option of the GRANT statement. Oracle Database 10g: Implementing Database Vault

Realm Authorizations and Rule Sets
An authorization rule set requires the rule to be satisfied for access to the realm-protected objects. Realm Authorizations and Rule Sets When you add an authorization to a realm, you can also specify an authorization rule set. This rule set must be satisfied in order for access to the realm-protected objects to be allowed. In this example, the HR user is a participant in the realm, which means that the HR user can access the protected objects. But the addition of the rule set means that that rule set must resolve to a true condition for access to be granted. This particular rule, called “Weekday,” requires that the current day on the database server be a weekday. So, HR can access these objects only on weekdays. Authorization rule sets are covered in detail in the lesson titled “Defining Rule Sets.” Oracle Database 10g: Implementing Database Vault

Realm Algorithm 1 2 3 4 5 Using system privileges?
Referenced objects in realm? User in realm authorization? Realm violation 1 2 3 Yes Yes No No Yes No No Rule set evaluate to TRUE? 4 5 User’s authorization based on rule set? Yes Realm Algorithm When a SQL statement is processed by Database Vault, it is checked for realm violations. The steps are: 1. Is the session taking advantage of system privileges to execute this statement? If so, go to step 2. Otherwise, there is no realm violation. 2. Are there objects being referenced that belong to a realm? If so, go to step 3. Otherwise, there is no realm violation. 3. Is the requesting database user an owner or participant in the realm in question? If so, then go to step 4. Otherwise, this is a realm violation, because the user is not allowed to access objects protected by the realm. 4. For the user’s authorization in this realm, is there an authorization rule associated with it? If so, go to step 5. Otherwise, there is no realm violation. 5. Does the authorization rule set evaluate to TRUE? If not, then there is a realm violation. Otherwise, there is no realm violation. No Yes No realm violation Oracle Database 10g: Implementing Database Vault

Realm Protection from DBAs: Example
SALES_DBA can drop an HR table because this user has the DBA role: 1 SQL> CONNECT sales_dba/password SQL> DROP TABLE hr.bonus_it; Table dropped. 2 DVO creates a realm to secure the HR tables: HR schema 3 SALES_DBA attempts to drop the restored HR table: SQL> DROP TABLE hr.bonus_it; ORA-20401: Realm Violation for drop table on HR.BONUS_IT Realm Protection from DBAs: Example In this example, the SALES_DBA user has been set up as the Database Administrator for the Sales application. So, it has been assigned the DBA role, which means that it has a host of powerful privileges, including DROP ANY TABLE. Normally, SALES_DBA would be able to drop any table in the database, including those in other schemas, such as HR. Step one shows how this application DBA is able to drop a table that belongs to another application. In step two, the DVO user uses Database Vault Administrator to create a realm and then secure all HR tables in that realm. Then, in step three, the same SALES_DBA user attempts to drop the same (now restored) HR table, but is unable to. Instead, a realm violation error is returned, and the DROP TABLE command fails. Oracle Database 10g: Implementing Database Vault

Schema Owner Access: Example
HR is unable to drop an HR table because of the realm: 1 SQL> DROP TABLE bonus_exec; ORA-20401: Realm Violation for drop table on HR.BONUS_EXEC 2 DVO makes HR a participant in the realm: HR schema 3 HR is now able to drop its own table: Schema Owner Access: Example Continuing with the HR example from the previous slide, now that there is a realm protecting the HR schema, even the HR user is unable to drop a table in the HR schema. This is typically not a desirable situation, so you decide to make the HR user able to drop its own tables. You do this by adding the HR user to the realm as an authorization. The user can be added as either a participant or an owner. Step one shows that the HR user is unable to drop its own table, because of the realm. In step two, DVO uses Database Vault Administrator to add the HR user as a participant in the realm. Then, HR is able to drop its table, as shown in step three. SQL> DROP TABLE bonus_exec; Table dropped. Oracle Database 10g: Implementing Database Vault

Greatest Level of Access
1 Even though SCOTT does not have access to this realm 2 SCOTT does have access to this realm. So SCOTT can access the OE.ORDERS table. Greatest Level of Access When a single object is protected by more than one realm, if any one of the realms allows access for the user, then access is granted. So, if one realm prevents access in that the requesting user is not a member of the realm, and another realm allows access by including the user in the realm as a participant, then access is granted. In the example in the slide, the SCOTT user is trying to access the OE.ORDERS table. Realm number one is protecting the entire OE schema, and SCOTT is not listed as a realm authorization, so SCOTT cannot gain access via this realm. But in the second realm, which also happens to be protecting the entire OE schema, SCOTT is listed as a participant, so access is granted. The same would be true if one or both of these realms were specifically protecting the OE.ORDERS table rather than the entire OE schema. There is no lesser or greater weight placed on realms that protect object lists with wildcard characters than on those that protect specifically named objects. Oracle Database 10g: Implementing Database Vault

Protecting Roles by Using Realms
Authorization type: meaningful for an object type of ROLE only Only an owner can grant ROLE. Protecting Roles by Using Realms Normally, a database role can be granted by anyone with the GRANT ANY ROLE system privilege, which is part of the DBA role. This can easily mean that there are more users in the database with this ability than really need to be. Putting roles under the protection of a realm solves this problem. As you add an object to a realm, you can specify the type of object to be ROLE. If this is the case, then the Object Owner setting has no effect, because there is no such thing as an owner of a role. In a realm, the difference between being an owner and being a participant is that an owner can grant privileges on the objects in the realm. For example, if a table is in the realm, and SCOTT is specified as Owner, then SCOTT can grant SELECT to other users on that table. In the same manner, when a role is in a realm, if an authorization is added that specifies the user as Owner, then the user can grant the role to other users. This is how a role can be locked down. Even if there are users who have the GRANT ANY ROLE privilege, they must be added to the realm as Owner in order to grant a realm-secured role.hoor234 In the example in the slide, the PM user can grant the HR_RECRUITING role as a result of adding this authorization. Oracle Database 10g: Implementing Database Vault

Protecting Roles by Using Realms (continued) A participant in a realm with a role means that the user can drop that role. Being a participant is required even if the user created the role in the first place. Note: The specification of a role name cannot be done with wildcards (%). You must specify the entire role name. Oracle Database 10g: Implementing Database Vault

Protecting Roles: Example
1 The HR user creates the BENNIES standard database role: SQL> CREATE ROLE bennies; Role created. 2 DVO secures the BENNIES role in a realm: 3 DVO adds the HR user as a participant in the realm: 4 HR is not able to grant the role: Protecting Roles: Example These steps illustrate how to protect a role by using a realm: 1. A user creates the BENNIES role. 2. The DVO user uses Database Vault Administrator (DVA) to secure the BENNIES role in a realm. 3. The DVO user uses DVA to add HR as a participant in that realm. 4. The HR user attempts to grant the role, but fails with a realm violation. This is because the HR user is a participant rather than an owner in the realm. SQL> grant bennies to sh; ORA-47401: Realm Violation for grant role privilege on NULL.NULL Oracle Database 10g: Implementing Database Vault

Protecting Roles: Example
5 DVO changes the HR user to be an owner in the realm: HR is able to grant the role: 6 SQL> GRANT bennies TO sh; Grant succeeded. HR is also able to revoke the role: 7 SQL> REVOKE bennies FROM sh; Revoke succeeded. Protecting Roles: Example (continued) 5. The DVO user uses DVA to change the HR user to be an owner in the realm, rather than a participant. 6. The HR user is now able to grant the role. 7. The HR user is also able to revoke the role. Oracle Database 10g: Implementing Database Vault

Delivered Realms Delivered Realms There are three realms delivered with the Database Vault product. Their names and descriptions are as follows: Database Vault Account Management: Database Vault administrative users have access to this realm to create database accounts. This is implemented by ensuring that only DVSYS and the Database Vault Account Administrator user (for example, DVAM) that you defined during installation can grant the CONNECT and DV_ACCTMGR roles. Oracle Data Dictionary: Oracle catalog schemas, including SYS and SYSTEM, are protected by this realm. This realm defines SYS as the only user who can create objects in these schemas or grant these administrative roles. Database Vault: This realm protects the Database Vault schemas. Oracle Enterprise Manager: This realm protects the DBSNMP and SYSMAN schemas and related roles. Oracle Database 10g: Implementing Database Vault

Realm Views DBA_DV_REALM NAME DESCRIPTION AUDIT_OPTIONS ENABLED DBA_DV_REALM DBA_DV_REALM_OBJECT REALM_NAME OWNER OBJECT_NAME OBJECT_TYPE DBA_DV_REALM_OBJECT DBA_DV_REALM_AUTH REALM_NAME GRANTEE AUTH_RULE_SET_NAME AUTH_OPTIONS DBA_DV_REALM_AUTH SELECT r.name, o.object_name FROM dvsys.dba_dv_realm r, dvsys.dba_dv_realm_object o, dvsys.dba_dv_realm_auth a WHERE r.name = a.realm_name AND r.name = o.realm_name AND r.enabled = 'Y' AND o.object_type = 'ROLE' AND a.auth_options = 'Owner' Realm Views The views that contain realm information are: DBA_DV_REALM: Each realm is represented here with one row. NAME: The name of the realm DESCRIPTION: The description of the realm AUDIT_OPTIONS: A number indicating when auditing is done: 0: Never audit 1: Audit on failure 3: Audit on success or failure ENABLED: Whether the realm is enabled or not. The value can be Y or N. DBA_DV_REALM_OBJECT: This view contains the list of realm-secured objects. REALM_NAME: Name of the realm OWNER: Owner of the realm-secured object OBJECT_NAME: Name of the secured object OBJECT_TYPE: Type of the secured object Oracle Database 10g: Implementing Database Vault

Realm Views (continued) DBA_DV_REALM_AUTH: The realm authorizations are represented in this view. REALM_NAME: Name of the realm GRANTEE: User or role authorized to access the realm-secured objects AUTH_RULE_SET_NAME: Rule set that must evaluate to TRUE in order for the grantee to access the realm-secured objects AUTH_OPTIONS: Indicates whether the grantee is able to grant any roles that are secured in this realm: Participant: Not able to grant Owner: Able to grant Oracle Database 10g: Implementing Database Vault

Realm Views Relative to DVA
DBA_DV_REALM NAME DESCRIPTION AUDIT_OPTIONS ENABLED DBA_DV_REALM DBA_DV_REALM_OBJECT REALM_NAME OWNER OBJECT_NAME OBJECT_TYPE DBA_DV_REALM_OBJECT DBA_DV_REALM_AUTH REALM_NAME GRANTEE AUTH_RULE_SET_NAME AUTH_OPTIONS DBA_DV_REALM_AUTH Realm Views Relative to DVA All the realm views correspond to information entered and viewed on the realm page of Database Vault Administrator (DVA) as shown. Oracle Database 10g: Implementing Database Vault

Realm Reporting: Configuration Issues
Is the realm properly protected? Realm Reporting: Configuration Issues On the Database Vault Reports tabbed page of DVA, you can run the Realm Authorization Configuration Issues report. This report displays information about realms that have the following configuration issues: A realm authorization has a disabled rule set. Grantee does not exist for a realm authorization. There is an incomplete rule set for a realm authorization. Owner does not exist for a realm-secured object. Oracle Database 10g: Implementing Database Vault

Realm Audit Report View realm audit records: Realm Audit Report The Realm Audit Report shows audit records generated by the realm protection and realm authorization operations. A rule set performs realm authorization. This report displays the results of the rule set processing. This is helpful in troubleshooting rule sets and monitoring failed authorization attempts. Realm violations are also displayed in this report. A database account attempts to perform an action on a realm object that it is not authorized to perform that action in the realm. When you configure a realm, you set the audit options for the realm operations. Oracle Database 10g: Implementing Database Vault

Realm API The DVSYS schema contains procedures to do the following with realms: Create a realm. Modify a realm: Modify the realm definition. Rename the realm. Add, update, and delete authorizations or objects associated with the realm. Delete a realm. Procedures are in the DVSYS.DBMS_MACADM package. Realm API The realm API is in the DBMS_MACADM package of the DVSYS schema. These procedures enable you to: Create realms: CREATE_REALM Modify realms: ADD_AUTH_TO_REALM ADD_OBJECT_TO_REALM DELETE_AUTH_FROM_REALM DELETE_OBJECT_FROM_REALM RENAME_REALM UPDATE_REALM UPDATE_REALM_AUTH Delete realms: DELETE_REALM DELETE_REALM_CASCADE Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: List the attributes of a realm Identify the uses of a realm List the ways in which realms provide separation of duties Create and update realms Create and update realms that prevent unauthorized granting of privileges List the steps in the algorithm for realm processing Match the columns of the realm views to the realm user interface elements View realm-related reports by using DVA Maintain realms by using the realm API Oracle Database 10g: Implementing Database Vault

Practice 3 Overview: Managing Realms
This practice covers the following topics: Creating realms to restrict DBA privileged users from creating new objects Creating realms to protect the granting of a role Oracle Database 10g: Implementing Database Vault

Defining Factors

Objectives After completing this lesson, you should be able to do the following: Create and edit factors View existing factors Use factor reports Oracle Database 10g: Implementing Database Vault

Factors: Static Component Context
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Factors: Static Component Context The relationship between Oracle Database Vault components is shown in the slide. Factors use rule sets to define their behavior. Factors use rule sets to limit factor evaluation, and rule sets can refer to factors in their definition. Factors use identities. Oracle Database 10g: Implementing Database Vault

Factors: Dynamic Component Relationships
Secure application role Identity Realm Factor Command rule Rule set Factors: Dynamic Component Relationships Factors are referenced by rule sets in their rule expressions. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Factors: Concepts Each factor: Is a named piece of data Has an identity (value) assigned in several ways Can contribute to security policy Factor: Identity Method Type Validation Audit Security policy Factor Factors: Concepts A Database Vault factor is a building block for the configuration of security policies and overall database security. Each factor is a named piece of data, such as a user location, database IP address, or session user, that Database Vault can recognize and secure. You can use factors for activities such as authorizing database accounts to connect to the database or creating filtering logic to restrict the visibility and manageability of data. A factor is much like a variable in an algebraic equation. Each factor has a value assigned to it. This value is called an identity. Factors are combined in logical ways with other factors in rules and rule sets to provide the basis for security policies. Factors have several attributes: factor type, method, validation expression, and audit options. Factors are evaluated at the session level. Each session accessing the factor can have a different identity (value). For example, the Client_IP factor evaluates to the IP address of the client machine for each session. Factor Factor Oracle Database 10g: Implementing Database Vault

Using Factors Factors can be: Used as delivered with predefined factors Configured by the Database Vault Administrator tool or with API Created and customized Used in rule sets to control access and operations Used to define and enforce security policies Using Factors Database Vault provides a selection of factors that enable you to set controls on such components as your site’s domain, IP addresses, databases, and so on. You can configure factors by using Database Vault Administrator or configure factors by using the APIs provided by Database Vault. You can create custom factors or customize the existing factors. Factors can be used in rule sets as inputs to conditional statement. A PL/SQL function is created for each factor with the name F$<factor_name> in the publicly available schema DVF. This function may be used in rules where a PL/SQL expression is required. Rules and rule sets are covered in detail in the lesson titled “Defining Rule Sets.” Oracle Database 10g: Implementing Database Vault

Predefined Factors Authentication_Method Client_Identifier Client_IP Database_Domain Database_Hostname Database_Instance Database_IP Database_Name Domain Enterprise_Identity Identification_Type Lang Language Machine Network_Protocol Program Proxy_Enterprise_Identity Proxy_User Session_User Predefined Factors There are a set of predefined factors that are automatically assigned values for each session. These factors can used to create additional factors, or they can be customized for your site: Authentication_Method: Returns PASSWORD, KERBEROS, SSL, RADIUS, OS, or DCE , depending on the method of authentication. Proxy with certificate, distinguished name (DN), or username without using password returns NON E. You can use Identification_type to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL. Client_IP: Returns the IP address of a client session if the client connects through the listener, else the returned value is NULL Database_Domain: Domain of the database as specified in the DB_DOMAIN initialization parameter Database_Hostname: Returns the host name of the database as seen in the V$INSTANCE view Database_Instance: Returns the instance identifier as seen in the USERENV context Database_IP: Returns the IP address of the database server on the basis of the host name of the server Oracle Database 10g: Implementing Database Vault

Predefined Factors (continued) Database_Name: Name of the database as specified in the DB_NAME initialization parameter Domain: Domain is a factor that does not have a predefined identity or method. It can be configured for your site. It is intended to be a named collection of physical factors, or configuration-specific or implementation-specific factors in the run-time environment. A domain can be identified via a number of factors such as the host name, IP address, and database instance names. Each domain can be uniquely determined using a combination of the factor identifiers that identify the domain. These identifying factors and possibly additional factors can be used to define Maximum Security Label within the domain, restricting data access and commands, depending on the physical factors about the Database Vault session. Examples of domains of interest are Corporate Sensitive, Internal Public, Partners, and Customers. Enterprise_Identity: The user’s enterprisewide identity. For enterprise users, this returns the Oracle Internet Directory DN. For external users, this returns the external identity (Kerberos principal name, Radius and DCE schema names, OS username, and Certificate DN). For local users and SYSDBA and SYSOPER logins, this returns NULL. The value of the attribute differs by proxy method. For a proxy with DN, this returns the Oracle Internet Directory DN of the client. For a proxy with certificate, this returns the certificate DN of the client for external users. For global users, this returns the Oracle Internet Directory DN. For a proxy with username, this returns the Oracle Internet Directory DN if the client is an enterprise user, and NULL if the client is a local database user. Identification_Type: Returns the way the user’s schema is created in the database. Specifically, it reflects the IDENTIFIED clause in the CREATE/ALTER USER syntax. The syntax used during schema creation is followed by the identification type returned. The IDENTIFIED BY password returns LOCAL. IDENTIFIED EXTERNALLY returns EXTERNAL. IDENTIFIED GLOBALLY returns GLOBAL SHARED. IDENTIFIED GLOBALLY AS DN returns GLOBAL PRIVATE. Lang: The International Organization for Standardization (ISO) abbreviation for the language name, a shorter form than the existing LANGUAGE parameter Language: The language and territory currently used by your session, along with the database character set, in this form: language_territory.characterset Machine: Provides the client machine name for the current session Network_Protocol: Returns the network protocol being used for communication, as specified in the PROTOCOL=protocol portion of the connect string Proxy_Enterprise_Identity: Returns the Oracle Internet Directory DN when the proxy user is an enterprise user Proxy_User: Name of the database user who opened the current session on behalf of SESSION_USER Session_User: For enterprises users, returns the schema. This is the database user name by which the current user is authenticated. This value remains the same throughout the duration of the session. Oracle Database 10g: Implementing Database Vault

Factors and Contexts Differences: Factors can be: Audited Combined logically without programming Assigned trust levels Assigned labels Exposed without coding or creating contexts Similarities: Both are: Cached in memory Assigned values at the session level Factors and Contexts Database Vault provides several predefined factors whose values are set by calls to the USERENV context. Factors use context values because they are memory based and fast. Factors provide several features that contexts do not, such as: Factors can be created without coding PL/SQL procedures. Factors can be set and used without changing the application code. Factors can be audited. Factors can be logically combined without programming. Factors can be assigned trust levels. Factors can be used with Oracle Label Security (OLS) to apply labels to sessions. Factors and contexts are similar because factors use context attributes. When a factor is created, the Database Vault packages create a context attribute for that factor. Factors have the advantages of contexts, without the coding. Factors add security features that are not available with contexts alone. Oracle Database 10g: Implementing Database Vault

Factor Scenarios Domain = INTERNET SELECT * FROM hr.employees HR Clerk
WorkHours = WEEKEND UPDATE hr.employees HR Clerk Proxy_User = SH Domain = SECURE Factor Scenarios Factors are useful in building security policies. They are building blocks that reduce the programming necessary to produce a robust security policy. Suppose only users connected through the internal network are allowed to access the HR schema. You can place the HR schema objects in a realm. Modify the Domain factor to identify the network source of the session. Create a rule set by using the factor that enforces “Do not allow HR realm access from the internet (Domain=INTERNET).” You can define a similar rule set that does not allow any DML (insert, update, or delete) outside of standard work hours. (WorkHours = WEEKEND or WorkHours = WEEKNIGHT). You can ensure that users can access the application schema objects only through the application server by using a secure application role. You can define a rule that says “This role can only be enabled when the session originates on the application server machine (Domain = SECURE) and the user is proxied by the application owner (Proxy_User = SH).” The factors Domain and Proxy User contribute to this scenario. Rules and rule sets are covered in the lesson titled “Defining Rule Sets.” Secure application roles are covered in the lesson titled “Configuring Secure Application Roles.” INSERT … INTO sh.sales WSMITH Oracle Database 10g: Implementing Database Vault

Creating and Editing Factors
To create or edit factors, log in to the Database Vault Administrator (DVA) tool as a user with the DV_ADMIN role. Navigate to the Administration page, and click the Factors link in the Database Vault Feature Administration section. The Factor page, as shown in the slide, is displayed. At this point, you can click Create to create a new factor or select an existing factor and click Edit. The predefined factors map to several session attributes that are commonly used to determine access rights. There are also a few factors such as Domain that are placeholders and are often defined, but are site specific. In the lesson titled “Defining Identities,” you edit the Domain factor to define meaningful identities. Oracle Database 10g: Implementing Database Vault

The Create Factor Page The Create Factor Page On the Create Factor page, enter the factor name, description, factor type, and the other factor attributes. Factor type and the rest of factor attributes are discussed in the following slides. In the slide, a factor named “TimeOfDay” is being created. A function to create or edit the factor with all of its attributes is provided in the DVSYS schema as part of the DBMS_MACADM package. CREATE_FACTOR is shown (UPDATE_FACTOR has the same parameters): CREATE_FACTOR(factor_name VARCHAR2, factor_type_name VARCHAR2, description VARCHAR2, rule_set_name VARCHAR2, get_expr VARCHAR2, validate_expr VARCHAR2, identify_by NUMBER, labeled_by NUMBER, eval_options NUMBER, audit_options NUMBER, fail_options NUMBER) Oracle Database 10g: Implementing Database Vault

Factor Types Factor types group factors into categories. Factor Type User Time Factors Factor Types The factor type enables you to group factors into categories. Some of the predefined factor types are authentication method, host name, and instance. You can define your own factor types such as application name or certificate information. Factors types are used only for grouping factors and have no effect on the factor or the factor display in DVA. For example, the predefined factors (Session User, OS User, and Proxy User) are grouped in the User factor type. The DBMS_MACADM package provides a function to create a factor type: CREATE_FACTOR_TYPE(name VARCHAR2, description VARCHAR2) The TimeOfDay factor is assigned to the Time factor type. Session user Identification type Proxy user TimeOfDay Oracle Database 10g: Implementing Database Vault

Factor Identification
The value of a factor is the identity. Factor identification is the process of assigning a value to the identity. Values are assigned by: Method Constant Factors Factor Identification The value of a factor is the identity of that factor. The identity of a factor is assigned by a method, a constant, or other factors. On the Edit Factor or Create Factor page, there are three choices for factor identification: By Method: This is the default option. When this option is chosen, a PL/SQL expression entered in the Retrieval Method field is evaluated to obtain the identity. The method can be any PL/SQL function that returns a VARCHAR2 data type. Examples can be seen in the predefined factors. By Constant: When this option is selected, a constant value entered in the Retrieval Method field is assigned to the factor. This option assigns a single value to the factor, and the value is always the same. The constant is a VARCHAR2 string. By Factors: When this option is selected, a mapping identity is used to evaluate a set of child factors. The result is assigned to the parent factor. This option is used to easily create a factor by using the results of multiple other factors that are already defined, without having to write a complex PL/SQL function. The TimeOfDay factor is identified by factors to allow multiple names for the different times needed for security, such as Workhours, Weeknight, and Weekend. The value of a factor may also be set by the application by using the DVSYS.SET_FACTOR function. Oracle Database 10g: Implementing Database Vault

Factor Evaluation Evaluation determines when an identity is assigned to the factor. For Session By Access CONNECT SELECT UPDATE Factor Evaluation Factor evaluation determines when the identity is assigned. By Session: With this option, the factor is evaluated once per session when the session is created. This option incurs less overhead, and should be used with factors such as Client_IP address or Session_User that remain constant for the entire session. By Access: With this option, the factor is evaluated when the session is created and each time the factor is accessed. This option forces the factor to be reevaluated. This option has a higher overhead, but ensures that factors that could change during the life of the session are assigned and validated properly. For example, Language-, Module-, and Time-based factors could change. The TimeOfDay factor should be evaluated by access. This would prevent a session continuing access or actions in a forbidden time of a day. The factors and rules cannot be avoided just by starting the session during a time when those actions or access are allowed. Oracle Database 10g: Implementing Database Vault

Retrieval Method The retrieval method is a PL/SQL expression that evaluates to a VARCHAR2 value: A constant: “INTERNET” An expression: JLS.MY_FUNCTION(DVF.F$HOST_IP) The function must return VARCHAR2. EXECUTE on function must be granted to DVSYS. Retrieval Method The retrieval method is required if Factor Identification is set to By Constant or By Method. The entry in the retrieval method field is a PL/SQL expression. This expression may be a constant VARCHAR2 string or a data type that is convertible to VARCHAR2. This expression may be a packaged or stand-alone function. The expression cannot be a complete SQL statement. When you use a function as a retrieval method, it must be completely specified with schema and function name, such as JLS.MY_FUNCTION(…). The DVSYS user must have the EXECUTE privilege on the function. As with the function JLS.MY_FUNCTION(DVF.F$HOST_IP), the value returned by another factor may be accessed using the DVF-owned function for that factor either as a parameter or in the function body. Oracle Database 10g: Implementing Database Vault

DVSYS.SET_FACTOR Set the factor identity by using the SET_FACTOR function. An assignment rule set must be specified. A validation method is recommended. BEGIN DVSYS.SET_FACTOR('DOMAIN','SECURE'); END; DVSYS.SET_FACTOR A factor may be set from the session that is using the factor. This function provides a way for applications and application servers to set factor information that may be available only to the application. A factor cannot be set unless an assignment rule set is specified. The rule set is evaluated when the SET_FACTOR function is called to determine whether the factor is allowed to be set. Because this function is executable by PUBLIC, it is recommended that a validation method is always specified for any factor that may be set by the SET_FACTOR function. Oracle Database 10g: Implementing Database Vault

Validation Method The validation method is: A PL/SQL expression that returns a BOOLEAN value An additional check on the identity A packaged or stand-alone function A condition Validation Method The validation method is evaluated each time the identity is retrieved, as an additional check on the value. The validation method can be any PL/SQL expression that returns a boolean value. The identity may be set in several ways, through defined method, constant, and other factors, and with the SET_FACTOR procedure. A validation method provides another check of the identity at each retrieval. Always use validation methods if the factor is assignable by the SET_FACTOR procedure to verify that invalid entries are not submitted. You can use a packaged or stand-alone function, or a condition as shown in the slide. There are two signatures available for the function: FUNCTION is_valid RETURN BOOLEAN This signature is more appropriate to factors that are evaluated by session. The DVF.F$factor_name function may be used inside this function. FUNCTION is_valid (p_factor_value VARCHAR2) RETURN BOOLEAN Oracle Database 10g: Implementing Database Vault

Factor Audit Options Audit options must be set: Multiple options may be selected. Options are combined to determine behavior. Factor Audit Options Audit options control the generation of a custom Database Vault audit record. It is a mandatory attribute, though it may be set to Never. The generated audit records can be displayed using the Database Vault Auditing Factor Violation report. Multiple audit options may be selected at a time. In the slide, the default options are shown for each of the values: Never, Always, and Sometimes. Each option is converted to a bit mask and added to determine the aggregate behavior. The following audit options are provided: Retrieval Error: Create an audit record when a factor’s identity cannot be resolved and assigned due to an error (such as “No data found” or “Too many rows”). Retrieval NULL: Create an audit record when a factor’s identity is resolved to NULL. Validation Error: Create an audit record when the validation method (if provided) returns an error. Validation False: Create an audit record when the validation method (if provided) returns FALSE. Trust Level NULL: Create an audit record when the factor’s resolved identity has an assigned trust level of NULL. Trust Level Less Than Zero: Create an audit record when the factor’s resolved identity has an assigned trust level less than zero. Oracle Database 10g: Implementing Database Vault

Error Options Error options control error message behavior: Show Error Message (default) Do Not Show Error Message Error Options The error option is a required attribute that defaults to Show Error Message. Error options control the processing that occurs when the resolution of a factor identity fails. The possible options are: Show Error Message: Displays an error message to the database session. This option is very useful for debugging. Do Not Show Error Message: Suppresses the error message. This option does not give any additional information to an unauthorized user, but fails silently. Oracle Database 10g: Implementing Database Vault

Deleting Factors Deleting Factors To delete a factor, perform the following steps: Select the factor by clicking the option next to the factor name. Click Remove. A confirmation page appears. Click Yes to delete the factor. The DBMS_MACADM package provides the function: DELETE_FACTOR(factor_name VARCHAR2) Oracle Database 10g: Implementing Database Vault

Factor Views NAME DESCRIPTION FACTOR_TYPE_NAME ASSIGN_RULE_SET_NAME GET_EXPR VALIDATE_EXPR IDENTIFIED_BY IDENTIFIED_BY_MEANING NAMESPACE NAMESPACE_ATTRIBUTE LABELED_BY LABELED_BY_MEANING EVAL_OPTIONS EVAL_OPTIONS_MEANING AUDIT_OPTIONS FAIL_OPTIONS FAIL_OPTIONS_MEANING DBA_DV_FACTOR DBA_DV_RULE_SET_RULE NAME DESCRIPTION DBA_DV_FACTOR_TYPE Factor Views The following views, in the DVSYS schema, contain factor-related information: DBA_DV_FACTOR: One row per factor, and holds the attributes of a factor, such as method, evaluation option, audit option, and assignment rule set. DBA_DV_FACTOR_LINK: One row for each parent factor and child factor link. The view is used in resolving the relationships from the factor links to identity maps. DBA_DV_FACTOR_TYPE: One row per factor type. A factor type supports categorizing factors by architecture and system components. This table has three attributes: PARENT_FACTOR_NAME CHILD_FACTOR_NAME LABEL_IND Oracle Database 10g: Implementing Database Vault

Factor Configuration Issues Report
The configuration issues report shows configuration problems and is used for: Troubleshooting Configuration audit Factor Configuration Issues Report The configuration issues report shows some of the common configuration issues that occur. This report is useful in troubleshooting and as a check that the Database Vault component has been configured. This report can be used by the Auditor or Security Analyst to audit the Database Vault configuration. The configuration report focuses on incomplete configuration and misconfigured objects. These issues could be the result of an interrupted configuration session, a poor design, or inexperienced administrator. Whatever the reason, these configuration issues have the potential for allowing security breaches in your system. The Factor Configuration Issues report displays the following issues: Disabled rule set for factor assignment Incomplete rule set for factor assignment Invalid audit options for the factor No factor retrieval method or constant No mapped factors linked to an identity factor No mapped factors linked to a label factor No Oracle Label Security (OLS) policy for the factor Oracle Database 10g: Implementing Database Vault

Factor Audit Report Factor Audit Report This report shows an example when audit options have been set to Always. This report is helpful when you are tracking an error and need to see the processing step for factors. In production, you would set the factor audit options to Sometimes or Never to reduce the processing cost and the volume of audit records. The Factor Audit report shows audit records generated as a result of factor evaluation and factor assignment operations. You can audit instances where a factor’s identity cannot be resolved and assigned (such as “No data found” or “Too many rows”). A factor can have an associated rule set that assigns an identity to the factor at run time. When you configure a factor, you can set it to audit the rule set processing results. Oracle Database 10g: Implementing Database Vault

Factors API The DVSYS schema has functions to: Create factors, factor links, and factor types Modify factors and factor types: Rename factor Update factor Delete factors, factor links, and factor types Integrate factors with Oracle Label Security PUBLIC is granted the EXECUTE privilege on procedures to: Set the factor Get factor attributes Factors API DVSYS Schema Functions Create factors, factor links, and factor types: ADD_FACTOR_LINK: Specifies a parent-child relationship for two factors CREATE_FACTOR: Creates a factor CREATE_FACTOR_TYPE: Creates a factor type Modify factors and factor types: RENAME_FACTOR: Renames a factor. The name change takes effect everywhere the factor is used. RENAME_FACTOR_TYPE: Renames a factor type. The name change takes effect everywhere the factor type is used. UPDATE_FACTOR: Updates a factor UPDATE_FACTOR_TYPE: Updates a factor type Delete factors, factor links, and factor types: DELETE_FACTOR: Deletes a factor DELETE_FACTOR_LINK: Removes a parent-child relationship for two factors DELETE_FACTOR_TYPE: Deletes a factor type Oracle Database 10g: Implementing Database Vault

Factors API (continued) Integrate factors with OLS: ADD_POLICY_FACTOR: Specifies that the label for a factor contributes to the Oracle Label Security label for a policy For other identity-related functions, see the lesson titled “Defining Identities.” Publicly Executable Function for Factors A small set of functions is exposed to the general database population. The procedures and functions just expose the minimum methods that are required. The procedures and functions that are used to enable Database Vault processing with the DVSYS schema are as follows: DVSYS.SET_FACTOR: This procedure can be used by an application that requires the ability to set factor identities dynamically. DVSYS.GET_FACTOR: This function is exposed to allow for the public factor functions to resolve the identity of a factor. DVSYS.GET_TRUST_LEVEL: This function returns the trust level of the current session identity for the factor requested. DVSYS.GET_TRUST_LEVEL_FOR_IDENTITY: This function returns the trust level for the factor and identity requested. There are other publicly executable functions that apply to identities and label security integration. Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Create and edit factors View existing factors Use factor reports Oracle Database 10g: Implementing Database Vault

Practice 4 Overview: Working with Factors
This practice covers the following topics: Creating factors Editing factors Viewing factors Oracle Database 10g: Implementing Database Vault

Defining Identities

Objectives After completing this lesson, you should be able to do the following: Describe the concept of identities Map identities Manage identities Oracle Database 10g: Implementing Database Vault

Identities: Static Component Context
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Identities: Static Component Context The relationship between Oracle Database Vault components is shown in the slide. Factors use identities. An identity is the value assigned to a factor. Oracle Database 10g: Implementing Database Vault

Identities: Dynamic Component Relationships
Secure application role Identity Realm Factor Command rule Rule set Identities: Dynamic Component Relationships Identities are referenced by factors. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Identities: Concepts An identity: Is a value Has a trust level Can be resolved from other factors Can have a label Trust level Label Method Factor with identity Mapping Identity Factor Identities: Concepts An identity is a value that is associated with a factor. The identity of a factor can vary on the basis of the session, application, user, or even time of day. For example, when a user connects through a machine in the office, the DOMAIN factor identity is set to INTRANET with a TRUSTED trust level. When the same user connects from home, the DOMAIN factor identity is set to INTERNET with an UNTRUSTED trust level. In this example, the DOMAIN factor can be used to determine what data the user is allowed to access and what commands the user is allowed to perform. The value, or identity that is assigned to a factor, can be a constant, determined by a method or derived from other factors. The identity can have a trust level associated with it. If Oracle Label Security (OLS) is used, a label can be assigned to the session on the basis of the labels assigned to the identities. A factor can have an identity assigned by a combination of multiple factors. The identity of these factors can in turn be resolved by other factors. Using factors to resolve an identity is called an identity mapping. Constant Factor Oracle Database 10g: Implementing Database Vault

Purpose of Identities Configure identities to: Define the known identities for a factor Add a trust level to a factor’s identity Resolve a factor’s identity through child factors (identity mapping) Add an OLS label to a factor’s identity Purpose of Identities A factor’s identity for a given database session is assigned at run time using the Factor Identification and Retrieval Method fields. Configuration of identities is optional and is used to serve the following purposes: To define the known identities for a factor To add a trust level to a factor’s identity To add an OLS label to a factor’s identity To resolve a factor’s identity through its child factors (identity mapping) Identities must be configured to use trust level, OLS label, or child factors. Oracle Database 10g: Implementing Database Vault

Identity Example: All Possible Identities
The DOMAIN factor is defined with three identities: SECURE INTRANET INTERNET Identity Example: All Possible Identities The DOMAIN factor is defined with three identities: SECURE, INTRANET, and INTERNET. If the assignment rule set is Null or Disabled, then these values are the only ones allowed that may be set with the SET_FACTORS function. The conditions that determine which identity is assigned are defined by the settings on the Map Identity region of the Create Identity or Edit Identity pages. If the retrieval method returns a value that is not one of the defined identities, then the identity is set to the returned value and the trust level is set to Untrusted. Oracle Database 10g: Implementing Database Vault

Identity Example: Adding Trust Levels
The DOMAIN factor has defined identities each with a trust level: SECURE has a trust level of Very Trusted (10). INTRANET has a trust level of Trusted (5). INTERNET has a trust level of Untrusted (–1). Identity Example: Adding Trust Levels Each identity defined must have a trust level assigned, even if it is the Trust Level Not Defined option. The trust level value can be used in rule sets and validation functions. For example, you have a security rule that the HR.EMPLOYEES table cannot be accessed when the user is connecting from the Internet. You can create a factor named HR_EMP_ACCESS that determines the access to the HR.EMPLOYEES table. Then, attach a validation function and an assignment rule set that prevents the HR_EMP_ACCESS factor from being set if DOMAIN has a trust level of Untrusted or Trust Level Not Defined. Oracle Database 10g: Implementing Database Vault

Identity Example: Mapping Child Factors
Use another factor to assign the identity. Identity Example: Mapping Child Factors The value of an identity can be assigned by evaluating another factor called a child factor. In this case, the value INTERNET is assigned to the DOMAIN factor when the Client_IP factor is not an address on the local subnet. Each identity can have one or more child factors that determine when the identity will be set. Mapping the factors provides a convenient way to build a modular system. By using factors in this way, you can reduce or eliminate the need to write PL/SQL retrieval methods. Oracle Database 10g: Implementing Database Vault

Editing the Factor: Creating an Identity
Identities can be created for factors that are identified by any of the three factor identification options. For the DOMAIN factor, Factor Identification is set to By Factor. You can declare a set of values that the factor identity is expected to have. For each identity, a trust level may be set, and with Label Security Integration, a label may be set for each identity. Oracle Database 10g: Implementing Database Vault

Creating an Identity 1 4 2 3 Creating an Identity 1. Click the Create button in the Identities section on the Edit Factors page. 2. Enter the value of the identity; this is a VARCHAR2 data type. 3. Set the trust level. This may be set to Trust Level Not Defined if the trust level is not used in your instance. 4. Click OK to create the identity. Oracle Database 10g: Implementing Database Vault

Trust Levels The trust level is a mandatory attribute and can have one of the following values: Very Trusted: Assigns a trust level value of 10 Trusted: Assigns a trust level value of 5 Somewhat Trusted: Assigns a trust level value of 1 Untrusted: Assigns a trust level value of –1 Trust Level Not Defined: Assigns a trust level value of NULL (default) Trust Levels The trust level represents the level of confidence in the factor-value pair. It is a mandatory attribute. A trust value of 1 signifies some trust. A higher value indicates a higher level of trust. A negative value indicates distrust. When the factor identity returned from a factor retrieval method is not defined in the identity table, the identity is automatically assigned a negative trust level. To determine the trust level of a factor identity at run time, you can use the following functions in the DVSYS schema that are publicly available: FUNCTION get_trust_level(p_factor IN VARCHAR2) RETURN NUMBER FUNCTION get_trust_level_for_identity(p_factor IN VARCHAR2, p_identity IN VARCHAR2) RETURN NUMBER For example: SQL> SELECT dvf.f$domain, get_trust_level('DOMAIN') FROM dual; F$DOMAIN GET_TRUST_LEVEL('DOMAIN') INTERNET Oracle Database 10g: Implementing Database Vault

Trust Levels (continued) SQL> SELECT get_trust_level_for_identity('DOMAIN','SECURE') FROM dual; GET_TRUST_LEVEL_FOR_IDENTITY('DOMAIN','SECURE') 10 In the preceding example, the INTERNET identity for the DOMAIN factor is untrusted (value equals –1), and the identity for the SECURE domain is 10, which implies a greater trust. Trust-level information can be used in rule sets, in validation methods, or directly from the application. The GET_TRUST_LEVEL and GET_TRUST_LEVEL_FOR_IDENTITY functions are executable by any user. For example, the application can check the trust level before allowing access to certain tables, or a validation method can check that a trust level must be above a certain level before it allows the application to set a factor. Oracle Database 10g: Implementing Database Vault

Mapping Identities 2 1 3 Mapping Identities Creating a map identity associates child factors with the identity value that is created in the previous slides. Perform the following tasks: 1. Select the identity to be changed in the Identities section on the Edit Factors page. 2. Click the Edit button. 3. Go to the Map Identity section, and click Create to create an identity mapping. Oracle Database 10g: Implementing Database Vault

Mapping Identities Mapping Identities (continued) On the Create Identity Map page, select a factor from the Contributing Factor field. The factor that you want to use must have been already defined. Choose a map condition, and enter a low value. In the example in the slide, the condition for this mapping is Client_IP Equal At run time, when the DOMAIN factor is evaluated, if the "Client_IP Equal " condition is true, then the SECURE identity is set for the DOMAIN factor. The low value field is required. The high value field is only required for conditions that require two operands such as Between. An identity may have multiple identity maps. If the maps use the same factor, the conditions are joined with OR, otherwise, they are joined with an AND condition. Oracle Database 10g: Implementing Database Vault

Examples of Identities Mapped to Factors
The INTRANET identity is defined to include all machines on the same local subnet, except for the server itself. The conditions in this case are as shown in the slide. Notice that the conditions skip the server address, Oracle Database 10g: Implementing Database Vault

Map Conditions If there are multiple identities for the same factor, then: Conditions should not overlap Identities are evaluated in an ASCII sort order of name Map Conditions When you have multiple identities for the the same factor, the first identity that is evaluated that returns TRUE for the map conditions will be set. The identities are evaluated in the order of the identity name, in an ASCII sort. If the conditions overlap, the evaluation order can lead to unexpected result. For example, if the DOMAIN factor is assigned the INTRANET identity for sessions originating on any machine on the subnet, except sessions originating on host , then DOMAIN is assigned SECURE. If INTRANET is defined as CLIENT_IP LIKE % and SECURE as CLIENT_IP = , even sessions originating on the secure server would get the DOMAIN identity of INTRANET, instead of the expected SECURE, because the INTRANET identity is evaluated first. Oracle Database 10g: Implementing Database Vault

Deleting Identities To delete an identity: Navigate to the Edit Factor page. On the Edit Factor page, remove identity. Deleting Identities Navigate to the Edit Factors page. Select the identity that you want to remove, and click Remove. You will be prompted to confirm your action. This action removes both the identity and any identity maps to the identity. Oracle Database 10g: Implementing Database Vault

Integrating Factors and Oracle Label Security
Is based on policies Assigns labels to users Database Vault factors: Database Vault factors can carry a label with each identity. Label is assigned when the identity is evaluated. Integrating Factors and Oracle Label Security Oracle Label Security (OLS) provides row-level security based on labels. These labels are assigned to rows and user sessions. For any object that is protected by an OLS policy, the session label is compared to data label to determine user access to the row. In OLS, labels can be assigned to sessions in a variety of ways: A user can have a single label specifically assigned; a user can be assigned a label based on session attributes; or with Database Vault, the user session can be assigned a label on the basis of a factor identity. Database Vault provides factors that are evaluated and assigned identities. Each identity can have a single OLS label assigned. These labels are applied to the user session. If there are multiple factors mapped to the factor identity, each of the factor labels is merged according to the algorithm that you specify. You can specify a label to be used when there is an error. This prevents unauthorized access when there is an error either in configuration or in initialization. It is important that a well-designed plan be constructed before implementing OLS. Poor label design can create security holes or prevent users from accessing data that they are authorized to view. OLS policy Oracle Database 10g: Implementing Database Vault

Oracle Label Security Oracle Label Security Oracle Label Security (OLS) provides row-level security built on Virtual Private Database (VPD) technology. The rows are labeled indicating a security classification required to access the row. Each user session is assigned a label. The session label must dominate (equal or exceed) the row label for the user to access the row. Oracle Label Security is applied to a table by using a policy. A policy is defined, named, and assigned to a table or schema. Oracle Policy Manager, a graphical tool for managing OLS policies, is shown in the example in the slide. In the example, the FACILITY policy is assigned to the HR.LOCATIONS table. Several users have been created, and labels that define the user access level have been defined. Label assignment to data is not shown. Each row has a label. When a user attempts to access the data, the SQL statement is rewritten according to the policy, so that only the rows that have a label dominated by the user session label are accessible. This is a brief overview of OLS. For more information about the operation and administration of OLS, see the Oracle Label Security Administrator's Guide 10g Release 2. Oracle Database 10g: Implementing Database Vault

Oracle Label Security Policies
OLS policies can be integrated with Database Vault. Click the Label Security Integration link on the Administration tabbed page of Database Vault Administrator (DVA) to display the Label Security Policies page. The policies list shown is empty until the policies are “created,” that is, associated with Database Vault. The policies must already exist in OLS. When you click the Create button, the Create Policy page is shown. You may choose an existing Label Security policy from the Label Security Policy pull-down menu. The function to associate a policy and a label algorithm with Database Vault is provided in the DBMS_MACADM package. CREATE_MAC_POLICY(policy_name VARCHAR2, algorithm VARCHAR2) Oracle Database 10g: Implementing Database Vault

Editing OLS Policies Editing OLS Policies You may set the merge algorithm and factors that will be used to set session labels when the policy is created or edit the policy later. The create and edit pages have the same fields. Choose the factors that will be used to determine the label, by selecting a factor from available factors, and moving it to the selected factors window. Factors can be assigned to policies before or after the label is assigned to the factor identity. The Edit Policy page is where you choose the merge algorithm when multiple factors are used to determine the label. You can also specify a label for initialization errors. The label specified for initialization errors is set when a configuration error or run-time error occurs during session initialization. This can be used to assign the session a data label that will prevent access or update to any data protected by the policy until the issue is resolved. Use the function from the DBMS_MACADM package to change the label algorithm: UPDATE_MAC_POLICY(policy_name VARCHAR2, algorithm VARCHAR2) Oracle Database 10g: Implementing Database Vault

OLS Merging Algorithms
Merge algorithms: Control the maximum access allowed Should match your design Are used when multiple factors determine an identity label OLS Merging Algorithms Database Vault can control the maximum access in a database session by merging the labels of Database Vault factors that are associated with an Oracle Label Security (OLS) policy. The merge algorithm is selected per policy. When multiple factors are combined to assign an identity, each factor identity can have an associated label. All applicable labels are merged to determine the final label for the policy. The merge process follows the rules of the OLS merge algorithms. The default algorithm is a minimum level, intersection, intersection (LII). The LII algorithm returns the minimum level, the intersection of compartments, and the intersection of groups. This means that if one factor grants a level of Highly Sensitive: C1: Asia, and another factor grants Sensitive:C2: Asia,US, the result will be Sensitive::Asia. This example assumes Sensitive is a lower level than Highly Sensitive. There are multiple merge algorithms to tailor the behavior to your needs. Oracle Database 10g: Implementing Database Vault

Factor Labeling Factors can receive a label: By Self By Factors Label Label Label Label Merge Label Factor Labeling If you are using OLS policies, then factor labeling becomes a mandatory field. By Self: It is the default. All possible identities are directly labeled, each with a label associated with an OLS policy. When the identity is assigned, a specific OLS label is also assigned. By Factors: The identity label is derived from the labels of child factor identities. When there are multiple child factor identities with labels, labels are merged using an OLS merge algorithm. This algorithm is specified for each OLS policy on the Label Security Policies page. A factor can have an assigned label for each applicable OLS policy. Suppose that you are using Oracle Label Security. With the DOMAIN factor, the By Self labeling is used. The By Self option is used when all identities are named in the factor. If the identities are derived from the child identities, then the By Factors option would be used. Oracle Database 10g: Implementing Database Vault

Identities and OLS Identities and OLS A factor may have many identities, so a factor may have different labels depending on which identity is assigned. Each factor identity can have one and only one label per policy. This label is assigned to the identity. When the factor is evaluated, the label is assigned to the session. In the example, the INTERNET identity is assigned a label, so Factor Labeling is set to By Self. If the label is assigned on the basis of factors that the INTERNET identity uses, then you remove the label identity for INTERNET and set Factor Labeling to By Factors. To assign a label to an identity, perform the following steps: 1. Navigate to the Edit Factor page, and select By Self in the Factor Labeling section. 2. In the Identities section, click Edit to edit an identity. 3. On the Edit Identity page, choose from available labels to assign labels to this identity. An identity cannot have overlapping labels. You can assign a label to a factor identity only if OLS has been implemented with policies and labels. After the policy is associated with Database Vault, the Available OLS Labels window is populated with the labels belonging to that policy. In the slide, two policies have been created, FACILITY and PRIVACY, so all the defined labels for those policies are available. OLS labels and trust levels are independent. Trust levels allow only some of the access control that labels provide. Oracle Database 10g: Implementing Database Vault

Identity View FACTOR_NAME VALUE TRUST_LEVEL DBA_DV_IDENTITY Identity View DVSYS.DBA_DV_IDENTITY has one row per identity. The attributes of this table map to the fields on the Edit Factor page, and are modified on the Edit Identity page. Oracle Database 10g: Implementing Database Vault

Identity Map View DBA_DV_RULE FACTOR_NAME IDENTITY_VALUE PARENT_FACTOR_NAME CHILD_FACTOR_NAME OPERATION_CODE OPERATION_VALUE OPERAND1 OPERAND2 LABEL_IND DBA_DV_IDENTITY_MAP Identity Map View DVSYS.DBA_DV_IDENTITY_MAP has one row for each parent factor and child factor link. The view is used in resolving the relationships from the factor links to identity maps. The attributes of this table map to the Map Identity section of the Edit Identity page. You modify these attributes on the Edit Identity Map page. Oracle Database 10g: Implementing Database Vault

Factors Without Identities Report
The report shows factors that may be vulnerable: Factors Without Identities Report This report lists all the factors that have no identities defined in the access control configuration. For some factors, such as Background_Job_Id, this may not be a real problem, but the report is useful in determining whether your access control configuration is complete and whether you have accounted for all factor configuration. There are several possibilities for this condition: The factor is not being used. In this case, remove the factor from the configuration to reduce processing at connect time. This processing applies only to factors evaluated by session. The factor has no assignment rule set. In this case, the factor cannot be set by using the SET_FACTOR procedure. The only values allowed are those returned through the Identified By settings: By Constant, By Method, or By Factors. These are more easily verified. The number of possible identities is too large to individually enumerate. The validation method should be used to check the value, especially if the identity can be set with SET_FACTOR. The identity configuration is incomplete. In this case, complete the configuration of the identities. Oracle Database 10g: Implementing Database Vault

Identity Configuration Issues Report
Check the identity configuration for: Mapped identities OLS label existence Identity Configuration Issues Report This report checks that an identity mapping exists for each identity where the factor is identified by other factors. This is shown in the slide. This report also shows identities that are assigned OLS labels that do not exist in the OLS policy. This situation should never occur. Oracle Database 10g: Implementing Database Vault

Label Security Integration Audit
View audit records of OLS session operations: Label Security Integration Audit The Label Security Integration Audit report shows audit records generated by the initialization operation of the label security integration session and label assignment operation of the label security session. You can audit instances where the label security session fails to initialize and where the label security component prevents a session from setting a label that exceeds the maximum session label. Oracle Database 10g: Implementing Database Vault

Identities API The DVSYS schema has functions to: Create identities and identity maps Modify identities: Change an identity Update an identity Delete identities and identity maps Identities API DVSYS Schema Functions Create identities and identity maps CREATE_IDENTITY: Creates an identity CREATE_IDENTITY_MAP: Defines a set of tests that are used to derive the identity of a factor from the value of linked child factors (subfactors) Modify identities CHANGE_IDENTITY_FACTOR: Associates an identity with a different factor CHANGE_IDENTITY_VALUE: Updates the value of an identity UPDATE_IDENTITY: Updates an identity Delete identities and identity maps DELETE_IDENTITY: Removes an identity DELETE_IDENTITY_MAP: Removes an identity map for a factor The OLS label for a policy Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Describe the concepts of identities Map identities Manage identities Oracle Database 10g: Implementing Database Vault

Practice 5 Overview: Managing Identities
This practice covers the following topics: Creating a factor identified by factors Creating identities and mapping to factors Performing a task and creating a factor to prohibit the task Oracle Database 10g: Implementing Database Vault

Defining Rule Sets

Objectives After completing this lesson, you should be able to do the following: Identify the uses of a rule set Create, modify, and delete a rule set Create rules and add them to a rule set View the rule set violation details of an audit record Oracle Database 10g: Implementing Database Vault

Rule Sets: Concepts Rule 1 TRUE or FALSE AND/OR Rule 2 TRUE or FALSE AND/OR AND/OR Rule n TRUE or FALSE Rule Sets: Concepts A rule set is a collection of rules that are evaluated together to produce a result. Each rule is defined as a WHERE clause expression. The rule set specifies whether the results of the rules are to be ANDed or ORed together. After each rule is evaluated, those results are ANDed or ORed together, and the result is a single value of TRUE or FALSE. Oracle Database Vault provides a rules engine to process rule sets. Rule set result TRUE or FALSE Oracle Database 10g: Implementing Database Vault

Rule Sets: Concepts Is machine local? TRUE or FALSE AND / OR
Is it a weekend? TRUE or FALSE AND / OR AND / OR Is the APP.STATUS column > 0? TRUE or FALSE Rule Sets: Concepts (continued) In this case, where the rule set is defined such that all rules must be TRUE, the rule set evaluates to FALSE. Because the machine is local and the APP.STATUS column is greater than zero, the second rule, which checks whether it is currently a weekend, resolves to FALSE. That result ANDed with the other rule results evaluates to a FALSE value for the entire rule set. If this were defined as an OR situation, then the result would have been TRUE, because at least one of the rules evaluates to TRUE. Rule set result TRUE or FALSE Oracle Database 10g: Implementing Database Vault

Rule Sets: Static Component Context
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Rule Sets: Static Component Context The relationship between Database Vault components is shown in the slide. Realms, command rules, secure application roles, and factors use rule sets to define their behavior. Rule sets can also refer to factors in their definition. Oracle Database 10g: Implementing Database Vault

Rule Sets: Dynamic Component Relationships
Secure application role Identity Realm Factor Command rule Rule set Rule Sets: Dynamic Component Relationships Rule sets are used by all the high-order components (secure application roles, realms, and command rules) and can also reference factors. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Using Rule Sets Authorize access to objects in Allow enabling of
Secure application roles Realms Rule sets Define execution criteria for Allow setting of Command rules Factors Using Rule Sets You can use rule sets to do the following: As a further restriction to realm authorization, define the conditions under which a realm authorization is active. Define when to allow a command rule. Enable a secure application role. Define under what circumstances to allow the setting of the identity of a factor. When you create a rule set, Database Vault makes it available for selection when you configure the authorization for a realm, factor, command rule, or secure application role. Rule sets are the primary means by which caveats are implemented to ensure that database administrators (DBAs) can still perform their duties. How rule sets are used with realms and factors is covered in detail later in this lesson. Using rule sets with command rules and secure application roles is covered in the lessons titled “Configuring Command Rules” and “Configuring Secure Application Roles,” respectively. Oracle Database 10g: Implementing Database Vault

Rule Sets Rule Sets Rule sets are highly configurable. You manage them by using Database Vault Administrator (DVA). On the Administration tabbed page, click Rule Sets. You see the existing rule sets displayed, and you can either edit or delete any of them. Oracle recommends that you do not edit or delete any of the rule sets that are delivered with Database Vault. Oracle Database 10g: Implementing Database Vault

Creating a Rule Set Create a rule set by doing the following: Click Create on the Rule Sets page in DVA. Provide the following: Name Description Status Evaluation Options Audit Options Error Handling Options Click OK to save the rule set. Edit the rule set to create and add rules. Creating a Rule Set You can create a rule set by using PL/SQL functions, which are covered later in this lesson, or by using DVA. On the rule sets page, click Create. Supply a name and description. Make the name meaningful enough so that it can easily be identified and applied to other components of Database Vault. Set the status to enabled or disabled, and choose the evaluation option. You can then save the rule set, and proceed to edit it in order to add rules to it. Oracle Database 10g: Implementing Database Vault

Creating a Rule Set Creating a Rule Set (continued) For Evaluation Options, a value of All True means that all the rules listed in the rule set must be true in order for the rule set to evaluate to TRUE. A value of Any True means that as long as any one of the rules evaluates to TRUE, the entire rule set is considered to be TRUE. Two rules are shown for the rule set in the slide. In this example, they both must be TRUE. Oracle Database 10g: Implementing Database Vault

Adding Existing Rules to a Rule Set
A rule set consists of one or more rules. So in the process of editing a rule set, you can add new or existing rules to it. If you already have a rule defined that you would like to include in a rule set, click Add Existing Rules. On the Add Existing Rules page, you can move one or more of the the available rules from the left to the right, making them part of the rule set. Oracle Database 10g: Implementing Database Vault

Creating a Rule Creating a Rule Click Create to create a new rule for the rule set. Then, on the Create Rule page, you can enter the name of the rule and the expression that should be evaluated. This expression can be any expression that appears in a WHERE clause. It evaluates to either TRUE or FALSE. After it is created, a rule is available to be added to other rule sets also. Note: An effective way to test an expression is to put it in the WHERE clause of this SELECT statement: SELECT 1 FROM DUAL WHERE <expression> If the value 1 is returned, then the expression is TRUE. If no value is returned, the expression is FALSE. If you receive an error, then the expression has an error in it. Oracle Database 10g: Implementing Database Vault

Reusing Rules Rule set A Rule set B Rule 1 Rule 2 Rule 3 Reusing Rules When you create a rule to be used in a rule set, that new rule is available to be used in other rule sets. There is no limit to how many rule sets a given rule can belong to. Oracle Database 10g: Implementing Database Vault

Auditing Rule Sets AUDIT_TRAIL$ … RULE_SET_NAME RULE_NAME Issue a command that violates Database Vault security: 1 SQL> CREATE TABLE hr.x2 (a INT); Query the audit table: 2 SQL> SELECT username, action_command, rule_set_name, rule_name 2> FROM dvsys.audit_trail$; View the resulting audit record: 3 Auditing Rule Sets Although the Database Vault functionality provides for auditing of successful and unsuccessful activities, there are specific columns defined for rule sets in the audit trail. These are RULE_SET_NAME and RULE_NAME. Consider the the case of Audit on Failure, for example. If a rule set is evaluated to FALSE, then an audit record is written which includes the rule set that failed along with the specific rule name that caused the failure. USERN ACTION_COMMAND RULE_SET_NAME RULE_NAME SYS create table hr.x2 (a int) Work Hours APPS Weekday Daytime Oracle Database 10g: Implementing Database Vault

Setting a Custom Event Handler
CREATE OR REPLACE PROCEDURE notify_security_mgr (p_ruleset VARCHAR2,p_result VARCHAR2) IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN … Required Setting a Custom Event Handler You can set a procedure to be called when a rule set is evaluated. It can be set to either execute on failure or execute every time the rule set is evaluated (on success or failure). In this example, when the rule set fails, the APPS.NOTIFY_SECURITY_MGR procedure is called. Oracle Database 10g: Implementing Database Vault

Using Rule Sets with Realms
A realm’s authorization rule set requires the rules to be satisfied for access to the realm-protected objects. Using Rule Sets with Realms A rule set can be used to provide an extra check on whether a user can access realm-protected objects. When you add an authorization to a realm, you can specify an authorization rule set. This rule set must be satisfied in order for access to the realm-protected objects to be allowed. In this example, the HR user is a participant in the realm, which means the HR user can access the protected objects. But the addition of the rule means it must also resolve to a true condition for access to be granted. This particular rule, called “Weekday,” requires that the current day on the database server be a weekday. So, the HR user can access these objects only on weekdays. Oracle Database 10g: Implementing Database Vault

Assignment Rule Sets for Factors
SQL> EXEC dvsys.set_factor('DOMAIN','LOCAL'); TRUE Set the factor value Factor has rule set? Yes Rule set violation No FALSE ORA-47391: Attempt to set Factor DOMAIN violates Rule Set Disabled Rule set Factor cannot be set Assignment Rule Sets for Factors When you set an assignment rule set for a factor, it allows the factor to be set with a call to the DVSYS.SET_FACTOR procedure. Without an assignment rule set, a factor cannot be set, and, thus, the only way that it has a value is through its evaluation method. If there is no assignment rule set for the factor, then you cannot call DVSYS.SET_FACTOR to set its value. If it has an assignment rule set, then that rule set is evaluated when DVSYS.SET_FACTOR is called; if it evaluates to TRUE, then the factor is set as requested, otherwise, it is not set. You may want to do this for the case where the evaluation of the factor cannot take into account certain aspects of the connection coming to the database. For example, an application server may authenticate a user, and then pool connections into a different database account. The application server may need to establish database privileges on behalf of the end user. This can be done by calling DVSYS.SET_FACTOR to force a factor to have a particular identity in order to provide for certain privileges. ORA-47392: Factor DOMAIN is not settable. Oracle Database 10g: Implementing Database Vault

Creating a Rule Set: Example
A scenario for a rule set: There are specific users who need to log in from remote computers to run reports. The username can vary, because different people do this, but the connections always come from the same set of client machines. The users have been granted the REPORTS database role. Create a rule set to be used in setting the Domain factor to LOCAL, providing the needed reporting privileges. Creating a Rule Set: Example Consider the situation where, normally, all logins are local; they originate from the database server. But now you need to allow a specific group of people to perform certain functions on connections coming from machines other than the database server. You need to create a rule set that ensures that, for this specific activity, the connections are coming from a specific set of machines, and the users have been granted a role called REPORTS. Suppose that the allowed machines are RMT001, RMT005, and RMT006. Oracle Database 10g: Implementing Database Vault

Creating a Rule Set: Example
Creating a Rule Set: Example (continued) In the General section of the Create Rule Set page, you name the rule set and give it a description. Set the status to Enabled. Leave Evaluation Options set to the default All True for now; after you define the rules for the rule set, you can revisit this and make sure that it is correct. The audit and error handling options are not shown here. You leave those with the default settings of auditing on failure, showing the default error message, and not having a customer error handling procedure. Oracle Database 10g: Implementing Database Vault

Editing the New Rule Set: Example
After you have created the rule set, you need to edit it in order to add the rules to it. To do this, click the Rule Sets link on the Administration tabbed page, select the rule set that you just created, and click Edit. Oracle Database 10g: Implementing Database Vault

Adding Rules to the New Rule Set: Example
You need to create a new rule to provide the check on the machine name, because none exists for this. So, instead of clicking the Add Existing Rules button, you need to click Create to create that rule. The Create Rule page appears, where you name the rule and provide the expression that is to be evaluated. You check on the machine name by using the Machine factor, which is delivered with Database Vault. To ensure that there are no case mismatches, you should convert strings like this to uppercase or lowercase in comparison expressions. The following expression evaluates whether the connection’s machine name is in the list of approved remote client machines: upper(dvf.f$machine) in ('RMT001','RMT005','RMT006') Oracle Database 10g: Implementing Database Vault

Adding Rules to the New Rule Set: Example
Adding Rules to the New Rule Set: Example (continued) You have to add a second rule to complete this rule set. This second rule evaluates whether the logged-in user has the REPORTS role. If the user has the role, then the rule is TRUE. Use the expression: dvsys.dbms_macutl.user_has_role_varchar ('REPORTS',USER) = 'Y' The expression checks on the user to ensure that it has been granted the REPORTS role. Oracle Database 10g: Implementing Database Vault

Verifying the Rule Set Logic: Example
Now that you have created the two rules, review the definition of the entire rule set. When a rule set has multiple rules associated with it, verify Evaluation Options. Initially, it was set to All True. This means that both of these rules must evaluate to TRUE for the rule set to be true. That is indeed the desired result with this example, because the machine must be in the privileged list, and the user must have the REPORTS role. So, the rule set is complete. Note that there is no way to apply precedence to the rules that are evaluated as part of a rule set. You may be tempted, for flexibility, to implement the machine list as three separate rules, one for each machine, rather than put them into the same rule. But then you would want to set Evaluation Options to Any True, and that would not give the correct results when you add the Has Reports Role rule; it would essentially be true when either the user has the role or the user is using one of the privileged machines. There is no way to indicate that the machine name checks are ORed together, and the result of that is ANDed with the role check. That is why, for this example, the machine checks are in a single rule. Oracle Database 10g: Implementing Database Vault

Adding the Rule Set to a Factor: Example
The rule set is defined. It does nothing unless it is used to enforce something. One of the objects it can be associated with is a factor. A factor is defined to have specific derived identities, based on the factor evaluation logic and its identities. If a factor has an assignment rule set defined, then the DVSYS.SET_FACTOR procedure can be called to set the factor’s identity for the current session. But, this call succeeds only if the assignment rule set evaluates to TRUE. So, by setting Assignment Rule Set of the Domain identity to the new “Is Remote Report Runner” rule set, users who pass the tests of that rule set are able to set the Domain factor to whatever value they choose. Note: If the factor has a validation method defined, then that may restrict what values the factor can be set to. For more information about validation methods, refer to the lesson titled “Defining Factors.” Oracle Database 10g: Implementing Database Vault

Delivered Rule Sets Delivered Rule Sets The rule sets delivered with Database Vault are: Allow Sessions: The rule set that controls the ability to create a session in the database. This rule set enables you to add rules to control database logins using the CONNECT command rule. The CONNECT command rule is useful when the SYSDBA access needs to be controlled or limited to certain programs that require its use. This rule set is not populated. Can Grant VPD Administration: The rule set that controls the ability to grant EXECUTE privileges on the Oracle VPD DBMS_RLS package Can Maintain Accounts/Profiles: The rule set that controls the roles that can manage user accounts and profiles Can Maintain Own Account: The rule set that controls the roles that can manage user accounts and profiles or your own account Disabled: The convenience rule set to quickly disable system features Enabled: The convenience rule set to quickly enable system features Oracle Database 10g: Implementing Database Vault

Can Maintain Own Account Rule Set
As an example, consider one of the rule sets called Can Maintain Own Account delivered with Database Vault. It ensures that the user either has the DV_ACCTMGR role or is performing an operation on its own account. In the lesson titled “Configuring Command Rules,” you see how this rule is used to prevent a user from performing the ALTER USER command on accounts other than its own, even if otherwise system privileged. True if either the user has the DV_ACCTMGR role or the user is maintaining their own account Oracle Database 10g: Implementing Database Vault

Enabled and Disabled Rule Sets
Enabled rule set: Disabled rule set: Enabled and Disabled Rule Sets Two other delivered rule sets are very simple yet very useful. They provide for a quick way to achieve an always-true or always-false rule set result. The always-true rule set is called Enabled. Its single rule has the expression “1 = 1,” which is, of course, always true. The always-false rule set is called Disabled. Its single rule has the expression “1 = 0,” which is, of course, always false. These rule sets can be used to react quickly to an emergency security situation where something has to be protected or opened up immediately. Oracle Database 10g: Implementing Database Vault

Rule Set Views DBA_DV_RULE_SET RULE_SET_NAME DESCRIPTION ENABLED EVAL_OPTIONS_MEANING AUDIT_OPTIONS FAIL_OPTIONS_MEANING FAIL_MESSAGE FAIL_CODE HANDLER_OPTIONS HANDLER Example of Query: Output: DBA_DV_RULE_SET_RULE RULE_SET_NAME RULE_NAME RULE_EXPR ENABLED RULE_ORDER DBA_DV_RULE NAME RULE_EXPR SELECT rs.rule_set_name, rs.enabled, rsr.rule_name, rsr.rule_expr, rsr.rule_order FROM dvsys.dba_dv_rule_set rs, dvsys.dba_dv_rule_set_rule rsr WHERE rs.rule_set_name = rsr.rule_set_name RULE_SET_NAME ENABLED RULE_NAME RULE_EXPR Can Maintain Own Account Y Is User Manager DVSYS.DBMS_MACUTL.USER_HAS_... Disabled Y False =0 Enabled Y True =1 Rule Set Views The following views, in the DVSYS schema, contain information about rule sets and rules: DBA_DV_RULE_SET: One row per rule set DBA_DV_RULE: One row per rule DBA_DV_RULE_SET_RULE: Associates a rule to a rule set These views are useful for seeing, either programmatically or as an ad hoc query, information about existing rule sets in the database. All the information viewable in Database Vault Administrator is also available here. DBA_DV_RULE_SET is the parent table, and contains information specific to the rule set definition itself, but nothing about the rules contained in it. DBA_DV_RULE contains information about each of the rules. DBA_DV_RULE_SET_RULE is the intersection table; it associates a rule to a rule set. For convenience, this view contains all the information that is also in the DBA_DV_RULE view, so there is no need to join it to the DBA_DV_RULE view. You can run meaningful queries on these views by joining the rule set name, as shown in the example in the slide. Oracle Database 10g: Implementing Database Vault

Rule Set Reporting: Configuration Issues
Are the rules being enforced? Rule Set Configuration Issues The Rule Set Configuration Issues report displays Database Vault rule set information where no rules are defined or enabled for a rule set. Oracle Database 10g: Implementing Database Vault

Rule Set API You can do the following with rule sets: Create a rule set Update a rule set Rename rule set Delete a rule set You can do the following with rules: Create a rule Update a rule Rename a rule Delete a rule Add a rule to a rule set Delete a rule from a rule set Rule Set API The rule set API enables you to do anything that DVA can do with rule sets, including some things that cannot be done in DVA. Here are some of the procedures you can call to manipulate rules and rule sets: CREATE_RULE(rule_name, rule_expr) CREATE_RULE_SET(rule_set_name,description, enabled, eval_options, audit_options, fail_options, fail_message, fail_code, handler_options, handler) ADD_RULE_TO_RULE_SET(rule_set_name, rule_name) DELETE_RULE_FROM_RULE_SET(rule_set_name, rule_name) DELETE_RULE(rule_name) RENAME_RULE(rule_name, new_name) RENAME_RULE_SET(rule_set_name, new_name) Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Describe how rule sets are referenced by other Database Vault components Create, modify, and delete a rule set Create rules and add them to a rule set View the rule set violation details of an audit record View the rule set configuration issues report using DVA Oracle Database 10g: Implementing Database Vault

Configuring Command Rules

Objectives After completing this lesson, you should be able to do the following: Identify the components of a command rule Apply command rules to restrict command execution Access the views containing command rule information Call PL/SQL functions to create, update, and delete command rules Oracle Database 10g: Implementing Database Vault

Command Rules: Concepts
Command type To perform this command Object On this object Owner Which is owned by this user Rule set This rule set must evaluate to TRUE. Command rule Command Rules: Concepts A command rule defines the rules that must be followed to perform a command on an object. These commands include most data definition language (DDL) commands and also SELECT, INSERT, UPDATE, and DELETE. You can implement a command rule to restrict specific commands to specific objects or groups of objects. The restriction is based on the evaluation of a rule set. If the rule set is TRUE, then the command is allowed. If it is FALSE, then the command is not allowed. A command rule cannot allow additional access that is not already allowed for a user; it only serves to restrict access for specific commands. Oracle Database 10g: Implementing Database Vault

Command Rules: Static Component Context
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Command Rules: Static Component Context The relationship between Oracle Database Vault components is shown in the slide. Command rules use rule sets to define their behavior. Oracle Database 10g: Implementing Database Vault

Command Rules: Dynamic Component Relationships
Secure application role Identity Realm Factor Command rule Rule set Command Rules: Dynamic Component Relationships Command rules are checked and evaluated as a SQL statement is processed. Its referenced rule set is evaluated, which determines whether the statement is allowed to execute or not. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Command Rules Page Command Rules Page Navigate to the Command Rules page by clicking the Command Rules link on the Administration page of Database Vault Administrator (DVA). On that page, you see a summary of all existing command rules. Oracle Database 10g: Implementing Database Vault

Command Rule Attributes
If this is Enabled To perform this command On this object Which is owned by this user Command Rule Attributes A command rule is made up of the following attributes: Command: This is the command that is being protected against. This includes: Most DDL (CREATE, ALTER, DROP, TRUNCATE) ALTER SYSTEM EXECUTE SELECT, INSERT, UPDATE, DELETE Status: Indicates whether the command rule is currently in effect or not. To disable the effects of a command rule, set this to Disabled. Object Owner: The owner of the object or objects that this rule applies to. This is not applicable in some cases, such with the FLASHBACK DATABASE command. Object Name: This is a pattern string representing the object or objects within the Object Owner schema that are being protected. This can be the name of a single object, or it can contain wildcard characters. Any objects matching the wildcard string are protected. Rule Set: The name of the rule set that protects these objects from this command. If the rule set evaluates to TRUE at the time of the command attempt, the command succeeds. Otherwise, a rule set violation error is returned. This rule set must evaluate to TRUE. Oracle Database 10g: Implementing Database Vault

Identifying a Command Rule
Unique identifier Identifying a Command Rule Command rules do not have a name. They are known by the unique combination of a command, object owner, and object name. Therefore, you cannot create a command rule that has those three values matching an existing command rule. Oracle Database 10g: Implementing Database Vault

Command Rule: Example 1 The OE user logs in and alters the OE.ORDERS table: SQL> ALTER TABLE oe.orders ADD (my_code VARCHAR2(10)); Table altered. 2 The OE_ORDERS_DBA user notices this new column and wonders why he was not consulted. 3 OE_ORDERS_DBA has a role created and granted to only himself: Command Rule: Example In this example, there is a user who is normally privileged to alter a table. But, administratively, that user should not do that. There is a user who is specifically assigned those duties. The steps for the example follow: 1. The OE user alters the OE.ORDERS table by adding a column. This user is allowed to do this, because it is the owner of the schema. But in this particular organization, duties have been assigned such that a different user is in charge of any tables related to orders. 2. The user with database design duties for the orders tables is OE_ORDERS_DBA. He keeps a watch on his table design, making sure no one else is changing it. He notices that there is a new column added, and decides that he needs something enforced at the database level. 3. The orders table administrator asks for a role to be created and granted only to himself. SQL> CREATE ROLE ORDER_APP_DBA; SQL> GRANT order_app_dba TO OE_ORDERS_DBA; Oracle Database 10g: Implementing Database Vault

Command Rule: Example Use Database Vault Administrator to create a command rule to prevent altering of OE order-related tables. 4 The user must have the ORDER_APP_DBA role. The OE_Order_Designer rule set: Command Rule: Example (continued) The Database Vault Owner user uses Database Vault Administrator to create a command rule that protects the ALTER TABLE command from being executed on any tables in the OE schema that begin with the string ORDER. This includes the ORDERS and ORDER_ITEMS tables. In the process, a rule set called OE_Order_Designer is created. It has a single rule: isOrderAppDBA. That rule’s expression ensures that the requesting user has the ORDER_APP_DBA role, which is created in step 3. Oracle Database 10g: Implementing Database Vault

Command Rule: Example 5 Now when OE attempts to alter an orders-related table, there is a violation: SQL> ALTER TABLE oe.orders ADD (my_code NUMBER); ORA-47400: Command Rule Violation for alter table on OE.ORDERS 6 Even when OE attempts to alter a different orders-related table, there is a violation: SQL> ALTER TABLE oe.order_items ADD (my_code NUMBER); ORA-47400: Command Rule Violation for alter table on OE.ORDER_ITEMS Command Rule: Example (continued) After OE_ORDERS_DBA removes the new column from the ORDERS table, again the OE user attempts to add the column back. But this time, there is a command rule violation for “alter table on OE.ORDERS.” The OE user is not able to alter this table. The OE user moves on to attempt to add this new column to the ORDER_ITEMS table. Again, there is a command rule violation. The wildcard caused this command rule to be applied to both the ORDERS and ORDER_ITEMS tables. Oracle Database 10g: Implementing Database Vault

Disallowing All Users from ALTER TABLE in a Schema: Example
A common compliance requirement is to prevent any user from adding columns to a table. The command rule shown does that for all tables in the OE schema. The object name is set to the % wildcard, meaning that all tables in OE are protected. And, Rule Set is set to Disabled, indicating that the Disabled rule set must be satisfied in order for the alter table statement to proceed. The Disabled rule set, which is delivered with Database Vault, contains a single rule called False, which has the expression 1=0. Of course, that is never true, so the command rule in the slide always prohibits altering any OE tables. Oracle Database 10g: Implementing Database Vault

Delivered Command Rules
ALTER PROFILE GRANT on SYS.DBMS_RLS CREATE PROFILE REVOKE on SYS.DBMS_RLS CREATE USER DVO user DVSYS user DROP PROFILE DROP USER ALTER USER DVSYS user Database Vault Account Manager DVO user DVSYS user The user being altered Delivered Command Rules There are eight command rules delivered with the Database Vault installation: Account management–related command rules: These command rules require that the user is either the Database Vault Account Manager or the DVSYS user. Those users are the only ones allowed to deal with accounts and profiles. The protected commands are: ALTER PROFILE CREATE PROFILE CREATE USER DROP PROFILE DROP USER Rules for handling permissions to deal with Fine-Grained Access Control (FGAC): These two command rules essentially restrict who can use the FGAC administrative interface. Only these two users are permitted to do this: DVO DVSYS Oracle Database 10g: Implementing Database Vault

Delivered Command Rules (continued) Alter user privileges: This defines the list of users who can do such things as change a user’s password, profile, lock status, default tablespace, and so on. Only the following three users can do this: DVO DVSYS The user being altered (meaning that a user can alter itself) Oracle Database 10g: Implementing Database Vault

DBA_DV_COMMAND_RULE View
RULE_SET_NAME OBJECT_OWNER OBJECT_NAME ENABLED PRIVILEGE_SCOPE DBA_DV_COMMAND_RULE View The DBA_DV_COMMAND_RULE view contains information about all the Database Vault command rules in the database. Its columns map directly to the fields on the Create Command Rule page, except for the PRIVILEGE_SCOPE column, which is an unused column. Oracle Database 10g: Implementing Database Vault

Command Rule Report You can report on any incorrectly configured command rules. Command Rule Report You can report on any command rules that have ineffective rule sets attached to them. For example, in this slide, the rule set contains a single rule that is always false. Even though it is not the delivered “Disabled” rule set name, the reporting tool evaluated it and listed it as a possible misconfiguration. Oracle Database 10g: Implementing Database Vault

Command Rule API The command rule API provides functions that enable you to: Create a command rule Update a command rule Delete a command rule SQL> exec DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE 2 ('DROP TABLE','Am HR User','HR','%','N'); SQL> exec DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE 2 ('DROP TABLE','Am HR User','HR','%','Y'); SQL> exec DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE 2 ('DROP TABLE','HR','%'); Command Rule API The three functions for dealing with command rules are listed as follows. They are all in the DVSYS schema and are part of the DBMS_MACADM package. So, they must be qualified with DVSYS.DBMS_MACADM. To create a command rule, use: CREATE_COMMAND_RULE (command VARCHAR2, rule_set_name VARCHAR2, object_owner VARCHAR2, object_name VARCHAR2, enabled VARCHAR2) To update a command rule, identified by the combination of command, object_owner, and object_name, use the following. All parameters are required, even if their values are not to be changed from their current value: UPDATE_COMMAND_RULE (command VARCHAR2, rule_set_name VARCHAR2, object_owner VARCHAR2, object_name VARCHAR2, enabled VARCHAR2) To delete a command rule, use: DELETE_COMMAND_RULE (command VARCHAR2, object_owner VARCHAR2, object_name VARCHAR2) Note: You must issue a COMMIT statement after calling each of these for the changes to take effect. Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Identify the components of a command rule Apply command rules to restrict command execution Access the views containing command rule information Call PL/SQL functions to create, update, and delete command rules Oracle Database 10g: Implementing Database Vault

Practice 7 Overview: Managing Command Rules
This practice covers creating a command rule to prevent altering of a table. Oracle Database 10g: Implementing Database Vault

Configuring Secure Application Roles

Objectives After completing this lesson, you should be able to do the following: Create secure application roles Edit secure application roles Enforce application security by enabling secure application roles Oracle Database 10g: Implementing Database Vault

Secure Application Roles: Static Component Context
Realm Command rule Secure application role Uses Uses Uses Rule set Factor Identity Secure Application Roles: Static Component Context The relationship between Oracle Database Vault components is shown in the slide. Secure application roles use rule sets to define their behavior. Oracle Database 10g: Implementing Database Vault

Secure Application Roles: Dynamic Component Relationships
Identity Realm Factor Command rule Rule set Secure Application Roles: Dynamic Component Relationships Secure application roles are evaluated when a role is requested to be set. The referenced rule set is evaluated, and that drives the decision of whether to allow the role to be set as requested. Optional flow Required flow Oracle Database 10g: Implementing Database Vault

Secure Application Roles: Concepts
A secure application role is a database role that can be enabled by using only a specific PL/SQL procedure. Database Vault Administrator can create secure application roles that are enabled based on the outcome of a Database Vault rule set. Applications can call the Database Vault API to set these roles. The role holds the necessary privileges. Secure Application Roles: Concepts A secure application role is a database role that can be enabled only by using a specific, declared PL/SQL procedure. This procedure is usually written by an application developer. In Database Vault, the procedure is implemented by the Database Vault packages. Database Vault changes the implementation of secure application roles to ease their administration, development, and use. Through Database Vault Administrator (DVA), you can create secure application roles that are enabled based on the outcome of a rule set. For example, the application can set the role if the associated rule set evaluates to TRUE. If the associated rule set evaluates to FALSE, then do not allow the role to be set. The secure application role is designed to be enabled from an application. In Database Vault, any application or user can execute the SET_ROLE function from the API. Database Vault controls the ability to enable the role with an associated rule set. A secure application role can be assigned system and object privileges just as any other role. In Database Vault, the role is created through the DVA tool. The system privileges must be assigned by a user with the DBA role, and object privileges are assigned for realm objects by a user with the DV_REALM_OWNER role for the specific realm. Oracle Database 10g: Implementing Database Vault

Secure Application Role
Without role enabled Enable role Secure Application Role The secure application role provides a way to grant privileges to users only when certain conditions are met. These conditions can be as simple as when connected through a named application, or as complex as privileges that are dependent on the user’s job role and client’s IP address. The user or the application can call the SET_ROLE function. If the rule set returns TRUE, the the role is enabled for the user. After the role is enabled, it remains enabled for the duration of the session. Do not use factors evaluated By Access for secure application roles if you intend for the role to be disabled when the factor changes. If the rule set is TRUE when the SET_ROLE function is called, the role is enabled. The role remains enabled even if the factor changes so that the rule set is FALSE. Oracle Database 10g: Implementing Database Vault

Using a Secure Application Role
A user connects to an application. The application validates the user. The application sets role. Using a Secure Application Role The secure application role is a secure method for allowing the user to be authorized only when the role is enabled. Before the secure application role was introduced in Oracle9i Database, a role could be protected by a password. This role could be enabled from an application with a password, but it required that the password be embedded in the application code. With Oracle9i Database, a secure application role could be enabled by using a secure PL/SQL package. Database Vault allows the security administrator to create a secure application role that is validated by a rule set. In all the versions, the same general procedure is followed in the application. Oracle Database 10g: Implementing Database Vault

Secure Application Role Changes in Database Vault
Do not write an enabling procedure. Do not grant the role to users. Do not use DBMS_SESSION.SET_ROLE. Create the role by using Database Vault Administrator. Use a rule set to control the enabling of the role. Use DVSYS.DBMS_MACSEC_ROLES.SET_ROLE to set the role. Secure Application Role Changes in Database Vault As in previous releases, a secure application role is enabled by a procedure in a secure package. With Database Vault, that procedure is provided, so you do not have to write it. Instead of writing a procedure, the security administrator uses a rule set to determine whether an application role should be enabled. The role is automatically created by the DVA tool and can be seen in the DBA_APPLICATION_ROLES view. The package that secures this role is listed in this view as DVSYS.DBMS_MACSEC_ROLES. Instead of granting EXECUTE on the DBMS_SESSION.SET_ROLE procedure to the application account, and calling the procedure from the application, call the publicly executable DVSYS.DBMS_MACSEC_ROLES.SET_ROLE procedure to set the role. Oracle Database 10g: Implementing Database Vault

Creating a Rule Set Create a rule set to control enabling the role. Creating a Rule Set In this example, create a rule set that returns TRUE when the session originates from the local subnet. Oracle Database 10g: Implementing Database Vault

Creating Rules Create rules that enforce the object of the rule set. Creating Rules For this example, only one rule is needed. Name the rule Local_subnet, and give it this rule expression: DVF.F$CLIENT_IP LIKE ‘ %’. Oracle Database 10g: Implementing Database Vault

Creating Secure Application Roles
Create a role that uses a named rule set. Creating Secure Application Roles Navigate to the Create Role page by selecting Create on the Secure Application Roles page. Give the role a name. Then, assign a rule set to control the role. You can choose only from already created rule sets. Oracle Database 10g: Implementing Database Vault

Deleting Secure Application Roles
You can delete a secure application role as follows: 1. Navigate to the Secure Application Roles page. 2. Select the role. 3. Click Remove. Oracle Database 10g: Implementing Database Vault

Examples The SET_ROLE function fails on a rule set violation. SQL> exec DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_EMP_CLERK'); BEGIN DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_EMP_CLERK'); END; * ERROR at line 1: ORA-47305: Rule Set Violation on SET ROLE (ALLOW_LOCAL_SUBNET_ACCESS) Examples The configuration for this example is as follows: Connect as user DVAM with the DV_ACCTMGR role, and user HR which is an owner in a realm protecting the HR schema. SQL> connect HR/HR Connected. SQL> grant select on hr.employees to hr_emp_clerk; Grant succeeded. Attempt to enable the role from a machine that is not on the local subnet: SQL> connect SQL> select * from hr.employees; select * from hr.employees * ERROR at line 1: ORA-01031: insufficient privileges Oracle Database 10g: Implementing Database Vault

Examples (continued) SQL> exec DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_EMP_CLERK'); BEGIN DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_EMP_CLERK'); END; * ERROR at line 1: ORA-47305: Rule Set Violation on SET ROLE (ALLOW_LOCAL_SUBNET_ACCESS) ORA-06512: at "DVSYS.DBMS_MACUTL", line 37 ORA-06512: at "DVSYS.DBMS_MACUTL", line 359 ORA-06512: at "DVSYS.DBMS_MACSEC", line 215 ORA-06512: at "DVSYS.ROLE_IS_ENABLED", line 4 ORA-06512: at "DVSYS.DBMS_MACSEC_ROLES", line 19 ORA-06512: at line 1 SQL> select dvf.F$Client_IP from DUAL; F$CLIENT_IP SQL> select * from hr.employees 2 where employee_id = 107; select * from hr.employees ORA-01031: insufficient privileges Attempt to enable the role from a machine that is on the local subnet: SQL> connect Connected. SQL> select dvf.f$client_ip from dual; PL/SQL procedure successfully completed. SQL> select first_name, Last_name, , salary 2 from hr.employees 3 where employee_id = 107; FIRST_NAME LAST_NAME SALARY Diana Lorentz DLORENTZ 4,200.00 Oracle Database 10g: Implementing Database Vault

Secure Application Role Views
RULE_NAME ENABLED DBA_DV_ROLE Secure Application Role Views The following view, in the DVSYS schema, contains secure application role–related information: DBA_DV_ROLE: An Oracle database secure application role used in privilege management. This view holds the rule set name associated with the role, and the status. Oracle Database 10g: Implementing Database Vault

Secure Application Configuration Issues
Are the secure roles functioning? Secure Application Configuration Issues This report displays Database Vault secure application role information where the following configuration issues exist: Database role does not exist. Rule set for role is disabled. Rule set for a role is incomplete. Oracle Database 10g: Implementing Database Vault

Secure Application Role Audit
View the audit that lists attempts to enable a secure application role. Secure Application Role Audit The Secure Application Role Audit report shows the audit records generated when a secure application role is enabled by Database Vault. You create rule sets to control the conditions required to enable a secure application role. There is no setting for audit options for a secure application role. The audit is based on the rule set audit options. Oracle Database 10g: Implementing Database Vault

Secure Application Roles API
The administration API DVSYS.DBMS_MACADM package contains: CREATE_ROLE DELETE_ROLE RENAME_ROLE UPDATE_ROLE The run-time API for applications is the DVSYS.DBMS_MACSEC_ROLES package, which contains: CAN_SET_ROLE(‘<role>’): Returns BOOLEAN SET_ROLE(‘<role>’) Secure Application Roles API An administration API is provided with the DVSYS.DBMS_MACADM package as an alternative to using DVA. The following functions are provided: CREATE_ROLE:Creates a Database Vault secure application role DELETE_ROLE:Deletes a Database Vault secure application role RENAME_ROLE:Renames a Database Vault secure application role. The name change takes effect everywhere the role is used. UPDATE_ROLE:Updates a Database Vault secure application role The run-time API for use by applications is provided in the separate package to provide better security. The DVSYS.DBMS_MACSEC_ROLES package provides the following functions: CAN_SET_ROLE(‘<role>’): Checks whether the user invoking the method is authorized to use the specified Database Vault secure application role. Returns a BOOLEAN value SET_ROLE(‘<role>’): Issues the SET ROLE command for a Database Vault secure application role Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Create secure application roles Edit secure application roles Enforce application security by enabling secure application roles Oracle Database 10g: Implementing Database Vault

Practice 8 Overview: Managing Secure Application Roles
This practice covers the following topics: Creating a secure application role Using a secure application role in a PL/SQL application Oracle Database 10g: Implementing Database Vault

Viewing Reports

Objectives After completing this lesson, you should be able to do the following: Review Oracle Database Vault monitoring Produce Database Vault reports Produce general security reports Objectives This lesson intends to help you become familiar with the reports that are available and the use of some of these reports in discovering and diagnosing common problems. Oracle Database 10g: Implementing Database Vault

Required Privileges You must have the DV_ADMIN or DV_SECANALYST role to log in to Database Vault Administrator. A security officer can view reports but not change the Database Vault configuration The administrator can change the Database Vault configuration and view reports. Required Privileges To log in to Database Vault Administrator (DVA), a user must have been granted either the DV_ADMIN or DV_SECANALYST role. To create a security officer account that has privileges to view reports, but does not have rights to change the Database Vault configuration, do the following: 1. The Database Vault Account Manager creates the user: CONNECT DVAM/oracle_10g CREATE USER sec IDENTIFIED BY <password>; GRANT CONNECT TO sec; 2. The Database Vault owner grants the DV_SECANALYST role: CONNECT DVO/oracle_10g GRANT DV_SECANALYST TO sec; Oracle Database 10g: Implementing Database Vault

Reporting Needs Database Vault provides reports to support: Configuration of Database Vault Auditing of Database Vault Review and auditing of security issues: Accounts Passwords Privileges Initialization parameters Other known security issues Reporting Needs In any system that has security requirements, reports are needed to support the evaluation of the security measures that have been implemented. Database Vault provides reports to ease the review and auditing of the security measures that have been implemented. There are two main sets of reports: Database Vault reports and general security reports. The Database Vault reports provide checks on the configuration of Database Vault features and can audit the use and possible abuse of Database Vault features. The general security reports cover a broad spectrum of security concerns and best practices. These reports cover issues such as status of default accounts, use of default passwords, and system and object privileges granted. There are additional reports that cover known security issues. Certain initialization parameters that have historical, compatibility, or diagnostic reasons for being available can have security vulnerabilities in some cases. These parameters are reported, so they can be checked. There are several other known security vulnerabilities that are checked in the Other Security Vulnerabilities report group. The Monitor page depends on information in the audit trails. For the information to be available, the AUDIT_TRAIL initialization parameter must be set to DB: ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE; Oracle Database 10g: Implementing Database Vault

Database Vault Monitor
The DVA tool includes a monitor page. This page gives you a visual representation of the structural change activity. This is a good place to start any security overview. The graph shows a number and category of the changes. Also on the page are three additional views: Security Policy Changes Detail Security Violation Attempts Database Configuration and Structural Changes Oracle Database 10g: Implementing Database Vault

Security Policy Changes Detail
This report shows who performed the security policy changes, when the change occurred, what has been done (the action, object, and return code), and if it has been successful. This report is helpful to quickly detect unauthorized actions, either attempted or successful, that would change the security policies. Oracle Database 10g: Implementing Database Vault

Security Violation Attempts
… … Security Violation Attempts You can check for security violations, finding out data such as the username of the person committing the violation, the action that is committed, and a time stamp of the activity. Besides finding the detailed information about attempts to access unauthorized objects, this is useful for verifying proper configuration of the Database Vault objects and the integration with Oracle Label Security (OLS). Oracle Database 10g: Implementing Database Vault

Database Configuration and Structural Changes
You can view structural changes to the database or database schema objects. This feature also audits commands such as CREATE TABLE, ALTER TABLE, DROP TABLE, and ALTER DATABASE. It audits all commands, and not just commands that are used in command rules. For example, if someone has unexpectedly altered a table on a production system, you can use this feature to find out what is happening. Oracle Database 10g: Implementing Database Vault

Database Vault Reports
Database Vault provides groups of reports: Database Vault configuration issue reports Database Vault audit reports Database Vault Reports Database Vault includes a large number of reports that display security-related information from the database. Reports also show custom Database Vault audit event information. The reports are in two groups: Database Vault configuration issue reports: These reports enable you to check configuration issues with realms, command rules, factors, factor identities, rule sets, and secure application roles. You can fix most of the issues shown by the Database Vault reports through DVA. Database Vault audit reports: These reports show the audit records collected by the level of auditing specified in the DVA tool. Oracle Database 10g: Implementing Database Vault

Database Vault Reports
Database Vault Reports (continued) To navigate to the Database Vault reports from the DVA home page, click Database Vault Reports on the upper tab bar. Oracle Database 10g: Implementing Database Vault

Database Vault Configuration Issues Reports
Command Rule Configuration Issues report Factor Configuration Issues report Factor Without Identities report Identity Configuration Issues report Realm Authorization Configuration Issues report Rule Set Configuration Issues report Secure Application Configuration Issues report Database Vault Configuration Issues Reports The reports available from this group point out some of the common configuration issues. Each of the items in these reports can be related to a configuration issue that might leave a security hole in your system. Many may be related to simply a default configuration for a rule, factor or role that is not being used, which, consequently, are harmless. Command Rule Configuration Issues report shows the following issues: Rule set for the command rule is disabled Rule set for the command rule is incomplete Object owner for the command rule does not exist Factor Configuration Issues report displays the following issues: Rule set for a factor assignment is disabled Rule set for a factor assignment is incomplete Audit options for a factor are invalid No factor retrieval method or constant exists No mapped factors are linked to an identity factor No mapped factors are linked to a label factor Oracle Label Security (OLS) policy does not exist for the factor Oracle Database 10g: Implementing Database Vault

Database Vault Configuration Issues Reports (continued) Factor Without Identities report displays Database Vault factors that have no identities defined in the access control configuration. For some factors such as Background_Job_Id, this may not be a real problem, but the report is useful in determining whether your access control configuration is complete and whether you have accounted for all factor configurations. Identity Configuration Issues report shows identities where the OLS label does not exist for the identity (the label has been removed) or where there is no map for the identity. Realm Authorization Configuration Issues report displays Database Vault realm information where the following configuration issues exist: Disabled rule set for a realm authorization Grantee does not exist for a realm authorization Incomplete rule set for a realm authorization Owner does not exist for a realm-secured object Rule Set Configuration Issues report displays Database Vault rule set information where no rules are defined or enabled for a rule set. Secure Application Configuration Issues report displays Database Vault secure application role information where the following configuration issues exist: Database role does not exist Disabled rule set for role Incomplete rule set for role Notes Only Oracle Database 10g: Implementing Database Vault

Review the Database Vault Configuration
Recommendations: Completely configure all items that are being used. Provide a retrieval method or constant for all factors. Identify all identities of all factors. Configure mapped factors for identity factors. Configure validation methods or rule sets for factors set with SET_FACTOR. Configure rule sets completely. Configure rule sets for realms and secure application roles. Review the Database Vault Configuration The Database Vault configuration reports show where the configuration recommendations are not being followed. Incomplete configuration yields incomplete security. There are times when the reports may show items as incompletely configured, which may be unavoidable. This leads you to follow other best practices: Create a repository rule set. This rule set is not used, except as a container for rules that are in development. These rules can be kept, and not be part of any active rule set. Remove factors that are not being used, including predefined factors. Factors that are not being used can take additional unnecessary auditing effort. Oracle Database 10g: Implementing Database Vault

Database Vault Auditing Reports
Realm Audit report Command Rule Audit report Factor Audit report Label Security Integration Audit report Core Database Vault Audit Trail report Secure Application Role Audit report Database Vault Auditing Reports In general, audit reports are required to monitor authorized actions and attempted unauthorized actions. They are also useful for troubleshooting configuration problems. Realm Audit report: Shows audit records generated by the realm protection and realm authorization operations. A rule set performs realm authorization. This report displays the audit of the rule set processing results. This is helpful in troubleshooting rule sets and monitoring failed authorization attempts. Realm violations are also displayed in this report. A database account attempts to perform an action on a realm object that it is not authorized to perform that action in the realm. When you configure a realm, you set the audit options for the realm operations. Command Rule Audit report: The Command Rule Audit report shows audit records generated by command rule processing operations. Command rules allow or disallow SQL commands on the basis of rule sets. When you configure a command rule, you can set it to audit the rule set processing results. Oracle Database 10g: Implementing Database Vault

Database Vault Auditing Reports (continued) Factor Audit report: The Factor Audit report shows audit records generated as a result of factor evaluation and factor assignment operations. You can audit instances where a factor’s identity cannot be resolved and assigned (such as “no data found” or “too many rows”). A factor can have an associated rule set that assigns an identity to the factor at run time. When you configure a factor, you can set it to audit the rule set processing results. Label Security Integration Audit report: The Label Security Integration Audit report shows audit records having to do with these label security integration operations: the session initialization operation and the session label assignment operation. You can audit instances where the label security session fails to initialize, and where the label security component prevents a session from setting a label that exceeds the maximum session label. Core Database Vault Audit Trail report: Not currently populated Secure Application Role Audit report: The Secure Application Role Audit report shows the audit records generated by the secure application role enabling operation. You can set secure application roles based on rule sets. Notes Only Oracle Database 10g: Implementing Database Vault

Reviewing Database Vault Audit Reports
A regular review of audit reports provides early detection of: Attempts against realm protections Violation of separation of duties Invalid use of factors by applications Configuration problems Reviewing Database Vault Audit Reports Audit records are useless without a regular review. They just take up space. When you review these audit records, you can detect unauthorized activities, if the auditing option have been set to record these activities. Normally, auditing is set for “On Failure” to reduce the number of audit records and prevent performance problems, but certain activities should be audited for both success and failure. Audit the Database Vault realm for failure and success. This will cause auditing of the DV_OWNER modifications of any rule sets, realms, and so on (such as adding oneself or disabling the component). When there is a need to temporarily open up a privilege, use the security manager (DVO) login ID. Open the privilege up, and turn on (more) auditing, and then close it when the database administrator (DBA) has finished the task Turning on auditing for success and failure can be helpful in the diagnosis of configuration problems. Oracle Database 10g: Implementing Database Vault

General Security Reports
General security reports provide groups of security-related reports. General Security Reports These reports enable you to check the status of object privileges, database account system privileges, sensitive objects, privilege management, powerful database accounts and roles, initialization parameters and profiles, account passwords, security audits, and other security vulnerability reports. You are required to use the Oracle Enterprise Manager Database console, SQL*Plus, or a SQL-based command-line tool to correct many of the issues shown by the general security reports. The groups of reports provided are: Object Privilege Reports Database Account System Privileges Reports Sensitive Objects Reports Privilege Management - Summary Reports Powerful Database Accounts and Roles Reports Initialization Parameters and Profiles Reports Database Account Password Reports Security Audit Report Other Security Vulnerability Reports Oracle Database 10g: Implementing Database Vault

Object Privilege Reports
Object Access By PUBLIC report Object Access Not By PUBLIC report Direct Object Privileges report Object Dependencies report Object Privilege Reports These reports provide a way to monitor the source of user privileges and provide information for the design of roles. Direct Object Privileges report: This report shows the direct object privileges granted to nonsystem database accounts. It is provided as a tool to help determine where password-protected roles can be implemented. The following database accounts are excluded from the report: CTXSYS LBACSYS PUBLIC WKSYS DMSYS MDSYS SYS WMSYS DVSYS OLAPSYS SYSMAN EXFSYS ORDSYS SYSTEM Oracle Database 10g: Implementing Database Vault

Object Privileges by PUBLIC
Object Access By PUBLIC report: This report lists all objects granted to PUBLIC. The report details all the object access privileges that the database account has through grants to PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, the object owner, or the object name. This report is useful for tracking the privileges that a particular user has through PUBLIC. Object Access Not By PUBLIC report: This report details all the object privileges that a database account has through direct grants to the account or through a role, but not through PUBLIC. You specify a single database account on the Report parameter page, and you can filter the results based on the privilege, the object owner, or the object name. Oracle Database 10g: Implementing Database Vault

Object Dependencies Object Dependencies This report describes all dependencies in the database between procedures, packages, functions, package bodies, and triggers, including dependencies on views created without any database links. It can help you develop a least privilege security policy for existing applications. If a database object, such as UTL_FILE, has privileges granted to PUBLIC or some other global role, then you can use the Object Dependencies report to determine an account that may depend on the object and to determine how the account uses the object. To run the report, enter the database account that you are inspecting for dependency and the object it may be dependent on, on the Report Parameters page. The Report Results page shows the dependent object and object type, as well as the source object name and type. This report shows where the potentially sensitive object is being used. By looking at several accounts, you might be able to see patterns that can help you develop restricted roles. These restricted roles can replace PUBLIC grants on widely used sensitive objects. Oracle Database 10g: Implementing Database Vault

Database Account System Privileges Reports
Direct System Privileges by Database Account report Direct and Indirect System Privileges by Database Account report Hierarchical System Privileges by Database Account report ANY System Privileges for Database Accounts report Database Account System Privileges Reports Hierarchical System Privileges by Database Account Report: This report displays a hierarchical breakdown of role-based system privileges and direct system privileges granted to the database account specified on the Report Parameters page. ANY System Privileges for Database Accounts Report: This report shows all *ANY* system privileges granted to a database account or role. ANY system privileges are very powerful and should be judiciously assigned to accounts and roles. In general, the *ANY* system privileges should be reserved for database administrators and application administrators. Oracle Database 10g: Implementing Database Vault

System Privileges by Database Account Reports
Privileges are granted to a user: Directly By role System Privileges by Database Account Reports The Direct System Privileges by Database Account report (shown in the slide) and Direct and Indirect System Privileges by Database Account report are very similar. Direct System Privileges by Database Account report: This report displays all system privileges that have been directly granted to the account selected on the Report Parameters page. It also shows whether a privilege has been granted with the WITH ADMIN option. Direct and Indirect System Privileges by Database Account report: This report displays all the system privileges for the database account selected on the Report Parameters page. The system privileges may have been granted directly or granted through a database role, along with the WITH ADMIN status. Oracle Database 10g: Implementing Database Vault

Sensitive Objects Reports
Execute Privileges to Strong SYS Packages report Access to Sensitive Objects report Public Execute Privilege to SYS PL/SQL Procedures report Accounts with SYSDBA/SYSOPER Privilege report Sensitive Objects Reports System Privileges by Privilege report: This report displays the database accounts and roles that have the system privilege selected on the Report Parameters page. Execute Privileges to Strong SYS Packages report: This report shows the database accounts and roles that have execute privileges on system packages that can be used to access operating system (OS) resources or other powerful system packages. The following system packages are included: DBMS_ALERT DBMS_RANDOM DBMS_BACKUP_RESTORE DBMS_REPAIR DBMS_CAPTURE_ADM DBMS_REPCAT DBMS_DDL DBMS_REPCAT_ADMIN DBMS_DISTRIBUTED_TRUST_ADMIN DBMS_FGA DBMS_JOB DBMS_RESOURCE_MANAGER DBMS_RLS DBMS_LDAP DBMS_RESOURCE_MANAGER_PRIVS DBMS_SESSION DBMS_LOB DEBUG_EXTPROC DBMS_LOGMNR UTL_FILE DBMS_LOGMNR_D UTL_HTTP UTL_SMTP DBMS_OBFUSCATION_TOOLKIT UTL_SMTP UTL_TCP DBMS_ORACLE_TRACE_AGENT UTL_TCP DBMS_PIPE Oracle Database 10g: Implementing Database Vault

Sensitive Objects Reports (continued) Access to Sensitive Objects report: This report shows the database accounts and roles that have object privileges on system tables or views that contain sensitive information. It includes the following system tables and views: $_PRIVILEGED_USER DEFROLE$ SOURCE$ ALL_SOURCE FGA_LOG$ SQL_SUMMARY ALL_USERS LINK$ SQLTEXT APPROLE$ OBJ$ STATS$ AUD$ OBJAUTH$ STREAMS AUDIT_TRAIL$ OBJPRIV$ SYSTEM_PRIVILEGE_MAP DBA_ROLE_PRIVS PROFILE$ TABLE_PRIVILEGE_MAP DBA_ROLES TRIGGER$ PROXY_ROLE_DATA$ DBA_TAB_PRIVS USER$ PROXY_ROLE_INFO$ USER_TAB_PRIVS ROLE$ USER_HISTORY$ DBMS_BACKUP_RESTORE DBA_USERS ROLE_ROLE_PRIVS Public Execute Privilege to SYS PL/SQL Procedures report: The Public Execute Privilege to SYS PL/SQL Procedures report shows all database accounts and roles that have execute privileges on packages owned by SYS. This can be used to determine as to which privileges can be revoked from PUBLIC, or from other accounts and roles. This reduces vulnerabilities as part of an overall least-privileges security policy implementation. Accounts with SYSDBA/SYSOPER Privilege report: This report displays database accounts that are able to connect as SYSDBA or SYSOPER. It also shows whether the accounts use an external password. However, note that this report does not cover operating system users who can become SYSDBA. Notes Only Oracle Database 10g: Implementing Database Vault

Privilege Management - Summary Reports
Privileges Distribution By Grantee report Privileges Distribution By Grantee, Owner report Privileges Distribution By Grantee, Owner, Privilege report Privilege Management - Summary Reports These reports display the count of privileges granted to a database account or role with various groupings. These can provide an insight into accounts and roles that may have powerful privileges. Privileges Distribution By Grantee report Privileges Distribution By Grantee, Owner report Privileges Distribution By Grantee, Owner, Privilege report Oracle Database 10g: Implementing Database Vault

Review Privilege Reports
Privilege reports give essential information for: Applying the principle of least privilege Reducing dependence on PUBLIC Removing requirement to grant the DBA role Removing access to sensitive objects Controlling object access Review Privilege Reports Privileges are the primary method of access control in the Oracle database. The system and object privileges provide the security for most objects in a database. The four groups of privilege reports—object, system, sensitive, and by grantee—provide you with tools to apply the principle of least privilege. Grant only the minimum privilege required for a user to do the assigned task. Applying the principle of least privilege is difficult without knowledge of what objects must be accessed, and how the privileges are currently granted to the user. There are over 21,000 object grants to PUBLIC in the version of the Oracle database. Granting privileges to public, grants those privileges to every user, many that may not need them. The default grants to PUBLIC are generally safe, but that cannot be said for the grants to the DBA role. The DBA role has object and system privileges that make it dangerous in the hands of untrusted users. Any user granted the DBA role should be thoroughly vetted and should also be subject to auditing. By knowing the grants required by a particular user, a role that grants just those privileges can be used instead of the DBA role. This reduces the insider threat. There are sensitive objects in the database that can provide information about users, roles, and privileges. There are powerful PL/SQL packages. Access to these objects and the EXECUTE privilege on these packages should not be available to PUBLIC, but only to users who have a need to know. Oracle Database 10g: Implementing Database Vault

Powerful Database Accounts and Roles Reports
WITH ADMIN Privilege Grants report Accounts With DBA Roles report Security Policy Exemption report BECOME USER report ALTER SYSTEM or ALTER SESSION report Password History Access report WITH GRANT Privileges report Roles/Accounts That Have a Given Role report Database Accounts With Catalog Roles report AUDIT Privileges report OS Security Vulnerability Privileges report Powerful Database Accounts and Roles Reports WITH ADMIN Privilege Grants report: The WITH ADMIN Privilege Grants report shows all database accounts that have been granted privileges with the WITH ADMIN clause. This privilege can be misused to give another account more system privileges than required. Accounts With DBA Roles report: This report shows all database accounts that have the DBA role granted to them. The DBA role is a privileged role that can be misused. It is often granted to a database account to save time and to avoid having to determine the least amount of privileges an account really needs. This report can help you start applying a least-privilege policy to an existing database. Security Policy Exemption report: The Security Policy Exemption report shows database accounts and roles that have the EXEMPT ACCESS POLICY system privilege granted to them. Accounts that have this privilege can bypass all Virtual Private Database (VPD) policy filters and any Oracle Label Security (OLS) policies that leverage VPD indirectly. This is a powerful system privilege that should be granted only if absolutely necessary, as it allows one to gain access to sensitive information in tables that are protected by VPD or OLS. BECOME USER report: The BECOME USER report shows all database accounts roles that have the BECOME USER system privilege. This is a very powerful system privilege, and accounts that possess this privilege can be misused to get sensitive information or to compromise an application. Oracle Database 10g: Implementing Database Vault

Powerful Database Accounts and Roles Reports (continued) ALTER SYSTEM or ALTER SESSION report: This report shows all database accounts and database roles that have the ALTER SYSTEM or ALTER SESSION privilege. Restricting these privileges to only those accounts and roles that truly need them (for example, the SYS account and the DB_ADMIN role) is recommended. The ALTER SYSTEM command can be used to change the security-related database initialization parameters that are set to secure values as part of the Database Vault security strengthening service. Both the ALTER SYSTEM and ALTER SESSION commands can be used to dump database trace files, potentially containing sensitive configuration information, to the operating system. Password History Access report: This report shows database accounts that have access to the USER_HISTORY$ table that stores hashed passwords that are previously used by each account. Access to this table can make guessing the existing password for an account easier for someone hacking the database. WITH GRANT Privileges report: This report shows all database accounts that have been granted privileges with the WITH GRANT clause. An account that has been granted privileges using the WITH GRANT option can be misused to grant object privileges to another account. Roles/Accounts That Have a Given Role report: This report displays the database accounts and roles to which a role has been granted. This report is provided for dependency-analysis purposes. Database Accounts With Catalog Roles report: This report displays all database accounts and database roles that have the following roles granted to them: DELETE_CATALOG_ROLE EXECUTE_CATALOG_ROLE RECOVERY_CATALOG_OWNER SELECT_CATALOG_ROLE These catalog-based roles have a very large number of powerful privileges. So, they should be granted with caution, much like the DBA role, which uses them. AUDIT Privileges report: This report displays all database accounts and roles that have the AUDIT privilege. This privilege can be used to disable auditing, which could be used to eliminate the audit trail record of a hacker who has compromised the system. The accounts that have this privilege could be targets for hackers to cover their tracks. OS Security Vulnerability Privileges report: This report shows the database accounts and roles that have the required system privileges to export sensitive or otherwise protected information to the operating system. Notes Only Oracle Database 10g: Implementing Database Vault

Using Powerful Database Accounts and Roles Reports
Each report focuses on a specific vulnerability, such as: The ability to grant privileges The ability to override protections The ability to gain access to another user’s objects The ability to change the system or session configuration The knowledge to more easily guess or crack passwords The ability to modify audit records or auditing options The ability to export sensitive or protected information to the OS Using Powerful Database Accounts and Roles Reports Each report in this group focuses on a specific vulnerability, but all these issues have the common thread of giving a user knowledge or ability to perform an unauthorized action. Some of these reports have to do with privileges that are one level away from the unauthorized action. One example of this is the AUDIT privileges report. This report shows users that can disable audit options and remove audit records, thus hiding these actions. Oracle Database 10g: Implementing Database Vault

Initialization Parameters and Profiles Reports
Security Related Database Parameters report Resource Profiles report System Resource Limits report Initialization Parameters and Profiles Reports The reports in this group deal with vulnerabilities in the database configuration. Parameters such as REMOTE_OS_AUTHENT and AUDIT_TRAIL can create security holes. Resource profiles set limits on user activity, but are not widely used. The System Resources report is a diagnostic to help detect attacks and find limited resources that may be limiting performance. Security Related Database Parameters report: This report displays database parameters that can represent security vulnerabilities, if not set correctly. This report can be used to compare the recommended settings with the current state of the database parameter values. Resource Profiles report: This report provides a view of resource profiles, such as CPU_PER_SESSION and IDLE_TIME, that may be allowing unlimited resource consumption. You should review the profiles that might need a cap on the potential resource usage. System Resource Limits report: This report provides an insight into the current system resource usage. This helps determine whether any of these resources are approaching their limits under the existing application load. Resources that show large increases over a short period of time may point to a Denial of Service (DoS) attack. You can reduce the resource’s upper limit to prevent the condition in the future. These are mostly shared resources, such as enqueue_locks, processes, and transactions. The significance of the particular parameter is covered in the course Oracle Database 10g: Security. Oracle Database 10g: Implementing Database Vault

Database Account Password Reports
Database Account Default Password report Database Account Status report Database Account Password Reports This group of reports focuses on password issues. Most of these issues are prevented by implementing a reasonable password policy. Database Vault provides a password policy by default. Database Account Default Password report: This report lists the database accounts that have default passwords. Default passwords are created during the Oracle database installation. You should change the passwords for accounts included in this report to nondefault, complex passwords. Using nondefault and complex passwords helps secure the database. Database Account Status report: This report provides a view of the status of existing database accounts. It helps you identify schema type accounts that need to be locked. Lock and expiry dates help determine whether the account was locked as a result of password aging or too many failed login attempts. You can identify the password profiles, proper default tablespaces, and temporary tablespaces for each account. Accounts using external passwords, a security vulnerability, can also be identified from the report. Oracle Database 10g: Implementing Database Vault

Security Audit Report - Core Database Audit Report
View the database audit records. These are the records from SYS.DBA_AUDIT_TRAIL. Add Screen shot Security Audit Report - Core Database Audit Report This report returns audit records based on the core database audit policy that is defined, as well as audit records for any other activity that has specifically been audited as a result of using the AUDIT command. This report only displays audit records that are captured if the database initialization parameter AUDIT_TRAIL has been set to DB. This report does not return the following audit events: LOGON, LOGOFF, LOGOFF BY CLEANUP. The following columns of the Audit table are included in the report: Timestamp, User, Host, Action, Return Code, Owner, Object, Privilege Used, Grantee, Comment, Client ID, Global UID, Session ID, Transaction ID, and Logoff Time. Not all columns shown Oracle Database 10g: Implementing Database Vault

Other Security Vulnerabilities Reports
Java Policy Grants report Objects Dependent on Dynamic SQL report Unwrapped PL/SQL Package Bodies report User Name or Password Tables report Tablespace Quotas report Non-Owner Object Trigger report Other Security Vulnerabilities Reports Each of these reports focuses on a possible security vulnerability: Java Policy Grants report: This report shows the Java policy permissions stored in the database. It helps reveal violations to the least privilege principle. Look for GRANT, READ, or WRITE privileges to PUBLIC or other accounts and roles that do not necessarily need the privilege. It is advisable to disable Java loading privileges from PUBLIC, if Java is not required in the database. Objects Dependent on Dynamic SQL report: This report shows objects that use dynamic SQL. Such objects can be a target for a SQL injection attack. After determining the objects that use dynamic SQL, you need to check the privileges that client applications (for example, a Web application) have over the object. You also need to check the access granted for the object to PUBLIC or a wider account base. These actions can limit the scope of an attack. Unwrapped PL/SQL Package Bodies report: This report displays PL/SQL package procedures that are not wrapped. Oracle provides a wrap utility that obfuscates code to the point where it cannot be read in the data dictionary. This prevents a hacker from reading source code and determining how to circumvent data protection. Oracle Database 10g: Implementing Database Vault

Other Security Vulnerabilities Reports (continued) User Name or Password Tables report: This report helps identify application tables in the database that store usernames and password strings by displaying tables with column_names with the strings USER%NAME or PASSWORD embedded. These tables should be examined to determine whether the information is encrypted, and if not, the code and applications using them should be modified to protect them from being visible to database sessions. Tablespace Quotas report: This report shows database accounts that have unlimited quotas on one or more tablespaces. These tablespaces can become potential targets for DoS attacks. Non-Owner Object Trigger report: This report helps reveal triggers that are owned by a database account that is different from the account that owns the database object on which the trigger acts. If the trigger is not part of a trusted database application, then it can steal sensitive data, possibly from tables protected through Oracle Label Security (OLS) or Virtual Private Database (VPD), and place it into an unprotected table for subsequent viewing or export. This kind of trigger requires that the owner of the trigger have privileges granted directly on the object that the trigger accesses. Notes Only Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Produce Database Vault reports Produce general security reports Correct commonly reported issues Oracle Database 10g: Implementing Database Vault

Practice 9 Overview: Viewing Reports
This practice covers the following topics: Creating a user account and giving the user the privilege to run reports Generating violations Viewing reports of audit records Creating an incompletely configured factor Viewing the Factor Configuration report Viewing the Security-Related Database Parameters report Oracle Database 10g: Implementing Database Vault

Implementing Best Practices

Objectives After completing this lesson, you should be able to do the following: Describe the first steps in securing a database by using Oracle Database Vault List the steps to protect a database from a system-privileged application DBA Define the nosysdba option of the orapwd utility Identify the Database Vault components needed to protect against accidental object loss List special considerations for dealing with an application server: connection pooling and limiting connections Identify performance issues to be considered Oracle Database 10g: Implementing Database Vault

Trusted People for Trusted Positions
Choose trusted individuals for trusted accounts and roles OS administrator (root) Oracle software owner Member of DBA or OINSTALL groups Users with the SYSDBA privilege Users with the SYSOPER privilege Users with the DV_OWNER role Users with the DV_ACCTMGR role Trusted People for Trusted Positions Oracle Database Vault restricts access to application data from many privileged users and roles in the database. However, in some cases, Oracle Database Vaults trusts certain accounts and roles. The accounts and roles listed have far reaching privileges, and should only be granted to trusted individuals. The OS administrator (root user) can view unencrypted database files, move and delete any file, login as any user including the oracle software owner, and start and stop any process. The Oracle software owner and members of the DBA and OINSTALL groups can view unencrypted database files, move and delete database files, disable Oracle database vault, start and start the database processes, and modify the initialization parameter file. Users with SYSBDA privilege are required for certain Oracle utilities: Recovery Manager, Data Guard and Data Guard Broker, Real Application Clusters svrctl utility, and Automatic Storage Management command line utilities. If these utilities are required in your environment, then enable the SYSDBA account and monitor the audit trail. SYSDBA is audited by default. Users with the SYSOPER privilege can startup and shutdown the database and change initialization parameters, but they have limited access to the data dictionary. Actions by users with the DV_OWNER or DV_ACCTMGR roles are audited, and these roles have limited privileges but are still quite powerful. Oracle Database 10g: Implementing Database Vault

Separation of Duties Use realms and rule sets together to implement separation of duties. HR DBA HR data Realms Rule sets Separation of Duties As described previously in this course, realms protect your database objects from anyone exercising system privileges. A user must be a member of a realm in order to get around that protection. Further, rule sets can be attached to the authorizations defined for a realm. Define the rule set to further qualify under what conditions the realm’s objects can be accessed. This could be a time of day or IP address of a client machine. The first and simplest line of defense is to place schemas into separate realms. That model fits most environments. Then, only add to the realm any database administrators (DBAs) that require access to manage the database objects. You may optionally add rule sets to the realm authorizations if additional and more granular checks need to be made on the access scenario. For example, the realm may allow the HR DBA to drop a table in the HR schema, but it may also have a rule set that requires that that be done on a weekend. Sales DBA Sales data Oracle Database 10g: Implementing Database Vault

Application DBA: Attributes
ALTER, DROP SELECT APPDBA user SOME_APP objects Run application Application DBA: Attributes An application DBA is a user that is able to perform the typical administration duties for the database objects related only to a specific application, or functional area, of the database. An example is a sales DBA, who is responsible for all the sales data. There may be other type of data in the database, such as HR data, but the sales DBA is responsible only for the sales data. The sales DBA: Can view the schema definitions of the protected objects Can modify definitions of protected objects, including performing these commands, among others: ALTER TABLE ALTER TABLESPACE CREATE INDEX Cannot view data in application tables Cannot make a copy of application tables An application user must still be able to run the application and view and modify data. Application users Oracle Database 10g: Implementing Database Vault

Application DBA: Implementation
Realm participant ALTER, DROP SELECT Command rule APPDBA user SOME_APP objects Run application Role membership and existing object privileges Application DBA: Implementation Put the application data (tables, views, and so on) into a realm. That will protect it from access by other DBAs in the database. Then the application DBA can be made a participant in that realm, making him or her able to access those objects. But then the application DBA is also able to view the data, and it is already been established that that is not to be allowed. So, you implement a command rule that restricts the SELECT operation on those objects to be performed only by users with a specific role assigned to them. It is assumed that the application users still have the object privileges necessary to override the realm protection. If this is not the case, they can also be made realm participants. Application users Oracle Database 10g: Implementing Database Vault

Application DBA: Example
1 Create a realm to protect the schema: 2 Make the DBA a participant: 3 Create a role intended only for application users: SQL> CREATE ROLE sales_app_user; 4 Grant the role only to application users: Application DBA: Example The steps to establish an application DBA called SALES_DBA are listed here. The sales data is in the SH schema. Protect the database objects using a realm: 1. Create a realm to protect the schema. This means only realm members (participants or owners) are able to access the application’s database objects. 2. Add SALES_DBA, which is the user ID for the application DBA, to the realm, making the application DBA able to access the database objects. Now the application DBA can manage those objects as needed. Restrict the application DBA from viewing the data: Do this by creating a SELECT command rule that checks for a particular role: 3. Create a role to be granted only to application users. This is the role that is required to pass the SELECT command rule. 4. Grant the role to the application users, so that their access is not affected. SQL> GRANT sales_app_user TO sales_app_user_1; SQL> GRANT sales_app_user TO sales_app_user_2; Oracle Database 10g: Implementing Database Vault

5 Create a rule set requiring the role: 6 Create a SELECT command rule referring to the rule set: Application DBA: Example (continued) 5. Create a rule set that has a single rule that checks for the SALES_APP_USER role. 6. Create a command rule that only allows SELECT on the SH objects when the preceding rule set is true. Oracle Database 10g: Implementing Database Vault

7 Secure the role in a realm: Application DBA: Example (continued) Protect the new role from misuse: Now that the SALES_APP_USER role exists, you need to protect it from being granted to inappropriate users. Create a realm that will hold this role, and choose a single user to be the owner of that realm. In this example, the SYSTEM user is made the owner, and thus is the only one who can grant this role. Oracle Database 10g: Implementing Database Vault

Application DBA: Result
SALES_DBA can perform administrative tasks such as creating an index: SQL> CREATE INDEX ix_cty ON 2 sh.customers(country_id); Index created. But SALES_DBA cannot view the application data: SQL> SELECT * FROM sh.customers; SELECT * FROM sh.customers * ERROR at line 1: ORA-01031: insufficient privileges Application DBA: Result As a result of the application data being put into a realm, the SALES_DBA user being made a participant of that realm, and the SELECT command rule being created to prevent SELECT on the data, SALES_DBA can perform such duties as index creation, but cannot view the application data. Oracle Database 10g: Implementing Database Vault

Dual Key Security Dual key security can be implemented using Database Vault rule sets that check whether another user is logged in. Dual Key Security Dual key security means that there needs to be the involvement of two people in order to perform a specific task. That task could mean granting access to database objects, executing a procedure, or executing any other database command. Database Vault provides the tools necessary to implement this by enabling you to write a rule set that determines whether another user is currently logged in. The user ID to be checked would belong to a different person than the person attempting the operation. You may actually set aside a user ID that is intended to serve only this kind of purpose. The user with this ID would be granted only the ability to connect, and then have no further privileges. The very fact that this user ID is logged in allows certain things to happen. Some examples are shown in the following slides. Oracle Database 10g: Implementing Database Vault

Dual Key Security: Realm Access Example
1 $ sqlplus BERNST/q1_w2_e3 SQL> select count(*) from hr.jobs; ORA-01031: insufficient privileges 2 $ sqlplus hr/hr SQL> SQL> / COUNT(*) 19 3 Dual Key Security: Realm Access Example In this example, the BERNST user is a participant in the HR realm. But there is an authorization rule set attached to the authorization for BERNST; the UTIL.USER_IS_ON function is called to see whether the HR user is currently logged in. If HR is logged in, then BERNST can access the realm secured objects. The following is the source code for the USER_IS_ON function: CREATE OR REPLACE FUNCTION UTIL.USER_IS_ON(p_username VARCHAR2) RETURN VARCHAR2 AS v_cnt number; BEGIN select count(*) into v_cnt from (select null from sys.v_$session where username = p_username and rownum < 2); if v_cnt > 0 then return 'Y'; else return 'N'; end if; END; Oracle Database 10g: Implementing Database Vault

Dual Key Security: Procedure Execution Example
Only allow execution of the HR.GIVE_RAISE procedure when the PAYROLL_MASTER user is logged in. Dual Key Security: Procedure Execution Example You may have a situation where a procedure should be run, but you want additional checks on the circumstances under which it is run. That can be implemented using dual key security by creating a command rule that controls the execution of the procedure. In this example, a user is assigned the duty of running the HR.GIVE_RAISE procedure. But there is a requirement that another person must have signed off for it to be run. That is implemented by creating a command rule on EXECUTE of the procedure HR_GIVE_RAISE. The command rule calls the rule set used in the previous example, checking for the PAYROLL_MASTER user to be logged in. If that user is not logged in, the GIVE_RAISE procedure cannot be run. It may be that the only purpose for the PAYROLL_MASTER user is to log in and allow this procedure to be run, and then log out. Possibly, the manager of human resources (HR) and the chief financial officer (CFO) are the only people with this password. Note: The PAYROLL_MASTER user is not able to execute the GIVE_RAISE procedure. This user’s only purpose is to allow another user to run it. Oracle Database 10g: Implementing Database Vault

Database Account Considerations
To further enhance the security of your Database Vault configuration, adhere to the following guidelines: Define two separate user IDs for the Database Vault Owner and Database Vault Account Manager. Assign these accounts to separate people: SYS Database Vault Owner Database Vault Account Manager Do not add the Database Vault Owner account as a participant or owner of any realms. Audit the Database Vault realm. Choose obscure names for the Owner and Account Manager accounts. Database Account Considerations When you install Database Vault, it is best to define separate accounts for the Owner and the Account Manager for Database Vault. This prevents the Owner user from creating new accounts, putting them into realms for the purpose of performing suspect tasks, and then dropping the accounts. If the Account Manager account is required to create and drop accounts, then there is accountability and separation of duties. The SYS account should also be assigned to a separate person. This is the only way the system privileges of SYS can be controlled. Otherwise, the SYS user may log in to Database Vault Administrator, disable a realm, and then bypass those realm protections. The Database Vault Owner account should never be added as a member of a realm. Doing this would eventually make that user equivalent to the SYS user, with the added ability to bypass the realm protections. Oracle Database 10g: Implementing Database Vault

Database Account Considerations (continued) To monitor what Database Vault configuration changes are made, audit the Database Vault realm for success or failure situations. This will produce an audit trail of any activity with Database Vault objects, including the case where the Owner account adds itself to a realm or disables a realm or rule set. If you choose an unobvious name for the Database Vault accounts, you can lessen the chance of Denial of Service (DoS) attacks, which may lock those accounts given enough attempts. If an attacker knows the account name, then repeated attempts to log in, even with the wrong password, may lock the account. Locking the Database Vault Owner account would render Database Vault Administrator unusable. Oracle Database 10g: Implementing Database Vault

Locking Down SYSDBA Succeeds with nosysdba option set to N:
SQL> CONNECT sys/oracle AS SYSDBA Connected to: Database Vault Release Create a new password file with the nosysdba=Y option: $ orapwd nosysdba=Y file= . . . Logging in AS SYSDBA fails now: $ sqlplus sys/oracle AS SYSDBA ERROR: ORA-01031: insufficient privileges To temporarily enable SYSDBA, keep a sysdba version of the password file available, and copy it in: Locking Down SYSDBA Database Vault adds a new option to the orapwd utility. The nosysdba=Y option enforces that no one can log in with the AS SYSDBA clause. The SYSOPER privilege, which allows a user to perform administrative tasks but not to view data, is still available, and should be used when appropriate. Some tasks require SYSDBA, which is why you should keep a copy of the password file available that was created with the nosysdba=N option. You can copy this file into place when needed, log in as SYSDBA, perform the tasks, and then copy the nosysdba=Y version of the password file back into place. These tasks include using LogMiner, performing incomplete recovery, and creating and dropping databases. Oracle recommends that you set the AUDIT_SYS_OPERATIONS initialization parameter to TRUE to audit the activity of the SYS user and any user who logs in as SYSDBA or SYSOPER. Then, if the password file is replaced with one created with the nosysdba=N option, any relevant actions will be audited. Note: Database Vault does not allow the use of operating system (OS) authentication. A password must always be supplied to log in. $ cp pwfile_sysdba orapworcl Oracle Database 10g: Implementing Database Vault

Dynamic Auditing Use a rule set’s Custom Event Handler Logic to dynamically turn on auditing. A rule set can have a procedure invoked whenever it is evaluated for any reason. The procedure can call procedures that update Database Vault components, setting their audit options appropriately. Dynamic Auditing Having full auditing on constantly is usually not good for performance or for managing an audit trail efficiently. So, you may want to have certain components’ auditing turned on (for example, for success and failure) when certain rule sets are evaluated. If a rule set that allows connections to come through a virtual private network (VPN) IP address gets invoked, the connection is allowed to be made, but the rule set that is evaluated can have a Custom Event Handler Logic procedure set. That procedure may make calls to update other rule sets that increase their auditing granularity, simply because you want to audit activity coming through VPN more thoroughly than that coming from internal clients. Oracle Database 10g: Implementing Database Vault

Protecting from Accidental Object Loss
Use command rules to prevent inadvertent loss of production objects. Command Owner Object Rule Set Name SQL> DROP TABLE employees; DROP TABLE employees * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47400: Command Rule Violation for drop table on HR.EMPLOYEES ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 Protecting from Accidental Object Loss In a production database, you may want to prevent any accidental dropping of objects in certain schemas or in all schemas. If you rely on allowing only a small subset of users to perform these commands, that lessens the likelihood of its occurrence, but it can still happen. If you define command rules to prevent dropping of tables, for example, then to drop the object, the DBA would have to request that the rule set be disabled. This separation of duties provides accountability and requires more consideration regarding the action being taken. Oracle Database 10g: Implementing Database Vault

Connection Pooling Considerations
SET_FACTOR('X') SET_FACTOR('Y') SET_FACTOR('Z') USER1 USER2 USER3 Application server APPUSER Connection Pooling Considerations When there is a connection pooling mechanism, the database may see all connections coming from the application users as the same database account. This makes it difficult to mitigate access when decisions specific to end users need to be made. This is a case where the application can take advantage of DVSYS.SET_FACTOR. This allows the application to communicate user-specific data to the database, through the connection pool. When the connection is made in Database Vault, the rule sets that refer to the factor are driven with the identities set by the application on behalf of the specific client. The rule set evaluates factor. Oracle Database 10g: Implementing Database Vault

Enforcing Connections from an Application Server
USER1 USER2 USER3 Application server APPUSER Enforcing Connections from an Application Server There may be circumstances where you know that all connections coming into Database Vault are from one or a set of application servers. You can code into a rule set a check on the IP address factor to ensure that the connection is coming from a known application server. Here is the expression for the rule in such a rule set: DV.F$CLIENT_IP IN(' ',' ') The rule set ensures that IP address is acceptable before connecting. Oracle Database 10g: Implementing Database Vault

Spoofing Program Identity
A program can be made to look like another program. SQL> exec dbms_application_info.set_module('hrmaint',null); PL/SQL procedure successfully completed. SQL> select sys_context('userenv','module') from dual; SYS_CONTEXT('USERENV','MODULE') hrmaint Spoofing Program Identity If you create factors or rule sets that depend on the DBMS_APPLICATION_INFO settings, be aware that those settings can be changed manually, effectively spoofing the program’s identity. In this example, a user has logged in to SQL*Plus. He then calls SET_MODULE to set the MODULE context variable to hrmaint. If your security depends on making sure that certain access is granted only to the hrmaint program, then this act could compromise that security. NO SQLPLUS secure application role Rule set enforcing module name is not SQL*Plus Oracle Database 10g: Implementing Database Vault

Fast Response to Policy Changes
You can respond quickly to security policy changes by using the delivered ON/OFF components to toggle: Factors: Use Enabled and Disabled assignment rule sets. Rule sets: Enable or disable the rule set. Add the True or False rule to the rule set. Realms: Enable or disable the realm. Command rules: Set the rule set to Enabled or Disabled. Secure application roles: Set the rule set to Enabled or Disabled. Fast Response to Policy Changes There are settings in the Database Vault components that make it very easy to open up or close down access very quickly. Most components can be enabled or disabled. And the rules True and False can be used to change rule set behavior. Oracle Database 10g: Implementing Database Vault

Performance Considerations: Auditing
Audit only on failure. Audit options for realms and rule sets Audit options for factors Use sparingly Performance Considerations: Auditing To maintain the best performance in Database Vault, you should audit only on failure, if possible. Otherwise, many audit records will be generated when they may not be necessary. So, use success auditing only when necessary. Also remember that the evaluation of rule sets and factors may be invoked when accessing realms, setting secure application roles, or resolving command rule access. So, the performance impact can add up if there are too many components being audited. Oracle Database 10g: Implementing Database Vault

Performance Considerations: Unused Factors
Delete unnecessary factors. CONNECT: GET_FACTOR(); Delivered session factors Performance Considerations: Unused Factors Delete any factors that you do not need. This is important for those factors defined with the For Session option. To mitigate performance issues for frequently used factors, these are evaluated and cached every time a user connects to the database. This makes subsequent accesses faster, because it is known that they only need to be evaluated once, for the session. But, whether they are ever referenced or not, they are evaluated once at connect time. If your system has a high frequency of session creation, then depending on the number and complexity of your defined factors, the speed of connections and other operations may be noticeably impacted. Note: If there is a factor that, by its nature, will not change during the lifetime of a connection, make sure that it is set to be evaluated For Session, rather than By Access. If it is being reevaluated every time it is accessed, but it never will change, then it is wasting resources. Oracle Database 10g: Implementing Database Vault

Diagnosing Database Vault Using Trace Files
A session encounters a Database Vault access restriction: The trace file shows that the cause is a realm authorization failure: SQL> alter session set events '47998 trace name context 2 forever, level 12'; Session altered. SQL> select * from hr.jobs; select * from hr.jobs * ERROR at line 1: ORA-01031: insufficient privileges *** SESSION ID:(143.99) :04:29.076 DATVAL: kzvaudevent() start DATVAL: Realm Auth Failed. Current User: SYSTEM DATVAL: Realm Auth Failed. Object Owner:HR, Object Name:JOBS Diagnosing Database Vault Using Trace Files You can monitor your Database Vault database instance for server and background process events. To do so, check the database instance’s trace files. Trace files can reveal events such as tracing information for the logic that the Database Vault security enforcement engine executes, as well as internal errors, block corruption errors, deadlock errors, administrative actions that may have taken place, values of parameters that had nondefault settings when the database instance started, and other information. To enable tracing, log in with any account that has the ALTER SESSION privilege and issue the following statement: SQL> ALTER SESSION SET EVENTS 2 '47998 trace name context forever, level 12' For example, suppose you have an account that is trying to select from a table, and the result is an ORA-01031: insufficient privileges error. You could turn on the trace event, reissue the command, and then look at the trace file to see that it was a realm authorization violation. Note: For more information about how to manage trace files, see the Oracle Database Administrator's Guide and the Oracle Database Performance Tuning Guide. Oracle Database 10g: Implementing Database Vault

Enabling and Disabling Database Vault
There are certain anomalous situations where Database Vault must be disabled in order for you to continue operating your database. For the purpose of this list, the Database Vault Account Manager and the Database Vault Owner accounts are referred to as DVAM amd DVO, respectively. The circumstances are: The DVAM password has been forgotten. The DVAM or DVO accounts have been locked out. A CONNECT command rule is configured such that no users can connect, including DVAM and DVO. You need to install other database options or products. Oracle Database 10g: Implementing Database Vault

Steps for Disabling Database Vault
Shut down Oracle processes. Relink Oracle executables without the Database Vault option. Start up the database. Disable Database Vault. Steps for Disabling Database Vault To disable Database Vault, perform the following steps: 1. Stop Enterprise Manager Database Control, and shut down the database: $ emctl stop dbconsole $ sqlplus sys/oracle as sysoper SQL> shutdown immediate 2. Relink the Oracle executable without the Database Vault option: $ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk dv_off $ cd $ORACLE_HOME/bin $ relink oracle 3. Start up the database: SQL> startup 4. Run Database Vault Configuration Assistant (DVCA) to disable Database Vault: $ORACLE_HOME/bin/dvca -silent -action disable \ -service orcl -sys_passwd oracle -owner_account dvo \ -owner_passwd oracle_10g -nodecrypt Oracle Database 10g: Implementing Database Vault

Steps for Enabling Database Vault
Run DVCA to enable Database Vault. Stop Oracle processes. Relink Oracle executables with the Database Vault option. Start up the database. Steps for Enabling Database Vault To enable Database Vault, perform the following steps: 1. Run Database Vault Configuration Assistant (DVCA) to enable Database Vault: $ORACLE_HOME/bin/dvca -silent -action ensable \ -service orcl -sys_passwd oracle -owner_account dvo \ -owner_passwd oracle_10g -nodecrypt 2. Stop Enterprise Manager Database Control, and shut down the database: $ emctl stop dbconsole $ sqlplus sys/oracle as sysoper SQL> shutdown immediate 3. Relink the Oracle executable to include the Database Vault option: $ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk dv_on $ cd $ORACLE_HOME/bin $ relink oracle 4. Start up the database: SQL> startup Oracle Database 10g: Implementing Database Vault

Password Policy Considerations
Oracle recommends making the following changes to your password policy: Default Recommended FAILED_LOGIN_ATTEMPTS 10 7 PASSWORD_GRACE_TIME UNLIMITED 3 PASSWORD_LIFE_TIME UNLIMITED 90 PASSWORD_REUSE_TIME UNLIMITED 180 Password Policy Considerations To further tighten security measures, Oracle recommends making these changes to the password policy, in a Database Vault instance: FAILED_LOGIN_ATTEMPTS: The number of failed login attempts allowed before the account is locked. The recommended value is seven attempts. PASSWORD_GRACE_TIME: The number of days after which the grace period begins (for a password change requirement) during which a warning is issued and login is allowed. If the password is not changed during the grace period, the password expires. The recommended value is 3 days. PASSWORD_LIFE_TIME: The number of days a password can be used. The recommended value is 90 days. PASSWORD_RESUSE_TIME: The number of days between reuses of the same password. The recommended value is 180 days. Oracle Database 10g: Implementing Database Vault

Guidelines for Procedures and Packages
Concern Remedy Java Stored Procedures Use invoker’s rights and realms to protect data UTL_FILE Package Grant execute only to users that require it. Use command rules to control creation of directory objects DBMS_FILE_TRANSFER Package Use command rules to control EXECUTE on DBMS_FILE_TRANSFER package Use comand rules to control creation of directory objects, and database links LogMiner Packages Grant execute privileges directly. Revoke privilege except when needed. Audit use of the LogMiner packages Guidelines for Procedures and Packages Database Vault does not protect everything. There are certain areas users of Database Vault should consider. Care must be take with the following procedures and packages. For detailed instructions to implement these recommendations see Oracle Database Vault Administrator's Guide 10g Release 2 (10.2). Java Stored Procedures For definers' rights Java stored procedures, the execution of the stored procedure is not blocked and realm protection is not enforced. However, underlying objects accessed by the Java stored procedure are protected by Oracle Database Vault command rules. For invoker rights Java stored procedures, the execution of the stored procedure is not blocked. However, underlying objects accessed by the Java stored procedure are protected by both Oracle Database Vault realms and command rules. UTL_FILE Package Oracle recommends that you grant EXECUTE permission for the UTL_FILE package to specific application owners and then revoke this package from PUBLIC. Use command rules to control creation of directory objects thus further control access to the file system. DBMS_FILE_TRANFER Package Grant EXECUTE privileges to only those users that require the use of this package. Revoke privileges from all others. Use command rules to control creation of directory objects and database links. Oracle Database 10g: Implementing Database Vault

Guidelines for Procedures and Packages (notes only slide)
Guidelines for Procedures and Packages (continued) LogMiner Packages If LogMiner packages are needed, grant execute privileges directly and revoke immediately after task is completed. Audit the use of the LogMiner packages. A user with privileges to execute LogMiner packages can view, insert, update, and delete records. Guidelines for Procedures and Packages (notes only slide) Oracle Database 10g: Implementing Database Vault

Other Guidelines Concern Remedy Recycle Bin Disable Recycle Bin feature or Realm users use DROP … PURGE ALTER SYSTEM ALTER SESSION Add command rules to prevent dumps CREATE ANY JOB CREATE JOB Revoke CREATE ANY JOB from all users Use CREATE JOB in place of CREATE ANY JOB Other Guidelines There are situations where a unauthorized user may see realm protected data, if they have certain privileges. These guidelines will help protect against these scenarios. For detailed instructions to implement these recommendations see Oracle Database Vault Administrator's Guide 10g Release 2 (10.2). Recycle Bin The SELECT_CATALOG_ROLE has SELECT privilege on the view DBA_RECYCLEBIN, which contains all dropped objects. A user with this role can see all the contents of the recycle bin. Oracle recommends that you disable the RECYCLE BIN feature. If this feature is required, then schema owners in protected realms should purge their recycle bins whenever they drop any objects. ALTER SYSTEM / ALTER SESSION privileges Users with the ALTER SESSION or ALTER SYSTEM privileges can set events and dump blocks, then read unencrypted data even from realm protected objects. Use command rules to prevent this. CREATE ANY JOB / CREATE JOB Users with the CREATE ANY JOB privilege may create a job in a schema that has realm access privileges. Revoke the privilege when it is not required. Grant the CREATE JOB privilege in place of CREATE ANY JOB whenever feasible. CREATE JOB allows the user to create jobs only in his or her own schema. Oracle Database 10g: Implementing Database Vault

Other Guidelines (continued) Oracle Streams, Oracle Database Enterprise Manager Grid Control, and Advanced Replication depend on the CREATE ANY JOB privilege. If you are using these products, then grant this privilege directly to SYS only. The CREATE ANY JOB recommendations described in this section also apply to the following privileges: CREATE EXTERNAL JOB EXECUTE ANY PROGRAM EXECUTE ANY CLASS MANAGE_SCHEDULER Oracle Database 10g: Implementing Database Vault

Miscellaneous Practices
Consider the following as you work with Database Vault: Do not put spaces in factor names: To create rules that are not yet needed in a rule set, define a repository rule set to store them in until they are needed. Test any expressions for rules and factors by putting them into this statement: SQL> select "DVF"."F$A B" from dual; ORA-00904: "DVF"."F$A B": invalid identifier SQL> SELECT 1 from dual WHERE <expression> Miscellaneous Practices There are some other considerations when working with Database Vault. Do not put spaces in factor names. It is possible to create a factor with a space in its name, but then when you refer to the factor name using the DVF.F$ syntax, it fails because of the space. If you need to create some rules that you know you will need at some point, but do not have a rule set to contain them yet, consider creating a repository rule set. There is nothing special about this rule set; it just will not be referenced anywhere. But if you create this, you can proceed to create any rule you think you will need at some point, and have a place to store it. When using Database Vault Administrator, the only way to create a rule is to edit a rule set. Rather than risking making changes to a rule set that is being referenced by other components, create a rule set called something like Repository, and put these homeless rules there. Then they will be available for use in other rule sets when you need them. Sometimes the expressions in rules can get complex. You can test them before saving them by appending the expression to the SQL statement: SELECT 1 FROM dual WHERE <expression> If 1 is returned, then the expression is true. If no rows are returned, then it is false. Oracle Database 10g: Implementing Database Vault

Summary In this lesson, you should have learned how to: Describe the first steps in securing a database using Database Vault List the steps to protect a database from a system-privileged application DBA Define the nosysdba option of the orapwd utility Identify the Database Vault components needed to protect against accidental object loss List special considerations for dealing with an application server: connection pooling and limiting connections Identify performance issues to be considered Oracle Database 10g: Implementing Database Vault

Introduction.

Similar presentations

Presentation on theme: "Introduction."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction.

Similar presentations

Presentation on theme: "Introduction."— Presentation transcript:

Similar presentations

About project

Feedback