D47175

Oracle Database 10g: Implementing Database Vault
Student Guide
D44719GC10 Edition 1.0 August 2006 D47175
Authors
Tom Best James Spiller
Copyright 2006, Oracle. All rights reserved. Disclaimer This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract. Trademark Notice Oracle, TimesTen, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Technical Contributors and Reviewers

Tom Bolick Harald van Breederode Jack Brinson M.J. Bryksa Ben Chang Scott Gaetjen Greg Gagnon Philip Garm Joel Goodman Thomas Hoogerwerf Pat Huey Sushma Jagannath Donna Keesling Russ Lowenthall Yi Lu Kurt Lysy Sabiha Miri Paul Needham Roman Niehoff Ashwini Surpur Kamal Tbeileh Peter Wahl Anthony Woodell John Zimmerman
Editors
Atanu Raychaudhuri Navratan Singh Nita Pavitran
Graphic Designer
Samir Mozumdar
Publisher
Jobi Varghese
Contents
Preface 1 Introduction Objectives 1-2 Suggested Schedule 1-3 What Is Database Vault? 1-4 Database Vault Option 1-5 Benefits of Database Vault 1-6 Database Vault: Effects 1-8 Database Vault Versus VPD and OLS 1-9 Access Control Components 1-10 Realms: Introduction 1-11 Factors: Introduction 1-12 Identities: Introduction 1-13 Rule Sets: Introduction 1-14 Command Rules: Introduction 1-15 Secure Application Roles: Introduction 1-16 Component Relationships: Static 1-17 Component Relationships: Dynamic 1-18 Scenarios 1-19 Database Vault Example: Separation of Duties 1-20 Database Vault Administrator (DVA) 1-21 Database Vault Configuration Assistant (DVCA) 1-22 Reporting 1-23 Monitoring 1-24 Database Vault API 1-25 Summary 1-26 Installing Database Vault Objectives 2-2 Installation Requirements 2-3 Installation Method 2-4 Performing a Clustered Installation 2-5 Performing a Stand-Alone Installation 2-7 Specifying Installation Details 2-8
iii
Installation Summary 2-9 Configuration Assistants 2-10 Logging In to Database Vault Administrator (DVA) 2-11 Database Vault Roles 2-12 Database Vault Accounts 2-14 DV_OWNER Versus DV_ACCTMGR 2-15 Database Vault Schemas 2-16 Summary 2-17 Practice 2 Overview: Installing Database Vault 2-18 3 Configuring Realms Objectives 3-2 Realms: Concepts 3-3 Realms: Static Component Context 3-4 Realms: Dynamic Component Relationships 3-5 Realms: Concepts 3-6 Effect of Realms on Nonmembers 3-7 Benefits of Using Realms 3-8 Realm Attributes 3-9 Creating Realms 3-10 Editing Realms 3-11 Adding Objects to Realms 3-12 Adding Authorizations to Realms 3-13 Realm Authorizations and Rule Sets 3-14 Realm Algorithm 3-15 Realm Protection from DBAs: Example 3-16 Schema Owner Access: Example 3-17 Greatest Level of Access 3-18 Protecting Roles by Using Realms 3-19 Protecting Roles: Example 3-21 Delivered Realms 3-23 Realm Views 3-24 Realm Views Relative to DVA 3-26 Realm Reporting: Configuration Issues 3-27 Realm Audit Report 3-28 Realm API 3-29 Summary 3-30 Practice 3 Overview: Managing Realms 3-31
iv
Defining Factors Objectives 4-2 Factors: Static Component Context 4-3 Factors: Dynamic Component Relationships 4-4 Factors: Concepts 4-5 Using Factors 4-6 Predefined Factors 4-7 Factors and Contexts 4-9 Factor Scenarios 4-10 Creating and Editing Factors 4-11 The Create Factor Page 4-12 Factor Types 4-13 Factor Identification 4-14 Factor Evaluation 4-15 Retrieval Method 4-16 DVSYS.SET_FACTOR 4-17 Validation Method 4-18 Factor Audit Options 4-19 Error Options 4-20 Deleting Factors 4-21 Factor Views 4-22 Factor Configuration Issues Report 4-23 Factor Audit Report 4-24 Factors API 4-25 Summary 4-27 Practice 4 Overview: Working with Factors 4-28 Defining Identities Objectives 5-2 Identities: Static Component Context 5-3 Identities: Dynamic Component Relationships 5-4 Identities: Concepts 5-5 Purpose of Identities 5-6 Identity Example: All Possible Identities 5-7 Identity Example: Adding Trust Levels 5-8 Identity Example: Mapping Child Factors 5-9 Editing the Factor: Creating an Identity 5-10 Creating an Identity 5-11 Trust Levels 5-12 Mapping Identities 5-14 Examples of Identities Mapped to Factors 5-16
v
Map Conditions 5-17 Deleting Identities 5-18 Integrating Factors and Oracle Label Security 5-19 Oracle Label Security 5-20 Oracle Label Security Policies 5-21 Editing OLS Policies 5-22 OLS Merging Algorithms 5-23 Factor Labeling 5-24 Identities and OLS 5-25 Identity View 5-26 Identity Map View 5-27 Factors Without Identities Report 5-28 Identity Configuration Issues Report 5-29 Label Security Integration Audit 5-30 Identities API 5-31 Summary 5-32 Practice 5 Overview: Managing Identities 5-33 6 Defining Rule Sets Objectives 6-2 Rule Sets: Concepts 6-3 Rule Sets: Static Component Context 6-5 Rule Sets: Dynamic Component Relationships 6-6 Using Rule Sets 6-7 Rule Sets 6-8 Creating a Rule Set 6-9 Adding Existing Rules to a Rule Set 6-11 Creating a Rule 6-12 Reusing Rules 6-13 Auditing Rule Sets 6-14 Setting a Custom Event Handler 6-15 Using Rule Sets with Realms 6-16 Assignment Rule Sets for Factors 6-17 Creating a Rule Set: Example 6-18 Editing the New Rule Set: Example 6-20 Adding Rules to the New Rule Set: Example 6-21 Verifying the Rule Set Logic: Example 6-23 Adding the Rule Set to a Factor: Example 6-24 Delivered Rule Sets 6-25 Can Maintain Own Account Rule Set 6-26 Enabled and Disabled Rule Sets 6-27
vi
Rule Set Views 6-28 Rule Set Reporting: Configuration Issues 6-29 Rule Set API 6-30 Summary 6-31 Practice 6 Overview: Managing Rule Sets 6-32 7 Configuring Command Rules Objectives 7-2 Command Rules: Concepts 7-3 Command Rules: Static Component Context 7-4 Command Rules: Dynamic Component Relationships 7-5 Command Rules Page 7-6 Command Rule Attributes 7-7 Identifying a Command Rule 7-8 Command Rule: Example 7-9 Disallowing All Users from ALTER TABLE in a Schema: Example 7-12 Delivered Command Rules 7-13 DBA_DV_COMMAND_RULE View 7-15 Command Rule Report 7-16 Command Rule API 7-17 Summary 7-18 Practice 7 Overview: Managing Command Rules 7-19 Configuring Secure Application Roles Objectives 8-2 Secure Application Roles: Static Component Context 8-3 Secure Application Roles: Dynamic Component Relationships 8-4 Secure Application Roles: Concepts 8-5 Secure Application Role 8-6 Using a Secure Application Role 8-7 Secure Application Role Changes in Database Vault 8-8 Creating a Rule Set 8-9 Creating Rules 8-10 Creating Secure Application Roles 8-11 Deleting Secure Application Roles 8-12 Examples 8-13 Secure Application Role Views 8-15 Secure Application Configuration Issues 8-16 Secure Application Role Audit 8-17 Secure Application Roles API 8-18 Summary 8-19 Practice 8 Overview: Managing Secure Application Roles 8-20
vii
Viewing Reports Objectives 9-2 Required Privileges 9-3 Reporting Needs 9-4 Database Vault Monitor 9-5 Security Policy Changes Detail 9-6 Security Violation Attempts 9-7 Database Configuration and Structural Changes 9-8 Database Vault Reports 9-9 Database Vault Configuration Issues Reports 9-11 Review the Database Vault Configuration 9-13 Database Vault Auditing Reports 9-14 Reviewing Database Vault Audit Reports 9-16 General Security Reports 9-17 Object Privilege Reports 9-18 Object Privileges by PUBLIC 9-19 Object Dependencies 9-20 Database Account System Privileges Reports 9-21 System Privileges by Database Account Reports 9-22 Sensitive Objects Reports 9-23 Privilege Management - Summary Reports 9-25 Review Privilege Reports 9-26 Powerful Database Accounts and Roles Reports 9-27 Using Powerful Database Accounts and Roles Reports 9-29 Initialization Parameters and Profiles Reports 9-30 Database Account Password Reports 9-31 Security Audit Report - Core Database Audit Report 9-32 Other Security Vulnerabilities Reports 9-33 Summary 9-35 Practice 9 Overview: Viewing Reports 9-36
10 Implementing Best Practices Objectives 10-2 Trusted People for Trusted Positions 10-3 Separation of Duties 10-4 Application DBA: Attributes 10-5 Application DBA: Implementation 10-6 Application DBA: Example 10-7 Application DBA: Result 10-10 Dual Key Security 10-11 Dual Key Security: Realm Access Example 10-12
viii
Dual Key Security: Procedure Execution Example 10-13 Database Account Considerations 10-14 Locking Down SYSDBA 10-16 Dynamic Auditing 10-17 Protecting from Accidental Object Loss 10-18 Connection Pooling Considerations 10-19 Enforcing Connections from an Application Server 10-20 Spoofing Program Identity 10-21 Fast Response to Policy Changes 10-22 Performance Considerations: Auditing 10-23 Performance Considerations: Unused Factors 10-24 Diagnosing Database Vault Using Trace Files 10-25 Enabling and Disabling Database Vault 10-26 Steps for Disabling Database Vault 10-27 Steps for Enabling Database Vault 10-28 Password Policy Considerations 10-29 Guidelines for Procedures and Packages 10-30 Other Guidelines 10-32 Miscellaneous Practices 10-34 Summary 10-35 Practice 10 Overview: Implementing Best Practices 10-36 Appendix A: Practices Appendix B: Practice Solutions Index
ix
Preface
Profile Before You Begin This Course Before you begin this course, you should have working experience with SQL and PL/SQL, and familiarity with Oracle Database 10g Security. How This Course Is Organized Oracle Database 10g: Implementing Database Vault is an instructor-led course featuring lectures and hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts and skills that are introduced.
Preface - 3
Related Publications Oracle Publications Title Oracle Database Vault Administrator's Guide 10g Release 2 (10.2) Oracle Database Vault Installation Guide 10g Release 2 (10.2) for Linux Oracle Database Vault Release Notes 10g Release 2 (10.2.0.2) for Linux Oracle Label Security Administrator's Guide 10g Release 2 (10.2) Oracle Database Administrator's Guide 10g Release 2 (10.2) Additional Publications System release bulletins Installation and users guides read.me files International Oracle Users Group (IOUG) articles Oracle Magazine Part Number B25166-01 B25165-01 B28934-01 B14267-02 B14231-02
Preface - 4
Typographic Conventions What follows are two lists of typographical conventions that are used specifically within text or within code. Typographic Conventions Within Text Convention Uppercase Object or Term Commands, functions, column names, table names, PL/SQL objects, schemas Filenames, syntax variables, usernames, passwords Trigger and button names Books, names of courses and manuals, and emphasized words or phrases Lesson module titles referenced within a course Example Use the SELECT command to view information stored in the LAST_NAME column of the EMPLOYEES table.
Lowercase, italic
where: role
is the name of the role to be created.
Initial cap
Assign a When-Validate-Item trigger to the ORD block. Choose Cancel. For more information on the subject see Oracle SQL Reference Manual Do not save changes to the database. This subject is covered in Lesson 3, Working with Objects.
Italic
Quotation marks
Preface - 5
Typographic Conventions (continued) Typographic Conventions Within Code Convention Uppercase Lowercase, italic Initial cap Object or Term Commands, functions Syntax variables Forms triggers Example SELECT employee_id FROM employees; CREATE ROLE role; Form module: ORD Trigger level: S_ITEM.QUANTITY item Trigger name: When-Validate-Item . . . . . . OG_ACTIVATE_LAYER (OG_GET_LAYER ('prod_pie_layer')) . . . SELECT last_name FROM employees; Bold Text that must be entered by a user CREATE USER scott IDENTIFIED BY tiger;
Lowercase
Column names, table names, filenames, PL/SQL objects
Preface - 6
Introduction
Copyright 2006, Oracle. All rights reserved.
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 1 - 2
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
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.
Database Vault Option

$ sqlplus hr/hr SQL*Plus: Release 10.2.0.2.0 - Production on Mon May 1 14:36:16 2006 Copyright (c) 1982, 2005, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Database Vault options
10.2.0.2.0
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 10.2.0.2 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.
Benefits of Database Vault
Compliant separation of duties
Protection from insider threat
Customized control of data access conditions
Consolidation of applications
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.
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.
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.
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.
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
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.
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.
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 DOMAIN factor
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.
Rule Sets: Introduction

Rule 1 TRUE or FALSE AND/OR Rule 2 TRUE or FALSE AND/OR
AND/OR Rule n TRUE or FALSE
Rule set result
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.
Command Rules: Introduction
Command type Object Owner Rule set Command rule
To perform this command On this object Which is owned by this user This rule set must evaluate to TRUE.
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.
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.
Component Relationships: Static
Realm
Command rule Uses
Secure application role
Rule set
Uses
Factor
Uses
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.
Component Relationships: Dynamic
Secure application role Identity
Realm
Factor Rule set
Command rule
Optional flow
Required flow
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.
Scenarios
At 3:00 p.m. Monday
HR DBA
CREATE USER
HR DBA
SELECT * FROM OE.CUSTOMERS
SYS
CONNECT AS SYSDBA
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.
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 ----------78279.6
2 3
The security manager protects the OE.ORDERS table with a realm. 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.
Database Vault Administrator (DVA)
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: http://<machine 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.
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
$ dvca
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.
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.
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.
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.
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
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
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 10.2.0.2 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 10.2.0.2. 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.
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.
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 \ -c "SYS/password AS SYSDBA"
3. Stop all node applications. An example is:

$ORACLE_HOME/bin/srvctl stop nodeapps -n node \ -c "SYS/password AS SYSDBA"
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 2 - 5
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:
jdbc:oracle:oci:@orcl1

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
Performing a Stand-Alone Installation
Stop all Oracle database processes:

1. Shut down the database. 2. Stop the listener. 3. Stop the Oracle Enterprise Manager Database Control console. 4. Stop the iSQL*Plus application server.
Run the Database Vault installer software. Restart Oracle database processes:
1. Start up the database. 2. Start the listener. 3. Start the Oracle Enterprise Manager Database Control console. 4. 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
Specifying Installation Details
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.
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 10.2.0.2.0 Database Vault J2EE Application 10.2.0.2.0 Database Vault One-Off Patch 10.2.0.2.0 Database Vault Scripts 10.2.0.2.0
Configuration Assistants
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.
Logging In to Database Vault Administrator (DVA)
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: http://edrsr9p1.us.oracle.com:1158/dva 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.
Database Vault Roles

DV_OWNER Grants DV_OWNER (e.g. the DVO user) Runs DVA to configure access control Views reports
PUBLIC
DV_PUBLIC Has EXECUTE on benign procedures
DV_ADMIN
DV_SECANALYST
Creates and alters accounts DV_ACCTMGR Grants CONNECT, DV_ACCTMGR (e.g. the DVAM user)
DV_REALM_RESOURCE Has CREATE system privileges
DV_REALM_OWNER Has ANY system privileges
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.
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.
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:

Any valid database account name 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.
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.
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.
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)
Practice 2 Overview: Installing Database Vault

This practice covers the following topics: Installing Database Vault Setting up database accounts for course practices
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
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.
Realms: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Realms: Dynamic Component Relationships
Realm
Factor Rule set
Command rule
Optional flow
Required flow
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.
Realms: Concepts
Using system privileges
R
SYSTEM
E A L
SYS schema
HR_DBA
M S
HR data
SALES_DBA
Sales data
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.
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 schemas 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.
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.
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.
Creating Realms
You have to create the realm before adding objects.
Creating Realms 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.
Editing Realms
Add objects and authorizations to the realm.
Editing Realms 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.
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.
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.
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.
Realm Algorithm
1
Using system privileges? Yes
2
Referenced objects in realm? No Yes
3
User in realm authorization? No
Realm violation
No
Yes No
4
Users authorization based on rule set? Yes
5
Rule set evaluate to TRUE?
No No realm violation
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 users 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.
Realm Protection from DBAs: Example

1 because this user has the DBA role:
SQL> CONNECT sales_dba/password SQL> DROP TABLE hr.bonus_it; Table dropped.
SALES_DBA can drop an HR table
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.
Schema Owner Access: Example

1
HR is unable to drop an HR table because of the realm:
SQL> DROP TABLE bonus_exec; ORA-20401: Realm Violation for drop table on HR.BONUS_EXEC
DVO makes HR a participant in the realm:
HR schema
HR is now able to drop its own table:

SQL> DROP TABLE bonus_exec; Table dropped.
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.
Greatest Level of Access

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.
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.
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.
Protecting Roles: Example

1 The HR user creates the BENNIES standard database role:
SQL> CREATE ROLE bennies; Role created.
DVO secures the BENNIES role in a realm:
3 4
DVO adds the HR user as a participant in the realm:
HR is not able to grant the role:
SQL> grant bennies to sh; ORA-47401: Realm Violation for grant role privilege on NULL.NULL
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.
Protecting Roles: Example
DVO changes the HR user to be an owner in the realm:
HR is able to grant the role:
SQL> GRANT bennies TO sh; Grant succeeded.
HR is also able to revoke the role:
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.
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.
Realm Views
DBA_DV_REALM
NAME DESCRIPTION AUDIT_OPTIONS ENABLED
DBA_DV_REALM_OBJECT
REALM_NAME OWNER OBJECT_NAME OBJECT_TYPE
DBA_DV_REALM_AUTH
REALM_NAME GRANTEE AUTH_RULE_SET_NAME AUTH_OPTIONS
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
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
Realm Views Relative to DVA
DBA_DV_REALM
NAME DESCRIPTION AUDIT_OPTIONS ENABLED
DBA_DV_REALM_OBJECT
REALM_NAME OWNER OBJECT_NAME OBJECT_TYPE
DBA_DV_REALM_AUTH
REALM_NAME GRANTEE AUTH_RULE_SET_NAME AUTH_OPTIONS
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.
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.
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.
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
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
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
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
Factors: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Factors: Dynamic Component Relationships
Realm
Factor Rule set
Command rule
Optional flow
Required flow
Factors: Dynamic Component Relationships Factors are referenced by rule sets in their rule expressions.
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
Factor 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.
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 sites 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.
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
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 users 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 users 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.
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.
Factor Scenarios
Domain = INTERNET
HR Clerk
SELECT * FROM hr.employees WorkHours = WEEKEND
UPDATE hr.employees HR Clerk Proxy_User = SH Domain = SECURE
WSMITH
INSERT INTO sh.sales
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.
Creating and Editing Factors
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.
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 factor_type_name description rule_set_name get_expr validate_expr identify_by labeled_by eval_options audit_options fail_options VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, NUMBER, NUMBER, NUMBER, NUMBER, NUMBER)
Factor Types
Factor types group factors into categories.
Factor Type
User
Time
Factors Session user Identification type Proxy user TimeOfDay
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.
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.
Factor Evaluation
Evaluation determines when an identity is assigned to the factor. CONNECT For Session
SELECT
By Access
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.
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.
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.
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
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 factors 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 factors 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 factors resolved identity has an assigned trust level of NULL. Trust Level Less Than Zero: Create an audit record when the factors resolved identity has an assigned trust level less than zero.
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.
Deleting Factors
Deleting Factors To delete a factor, perform the following steps: 1. Select the factor by clicking the option next to the factor name. 2. Click Remove. A confirmation page appears. Click Yes to delete the factor. The DBMS_MACADM package provides the function:
DELETE_FACTOR(factor_name VARCHAR2)
Factor Views
DBA_DV_FACTOR
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_RULE_SET_RULE DBA_DV_FACTOR_TYPE
NAME DESCRIPTION
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
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
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 factors 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.
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
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.
Summary
In this lesson, you should have learned how to: Create and edit factors View existing factors Use factor reports
Practice 4 Overview: Working with Factors

This practice covers the following topics: Creating factors Editing factors Viewing factors
Defining Identities
Objectives
After completing this lesson, you should be able to do the following: Describe the concept of identities Map identities Manage identities
Identities: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Identities: Dynamic Component Relationships
Realm
Factor Rule set
Command rule
Optional flow
Required flow
Identities: Dynamic Component Relationships Identities are referenced by factors.
Identities: Concepts
An identity: Is a value Has a trust level Can be resolved from other factors Can have a label
Factor with identity Factor Method
Trust level
Label
Mapping
Identity
Factor
Constant
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.
Purpose of Identities
Configure identities to: Define the known identities for a factor Add a trust level to a factors identity Resolve a factors identity through child factors (identity mapping) Add an OLS label to a factors identity
Purpose of Identities A factors 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 factors identity To add an OLS label to a factors identity To resolve a factors identity through its child factors (identity mapping) Identities must be configured to use trust level, OLS label, or child factors.
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.
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.
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.
Editing the Factor: Creating an Identity
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.
Creating an Identity
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.
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 -1 Oracle Database 10g: Implementing Database Vault 5 - 12
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.
Mapping Identities
2 1
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.
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 139.185.35.103. At run time, when the DOMAIN factor is evaluated, if the "Client_IP Equal 139.185.35.103" 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.
Examples of Identities Mapped to Factors
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, 139.185.35.103.
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 139.185.35 subnet, except sessions originating on host 139.185.35.103, then DOMAIN is assigned SECURE. If INTRANET is defined as CLIENT_IP LIKE 139.185.35.% and SECURE as CLIENT_IP = 139.185.35.103, 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.
Deleting Identities
To delete an identity: 1. Navigate to the Edit Factor page. 2. 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.
Integrating Factors and Oracle Label Security

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.
OLS policy
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.
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 Label Security Policies
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)
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)
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.
Factor Labeling
Factors can receive a label: By Self
Label Label
Label Label
By Factors
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.
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.
Identity View
DBA_DV_IDENTITY
FACTOR_NAME VALUE TRUST_LEVEL
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.
Identity Map View
DBA_DV_IDENTITY_MAP DBA_DV_RULE
FACTOR_NAME IDENTITY_VALUE PARENT_FACTOR_NAME CHILD_FACTOR_NAME OPERATION_CODE OPERATION_VALUE OPERAND1 OPERAND2 LABEL_IND
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.
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.
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.
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.
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
Summary
In this lesson, you should have learned how to: Describe the concepts of identities Map identities Manage identities
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
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
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 set result
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 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 set result
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 Sets: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Rule Sets: Dynamic Component Relationships
Realm
Factor Rule set
Command rule
Optional flow
Required flow
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.
Using Rule Sets
Authorize access to objects in
Allow enabling of
Realms
Secure application roles
Command rules
Define execution criteria for
Rule sets
Allow setting of
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.
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.
Creating a Rule Set
Create a rule set by doing the following: 1. Click Create on the Rule Sets page in DVA. 2. Provide the following:
Name Description Status Evaluation Options Audit Options Error Handling Options
3. Click OK to save the rule set. 4. 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.
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.
Adding Existing Rules to a Rule Set
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.
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.
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.
Auditing Rule Sets

AUDIT_TRAIL$
RULE_SET_NAME RULE_NAME
1 Issue a command that violates Database Vault security:

SQL> CREATE TABLE hr.x2 (a INT);
Query the audit table:
SQL> SELECT username, action_command, rule_set_name, rule_name 2> FROM dvsys.audit_trail$;
View the resulting audit record:
USERN ACTION_COMMAND RULE_SET_NAME RULE_NAME ----- ---------------------------- ----------------- ---------------SYS create table hr.x2 (a int) Work Hours APPS Weekday Daytime
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.
Setting a Custom Event Handler
Required
CREATE OR REPLACE PROCEDURE notify_security_mgr (p_ruleset VARCHAR2,p_result VARCHAR2) IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN
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.
Using Rule Sets with Realms
A realms 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.
Assignment Rule Sets for Factors

SQL> EXEC dvsys.set_factor('DOMAIN','LOCAL');
TRUE Factor has rule set? No Yes
Set the factor value
FALSE Rule set
Rule set violation
ORA-47391: Attempt to set Factor DOMAIN violates Rule Set Disabled
Factor cannot be set

ORA-47392: Factor DOMAIN is not settable.
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.
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.
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.
Editing the New Rule Set: Example
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.
Adding Rules to the New Rule Set: Example
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 connections machine name is in the list of approved remote client machines:
upper(dvf.f$machine) in ('RMT001','RMT005','RMT006')
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.
Verifying the Rule Set Logic: Example
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.
Adding the Rule Set to a Factor: Example
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 factors 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.
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
Can Maintain Own Account Rule Set
True if either the user has the DV_ACCTMGR role or the user is maintaining their own account
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.
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.
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
DBA_DV_RULE_SET_RULE
RULE_SET_NAME RULE_NAME RULE_EXPR ENABLED RULE_ORDER
DBA_DV_RULE
NAME RULE_EXPR
Example of Query:
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
Output:
RULE_SET_NAME -------------------------Can Maintain Own Account Disabled Enabled ENABLED ------Y Y Y RULE_NAME --------------Is User Manager False True RULE_EXPR -----------------------------DVSYS.DBMS_MACUTL.USER_HAS_... 1=0 1=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.
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.
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)
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
Practice 6 Overview: Managing Rule Sets

This practice covers the following topics: Creating new rules and rule sets Using a rule set in a realm authorization to further restrict realm access
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
Command Rules: Concepts
Command type Object Owner Rule set Command rule
To perform this command On this object Which is owned by this user This rule set must evaluate to TRUE.
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.
Command Rules: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Command Rules: Dynamic Component Relationships

Realm
Factor Rule set
Command rule
Optional flow
Required flow
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.
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.
Command Rule Attributes

If this is Enabled To perform this command
On this object Which is owned by this user
This rule set must evaluate to TRUE.
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.
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.
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.
OE_ORDERS_DBA has a role created and granted to only himself:
SQL> CREATE ROLE ORDER_APP_DBA; SQL> GRANT order_app_dba TO OE_ORDERS_DBA;
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.

4
Use Database Vault Administrator to create a command rule to prevent altering of OE orderrelated tables.
The user must have the ORDER_APP_DBA role.
The OE_Order_Designer rule set:
Command Rule: Example (continued) 4. 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 rules expression ensures that the requesting user has the ORDER_APP_DBA role, which is created in step 3.
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
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) 5. 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. 6. 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.
Disallowing All Users from ALTER TABLE in a Schema: Example
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.
Delivered Command Rules
ALTER PROFILE CREATE PROFILE
GRANT on SYS.DBMS_RLS REVOKE on SYS.DBMS_RLS
CREATE USER DROP PROFILE DROP USER
DVO user DVSYS 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 managementrelated 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
Delivered Command Rules (continued) Alter user privileges: This defines the list of users who can do such things as change a users 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)
DBA_DV_COMMAND_RULE View
DBA_DV_COMMAND_RULE
COMMAND 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.
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.
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> 2 SQL> 2 SQL> 2 exec DVSYS.DBMS_MACADM.CREATE_COMMAND_RULE ('DROP TABLE','Am HR User','HR','%','N'); exec DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE ('DROP TABLE','Am HR User','HR','%','Y'); exec DVSYS.DBMS_MACADM.DELETE_COMMAND_RULE ('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.
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
Practice 7 Overview: Managing Command Rules

This practice covers creating a command rule to prevent altering of a table.
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
Secure Application Roles: Static Component Context
Realm
Command rule Uses
Rule set
Uses
Factor
Uses
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.
Secure Application Roles: Dynamic Component Relationships

Realm
Factor Rule set
Command rule
Optional flow
Required flow
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.
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.
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 users job role and clients 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.
Using a Secure Application Role
Application 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.
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.
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.
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 139.185.35.%.
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.
Deleting Secure Application Roles
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.
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 kpartner/q1_w2_e3@dv Connected. SQL> select * from hr.employees; select * from hr.employees * ERROR at line 1: ORA-01031: insufficient privileges
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 -------------------------------------------141.144.104.129 SQL> select * from hr.employees 2 where employee_id = 107; select * from hr.employees * ERROR at line 1: ORA-01031: insufficient privileges
Attempt to enable the role from a machine that is on the local subnet:
SQL> connect kpartner/q1_w2_e3@orcl Connected. SQL> select dvf.f$client_ip from dual; F$CLIENT_IP ---------------------------------------------------139.185.35.103 SQL> exec DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_EMP_CLERK'); PL/SQL procedure successfully completed. SQL> select first_name, Last_name, email, salary 2 from hr.employees 3 where employee_id = 107; FIRST_NAME LAST_NAME EMAIL SALARY ---------- ---------- -------- ----------Diana Lorentz DLORENTZ 4,200.00
Secure Application Role Views
DBA_DV_ROLE
ROLE RULE_NAME ENABLED
Secure Application Role Views The following view, in the DVSYS schema, contains secure application rolerelated 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.
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.
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.
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
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
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
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.
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;
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;
Database Vault Monitor
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
Security Policy Changes Detail
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.
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).
Database Configuration and Structural Changes
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.
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.
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.
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
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
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.
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.
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 factors 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.
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.
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
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 passwordprotected 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
Object Privileges by PUBLIC
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.
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.
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.
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.
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_REPAIR DBMS_DDL DBMS_FGA DBMS_RLS DBMS_SESSION DBMS_LOGMNR UTL_HTTP UTL_SMTP UTL_TCP DBMS_RANDOM DBMS_CAPTURE_ADM DBMS_REPCAT_ADMIN DBMS_JOB DBMS_LDAP DBMS_LOB UTL_FILE UTL_SMTP UTL_TCP DBMS_PIPE DBMS_BACKUP_RESTORE DBMS_REPCAT DBMS_DISTRIBUTED_TRUST_ADMIN DBMS_RESOURCE_MANAGER DBMS_RESOURCE_MANAGER_PRIVS DEBUG_EXTPROC DBMS_LOGMNR_D DBMS_OBFUSCATION_TOOLKIT DBMS_ORACLE_TRACE_AGENT
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 ALL_SOURCE ALL_USERS APPROLE$ AUD$ AUDIT_TRAIL$ DBA_ROLE_PRIVS DBA_ROLES DBA_TAB_PRIVS USER_TAB_PRIVS DBMS_BACKUP_RESTORE DEFROLE$ FGA_LOG$ LINK$ OBJ$ OBJAUTH$ OBJPRIV$ PROFILE$ TRIGGER$ USER$ ROLE$ DBA_USERS SOURCE$ SQL_SUMMARY SQLTEXT STATS$ STREAMS SYSTEM_PRIVILEGE_MAP TABLE_PRIVILEGE_MAP PROXY_ROLE_DATA$ PROXY_ROLE_INFO$ USER_HISTORY$ 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.
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
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 reportsobject, system, sensitive, and by granteeprovide 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 10.2.0.1 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.
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.
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 dependencyanalysis 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.
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 users 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.
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 resources 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.
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.
Security Audit Report - Core Database Audit Report

View the database audit records. These are the records from SYS.DBA_AUDIT_TRAIL.
Add Screen shot
Not all columns shown
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.
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.
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.
Summary
In this lesson, you should have learned how to: Produce Database Vault reports Produce general security reports Correct commonly reported issues
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
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 systemprivileged 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
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.
Separation of Duties
Use realms and rule sets together to implement separation of duties.
HR DBA
HR data
Realms Sales DBA
Rule sets Sales data
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 realms 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.
Application DBA: Attributes
ALTER, DROP SELECT APPDBA user SOME_APP objects
Run application
Application users
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 DBA: Implementation

Realm participant ALTER, DROP SELECT Command rule APPDBA user SOME_APP objects
Run application Role membership and existing object privileges
Application users
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 DBA: Example

1
Create a realm to protect the schema:
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:

SQL> GRANT sales_app_user TO sales_app_user_1; SQL> GRANT sales_app_user TO sales_app_user_2;
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 applications 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.

5
Create a rule set requiring the role:
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.

7
Secure the role in a realm:
Application DBA: Example (continued) Protect the new role from misuse: 7. 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.
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.
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.
Dual Key Security: Realm Access Example
$ sqlplus BERNST/q1_w2_e3 SQL> select count(*) from hr.jobs; ORA-01031: insufficient privileges
2 3
SQL> / COUNT(*) ---------19
$ sqlplus hr/hr SQL>
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;
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 users only purpose is to allow another user to run it.
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.
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.
Locking Down SYSDBA

Succeeds with nosysdba option set to N: SQL> CONNECT sys/oracle AS SYSDBA Connected to: Database Vault Release 10.2.0.1.0 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: $ cp pwfile_sysdba orapworcl
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.
Dynamic Auditing
Use a rule sets 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.
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.
Connection Pooling Considerations

SET_FACTOR('X') USER1 SET_FACTOR('Y') USER2 SET_FACTOR('Z') USER3
Application server APPUSER
The rule set evaluates factor.

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.
Enforcing Connections from an Application Server
USER1
USER2
USER3
Application server APPUSER
The rule set ensures that IP address is acceptable before connecting.

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('111.111.111.111','111.111.111.222')
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
NO SQLPLUS secure application role
Rule set enforcing module name is not SQL*Plus
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 programs 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.
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.
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.
Performance Considerations: Unused Factors

Delete unnecessary factors.
CONNECT: GET_FACTOR(); GET_FACTOR(); GET_FACTOR(); 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.
Diagnosing Database Vault Using Trace Files

A session encounters a Database Vault access restriction:
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
The trace file shows that the cause is a realm authorization failure:
*** SESSION ID:(143.99) 2006-05-19 08: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 instances 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.
Enabling and Disabling 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.
Steps for Disabling Database Vault
1. Shut down Oracle processes. 2. Relink Oracle executables without the Database Vault option. 3. Start up the database. 4. 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:

$ sqlplus sys/oracle as sysoper 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
Steps for Enabling Database Vault
1. Run DVCA to enable Database Vault. 2. Stop Oracle processes. 3. Relink Oracle executables with the Database Vault option. 4. 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:

$ sqlplus sys/oracle as sysoper SQL> startup
Password Policy Considerations
Oracle recommends making the following changes to your password policy:

Default FAILED_LOGIN_ATTEMPTS PASSWORD_GRACE_TIME PASSWORD_LIFE_TIME PASSWORD_REUSE_TIME
10 UNLIMITED UNLIMITED UNLIMITED
Recommended
7 3 90 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.
Guidelines for Procedures and Packages
Concern Java Stored Procedures UTL_FILE Package
Remedy
Use invokers rights and realms to protect data Grant execute only to users that require it. Use command rules to control creation of directory objects Grant execute only to users that require it. Use command rules to control EXECUTE on DBMS_FILE_TRANSFER package Use comand rules to control creation of directory objects, and database links
DBMS_FILE_TRANSFER Package
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.
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.
Other Guidelines
Concern Recycle Bin ALTER SYSTEM ALTER SESSION CREATE ANY JOB CREATE JOB
Remedy
Disable Recycle Bin feature or Realm users use DROP PURGE Add command rules to prevent dumps
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.
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
Miscellaneous Practices
Consider the following as you work with Database Vault: Do not put spaces in factor names:
SQL> select "DVF"."F$A B" from dual; ORA-00904: "DVF"."F$A B": invalid identifier
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 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.
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 systemprivileged 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
Practice 10 Overview: Implementing Best Practices

This practice covers implementing Database Vault best practices.
Appendix A Practices
Practice for Lesson 1 Introduction

There is no practice for the Introduction lesson.
Oracle Database 10g: Implementing Database Vault A - 2
Practice for Lesson 2 Installing Database Vault

You are now installing the Oracle Database Vault option. All of the following should be done as the oracle OS user, unless otherwise specified. Where you see a string such as edrsr9p1 as a machine name, substitute the name of your machine. You can find out the host name by entering the hostname command at the OS prompt. Unless otherwise specified, any scripts that are to be run are located in the /home/oracle/labs directory. 1) Open a command shell and stop all Oracle processes, including the database and the listener, and then start the Database Vault runInstaller program. The runInstaller program is located in the /stage/dv/Disk1 directory. 2) Continue with the Database Vault installer, installing Database Vault in the existing ORACLE_HOME directory. The Database Vault owner username should be DVO, and the account manager user should be DVAM. Passwords for each of these users should be oracle_10g. When you are finished with this step, make note of the displayed URL for accessing Enterprise Manager here: ___________________________________________________________ Make note of the URL for the Database Vault Administrator here: ___________________________________________________________ 3) Run the switch_sysdba.sh script to change the password file over to one that allows logging in as SYSDBA. This is required to initially set up the users and roles. 4) Test the database by logging in as SYS by using OS authentication. Why cant you log in in this manner? Log in by supplying SYS/oracle as the username/password combination. Test the connection by executing a SELECT statement. 5) Using a browser, navigate to the Enterprise Manager Database Control page. 6) Test the URL for the Database Vault Administration tool as well, and log in as the DVO user.
Practice 2-1: Installing Database Vault
Practice 2-2: Creating Database Accounts
You now create the roles and database users that are needed throughout these practices. They represent typical user definitions as might exist in an office that has an HR application (based on the HR schema) and a sales application (based on the OE schema). 1) Run the create_users.sql script to create the users and roles you will be using in these practices. The following are the descriptions of the users and roles that are created. You may want to refer to this list throughout the course. SMAVRIS: HR Manager WSMITH: HR Clerk KPARTNER: HR Clerk BERNST: HR Application DBA (has the HR_DBA role) AHUNOLD: Order Entry Application DBA (has the OE_DBA role) 2) Make a backup of the database for use later by running the lab_02_02_02.sh script. This will take several minutes to run.
Practice for Lesson 3 Realms

Practice 3-1: Managing Realms
You are now going to work with realms. The simplest and most basic functionality provided by Database Vault is protecting a schema using a realm. In this practice, you protect an application schema using a realm. Then you authorize only that applications DBA to access the data. You also use a realm to prevent unauthorized granting of a role. 1) To illustrate a security issue you have in your environment, log in as the AHUNOLD user and create an HR.EMPLOYEES_COPY table that is a copy of the HR.EMPLOYEES table. Why is AHUNOLD able to create a table in the HR schema? 2) The HR application DBA, BERNST, notices the new table, and decides to protect the schema from other DBAs. He requests that the security manager protect the schema with a realm. Log on to Data Vault Administrator (DVA) as the DVO user and create a realm called HR Schema that prohibits all users from accessing any objects in the HR schema. 3) Test the created realm by attempting to drop the HR.EMPLOYEES_COPY table as the BERNST user. Why does this fail? 4) Allow the BERNST user to access objects in the HR schema by adding him as a participant in the HR Schema realm. 5) As the BERNST user, reattempt to drop the HR.EMPLOYEES_COPY table. Why does it succeed now? 6) As the AHUNOLD user, attempt to create another table in the HR schema. Why does it fail?
Practice 3-2: Using Realms to Protect Roles
Use a realm to protect access to a role. If a role is protected by a realm, then only members of the realm are able to grant that role. In this practice, you protect a role by using a realm, and then demonstrate that protection by attempting to grant the role in various ways. 1) Use the BERNST user to create a new role called HR_MGR. 2) Create an HR Manager realm and add the HR_MGR role to it. 3) As the BERNST user, attempt to grant the HR_MGR role to SMAVRIS. What is the result? 4) Add SMAVRIS to the HR Manager realm as a participant. 5) Reattempt the grant as described above. What is the result? 6) Edit the realm, and make SMAVRIS an Owner in the realm. 7) Reattempt the grant as described above. What is the result? 8) Make the BERNST user a participant in the HR Manager realm, and then reattempt the grant as described above. What is the result? 9) Make the BERNST user an owner in the HR Manager realm, and then reattempt the grant as described above. What is the result? 10) In this practice, you modified the realm by using four different permutations of making the grantor and grantee a participant or an owner in the realm that protects the role. What actually protects the role from being granted to others?
Practice for Lesson 4 Factors

Practice 4-1: Creating Factors
You now create some factors whose values are evaluated in different ways. One is computed by looking up a user in a table. Others are simpler, computing a value based on the current date and time. In this practice, these factors will not be used to provide any functionality. You simply show their values after you create them to verify that they are functioning properly. 1) Edit the HR Schema realm and add the HR user as an owner. Note that it must be either a participant or owner of this realm in order for the HR user to access its own objects because they are now protected by a realm. 2) Create a function in the HR schema called GET_JOB_ID. This function returns the JOB_ID of the connected user if the user login matches the EMAIL column of the HR.EMPLOYEES table. Use the get_job_id.pls script to create this function. 3) Grant EXECUTE on the get_job_id function to the DVSYS user. 4) Create a factor called JOBROLE. Note that all users in these practices appear in the HR.EMPLOYEES table. So, the JOBROLE factor uses the user ID and matches it to a row in the EMPLOYEES table and determines the JOBROLE from the JOB_ID column. The factor retrieval method is HR.GET_JOB_ID(). 5) Verify that the factor is set. Use the GET_FACTOR function or execute SELECT DVF.F$JOBROLE FROM DUAL as various users including SMAVRIS, KPARTNER, and HR. Note the different values returned. Why are the values different for each user? 6) Create a factor called DayOfWeek that returns the name of the day. Give the factor the Time factor type. The factor should be evaluated for each access. Hint: Use the TO_CHAR(sysdate,DAY) function. 7) Verify that the DayOfWeek factor is set. As any user, call GET_FACTOR or execute SELECT DVF.F$DayOfWeek FROM DUAL. 8) Create a factor called HourOfDay that returns the current hour in 24-hour format. The factor type should be Time, and the evaluation should be By Access. Test the factor after creating it. Hint: Use the TO_CHAR(sysdate,HH24) function. 9) Run the lab_04_01_09.sql script to modify the Retrieval Method for the Client_IP factor. Then select the factor value to make sure it is appropriately set. This modified value is referred to as the zero-padded IP address in the remainder of this course. Note: This script forces the last octet of the IP address to be left-padded with zeros to a length of three digits. For example, if the IP address of the machine is 10.156.49.80, then the actual string returned by this factor is 10.156.49.080.
Practice 4-1: Creating Factors (continued) This is in preparation for the following practices, which make range comparisons of IP addresses.
Practice for Lesson 5 Managing Identities

Practice 5-1: Managing Identities
The Domain factor exists when Database Vault is delivered, but no identities are defined for it. In this practice, you define three Domain identities that connote different levels of trust and access. These can then be used to evaluate whether access can be granted to different areas of the database, under different circumstances. 1) Edit the Domain factor and add three identities to it called SECURE, INTRANET, and INTERNET, with trust levels of Very Trusted, Trusted, and Untrusted, respectively. 2) Create an identity mapping for the SECURE identity. Use the mapping to set the identity to SECURE when the Client_IP factor has a value that is equal to the zero-padded IP address of your machine. Hint: You can determine the IP address of your machine by using the ifconfig OS command. 3) Create an identity mapping for the INTERNET identity. Use the mapping to set the identity to INTERNET when the client machine is not on the local subnet. In this case, the Client_IP factor has a value that is not like the first three octets of the IP address of the student PC. For example, if your PC has an IP address of 192.168.1.10, then the local subnet is 192.168.1. The definition of local subnet can vary depending on the subnet mask defined. The subnet mask for OU classrooms is 255.255.255, a class C subnet. 4) Create an identity mapping for the INTRANET identity. Use the mapping to set the identity to INTRANET when the client machine is on the local subnet, but is not your machine. Because the identities are evaluated in ASCII sort order of the identity name, INTRANET will be evaluated first. Because of this, exclude your PC from the set of machines that will be assigned the INTRANET identity. 5) Test the Domain factor identities. Connect to your machine using the service name, and display the identity of the Domain factor. Then connect to another machine in the classroom, and display the identity again. They should be different. This step requires the use of network services. The network service name for your database is orcl_<machine name>. The machine name is found using the hostname command. If this is different, the instructor will tell you how to set the network service name. 6) Create a factor called IS_HR_DBA. This factor can be used to identify a user as the HR Schema realm owner. Set the Identification to By Factors, and create an identity of TRUE. Create an identity mapping that sets the identity to TRUE when the Session_user factor is equal to BERNST, the current HR application DBA. 7) Delete the IS_HR_DBA factor
Practice for Lesson 6 Managing Rule Sets

Practice 6-1: Managing Rule Sets
Rule sets introduce a lot of flexibility in the configuration of Database Vault components. In this practice, you create rule sets. You then associate those rule sets to a realm to ensure access only under certain circumstances. You also attach a rule set to a factor, making the factor settable when the conditions of the rules are met. 1) Create a rule set called Non Work Hours that enforces the rule that access is allowed only during nonworking hours of a day, which are any hours outside of 8:00 a.m. to 4:59 p.m. local time, Monday through Friday. Assume that the server is in the local time zone. Use two rules: one called Night and one called Weekend. 2) Edit the HR Schema realm and add the Non Work Hours rule set as an authorization rule set for the BERNST participant. 3) As the BERNST user, attempt to create a new table in the HR schema. What happens, and why? 4) Edit the Non Work Hours rule set to have another rule, called Secure, that checks for an identity of SECURE for the Domain factor. This should override the time criteria, allowing a SECURE connected session to have access no matter whether it is during working hours or not. 5) Reattempt creating the HR table as the BERNST user. What is the result? Why?
Practice 6-2: Using Assignment Rule Sets with Factors

1) As the BERNST user, select the JOBROLE factor value. What is it? 2) As the SMAVRIS user, select the JOBROLE factor value. What is it? 3) As the WSMITH user, select the JOBROLE factor value. What is it?
In this practice, you set an assignment rule set for a factor and see the results.
4) As WSMITH, use the DVSYS.SET_FACTOR procedure to attempt to set the JOBROLE factor value to IT_PROG. What happens? Why? 5) Add an assignment rule set to the JOBROLE factor. The rule set should always be true. Use the delivered Enabled rule set. 6) Reattempt to set the factor as the WSMITH user. What happens? Why? 7) Select the JOBROLE factor value to see what it is. 8) Set the factor to xyz and select it to see that it is set. 9) What can you deduce about the ability to set a factor value?
Practice 6-3: Using Rule Sets to Restrict Connection Sources

The JOBROLE factor is now settable, but it is made settable by an always-true rule set. In this exercise, you change the assignment rule set to be something more meaningful, requiring that the session have a specific context setup, and a specific role active. 1) Create the rule set HR_REP hrmaint that ensures that the job ID is HR_REP and the running program is hrmaint. (This will be used in the Secure Application Roles practice.) 2) Test the new rule set. Make it the assignment rule set for the JOBROLE factor and attempt to execute the same SET_FACTOR call as was done in the previous practice. The SET_FACTOR call should now fail. When finished testing, set the factors assignment rule set back to its original setting.
Practice for Lesson 7 Command Rules

Practice 7-1: Using Command Rules
You are now going to work with command rules. First, you prevent the creation of a view by using a command rule. 1) As the AHUNOLD user, create the OE.BIG_ORDERS view that is defined as all OE.ORDERS rows where the ORDER_TOTAL is greater than 100000. Then drop the view. 2) Create a command rule that prevents users from issuing the CREATE VIEW command on OE objects unless it is during nonworking hours. Use the Non Work Hours rule set. 3) Reattempt the CREATE VIEW command as the AHUNOLD user. What happens? Why?
Practice 7-2: Protecting the Data

You create a rule set that prevents AHUNOLD from selecting his own data, but he can still alter and create objects. This is the method to prevent an application DBA from reading the data in the objects he or she manages. 1) As AHUNOLD, select data from one of the OE tables. This should succeed. 2) As AHUNOLD, create a new test table. Drop the table. These should succeed. 3) Create a (traditional) role called APP_USER, as the SYSTEM user. 4) Create a rule set called HAS APP USER that ensures that the user has the APP_USER role.
5) Create a command rule SELECT OE.% that uses the HAS APP USER rule set. 6) Reattempt to SELECT from OE tables as AHUNOLD. This should fail. Why? 7) As the AHUNOLD user, create a new table and drop it. This should still succeed. 8) Confirm that it is the absence of the APP_USER role that is preventing SELECT access. Do this by granting this role to BERNST and retrying the SELECT statement. Then revoke the role.
Practice 7-3: Preventing Accidents
Sometimes, to prevent accidents, you may want to define a peculiar way to execute a certain command. This requires some thought on the part of the user who is executing the command. In this practice, you prevent the recompiling of functions unless the word function is capitalized in a special way. 1) Recompile the GET_JOB_ID function while logged in as the BERNST user. Recall that, because of the Non Work Hours rule set, you must override the work hours requirement by logging in with a service name, which causes the Domain factor to be set to the SECURE identity. You can simply use the orcl service name when logging in to the local database. This recompile should work because BERNST has access to the HR schema via the HR Schema realm. 2) Create a command rule that prevents recompilation of functions in the HR schema unless the keyword FunctioN appears in the statement, with only the first and last letters capitalized. Create a rule set called FunctioN in order to implement this command rule. 3) Test the new command rule by attempting to compile the GET_JOB_ID function as the BERNST user. For this test, simply capitalize the FUNCTION keyword as you normally would: either in all capitals or in all lowercase. 4) Reattempt the ALTER FUNCTION statement, but this time capitalize only the first and last characters of the function keyword.
Practice for Lesson 8 Managing Secure Application Roles

You now use secure application roles to control what users can execute a procedure. You create a secure application role that uses a rule set you defined previously. You grant the ability to execute a procedure to the secure application role, which means that the session must meet the conditions of the roles associated rule set in order to execute the procedure. 1) As the HR user, issue a grant statement so that SMAVRIS will be able to select rows from the HR.EMPLOYEES table. 2) As the SMAVRIS user, view the HR.EMPLOYEES table. 3) As the SMAVRIS user in SQL*Plus, attempt to give every employee a 5% raise. 4) Create a secure application role called HR_APP that uses the HR_REP hrmaint rule set. 5) Create the HR.GIVE_RAISE procedure by running the give_raise.pls script while logged in as the HR user. This script creates a procedure GIVE_RAISE(EMP_ID,RAISE_PERCENT). It can be viewed as follows: 6) While still connected as HR, grant the EXECUTE privilege on the GIVE_RAISE procedure to the HR_APP secure application role. 7) As the SMAVRIS user, attempt to run the GIVE_RAISE procedure. Attempt to give the employee with the ID of 106 a raise of 5%. What is the result? Why? 8) To meet the requirements of the rule set on the HR_APP role, the session calling the SET_ROLE function must be known to the database as hrmaint. Call DBMS_APPLICATION_INFO.SET_MODULE to set the module to hrmaint. 9) Call SET_ROLE to enable the HR_APP secure application role. 10) Reattempt the GIVE_RAISE procedure, still logged in as SMAVRIS. What is the result? Why? 11) Verify that the raise was applied by querying for the salary of employee number 106 and compare it with the previous result. 12) Roll back the transaction and exit SQL*Plus.
Practice 8-1: Managing Secure Application Roles
Practice for Lesson 9 Viewing Reports

Practice 9-1: Viewing Reports
This practice guides you through several reports available in DVA. You may run others that are not specified here, if you want to. 1) For Database Vault Monitor to report on configuration changes and violations, the AUDIT_TRAIL initialization parameter must be set to DB. The AUDIT_TRAIL parameter is static and can be changed only in the spfile, after which the database must be restarted for the change to take effect. Set this parameter to DB, and restart the database. 2) Create a new user named SEC with a password of q1_w2_e3. This user serves the purpose of a security auditor that will view reports and configuration information, but does not have the privileges to change the Database Vault configuration. Verify that this user can view the reports, and view the edit pages for the various DV objects, but cannot change the DV objects. 3) Run the lab_09_01_03.sql script to create some Database Vault components that are not correctly configured. This will provide some data for the reports you are about to run. 4) Run the lab_09_01_04.sql script that generates violations of various realms, rules, and factors. 5) Run the lab_09_01_05.sql script that grants privileges that should not be normally granted. 6) View the Database Vault Monitor for changes and violations. 7) View the Database Vault reports and find the misconfigured items. 8) View the Database Vault Audit reports and note any violations. 9) View the General Security System reports. Many of these reports are considered standard reports needed to view the security aspects of the database. Run some sample reports: a) Hierarchical System Privileges by Database Account for DVO b) Execute Privileges to Strong SYS Packages report c) Accounts With DBA Role report d) OS Security Vulnerability Privileges report e) Security-Related Database Parameter report f) Database Account Status report g) Other reports as you desire 10) Run the lab_09_01_cleanup.sql script to remove the incomplete and misconfigured items.
Practice for Lesson 10 Best Practices

Practice 10-1: Defining Application DBAs
Your company has hired an internal auditor to periodically check the IT systems in order to make independent audits happen more smoothly. The following practices represent some common situations that may need correcting in order to meet audit requirements. First, restore the backup taken at the beginning of this class. That guarantees that any mistakes made up to this point will not affect these practices. 1) Restore from the backup that was taken at the end of the installation practice by running the lab_10_01.sh script. 2) The auditor asks you to show him which database users have the SELECT ANY TABLE privilege. Run a report to show that information. 3) Based upon that report, you and the auditor see that there are users who can read any table in the database even if they do not need it. Create realms to protect each individual schema, and allow each application DBA to access its own realm-protected data. 4) Prove to the auditor that the users with SELECT ANY TABLE can no longer read realm-protected tables outside of their realm.
The auditor realizes that the application DBAs are now locked into their realms, but wants further controls on who can become an application DBA. You need to restrict the usage of these roles to be only where the Action for the session is ADMIN. You decide to revoke the application roles from all users, and, instead, define new secure application roles that can have a rule set that can implement the requirements of the auditor. Then, lock down the HR_DBA and OE_DBA roles so that they can no longer be granted to anyone without the intervention of the DVO user. 1) Create a factor called ACTION that represents the ACTION context value for the session. 2) Create a rule set called ADMIN that ensures that the ACTION factor is equal to ADMIN. 3) Create the OE_DBA_SAR and HR_DBA_SAR secure application roles. The rule set to be satisfied for each of these is ADMIN. 4) Revoke the OE_DBA and HR_DBA roles from all users that have them. 5) Grant the OE_DBA and HR_DBA roles to the new secure application roles, respectively. 6) Test the new secure application roles by logging in and setting the Action application information variable to ADMIN, ensuring that it allows you to read the data as the appropriate user. You must enable the role to see the data. Test to see whether you cannot see the data if you do not enable the role in the session. Do this for the BERNST user and for the AHUNOLD user. 7) Lock down the HR_DBA and OE_DBA roles so that they can no longer be granted to anyone, without having DVO intervene. 8) Test to illustrate that these two roles can no longer be granted.
Practice 10-2: Locking Down the DBA Roles
You understand that as well as preventing intentional unwanted data manipulation, you also need to guard against accidental loss of data. There are certain commands you want to control the use of, and one of them is DROP TABLE. You need to implement safeguards against this command executing accidentally, which is a practice one may follow in a production database. In this practice, you set up a command rule that will require a simple action on the part of the DVO user in order to perform a DROP TABLE. 1) Create the DROP TABLE command rule that has Disabled as its rule set. 2) Test the command rule by creating and then dropping a table. Use the SH user for these tests. First create a test table, and then attempt to drop it. 3) Use DVA to set the rule set for the DROP TABLE command rule to Enabled, and then reattempt the DROP command.
Practice 10-3: Preventing Data Loss
Practice 10-4: Disabling SYSDBA

The auditor notices that you log in as SYSDBA to perform certain tasks. He asks whether you can disable that. You do that by creating a nosysdba version of the password file. 1) Back up the existing password file. 2) Run the orapwd utility to create a nosysdba version of a password file. 3) Show the auditor that you can no longer log in as SYSDBA.
Appendix B Practice Solutions
Practice Solutions for Lesson 1 Introduction

There is no practice for the Introduction lesson.
Oracle Database 10g: Implementing Database Vault B - 2
Practice Solutions for Lesson 2 Installing Database Vault

You are now installing the Oracle Database Vault option. All of the following should be done as the oracle OS user, unless otherwise specified. Where you see a string such as edrsr9p1 as a machine name, substitute the name of your machine. You can find out the host name by entering the hostname command at the OS prompt. Unless otherwise specified, any scripts that are to be run are located in the /home/oracle/labs directory. 1) Open a command shell and stop all Oracle processes, including the database and the listener, and then start the Database Vault runInstaller program. The runInstaller program is located in the /stage/dv/Disk1 directory. Answer: 1. Double-click the Xterm icon on the desktop. This brings up a command window. 2. Start SQL*Plus by entering the following at the OS command prompt:
$ sqlplus / as sysdba
Solutions for Practice 2-1: Installing Database Vault
3. Shut down the database server by entering the following at the SQL*Plus prompt:
SQL> shutdown immediate
4. Quit SQL*Plus by entering the following at the SQL*Plus prompt:

SQL> exit
5. Start the listener control utility by entering the following at the OS command prompt:
$ lsnrctl
6. At the lsnrctl prompt, stop the listener by entering the following:

LSNRCTL> stop
7. Exit the listener control utility by entering the following at the lsnrctl prompt:
LSNRCTL> exit
8. Change to the directory where the Database Vault software is staged by entering the following at the OS command prompt:
$ cd /stage/dv/Disk1
9. Start the Database Vault installer by entering the following at the OS command prompt:
$ ./runInstaller
After several seconds, the Installation Details installer page is displayed.
Solutions for Practice 2-1: Installing Database Vault (continued) 2) Continue with the Database Vault installer, installing Database Vault in the existing ORACLE_HOME directory. The Database Vault owner username should be DVO, and the account manager user should be DVAM. Passwords for each of these users should be oracle_10g. When you are finished with this step, make note of the displayed URL for accessing Enterprise Manager here: ___________________________________________________________ Make note of the URL for the Database Vault Administrator here: ___________________________________________________________ Answer: 1. On the Installation Details page, specify the following, and then click Next: Destination Path: /u01/app/oracle/product/10.2.0/db_1 Database Vault Owner: dvo All password fields: oracle_10g Create a Separate Account Manager: Yes, select this check box. Database Vault Account Manager: dvam
Solutions for Practice 2-1: Installing Database Vault (continued) 2. On the Existing Database page, enter oracle for both password fields, and then click Next.
3. A status bar appears for a few seconds, followed by a warning that the Database Vault installation is going to modify your system. Click OK in the warning window.
Solutions for Practice 2-1: Installing Database Vault (continued)
4. The Product-Specific Prerequisite Checks window appears. After the checks are completed, review the status to ensure that they have each Succeeded. Then click Next.
Solutions for Practice 2-1: Installing Database Vault (continued) 5. When the Summary page appears, expand the New Installations tree item to see the Database Vault options that are being installed. Then click Install.
Solutions for Practice 2-1: Installing Database Vault (continued) 6. As the installation starts, note the reported progress on the Configuration Assistants page:
Solutions for Practice 2-1: Installing Database Vault (continued) 7. The End of Installation page appears. Click Exit to finish the Database Vault installation, and then click Yes to confirm.
3) Run the switch_sysdba.sh script to change the password file over to one that allows logging in as SYSDBA. This is required to initially set up the users and roles.
$ cd ~/labs $ ./switch_sysdba.sh sysdba
4) Test the database by logging in as SYS using OS authentication. Why cant you log in in this manner? Log in by supplying SYS/oracle as the username/password combination. Test the connection by executing a SELECT statement. Answer: 1. Enter the following at the OS command prompt:
$ sqlplus / as sysdba ORA-01031: insufficient privileges
2. Press and hold [Ctrl] + [D] to escape the username prompt. 3. To log in to SQL*Plus, enter the following at the OS command prompt:
$ sqlplus sys/oracle as sysdba
Solutions for Practice 2-1: Installing Database Vault (continued) 4. Ensure that the database is running by entering the following at the SQL*Plus command prompt:
SQL> select sysdate from dual; SYSDATE --------28-MAR-06
5. Quit SQL*Plus by entering the following at the SQL*Plus prompt:

SQL> exit
5) Using a browser, navigate to the Enterprise Manager Database Control page. Answer: 1. Start the Mozilla browser by double-clicking the Mozilla icon on the desktop. If prompted to select a Mozilla profile, choose oracle and click Start Mozilla. Then navigate to the following URL:
http://localhost:1158/em
6) Test the URL for the Database Vault Administration tool as well, and log in as the DVO user. Answer: 1. Enter the following URL into the browser address bar. Note: Either the literal machine name (obtained by issuing the hostname OS command) or you may use the name localhost.
http://localhost:1158/dva
Solutions for Practice 2-1: Installing Database Vault (continued) 2. Note that the login screen appears. Log in as the DVO user by entering DVO in the User Name field, and oracle_10g in the Password field. Click Login. 3. The DVA home page appears. You now see that you have successfully installed the Oracle Database Vault option.
Solutions for Practice 2-2: Creating Database Accounts
You now create the roles and database users that are needed throughout these practices. They represent typical user definitions as might exist in an office that has an HR application (based on the HR schema) and a sales application (based on the OE schema). 1) Run the create_users.sql script to create the users and roles you will be using in these practices. The following are the descriptions of the users and roles that are created. You may want to refer to this list throughout the course. SMAVRIS: HR Manager WSMITH: HR Clerk KPARTNER: HR Clerk BERNST: HR Application DBA (has the HR_DBA role) AHUNOLD: Order Entry Application DBA (has the OE_DBA role) Answer: 1. Enter the following at the OS prompt:
$ cd ~/labs $ sqlplus /nolog @create_users
2) Make a backup of the database for use later by running the lab_02_02_02.sh script. This will take several minutes to run. Answer: 1. Enter the following at the OS prompt:
$ ~/labs/lab_02_02_02.sh
Practice Solutions for Lesson 3 Realms

Solutions for Practice 3-1: Managing Realms
You are now going to work with realms. The simplest and most basic functionality provided by Database Vault is protecting a schema using a realm. In this practice, you protect an application schema using a realm. Then you authorize only that applications DBA to access the data. You also use a realm to prevent unauthorized granting of a role. 1) To illustrate a security issue you have in your environment, log in as the AHUNOLD user and create an HR.EMPLOYEES_COPY table that is a copy of the HR.EMPLOYEES table. Why is AHUNOLD able to create a table in the HR schema? Answer: 1. At the OS prompt, enter the following to log in as the AHUNOLD user:
$ sqlplus ahunold/q1_w2_e3
2. To create the table, enter the following at the SQL*Plus prompt:

SQL> create table hr.employees_copy as > select * from hr.employees;
3. AHUNOLD is able to create a table in the HR schema because AHUNOLD has been granted the DBA role, which has the CREATE ANY TABLE system privilege. 2) The HR application DBA, BERNST, notices the new table, and decides to protect the schema from other DBAs. He requests that the security manager protect the schema with a realm. Log on to Data Vault Administrator (DVA) as the DVO user and create a realm called HR Schema that prohibits all users from accessing any objects in the HR schema. Answer: 1. On the DVA Administration tabbed page, click Realms.
Solutions for Practice 3-1: Managing Realms (continued) 2. On the Realms page, click Create.
3. On the Create Realm page, name the realm HR Schema, and provide a description. The Status should remain as Enabled. Then click OK.
Solutions for Practice 3-1: Managing Realms (continued) 4. Edit the HR Schema realm by selecting it and clicking Edit.
5. Click Create in the Realm Secured Objects region.
6. Choose HR as the Object Owner. Choose % as the Object Type and set Object Name to %. Then click OK.
3) Test the created realm by attempting to drop the HR.EMPLOYEES_COPY table as the BERNST user. Why does this fail? Answer: 1. Log in to SQL*Plus as the BERNST user by entering the following at the OS prompt. First, exit SQL*Plus if already connected as another user.
$ sqlplus bernst/q1_w2_e3 Oracle Database 10g: Implementing Database Vault B - 15
Solutions for Practice 3-1: Managing Realms (continued) 2. Attempt to drop the HR.EMPLOYEES_COPY table by entering the following at the SQL*Plus prompt:
SQL> drop table hr.employees_copy; drop table hr.employees_copy * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for drop table on HR.EMPLOYEES_COPY ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
3. This DROP fails because the HR schema objects, including this table, are protected by the HR Schema realm and the BERNST user is not a member of that realm. 4) Allow the BERNST user to access objects in the HR schema by adding him as a participant in the HR Schema realm. Answer: 1. In DVA, click the Realms link in the history trail at the top of the page.
2. Select the HR Schema realm, and click Edit.
3. Click Create in the Realm Authorizations region.
4. Select BERNST as the Grantee.

Solutions for Practice 3-1: Managing Realms (continued) 5. Set the Authorization Type to Participant.
6. Click OK. 5) As the BERNST user, reattempt to drop the HR.EMPLOYEES_COPY table. Why does it succeed now? Answer: 1. Attempt to drop the HR.EMPLOYEES_COPY table by entering the following at the SQL*Plus prompt of the BERNST session:
SQL> drop table hr.employees_copy; Table dropped.
2. This succeeds now because BERNST has been made a participant in the HR Schema realm, allowing him to access objects that are protected by it. 6) As the AHUNOLD user, attempt to create another table in the HR schema. Why does it fail? Answer: 1. Connect as AHUNOLD in the SQL*Plus session by entering the following at the SQL*Plus prompt:
SQL> connect ahunold/q1_w2_e3
2. Attempt to create a table in the HR schema by entering the following at the SQL*Plus prompt:
SQL> create table hr.x (a number); create table hr.x (a number) * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for create table on HR.X ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
Solutions for Practice 3-1: Managing Realms (continued) 3. This fails because only BERNST has been made a participant in the realm that protects the HR schema. AHUNOLD is still not a participant and, therefore, cannot access the HR objects.
Solutions for Practice 3-2: Using Realms to Protect Roles
Use a realm to protect access to a role. If a role is protected by a realm, then only members of the realm are able to grant that role. In this practice, you protect a role by using a realm, and then demonstrate that protection by attempting to grant the role in various ways. 1) Use the BERNST user to create a new role called HR_MGR. Answer: 1. Log in to SQL*Plus as BERNST, as shown. Exit SQL*Plus if already connected as another user.
$ sqlplus bernst/q1_w2_e3
2. Create the HR_MGR role by entering the following at the SQL*Plus prompt:
SQL> create role hr_mgr;
2) Create an HR Manager realm and add the HR_MGR role to it. Answer: 1. In DVA, click the Administration tab, and then click Realms. 2. Click Create to begin the realm creation. 3. Enter HR Manager as the Name of the realm, and provide a description. Retain the default values for all other fields, and then click OK.
Solutions for Practice 3-2: Using Realms to Protect Roles (continued) 4. Select the HR Manager realm, and click Edit. 5. In the Realm Secured Objects region, click Create. 6. On the Create Realm Secured Object page, select ANONYMOUS as the Object Owner, ROLE as the Object Type, and enter HR_MGR in the Object Name field.
7. Click OK, and then review the newly secured object.
3) As the BERNST user, attempt to grant the HR_MGR role to SMAVRIS. What is the result? Answer: 1. Return to the BERNST SQL*Plus session, and attempt to grant the new role to SMAVRIS by entering the following at the prompt:
SQL> grant hr_mgr to smavris; grant hr_mgr to smavris * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for grant role privilege on NULL.NULL ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
4) Add SMAVRIS to the HR Manager realm as a participant.
Solutions for Practice 3-2: Using Realms to Protect Roles (continued) Answer: 1. Return to DVA, where the Edit Realm: HR Manager page is still displayed. Click Create in the Realm Authorizations region. 2. Select SMAVRIS as Grantee, and retain the default values for the rest of the fields.
3. Click OK. 5) Reattempt the grant as described above. What is the result? Answer: 1. Return to the BERNST SQL*Plus session, and enter the following at the SQL prompt:
SQL> grant hr_mgr to smavris; grant hr_mgr to smavris * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for grant role privilege on HR_MGR. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
6) Edit the realm, and make SMAVRIS an Owner in the realm. Answer: 1. Return to DVA, where the Edit Realm: HR Manager page is still displayed. Select the SMAVRIS row in the Realm Authorizations region, and then click Edit. 2. Change the Authorization Type to Owner, and then click OK.
Solutions for Practice 3-2: Using Realms to Protect Roles (continued)
7) Reattempt the grant as described above. What is the result? Answer: 1. Return to the BERNST SQL*Plus session, and enter the following at the SQL prompt:
8) Make the BERNST user a participant in the HR Manager realm, and then reattempt the grant as described above. What is the result? Answer: 1. Return to DVA, where the Edit Realm: HR Manager page is still displayed. Click Create in the Realm Authorizations region. 2. On the Create Realm Authorization page, select BERNST as the Grantee, and keep the default values in the rest of the fields. 3. Click OK. 4. Return to the BERNST SQL*Plus session, and enter the following at the SQL prompt:
Solutions for Practice 3-2: Using Realms to Protect Roles (continued) 9) Make the BERNST user an owner in the HR Manager realm, and then reattempt the grant as described above. What is the result? Answer: 1. Return to DVA, where the Edit Realm: HR Manager page is still displayed. Select BERNST in the Realm Authorizations region, and then click Edit. 2. Change the Authorization Type to Owner, and then click OK.
3. Return to the BERNST SQL*Plus session, and enter the following at the SQL prompt:
SQL> grant hr_mgr to smavris; Grant succeeded.
10) In this practice, you modified the realm by using four different permutations of making the grantor and grantee a participant or an owner in the realm that protects the role. What actually protects the role from being granted to others? Answer: 1. All that is necessary is that the grantor must be an owner in the realm that protects the role. Whether the grantee is in the realm or not does not matter.
Practice Solutions for Lesson 4 Factors

Solutions for Practice 4-1: Creating Factors
You now create some factors whose values are evaluated in different ways. One is computed by looking up a user in a table. Others are simpler, computing a value based on the current date and time. In this practice, these factors will not be used to provide any functionality. You simply show their values after you create them, to verify that they are functioning properly. 1) Edit the HR Schema realm and add the HR user as an owner. Note that it must be either a participant or owner of this realm in order for the HR user to access its own objects because they are now protected by a realm. Answer: 1. Click Realms on the Administration tabbed page of DVA. 2. Select the HR Schema realm and click Edit. 3. In the Realm Authorizations region, click Create.
4. On the Create Realm Authorization page, choose HR as the Grantee, and set the Authorization Type to Owner. Then click OK.
Solutions for Practice 4-1: Creating Factors (continued) 2) Create a function in the HR schema called GET_JOB_ID. This function returns the JOB_ID of the connected user if the user login matches the EMAIL column of the HR.EMPLOYEES table. Use the get_job_id.pls script to create this function. Answer: 1. Run the get_job_id.pls script as the HR user by entering the following in SQL*Plus:
SQL> connect hr/hr Connected. SQL> @$HOME/labs/get_job_id.pls Function created.
3) Grant EXECUTE on the get_job_id function to the DVSYS user. Answer: 1. While logged in as HR, enter the following to grant EXECUTE on the get_job_id function to DVSYS:
SQL> grant execute on get_job_id to DVSYS; Grant succeeded.
4) Create a factor called JOBROLE. Note that all users in these practices appear in the HR.EMPLOYEES table. So, the JOBROLE factor uses the user ID and matches it to a row in the EMPLOYEES table and determines the JOBROLE from the JOB_ID column. The factor retrieval method is HR.GET_JOB_ID(). Answer: 1. Navigate to the Factors page and click Create.
2. Enter JOBROLE as the factor name, and HR.GET_JOB_ID() as the retrieval method. Then click OK.
Solutions for Practice 4-1: Creating Factors (continued)
5) Verify that the factor is set. Use the GET_FACTOR function or execute SELECT DVF.F$JOBROLE FROM DUAL as various users including SMAVRIS, KPARTNER, and HR. Note the different values returned. Why are the values different for each user? Answer: 1. Connect as various users and execute SELECT DVF.F$JOBROLE FROM DUAL by entering the following into the SQL*Plus session:
SQL> connect SMAVRIS/q1_w2_e3 Connected. SQL> select dvf.F$JOBROLE from dual; F$JOBROLE --------------------------------------------------------HR_REP SQL> connect kpartner/q1_w2_e3 Connected. SQL> select dvf.F$JOBROLE from dual; F$JOBROLE --------------------------------------------------------SA_MAN SQL> connect HR/HR

Connected. SQL> select dvf.F$JOBROLE from dual; F$JOBROLE --------------------------------------------------------SQL>
2. Note that the JOBROLE factor has a non-NULL identity for user IDs that exist in the HR.EMPLOYEES table. Otherwise, it is NULL. The HR user is not listed in the EMPLOYEES table. 6) Create a factor called DayOfWeek that returns the name of the day. Give the factor the Time factor type. The factor should be evaluated for each access. Hint: Use the TO_CHAR(sysdate,DAY) function. Answer: 1. In DVA, navigate to the Factors page and click Create. 2. Enter DayOfWeek in the Name field. Enter a description. Set Factor Type to Time. Set Evaluation to By Access. Enter TO_CHAR(sysdate,DAY) as the Retrieval Method. Leave the default values for all other settings. Then click OK.
7) Verify that the DayOfWeek factor is set. As any user, call GET_FACTOR or execute SELECT DVF.F$DayOfWeek FROM DUAL. Answer: 1. Test the DayOfWeek factor as any user by entering the following in SQL*Plus:

SQL> SELECT DVF.F$DAYOFWEEK FROM DUAL; F$DAYOFWEEK -------------------------------------------------------WEDNESDAY SQL>
8) Create a factor called HourOfDay that returns the current hour in 24-hour format. The factor type should be Time, and the evaluation should be By Access. Test the factor after creating it. Hint: Use the TO_CHAR(sysdate,HH24) function. Answer: 1. Navigate to the Factors page in DVA, and click Create. 2. Name the factor HourOfDay, provide a description, set Factor Type to Time, and Evaluation to By Access. 3. Set Retrieval Method to the following expression:
TO_CHAR(sysdate,HH24)
4. Retain the default values for all other settings, and then click OK.
5. Test the factor by entering the following in SQL*Plus:

SQL> SELECT DVF.F$HOUROFDAY from DUAL; F$HOUROFDAY

-------------------------------------------------------11 SQL>
9) Run the lab_04_01_09.sql script to modify the Retrieval Method for the Client_IP factor. Then select the factor value to make sure it is appropriately set. This modified value is referred to as the zero-padded IP address in the remainder of this course. Note: This script forces the last octet of the IP address to be left-padded with zeros to a length of three digits. For example, if the IP address of the machine is 10.156.49.80, then the actual string returned by this factor is 10.156.49.080. This is in preparation for the following practices, which make range comparisons of IP addresses. Answer: 1. At the SQL*Plus prompt, enter the following:
SQL> @lab_04_01_09 Connected. PL/SQL procedure successfully completed.
Commit complete. SQL> connect hr/hr@orcl Connected. SQL> select dvf.f$client_ip from dual; F$CLIENT_IP ----------10.156.49.080 SQL>
Practice Solutions for Lesson 5 Managing Identities

Solutions for Practice 5-1: Managing Identities
The Domain factor exists when Database Vault is delivered, but no identities are defined for it. In this practice, you define three Domain identities that connote different levels of trust and access. These can then be used to evaluate whether access can be granted to different areas of the database, under different circumstances. 1) Edit the Domain factor and add three identities to it called SECURE, INTRANET, and INTERNET, with trust levels of Very Trusted, Trusted, and Untrusted, respectively. Answer: 1. Navigate to the Factors page in DVA, select the Domain factor, and click Edit. 2. In the Identities region of the Edit Factor page, click Create.
3. Enter SECURE in the Value field, and set the Trust Level to Very Trusted. Then click OK.
4. Repeat steps 1 through 3 above, once for the INTRANET identity with a Trusted trust level, and once for the INTERNET identity with an Untrusted trust level. 5. Review the three identities that you have just defined for the Domain factor.
Solutions for Practice 5-1: Managing Identities (continued)
2) Create an identity mapping for the SECURE identity. Use the mapping to set the identity to SECURE when the Client_IP factor has a value that is equal to the zero-padded IP address of your machine. Hint: You can determine the IP address of your machine by using the ifconfig OS command. Answer: 1. On the Edit Factor: Domain page, select the SECURE identity and click Edit.
Solutions for Practice 5-1: Managing Identities (continued) 2. On the Edit Identity: SECURE page, click Create in the Map Identity region.
3. On the Create Identity Map page, choose Client_IP as the Contributing Factor, and choose Equal as the Map Condition. Enter the zero-padded IP address of your machine in the Low Value field and then click OK. Remember that the zero padding applies only to the last octet.
4. Back on the Edit Identity: SECURE page, click OK to save the mapping definition for the SECURE identity. 3) Create an identity mapping for the INTERNET identity. Use the mapping to set the identity to INTERNET when the client machine is not on the local subnet. In this case, the Client_IP factor has a value that is not like the first three octets of the IP address of the student PC. For example, if your PC has an IP address of 192.168.1.10, then the local subnet is 192.168.1. The definition of local subnet can vary depending on the subnet mask defined. The subnet mask for OU classrooms is 255.255.255, a class C subnet. Answer: 1. On the Edit Factor: Domain page, select the INTERNET identity and click Edit. 2. In the Map Identity region of the Edit Identity page, click Create. 3. On the Create Identity Map page, select Client_IP as the Contributing Factor and Not Like as the Map Condition, and then enter the IP address of your machine in the Low Value field, replacing the last octet with the percentage sign. Click OK.
4. Back on the Edit Identity: INTERNET page, click OK to save the mapping definition for the INTERNET identity. 4) Create an identity mapping for the INTRANET identity. Use the mapping to set the identity to INTRANET when the client machine is on the local subnet, but is not your machine. Because the identities are evaluated in ASCII sort order of the identity name, INTRANET will be evaluated first. Because of this, exclude your PC from the set of machines that will be assigned the INTRANET identity. Answer: 1. On the Edit Factor: Domain page, select the INTRANET identity and click Edit. 2. In the Map Identity region of the Edit Identity page, click Create. 3. On the Create Identity Map page, select Client_IP as the Contributing Factor. 4. Choose Between as the Map Condition. Then enter your machines IP address in the Low Value field, replacing the last octet with 001. 5. Enter your machines zero-padded IP address in the High Value field, replacing the last octet with the number that is one less than your machines last octet value. Then click OK. In the example shown below, the machines IP address is 10.156.49.80, so the zero-padded number that is entered is 10.156.49.079.
6. You have now taken care of the range of IP addresses below your machines address. Back on the Edit Identity: INTRANET page, review the mapping you just created.
7. Click Create in the Map Identity region again, to take care of the IP addresses above your machines address. 8. Set the Contributing Factor to Client_IP and Map Condition to Between. 9. Enter your machines zero-padded IP address in the Low Value field, adding one to the last octet value. 10. Enter your machines IP address in the High Value field, changing the last octet to 255. Then click OK.
11. Review the mappings you just created. Ensure that the IP address ranges cover all IP addresses in your subnet except for that of your machine.
5) Test the Domain factor identities. Connect to your machine using the service name, and display the identity of the Domain factor. Then connect to another machine in the classroom, and display the identity again. They should be different. This step requires the use of network services. The network service name for your database is orcl_<machine name>. The machine name is found using the hostname command. If this is different, the instructor will tell you how to set the network service name. Answer: 1. Confirm the service name by showing your machine name and prepending orcl_ to it. Then use tnsping to test the service name.
$ hostname edrsr3p1

[oracle@ed66r1p0 labs]$ tnsping orcl_edrsr3p1 . . . OK (30 msec) $
2. Connect to the database using SQL*Plus, using a network service name for your machine. Verify that the identity of the Domain factor is SECURE.
SQL> connect hr/hr@orcl_edrsr3p1 Connected. SQL> select dvf.f$domain from dual; F$DOMAIN --------------------------------------------------------SECURE SQL>
3. Connect to the database using SQL*Plus, but without using a service name. What is the identity of the Domain factor in this case? Why?
SQL> connect hr/hr Connected. SQL> select dvf.f$domain from dual; F$DOMAIN --------------------------------------------------------INTERNET SQL>
The answer is that the identity is NULL. This is because when you log in without a service name, the IP address is not set for the session. So, the only identity mapping that matches this condition is the first one, according to the ASCII sort order that says that the IP address is not like the subnet string. Note that the order does not matter in this case because this is the only mapping of the three that has a satisfactory condition. 4. Connect to your database using a SQL*Plus session that emanates from a different machine in the classroom. Use the ssh utility to start a session on the instructor machine. (The instructor may provide an alternate machine or IP address for this purpose). Verify that Domain is set to INTRANET. The commands to do this are somewhat like the following:
[oracle@edrsr3p1 oracle]$ ssh edrsr10p1 The authenticity of host 'edrsr10p1 (139.185.35.110)' can't be established. RSA key fingerprint is 27:d8:73:3d:25:d1:5a:1a:4d:54:f4:b8:b5:bc:a9:48. Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'edrsr10p1,139.185.35.110' (RSA) to the list of known hosts. oracle@edrsr10p1's password: -bash: ulimit: max user processes: cannot modify limit: Operation not permitted [oracle@edrsr10p1 oracle]$ sqlplus hr/hr@orcl_edrsr3p1 SQL*Plus: Release 10.2.0.1.0 - Production on Wed Aug 9 08:53:16 2006 Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options SQL> select dvf.f$domain from dual; F$DOMAIN -------------------------------------------------------INTRANET SQL>
6) Create a factor called IS_HR_DBA. This factor can be used to identify a user as the HR Schema realm owner. Set the Identification to By Factors, and create an identity of TRUE. Create an identity mapping that sets the identity to TRUE when the Session_user factor is equal to BERNST, the current HR application DBA. Answer: 1. Navigate to the Factors page in DVA, and click Create. 2. On the Create Factor page, enter IS_HR_DBA as the Name, provide a description, and set the Factor Identification to By Factors. Then click OK.
3. On the Factors page, select the IS_HR_DBA factor, and click Edit. 4. Click Create in the Identities region. 5. Enter TRUE as the Value, and set the Trust Level to Very Trusted. Then click OK.
6. Back on the Edit Factor page, select the TRUE identity and click Edit. 7. On the Edit Identity: TRUE page, click Create in the Map Identity region. 8. On the Create Identity Map page, choose Session_User as the Contributing Factor. Choose Equal as the Map Condition. Enter BERNST as the Low Value. Then click OK.
9. Test the IS_HR_DBA factor by entering the following in a SQL*Plus session:

SQL> connect HR/HR Connected. SQL> select dvf.f$is_hr_dba from dual; F$IS_HR_DBA -------------------------------------------------------SQL> connect bernst/q1_w2_e3 Connected. SQL> select dvf.f$is_hr_dba from dual; F$IS_HR_DBA --------------------------------------------------------TRUE SQL>
7) Delete the IS_HR_DBA factor. Answer: 1. Navigate to the Factors page, select the IS_HR_DBA factor, and click Remove. 2. Click Yes to confirm.
Practice Solutions for Lesson 6 Managing Rule Sets

Solutions for Practice 6-1: Managing Rule Sets
Rule sets introduce a lot of flexibility in the configuration of Database Vault components. In this practice, you create rule sets. You then associate those rule sets to a realm, to ensure access only under certain circumstances. You also attach a rule set to a factor, making the factor settable when the conditions of the rules are met. 1) Create a rule set called Non Work Hours that enforces the rule that access is allowed only during nonworking hours of a day, which are any hours outside of 8:00 a.m. to 4:59 p.m. local time, Monday through Friday. Assume that the server is in the local time zone. Use two rules: one called Night and one called Weekend. Answer: 1. In DVA, click Rule Sets to go to the Rule Sets page.
2. Click Create.
3. Enter Non Work Hours as the Name. 4. Enter Hours outside of 8:00 AM to 4:59 PM local time for Description.
Solutions for Practice 6-1: Managing Rule Sets (continued)
5. Review the rest of the page, and then click OK. 6. Select Non Work Hours in the rule set list, and then click Edit.
7. In the Rules Associated to the Rule Set region, click Create.
Solutions for Practice 6-1: Managing Rule Sets (continued) 8. On the Create Rule page, enter Night as the Name, and enter the following in the Rule Expression field:
to_char(sysdate,'hh24') not between 08 and 16
9. Click OK. 10. Again, in the Rules Associated to the Rule Set region, click Create. 11. On the Create Rule page, enter Weekend as the Name, and enter the following as the Rule Expression:
to_char(sysdate,'d') not between '2' and '6'
12. Click OK and then review the rules in the rule set:
13. Set the rule set Evaluation Options to Any True, and then click OK. Note: You may want to edit the Non Work Hours such that working hours are as late as 10:00 p.m. This will prevent timing problems if you work on the practices after 4:59 p.m. All scenarios in this course are set up with the assumption that they will be executed during working hours, which is the complement of the time frame defined by the Non Work Hours rule set. 2) Edit the HR Schema realm and add the Non Work Hours rule set as an authorization rule set for the BERNST participant. Answer: 1. In DVA, click the Realms link, and then select the HR Schema realm, and click Edit. 2. Select the BERNST row in the Realm Authorizations region, and then click Edit. 3. Set the Authorization Rule Set to Non Work Hours, and then click OK.
Solutions for Practice 6-1: Managing Rule Sets (continued)
3) As the BERNST user, attempt to create a new table in the HR schema. What happens, and why? Answer: 1. Return to the BERNST SQL*Plus session, and enter the following at the SQL*Plus prompt:
SQL> create table hr.x (a number); create table hr.x (a number) * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for create table on HR.X ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
This fails because of the added requirement that BERNSTs access be only during nonworking hours. 4) Edit the Non Work Hours rule set to have another rule, called Secure, that checks for an identity of SECURE for the Domain factor. This should override the time criteria, allowing a SECURE connected session to have access no matter whether it is during working hours or not. Answer: 1. Return to DVA, and click Rule Sets. 2. Select the Non Work Hours rule set, and click Edit.
Solutions for Practice 6-1: Managing Rule Sets (continued) 3. Click Create in the Rules Associated to the Rule Set region.
4. On the Create Rule page, enter Secure as the rules Name, and then enter the following in the Rule Expression field:
dvf.f$domain = SECURE
5. Click OK. 6. Review the rules in the rule set:
5) Reattempt creating the HR table as the BERNST user. What is the result? Why? Answer: 1. Return to the BERNST SQL*Plus session, reconnect using a net service name, and enter the following at the prompt:
SQL> connect bernst/q1_w2_e3@orcl_edrsr3p1 Connected. SQL> create table hr.x (a number); Table created.
The CREATE TABLE statement succeeds now because, although it is still during work hours, the alternative requirement of having the SECURE identity for the Domain factor satisfies the authorization rule set (that requires that only one of the three rules is true).
Solutions for Practice 6-2: Using Assignment Rule Sets with Factors
In this practice, you set an assignment rule set for a factor and see the results. 1) As the BERNST user, select the JOBROLE factor value. What is it? Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> connect bernst/q1_w2_e3 Connected. SQL> SELECT DVF.F$JOBROLE from DUAL; F$JOBROLE --------------------------------------------------------IT_PROG SQL>
2) As the SMAVRIS user, select the JOBROLE factor value. What is it? Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> connect smavris/q1_w2_e3 Connected. SQL> SELECT DVF.F$JOBROLE from DUAL; F$JOBROLE -------------------------------------------------------HR_REP SQL>
3) As the WSMITH user, select the JOBROLE factor value. What is it? Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> connect WSMITH/q1_w2_e3 Connected. SQL> SELECT DVF.F$JOBROLE from DUAL; F$JOBROLE -------------------------------------------------------SA_REP SQL>
Solutions for Practice 6-2: Using Assignment Rule Sets with Factors (continued) 4) As WSMITH, use the DVSYS.SET_FACTOR procedure to attempt to set the JOBROLE factor value to IT_PROG. What happens? Why? Answer: 1. Enter the following at the SQL*Plus prompt where WSMITH is logged in:
SQL> exec dvsys.set_factor('JOBROLE','IT_PROG'); BEGIN dvsys.set_factor('JOBROLE','IT_PROG'); END; * ERROR at line 1: ORA-47392: Factor JOBROLE is not settable. ORA-06512: at "DVSYS.DBMS_MACSEC", line 3 ORA-06512: at "DVSYS.DBMS_MACSEC", line 54 ORA-06512: at "DVSYS.SET_FACTOR", line 5
The SET_FACTOR call fails because there is no assignment rule set defined for the JOBROLE factor. 5) Add an assignment rule set to the JOBROLE factor. The rule set should always be true. Use the delivered Enabled rule set. Answer: 1. Navigate to the Factors page in DVA, select the JOBROLE factor, and click Edit. 2. Set the Assignment Rule Set to Enabled. Click OK.
6) Reattempt to set the factor as the WSMITH user. What happens? Why? Answer: 1. Enter the following at the SQL*Plus prompt where WSMITH is logged in:
SQL> exec dvsys.set_factor('JOBROLE','IT_PROG'); PL/SQL procedure successfully completed. Oracle Database 10g: Implementing Database Vault B - 47
Solutions for Practice 6-2: Using Assignment Rule Sets with Factors (continued) 7) Select the JOBROLE factor value to see what it is. Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> select dvf.f$jobrole from dual; F$JOBROLE -----------------------IT_PROG
8) Set the factor to xyz and select it to see that it is set. Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> exec dvsys.set_factor('JOBROLE','xyz'); PL/SQL procedure successfully completed. SQL> select dvf.f$jobrole from dual; F$JOBROLE ---------------------------------------------------------xyz SQL>
9) What can you deduce about the ability to set a factor value? Answer: 1. All that is necessary is that the factor has an assignment rule set defined for it (making it assignable) and that that rule set evaluates to true. Then the factor can be set to any value, regardless of its other attributes or associated identities.
Solutions for Practice 6-3: Using Rule Sets to Restrict Connection Sources
The JOBROLE factor is now settable, but it is made settable by an always-true rule set. In this exercise, you change the assignment rule set to be something more meaningful, requiring that the session have a specific context setup, and a specific role active. 1) Create the rule set HR_REP hrmaint that ensures that the job ID is HR_REP and the running program is hrmaint. (This will be used in the Secure Application Roles practice.) Answer: 1. In DVA, click Rule Sets to go to the Rule Sets page. 2. Click Create to create the new rule set. 3. Name the rule set HR_REP hrmaint, and enter Ensures that the job ID is HR_REP and the running program is hrmaint in the Description field.
4. Click OK. 5. On the Rule Sets page, select the HR_REP hrmaint rule set and then click Edit. 6. In the Rules Associated To The Rule Set region, click Create. 7. Name the new rule Is HR_REP. 8. Enter the following Rule Expression, and then click OK.
dvf.f$jobrole = 'HR_REP'
Solutions for Practice 6-3: Using Rule Sets to Restrict Connection Sources (continued)
9. On the HR_REP hrmaint rule set page, again click Create in the Rules Associated To The Rule Set region. 10. Name the new rule Is hrmaint Program. 11. Enter the following for Rule Expression:
sys_context('USERENV','module') = 'hrmaint'
12. Click OK.
13. On the Rule Set page, click OK to save the new rule set. 2) Test the new rule set. Make it the assignment rule set for the JOBROLE factor and attempt to execute the same SET_FACTOR call as was done in the previous practice. The SET_FACTOR call should now fail. When finished testing, set the factors assignment rule set back to its original setting. Answer: 1. Navigate to the Factors page, select the JOBROLE factor, and click Edit. 2. On the Edit Factor page, set the Assignment Rule Set to HR_REP hrmaint, and then click OK.
3. Attempt to set the factor from a SQL*Plus session, using the WSMITH user.
SQL> connect WSMITH/q1_w2_e3 Connected. SQL> SELECT DVF.F$JOBROLE from DUAL;
F$JOBROLE -------------------------------------------------------SA_REP SQL> exec dvsys.set_factor('JOBROLE','IT_PROG'); BEGIN dvsys.set_factor('JOBROLE','IT_PROG'); END; * ERROR at line 1: ORA-47391: Attempt to set Factor JOBROLE violates Rule Set HR_REP hrmaint ORA-06512: at "DVSYS.DBMS_MACSEC", line 3 ORA-06512: at "DVSYS.DBMS_MACSEC", line 54 ORA-06512: at "DVSYS.SET_FACTOR", line 5 ORA-06512: at line 1
4. On the Factors page, select the JOBROLE factor, and click Edit. 5. Set the Assignment Rule Set back to Enabled, and then click OK.
Practice Solutions for Lesson 7 Command Rules

Solutions for Practice 7-1: Using Command Rules
You are now going to work with command rules. First, you prevent the creation of a view using a command rule. 1) As the AHUNOLD user, create the OE.BIG_ORDERS view that is defined as all OE.ORDERS rows where the ORDER_TOTAL is greater than 100000. Then drop the view. Answer: 1. Log in to SQL*Plus as the AHUNOLD user by entering the following at the OS prompt:
$ sqlplus ahunold/q1_w2_e3
2. Create the view by entering the following at the SQL*Plus prompt:

SQL> create view oe.big_orders as select * from oe.orders where order_total > 100000; View created.
3. Drop the view by entering the following at the SQL*Plus prompt:

SQL> drop view oe.big_orders; View dropped.
2) Create a command rule that prevents users from issuing the CREATE VIEW command on OE objects unless it is during nonworking hours. Use the Non Work Hours rule set. Answer: 1. In DVA, click Command Rules on the Administration tabbed page.
Solutions for Practice 7-1: Using Command Rules (continued) 2. Click Create.
3. Choose CREATE VIEW as the Command, set Object Owner to OE, and set Rule Set to Non Work Hours. Then click OK.
3) Reattempt the CREATE VIEW command as the AHUNOLD user. What happens? Why? Answer: 1. Enter the following at the SQL*Plus prompt:
SQL> create view oe.big_orders as select * from oe.orders where order_total > 100000; ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47400: Command Rule Violation for create view on OE.BIG_ORDERS ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
The CREATE VIEW statement fails because the command rule just created requires that it be done only during nonworking hours.
Solutions for Practice 7-2: Protecting the Data

You create a rule set that prevents AHUNOLD from selecting his own data, but he can still alter and create objects. This is the method to prevent an application DBA from reading the data in the objects he or she manages. 1) As AHUNOLD, select data from one of the OE tables. This should succeed. Answer: 1. Show only the first nine rows returned from the OE.ORDERS table, when you select the order_id, customer_id, and order_total columns.
SQL> connect ahunold/q1_w2_e3 Connected. SQL> select order_id, customer_id, order_total 2 from oe.orders 3 where rownum < 10; ORDER_ID CUSTOMER_ID ORDER_TOTAL ---------- ----------- ----------2458 101 78279.6 2397 102 42283.2 2454 103 6653.4 2354 104 46257 2358 105 7826 2381 106 23034.6 2440 107 70576.9 2357 108 59872.4 2394 109 21863 9 rows selected. SQL>
2) As AHUNOLD, create a new test table. Drop the table. These should succeed. Answer: 1. Still connected as AHUNOLD, create and drop a table.
SQL> create table oe.test (customer_id NUMBER(12)); Table created. SQL> drop table oe.test; Table dropped. SQL>
3) Create a (traditional) role called APP_USER, as the SYSTEM user.
Solutions for Practice 7-2: Protecting the Data (continued) Answer: 1. Connect as the SYSTEM user and create the APP_USER role by entering the following in the SQL*Plus session:
SQL> connect system/oracle Connected. SQL> create role app_user; Role created. SQL>
4) Create a rule set called HAS APP USER that ensures that the user has the APP_USER role. Answer: 1. Navigate to the Rule Set page in DVA and click Create. 2. Name the rule set HAS APP USER, and then provide a description. Then click OK.
3. Select the HAS APP USER rule set and click Edit. 4. Click Create in the Rules Associated to the Rule Set region. 5. Name the rule Has App User Role, and enter the following as the Rule Expression:
DVSYS.DBMS_MACUTL.USER_HAS_ROLE_VARCHAR('APP_USER') = 'Y'
6. Click OK.
Solutions for Practice 7-2: Protecting the Data (continued) 5) Create a command rule SELECT OE.% that uses the HAS APP USER rule set. Answer: 1. Navigate to the Command Rules page and click Create. 2. Choose SELECT as the Command, OE as the Object Owner, and HAS APP USER as the Rule Set, and then click OK.
6) Reattempt to SELECT from OE tables as AHUNOLD. This should fail. Why? Answer: 1. Attempt the same SELECT statement as in step 1.
SQL> connect ahunold/q1_w2_e3 Connected. SQL> select order_id, customer_id, order_total 2 from oe.orders 3 where rownum < 10; select order_id, customer_id, order_total from oe.orders * ERROR at line 1: ORA-01031: insufficient privileges
SQL>
The Command rule causes the SELECT command to fail because AHUNOLD does not have the APP_USER role.
Solutions for Practice 7-2: Protecting the Data (continued) 7) As the AHUNOLD user, create a new table and drop it. This should still succeed. Answer: 1. Create a table and drop it as in step 2, by entering the following in the SQL*Plus session.
SQL> create table oe.test (customer_id NUMBER(12)) ; Table created. SQL> drop table oe.test; Table dropped.
8) Confirm that it is the absence of the APP_USER role that is preventing SELECT access. Do this by granting this role to BERNST and retrying the SELECT statement. Then revoke the role. Answer: 1. Grant the APP_USER role to BERNST by entering the following in the SQL*Plus session:
SQL> connect system/oracle Connected. SQL> grant app_user to bernst; Grant succeeded. SQL>
2. Reattempt the SELECT statement by entering the following in the SQL*Plus session:
SQL> connect bernst/q1_w2_e3 Connected. SQL> select order_id, customer_id, order_total 2 from oe.orders 3 where rownum < 10; ORDER_ID CUSTOMER_ID ORDER_TOTAL ---------- ----------- ----------2458 101 78279.6 2397 102 42283.2 2454 103 6653.4 2354 104 46257 2358 105 7826 2381 106 23034.6 2440 107 70576.9 2357 108 59872.4 2394 109 21863 9 rows selected. SQL> Oracle Database 10g: Implementing Database Vault B - 58
Solutions for Practice 7-2: Protecting the Data (continued) 3. Revoke the APP_USER role from BERNST by entering the following in the SQL*Plus session:
SQL> connect system/oracle Connected. SQL> revoke app_user from bernst; Revoke succeeded. SQL>
Solutions for Practice 7-3: Preventing Accidents
Sometimes, to prevent accidents, you may want to define a peculiar way to execute a certain command. This requires some thought on the part of the user who is executing the command. In this practice, you prevent the recompiling of functions unless the word function is capitalized in a special way. 1) Recompile the GET_JOB_ID function while logged in as the BERNST user. Recall that, because of the Non Work Hours rule set, you must override the work hours requirement by logging in with a service name, which causes the Domain factor to be set to the SECURE identity. You can simply use the orcl service name when logging in to the local database. This recompile should work because BERNST has access to the HR schema via the HR Schema realm. Answer: 1. Log in as BERNST and recompile the HR.GET_JOB_ID function by entering the following in the SQL*Plus session:
SQL> connect bernst/q1_w2_e3@orcl Connected. SQL> alter function hr.get_job_id compile; Function altered. SQL>
2) Create a command rule that prevents recompilation of functions in the HR schema unless the keyword FunctioN appears in the statement, with only the first and last letters capitalized. Create a rule set called FunctioN in order to implement this command rule. Answer: 1. Create the FunctioN rule set. a. Navigate to Rule Sets in DVA, and click Create. b. Set Name to FunctioN, provide a description, and then click OK. c. Select the FunctioN rule set and click Edit. d. Click Create in the Rules Associated to the Rule Set region. e. Name the new rule FunctioN. f. Enter the following as the Rule Expression, and then click OK.
instr(dvsys.dv_sql_text,'FunctioN') > 0
Solutions for Practice 7-3: Preventing Accidents (continued)
2. Create the command rule that uses the FunctioN rule set. a. Navigate to the Command Rules page in DVA and click Create. b. Select ALTER FUNCTION as the Command, HR as the Object Owner, and FunctioN as the Rule Set. Then click OK.
3) Test the new command rule by attempting to compile the GET_JOB_ID function as the BERNST user. For this test, simply capitalize the FUNCTION keyword as you normally would: either in all capitals or in all lowercase. Answer: 1. Enter the following in the SQL*Plus session:
SQL> connect bernst/q1_w2_e3@orcl Connected. SQL> alter function hr.get_job_id compile; alter function hr.get_job_id compile *
Solutions for Practice 7-3: Preventing Accidents (continued)

ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47400: Command Rule Violation for alter function on HR.GET_JOB_ID ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
Note that the compile fails because of the command rule violation. 4) Reattempt the ALTER FUNCTION statement, but this time capitalize only the first and last characters of the function keyword. Answer: 1. Enter the following in the BERNST SQL*Plus session:
SQL> alter FunctioN hr.get_job_id compile; Function altered. SQL>
Note that the compile succeeds now.
Practice Solutions for Lesson 8 Managing Secure Application Roles

You now use secure application roles to control what users can execute a procedure. You create a secure application role that uses a rule set you defined previously. You grant the ability to execute a procedure to the secure application role, which means that the session must meet the conditions of the roles associated rule set in order to execute the procedure. 1) As the HR user, issue a grant statement so that SMAVRIS will be able to select rows from the HR.EMPLOYEES table. Answer: 1. Issue the GRANT command by entering the following in a SQL*Plus session:
SQL> connect HR/HR Connected. SQL> GRANT SELECT ON hr.employees TO smavris; Grant succeeded. SQL>
Solutions for Practice 8-1: Managing Secure Application Roles
2) As the SMAVRIS user, view the HR.EMPLOYEES table. Answer: 1. Enter the following in the SQL*Plus session:
SQL> connect SMAVRIS/q1_w2_e3 Connected. SQL> SELECT last_name, salary 2 FROM hr.employees 3 WHERE employee_id = 106; LAST_NAME SALARY ------------------------- ---------Pataballa 4800
3) As the SMAVRIS user in SQL*Plus, attempt to give every employee a 5% raise. Answer: 1. Enter the following in the SMAVRIS SQL*Plus session:
SQL> UPDATE HR.EMPLOYEES SET salary = salary * 1.05; UPDATE HR.EMPLOYEES SET salary = salary * 1.05 * ERROR at line 1: ORA-01031: insufficient privileges
Solutions for Practice 8-1: Managing Secure Application Roles (continued) 4) Create a secure application role called HR_APP that uses the HR_REP hrmaint rule set. Answer: 1. Navigate to the Secure Application Roles page in DVA, and click Create. 2. Name the role HR_APP, set Rule Set to HR_REP hrmaint, and click OK.
5) Create the HR.GIVE_RAISE procedure by running the give_raise.pls script while logged in as the HR user. This script creates a procedure GIVE_RAISE(EMP_ID,RAISE_PERCENT). It can be viewed as follows:
$ cd ~/labs $ cat <give_raise.pls CREATE OR REPLACE PROCEDURE HR.GIVE_RAISE( Emp_id IN NUMBER, raise_percent IN NUMBER) AS v_salary Number(8,2); v_raise_pct NUMBER(6,5); BEGIN v_raise_pct := raise_percent/100; SELECT salary INTO v_salary FROM HR.EMPLOYEES WHERE employee_id = EMP_ID; v_salary := v_salary * (1 + v_raise_pct); UPDATE HR.EMPLOYEES SET salary = v_salary WHERE employee_id = EMP_ID; EXCEPTION WHEN NO_DATA_FOUND THEN NULL; END; /
Solutions for Practice 8-1: Managing Secure Application Roles (continued) Answer: 1. Enter the following in the SQL*Plus session:
SQL> connect hr/hr Connected. SQL> @$HOME/labs/give_raise.pls Procedure created.
6) While still connected as HR, grant the EXECUTE privilege on the GIVE_RAISE procedure to the HR_APP secure application role. Answer: 1. Enter the following in the SQL*Plus session:
SQL> GRANT EXECUTE ON give_raise TO hr_app; Grant succeeded.
7) As the SMAVRIS user, attempt to run the GIVE_RAISE procedure. Attempt to give the employee with the ID of 106 a raise of 5%. What is the result? Why? 1. Enter the following in the SQL*Plus session:
SQL> connect SMAVRIS/q1_w2_e3 Connected. SQL> execute HR.GIVE_RAISE(106,5); BEGIN HR.GIVE_RAISE(106,5); END; * ERROR at line 1: ORA-06550: line 1, column 7: PLS-00201: identifier 'HR.GIVE_RAISE' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored
This fails because SMAVRIS does not have EXECUTE privileges on the HR.GIVE_RAISE procedure. 8) To meet the requirements of the rule set on the HR_APP role, the session calling the SET_ROLE function must be known to the database as hrmaint. Call DBMS_APPLICATION_INFO.SET_MODULE to set the module to hrmaint. Answer: 1. Enter the following in the SMAVRIS SQL*Plus session:
SQL> exec dbms_application_info.set_module('hrmaint',null); PL/SQL procedure successfully completed. SQL> select sys_context('userenv','module') from dual;
Solutions for Practice 8-1: Managing Secure Application Roles (continued)

SYS_CONTEXT('USERENV','MODULE') ------------------------------hrmaint
9) Call SET_ROLE to enable the HR_APP secure application role. Answer: 1. Enter the following in the SQL*Plus session:
SQL> execute dvsys.dbms_macsec_roles.set_role('HR_APP'); PL/SQL procedure successfully completed.
10) Reattempt the GIVE_RAISE procedure, still logged in as SMAVRIS. What is the result? Why? Answer: 1. Enter the following in the SQL*Plus session:
SQL> EXECUTE HR.GIVE_RAISE(106, 5) PL/SQL procedure successfully completed.
11) Verify that the raise was applied by querying for the salary of employee number 106 and compare it with the previous result. Answer: 1. Enter the following in the SQL*Plus session:
SQL> SELECT last_name, salary FROM HR.EMPLOYEES 2 WHERE EMPLOYEE_ID = 106; LAST_NAME SALARY ------------------------- ---------Pataballa 5040
Note that previously this salary was 4800. Now it is 5040, which is 5% higher. So, the 5% raise did indeed take effect. 12) Roll back the transaction and exit SQL*Plus. Answer: 1. Enter the following in the SQL*Plus session:
SQL> rollback; Rollback complete. SQL> exit
Practice Solutions for Lesson 9 Viewing Reports

Solutions for Practice 9-1: Viewing Reports
This practice guides you through several reports available in DVA. You may run others that are not specified here, if you want to. 1) For Database Vault Monitor to report on configuration changes and violations, the AUDIT_TRAIL initialization parameter must be set to DB. The AUDIT_TRAIL parameter is static and can be changed only in the spfile, after which the database must be restarted for the change to take effect. Set this parameter to DB, and restart the database. Answer: 1. Start a SQL*Plus session as the SYS user, and enter the following commands:
$ sqlplus sys/oracle as sysdba SQL*Plus: Release 10.2.0.2.0 - Production on Tue Aug 15 18:13:42 2006 Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options SQL> ALTER SYSTEM set AUDIT_TRAIL=DB SCOPE=SPFILE; System altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted. Database opened. SQL> 285212672 1260420 188744828 92274688 2932736 bytes bytes bytes bytes bytes
Solutions for Practice 9-1: Viewing Reports (continued) 2) Create a new user named SEC with password of q1_w2_e3. This user serves the purpose of a security auditor that will view reports and configuration information, but does not have the privileges to change the Database Vault configuration. Verify that this user can view the reports, and view the edit pages for the various DV objects, but cannot change the DV objects. Answer: 1. Enter the following in the SQL*Plus session:
SQL> connect DVAM/oracle_10g Connected. SQL> CREATE USER sec IDENTIFIED BY q1_w2_e3; User created. SQL> GRANT CONNECT TO sec; Grant succeeded.
2. As the DVO user, grant the required privileges to SEC for viewing reports available in DVA.
SQL> CONNECT DVO/oracle_10g Connected. SQL> GRANT DV_SECANALYST TO sec; Grant succeeded.
3. In DVA, click Logout. 4. On the DVA login page, enter sec as the User Name, and q1_w2_e3 as the Password. Then click Login. 5. Click the Database Vault Reports tab. 6. Select the Factors Without Identities report and click Run Report.
Solutions for Practice 9-1: Viewing Reports (continued)
The resulting report is shown:
7. Navigate to the Administration tabbed page, in an attempt to change one of the factors. Note that none of the Administration links are available.
3) Run the lab_09_01_03.sql script to create some Database Vault components that are not correctly configured. This will provide some data for the reports you are about to run. Answer: 1. Enter the following in the SQL*Plus session, while connected as any user.
SQL> @$HOME/labs/lab_09_01_03.sql Connected. PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
Commit complete. SQL>
4) Run the lab_09_01_04.sql script that generates violations of various realms, rules, and factors. Answer: 1. Enter the following in the SQL*Plus session, while connected as any user. The errors are expected. These errors and violations will generate audit records.
SQL> @$HOME/labs/lab_09_01_04.sql Connected. Select * from hr.employees *

ERROR at line 1: ORA-01031: insufficient privileges
Update hr.employees set salary = salary*.75 * ERROR at line 1: ORA-01031: insufficient privileges
Grant succeeded.
Table created. Connected. select * from sh.sales * ERROR at line 1: ORA-01031: insufficient privileges
update sh.sales set AMOUNT_SOLD = AMOUNT_SOLD*1.02 * ERROR at line 1: ORA-01031: insufficient privileges
Connected. select * from hr.employees * ERROR at line 1: ORA-01031: insufficient privileges
Grant all on sh.sales to Kpartner * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for grant object privilege on SH.SALES ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
SQL>
Solutions for Practice 9-1: Viewing Reports (continued) 5) Run the lab_09_01_05.sql script that grants privileges that should not be normally granted. Answer: 1. Enter the following in the SQL*Plus session:
SQL> @$HOME/labs/lab_09_01_05.sql Connected. Grant succeeded.
Grant succeeded.
Grant succeeded.
System altered.
System altered. Connected. Grant succeeded.
Grant succeeded. SQL>
6) View the Database Vault Monitor for changes and violations. Answer: 1. On the DVA Home page, click the Monitor tab.
2. Scroll down to Security Policy Changes Detail and expand (click +). View the report and determine which changes were caused by the scripts in steps 3 through 5.
Solutions for Practice 9-1: Viewing Reports (continued) 3. Scroll down and expand Security Violation Attempts, and review the items shown. Determine what violations occurred.
4. Scroll down to the Database Configuration and Structural Changes. Expand it, and determine what was changed by the scripts in steps 3 through 5.
7) View the Database Vault reports and find the misconfigured items. Answer: 1. Run each of the reports listed in the Database Vault Reports and under the Database Vault Configuration Issues Reports heading.
2. Run the Command Rule Configuration Issues report.
3. Run the Factor Configuration Issues report.
Solutions for Practice 9-1: Viewing Reports (continued) 4. Run the Factors Without Identities report.
5. Run the Identity Configuration Issues report.
6. Run the Realm Authorization Configuration Issues report.
7. Run the Rule Set Configuration Issues report.
Solutions for Practice 9-1: Viewing Reports (continued) 8. Run the Secure Application Configuration Issues report. This report shows configuration problems with secure application roles.
8) View the Database Vault Audit reports and note any violations. Answer: 1. View the list of Audit reports that are available.
2. View the Realm Audit report. Notice that the scripts you ran earlier caused realm violations to appear in the audit reports. By default, the realms are audited only on failure.
Solutions for Practice 9-1: Viewing Reports (continued) 3. View the Command Rule Audit report. Several command rule violations were audited. Note that you cannot set auditing on a command rule; the auditing is set on the rule set.
4. View the Factor Audit report. The factor evaluation is audited depending on the audit options setting for the factor. The audit records are usually useful for debugging.
5. View the Label Security Integration Audit report. This report will be populated only if you have performed the Oracle Label Security integration. In this report, $HOME/demos/demo_05_18_setup.sql was executed to set up a Label Security Policy and the Facility policy was associated with Database Vault. See the instructor if you want to view a populated report.
6. View the Core Database Vault Audit report. This report is not populated in this version of Oracle Database Vault.
7. View the Secure Application Role Audit report. The Secure Application Audit report is based on the audit settings of the rule set. There are no audit options available for Secure Application Roles.
9) View the General Security System reports. Many of these reports are considered standard reports needed to view the security aspects of the database. Run some sample reports: a) Hierarchical System Privileges by Database Account for DVO b) Execute Privileges to Strong SYS Packages report c) Accounts With DBA Role report d) OS Security Vulnerability Privileges report
Solutions for Practice 9-1: Viewing Reports (continued) e) Security-Related Database Parameter report f) Database Account Status report g) Other reports as you desire Answer: 1. There are 40 General Security Systems reports to help find and identify common security problems.
Solutions for Practice 9-1: Viewing Reports (continued) 2. Run the Hierarchical System Privileges by Database Account report for DVO. Notice that all privileges granted to DVO are visible including the privileges granted through a role, and the role is identified.
3. Run the Execute Privileges to Strong SYS Packages report. This report shows which users and roles have been granted the EXECUTE privilege on SYS packages that have a potential of being misused. Specifically, Oracle recommends that PUBLIC should not be granted EXECUTE on these packages, but there may be dependencies in applications that require these permissions. Therefore, check the application documentation carefully before revoking these privileges. DBMS_OBFUSCATION_TOOLKIT has an encryption procedure that could be used by anyone with database access to encrypt data. If a disgruntled employee were to encrypt certain data and refuse to provide the key, then this could cause a disruption in business and a loss of data.
Solutions for Practice 9-1: Viewing Reports (continued) 4. Run the Accounts With DBA Role report. This report allows you to find users that may have been granted the DBA role inappropriately.
5. Run the OS Security Vulnerability Privileges report. This report shows the database privileges that could be used to gain access to OS files and directories. These privileges should be carefully controlled.
Solutions for Practice 9-1: Viewing Reports (continued) 6. Run the Security-Related Database Parameter report. This report shows a list of parameters that could be used to create security infractions and their current values. These are not security violations but could be based on the parameter value and other settings.
7. Run the Database Account Status report. This report displays the status for each database account.
Solutions for Practice 9-1: Viewing Reports (continued) 10) Run the lab_09_01_cleanup.sql script to remove the incomplete and misconfigured items. Answer: 1. Enter the following in the SQL*Plus session:
SQL> @$HOME/labs/lab_09_01_cleanup SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 07:55:23 2006 Copyright (c) 1982, 2005, Oracle. Connected. PL/SQL procedure successfully completed. All Rights Reserved.

PL/SQL procedure successfully completed. Connected. Table dropped.
Commit complete. SQL>
Practice Solutions for Lesson 10 Best Practices

Solutions for Practice 10-1: Defining Application DBAs
Your company has hired an internal auditor to periodically check the IT systems in order to make independent audits happen more smoothly. The following practices represent some common situations that may need correcting in order to meet audit requirements. First, restore the backup taken at the beginning of this class. That guarantees that any mistakes made up to this point will not affect these practices. 1) Restore from the backup that was taken at the end of the installation practice by running the lab_10_01.sh script. Answer: 1. Enter the following at the OS prompt:
$ ~/labs/lab_10_01.sh SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 08:48:52 2006 Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options SQL> Database closed. Database dismounted. ORACLE instance shut down. SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 08:53:23 2006 Copyright (c) 1982, 2005, Oracle. Connected to an idle instance. SQL> ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers 285212672 1260420 184550524 96468992 bytes bytes bytes bytes All Rights Reserved.
Solutions for Practice 10-1: Defining Application DBAs (continued)

Redo Buffers 2932736 bytes Database mounted. Database opened. SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options [oracle@edrsr3p1 labs]$
2) The auditor asks you to show him which database users have the SELECT ANY TABLE privilege. Run a report to show that information. Answer: 1. Log in to DVA as the DVO user. 2. Click the General Security Reports tab. 3. Select the System Privileges by Privilege report, and click Run Report.
4. Choose SELECT ANY TABLE in the Privilege drop-down list, and then click Run Report. See the resulting report below.
3) Based upon that report, you and the auditor see that there are users who can read any table in the database even if they do not need it. Create realms to protect each individual schema, and allow each application DBA to access its own realm-protected data. Answer: 1. Using DVA, click the Realms link on the Administration tabbed page.
2. Click Create.
3. Enter HR Schema as the realm name and then click OK.
4. Select the realm just created and click Edit.
Solutions for Practice 10-1: Defining Application DBAs (continued) 5. In the Realm Secured Objects region, click Create.
6. Select HR as the Object Owner, and click OK.
7. Click Create in the Realm Authorizations region.
8. Select BERNST as Grantee, and click OK.
9. Perform the steps listed above for the OE Schema realm, adding AHUNOLD as the realm participant.
4) Prove to the auditor that the users with SELECT ANY TABLE can no longer read realm-protected tables outside of their realm. Answer: 1. Enter the following at the OS prompt, and in the SQL*Plus session:
$ sqlplus AHUNOLD/q1_w2_e3 SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 09:32:55 2006 Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options

SQL> SELECT last_name, salary FROM HR.EMPLOYEES 2 WHERE EMPLOYEE_ID = 108; SELECT last_name, salary FROM HR.EMPLOYEES * ERROR at line 1: ORA-01031: insufficient privileges
SQL> exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options
2. Enter the following at the OS prompt and in the SQL*Plus session:

$ sqlplus BERNST/q1_w2_e3 SQL*Plus: Release 10.2.0.2.0 - Production on Fri Aug 11 09:35:12 2006 Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options SQL> SELECT Customer_id, order_total FROM OE.ORDERS 2 WHERE ROWNUM < 10; SELECT Customer_id, order_total FROM OE.ORDERS * ERROR at line 1: ORA-01031: insufficient privileges
SQL> exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options [oracle@edrsr3p1 labs]$
The auditor realizes that the application DBAs are now locked into their realms, but wants further controls on who can become an application DBA. You need to restrict the usage of these roles to be only where the Action for the session is ADMIN. You decide to revoke the application roles from all users, and, instead, define new secure application roles that can have a rule set that can implement the requirements of the auditor. Then, lock down the HR_DBA and OE_DBA roles so that they can no longer be granted to anyone without the intervention of the DVO user. 1) Create a factor called ACTION that represents the ACTION context value for the session. Answer: 1. Navigate to the Factors page in DVA, and click Create. 2. Name the factor ACTION. 3. Set the Retrieval Method to the following expression:
sys_context('USERENV','ACTION')
Solutions for Practice 10-2: Locking Down the DBA Roles
4. Set the Factor Identification to By Method. 5. Set the factors Evaluation to By Access.
6. Save the factor by clicking OK. 2) Create a rule set called ADMIN that ensures that the ACTION factor is equal to ADMIN. 1. Navigate to the Rule Sets page in DVA, and click Create.
Solutions for Practice 10-2: Locking Down the DBA Roles (continued) 2. Name the rule set ADMIN, and then click OK.
3. Select the ADMIN rule set, and click Edit 4. Click Create in the Rules Associated To The Rule Set region. 5. Name the new rule ADMIN_ACTION. 6. Set Rule Expression to the following:
dvf.f$action = ADMIN
7. Click OK. 3) Create the OE_DBA_SAR and HR_DBA_SAR secure application roles. The rule set to be satisfied for each of these is ADMIN. 1. Navigate to the Secure Application Roles page in DVA, and click Create. 2. Name the role OE_DBA_SAR, and set Rule Set to ADMIN. 3. Click OK. 4. Click Create again, and name the other role HR_DBA_SAR.
Solutions for Practice 10-2: Locking Down the DBA Roles (continued) 5. Set Rule Set to ADMIN, and click OK. 6. Review the two new secure application roles.
4) Revoke the OE_DBA and HR_DBA roles from all users that have them. Answer: 1. Enter the following at the OS prompt:
$ sqlplus system/oracle
2. Enter the following at the SQL*Plus prompt:

SQL> REVOKE OE_DBA FROM AHUNOLD; Revoke succeeded. SQL> REVOKE HR_DBA FROM BERNST; Revoke succeeded.
5) Grant the OE_DBA and HR_DBA roles to the new secure application roles, respectively. Answer: 1. Enter the following at the SQL prompt (as the SYTEM user):
SQL> GRANT oe_dba TO oe_dba_sar; Grant succeeded. SQL> GRANT hr_dba to hr_dba_sar; Grant succeeded. SQL>
Solutions for Practice 10-2: Locking Down the DBA Roles (continued) 6) Test the new secure application roles by logging in and setting the Action application information variable to ADMIN, ensuring that it allows you to read the data as the appropriate user. You must enable the role to see the data. Test to see whether you cannot see the data if you do not enable the role in the session. Do this for the BERNST user and for the AHUNOLD user. Answer: 1. Enter the following in the SQL*Plus session:
SQL> CONNECT AHUNOLD/q1_w2_e3 Connected. SQL> SELECT customer_id, order_id, order_total 2 FROM oe.orders 3 WHERE rownum < 10; FROM oe.orders * ERROR at line 2: ORA-00942: table or view does not exist
2. Enter the following to set the ACTION to ADMIN:

SQL> EXECUTE DBMS_APPLICATION_INFO.SET_ACTION('ADMIN'); PL/SQL procedure successfully completed. SQL> select sys_context('USERENV','ACTION') from dual; SYS_CONTEXT('USERENV','ACTION') --------------------------------------------------------ADMIN SQL>
3. Enter the following to set the secure application role:

SQL> EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('OE_DBA_SAR'); PL/SQL procedure successfully completed. SQL>
4. Attempt to read data from the OE.ORDERS table.

SQL> SELECT customer_id, order_id, order_total 2 FROM oe.orders 3 WHERE rownum < 10; CUSTOMER_ID ORDER_ID ORDER_TOTAL ----------- ---------- ----------101 2458 78279.6 102 2397 42283.2 103 2454 6653.4
Solutions for Practice 10-2: Locking Down the DBA Roles (continued)
104 105 106 107 108 109 9 rows selected. SQL> 2354 2358 2381 2440 2357 2394 46257 7826 23034.6 70576.9 59872.4 21863
5. Repeat for the BERNST user and the HR.EMPLOYEES table. Enter the following:
SQL> CONNECT bernst/q1_w2_e3 Connected. SQL> SELECT last_name, salary FROM hr.employees 2 WHERE EMPLOYEE_ID = 108; SELECT last_name, salary FROM hr.employees * ERROR at line 1: ORA-00942: table or view does not exist
SQL> EXECUTE DBMS_APPLICATION_INFO.SET_ACTION('ADMIN'); PL/SQL procedure successfully completed. SQL> select sys_context('USERENV','ACTION') from dual; SYS_CONTEXT('USERENV','ACTION') ---------------------------------------------------------ADMIN SQL> EXEC DVSYS.DBMS_MACSEC_ROLES.SET_ROLE('HR_DBA_SAR'); PL/SQL procedure successfully completed. SQL> SELECT last_name, salary FROM hr.employees 2 WHERE EMPLOYEE_ID = 108; LAST_NAME SALARY ------------------------- ---------Greenberg 12000 SQL>
7) Lock down the HR_DBA and OE_DBA roles so that they can no longer be granted to anyone, without having DVO intervene. Answer: 1. Navigate to the Realms page using DVA, and click Create. 2. Name the new realm APP_DBA, and then click OK.
3. Select the realm just created, and click Edit. 4. Click Create in the Realm Secured Objects region. 5. Set the Object Owner to ANONYMOUS, set the Object Type to ROLE, and set the Object Name to HR_DBA. Then click OK. Note: Roles do not have owners, so the value for the Object Owner field in this case does not matter. 6. Click Create again. 7. Set the Object Owner to ANONYMOUS, set the Object Type to ROLE, and set the Object Name to OE_DBA. Then click OK. 8. Review the two secured roles in this realm.
Now that these roles are in a realm that has no Owners set, no user can grant these roles, unless DVO disables this realm or removes them from it. 8) Test to illustrate that these two roles can no longer be granted. Answer: 1. Connect as SYSTEM or any other user that has the GRANT ANY ROLE privilege and attempt to grant the protected roles to SMAVRIS by entering the following in the SQL*Plus session:
SQL> CONNECT system/oracle Connected. SQL> GRANT HR_DBA to SMAVRIS;
GRANT HR_DBA to SMAVRIS * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for grant role privilege on HR_DBA. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
SQL> GRANT OE_DBA to SMAVRIS; GRANT OE_DBA to SMAVRIS * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm Violation for grant role privilege on OE_DBA. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13
SQL>
You understand that as well as preventing intentional unwanted data manipulation, you also need to guard against accidental loss of data. There are certain commands you want to control the use of, and one of them is DROP TABLE. You need to implement safeguards against this command executing accidentally, which is a practice one may follow in a production database. In this practice, you set up a command rule that will require a simple action on the part of the DVO user in order to perform a DROP TABLE. 1) Create the DROP TABLE command rule that has Disabled as its rule set. Answer: 1. Navigate to the Command Rules page in DVA, and click Create. 2. Set Command to DROP TABLE, and set Rule Set to Disabled. Then click OK. 2) Test the command rule by creating and then dropping a table. Use the SH user for these tests. First, create a test table, and then attempt to drop it. Answer: 1. As the SH user, issue the following at the SQL prompt:
SQL> connect sh/sh Connected. SQL> create table y (a int); Table created. SQL> drop table y; drop table y * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47400: Command Rule Violation for drop table on SH.Y ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 13 SQL>
Solutions for Practice 10-3: Preventing Data Loss
3) Use DVA to set the rule set for the DROP TABLE command rule to Enabled, and then reattempt the DROP command. 1. Return to the Command Rules page in DVA, select the DROP TABLE command rule you just created, and click Edit. 2. Set Rule Set to Enabled, and then click OK. 3. Still as the SH user, issue the following at the SQL prompt to reattempt the DROP TABLE command.
SQL> drop table y; Table dropped. SQL>
Solutions for Practice 10-4: Disabling SYSDBA

The auditor notices that you log in as SYSDBA to perform certain tasks. He asks whether you can disable that. You do that by creating a nosysdba version of the password file. 1) Back up the existing password file. Answer: 1. Enter the following at the OS prompt:
$ mv $ORACLE_HOME/dbs/orapworcl $ORACLE_HOME/dbs/orapworcl_save
2) Run the orapwd utility to create a nosysdba version of a password file. Answer: 1. Enter the following at the OS prompt:
$ orapwd file=$ORACLE_HOME/dbs/orapworcl \ password=oracle entries=5 nosysdba=Y
3) Show the auditor that you can no longer log in as SYSDBA. Answer: 1. Enter the following at the OS prompt:
$ sqlplus sys/oracle as sysdba SQL*Plus: Release 10.2.0.2.0 - Production on Wed Aug 16 00:40:51 2006 Copyright (c) 1982, 2005, Oracle. ERROR: ORA-01031: insufficient privileges All Rights Reserved.
Index
A Alert 9-23 Application DBA 3-16, 10-2, 10-5, 10-6, 10-7, 10-8, 10-9, 10-10, 10-35 Application Server 2-7, 4-10, 6-17, 10-2, 10-19, 10-20, 10-35 ASM 2-5 Audit 1-6, 3-9, 3-10, 3-24, 3-26, 3-28, 4-5, 4-12, 4-19, 4-22, 4-23, 4-24, 5-30, 6-2, 6-9, 6-14, 6-19, 6-30, 6-31, 8-17, 9-4, 9-9, 9-11, 9-14, 9-15, 9-16, 9-17, 9-24, 9-27, 9-28, 9-29, 9-30, 9-32, 9-36, 10-3, 10-14, 10-15, 10-16, 10-17, 10-23, 10-31 AUDIT_SYS_OPERATIONS 10-16 AUDIT_TRAIL 6-14, 9-4, 9-24, 9-30, 9-32 Automatic Storage Management 2-5, 10-3 B Block 1-12, 4-5, 10-25 Block corruption 10-25 C Cluster 3-12 Command Rules 1-3, 1-10, 1-15, 1-17, 1-18, 6-5, 6-6, 6-7, 6-26, 7-1, 7-2, 7-3, 7-4, 7-5, 7-6, 7-8, 7-13, 7-14, 7-15, 7-16, 7-17, 7-18, 7-19, 9-8, 9-9, 9-14, 10-18, 10-22, 10-30, 10-32 Configuration assistant 1-22, 2-5, 10-27, 10-28 Corruption 10-25 D Database Control 2-7, 2-11, 10-27, 10-28 DB_DOMAIN 4-7 DB_NAME 2-5, 4-8 DBA 1-4, 1-7, 1-19, 1-20, 3-6, 3-8, 3-16, 3-19, 3-24, 3-25, 3-26, 3-31, 4-22, 5-26, 5-27, 6-28, 7-9, 7-10, 7-11, 7-15, 8-5, 8-8, 8-15, 9-16, 9-24, 9-26, 9-27, 9-28, 9-32, 10-2, 10-3, 10-4, 10-5, 10-6, 10-7, 10-8, 10-9, 10-10, 10-18, 10-32, 10-35 DBMS_MACADM 1-25, 3-29, 4-12, 4-13, 4-21, 5-21, 5-22, 7-17, 8-18 DBMS_MACSEC 1-25, 8-8, 8-13, 8-14, 8-18 DBMS_MACUTL 1-25, 6-22, 6-28, 8-14 DBMS_OBFUSCATION_TOOLKIT 9-23
Oracle Database 10g: Implementing Database Vault Index - 2
D DBMS_RANDOM 9-23 DDL 1-15, 7-3, 7-7, 9-23 Disabling Database Vault 10-26, 10-27 DML 4-10 Dual Key Security 1-14, 10-11, 10-12, 10-13 DV_ACCTMGR 2-12, 2-13, 2-14, 2-15, 3-23, 6-26, 8-13, 10-3 DV_OWNER 2-12, 2-13, 2-14, 2-15, 9-16, 10-3 DV_PUBLIC 2-12 DVCA 1-22, 2-5, 2-6, 10-27, 10-28 E emctl 10-27, 10-28 Enterprise Manager 1-21, 2-7, 2-11, 3-23, 9-17, 10-27, 10-28, 10-33 Enterprise Manager Database Control 2-7, 2-11, 10-27, 10-28 EVENT 6-15, 9-9, 10-17, 10-18, 10-25 EXTPROC 9-23 F Factor 1-10, 1-12, 1-13, 1-17, 1-18, 2-16, 3-4, 3-5, 4-2, 4-3, 4-4, 4-5, 4-6, 4-8, 4-9, 4-10, 4-11, 4-12, 4-13, 4-14, 4-15, 4-16, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23, 4-24, 4-25, 4-26, 4-27, 5-3, 5-4, 5-5, 5-6, 5-7, 5-8, 5-9, 5-10, 5-12, 5-13, 5-15, 5-17, 5-18, 5-19, 5-22, 5-23, 5-24, 5-25, 5-26, 5-27, 5-28, 5-29, 5-31, 5-33, 6-5, 6-6, 6-7, 6-17, 6-18, 6-21, 6-24, 7-4, 7-5, 8-3, 8-4, 8-6, 9-9, 9-11, 9-12, 9-13, 9-14, 9-15, 9-36, 10-19, 10-20, 10-24, 10-34 Factor types 4-13, 4-25 FGA 9-23, 9-24 FGAC 7-13 Flashback Database 7-7
I Identity 1-10, 1-12, 1-13, 1-17, 1-18, 3-4, 3-5, 4-3, 4-4, 4-5, 4-7, 4-8, 4-14, 4-15, 4-17, 4-18, 4-19, 4-20, 4-22, 4-23, 4-24, 4-26, 5-3, 5-4, 5-5, 5-6, 5-7, 5-8, 5-9, 5-10, 5-11, 5-12, 5-13, 5-14, 5-15, 5-16, 5-17, 5-18, 5-19, 5-22, 5-23, 5-24, 5-25, 5-26, 5-27, 5-28, 5-29, 5-31, 6-5, 6-6, 6-7, 6-17, 6-24, 7-4, 7-5, 8-3, 8-4, 9-11, 9-12, 9-13, 9-15, 10-21 Index 10-5, 10-10 Initialization parameters 9-4, 9-17, 9-28, 9-30, 10-3 Instance 1-4, 1-5, 2-4, 2-5, 2-6, 3-8, 4-7, 4-8, 4-13, 5-11, 10-25, 10-29 iSQL*Plus 2-7 J JDBC 2-5, 2-6 job 1-6, 3-6, 5-28, 8-6, 9-12, 9-23, 10-32, 10-33 L Label Security 1-5, 1-9, 2-3, 4-9, 4-23, 4-25, 4-26, 5-5, 5-10, 5-19, 5-20, 5-21, 5-23, 5-24, 5-30, 9-7, 9-11, 9-14, 9-15, 9-27, 9-34 Listener 2-7, 4-7 Lock 7-14, 9-31, 10-15 M Mapping Identities 5-14, 5-15 O Object Privilege 9-17, 9-18 OINSTALL 10-3 OLS 1-5, 1-9, 2-3, 4-9, 4-23, 4-26, 5-5, 5-6, 5-19, 5-20, 5-21, 5-22, 5-23, 5-24, 5-25, 5-29, 5-30, 5-31, 9-7, 9-11, 9-12, 9-27, 9-34 Oracle Label Security 1-5, 1-9, 2-3, 4-9, 4-23, 4-25, 4-26, 5-5, 5-19, 5-20, 5-21, 5-23, 5-24, 9-7, 9-11, 9-27, 9-34 ORACLE_HOME 2-5, 2-6, 10-27, 10-28 orcl 8-14, 10-27, 10-28 OUI 2-10
P Package 1-16, 3-29, 4-12, 4-13, 4-21, 5-21, 5-22, 6-25, 7-17, 8-7, 8-8, 8-18, 9-20, 9-33, 10-30 Password 2-5, 2-6, 2-8, 2-11, 3-16, 4-7, 4-8, 7-14, 8-7, 9-3, 9-17, 9-18, 9-24, 9-27, 9-28, 9-31, 9-33, 9-34, 10-13, 10-15, 10-16, 10-26, 10-29 Performance 1-8, 9-16, 9-30, 10-2, 10-17, 10-23, 10-24, 10-25, 10-35 Pipe 9-23 Policy Manager 5-20 Privilege 1-9, 1-19, 1-20, 3-3, 3-19, 3-21, 4-16, 4-25, 7-15, 8-15, 9-16, 9-17, 9-18, 9-19, 9-20, 9-22, 9-23, 9-24, 9-25, 9-26, 9-27, 9-28, 9-32, 9-33, 9-36, 10-3, 10-16, 10-25, 10-32, 10-33 Procedure 1-16, 3-7, 4-18, 4-26, 5-28, 6-15, 6-17, 6-19, 6-24, 8-5, 8-7, 8-8, 8-14, 10-11, 10-13, 10-17, 10-21, 10-30 PROCESSES 2-7, 9-30, 10-3, 10-27, 10-28 Profile 7-13, 7-14, 9-24 R Realm 1-11, 1-17, 1-18, 1-20, 2-12, 2-13, 2-15, 3-2, 3-3, 3-4, 3-5, 3-6, 3-7, 3-8, 3-9, 3-10, 3-11, 3-12, 3-13, 3-14, 3-15, 3-16, 3-17, 3-18, 3-19, 3-20, 3-21, 3-22, 3-23, 3-24, 3-25, 3-26, 3-27, 3-28, 3-29, 3-30, 4-3, 4-4, 4-10, 5-3, 5-4, 6-5, 6-6, 6-7, 6-16, 6-32, 7-4, 7-5, 8-3, 8-4, 8-5, 8-13, 9-11, 9-12, 9-14, 9-16, 10-4, 10-6, 10-7, 10-9, 10-10, 10-12, 10-14, 10-15, 10-22, 10-25, 10-30, 10-32 Realm algorithm 3-15 Recovery Manager 10-3 Recycle bin 10-32 recyclebin 10-32 RECYCLEBIN 10-32 REMOTE_OS_AUTHENT 9-30
R Role 1-10, 1-11, 1-16, 1-17, 1-18, 1-20, 2-12, 2-13, 2-14, 2-15, 3-4, 3-5, 3-6, 3-13, 3-16, 3-19, 3-20, 3-21, 3-22, 3-25, 3-31, 4-3, 4-4, 4-10, 4-11, 5-3, 5-4, 6-5, 6-6, 6-7, 6-18, 6-22, 6-23, 6-26, 7-4, 7-5, 7-9, 7-10, 8-3, 8-4, 8-5, 8-6, 8-7, 8-8, 8-9, 8-11, 8-12, 8-13, 8-14, 8-15, 8-16, 8-17, 8-18, 8-20, 9-3, 9-11, 9-12, 9-14, 9-15, 9-19, 9-20, 9-21, 9-22, 9-24, 9-25, 9-26, 9-27, 9-28, 10-3, 10-6, 10-7, 10-8, 10-9, 10-21, 10-32 Rule 1-3, 1-6, 1-10, 1-12, 1-14, 1-15, 1-16, 1-17, 1-18, 3-4, 3-5, 3-9, 3-14, 3-15, 3-24, 3-25, 3-26, 3-27, 3-28, 4-3, 4-4, 4-5, 4-6, 4-10, 4-12, 4-17, 4-22, 4-23, 4-24, 5-3, 5-4, 5-7, 5-8, 5-13, 5-28, 6-1, 6-2, 6-3, 6-4, 6-5, 6-6, 6-7, 6-8, 6-9, 6-10, 6-11, 6-12, 6-13, 6-14, 6-15, 6-16, 6-17, 6-18, 6-19, 6-20, 6-21, 6-22, 6-23, 6-24, 6-25, 6-26, 6-27, 6-28, 6-29, 6-30, 6-31, 6-32, 7-2, 7-3, 7-4, 7-5, 7-7, 7-8, 7-9, 7-10, 7-11, 7-12, 7-15, 7-16, 7-17, 7-18, 7-19, 8-3, 8-4, 8-5, 8-6, 8-7, 8-8, 8-9, 8-10, 8-11, 8-13, 8-14, 8-15, 8-16, 8-17, 9-9, 9-11, 9-12, 9-13, 9-14, 9-15, 9-16, 10-4, 10-6, 10-7, 10-8, 10-10, 10-11, 10-12, 10-13, 10-15, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 10-23, 10-26, 10-34 Rule set 1-10, 1-14, 1-15, 1-16, 1-17, 1-18, 3-4, 3-5, 3-9, 3-14, 3-15, 3-25, 3-27, 3-28, 4-3, 4-4, 4-10, 4-17, 4-22, 4-23, 4-24, 5-3, 5-4, 5-7, 5-8, 5-28, 6-2, 6-3, 6-4, 6-5, 6-6, 6-7, 6-9, 6-10, 6-11, 6-12, 6-13, 6-14, 6-15, 6-16, 6-17, 6-18, 6-19, 6-20, 6-21, 6-22, 6-23, 6-24, 6-25, 6-26, 6-27, 6-28, 6-29, 6-30, 6-31, 6-32, 7-3, 7-4, 7-5, 7-7, 7-10, 7-12, 7-16, 8-3, 8-4, 8-5, 8-6, 8-7, 8-8, 8-9, 8-10, 8-11, 8-13, 8-14, 8-15, 8-16, 8-17, 9-11, 9-12, 9-13, 9-14, 9-15, 10-4, 10-8, 10-11, 10-12, 10-13, 10-15, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 10-34 S Scheduler 10-33 Schema 1-10, 1-20, 2-13, 2-16, 3-6, 3-7, 3-9, 3-16, 3-17, 3-18, 3-29, 4-6, 4-8, 4-10, 4-12, 4-16, 4-22, 4-25, 4-26, 5-12, 5-20, 5-31, 6-28, 7-7, 7-9, 7-10, 7-12, 7-17, 8-13, 8-15, 9-8, 9-31, 10-4, 10-5, 10-7, 10-32
S Secure Application Role 1-16, 1-17, 1-18, 3-4, 3-5, 4-3, 4-4, 4-10, 5-3, 5-4, 6-5, 6-6, 6-7, 7-4, 7-5, 8-3, 8-4, 8-5, 8-6, 8-7, 8-8, 8-12, 8-15, 8-16, 8-17, 8-18, 8-20, 9-12, 9-14, 9-15, 10-21 Secure Application Roles 1-3, 1-10, 1-16, 1-17, 1-18, 1-25, 4-10, 6-5, 6-6, 6-7, 8-1, 8-2, 8-3, 8-4, 8-5, 8-6, 8-11, 8-12, 8-18, 8-19, 8-20, 9-9, 9-13, 9-15, 10-22, 10-23 Separation of Duties 1-4, 1-6, 1-8, 1-20, 2-14, 2-15, 3-2, 3-6, 3-30, 9-16, 10-4, 10-14, 10-18 SESSIONS 4-9, 5-17, 5-19, 6-25, 9-34 SPFILE 9-4 SQL*Plus 1-5, 9-17, 10-21 sys_context 10-21 SYSDBA 1-9, 1-19, 2-5, 2-6, 4-8, 6-25, 9-23, 9-24, 10-3, 10-16 SYSOPER 4-8, 9-23, 9-24, 10-3, 10-16, 10-27, 10-28 System privilege 1-9, 1-20, 3-3, 3-19, 9-23, 9-27 T Tablespace 1-6, 7-14, 9-33, 9-34, 10-5 THREAD 9-29 Trace Files 9-28, 10-25 TRANSACTIONS 1-6, 9-30 Trigger 9-24, 9-33, 9-34 V V$INSTANCE 4-7 View 1-6, 1-20, 2-11, 3-24, 3-25, 3-28, 3-30, 4-2, 4-7, 4-22, 4-27, 5-19, 5-26, 5-27, 5-30, 6-2, 6-14, 6-28, 6-31, 7-15, 8-8, 8-15, 8-17, 9-3, 9-8, 9-30, 9-31, 9-32, 10-3, 10-5, 10-6, 10-10, 10-16, 10-31, 10-32 VPD 1-9, 5-20, 6-25, 9-27, 9-34

D47175

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

D47175

Caricato da

Copyright:

Formati disponibili

Oracle Database 10g: Implementing Database Vault

D44719GC10 Edition 1.0 August 2006 D47175

Technical Contributors and Reviewers

is the name of the role to be created.

Column names, table names, filenames, PL/SQL objects

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 2

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 3

What Is Database Vault?

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 4

Database Vault Option

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 5

Benefits of Database Vault

Compliant separation of duties

Protection from insider threat

Customized control of data access conditions

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 6

Oracle Database 10g: Implementing Database Vault 1 - 7

Database Vault: Effects

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 8

Database Vault Versus VPD and OLS

Oracle Label Security (OLS):

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 9

Access Control Components

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 10

Object privileges or Realm participation

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 11

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 12

SECURE identity DOMAIN factor

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 13

Rule Sets: Introduction

AND/OR Rule n TRUE or FALSE

Rule set result

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 14

Command Rules: Introduction

Command type Object Owner Rule set Command rule

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 15

Secure Application Roles: Introduction

Role not enabled

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 16

Component Relationships: Static

Command rule Uses

Secure application role

Copyright 2006, Oracle. All rights reserved.

Oracle Database 10g: Implementing Database Vault 1 - 17

Component Relationships: Dynamic

Secure application role Identity

Factor Rule set

Copyright 2006, Oracle. All rights reserved.