Oracle Database 11g Security

Volume I Student Guide
D50323GC20
Edition 2.0
April 2010
D66808
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
COMPUTER IS STRICTLY PROHIBITED
Oracle University and ORACLE CORPORATION use only
Oracle Database 11g: Security
Authors
Copyright 2010, Oracle and/or it affiliates. All rights reserved.
Donna Keesling
James Spiller
Disclaimer
Tammy Bednar
Tom Best
Maria Billings
Herbert Bradbury
Howard Bradley
Tomohiko Fukuda
Philip Garm
Joel Goodman
Naveen Gopal
Xander Heemskerk
Uwe Hesse
Magnus Isaksson
Tomoki Ishii
Chandrasekharan Iyer
Sushma Jagannath
Martin Jensen
Dominique Jeunot
Victor Lu
Yi L Lu
Tom Minella
Sabiha Miri
Pam Moutrie
Lynn Munsinger
Paul Needham
Roman Niehoff
Preetam Ramakrishna
Surya Rekha
Kevin Reardon
Wayne Reeser
Walter Romanski
Ron Soltani
Kar Srinivasan
Glenn Tripp
Branislav Valny
Peter Wahl
Andrew Webber
Anthony Woodell
Paul Youn
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 and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Editors
Aju Kumar
Amitha Narayan
Raj Kumar
Graphic Designer
Satish Bettegowda
Publishers
Jayanthy Keshavamurthy
Shaik Mahaboob Basha
Sujatha Nagendra
Contributors and
Reviewers
Preface

Profile
Before You Begin This Course
Before you begin this course, you should have the following qualifications:
Working experience with Oracle Database 11g
Or have attended the following courses:
Oracle Database 11g: Administration Workshop II (D50079GC20) inClass
How This Course Is Organized
Oracle Database 11g: Security is an instructor-led course featuring lectures and hands-on
exercises. Online demonstrations and written practice sessions reinforce the concepts and
skills.
Preface - 3
Oracle Database 11g: Administration Workshop I (D50102GC20 ) inClass
Related Publications
Oracle Publications
Title
Part Number
Oracle Database Administrator's Guide 11g Release 2 (11.2)
E10595-06
Oracle Database Advanced Security Administrator's Guide

11g Release 2 (11.2)
E10746-01
Oracle Database Concepts 11g Release 2 (11.2)
E10713-05
E10574-03
Oracle Database Net Services Administrator's Guide

E10836-03
PL/SQL Packages and Types Reference 11g Release 2 (11.2)
E10577-04
Oracle Database Reference 11g Release 2 (11.2)
E10820-03
Oracle Database Security Guide 11g Release 2 (11.2)
E10574-03
Oracle Database SQL Reference 11g Release 2 (11.2)
E10592-04
Oracle Internet Directory Administrator's Guide,

10g (10.1.4.0.1)
B15991-01
Oracle Database Enterprise User Security Administrator's

Guide 11g Release 2 (11.2)
E10744-01
Additional Publications
System release bulletins
Installation and users guides
read.me files
International Oracle Users Group (IOUG) articles
Oracle Magazine
Preface - 4
Oracle Label Security Administrator's Guide
Typographic Conventions
Convention
Object or Term
Example
Uppercase
Commands,
functions,
column names,
table names,
PL/SQL objects,
schemas
Use the SELECT command to view

information stored in the LAST_NAME
column of the EMPLOYEES table.
Lowercase,
italic
Filenames,
syntax variables,
usernames,
passwords
where: role
Initial cap
Trigger and
button names
Assign a When-Validate-Item trigger to

the ORD block.
is the name of the role

to be created.
Select Cancel.
Italic
Quotation marks
Books, names of
courses and
manuals, and
emphasized
words or phrases
For more information on the subject see

Oracle SQL Reference
Manual
Lesson module
titles referenced
within a course
This subject is covered in Lesson 3,

Working with Objects.
Do not save changes to the database.
Preface - 5
The following table lists the typographical conventions that are used in text and code.
Typographic Conventions in Text
Convention
Object or Term
Example
Uppercase
Commands,
functions
SELECT employee_id
FROM employees;
Lowercase,
italic
Syntax variables
CREATE ROLE role;
Initial cap
Forms triggers
Form module: ORD

Trigger level: S_ITEM.QUANTITY
item
Trigger name: When-Validate-Item
. . .
Lowercase
Column names,
table names,
filenames,
PL/SQL objects
. . .
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;
Preface - 6
Typographic Conventions (continued)

Typographic Conventions in Code
Contents
Introduction to Database Security

Course Objectives I-2
Agenda I-3
Prerequisites I-6
Understanding Security Requirements

Objectives 1-2
Fundamental Data Security Requirements 1-3
Data Security Concerns 1-5
Compliance Mandates 1-6
Security Risks 1-8
Security Standards 1-10
Developing Your Security Policy 1-11
Defining a Security Policy 1-12
Implementing a Security Policy 1-14
Quiz 1-15
Techniques for Enforcing Security 1-16
Principle of Least Privilege 1-17
Defense in Depth 1-18
Common Exploits 1-19
Preventing Exploits 1-21
Summary 1-22
Case Study: Applying Security Practices 1-23
Understanding SQL Injection 1-24
Preventing SQL Injection 1-25
Reducing the Attack Surface 1-26
Using Invokers Rights 1-27
Avoiding Dynamic SQL 1-28
Validating Input to Dynamic SQL 1-29
Coding Review and Testing Strategy 1-30
Mitigating the Scope of Exploits 1-31
Avoiding Privilege Escalation 1-32
Trapping and Handling Exceptions 1-33
iii
Preface
Choosing Security Solutions

Objectives 2-2
Assuring Data Integrity 2-3
Data Protection 2-5
Authentication and Authorization 2-7
Networkwide Authentication 2-9
Access Control and Monitoring 2-10
Quiz 2-11
Oracle Database Vault 2-12
Oracle Audit Vault 2-13
Combining Optional Security Features 2-14
Compliance Scanner 2-16
Enterprise Manager Database Control: Policy Trend 2-17
Security at a Glance: Details 2-18
Enterprise Manager Grid Control Security Advisor 2-19
Policy Library 2-20
Summary 2-21
Practice 2 Overview: Hardening Database Access 2-22
Basic Database Security

Objectives 3-2
Database Security: Checklist 3-3
Reducing Administration Effort 3-4
Installing Only What Is Required 3-5
Applying Security Patches 3-6
Secure Password Support 3-7
Automatic Secure Configuration 3-8
Password Configuration 3-9
SYS and SYSTEM Accounts 3-10
SYSDBA, SYSOPER, and SYSASM 3-11
Allowing Remote Database Administration 3-12
Locking and Expiring Default User Accounts 3-13
Changing Default Account Passwords 3-15
Enforcing Password Management 3-17
Enabling Built-in Password Complexity Checker 3-19
Quiz 3-20
Protecting the Data Dictionary 3-21
System and Object Privileges 3-22
Restricting the Directories Accessible by the User 3-23
Managing Fine-Grained Access to External Network Services 3-24
Managing Scheduler Security 3-26
iv
Auditing Database Users, Privileges, and Objects

Objectives 4-2
Monitoring for Suspicious Activity 4-3
Audit Tool Comparisons 4-5
Standard Database Auditing: Overview 4-6
Standard Database Auditing 4-7
Setting the AUDIT_TRAIL Parameter 4-9
Audit Log Location Options 4-10
Moving the Database Audit Trail from the SYSTEM Tablespace 4-11
Limiting the Size of the Operating System Audit Trail 4-13
Limiting the Age of the Operating System Audit Trail 4-14
Clearing the Size and Age Properties 4-15
Specifying Audit Options 4-16
Auditing Sessions 4-18
Viewing Auditing Options 4-20
Viewing Auditing Results 4-21
Quiz 4-22
Purging Audit Trail Records 4-23
Initializing the Audit Trail for Purging 4-24
Setting an Archive Timestamp for Audit Records 4-25
Manually Purging the Audit Trail 4-26
Scheduling an Automatic Purge Job for the Audit Trail 4-27
Auditing the SYSDBA and SYSOPER Users 4-29
Viewing the SYSDBA Audit Trails 4-30
Audit to XML Files 4-32
Writing Audit Records to syslog 4-33
Configuring Auditing to syslog 4-34
syslog Limitations 4-35
Value-Based Auditing 4-37
Triggers and Autonomous Transactions 4-39
Summary 4-41
Practice 4 Overview: Implementing Basic Auditing 4-42
v
External Jobs 3-27

Limiting Users with Administrative Privileges 3-28
Separation of Responsibilities 3-30
Using Available Database Security Features 3-32
Summary 3-33
Practice 3 Overview: Hardening Database Access 3-34
Auditing DML Statements

Objectives 5-2
Fine-Grained Auditing (FGA) 5-3
FGA Policy 5-4
Triggering Audit Events 5-6
Data Dictionary Views 5-7
DBA_FGA_AUDIT_TRAIL 5-8
Quiz 5-9
DBMS_FGA Package 5-10
Enabling and Disabling an FGA Policy 5-11
Dropping an FGA Policy 5-12
FGA Policy Guidelines 5-13
FGA Policy Errors 5-14
Maintaining the Audit Trail 5-15
Summary 5-16
Practice 5 Overview: Implementing Fine-Grained Auditing 5-17
Using Basic User Authentication

Objectives 6-2
User Authentication 6-3
User Identified by a Password 6-4
User Identified Externally 6-5
Protecting Passwords 6-6
Quiz 6-7
Fixed User Database Links 6-8
Encrypted Database Link Passwords 6-9
Database Links Without Credentials 6-10
Database Links and Changing Passwords 6-12
Auditing with Database Links 6-13
Restricting a Database Link with Views 6-14
Summary 6-16
Practice 6 Overview: Using Basic Authentication Methods 6-17
Using Strong Authentication

Objectives 7-2
Strong User Authentication 7-4
Single Sign-On 7-6
Public Key Infrastructure (PKI) Tools 7-7
Certificates 7-8
How to Use Certificates for Authentication 7-9
vi
Using Enterprise User Security

Objectives 8-2
Enterprise User Security 8-4
Oracle Identity Management Infrastructure: Default Deployment 8-5
Oracle Database: Enterprise User Security Architecture 8-6
Authenticating Enterprise Users 8-7
OID Structure Overview 8-9
Quiz 8-10
Setting Up Enterprise User Security 8-11
Installing Oracle Application Server Infrastructure 8-12
Registering the Database 8-13
Managing Enterprise User Security 8-14
Creating an Enterprise User 8-15
Creating an Enterprise User in the Directory 8-16
Creating a Schema Mapping Object in the Directory: Subtree 8-17
Creating a Schema Mapping Object in the Directory: User Name 8-18
Identifying the Enterprise User 8-19
Enabling Current User Database Links 8-20
User Migration Utility 8-21
Enterprise-User Auditing 8-23
Summary 8-24
Practice 8 Overview: Implementing Enterprise User Security 8-25
vii
Configuring SSL on the Server 7-10

Configuring Oracle Net Files on the Server 7-11
Configuring SSL on the Client 7-12
Configuring Oracle Net Files on the Client 7-13
Creating a User Identified by a Certificate 7-15
Connecting to the Database 7-16
Quiz 7-17
orapki Utility 7-18
How to Use Kerberos for Authentication 7-19
How to Use KDC with Windows 2000 for Authentication 7-21
RADIUS Authentication: Overview 7-23
Secure External Password Store 7-24
Configuring the Wallet 7-25
Configuring sqlnet.ora 7-26
Managing the External Password Store 7-27
Summary 7-28
Practice 7 Overview: Configuring the External Secure Password Store 7-29
Using Proxy Authentication

Objectives 9-2
Security Challenges of Three-Tier Computing 9-4
Identifying the Real User 9-5
Common Implementations of Authentication 9-7
User Reauthentication 9-9
Restricting the Privileges of the Middle Tier 9-11
Implementing Proxy Authentication Solutions 9-12
Quiz 9-14
Authenticating Database and Enterprise Users 9-15
Using Proxy Authentication for Database Users 9-17
Using Proxy Authentication for Enterprise Users 9-19
Proxy Access Through SQL*Plus 9-21
Enterprise User Proxy 9-22
Enterprise User Proxy: Example 9-23
Revoking Proxy Authentication 9-25
Application-User Model 9-26
Data Dictionary Views for Proxy Authentication 9-28
Data Dictionary Views: DBA_PROXIES and USER_PROXIES 9-29
Data Dictionary Views: V$SESSION_CONNECT_INFO 9-30
Auditing Actions Taken on Behalf of the Real User 9-31
Data Dictionary Views: DBA_STMT_AUDIT_OPTS 9-33
Data Dictionary Views: DBA_AUDIT_TRAIL 9-34
Summary 9-35
Practice 9 Overview: Implementing Proxy Authentication 9-36
10 Using Privileges and Roles

Objectives 10-2
Authorization 10-3
Privileges 10-4
Roles 10-5
Benefits of Roles 10-6
Predefined Roles 10-7
CONNECT Role Privileges 10-8
Using Proxy Authentication with Roles 10-9
Quiz 10-10
Using Enterprise Roles 10-11
Creating an Enterprise Role 10-12
viii
11 Using Application Contexts

Objectives 11-2
Application Context: Description 11-3
Creating a Context in a Namespace 11-4
Using the Application Context 11-5
Setting the Application Context 11-6
Using the SYS_CONTEXT PL/SQL Function 11-7
Application Context Data Sources 11-8
Quiz 11-10
Implementing a Local Context 11-11
Step 1: Create an Application Context 11-12
Step 2: Create a PL/SQL Package That Sets the Context 11-14
Step 3: Call the Package 11-15
Step 4: Read the Context Attribute in the Application 11-16
Application Context Accessed Globally 11-17
Application Context Accessed Globally in Action 11-19
Using the DBMS_SESSION Package 11-21
Implementing the Application Context Accessed Globally 11-24
Step 1: Create the Application Context Accessed Globally 11-25
Step 2: Establish a Session 11-26
Step 3: Handle Subsequent Requests 11-27
Step 4: End a Session 11-28
Viewing Application Context Information 11-29
Application Context Usage Guidelines 11-31
Summary 11-33
Practice 11 Overview: Creating an Application Context 11-34
ix
Assigning an Enterprise User to an Enterprise Role 10-13

Securing Objects with Procedures 10-14
Secure Application Role 10-15
Implementing a Secure Application Role 10-16
Step 1: Create the Role 10-17
Step 2.a: Create the Package Specification 10-18
Step 2.b: Create the Package Body 10-19
Step 3: Grant the EXECUTE Privilege on the Package 10-21
Step 4: Write the Application Server Code That Sets the Role 10-22
Viewing Dictionary Information for Secure Application Roles 10-23
Summary 10-24
Practice 10 Overview: Implementing the Secure Application Role 10-25
x
12 Implementing Virtual Private Database

Objectives 12-2
Fine-Grained Access Control: Overview 12-3
Understanding Fine-Grained Access Control Policy Execution 12-5
Benefits of Using Fine-Grained Access Control 12-7
Virtual Private Database 12-8
Examples of Virtual Private Database 12-9
Quiz 12-11
Tools to Implement Virtual Private Database 12-12
Enterprise Manager 12-14
Managing VPD Policies 12-15
Using DBMS_RLS to Manage Policies 12-16
Column-Level VPD 12-18
Column-Level VPD: Example 12-19
Policy Types: Overview 12-20
Static Policies 12-21
Context-Sensitive Policies 12-22
Sharing Policy Functions 12-23
Exceptions to VPD Policies 12-24
Designing and Implementing a VPD Solution 12-25
Implementing a VPD Policy 12-26
Creating a Package and Context 12-27
Writing the Function That Creates a Predicate 12-29
Testing the Security Function 12-31
Writing a Function That Returns Different Predicates 12-32
Creating a Policy 12-34
Quiz 12-35
Implementing Policy Groups 12-36
Grouping Policies 12-38
Default Policy Group 12-39
Creating a Driving Context 12-41
Making the Context a Driving Context 12-43
Creating a Policy Group 12-45
Adding a Policy to a Group 12-46
Best Practices for VPD 12-48
Guidelines for Policies and Context 12-49
Policy Performance 12-51
Export and Import 12-53
Policy Views 12-54
Checking for Policies Applied to SQL Statements 12-55
13 Oracle Label Security Concepts

Objectives 13-2
Access Control: Overview 13-3
Discretionary Access Control 13-4
Oracle Label Security 13-5
How Sensitivity Labels Are Used 13-6
Installing Oracle Label Security 13-7
Quiz 13-8
Oracle Label Security: Features 13-9
Comparing Oracle Label Security and VPD 13-11
Oracle Label Security and VPD Comparison 13-12
Analyzing Application Requirements 13-13
Summary 13-14
14 Implementing Oracle Label Security
Objectives 14-2
Implementing an Oracle Label Security Solution 14-3
Step 3: Create Policies 14-5
Policy Enforcement Options 14-6
Step 4: Define Labels: Overview 14-8
Defining Levels by Using Enterprise Manager 14-9
Creating Levels 14-10
Defining Groups by Using Enterprise Manager 14-11
Creating Groups 14-12
Defining Compartments by Using Enterprise Manager 14-13
Creating Compartments 14-14
Identifying Data Labels 14-15
Creating Data Labels 14-16
Access Mediation 14-17
Administering Labels 14-18
Adding Labels to Data 14-19
Step 5: Apply the Policy to a Table 14-20
Step 6: Assign User Authorization Labels 14-21
Quiz 14-23
Oracle Label Security Special User Privileges 14-24
Example: READ Privilege 14-25
Example: FULL Privilege 14-26
Example: COMPACCESS Privilege 14-27
xi
Summary 12-56
Practice 12 Overview: Implementing a Virtual Private Database Policy 12-57
15 Using the Data Masking Pack

Objectives 15-2
Data Masking: Overview 15-3
Understanding Data Masking 15-4
Using the Data Masking Pack 15-5
Accessing the Data Masking Pack 15-6
Data Masking Pack: Features 15-7
Data Masking: Best Practices 15-8
Implementing Data Masking 15-9
Identifying Sensitive Data for Masking 15-11
Quiz 15-12
Determining How to Mask the Data 15-13
Managing the Data Mask Format Library 15-14
Using Oracle-Supplied Mask Formats 15-15
Types of Built-in Masking Primitives and Routines 15-16
Example: Data Masking of the EMPLOYEES Table 15-18
Creating Data Mask Formats 15-19
Creating a User-Defined Data Mask Format 15-20
Creating a Masking Format Using a User-Defined Function 15-21
Creating Data Masking Definitions 15-22
Using Masking Formats 15-23
Automatic Identification of Related Columns 15-24
Adding Dependent Columns 15-25
Importing Formats 15-26
Importing Formats and Modifying Properties 15-27
Using Condition-Based Masking 15-28
Using Compound Masking 15-29
Using a User-Defined Masking Function 15-30
Creating a Post-Processing Function 15-31
Implementing a Post-Processing Function 15-32
Generating the Data Masking Script 15-33
Viewing the Data Masking Impact Report 15-34
Viewing the Data Masking Script 15-35
xii
Using the PROFILE_ACCESS Privilege 14-28

Trusted Stored Package Units 14-30
Exporting with Oracle Label Security 14-31
Importing with Oracle Label Security 14-32
Performance Tips 14-33
Summary 14-35
Practice 14 Overview: Implementing Oracle Label Security 14-36
16 Encryption Concepts
Objectives 16-2
Understanding Encryption 16-3
What Problems Does Encryption Solve? 16-4
Cost of Encryption 16-5
Encryption Is Not Access Control 16-6
Access by Privileged Users 16-7
What to Encrypt 16-9
Quiz 16-10
Data Encryption: Challenges 16-11
Encryption Key Management: Key Generation 16-12
Encryption Key Management: Key Modification and Transmission 16-13
Encryption Key Management: Storage 16-14
Storing the Key in the Database 16-15
Storing the Key in the Operating System 16-17
Letting the User Manage the Key 16-18
Solutions 16-19
Summary 16-20
17 Using Application-Based Encryption
Objectives 17-2
Overview 17-3
DBMS_CRYPTO Package 17-4
Generating Keys Using RANDOMBYTES 17-6
Quiz 17-9
Using ENCRYPT and DECRYPT 17-10
Enhanced Security Using Cipher Block Modes 17-13
Hash and Message Authentication Code 17-14
Summary 17-17
Practice 17 Overview: Using DBMS_CRYPTO for Encryption 17-18
xiii
Scheduling the Data Masking Job 15-36

Specifying Automatic Masking After Cloning 15-37
Understanding the Data Masking Process 15-38
Creating an Application Masking Template 15-39
Importing Data Masking Definitions 15-40
Controlling Data Masking Operations 15-41
Creating Custom Reports for Auditors 15-42
Summary 15-45
Practice 15 Overview: Implementing Data Masking 15-46
19 Applying File Encryption

Objectives 19-2
RMAN-Encrypted Backups 19-3
Oracle Secure Backup Encryption 19-4
Encrypted Backups to Tape 19-6
Creating RMAN-Encrypted Backups 19-7
Using Transparent-Mode Encryption 19-8
Using Password-Mode Encryption 19-10
Using Dual-Mode Encryption 19-11
Quiz 19-12
Restoring Encrypted Backups 19-13
xiv
18 Applying Transparent Data Encryption

Objectives 18-2
Transparent Data Encryption 18-3
Benefits of TDE 18-4
Components of TDE 18-5
Using TDE 18-6
Creating the Master Key 18-7
Opening the Wallet 18-9
Using Auto Login Wallet 18-11
Backup and Recovery of the Wallet 18-12
Quiz 18-13
Master Key Re-Key Concepts 18-14
Re-Keying Table Keys 18-15
Using Hardware Security Modules 18-16
Configuring for Hardware Security Modules 18-17
Creating an Encrypted Column 18-20
Encrypt Clause Syntax 18-21
Creating an Index on an Encrypted Column 18-22
Altering an Encrypted Column 18-23
TDE Column Encryption Support 18-24
TDE Column-Level Storage Requirements 18-26
TDE Column Encryption: Restrictions 18-27
Tablespace Encryption: Advantages 18-28
Creating an Encrypted Tablespace 18-29
Tablespace Encryption: Restrictions 18-30
Exporting and Importing with TDE 18-31
SECUREFILE LOB Encryption 18-32
Summary 18-33
Practice 18 Overview: Implementing TDE 18-34
RMAN-Encrypted Backups: Considerations 19-14

Data Pump Encryption 19-15
ENCRYPTION Parameter 19-16
ENCRYPTION_MODE Parameter 19-18
Encrypting Dump Files 19-19
Summary 19-20
Practice 19 Overview: Using RMAN Backup File Encryption 19-21
20 Oracle Net Services: Security Checklists
Objectives 20-2
Overview: Security Checklists 20-3
Client Checklist 20-4
Issues with Securing the Client Computer 20-5
Configuring the Browser 20-6
Network Security: Checklist 20-7
Using a Firewall to Restrict Network Access 20-8
Restricting Network IP Addresses: Valid Node Checking 20-9
Restricting Network IP Addresses: Guidelines 20-11
Configuring IP Restrictions with Net Manager 20-12
Quiz 20-13
Restricting Open Ports 20-14
Encrypting Network Traffic 20-15
End-to-End Encryption 20-17
Configuring Network Encryption 20-18
Checksumming 20-19
Configuring Checksumming 20-20
Oracle Net Services Log Files 20-21
Summary 20-23
Practice 20 Overview: Configuring Net Security 20-24
21 Securing the Listener
Objectives 21-2
Listener Security: Checklist 21-3
Moving the Listener to a Nondefault Port 21-4
Password-Protecting the Listener 21-5
Preventing Online Administration of the Listener 21-7
Quiz 21-8
Administering the Listener Using TCP/IP for SSL 21-9
INBOUND_CONNECT_TIMEOUT 21-10
Setting Listener-Logging Parameters 21-12
xv
ENCRYPTION_PASSWORD Parameter 19-17
Analyzing Listener Log Files 21-14

Listener Log Connect: Examples 21-16
Listener Log Command: Examples 21-18
Summary 21-20
Practice 21 Overview: Securing the Listener 21-21
Appendix B: Using Oracle Connection Manager as a Firewall

Objectives B-2
Overview of Firewalls B-3
Network Architecture Regions B-4
Guidelines for Positioning Servers Within Firewalls B-5
Using a Firewall to Restrict Database Access B-6
Types of Firewalls B-7
Control Traffic from the Internet B-8
Using Oracle Connection Manager as a Firewall B-10
Oracle Connection Manager: Overview B-11
Oracle Connection Manager Processes B-12
Oracle Connection Manager Architecture B-13
Access Control with Oracle Connection Manager B-14
Configuring Oracle Connection Manager B-15
Configuring the cman.ora File B-16
Preventing Remote Administration of Oracle Connection Manager B-18
Allowing or Denying Access B-19
Configuring Clients to Use CMAN B-21
Configuring Database Servers to Use CMAN B-22
Oracle Connection Manager Control Utility B-23
Starting and Shutting Down Oracle Connection Manager B-24
Additional Commands B-26
Monitoring Connection Events Using the CMAN Log File B-28
Analyzing Oracle Connection Manager Log Files B-30
Summary B-31
Practice 22 Overview: Implementing CMAN as a Firewall B-32
Appendix C: Securing SQL*Plus

Objectives C-2
Limiting Commands Available in SQL*Plus C-3
Creating the PUP Table C-4
xvi
Appendix A: Practices and Solutions
Commands That Can Be Disabled C-6

Example: Disabling a Command C-7
Disabling a Role C-8
Example: Disabling a Role C-9
Using SET ROLE to Enable a Disabled Role C-11
PRODUCT_USER_PROFILE: Guidelines C-13
Summary C-14
Practice 23 Overview: Securing SQL*Plus C-15
Appendix D: Source Code
Appendix E: USERENV Context
xvii
Example: Disabling SET ROLE C-12

Copyright 2010, Oracle and/or its affiliates. All rights reserved.
After completing this course, you should be able to do the

following:
Describe security risks and solutions
Secure your database and network
Choose a user-authentication model
Implement Enterprise User Security
Implement database and fine-grained auditing
Authorize users with roles and secure application roles
Manage data by using Virtual Private Database (VPD) and
Oracle Label Security
Implement Data Masking
Encrypt and decrypt columns, tablespaces, and files
Oracle Database 11g: Security I - 2
Course Objectives
Agenda
Lesson
Topic
Auditing Database Users, Privileges, and Objects
Day
Day
Lesson
Topic
10
Using Privileges and Roles
11
Using Application Contexts
12
Implementing Virtual Private Database
13
Oracle Label Security Concepts
14
Implementing Oracle Label Security
15
Using the Data Masking Pack
16
Encryption Concepts
17
Using Application-Based Encryption
18
Applying Transparent Data Encryption
19
Applying File Encryption
Agenda
Day
Lesson
Topic
20
Oracle Net Services: Security Checklists
21
Securing the Listener
Optional
App B
Using Oracle Connection Manager as a Firewall
Optional
App C
Securing SQL*Plus
Agenda
For this course, it is assumed that you have attended:

Oracle Database 11g: Administration Workshop I (or
equivalent experience)
Oracle Database 11g: Administration Workshop II (or
equivalent experience)
Prerequisites
After completing this lesson, you should be able to do the

following:
Describe business security requirements
Define the following terms:
Least privilege
Authorization
Authentication
Describe security policies

Describe the concept of in-depth security
Apply these concepts to prevent SQL injection
Oracle Database 11g: Security 1 - 2
Objectives
Security standards require security policies to meet

fundamental data security requirements:
Confidentiality: Ensure that individuals see only the data
they are supposed to see
Integrity: Ensure that data remains valid
Availability: Ensure that denial-of-service attacks do not
impact access to and use of systems
Fundamental Data Security Requirements

Security standards include both legal and business standards. These standards require that your
security policy meet the following fundamental requirements:
Confidentiality: Confidentiality ensures that individuals see only the data that they are
supposed to see. This includes:
- Privacy of communication
- Secure storage of data, including backup media (may require encryption)
- Secure transmission of sensitive data (may require network encryption)
- Restricted access to services
- Authenticated users (only authenticated users may see data)
- Granular access control (only authorized users may view allowed data)
Integrity: A secure system ensures that the data remains valid. Data integrity means that data is
protected from deletion and corruption, both while it resides within the database and while it is
being transmitted over the network. Integrity has several aspects:
- System and object privileges control access to application tables and system commands,
so that only authorized users can change data.
Fundamental Data Security Requirements
Fundamental Data Security Requirements (continued)

- Constraints contribute to integrity by enforcing rules on data to keep it valid. For
example, referential integrity is a constraint that maintains valid relationships
between entities in the database, according to the rules that have been defined.
- A database must be protected against viruses that are designed to corrupt the data.
- The network traffic must be protected from deletion, corruption, and eavesdropping.
Availability: Availability is usually thought of as a backup and recovery issue, and not as a
security issue; however, denial-of-service (DoS) attacks attempt to block authorized users
ability to access and use the system when needed. Preventing DoS attacks is a security
issue. These attacks usually gain unauthorized access to computers, and then use these
computers to generate requests that flood the targeted system.
Availability can sometimes be hindered by your own security measures. Very restrictive
firewalls can protect your resources, but can also block access for authorized users.
Data Security Concerns
Identity theft
Insider threats
Data consolidation
Globalization
Right sourcing
Compliance
mandates
SOX
HIPAA
EU directives
PCI
FDA
GLBA
Basel II
SB1386
Data Security Concerns

Every business should recognize and develop policies that protect it. The accounting policies provide
investors with the assurance that the company is sound and well managed. Engineering and safety
policies assure customers and employees that proper precautions are being taken to protect the health
and safety of both. These policies also protect the business from liability. Computer security policies
serve a similar function. Privacy policies are required by the Payment Card Industry (PCI) for
businesses that process credit cards. Customers may be attracted or repelled by certain privacy
policies. Data security can prevent proprietary data from being stolen or abused.
Worldwide, businesses are adopting new computer security policies. For some, these policies are
driven by law; others, by the threat of theft, fraud, or sabotage; and still others, by the need for
approval by financial regulators, access to credit cards, or investors.
Industrial espionage
Security
threats
Sarbanes-Oxley Act (SOX), J-SOX

European Union Data Protection Directive
Other U.S. laws
Payment Card Industry Data Security Standard (PCI DSS)
Reasonable care
Security Audits
Compliance Mandates
Security requirements have been a matter of individual concern until recently. Unless you were
handling government or military data, there were few legal requirements. This is rapidly changing. A
variety of laws have been passed to enforce privacy and accuracy of data in North America and
Europe. Along with these laws comes a requirement to audit the security measures that are in place.
These laws are becoming a pattern for laws in other countries, such as India and Japan.
Legal: Each of the laws listed here has specific requirements. This list is representative of many
other laws that are being passed worldwide. These laws and industry standards are being held as a
measure of reasonable care.
Sarbanes-Oxley Act (SOX) requires that publicly traded companies in the United States
strengthen and document internal controls to prevent individuals from committing fraudulent
acts that may compromise an organizations financial position or the accuracy of its financial
statements. The chief executive officer and the chief financial officer must attest to the
adequacy of the internal controls and accuracy of the financial report. These officers are subject
to fines and imprisonment for a fraudulent report. The requirements of SOX include providing
information that is used to generate the reports and providing documentation about the internal
controls used to assure the integrity of the financial information. Other countries, such as Japan,
are implementing similar laws.
Compliance Mandates
Compliance Mandates (continued)

European Union Data Protection Act is intended to protect individual privacy by
restricting access to individually identifiable data. It has eight points, one of which requires
that data be kept secure.
Other U.S. laws:
- Health Information Portability and Accountability Act (HIPAA) is intended to
protect personally identifiable health information (PII) from release or misuse.
Information holders must provide audit trails of all who access this data.
- Family Educational Rights and Privacy Act (FERPA) covers health and personally
identifiable information held by schools.
- California Security Breach Notification Law requires that an organization holding
a variety of personally identifiable information (PII)for example, credit card,
drivers license, and government identity numbersmust protect this information. If
the information has been compromised, the organization must notify any resident of
California whose unencrypted personal information was or is reasonably believed to
have been acquired by an unauthorized person. There are two laws (CA-SB-1386 and
CA-AB-1950) that apply to organizations that hold PII.
- Federal Information Security Management Act (FISMA) creates security
guidance and standards through Federal Information Processing Standard (FIPS)
documents that are managed by the National Institute of Standards and Technology
(NIST). These standards are applied to organizations that process information for the
U.S. government.
Payment Card Industry Data Security Standard (PCI DSS): For a business that captures
credit card information, there are strict rules imposed by contract and possible fines.
Security Audits: Many of these laws include provisions that require that the security plans
(internal controls) be audited periodically. SOX requirements are vague and subject to
interpretation by the officers of the organization. The implementation details can vary widely,
depending on the level of detail that the officers require. Although SOX is vague, its penalties
are severe. It is thus important to protect your company. The cost of security measures must be
balanced against the risk. No one can certify that you are 100% secure.
Reasonable Care: A good solution to determining the proper level of security measures to
implement is industry consensus. If you meet the agreed-upon minimum security practices and
have accomplished due diligence, you may be safe from the worst penalties of the law. The
current legal environment also requires reasonable care or due care. Due care is defined as the
conduct that a reasonable man or woman will exercise in a particular situation, in looking out for
the safety of others. If one uses due care, an injured party cannot prove negligence. If the
security audit is part of due diligence, applying patches and hardening the system could be
considered part of due care.
You, as DBA, security officer, or auditor, may be held responsible if you know of good practices
and do not follow them, or if you neglect to be informed of common security solutions. Because
of due diligence and due care, you must be able to advise management on the technical security
measures that are available in the database. This course helps you to be informed of common
security issues and solutions.
Security Risks
External threats:
Internal threats:
Unauthorized users
Denial of service
Unauthorized data access
Exploits: SQL injection and others
Abuse: Data theft
Sabotage: Data or service corruption
Complexity
Recovery
Omission
External threats listed above
Partners
Security Risks
Security risks come with accessibility. Accessibility makes your data valuable. If all your data were
in filing cabinets or vaults, you could be sure that it was secure, but the time to retrieve it would
make it worthless. External exploits by criminals breaking into systems get big headlines, but
industry specialists estimate that 80% to 90% of the damage to information systems is done by
insiders.
No system can be guaranteed to be 100% secure. The costs of securing a system are weighed against
the possible costs of a security breach, whether it is internal or external. A thorough review can be
expensive. But it is important to be aware of the issues, set the priorities, and determine the funding.
Some of the security standards, such as ISO/IEC 17799:2005, require a risk assessment and provide
guidance.
External Threats
Unauthorized users: These are outsiders who gain access to your system. They may use
software exploits, bypass login information, crack passwords, or use social engineering. They
may be helped by poor passwords, unattended terminal sessions, and unsecured servers or
modem lines. Even your trash may contain information that allows them to get into your
system.
Denial of service: It can be an attack from a malicious source that requests limited resources
such as port allocations to disrupt authorized users. It can be accidentally caused by authorized
users who make inappropriate requests.
Security Risks (continued)

Unauthorized data and service access: When an outsider obtains authentication, the
system sees him or her as a valid user. This user then has the privileges granted to insiders.
Exploits: This is a method of gaining access. SQL injection is a type of exploit that may
accomplish one or more of the external threats listed.
Internal Threats
All the threats that are listed as outsider threats may also be performed by insiders. For example,
an insider can gain unauthorized access by watching an authorized user enter a password.
Abuse of privilege: Internal users have a justified authorization to your system. But using
that authorization to gain unauthorized access to certain dataor using the services in
unauthorized waysis considered to be abuse.
Data or service theft: After access to data and services is obtained, theft is easy. This can
be as minor as playing games on the server or as severe as selling proprietary information
to a competitor. Personally identifiable information (PII) has become the most valuable
information on systems, both in terms of the value to unauthorized users (identity theft) and
cost when this information is compromised.
Sabotage (data or service corruption): Sabotage by authorized users is always a
possibility. This can be subtle or well intentioned: a data clerk altering data to help friends
or a programmer leaving debug code in a program. The corruption can be intentionalfor
example, altering financial reports to move the stock price or cover embezzlement.
Complexity: Increased complexity of the system increases the likelihood of security holes
or avenues of attack that have been overlooked. One of the most overlooked security holes
is passwords. Users forget or write down passwords when passwords are required to meet
stronger complexity checks. Users often use simple passwords or write passwords in easyto-find locations when they have many accounts. Some customers report that as much as
70% of their help-desk time is consumed by password resets. Single sign-on systems help
reduce the complexity, allowing the user to remember one strong password instead of
trying to remember several. But a poorly designed single sign-on system can allow a single
breach to access multiple systems.
Recovery: What measures are in place to recover your systems if a breach should occur?
How long will it take to have your system operational? Is there another system that can be
placed in service so that the breached system may be examined forensically?
Omission: How do you verify that the policies that are determined to be necessary are in
place, and consistently applied across your systems? If access control and authorization
policies are not applied properly, OS security patches will not prevent unauthorized access.
Omission in policies allow holes in the security that do not require sophisticated skills to
exploit.
Partners
A relatively new area of concern and risk is partner access. The partner has authorized access to
your system, but you do not have control of the partners security policies.
External threat: When external attackers breach the partner system, they have the same
access that the partner is permitted.
Partner threat: A growing number of breaches occur when the partner accesses sensitive
data or proprietary information that is not appropriate for the partner to access. This occurs
when the partner is allowed internal user type access.
Organizations publishing recognized security standards:

SANS Institute
Computer Emergency Response Team (CERT/CC)
International Standards Organization (ISO 17799/27002)
Do your policies meet the standards?
Security Standards
Several organizations produce guidelines for industry standard practices. Some of these are:
SysAdmin, Audit, Network, Security (SANS) Institute, and the Computer Emergency Response
Team (CERT/CC) operated by Carnegie Mellon University for the United States of America
Department of Defense. More information about these organizations and the services that they
provide can be found at www.sans.org and www.cert.org
The International Standards Organization (ISO) produces standards for a broad range of industries.
ISO-17799/27002 is an international standard of computer security practices. It includes best
practices, certification, and risk assessment. It covers a broad range of issues and includes prewritten
policies. For more information about ISO-17799/27002, see: www.iso.org or
www.computersecuritynow.com
Security requirements are changing. It is important to be aware of the changes and their impact. The
organizations listed in the slide (and others) provide newsletters and study opportunities.
Security Standards
To develop your security policy, perform the following steps:

1. Assemble your security team.
2. Define your security requirements.
3. Develop procedures and systems to meet these
requirements.
4. Implement security procedures.
5. Audit.
Developing Your Security Policy

1. Assembling Your Security Team: First, determine which people in your organization will
participate on the security team. To be effective, this team must include system architects,
system administrators, database administrators (DBAs), network administrators, data owners,
and representatives of end users. Although technical personnel monitor security, you must also
include data owners and end users when defining your security requirements. Others to be
included in the team are business experts who understand the organization, security, and
disclosure requirements, and legal experts who know the legal requirements for handling the
data of the organization.
2. Defining Security Requirements: To define your security requirements, examine who needs
access to which data and services, and why they need it.
3. Developing Security Procedures and Systems: After you know the security requirements of
your organization, you can develop procedures and systems to meet these requirements.
4. Implementing Security Procedures: Now that you have defined a policy, implement it to
secure the data on a day-to-day basis.
5. Audit: A security policy will have specific details that can be audited. An audit of your systems
and procedures will confirm that the security policy has been implemented.
Developing Your Security Policy
Defining a Security Policy

What is a security policy?
A set of rules
Specific to an area and site
Required
Approved by management
What is a standard?
Rules specific to a system or process
Required for everyone
What are guidelines?

Suggestions and best practices
Specific to a system or a process
Best practices
Defining a Security Policy

A security policy is set of documents that are specific to your site. Policy documents are approved
by the management. They identify what is required by the company. The policy applies to a specific
security area, such as acceptable use of modems, or formation of passwords. A policy is a set of
mandatory rules. It must be only as long as required (a couple of pages) and easy to understand. It
must be enforceable. To be successful, a policy must balance protection and productivity. Policies
should include:
Configuration management: Who is responsible for the security and to what level?
Incident reports: How are security incidents handled?
Infractions: What are the consequences of security violations?
A standard is a set of rules that apply to a specific system or process (for example, securing external
procedures). Policies refer to standards. Standards, procedures, and guidelines are established at the
department level and are much more detailed. They spell out what must be done to meet the policy
for example, your developers should have a secure coding standard that specifies certain coding
practices that must be followed.
A guideline is a suggestion or a best practice for a specific system or process. Policies refer to
guidelines. For novices, it is critical to get examples, especially for meeting the requirements of SOX
or HIPPA. The SANS Institute and CERT/CC are very good resources.
Legal Implications
The legal department must be consulted and must approve the policy or procedure. How the
policies are written and enforced can have a direct impact on whether you can prosecute
violations and on whether your company is financially liable when breaches occur. The legal
comment is critical. Security consultants have been sued for running password crackers on the
network without written permission, even when they were being proactive. Legal advice is also
critical when looking at warning banners and email monitoring. For your own protection,
establish approved procedures for all forms of monitoring, sniffing, and cracking; such procedures
should specify approved monitoring activities and should explicitly identify who performs these
activities.
Best Practices
Security policies can often include references to best practice recommendations. Oracle provides
a set of recommendations that can be accessed on the Oracle Database 11g: Maximum Security
Architecture Web page at http://www.oracle.com/technology/deploy/security/databasesecurity/maximum-security-architecture.html.
Defining a Security Policy (continued)

Policies must be reviewed and updated regularly. By creating policies in a modular format, the
pieces may be updated as needed without having to change a massive document. Policies should
not go into details that change frequently, such as OS versions or hardware models.
Implement your standards and procedures.

Implement the plan for developing new systems and
applications.
Monitor and enforce the policy.
Keep systems and applications up-to-date with security
patches.
Educate users.
Implementing a Security Policy

Now that you have a policy defined, implement it to secure the data on a day-to-day basis.
If you need to add systems or develop new applications to complete your security policy,
immediately implement as much of the policy as you can without these systems. Then as you
complete the new systems and applications, revise your security policy to include them.
Monitoring and Enforcing Security
Ensure that all employees understand the significance of keeping your organization secure.
Employees must understand the security issues associated with their functions in the organization.
They must also be aware of how they may be disciplined if they breach the security policy.
Applying Security Patches
System administrators and DBAs who are responsible for software installations must search for and
apply security patches on a periodic basis. As part of the security policy, include a schedule to search
for and apply new security patches.
Implementing a Security Policy
A successful security policy should balance protection and

productivity.
a. True
b. False
Answer: a
Quiz
Authentication
Authorization
Access control
Auditing
Encryption
Techniques for Enforcing Security

The following techniques are used to enforce security:
Authentication is the process by which a users identity is checked. When a user is
authenticated, the user is verified as an authorized user of an application.
Authorization is the process by which a users privileges are ascertained.
Access control is the process by which a users access to physical data in the application is
limited, based on the users privileges. Access control is a critical issue in systems that hold
sensitive or personally identifiable information (PII).
Auditing is the process that allows users to be held accountable for their actions, both by
verifying that users are not using their privileges improperly and as a deterrent to unauthorized
access attempts.
Encryption is the process of transforming data into meaningless symbols until a key is applied
to transform it into the original form. Encryption is used to protect data during transmission and
on disk. Encryption is not access control.
For example, if JAUSTEN is trying to access the database, authentication would identify her as a
valid user. Authorization would verify her right to connect to the database with Product Manager
privileges. Access control would enforce the Product Manager privileges upon her user session.
Auditing could record her connection times and any access made to sensitive data.
Techniques for Enforcing Security
Install only the required software on the machine.

Activate only the required services on the machine.
Give operating system (OS) and database access to only
those users who require access.
Limit access to the root or administrator account.
Limit access to privileged database accounts.
Limit users access to only the database objects that they
require to do their jobs.
Principle of Least Privilege

Apply the principle of least privilege starting at the lowest level, and continue at every level. Least
privilege is the principle that users should have the fewest privileges necessary to perform their
duties. There will always be new security exploits that cannot be anticipated. By applying this
principle, the possibility of the exploit is reduced and the damage can be contained.
Install only the required software on the machine: Reduce maintenance, upgrades, the
possibility of security holes, and software conflicts by reducing the number of software
packages installed.
Activate only the required services on the machine: Fewer services imply fewer open ports
and fewer attack vectors.
Give OS and database access to only those users who require access: Having fewer users
means requiring fewer passwords and accounts. Reduce the possibility of open or stale
accounts. With fewer accounts, it is easier for the administrator to keep the accounts current.
Limit access to the root or administrator account: The administrator account must be
carefully guarded, audited, and never shared.
Limit access to privileged database accounts: Any user that can connect as SYSDBA,
SYSOPER, or SYSASM has access to a higher level of privileges. Users who require access as
SYSDBA, SYSOPER, or SYSASM must each have his or her own account, and must be audited.
Limit users access to only the database objects required to do their jobs: Do they have a
need to know? Users who have access to more objects and services than they require have an
THESE eKIT opportunity
MATERIALS ARE
FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
for mischief.
Principle of Least Privilege
Using the concept of defense in depth:

Enforce security policies
Train users
Harden the operating system
Use firewalls
Use network security
Use database security features
Defense in Depth
Defense in depth means that you consider every level (OS, network, file system permissions,
database, firewall, password protection, user education, and software bug fixes). The defeat of one
security feature must not give full access to all data or services. A policy is a roadmap for security
implementation, but it must be implemented to be effective. Users must be trained to avoid activities
that could easily breach security. You may have a perfect firewall and antivirus checking on all
incoming traffic, but if a user working from home downloads a virus or a Trojan, it can infect the
network from behind the firewall.
The operating systems on machines that host the application server, the database, the mail server, and
other critical services must be hardened. The network services, firewalls, and proxies each add
another layer. Then, secure the database. Every layer shown in the slide needs to be in place. Each
level complements the others to achieve better security. Defense in depth considers everything.
The list presented in the slide is an outline of best practices. This course deals with database-related
items from several of these items.
Defense in Depth
There are several classes of common exploits:

Phishing
Well-known and default accounts
Backdoors
Debug code
Cross-scripting
SQL injection
Two main methods of preventing these attacks:
Educate users about social engineering (limited
effectiveness).
Use secure coding practices.
Common Exploits
An exploit is a technique used to attack, sabotage, gain unauthorized access to data or services, or to
deny service to authorized users. There are several general classes of methods used. Some of the
most common are listed.
Phishing is a social engineering method. A carefully crafted email, Web page, or even a phone
call to unsuspecting end users can be used to obtain personal information that can then be used
for identity theft, or to access their accountsfor example, when users receive an email
apparently from their bank asking them to connect to a corporate Web site, and log in, a certain
percentage of people will do so. The malicious site then captures their login information.
Default accounts: Many applications have well-known demonstration or default accounts.
These accounts should have a method of being secured or deleted.
Back doors: A programmer builds in an undocumented method of bypassing authorization.
These should never be allowed to be coded. These can be prevented only by administrative
controls and code review.
Debug code: Often, debug code is included in the production code to help during development
and later to aid support. This code should have clearly documented methods to be enabled and
disabled. Debug code may give additional privileges or bypass authorizations.
Common Exploits
There are two methods of prevention.

The first is educating the end user to limit social engineering attacks such as phishing and crossscripting. Because of the imagination of the attackers, the attacks will always be changing. The
educators can publish warnings and counter measures only after the exploit is discovered.
The second method is a secure-coding practice, which implements verified methods to prevent
attacks. The methods to prevent these exploits are similar across the various exploit types. A few
methods to limit SQL injection attacks are presented here. For more detail, see the course titled
Oracle Database 11g: Advanced PL/SQL or the Tutorial on Defending Against SQL Injection
Attacks available at
http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm.
Standard Configuration Policies: Enforcing standard configurations policies by scanning is
another way to help prevent attacks. Some companies go as far as to have internal hackers
attempting to break into systems to test the security policies.
Common Exploits (continued)

Cross-scripting: This is a very common way of gaining information. A crafted URL or
script injected into a vulnerable Web page can result in elevated privileges, or access to
sensitive information, such as session identifiers, cookies, or login credentials. Often, a
cross-scripting attack is hidden in a seemingly innocent email or Web site that invites the
recipient to access a URL.
SQL injection: SQL injection makes use of security holes in applications to input and
execute crafted SQL statements.
Preventing attacks
Common exploits may be prevented or mitigated by:

Reducing the attack surface
Limiting privileges to avoid privilege escalation
Avoiding known vulnerable code constructs
Avoid dynamic SQL.

Avoid known weak protocols.
Always validate input.
Trap and handle exceptions.
Designing code that is immune to common exploits

Reviewing and testing code for common exploits
Preventing Exploits
The principles outlined in the slide can be applied to many types of attacks: SQL injection, crossscripting, and buffer overflow exploits. These methods are derived from the policies. Reducing the
attack surface and limiting privileges are applications of the principle of least privilege.
Applying the methods shown in the slide are covered in more detail in the case study at the end of
this lesson.
There are two white papers available on OTN that give more details about SQL and PL/SQL coding
practices: Doing SQL and SQL Best and Worst Practices at
www.oracle.com/technology/tech/pl_sql/pdf/doing_sqlfrom_plsql.pdf
and How to Write Injection-Proof PL/SQL at
www.oracle.com/technology/tech/pl_sql/pdf/how_to_write_injection_proof_plsql.pdf.
Preventing Exploits
Summary
Least privilege
Authorization
Authentication
Describe security policies

Describe the concept of in-depth security
Apply these concepts to prevent SQL injection
Summary
Security is not easy. Developing and implementing thorough security policies require management
support.
The types of attacks on a secure environment are constantly changing. To counter these risks,
sometimes you need to think like a hacker. Maintaining a secure environment often requires a certain
level of paranoia. The exploits and attacks are becoming more sophisticated. The average
administrator or security officer may not have the time or the background to keep up with new attack
vectors. The recommendations presented here are derived from the best industry practices. Applying
these recommendations may not prevent an attack, but they can help mitigate the damage, reduce the
access, and track the offender.
In this lesson, you should have learned how to:

Describe fundamental security requirements
Define the following terms:
Case Study:
Applying Security Practices
Case Study: Applying Security Practices

The following slides are a case study of how secure-coding practices can be used to reduce or
eliminate the possibility of SQL injection exploits. Your instructor will guide you through this
section. The basic methods used in reducing the possibility of SQL injection can be adapted and
applied to other common exploits. Specifics such as removing dynamic SQL would be changed to
not allowing certain characters in XML or HTML to prevent cross-scripting. But general techniques
such as peer review and testing are applicable across all type of exploits.
This case study covers applying security practices to a SQL

injection exploit.
SQL injection:
Tricks the SQL engine into executing unintended
commands
Exploits a common vulnerability in the application
Supplies crafted user-supplied strings, which are used in
dynamic SQL statements
Understanding SQL Injection

SQL injection is a technique for maliciously exploiting applications that use client-supplied data in
SQL statements. The flaw is common; a user-supplied input string is concatenated to a dynamic SQL
statement, and then executed.
Attackers trick the SQL engine into executing unintended commands by supplying specially crafted
string input. This input can allow the attacker to gain unauthorized access to a database to view or
manipulate restricted data.
SQL injection techniques may differ, but they all exploit a common vulnerability in the application.
That vulnerability is a user-supplied string literal interpreted as code by the SQL engine. These
literals may be input through forms, URLs, or hidden fields in Web pages. The vulnerability comes
whenever the input string is added to a dynamic SQL statement by the application code.
To immunize your code against SQL injection attacks, you must use bind arguments (either
automatically with static SQL, or explicitly with dynamic SQL), or validate and sanitize all input
concatenated to dynamic SQL.
Although a program or an application may be vulnerable to SQL injection, Web applications are at a
higher risk because an attacker can perpetrate SQL injection attacks without any database or
application authentication.
Understanding SQL Injection
Preventing SQL Injection
Use invokers rights.

Reduce arbitrary inputs.
Avoiding dynamic SQL with concatenated input

Use static SQL.
Use bind arguments.
Validate input.
Designing code that is immune to SQL injections

Testing code for SQL injection flaws
Preventing SQL Injection

Applying the principles outlined in the lesson to prevent and mitigate common exploits to SQL
injection attacks yields the list shown in the slide. Methods shown are covered in more detail in the
following slides.
SQL injection can be prevented by:

Reducing the attack surface
Reducing the Attack Surface
-- this example does not use Invoker's rights

CONNECT / as sysdba
CREATE OR REPLACE
PROCEDURE change_password(p_username VARCHAR2 DEFAULT NULL,
p_new_password VARCHAR2 DEFAULT NULL)
IS
Note the use of dynamic SQL with
v_sql_stmt VARCHAR2(500);
concatenated input values.
BEGIN
v_sql_stmt := 'ALTER USER '||p_username ||' IDENTIFIED BY '
|| p_new_password;
EXECUTE IMMEDIATE v_sql_stmt;
END change_password;
GRANT EXECUTE ON change_password to OE, HR, SH;
Reducing the Attack Surface

If you do not provide an interface to an attacker, clearly it is not available to be abused. Thus, the
first, and arguably the most important, line of your defense is to reduce the exposed interfaces to only
those that are absolutely required. You can reduce the exposed interfaces by:
Using invokers rights to reduce SQL injection vulnerability
Reducing arbitrary inputs
Using Invokers Rights
Stored program units and SQL methods execute with a set of privileges. By default, the privileges are
those of a schema owner, also known as the definer. Definers rights not only dictate the privileges,
they are also used to resolve object references. If a program unit does not need to be executed with
the escalated privileges of the definer, you should specify that the program unit executes with the
privileges of a caller, also known as the invoker.
1. The example shown in the slide uses definers rights. The CHANGE_PASSWORD procedure is
created under the SYS schema. It accepts two parameters and uses them in the ALTER USER
statement.
2. SYS grants OE, HR, and SH the ability to execute the CHANGE_PASSWORD procedure.
Result: Anyone that connects as SH, OE, or HR can change the password of any user, without
knowing that users password.
Using invokers rights helps to:

Limit the privileges
Minimize the security exposure
CONNECT /as sysdba

CREATE OR REPLACE
PROCEDURE change_password(p_username VARCHAR2 DEFAULT NULL,
p_new_password VARCHAR2 DEFAULT NULL)
AUTHID CURRENT_USER
IS
v_sql_stmt VARCHAR2(500);
BEGIN
v_sql_stmt := 'ALTER USER '||p_username ||' IDENTIFIED BY '
|| p_new_password;
EXECUTE IMMEDIATE v_sql_stmt;
END change_password;

To disallow another user from changing a password that does not belong to the user, redefine the
procedure with the invokers rights. This is done with the AUTHID CURRENT_USER option.
CONNECT oe
EXECUTE change_password ('SYS', 'mine')
ERROR at line 1:
ORA-01031: Insufficient privileges
ORA-06512: at "SYS.CHANGE_PASSWORD", at line 1
ORA-06512: at line 1
Now OE can no longer change the SYS (or any other account) password.
Note that the CHANGE_PASSWORD procedure contains dynamic SQL with concatenated input
values. This is a SQL injection vulnerability. Although using invokers rights does not guarantee the
elimination of SQL injection risks, it can help mitigate the exposure.
This is an extreme example, but shows clearly how a PL/SQL procedure that uses dynamic SQL and
definers rights can allow a user more privileges than intended.
Add the AUTHID CURRENT_USER clause.
Avoiding Dynamic SQL
Most common vulnerability:

Dynamic SQL with string concatenation
Your code design needs to:

Avoid input string concatenation in dynamic SQL
Use bind arguments, whether automatically via static SQL or
explicitly via dynamic SQL statements
Avoiding Dynamic SQL

Poor application design can lead to designed in vulnerabilities, where there are no apparent coding
problems and everything works as intended.
However, you must design your code such that it is (ideally) entirely free of SQL injection
vulnerabilities, or contains measures that mitigate the impact of a successful attack.
The common flaw of all code vulnerable to SQL injection is the construction of dynamic SQL by
using string concatenation. Complete immunity from SQL injection attack can be achieved only
through the elimination of input string concatenation in dynamic SQL.
Avoid input string concatenation.
Use bind arguments, whether automatically via static SQL or explicitly via dynamic SQL
statements. Bind arguments are immune to SQL injection.
Design your code to use bind arguments wherever possible. The only exceptions should be when you
need to concatenate identifiers or keywords because you have no other choice.
Validating Input to Dynamic SQL

All user input must be validated.
Use the DBMS_ASSERT package to validate.
Use in-house developed filters.
Validating Input to Dynamic SQL

To guard against SQL injection in applications that do not use bind arguments with dynamic SQL,
you must filter and sanitize concatenated strings. The primary use case for dynamic SQL with string
concatenation is when an Oracle identifier (such as a table name) is unknown at code compilation
time.
DBMS_ASSERT is an Oracle-supplied PL/SQL package containing functions that can be used to
filter and sanitize input strings, particularly those that are meant to be used as Oracle identifiers.
If other input filters are used, there are a number of issues to consider. An incorrectly constructed
filter can allow injection and limit valid input. For more details, see Tutorial on Defending Against
SQL Injection Attacks! available at
http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm.
Before deploying your filters, each filter must be reviewed and tested.
Coding Review and Testing Strategy
Test:
Review:
Peer and self-reviews
Analysis tools
Coding Review and Testing Strategy

You can use a number of strategies to test SQL injection vulnerability. Using a combination of these
strategies should be regarded as a sensible minimum to get some degree of confidence in freedom
from vulnerabilities.
Effective testing of complex products is essentially a process of investigation, and not merely a
matter of creating and following routine procedure. Code reviews or walk-throughs are referred to as
static testing, whereas actually running the program with a given set of test cases in a given
development stage is often referred to as dynamic testing.
Testing for SQL injection flaws requires both static and dynamic testing. For static testing, you can
begin with a peer (or self) code review or make use of a static code analysis tool, or both. After
finding and fixing the semantical SQL injection bugs, you must perform dynamic testing by using
tools that generate random input (fuzzing), and also run through test cases that you define
specifically for SQL injection detection within your code.
Dynamic testing
Static testing
Mitigating the Scope of Exploits
Mitigating the Scope of Exploits

Although it is impossible to predict all the types of exploits that may be used to attack an application,
the scope of the damage that these attacks can cause can be reduced by following secure coding
practices.
If an attack is successful, reduce the scope by:

Avoiding privilege escalation
Trapping and handling exceptions
Give out privileges appropriately.

Run code with invokers rights when possible.
Ensure that the database privilege model is upheld when
using definers rights.
Invokers rights
Definers rights
Avoiding Privilege Escalation

Unless carefully designed, routines may effectively grant users more privileges than intended.
Wherever possible, run code with invokers rights to minimize the scope for privilege escalation
attacks and to mitigate the impact of a successful SQL injection attack.
Where this is not possible, the routines that are run with definers rights should be carefully reviewed
to ensure that the database privilege model is upheld.
If none of the methods of execution (definers rights, invokers rights) appears suitable, consider
implementing specific bypass checks for the duration of the call.
Avoiding Privilege Escalation
Trapping and Handling Exceptions
Design your code to trap and handle exceptions

appropriately.
Before deploying your application, remove all:
Code tracing
Debug messages
Trapping and Handling Exceptions

Normal SQL injection attacks depend, in large measure, on the ability of an attacker to reverseengineer portions of the original SQL query by using information gained from error messages.
Therefore, keep application error messages succinct and do not divulge metadata information (such
as column names and table names).
Be aware that trace files, audit logs, and alert logs can contain metadata information. Protect these
files by setting the directory permissions to prevent anyone but the instance owner from reading
these files. Sometimes, these permissions must be relaxed to allow others access for debugging and
performance tuning. Be sure to limit the users carefully and return to original permissions when the
need is past.
Note: From Oracle Database 10.2 and onward, you can use PL/SQL conditional compilation for
managing self-tracing code, asserts, and so on. For more information about conditional compilation,
see the Oracle Database PL/SQL Language Reference.

After completing this lesson, you should be able to describe the

following recommended solutions to common security
concerns:
Maintaining data integrity
Protecting data
Controlling data access
Objectives
Financial regulators require assurance of integrity of the data

that is used to produce financial reports. Oracle Database 11g
can provide the following:
Standard database auditing
Fine-grained auditing
Privileged-account auditing
Network encryption
Separation of duties
Secure audit logs
Encryption of data
Assuring Data Integrity

Compliance is the term used to describe the actions required by the Sarbanes-Oxley (SOX)
regulation in the U.S. and other industry regulations to assure the integrity of data that is used to
produce financial reports. For compliance, you must track who accessed the data, when it was
accessed, and how it was changed. In addition to triggers and integrity constraints, Oracle
Database 11g can provide the following:
Standard database auditing: Can show the time of access, the users who attempted to
access or accessed a database object, or the privilege that was used. With extended
auditing, the SQL statement and bind values can be captured.
Fine-grained auditing (FGA): Is focused on the access of specific columns and rows.
With extended auditing, the SQL statements that were issued and the bind variables are
also captured. FGA when used in combination with flashback may show the data that was
viewed.
Privileged-account auditing: Can track every statement that is issued by a user who is
connected as SYSDBA
Network encryption: Prevents the possibility that data was viewed or changed in transit.
Network encryption can be provided by Oracle Advanced Security (ASO).
Separation of duties: Can be enforced with multiple administrators: one to create users,
another to manage the application data definition language (DDL), and a third to maintain
database-wide
suchINasTHIS
backups.
This isONLY.
enforced
by Oracle
Vault.
THESE eKIT MATERIALS
ARE operations,
FOR YOUR USE
CLASSROOM
COPYING
eKIT Database
MATERIALS
FROM THIS
Assuring Data Integrity
Assuring Data Integrity (continued)

Secure Audit Logs: Can be sent to system-level files owned by another OS user, sent to
another machine, or sent to another database. Sending audit records to the syslog file is a
feature that provides some of these services. Oracle Audit Vault is designed to provide
these services and a warehouse to monitor and analyze audit records.
Encryption of Data: Is used to protect sensitive data in database files. The sensitive data
can be encrypted at the column or tablespace level. Transparent Data Encryption (TDE) is
designed to protect data in database files and backups from privileged operating system
users such as root.
Personally identifiable information (PII) and other sensitive data

must be protected. Use the following techniques:
Restrict access.
Encrypt stored data.
Encrypt network traffic.
Restrict network access.
Monitor activity.
Harden every layer.
Mask data that is not used for production.
Data Protection
California Security Breach LawsCA-SB-1386 and CA-AB-1950require that personally
identifiable information (PII) be protected. The Payment Card Industry Data Security Standard
(PCI-DSS) requires that credit card information be protected at several levels. Reasonable care
dictates that businesses must protect private information to avoid liability.
Restrict access: This is the first step. Use database hardening and access control to limit
the access to authorized persons.
Encrypt stored data: This step assumes that the OS can be compromised. Encrypting the
stored data protects data files from being scanned by OS utilities. Encrypting the data also
assures the protection of backups.
Encrypt network traffic: The data must be protected while in transit. For Oracle Net
traffic, end-to-end encryption is provided with Oracle Advanced Security.
Restrict network access: Restrict network access to authorized individuals. Departmental
or data center firewalls are another layer of protection.
Monitor activity: Monitor activity with intrusion detection tools and auditing tools.
Unusual activity on the network or database at odd times can signal an attack or illegal
access.
Data Protection
Data Protection (continued)

Harden every layer: Practice defense in depth. Do not neglect the OS, database, or
network.
Mask data not used for production: Data is often sent offsite or cloned into a
nonproduction instance for a number of reasons: testing, development, or QA. Sensitive
data must still be protected, or changed to be unrecognizable. Data masking provides the
ability to replace sensitive data with correct format, but fictitious data.
Authentication and Authorization
Authentication verifies the users identity.
Authorization determines the users privileges.

Privileges
Roles
Identity can be propagated in a three-tier environment.

Pass through
Proxy user
Secure application role (enabled only by an authorized
PL/SQL package or procedure)
Enterprise User Security
Authentication and Authorization

Authentication verifies who the end user is and authorization determines the users privileges.
Centralized identity management such as Enterprise User Security reduces the time and effort
required to manage users over multiple databases and applications. Strong authentication allows
the use of Smart Cards, biometrics, Kerberos tokens, or certificates to be assured that the end
user is correctly identified.
In Oracle Database, system and object privileges are granted to the end user either directly or
through roles. These privileges give the user permission to execute certain commands or
access certain database objects. These objects may include tables, views, or synonyms that
contain data.
Identity is determined by authentication, and privileges, by authorization. This identity can be
propagated in the three-tier environment by various methods with supported techniques instead
of having to either trust the middle tier or reauthenticate at each server.
Many applications handle the authentication and authorization for application users. This is
usually expensive and less secure than other solutions. The expense comes with coding the
security into each application, and the application developer may not have the experience to
code, test, and maintain the security module. Auditing can be a problem in the environment
where the user is not known to the database.
Centralized identity management

Strong authentication
Authentication and Authorization (continued)

Some of the solutions to these problems are:
Pass through: The user provides the database login credentials. The application server
passes the credentials to the database. The database server performs the authentication and
authorization.
Proxy User: The user has a database account, and the application is granted the privilege
to connect on behalf of the user. The connection can be either with or without a user
password and may include the privilege to enable some or all of the roles granted to the
user.
Secure Application Role: The application connects as a low-privileged user, and then
may enable roles only through a secure package. In this case, the end user may not be
known to the database, and the application is responsible for authorizing the user and
enabling the required roles.
Enterprise User Security (EUS): The end user may be a schema-independent user,
unknown to the database, but authenticated in Oracle Internet Directory (OID). The end
user identity is supplied by OID to the database session and is available for audit.
Solutions involving single sign-on or single point of

authentication reduce administration costs and can
improve security.
Solutions include:
Oracle Identity Management

Enterprise User Security (EUS)
Integration with Active Directory
Integration with Kerberos
Integration with Entrust PKI
Networkwide Authentication
For secure systems, users must have strong passwords (longer than n characters, with digits and
special characters). When users have multiple accounts, this requirement is often met with
resistance and increases help-desk costs for password resets. If a user needs only one strong
enterprisewide password, the resistance and costs diminish. There are several solutions:
Oracle Identity Management provides single sign-on that is integrated with the Oracle
Applications server. Oracle Identity Management can provide self-service password resets
and account provisioning (creation). It can be integrated with the existing Lightweight
Directory Access Protocol (LDAP) v3 directories.
Enterprise User Security provides a single point of authentication. EUS can be
configured to use passwords, certificates, or Kerberos v5 tickets. It gives administrators a
centralized repository for user account information.
Integration with Active Directory from Microsoft can be used for networkwide
authentication. Oracle Database may be configured to use Active Directory as an
authentication source.
Integration with Kerberos can be used for networkwide authentication. Oracle Database
may be configured to use Kerberos as an authentication source.
Integration with Entrust PKI provides the ability to use a central sign system with
certificates.
Networkwide Authentication
Access Control and Monitoring

Access control includes:
Discretionary access control

Implementing Virtual Private Database (VPD)
Using Oracle Label Security (OLS)
Using Oracle Database Vault
Monitoring includes:
Applying auditing
Using Oracle Audit Vault
Access Control and Monitoring

Oracle Database provides several ways to control access.
Discretionary access control is a feature of every Oracle Database that is controlling access at
the object level.
Virtual Private Database is a custom row-level access control that you can build from the finegrained access control feature and secure application context.
Oracle Label Security is an option that provides multilevel row-level security, so that users and
data can be given classification and clearance levels to determine data access.
Oracle Database Vault provides separation of duties, and restricts users to declared realms that
contain data objects. Even users with powerful system privileges do not get to see data that is
protected by a realm unless it is specifically granted.
When privileges are assigned, a certain level of trust is also given. Auditing protects trustworthy
individuals and verifies that the trust is not being abused.
Audit Vault provides a secure location to collect, store, and review audit records.
Which of the following are used to implement authentication?

a. Enterprise User Security
b. Oracle Database system privileges
c. Oracle Identity Management
Answer: a, c
Quiz
Oracle Database Vault

Protection
realms
Separation
of duty
Command
rules
Existing Oracle
database

Oracle Database Vault is a database option that enables you to set a variety of access controls to
implement dynamic and flexible security requirements. Oracle Database Vault:
Provides controls on privileged users to protect application data from access by a database
administrator (DBA) and any other privileged user
Enforces protection of database structures from unauthorized change
Enforces separation of duties
Allows real-time access control based on a variety of factors, including user-defined
parameters
Because Oracle 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 Oracle Database Vault to manage the security for an individual Oracle database.
You can use Oracle Database Vault on stand-alone Oracle Database installations, and in Oracle
Real Application Clusters (RAC) environments.
Oracle Database Vault is part of the database kernel, and thus is more secure than a security
solution implemented in custom PL/SQL packages.
For more details, attend the Oracle Database 11g: Implement Database Vault course.
Realm violation
reports
Multifactor
authorization
Oracle Audit Vault

Monitor
Security
Reports
Oracle Database 9iR2,

Oracle Database 10g,
Oracle Database 11g
Microsoft SQL Server 2000 & 2005
Oracle Audit Vault

Oracle Audit Vault provides the ability to consolidate audit data and critical events from various
sources such as database management systems, application servers, applications, and operating
systems into a centralized, secure, and scalable audit warehouse.
Oracle Audit Vault provides the ability to collect audit data generated by Oracle9i Database
Release 2, and later releases of Oracle Database.
Audit Vault services include the following:
Management and monitoring of audit collectors
Centralized reporting, analysis, and alerts based on data collected and stored in the data
warehouse
Reporting based on Oracle Application Express, and focused on business-specific areas
A data warehouse of audit information protected by Oracle Database Vault
Archival of audit data
Policies (audit settings) that define what activity is audited and what type of activity raises
alerts. Policies (audit settings) can be provisioned to the various systems within the
enterprise. This provides the ability to efficiently create and apply audit settings for
compliance and security requirements.
Policies
Combining Optional Security Features
Object-level
access control
(Oracle Database Vault)
Data Masking
Row-level security
(OLS or VPD)
Column
encryption
Secure (TDE)
Backup file encryption

(RMAN and OSB)
audit logs
(Oracle Audit Vault)
Combining Optional Security Features

Oracle provides security features at several levels of the software and product stack. Not all
users will need all features or options. No one feature or option will provide everything that
every user may require. By combining features and options, users can build a complete security
solution for their environment. In the slide, several security options have been combined to
provide a secure solution that is more complete.
Encrypted Communication: Oracle Advanced Security provides the ability to encrypt all
communication between any two Oracle base components (client, application server, or
database server).
Data Encryption: Transparent Data Encryption (TDE) provides column or tablespace
encryption. TDE does not require any changes to the application. Oracle Advanced
Security is required for TDE. When TDE column encryption and network encryption are
combined, sensitive data is encrypted on disk and in transit. The sensitive data is decrypted
in the session private memory and when received by the client application or user.
Encrypted communication
Oracle Advanced Security
Combining Optional Security Features (continued)

Object-Level Access Control: Oracle Database Vault allows the principle of least
privilege to be applied to all users, including the DBA. Database Vault gives the ability to
partition administration among several users by enforcing fine-grained control of powerful
system privileges such as the ANY system privileges, and of specific DDL and database
control commands such as ALTER SYSTEM and CREATE USER. Database Vault allows
privileges to be linked to multiple factors, such as allowing greater privileges when
connected over a local network versus when connected over a Virtual Private Network.
Even the CONNECT operation can be limited based on factors.
Row-Level Access Control: Some applications will require that only certain users access
certain rows. This requires the use of the Virtual Private Database (VPD) technology. VPD
allows developers to create their own row-level security policies. Oracle Label Security is
built on the same technology as VPD, but provides an implementation without requiring
coding.
Encrypted Backup Files: A lost or stolen backup can have disastrous consequences.
Recovery Manager (RMAN) or Oracle Secure Backup (OSB) can encrypt backup files to
tape, preventing them from being useful to anyone besides authorized users.
Secure Audit Logs: If the audit logs are not secure, insiders with certain privileges can
make changes to the database and remove the audit records of those changes. Without
secure audit logs, certifying compliance is difficult. Oracle Audit Vault provides a data
warehouse type facility built on Database Vault to securely capture, store, and report on
audit records. These audit records can originate anywhere: the OS, another database, and
even non-Oracle databases.
Data Masking: Sensitive data must be protected wherever it resides. Oracle users report
that the use of a clone of production data is common for development, testing, and QA
instance. It is also common that these activities are performed by third parties. Oracle users
also report that very seldom is the sensitive data protected in these database copies. Data
Masking will convert the sensitive data into a form that is correct in format but not
personally identifiable, with nonreversible functions.
Compliance Scanner
A compliance scanner is available through the Enterprise
Manager Security Advisor and the Policy Manager.
Compliance Scanner
Auditors need to have a consistent set of standards that are used to determine whether a system
is compliant. Administrators want to know the standards, to be prepared for audits and have
some assurance that most security issues are being addressed.
Oracle Enterprise Manager supplies the Security Advisor and Policies. You can access these
pages through Enterprise Manager Database Control, as shown in the slide, or through
Enterprise Manager Grid Control. Rules for the policies are set in the Policy Library. You can
enable or disable these rules as appropriate for your site.
User-defined policies may be created and managed using the
MGMT_USER_DEFINED_POLICY package. These policies can be applied to exiting targets.
For more details, see Oracle Enterprise Manager Extensibility.
For more information about policies, see the Oracle Enterprise Manager Policy Reference
Manual.
Enterprise Manger Database Control
Enterprise Manager Database Control: Policy Trend

The Policy Trend Overview page in Enterprise Manager Database Control displays a summary
of policy violations that have occurred over a specified time period on a single database. To
navigate to this page from the database home page, click the compliance score link shown on the
previous page.
The Security at a Glance page in Enterprise Manager Grid Control is similar, but allows you
to see, in one place, the policy violations over a group of targets. This view can be customized to
list the data from one target or a set of targets being monitored. Targets may be grouped and the
statistics displayed as a group.
Enterprise Manager Database Control: Policy

Trend
Security at a Glance: Details

The Details section of the Security at a Glance page gives more information about the severity
and number of rules violated. This section includes a detail of violations per target. Similar
information is displayed on the database home page on Enterprise Manager Database Control.
If access to My Oracle Support for patching has been configured, critical patch updates that are
available will be displayed.
Security at a Glance: Details
Enterprise Manager Grid Control Security Advisor

Both Enterprise Manager Database Control and Enterprise Manager Grid Control access the
Security Advisor pages through drilldown from the Policy Violations link. Enterprise Manager
Grid Control provides more detail. The compliance scanner and Policy Library are available
through the Database Configuration Management Pack.
Enterprise Manager Grid Control Security Advisor
Policy Library
Both Enterprise Manager Grid Control and Database Control have a library of policies. Because
Grid Control can monitor more types of targets, the Policy Library is more extensive. Each
policy in the library has a description and can be enabled or disabled. In Grid Control, the
policies may be applied to particular targets. When the policies are violated, a violation is
generated as seen on the Violations page and the Security at a Glance page.
Policy Library
In this lesson, you should have learned how to describe the

following recommended solutions to common problems:
Maintaining data integrity
Protecting data
Controlling data access
Summary
This practice covers the following topics:

Installing the Oracle Management Agent
Configuring monitoring credentials for your database
Choosing a security solution
Practice 2 Overview:
Hardening Database Access

following:
Apply the principle of least privilege to the database
Lock and expire default user accounts
Change default user passwords
Create strong passwords
Enforce password management
Protect the data dictionary
Objectives
More Information
This lesson also explains how to configure Oracle Database 11g in a secure manner by adhering to
industry standard best security practices for operational database deployments. Details about
specific database-related tasks and actions can be found in the following:
Other lessons in this course
Other courses, including the following:
- Oracle Database 11g: Administration Workshop I
- Oracle Database 11g: Administration Workshop II
- Oracle Application Server 10g R2: Administration I
- Oracle Application Server 10g R2: Administration II
Oracle Database 11g documentation set
For a detailed explanation of the topics covered in this lesson, refer to the Oracle Database Security
Guide.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-2
Objectives
Database Security: Checklist
Harden the operating system (OS).

Install only what is required.
Apply security patches.
Manage default user accounts.
Enforce password management.
Protect the data dictionary.
Restrict the directories accessible by the user.
Limit users with administrative privileges.
Restrict remote database authentication.

Use available database security features.
Database Security: Checklist

The Oracle Database server leads the industry in security. However, to fully maximize the security
features that are offered, it is imperative that the database itself is well protected.
Furthermore, proper use of the security features and adherence to basic security practices help protect
against database-related threats and attacks, and provide a more secure operating environment for the
database.
Practicing the Principle of Least Privilege
The principle of least privilege means that a user must be given only those privileges that are
required to efficiently complete a task. This reduces the risk of a user, either accidentally or
maliciously, modifying the data that he or she does not have the privilege to modify.
Hardening the OS
Follow best practices of your operating system. For example, protect sensitive files with proper file
permissions. Give the OS user only the privileges and permissions needed to do his or her job.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-3
Apply the principle of least privilege:
Reducing Administration Effort
Reducing Administration Effort

Easing Administration of Database Security
Group users with the same security requirements into roles. Normally, roles are organized around the
job function of the employee. These roles are independent of the user. Therefore, if another user
needs the same privileges, he or she can be assigned those privileges in a role. If a user is dropped,
any directly granted privileges are also dropped. Assigning privileges through roles allows the role
definition to exist without being assigned to a user.
As users change jobs, roles can be enabled or disabled for each user. When the job responsibilities
change or the process changes, different privileges may be required. Then privileges can be added to
or removed from a role.
In sites with large numbers of users or a large number of systems, a significant effort is required just
to keep user accounts current on each system so that users can continue to work. Often,
administrators do not have the time or the information required to purge accounts of users who no
longer have a need for access or users who are no longer authorized. Assume a system with hundreds
of users, each with accounts on many systems. When a user is removed, the administrator may not
know all the accounts that need to be locked. A central authentication system, which manages the
users credentials and authorizations, reduces the effort required to manage (create, update, and
purge) accounts.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-4
Use roles to group users by job function.

Enable and disable roles as appropriate.
Use single sign-on.
Installing Only What Is Required
Determine what needs to be installed.

Determine if a custom installation is required.
You can install additional products later.
Installing Only What Is Required

The Oracle Database software contains many products in addition to the database server. Install
additional products and options only as necessary. There is no need to maintain the additional
products and options if they are not being used. They can always be properly and easily installed as
required.
By reducing the number of products installed, you can reduce the possibility of patches being
required and also the possibility of software conflicts. And, typically, you can reduce the cost of
licenses and maintenance. These principles apply to all software products.
Note: The Oracle inventory directory keeps a record of installed software, and patches are applied
only to the installed software. In many cases, if a new product or option is installed from the
prepatched base distribution, the patches must be reapplied.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-5
Install only the required products and features.

Plan your installation:

Critical Patch Update (CPU) Process
Oracle Corporation uses a CPU process that bundles together critical patches on a quarterly basis.
These patches are cumulative and include commonly requested and required prerequisite patches.
The quarterly patch release comes with a risk assessment matrix to enable you to determine for your
site the impact and security risks. See My Oracle Support note 360470.1, Security Alerts and
Critical Patch Updates- Frequently Asked Questions. You must subscribe to My Oracle Support to
receive these updates.
Applying All Security Patches and Workarounds
Always apply all relevant and current security patches for both the operating system on which the
database resides and the Oracle software, and for all installed options and components.
Referring to the Oracle Security Products Web Site
If you find a security vulnerability in the Oracle software, follow the instructions provided on the
Security Alerts page at http://www.oracle.com/technology/deploy/security/alerts.htm.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-6
Use the Critical Patch Update process.

Apply all security patches and workarounds.
See the Oracle Security Products Web site.
Secure Password Support
Are case-sensitive
May contain more different characters
Use more secure hash algorithm
Use salt in the hash algorithm
Usernames are still Oracle identifiers (up to 30 characters,

non-case-sensitive).
Secure Password Support

You must use more secure passwords to meet the demands of compliance to various security and
privacy regulations. Passwords that are very short and formed from a limited set of characters are
susceptible to brute force attacks. Longer passwords with more different characters allowed make the
password much more difficult to guess or find. In Oracle Database 11g, the password is handled
differently than in previous versions:
Passwords are case-sensitive. Uppercase and lowercase characters are now different characters
when used in a password.
Passwords may contain multibyte characters without quoting. Of the special characters, only
$, _, and # are allowed in the password without quoting the password.
Passwords are always passed through a hash algorithm, and then stored as a user credential.
When the user presents a password, it is hashed, and then compared to the stored credential. In
Oracle Database 11g, the hash algorithm is SHA-1 instead of the algorithm used in the previous
versions of the database. SHA-1 is a stronger algorithm that uses a 160-bit key.
Passwords always use salt. A hash function always produces the same output, given the same
input. Salt is a unique (random) value that is added to the input to ensure that the output
credential is unique.
Note: Usernames and passwords are limited to 30 bytes.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-7
Oracle Database 11g supports passwords that are more

secure.
Passwords:
Automatic Secure Configuration
Automatic Secure Configuration

Oracle Database 11g installs and creates the database with certain security features recommended by
the Centre for Internet Security (CIS) benchmark. The CIS-recommended configuration is more
secure than the default installation of Oracle Database 10g, Release 2; yet open enough to allow the
majority of applications to be successful. Many customers have adopted this benchmark already.
There are some recommendations of the CIS benchmark that may be incompatible with some
applications.
The secure configuration of Oracle Database 11g provides the following primary features:
Default password profile: A password profile includes a default limit on the number of failed
login attempts.
Built-in password complexity checking: A password complexity checker is provided, and can
be enabled in any profile.
Default auditing: Several privileges that are important to the security of the database are
audited by default. The full list is provided in the lesson titled Auditing Database Users,
Privileges, and Objects.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-8
Default password profile

Built-in password complexity checking
Default auditing of certain privileges
Password Configuration
By default:
In upgrade:
Passwords are non-case-sensitive until changed.
Passwords become case-sensitive by ALTER USER.
On creation:
Passwords are case-sensitive.
Password Configuration
When creating a custom database by using the Database Configuration Assistant (DBCA), you can
specify the Oracle Database 11g default security configuration. By default, if a user tries to connect
to an Oracle instance multiple times using an incorrect password, logins are delayed after the third
try. This protection applies for attempts made from different IP addresses or multiple client
connections. Afterwards, it gradually increases the time elapsed before the user can try another
password, up to a maximum of about 10 seconds.
The default password profile is enabled with the following settings at database creation:
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION NULL
When an Oracle Database is upgraded to 11g, passwords are non-case-sensitive until the ALTER
USER command is used to change the password.
When the database is created, the passwords will be case-sensitive by default.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
3-9
Default password profile is enabled.

Account is locked after 10 failed login attempts.
SYS and SYSTEM Accounts

The SYS account:
Is required for startup, shutdown, and some maintenance

commands
Owns the data dictionary
The SYSTEM account is granted the DBA role.

These accounts are not for normal use.
SYS and SYSTEM Accounts

The SYS and SYSTEM accounts have the DBA role granted to them by default.
The SYS account, in addition, has all privileges with ADMIN OPTION and owns the data dictionary.
To connect to the SYS account, you must use the AS SYSDBA clause. Any user who is granted the
SYSDBA privilege can connect to the SYS account by using the AS SYSDBA clause.
Only users who are granted the SYSDBA or SYSOPER privilege are allowed to start up and shut
down the database instance.
The SYSTEM account is granted the DBA role by default, but not the SYSDBA privilege.
Applying the principle of least privilege, these accounts are not used for routine operations. Users
who need the DBA privileges have separate accounts with the required privileges granted to them.
For example, Jim has a low privileged account called JIM and a privileged account called
JIM_DBA. This method enables the principle of least privilege to be applied, eliminates the need for
account sharing, and enables individual actions to be audited.
The SYS and SYSTEM accounts are required accounts in the database. They cannot be dropped.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 10
Is granted the DBA role

Has all privileges with ADMIN OPTION
SYSDBA, SYSOPER, and SYSASM
Database instance
Connect as SYSDBA
SYS
PUBLIC
Operator
Connect as SYSOPER
Connect as SYSASM
SYS
DBA
ASM instance
SYSDBA, SYSOPER, and SYSASM

SYSDBA: SYSDBA is a special database administration privilege that contains every system
privilege with the ADMIN OPTION and SYSOPER system privileges. SYSDBA also permits the
CREATE DATABASE actions and incomplete recovery. When you connect with the SYSDBA
privileges, you are in the schema owned by SYS.
SYSOPER: SYSOPER is a special database administration privilege that permits a database
administrator to use the STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER
DATABASE BACKUP, ARCHIVE LOG, and RECOVER commands. This privilege includes the
RESTRICTED SESSION privileges. SYSOPER does not have the ability to look at data. When
you connect as SYSOPER, you are in the PUBLIC schema with only those privileges that are
granted to the PUBLIC user.
If users are granted the SYSDBA or SYSOPER role, they can connect using their normal account
names with the AS SYSDBA clause. For example, Julie connects with the username JSMITH;
but when she needs to shut down the database, she connects with JSMITH AS SYSDBA.
SYSASM: With Oracle Database 11g, the SYSASM privilege enables the separation of the
database operating system credentials from the ASM credentials. Use the SYSASM privilege
instead of the SYSDBA privilege to connect to and administer an ASM instance. If you use the
SYSDBA privilege to connect to an ASM instance, Oracle writes warnings to the alert log file
because commands that you run using the SYSDBA privilege on an ASM instance will
eventually be deprecated.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 11
DBA
Allowing Remote Database Administration
Create a password file

Add user with GRANT SYSDBA TO <user>
Connect sys/<pw>@service AS SYSDBA
$ orapwd file=$ORACLE_HOME/dbs/orapwp0orcl entries=5
Enter password for SYS:<password>
$ sqlplus sys/<password>@p0orcl AS SYSDBA
View the privileged accounts.

SQL> SELECT * FROM v$pwfile_users;
Allowing Remote Database Administration

When you request to start up or shut down the database using Enterprise Manager Grid Control, a
host connection is made to the database server target machine as an OS user through the agent
running on the target machine, so it is a local connection and the password file is not needed.
Enterprise Manager Database Control always connects through the listener, so any AS SYSDBA
connection must use the password file.
To shut down or start up a database remotely, with a utility such as SQL*Plus, the database must be
configured to allow remote connections by privileged users. REMOTE_LOGIN_PASSWORDFILE
must be set to EXCLUSIVE. The password file must be created with the orapwd utility, and the
users must be added to the file.
List the users who have been added to the password file by selecting from the V$PWFILE_USERS
view. Any user that has been granted SYSDBA, SYSOPER, or SYSASM will be listed; SYS is always
listed. The password file is created on a per-instance basis; so in a RAC instance, the
GV$PWFILE_USERS view may show different users for each instance ID.
The password for the SYS user is set with the orapwd utility; all other users that are granted the
SYSDBA, SYSOPER, or SYSASM privilege have the same password that is set for their database
account.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 12
To start up and shut down from a remote node:

Set REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
The Database Configuration Assistant (DBCA) expires and

locks all accounts, except:
SYS
SYSTEM
SYSMAN
DBSNMP
MGMT_VIEW
For a manual database creation, lock and
expire accounts by using:
ALTER USER hr PASSWORD EXPIRE ACCOUNT LOCK;
Locking and Expiring Default User Accounts

Oracle Database installs a number of default, preset database server user accounts. During the
successful installation of the database server, the DBCA tool automatically locks and expires all
default database user accounts, except the following:
SYS
SYSTEM
SYSMAN
DBSNMP
MGMT_VIEW
The MGMT_VIEW account, which is used for Oracle Enterprise Manager Database Control, has been
granted the MGMT_USER role with only select privileges on some SYSMAN views.
Refer to My Oracle Support for notes about changing the passwords for the default user accounts
under special circumstances.
Manual Database Creation
If you create the database manually (that is, without using DBCA), none of the default database users
are locked on the successful creation of the database. If left open in their default states, these user
accounts may be exploited to gain unauthorized access to data or to disrupt database operations.
After creating a database without using DBCA, lock and expire all default database user accounts
except those in the preceding list. Use the appropriate SQL statements to perform such operations.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 13
Locking and Expiring Default

User Accounts
Locking and Expiring Default User Accounts (continued)

Locking and Expiring an Account
Use the ALTER USER command to lock and expire an existing account. In the following example,
the HR account is locked and expired:
SQL> ALTER USER hr
2 PASSWORD EXPIRE ACCOUNT LOCK;
If any default database server user account is required for any reason, you can simply unlock and
activate that account with a new password.
Installed Users
To get a complete list of installed accounts, issue the following SELECT statement:
SQL> COL account_status FORMAT A20
SQL> SELECT username, account_status FROM dba_users;
USERNAME
-----------------------------MGMT_VIEW
SYS
SYSTEM
DBSNMP
SYSMAN
SCOTT
ANONYMOUS
XDB
ORDPLUGINS
ACCOUNT_STATUS
-------------------OPEN
OPEN
OPEN
OPEN
OPEN
OPEN
USERNAME
-----------------------------SI_INFORMTN_SCHEMA
OLAPSYS
TSMSYS
MDDATA
DIP
ACCOUNT_STATUS
--------------------EXPIRED & LOCKED
EXPIRED & LOCKED
EXPIRED & LOCKED
EXPIRED & LOCKED
EXPIRED & LOCKED
EXPIRED & LOCKED

EXPIRED & LOCKED
EXPIRED & LOCKED
27 rows selected.
The exact accounts that are returned depend on the installation type and the version of the Oracle
software.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 14
User altered.
Default accounts provide easy access to the database.

Change the password on any account that has not been
locked.
As an example, change the password of the SH account to
s9049gbnij:
SQL> connect /as sysdba
SQL> PASSWORD sh
Changing password for sh
New password:*******
Retype new password:*******
Password changed
SQL>
Changing Default Account Passwords

The most trivial method by which the database can be compromised is by connecting to a default
user account that still has a default password. Several exploits require access only to a low-privilege
account.
Changing Default Passwords of Administrative Users
Change the default passwords associated with the SYS and SYSTEM users immediately upon
installation and initial configuration of the database server. The DBCA and Oracle Universal Installer
(OUI) tools force you to change the SYS, SYSTEM, SYSMAN, and DBSNMP passwords when creating
new databases.
Unlocking Accounts
The other default accounts are created with a default password that is exactly the same as the
username. For example, the MDSYS user is created with the MDSYS password. If any of the other
default user accounts that were locked and expired upon installation need to be activated, assign a
new password to that user account.
Patching Locked Default Accounts
If the patch process changes the schema objects of an account that is locked, you may be required to
unlock the account for the patch to succeed.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 15
Changing Default Account Passwords
Oracle Corporation recommends that the database instance be managed through Enterprise
Manager Database Control or Enterprise Manager Grid Control.
For many sites, it is a common requirement to change passwords periodically. Changing the
DBSNMP password is a special case because it is used by the agent to monitor the database. Refer
to My Oracle Support note 259387.1, How to change the password of the 10g database user
dbsnmp. This note also applies to Oracle Database 11g.
Changing the MGMT_VIEW Password
The MGMT_VIEW password should not be changed. Changing the password will have a serious
effect on many pages displayed by Oracle Enterprise Manager Database Control and Enterprise
Manager Grid Control. The password is a long, random string, generated from a combination of
the user-provided SYSMAN password and the random output from
java.security.SecureRandom hashed together. The MGMT_VIEW account has only read
access to the tables that contain management data such as the percent CPU usage over time for
servers in the data center.
The MGMT_VIEW user is assigned to the DEFAULT profile. Any changes to the DEFAULT
profile that forces password expiration and changes could cause this account to become
unusable.
Best Practice Tip: Create a profile specifically for the MGMT_VIEW account, in which the
password never expires.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 16
Changing Default Account Passwords (continued)

Changing the Password Securely
It is important that passwords not be entered on the command line because they show up in logs,
shell history files, and in the process listing on UNIX.
It is just as important not to change a password with the ALTER USER command because if you
are not running an encrypted shell or Oracle native encryption, it passes over the network in clear
text and can easily be intercepted by a network sniffing program. The SQL*Plus PASSWORD
command does not echo the password and encrypts the password before transmitting it over the
network.
Even if you are only performing a quick action such as unlocking an account for patching, do not
use a standard or weak password. Attackers will know patching windows due to announced
outages, and it only takes a small window of time for an attacker to run a script that will loosen
security settings or create a backdoor that he or she can use later to escalate his privileges.
Always use a secure connection and always use strong passwords.
Changing the DBSNMP Password
Enforcing Password Management

Use a password verification function to enforce constraints
on the users new password.
Use Oracle Advanced Security for strong authentication.
Enable password complexity checking.
Enforcing Password Management

Apply the basic password management rules provided by the database, such as password length,
history, and complexity, to all user passwords. Ensure that all users must change their passwords
periodically. The password management rules may be applied in the database to manage the database
user, or in Oracle Internet Directory to enforce the same rules on enterprise users.
Strong Authentication
Use Oracle Advanced Security with network authentication services, token cards, smart cards, or
X.509 certificates. These services enable strong authentication of users to provide better protection
against unauthorized access to the database.
Strong Passwords
A strong password is a password that is not easily guessed or cracked. It is:
Not a dictionary word, jargon, or an easily guessed name (for example, a fictional character)
Not related to the username, as in Social Security Number, birth date, or address
Not a simple substitution of one of the above with numbers for letters (for example,
3 for E)
A strong password has seven or more characters with at least one digit and one special character.
This, combined with the preceding requirements, makes it difficult for users to remember their
passwords.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 17
The profile identifies the routine to use.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 18
Enforcing Password Management (continued)

Passwords must be easy to remember, or users will violate security rules by writing them, such
as noting them down on the underside of the keyboard or more obvious places. The following
two suggestions can help produce memorable and strong passwords:
Pick a name, phrase, or some other set of characters that you can remember, place your
fingers on the keyboard, and move them one row up or down. Then, type as if your fingers
were on the home row. This has the effect of encrypting your password.
Recall a poem, a song, or a recitation that you remember well. Use the first or last letter
from each word, including punctuation, to form your password.
Enable Password Complexity Checking
Password verification helps enforce strong passwords. The utlpwdmg.sql script in the
$ORACLE_HOME/rdbms/admin directory creates a PL/SQL function called
VERIFY_FUNCTION_11G, and then sets the DEFAULT profile to use this routine. Additional
information on this function is provided on the next page.
Enabling Built-in Password Complexity Checker
SQL> CONNECT / as SYSDBA

SQL> @?/rdbms/admin/utlpwdmg.sql
Alter a profile to use the password verification function:

ALTER PROFILE users_profile LIMIT
PASSWORD_VERIFY_FUNCTION verify_function_11g;
Enabling Built-in Password Complexity Checker

VERIFY_FUNCTION_11G is a sample PL/SQL function that can be easily modified to enforce the
password complexity policies at your site. Both VERIFY_FUNCTION_11G and the older
VERIFY_FUNCTION are included in the utlpwdmg.sql file.
To enable password complexity checking, create a verification function owned by SYS. Use one of
the supplied functions or modify one of them to meet your requirements. The example shows using
the utlpwdmg.sql script. If there is an error in the password complexity check function named in
the profile or it does not exist, you cannot change passwords or create users. The solution is to set
PASSWORD_VERIFY_FUNCTION to NULL in the profile, until the problem is solved.
The VERIFY_FUNCTION11G function checks that the password contains at least eight characters,
contains at least one number and one alphabetic character, and differs from the previous password by
at least three characters. The function also checks that the password is not one of the following: a
username or username appended with a number between 1 and 100; a username reversed; a server
name, or server name appended with a number between 1 and 100; or one of a set of well-known
and common passwords such as welcome1, database1, oracle123, or oracle
(appended with a number between 1 and 100), and so on.
Your password verification routine can be added to a custom profile as shown in the slide.
Users should always use the SQL*Plus PASSWORD command rather than the ALTER
USERIDENTIFIED BY command.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 19
Execute the utlpwdmg.sql script to create the password

verification function named VERIFY_FUNCTION_11G and
alter the default profile to use the function:
Which of the following would you need to perform to implement

the Oracle-supplied password complexity function?
a. Execute the utlpwdmg.sql script.
b. Grant EXECUTE on the function to database users.
c. Alter the DEFAULT profile to use the function.
d. Alter profiles other than the DEFAULT profile to use the
function.
Answer: a, d
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 20
Quiz
The data dictionary is protected, by default, with the

O7_DICTIONARY_ACCESSIBILITY initialization parameter
set to FALSE.
This configuration prevents users with the ANY system
privileges from accessing the data dictionary base tables.
The SELECT ANY DICTIONARY system privilege allows
read access only to the dictionary.
Protecting the Data Dictionary

In Oracle Database 11g, by default, the data dictionary is protected to prevent users having the ANY
system privileges from using such privileges on the data dictionary. The
O7_DICTIONARY_ACCESSIBILITY initialization parameter controls this behavior.
The default value for O7_DICTIONARY_ACCESSIBILITY is FALSE. Setting the
O7_DICTIONARY_ACCESSIBILITY parameter to FALSE may impact existing Oracle and thirdparty application environments that depend on dictionary access. Customers should refer to
application-specific documentation for security guidelines.
This configuration does not restrict users who have the DBA privilege, such as SYSDBA.
If a user requires view access to the data dictionary, it is permissible to grant that user the SELECT
ANY DICTIONARY system privilege. This configuration allows the user to read the data dictionary,
but does not give the user access to objects owned by other schemas.
Example
If this parameter is set to TRUE, any user with a DROP ANY TABLE system privilege can drop parts
of the data dictionary either maliciously or accidentally.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 21
Protecting the Data Dictionary
System and Object Privileges
Limit system privileges.

Selectively grant specific privileges to users.
Encapsulate sensitive objects.
System and Object Privileges

Analyze your system while keeping the principle of least privilege in mind. This requires more
effort, but it can prevent misuse. There will always be bugs, and ingenious individuals will find new
ways of exploiting weaknesses in the very complex business systems that have been deployed.
Although the next exploit cannot be predicted, if you put the principle of least privilege into practice,
the number and severity of possible exploitations can be reduced.
Grant only the privileges required. The GRANT ALL command gives a user the ability to drop or
alter a database object. These privileges must be reserved for the DBA, application administrator,
and the object owner, except in special cases. Granting the DBA role must be limited to the actual
DBA. At many sites, even the DBA role has more privileges than required, and a new role must be
created with a subset of the DBA role privileges. The CONNECT, RESOURCE, and DBA roles are
provided in the database for backward compatibility. These roles have more privileges than are
required in most cases. Create new roles that are customized to the requirements of your site.
Encapsulate objects containing sensitive data and access them only through stored procedures and
packages. Sensitive data is not just data of a confidential nature, but data and objects that must be
kept correct to prevent business disruption. The stored procedure can apply stringent controls on
what can be updated easily. These procedures can also provide auditing mechanisms beyond the
capability of database auditing features.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 22
Applying the principle of least privilege:

Limit object privileges to actual needs.
Do not use GRANT ALL ON object.
Restricting the Directories

Accessible by the User
Allows granular access to directory paths by the user

Allows read or write access separately
Is limited to the directories that the Oracle process can access
Example:
CREATE DIRECTORY local AS '/user/local/dbs';
GRANT READ, WRITE ON DIRECTORY local TO scott;
Restricting the Directories Accessible by the User

The UTL_FILE_DIR configuration parameter has been deprecated in favor of the DIRECTORY
object. By default, no directories can be accessed. With UTL_FILE_DIR, all PL/SQL users can read
from or write to all files in the directories specified by this parameter. Thus, all PL/SQL users must
be trusted with the information in the directories specified by this parameter.
Never set UTL_FILE_DIR = * because this enables access to all directories accessible by the
Oracle instance, including the data file and redo log directories.
Directory Objects
The recommended method of controlling database-user access to OS directories is through directory
objects. Any OS path that is accessible to the Oracle software owner can be accessed through a
directory object. A DIRECTORY object is created with a name and a path, as shown in the slide. All
directories are created in a single namespace and are not owned by an individual schema. You must
have the CREATE ANY DIRECTORY system privilege to create directories. When a user creates a
directory, that user is automatically granted the READ and WRITE object privileges on the directory
with the GRANT option. The DBA can also grant these privileges to other users and roles.
Best Practice Tip: Avoid allowing different database instances access to the same directories.
Differing security requirements could allow one to read or write sensitive data from or to the other.
Also one instance could cause a Denial of Service (DoS) for the other instance by completely filling
a common file system.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 23
Do not use the UTL_FILE_DIR parameter.

Use DIRECTORY objects:
Managing Fine-Grained Access to

External Network Services
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl => 'us-oracle-com-permissions.xml',
description => Permissions for oracle network',
principal => SCOTT',
is_grant => TRUE,
privilege => 'connect');
END;
Managing Fine-Grained Access to External Network Services

The network utility family of PL/SQL packages such as UTL_TCP, UTL_INADDR, UTL_HTTP,
UTL_SMTP, and UTL_MAIL allow Oracle users to make network callouts from the database using
raw TCP or higher-level protocols built on raw TCP. By default, the execute privilege on these
packages is granted to PUBLIC. In Oracle Database 11g, access to network resources through these
packages is controlled by access control lists (ACL). The DBMS_NETWORK_ACL_ADMIN package
allows you to manage fine-grained control using access control lists (ACL) implemented by XML
DB. The SYS user, XDB user, and users with the XDBADMIN role are not restricted by the ACL.
The ACLs may be managed either through the PL/SQL API shown or through Enterprise Manager.
Managing the ACL is a two-step process. First, create the ACL and include the principal, which is
either a user or a role. Then add privileges to the ACL. When you add privileges, you can also add
users to the ACL. The ACL is a mapping of users, privileges, and network resources. The network
resources can be specified as IP addresses, machine or domain names, or URLs.
1. Create an access control list (ACL): The ACL is a list of users and privileges held in an XML
file. The XML document named in the acl parameter is relative to the /sys/acl/ folder in
XML DB. In the example, SCOTT is granted CONNECT. The username is case-sensitive in the
ACL and must match the username of the session. There are only RESOLVE and CONNECT
privileges. The CONNECT privilege implies RESOLVE. Optional parameters can specify a start
and end time stamp for these privileges.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 24
1. Create an access control list (ACL) and its privileges:
Managing Fine-Grained Access to

External Network Services
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl => us-oracle-com-permissions.xml',
host => *.us.oracle.com',
lower_port => 80,
upper_port => null);
END;
Managing Fine-Grained Access to External Network Services (continued)

2. Assign an ACL to one or more network hosts: The ASSIGN_ACL procedure associates the
ACL with a network host and, optionally, a port or range of ports. In the example, the host
parameter allows wildcard characters for the host name to assign the ACL to all the hosts of a
domain. The use of wildcards affects the order of precedence for the evaluation of the ACL.
Fully qualified host names with ports are evaluated before hosts with ports. Fully qualified host
names are evaluated before partial domain names, and subdomains are evaluated before the toplevel domain level.
Multiple hosts can be assigned to the same ACL and multiple users can be added to the same ACL in
any order after the ACL has been created.
For more information, see the My Oracle Support note 453756.1, Configuring Fine-Grained Access
to External Network Services.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 25
2. Assign an ACL to one or more network hosts:
Database jobs execute with the privileges of the owner.

The CREATE ANY JOB privilege allows a job to be created in
any schema.
The CREATE EXTERNAL JOB privilege is required to create
an OS job.
Managing Scheduler Security

The Scheduler is a very powerful manageability feature. You can create jobs from PL/SQL blocks,
stored procedures, programs, or external commands. Privileges of these jobs fall into two categories:
database jobs and external jobs. External jobs are OS commands.
Database jobs are run with the privileges that are granted to the job owner directly or indirectly
through default logon roles. External OS roles are not supported. Given sufficient privileges, users
can create jobs in schemas of other users. The creator and the owner of the job can, therefore, be
different. For example, if user JIM has the CREATE ANY JOB privilege and creates a job in the
SCOTT schema, the job will run with the privileges of SCOTT.
You should grant the CREATE JOB system privilege to regular users who need to use the Scheduler
to schedule and run jobs. You should grant MANAGE SCHEDULER to any database administrator who
needs to manage system resources. Granting any other Scheduler system privilege or role should only
be done with great caution. In particular, the CREATE ANY JOB system privilege and the
SCHEDULER_ADMIN role, which includes the CREATE ANY JOB privilege, are very powerful
because they allow execution of code as any user.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 26
Managing Scheduler Security
External Jobs
Is named the extjob process

Is owned by root
Runs as the user specified in the externaljob.ora file
An external job on Windows:

Is named the OracleJobSchedulerSID Windows service
Runs as LocalSystem or a named user
External Jobs
A particularly important issue from a security point of view is handling external jobs. Only users that
need to run jobs outside of the database should be allowed to do so. Grant the CREATE EXTERNAL
JOB system privilege only to those users.
When upgrading from Oracle Database 10g Release 1 to 10g Release 2 or higher, CREATE
EXTERNAL JOB is automatically granted to all users and roles that have the CREATE JOB privilege.
It is recommended that you revoke this privilege from users that do not need it.
In Oracle Database 10g Release 2 and later, the security model allows you to edit the
external_job.ora file in the $ORACLE_HOME/rdbms/admin directory to specify which
user the extjob should run as. The external_job.ora file is owned by the root user and can
be modified only by root.
In Oracle Database 11g on UNIX and Linux, the extjob process is owned by root with the setuid
bit set, but the external jobs started by extjob run as the OS user nobody by default or the user
specified by the externaljob.ora file.
On Windows, the jobs will run as the user specified for the OracleJobScheduler<SID>Windows
service: either LocalSystem or a named user (local or domain).
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 27
An external job on UNIX:
Limiting Users with Administrative Privileges
Grants of system and object privileges

SYS-privileged connections: SYSDBA and SYSOPER
DBA-type privileges, such as DROP ANY TABLE
Restrict run-time permissions.

Example: List all users with the DBA role:
SQL> SELECT grantee FROM dba_role_privs
2
WHERE granted_role = 'DBA';
GRANTEE
-----------------------------SYS
SYSTEM
Limiting Users with Administrative Privileges

Do not provide database users more privileges than necessary. To implement the least privilege,
restrict the following types of privileges:
Grants of system and object privileges
SYS-privileged connections to the database, such as SYSDBA and SYSOPER
Other DBA-type privileges, such as DROP ANY TABLE
Grant SYSOPER instead of SYSDBA as much as possible. Administratively, limit access to the
SYSDBA password.
Create separate user accounts with DBA-like privileges, but limit the privileges to just those that are
needed. Create roles similar to the DBA role but with only the required privileges for a job function.
Assign the role to all users with that job function.
Restricting Permissions on Run-Time Facilities
Do not assign all permissions to any database server run-time facility, such as the Oracle Java Virtual
Machine. Grant specific permissions to the explicit file paths for such facilities that may execute files
and packages outside the database server.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 28
Restrict the following types of privileges:
Limiting Users with Administrative Privileges (continued)

The following example of a vulnerable run time gives SCOTT read access to all the files and
directories below the root directory:
call dbms_java.grant_permission (
'SCOTT', 'SYS:java.io.FilePermission', '/-', 'read' );
The following example of a better and more secure run-time call restricts SCOTT to reading all the
files in the HR directory:
Example
The example in the slide lists all users who have the DBA role granted to them. The two users
displayed are the built-in users with the DBA role granted.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 29
call dbms_java.grant_permission (
'SCOTT', 'SYS:java.io.FilePermission', '/hr/*', 'read' );
Separation of Responsibilities
Prevent abuse of trust

Allow audit trails to protect the trusted position
To implement separation of responsibility:
DBA responsibilities must be shared

Accounts must never be shared
DBA and system administrator must be different people
SYSOPER and SYSDBA responsibilities must be separated
Security officer is an additional protection

Oracle Database Vault provides separation of duty features
Separation of Responsibilities
These are the main requirements for a satisfactory separation of duties. Many small companies do not
have enough people to fulfill all these requirements. For more stringent requirements, Oracle
Database Vault enforces separation of duties.
DBAs must be trusted. It is hard to restrict a DBA. To do their job, DBAs require high-level
privileges. A DBA has a position of trust and must be thoroughly vetted. Even a trusted DBA
must have accountability. A policy of separation of responsibility can:
- Prevent abuse of trust. A DBA can view the encrypted passwords in the DBA_USERS
table. The DBA can save any users encrypted password, change the password, and connect
as that user. When finished, the DBA can replace the users original password by using the
following command:
ALTER USER username IDENTIFIED BY VALUES 'encrypted_password';
The DBA need not know the original password. This action is not traceable unless auditing
for the ALTER ANY USER privilege is turned on. If the password profile
PASSWORD_REUSE_MAX is set to a number of days, the password cannot be set back to
the original value for a number of days (of course, a DBA can also change the profile
during this exploit). In Database Vault, by default, the DBA user cannot issue an ALTER
USER IDENTIFIED BY command. Only the database account manager would be
allowed to do that.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 30
Users with DBA privileges must be trusted, but separation

of responsibilities can:
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 31
Separation of Responsibilities (continued)

Allow audit trails to protect the trusted position. When auditing is carefully implemented
and the guidelines have been followed, the audit trail can show that the particular person did
not violate procedures or commit a damaging act. If a malicious user tries to cast suspicion
on a trusted user, well-designed audit trails detect the act. In the lesson titled Auditing
Database Users, Privileges, and Objects, you implement auditing on SYSDBA users.
DBA responsibilities must be shared. In any job that requires trust, the principle of
separation of responsibilities protects all involved. A single DBA does not have the
oversight of another to correct errors, ask questions, and challenge actions. Two or more
DBAs can hold each other accountable.
Accounts must never be shared. This principle applies from the least-privileged account to
the highest. When users share accounts (and passwords), no single user can be held
accountable. With shared accounts, audit records can narrow the source but not confirm the
actual user. It is especially important that root and DBA accounts are not shared. When
multiple users require SYSDBA privileges, they can be added to the OSDBA group. Each
user can have his or her own account and connect by using the AS SYSDBA clause.
The DBA and the system administrator must be different people. The DBA must not
have root access. System administrators with root access can always give themselves
SYSDBA privileges. In very secure environments, even most system administrators are not
given root access on production servers; instead, root privileges are handled via audited
mechanisms such as sudo. By separating duties, the DBA and the system administrator can
avoid situations where one person can easily compromise security. Even with trusted people
in these positions, audit logs must be maintained and protected by yet another person to
allow accountability.
Historically, banks have required officers to take two consecutive weeks of vacation to
prevent embezzlement and consequent concealment. Rotation of duties of system
administrators, DBAs, and security officers adds another layer of accountability. If someone
always administers the same task with no oversight, he or she could be hiding improper
actions. Rotating duties increases the likelihood of catching an embezzler and preventing
abuse of trust violations.
SYSOPER and SYSDBA responsibilities should be separated. Do not grant SYSDBA
when SYSOPER provides sufficient privileges. The SYSOPER role can do almost all of the
day-to-day operations that SYSDBA can, but cannot see all the data. SYSOPER has only the
privileges that are granted to the PUBLIC user. For example, the PUBLIC user does not
have the SELECT ANY TABLE or EXECUTE ANY PROCEDURE privileges by default. The
SYSDBA role has the privileges granted to SYS.
Security officer is an additional protection. Additional roles such as security officer and
auditor can provide an another level of oversight. The security officer role could be
responsible for account activations and grants. Auditing activities such as enabling,
disabling, and viewing audit records can be included in the auditor role.
Oracle Database Vault enforces separation of duties. Oracle Database Vault enforces
separation of duties by default. Privileges of the SYSDBA user are limited. A separate user
is required by Oracle Database Vault to create and alter users. With Oracle Database Vault,
you have the ability to create new administrative roles with specific privileges tailored to
the job and no more. Refer to Oracle Database Vault Administrators Guide 11g Release 2
(11.2) for detailed information about separation of duties.
Authenticate the users through the middle tier.

Use secure application roles.
Use Virtual Private Database.
Audit user activity, especially privileged activity.
Encrypt columns for additional privacy protection.
Using Available Database Security Features

Use the following database features to restrict data access:
Enable and disable roles to restrict the current privileges of a user. Enabling and disabling roles
are discussed in the Oracle Database 11g: Administration Workshop I course.
Use secure application roles to enable roles only after they pass a validation check.
Use virtual private databases to limit the rows that a user can access from a table or view.
Encrypt columns for additional privacy protection.
Secure application roles, middle-tier authentication, virtual private databases, and encryption are
covered in subsequent lessons in this course.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 32
Using Available Database Security Features

Apply the principle of least privilege to the database
Lock and expire default user accounts
Change default user passwords
Create strong passwords
Enforce password management
Protect the data dictionary
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 33
Summary

Finding and correcting security policy violations
Creating a security officer account
Applying a password verification function
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
3 - 34
Hardening Database Access
Auditing Database Users,

Privileges, and Objects

following:
Implement basic database auditing
Implement auditing of the privileged user
Implement data manipulation language (DML) and data
definition language (DDL) auditing
Send audit records to the operating system (OS) files
Configure audit trail purging
Objectives
Monitoring for Suspicious Activity
Monitoring or auditing should be an integral part of your

security procedures.
The audit tools in Oracle Database include:
Database auditing
Audit privileged user operations
Fine-grained auditing (FGA)
You can create custom value-based auditing.
Monitoring for Suspicious Activity

Even authorized, authenticated users can sometimes compromise your system. Identifying
unusual database activity (such as an employee who suddenly begins querying large amounts of
credit card information, research results, or other sensitive information) can be the first step to
detecting information theft. Oracle Database provides a rich set of auditing tools to track user
activity and identify suspicious trends.
The administrator can audit all actions that take place within the database. It is important to
remember that capturing and storing audit information increases the amount of work that the
system must perform. Auditing should be focused so that only events that are of interest are
captured. Properly focused auditing has minimal impact on system performance. Improperly
focused auditing can significantly affect performance.
Oracle Database provides three different types of auditing: standard database auditing
(implemented with the AUDIT command), audit of privileged user operations with the
AUDIT_SYS_OPERATIONS parameter, and fine-grained auditing (FGA). A fourth audit type,
value-based auditing, may be implemented by customizing your application with triggers and
PL/SQL.
Standard database auditing captures several pieces of information about an audited event,
including that the event occurred, when it occurred, the user who caused the audited event, and
which client machine the user was on when the event happened.
Value-based auditing is a technique for capturing changes (inserts, updates, or deletes) to

data. It is a customization that is built for each application. Value-based auditing extends
standard database auditing, capturing not only that the audited event occurred, but also the
actual values that were inserted, updated, or deleted. Value-based auditing has been
traditionally implemented through database triggers. Flashback data archive (FDA),
flashback transaction, and Log Miner can be used to extract changes to table data.
Monitoring for Suspicious Activity (continued)

Audit of privileged users is always on for connections and can be turned on to capture all
operations. This level of audit always goes to the operating system: either to the audit trail
files on UNIX or the Application Event Viewer in Windows.
Fine-grained auditing (FGA) audits DML statements: INSERT UPDATE, DELETE, and
SELECT. FGA extends standard database auditing, capturing the actual SQL statement that
was issued rather than only what action occurred (type of statement executed). The FGA
policy determines which statements are captured based on which columns and rows are
accessed. For more detail, see the lesson titled Auditing DML Statements.
Type of Audit
What Is Audited?
What Can Be in
the Audit Trail?
Standard database
auditing
Privilege use, including object

access
Fixed set of data,

including the SQL
statement and bind
Privileged user
auditing
Connections by default
When enabled, all the
statements that are issued
Fixed set of data
Fine-grained auditing
(FGA)
SQL statements (INSERT,

UPDATE, DELETE, and
SELECT) based on content
Fixed set of data,

including the SQL
statement and bind;
extensible through
event handlers
Audit Tool Comparisons

Fine-grained auditing in Oracle Database includes DML statement auditing, including MERGE,
and per-policy and auditing of large objects (LOBs). Details of FGA are covered in the lesson
titled Auditing DML Statements.
Audit Tool Comparisons
Is enabled through the AUDIT_TRAIL parameter
Can audit:
Login events
Exercise of system privileges
Exercise of object privileges
Use of SQL statements
Standard Database Auditing: Overview

To use database auditing, you must first set the static AUDIT_TRAIL parameter to point to a
storage location for audit records.
Database auditing can capture information about login events, the exercise of system privileges,
and the exercise of object privileges.
Standard Database Auditing: Overview
DBA
Enable
database
auditing.
Parameter
file
Specify audit options.
User
executes
command.
Database
SYSLOG
files
Audit
options
syslog
Audit
trail
Server
process
Generate
audit trail.
Review audit information.
OS audit
trail
Standard Database Auditing

After the administrator has enabled database auditing (with the AUDIT_TRAIL parameter) and
specified auditing options, the database begins collecting audit information.
If AUDIT_TRAIL is set to OS, the audit records are stored in the operating system either as a
file in the AUDIT_FILE_DEST directory or in the SYSLOG files as specified by the
AUDIT_SYSLOG_LEVEL parameter. On a Windows system, audit records are stored in the
application event log. On a UNIX or Linux system, audit records are stored in a file. If
AUDIT_TRAIL is set to DB, audit records are stored in the AUD$ table that is part of the SYS
schema. The AUD$ table is stored in the SYSTEM tablespace. Moving the AUD$ table to another
schema or tablespace is not supported.
Note: The AUD$ table will be moved to the SYSTEM schema when Oracle Label Security (OLS)
is installed.
Standard Database Auditing
Standard Database Auditing (continued)

It is important to manage and protect the audit trail. A knowledgeable person would try to
remove traces of unauthorized activity from the audit trail. Export the audit trail regularly if
it is in the database. If it is on the OS, copy it to another machine. Depending on the focus of
the audit options, the audit trail can grow very large very quickly. If not properly
maintained, the audit trail can consume so much space that it affects the performance of the
system. It is often a temptation to simply delete the audit records without analysis when
there is a large volume. If audit records are not analyzed and archived, there is no need to
audit.
Usually, the task of managing the database audit trail is handled by the DBA. But if this task
needs to be delegated, DELETE_CATALOG_ROLE grants permission to delete the audit
records from the audit trail. A common practice is to export the SYS.AUD$ table, and then
truncate.
The root user usually manages the audit files on the OS, but this can be delegated as well
by setting the permissions on the files and directories.
The audit trail and the privileges required to access it should be audited whether on the OS
or in the database. If the operations on the audit trail are audited, these audit records need to
be placed in some other location that is managed separately from the audit trail. This is a
problem that can be solved by Oracle Audit Vault.
The parameter values can be:

NONE: Disables collection of audit records
DB: Enables auditing with records stored in the database
DB,EXTENDED: Populates SQLBIND and SQLTEXT
columns
XML: Enables auditing with records stored in XML format
OS files
XML,EXTENDED: Includes SQLBIND and SQLTEXT
information
OS: Enables auditing with records stored in the OS audit
trail
Setting the AUDIT_TRAIL Parameter

The AUDIT_TRAIL parameter defines where audit records will be written. This parameter is
set to DB by default. If AUDIT_TRAIL is not set or is set to a value of NONE, standard database
auditing is disabled. The AUDIT_TRAIL parameter is a static parameter and cannot be
modified without restarting the database instance. To change this parameter, the user must have
the ALTER SYSTEM privilege or access to the initialization parameter file.
The possible parameter values that enable auditing are:
DB: Enables database auditing and directs all audit records to the database audit trail (the
SYS.AUD$ table)
DB,EXTENDED: In addition to action of the DB value, captures the SQL executed along
with any bind variables (SQLTEXT and SQLBIND columns) of the audit table
XML: Enables database auditing and writes all audit records to the XML format OS files
XML,EXTENDED: In addition to the action of the XML value, captures the SQL executed
along with any bind variables
OS: Enables database auditing and directs all audit records to the operating systems audit
trail. If AUDIT_SYSLOG_LEVEL is set, the records are sent to the syslog process.
For all AUDIT_TRAIL options that write to the OS files, the default directory is determined by
AUDIT_FILE_DEST.
Setting the AUDIT_TRAIL Parameter
Audit Log Location Options
SYSDBA
The DBA role
Anyone with the * ANY TABLE privileges
Optionally, Database Vault can protect database audit

tables from the privileged users.
OS audit files are accessible to:
The root user on the repository machine
Any user depending on directory permissions
Audit Vault records are accessible to:

Configured users
Records protected by Database Vault
Audit Log Location Options

The location of the audit logs determines the security of the audit records. The primary question
is Who has access to the audit records? The audit records must not be accessible to a person
that is being held accountable by those records. For example, the user with the privileges of the
DBA role could perform a malicious act and delete the audit records if the records were in the
database. An OS user that is given or gains root privileges can erase the traces of his or her
activities from OS files. Audit logs must be protected. Tables containing audit logs must be
exported regularly from the database, and OS audit logs copied to another machine.
OS files are considered more secure than database tables for audit records. Seldom are database
users, even SYSDBA, given root privileges; therefore, it is reasoned that OS files can be
protected by OS privileges. But the oracle user must have write privileges on the file. Often,
the SYSDBA user has access to the oracle user account and password, and therefore has
access to the audit log file.
There are two solutions: syslog and Oracle Audit Vault. syslog is a UNIX facility that
accepts messages from any enabled process, and writes the message to any file or stream.
syslog can write as root to a directory that the oracle user cannot access, or to another
machine where the root password is different. Oracle Audit Vault employs a logically
equivalent method. Oracle Audit Vault accepts audit records from collectors and stores those
records in a separate secure database protected by Oracle Database Vault.
Who has access?

The database audit table is accessible to:
11.2
Moving the Database Audit Trail from the SYSTEM

Tablespace
The database audit trail (SYS.AUD$ and SYS.FGA_LOG$

tables) can be moved from the SYSTEM tablespace to:
User-created tablespace
Use the
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION
procedure to move the audit trail tables from the current
tablespace to a user-specified tablespace:
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
AUDIT_TRAIL_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
AUDIT_TRAIL_LOCATION_VALUE => 'AT_TBS')
Moving the Database Audit Trail from the SYSTEM Tablespace

To minimize the effect on performance in the SYSTEM tablespace, you can move the database
audit trail tables (SYS.AUD$ and SYS.FGA_LOG$) from the SYSTEM tablespace to the
SYSAUX tablespace or to a user-created tablespace by using the
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION procedure.
The DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION procedure has the following
parameters:
AUDIT_TRAIL_TYPE: Specifies the database audit trail type. Valid values are:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Indicates the standard audit
trail table (SYS.AUD$)
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Indicates the fine-grained audit
trail table (SYS.FGA_LOG$)
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Indicates the standard and finegrained audit trail tables
AUDIT_TRAIL_LOCATION_VALUE: Specifies the destination tablespace
Before executing the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION procedure,
you should ensure that the destination tablespace has adequate space to accommodate the audit
trail tables.
SYSAUX tablespace
Moving the Database Audit Trail from the SYSTEM Tablespace (continued)
Note: The DBMS_AUDIT_MGMT package belongs to the SYS schema. The EXECUTE
privilege on this package is granted only to EXECUTE_CATALOG_ROLE. Because the
procedures in this package are used to manage audit records, the EXECUTE privilege on the
package should be carefully administered.
11.2
The DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property

specifies the maximum size to which an operating system
or XML audit file can grow before a new file is opened.
Set the property by using the
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY
procedure:
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
AUDIT_TRAIL_PROPERTY=>DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
AUDIT_TRAIL_PROPERTY_VALUE=>100)
Query DBA_AUDIT_MGMT_CONFIG_PARAMS to view

current settings.
The default value is 10 MB.
Limiting the Size of the Operating System Audit Trail

You can limit the size of the operating system audit trail file by setting the
DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property. This property is set through the
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY procedure.
The procedure has the following parameters:
AUDIT_TRAIL_TYPE: Specifies the type of operating system audit trail. Valid values
are:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS: Specifies operating system audit trail
files that have an .aud extension.
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: Specifies XML audit trail files.
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES: Specifies operating system (.aud
extension) and XML audit trail files.
AUDIT_TRAIL_PROPERTY: Must be set to
DMBS_AUDIT_MGMT.OS_FILE_MAX_SIZE to set the maximum size
AUDIT_TRAIL_PROPERTY_VALUE: Used to set the maximum file size. The default is
10 MB.
You can query DBA_AUDIT_MGMT_CONFIG_PARAMS to view the current values.
Limiting the Size of the

Operating System Audit Trail
11.2
The DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE property

specifies the maximum age in days that an operating
system or XML audit file is open before a new file is
created.
Set the property by using the
procedure:
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_PROPERTY=>DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
AUDIT_TRAIL_PROPERTY_VALUE=>14)
The default value is 5 days.
Limiting the Age of the Operating System Audit Trail

You can limit the age of the operating system audit trail file by setting the
DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE property. This property is set through the
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY procedure. When this limit is met, a
new operating system file is created for subsequent audit trail records.
are:
files that have an .aud extension
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML: Specifies XML audit trail files
extension) and XML audit trail files
AUDIT_TRAIL_PROPERTY: Must be set to
DMBS_AUDIT_MGMT.OS_FILE_MAX_AGE to set the age limit
AUDIT_TRAIL_PROPERTY_VALUE: Used to set the age limit in days. The default is 5
days.
Limiting the Age of the

Operating System Audit Trail
11.2
Use the
procedure to clear the
DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE and
DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE properties.
Setting USE_DEFAULT_VALUES to:
TRUE sets the property to the default value
FALSE clears the property so that no file size or age is set
DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY(
AUDIT_TRAIL_PROPERTY=>DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
USE_DEFAULT_VALUES=>TRUE)
Clearing the Size and Age Properties

You can clear the size and age properties by using the
DBMS_AUDIT_MGMT.CLEAR_AUDIT_TRAIL_PROPERTY procedure.
are:
extension) and XML audit trail files
AUDIT_TRAIL_PROPERTY:
- DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE to clear the file size
- DMBS_AUDIT_MGMT.OS_FILE_MAX_AGE to clear the age limit
USE_DEFAULT_VALUES:
- TRUE: To set the property to the default value
- FALSE: To clear the property value and revert to pre-Oracle Database 11g Release 2
behavior
Clearing the Size and Age Properties
Specifying Audit Options
SQL statement auditing (nonfocused and focused):
System-privilege auditing (nonfocused and focused):
AUDIT select any table, create any trigger;

AUDIT select any table BY hr BY ACCESS;
Object-privilege auditing (nonfocused and focused):
AUDIT ALL on hr.employees;

AUDIT UPDATE,DELETE on hr.employees BY ACCESS;
Specifying Audit Options

Auditing may be focused BY SESSION or BY ACCESS with the exception of audited DDL
statements, which are always BY ACCESS. For object and statement auditing, BY ACCESS and
BY SESSION both produce one audit record per statement, but populate different values in the
ACTION field of the audit record. BY SESSION is the default for statement and object auditing.
BY ACCESS is the default for privilege auditing.
SQL statement auditing: The statement shown in the slide audits any DDL statement that
affects a table, including CREATE TABLE, DROP TABLE, and TRUNCATE TABLE. The
following SQL statement auditing is focused, only collecting unsuccessful actions for the
hr user:
SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;
System-privilege auditing: This is used to audit the exercise of any system privilege (such
as DROP ANY TABLE).
Object-privilege auditing: This is used to audit actions on tables, views, procedures,
sequences, directories, and user-defined data types.
Network Auditing: This is typically used to uncover network layer configuration errors.
For more information, see Oracle Database Security Guide.
AUDIT table;
AUDIT SELECT TABLE BY SCOTT BY ACCESS;
Note: Often, your audit options start as unfocused because you are not sure what type of
activity you are looking for. The AUDIT ALL option is a convenient shortcut to audit a
broad range of activity. If used with object-privilege auditing (as shown in the slide), it
detects the following: ALTER, AUDIT, COMMENT, DELETE, GRANT, INDEX, INSERT,
LOCK, READ, RENAME, SELECT, and UPDATE.
If the AUDIT ALL option specifies a username such as AUDIT ALL BY hr, all DDL
statements for the following objects and actions are audited for the user:
ALTER SYSTEM
Cluster
Context
CREATE SESSION
Database Link Dimension
Directory
Index
Materialized
NOT EXISTS
View
Public
Public Synonym
Database Link
Sequence
Synonym
Procedure
Profile
Role
System Audit
Rollback
Segment
System Grant
Table
Tablespace
Trigger
Type
User
View
Specifying Audit Options (continued)

Events that generate audit records can focus on individual users and the status of the event
(successful or not). An example of a poorly focused audit command is: AUDIT TABLE
This audit command generates a large amount of information capturing any operation that
affects any table.
A better example of an audit command (because it is more narrowly focused) is: AUDIT
DELETE ON hr.employees WHENEVER SUCCESSFUL
BY ACCESS
Auditing BY ACCESS generates an audit trail record for every user attempt. The benefit of
BY ACCESS is that the audit trail shows the number of times the audited action was
attempted, the sequence of audited actions, and the result (either success or failure code) of
each action. An ACCESS record with a nonzero value in
DBA_AUDIT_TRAIL.RETURNCODE indicates a failed attempt. RETURNCODE is simply
the Oracle error code returned due to the failure.
AUDIT WHENEVER SUCCESSFUL or NOT SUCCESSFUL
All AUDIT types can be restricted to audit only when a user action succeeds or when it fails.
Note that the syntax is WHENEVER [NOT] SUCCESSFUL. If the clause is removed entirely,
an audit record will always be created. Restricting audit records to successful or failed
attempts can be a useful tool in limiting the extraneous records in the audit trail. If users are
allowed to perform certain actions, and if there is no security relevance to those actions,
there is no need to audit on success. Instead, you should audit unsuccessful actions. This not
only catches attempts to escalate privileges and exploration by malicious users, but also
catches failed SQL, indicating application-coding errors or users who need training.
Auditing Sessions
Audit unsuccessful attempts to connect:
Monitor DBA_AUDIT_SESSION:
USERNA
-----FRED
FRED
FRED
FRED
ACTION_NAME
RETURNCODE LOGOFF
-------------------- ---------- ---------LOGON
1017
LOGOFF
0 0829 22:39
LOGOFF BY CLEANUP
0 0829 22:40
LOGON
0
Check DBA_AUDIT_TRAIL.COMMENT_TEXT.
Auditing Sessions
The AUDIT SESSION option audits the creation of user sessions in the database by auditing the
CREATE SESSION privilege. It can be focused by username or by success or failure. This
option is unique because it generates a single audit record for each session created by
connections to an instance. An audit record is inserted into the audit trail at connection time and
updated at disconnection time. Cumulative information about a session (such as connection time,
disconnection time, and logical and physical I/Os processed) is stored in a single audit record
that corresponds to the session. In many databases, it is common to use the AUDIT SESSION
(unfocused) command. In almost all databases, you should audit unsuccessful login attempts
because this allows you to detect attempts to break into your database.
The AUDIT SESSION command is one of the primary sources of confusion for new auditors.
Records produced by this audit option are unusual in that they are updated after the initial write
to the audit trail. The initial record is written with an action of LOGON, and when the user
disconnects, the record is updated and the action is changed. This can cause confusion. You find
only a few LOGON records, but many LOGOFF records in the audit trail. If AUDIT SESSION is
enabled, session statistics are accumulated for each successful connection and written when the
session ends. This behavior changed starting with 11.1.0.7. The LOGON record will not be
updated, but a LOGOFF record will be created. This applies to both OS and database audit trails.
AUDIT CREATE SESSION BY ACCESS

WHENEVER NOT SUCCESSFUL;
select username, to_char(timestamp,'MMDD HH24:MI:SS') ts,

action_name, returncode,
to_char(logoff_time,'MMDD HH24:MI:SS') Logoff
from dba_audit_trail order by timestamp;
USERNA
-----FRED
FRED
FRED
FRED
TS
---------0829 22:29
0829 22:36
0829 22:39
0829 22:41
ACTION_NAME
RETURNCODE LOGOFF
-------------------- ---------- ---------LOGON
1017
LOGOFF
0 0829 22:39
LOGOFF BY CLEANUP
0 0829 22:40
LOGON
0
Note that the elapsed time for the session is available by subtracting the logoff time from the
login time. Calculate the elapsed time in days, and then adjust it to the desired units.
select (LOGOFF_TIME-TIMESTAMP)*(60*24) AS
"session time in minutes"
from dba_audit_trail
where action_name like 'LOGOFF%'
and logoff_time is not null;
The DBA_AUDIT_TRAIL.COMMENT_TEXT field is critical in analyzing SESSION audits

because it contains authentication information about the connection method. Although IP
addresses and client machine names can be spoofed, the information is still useful in most
cases.
Note: If the SYSTEM tablespace holding the audit table is full, and AUDIT SESSION is on,
no audited user can log in. For this reason, login by SYSDBA is never audited by AUDIT
SESSION, so SYSDBA can log in to fix the problem. To see failed SYSDBA login attempts,
you must review the OS audit log. SYSDBA logins are always recorded in the OS audit logs.
Auditing other SYSDBA actions is covered later in this lesson.
Auditing Sessions (continued)

ACTION_NAME is changed from LOGON to LOGOFF for a clean exit, or to LOGOFF BY
CLEANUP if the session terminated without logging off. Records with
ACTION_NAME=LOGON are either unsuccessful login attempts (check RETURNCODE to
see why) or successful connections (RETURNCODE = 0). The database does not clean up the
LOGON records during instance recovery, so LOGON records indicating successful logon
with no matching session identify current sessions at the time of a database abort or crash.
In the following example, the first record has a nonzero value in RETURNCODE (in this
case, a logon attempt with the wrong password). The second record was produced when
FRED connected, and then exited normally. The LOGOFF BY CLEANUP record was
produced by connecting as FRED, and then killing the SQL*Plus client process instead of
logging out. The last LOGON record is the current session and was used to execute the query:
Data Dictionary View
Description
ALL_DEF_AUDIT_OPTS
Default audit options
DBA_STMT_AUDIT_OPTS
Statement auditing options
DBA_PRIV_AUDIT_OPTS
Privilege auditing options
DBA_OBJ_AUDIT_OPTS
Schema object auditing options
Viewing Auditing Options

To see which audit options have been selected, use the views listed in the slide.
DBA_STMT_AUDIT_OPTS and DBA_PRIV_AUDIT_OPTS list the audit options that have
been enabled respectively for statements and privileges. DBA_OBJ_AUDIT_OPTS contains one
record per audited object regardless of what object audit options have been specified. The view
shows a column for each audit option. For example, INSERT audit options are shown in the
INS column. Audit options are displayed as SUCCESSFUL/NOT SUCCESSFUL with three
possible values for each status:
- Not audited
S Collect audit records by session
A Collect audit records by access
SQL> SELECT object_name, object_type, ins, upd
FROM dba_obj_audit_opts WHERE object_name = 'EMPLOYEES'
OBJECT_NAME OBJECT_TY INS UPD
------------ --------- --- --EMPLOYEES
TABLE
A/S -/-
The ALL_DEF_AUDIT_OPTS view shows the default object-auditing options that will be
applied when objects are created.
Viewing Auditing Options
Audit Trail View
Description
DBA_AUDIT_TRAIL
All audit trail entries
DBA_AUDIT_EXISTS
Records produced by the NOT EXISTS audit
DBA_AUDIT_OBJECT
Records concerning the schema objects
DBA_AUDIT_SESSION
All connect and disconnect entries
DBA_AUDIT_STATEMENT
Auditing records at the statement level
Viewing Auditing Results

Access to audit records in any location should be tightly controlled because they may contain
sensitive information. The DBA_AUDIT_* views access the SYS.AUD$ table. This table is
populated only when AUDIT_TRAIL=DB or DB,EXTENDED.
Despite the many views against the audit trail, most of them work from the same base table
(AUD$), so they are just restricting and reformatting the data that is already available in
DBA_AUDIT_TRAIL. Do not make the mistake of creating a UNION of the various audit trail
views.
The DBA_AUDIT_EXISTS view is a bit different because these records are produced by setting
AUDIT NOT EXISTS. It holds the records of all SQL statements that fail because a specified
object does not exist.
Viewing Auditing Results
Quiz
a. True
b. False
Answer: b
To use standard database auditing to audit the use of object

privileges, you need to set only the AUDIT_TRAIL parameter
to DB, EXTENDED to generate audit records.
11.2
Use the procedures in DBMS_AUDIT_MGMT to purge audit

trail records after they have been archived.
To configure automatic purging of archived audit trail
records, perform the following steps:
1. Initialize the audit trail for purging by executing the
INIT_CLEANUP procedure.
2. Set the "last archive timestamp" for the audit records by
using the SET_LAST_ARCHIVE_TIMESTAMP procedure.
3. Purge audit trail records by using the CREATE_PURGE_JOB
to create and schedule a purge job.
Purging Audit Trail Records

In Oracle Database 11g Release 2, the DBMS_AUDIT_MGMT package contains procedures that
enable you to manually purge audit trail records. In addition, by using the
CREATE_PURGE_JOB procedure, you can configure a job to automatically purge audit records.
Additional information about DBMS_AUDIT_MGMT procedures is provided on the following
pages.
Purging Audit Trail Records
11.2
Initializing the Audit Trail for Purging

Configure the audit trail purging infrastructure and a default
cleanup interval by executing
DBMS_AUDIT_MGMT.INIT_CLEANUP:
DBMS_AUDIT_MGMT.INIT_CLEANUP(
AUDIT_TRAIL_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
DEFAULT_CLEANUP_INTERVAL=>8)
INIT_CLEANUP needs to be executed only once.
Cleanup interval can be modified by using the

procedure.
Initializing the Audit Trail for Purging

Before creating the audit trail purge job, you must execute the
DBMS_AUDIT_MGMT.INIT_CLEANUP procedure to configure the audit trail purging
infrastructure and a default cleanup interval. This procedure needs to be executed only once.
If the audit trail tables are located in the SYSTEM tablespace, they will be moved to the SYSAUX
tablespace during the execution of the INIT_CLEANUP procedure.
Note: You can use the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION procedure to
move the audit trail tables from the current tablespace (including SYSTEM) to a user-specified
tablespace.
The DBMS_AUDIT_MGMT.INIT_CLEANUP procedure has the following parameters:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Indicates the standard audit
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Indicates the fine-grained audit
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Indicates the standard and finegrained audit trail tables
DEFAULT_CLEANUP_INTERVAL: Specifies the interval (in hours) after which the
DBMS_AUDIT_MGMT.CLEAN_AUDIT TRAIL is called
11.2
DBMS_AUDIT_MGMT_SET_LAST_ARCHIVE_TIMESTAMP
is used to specify when the audit records were last
archived.
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL uses the
timestamp to determine which audit records to purge.
Time zone of the timestamp must be:
Coordinated Universal Time (UTC) for database audit trail
tables
Local time zone time when the audit trail types are
AUDIT_TRAIL_OS or AUDIT_TRAIL_XML
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
LAST_ARCHIVE_TIME=>'2010-01-13 2:00:00')
Setting an Archive Timestamp for Audit Records

The DBMS_AUDIT_MGMT.LAST_ARCHIVE_TIMESTAMP procedure has the following
parameters:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Specifies the standard audit
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Specifies the fine-grained audit
LAST_ARCHIVE_TIME: Specifies when the audit records or files were last archived
- Must be specified in Coordinated Universal Time (UTC) when the audit trail types
are AUDIT_TRAIL_AUD_STD or AUDIT_TRAIL_FGA_STD because the audit
record timestamp format is UTC
- Must be specified as the local time zone time when the audit trail types are
AUDIT_TRAIL_OS or AUDIT_TRAIL_XML
RAC_INSTANCE_NUMBER: Specifies the instance number for an Oracle Real Application
Clusters (RAC) instance. Optional for non-RAC databases.
Setting an Archive Timestamp for Audit Records
11.2
You can manually purge the audit trail by using

DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL.
The USE_LAST_ARCH_TIMESTAMP parameter indicates
whether to purge records created only before the last
archive timestamp (TRUE) or all records (FALSE):
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
USE_LAST_ARCH_TIMESTAMP=>TRUE)
Manually Purging the Audit Trail

The DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedure has the following parameters:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Specifies the standard and finegrained audit trail tables
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: Specifies all audit trail records
(database and operating system)
USE_LAST_ARCH_TIMESTAMP: Specifies whether the last archived timestamp should
be used to determine which records should be deleted
- TRUE: Indicates that only audit records created before the last archive timestamp
should be deleted. This is the default value.
- FALSE: Indicates that all audit records should be deleted
Manually Purging the Audit Trail
11.2
Use DBMS_AUDIT_MGMT.CREATE_PURGE_JOB to
automate audit trail purging.
Modify the status of the purge job (enable/disable) by
using DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS.
Modify the purge interval of the purge job by using
DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL.
DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(
AUDIT_TRAIL_PURGE_INTERVAL=>8,
AUDIT_TRAIL_PURGE_NAME=>'AT_PURGE',
USE_LAST_ARCH_TIMESTAMP=>TRUE)
Scheduling an Automatic Purge Job for the Audit Trail

Use the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB procedure to create and schedule a job
that will periodically purge the audit trail. The purge job calls the CLEAN_AUDIT_TRAIL
procedure to purge the audit trail records.
The DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedure has the following parameters:
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Specifies the standard and finegrained audit trail tables
- DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL: Specifies all audit trail records
(database and operating system)
AUDIT_TRAIL_PURGE_INTERVAL: Specifies the interval, in hours, when the clean up
procedure is called
Scheduling an Automatic Purge Job for the Audit

Trail
You can disable and enable the audit trail purge job by using
DBMS_AUDIT_MGMT.SET_PURGE_JOB_STATUS. You can modify the interval at which
the CLEAN_AUDIT_TRAIL procedure is called for the purge job by using
DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL. Refer to Oracle Database PL/SQL
Packages and Types Reference 11g Release 2 (11.2) and Oracle Database Security Guide
11g Release 2 (11.2) for additional information about these procedures.
Scheduling an Automatic Purge Job for the Audit Trail (continued)

AUDIT_TRAIL_PURGE_NAME : Specifies a job name
USE_LAST_ARCH_TIMESTAMP: Specifies whether the last archived timestamp
should be used to determine which records should be deleted
- TRUE: Indicates that only audit records created before the last archive timestamp
should be deleted. This is the default value.
- FALSE: Indicates that all audit records should be deleted
Control auditing of privileged users with the following

parameters:
AUDIT_SYS_OPERATIONS enables additional auditing of
the SYSDBA or SYSOPER actions.
AUDIT_FILE_DEST controls the location of the audit trail.
The default is:
(UNIX or Linux)
First: $ORACLE_BASE/admin/<ORACLE_SID>/adump
Second: $ORACLE_HOME/rdbms/audit
On Windows: Windows Application Event Log
Auditing the SYSDBA and SYSOPER Users

The SYSDBA and SYSOPER users have privileges to start up and shut down the database.
Because they may make changes while the database is closed, the audit trail for these privileges
must be stored outside the database. The instance captures login events by the SYSDBA and
SYSOPER users automatically, but does not capture anything other than the login events unless
auditing is specifically enabled. The audit trail files require frequent monitoring due to growth.
Enable the auditing of the SYSDBA and SYSOPER users by setting the initialization parameter:
AUDIT_SYS_OPERATIONS=TRUE (the default is FALSE)
If SYS operations are audited, the AUDIT_FILE_DEST initialization parameter controls where
the audit records will be stored. On a Windows platform, the SYS operations audit trail defaults
to the Windows Application Log. On UNIX or Linux platforms, audit records are stored in
$ORACLE_HOME/rdbms/audit by default. The audit file on Linux is named ora_N.aud,
where N is the process ID.
Note: Before the instance comes up, SYSDBA and SYSOPER login events may be recorded in
the $ORACLE_BASE/admin/$ORACLE_SID/adump directory.
The SYS audit log records the OS user and the database user when the authentication is through
the password file. When the authentication is by the OS (the OS user must be a member of the
OSDBA group), the SYS audit log shows only the OS user. The database user is /.
All the initialization
parameters
that CLASSROOM
affect auditing
are static.
THESE Note:
eKIT MATERIALS
ARE FOR YOUR
USE IN THIS
ONLY.
COPYING eKIT MATERIALS FROM THIS
Auditing the SYSDBA and SYSOPER Users
Viewing the SYSDBA Audit Trails

Even if the DBA is trusted, it is critical to review failed connections to the SYSDBA account.
This is the only way to detect a password-cracking attempt against SYSDBA. A brute-force
attack against the password of a known SYSDBA account eventually succeeds.
The SYSDBA connection attempts always go to the OS audit log regardless of whether SYSDBA
auditing is enabled. But these records are often ignored or deleted to conserve space. SYSDBA
auditing provides a valuable way to track authorized or unauthorized SYSDBA actions, but it is
useful only if the OS audit trail is reviewed.
On the Windows platform, audit information is always written to the Event Viewer. So,
AUDIT_FILE_DEST is not supported in Windows. The audit record is viewed by navigating to
the Event Viewer and selecting the Application Log. Note that, in the slide, a record with a
source of Oracle.orcl is selected for viewing. Some operations (such as startup and
shutdown, and connection attempts) are always captured. An excerpt from the audit file from a
Linux system is shown on the next page.
Best Practice Tip: Windows Event Log entries could be overwritten when the Application
Event Viewer properties are configured to Overwrite events . Change the setting to Do not
overwrite events so that the logs can be archived and cleared manually.
Viewing the SYSDBA Audit Trails
Audit file /home/oracle/orcl/audit/ora_28480.aud

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
Oracle Database Vault and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
System name:
Linux
Node name:
ed.us.oracle.com
Release:
2.6.18-92.el5
Version:
#1 SMP Fri May 23 22:17:30 EDT 2008
Machine:
i686
Instance name: p1orcl
Redo thread mounted by this instance: 1
Oracle process number: 24
Unix process pid: 28480, image: oracle@ed.us.oracle.com (TNS V1-V3)
Fri Jan 8 11:19:34 2010 +00:00
ACTION : 'CONNECT'
DATABASE USER: '/'
PRIVILEGE : SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL:
STATUS: 0
Fri Jan 8 11:19:34 2010 +00:00
ACTION : 'ALTER SYSTEM SET AUDIT_SYSLOG_LEVEL='local3.info'
SCOPE=SPFILE'
DATABASE USER: '/'
PRIVILEGE : SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL:
STATUS: 0
Fri Jan 8 11:19:34 2010 +00:00
ACTION : 'ALTER DATABASE CLOSE NORMAL'
DATABASE USER: '/'
PRIVILEGE : SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL:
STATUS: 0
Viewing the SYSDBA Audit Trails (continued)
Audit to XML Files
Audit records can be sent to XML format files.
Fine-grained audit (FGA) records
XML files can be read with a variety of readers.

XML files can be protected by the OS.
Audit to XML Files

Oracle Database allows most audit records to be sent to XML format files. Setting
AUDIT_TRAIL to XML or XML,EXTENDED causes the standard audit records and the SYS
audit records to be written in XML format. With the variety of XML readers available, this
feature eases the monitoring of audit records.
If you place audit records on the OS rather than in the database, it makes hiding a malicious
action in the database by removing the audit trail slightly more difficult.
Warning: A database user with access to the OS database owner login or a login that is a
member of the OSDBA group can access the OS files from an OS login. A user with the CREATE
DIRECTORY privilege can create a directory object in the database and overwrite the audit file
by using the UTL_FILE package. This applies to any OS audit file written by the instance.
Standard audit
SYS operations audit records
Writing Audit Records to syslog
Audit records sent to syslog can be written to:

Files owned by root
Configuring syslog
The AUDIT_SYSLOG_LEVEL initialization parameter sets
facility.priority of the messages.
The syslog.conf file determines where syslog writes the
message.
Note: syslog is available for *NIX only.
Writing Audit Records to syslog

In Oracle Database, the database processes can be configured to send the audit records to the
syslog process on UNIX and Linux machines. The syslog process runs as root and can
write the syslog output to any users file. The file permissions of the log file are never
changed by syslogthis means you can set the permissions to secure the log files without
concern for syslog. If the syslog output is written to a different OS user or to a different
server, a process running under the oracle user OS account would be unable to delete or
modify the audit trail, thus removing the possibility that a user with knowledge of the Oracle
software owner password could alter the audit trail to hide malicious actions. The capability and
configuration of the syslog facility varies somewhat by platform. But syslog can write the
messages it receives to: a local file, syslog on another machine, named pipes, a list of users, a
terminal, or console. The configuration also allows the messages to be written to multiple
locations.
On UNIX and Linux systems, the AUDIT_SYSLOG_LEVEL parameter overrides
AUDIT_FILE_DESTINATION and sends the audit records to the syslog process. The
syslog.conf file configures where the syslog process writes various records based on the
facility and priority.
Another machine
Configuring Auditing to syslog
Set the parameters:
*.AUDIT_TRAIL=OS
*.AUDIT_SYSLOG_LEVEL='local1.info'
Modify the syslog.conf file.

Add configuration lines.
# Capture Oracle audit records

local1.info
/var/log/oracle_audit.log
local1.info
@edrsr5p1
Configure the services file on remote machines.

Configuring Auditing to syslog

To configure the Oracle processes to send the audit records to syslog, set the AUDIT_TRAIL
parameter to OS and AUDIT_SYSLOG_LEVEL to facility.priority.
The facility and priority values are a limited set determined by the syslog process. On Linux,
the possible values of facility are: auth, authpriv, cron, daemon, kern, lpr, mail,
news, syslog, user, uucp, and local0 through local7. If Oracle audit records are to be
kept separate from other OS messages, choose a facility that is not used on your systemfor
example, local1. The allowed priority values are in ascending order: debug, info,
notice, err, warning, crit, alert, and emerg. The priority defines the severity of the
message. All error messages sent from the Oracle processes will have the same
facility.priority tag.
Modify the /etc/syslog.conf file. Add a line or lines to specify where the audit records
are to be written. In the example in the slide, audit records will be written to the file at
/var/log/oracle_audit.log. The second line specifies that the records are to be written
to the remote machine edrsr5p1.
Configure the services on the remote machine for syslog to listen on port 514/udp.
Typically, this can be performed only by the root user. Start the syslog process with the -r
option to force it to listen for messages from remote machines.
AUDIT_TRAIL = OS
AUDIT_SYSLOG_LEVEL = facility.priority
syslog Limitations
Fine-grained audit records are not captured.

Oracle Label Security audit records are not captured.
Oracle Database Vault audit records are not captured.
Message limited to 1,024 bytes on some machines.
Remote messages are sent by user datagram protocol
(UDP)
syslog Limitations
The syslog logging does not capture audit records from fine-grained auditing.
The syslog logging does not capture Oracle Database Vault audit records. OS and syslog
logging encode information, and this information can be decoded using data dictionary tables
and error messages as follows:
Action code: Describes the operation performed or attempted, using codes listed in the
AUDIT_ACTIONS data dictionary table, with their descriptions
Privileges used: Describes any system privileges used to perform the operation, using
codes listed in the SYSTEM_PRIVILEGE_MAP table, with their descriptions
Completion code or return code: Describes the result of the attempted operation, using
codes listed in Oracle Database Error Messages, with their descriptions. Successful
operations return a value of zero and unsuccessful operations return an Oracle error code
corresponding to the reason the operation was unsuccessful.
syslog limitations:
syslog Limitations (continued)

A sample syslog record is:
In the audit record, nnnnn in the Oracle Audit [nnnnn] entry is the Oracle server process
ID.
The syslog messages are limited and must meet the standards set by the Internet
Engineering Task Force. These standards are under review and may change to increase the
allowable message size, increase security, and provide a more reliable protocol.
Universal Datagram Protocol (UDP) is the protocol used by syslog to send messages to
another machine. This protocol is unreliable because no acknowledgement is required. This
means that the message is sent to the remote machine, and if for some reason the message
does not arrive, the contents are lost.
Oct 3 02:34:50 edrsr10p1 Oracle Audit[13312]: SESSIONID: "216276"

ENTRYID: "1" STATEMENT: "1" USERID: "SYSMAN" USERHOST:
"edrsr10p1.us.oracle.com" TERMINAL: "unknown" ACTION: "100" RETURNCODE:
"0" COMMENT$TEXT: "Authenticated by: DATABASE; Client address:
(ADDRESS=(PROTOCOL=tcp)(HOST=139.185.35.110)(PORT=2387))" OS$USERID:
"oracle" PRIV$USED: 5
A user makes a
change.
Trigger fires.
An audit record is
created by the
trigger.
The users change

is made.
A record is
inserted into an
audit trail table.
Value-Based Auditing
Database auditing records that inserts, updates, and deletes have occurred on audited objects, but
does not capture the actual values that have been changed. Value-based auditing extends
database auditing, capturing the actual values that have been changed. Value-based auditing
leverages database triggers (event-driven PL/SQL constructs).
When a user inserts, updates, or deletes data into or from a table with the appropriate trigger
attached, the trigger works in the background to copy audit information to a table designed to
contain the audit information. Value-based auditing tends to degrade performance more than
standard database auditing because the audit trigger code must be executed each time the insert,
update, or delete operation occurs. The degree of degradation depends on the efficiency of the
trigger code. Value-based auditing should be used only in situations where the information
captured by standard database auditing is insufficient.
In Oracle Database, there are certain features that reduce the need for user-developed valuebased auditing. Flashback data archive (FDA) allows the database administrator to configure a
secure area in the database to capture all the changes to a specific table. Flashback transaction
can be used to view the data as it was at a particular point in time if either undo records exist or
FDA is enabled. The Log Miner utility also allows the database administrator to view all
transactions that have occurred by reconstructing the SQL statements that were issued from redo
log records if the archived redo logs are still available.
Value-Based Auditing
CREATE OR REPLACE TRIGGER system.hrsalary_audit

AFTER UPDATE OF salary
ON hr.employees
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF :old.salary != :new.salary THEN
INSERT INTO system.audit_employees
VALUES (sys_context('userenv','os_user'), sysdate,
sys_context('userenv','ip_address'),
:new.employee_id ||' salary changed from
'||:old.salary||
' to '||:new.salary);
END IF;
END;
/
This trigger focuses auditing to capture changes to the salary column of the
HR.EMPLOYEES table. When a row is updated, the trigger checks the salary column. If the
old salary is not equal to the new salary, the trigger inserts an audit record into the
AUDIT_EMPLOYEES table (created via a separate operation in the SYSTEM schema). The
audit record includes the username, the IP address from which the change has been made,
the primary key identifying which record has been changed, and the actual salary values that
have been changed.
This trigger uses the SYS_CONTEXT function to capture information from the built-in
USERENV context. This function is shown in detail in the lesson titled Using Application
Contexts, and the attributes of the USERENV context are listed in the appendix titled
USERENV Context.
Database triggers can also be used to capture information about user connections in cases
where standard database auditing does not gather sufficient data. With triggers, the
administrator can capture any information that is available to the database through any of the
database tables or views. Examples of such information include:
- IP address of the person logging in
- First 48 characters of the program name used to connect to the instance
- Terminal name used to connect to the instance
- MODULE or ACTION that originated the audited action (This may be available if the
application is instrumented by using the DBMS_APPLICATION_INFO package.)
Flashback Archive
Flashback Archive provides a way to capture all the changes to a table and view the values
in the table at any point in time during the retention period. Flashback Archive provides an
alternative to value-based auditing.
Value-Based Auditing (continued)

The key to value-based auditing is the audit trigger. A typical audit trigger is as follows:
Further enhance and protect the auditing by:

Capturing DML changes to the shadow table
Replicating audit records to another table
Capturing attempts to change audit records
Triggers and Autonomous Transactions

You can use database triggers to log events transparently. Suppose that you want to track all
DML changes to a table, even those that roll back. You can use a trigger to insert duplicate rows
into a shadow table as an autonomous transaction. Because it is autonomous, the trigger can
commit changes to the shadow table whether or not you commit changes to the main table. The
transaction of autonomous triggers is independent of the transaction and action that fire the
trigger. See a full example on the next page.
Note: An autonomous transaction is a transaction that takes place within another transaction,
usually in a trigger. The autonomous transaction can roll back or commit independently of the
status of the surrounding transaction and action that invoked the autonomous transaction. The
autonomous transaction is identified by PRAGMA AUTONOMOUS_TRANSACTION; in the
declare section of a PL/SQL block.
Triggers and Autonomous Transactions
Triggers and Autonomous Transactions (continued)
-- create an autonomous trigger that inserts into the

-- shadow table before each insert into the main table
CREATE TRIGGER parts_trig
BEFORE INSERT ON parts FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO parts_log VALUES(:new.pnum, :new.pname);
COMMIT;
END;
-- insert a row into the main table, and then commit the insert
INSERT INTO parts VALUES (1040, 'Head Gasket');
COMMIT;
-- insert another row, but then roll back the insert
INSERT INTO parts VALUES (2075, 'Oil Pan');
ROLLBACK;
-- show that only committed inserts add rows to the main table
SELECT * FROM parts ORDER BY pnum;
PNUM PNAME
------- --------------1040 Head Gasket
-- show that both committed and rolled-back inserts add rows
-- to the shadow table
SELECT * FROM parts_log ORDER BY pnum;
PNUM PNAME
------- --------------1040 Head Gasket
2075 Oil Pan
-- create a main table and its shadow table

CREATE TABLE parts (pnum NUMBER(4), pname VARCHAR2(15));
CREATE TABLE parts_log (pnum NUMBER(4), pname VARCHAR2(15));

Implement basic database auditing
Implement auditing of the privileged user
Implement DML and DDL auditing
Send audit records to the OS files
Configure audit trail purging
Summary

Applying database auditing
Enabling auditing of the SYS user
Capturing audit records with syslog
Implementing Basic Auditing

following:
Implement fine-grained auditing (FGA)
Maintain FGA policies
Implement an FGA audit event handler
Read FGA audit events from the FGA audit trail
Objectives
Fine-Grained Auditing (FGA)
Are created on tables or views

May fire an event handler procedure
Are administered with the DBMS_FGA package
Policy: AUDIT_EMPS_SALARY
SELECT name, salary
FROM employees
WHERE
department_id = 10;
EMPLOYEES
Fine-Grained Auditing (FGA)

Database auditing can record that an operation has occurred, and in extended mode, it records
the statement that caused the operation. FGA extends that capability, allowing auditing to be
more narrowly focused. FGA captures audit records when certain columns are accessed or when
specified conditions are met.
FGA auditing is available only with the Enterprise Edition of Oracle Database 11g.
FGA audit options can be focused on individual columns within a table or view, and can even be
specified so that audit records are captured only if certain administrator-defined conditions are
met.
The administrator uses the DBMS_FGA PL/SQL package to create an audit policy on the target
table or view. If any of the rows returned from a query block matches the audited column and
the audit condition, an audit event causes an audit record to be created and stored in the FGA
audit trail (FGA_LOG$). Optionally, the audit event can also execute a procedure. FGA
automatically focuses auditing at the statement level. So a SELECT statement that returns
thousands of rows generates only one audit record.
Note: A MERGE statement is not considered a single auditable statement. It can perform an
INSERT, UPDATE, and sometimes DELETE. So the FGA policies for each of these could fire
for one MERGE statement.
Policies:
Monitor data access based on content
Audit SELECT, INSERT, UPDATE, or DELETE
dbms_fga.add_policy
object_schema =>
object_name
=>
policy_name
=>
audit_condition=>
audit_column =>
handler_schema =>
handler_module =>
enable
=>
statement_types=>
Defines:
Audit criteria
Audit action
(
'hr',
'employees',
'audit_emps_salary',
'department_id=10',
'salary',
'sec',
'log_emps_salary',
TRUE,
'select' );
SELECT last_name,job_id
FROM employees;
SELECT last_name,salary
FROM employees
WHERE
department_id = 10;
SEC.LOG_
EMPS_SALARY
EMPLOYEES
FGA audit trail
FGA Policy
The slide illustrates an example where the SEC user uses the DBMS_FGA.ADD_POLICY
procedure to create an FGA policy on the HR.EMPLOYEES table. After an FGA policy has been
enabled, any SQL statement that matches the audit condition and audit column will generate an
audit record.
Note: The SEC user must be granted EXECUTE on the DBMS_FGA package.
The procedure accepts the following arguments:
Policy Name: Each FGA policy is assigned a name when you create it. The example in the
slide names the policy AUDIT_EMPS_SALARY, using the following argument:
policy_name => 'audit_emps_salary'
Object: The object is the table or view that is being audited. It is passed as two arguments:
- The schema that contains the object
- The name of the object
In the example in the slide, the HR.EMPLOYEES table is audited by using the following
arguments:
object_schema => 'hr'
object_name => 'employees'
FGA Policy
FGA Policy (continued)
Statement Type: Which type of statements should be audited? Any combination of

SELECT, INSERT, UPDATE, DELETE, or INDEX may be specified as a single
comma delimited string for the statement_types argumentfor example,
'SELECT,INSERT,DELETE'. The default is all except INDEX.
Audit Condition: The audit condition is a SQL predicate that defines when the audit
event should fire. In the example in the slide, whenever an employee record belonging
to department 10 is accessed, an audit event fires due to the audit_condition
argument:
audit_condition => 'department_id = 10'
Audit Column: The audit column defines the data that is being audited. An audit
event occurs only if this column is included in the SELECT statement. In the example
in the slide, the SALARY column is audited by using the following argument:
audit_column => 'salary'
This argument is optional. If it is not specified, only the AUDIT_CONDITION

argument determines whether an audit event occurs.
Handler: An optional event handler is a PL/SQL procedure that defines any additional
actions that should be taken during auditing. For example, the event handler may send
an alert page to the administrator. When the audit event occurs, an audit event entry is
inserted into the FGA audit trail. If an audit event handler is defined, the audit event
handler is executed.
The audit event entry includes the FGA policy that caused the event, the user
executing the SQL statement, and the SQL statement and its bind variables.
The event handler is passed as two arguments:
- The schema that contains the PL/SQL program unit
- The name of the PL/SQL program unit
The example in the slide executes the SEC.LOG_EMPS_SALARY procedure by using
the following arguments:
handler_schema => SEC'
handler_module => 'log_emps_salary'
Status: The status indicates whether the FGA policy is enabled. In the example in the
slide, the following argument enables the policy:
enable => TRUE
The FGA policy can generate audit records when the SQL statement does not access the
columns or rows targeted. This is called a false positive. This can occur because the
evaluation takes place at parse time rather than when the rows are returned. False positives
can occur but not false negatives.
Triggering Audit Events

The following SQL statements cause an audit event:
SELECT count(*)
FROM hr.employees
WHERE department_id = 10
AND salary > &v_salary;
SELECT salary
FROM hr.employees;
The following statement does not cause an audit event:
SELECT last_name
FROM hr.employees
WHERE department_id = 10;
Triggering Audit Events

In general, the audited columns and simple user-defined SQL predicates determine the FGA
policy. During parsing, whenever policy conditions are met for a statement, the statement is
audited, and if there is an event handler, it is also fired.
The audit function is executed as an autonomous transaction. Each audit policy is applied
individually. That is, as long as the rows being returned or changed match any of the audit
conditions defined on the table, an audit record is generated, but there is only one record
generated for each policy per SQL statement.
Examples
The first two examples in the slide cause an audit event because they access the SALARY
column and rows with DEPARTMENT_ID = 10. The database server is aware that the second
example accesses the rows in department 10, even though DEPARTMENT_ID is not referenced
in the SQL statement WHERE clause. No audit record is created if there are no records for
department 10.
The last example does not cause an audit event because the SALARY column is not accessed. If
the SALARY column had not been specified as AUDIT_COLUMN when the policy was created,
this SELECT statement would cause an audit event. My Oracle Support Note 266896.1, 10g:
Fine-Grained Auditing gives full examples of FGA behavior.
View Name
Description
DBA_FGA_AUDIT_TRAIL
All FGA events
ALL_AUDIT_POLICIES
All FGA policies for objects that the current

user can access
DBA_AUDIT_POLICIES
All FGA policies in the database
USER_AUDIT_POLICIES
All FGA policies for objects in the current

user schema
Data Dictionary Views

FGA audit entries are logged into a separate table from object and privilege audits. The entries
are recorded in the DBA_FGA_AUDIT_TRAIL view.
The other three views listed in the slide contain policy definitions.
Data Dictionary Views
SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')

2
AS timestamp,
3
db_user,
4
policy_name,
5
sql_bind,
6
sql_text
7
FROM dba_fga_audit_trail;
TIMESTAMP DB_USER POLICY_NAME
SQL_BIND
---------- ------- ----------------- ---------SQL_TEXT
----------------------------------------------0808272222 HR
AUDIT_EMPS_SALARY
#1(4):1000
SELECT COUNT(*) FROM HR.EMPLOYEES WHERE
DEPARTMENT_ID = 10 AND SALARY > :B1
0808272222 HR
SELECT salary
FROM hr.employees
AUDIT_EMPS_SALARY
DBA_FGA_AUDIT_TRAIL
Selecting from the FGA Audit Trail
The slide displays the two audit rows created by the valid examples from the previous page. The
SQL_BIND column has a value of #1(4):1000, which includes the following components:
#1indicates that this is the first bind variable in the statement.
(4)indicates that the bind variable has a length of 4.
1000 indicates that the bind variable has a value of 1000.
Note: This example shows a partial list of columns available in DBA_FGA_AUDIT_TRAIL.
For more information, see the Oracle Database Reference Guide.
DBA_FGA_AUDIT_TRAIL
Which of the following types of auditing must you implement to

audit the access of a specific column?
a. SQL statement auditing
b. Object privilege auditing
c. Fine-grained auditing
Answer: c
Quiz
Use DBMS_FGA to maintain FGA policies.

Grant the EXECUTE privilege only to administrators.
The DBMS_FGA package includes the following
subprograms:
Subprogram
Description
ADD_POLICY
Creates an audit policy by using the supplied

predicate as the audit condition
DROP_POLICY
Drops an audit policy
ENABLE_POLICY
Enables an audit policy
DISABLE_POLICY
Disables an audit policy
DBMS_FGA Package
The DBMS_FGA package is the tool to manage FGA functions. The EXECUTE privilege on
DBMS_FGA is needed to administer FGA policies. Because the FGA audit trail can contain
sensitive information, the EXECUTE privilege on this package must be reserved only for
administrators.
To audit usage of the DBMS_FGA package, wrap it with a PL/SQL package that captures user
information and then executes the DBMS_FGA procedures. Grant EXECUTE on the wrapper to
users that need it. Revoke EXECUTE from the DBMS_FGA package except to the owner of the
wrapper package. The PL/SQL wrapper package must use definers rights.
DBMS_FGA Package
Enabling and Disabling an FGA Policy

Enable a policy:
dbms_fga.enable_policy (
object_schema => 'hr',
object_name
=> 'employees',
policy_name
=> 'audit_emps_salary' );
Disable a policy:
dbms_fga.disable_policy (
object_name
=> 'employees',
policy_name
=> 'audit_emps_salary' );
Enabling and Disabling an FGA Policy

Enable an FGA to generate audit events. The policy will not generate any log events when it is
disabled. By default, the policy is enabled when it is created. The example in the slide shows
how to enable and disable a policy. For both procedures, all arguments are required.
BEGIN
dbms_fga.drop_policy (
object_name
=> 'employees',
policy_name
=> 'audit_emps_salary');
END;
Dropping an FGA Policy

If you no longer require an FGA policy, you can remove it with DBMS_FGA.DROP_POLICY.
All arguments are required.
Dropping an FGA Policy
FGA Policy Guidelines
To audit all statements, use a NULL or TRUE condition.

If the audit condition syntax is invalid, an ORA-28112 error is
raised when the audited object is accessed.
Audit columns
If audit column is set to NULL, all columns are audited.
If the audit column name is valid but incorrect, the wrong
statements are audited.
FGA Policy Guidelines

Audit Conditions
When creating a new FGA policy, the audit condition defaults to null. An audit condition of
null, or a condition that always evaluates to TRUE such as 1=1 are equivalent. Either means
that all statements will be audited, including statements resulting in no rows selected. FGA
with null (audit all) can be extremely useful in capturing SQL to determine whether tuning (or
developer training) is needed. It can also help troubleshoot data corruption from GUI
applications by capturing the data manipulation language (DML) statements plus bind variables.
If the audit condition has an invalid syntax, the policy is created without an error. But the
following error is raised when the audited object is accessed:
ORA-28112: failed to execute policy function
If the audit condition has a valid syntax, but is incorrect, the wrong rows are audited.
Audit Columns
When the audit column is null, all columns are audited.
If the audit column name is valid but incorrect, the wrong statements are audited.
Setting policy parameters

Audit conditions
FGA Policy Errors
Policy creation errors occur when:
The audit column does not exist
Audited SQL statements fail when:

The audit condition is invalid
The event handler does not exist or is invalid
FGA Policy Errors

Errors can occur at the time the policy is created, or when the policy is invoked. Some error
policy configuration errors do not appear until an audited SQL statement is executed.
Policy Creation Errors
Audited-Object Errors: The audited table or view must exist when you create the policy.
If it does not, you receive the following error:
ORA-00942: table or view does not exist
Policy-Name Error: Policy names must be unique within the database. They have no
owner. If a duplicate name is used, you receive the following error when creating the
policy:
ORA-28101: policy already exists
If the audit column does not exist, the ADD_POLICY procedure fails.
Audited SQL Statement Errors

Invalid Audit Condition: An audit condition with invalid syntax causes the SQL
statement to fail. No audit record can be created.
Invalid Event Handler: The policy is created even when the policy references a
nonexistent or invalid event handler. The SQL statement will fail when the handler is
accessed. Unhandled exceptions in the handler cause the SQL statement to fail. The policy
is still enforced and the audit records are created.
The audited table or view does not exist

The policy already exists; error ORA-28101 is raised
Maintaining the audit trail must include:

Reviewing and storing old records
Preventing storage problems
Avoiding loss of records
Maintaining the Audit Trail

Each type of audit trail must be maintained. Basic maintenance must include reviewing the audit
records and removing older records from the database or operating system. Audit trails can grow
to fill the available storage. If the file system is full, the system may crash or exhibit
performance problems. If the database audit trail fills the tablespace, audited actions do not
complete. If the audit trail fills the system tablespace, the performance of other operations are
affected before audit operations halt.
The audit trail for standard auditing is stored in the AUD$ table. The audit trail for FGA auditing
is the FGA_LOG$ table. Both these tables are created in the SYSTEM tablespace.
Audit records can be lost during the process of removing records from the audit tables. A copy
operation that is followed by a delete or truncate operation can remove records that are not
captured by the copy operation. A better method is to perform an export of records that is based
on a time stamp, and then delete those records that have the same (or an earlier) time stamp.
Maintaining the Audit Trail

Implement FGA
Maintain FGA policies
Implement an FGA audit event handler
Read FGA audit events from the FGA audit trail
Summary

Creating an FGA policy
Observing audited records in the database audit table
Creating an FGA policy with an event handler
Implementing Fine-Grained Auditing


following:
Authenticate users with passwords
Protect passwords
Authenticate users with the operating system (OS)
Protect database link passwords
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-2
Objectives
User Authentication
Database user identified by a password

Database user identified by the operating system
Proxy authentication
User Authentication
A basic security requirement is that you must know your users. You must identify them before you
can determine their privileges and access rights, so that you can audit their actions on the data. In this
lesson, you create and audit database authenticated users and operating system authenticated users.
Users can be authenticated in a number of different ways before they are allowed to create a database
session. With database authentication, you define users such that the database performs the
authentication of users. With operating system (OS) authentication, you define users such that
authentication is performed by the operating system or an OS-based network service.
Later lessons cover the following user authentication related topics:
Strong authentication: You can define users such that they are authenticated by strong
authentication methods: certificates, smart cards, and Kerberos.
Enterprise User Security: Enterprise users are authenticated through an enterprise directory
and authorized for access to the database through enterprise roles.
Proxy users: You can specify users who are allowed to connect through a middle-tier server.
The middle-tier server authenticates and assumes the identity of the user and is allowed to
enable specific roles for the user. This is called proxy authentication.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-3
Identify the user in the following ways:

Basic authentication
A database user:
Has a schema
Is easily audited
Is authenticated by a password in the database
CREATE USER username IDENTIFIED BY password;
User Identified by a Password

An IDENTIFIED BY PASSWORD user is always authenticated by the database. This user has a
schema. The schema may be empty but it does exist. Because the identity of the user is authenticated
by the database, the user identity is available for audit records. The authentication is based on a
password. The advantages are clear: simplicity, local authentication, and auditing, and the DBA has
complete control.
However, some of the advantages can also be viewed as disadvantages. Each database user is
authenticated in each database. This can result in a user having many different passwords. Each
database can have its own password policy. Conflicting policies often lead to multiple passwords per
user. When there is a change in user status, the user accounts must be updated in all databases where
the user accounts exist. Each database user has a schema and, by implication, can create certain
objects, even when most end users in a production database have no need for a schema.
When applications create a single local database user with password identification that is used to
establish a connection pool, end users can have lightweight sessions that increase performance, but
the application is then responsible for authenticating the end user.
When multiple databases can be accessed through database links, the database with the weakest
password protection could become a point of entry to all.
Best practice tip: Local database authentication should include a password profile that enforces
password policies and users should periodically be required to justify the existence of their accounts.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-4
User Identified by a Password
A database user:
Has a schema
Is easily audited
Is authenticated by the operating system
CREATE USER username IDENTIFIED EXTERNALLY;
User Identified Externally

The IDENTIFIED EXTERNALLY user has all the same advantages and disadvantages of the
IDENTIFIED BY PASSWORD user, with the major difference that the authentication is performed
by the operating system.
An IDENTIFIED EXTERNALLY user can connect to the database with a /. This type of
connection, by default, requires that the user have an account on the machine where the database
resides. The externally identified user account is used primarily for scripting and batch programming,
so passwords would not be embedded in files.
The OS_AUTHENT_PREFIX initialization parameter determines the relationship between the OS
account name and the database account name. The default value for this parameter is OPS$. Users
connecting as an OS-authenticated user do not supply a password to log in; / is sufficient. Unless
the REMOTE_OS_AUTHENT initialization parameter is also set the same, users would supply a
password on remote connectionsthat is, using @service_name.
The REMOTE_OS_AUTHENT initialization parameter allows the externally identified user to be
authenticated remotely. The default value is FALSE. This parameter is deprecated in Oracle
Database 11g and should not be used.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-5
User Identified Externally
Protecting Passwords
Beware that passwords placed in an environment variable

are visible when executing the ps command.
Use externally authenticated users for server scripts and
tools.
Protecting Passwords
Passwords used in scripts, job schedulers, and command lines are vulnerable. A password must never
be placed in script files in clear text. Even passwords embedded in executable files are vulnerable to
the strings command or a binary file editor.
Entering the password on the command line may seem safe if no one sees you type it. But on some
UNIX systems, it is possible to view the full command line, including the username and password,
by using the ps command with the appropriate switches. If an OS account is compromised, someone
viewing the shell command history file may find passwords to privileged database accounts. Using
environment variables to hold a password is also visible with the ps command and the show
environment switchfor example, ps ef e shows a full listing of every process followed by
the environment variables.
The externally authenticated database user account is a better way to protect the password:
CREATE OPS$FRED IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO OPS$FRED;
Suppose Fred is a database administrator (DBA) and needs to run batch jobs on the server machine.
With the two preceding commands, an OS user with a login of fred can now connect to the
database with / and run a script without a password:
sqlplus / @script
This method depends on the OS accounts being secure.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-6
A password must never be embedded in files.

Beware that passwords entered on the command line are
visible when executing the ps command.
Quiz
a. True
b. False
Answer: a
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-7
A user that is authenticated externally can execute a SQL*Plus

script as follows: sqlplus / @<script_name>
Fixed User Database Links

Create a public fixed database link:
Use a public database link:

SELECT * FROM emp@TEST;
connect scott/tiger
Finance
Fixed User Database Links

To create a fixed user database link, you embed the credentials (in this case, a username and
password) required to access the remote database in the definition of the link. In Oracle Database
11g, the credentials are stored in the data dictionary in an encrypted form.
The following statement creates a public link to the remote SUPPLY database by using the global
database name. The link connects to the remote database with the user ID and password as SCOTT
and tiger, respectively:
CREATE PUBLIC DATABASE LINK supply.us.acme.com
CONNECT TO scott IDENTIFIED BY tiger;
The following statement creates a private fixed user link called JANE_FINANCE to the database
with the service name, FINANCE. The link connects to the remote database with the user ID and
password as JANE and doe, respectively:
CREATE DATABASE LINK jane_finance
CONNECT TO jane IDENTIFIED BY doe USING 'finance';
When an application uses a fixed user database link, the local server always establishes a connection
to the specified schema in the remote database. The local server also sends the fixed users
credentials across the network when an application uses the link to access the remote database.
Anyone who is granted access to a fixed database link has access to everything in the remote schema.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-8
CREATE PUBLIC DATABASE LINK test CONNECT TO scott

IDENTIFIED BY tiger USING 'FINANCE';
Encrypted Database Link Passwords
SELECT userid, NVL(password,'NULL') as PASSWORD,

passwordx
FROM sys.link$
WHERE passwordx IS NOT NULL;
The passwords for fixed links are encrypted:

USERID
-----HR
SCOTT
PASSWORD
-------NULL
NULL
PASSWORDX
---------------------------------05D5C32321F5BE85A5647B59FA9E9C0ECC
050398267C2DAAA1535086BB5093B97AAF
Encrypted Database Link Passwords

Database link passwords are protected by encryption since Oracle Database 10g Release 2. Even
though the PASSWORD and PASSWORDX columns are visible in the SYS.LINK$ table, and the
PASSWORD column is visible to the link owner in the USER_DB_LINKS view, the password
column is NULL and the PASSWORDX column is encrypted.
For more information about the privileges that are necessary to view objects in the SYS schema, see
the Oracle Database Security Guide.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
6-9
A privileged user may view database link password

columns:
Database Links Without Credentials
CREATE DATABASE LINK sales.division3.acme.com

USING 'sales';
Create a current user database link:

CREATE DATABASE LINK sales
CONNECT TO CURRENT_USER USING 'sales';
Current user database links are part of Oracle Advanced
Security.
Database Links Without Credentials

Users can connect to remote databases without having to embed a password in the database link
definition. The connected user and current user database links do not include credentials in the
definition of the link. The credentials that are used to connect to the remote database change
depending on the user that references the database link and the operation performed by the
application.
Creating a Connected User Database Link
To create a connected user database link, omit the CONNECT TO clause. The following syntax
creates a connected user database link, where dblink is the name of the link and USING
net_service_name is an optional connect string:
CREATE DATABASE LINK dblink ... [USING 'net_service_name];
This type of database link requires that the user on the local database have an account on the remote
database with the same username and password. The local instance passes the credentials of the
current user to the remote instance.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 10
To avoid storing passwords in the data dictionary:

Create a connected user database link:
Database Links Without Credentials (continued)

Creating a Current User Database Link
To create a current user database link, use the CONNECT TO CURRENT_USER clause in the link
creation statement. The following syntax creates a current user database link, where dblink is
the name of the link and USING net_service_name is an optional connect string:
To use a current user database link, the current user must be a global user registered with a
Lightweight Directory Access Protocol (LDAP) directory service and be authorized to connect to
both the databases that are involved in the link. Because a current user link must be for a user
identified globally, this is available only through Oracle Advanced Security.
Controlling Access to Remote Databases
In many distributed applications, you do not want a user to have privileges in a remote database.
One simple way to achieve this result is to embed a fixed user or current user database link
within a procedure. This procedure performs the needed SQL operation with definers rights.
Thus, the user accessing the procedure temporarily assumes the privileges of the user defined in
the link. The fixed link connects to the remote database as the user defined in the link. The
current user link connects as the owner of the procedure.
In this definers rights example, the HR user creates a database link and a procedure, and then
grants EXECUTE on the procedure to a role: HR_CLERK. Anyone with the role can execute the
update_hr_salary procedure, but cannot access the remote HR schema through the
database link except through the procedure.
CONNECT HR
PASSWORD:****
CREATE DATABASE LINK hremp
CONNECT TO hr IDENTIFIED BY oracle_1 USING 'p0orcl';
CREATE OR REPLACE PROCEDURE update_hr_salary
(p_employee_id NUMBER, p_salary NUMBER)
IS
BEGIN
UPDATE employees@hremp SET salary = p_salary
WHERE employee_id = p_employee_id;
END;
GRANT execute on update_hr_salary to HR_CLERK;
See the dblink_proc.sql demonstration script in the /home/oracle/demos directory.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 11
CREATE DATABASE LINK dblink

CONNECT TO CURRENT_USER [USING 'net_service_name'];
Database Links and Changing Passwords
Current user links: User credentials are in the directory.

Connected user links: Find links to be changed by username.
Fixed links: Find links to be changed by username.
Database Links and Changing Passwords

Good practice demands that all passwords be changed periodically. There is no automatic way to find
the database links on remote databases that depend on the password on a local database. Password
changes on one machine can cause the database links on multiple machines to fail.
For ease of maintenance, current user links are the best. The user credentials are kept in a directory.
The password is changed in only one location.
For connected user links, the administrative practice of keeping all passwords the same on all
databases will mitigate the troubleshooting that is required when passwords are not synchronized.
This practice depends on users remembering to drop and create all links on all machines that depend
on the password when the password must be changed on the links.
For fixed links, keep a record of all database links by auditing the CREATE and DROP LINK
commands, and audit ALTER USER to detect password changes. User-created links can be listed with
the query:
SELECT owner, db_link, username, host FROM DBA_DB_LINKS
WHERE username not in ('SYS', 'SYSTEM', 'PUBLIC');
This query reports the user that is named in the CONNECT TO clause, and the host where the user
account exists.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 12
Good practice requires passwords to change.

Cascade password changes to database links.
Auditing with Database Links
connect scott/tiger
Finance
Local database audits

JANE
Remote database audits

SCOTT
Auditing with Database Links

You must always perform auditing operations locally. That is, if a user acts in a local database and
accesses a remote database through a database link, the local actions are audited in the local
database, and the remote actions are audited in the remote database, provided that appropriate audit
options are set in the respective databases.
The remote database cannot determine whether a successful connection request and subsequent SQL
statements come from another server or a locally connected client. For example, assume the
following:
A fixed user link named hq.acme.com connects the local user JANE to the remote HQ
database as the remote user SCOTT.
The SCOTT user is audited on the remote database.
Actions performed during the remote database session are audited as though SCOTT were connected
locally to HQ and performing the same actions there. You must set audit options in the remote
database to capture the actions of the user (in this case, SCOTT on the HQ database) that is embedded
in the link if the desired effect is to audit what jane does in the remote database.
Note: You can audit the global username for global users. Global users are identified in the directory.
You cannot set local auditing options on remote objects. Therefore, you cannot audit the use of a
database link although access to remote objects can be audited on the remote database.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 13
connect jane/doe
Creating views to access data through a database link:

Allows private database link owned by the application
owner
Limits the access to the remote schema
Limits changes to a database link to a view rebuild
Simplifies auditing of database link access
Restricting a Database Link with Views

When a database link is exposed to an end user, that user has access to every table in the schema
authorized by the database link. Auditing the access of the database link is not possible on the local
machine.
A possible solution is to create a view in the schema of the application owner that uses the database
link. The database link is owned by the application owner, and not exposed to other users. The
application owner grants access only to the views. Typically, the application owner account would be
locked in the production environment.
The solution of putting the database link behind a view provides an extra layer of security and also
minimizes the dependency on the database link. If something about the remote database changes, the
database can be changed in one place and the views that need to be rebuilt are limited to the schema
of the application owner. In many databases, the policies require that passwords must be changed on
a regular basis.
The view over a database link makes it impossible for the developers of the middle-tier application to
reference the database link directly.
The grantees to the views get privileges only to the views, even if the link offers more. Access of the
views can be audited easily.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 14
Restricting a Database Link with Views
Restricting a Database Link with Views (continued)

Example:
In this example, the HR user creates a database link and a view, and then grants privileges on the
view to the HR_MGR role. Anyone with the role can change the EMPLOYEES table but not any
other table in the HR schema, nor can they access the remote HR schema through the database
link except through the view.
CONNECT HR
CREATE DATABASE LINK hrviewlink
CONNECT TO hr IDENTIFIED BY oracle_1 USING 'p0orcl';
CREATE OR REPLACE VIEW employees_vw
AS SELECT * FROM employees@hrviewlink;
GRANT select, insert, update, delete on EMPLOYEES_VW to HR_MGR;
See the dblink_view.sql demonstration script in the /home/oracle/demos directory.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 15
PASSWORD:****

Authenticate users with passwords
Protect passwords
Authenticate users with the OS
Protect database link passwords
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 16
Summary

Implementing an OS-authenticated user connecting locally
without a password
Observing the stored password for a fixed database link
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
6 - 17
Using Basic Authentication Methods

Objectives
Certificates
Kerberos
Remote authentication dial-in service (RADIUS)
Describe a setup for strong authentication that uses:

Certificates
Kerberos
Key Distribution Center (KDC)
Implement the secure external password store

following:
Describe strong authentication that uses:
User Authentication

User Authentication
User authentication is a basic security requirement. The users identity must be confirmed before
granting privileges and access rights. Auditing of user actions on data is essential, and user
authentication is the first step to having a valid audit trail of user actions on the data.
Authentication methods can be classified as:
Something you know (password)
Something you are (biometric)
Something you have (smart card)
Strong user authentication is a way of confirming the identity of the user with something other
than a password. Smart cards, biometrics, certificates, and Kerberos tokens provide strong user
authentication. Some of these methods are known as two-factor or multifactor authentication.
Two-factor authentication requires something that the user knows plus something that the user
has. Several of the strong authentication options use centralized authentication, which gives you
high confidence in the identity of users, clients, and servers in distributed environments. These
centralized servers may also include single sign-on.

Strong authentication:
Is stronger than password authentication
Often includes the single sign-on functionality
Is supported by the following authentication technologies:
Certificates, public key infrastructure (PKI)
RADIUS, token, and smart cards
Kerberos
Integrates with Oracle Net Services

Requires Oracle Advanced Security
Strong User Authentication

Certificates
Certificates are digital documents that are used to provide proof of identity. Certificates can use
PKI or a Web of trust to authenticate a user or a machine. They are used in one-way
authentication to authenticate a server to a user and in two-way authentication that additionally
authenticates the user to the server. The process for exchanging certificates is based on TCP for
the secure sockets layer (SSL)enabled protocol called TCPS. SSL has been superceded by
Transport Layer Security (TLS), but is still referred to as SSL. The certificates require the use of
the SSL libraries that are available with Oracle Advanced Security.
Authentication Adapters
Support for authentication services is provided through authentication adapters, which are very
much like the existing Oracle Net protocol adapters. Authentication adapters integrate below the
Oracle Net interface so that existing applications can take advantage of new authentication
systems transparently, without any changes to the application. These adapters are available when
you install Oracle Advanced Security.
Strong User Authentication
Remote Authentication Dial-In User Service (RADIUS) is a flexible, lightweight protocol that
provides authentication, authorization, accounting, and centralized user information.
RADIUS provides two major benefits:
It enables support for authentication technologies, including token cards, smart cards, and
challenge-response.
It readily integrates into existing systems by making the Oracle database a RADIUS client,
thus capitalizing on the infrastructure and investment that organizations have already
made.
Supported RADIUS Services
With RADIUS, you can choose virtually any mechanism available to authenticate network users.
Many token and smart card manufacturers support RADIUS. Any RADIUS-compliant device
can integrate with Oracle Advanced Security to authenticate database users with little
modification required by the authentication provider. Because many organizations have
implemented RADIUS for remote access to their networks, the Oracle server easily integrates
into existing systems and takes advantage of the investments that an organization has already
made.
Kerberos Adapters
Kerberos is a trusted third-party authentication system that relies on shared secrets. It assumes
that the third party is secure. It provides the following:
Single sign-on capabilities
Centralized password storage
Database-link authentication
Enhanced PC security
Two adapters for the Kerberos authentication service are provided with Oracle Advanced
Security:
Kerberos Authentication Adapter (essentially a Kerberos client) is available with Oracle
Advanced Security. The Kerberos server can be obtained from third-party vendors. The
Massachusetts Institute of Technology Key Distribution Center (MIT KDC) is an open
source.
Microsoft provides a slightly different version of KDC that works with Active Directory on
the Windows servers. The Windows and UNIX versions of Kerberos are interoperable.
Entrust/PKI
Oracle Advanced Security supports the public key infrastructure provided by the Entrust/PKI
software from Entrust. Entrust-enabled Oracle Advanced Security enables Entrust users to
incorporate Entrust single sign-on into their Oracle applications, and it enables Oracle database
users to incorporate Entrust-based single sign-on into Oracle applications.
Strong User Authentication (continued)

RADIUS Authentication
Single Sign-On
Single sign-on is a centralized authentication service.
The user has a single username and password.
Servers authenticate users through the central service.
Client
Authentication server
Server
Single Sign-On
Confidence in the identity of users and hosts can be achieved by using a centralized, secure
authentication service rather than relying on hosts and users identifying themselves to one
another directly. Single sign-on is a centralized authentication service that allows users to access
multiple services with a single login. Network authentication services, such as certificates, also
can provide the benefit of single sign-on for users. Oracle Application Server Single Sign-On
requires the Oracle Advanced Security option.
When a central authentication service is not available, users generally respond to multiple
accounts in one of the following ways:
The users may set the same passwords on all machines (which results in a potentially large
exposure in the event of a compromised password).
The users may just write the passwords down or forget them, either of which severely
compromises password secrecy and service availability.
To avoid these behaviors, provide a single sign-on or a centralized authentication server so that
users can access multiple accounts and applications with a single password. The need for
multiple passwords for users is eliminated and management of user accounts and passwords is
simplified for system administrators.
Public Key Infrastructure (PKI) Tools
Oracle wallet
Oracle Identity Management Infrastructure
Management tools:
Oracle Wallet Manager
Public Key Infrastructure (PKI) Tools

The authentication systems based on the Public-Key Cryptography Standards (PKCS) issue
digital certificates to users. The certificates are used to authenticate users directly to servers in
the enterprise without the direct involvement of an authentication server. Oracle Database 11g
provides PKI tools for using public keys and certificates. Some of its features and tools are as
follows:
Oracle wallet is a data structure used to store and manage security credentials for an
individual entity. These credentials can be passwords or certificates.
Oracle Wallet Manager is an application that is used to manage and edit the security
credentials in Oracle wallets. Oracle wallets are data structures that contain a user private
key, a user certificate, and a set of trust points (the list of root certificates that the user
trusts). Oracle Wallet Manager uses the Public-Key Cryptography Standards (PKCS) #12
specification for the wallet format, and PKCS #10 for certificate requests.
Integration with Entrust PKI provides full-certificate life-cycle management and certificate
revocation list (CRL) checking.
An Oracle Database environment supports hardware devices by providing APIs that
conform to the RSA Security, Inc., PKCS #11 specification.
The Oracle Database PKI implementation includes:

Components:
Certificates
Certificates:
Are digital documents
Provide proof of identity
Are stored in Oracle Wallets
Certificate authority:
Is a trusted organization (trust point)
Attests the identity of the certificate
Issues trusted certificates X.509 v3
Certificate use:
Requires a secure sockets layer (SSL)
Requires a level of trust in the signing authority
Certificates
Certificates are digital documents that are used to provide proof of identity. For example,
a certificate from a banks URL convinces bank customers that they have connected to the bank
and not a spoofed site that is designed to collect their account numbers. When used in a PKI,
each certificate includes an issuing certificate authority (CA). The CA asserts that it is a valid
certificate.
The CA is also known as a trust point and is hierarchical. If George connects to a Web site that
presents a certificate signed by a CA that George does not recognize, he can check the signer of
the CA certificate and so on. The certificate contains identity credentials: name, public key,
expiration time, and a URL of a signing authority. Each signing authority provides a certificate
of another signing authority at a higher level. This chain of certificates repeats to a self-signed
root certificate provided by one of the root certificate authorities such as Verisign. This chain of
trust is the PKI.
For SSL sessions, certificates are exchanged, and the public keys are used to pass a shared key.
Then the much faster symmetric encryption algorithms are used for the session messages.
Certificates may be used between a client and a server without any centralized server. Note that
only the client and the server are involved in the authentication after the certificates have been
issued.
How to Use Certificates for Authentication
listener.ora
sqlnet.ora
4. Configure the client for SSL.

5. Configure the client-side Oracle Net files:
sqlnet.ora
tnsnames.ora
6. Create a user that is authenticated with a certificate.

7. Connect to the database.
How to Use Certificates for Authentication

1. Install the required components. You must install Oracle Advanced Security. Oracle
Advanced Security provides the SSL libraries and tools for managing certificates.
Enterprise Identity Management, though not required for SSL, provides Oracle Internet
Directory (OID), directory management tools, and Oracle Application Server Single SignOn.
2. Configure the server for SSL. Use Oracle Wallet Manager to configure a wallet for the
node. The same steps are required for both the server and client wallets.
3. Configure the server-side Oracle Net files. Use Net Manager to configure the Oracle Net
files to use SSL.
4. Configure the client for SSL. Use Oracle Wallet Manager to configure a wallet for the
user. The same steps are required for both the server and client wallets.
5. Configure the client-side Oracle Net files. Use Net Manager.
6. Create a user that is authenticated with a certificate. Use the distinguished name.
7. Connect to the database. The connect string that named the SSL listener port and the
distinguished name of the server authenticates a user by using only the certificate. The
Oracle Database server checks the directory by using the user-distinguished name for the
user authorizations.
1. Install the required components.

2. Configure the server for SSL.
3. Configure the server-side Oracle Net files:
Configuring SSL on the Server

To obtain a certificate for the server database instance, you must generate a certificate request
and send the request to a CA. You must import the certificates that you receive into the wallet.
Oracle Wallet Manager is used to create the wallet, generate the request, and import the
certificates into the wallet. The user certificate refers to a certificate that matches the certificate
requestin this case, a database. The certificates returned by the CA are the trusted certificate
and the user certificate. The trusted certificate must be imported first. It is important that the
distinguished name (DN) on the user certificate be the same as the database service name.
The wallet can be stored in the systems default location, in a specified directory, or in the
Windows registry. The wallet has a password. The Oracle Wallet Manager auto login feature
creates an obfuscated copy of the wallet. File system permissions provide the necessary security
for auto login wallets. When auto login is enabled for a wallet, it is available only to the
operating system user who created that wallet.
You must enable auto login if you want single sign-on access to multiple Oracle databases,
which is disabled by default. Sometimes, these wallets are called SSO wallets because they
provide the single sign-on capability.
Note: For troubleshooting the SSL configuration, refer to My Oracle Support Note 166492.1,
Oracle Advanced Security SSL Troubleshooting Guide.
Configuring SSL on the Server
Configuring Oracle Net Files on the Server

Setting the Wallet Location
To set up the configuration files for Oracle Net services, set the wallet location in both the
listener.ora and sqlnet.ora files:
WALLET_LOCATION =
(SOURCE= (METHOD=File)
(METHOD_DATA= (DIRECTORY=<wallet_location>)))
where <wallet_location> is the name of the directory holding the wallet.

In the listener.ora file, set the listener to listen on an end point for the TCPS protocol. The
recommended port is 2484:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)
(HOST = <server_name>)
(PORT = 2484))
)
)
Configuring Oracle Net Files on the Server
Configuring SSL on the Client

This process is almost identical to configuring SSL on the server. On the server, the certificate
request is for the server machine or database. On the client, the certificate request is for a user
and is requested with the DN of that user. The DN of the user is used to query the directory to
obtain the user authorizations.
Configuring SSL on the Client
On the client, specify:

The servers distinguished name
The TCPS protocol listener port
The client wallet location
Configuring Oracle Net Files on the Client

On the client:
In the sqlnet.ora file:
Specify the wallet location
Set SSL_CLIENT AUTHENTICATION to TRUE to require the client to use SSL
authentication
Set SSL_SERVER_DN_MATCH to ON to require the server service name to match the
distinguished name.
wallet_location =
(SOURCE=
(METHOD=File)
(METHOD_DATA=
(DIRECTORY=<wallet_location>)))
SSL_CLIENT_AUTHENTICATION =TRUE
SSL_SERVER_DN_MATCH=(ON)
where <wallet_location> is the name of the directory holding the wallet.

SSL_SERVER_DN_MATCH=ON requires that the DN of the server match the service name
listed in the tnsnames.ora entry.
Configuring Oracle Net Files on the Client
SSL_ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)
(HOST = edrsr24p1)
(PORT = 2484))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl.us.oracle.com)
)
)
Configuring Oracle Net Files on the Client (continued)

Set an entry in the tnsnames.ora file to reference the port for the TCPS protocol:
Creating a User Identified

by a Certificate
When you create a global user, you can specify the X.509
name that identifies this user at the enterprise directory
server:
CREATE USER global_user1

IDENTIFIED GLOBALLY AS
'CN=analyst, OU=division1, O=oracle, C=US';
You can create a shared schema that allows any user

identified to the directory and mapped to the schema to
connect to the schema:
CREATE USER global_user2

IDENTIFIED GLOBALLY AS '';
Creating a User Identified by a Certificate

A user identified by a certificate can connect to the database in two different ways. The first way
is a user that has a one-to-one user-schema mapping in the directory. Roles can be assigned
directly to this user, or a mapping object can be stored in the directory that maps the user to a
global role defined in the database. This method requires that the user be created in every
database where the end user requires access. The following command creates a database user
identified by a distinguished name:
CREATE USER global_user1 IDENTIFIED GLOBALLY AS
'CN=analyst,OU=division1, O=oracle, C=US';
The second way creates a shared schema. Any user identified to the directory can be mapped to
the shared schema in the database. The mapped user will be authenticated by the directory and
the schema mapping will provide the privileges. The following command creates the shared
schema:
CREATE USER global_user2 IDENTIFIED GLOBALLY AS '';
No one connects directly to the GLOBAL_USER2 schema. Any user that is mapped to the
GLOBAL_USER2 schema in the directory can connect to this schema.
Detailed information about mapping a user to a global schema is presented in the lesson titled
Using Enterprise User Security.
Connecting to the Database
CONNECT /@SSL_ORCL;
Connecting to the Database

The user that owns the client wallet may connect to the database without a password as shown in
the slide.
1. The wallet is accessed and the certificate information is passed to the server.
2. The server certificate information is passed to the client. All this information is passed as
encrypted text.
3. The user authorizations, such as roles, are retrieved from Oracle Internet Directory. Using
the user DN created in the previous slide as an example, the certificate for this user has a
DN of CN=analyst,OU=division1,O=oracle,C=US to connect as the
global_user1 user.
An application server can use this method to connect and establish the connection pool without
having to code a password in the application. The application server (application user) creating
the connection pool is identified by a certificate.
The user that owns the client wallet may connect to the
database as shown in the following example:
Quiz
c. Oracle Internet Directory

d. Oracle wallet
Answer: c, d
In which of the following do you store certificates?

a. listener.ora file
b. sqlnet.ora file
orapki is a command-line utility for scripting common PKI

management tasks. It can be used for:
Creating and viewing signed certificates for testing
purposes
Creating and displaying Oracle wallets
Managing Oracle wallets
Renaming CRLs with a hash value for certificate validation
orapki Utility
orapki is a command-line utility for managing PKI elements, such as wallets and certificate
revocation lists. The orapki utility allows the DBA to script the management of PKI elements,
making it possible to automate many of the routine tasks of maintaining a PKI. This commandline utility can be used to perform the following tasks:
Creating and viewing signed certificates for testing purposes
Creating and displaying Oracle wallets:
- Adding and removing certificate requests
- Adding and removing certificates
- Adding and removing trusted certificates
- Managing certificate revocation lists (CRLs)
Managing Oracle wallets
Renaming CRLs with a hash value for certificate validation:
- Uploading, listing, viewing, and deleting CRLs in Oracle Internet Directory
orapki Utility
1. Install Kerberos.
2. Configure a service principal for the Oracle Database
server.
3. Extract a service key table from Kerberos.
4. Install an Oracle Database server and a client.
5. Install Oracle components.
6. Configure Oracle Net Services and Oracle Database.
7. Configure Kerberos authentication.
8. Create a Kerberos user.
9. Create an externally authenticated Oracle user.
10. Get an initial ticket for the Kerberos and Oracle user.
How to Use Kerberos for Authentication

To use Kerberos authentication, you must perform the following steps: (Additional details are
available in the Oracle Database Advanced Security Administrators Guide.)
1. Install Kerberos: Install it on the machine that functions as the authentication server.
2. Configure a service principal for an Oracle Database server: Create a name in
Kerberos to identify the Oracle database. This name has the following format:
kservice/kinstance@REALM
kservice is a case-sensitive string. It may be the same as the database service name.
kinstance is typically the fully qualified name of the system on which the Oracle
database is running.
REALM is the domain name of the database server. REALM must always be in uppercase
and is typically the DNS domain name.
Example: orcl/testp1.us.acme.com@US.ACME.COM
How to Use Kerberos for Authentication
SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=kservice
8. Create a Kerberos user: To create Oracle users that Kerberos can authenticate,
perform this task on the Kerberos authentication server where the administration tools
are installed. The realm must already exist. On UNIX, run
/krb5/admin/kadmin.local as root to create a new Kerberos user, such as
krbuser:
# ./kadmin.local
kadmin.local: addprinc krbuser
Enter password for principal: "krbuser@SOMECO.COM":
(password does not display)
Re-enter password for principal: "krbuser@SOMECO.COM":
(password does not display)
kadmin.local: exit
9. Create an externally authenticated Oracle user.

SQL> CONNECT / AS SYSDBA;
SQL> CREATE USER "KRBUSER@SOMECO.COM" IDENTIFIED
EXTERNALLY;
SQL> GRANT CREATE SESSION TO "KRBUSER@SOMECO.COM";
10. Get an initial ticket for the Kerberos and Oracle user: In Kerberos authentication,
an initial ticket or ticket granting ticket (TGT) identifies the user as having the right to
ask for additional service tickets. No tickets can be obtained without an initial ticket.
An initial ticket is retrieved by running the okinit program and providing a
password. Before you can connect to the database, you must ask the Key Distribution
Center (KDC) for an initial ticket. To do so, run the following on the client:
$ okinit username
At this point, the krbuser user can connect to any database with a kservice name
and krbuser defined with the string:
$ sqlplus /@orcl
How to Use Kerberos for Authentication (continued)

3. Extract a service key table from Kerberos: In Kerberos authentication, a service key
table is a list of service principals that exist on kinstance. This information must be
extracted from Kerberos and copied to the database server before Kerberos can be used
by the Oracle instance.
4. Install an Oracle Database server and an Oracle client.
5. Install Oracle components: The components are Oracle Net Services and Oracle
Advanced Security.
6. Configure Oracle Net Services and Oracle Database.
7. Configure Kerberos authentication: Use Oracle Net Manager to configure the
Kerberos authentication service parameters on the client and on the database server.
Set the Kerberos method for authentication and provide the Kerberos service name.
The sqlnet.ora file parameters to define Kerberos authentication are as follows:
1. Configure an Oracle Kerberos client to interoperate with a

Windows 2000 domain controller KDC.
2. Configure a Windows 2000 domain controller KDC to
interoperate with an Oracle client.
3. Configure an Oracle database to interoperate with a
Windows 2000 domain controller KDC.
How to Use KDC with Windows 2000 for Authentication

Windows 2000 Server includes a version of Kerberos called KDC that configures Kerberos to
operate with Windows 2000 domain controllers. This is a high-level overview of the
configuration process. For details, see the Oracle Database Advanced Security Administrators
Guide.
1. Configure the Oracle Kerberos client to interoperate with a Windows 2000 domain
controller KDC.
On the computers that use the Oracle client, perform the following steps:
a. Create the Kerberos client configuration files: krb.conf, krb5.conf, and
krb5.realms.
b. Specify the Oracle Net configuration parameters in the sqlnet.ora file. These
may be specified with Net Manager.
c. For UNIX clients, specify the listening port number. Set the port number in the
/etc/services file to UDP/TCP port 88.
How to Use KDC with Windows 2000

for Authentication
$ sqlplus /@orcl
How to Use KDC with Windows 2000 for Authentication (continued)

2. Configure a Windows 2000 domain controller KDC to interoperate with an
Oracle client.
Perform the following steps on the Windows 2000 domain controller:
a. Create a new user for the Oracle client in Microsoft Active Directory. This is the
name of the Kerberos user that connects to the database.
b. Create a new user for the Oracle database in Microsoft Active Directory. For
example, if the Oracle database runs on the host sales3854.us.acme.com,
use Active Directory to create a user with the username
sales3854.us.acme.com and the password oracle.
c. Use the Ktpass command-line utility to extract the keytab file.
d. Copy the extracted keytab file to the host computer where the Oracle database
is installed.
3. Configure an Oracle database to interoperate with a Windows 2000 domain
controller KDC.
On the computer hosting the Oracle database, perform the following steps:
a. Set the sqlnet.ora parameters.
b. Create an externally identified user. Ensure that the username is created in all
uppercase characters. For example, ORAKRB@SALES.US.ACME.COM.
In Kerberos authentication, an initial ticket or TGT identifies the user as having the
right to ask for additional service tickets. No tickets can be obtained without an initial
ticket.
With Active Directory, do not use okinit. Instead, use the Windows in-memory
credential cache by setting SQLNET.KERBEROS5_CC_NAME=OSMSFT://.
At this point, the Kerberos user can connect to the database configured in step 3 with
the following string:
RADIUS is a protocol for remote authentication and

access.
You may use any authentication method that supports the
RADIUS standard.
You may change authentication methods without changing
the database or client configuration.
The user is defined in the database as IDENTIFIED
EXTERNALLY.
RADIUS Authentication: Overview

RADIUS is a client/server security protocol that is widely used to enable remote authentication
and access. Oracle Advanced Security uses this industry standard in a client/server network
environment. You can enable the network to use any authentication method that supports the
RADIUS standard, including token cards and smart cards, by installing and configuring the
RADIUS protocol. Moreover, when you use RADIUS, you can change the authentication
method without modifying either the Oracle client or the Oracle database server. For details
about enabling RADIUS authentication, see the Oracle Database Advanced Security
Administrators Guide.
From the users perspective, the entire authentication process is transparent. When the user seeks
access to an Oracle database server, the Oracle database server (acting as the RADIUS client)
notifies the RADIUS server. The RADIUS server:
Looks up the users security information
Passes authentication and authorization information between the appropriate authentication
server or servers and the Oracle database server
Grants the user access to the Oracle database server
Logs session information, including when, how often, and for how long the user is
connected to the Oracle database server
RADIUS Authentication: Overview
Secure External Password Store
vkrama/?????@DEV
RAMA
CONNECT /@DEV
ramav/????@prod_db.acme.com
PROD
Secure External Password Store

The password store is an Oracle wallet created to provide a secure method of storing user login
passwords. By default, this is an auto login wallet, so a password is not needed to open the
wallet. The OS authenticates the user, and file system permissions control access to the wallet.
The credentials to access the database are extracted from the wallet for the user. In the example,
the OS user, Rama, owns a wallet that holds different passwords for each database. With this
feature, Rama may connect with CONNECT /@DEV or CONNECT /@prod_db.acme.com.
The username and password are stored in the wallet and retrieved based on the connect string.
The connect string can be a tnsnames.ora file entry as shown for DEV, a hostname to be
resolved with DNS, or a hostname:port:sid string such as dlsun1:1521:dev.
This feature (which does not require Oracle Advanced Security) provides a secure way to run
applications or command files without embedding the password in OS files. An application
server can use this method to connect and establish the connection pool without requiring a
password in the application.
Note: The wallet for the external password store is managed with the mkstore utility. The PKI
Wallet managed by Oracle Wallet Manager is intended for use by the database. If the user that
owns the database wallet wants to also use the external password store, the mkstore utility
must be used to configure the external password store. The external password store uses a
separate section of the database wallet.
DEV
Configuring the Wallet

Use the mkstore command:
Create the wallet:
mkstore -wrl $HOME/admin/orcl/wallets -create
Add credentials to the wallet:
mkstore -wrl $HOME/admin/orcl/wallets

-createCredential dev hr [hr]
Note: User password is not required on the command line; the

command-line input must be on one line.
Configuring the Wallet

If the wallet does not exist, create the client wallet:
mkstore -wrl <wallet_location> -create
<wallet_location> is the path to the directory where you want to create and store
the wallet. This command creates an Oracle wallet with the auto login feature enabled at
the location you specify. When auto login is enabled for a wallet, only the operating
system user who created it can manage it.
$ mkstore -wrl $ORACLE_BASE/admin/wallet -create
Enter password: <wallet_password>
Enter password again: <wallet_password>
Add the database connection credentials to the wallet using:

$ mkstore -wrl <wallet_location> -createCredential
<db_connect_string> <username> [<password>]
where <db_connect_string> is a TNS alias or any service name used to connect to

the database. The service name specified in the mkstore command and the service name
used to connect to the database (in connect /@<db_connect_string>) must be
identical.
$ mkstore -wrl $ORACLE_BASE/admin/wallet -createCredential hr_orcl hr
hr
Enter password: <wallet_password>
Create credential oracle.security.client.connect_string1
Configuring sqlnet.ora
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY =
/home/rama/admin/orcl/wallet)))
SQLNET.WALLET_OVERRIDE = TRUE
Configuring sqlnet.ora
The sqlnet.ora file has three parameters for configuring the secure external password store:
WALLET_LOCATION, SQLNET.WALLET_OVERRIDE, and
SQLNET.AUTHENTICATION.SERVICES.
WALLET_LOCATION points to the directory where the wallet resides; this parameter exists in
earlier versions.
Set the SQLNET.WALLET_OVERRIDE parameter to TRUE. This setting causes all CONNECT
/@db_connect_string statements to use the information in the wallet at the specified
location to authenticate to databases.
If an application uses SSL for encryption, the sqlnet.ora parameter,
SQLNET.AUTHENTICATION_SERVICES, specifies SSL and an SSL wallet is created. If this
application wants to use secret store credentials to authenticate to databases (instead of the SSL
certificate), those credentials must be stored in the SSL wallet. If
SQLNET.WALLET_OVERRIDE = TRUE, the usernames and passwords from the wallet are
used to authenticate to databases. If SQLNET.WALLET_OVERRIDE = FALSE, the SSL
certificate is used.
For more information, refer to Oracle Database Net Services Reference 11g.
Set the following in sqlnet.ora:

WALLET_LOCATION
SQLNET.WALLET_OVERRIDE
Managing the External Password Store
List the contents of the external password store

Add database login credentials to an existing client wallet
Modify database login credentials that are stored in the
wallet
Delete database login credentials
Managing the External Password Store

To list the contents of the external password store, enter the following command at the command
line:
mkstore -wrl <wallet_location> -listCredential
To add database login credentials to an existing client wallet, enter the following command:
mkstore -wrl <wallet_location> \
-createCredential <db_alias> <username> <password>
You can store multiple credentials in one client wallet. For example, if a client batch job
connects to hr_database and a script connects to sales_database, you can store the
login credentials in the same client wallet. Each set of credentials requires a separate
<db_alias>.
If usernames or passwords change, you can modify the database login credentials that are stored
in the wallet. To modify database login credentials, enter the following command:
mkstore -wrl <wallet_location> \
-modifyCredential <dbase_alias> <username> <password>
To delete database login credentials, enter the following command:

mkstore -wrl <wallet_location> -deleteCredential <db_alias>
Use the mkstore command to:
Summary
Certificates
Kerberos
RADIUS
Describe a setup for strong authentication that uses:

Certificates
Kerberos
Key Distribution Center (KDC)
Implement an external secure password store

Describe strong authentication that uses:

Configuring the external secure password store
Implementing a user connecting remotely without a
password
Viewing the contents of the wallet
Configuring the External Secure Password Store


following:
Describe Enterprise User Security
Set up Enterprise User Security
Create an enterprise user
Use shared schemas
Audit enterprise users
Migrate users from the database to Oracle Internet
Directory (OID)
Objectives
This lesson describes the basic components of Enterprise User Security. It shows the architecture
of this feature and describes the installation process. The components required to create and
manage an enterprise user are discussed. In addition, the lesson explains the techniques for using
the enterprise user in the context of the database server and integrating the enterprise user with
familiar security policies and auditing.
Objectives
User Authentication

User Authentication
A basic security requirement is that you must know your users. You must identify them before
you can determine their privileges and access rights, so that you can audit their actions on the
data. In this lesson, you create and audit enterprise users authenticated through Oracle Internet
Directory.

Enterprise User Security stores user credentials and

authorizations in a central location (LDAP-compliant
directory such as Oracle Internet Directory).
It eases administration through centralization.
It enables single-point authentication.
It eliminates the need for client-side wallets.
Example:
User changes job roles.
Security administrator changes the user roles in Oracle
Internet Directory.
No changes are made to the services that the user
accesses.

Enterprise User Security addresses the user, the administrative, and the security challenges by
centralizing storage and management of user-related information in a Lightweight Directory
Access Protocol (LDAP)compliant directory service.
When an employee changes jobs in such an environment, the administrator needs to modify
information only in one location (the directory) to make effective changes in multiple databases
and systems. This centralization can substantially lower administrative costs while materially
improving enterprise security.
Enterprise User Security requires the installation of Oracle Identity Management infrastructure.
Oracle Identity Management Infrastructure:

Default Deployment
SSO
DAS
OCA
Oracle
Internet
Directory
Server
Identity
Management
Infrastructure
Database
Oracle Identity Management Infrastructure: Default Deployment

A default installation of the Oracle Application Server infrastructure consists of installing all
infrastructure components on the same system, including OracleAS Single Sign-On (SSO),
Oracle Application Server Certificate Authority (OCA), and Oracle Delegated Administration
Services (DAS). This deployment is simple, and it automatically configures SSO, OCA, and
DAS as part of the repository and Oracle Internet Directory (OID). This deployment is adequate
for setting up a quick development or testing environment.
This deployment is all that is required for Enterprise User Security. The Oracle HTTP Server,
OracleAS Containers for J2EE (OC4J), and Oracle Enterprise Manager components are always
installed.
sso.mydomain.com
Oracle Database: Enterprise User

Security Architecture
OracleAS
Metadata
Repository
OID
Client
Verifies the user

Applies roles
Username and password
Oracle DB
Oracle Database: Enterprise User Security Architecture

The Enterprise User Security architecture is transparent to the end user. In the example shown in
the slide, a client can submit the same connect command, whether connecting as a database user
or an enterprise user. The enterprise user has the additional benefit of allowing the use of a
shared schema.
The authentication process is as follows:
1. The user presents a username and password (or other credentials).
2. The directory returns the authorization token to the database.
3. The schema is mapped from OID information.
4. The directory supplies the global roles for the user. Enterprise roles are defined in OID and
global roles are defined in the database. The mapping from enterprise roles to global roles
is in the directory.
5. The directory can supply the application context. An application context supplied from
OID is called a global context.
Enterprise User Security supports the following authentication

methods:
Password authentication
Secure sockets layer (SSL) authentication
Kerberos authentication
Authenticating Enterprise Users

Enterprise User Security supports three authentication methods. Each authentication method has
advantages and disadvantages. These determine which authentication method is best for your
Enterprise User Security implementation. Configuring password authentication is described in
this lesson. Configuration details for the other methods can be found in the Oracle Database
Advanced Security Administrators Guide.
All three methods provide:
Centralized user and credential management
A user identity that can be used in two-tier or multitier applications
The methods to support current user database links if the connection between databases is
over the secure sockets layer (SSL)
Password authentication:
Is password-based authentication
Requires separate authentication for each database connection
Retains users current authentication methods
Supports Oracle Release 7.3 (and later) clients with Oracle Database 10g and later
Authenticating Enterprise Users
Initial configuration may be more difficult because public key infrastructure (PKI)
credentials must be generated for all users. (The degree of difficulty depends on
administrators PKI knowledge.)
Kerberos authentication:
Provides strong authentication by using Kerberos (version 5) tickets
Supports single sign-on by using Kerberos (version 5) encrypted tickets and
authenticators, and authentication forwarding
Supports Oracle Database 10g (and later) clients with Oracle Database 10g and later
Initial configuration may be more difficult because Kerberos must be installed and
configured to authenticate database users.
Authenticating Enterprise Users (continued)

SSL authentication:
Provides strong authentication over SSL
Supports single sign-on by using SSL
Supports Oracle8i (and later) clients with Oracle Database 10g and later
OID Structure Overview
dc=oracle
dc=us
cn=users
cn=groups
cn=oracle context
cn=orcladmin
OID Structure Overview

The structure of Oracle Internet Directory is a tree structure following the LDAP standards. Each
level is a called a realm.
There is an orcladmin defined at the highest level (not shown) that is the administrator of the
entire structure.
The cn=orcladmin,cn=users,dc=us,dc=oracle,dc=com (shown at the lower left)
is the administrator that is used to manage the us.oracle.com realm.
dc=com
Enterprise User Security does not require Oracle Internet

Directory when other LDAP-compliant directory services are
used to define enterprise users.
a. True
b. False
Answer: b
Quiz
Setting Up Enterprise User Security
Setting Up Enterprise User Security

In the following slides, the steps required to set up Enterprise User Security are described.
1. Install Oracle Application Server Infrastructure.

2. Register the database.
Installing Oracle Application Server Infrastructure

OID must be installed to use Enterprise User Security. OID requires a metadata repository in an
Oracle database. The simplest way to meet these requirements is to use the default installation of
Oracle Application Server Infrastructure with a metadata repository from Oracle Universal
Installer.
Installing Oracle Application Server Infrastructure
Registering the Database

The database must be configured to use LDAP. The first choice is to use Domain Name Services
(DNS) to perform automatic domain name lookup to locate the directory on your network. The
network administrator must have entered a DNS Service Location Record (SRV) into the
domain name server.
The database administrator (DBA) can use Oracle Net Configuration Assistant to create an
ldap.ora file for your ORACLE_HOME. This configuration file specifies the directory host
and port information, and the name of the identity management realm so that the database can
connect to the directory. This step is required if you are not using automatic domain name
lookup.
Use the Database Configuration Assistant (DBCA) to register the database in the directory.
Registration creates an entry in the directory so that the database can bind or log in to it. The
DBCA performs several configuration tasks, including creating a wallet for the database and
assigning a password for the wallet.
Registering the Database
Managing Enterprise User Security

In Oracle Database 11g, Enterprise Manager Database Control has pages to help you manage the
Enterprise User Security. On the database home page, click the Server tab to view these pages in
the Security section.
Managing Enterprise User Security
Creating an Enterprise User

There are two types of enterprise users:
An enterprise user with a schema is identified in the
database as a global user.
An enterprise user sharing an application schema is not
identified in the database. The shared schema is identified
globally.
Both of the following statements create a global user:
CREATE USER scott IDENTIFIED GLOBALLY AS

'cn=scott,cn=users,dc=us,dc=oracle,dc=com';
CREATE USER appschema IDENTIFIED GLOBALLY;
Creating an Enterprise User

Enterprise users are created and managed in the directory. Enterprise users are mapped to either
a single schema or a shared schema that is identified in the database as a global user.
Creating a global user who is authenticated by a password and authorized by the enterprise
directory service is illustrated by the following statement:
CREATE USER scott IDENTIFIED GLOBALLY AS
'cn=scott,cn=users,dc=us,dc=oracle=dc=com';
Exclusive schema example

In this case, assume SCOTT is a schema in the database mapped to a single enterprise user,
cn=scott,cn=users,dc=us,dc=oracle=dc=com. The SCOTT enterprise user must
be created in the directory, and a global user SCOTT must be created in every database that the
enterprise user SCOTT accesses.
Shared schema example
The application schema is created in the database, as shown in the slide. The directory maps one
or more enterprise users to this shared schema. A shared schema allows multiple enterprise users
to access a single schema in the database. This type of enterprise user:
Is authenticated by SSL, Kerberos, or passwords
Is created only in the directory
Connects to a shared schema
Creating an Enterprise User in the Directory

You can create enterprise users in the directory by using the Oracle Identity Management
Provisioning console. This function resides in the Oracle Internet Directory Self Service
Console.
Create an Enterprise User:
1. Use the URL, http://<oidhost>:<port>/oiddas, to access the Self Service Console page. The
default port is 7777.
2. Log in and enter user credentials of a user that has privileges to create users, such as
orcladmin.
3. On the Self Service Console page, click Directory.
4. On the Users page, click Create.
5. On the Create User page, enter the basic information and click Submit.
In the example in the slide, the user Scott Taylor is created. He has a user ID of staylor. This
is the name Scott will use when he attempts to connect. His distinguished name (DN) is
cn=Scott Taylor, cn=users, dc=us, dc=oracle, dc=com because of the user
creation base that was set in the directory configuration.
Creating an Enterprise User in the Directory
Creating a Schema Mapping Object in the Directory: Subtree

You can create multiple enterprise users and a mapping object in the directory. The mapping
object informs the database about how you want to map the DN of the users to the shared
schema. Either you can do a full DN mapping (one enterprise user to one DB schema) or you
can do a subtree mappingfor example, every user containing the following DN components:
dc=us,dc=oracle,dc=com to appschema.
Create a Shared Schema Mapping (subtree):
The Create Mappings page is shown in the slide. To create a subtree mapping, perform the
following steps:
1. On the Enterprise User Security page of Enterprise Manager Database Control, click
Manage Databases.
2. On the Manage Databases page, select the database and click Configure.
3. On the Configure Database page, click the User-Schema Mappings tab.
4. On the User-Schema Mappings tab page, click Create
5. Select Subtree and enter the subtree DN. Enter the global schema to which users in this
subtree will map.
Most users do not need their own schemas, and implementing shared schemas divorces users
from databases. Create one or many enterprise users in the directory. Then, those users can
access the shared schema in any database where the schema mapping exists.
Creating a Schema Mapping Object

in the Directory: Subtree
Creating a Schema Mapping Object in the Directory: User Name

When a user needs a dedicated schema, this is the method for making a one-to-one mapping.
Create a Shared Schema Mapping (User Name):
The Create Mappings page is shown in the slide. To create a subtree mapping, perform the
following steps:
1. On the Enterprise User Security page of Enterprise Manager Database Control, click
Manage Enterprise Users.
2. On the Manage Enterprise Users page, select the user and click Configure.
3. On the Configure User page, click the User-Schema Mappings tab.
4. On the User-Schema Mappings tabbed page, click Create.
5. Select User Name. Enter the global schema to which users in this subtree will map.
This can be a useful technique to move database users, who each currently have his or her own
schema in the database, to enterprise users.
1. Migrate the database users to the directory. (See the topic titled User Migration Utility in
this lesson.)
2. Alter each schema to be identified globally.
3. Create a mapping for each user to his or her database schema.
Creating a Schema Mapping Object

in the Directory: User Name
Identifying the Enterprise User
SELECT user FROM dual;
Show the real user:
select sys_context ('userenv' , 'external_name')

from dual;
SYS_CONTEXT('USERENV','EXTERNAL_NAME')
--------------------------------------------cn=Scott Taylor,cn=Users,dc=us,dc=oracle,dc=com
Identifying the Enterprise User

The enterprise user who is mapped to a shared schema is unknown to the database. When OID is
used to authenticate the user to the database, the real name of the enterprise user can be found
in his or her login session by using the SYS_CONTEXT function. This name is held in the
EXTERNAL_NAME attribute of the USERENV context. The shared schema is shown by:
$ sqlplus staylor
Password: ******
SQL> SELECT user FROM dual;
USER
----------------GUEST
The real user is shown by checking the EXTERNAL_NAME attribute of the USERENV context:
SQL> select sys_context ('userenv' , 'external_name') from dual;
SYS_CONTEXT('USERENV','EXTERNAL_NAME')
----------------------------------------------------------cn=Scott Taylor,cn=Users,dc=us,dc=oracle,dc=com
Who is the real user?

Show the current shared schema:
Enabling Current User Database Links
OIM
Metadata
Repository
OID
Username and
password
Client
Verifies user
Applies roles
Oracle DB
SSL
Oracle DB
Current user
database link
Enabling Current User Database Links

Current user database links require SSL-enabled network connections between the databases.
Before you can enable current user database links, you must enable SSL, create Oracle wallets,
and obtain PKI credentials for all databases involved. OID and Oracle Identity Management
Metadata Repository are not required, but some form of global authentication is required (SSL
or Kerberos).
Current user database links enable you to connect to another database as the user you are logged
in as, or as another user when used from within a stored procedure owned by that user. Access is
limited to the scope of the procedure.
If you are using OID, use the Configure Domain page of Enterprise Users Security in Enterprise
Manager Database Control to enable current user database links between databases within the
enterprise domain in the directory by performing the following steps:
1. On the Enterprise User Security page, click Manage Enterprise Domains.
2. On the Manage Enterprise Domains page, select a specific enterprise domain and click
Configure.
3. On the Configure Domain page, click the Configuration tab, select Enable Current User
Database Links, and click Ok
Note: Each user accessing a current user database link must be a global user.
User Migration Utility
External users
Local users
A supplied list of users
In a two-phase process:
Phase 1 populates a table in the database with user
information. The DBA is allowed to modify the table data as
required.
Phase 2 updates the directory and the database.
User Migration Utility

The user migration utility is a command-line utility invoked with the umu command, which is
used to move users from a local database model to an enterprise-user model. This utility makes
it easy to migrate local and external database users to an enterprise-user environment in an
LDAP directory. It uses the Oracle JDBC Oracle Call Interface (OCI) driver to connect to the
database.
Enterprise-user administrators can select for migration any combination of the following user
subsets in a database:
List of users specified on the command line or in a file
All external users
All local users
In addition, enterprise-user administrators can specify values for utility parameters that
determine how the users are migrated, such as:
Where to put the migrated users in the LDAP directory tree
Mapping a user with multiple accounts on various databases to a single directory user entry
The user migration utility is a command-line tool. It migrates

users:
From the database to OID:
umu HELP=YES
For more information about the user migration utility, see the Oracle Database Enterprise
User Administrators Guide.
User Migration Utility (continued)

Step 1: Preparing for the Migration (Phase One)
In the first part of the migration process, the ORCL_GLOBAL_USR_MIGRATION_DATA
interface table is populated with information about the users from the database and the
directory. The command-line options that are used determine what information populates
this table.
Step 2: Verifying User Information
This is an intermediate step to allow the enterprise-user administrator to verify that the user
information is correct in the interface table before committing the changes to the database
and the directory.
Step 3: Completing the Migration (Phase Two)
After the user information in the interface table is checked, in phase two, the utility retrieves
the information from the table and updates the directory and the database.
Depending on whether directory entries exist for migrating users, the utility creates random
passwords as follows:
If migrating users are being mapped to newly created directory entries, the utility
generates random passwords, which are used as credentials for both the database and
the directory.
If migrating users are being mapped to existing directory entries with unset database
passwords, the utility generates random database passwords only.
In either case, after generating the required random passwords, the utility stores them in the
DBPASSWORD and DIRPASSWORD interface table columns. The enterprise-user
administrator can read these passwords from the interface table and inform migrating users.
The umu utility will produce a listing of the allowable parameters for each phase with:
Exclusive schema
Shared schema
Standard audit
Standard audit
USERNAME
USERNAME
GLOBAL_UID
Fine-grained audit
Fine-grained audit
DB_USER
DB_USER
GLOBAL_UID
Enterprise-User Auditing
If auditing is turned on, the Oracle Database server captures the identity of enterprise users in its
audit trails. OID can store additional attributes for each user to help identify both authorized and
unauthorized users.
When an enterprise user has his or her own schema (an exclusive schema) in the database, the
database username represents the enterprise user. The enterprise user has a one-to-one mapping
to the database user or schema. When enterprise users access exclusive schemas:
In standard auditing: The USERNAME column shows the user identity in the database,
and the GLOBAL_UID column shows the same users global identity
In fine-grained auditing: The DB_USER column shows the user identity in the database,
and the GLOBAL_UID column shows the same users global identity
When enterprise users map to a shared schema in the database, the audit trails capture both the
username of the shared schema user and the identity of the actual user managed in the directory.
When enterprise users access shared schemas:
In standard auditing: The USERNAME column shows the shared schema, and the
GLOBAL_UID column shows the identity of the enterprise user
In fine-grained auditing: The DB_USER column shows the shared schema, and the
GLOBAL_UID column shows the identity of the enterprise user
Enterprise-User Auditing

Describe Enterprise User Security
Set up Enterprise User Security
Create an enterprise user
Use shared schemas
Audit enterprise users
Migrate users from the database to Oracle Internet
Directory
Summary

Setting up Enterprise User Security
Creating an Enterprise User with a database schema
Configuring enterprise users to use a shared schema
Implementing Enterprise User Security


following:
Describe how proxy authentication works
Manage users authenticated by proxy authentication
Audit users authenticated by proxy
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-2
Objectives
User Authentication

User Authentication
A basic security requirement is that you must know your users. You must identify them before you
can determine their privileges and access rights, and so that you can audit their actions on the data.
Knowing the end user allows you to specify users who are allowed to connect through a middle-tier
server. In many cases, the middle-tier server authenticates and assumes the identity of the user and is
allowed to enable specific roles for the user. This is called proxy authentication.
Note: The term application or application server is used in the rest of this lesson to refer to a
generic application program or application server that may be a custom application or a third-party
application. It is not an Oracle Application Server.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-3

Security Challenges of
Three-Tier Computing
User
Application
server
Database
Security Challenges of Three-Tier Computing

Although three-tier computing provides many benefits, it raises a number of new security issues.
These issues are described in the subsequent sections:
Identify the real user.
- Who is the real user? Database-level access control and auditing depends on being able to
identify the end user.
Authenticate the end user to the database.
- In multitier computing, authenticating the end user to the database securely becomes a
challenge.
Restrict the privileges of the middle tier.
- For many applications, the security model gives the proxy application user excessive
privileges. The challenge is to allow the session created or used by the middle tier to have
privileges that are appropriate to the real end user.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-4
Identify the real user

Authenticate the end user to the database
Restrict the privileges of the middle tier
Identifying the Real User
Authentication
Data access control
Auditing
Application-level security requires that:

Security must be coded in every application
Applications must be the only method to access the data
User
Application
server
Database
Abuser
Identifying the Real User

For authentication, access control, and auditing, most organizations need to know the identity of the
actual user who is accessing the database. User accountability is diminished if the identity of the user
cannot be traced through all tiers of the application. If the security is implemented in the application,
the possibility exists that the application could be bypassed.
Authentication
When only the application server knows who the user is, all per-user security enforcement must be
done by the application itself. Application-based security is very expensive. If each application that
accesses the data must enforce security, security must be reimplemented in each and every
application. It is often preferable to build security on the data itself, with per-user accountability
enforced within the database.
Access Control
Data access control at the database level is not possible when only the application knows the user
identity. The application must enforce the data access control. If the application is coded to use
secure application roles, the application use these roles to control data access by the user.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-5
The database server needs the end-user identity for the

following security functions:
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-6
Identifying the Real User (continued)

Auditing
Accountability through auditing is a basic principle of information security. Most organizations
want to know on whose behalf a transaction has been accomplished, not just that a particular
application server performed a transaction. A system must, therefore, be able to differentiate
between a user performing a transaction and an application server performing a transaction on
behalf of a user.
Auditing in three-tier systems should be tied to the issue of knowing the real user; if you cannot
preserve the users identity through the middle tier of a three-tier application, you cannot audit
actions on behalf of the user.
Pass through: The user is unknown to the application.

One big-application user: The user is unknown to the
database.
Other methods:
The user is reauthenticated to the database.
The user is identified to the database.
The user is proxied.
User
Application
server
Database
Common Implementations of Authentication

There are several implementations of three-tier authentication methods and variations of those
methods. Most of these methods can be grouped into the following categories:
Pass through (The user is unknown to the application.): In this model, the application queries
the user for credentials and passes the response to the database server for authentication. This is
a traditional model requiring each user to have a database schema and login. This method can be
moved to an enterprise-user model with no changes to the application. The application is not
responsible for authentication, authorization, or access control. Auditing can be handled by the
database server because the real user is obvious. This method is no different from the
client/server model, where the user connects directly to the database.
One big-application user (The user is unknown to the database.): In this model, the
application is responsible for authentication, authorization, and access control. All end users
present their credentials to the application, and the application user connects to the database.
Often, the application user is the application owner with all the privileges to all application
objects. This method is easy to code, but violates the principle of least privilege.
When the authentication process is determined by the application, it can use an LDAP directory,
local files, or some other method to validate the user. The application can make use of roles, enabling
and disabling roles to control access. Unless the application keeps some kind of mapping, end-user
auditing can be difficult or impossible.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-7
Common Implementations
of Authentication
Distinguished name (DN)

Certificate
Proxy authentication is covered in detail later in this lesson.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-8
Common Implementations of Authentication (continued)

Other methods:
The user is reauthenticated to the database: In this model, the user presents a credential
to the application (not necessarily the same as the database credentials), and the application
authenticates the user to the database. This model requires a secure method of storing user
credentials in the middle tier. Using LDAP directory services is one of the few methods that
can store credentials securely. Single sign-on is a secure solution for this model.
The user is identified to the database: The application can identify the user with a token
of some kind. This token maps the end user to a session. The end user is still unknown to the
database server, but end-user auditing is possible. The application uses the
DBMS_APPLICATION_INFO.SET_CLIENT_IDENTIFIER procedure or sets
CLIENT_IDENTIFIER with the DBMS_SESSION.SET_IDENTIFIER procedure in
conjunction with the application context to make this identification. The later method is
covered in the lesson titled Using Application Contexts.
The user is proxied: Oracle Database supports three forms of proxy authentication:
- The middle-tier server authenticates itself to the database server and provides an enduser name. The end user has already authenticated to the middle-tier server. End-user
identities can be maintained all the way through to the database.
- The database user is not authenticated by the middle-tier server. The end-user identity
and database password are passed through the middle-tier server to the database server
for authentication. This is another form of the pass-through method.
- The end userin this case, a global useris authenticated by the middle-tier server
and passes one of the following through the middle tier for retrieving the end-user
name:
Types of authentication in three-tier systems:

Middle tier-to-database authentication
Client-to-middle tier authentication
Client reauthentication through the middle tier to the
database:
Does the end user need to log in multiple times?
Can the end users database account information be stored in
the application?
Can the user be authenticated by using Lightweight Directory
Access Protocol (LDAP)?
Point-to-point protocols, such as secure sockets layer (SSL),
can authenticate to only one node.
Single authentication
User Reauthentication
To meet the requirements of database-level security, every user must be identified to the database:
the application server, end users, and proxy users must be identified. Reauthentication occurs when a
user is identified to the middle tier and then is identified again to the database.
Types of Authentication
In client/server systems, authentication tends to be straightforward; the client authenticates to the
server. In three-tier systems, authentication is more difficult because there are several potential types
of authentication:
Middle tier-to-database authentication
End user-to-middle tier authentication
End-user reauthentication through the middle tier to the database
Middle Tier-to-Database Authentication
Because the middle tier usually initiates a connection to a database to retrieve data, whether on its
own behalf or on behalf of the user, this connection clearly must be authenticated. In fact, the Oracle
database does not allow unauthenticated connections. Middle tier-to-database authentication can also
be mutual if you are using a protocol that supports this, such as secure sockets layer (SSL).
If you are using connection pooling, the application server authenticates to the database when it
builds the pool during startup, before there are any end users.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle Database
11g: Security
9-9
User Reauthentication
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 10
User Reauthentication (continued)

End User-to-Middle Tier Authentication
If a system is to conform to basic security principles, client authentication to the middle tier is
required. This is because the middle tier is the first gateway to useful information and services
that the user can access.
Note that such authentication can be mutual by using SSLthat is, the middle tier authenticates
to the client just as the client authenticates to the middle tier.
End-User Reauthentication Through the Middle Tier to the Database
There are many methods used for end-user authentication through the middle tier. End-user
reauthentication from the middle tier to the database is problematic in three-tier systems. The
problems are as follows:
The username may not be the same on the middle tier and the database. In this case, users
may need to remember and reenter a username and password, which the middle tier uses to
connect on their behalf.
For the end user to reauthenticate to the database, the middle tier either needs to ask the user
for a password or retrieve a password for the user and use that to authenticate the user. Both
approaches involve security risks because the middle tier is trusted to handle the users
password properly, and not to allow it to be used improperly.
Two sets of authentication handshakes per user involve considerable network overhead.
The database server may simply accept that the middle tier has performed proper
authentication. That is, the database server accepts the identity of the real users without
requiring the real users to authenticate themselves. This method hides the real user from the
database server, so auditing at the database level is not possible.
For some authentication protocols, end-user reauthentication is just not possible. For
example, many browsers and application servers support the SSL protocol. However, SSL is
a point-to-point protocol, and not an end-to-end protocol. It cannot be used to reauthenticate
a browser client through the middle tier to the database.
The middle tier may map the username provided during middle-tier authentication to a
database username. Where this mapping is held is the problem. Does the mapping include
passwords? Is the mapping secure?
Secure Reauthentication Methods
One solution is for the middle tier to use a username-mapping through a Lightweight Directory
Access Protocol (LDAP)compliant directory service, such as Oracle Internet Directory.
One of the only cases for which reauthentication does not involve trusting the middle tier occurs
when a middle tier downloads an applet to a client, and the client connects directly to the
database via the applet. In this case, the application server serves the application (applet) to the
user and has no part in further authentication of the user. This is considered a pass-through
method.
Other secure methods are discussed later in this lesson.
Single Authentication
The end user prefers to have a single authentication because it simplifies the process. Also, when
the client must remember multiple account names and passwords, it increases the chances that
the end user writes this information down, making the application less secure.
Restricting the Privileges of the Middle Tier
Connects with one database user for all application users

Has all privileges for all application users for all connections
Does not identify the end user to the database
Known as "one big-application user" model
Middle tier with limited privileges:

Adjusts privileges by user identity
May identify user to database
Restricting the Privileges of the Middle Tier

Middle Tier with High Privileges
A common application security model uses one application user to perform all connections to the
database, and all user requests through the application are performed as the application user. These
all-privileged middle tiers, such as transaction processing (TP) monitors, can perform all actions
for all users. In this architecture, the middle tier connects to the database as the same user for all
application users. It, therefore, needs to have all privileges that application users need to do their
jobs. This is also called the one big-application user model.
This security model does not provide defense in depth. If the middle tier is compromised, all the
application data is exposed. More desirable is a limited trust model, in which the identity of the real
client is known to the data server, and the application server (or other middle tier) has a restricted
privilege set.
Middle Tier with Limited Privileges
A more secure model limits the privileges granted to the application. It allows the application to
connect on behalf of certain users only, and allows it to assume only certain roles on behalf of the
user. For example, many organizations prefer that users have different privileges, depending on
where they are connecting from. Users connecting to a Web server or an application server on the
firewall may be able to access only a minimal set of data, whereas users connecting to a server within
the enterprise may be able to exercise all privileges that they are otherwise entitled to have.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 11
Middle tier with high privileges:
Implementing Proxy Authentication Solutions
Database user and enterprise user

Possible to reauthenticate to the database
Auditing actions taken on behalf of the real user
Unknown to the database:

End user known only to the application
Support for application-user models
Limiting the privilege of the middle tier
Proxy Authentication Solutions

Proxy authentication is implemented in two ways, depending on the identity of the end user. The first
is for the database user and the enterprise user. Both these users are identified to the database. The
second is for the end user who is known only to the application.
Passing Through the Identity of the Real User
Many organizations want to know who the user is through all the tiers of an application, without
sacrificing the benefits of a middle tier. The Oracle database supports proxy authentication for
preserving user identity through the middle tier of an application. The real user can be identified in
the following situations:
Database users have a database account that maintains their identity.
Enterprise-user identities are maintained in Oracle Internet Directory (OID) and are identified by
using a distinguished name (DN).
Application users are known to the application, but not to the database.
Reauthenticating the Real User
Database and enterprise users can be reauthenticated to the database after connecting to the
application server. Database users can supply a password that is passed to the database.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 12
Proxy authentication solutions depend on the type of the end

user:
Known to the database:
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 13
Proxy Authentication Solutions (continued)

Enterprise users can be authenticated to the database by a password, certificate, or Kerberos
token. End users unknown to the database cannot be authenticated to the database.
Support for Application User Models
Many applications use session pooling to set up a number of sessions that are owned by the
application user. These sessions are reused by multiple end users. These end users who are not
known to the database are authenticated to the middle tier of an application. The Oracle database
supports application-user proxy for these types of applications. The application can identify the
user with an arbitrary identifier; in the Oracle Database, this identifier can be audited. The
application is responsible for maintaining a mapping between the identifier and the end user.
Limiting the Privilege of the Middle Tier
The Oracle database proxy feature enables you to limit the middle tier so that it can connect on
behalf of certain database users only, using only specific database roles.
Auditing Actions Taken on Behalf of the Real User
The proxy authentication features of the Oracle database enable you to audit actions that a middle
tier performs on behalf of a user.
Which of the following are valid for proxy authentication?

a. End users unknown to the database
b. Enterprise users that are maintained in Oracle Internet
Directory
c. Database user that supplies a password
d. Application users that are known to the application but not
to the database
Answer: b, c, d
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 14
Quiz
Authenticating Database and

Enterprise Users
Use Oracle Call Interface (OCI) or Java Database

Connectivity (JDBC).
The authentication process includes the following steps:
1.
2.
3.
4.
The client authenticates to the middle tier.

The middle tier authenticates to the database.
The middle tier creates the end users session.
The database verifies that the middle tier can:
Create the session for the user

Assign the roles assigned to the user
Database users can be:

Authenticated to the application server
Reauthenticated to the database
Authenticating Database and Enterprise Users

For enterprise users or database users, Oracle Call Interface (OCI) or Java Database Connectivity
(JDBC) enables a middle tier to set up, within a single database connection, a number of lightweight
user sessions, each of which uniquely identifies a connected user. These lightweight sessions reduce
the network overhead of creating separate network connections from the middle tier to the database.
The application can switch between these sessions as required to process transactions on behalf of
users.
The full authentication sequence from the client to the middle tier to the database occurs as follows:
1. The client authenticates to the middle tier, using whatever form of authentication the middle tier
accepts. For example, the client can authenticate to the middle tier by using a username and
password, or an X.509 certificate by means of SSL.
2. The middle tier creating the lightweight client sessions must first connect to the database as a
database user rather than an enterprise user. The middle tier authenticates itself to the database,
using whatever form of authentication the database accepts. This can be a password or an
authentication mechanism supported by Oracle Advanced Security, such as a Kerberos ticket or
an X.509 certificate (SSL).
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 15
Reauthenticating the Real User

In the case of authentication with a database password, the password of the client is passed to the
middle-tier server. The middle-tier server then passes the password as an attribute to the data
server for verification. The main advantage of this is that the client machine is not required to
have Oracle software actually installed on it.
As described previously, it is not always beneficial to reauthenticate users to the database after
they have been authenticated to the middle tier.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 16
Authenticating Database and Enterprise Users (continued)

3. The middle tier then creates one or more sessions for users by using OCI or JDBC.
- If the user is a database user, the lightweight session must, as a minimum, include the
database username. If the database requires it, the session may also include a password
(which the database verifies against the password stored in the database). The session
may also include a list of database roles for the user.
- If the user is an enterprise user, the lightweight session may provide different
information, depending on how the user is authenticated. If the user is authenticated to
the middle tier via SSL, the middle tier can provide the DN from the users X.509
certificate, or the certificate itself in the session. The database uses the DN to look up the
user in Oracle Internet Directory. The users roles are automatically retrieved from
Oracle Internet Directory after the session is established.
- If the user is a password-authenticated enterprise user, the middle tier must provide, as a
minimum, a globally unique name for the user. The database uses this name to look up
the user in Oracle Internet Directory. If the session also provides a password for the user,
the database verifies the password against that stored in Oracle Internet Directory. The
users roles are automatically retrieved from Oracle Internet Directory after the session
is established.
4. If the user is a database user, the database server verifies that the middle tier is privileged to
create sessions on behalf of the user, using the roles provided. The OCISessionBegin call
fails if the application server is not allowed to proxy on behalf of the client by the
administrator, or if the application server is not allowed to activate the specified roles.

for Database Users
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR;
Authenticate the user with a database password:

ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATION REQUIRED PASSWORD;
Using Proxy Authentication for Database Users

Middle-tier authentication allows one JDBC connection (session) to act as a proxy for other JDBC
connections. Use the CONNECT THROUGH clause in the ALTER USER command to indicate that the
user is authenticated through a middle tier.
Authenticating Without a Database Password
When the middle tier authenticates the user, you may not want to give the middle tier the users
database password. If the middle tier does not know the password, the user can be authenticated
without a database password, using the following command:
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR;
The user can connect as PHALL by using the already authenticated credentials of the middle-tier
APPSVR. This method assumes that the middle tier is trusted to perform the authentication. The
created session behaves as if PHALL has been connected normally; PHALL does not have to divulge
his password to the middle tier. The proxy session accesses the schema of PHALL. This method is
sometimes appropriate for application servers in a trusted region.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 17
Authenticate the user without a database password:
Using Proxy Authentication for Database Users (continued)

Authenticating with a Database Password
To authenticate the user with a password, use the following command:
The Oracle instance expects the proxy to authenticate the user, unless you specify the
AUTHENTICATION REQUIRED clause. The AUTHENTICATION REQUIRED clause is relevant
only as part of a GRANT CONNECT THROUGH PROXY clause. In this method, the middle tier is
not assumed to be trusted. The middle tier may not perform any authentication. The user
authenticates to the database by providing the database password. This method is appropriate to
application servers that are outside a trusted region (firewall). The user will provide a password
that is passed through to the database.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 18
ALTER USER phall

GRANT CONNECT
THROUGH APPSVR
AUTHENTICATION REQUIRED PASSWORD;

for Enterprise Users
ALTER USER phall
GRANT CONNECT THROUGH APPSVR
AUTHENTICATED USING DISTINGUISHED NAME;
Authenticate the user with a certificate:

ALTER USER phall
GRANT CONNECT THROUGH APPSVR
AUTHENTICATED USING CERTIFICATE
TYPE 'X.509' VERSION '3';
Using Proxy Authentication for Enterprise Users

In both the DISTINGUISHED NAME and CERTIFICATE cases, the proxy has already authenticated
to the database and acts on behalf of a global database user who is known to the database. The
application server is responsible for the authentication in both cases and is trusted by the database.
Authenticating with a Distinguished Name
To authenticate the user with a distinguished name, use the following command:
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
AUTHENTICATED USING DISTINGUISHED NAME;
The distinguished name is a global name in lieu of the password of the user being proxied for. For
example, the distinguished name can be the following:
CN=phall,OU=americas,O=oracle,L=redwoodshores,ST=ca,C=us
The distinguished name is provided by the application server when the application server connects
for the user. The distinguished name may initially be provided by the user to the application server or
the application server may retrieve the distinguished name from an LDAP directory.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 19
Authenticate the user with a distinguished name:
Using Proxy Authentication for Enterprise Users (continued)

To pass the distinguished name of the client to the database, the application server would call
OCIAttrSet() with the following pseudo interface:
Authenticating with a Certificate

To authenticate the user with a certificate, use the following command:
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
In both the DISTINGUISHED NAME and CERTIFICATE cases, the proxy has already
authenticated and is acting on behalf of a global database user.
To pass over the entire certificate, the middle tier would use the following pseudo interfaces:
OCIAttrSet (
OCISession
*session_handle,
OCI_HTYPE_SESSION,
ub1
*certificate,
ub4
certificate_length,
OCI_ATTR_CERTIFICATE,
OCIError *error_handle );
If the type is not specified, the server uses its default certificate type of X.509.
Authenticating with a Specific Certificate Type
You can also indicate the type of certificate used to authenticate the user, using the following
command:
ALTER USER phall
GRANT CONNECT
THROUGH APPSVR
TYPE 'X.509' VERSION '3';
The two additional keywords have the following meanings:
TYPE is the type of certificate to be presented. If you do not specify the type, the default is
X.509.
VERSION is the version of the certificate that is to be presented. If you do not specify the
version, the default is 3.
Note: The AUTHENTICATED USING CERTIFICATE clause is discouraged, and may not be
supported in future versions.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 20
OCIAttrSet (
OCISession
*session_handle,
OCI_HTYPE_SESSION,
lxstp
*distinguished_name,
(ub4)
0,
OCI_ATTR_DISTINGUISHED_NAME,
OCIError *error_handle );
Proxy Access Through SQL*Plus

Proxy access through SQL*Plus when:
User is known to the database
User is unknown to the database (Enterprise User Proxy)

CONNECT rajeev[APPSVR]/rajeev_pwd
Proxy Access Through SQL*Plus

When both users are known to the database, the APPSVR user can connect on behalf of PHALL.
When connected, the user is PHALL and the schema is PHALL. The application can connect as
HRAPP and then initiate a session for PHALL. The APPSVR user may have authority to enable some
or all of the roles granted to PHALL. This is the database proxy feature shown earlier in this lesson
implemented in SQL*Plus.
When the user is unknown to the database, as in the case of an enterprise user with a shared schema,
the user is authenticated by the directory. The target user, APPSVR, is the user connected to the
database. The target user is not IDENTIFIED GLOBALLY, but allows CONNECT THROUGH
ENTERPRISE USERS. When connected, the user is APPSVR. The users provide their own
enterprise user credentials, but connect as the target user with the privileges and roles of the target
userin this case, APPSVR.
In both cases, notice that the session is for the user named in the "[ ]".
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 21
CONNECT APPSVR[PHALL]/appsvr_pwd
Enterprise User Proxy
CONNECT george[APPSVR]/george_pwd
george[APPSVR]
APPSVR
george
Enterprise User Proxy

In Oracle Database, the enterprise user proxy is available to allow you to use enterprise user security
in combination with existing applications that use the one big-application user model. All the users
have been connecting as APPSVR, and now they have been given enterpriser user credentials in the
directory. They can continue to use the application with a proxy connect as shown. The users provide
their Enterprise User Security (EUS) credentials and the target user, and connect to the database as
the target user.
Enterprise users can be individually granted permissions to proxy as local database users.
Enterprise user proxy permissions are created and stored in Oracle Internet Directory. A permission
allows one or more enterprise users or groups to proxy as a target database user. By default, domain
administrators manage proxy permissions in the directory for an enterprise domain. These
permissions are configured and managed using Enterprise Manager Enterprise User Security pages.
Note: In most cases, enterprise users such as GEORGE are unknown to the database. They are called
proxy users. The mapping of a proxy user to a database user is called a proxy permission. The user
making the connection, APPSVR, is called the target user, is a database user, and is not identified
globally.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 22
Use enterprise users with current applications.

Let the directory authenticate the users.
Connect as a database user.
Rajeev
CONNECT RAJEEV[PARTS_GUEST]/pwd
CONNECT JIM[PARTS_GUEST]/pwd
PARTS_DB
Jim
Enterprise User Proxy: Example

Consider the case where the PARTS application connects to the database as the PARTS_GUEST user
and creates a connection pool. The PARTS_GUEST user has privileges to access the PARTS_APP
schema. These privileges may be granted through roles granted to PARTS_GUEST. PARTS_GUEST
is not a global user.
JIM and RAJEEV are enterprise users created in the directory. They are mapped to a shared schema.
Any shared schema is adequate because the shared schema is not used.
Any user that connects using the PARTS_GUEST proxy schema is granted the roles granted to the
PARTS_GUEST user. Every user connecting to the PARTS_GUEST schema receives all the roles
and privileges granted to PARTS_GUEST by default. The application may enable secure application
roles to allow RAJEEV and JIM the individual access required.
The DBA still controls which database users may be proxied. The DBA changes the proxy grant with
the following command:
ALTER USER parts_guest GRANT CONNECT THOUGH ENTEPRISE USERS;
Only local database schemas may be granted CONNECT THOUGH ENTEPRISE USERS. Only
users designated as such may be added as a database target user to a proxy permission in the
directory.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 23
Enterprise User Proxy: Example
Enterprise User Proxy: Example (continued)

You may create an Enterprise User Proxy by performing the steps as shown in this example:
1. Create a named proxy permission, PROXY1 in the directory.
2. Assign enterprise users JIM and RAJEEV to the proxy permission.
3. Assign a database target user, PARTS_GUEST, to the proxy permission.
4. Change PARTS_GUEST in the database with the following command:
ALTER USER PARTS_GUEST CONNECT THROUGH ENTERPRISE USERS.
CONNECT JIM[PARTS_GUEST]/pwd@parts_db
The PARTS_DB database server contacts the directory to authenticate the enterprise users. The
roles are assigned based on the roles assigned to the target database user, PARTS_GUEST.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 24
When JIM or RAJEEV want to create a session, the application issues an OCI call equivalent to
the to following SQL command:
Revoking Proxy Authentication
ALTER USER phall

REVOKE CONNECT THROUGH APPSVR;
Do not use the AUTHENTICATED USING or

AUTHENTICATION REQUIRED clause with REVOKE.
Revoking Proxy Authentication

The following statement takes away the right of the user PHALL to connect through the proxy user
APPSVR:
ALTER USER phall REVOKE CONNECT THROUGH APPSVR;
You cannot specify the AUTHENTICATED USING or AUTHENTICATION REQUIRED clause as

part of a REVOKE CONNECT THROUGH <PROXY> clause.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 25
Revoke proxy authentication through a middle tier:
Application-User Model
Use OCI, thin JDBC, or thick JDBC.
End-user identity is set by the middle tier.
The authentication process is as follows:
1. The middle tier authenticates to the database.
2. The end user authenticates to the middle tier.
3. The middle tier allocates a session to the user, identifying the
user with CLIENT_IDENTIFIER.
4. Optionally, the middle tier can enable roles to restrict the
privileges of the user.
Examples:
Certificate
Application username and password
Application-User Model
Many applications use session pooling to set up a number of sessions to be reused by multiple users.
In this context, the end users who are not known to the database are authenticated to the middle tier
of an application. The Oracle Database supports an application-user proxy for these types of
applications.
In this model, the middle tier passes a client identifier to the database upon session establishment.
(The client identifier can actually be anything that represents an end user connecting to the middle
tierfor example, the end-user ID or an IP address.) The client identifier, representing the end user,
is available in user-session information and can also be accessed via an application context (via the
USERENV naming context). In this way, applications can set up and reuse sessions, while still being
able to keep track of the end user in the session.
Applications can reset the client identifier and, thus, reuse the session for a different user, enabling
high performance. For OCI-based connections, the call to change CLIENT_IDENTIFIER is
combined with other OCI calls to further enhance performance. An application-user proxy is
available in thin JDBC, thick JDBC, and OCI, and provides the benefits of connection pooling
without the overhead of separate user sessions (even lightweight ones).
Note: V$SESSION.CLIENT_IDENTIFIER and
V$SESSION_CONNECT_INFO.AUTHENTICATION_TYPE can provide additional information
about the end users identity and authentication, for auditing purposes.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 26
The full authentication sequence from the client to the middle tier to the database occurs as
follows:
1. During startup, the middle tier authenticates itself to the database server and creates a
connection pool. The method of authenticating to the database can be a password or an
authentication mechanism supported by Oracle Advanced Security, such as a Kerberos
ticket or an X.509 certificate (SSL).
2. The end user authenticates to the middle tier, using whatever form of authentication that
the middle tier accepts. Two examples are:
- The user can authenticate to the middle tier by using an X.509 certificate by means of
SSL.
- The user can authenticate to the middle tier by using a username and password stored
in the application.
3. The middle tier uses an available connection from its connection pool to create a session
for the end user, and uses JDBC or OCI calls to pass the end-user identifier to the database.
4. Depending on the information stored in the application, the middle tier can also set roles
for the end user. For example, if the application has multiple roles, you can do the
following:
a. Create database roles that match the application roles.
b. Assign appropriate privileges to the database roles.
c. Assign these roles to the application-server user, but disable the roles.
d. When the user starts a session, the application server enables the appropriate roles,
depending on the roles assigned to the user in the application. These roles may be
secure application roles, which may be enabled only through a secure package.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 27
Application-User Model (continued)

Authenticating Application Users
DBA_PROXIES: All proxy connections

USER_PROXIES: Connections that the current user is
allowed to proxy
PROXY_USERS: Users who can assume the identity of other
users
V$SESSION_CONNECT_INFO: Network connections for all
current sessions
V$SESSION: Session-connect details:
The PROGRAM column contains proxy-user
The MODULE column contains proxy-user
Data Dictionary Views for Proxy Authentication

USER_PROXIES: Displays information about connections that the current user is allowed to
proxy. This view does not display the PROXY column.
PROXY_USERS: Describes users who can assume the identity of other users.
V$SESSION_CONNECT_INFO: Displays information about network connections for all
current sessions.
V$SESSION: The PROGRAM and MODULE columns have a value of proxy-user when
the session is being proxied.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 28
Data Dictionary Views for

Proxy Authentication
SQL> SELECT proxy, client, authentication,

2
authorization_constraint
3 FROM dba_proxies
PROXY
-------HRUSER
APPSVR
CLIENT
-------PHALL
PHALL
AUTH
---NO
NO
AUTHORIZATION_CONSTRAINT
-----------------------------PROXY MAY ACTIVATE ROLE
NO CLIENT ROLES MAY BE
ACTIVATED
HRUSER
PFAY
YES
PROXY MAY ACTIVATE ALL CLIENT

ROLES
Data Dictionary Views: DBA_PROXIES and USER_PROXIES

DBA_PROXIES
DBA_PROXIES displays information about all proxy connections in the system. In the example in
the slide, HRUSER may activate any or all roles granted to PFAY. HRUSER may activate only a
specified role for PHALL. APPSVR may not activate any roles for PHALL.
USER_PROXIES
USER_PROXIES contains connections that the current user is allowed to proxy.
Columns
The columns for both DBA_PROXIES and USER_PROXIES are:
PROXY: Proxy username, in DBA_PROXIES only
CLIENT: Name of the client user on whose behalf the proxy user can act
AUTHENTICATION: Credential passed by the proxy for the client
AUTHORIZATION_CONSTRAINT: Authority of the proxy to exercise roles on the clients
behalf. The value PROXY MAY ACTIVATE ROLES indicates that only selected roles may be
activated.
ROLE: Role referenced in authorization constraint
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 29
Data Dictionary Views:

DBA_PROXIES and USER_PROXIES
Data Dictionary Views:

V$SESSION_CONNECT_INFO
SID AUTHENTICA OSUSER NETWORK_SERVICE_BANNER

----- ---------- ------ --------------------------------------148 DATABASE
oracle TCP/IP NT Protocol Adapter for Linux:
Version 11.2.0.1.0 - Production
148 DATABASE
oracle Oracle Advanced Security: encryption
service for Linux: Version 11.2.0.1.0 Production
148 DATABASE
oracle Oracle Advanced Security:
crypto-checksumming service for Linux:
Version 11.2.0.1.0 - Production
Data Dictionary Views: V$SESSION_CONNECT_INFO

This view displays information about network connections for the current session. The SID column
can be used to join this view with V$SESSION. There can be multiple rows returned for each
session. This is a banner for one session started by OSUSER oracle.
Columns
The columns and descriptions are:
SID: Session identifier
AUTHENTICATION_TYPE: How the user is authenticated:
DATABASE: Username and password
OS: External operating system
NETWORK: Network or Oracle Advanced Security
PROXY: OCI proxy connection
OSUSER: External username for the database user
NETWORK_SERVICE_BANNER: Product banners for each Oracle Net service used for this
connection, with one row per banner
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 30
SQL> SELECT sid, authentication_type,

2
osuser, network_service_banner
3 FROM v$session_connect_info WHERE sid = 148;
Auditing Actions Taken on Behalf

of the Real User
AUDIT SELECT TABLE ON employees

BY hrappserver ON BEHALF OF phall;
Audit SELECT from the EMPLOYEES table that

HRAPPSERVER initiates for any user as follows:
AUDIT SELECT TABLE ON employees
BY hrappserver ON BEHALF OF ANY;
The statements in this slide audit only SELECT statements

initiated by HRAPPSERVER.
You cannot audit CONNECT ON BEHALF OF 'DN'.
Auditing Actions Taken on Behalf of the Real User

You can use the proxy authentication features of the database to audit the actions that the middle tier
performs on behalf of a user.
Auditing on Behalf of a Specific User
For example, suppose an application server HRAPPSERVER creates multiple lightweight sessions for
the PHALL user. You can enable auditing for SELECT from the EMPLOYEES table that
HRAPPSERVER initiates for PHALL, as follows:
AUDIT SELECT TABLE
ON employees
BY hrappserver ON BEHALF OF phall;
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 31
Audit SELECT from the EMPLOYEES table that

HRAPPSERVER initiates for PHALL as follows:
Auditing Actions Taken on Behalf of the Real User (continued)

Auditing on Behalf of Any User
Alternatively, you can enable auditing on behalf of multiple users connecting through a middle
tier, as follows:
ON BEHALF OF Clause Does Not Audit Database Users

This auditing option audits only the SELECT statements being initiated by HRAPPSERVER on
behalf of other users.
To audit database users, enable separate auditing options. For example, to capture SELECTs
against the EMPLOYEES table from clients connecting directly to the database, use the following
command:
AUDIT SELECT TABLE
ON employees;
Auditing Enterprise Users

For audit actions taken on behalf of the real user, you cannot audit CONNECT ON BEHALF OF DN
because the distinguished name is not known to the database. However, if the user accesses a
shared schema (for example, APPUSER), you can audit CONNECT ON BEHALF OF APPUSER.
With enterpriser user proxy, the distinguished name of the enterprise user is available in the
PROXY_ENTERPRISE_IDENTITY attribute of the USERENV context. With a fine-grained
auditing (FGA) event handler, the PROXY_ENTERPRISE_IDENTITY can be captured from the
USERENV context.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 32
AUDIT SELECT TABLE

ON employees
BY hrappserver
ON BEHALF OF ANY;
DBA_STMT_AUDIT_OPTS describes the current system

auditing options.
USER_NAME column:
ANY CLIENT: Auditing access by a proxy
NULL: Systemwide auditing
PROXY_NAME column:
The name of the proxy user performing an operation for the
client
NULL if the client is performing the operation directly
Data Dictionary Views: DBA_STMT_AUDIT_OPTS

This view describes the current system auditing options across the system and by the user.
Columns
The following columns are related to auditing the actions of the proxy user:
USER_NAME: If auditing user actions, the username is recorded. If access by a proxy on behalf
of a client is being audited, ANY CLIENT is recorded. Else, NULL is recorded for system-wide
auditing.
PROXY_NAME: The name of the proxy user who is performing an operation for the client is
recorded. If the client is performing the operation directly, NULL is recorded.
Other columns that are not related to proxy users are not listed.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 33
Data Dictionary Views: DBA_STMT_AUDIT_OPTS
These views list audit-trail entries:

DBA_AUDIT_TRAIL
USER_AUDIT_TRAIL
The COMMENT_TEXT column can indicate how the user has
been authenticated:
DATABASE: Authentication done by the password
NETWORK: Authentication done by Oracle Net Services or
PROXY: Authentication by another user
EXTERNAL NAME: The distinguished name (DN) of the

Enterprise User Security (EUS) user
Data Dictionary Views: DBA_AUDIT_TRAIL

DBA_AUDIT_TRAIL
This view lists all audit-trail entries.
USER_AUDIT_TRAIL
This view contains all audit-trail entries related to the current user.
Columns Related to Proxies
The COMMENT_TEXT column can indicate how the user has been authenticated. The method can be
one of the following:
DATABASE: Authentication has been done by the password.
NETWORK: Authentication has been done by Oracle Net Services or Oracle Advanced Security.
PROXY: The client has been authenticated by another user; the name of the proxy user follows
the method type.
EXTERNAL NAME: The distinguished name is provided in addition to the other comments if the
user is an enterprise user.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 34
Data Dictionary Views: DBA_AUDIT_TRAIL

Describe how proxy authentication works
Manage users authenticated by proxy authentication
Audit users authenticated by proxy
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 35
Summary
Implementing Proxy Authentication
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
9 - 36

Implementing and testing database proxy authentication
Implementing EUS proxy
Using Privileges and Roles

following:
Implement database roles
Implement enterprise roles
Use procedures to secure objects
Manage roles and users by using secure application roles
Objectives
Authorization determines the privileges that the user has in the

database. User privileges are set in the database by:
System privileges
Object privileges
Roles
Authorization
Authorization is the process that determines the privileges that the user is allowed to exercise. In
Oracle Database, authorization is determined by the administration of system and object
privileges. A role is a named set of privileges and may be used to grant the privileges as a unit.
Authorization
There are two types of user privileges:

System: Enables users to perform particular actions in the
database
Object: Enables users to access and manipulate a specific
object
Privileges
A privilege is a right to execute a particular type of SQL statement or to access another users
object. Oracle Database allows very fine-grained control over what users can or cannot do within
the database. Privileges are divided into two categories:
System privileges: Each system privilege allows a user to perform a particular database
operation or class of database operations (for example, the privilege to create tablespaces is
a system privilege). System privileges can be granted by the administrator or by someone
who is explicitly given permission to administer the privilege. There are over 150 distinct
system privileges.
Object privileges: Object privileges allow a user to perform a particular action on a
specific object, such as a table, view, sequence, procedure, function, or package. Without
specific permission, users can access only their own objects. Object privileges can be
granted by the owner of an object, by the administrator, by someone with the GRANT ANY
PRIVILEGE privilege, or by someone who has been explicitly given permission to grant
privileges on the object.
Privileges
Roles
Users
Roles
Privileges
Girard
HR_MGR
Delete
employees
Vance
HR_CLERK
Select
employees
Update
employees
Insert
employees
Roles
In most systems, it is too time consuming to grant necessary privileges to each user individually,
and there is too great a chance of error. Oracle Database provides for easy and controlled
privilege management through roles. Roles are named groups of related privileges that are
granted to users or to other roles. They are designed to ease the administration of privileges in
the database and, therefore, improve security.
Role Characteristics
Privileges are granted to and revoked from roles in the same manner as a user.
Roles can be granted to and revoked from users or other roles as though they were system
privileges. An exception is that you cannot grant an IDENTIFIED GLOBALLY role to
anything.
A role can consist of both system and object privileges.
A role can be enabled or disabled for each user who is granted the role.
A role can require a password for the role to be enabled (IDENTIFIED BY password).
A role can be authorized by using an external source (IDENTIFIED EXTERNALLY).
Roles are not owned by anyone, and they are not in any schema.
In the example in the slide, the HR_CLERK role is granted the SELECT and UPDATE privileges
on the EMPLOYEES table. The HR_MGR role is granted the DELETE and INSERT privileges on
the EMPLOYEES table and granted the HR_CLERK role. The manager is granted the HR_MGR
role and can now select, delete, insert, and update rows in the EMPLOYEES table.
Neena
Easier privilege management

Dynamic privilege management
Selective availability of privileges
Can be granted through the operating system
Benefits of Roles
Easier Privilege Management
Use roles to simplify privilege management. Rather than granting the same set of privileges to
several users, you can grant the privileges to a role, and then grant that role to each user.
Dynamic Privilege Management
If the privileges associated with a role are modified, all the users who are granted the role
acquire the modified privileges automatically and immediately.
Selective Availability of Privileges
Roles can be enabled and disabled to turn privileges on and off temporarily. Enabling a role can
also be used to verify that a user has been granted that role.
Granting Through the Operating System
Operating system commands or utilities can be used to assign roles to users in the database, in
some operating systems.
Note: Roles are disabled in PL/SQL subprograms. The owner of a PL/SQL subprogram declared
with definers rights must have the privileges required for the subprogram granted directly and
not through a role. For a subprogram with invokers rights, roles are enabled unless the
subprogram is invoked directly or indirectly from a definers right subprogram.
Benefits of Roles
CONNECT
CREATE SESSION
RESOURCE
CREATE TABLE, CREATE PROCEDURE, CREATE

SEQUENCE, CREATE TRIGGER, CREATE TYPE,
CREATE CLUSTER, CREATE INDEXTYPE, CREATE
OPERATOR
SCHEDULER_ADMIN
CREATE ANY JOB, CREATE JOB, EXECUTE ANY

CLASS, EXECUTE ANY PROGRAM, MANAGE
SCHEDULER
DBA
Most system privileges, several other roles. Do not

grant to nonadministrators.
Predefined Roles
There are several roles that are defined automatically for Oracle databases when you execute
database creation scripts. CONNECT is granted automatically to any user who is created with
Oracle Enterprise Manager. The DBA role includes nearly all privileges and should not be
granted to nonadministrators.
Functional Roles
Other roles that authorize you to administer special functions are created when that functionality
is installed. For example, XDBADMIN contains the privileges that are required to administer the
XML database if that feature is installed. AQ_ADMINISTRATOR_ROLE provides privileges to
administer Advanced Queuing. HS_ADMIN_ROLE includes the privileges needed to administer
heterogeneous services. You must not alter the privileges granted to these functional roles
without the assistance of Oracle Support because you may inadvertently disable the needed
functionality.
Predefined Roles
The CONNECT role has only the CREATE SESSION

privilege.
A script to restore pre-Oracle Database 10g Release 2
privileges is provided for backward compatibility.
CONNECT Role Privileges

The DBA_CONNECT_ROLE_GRANTEES view enables you to quickly see which users have the
CONNECT role.
Note: Before Oracle Database 10g Release 2, the CONNECT role had the following privileges:
ALTER SESSION, CREATE SESSION, CREATE CLUSTER, CREATE SYNONYM, CREATE
DATABASE LINK, CREATE TABLE, CREATE SEQUENCE, and CREATE VIEW.
The rstrconn.sql script located in the $ORACLE_HOME/rdbms/admin directory is
provided to restore the pre-Oracle Database 10g Release 2 privileges to the CONNECT role.
After a database upgrade or new database creation, this script can be used to grant back the
privileges removed from the CONNECT role. However, the secure and recommended method is
to create a new role containing only the required privileges. Then determine which users or
database roles have the CONNECT role and grant the new role to these users or roles.
CONNECT Role Privileges
Using Proxy Authentication with Roles

Specify roles that the proxy user is allowed to activate:
ALTER USER phall

GRANT CONNECT THROUGH hruser
WITH ROLE hr_clerk;
Prevent any roles from being activated by the proxy user:
ALTER USER phall

GRANT CONNECT THROUGH appsrv
WITH NO ROLES;
Using Proxy Authentication with Roles

By default, a proxy user can activate all roles that are granted to a user. If a user is allowed only
certain privileges through a specific application, you can limit the roles that the proxy may
activate, as shown in the slide example or this example:
ALTER USER phall
WITH ALL ROLES EXCEPT hr_manager;
If the user does not require any privileges in a specific application, the proxy user can be
prevented from activating any roles that may be granted to the user for use in other applications,
as shown in this example:
ALTER USER phall
WITH NO ROLES;
Which of the following are characteristics of a database role?

a. Consists of only system privileges
b. Consists of only object privileges
c. Is a named set of privileges
d. Can consist of other roles
Answer: c, d
Quiz
Using Enterprise Roles
OID
Enterprise role:
PRACTICE_MGR
Enterprise role:
PROGRAMMER
Global role:
MANAGER
Global role:
USER
Global role:
EMPLOYEE
Global role:
DEVELOPER
HRDB
BUGDB
Global role:
PARTICIPANT
PROJDB
Using Enterprise Roles

An enterprise role allows the administrator to collect all the access requirements for a job role or
function into a named role that can span the enterprise. Roles defined in each database are
tailored to the applications and data residing in that database. Enterprise roles require the use of
Oracle Internet Directory (OID).
Example: The HRDB database has a MANAGER role that allows a manager to modify certain
fields of the employee records that are assigned to his or her organization. The BUGDB database
has a USER role that allows a user to create bugs and update bugs that he or she created. The
PRACTICE_MGR enterprise role is assigned a set of global roles: MANAGER in the HRDB
database, USER in the BUGDB database, and PARTICIPANT in the PROJDB database. Each
global role is defined in the local database, so the practice manager will get different privileges
in each database.
The HRDB database has an EMPLOYEE role that allows every employee to view and modify
certain records, such as a profile. The BUGDB database has a DEVELOPER role that is allowed to
update any bug that is assigned to him or her. The PROGRAMMER enterprise role is assigned
EMPLOYEE and DEVELOPER global roles
Note: All users assigned the same enterprise role receive the same privileges.
Enterprise roles can be used similar to job descriptions.

Define the application or database roles required.
Assign the database roles to an enterprise role.
Creating an Enterprise Role

An enterprise role is an OID directory structure that can contain global roles on multiple
databases. The enterprise role is granted to enterprise users. When an enterprise user attempts to
connect to the database, the enterprise directory is queried to obtain any global roles associated
with the user. The global role is defined locally in the database and granted privileges and roles.
You cannot grant the global role to a user or role in the database. An enterprise user can be
authorized to use the role only by an enterprise directory service.
Use the Enterprise Manager Database Control Enterprise User Security page to create an
enterprise role. This creates a container for the global roles. An example is HRACCESS_ROLE
as shown in the slide.
Creating an Enterprise Role and Assigning a Global Role
The Create Enterprise Role page is shown in the slide. To create mapping to a global role,
perform the following steps:
1. On the Enterprise User Security page, click Manage Enterprise Domains.
2. On the Manage Enterprise Domains page, select the domain and click Configure.
3. On the Configure Domain page, click the Enterprise Roles tab.
4. On the Enterprise Roles tabbed page, click Create.
5. Enter a name for the enterprise role and click Add.
6. On the Search And Select : Database Global Roles page, select the database and enter the
credentials for a user with access to DBA_ROLES, and then select the roles and click
Select.
Creating an Enterprise Role
Assigning an Enterprise User to an Enterprise Role

The Enterprise Manager Database Control Enterprise User Security tool enables you to associate
an enterprise role with a user. When the user connects to the database, the global roles assigned
to the enterprise role are enabled for the user.
Assigning an Enterpriser User to an Enterprise Role
Continuing from the previous page:
7. On the Create Enterprise Role page, click the Grantees tab, and then click Add.
8. On the Search And Select page, enter the user search string, and click Go.
9. Browse and select a user and click Select.
10. On the Create Enterprise Role page, click Continue.
11. On the Configure Domain page, click OK.
Assigning Enterprise Roles to Groups
Assigning the enterprise role to many users by using this method can be tedious. Enterprise roles
can be assigned to groups of users. Use the Oracle Identity Management Self Service console to
create the group and assign users to the group. Then use the EUS pages to assign the group to the
role in the same way as discussed here by using the cn=Groups node instead of the
cn=Users node.
Assigning an Enterprise User

to an Enterprise Role
Object access can be strictly controlled through

procedures.
The object owner creates procedures and functions to
access the object.
Users are granted the EXECUTE privileges on program
units.
Users do not have direct access to objects.
Securing Objects with Procedures

When the built-in authorization mechanisms are not sufficient, an object-oriented approach is
useful. Program units, procedures, and functions in the database, by default, run with definers
rights. This means that the program unit executes with the privileges of the owner of the unit.
Example: The HR application owner has a MEDICAL_HISTORY table with very strict access
controls. The HR user creates PL/SQL procedures and functions to implement the allowed
access. HR can grant the EXECUTE privilege on these program units to authorize certain users to
perform only the actions that are implemented in the procedures. Users can access the table only
through the procedures because they have not been granted any other object privileges. The
procedures successfully access the table because they execute with the privileges of HR.
Program units can also execute with invokers rights. In this case, the procedure executes with
only the privileges of the user that executes the procedure. This is useful for procedures that are
very general and owned by SYS. An example is the DBMS_LOB package that provides the LOB
access routines that may be called by any user. The invoker must have privileges to access the
LOB.
Securing Objects with Procedures
The secure application role solves the problem of

preventing unauthorized access to data through other
client programs.
It uses the same SYS_CONTEXT mechanism as Virtual
Private Database (VPD).
Enabling a role is checked through a package,
and not a password.
Secure Application Role

Often, users are authorized to access certain objects only through an application that can control
and check their actions.
The secure application role is enabled only through a package. The server checks the calling
stack to ensure that the proper package is being used, so that it cannot be spoofed. To enable a
secure application role, the associated procedure must be called, which controls whether the role
is enabled. The procedure can make additional checks and get information about the users
environment by using a call to SYS_CONTEXT('USERENV',nnn), where nnn can be, for
example, IP_ADDRESS or PROXY_USER.
The EXECUTE privilege is granted on the package only to the application. So even if users know
the details of the package, they cannot enable the role, except through the application.
Note: Refer to Oracle Database Vault Administrators Guide 11g Release 2 (11.2) for
information about Oracle Database Vault secure application roles.
Secure Application Role
Implementing a Secure Application Role
a. Create the package specification.

b. Create the package body.
3. Grant the EXECUTE privilege on the package.

4. Write the application server code that sets the role.
Implementing a Secure Application Role

Roles grant authorizations to the authenticated user. You may require additional validation. For
example, access may be restricted by time of day or client IP address. Because a secure
application role is a role implemented by a package, the package can perform the desired
validation. Besides limiting the privileges of the application server, the secure application role
prevents users from accessing data outside an application. They are forced to work within the
framework of the application privileges that they have been granted.
To create a secure application role, perform the following steps:
1. Create the secure application role.
2. Create the package that sets the role:
a. Create the package specification.
b. Create the package body.
3. Grant the EXECUTE privilege on the package so that the application server can set the role
for the application user.
4. Write the application server code that sets the role by calling the package just created.
Note: Because the package does not need to exist when the CREATE ROLE command is issued,
step 2 can be performed before step 1.
1. Create the role.

2. Create the package that sets the role:
The CREATE ROLE command identifies the package that

sets the role.
The package does not need to exist.
Example:
CREATE ROLE oe_sales_rep

IDENTIFIED USING sec.oe_roles;
Step 1: Create the Role

The CREATE ROLE command identifies the package that sets the role. The package does not
need to exist when the role is created. When the procedure is called to set the OE_SALES_REP
role, the calling stack is checked for the SEC.OE_ROLES package.
Step 1: Create the Role
The OE_ROLES package is referenced in the CREATE

ROLE command.
The AUTHID CURRENT_USER clause is required to
properly set the role.
Example:
CREATE OR REPLACE PACKAGE oe_roles

AUTHID CURRENT_USER
IS
PROCEDURE set_sales_rep_role;
END;
/
Step 2.a: Create the Package Specification

Because procedures with definers rights always execute with the privileges of the owner, secure
application roles can be enabled only inside procedures with invokers rights. The AUTHID
CURRENT_USER clause defines a procedure with invokers rights. It applies only to packages
and stand-alone procedures and functions. For a package, it must be coded in the specification of
the package and cannot be coded in the procedures or functions of the package:
CREATE OR REPLACE PACKAGE oe_roles
AUTHID CURRENT_USER
IS
PROCEDURE set_sales_rep_role;
END;
/
Sometimes, a secure package may need to access a table to retrieve all the roles that may be
enabled. This table must be accessed by a definers rights procedure called from the secure
procedure that sets the role. Create a definers rights package to return a list of roles from the
table (via an open cursor) to the invokers rights procedure. Then, fetch from the cursor the list
of roles to be enabled.
Step 2.a: Create the Package Specification
...
SELECT
id
INTO
v_id
FROM
oe.app_roles
WHERE username = sys_context
('userenv','current_user')
AND role = 'SALES_REP'
AND ip_address = sys_context
('userenv','ip_address');
dbms_session.set_role('oe_sales_rep');
...
Step 2.b: Create the Package Body

The package that enforces the secure application role selects from the APP_ROLES table. The
APP_ROLES table validates users in the application by ensuring that the user enabling the role
is connecting from a valid IP address. It contains the following columns:
USERNAME contains the name of the user who is trying to enable the role.
ROLE contains the name of the role that the user wants to enable.
IP_ADDRESS contains the address of the client that can enable the row.
For example, if the PHALL user can enable only the SALES_REP role from the IP addresses
134.43.51.114 and 134.43.51.120, the table would contain the following rows:
USERNAME
ROLE
IP_ADDRESS
PHALL
SALES_REP
134.43.51.114
PHALL
SALES_REP
134.43.51.120
Step 2.b: Create the Package Body
Step 2.b: Create the Package Body (continued)

The WHERE clause includes the following criteria:
The current user must be named in the table.
The user must be a sales representative.
The user must be logged on from an approved IP address.
If the user passes the validation, enable the role by executing DBMS_SESSION.SET_ROLE. If
the user does not pass the validation, a NO_DATA_FOUND exception is raised, and the role is
never enabled:
CREATE OR REPLACE PACKAGE BODY oe_roles IS
PROCEDURE set_sales_rep_role
AS
v_id oe.app_roles.id%TYPE;
BEGIN
SELECT
id
INTO
v_id
FROM
oe.app_roles
WHERE sys_context('userenv','current_user')
AND role = 'SALES_REP'
AND ip_address = sys_context('userenv','ip_address');
dbms_session.set_role('oe_sales_rep');
END;
END;
/
The application server connects as the APPSRV user.
It sets the role after it starts the users session.

Example:
GRANT execute
ON oe_roles
TO appsrv;
Step 3: Grant the EXECUTE Privilege on the Package

In this example, the account used by the application server is granted the EXECUTE privilege on
the package. The application server can execute the package to enable the role when it creates a
session for the end user:
GRANT execute ON oe_roles TO appsrv;
Step 3: Grant the EXECUTE Privilege

on the Package
Step 4: Write the Application Server

Code That Sets the Role
When starting, the application server:

Connects as the APPSRV user
When starting a session for a user, the application server:

Gets a connection from the pool
Starts a session for the user
Sets the users role
Set the users role by using:
sec.oe_roles.set_sales_rep_role;
Step 4: Write the Application Server Code That Sets the Role
To set the role for a user, the application server calls a procedure in the package referenced in
the CREATE ROLE command. The procedure is called after the application server establishes a
session for the user.
Note: Do not grant the secure role to the user as a default role. If the role is granted to the user, it
is enabled at login if the default role is set to all. If there are roles that should be enabled for
users at login, the following command disables the secure role:
ALTER USER phall DEFAULT ROLE ALL EXCEPT oe_sales_rep;
Creates a connection pool
SQL> SELECT *
2
FROM dba_application_roles
3
WHERE ROLE = 'OE_SALES_REP';
ROLE
SCHEMA PACKAGE
------------- ------- -------OE_SALES_REP SEC
OE_ROLES
SQL>
Viewing Dictionary Information for Secure Application Roles

SESSION_ROLES
After the application server sets the role, the role appears in the SESSION_ROLES data
dictionary view.
DBA_APPLICATION_ROLES
This data dictionary view lists all the secure application roles in the database. The example in
the slide selects the role previously created. The SCHEMA column contains the owner of the
package. Roles are not owned by a schema.
Viewing Dictionary Information for Secure

Application Roles

Implement database roles
Implement enterprise roles
Use procedures to secure objects
Manage roles and users by using secure application roles
Summary
Implementing the Secure Application Role

Implementing the secure application role
Configuring an enterprise role

Using Application Contexts

following:
Describe how an application context is used
Describe the sources of application context values
Implement a local context
Implement an application context that is accessed globally
Objectives
An application context is a memory container with

read-only attributes.
The container is called a namespace and has named
attributes.
Each namespace is independent of others.
The namespace is populated by a package.
Application Context: Description

An application context is a memory container with read-only attributes. It may be populated
only by a named package. You can use these attributes explicitly or implicitly in your
application. Using an application context is like writing down an often-used phone number and
keeping it next to your phone, where you can find it easily, rather than looking it up every time
you need it.
A context has an allocated area of memory called a namespace. The context or namespace has
named attributes. Each attribute can hold a text string value. In some programming languages,
this is known as an associative array.
The application context namespace identifies the application context. For example, you may
have the HRAPP and OEAPP namespaces that are used with the Human Resources and Order
Entry applications, respectively. Multiple namespaces enable you to use the same attributes
name in a different namespace without interfering with other namespaces. For example, the
HRAPP and OEAPP application contexts can each have an attribute named ID that contains a
different value in each context.
Context memory accessed locally is allocated from the fixed portion of the user global
area (UGA), which belongs to each server process. This memory allocation is not subject to the
effects of the PGA_AGGREGATE_TARGET parameter.
Application Context: Description
Creating a Context in a Namespace

HRAPP
Use the CREATE CONTEXT command to:
CREATE CONTEXT hrapp

USING hr_context;
Use the SET_CONTEXT procedure to:

Create attributes
Set values of attributes
DBMS_SESSION.SET_CONTEXT (
'hrapp', 'emp_id', v_emp_id );
Creating a Context in a Namespace

A namespace is a set of names in a naming system where all names are unique. Each context is
created in its own namespace. In the example in the slide, each attribute of the HRAPP context is
unique within the HRAPP context.
When a context is created, a memory area is allocated, and the context is given a name. A
package is associated with the context at creation. This package is the only package that is
allowed to set the attributes in a context. In the example in the slide, the HRAPP context is
created and a package is named that has exclusive rights to set the attributes of the context. In
the example, the package is HR_CONTEXT.
The package calls the SET_CONTEXT procedure of the DBMS_SESSION package to set the
value of an attribute. If the attribute does not exist, it is created. In the example, the EMP_ID
attribute is created in the HRAPP context and the value of V_EMP_ID is assigned.
The details of the PL/SQL calls are covered later in this lesson.
Create a context in a namespace

Associate a package with the context
Using the Application Context
Authorize users
Limit access to data, called by a fine-grained access control
policy
Set attributes used in the application
Using the Application Context

Although the main benefit of using application contexts is improved performance, contexts are
used with Oracle Database security features, such as Virtual Private Database (VPD) or
fine-grained access control.
With application context, you can write applications that use the attributes of the application
context to perform the following:
Authorize users when they log on. For example, you can verify that the user is connecting
through a specific computer by verifying the users IP address. You would use the
USERENV context to access the users current IP address.
Set context attributes that are used by fine-grained access control policies. Session
properties may be used to limit the rows that the user can access. In an order-entry
application, customers can access only their own orders by setting a context attribute with
the current users customer number. Because of the way the context is set and used, you
can implement fine-grained access control without changing the application.
Set the attributes that are used in the application. In this situation, set the attributes as part
of the context, rather than accessing the attributes from a table. For example, if the users
employee number is used frequently in the application, you can create a context attribute
that contains the employee number, rather than selecting the employee number from a
table.
An application context:
Is read by applications
Can be used to:
Setting the Application Context

The context attributes are set by a package, which:
Creates attributes in the context
Assigns values to the attributes of the context
Is usually called when a user connects
Each application can use one or more contexts.

A context may be used by multiple applications.
USERENV is a built-in context with session properties and is
available to all applications.
Setting the Application Context

Setting the Attributes
The application developer or security developer writes a package that assigns values to the
context attributes. The attributes of the context can be set only with this package. This is the
package that is associated with the context when the context is created. This package can be
called by the application or a logon trigger. The package sets the attributes that are used for that
session. These must be attributes that are frequently used by the application. The benefit of the
context comes from caching these values in memory and not having to perform SQL or system
callouts to retrieve them.
Each application can have its own application-specific context. For example, the context
attributes for a human resources application can include position, organizational unit, and
country, whereas context attributes for the order-entry system may be customer ID and name.
Applications can use multiple contexts, and a context may be used by multiple applications.
A special context is the built-in USERENV context. The USERENV context is populated with
values that are commonly found in the V$SESSION and V$PROCESS views. For a full list of
the attributes of the USERENV context, see the appendix titled USERENV Context.
SYS_CONTEXT returns context attributes:

sys_context ('context','attribute')
To return the client IP address from the built-in context,

use:
sys_context ('userenv', 'ip_address')
To return EMP_ID from the HRAPP context, use:
sys_context ('hrapp', 'emp_id')
Using the SYS_CONTEXT PL/SQL Function

This function returns the values of context attributes, including:
Built-in attributes from the USERENV context, which contains session properties
User-defined attributes from user-defined contexts
Syntax
This function has the following syntax:
SYS_CONTEXT ('context', 'attribute')
where:
context is the name of the application context
attribute is the name of the attribute in this context
The function returns the value of the attribute.
Example:
The examples in the slide show SYS_CONTEXT being used to return the:
IP address of the client computer, by using the IP_ADDRESS attribute of the built-in
USERENV context
Employee ID from the HRAPP context
Using the SYS_CONTEXT PL/SQL Function
Application Context Data Sources
The built-in USERENV context contains session primitives

as attributes.
A local context uses database objects. The developer sets

these attributes.
Example: The EMPLOYEE_ID column in the EMPLOYEES
table
An externalized context can get values from an external

source, such as Oracle Call Interface (OCI).
A global context uses values from the directory-entry
attributes.
Application Context Data Sources

A context can be classified by the source of the data values that it contains. The value that is
assigned to the context attribute can have different sources.
Built-in Context
The built-in context called USERENV includes the following types of attributes:
Client properties, such as the IP address of the client computer
User properties, such as the proxy, session, and operating system user
Authentication methods, such as the type (which indicates whether the user is
authenticated through the database), the operating system, the network, or a proxy
National Language Support (NLS) settings, such as NLS_TERRITORY
For a complete list of attributes, refer to SYS_CONTEXT in Oracle Database SQL Reference.
Local Application Contexts
You can set attributes that are stored in a context from any database object. For example, an
EMPLOYEES table can include cost center, title, signing authority, and other information that is
useful for row level security. Also, values returned from procedures and functions can be used.
For example, use a function that returns the employee ID to assign a value to the context
attribute.
Example: Client IP address
Externalized Application Contexts

An externally initialized application context is characterized by attributes and values that are
initialized through external resources, such as an OCI call, a job queue process, or a
database link. It provides:
For remote sessions, automatic propagation of context values that are in an external
initialized context namespace
For job queues, restoration of context values that are in an externally initialized
context namespace
For OCI, a mechanism to initialize context values that are in an externally initialized
context namespace
Any client program can initialize this context by making OCI calls, and there are logon
event triggers that can verify the values. It is up to the application to interpret and trust the
values of the attributes. This type of context is created with the following command:
CREATE CONTEXT external USING ext_package INITIALIZED EXTERNALLY;
Note that with an externally initialized application context, the middle-tier server can
actually initialize context values on behalf of database users. Context attributes are
propagated for the remote session at initiation time, and the remote database accepts the
values if the namespace is externally initialized.
Global Application Contexts
Many organizations centralize user information and user management in a Lightweight
Directory Access Protocol (LDAP)based directory, such as Oracle Internet Directory
(OID). Application context attribute values can be stored in OID. This type of context is
created in the database as shown in the following example:
CREATE CONTEXT hrgapp USING hr_g_context INITIALIZED GLOBALLY;
When an enterprise user connects to the database, the attributes defined in the global context
of that users OID entry are placed in the named application context. The global context
named in the preceding example is HRGAPP. The attributes that are available are dependent
on the attributes defined in the LDAP directory. The SYS_CONTEXT function can be used
to access the attributes of the context as shown in the following example:
SYS_CONTEXT('HRGAPP','Title')
The HRGAPP context and the TITLE attribute must be added to the users OID entry in the
OracleDBAppContext object. For more details, see the Oracle Database Security
Guide.
If an LDAP inetOrgPerson object entry exists for the user, the connection also retrieves
all the attributes from inetOrgPerson and assigns them to the
SYS_LDAP_USER_DEFAULT namespace as shown in the following example:
SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','telephoneNumber')
Application Context Data Sources (continued)

Sources of Context Values
You must create a PL/SQL package to set an application

context attribute.
a. True
b. False
Answer: a
Quiz
1.
2.
3.
4.
Create an application context.

Create a PL/SQL package that sets the context.
Call the package to set the context attribute.
Read the context attribute in the application.
Set
PL/SQL package
Application
context
Read
PL/SQL program
Implementing a Local Context

To build an application context, perform the following steps:
1. Create an application context.
The application context is associated with the package in step 2. This ensures that the
context is changed only through the package.
2. Create a PL/SQL package that sets the attributes in the application context.
3. Call the package from the application or in a logon trigger.
The logon trigger is shown in this example.
4. Read the application context attributes in your application.
Note: Steps 1 and 2 can be reversed.
In the following example, an application context, HRAPP, is created by using the HR_CONTEXT
package. The context holds an EMP_ID attribute that has the value of EMPLOYEE_ID for each
user that logs in. The value is retrieved from the HR.EMPLOYEES table on the basis of the
users email address. It is assumed for this example that the users database account name is the
same as the users email ID.
Implementing a Local Context
Step 1: Create an Application Context
Create a unique context:

Names the context HRAPP
Associates it with the HR_CONTEXT package
You can set the context attributes only in the:

Package named in CREATE CONTEXT
Function associated with a policy
In the package, set attributes by calling

DBMS_SESSION.SET_CONTEXT.
Alternatively, you can use Enterprise Manager.
Step 1: Create an Application Context

To perform this task, use the CREATE CONTEXT statement. Each context must have a unique
attribute and must belong to a namespace. That is, context names must be unique within the
database, not just within a schema. Contexts are always owned by the SYS schema.
Example:
CREATE CONTEXT hrapp USING hr_context;
where:
HRAPP is the context namespace
HR_CONTEXT is the trusted package that can set attributes in the context namespace
In the example code, the package and security objects are created by a user specifically defined
to own the security package and objects.
CREATE CONTEXT hrapp USING hr_context;
After you have created the context, you can set or reset the context attributes by using the
DBMS_SESSION.SET_CONTEXT package. The values of the attributes that you set
remain either until you reset them or until the user ends the session.
You can set the context attributes only in two locations:
Inside a procedure of the trusted package that you have named in the CREATE
CONTEXT statement
Inside the function named in the policy, which is discussed in the lesson titled
This prevents a malicious user from changing context attributes without proper attribute
validation.
Enterprise Manager
Administration of application contexts is integrated in Enterprise Manager with a graphical
user interface for managing application contexts, fine-grained access control policies, and
Oracle Label Security policies. You can use Enterprise Manager to create a context and
associate it with a PL/SQL package.
Step 1: Create an Application Context (continued)

Setting the Context
Step 2: Create a PL/SQL Package

That Sets the Context
Create the HR_CONTEXT.SET_EMP_ID procedure:
Use SYS_CONTEXT to get the session username:
Use the session username to get the employee ID:
SELECT employee_id INTO v_emp_id

FROM employees
WHERE email =
sys_context('userenv', 'session_user');
Use SET_CONTEXT to set a context attribute:
dbms_session.set_context (
'hrapp', 'emp_id', v_emp_id );
Step 2: Create a PL/SQL Package That Sets the Context

Create a PL/SQL package with functions that sets the context for your application.
The following example creates the HR_CONTEXT package. The package sets the EMP_ID
attribute of the HRAPP context:
CREATE OR REPLACE PACKAGE hr_context IS
PROCEDURE set_emp_id;
END;
/
CREATE OR REPLACE PACKAGE BODY hr_context IS
PROCEDURE set_emp_id
IS
v_emp_id NUMBER;
BEGIN
SELECT employee_id INTO v_emp_id FROM hr.employees
WHERE email =
SYS_CONTEXT('USERENV', 'SESSION_USER');
DBMS_SESSION.SET_CONTEXT
('hrapp', 'emp_id', v_emp_id);
EXCEPTION
WHEN no_data_found THEN
('hrapp', 'emp_id', 0);
END;
END;
/ ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
THESE eKIT MATERIALS
sys_context('userenv', 'session_user');
Step 3: Call the Package
CREATE OR REPLACE TRIGGER hr_context_logon

AFTER LOGON ON phall.SCHEMA
BEGIN
hr_context.set_emp_id();
END;
/
Step 3: Call the Package

Although a logon trigger is not required (the application can initialize the context at any time), it
is highly recommended because the users context must be set before the user accesses any data:
AFTER LOGON ON phall.SCHEMA
BEGIN
END;
/
The example shows a logon trigger that affects only a single user or schema. If all application
users are connecting as PHALL, this is an effective method of setting the context. If all users are
connecting with their own usernames, the following alternative logon trigger can be used:
AFTER LOGON ON DATABASE
BEGIN
END;
/
Create a logon trigger that calls the

HR_CONTEXT.SET_EMP_ID procedure:
Step 4: Read the Context Attribute

in the Application
To return an attribute value, use:
sys_context('hrapp', 'emp_id')
There are two arguments:

Name of the context
Name of the attribute
Example in SELECT:
SELECT * FROM departments

WHERE manager_id =
sys_context('hrapp','emp_id');
Step 4: Read the Context Attribute in the Application

Access the application context attributes and use them where they are needed in your
application.
Application Context Accessed Globally

Shares a context across sessions
Simplifies connection pooling from a middle tier
Uses a client identifier to identify the user of a session
SGA
Application context is EMP ID = 101
PL/SQL program A
User Database Session 1
PL/SQL program B
User Database Session 2
Application Context Accessed Globally

By default, the memory for the application context is allocated from the sessions UGA. In many
application architectures, the middle-tier application is responsible for managing connection
pooling for application users. Users authenticate themselves to the application. The application
then uses a single identity to log in to the database and maintains all the connections. In a
connection-pooling environment, usually any user can use any connection. The application
decides the connection that a user request can use. In this environment, it is not possible to
maintain application attributes by using session-dependent secure application context because
the context is private to each session, and because of the sessionless model of the application,
any user can use any session.
The application context accessed globally is a type of secure application context that can be
shared among trusted sessions. It can be shared because the memory for the context is allocated
from the system global area (SGA). Middle-tier applications use globally accessed application
contexts to manage application attributes securely and globally. Global application contexts with
connection pooling allow multiple connections to access one or more contexts, instead of setting
up an application context for each user session. Globally accessed application contexts provide
additional flexibility for Web-based applications. They also provide enhanced performance
through the reuse of common application contexts among multiple sessions, instead of setting up
application contexts for each session.
The middle tier sets the application context for each session. The context accessed globally
allows the middle tier to store the various application context definitions in a central place in the
SGA and apply the context to a user session at session-creation time. This then becomes that
sessions driving context. This also reduces the setup time of the user session when the
application is using connection pooling.
Limitation: A context accessed globally cannot be initialized from OID or an external source.
So any context accessed globally must be a local context accessed globally.
To support connection pooling managed by middle-tier applications, the DBMS_SESSION
interface gives the application the ability to add a client identifier for each application context.
The application can manage the context globally, whereas each client sees only its assigned
application context.
The application must test input to prevent a malicious user from injecting a call to
DBMS_SESSION or any SQL injection attempt. Because DBMS_SESSION is granted to
PUBLIC, such an injection can allow the user unauthorized privileges.
By default, a context is not accessed globally.
Note: A context accessed globally is not available in the Real Application Clusters (RAC)
environment for connections that span instances. The context accessed globally is stored in the
shared pool of one instance and is not available in the other instances of the cluster.
Application Context Accessed Globally (continued)

Application contexts accessed globally provide performance improvements through connection
reuse. These application contexts are initialized once, instead of being initialized for each
session individually.
Note: The application must initialize the context.
Application Context Accessed Globally in Action

1. Builds connection pool
3. Establishes session
4. Processes request
5. Completes request
6. Makes another request
7. Processes second request
8. Logs out
9. Clears context
PHALL
Application server
Database
Application Context Accessed Globally in Action

The boxes in the slide show the actions being performed. The box on the left shows the actions
taken by the user. The box on the right shows the actions taken by a program running on the
application server.
1. The application server starts up and builds its connection pool by establishing multiple
connections to the database as the APPSMGR user.
2. The user PHALL logs in to and is authenticated by the application server.
3. The application server establishes a session for the request from PHALL by:
- Using a connection from the connection pool
- Calling SET_IDENTIFIER to assign a session client identifier for the PHALL
username
- Setting the application context
- Saving the client identifier in the browser of PHALL as part of a cookie, or
maintaining the client identifier within the application server
4. The application server processes the request of PHALL. When the application reads
contexts, it does not include the client identifier because the SET_IDENTIFIER call in
step 3 has already identified the session.
2. Logs in
Application Context Accessed Globally in Action (continued)

5. When the application server finishes the request of PHALL, it:
- Issues a CLEAR_IDENTIFIER call
- Returns the connection to the pool
6. The PHALL user makes another request.
7. The application starts differently because there is a cookie identifying the current
context:
- The session client identifier is retrieved from the cookie or the application server
storage.
- The client identifier is used in the SET_IDENTIFIER call after the connection
is obtained from the pool.
- The application runs as before, accessing the context from the previous call.
8. PHALL logs out from the application.
9. The application server issues CLEAR_CONTEXT to clear out the application context.
All SYS_CONTEXT calls within this database session return only application context values
belonging to the client sessionfor example, SYS_CONTEXT('HRAPP','ID') returns
PHALL.
Using the DBMS_SESSION Package
Maintaining contexts:
dbms_session.set_context
('hrapp', 'emp_id', v_emp_id );
Setting global identifiers:
dbms_session.set_identifier(client_id);
dbms_session.set_identifier(12345);
Using the DBMS_SESSION Package

Use the programs in the DBMS_SESSION package to:
Maintain application contexts
List application contexts
Maintain client identifiers that are used with global application contexts
The procedures and functions in DBMS_SESSION listed on the following pages include only
those that are related to application contexts.
Examples:
The first SET_CONTEXT example sets the EMP_ID attribute in the HRAPP context to the value
in the V_EMP_ID PL/SQL variable. Because the client identifier is not included as an argument,
this context is not being shared.
The second example sets a session client identifier for the current user, enabling the session to
access a context accessed globally.
set_context(context, attribute, value );
Using the DBMS_SESSION Package (continued)

SET_IDENTIFIER
where CLIENT_ID is the identifier being set for this session. This identifier is arbitrary,
and it has no relationship to the SESSION_ID username. The application chooses the
identifier. Because this identifier is often placed in the browser cookie, it should not be the
information that can violate the privacy of the user. The identifier should be a randomly
chosen string or number. If the application code sets the client identifier with a call to
DBMS_SESSION.SET_IDENTIFIER, CLIENT_ID is recorded in audit trails and can
provide a way to link a user to an action, if the application maintains a CLIENT_ID to user
mapping.
CLEAR_IDENTIFIER
This procedure clears the current session identifier that has been set with
DBMS_SESSION.SET_IDENTIFIER. It has no arguments.
SET_CONTEXT
This procedure sets a context attribute. It has the following syntax:
PROCEDURE set_context (
namespace VARCHAR2,
attribute VARCHAR2,
value
VARCHAR2,
username VARCHAR2 DEFAULT NULL,
client_id VARCHAR2 DEFAULT NULL )
where:
namespace is the name of the application context
attribute is the name of the attribute to be set
value is the value to be assigned to the attribute
username is the username attribute for the application context
client_id is the client identifier that identifies a user session to set a context.
This procedure sets an identifier that can be used to share a global context. It has the
following specification:
PROCEDURE set_identifier (
client_id VARCHAR2 )
Using the DBMS_SESSION Package (continued)

CLEAR_CONTEXT
where:
namespace is the namespace of the application context that contains the attribute to be
cleared
client_id is the ID of the client that has the contexts
attribute is the name of the attribute to be cleared
If ATTRIBUTE is not included, all contexts for the client are cleared.
LIST_CONTEXT
This procedure lists all the current context namespaces. It has the following syntax:
PROCEDURE list_context (
list OUT AppCtxTabTyp,
lsize
OUT NUMBER )
where:
list is a table of records for storing the list of application contexts set in the current
session, where each item in the list includes the namespace, attribute, and value of the
fields
lsize is the number of entries in the buffer
The AppCtxTabTyp type has the following specification:
TYPE AppCtxRecTyp IS RECORD (
namespace VARCHAR2(30),
attribute VARCHAR2(30),
value
VARCHAR2(4000));
TYPE AppCtxTabTyp IS TABLE OF AppCtxRecTyp
INDEX BY BINARY_INTEGER;
UNIQUE_SESSION_ID
This function returns an identifier, which is unique for all sessions that are currently
connected to this database. Multiple calls to this function during the same session always
return the same result. It has the following specification:
FUNCTION unique_session_id RETURN VARCHAR2
This identifier is different from the identifier that you can set by using SET_IDENTIFIER.
This identifier is a hexadecimal representation of session_id (SID), serial#, and a
sequence number. It can be up to 24 bytes and consist of alphanumeric characters.
This procedure clears the attributes in a context. It has the following syntax:
PROCEDURE clear_context (
namespace VARCHAR2,
client_id VARCHAR2,
attribute VARCHAR2 DEFAULT NULL )
Implementing the Application Context Accessed

Globally
Set the application context.

Set the session client identifier.
Clear the client identifier when the request ends.
3. Modify the application program that handles subsequent

requests in the same session:
Set the session client identifier from this session.
Clear the client identifier when the request ends.
4. Create or modify the application program that ends a

session to clear the context.
Implementing the Application Context Accessed Globally

To implement an application context accessed globally, perform the steps mentioned in the slide.
Because the application server sets the session client identifier when a session is established, the
application programs that access the application context are coded the same, whether or not the
context is accessed globally. In either case, you do not include the session client identifier when
reading an application context.
These instructions apply only to application contexts that are preserved between database
connections. For a stateless session, you can use an application context without accessing it
globally.
The SET_IDENTIFIER procedure sets an arbitrary value as CLIENT_ID. This value is used
to identify a user. A user can receive the same client identifier every time he or she connects, or
it can be unique every day or every hour. When you decide on the assignment of the client
identifier, consider how cookies can be intercepted and possibly used to hijack user sessions or
spoof user authentications. The client identifier must never contain any private or personal
information that may be used to steal a users identity. It is essential that the database trust the
identifier from the application server. A secure application role enabled by the application server
together with the identifier forms a defense-in-depth solution.
1. Create the application context accessed globally.

2. Modify the program that establishes a session:
Step 1: Create the Application Context Accessed

Globally
Create the context by using:
The ACCESSED GLOBALLY clause indicates that the

context can be accessed from multiple sessions.
Step 1: Create the Application Context Accessed Globally

The example in the slide creates the HRAPP application context that is initialized in the
HR_CONTEXT package. You must indicate that the application context is accessed globally.
CREATE CONTEXT hrapp

USING hr_context ACCESSED GLOBALLY;
Step 2: Establish a Session
(context, attr, value, username, client_id);
('hrapp','id','phall','APPSMGR', 12345 );
('hrapp','dept','sales','APPSMGR', 12345 );
3. Set the session client identifier:

dbms_session.set_identifier( 12345 );
4. Save the client identifier in a cookie.
Step 2: Establish a Session

When the user connects to the application server, the application server uses a connection from
its connection pool to connect that user to the database. After the connection is obtained, the
application server checks whether the user has already established a session. It checks for the
cookie containing the session client identifier. If there is no client identifier, the application
server establishes the session by:
1. Getting a unique client identifier (for example, the user_id, DN, or other code to identify
the user. This value appears in audit records and trace files.)
2. Calling the package that sets up the context for this session by using the client identifier.
The package must include the client identifier when it sets the context.
3. Setting the session client identifier by using SET_IDENTIFIER
4. Saving the client identifier in a cookie
If there is a client identifier in the cookie, this is not the initial request; the procedure for a
subsequent request is used.
Using the Global Application Context
In the application, all SYS_CONTEXT calls within this database session return application
context values belonging to the client session only. For example, the SYS_CONTEXT('hrapp',
'id') call returns PHALL.
1. Get a unique value to use as a client identifier.

2. Set the application context:
Step 3: Handle Subsequent Requests

1. Retrieve the client identifier.
2. Set the client identifier for this session:
3. Clear the client identifier when the request ends:
dbms_session.clear_identifier();
Step 3: Handle Subsequent Requests

1. Get the client identifier: If there is a session client identifier, this user has already
established a session. Therefore, use the client identifier to ensure that the users access the
correct application context. It is a common practice to place the client identifier in the
session cookie, but the client identifier can be stored in the application as well.
Best Practice: Do not put the client identifier in the session cookie.
2. Set the client identifier for this session: Because the application context can be shared
among database connections, it does not matter which database connection processes this
request from the user.
3. Clear the identifier: At the end of the request, before the connection is put back into the
connection pool, clear the current client identifier. This ensures that the next session cannot
inadvertently use a left-over client identifier to access an inappropriate context.
dbms_session.set_identifier( 12345 );
Step 4: End a Session
EXEC dbms_session.clear_context
('HRAPP', '12345');
Step 4: End a Session

When the user has completed all requests and wants to end his or her session, clear the context
that applies to the users session.
In the example in the slide, all the attributes for the HRAPP application context for the client
identifier 12345 are cleared because the attribute name is not included as the third argument.
1. Retrieve the client identifier.

2. Clear the context:
Viewing Application Context Information
Context created.
SQL> SELECT *
2
FROM dba_context
3
WHERE namespace = 'HRAPP';
NAMESPACE SCHEMA PACKAGE
TYPE
--------- ------ ---------- ---------------HRAPP
SYS
HR_CONTEXT ACCESSED LOCALLY
SQL>
Viewing Application Context Information

The data dictionary includes the following views that are related to application contexts:
ALL_CONTEXT describes all context namespaces in the current session for which
attributes and values have been specified by using the DBMS_SESSION.SET_CONTEXT
procedure. It has the same columns as DBA_CONTEXT.
DBA_CONTEXT describes all context namespaces that are defined in the database,
regardless of whether any attributes have been specified for them by using the
DBMS_SESSION.SET_CONTEXT procedure. The example in the slide uses this view.
DBA_GLOBAL_CONTEXT contains a description of all context information that is
accessible globally. This view is a subset of the information in DBA_CONTEXT.
SQL> CREATE CONTEXT hrapp USING hr_context;
Viewing Application Context Information (continued)

SESSION_CONTEXT, V$CONTEXT, and GV$CONTEXT list the attributes and the
attribute values for the current session. The views include the following columns:
NAMESPACE is the namespace that the active attribute is in.
ATTRIBUTE is the name of the active attribute.
VALUE is the value of the active attribute.
SESSION_CONTEXT and V$CONTEXT list the same information. GV$CONTEXT is
used with Real Application Clusters (RAC).
V$GLOBALCONTEXT and GV$GLOBALCONTEXT list the attributes and the attribute
values for application contexts that are accessed globally. The views include the
following columns:
- NAMESPACE is the namespace that the active attribute is in.
- ATTRIBUTE is the name of the active attribute.
- VALUE is the value of the active attribute.
- USERNAME is the username for the session.
- CLIENTIDENTIFIER is the unique session identifier.
GV$GLOBALCONTEXT is used with RAC.
Attempting to change the context outside of its package

results in the following error message:
ORA-01031: insufficient privileges.
SYS_CONTEXT works much like a bind variable.
Versioning does not apply to contexts accessed globally.
There are parallel query and Real Application Clusters
(RAC) limitations.
Context sources must be validated.
Application Context Usage Guidelines

Setting the Context Outside of the Package
If you try to change the context outside of the package specified in the CREATE CONTEXT
command, you receive an error message stating that you do not have the privilege required to
change the context:
SQL> exec DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', 0);
BEGIN DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', 0); END;
*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SYS.DBMS_SESSION", line 78
ORA-06512: at line 1
Application Context Usage Guidelines
Parallel Queries
If you try to execute SYS_CONTEXT in a parallel query environment, you receive a query
error.
If SYS_CONTEXT is used inside a SQL function that is embedded in a parallel query, the
function cannot pick up the application context. This is true because the application context
exists only in the user session. To use these features in combination, you must call
SYS_CONTEXT directly from the query.
Application Contexts Accessed Globally and RAC
Application contexts accessed globally are not available in RAC.
Validating Context Sources
When using an application context for security, the source of the values for the context
attributes must be thoroughly validated. If the source of the context is user input, there is a
possibility that the attribute may be altered to allow unintended access.
Application Context Usage Guidelines (continued)

Performance
If the SYS_CONTEXT arguments are constants, the SYS_CONTEXT function works much
like a bind variable, enabling cursor sharing.
Versioning in Application Context
When you execute a statement, Oracle Database 11g takes a snapshot of the entire application
context. Within the duration of a query, the context remains the same for all fetches of the
query. If you attempt to change the context within a query, the change does not take effect in
the current query. Because a simple application context is allocated per session, the
application context can be versioned.
Versioning is not available for the application context accessed globally. Versioning returns
the SYS_CONTEXT values at a point in time. Because multiple client sessions may be
accessing the same global application context values at any time, versioning is not possible.

Use an application context
Access the sources of application context values
Implement a local context
Implement an application context that is accessed globally
Summary

Creating an application context
Setting the context with a secure package
Testing the application context
Creating an Application Context

following:
Describe fine-grained access control
Describe Virtual Private Database (VPD)
Implement VPD
Group policies
Objectives
Limits row access

SELECT * FROM orders;
Limits column access
Uses a predicate
SELECT * FROM orders
Is returned from a
WHERE sales_rep_id = 406;
function
ORDERS
Is associated with a table or view
Is automatically enforced

WHERE sales_rep_id = 152;
Fine-Grained Access Control: Overview

Fine-grained access control enables you to build applications that enforce security policies at a
low level of granularity. You can use fine-grained access control to restrict access by rows and
columns, as in the following examples:
Customers can see only their own accounts.
Physicians see only the records of their own patients.
Managers see only the records of employees who work for them.
A fulfillment clerk sees customer records for shipping purposes, but not columns with credit
card numbers.
To use fine-grained access control, create a security policy function that returns a predicate (a
WHERE condition). After you attach the policy to a table, view, or synonym, the predicate controls
the rows accessed from the table or view. When a user executes a SQL statement (SELECT,
INSERT, UPDATE, or DELETE) on that object, the Oracle server dynamically modifies the users
statementtransparently to the user or applicationso that the user sees only the appropriate
rows. The policy can be set to add the predicate only when certain columns of interest are
accessed, allowing the control to be more fine-grained and reducing the overhead when those
columns are not accessed.
Fine-Grained Access Control: Overview
Example:
In the example in the slide, two different users enter the same SQL statement; however, the
security policy is applied to limit the query to those rows where the user is the sales
representative for the order. In this example, the security policy consists of the entire WHERE
clause.
Fine-Grained Access Control: Overview (continued)

Using fine-grained access control, you can:
Create different policies for SELECT, INSERT, UPDATE, and DELETE statements
Use security policies only on the tables where you need them
Use multiple policies for each table
Group policies so that the policies are applied per application
Limit the rows that the user can access, even though the application is not aware that
FGAC is being used
Limit rows that can be viewed if sensitive columns are included
Allow all rows to be viewed and mask the sensitive columns
You administer the security policies by using the DBMS_RLS PL/SQL package. With this
package, you can add, drop, enable, disable, and refresh the policies that you have created.
1.
2.
3.
4.
5.
The user accesses a table or view with a policy.

The data server calls the policy function.
The policy function returns a predicate.
The data server adds the predicate to the statement.
The data server executes the modified statement.
SELECT *
FROM orders;
becomes
SELECT *
FROM orders
WHERE customer_id =
sys_context
('oeapp','cust_id');
Understanding Fine-Grained Access Control Policy Execution

An example of fine-grained access control policy execution is as follows:
1. The user accesses the ORDERS table object with the following statement:
The DML statement can be SELECT, UPDATE, INSERT, DELETE, or INDEX. Oracle
Database does not implement fine-grained access control during MERGE statements. You
must use equivalent INSERT and UPDATE statements instead of MERGE to avoid error
messages and to ensure correct access control. For SELECT, the security is enforced even
when the table is accessed in a subquery.
2. The Oracle server calls the security function that implements the security policy for the
ORDERS table. If you are using policy groups, the Oracle data server looks up the driving
context to determine the policy group in effect and calls the security function in that group.
3. The policy function returns the predicate:
cust_id = sys_context ('oeapp', 'cust_id')
The call to SYS_CONTEXT gets the CUST_ID attribute from the OEAPP context. Because
the predicate uses an application context, this is also an example of a VPD; however, you do
not need to use a context to implement fine-grained access control.
Understanding Fine-Grained Access Control

Policy Execution
Understanding Fine-Grained Access Control Policy Execution (continued)

4. The Oracle server dynamically modifies the users statement to read:
If there are multiple policies attached to a table, the data server combines and enforces
all the predicates.
5. The Oracle server executes the dynamically modified statement. Upon execution, the
function employs the username returned by
SYS_CONTEXT ('USERENV','SESSION_USER')
to look up the corresponding customer and to limit the data returned from the ORDERS
table to that customers data only.
Multiple Policies
You can establish several policies for the same table or view. Suppose that you have a base
application for order entry, and each division of your company has its own special rules for
data access. You can add a division-specific policy function to a table without having to
rewrite the policy function of the base application.
All policies applied to a table are enforced with the AND syntax. Thus, if you have three
policies applied to the CUSTOMERS table, each policy is applied to any access of the table.
Also, you can use policy groups and a driving application context to partition fine-grained
access control enforcement so that different policies apply, depending on which application is
accessing the data.

WHERE customer_id =
SYS_CONTEXT ('oeapp', 'cust_id');
Benefits of Using Fine-Grained Access Control
Security:
Simplicity:
Define the policy once.
The policy is independent of the application.
Flexibility:
Apply different access rules to different SQL statements.
Group policies
High performance:
Define policies as static, context sensitive, or dynamic.
Active policies stored in memory.
Benefits of Using Fine-Grained Access Control

Security
Fine-grained access control attaches security policies to tables, views, or synonyms to enforce
business rules. No matter how a user accesses the data, the same security is always in force.
Exceptions are users connecting as SYS and those with the EXEMPT ACCESS POLICY privilege.
Simplicity
Adding the security policy to the table or view means that you make the addition only once, rather
than repeatedly adding it to each of your table- or view-based applications.
Flexibility
You can have one security policy for the SELECT statement, another policy for INSERT, and
others for UPDATE and DELETE statements. For example, you may want to enable a human
resources clerk to select all employee records in his or her division, but to update salaries only for
those employees in his or her division whose last names begin with A through F.
High Performance
You can control the evaluation frequency of the policies by declaring them static, contextsensitive, or dynamic. Active policies are cached in the shared pool for fast evaluation.
The fine-grained access control policy is always applied.

The policy enforces business rules to limit row access.
A Virtual Private Database (VPD) combines an application

context and fine-grained access control to:
Enforce business rules to limit row access
Use a secure application context to provide highperformance resolution of user attributes
Virtual Private Database

A Virtual Private Database (VPD) uses fine-grained access control to limit row and column
access and an application context to provide the information that is used to set the policy
predicates. Fine-grained access control is an enabling technology that is a building block for a
VPD and Oracle Label Security. Fine-grained access control without the use of an application
context often requires subqueries and repeated evaluation of the policy. By using a context, the
policy predicate often remains the same, reducing or eliminating the need to reevaluate the policy
and eliminating the cost of executing a subquery. The VPD feature is available with Oracle
Database Enterprise Edition.
Examples of Virtual Private Database

VPD allows multiple policies on the same table:
Customer example:
Predicate:
CUSTOMER_ID=SYS_CONTEXT ('OEAPP', 'CUST_ID')
Sales representative example:

Context attribute: EMP_ID
Predicate:
SALES_REP_ID=SYS_CONTEXT ('OEAPP', 'EMP_ID')
Examples of the Virtual Private Database

VPD is based on dynamically modified statements. For example, you have implemented a policy
that customers can see only their own orders. The policy causes any data manipulation language
(DML) statement, including SELECT, that accesses the ORDERS table to be modified to restrict
row access. This description is for the row-level access control. For column-level access control,
the columns of interest are checked first. If no columns of interest are accessed, no predicate is
applied.
Consider an order-entry application, which enforces the following rules:
Customers see only their own orders.
Account managers see only orders for their customers.
Sales representatives see only the orders that they entered.
Sales analysts do not see credit card numbers.
These rules require different predicates: one for customers and another for employees.
For customers, the predicate uses the customer identifier to limit the rows that are accessed. So
you define a context with a CUST_ID attribute.
Context attribute: CUST_ID
To design a VPD policy to return a specific predicate for an attribute, access the application
context within the function that implements the policy.
Using an Application Context with FGAC
Customer Example
For example, to limit customers to seeing their own records only, use FGAC to dynamically
modify the users query from SELECT * FROM orders to:
WHERE customer_id =
SYS_CONTEXT ('oeapp', 'cust_id');
In this example, the security function returns the following value:
customer_id = SYS_CONTEXT ('oeapp', 'cust_id')
Sales Representative Example
To limit sales representatives to seeing the records for their customers only, use FGAC to
dynamically modify the same query as above to this:
WHERE sales_rep_id =
SYS_CONTEXT ('oeapp', 'emp_id');
In this example, the security function returns the following value:
sales_rep_id = SYS_CONTEXT ('oeapp', 'emp_id')
Examples of the Virtual Private Database (continued)

For employees, you can define an application context with an employee identifier and jobtitle attribute, and these attributes can be accessed within the policy function to return the
correct predicate, depending on the value of the attributes. Thus, you can enable a user in the
account manager position to retrieve all the orders for his or her customers. The sales analyst
can view and summarize customer information without having access to sensitive
information. The sales representative can access all the records for his or her customers.
Identify the features that are utilized by Virtual Private

Database.
a. Oracle Label Security
b. Application context
c. Fine-grained access control
Answer: b, c
Quiz
Tools to Implement Virtual Private Database
PL/SQL procedures and packages:
Contexts
Client identifiers
DBMS_RLS: Manages:
Policies
Policy groups
Enterprise Manager:
Uses DBMS_RLS
Provides security policy administration
Manages VPD
Tools to Implement Virtual Private Database

SYS_CONTEXT
This function returns the values of context attributes, including:
Built-in attributes that contain session properties
User-defined attributes from user-defined contexts
DBMS_SESSION
Use the procedures and functions in the DBMS_SESSION package to:
Maintain application contexts
List application contexts
Maintain client identifiers used with global contexts
Note: The DBMS_SESSION package executes with the rights of the calling user. Some
procedures and functions are executable by the PUBLIC user. The routines that set and modify
the context must be called directly or indirectly by the trusted package. The security of the
context is controlled by the privileges granted on the trusted package. The DBMS_SESSION
routines check the calling stack for the trusted package. Therefore, these DBMS_SESSION
routines cannot be executed from the SQL*Plus command line directly.
SYS_CONTEXT: Returns context attributes

DBMS_SESSION: Manages:
Tools to Implement Virtual Private Database (continued)

DBMS_RLS
Enterprise Manager
Alternatively, you can use Enterprise Managers graphical user interface (GUI) to apply
security policies to schema objects (such as tables and views) and to create application
contexts. Enterprise Manager provides an easy-to-use interface to manage security policies
and application contexts, and, therefore, makes the VPD easier to develop.
Use the DBMS_RLS package to implement a VPD by indicating which security policies apply
to which tables and views. Use the CREATE CONTEXT command to create application
contexts.
The DBMS_RLS package contains procedures and functions that are used to manage:
Policies
Policy groups
Manage VPD policies.
Enterprise Manager
Enterprise Manager is the GUI administration tool for the following features:
Application context
Enterprise Manager
Managing VPD Policies

You can manage VPD from the Enterprise Manager pages or you can use APIs that are available
through the DBMS_RLS package.
Managing VPD Policies
Using DBMS_RLS to Manage Policies

Associate policies with tables or views:
ADD_POLICY
ADD_GROUPED_POLICY
DROP_POLICY
DROP_GROUPED_POLICY
Enable and disable policies:

DISABLE_GROUPED_POLICY
ENABLE_POLICY
ENABLE_GROUPED_POLICY
Refresh policies:
REFRESH_POLICY
Group policies:
CREATE_POLICY_GROUP
REFRESH_GROUPED_POLICY
DELETE_POLICY_GROUP
Manage driving contexts:

ADD_POLICY_CONTEXT
DROP_POLICY_CONTEXT
Using DBMS_RLS to Manage Policies

These procedures are used to create, drop, enable, disable, and group policies.
Note that the argument for the policy group name is different in different procedures. It can be
POLICY_GROUP or GROUP_NAME.
The DBMS_RLS procedures cause current DML transactions, if any, to commit before the
operation. However, the procedures do not cause a commit first if they are inside a data definition
language (DDL) event trigger. The DBMS_RLS procedures are part of DDL transactions.
Syntax for the procedures in the DBMS_RLS package is shown in the slides where those
procedures are discussed. The syntax for the other procedures is shown in PL/SQL Packages and
Types Reference.
Parameters
The parameters that are used by the procedures in the DBMS_RLS package have common names.
Every parameter has the same meaning regardless from which procedure the parameter is called.
For example, object_schema always means the name of the schema containing the table,
view, or synonym (current default schema, if NULL).
The following is a list of parameters that are used in the DBMS_RLS procedures:
object_schema: This is the schema containing the table, view, or synonym (current
default schema, if NULL).
object_name: This is the name of the table, view, or synonym to which the policy is
added.
policy_name: This is the name of the policy to be added. It must be unique for the
same table or view.
function_schema: This is the schema of the policy function (current default
schema, if NULL).
policy_function: This is the name of a function that generates a predicate for the
policy. If the function is defined within a package, the name of the package must be
present.
statement_types: These are the statement types to which the policy applies. It can
be any combination of INDEX, SELECT, INSERT, UPDATE, or DELETE. The default
is to apply the policy to all of these types, except INDEX. Oracle Database does not
implement fine-grained access control during MERGE statements. You must use
equivalent INSERT and UPDATE statements instead of MERGE to avoid error messages
and to ensure correct access control.
update_check: This is the optional argument for the INSERT or UPDATE statement
types. The default is FALSE. Setting update_check to TRUE causes the server to
also check the policy against the value after insert or update.
enable: This indicates whether or not the policy is enabled when it is added. The
default is TRUE.
static_policy: The default is FALSE. If it is set to TRUE, the server assumes that
the policy function for the static policy produces the same predicate string for anyone
accessing the object, except for SYS or the privilege user who has the EXEMPT
ACCESS POLICY privilege.
policy_type: The default is NULL, which means policy_type is decided by the
value of static_policy. The available policy types are described in the following
slides. Specifying any of these policy types overrides the value of static_policy.
long_predicate: The default is FALSE, which means the policy function can
return a predicate with a length of up to 4 KB. TRUE means the predicate text string
length can be up to 32 KB. Policies existing before the availability of this parameter
retain a 32-KB limit.
sec_relevant_cols: This enables column-level VPD, which enforces security
policies when a column containing sensitive information is referenced in a query. This
applies to tables and views, but not to synonyms. Specify a list of valid column names
of the policy-protected object separated by commas or spaces. The policy is enforced
only if a specified column is referenced (or, for an abstract data type column, its
attributes are referenced) in the user SQL statement or its underlying view definition.
The default is all the user-defined columns for the object.
sec_relevant_cols_opt: Use with sec_relevant_cols to display all rows
for column-level VPD filtered queries (SELECT only), but where sensitive columns
appear as NULL. The default is set to NULL, which allows the filtering defined with
sec_relevant_cols to take effect. Set to dbms_rls.ALL_ROWS to display all
rows, but with sensitive column values, which are filtered by sec_relevant_cols,
displayed as NULL.
Using DBMS_RLS to Manage Policies (continued)
Column-Level VPD
Statements are not always rewritten.
Example: A policy protects the SALARY column of the
EMPLOYEES table. The VPD policy is:
Not enforced for this query:
SQL> SELECT last_name FROM employees;
Enforced for these queries:
SQL> SELECT last_name, salary
2 FROM employees;
SQL> SELECT * FROM employees;
Column-Level VPD
With column-level VPD, the policy is applied and the statements are rewritten only when the
security-relevant columns are accessed. This means that the combination of row-level access
control and security-relevant columns implies that you can control access down to the element
referenced.
Suppose that the business policy and the imposed VPD policy is that a manager can access the
EMPLOYEES sensitive information only for his or her employees. The SALARY column is
considered sensitive information.
The Oracle Database server does not enforce the VPD policy when you select only the
LAST_NAME column from the EMPLOYEES table. So all employees can access nonsensitive
information in the EMPLOYEES table. However, when you issue queries that access columns
considered as security relevant, VPD applies the access control policy defined by the policy
function.
Note: Some commands explicitly reference the columns and others reference them implicitly.
Depending on how you define the policy function, the column-level policy can be applied for
DML statements as well.
BEGIN
dbms_rls.add_policy(object_schema => 'hr',
object_name
=> 'employees',
policy_name
=> 'hr_policy',
function_schema
=> 'hr',
policy_function
=> 'hrsec',
statement_types
=> 'select',
sec_relevant_cols
=> 'salary',
sec_relevant_col_opts => dbms_rls.ALL_ROWS);
END;
/
Column-Level VPD: Example

Use the SEC_RELEVANT_COLS parameter in the DBMS_RLS.ADD_POLICY procedure to name
the security-relevant columns when you apply the policy to the table or view. This parameter does
not apply to synonyms. If no columns are named, all columns are considered relevant.
If you have named security-relevant columns, you can specify the SEC_RELEVANT_COL_OPTS
constant. There are two options: ALL_ROWS and NULL.
DBMS_RLS.ALL_ROWS: All rows are displayed but the columns named in
SEC_RELEVANT_COLS have NULL values for the values that the user is not permitted to
access.
NULL: Only the rows that are allowed by the policy are displayed.
Note: SEC_RELEVANT_COL_OPTS applies only to the SELECT operations. If
SEC_RELEVANT_COL_OPTS is specified for DML operations, the ADD_POLICY procedure
fails.
In the example, you apply the policy that is implemented by the HRSEC function to the
EMPLOYEES table. You also set the policy to apply the VPD predicate to SELECT statements.
The security-relevant column in the EMPLOYEES table is SALARY.
Note: Column-level policies must include a function that returns a predicate; if the rows are not
restricted, column restrictions are not enforced.
Column-Level VPD: Example
Policy Types: Overview
DBMS_RLS.DYNAMIC (default)
Static
DBMS_RLS.STATIC
DBMS_RLS.SHARED_STATIC
Context sensitive
DBMS_RLS.CONTEXT_SENSITIVE
DBMS_RLS.SHARED_CONTEXT_SENSITIVE
Shared: Shared policies allow you to share the same

policy function with different objects.
Policy Types: Overview

The execution of policy functions can consume a significant amount of system resources. If you
can minimize the number of times policy functions must execute, you can optimize your database
performance. You can control when the policy is reevaluated by specifying the POLICY_TYPE
parameter.
Policies can be specified to be static, context-sensitive, or dynamic. The policy parameter
STATIC_POLICY=>TRUE or POLICY_TYPE=>STATIC sets the policy to be static.
Note: The POLICY_TYPE parameter overrides the STATIC_POLICY setting. A static policy is
executed once and the same predicate is used for all statements. But policies are dynamic by
default. For dynamic policies, the Oracle Database server assumes that the predicate may be
affected by any system or session attribute. The Oracle Database server makes no assumption
about when the change takes place and, therefore, always executes the policy function on each
statement parsing or execution.
In addition to static and dynamic policies, there are context-sensitive policies. These policy types
provide a way to improve server performance because they do not always reexecute policy
functions for each DML statement.
Shared policies allow you to specify the same policy on multiple objects.
The policy types specify how often a policy function should be

reevaluated. The types are:
Dynamic
The policy function is evaluated once.

The resulting policy predicate is cached in memory.
Every statement accessing protected objects uses the
same policy predicate.
BEGIN
dbms_rls.add_policy(
object_schema
=>
object_name
=>
policy_name
=>
function_schema
=>
policy_function
=>
statement_types
=>
policy_type
=>
sec_relevant_cols =>
END;
'hr',
'employees',
'hr_policy',
'hr',
'hrsec' ,
'select,insert',
dbms_rls.static,
'salary');
Static Policies
When you use static policies, VPD always enforces the same predicate for access control.
Regardless of which user accesses the objects, everyone gets the same predicate.
The policy function is executed only once. The returned predicate is cached in the system global
area (SGA) for all static policies with the same policy function. This makes static policies very
fast because the policy function is not executed for each query.
You can use a static policy when every query needs the same policy predicate.
You can enable static or shared static policies by setting the POLICY_TYPE parameter of the
DBMS_RLS.ADD_POLICY procedure to DBMS_RLS.STATIC or
DBMS_RLS.SHARED_STATIC, respectively.
In this example, the business policy is that a manager can access the EMPLOYEES sensitive
information only for his or her employees.
Note: The policy predicate is the same for every rewritten statement. But each execution of the
same rewritten statement can produce a different row set because the predicate may filter the data
differently according to context attributes or functions (such as SYSDATE). When the predicate
uses the SYS_CONTEXT function and the attribute remains the same, the function call is treated
like a bind variablethat is, the value returned by the function may change, but the cursor
remains the same.
Static Policies
Context-Sensitive Policies
The policy function is evaluated for each session when:
The resulting policy predicate is cached in the users

session memory.
BEGIN
dbms_rls.add_policy(
object_schema
=>
object_name
=>
policy_name
=>
function_schema
=>
policy_function
=>
statement_types
=>
policy_type
=>
sec_relevant_cols =>
END;
'hr',
'employees2',
'hr_policy2',
'hr',
'hrsec2',
'select,insert',
dbms_rls.context_sensitive,
'salary');
Context-Sensitive Policies
Policies are not always static or dynamic. Policy predicates may be static for a particular user
session, but different for other users. In some cases, policy predicates can change when certain
context attributes are changed within a user session. For either of these situations, you enable
context-sensitive or shared context-sensitive policies by setting the POLICY_TYPE parameter of
the DBMS_RLS.ADD_POLICY procedure. A policy type of
DBM_RLS.CONTEXT_SENSITIVE assumes that the policy predicate may be changed after
statement parsing for a particular database session. This change can occur only if there are some
session context changes. Therefore, the server reevaluates the policy function at statement
execution time if it detects context changes since the last use of the cursor. The policy predicate is
cached in the session memory.
In this example, the business policy is that a manager can access the EMPLOYEES2 sensitive
information only for his or her employees, and employees who are not managers can access only
their own sensitive information. The text of the predicate changes depending on who the user is.
The statement is first parsed

There is a related change in the local application context
departments
Same policy
function
countries
emp_v
employees
Sharing Policy Functions

With Oracle Database, you can apply both the static and nonstatic VPD policies to multiple
objects. These policies are called shared policies.
With shared policies, you can enforce a companys business policy (such as Users should see
only data relevant to their business line) on several objects by using a single policy function.
This is very helpful in easing the administration of policy functions. This is a better model than
repeatedly creating one policy function per object.
To share policy functions, you must use the same policy function in each policy that you define
with the DBMS_RLS.ADD_POLICY procedure. Each policy has its own name, but the
corresponding functions are the same. The policy type must be DBMS_RLS.SHARED_STATIC
or DBMS_RLS.SHARED_CONTEXT_SENSITIVE.
The caching behavior for shared static policies is exactly the same as static policies, except that
the Oracle Database server first looks for cached predicates generated by the same policy function
of the same policy type.
When the policy type is set to DBMS_RLS.SHARED_CONTEXT_SENSITIVE, the contextsensitive policy shares its policy function. The caching behavior is similar to the nonshared
policy, except that the server first looks for cached policy predicate generated by the same policy
function for the same policy type within the same database session.
Sharing Policy Functions
Policies are not enforced for:

DIRECT path export
The SYS user (any user connected AS SYSDBA)
Users granted the EXEMPT ACCESS POLICY privilege
Exceptions to VPD Policies

Fine-grained access control policies are the basis for the VPD and Oracle Label Security. The
exceptions listed here apply to both:
DIRECT Path Export
Fine-grained access control policies are not enforced during the DIRECT path export. Only SYS
or a user with the EXPORT_FULL_DATABASE role enabled can perform the DIRECT path
export.
SYS User (Connected AS SYSDBA)
Fine-grained access control policies cannot be applied to objects in the SYS schema.
Consequently, the SYS user and users making a privileged connection to the database (for
example, CONNECT / AS SYSDBA) do not have fine-grained access control policies applied to
their actions. They are always exempted from fine-grained access control enforcement. However,
the SYSDBA actions can be audited.
Users Granted EXEMPT ACCESS POLICY
Database users that are granted the EXEMPT ACCESS POLICY privilege, either directly or
through a database role, are exempted from fine-grained access control enforcements. EXEMPT
ACCESS POLICY is a very powerful privilege and should be carefully managed. Do not grant
this privilege and the WITH ADMIN OPTION clause.
Exceptions to VPD Policies
The steps to design and implement a VPD solution are:

1. Develop a strategy to understand the security problem.
2. Analyze the data to be protected.
3. Determine user access requirements.
4. Implement VPD policies.
5. Review and document your policy decisions.
Designing and Implementing a VPD Solution

Do not attempt to protect everything; usually, only a small number of tables contain sensitive
data. The design process steps are repeated for each set of data that is to be protected.
1. Develop a strategy: Talk to the right people. Identify those individuals in your organization
who really understand the business-security problem. Make sure that you understand the
problem before adding more security to your application.
2. Analyze the data to be protected: Ask the following questions:
- Where does the sensitive data reside in the application?
- Who needs access to this data?
- Who owns the data?
- Who should be able to read the data?
- Who should be able to make updates?
3. Determine user access requirements: This analysis includes a grouping of the user
community by access needs:
- Does that grouping follow organizational lines?
- Does it depend on the job function?
4. Implement VPD policies.
5. Review and document policy decisions: Do the policies solve the original problem?
Designing and Implementing a VPD Solution
1.
2.
3.
4.
Create a PL/SQL package that sets the context.

Create an application context.
Write the function that creates a predicate.
Create a policy to associate the function to the table.
Set
OEAPP
context
Read
CUST_ORDER
OE_SECURITY
package
function
OE_POLICY
OE.ORDERS
Implementing a VPD Policy

To implement a VPD policy, perform the steps listed in the slide and shown in the following
slides and notes.
Steps 1 and 2 are the same as listed in the lesson titled Using Application Contexts, but use a
different context and package.
Implementing a VPD Policy
Creating a Package and Context
Is associated with the package created in step 1

Prevents the context from being changed
CREATE CONTEXT oeapp USING oe_security;
Creating a Package and Context

Step 1: Create a PL/SQL package that sets the context.
Notice that OEAPP is the name of the context. The following creates the OE_SECURITY
package:
CREATE OR REPLACE PACKAGE oe_security IS
PROCEDURE set_cust_id;
END;
/
CREATE OR REPLACE PACKAGE BODY oe_security IS
PROCEDURE set_cust_id
IS
v_cust_id NUMBER;
BEGIN
SELECT customer_id INTO v_cust_id FROM oe.customers
WHERE cust_first_name || '_' || cust_last_name =
DBMS_SESSION.SET_CONTEXT('oeapp', 'cust_id', v_cust_id);
EXCEPTION
DBMS_SESSION.SET_CONTEXT('oeapp', 'cust_id', NULL);
END;
END;
1. Create a PL/SQL package that sets the context.

2. Create an application context that:
Creating a Package and Context (continued)

Step 1: Create a PL/SQL package that sets the context. (continued)
It is common to use a logon trigger to set the initial context because the users context must be set
before the user accesses any data. But the application can call the trusted package to set the
context as shown in the lesson titled Using Application Contexts.
For this example:

OEAPP is the context namespace.
OE_SECURITY is the trusted package that can set attributes in the context namespace.
After you have created the context, you can set or reset the context attributes by using the
DBMS_SESSION.SET_CONTEXT package. The values of the attributes that you set remain until
you reset them or the user ends the session. You can set the context attributes from only one
location: inside the trusted procedure that you named in the CREATE CONTEXT statement.
This prevents a user from changing context attributes without proper attribute validation.
Step 2: Create a unique context and associate it with the PL/SQL package.
To perform this task, use the CREATE CONTEXT statement. Context names must be unique
within the database, not just within a schema. Contexts are always owned by the SYS schema.
Writing the Function That

Creates a Predicate
CREATE PACKAGE BODY oe_security_p AS

FUNCTION cust_order (
object_schema VARCHAR2,
object_name
VARCHAR2 )
RETURN VARCHAR2
IS
BEGIN
RETURN 'customer_id =
sys_context(''oeapp'', ''cust_id'')';
END cust_order;
END oe_security;
Writing the Function That Creates a Predicate

The function that implements the security policy on the database object can access the context for
best performance. This function can be stand-alone or part of a package.
The example shows the function as part of a package, assuming that the security policies for the
entire order-entry application would be implemented as functions in the OE_SECURITY package.
Function Specification
The policy functions are called by the server. They require the following specification:
FUNCTION policy_function (
object_schema
IN
object_name
IN
RETURN VARCHAR2
VARCHAR2,
VARCHAR2 )
where:
object_schema is the schema owning the table or view.
object_name is the name of the table or view to which the policy is applied.
3. Write the function that creates a predicate.
Example:
The package body creates a predicate for the ORDERS table, which limits the orders returned
to those with the users customer identifier. The function uses the CUST_ID context attribute,
instead of a subquery on the CUSTOMERS table.
The following is the entire code for the example:
CREATE OR REPLACE PACKAGE oe_security_p AS
object_schema
VARCHAR2,
object_name VARCHAR2 )
RETURN VARCHAR2;
END;
/
CREATE OR REPLACE PACKAGE BODY oe_security_p AS
object_schema
VARCHAR2,
object_name VARCHAR2 )
RETURN VARCHAR2
IS
BEGIN
RETURN 'customer_id = SYS_CONTEXT(''oeapp'',
''cust_id'')';
END cust_order;
END oe_security_p;
/
Writing the Function That Creates a Predicate (continued)

Guidelines
The maximum length of the predicate that the policy function can return is 32 KB. This
length is limited by the LONG_PREDICATE parameter of the ADD_POLICY procedure
to 4 KB by default.
The policy functions must have the purity level of WNDS (write no database state).
Dynamic predicates generated out of different policies for the same object are combined
and enforced as though they were separate conditions of a WHERE clause joined by the
AND keyword.
The security check and object lookup are performed against the owner of the policy
function for objects in the subqueries of the dynamic predicates.
If the function returns a zero-length predicate, it is interpreted as no restriction being
applied to the current user for the policy.
When a table alias is required in the predicate, the name of the table or view itself must
be used as the name of the alias, so that the predicate references a valid object in the
SQL statement. For example, an alias is required when the parent object is an object
table.
The checking of the validity of the function is done at run time for ease of installation
and other dependency issues during import and export.
Testing the Security Function
OE_SECURITY.CUST_ORDER('A','B')
--------------------------------------------customer_id = SYS_CONTEXT('oeapp', 'cust_id')
Testing the Security Function

Because the security function does not access the context, you can easily test the function by
calling it and verifying that the appropriate predicate is returned:
SQL> SELECT oe_security_p.cust_order('a', 'b') FROM dual;
OE_SECURITY.CUST_ORDER('A','B')
------------------------------------------------------customer_id = SYS_CONTEXT('oeapp', 'cust_id')
SQL> SELECT oe_security.cust_order('a', 'b')

FROM dual;
Writing a Function That Returns

Different Predicates
The owner of the table has access to all rows:
RETURN 'NULL';
Sales representatives see only their orders:
RETURN 'sales_rep_id =
sys_context(''oeapp'', ''emp_id'')';
Customers can see only their own orders:
RETURN 'customer_id
= sys_context(''oeapp'', ''cust_id'')';
Other users have no access:
RETURN '1=2';
Writing a Function That Returns Different Predicates

In reality, you may have several different predicates based on a users status. For example, a sales
manager would be able to see the records only for his or her customers, and a customer can see
only his or her own orders.
To implement these policies, expand the CUST_ORDER function to return different predicates,
depending on the context values of the user.
Example:
The example enforces the following rules:
The owner of the table has access to all rows in the table.
Sales representatives can see only the orders that they have entered.
Customers can see only their own orders.
Any other user has no access to the table.
The rules enforced in this function use the following logic:
If the user is the owner of the object, which is the first argument, the predicate NULL is
returned, no restriction is applied, and the owner sees all the rows in the table.
CREATE OR REPLACE PACKAGE BODY oe_security_p AS

object_schema
VARCHAR2,
object_name
VARCHAR2 )
RETURN VARCHAR2;
IS
v_temp VARCHAR2(200);
BEGIN
/* The owner of the table has access to all rows */
IF lower(SYS_CONTEXT('USERENV', 'SESSION_USER'))
= lower(object_schema) THEN
RETURN 'NULL';
END IF;
/* Sales representatives only see their orders */
v_temp := SYS_CONTEXT('oeapp', 'emp_id');
IF v_temp IS NOT NULL THEN
RETURN 'sales_rep_id
= SYS_CONTEXT(''oeapp'', ''emp_id'')';
END IF;
/* A customer can only see their own orders. */
v_temp := SYS_CONTEXT('oeapp', 'cust_id');
IF v_temp IS NOT NULL THEN
RETURN 'customer_id
= SYS_CONTEXT(''oeapp'', ''cust_id'')';
END IF;
/* Any other user has no access to the table. */
RETURN '1=2';
END cust_order;
END oe_security;
Writing a Function That Returns Different Predicates (continued)

If the user is an employee, the OEAPP context is set from his or her row in the
EMPLOYEES table, and the security function returns the following predicate:
sales_rep_id = SYS_CONTEXT('oeapp', 'emp_id')
If the user is a customer, the OEAPP context is set from the users row in the
CUSTOMERS table, and the security function returns the following predicate:
customer_id = SYS_CONTEXT('oeapp', 'cust_id')
If the user is neither a customer nor an employee, the 1=2 predicate is returned. It
always evaluates to FALSE. Therefore, this user cannot view any rows from the table.
Creating a Policy
dbms_rls.add_policy (
object_schema =>'oe', object_name => 'orders',
policy_name => 'oe_policy',
function_schema =>'sec',
policy_function =>'oe_security_p.cust_order',
statement_types =>'select')
Arguments include the following:
Associated table: OE.ORDERS

Policy name: OE_POLICY
Function: SECURE.OE_SECURITY_P.CUST_ORDER
Applies to: SELECT
Creating a Policy
Create the policy by using the DBMS_RLS.ADD_POLICY procedure as shown in the code
example in the slide. This example adds a policy named OE_POLICY to the ORDERS table in the
OE schema. The OE_SECURITY.CUST_ORDER function is stored in the SEC schema and
returns the policy predicate. The policy applies to the SELECT statements only.
EXECUTE Privilege on the Policy Function
You need not grant the EXECUTE privilege on the security package to application users.
4. Create the policy:
To implement Virtual Private Database, you must create a

PL/SQL package to set the context.
a. True
b. False
Answer: a
Quiz
Order-entry Inventory
policy group policy group
Default policy
AND
AND
Orders
Security policies are

application-driven.
Different policies apply,
depending on the active
driving context.
Policies can be
developed
independently.
The default policy
always applies.
Policy groups are useful
when hosting
applications.
Implementing Policy Groups

By default, all policies defined on a table or view are applied to all SQL statements. The policies
written for one application will generate predicates for other applications. This requires
development groups to collaborate on policies. Partitioned fine-grained access control using
policy groups allows application-driven security policies.
With policy groups, applications can have different security policies based on their individual
application needs.
You can use policy groups and a driving application context to partition fine-grained access
control enforcement so that different policies apply for each application that is accessing the data.
The application sets the active driving context so that only the policy group for that application is
applied.
In the example, an order-entry clerk in Company B accesses the ORDERS table through the orderentry application. The order-entry application sets a driving context. Inside the database, a driving
context sets the policy group to Order Entry (which enforces access control on customer
number and region). There is also a default policy group that enforces data separation for each
company because this is a hosted application.
An inventory manager in Company C connects to the inventory application that accesses the same
ORDERS table. The driving context sets the inventory managers policy group to Inventory,
which enforces access control according to part number. The default policy group that enforces
data separation for each company is still in effect because this is a hosted application.
Implementing Policy Groups
Developing Policies in a Hosting Environment

In this example, in a hosting environment, Company A can host the ORDERS table for
Company B and Company C. The hosting company puts a default policy in place that is
always in effect. This policy applies a predicate that allows users from Company B to access
only their own data, and not any data owned by Company C.
The ORDERS table is accessed by two different applications (order entry from Company B and
inventory from Company C) with two different security policies. To integrate these two
policies into the ORDERS table without partitioned fine-grained access would require joint
development of policies between the two companies, which is not a feasible option. By
defining an application context to drive the enforcement of a particular set of policies to the
base objects, each application can implement a private set of security policies.
Implementing Policy Groups (continued)

Each user accesses different data, based on entirely different policies. The security
enforcement is transparent to the userfor example, each user may issue the SELECT *
from ORDERS SQL statement, but entirely different data sets are returned. With the
partitioning of FGAC policies, administrators can specify which policy group the policy
belongs to when adding a policy to a table or view by using the ADD_POLICY_TO_GROUP
interface.
Grouping Policies
a. Create the context.

b. Create the function that sets the context.
c. Make the context the driving context.
3. Create a policy group for each application.

4. Add each policy to the appropriate group.
Grouping Policies
Because multiple applications, with varying security policies, can share the same table or view, it
is important to identify which policies should be in effect when the table or view is accessed for
each application.
To do this, you can organize security policies into groups. By referring to the driving application
context, the Oracle server determines which group of policies should be in effect at run time. The
server enforces all policies that belong to that policy group.
The slide outlines the steps to create and implement grouped policies.
1. Determine the default policies.

2. Set up a driving context for each table:
Default Policy Group

A predefined default policy group is always applied.
The default group is named SYS_DEFAULT.
Each object has a default group.
Default Policy Group

Default Policy Always Applies
Some policies should always be applied. These policies belong to the default group.
SYS_DEFAULT Group
There is a predefined policy group named SYS_DEFAULT. Policies defined in this policy group
for a particular table or view are always executed along with the policy group specified by the
driving context.
Default Group
By default, all policies belong to the SYS_DEFAULT policy group. The policies defined in this
group for a particular table or view are always executed along with the policy group specified by
the driving context. The SYS_DEFAULT policy group may or may not contain policies.
For example, in a hosting environment, the policy that restricts the customers to seeing their own
rows may be in this group.
Default Policy Group (continued)

Multiple Policies in the SYS_DEFAULT Policy Group
If you add policies that are associated with two or more objects to the SYS_DEFAULT policy
group, each object has a separate SYS_DEFAULT policy group associated with it.
For example, the EMP table in the SCOTT schema has one SYS_DEFAULT policy group, and
the DEPT table in the SCOTT schema has a different SYS_DEFAULT policy group associated
with it.
Creating a Driving Context
Create the context:
Create the procedure that sets the context:
CREATE OR REPLACE PACKAGE BODY secure.apps_cxt_pkg

PROCEDURE set_driver( policy_group VARCHAR2)...
APP_DRIVER
SECURE.APPS_CXT_PKG
Creating a Driving Context

A driving application context is a context that holds at least one attribute. This attribute is used to
determine which group of policies will be applied. The driving application context is set by the
application that is accessing the data. The Oracle data server references the driving application
context to determine which policy group to apply.
Create a context and a trusted package to set the attributes in the same way as described in the
lesson titled Using Application Contexts. The driving context holds the name of the active
application context. The name of the attribute is arbitrary, but it is specified in the
ADD_POLICY_CONTEXT procedure. The value returned from the driving context attribute
defines the driving context of the policy.
The following steps can be performed in any order.
Creating a Context
Create a namespace for the driving context and associate it with a trusted package. For example:
CREATE CONTEXT app_driver USING secure.apps_cxt_pkg;
CREATE CONTEXT app_driver

USING secure.apps_cxt_pkg;
Creating a Driving Context (continued)

Creating the Procedure That Sets the Context
Create the package that administers the driving context. In this procedure, determine the
current application. Techniques for determining the application include the following:
If the application server determines the application, check the proxy.
If the user must be in an application table to use the application, set the application only
after verifying that the user exists in that table.
CREATE OR REPLACE PACKAGE BODY secure.apps_cxt_pkg
PROCEDURE set_driver ( policy_group varchar2 )
BEGIN
('APPS', 'ACTIVE_APP', policy_group );
END;
END;
If the driving context is a policy group with policies, all enabled policies from that
policy group are applied, along with all policies from the SYS_DEFAULT policy group.
In this example, the context is set to the parameter passed to the procedure:
Making the Context a Driving Context
dbms_rls.add_policy_context(
object_schema =>'OE',
object_name => 'ORDERS' ,
namespace => 'APP_DRIVER',
attribute => 'ACTIVE_APP')
APP_DRIVER
Orders

Associating the Driving Context with a Table
The ADD_POLICY_CONTEXT procedure in the DBMS_RLS package makes a context a driving
application context. The driving context enforces the policies. It is the driving context that
determines which application is running.
When using this procedure, consider the following guidelines:
The driving context can be local or accessed globally.
If the driving context is NULL, policies from all policy groups are used.
There must be at least one driving context defined for each object that has FGAC policies;
otherwise, all policies for the object are executed.
Adding multiple contexts to the same object causes policies from multiple policy groups to
be enforced.
Define the driving context for the ORDERS table:
DBMS_RLS.ADD_POLICY_CONTEXT
('OE', 'ORDERS' , 'APP_DRIVER', 'ACTIVE_APP');
Associate the driving context with a table:
CREATE OR REPLACE PACKAGE oe_context IS

PROCEDURE set_cust_id;
END;
/
CREATE OR REPLACE PACKAGE BODY oe_context IS
PROCEDURE set_cust_id
IS
v_cust_id NUMBER;
BEGIN
DBMS_SESSION.SET_CONTEXT('oe', 'cust_id', v_cust_id);
apps_context.set_driver('OE_GRP');-- set the driver
EXCEPTION
apps_context.set_driver('XX'); -- set the driver
END;
END;
/
The OE_CONTEXT.SET_CUST_ID procedure is called when the order-entry application is

entered. If the user is a valid customer, the OE.CUST_ID and APPS.ACTIVE_APP context
attributes are set. If not, the driver is set to an invalid driving context that causes an error,
preventing the user from accessing any rows.
Instead of an invalid context, you can create a driving context that references a group containing a
policy that always returns the 1=2 predicate, which is always FALSE, preventing access to any
rows.
Making the Context a Driving Context (continued)

Modify the function that sets the predicate. The driving context is set after the user is
authenticated as a valid user for the application.
Creating a Policy Group

Create the OE_GRP group:
dbms_rls.create_policy_group(
object_schema =>'OE',
object_name => 'ORDERS',
policy_group => 'OE_GRP' );
Create the AC_GRP group:
dbms_rls.create_policy_group
( 'OE', 'ORDERS', 'AC_GRP' );
Creating a Policy Group

Each policy group must have a unique name for each table. No table can have two policy groups
with the same name. The CREATE_POLICY_GROUP procedure of the DBMS_RLS package
creates the policy group and associates it with a table or view.
This example creates the OE_GRP and AC_GRP groups:
DBMS_RLS.CREATE_POLICY_GROUP('OE', 'ORDERS', 'OE');
DBMS_RLS.CREATE_POLICY_GROUP('OE', 'ORDERS', 'AC');

Syntax
PROCEDURE create_policy_group (
object_schema
IN
VARCHAR2 := NULL,
object_name
IN
VARCHAR2 := NULL,
policy_group
IN
VARCHAR2 );
where:
OBJECT_SCHEMA is the owner of the table or view that the policy group is applied to; the
current user is the default.
OBJECT_NAME is the name of the table or view that the policy group is applied to.
POLICY_NAME is the name of the policy group.
Adding a Policy to a Group
dbms_rls.add_grouped_policy (
object_schema
=> 'oe',
object_name
=> 'orders',
policy_group
=> 'oe_grp',
policy_name
=> 'oe_security',
function_schema => 'sec',
policy_function => 'oe_context');
2. Add the AC_SECURITY policy to the AC_GRP group:

dbms_rls.add_grouped_policy (
'oe', 'orders', 'ac_grp', 'ac_security',
'sec', 'ac_context');
Adding a Policy to a Group

When you create a policy that is part of a policy group, use the ADD_GROUPED_POLICY
procedure of the DBMS_RLS package, instead of the ADD_POLICY procedure.
The first step in the slide adds a policy named OE_SECURITY to the OE_GRP policy group. The
SEC.OE_CONTEXT function returns the predicate to enforce security on the OE.ORDERS table.
The second step adds a policy named AC_SECURITY to the AC_GRP policy group. The
SEC.AC_CONTEXT function returns the predicate to enforce security on the OE.ORDERS table.
You must also create the appropriate security functions.
1. Add the OE_SECURITY policy to the OE_GRP group:
Adding a Policy to a Group (continued)

ADD_GROUPED_POLICY
This procedure adds a policy for a table or view and associates it with a policy group. The
policy group must have been created by using the CREATE_POLICY_GROUP procedure. The
policy name must be unique within a policy group for a specific object.
DBMS_RLS.ADD_GROUPED_POLICY(
object_schema
VARCHAR2,
object_name
VARCHAR2,
policy_group
VARCHAR2,
policy_name
VARCHAR2,
function_schema VARCHAR2,
policy_function VARCHAR2,
statement_types VARCHAR2,
update_check
BOOLEAN,
enabled
BOOLEAN,
static_policy
IN BOOLEAN FALSE,
policy_type
IN BINARY_INTEGER NULL,
long_predicate IN BOOLEAN FALSE,
sec_relevant_cols IN VARCHAR2);
The DBMS_RLS package contains the following procedures for managing grouped policies:
ADD_GROUPED_POLICY
DROP_GROUPED_POLICY
ENABLE_GROUPED_POLICY
DISABLE_GROUPED_POLICY
REFRESH_GROUPED_POLICY
CREATE_POLICY_GROUP
DELETE_POLICY_GROUP
For the specifications for these procedures and usage notes, refer to the PL/SQL Packages and
Types Reference manual.
It has the following specification:
Guidelines for policies and context

Building predicates and policies for best performance
Using import and export with FGAC or VPD
Using policy views
Best Practices for VPD
Guidelines for Policies and Context
Restrict SELECT and data manipulation language (DML)

commands with the same policy.
If there is no context, SYS_CONTEXT returns NULL.
A policy may not select from a table protected by the
policy.
Avoid recursive contexts.
Look in the session trace file to resolve errors.
Guidelines for Policies and Context

Restrict with the Same Policy
If you do not restrict all DML statements, you can get unexpected results.
For example, if you restrict only the SELECT statement, the customer issues this query to count
the rows in the table:
SQL> SELECT COUNT(*)
2
FROM oe.orders
3
GROUP BY customer_id;
COUNT(*)
---------1
However, if the customer updates the table, he or she can access all the rows in the table, as in the
following:
SQL> UPDATE oe.orders
2
SET sales_rep_id = 152;
107 rows updated.
If you apply different policies or predicates for different statement types on the same user and
table, be aware of this implication.
A policy for a table or view adds a predicate to every SQL statement executed against the table or
view. A SELECT statement against that table or view cannot be executed from within the policy.
Avoid Recursive Contexts
If the procedure that sets the application context executes a SELECT statement from a table, and
the policy on the table uses that application context to set the predicate, the SELECT statement
will fail. For example, if the users employee ID is used to set the application context by selecting
from the EMPLOYEES table when the user logs on, and a policy uses that application context to
set a predicate controlling access to the EMPLOYEES table, the SELECT statement returns no
rows. This is because the application context attributes are not set. To avoid this problem, access
the EMPLOYEES table by using the privileges of a user that has the EXEMPT ACCESS POLICY
system privilege.
Error Handling
To resolve the error message:
ORA-28112: failed to execute policy
look in the trace file for the session. The following trace file includes the PLS-00306 error,
which means that the wrong number of arguments were passed to the security function. Tracing of
errors is automatic. There are no tracing parameters required to enable this behavior.
*** 2010-01-29 11:27:43.478
------------------------------------------------------Policy function execution error:
Logon user
: TEST
Table/View
: TEST.TAB
Policy name
: TAB_RLS_POLICY
Policy function: TEST.TAB_SECURITY
ORA-06550: line 1, column 15:
PLS-00306: wrong number or types of arguments in call to
'TAB_SECURITY'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
Guidelines for Policies and Context (continued)

Missing Contexts
If user BOB has SELECT privileges on the OE.ORDERS table, but he does not have a CUST_ID
set properly in the OE.CUSTOMERS table, his OE.CUST_ID context attribute is null and the
predicate is evaluated as CUSTOMER_ID = NULL. This evaluates to NULL and prevents BOB
from accessing any rows in the table. Also, if BOB is not supposed to have access, be sure that an
exception does not leave the predicate set for a previous user.
SELECT Restriction
For best performance:

Consider indexing the column in the predicate.
Do not use subqueries in the predicate.
Do not use literals in the predicate.
Use STATIC_POLICY=TRUE when possible.
Use DBMS_RLS.STATIC or SHARED_STATIC when
possible.
Policy Performance
Index the Column in the Predicate
Because the columns used in the predicate are used to access the table, you may be able to
improve query performance by indexing these columns.
Example: The predicate returned is:
customer_id = SYS_CONTEXT('oe', 'cust_id')
The optimizer could use an index on OE.CUSTOMER_ID.

Do Not Use Subqueries in the Predicate
To avoid the overhead of a subquery, do not include it in the predicate. Instead, perform the query
and use the result to set a context and use the context in the predicate.
The correct code is as follows:
Set the context value with the query:
DBMS_SESSION.SET_CONTEXT('oe', 'cust_id', v_cust_id);
From the security function, return this predicate, which uses the context:
customer_id = SYS_CONTEXT('oe', 'cust_id')
Policy Performance
Policy Performance (continued)

Do not bypass the context and code the predicate with a subquery:
customer_id = ( SELECT customer_id
FROM oe.customers
SYS_CONTEXT('USERENV', 'SESSION_USER' )
This code causes the subquery to be performed every time the table is accessed.
Literal values in the predicate could make every SQL statement issued have a different predicate.
The SQL cursors could not be shared, so there would be an additional overhead for parsing.
Because the call to SYS_CONTEXT is the same for all predicates, the SQL statement cursors can
be shared by multiple users. The use of application context in a fine-grained access control
package effectively gives you a bind variable in a parsed statement.
For example, a predicate applied to the ORDERS table uses the actual customer identifier, as in
the following:
cust_id = 12345
Each customer that logs on gets a different predicate, and because each predicate is different, the
cursor could not be shared.
Static Policy and Policy Type Parameters
Always specify the frequency that the policy needs to be evaluated by using either the
STATIC_POLICY policy parameter or set a POLICY_TYPE when using the ADD_POLICY
procedure. Reduce the execution overhead by specifying STATIC_POLICY=TRUE to indicate
that the policy function always returns the same predicate. As an alternative, specify
POLICY_TYPE for DBMS_RLS.STATIC or DBMS_RLS.SHARED_STATIC. Setting
POLICY_TYPE overrides the setting of the STATIC_POLICY parameter. If neither are set, the
default is a dynamic policy that is evaluated for every DML.
Do Not Use Literals in the Predicate
Export and Import
If a user attempts to export a table with fine-grained

access policies enabled, only those rows that the exporter
is privileged to read are exported.
Policies are not enforced in the DIRECT path export; only
SYS or a user with the EXP_FULL_DATABASE role enabled
can perform the DIRECT path export.
Policies are not enforced for SYS or any user with the
EXEMPT ACCESS POLICY privilege.
Export and Import

Export and Import, and Fine-Grained Access Control
You can export tables with fine-grained access policies enabled. When doing so, consider the
following:
To restore the policies, the user who imports from an export file containing such tables must
have the EXECUTE privilege on the DBMS_RLS package so that the security policies of the
tables can be reinstated.
If a user without the right privileges attempts to export a table with fine-grained access
policies enabled, only those rows that the exporter is privileged to read are exported.
Policies are not enforced for the DIRECT path export. Only SYS or a user with the
EXPORT_FULL_DATABASE role enabled can perform the DIRECT path export.
Policies are not enforced for SYS at any time, or any user who has been granted the
EXEMPT ACCESS POLICY privilege.
For export and import, consider the following guidelines:

To restore the policies, the user must have the EXECUTE
privilege on the DBMS_RLS package.
Policy views list security policies: *_POLICIES
Policy context views list driving contexts:

*_POLICY_CONTEXTS
Policy group views list policy groups: *_POLICY_GROUPS
Dynamic performance views list active policies:

V$VPD_POLICY
GV$VPD_POLICY
Policy Views
Security Policy Views
*_POLICIES: Views with information provided in the ADD_POLICIES procedure
Policy Context Views
*_POLICY_CONTEXTS: All driving contexts defined for tables or views in the scope of
the view. The columns have the information provided in the DBMS_RLS.ADD_POLICIES
procedure.
Policy Group Views
*_POLICY_GROUPS: All policy groups defined for any tables or views in the scope of the
view. The columns are the same as the parameters passed to
DBMS_RLS.CREATE_POLICY_GROUP .
Dynamic Performance Views
V$VPD_POLICY: All the fine-grained security policies and predicates associated with the
cursors currently in the library cache
GV$VPD_POLICY: The same information as V$VPD_POLICY, except that this view is
used with multiple instances with Real Application Clusters
For more details, see Oracle Database Reference.
Policy Views
Checking for Policies Applied

to SQL Statements
SQL> SELECT distinct policy, predicate, sql_text
FROM v$vpd_policy p,
WHERE s.child_address = p.address;
POLICY
v$sql s
PREDICATE
------------ --------------------------------------SQL_TEXT
-------------------------------------------------------OE_POLICY
1=1
select * from oe.orders

OE_POLICY
sales_rep_id = SYS_CONTEXT('hrapp', 'id')
select * from oe.orders
Checking for Policies Applied to SQL Statements

V$VPD_POLICY contains the policies that are applied to SQL statements. To find which policy
corresponds to a particular SQL statement, perform the following query:
SELECT distinct policy, predicate, sql_text
FROM v$vpd_policy p, v$sql s
WHERE s.child_address = p.address;
This query is executed after a user LSMITH (a sales representative) and the OE user accessed the
ORDERS table with the following statement:
SELECT count(*) FROM oe.orders;
There are no group policies in effect at the time of the queries.

The query shown in the slide and the V$VPD_POLICY view are helpful when tuning statements
that are being rewritten by VPD policies.

Describe VPD
Implement VPD
Group policies
Summary

Creating a policy function
Enabling the policy
Testing the policy
Implementing a Virtual Private Database Policy

Oracle Label Security Concepts
Objectives
Label concepts
Access mediation
Determine when to use Oracle Label Security
Objectives
This lesson is an introduction to Oracle Label Security. Implementation of Oracle Label Security is
presented in the next lesson. Additional information can be found in the Oracle Label Security
Administrators Guide.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 2

following:
Describe Oracle Label Security
Access Control: Overview
Allows only grant and revoke

Controls access on an entire object
Controls access by privilege
Row-level security
Allows sophisticated access rules
Supplements DAC
Is provided by Virtual Private Database and Oracle Label
Security
DAC and row-level security dictate row access.
Access Control: Overview

Access control defines the users right to read, insert, update, and delete information. Every object in
the Oracle database is protected by discretionary access control (DAC).
Discretionary access control: DAC provides SELECT, INSERT, UPDATE, and DELETE
privileges on an object to a user. The user may be granted one or more of these privileges. The
limitation of DAC is that it gives access to all the data in a table or allows access to none of the
data in the table.
Note: There are more object privileges than are mentioned here, and some privileges can be
used to restrict access on a column basis.
Row-level security: This enables sophisticated access control rules beyond those of DAC by
using data in the row. Virtual Private Database (VPD) and Oracle Label Security are available to
control row-level security.
Row-level access control depends first on the basic DAC policy. DAC and row-level security
together dictate the criteria, controlling whether access to a row is permitted or denied.
Oracle Database Vault without using row-level security extends DAC in ways that row-level security
cannot. Oracle Database Vault enforces separation of duties, and restricts users including those with
the powerful ANY privileges from seeing or modifying data in protected realms.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 3
Oracle provides two complementary access control models:

Discretionary access control (DAC)
Discretionary Access Control
Joe
REVOKE SELECT ON emp FROM fred;
Fred
Discretionary Access Control

Access to every table in the database is controlled by DAC. In the example in the slide, Joe issues a
SELECT statement against the EMP table. Because Joe has received the SELECT privileges on the
EMP table, he sees a result returned. Because Freds access privilege is revoked, when he issues a
SELECT statement against the EMP table, he sees the error message Table or view does not exist.
The granularity of DAC is at the object level by privilege. There are four basic privileges (SELECT,
INSERT, UPDATE, and DELETE) plus several more that depend on the object type. In most
databases, DAC is sufficient to handle the access control needs.
If viewing certain columns is limited to certain individuals or job functions, DAC can handle it. Place
those columns in a separate table and join on a key value, or hide the columns from all but authorized
users by defining a view of all but the sensitive columns.
Even in situations where DAC does not meet the needs for access control, there are seldom more
than a few tables that require row-level access control. If the data in a row determines who is allowed
to access the row, DAC is inadequate. For these situations, row-level access control is required.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 4
GRANT SELECT ON emp TO joe;
SELECT object Discretionary

privilege granted? access control
User clearance
dominates
data row label?
Confidential
OLS access
mediation
X
X
Location
Storage
OLS Label
Nevada
Conventional
Sensitive
Montana
Nuclear
Highly Sens.
Colorado
Medical
Confidential

Oracle Label Security does not bypass DAC but supplements it. For all users making a SQL request,
DAC is applied first. DAC denies access to all users without the correct privileges. After DAC is
applied, the Oracle database server checks whether an Oracle Label Security policy is applied.
Additional predicates can easily be added to the policies to further refine access because Oracle
Label Security is built on the same infrastructure as VPD.
The objects in the database can have rows that are labeled. Access to rows is restricted on the basis of
Oracle Label Security authorizations. There are a few conditions under which Oracle Label Security
is not enforced. It is not enforced during DIRECT path export and cannot be applied to objects in the
SYS schema. Note also that the SYS user and users with the special EXEMPT ACCESS
POLICY database privilege are exempt from both Oracle Label Security and VPD enforcement. The
EXEMPT ACCESS POLICY privilege is a powerful database privilege and should be managed
carefully.
If your site requires that the SYS user and users with DBA-type privileges are not allowed to view
application data, Oracle Database Vault has the facilities to meet this requirement. Oracle Database
Vault and Oracle Label Security are designed to work together
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 5
SQL request
How Sensitivity Labels Are Used
Authorizations
Access mediation
Data
Labels
Data sensitivity
Secret
How Sensitivity Labels Are Used

Specifying data sensitivity: Labels are used to specify the sensitivity of data. These are known as
data labels. Each row has a data label. In the example in the slide, the row has a label of
Secret::.
Authorizations: Labels are used to specify a users security clearance or label authorization.
Each user is assigned a set of labels that indicate the range of data labels that the user is allowed
to read and write. In the example, the user has a label of Top Secret::.
Access mediation: The user label and the data labels are compared in a process known as access
mediation that uses a set of algorithms supplied by Oracle Label Security. The user is allowed to
view the row when his or her label dominates the data label of that row; otherwise, he or she is
not able to see the row. In the example, the users label of Top Secret:: dominates the
data label of Secret:: and access is allowed. Whether a particular label dominates another
is determined by the security administrator when the labels are created.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 6
Users Top Secret
To install Oracle Label Security, perform the following steps:

1. Use the Custom Install option of Oracle Universal Installer
(OUI) to add Oracle Label Security components.
2. Use the Database Configuration Assistant (DBCA) to
configure Oracle Label Security.
3. Use either Enterprise Manager Grid Control or Database
Control to manage the Label Security policies.
Installing Oracle Label Security

To install Oracle Label Security, perform the following steps:
1. Use the OUI Custom Install option.
Use the Custom Install option of Oracle Universal Installer (OUI) to add the Label Security
option to a base installation.
2. Use the DBCA to configure Oracle Label Security.
Oracle highly recommends that you use the Database Configuration Assistant (DBCA) to
configure the Label Security option. This configuration creates the LBACSYS user and
LBAC_DBA role, and more than 200 objects. The database instance must be restarted after the
configuration is complete.
3. Use Enterprise Manager to manage the Label Security policies.
Enterprise Manager has pages that enable you to create policies and manage labels and policies.
These pages are available from the Security section under the Server tab on the database home
page of database control in Oracle 11g. The same pages can be seen in Grid Control by
navigating to a target database, and clicking the Administration tab.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 7
Installing Oracle Label Security
Oracle Label Security is used as an alternative to discretionary

access control.
a. True
b. False
Answer: b
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 8
Quiz
Oracle Label Security provides:

Row-level security based on Virtual Private Database (VPD)
technology
A complete infrastructure for managing label security
policies, sensitivity labels, and user security clearances
Enterprise Manager pages containing a graphical user
interface for managing Oracle Label Security
A complete command-line interface to supplement the
Enterprise Manager interface
Integration with Oracle Identity Management starting in
Oracle Database 10g Release 1
Oracle Label Security: Features

Oracle Label Security is a packaged system that provides an easy-to-implement row-level security
solution, where access control is based on data sensitivity. Security requirements are complicated by
data restrictions generated by regulatory compliance. Medical data can be viewed only by attending
medical professionals and by the person whose data it is. Nuclear weapon data is restricted to persons
who have the proper security clearance and compartment endorsement. Different users need to see
different data depending on their jobs, positions, or roles. When this data can be separated into
different tables, DAC can provide the required granularity. When the data restrictions are based on
row and column values, the need for fine-grained access becomes obvious.
Row-Level Security
Oracle Label Security is built on the fine-grained access control technology of VPD. The major
advantage of using Oracle Label Security is that OLS is a complete system. It is a ready-to-use VPD.
Oracle Label Security provides sophisticated functions and procedures for evaluating and comparing
sensitivity labels. It provides a sophisticated infrastructure for storing and managing sensitivity labels
and user security clearances.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 9
Oracle Label Security: Features
The previous releases of Oracle Label Security have relied on the Oracle database as the central
repository for policy and user label authorizations. This architecture took advantage of the scalability
and high availability of the Oracle database, but did not make use of the Oracle Identity Management
infrastructure, which includes Oracle Internet Directory. This directory is part of the Oracle Identity
Management platform. Integrating your installation of Oracle Label Security with Oracle Internet
Directory allows label authorizations to be part of your standard provisioning process.
For sites that use Oracle Internet Directory, database servers retrieve Oracle Label Security policy
information from the directory. Administrators use the olsadmintool policy administration tool
to operate directly on the directory to insert, alter, or remove metadata as needed. Because enterprise
users can log in to multiple databases by using the credentials stored in Oracle Internet Directory, it
is logical to store their Oracle Label Security policy authorizations and privileges there as well. An
administrator can then modify these authorizations and privileges simply by updating these metadata
in the directory. (Other aspects of managing enterprise users are performed through the Oracle
Identity Management Provisioning console.)
For distributed databases, centralized policy management removes the need for replicating policies
because the appropriate policy information is available in the directory. Policy changes in the
directory are synchronized with policy information in the databases by means of the Directory
Integration Platform and are effective without further effort.
The following Oracle Label Security information is stored in the directory:
Policy information, namely, policy name, column name, policy enforcement options, and audit
options
User profiles identifying their labels and privileges
Policy label components: levels, compartments, and groups
Policy data labels
The database-specific metadata is not stored in the directory. The examples include:
Lists of schemas or tables, with associated policy information
Program units, with associated policy privileges
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 10
Oracle Label Security: Features (continued)

Integration with Oracle Identity Management
Comparing Oracle Label Security

and VPD
VPD provides:
Oracle Label Security provides:

A system evaluated under Common Criteria EAL 4
All required packages for access mediation
Complete data dictionary for managing policies, sensitivity
labels, and user clearances
A complete user interface for managing Oracle Label Security
Integration with Oracle Identity Management
Comparing Oracle Label Security and VPD

The VPD provides an API for implementing row-level security by using application context. The
policy procedures, the application context, and the rules for control access to the data must be created
by developers.
Oracle Label Security provides a complete system:
Access rules: Oracle Label Security comes with predefined access rules. These rules meet the
requirements of many applications without modification. These rules can be customized to meet
special circumstances.
Common Criteria: Oracle Label Security has been evaluated under the International Common
Criteria (ISO 15408) at Evaluation Assurance Level (EAL) 4. The Common Criteria standard
has superseded the DOD Orange Book standard and other European and Russian standards.
Complete data dictionary: It is provided in the database to manage the aspects of Oracle Label
Security.
A complete user interface: Enterprise Manager provides a graphical interface that allows pointand-click control. The SA_* packages provide a complete command-line interface.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 11
An API for implementing row-level security by using

application context and PL/SQL
Oracle Label Security and VPD Comparison

OLS
Access Control
Based on the WHERE

clause
Compare data labels with user

clearances.
Implemented
With user-programmed
policies
With provided code; no coding

needed
Table changes
No columns added
Data label column added (hidden)
New Data
Classification
None
Automatic
In addition to DAC
Policies automatically
applied
User clearances automatically

applied
Column-level control
Uses column-level VPD
May be used with column-level

VPD
User clearance may be used as a

factor to control access.
Oracle Label Security and VPD Comparison

Oracle Label Security is built on the same technology as that used for the VPD. Oracle Label
Security does not depend on preexisting data attributes as the basis for access control, but depends on
assigned data labels and user clearances. Label Security adds a column to every table protected. This
column can be a hidden column.
Every application of VPD is custom built. VPD provides row-level access control by using
application context and a WHERE clause that is added to every SQL statement. OLS provides the
packages required to implement the customer requirements.
When new data is added to the protected table, OLS assigns data labels based on the user clearance
automatically. If new values are placed in the columns used by VPD, the WHERE clause in the policy
may need to be changed.
OLS is designed to work with column-level VPD and Oracle Database Vault. A column-level policy
may be applied to further restrict column access, and user clearances may be used as factors in
Oracle Database Vault to limit access to schemas and commands.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 12
VPD
Analyzing Application Requirements
The majority of the tables do not require Oracle Label

Security.
Use existing tools when possible.
Do not apply Oracle Label Security to everything.
Identify important application queries where possible.
Discretionary access control (DAC) is sufficient for most

tables:
Database roles
Secure application roles
Stored procedures and functions
Analyzing Application Requirements

Identify the application tables that need Oracle Label Security: Usually, only a very few
tables hold data that requires the protection provided by Oracle Label Security. Do not apply
Oracle Label Security where it is not needed. Use the appropriate security technology for your
situation. The built-in technologies described below frequently meet the business-security
requirements with minimal overhead.
Oracle Label Security has a performance cost. Identify the most resource-intensive application
queries and tune them for use in the Oracle Label Security environment.
Discretionary access control (DAC) is sufficient for most tables: DAC is always applied
before the Oracle Label Security policies. DAC specifies access control privileges at the object
level.
Stored procedures and functions: These can be used to encapsulate objects, allowing the
owner to expose only certain methods of accessing the object. This technique can provide very
tight control over data integrity.
Database roles and secure application roles: These have been covered in the previous lessons.
Oracle Database Vault: This can be used to extend DAC in ways that OLS cannot. Oracle
Database Vault is covered in detail in the course titled Implementing Oracle Database Vault.
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 13
Identify application tables that need Oracle Label Security:
Summary
Label concepts
Access mediation
Determine when to use Oracle Label Security
COMPUTER
IS STRICTLY
PROHIBITED
Oracle
Database
11g: Security
13 - 14

Describe Oracle Label Security
After completing this lesson, you should be able to implement a

simple Oracle Label Security policy by:
Creating policies
Defining data labels
Applying policies to tables
Setting up user authorizations
Objectives
The steps to implement an Oracle Label Security solution are:

1. Develop a strategy to understand the security problem.
2. Analyze the data levels in the application.
3. Create policies.
4. Define data labels.
5. Apply the policies.
6. Assign user authorizations.
7. Review and document your policy decisions.
Implementing an Oracle Label Security Solution

1. Develop a strategy: Talk to the right people. Identify those individuals in your
organization who really understand the business-security problem. Make sure that you
understand the problem before adding additional security to your application.
2. Analyze the data to be protected: Ask the following questions:
- Where does the sensitive data reside in the application (which tables)?
- Who needs access to this data?
- Who owns the data?
- Who should be able to read the data?
- Who should be able to make updates?
This analysis includes a grouping of the user community by access needs:
- Does that grouping follow organizational lines?
- Does it depend on the job function?
This process is repeated for each set of data that is to be protected.
3. Create policies: Name the policies and define the default policy enforcement options.
Implementing an Oracle Label Security Solution
Implementing an Oracle Label Security Solution (continued)

4. Define labels: When the Oracle Label Security policy is applied to a table, a label
column is added to the table. The value in this label column is compared to the access
permissions assigned to the user to determine which users have access to that row. The
labels have three parts: level, compartment, and group. Each of these can be defined
for your site. After the labels have been defined, you must assign the data labels to the
data rows. This is not automatic.
The Data labels must be applied to the table. That means update the rows of the table
by assigning the data label to every row, before the policy is applied. If the data label
column is null, that row will not be accessible.
Note: Label definitions are global. Therefore, two policies in the same database cannot
define the same security label with different values. This means that if you try to run
two Oracle Label Securityenabled applications against the same database, you must
have considered this, or label collisions occur.
5. Apply policies: A policy must be applied to the table to be enforced. Policies can be
administered by users with appropriate privileges, such as a security officer. Policies
can be enforced, disabled, applied, or removed. In a single database, several Oracle
Label Security policies can be protecting data. Each of these policies can be applied to
different tables, and multiple policies may be applied to a single table. To access data,
a user must have label authorizations (or clearances) for all policies protecting that
data. To access any particular row, you must be authorized by all policies protecting
the table containing your desired rows. The security officer must be given specific
permissions to create and administer policies and labels. These actions are performed
by using the Oracle Policy Manager interface or PL/SQL packaged procedures. See the
Oracle Label Security Administrators Guide for a full description of the packages,
procedures, and required privileges.
6. Assign user authorizations: A user authorization is the range of labels that a user can
access. They are created and assigned to the user on the basis of access requirements.
Special privileges are included in this set of authorizations. After the policy has been
applied, no user can access the data without a set of authorizations. This step is
independent of applying the policy; user authorizations may be assigned before or after
the policy is applied.
7. Review and document your policy decisions: This documentation provides a
reference point for future changes and audits. Implementing label security can be
complex. Many seemingly small decisions are made for ease of use or performance.
When these policies are called into question, the documentation saves many hours of
reanalyzing the application.
Create the policy to contain the label information as in the

following example:
Set the Policy name to FACILITY.
Set the Policy label column to FACLAB.
Set the Default access options.
BEGIN
SA_SYSDBA.CREATE_POLICY(
POLICY_NAME =>'FACILITY',
COLUMN_NAME => 'FACLAB',
DEFAULT_OPTIONS =>
'READ_CONTROL,CHECK_CONTROL,LABEL_DEFAULT,HIDE');
END;
Step 3: Create Policies

The first step in setting up Oracle Label Security is to create policies. The named policy is a
container for all the information that is associated with a policy: labels, tables, views, privileges,
and procedures.
Creating the Policy
Create a new Oracle Label Security policy that defines a policy-specific column name and
specifies a set of default policy options. The column is added to every table associated with the
policy. The policy may be created by using Enterprise Manager or PL/SQL as follows:
Syntax
PROCEDURE CREATE_POLICY ( policy_name IN VARCHAR2, column_name
IN VARCHAR2 DEFAULT NULL,
default_options IN VARCHAR2 DEFAULT NULL);
Example
SA_SYSDBA.CREATE_POLICY('FACILITY','FACLAB',
'READ_CONTROL,CHECK_CONTROL,LABEL_DEFAULT,HIDE');
Note: The policy enforcement options can be set at the policy level as shown or at the schema or
table level when the policy is applied.
Step 3: Create Policies
Policy Enforcement Options
Access-control enforcement:
Label-management enforcement:
LABEL_DEFAULT
LABEL_UPDATE
CHECK_CONTROL
Options to override enforcement:

ALL_CONTROL
NO_CONTROL
Policy Enforcement Options

This is a brief introduction to the policy-enforcement options. For more details, see the Oracle
Label Security Administrator Guide.
A basic policy with full enforcement would have the READ_CONTROL, WRITE_CONTROL, and
LABEL_DEFAULT options enforced.
The interaction of the various enforcement options should be well understood for effectively
designing an Oracle Label Security system.
Access-control enforcement controls read and write access to the data. The policies can be set
for each type of data manipulation language (DML):
READ_CONTROL enforces the policy for all queries, controlling which data rows are
accessible for SELECT, UPDATE, and DELETE. If READ_CONTROL is OFF on a policy,
for any table protected by the policy, all rows are accessible to all users.
WRITE_CONTROL determines the ability to insert, update, and delete data in a row. If this
option is active, it enforces INSERT_CONTROL, UPDATE_CONTROL, and
DELETE_CONTROL. You can apply INSERT_CONTROL, UPDATE_CONTROL, and
DELETE_CONTROL separately.
READ_CONTROL
WRITE_CONTROL
Set Policy Enforcement Options at the policy level as shown in the previous slide with the
DEFAULT_OPTIONS parameter. These options will be used unless other options are
specified when the policy is applied to the table or schema.
Note: Table-level options take precedence over the schema-level options.
Policy Enforcement Options (continued)

Label-management enforcement ensures that data labels written for inserted or updated
rows do not violate policies set for such labels:
LABEL_DEFAULT uses the sessions default row label value unless the user explicitly
specifies a label on INSERT.
LABEL_UPDATE applies policy enforcement to the UPDATE operations that set or

change the value of a label attached to a row. The WRITEUP, WRITEDOWN, and
WRITEACROSS privileges are enforced only if the LABEL_UPDATE option is active.
Note that any label function that is in force overrides the LABEL_UPDATE option.
CHECK_CONTROL applies the READ_CONTROL policy enforcement to the INSERT

and UPDATE statements to ensure that the new row label is read-accessible by the user
that is changing the label.
Options to override enforcement can suspend or apply all other enforcement options:
ALL_CONTROL applies all enforcement options.
NO_CONTROL applies no enforcement options. A labeling function or a SQL predicate

can still be applied. In the absence of a label function, data rows that are inserted do
not have a label. If enforcement options are turned on later, the unlabeled rows are not
visible unless the user has the READ or FULL access authorization.
Step 4: Define Labels: Overview

Labels have three parts:
Level
Group (optional)
Compartment (optional)
Every label must have a level.

The label is defined on the basis of the combinations of the
parts.
Step 4: Define Labels: Overview

Each data label can have three parts: a level, one or more compartments, and one or more
groups. Every label must have a level, but the compartment and group portions of the label are
optional. Each level, compartment, and group that will be used in a label must be created before
it can be used in a label.
Defining the required levels, groups, and compartments follows the analysis of the data-security
needs. Each part of the label is defined. The following pages discuss:
Defining levels
Defining groups
Defining compartments
Identifying labels
These levels are part of the label that is assigned to users

and data.
In the example, the SENSITIVE data level has a:
Short name of S
Numeric tag of 300
Defining Levels by Using Enterprise Manager

Every label must have a level defined, and by implication, every row protected by Oracle Label
Security must be assigned to a level. The following are characteristics of levels:
A level is an arbitrary name, such as SENSITIVE or CLASSIFIED. Higher and lower
levels are determined by the tag (the numeric form of the level). The numeric form can
range from 0 through 9999. A user with a higher level can access lower levels. Levels have
ranking determined by the numeric tag.
Assume that only levels are used. A user with a label of SENSITIVE may access data
with a SENSITIVE level or below.
Each policy has its own set of levels.
Defining Levels by Using Enterprise Manager
BEGIN
SA_COMPONENTS.CREATE_LEVEL(
LEVEL_NUMBER => '100',
SHORT_NAME => 'P',
LONG_NAME => 'PUBLIC');
END;
Creating Levels
To define levels, the database administrator (DBA) or security administrator uses the
CREATE_LEVEL procedure of the SA_COMPONENTS package or Enterprise Manager.
Syntax
PROCEDURE CREATE_LEVEL (
policy_name IN VARCHAR2,
level_num IN INTEGER,
short_name IN VARCHAR2,
long_name IN VARCHAR2);
Creating Levels
In the example, for the group WR_FINANCE:

WR_FIN will appear in the group field of the
level:compartment:group label
The parent group is WESTERN REGION
Defining Groups by Using Enterprise Manager

A data label can have zero or more groups assigned to it. Groups are a means of making a
hierarchical assignment. Data assigned to a group can be accessed by a user belonging to that
group or a parent of the group.
In the example, WESTERN_REGION is the parent group to WR_FINANCE and WR_SALES. A
user belonging to the WESTERN_REGION group can access data belonging to either the
WR_FINANCE group or the WR_SALES group. But a user belonging to the WR_SALES group
cannot access data belonging to WR_FINANCE or WESTERN_REGION.
A label can include multiple groups. A user having permission on any of the groups in the data
label is allowed access. The numeric form does not indicate any type of ranking. It does not
indicate a parent-child relationship, or greater or less sensitivity. It controls only the display
order of the short form of the group name in the label character string.
Note: The group access is evaluated after the level is evaluated. All labels have a level. So
access is further restricted by standard groups. Group access does not give access when access
would be denied by the level. (This discussion is limited to standard groups; inverse groups is
outside the scope of this course.)
Defining Groups by Using Enterprise Manager
BEGIN
SA_COMPONENTS.CREATE_GROUP(
GROUP_NUMBER => '1000',
SHORT_NAME => 'WR_SAL',
LONG_NAME => 'WR_SALES',
PARENT_NAME => 'WR');
END;
Creating Groups
To define groups, the DBA or security administrator uses the CREATE_GROUP procedure of the
SA_COMPONENTS package or Enterprise Manager.
Syntax
PROCEDURE CREATE_GROUP (
group_num IN INTEGER,
long_name IN VARCHAR2,
parent_name IN VARCHAR2 DEFAULT NULL);
Example
BEGIN
SA_COMPONENTS.CREATE_GROUP('FACILITY',1000,
'WR','WESTERN_REGION');
'WR_FIN','WR_FINANCE','WR');
'WR_AP','WR_ACCT_PAYABLE','WR_FIN');
END;
Creating Groups
In the example:
Optional compartments are OP, CH, and FIN.
FIN could appear in the compartment field of the
level:compartment:group label.
Example: Label S:OP,CH:
Defining Compartments by Using Enterprise Manager

Compartments provide a finer granularity to the level classification. To access rows with
compartments included in the data label, the user label must include the level and the
compartment. The following are the characteristics of compartments:
Compartments are independent classifications. A data label can have zero or more
compartments assigned to it. For a user to access that row, the user authorization must first
have the correct level and include all the compartments. Compartments can be used to
separate the work of various projects.
In the example, a data row has a label with two compartments: OP and CH. To access the
row, the user must have a label with the same or higher level, and at least the two
compartments (OP and CH).
The numeric tags for compartments do not indicate a higher or lower classification. This
tag only provides a way to order the compartment-name strings in a label. For example,
FIN is not higher than OP, but in a label, OP appears before FIN:
S:OP,FIN
Defining Compartments by Using Enterprise

Manager
BEGIN
SA_COMPONENTS.CREATE_COMPARTMENT(
COMP_NUMBER => '85',
SHORT_NAME => 'FIN',
LONG_NAME => 'Financial');
END;
Creating Compartments
To define compartments, the DBA or security administrator uses the CREATE_COMPARTMENT
procedure of the SA_COMPONENTS package or Enterprise Manager.
Syntax
PROCEDURE CREATE_COMPARTMENT (
comp_num IN INTEGER,
long_name IN VARCHAR2);
Creating Compartments
Identifying Data Labels
LEVEL:COMPARMENT:GROUP
---------------------------------------------SENSITIVE:FINANCIAL,CHEMICAL:WESTERN_REGION
CONFIDENTIAL:FINANCIAL:WR_SALES
SENSITIVE::
HIGHLY_SENSITIVE:FINANCIAL:
SENSITIVE::WESTERN_REGION
Identifying Data Labels

After defining label components, create data labels by combining particular sets of levels,
compartments, and groups. Out of all the possible permutations of label components, specify
those combinations that are actually used as valid data labels in the database. The maximum
length of the short form of the label is 4,000 characters. The short form is used in the
LABEL_VALUE parameter of the CREATE_LABEL procedure.
When a valid data label is created:
The label is automatically designated as a valid data label. This functionality limits the
labels that can be assigned to data. Oracle Label Security can also create valid data labels
dynamically at run time from those components that are predefined in Oracle Internet
Directory. Most users, however, prefer to create the labels manually to limit data-label
proliferation.
A numeric label tag is associated with the text string representing the label. It is this
numeric label tag (not the text string) that is stored in the policy label column of the
protected table. This tag must be unique across all policies in the database. It is a good
practice for performance reasons to set tags for labels of higher sensitivity to a higher
numeric value than tags for labels of lower sensitivity.
Create a set of data labels from the components already

defined.
BEGIN
SA_LABEL_ADMIN.CREATE_LABEL(
LABEL_TAG => '201000',
LABEL_VALUE => 'S::WR');
END;
Creating Data Labels

When the FACILITY policy is created, a role named FACILITY_DBA is also created with the
EXECUTE privilege on several packages owned by LBACSYS.
The DBA or a user who is assigned the <policy>_DBA role can create labels by using the
CREATE_LABEL procedure in the SA_LABEL_ADMIN package or by using Enterprise
Manager. The <policy>_DBA role is created when the policy is created.
Syntax
PROCEDURE CREATE_LABEL (
label_tag IN INTEGER,
label_value IN VARCHAR2,
data_label IN BOOLEAN DEFAULT TRUE);
Example
BEGIN
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',1000,'P');
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',2101,'S::US');
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',3101,'HS::US');
END;
Creating Data Labels
Access Mediation
The user label dominates the data label.

Sensitive: Access Granted
Confidential: Access Granted
The user label does not dominate Highly Sens.: Access Denied
Location
Storage
OLS Label
Nevada
Conventional
Sensitive
Montana
Nuclear
Highly Sens.
Colorado
Medical
Confidential
Sensitive
Access Mediation
The process of comparing user authorization and data label to decide what access is granted is
called access mediation.
There are two types of access mediation for protected tables: read and write. A user can read any
data up to his or her maximum level. Write access is a subset of read access. A user cannot write
lower than his or her minimum level. This controls the users ability to disseminate data by
lowering its sensitivity.
In addition, there are separate lists of compartments and groups for which the user is
authorized that is, for which the user has at least read access. An access flag indicates whether
the user can also write to individual compartments or groups.
You can further customize user data access by granting policy privileges and setting policyenforcement options.
The user is assigned the Sensitive label S::.
Use Enterprise Manager to:

Define and manage labels
Apply the policy to tables or schemas
Assign labels to users
Set user-label privileges
Administering Labels
Oracle Label Security provides administrative interfaces to define and manage the labels used in
a database. You can define labels in an Oracle database by using Oracle Label Security packages
or Enterprise Manager. Initially, you must define the levels, compartments, and groups that
compose the labels, and then you can define the set of valid data labels for the contents of the
database.
You can apply a policy to individual tables in the database, or to entire application schemas.
Finally, assign to each database user the label components (and privileges, if needed) that are
appropriate for the persons job function.
Set the privileges that allow data labels to be changed by certain users, if appropriate. Some sites
may not allow anyone to change a label. Some customers may have specific individuals who are
responsible for reviewing and assigning the appropriate labels.
Users are allowed to change their session label as well as row label, within the range of their
minimum and maximum labels by using the SET_LABEL and SET_ROW_LABEL procedures of
the SA_SESSION package.
Administering Labels
Adding Labels to Data

Labels are defined by the administrator.
Access mediation requires all rows to have labels.
Labels are set on rows.
Adding Labels to Data

The components of the labels have been created. The data labels have been created and marked
as valid. For access mediation to work properly, the individual rows must have a label assigned.
Labels must be defined: The labels that are assigned to data rows must first be created.
There are usually many more permutations of the different components of the labels than
are actually used. Most sites require that the labels that are actually used be created by an
administrator to control the proliferation of labels.
All rows must have labels: When creating policies, the label column for existing rows is
initially NULL. The NULL value does not match any label, so the data is not accessible,
except by users with the FULL access privilege.
Set labels by updating rows: For existing rows, a user who has full access privileges
(typically, the security administrator) updates the rows, setting the label column to the
proper label value for that row. For new rows, users or the application supplies the label,
either directly by a pick list, defaulted to the session labels, or by a policy function.
Step 5: Apply the Policy to a Table

Add the FACILITY policy to the LOCATIONS table.
TABLE_OPTION => NULL implies that the policy default
options are used.
BEGIN
SA_POLICY_ADMIN.APPLY_TABLE_POLICY (
POLICY_NAME => 'FACILITY',
SCHEMA_NAME => 'HR',
TABLE_NAME => 'LOCATIONS',
TABLE_OPTIONS => NULL,
LABEL_FUNCTION => NULL);
END;
Step 5: Apply the Policy to a Table

When you apply a policy to a table or schema, the policy is automatically enabled. To disable a
policy is to turn off its protections, although it is still applied. To enable a policy is to turn on
and enforce its protections for a particular table or schema.
To remove a policy is to take it entirely away from the table or schema. Note, however, that the
policy label column and labels remain in the table unless you explicitly drop them.
Use the APPLY_TABLE_POLICY procedure or Enterprise Manager to add the specified policy
to a table. A policy label column is added to the table if it does not exist, and is set to NULL.
When a policy is applied, it is automatically enabled. The policy enforcement options are
specified with a comma-delimited list in the TABLE_OPTIONS parameter. To change the table
options, labeling function, or predicate, you must first remove the policy, and then reapply it.
Syntax
PROCEDURE APPLY_TABLE_POLICY (
policy_name
IN VARCHAR2,
schema_name
IN VARCHAR2,
table_name
IN VARCHAR2,
table_options
label_function
predicate
IN VARCHAR2 DEFAULT NULL);
A user is assigned:
Maximum and minimum labels
A default session label
A row label for inserts
BEGIN
SA_USER_ADMIN.SET_USER_LABELS (
USER_NAME => 'MYCO_MGR',
MAX_READ_LABEL =>'S::US,EU,ASIA');
END;
Step 6: Assign User Authorization Labels

Users can access data only within the range of their own label authorizations. A user has:
Maximum and minimum labels
A set of authorized compartments
A set of authorized groups (and, implicitly, authorization for any subgroups)
Each user has a session label and a row label. The session label is the particular combination of
levels, compartments, and groups on which a user works at any given time. The user can change
the session label to any combination of components for which he or she is authorized.
When a user writes data without specifying its label, a row label is assigned automatically, using
the users session label. However, the user can set the label for the written row within certain
restrictions on the components of the label that he or she specifies with the
SA_SESSION.SET_ROW_LABEL procedure.
Step 6: Assign User Authorization Labels
Syntax
PROCEDURE SET_USER_LABELS (
policy_name
IN VARCHAR2,
user_name
IN VARCHAR2,
max_read_label
IN VARCHAR2,
max_write_label IN VARCHAR2 DEFAULT
min_write_label IN VARCHAR2 DEFAULT
def_label
IN VARCHAR2 DEFAULT
row_label
IN VARCHAR2 DEFAULT
NULL,
NULL,
NULL,
NULL);
MAX_READ_LABEL: Specifies the label string to be used to initialize the users

maximum authorized read label. It is composed of the users maximum level.
Compartments are authorized for read access, and groups are authorized for read
access.
MAX_WRITE_LABEL: Specifies the label string to be used to initialize the users
maximum authorized write label. It is composed of the users maximum level.
Compartments are authorized for write access, and groups are authorized for write
access. If MAX_WRITE_LABEL is not specified, it is set to MAX_READ_LABEL.
MIN_WRITE_LABEL: Specifies the label string to be used to initialize the users
minimum authorized write label. It contains only the level, with no compartments or
groups. If MIN_WRITE_LABEL is not specified, it is set to the lowest defined level
for the policy, with no compartments or groups.
DEF_LABEL: Is the label string including level, compartments, and groups that
determines the initial session setting for what a user can see. It can be increased by the
user up to MAX_READ_LABEL. If DEF_LABEL is not specified, it is set to
MAX_READ_LABEL.
POLICY_NAME: Specifies the policy
USER_NAME: Specifies the username
ROW_LABEL: Is the label string including level, compartments, and groups put on data
that the user inserts if he or she does not specify the data label as a field in the
INSERT statement. If ROW_LABEL is not specified, it is set to DEF_LABEL, with
only the compartments and groups authorized for write access.
Step 6: Assign User Authorization Labels (continued)

Specify the users initial session label and an initial default row label when setting up user
authorizations. These authorizations are kept in the Oracle Label Security data dictionary
tables for each user. To define user authorizations, use the SA_USER_ADMIN package as in
the following example or the Enterprise Manager interface:
BEGIN
'FACILITY','MYCO_EMP','P');
'FACILITY','MYCO_MGR','S::US,EU,ASIA');
'FACILITY','MYCO_PLANNING','HS::GLOBAL');
END;
Which of the following steps are optional when implementing

Oracle Label Security?
a. Create the policy.
b. Define data label levels.
c. Define data label groups.
d. Define data label compartments.
e. Apply the policy to a table.
f. Assign user authorization labels.
Answer: c, d
Quiz
Oracle Label Security supports these privileges that allow

authorized users to bypass certain parts of the policy.
Set the following privileges with the
SA_USER_ADMIN.SET_USER_PRIVS procedure:
READ
FULL
COMPACCESS
Set PROFILE_ACCESS with the

SA_POLICY_ADMIN.SET_ACCESS_PROFILE procedure.
Oracle Label Security Special User Privileges

The first set of Label Security privileges are set with the
SA_USER_ADMIN.SET_USER_PRIVS procedure.
READ
Allows read access to all data protected by the policy
FULL
Allows full read and write access to all data protected by the policy
COMPACCESS
Allows a session access to data authorized by the rows compartments, independent of the
row groups
PROFILE_ACCESS is set with the SA_POLICY_ADMIN.SET_ACCESS_PROFILE
procedure.
PROFILE_ACCESS: Allows a user to change the Oracle Label Security authorizations and
privileges of the database session to those of the specified user
There are additional special privileges, described in the Oracle Label Security Administrators
Guide.
Oracle Label Security Special User Privileges
Example: READ Privilege
All rows returned
READ
privilege
SELECT
Labeled data rows

Example: READ Privilege

The READ privilege enables the user to bypass the Oracle Label Security policy entirely for read
access to data. A user with the READ privilege can read all data protected by the policy,
regardless of his or her authorizations or session label. The user does not even need to have label
authorizations. However, access mediation is still enforced on the UPDATE, INSERT, and
DELETE operations. A user with the READ privilege can write only to data rows for which he or
she has write access, based on any label authorizations.
Application Uses
Data export
Report generation
Executive management privilege
User-label authorizations
None
Example: FULL Privilege
Labeled data rows
FULL
privilege
Any DML
All rows affected
Example: FULL Privilege

The FULL privilege has the same effect and benefits as the READ privilege, with one difference:
a user with the FULL privilege can also write to all the data. The ability to write effectively
bypasses all Oracle Label Security controls. Oracle Database discretionary access controls still
protect the underlying table. For example, if a user does not have the UPDATE privilege on the
underlying table and attempts to update a table directly with an UPDATE SQL statement, the
statement would fail.
This is a very powerful privilege and should be reserved for only users that require it. A
classifier (someone who reviews data to determine its security classification) would need this
privilege to be allowed to see the data and change the classification freely.
Any
Example: COMPACCESS Privilege
Data label
Compartment = OP, Group=Any
COMPACCESS
privilege
Labeled data rows

Example: COMPACCESS Privilege

The COMPACCESS privilege allows a session to access rows on the basis of the rows
compartments, independent of the row groups. If a row has no compartments, access is
determined by the group authorizations. However, when compartments exist, and access to them
is authorized, the group authorization is bypassed. Level authorizations are still enforced.
As in the example in the slide, if the row has a data label of
Confidential:Operations:Western_Region and the user label is
Confidential:Operations:Central_Region, the user can access the row on the
basis of the compartment. The group is ignored.
This privilege is required only in special situationsfor example, where a compartment is
created for a project that crosses groups but does not include all members of each group.
Compartment = OP
The SA_SESSION.SET_ACCESS_PROFILE function in Oracle

Label Security:
Allows an application session to assume a different Oracle
Label Security authorization
SQL>
SQL>
2
3
connect appuser/mypassword
begin
sa_session.set_access_profile('finance','manager');
end;
Is used when application users do not have real database

accounts
Note: Users who are assigned Oracle Label Security
authorizations do not need to be real database users.
Using the PROFILE_ACCESS Privilege

The SA_SESSION.SET_ACCESS_PROFILE procedure sets the Oracle Label Security
authorizations and privileges of the database session to those of the specified user. (Note that the
originating user retains the PROFILE_ACCESS privilege.)
The user executing the SA_SESSION.SET_ACCESS_PROFILE procedure must have the
PROFILE_ACCESS privilege. Note that the database user (the session user ID) who has logged
in does not change. That user assumes only the authorizations and privileges of the specified
user. By contrast, the Oracle Label Security username is changed.
Shared Schema Support
User accounts defined in Oracle Internet Directory cannot be given individual Oracle Label
Security authorizations. However, authorizations can be given to the shared schema to which the
directory users are mapped.
The Oracle Label Security SET_ACCESS_PROFILE function can be used programmatically to
set the label authorization profile after a user has been authenticated and mapped to a shared
schema. Oracle Label Security does not enforce a mapping between users who are given label
authorizations in Oracle Label Security and actual database users.
Using the PROFILE_ACCESS Privilege
This administrative procedure is useful for various tasks:

With SET_ACCESS_PROFILE, the administrator can see the result of the authorization
and privilege settings for a particular user.
Applications that have proxy accounts connect as (and assume the identity of) application
users for purposes of accessing labeled data. With the SET_ACCESS_PROFILE privilege,
the proxy account can act on behalf of application users.
Syntax
PROCEDURE SET_ACCESS_PROFILE
(policy_name IN VARCHAR2,
user_name IN VARCHAR2);
Using the PROFILE_ACCESS Privilege (continued)
Trusted stored package units can extend the privileges of users

in a specific and controlled manner.
To create a trusted stored package unit, you must:
Have the special <policy>_DBA role
Grant the Oracle Label Security privileges to a program

unit
Use Enterprise Manager or the SA_USER_ADMIN package
to grant privileges
SQL>
2>
3>
4>
5>
EXECUTE SA_USER_ADMIN.SET_PROG_PRIVS(POLICY_NAME=>'HR',SCHEMA_NAME=>'MYSCHEMA',PROGRAM_UNIT_NAME =>'SUM_PURCHASES',PRIVILEGE=>'READ');

Trusted Stored Package Units

A trusted stored program unit is a stored procedure, function, or package that has been granted
one or more Oracle Label Security privileges. Trusted stored program units are typically used to
enable users to downgrade information in a controlled manner, or update data at several labels.
This is the optimal way in which users can be enabled to access data beyond their authorization.
To grant privileges to a stored program unit, you must have the special <policy>_DBA role
(where policy is the name of a policy) and the EXECUTE permission on the program unit.
Use either Enterprise Manager or the SA_USER_ADMIN package to grant privileges to a
program unit. The SA_USER_ADMIN.SET_PROG_PRIVS procedure sets policy-specific
privileges for program units.
In the example on the slide, the SUM_PURCHASES procedure has been granted the READ
privilege. When the SUM_PURCHASES procedure is called, it executes with the READ privilege
as well as the current users Oracle Label Security privileges. This allows the total purchases to
be calculated.
Trusted Stored Package Units
Only rows with labels authorized for read access are

exported.
The HIDE property is not exported.
The LBACSYS schema cannot be exported.
Exporting with Oracle Label Security

Only rows with labels authorized for read access are exported. To export all the data, the user
must be granted the READ or FULL access. A user with the EXEMPT ACCESS POLICY
privilege can also export all the data.
The HIDE property is not exported. When protected tables are exported, the label columns in
those tables are also exported (as numeric values). However, if a label column is hidden, it is
exported as a normal, unhidden column.
The LBACSYS schema cannot be exported due to the use of opaque types in Oracle Label
Security. An export of the entire database (the FULL=Y parameter) with Oracle Label Security
installed can be performed, except that the LBACSYS schema would not be exported. One
option is to maintain the policy on the production side from the beginning with scripts.
Exporting with Oracle Label Security
Importing with Oracle Label Security

Precreate Oracle Label Security policies and tables.
Labels and tag values must be the same.
Importing with Oracle Label Security

To use the import utility with Oracle Label Security, you must prepare the import database and
ensure that the import user has proper authorizations.
Preparing the Import Database
1. Install Oracle Label Security.
2. Create any Oracle Label Security policies that protect the data to be imported. The policies
must use the same column names as in the export database.
3. In the import database, define all the label components and individual labels used in the
tables being imported. Tag values assigned to the policy labels in each database must be
the same.
Verifying Import User Authorizations
To successfully import data under Oracle Label Security, the user running the import operation
must be authorized for all the labels required to insert the data and labels contained in the export
file. The following requirements must be met:
Requirement 1: The user must have the <policy>_DBA role for all policies with data
being imported. After each schema or table is imported, any policies from the export
database are reapplied to the imported objects.
Requirement 2: The user must have the ability to write all rows that have been exported.
Limit policies to the required tables.

Plan a label tag strategy.
Analyze the LBACSYS schema.
Consider adding a label column to the existing indexes.

Consider applying a bitmap index on the label column.
Partition on the basis of the label.
Allow time to tune your application after applying Oracle
Label Security.
Performance Tips
Limit policies to required tables: In most cases, only a small subset of the tables in a
database require row-level security. Carefully identify these tables and limit the policies to
these.
Warning: The policies you add will directly affect performance. Use them wisely
Planning a Label Tag Strategy: For optimal performance, you can plan a strategy for
assigning values to label tags. In general, it is best to assign higher numeric values to labels
with higher sensitivity levels. Usually, many more users can see data at comparatively low
levels; fewer users at higher levels can see many levels of data.
With READ_CONTROL set, Oracle Label Security generates a predicate that uses a
BETWEEN clause to restrict the rows to be processed by the query. If the higher-sensitivity
labels do not have a higher label tag than the lower-sensitivity labels, the query potentially
examines a larger set of rows. This affects performance by requiring more reads.
Analyzing the LBACSYS schema: Run the DBMS_STATS.GATHER_SCHEMA_STATS
procedure on the LBACSYS schema, so that the cost-based optimizer can improve
execution plans on queries. Having the statistic for the Oracle Label Security data
dictionary tables improves Oracle Label Security performance.
Performance Tips
Performance Tips (continued)

Indexing the Policy Label Column: Create a bitmap index on the policy label column
on the basis of the number of distinct values.
Partitioning on the Basis of the Label: If you are using a numeric ordering strategy
with the numeric label tags that you have applied to the labels, you can use this as a
basis for data partitioning. Depending on the application, partitioning data on the basis
of label values may or may not be useful.

Creating policies
Defining labels
Setting up user authorizations
Applying policies to tables
Summary

Creating a label security solution for a given scenario
Creating policies
Creating labels
Applying policies
Testing access control
Copyright 2010, Oracle. All rights reserved.
After completing this lesson, you should be able to use the

Data Masking Pack to:
Create masking formats
Manage the format library
Mask sensitive and confidential data
Objectives
What is data masking? Data masking is the process of

replacing sensitive information with realistic data based on
masking rules.
Why use data masking? Use data masking so that data
can be shared with nonproduction users such as testing
companies.
Data Masking: Overview

A number of regulations mandate that company confidential, sensitive, and personally
identifiable data must be protected and access to this data must be restricted.
There is often a need to provide production data, or realistic looking data to in-house developers
and testing organizations during application development.
Data masking is a way to meet these two conflicting needs. Data masking is the act of
anonymizing customer, financial, or company confidential data to create new, legible data,
which retains the original datas properties, such as width, type, and format.
Data Masking: Overview
Understanding Data Masking

LAST_NAME
DEPARTMENT_ID
PHONE_NUMBER
100 King
90 515.123.4567
105 Austin
60 590.423.4569
110 Chen
100 515.124.4269
EMPLOYEE_ID
LAST_NAME
DEPARTMENT_ID
PHONE_NUMBER
468 Jefferies
90 510.555.1256
975 Smith
60 650.555.9753
396 Allen
100 925.555.3597
Understanding Data Masking

In the example in the slide, three columns of the HR.EMPLOYEES table have been masked so
that the data can be provided for testing or development without compromising the security of
the information.
EMPLOYEE_ID
Implement data masking in an Oracle database by using the

Data Masking Pack:
Separately licensed Oracle Enterprise Manager
Management Pack
Available with
Enterprise Manager Grid Control
Enterprise Manager Database Control 11g Release 2

The Data Masking Pack is a separately licensed Oracle Enterprise Manager management pack
available with Oracle Enterprise Manager Grid Control and Oracle Enterprise Manager Database
Control 11g Release 2.
Note: Although management packs may be included in product CDs or downloads, or described
in the documentation that you receive, this does not authorize you to use them without the
appropriate licenses.
Accessing the Data Masking Pack

Data Masking section on the Schema page
Data Masking Definitions and Data Masking Format
Library links on Databases page in Grid Control
Accessing the Data Masking Pack

You can access the Data Masking Pack on the Schema page of Enterprise Manager Database
Control and Enterprise Manager Grid Control.
The Data Masking Pack can also be accessed through the Data Masking Format Library and
Data Masking Definitions links on the Databases page in Enterprise Manager Grid Control.
Uses an irreversible process to replace the sensitive

database based on masking rules
Ensures that the original data cannot be retrieved,
recovered, or restored
Enables you to define a central definition for common data
masking formats to be used with all databases
Data Masking Pack: Features

The Data Masking Pack can help organizations comply with privacy and confidentiality laws by
masking sensitive or confidential data in development, testing, and staging environments. The
Data Masking Pack uses an irreversible process to replace sensitive data with realistic-looking,
scrubbed data based on masking rules and ensures that the original data cannot be retrieved,
recovered, or restored. By using the Data Masking Packs central definition for common data
masking formats, you can apply data privacy rules consistently to all production data and ensure
compliance with regulations.
Data Masking Pack: Features
Create predefined mask formats for all common regulated

information.
Apply predefined mask formats to sensitive data
regardless of which database the data resides in.
Ensure that sensitive data is consistently masked across
the organization.
Data Masking: Best Practices

Create a library of data format masks that can be used consistently across databases.
Data Masking: Best Practices
Implementing Data Masking
DBA
Production
Clone
production
to staging
App
DBA
Create
masking
definitions
Create
data mask
formats
Execute
masking
job
Staging
Create
masking
definitions
Clone
staging
to test
Test

In this example, the production database is first cloned to a staging database and then masked for
use in a testing environment.
The security administrator performs the following tasks:
1. Review the application database and identify sensitive data.
The application database administrator would typically perform the following tasks:
1. Define mask formats for sensitive data.
2. Create a masking definition to associate table columns to the defined mask formats.
The database administrator performs the following tasks:
1. Clone the production database to a staging database.
2. Create a masking definition if this task is not performed by the application database
administrator.
3. Execute the masking job.
The security administrator performs the following tasks:
1. Verify that the masked data meets the information security requirements.
2. Refine the masking definition as necessary.
Security
admin
Identify
sensitive
information
Implementing Data Masking (continued)

If the masking definition is changed, the database administrator performs the following tasks:
1. Restore the altered tables.
2. Reapply the masking definition until the optimal masking definitions are identified.
The application database administrator, business analyst, and users test the application.
The database administrator performs the following tasks:
1. Export the masking definition for future use.
2. Clone the staging database to a test database.
Identifying Sensitive Data for Masking
The security administrator identifies data that needs

to be masked to ensure regulation compliance.
The application database administrator:

Determines specific columns
Flags columns with column comment
App
DBA
COMMENT ON COLUMN hr.employees.employee_id IS 'MASK

candidate: HR Benefits Policy';
COMMENT ON COLUMN hr.employees.first_name IS 'MASK
candidate: HR Privacy Policy';
COMMENT ON COLUMN hr.employees.last_name IS 'MASK
candidate: HR Privacy Policy';
COMMENT ON COLUMN hr.employees.salary IS 'MASK
candidate: HR Compensation Policy';
Identifying Sensitive Data for Masking

The security administrator would typically direct the process by identifying what types of
information must be masked to comply with various regulations. The application database
administrator can use a technique as shown in the slide to identify specific columns in database
tables that should be masked. This technique will enable the database administrator to easily
identify columns that are to be masked when creating masking definitions with the Data
Masking Pack.
Security
admin
Which of the following features are provided by the Data

Masking Pack?
a. Uses an irreversible process to replace sensitive data with
realistic-looking data
b. Enables you to define masking rules
c. Enables you to restore the data to its state prior to masking
d. Provides a central definition for common data masking
formats
Answer: a, b, d
Quiz
Data masking choices:

Use Oracle-supplied mask formats.
Use supplied mask primitives for various types of data.
Use built-in masking routines such as shuffling.
Create a specific masking format using the supplied mask
primitives and routines.
Create a function for more complicated masking.
Determining How to Mask the Data

The Data Masking Pack includes a format library containing formats for various types of
sensitive data. The Data Masking Pack also contains built-in masking primitives that can be used
directly to mask column data. You can also use the built-in masking routines to directly mask
the column data. The built-in masking primitives and routines can also be used to build a more
sophisticated masking format. If the built-in masking primitives and routines do not satisfy your
data masking requirements, you can create a PL/SQL function to use for masking.
Determining How to Mask the Data
The Data Masking Pack format library contains a collection

of ready-to-use masking formats that are used when
creating a masking definition.
Masking formats can be defined using:
Built-in data masking primitives, referred to as format
entries
User-defined format masks
A format library can be exported (saved as an XML file) so

that it can be reused or shared with another Enterprise
Manager installation.
Managing the Data Mask Format Library

The Data Masking Pack format library contains predefined masking formats that are used to
create a masking definition. A masking definition associates a masking format with a column in
a database table.
There are built-in data masking primitives in the format library and you can define additional
format masks.
The format library can be saved to an XML file so that it can be reused or shared with another
installation of Enterprise Manager.
Managing the Data Mask Format Library
Using Oracle-Supplied Mask Formats
Using Oracle-Supplied Mask Formats

The Data Masking Pack includes predefined formats for a number of types of sensitive data,
such as credit card numbers, national identifiers, and phone numbers. The mask formats are built
of mask primitives. The predefined formats cause a random number to be generated and then
post-processing is performed to ensure that the resulting data is realistic.
When you are using the Data Masking Pack through Enterprise Manager Grid Control, you need
to verify that the DM_FMTLIB package is installed on your target database (any database other
than the repository database). If required, copy the following scripts to your target database and
execute them in SQL*Plus as a user that has privileges to create packages in the DBSNMP
schema:
$ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgdef.sql
$ORACLE_HOME/sysman/admin/emdrep/sql/db/latest/masking/dm_fmtlib_pkgbody.plb
The DM_FMTLIB package includes variables that enable you to modify the format style of the
predefined format definitions. As an example, you can use the DM_SSN_FORMAT variable to
include hyphens in the social security number. Refer to Oracle Enterprise Manager Concepts
10g Release 5 (10.2.0.5) for additional information and examples.
Oracle Data Masking Pack includes predefined formats:
Type
Definition
Array List
List of values that will be selected randomly
Fixed Number
Number that will be used
Fixed String
Literal string that will be used
Random Dates
Range of dates that will be used randomly
Random Digits
Random digits in the specified range
Random Numbers
Range of numbers that will be used randomly
Random Strings
Literals in the specified range
Types of Built-in Masking Primitives and Routines

The Data Masking Pack includes built-in masking primitives for various types of data. The builtin data masking primitives are described in the table on this page and the next.
Type
Definition
Shuffle
Shuffling of original data
Substitute
Uses a hash-based substitution for the original value and

always yields the same mask value for any given input value
(deterministic masking)
Substring
Literal with the specified start position and length
Table column
The specified column that is used randomly
Types of Built-in Masking Primitives and Routines (continued)

In addition to the built-in masking primitives, you can use built-in masking routines, such as
shuffling. This routine is useful when the range of values in a column is not known and you
determine that the shuffling of values in the same table provides a sufficient degree of privacy
protection.
Deterministic masking (consistent masking within and across databases) is supported through
the substitute mask format.
Example: Data Masking of the EMPLOYEES Table

LAST_NAME
DEPARTMENT_ID
PHONE_NUMBER
100 King
90 5151234567
105 Austin
60 5904234569
110 Chen
100 5151244269
Random
number
Anglo-American
last name
EMPLOYEE_ID
LAST_NAME
USA Phone
Number
DEPARTMENT_ID
PHONE_NUMBER
468 Jefferies
90 5105551256
975 Smith
60 6505559753
396 Allen
100 9255553597
Example: Data Masking of the EMPLOYEES Table

Masking of the EMPLOYEE_ID column is accomplished by using one of the built-in masking
primitives. The mask for the LAST_NAME column is constructed by referencing another column
in the database. The PHONE_NUMBER column is masked by using the USA Phone Number
mask from the Oracle-supplied format library.
EMPLOYEE_ID
Creating Data Mask Formats
Creating Data Mask Formats

You can create a data mask format as follows:
1. Navigate to the Create Format page by clicking Create on the Format Library page.
Specify a name and, optionally, a description for the data mask format.
2. Select the data mask primitive (referred to as a format entry in Enterprise Manager) and
click Go to enter the specific details for that format entry.
You can use multiple built-in data mask primitives to create your data mask format. In this
example, a data mask format is created for California Drivers Licenses. The format is
defined as follows:
Array List is specified as the first format entry type. A list of values (A, B, C, D) is
specified to provide the first part of the data mask.
For the second part of the mask, Random Digits is specified. After selecting Random
Digits and clicking Go, a start and end length can be specified.
Note that sample values are provided so that you can verify your specifications.
Create a data mask format by using built-in format primitives:
Creating a User-Defined Data Mask Format
CREATE OR REPLACE FUNCTION hr.email_mask

(orig_value VARCHAR2) RETURN VARCHAR2
IS
emailadd varchar2(100);
BEGIN
SELECT first_name || '.' || employee_id || '.' ||
last_name || '@not_realco.com' INTO emailadd
FROM hr.employees
WHERE email = orig_value;
RETURN emailadd;
END;
Creating a User-Defined Data Mask Format

A PL/SQL function of your own design can be used to mask data. The function in the slide is
used to generate a mask for the email address.
This code is executed on the target database.
Notice that this function does not hide the users real name, but uses the actual first and last
names, and the actual employee ID, in the masked email address.
The masking functions must be reviewed, and results checked, to ensure that the functions
actually provide the level of protection required.
If a reversible function is required, it can be implemented as a user-defined function. You must
assume that if an obfuscation or encryption algorithm is reversible, it will be reversed. That is, if
the original data can be extracted from the masked, or encrypted data, someone will extract the
original data.
Use for specific business or application requirements:
Creating a Masking Format Using a

User-Defined Function
Specify User Defined Function as the format entry type.
Specify the previously created function.
Creating a Masking Format Using a User-Defined Function

After creating the PL/SQL function that you intend to use for masking, you can specify it in a
data mask format.
A data masking definition associates a data masking

format with a database column.
Foreign key relationships are automatically identified and
columns are masked.
Application-enforced constraints can be defined as related
columns for automatic masking.
Data masking definitions can be saved to XML files.
The Create like feature can be used for similar database
structures.
Invoke the Mask Wizard in Enterprise Manager Grid
Control or Enterprise Manager Database Control.
Creating Data Masking Definitions

A data masking definition associates a data masking format with a specified column in the
database.
If you select a column with referential integrity constraints defined on it, the Data Masking Pack
automatically applies the same masking rule to the associated tables and columns.
If the referential integrity of the data is maintained in the application instead of the database, you
can add the associated tables and columns via the Dependent Column capability. This ensures
that the data remains consistent whether the referential integrity of the application is maintained
in the database or in the application.
Creating Data Masking Definitions
Using Masking Formats
Using Masking Formats

In this example, the data masking definition associates the built-in Random Numbers data
masking primitive (format entry) with the EMPLOYEES.EMPLOYEE_ID column.
To create the masking definition as shown in the slide, perform the following steps:
1. On the Schema page, select Definitions in the Data Masking region.
2. On the Data Masking Definitions page, click Create.
3. Specify a name for the mask, the database name and optionally a description.
4. Click Add in the Columns section to select the table and column.
5. Specify the schema, table name, and column name. Click Search.
6. Select the column and click Define Format and Add.
7. Select Random Numbers from the Add drop-down list. Click Add.
8. Enter the start and end values. Click OK.
9. Click OK on the Create Masking Definition page.
Create a masking definition by using built-in format entries:
Automatic Identification of Related Columns
Automatic Identification of Related Columns

The Data Masking Pack automatically identifies all columns related to the selected column
based on referential integrity constraints defined in the data dictionary. The masking rule
defined for the primary key column is also automatically applied to the associated columns as
shown in the slide.
The masking definition automatically includes foreign keys.
Adding Dependent Columns
Adding Dependent Columns

If the relationships between tables are defined in the application, you can use the Dependent
Column feature to add associated columns.
Implement data masking for application-based referential

integrity by adding dependent columns:
Importing Formats
Importing Formats
You can create a masking definition for a column by using a previously defined data masking
format.
Perform the following steps:
1. After selecting the table and column for masking, click Import Format to display the
formats in the library.
2. Select the masking format that you want to use and click Import.
Create the masking definition by using a previously defined

format:
Importing Formats and Modifying Properties
Importing Formats and Modifying Properties

The data masking format is imported from the library and associated with the specified column.
You can modify the format entry properties as necessary.
The format is imported from the format library:
Assign multiple mask formats to the data in a column

based on conditions you specify through a SQL query.
Separate SQL queries identify the rows for each specified
mask format.
Specify a default masking format for data in rows that are
not selected based on the defined conditions.
Using Condition-Based Masking

In some cases you may want to apply different masking routines to a column based on specific
conditions. The Data Masking Pack supports condition-based masking so that you may assign
multiple mask formats to the data in a column based on conditions you specify through a SQL
query.
For each masking format, you specify a separate SQL query. You must also define a default
masking format that applies to any rows not selected via the conditional SQL queries.
Using Condition-Based Masking
Mask related columns so that the entire set of mask

columns remains consistent and valid.
Mask columns as a group by using another set of related
data elements.
Using Compound Masking

In many cases, the columns in database tables contain data that is related to other columns in
that same table. When one or more of these columns contain sensitive data that needs to be
masked, these intercolumn dependencies need to be maintained so that the masked data as a
whole is consistent with the original data. For example, if the table has address information
consisting of a street address, city, state, and ZIP code, the masked copy of the data must be
valid so that the city, state, and ZIP code are consistent.
By using the compound masking capability of the Data Masking Pack, you can group the related
data elements together and mask the group with another set of related data elements.
Using Compound Masking
Using a User-Defined Masking Function

You can specify a user-defined function for the format entry. After selecting User Defined
Function from the Format Entry menu, specify the name of the package (optional) and function
in the Format Entry Properties fields.
Using a User-Defined Masking Function
CREATE OR REPLACE FUNCTION checksum

(rid rowid, columnName varchar2, p_buff in varchar2 )
RETURN varchar2
IS
l_sum number default 0;
l_n number;
BEGIN
FOR i in 1 .. trunc(length(p_buff||'x')/2)
LOOP
l_n := ASCII(substr(p_buff||'x', 1+(i-1)*2, 1))*256 +
ASCII(substr(p_buff||'x', 2+(i-1)*2, 1));
l_sum := mod(l_sum+l_n,4294967296);
END LOOP;
WHILE (l_sum > 65536)
LOOP
l_sum := bitand(l_sum, 65535) + trunc(l_sum/65536);
END LOOP;
RETURN p_buff || lpad(l_sum, 5, 0);
END checksum;
Creating a Post-Processing Function

You can create a PL/SQL function such as the checksum function shown in the slide. This
function is executed after the data is masked.
The pbuff parameter is the masked data (new value). Notice in this function that the calculated
checksum is concatenated to the p_buff parameter.
This could be combined with other format functions to provide another piece of a mask
definition.
Creating a Post-Processing Function
Implementing a Post-Processing Function
Implementing a Post-Processing Function

A predefined PL/SQL function can be specified as a post-processing function. This function will
execute against the data after it is masked. This function is created in the Enterprise Manager
repository.
Specify a predefined function that will execute after the data is

masked:
Generating the Data Masking Script

Validation checks are performed:
Ensures that uniqueness can be maintained

Ensures that data mask formats match column data types
Checks space availability
Warns about check constraints
Checks for the presence of default partitions
PL/SQL-based masking script is generated
Generating the Data Masking Script

After creating the data masking definitions, you can generate the masking script.
When you generate the script, the Data Masking Pack first performs a series of validation checks
to ensure that the data masking process will complete successfully. After the validation checks
have successfully completed, a PL/SQL-based script is generated.
Viewing the Data Masking Impact Report

The impact report alerts you to many possible error conditions that may occur before running the
data masking definition script. In particular, it checks the space available to the various user
schemas that are involved in the masking process.
The original table, the new table plus mapping tables, and indexes on both original and new
tables exist at the same time during the masking process.
Viewing the Data Masking Impact Report
Viewing the Data Masking Script

The script generation step produces a script that you can review and save.
Viewing the Data Masking Script
Schedule immediately after script generation:
Schedule on the Data Masking Definitions page:
Scheduling the Data Masking Job

After the data masking script has been generated, you can immediately schedule the data
masking job. You can also schedule it at a later date by clicking Schedule Job on the Data
Masking Definitions page.
Scheduling the Data Masking Job
Specifying Automatic Masking After Cloning

In addition to the standalone masking capabilities presented earlier in the lesson, you can also
specify data masking as part of the database cloning process.
You can add masking definitions as part of the Database Configuration step in the cloning
wizard. Note that the masking definitions must be generated (Ready to Mask status is True)
before adding them to the cloning process.
After the cloning process is complete, the database is placed in RESTRICTED mode and the
masking process executes. Upon verification that the masking process has completed
successfully, the database is made available for users.
Specifying Automatic Masking After Cloning
Build mapping
table
Drop
constraints
Rename
table
Collect
statistics
Create
indexes
Re-create and
reload from
renamed table
and mapping
tables
Create
constraints
Drop renamed
table and
indexes
Drop
mapping table
Understanding the Data Masking Process

The data masking job performs bulk operations to rapidly replace the table containing sensitive
data with an identical table containing masked data while retaining the original database
constraints, referential integrity and associated access structures, such as indexes,
partitions, and access permissions, such as grants. The script takes advantage of the
built-in optimizations in the database. It disables database logging and runs in parallel to quickly
create a masked replacement for the original table. The original table containing sensitive data is
dropped from the database completely and is no longer accessible.
Steps in the masking process:
1. Build a mapping table for each column to be masked. The mapping table contains
(original_value, mask_value).
2. Drop constraints and revoke grants.
3. Rename the table.
4. Create a new table using mapping tables joined to the original table.
5. Create indexes on the new table.
6. Gather statistics.
7. Replace constraints and grants.
8. Drop indexes on the original table and drop the original table with the purge option.
9. Drop mapping tables.
Understanding the Data Masking Process
An Application Masking Template:

Is an XML file of the data masking definition
Serves as a backup of the masking definition
Allows data masking definitions to be shared with other
Enterprise Manager installations
Creating an Application Masking Template

After you have completed the masking definition, you can save the definition in a portable XML
format called an Application Masking Template. This enables you to restore the masking
definition if needed and to share the masking definition with another Enterprise Manager
installation.
The Application Masking Template is created by using the Export Masking Definition feature.
Creating an Application Masking Template
Importing Data Masking Definitions

Import a previously exported masking definition.
Masking definition is imported into the Enterprise Manager
repository.
Importing Data Masking Definitions

You can import a previously exported masking definition that is stored in an XML file (an
Application Masking Template) into the Enterprise Manager repository. This enables you to use
the masking definition for new masking definitions.
Disable redo log generation during masking

Refresh statistics after masking
Drop temporary (mapping) tables created during masking
Ignore orphan foreign key rows
Customize degree of parallelism
Controlling Data Masking Operations

When you create a data masking definition you can modify the following options:
Disable redo log generation during masking: By default, redo logging and flashback
logging are disabled during masking. If you only want to test your data masking definition,
you may choose to enable redo log generation and use flashback database to restore the
database to its pre-masking state.
Refresh statistics after masking: Disable this option if you want to use special options
when collecting statistics, such as histograms or different sampling percentages.
Drop temporary (mapping) tables created during masking: Temporary tables that map
the original sensitive data values to mask values are created during the masking process.
You may want to keep these tables until the business users have validate the masked data.
Because the mapping tables show how masking changed the tables, the mapping tables
must be dropped before the database is available for unprivileged users.
Ignore orphan foreign key rows:
Customize the degree of parallelism: You can customize the degree of parallelism for the
masking process.
Controlling Data Masking Operations
Creating Custom Reports for Auditors

Auditors need to review the following types of information
with respect to data masking:
Number of masking sessions

Columns that were masked
Masking formats used
Dependent columns that were masked (that were not
identified by existing constraints)
Create custom reports by using Enterprise Manager Grid

Control Reports.

The Data Masking Pack enables you to create custom reports to monitor and audit data masking
operations.
Creating Custom Reports for Auditors (continued)

Although there are no predefined data masking reports in Enterprise Manager Grid Control, you
can create data masking reports by using the Reports Definition capability.
To create data masking reports, perform the following steps:
1. Click the Reports tab in Enterprise Manager Grid Control.
2. Click Create.
3. Specify a report title such as Data Masking Report.
4. Select Security from the Category drop-down list, or another category such as Custom.
5. Select Security Policy Overview from the Subcategory drop-down list or create a new
subcategory such as Data Masking.
6. Click the Elements tab,
7. On the Elements tabbed page, click Add.
8. Select an element type (table from SQL).
9. Click OK.
10. Click Set Parameters.
11. Enter a header and SQL statement, and then click Continue.
12. Click OK.
For more details about creating reports, see Oracle Enterprise Manager Extensibility 10g.
select d.source_name "Database", d.ss_name "Mask Definition", d.ss_owner

"Author", e.submission_ts "Mask Run Date", j.job_owner "Mask Run Submitter",
(s.end_time-s.start_time)*24*60*60||' seconds' "Mask Run Duration"
from sysman.mgmt_dm_scopespecs d, sysman.mgmt_dm_job_executions e,
sysman.mgmt_job j, sysman.mgmt_job_exec_summary s
where d.ss_guid = e.ss_guid
and j.job_id = s.job_id
and e.execution_id = s.execution_id
and d.source_id = ??EMIP_BIND_TARGET_GUID??
select s.ss_name "Mask Definition", c.table_schema "Schema", c.table_name
"Table", c.column_name "Column",e.entry_order "Sequence",
decode(e.rule_type,'RN','Random Number','CC', 'Table Column','DT','Random
Date','AL','Array List','FN','Fixed Number','FS','Fixed String',
'RD','Random Digits','RS', 'Random String','SH','Shuffling',
'UF','User Defined Function','UT','Post-Processing User Defined')
"Format Entry",
decode(e.rule_type,
'RN', 'Start Length: '||rule_low||' End Length: '||rule_high,
'CC', 'Schema owner: '||e.table_schema||' Source table and column:
'||e.table_name||'.'||e.column_name,
'AL',a.arraylist_item,
'FS',fixed_string,
'RD','Start Digits: '||rule_low||' End Digits: '||rule_high,
null) "Format Entry Parameters"
from sysman.mgmt_dm_ruleentry e, sysman.mgmt_dm_scopespecs s,
sysman.mgmt_dm_ss_columns c,
sysman.mgmt_dm_alitems a, sysman.mgmt_dm_job_executions j
where e.rule_guid = c.rule_guid
and e.rule_guid = a.rule_guid (+)
and e.entry_order = a.entry_order (+)
and s.ss_guid = j.ss_guid
and s.ss_guid = c.ss_guid
and s.source_id = ??EMIP_BIND_TARGET_GUID??
order by s.ss_name, c.table_schema, c.table_name, c.column_name,
e.entry_order
select c.parent_schema "Primary Schema", c.parent_table "Primary Table",
parent_column "Primary Column", c.table_schema "Dependant Schema",
c.table_name "Dependant Table", c.column_name "Dependant Column"
from sysman.mgmt_dm_infcons_columns c, sysman.mgmt_dm_scopespecs d
where d.ss_guid = c.ss_guid
and d.source_id = ??EMIP_BIND_TARGET_GUID??
Note: The ??EMIP_BIND_TARGET_GUID?? string is a named parameter in the Enterprise

Manager reporting framework.
Creating Custom Reports for Auditors (continued)

An example of the elements of a Data Masking Auditors report are shown below. Note that the
SELECT privilege on the tables named in these queries must be granted to the MGMT_VIEW
user.
In this lesson, you should have learned how to use the Data
Masking Pack to:
Create masking formats
Manage the format library
Mask sensitive and confidential data
Summary

Identifying sensitive data
Creating data mask formats
Managing the data mask format library
Creating data masking definitions
Creating and applying a user-defined data mask
Encryption Concepts

following:
Discuss issues related to the use of encryption
Discuss the challenges of encryption
Describe key management solutions
Describe the encryption options available with Oracle
Database 11g
Objectives
Understanding Encryption
Data is encrypted and decrypted:
Key management is critical.

Secure transmission
Secure storage (avoiding loss)
Encrypt/Decrypt
Understanding Encryption
Encryption in various forms has been around for centuries. All encryption has two parts: an
algorithm, which is a procedure or method of manipulating the data, and a key or a secret that
allows the data to be decrypted. In the past, for many algorithms, the method was the secret.
Modern algorithms are typically public and depend on mathematics to make the algorithm
sufficiently complex that the key cannot be guessed or derived from the encrypted data in a
reasonable time frame. In modern algorithms, the key is typically a string of numbers or
characters.
Key management becomes the critical issue with encryption. If the key is lost, the data cannot be
decrypted. If the key is mishandled and compromised, the data could be decrypted by
unauthorized persons.
The administrative costs of encryption include periodically decrypting and encrypting the data
with a new key, keeping the keys secure, and transmitting the keys to an authorized user in a
secure manner.
The processing costs of encryption include the time that is required to encrypt and decrypt the
data. Generally, a more complex algorithm produces a more secure data set, and requires more
processing to encrypt and decrypt the data.
With an encryption algorithm

Using a key or secret
What Problems Does Encryption Solve?
What Problems Does Encryption Solve?

Encryption is cited as a method to meet PCI DSS requirements for data at rest and data in transit.
In an Oracle database, the data files without encryption are available to OS privileged users. OS
privileged users are those users who may bypass the file permissions and access any file on the
operating system. These users may have the ability to read the data files and convert them into
intelligible data.
Data transmitted without some form of network encryption is available to anyone who has
physical access to the network. These individuals can capture transmitted data. In both cases,
encrypted data will prevent the intruder from being able to convert it into intelligible data.
Encryption is not an access control solution.
Encryption protects:
Data at rest (in files)
Data in transit (network)
Cost of Encryption
Encryption and decryption of data
Management of encryption keys

Secure transmission
Administrative overhead
Encrypt/Decrypt
Cost of Encryption
Although there are some valid reasons to encrypt data, encryption does not solve all security
problems, and may even make some problems worse. Because there is some overhead associated
with the encrypting and decrypting of data, it should be applied only in the appropriate situation.
The encryption and decryption of data uses CPU resources, whereas the management of
encryption keys requires personnel resources.
Cost of Managing Encryption
Because the human resources (HR) records are considered sensitive information, it is tempting
to think that this information should be encrypted for better security. However, encryption does
not enforce granular access control and may actually hinder data access. In the human resources
example, an employee, his or her manager, and the HR clerk need to access the employees
record. If employee data is encrypted, each person must also be able to access the data in
unencrypted form. Therefore, the employee, the manager, and the HR clerk would have to share
the same encryption key to decrypt the data. Encryption would not provide any additional
security in the sense of better access control, and the encryption may actually hinder the proper
functioning of the application.
There is the additional issue of securely transmitting and sharing the encryption keys among
multiple users of a system.
Accessibility
Performance
Encryption Is Not Access Control

Do not use encryption in place of access control.
Strong data access mechanisms are available.
Encryption must not interfere with access control.
Encryption Is Not Access Control

Most organizations need to limit data access to those who have a need to know. For example, an
HR system may limit employees to reviewing only their own employment records, whereas
managers of employees may see the employment records of those employees working for them.
HR specialists may also need to see employee records for multiple employees.
These requirements are typically addressed by access control mechanisms, rather than
encryption. The Oracle database provides strong, independently evaluated access control
mechanisms.
A basic principle is that encrypting stored data must not interfere with access control. For
example, a user who has the SELECT privilege on the EMPLOYEES table should not be limited
by the encryption mechanism from seeing all the data he or she is otherwise allowed to see.
Access by Privileged Users

DBAs can access all data. Limit and monitor the DBA by:
Using SYSOPER with limited privileges

Creating assistant DBA roles to limit access
Auditing the actions of the DBA
Running background checks on the DBAs
Encrypting sensitive columns
Using Oracle Database Vault to secure application data.
The system administrator has access to all data files.

Use column Transparent Data Encryption
Use tablespace Transparent Data Encryption
Backup media may be compromised.

Use Recovery Manager (RMAN) to create encrypted
backups.
Use Data Pump Export to create encrypted dump files.
Access by Privileged Users

DBAs Can Access All Data
Some organizations are concerned that DBAs (privileged users) can see all the data in the
database, because they typically have all privileges. These organizations feel that DBAs should
merely administer the database, but should not be able to see the data that the database contains.
Some organizations are also concerned about the concentration of privileges in one person, and
would prefer to partition the DBA function and enforce a separation of duties. Limiting the
privileges of the DBA is discussed in the lesson titled Basic Database Security. The Oracle
Database instance can audit all the actions taken by users with the SYSDBA privilege, as covered
in the lesson titled Auditing Database Users, Privileges, and Objects.
Oracle Database Vault resolves these issues, with strong access control.
The DBA job position by its nature requires a trustworthy person. Organizations with the most
sensitive data, such as intelligence agencies, scrutinize their DBAs closely because it is a
position of trust. If an untrustworthy user has significant privilege, he or she may pose far more
significant threats to an organization than viewing unencrypted credit card numbers.
System Administrator Has Access to All Data Files

The system administrator can always access all files on a machine. If the security of the
machine is compromised or if data files do not have the proper permissions, others may
directly access the data files. Anyone with access to data files and a hex editor can read and
decode the information in a data file, given enough time. Encrypting sensitive data in the
data files can mitigate a breach and limit the view of the system administrator or someone
who manages to gain administrator privileges.
Oracle Advanced Security provides Transparent Data Encryption (TDE) for both columns
and tablespaces.
Protecting Backup Media
Backup media must be protected. A knowledgeable user can use a full backup to re-create
your database. Encrypting sensitive data can prevent access of sensitive data in backup files
in the case of lost or stolen backup media. Backup and dump files can be encrypted using
RMAN, and Data Pump Export respectively.
Access by Privileged Users (continued)

DBAs Can Access All Data (continued)
Encrypting everything does not make data secure.

Data is unavailable during key changes.
Lost keys mean lost data.
The management of keys becomes critical.
What to Encrypt
It is a pervasive tendency to think that if encrypting some data strengthens security, encrypting
everything can make all data secure. Encryption does not make data secure if the issues of key
management and transmission are not adequately addressed. It just changes the point of attack.
Encryption does not address access control issues. Consider the implications of encrypting an
entire production database. All data must be decrypted to be read, updated, or deleted, and the
encryption must not interfere with normal access controls. Encryption is a performance-intensive
operation; encrypting all data significantly affects performance. Availability is a key aspect of
security. If the data is not available in a timely manner because it is encrypted, you have created
a new security problem.
Encryption keys must be changed regularly as part of a good security practice, which means that
the data is inaccessible while it is being decrypted and reencrypted with a new key or keys. This
also adversely affects availability.
The management of encryption keys is critical. If a key is lost, the encrypted data is also lost. If
a key is compromised, the data must be reencrypted. This is no different from changing the locks
when an employee that has keys leaves the company.
What to Encrypt
Encryption enables you to control who has access to the

encrypted data.
a. True
b. False
Answer: b
Quiz
Data Encryption: Challenges

Key management:
Generation
Changing
Transmission
Storage
Encrypting special types of data:

Indexed
Large objects (LOBs)
Data Encryption: Challenges

Key Management
Key management, including both generation and secure storage of cryptographic keys, is
arguably one of the most important aspects of encryption. If keys are poorly chosen or stored
improperly, it makes it far easier for an attacker to break the encryption or steal the keys. Rather
than searching through all the possible keys in hopes of finding the correct decryption key,
hackers can seek weaknesses in the choice of keys or the way in which keys are stored. Any
cryptographic scheme can be broken if there is sufficient time. So changing the keys on a regular
basis reduces the time during which it may be possible to discover the key. When a key must be
known to multiple persons or machines, how will the keys be protected during transmission?
Encrypting Special Types of Data
Indexes need to be fast to be useful. If the index is over a column that is encrypted, the index
should be encrypted as well. This causes performance problems and limits the types of index
lookups that are possible.
Large objects have a unique set of problems due to their possible size and considerations for
access methods.
Keys are generated with random numbers. Use an approved

random-number generator:
DBMS_CRYPTO.RANDOMBYTES is based on RSA Security
Inc. x9.31 PRNG.
DBMS_OBFUSCATION_TOOLKIT.GETKEY is available for
backward compatibility.
DBMS_RANDOM is not approved.
Encryption Key Management: Key Generation

Key generation is an important aspect of encryption. Typically, keys are generated automatically
through a random-number generator, from a cryptographic seed. Provided that the randomnumber generation is sufficiently strong, this can be a secure form of key generation. However,
if random numbers are not well formed, but have elements of predictability, the security of the
encryption may be easily compromised.
To address the issue of secure cryptographic key generation, Oracle Database 11g supports
secure random-number generation. The RANDOMBYTES procedure of DBMS_CRYPTO calls a
secure random-number generator based on the RSA Security Inc. x9.31 Pseudo-Random
Number Generator (PRNG) standard, which is an approved random-number generator as per the
Federal Information Processing Standard (FIPS)-140-2 Annex C.
The GETKEY procedure of the DBMS_OBFUSCATION_TOOLKIT package is an approved
FIPS-140 random-number generator and is available for backward compatibility.
Developers should not use the DBMS_RANDOM package that generates pseudo-random numbers,
rather than random numbers. As "RFC1750 - Randomness Recommendations for Security"
states, the use of pseudo-random processes to generate secret quantities can result in pseudosecurity.
Best Practice: Revoke EXECUTE on DBMS_RANDOM from PUBLIC to prevent any developer
using this package.
THESE from
eKIT MATERIALS
ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
Encryption Key Management:

Key Generation
Encryption Key Management: Key Modification

and Transmission
Modify periodically, as you would a password, to:
Transmit the keys in a secure manner:

Electronic transmission (encrypt the key)
Physical transmission
Encryption Key Management: Key Modification and Transmission

Key Modification
Prudent security practice dictates that you periodically change encryption keys. For stored data,
this requires periodically decrypting the data and reencrypting it with another well-chosen key.
This should be done while the data is not being accessed. This creates another challenge for
applications that need to be continuously available. Consider a Web-based application
encrypting credit card numbers. You do not want to make the entire application unavailable
while you switch encryption keys.
Key Transmission
If the key is used outside the database, is used by multiple users, or is changed, the key must be
transmitted in some manner. The method depends on where and to whom the key is to be passed.
If the key is to be passed over the network, it must be encrypted. Otherwise, a network snooper
may grab the key as it is being transmitted. The use of network encryption, such as that provided
by Oracle Advanced Security, protects all data in transit from modification or interception,
including cryptographic keys. The physical transmission of the key poses the risk of losing the
key copy or having it stolen.
Reduce the possibility of brute force key discovery

Reencrypt the data
Store the keys by using one of the following methods:

Store the key in the database.
Store the key in an operating system file.
Let the user manage the key.
Encryption Key Management: Key Storage

Key storage is one of the most important, yet difficult, aspects of encryption. To recover data
encrypted with a symmetric key, the key must be accessible to the application or user seeking to
decrypt data. Users must be able to access encrypted data without significant performance
degradation. Authorized users must be able to retrieve the key quickly, but the key must be
secure enough so that an unauthorized user cannot easily recover it.
There are three basic options:
Store the key in the database.
Store the key in an operating system file.
Let the user manage the key.
The details of each of these options are covered later in this lesson.
Encryption Key Management: Storage
The techniques for protecting keys in the database are:

Store keys in a separate table and schema.
Perform additional data transformation.
Wrap the PL/SQL package that performs the encryption.
Use one key per row.
Combine the techniques.
Storing the Key in the Database

Storing the keys in the database cannot protect data against the DBA accessing encrypted data.
An all-privileged DBA can access tables containing encryption keys. However, it can often
provide good security against the casual snooper or against someone reading the database file
from a compromised operating system account. If an intruder gets access to the encryption key,
he or she can decrypt and read the encrypted data. So it is important to keep the key private.
Some techniques for providing additional security for encryption include the following:
Never store the key in the same table as the encrypted data. When hackers have access to
the table, they can decrypt the data. Store the key in a separate schema, and use PL/SQL
techniques to control access to the key.
Encrypt the data with a technique that performs some additional data transformation, such
as an XOR operation on the encrypted data with another value. You can use another
column, but that column must not change. For example, you can use the primary key of the
row as the additional value.
Wrap the PL/SQL package body that performs encryption. The wrap utility transforms the
code so that the package body is not human readable. For example, to wrap a package body
stored in the keymanage.sql file, perform the following:
wrap iname=keymanage.sql
Storing the Key in the Database
Storing the Key in the Database (continued)

Even in cases where a different key is supplied for each encrypted data value (so that
the value of the key is not embedded within a package), wrapping the package that
performs key management is recommended. Additional information about the wrap
utility is available in the PL/SQL Users Guide and Reference.
Note that even when the key is wrapped in a package, it may still be viewed in the
DBA_SOURCE view. Therefore, any user who has the SELECT privilege on this view
can see the key.
Rather than using one key for the entire column, create a separate key for each row and
store the encryption key in another table. The key table can be joined to the data table
by using a primary keyforeign key relationship. For example, SALES_ID is the
primary key in the SALES table, which stores sales transactions and the encrypted
CREDIT_CARD_NO value. SALES_ID is a foreign key to the SALES_KEYS table,
which stores the encryption keys for each credit card number.
The strengths of this approach are the following:
Users who have direct table access cannot see the sensitive data unencrypted, nor can
they retrieve the keys to decrypt the data.
Access to decrypted data can be controlled through a procedure that selects the
encrypted data, retrieves the decryption key from the key table, and transforms the key
before it can be used to decrypt the data.
The data transformation algorithm is hidden from casual snooping by wrapping the
procedure, which obfuscates the procedure code.
Read access to both the data table and the key table does not guarantee that the user
with this access can decrypt the data, because the key is transformed before use.
The weakness in this approach is that a user who has SELECT access to both the key table
and the data table (who can derive the key transformation algorithm) can break the
encryption scheme.
This approach does not guarantee complete security; it can protect against easy retrieval of
sensitive information that is stored encrypted (for example, credit card numbers) and the
data is encrypted in the data files protecting the data from access through OS files and
backup media.
Use this method to restrict DBA access to the keys:

Set up the file storing the keys so that the DBA does not
have access to the file.
Retrieve the data from the database without decrypting the
data.
Decrypt the data in the application accessing the data. The
DBA must also be denied access to this application.
Storing the Key in the Operating System

Storing keys in a file in the operating system is another option. You can use the UTL_FILE
package to make callouts from PL/SQL, which you can use to retrieve encryption keys.
However, if you store keys in the operating system (OS) and make callouts to it, your data is
only as secure as the protection on the OS. If you are encrypting data stored in the database
because the database can be broken into from the OS, storing the keys in the OS makes it easier
for an intruder to retrieve encrypted data than if the keys were stored in the database itself.
The following technique may be used to hide the data from the DBA:
1. Set up the file storing the keys so that the DBA does not have access to the file.
2. Retrieve the data from the database without decrypting the data.
3. Decrypt the data in the application accessing the data. The DBA must also be denied
access to this application.
Storing the Key in the Operating System
User-managed keys have the following problems:

Users forget the key.
Users archive the key in an insecure manner.
Users must use secure transmission methods, such as
network encryption.
Letting the User Manage the Key

Having the user supply and manage the key is another technique for managing keys. However,
considering the estimate that 70% of the help-desk calls are from the users who have forgotten
their passwords, you can see the risks of having users manage encryption keys. In all likelihood,
users either forget an encryption key or write the key down, which creates a security weakness.
If a user forgets an encryption key or leaves the company, your data is unrecoverable.
If you elect to have user-supplied or user-managed keys, you must use network encryption so
that the key is not passed from the client to the server unencrypted. You must also develop key
archive mechanisms, which pose another difficult security problem. Arguably, key archives
create a security weakness that encryption attempts to address in the first place.
Letting the User Manage the Key
Solutions
Transparent Data Encryption (TDE)
File encryption
RMAN backup encryption
Oracle Secure Backup
Application encryption
Solutions
Depending on the problem that you are trying to solve, there are several solutions. Each solution
solves a particular set of problems.
Oracle Database Vault: If the reason for encryption is to limit access by the DBA, Database
Vault provides powerful tools to enforce separation of duties and limit access of schema data to
authorized persons.
Transparent Data Encryption is an option that is integrated with the database when the Oracle
Advanced Security option is installed. With column-level encryption, the data is encrypted in the
database files and System Global Area (SGA). Columns are encrypted as declared in the table
definitions. With tablespace encryption, the entire tablespace is encrypted, and the encryption
and decryption is handled in the I/O layer. The encryption keys are stored encrypted in the
database, and a master key is stored in an external wallet. All access is controlled by standard
database access control methods.
File encryption provides the ability to encrypt sensitive data in backup files and dump files.
Application Encryption is a last resort. It has the advantage of limiting the access of sensitive
data to only those users that have access to the encryption key, but has all the disadvantages
inherent in a custom application, plus the issues of key management.

Discuss the issues of encryption
Discuss the challenges of encryption
Describe key management solutions
Describe the encryption options available with Oracle
Database 11g
Summary

Oracle Database 11g Security

Caricato da

Informazioni sul documento

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

Oracle Database 11g Security

Caricato da

Copyright:

Formati disponibili

Volume I Student Guide

Oracle University and ORACLE CORPORATION use only