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. Government’s 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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS Sujatha Nagendra COMPUTER IS STRICTLY PROHIBITED
Oracle University and ORACLE CORPORATION use only
Contributors and Reviewers
Oracle University and ORACLE CORPORATION use only
Preface
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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
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 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: 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
11g Release 2 (11.2)
E10574-03
Oracle Database Net Services Administrator's Guide 11g Release 2 (11.2)
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 user’s guides • read.me files • International Oracle User’s Group (IOUG) articles • Oracle Magazine
Preface - 4 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 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 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
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 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
Typographic Conventions (continued) Typographic Conventions in Code
Contents
I
Introduction to Database Security Course Objectives I-2 Agenda I-3 Prerequisites I-6
1
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 Invoker’s 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 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
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
3
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 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
2
4
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 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
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
6
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
7
Using Strong Authentication Objectives 7-2 User Authentication 7-3 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 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
5
8
Using Enterprise User Security Objectives 8-2 User Authentication 8-3 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 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
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 User Authentication 9-3 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 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
9
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
Example: Disabling SET ROLE C-12
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Introduction to Database Security
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security I - 2
Oracle University and ORACLE CORPORATION use only
Course Objectives
Agenda Lesson
1
Topic Introduction to Database Security
1
1
Understanding Security Requirements
1
2
Choosing Security Solutions
1
3
Basic Database Security
1
4
Auditing Database Users, Privileges, and Objects
2
5
Auditing DML Statements
2
6
Using Basic User Authentication
2
7
Using Strong Authentication
2
8
Using Enterprise User Security
3
9
Using Proxy Authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security I - 3
Oracle University and ORACLE CORPORATION use only
Day
Day
Lesson
Topic
3
10
Using Privileges and Roles
3
11
Using Application Contexts
3
12
Implementing Virtual Private Database
4
13
Oracle Label Security Concepts
4
14
Implementing Oracle Label Security
4
15
Using the Data Masking Pack
4
16
Encryption Concepts
5
17
Using Application-Based Encryption
5
18
Applying Transparent Data Encryption
5
19
Applying File Encryption
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security I - 4
Oracle University and ORACLE CORPORATION use only
Agenda
Day
Lesson
Topic
5
20
Oracle Net Services: Security Checklists
5
21
Securing the Listener
Optional
App B
Using Oracle Connection Manager as a Firewall
Optional
App C
Securing SQL*Plus
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security I - 5
Oracle University and ORACLE CORPORATION use only
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)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security I - 6
Oracle University and ORACLE CORPORATION use only
Prerequisites
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Understanding Security Requirements
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 2
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 3
Oracle University and ORACLE CORPORATION use only
Fundamental Data Security Requirements
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 4
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 5
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 organization’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 6
Oracle University and ORACLE CORPORATION use only
Compliance Mandates
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 7
Oracle University and ORACLE CORPORATION use only
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, driver’s license, and government identity numbers—must 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 8
Oracle University and ORACLE CORPORATION use only
•
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 9
Oracle University and ORACLE CORPORATION use only
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 data—or using the services in unauthorized ways—is 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 intentional—for 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 partner’s 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?
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 10
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 11
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 12
Oracle University and ORACLE CORPORATION use only
•
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 13
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 14
Oracle University and ORACLE CORPORATION use only
Implementing a Security Policy
A successful security policy should balance protection and productivity. a. True b. False
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 15
Oracle University and ORACLE CORPORATION use only
Quiz
• • • • •
Authentication Authorization Access control Auditing Encryption
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Techniques for Enforcing Security The following techniques are used to enforce security: • Authentication is the process by which a user’s 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 user’s privileges are ascertained. • Access control is the process by which a user’s access to physical data in the application is limited, based on the user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 16
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 1 - 17
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 18
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 accounts—for 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 19
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 20
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 21
Oracle University and ORACLE CORPORATION use only
Preventing Exploits
Summary
– Least privilege – Authorization – Authentication
• • •
Describe security policies Describe the concept of in-depth security Apply these concepts to prevent SQL injection
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 22
Oracle University and ORACLE CORPORATION use only
In this lesson, you should have learned how to: • Describe fundamental security requirements • Define the following terms:
Case Study: Applying Security Practices
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 23
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 24
Oracle University and ORACLE CORPORATION use only
Understanding SQL Injection
Preventing SQL Injection
– Use invoker’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 25
Oracle University and ORACLE CORPORATION use only
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;
1
GRANT EXECUTE ON change_password to OE, HR, SH;
2
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 invoker’s rights to reduce SQL injection vulnerability • Reducing arbitrary inputs Using Invoker’s 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. Definer’s 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 definer’s 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 user’s password. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 26
Oracle University and ORACLE CORPORATION use only
Using invoker’s rights helps to: • Limit the privileges • Minimize the security exposure
Using Invoker’s Rights
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Using Invoker’s Rights To disallow another user from changing a password that does not belong to the user, redefine the procedure with the invoker’s 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 invoker’s 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 definer’s rights can allow a user more privileges than intended.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 27
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 28
Oracle University and ORACLE CORPORATION use only
•
Validating Input to Dynamic SQL All user input must be validated. • Use the DBMS_ASSERT package to validate. Use in-house developed filters.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 29
Oracle University and ORACLE CORPORATION use only
•
Coding Review and Testing Strategy •
Test:
•
Review: – Peer and self-reviews – Analysis tools
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 30
Oracle University and ORACLE CORPORATION use only
– Dynamic testing – Static testing
Mitigating the Scope of Exploits
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 31
Oracle University and ORACLE CORPORATION use only
If an attack is successful, reduce the scope by: • Avoiding privilege escalation • Trapping and handling exceptions
• • •
Give out privileges appropriately. Run code with invoker’s rights when possible. Ensure that the database privilege model is upheld when using definer’s rights.
Invoker’s rights
Definer’s rights
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Avoiding Privilege Escalation Unless carefully designed, routines may effectively grant users more privileges than intended. Wherever possible, run code with invoker’s 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 definer’s rights should be carefully reviewed to ensure that the database privilege model is upheld. If none of the methods of execution (definer’s rights, invoker’s rights) appears suitable, consider implementing specific bypass checks for the duration of the call.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 32
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 1 - 33
Oracle University and ORACLE CORPORATION use only
•
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Choosing Security Solutions
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 2
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 3
Oracle University and ORACLE CORPORATION use only
Assuring Data Integrity
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 4
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Data Protection California Security Breach Laws—CA-SB-1386 and CA-AB-1950—require 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 5
Oracle University and ORACLE CORPORATION use only
Data Protection
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 6
Authentication and Authorization •
Authentication verifies the user’s identity.
•
Authorization determines the user’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Authentication and Authorization Authentication verifies who the end user is and authorization determines the user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 7
Oracle University and ORACLE CORPORATION use only
– Centralized identity management – Strong authentication
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 9
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 10
Oracle University and ORACLE CORPORATION use only
•
Which of the following are used to implement authentication? a. Enterprise User Security b. Oracle Database system privileges c. Oracle Identity Management
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a, c
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 11
Oracle University and ORACLE CORPORATION use only
Quiz
Oracle Database Vault Protection realms
Separation of duty
Command rules
Existing Oracle database
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Database Vault 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 12
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 13
Oracle University and ORACLE CORPORATION use only
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) Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 14
Oracle University and ORACLE CORPORATION use only
Encrypted communication Oracle Advanced Security
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 15
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 16
Oracle University and ORACLE CORPORATION use only
Enterprise Manger Database Control
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 17
Oracle University and ORACLE CORPORATION use only
Enterprise Manager Database Control: Policy Trend
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 18
Oracle University and ORACLE CORPORATION use only
Security at a Glance: Details
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 19
Oracle University and ORACLE CORPORATION use only
Enterprise Manager Grid Control Security Advisor
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 20
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 21
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Installing the Oracle Management Agent • Configuring monitoring credentials for your database • Choosing a security solution
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 2 - 22
Oracle University and ORACLE CORPORATION use only
Practice 2 Overview: Hardening Database Access
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Basic Database Security
After completing this lesson, you should be able to do the 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-2
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-3
Oracle University and ORACLE CORPORATION use only
• Apply the principle of least privilege:
Reducing Administration Effort
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s credentials and authorizations, reduces the effort required to manage (create, update, and purge) accounts. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-4
Oracle University and ORACLE CORPORATION use only
• 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-5
Oracle University and ORACLE CORPORATION use only
• Install only the required products and features. • Plan your installation:
Applying Security Patches
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Applying Security Patches 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-6
Oracle University and ORACLE CORPORATION use only
• 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).
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-7
Oracle University and ORACLE CORPORATION use only
• Oracle Database 11g supports passwords that are more secure. • Passwords:
Automatic Secure Configuration
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.”
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-8
Oracle University and ORACLE CORPORATION use only
• 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3-9
Oracle University and ORACLE CORPORATION use only
– 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 10
Oracle University and ORACLE CORPORATION use only
– 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 11
Oracle University and ORACLE CORPORATION use only
DBA
Allowing Remote Database Administration
• Create a password file • Add user with GRANT SYSDBA TO • Connect sys/@service AS SYSDBA $ orapwd file=$ORACLE_HOME/dbs/orapwp0orcl entries=5 Enter password for SYS: $ sqlplus sys/@p0orcl AS SYSDBA
View the privileged accounts. SQL> SELECT * FROM v$pwfile_users;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 12
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 13
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 14
Oracle University and ORACLE CORPORATION use only
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>
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 15
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 16
Oracle University and ORACLE CORPORATION use only
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 user’s new password. • Use Oracle Advanced Security for strong authentication. • Enable password complexity checking.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 17
Oracle University and ORACLE CORPORATION use only
– The profile identifies the routine to use.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 18
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 USER…IDENTIFIED BY… command. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 19
Oracle University and ORACLE CORPORATION use only
• 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 20
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 21
Oracle University and ORACLE CORPORATION use only
Protecting the Data Dictionary
System and Object Privileges
• Limit system privileges. • Selectively grant specific privileges to users. • Encapsulate sensitive objects.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 22
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 23
Oracle University and ORACLE CORPORATION use only
• 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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 24
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.”
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 25
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 26
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 OracleJobSchedulerWindows service: either LocalSystem or a named user (local or domain).
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 27
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 28
Oracle University and ORACLE CORPORATION use only
• 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 29
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s encrypted password, change the password, and connect as that user. When finished, the DBA can replace the user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 30
Oracle University and ORACLE CORPORATION use only
• Users with DBA privileges must be trusted, but separation of responsibilities can:
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 31
Oracle University and ORACLE CORPORATION use only
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 Administrator’s 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 32
Oracle University and ORACLE CORPORATION use only
Using Available Database Security Features
In this lesson, you should have learned how to: • 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 33
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Finding and correcting security policy violations • Creating a security officer account • Applying a password verification function
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 3 - 34
Oracle University and ORACLE CORPORATION use only
Practice 3 Overview: Hardening Database Access
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Auditing Database Users, Privileges, and Objects
After completing this lesson, you should be able to do the 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 2
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 3
Oracle University and ORACLE CORPORATION use only
•
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 4
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.”
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 5
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 6
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 7
Oracle University and ORACLE CORPORATION use only
Standard Database Auditing
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 system’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 9
Oracle University and ORACLE CORPORATION use only
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 10
Oracle University and ORACLE CORPORATION use only
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')
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 11
Oracle University and ORACLE CORPORATION use only
– SYSAUX tablespace
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 12
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 13
Oracle University and ORACLE CORPORATION use only
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 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_AGE, AUDIT_TRAIL_PROPERTY_VALUE=>14)
•
The default value is 5 days.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. 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_AGE to set the age limit • AUDIT_TRAIL_PROPERTY_VALUE: Used to set the age limit in days. The default is 5 days.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 14
Oracle University and ORACLE CORPORATION use only
Limiting the Age of the Operating System Audit Trail
11.2
•
•
Use the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY 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_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, AUDIT_TRAIL_PROPERTY=>DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE, USE_DEFAULT_VALUES=>TRUE)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. 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: - 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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 15
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 16
Oracle University and ORACLE CORPORATION use only
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 17
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 18
Oracle University and ORACLE CORPORATION use only
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 19
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 20
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 21
Oracle University and ORACLE CORPORATION use only
Viewing Auditing Results
Quiz
a. True b. False
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 22
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 23
Oracle University and ORACLE CORPORATION use only
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 DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY procedure.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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: • 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 • DEFAULT_CLEANUP_INTERVAL: Specifies the interval (in hours) after which the DBMS_AUDIT_MGMT.CLEAN_AUDIT TRAIL is called THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 24
Oracle University and ORACLE CORPORATION use only
•
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( AUDIT_TRAIL_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, LAST_ARCHIVE_TIME=>'2010-01-13 2:00:00') Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Setting an Archive Timestamp for Audit Records The DBMS_AUDIT_MGMT.LAST_ARCHIVE_TIMESTAMP procedure has the following parameters: • AUDIT_TRAIL_TYPE: Specifies the database audit trail type. Valid values are: - DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Specifies the standard audit trail table (SYS.AUD$) - DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Specifies the fine-grained audit trail table (SYS.FGA_LOG$) - 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 • 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 25
Oracle University and ORACLE CORPORATION use only
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( AUDIT_TRAIL_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, USE_LAST_ARCH_TIMESTAMP=>TRUE)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Manually Purging the Audit Trail The DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedure has the following parameters: • AUDIT_TRAIL_TYPE: Specifies the database audit trail type. Valid values are: - DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Specifies the standard audit trail table (SYS.AUD$) - DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Specifies the fine-grained audit trail table (SYS.FGA_LOG$) - DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Specifies the standard and finegrained audit trail tables - 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_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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 26
Oracle University and ORACLE CORPORATION use only
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_TYPE=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, AUDIT_TRAIL_PURGE_INTERVAL=>8, AUDIT_TRAIL_PURGE_NAME=>'AT_PURGE', USE_LAST_ARCH_TIMESTAMP=>TRUE)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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: • AUDIT_TRAIL_TYPE: Specifies the database audit trail type. Valid values are: - DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Specifies the standard audit trail table (SYS.AUD$) - DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Specifies the fine-grained audit trail table (SYS.FGA_LOG$) - DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Specifies the standard and finegrained audit trail tables - 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_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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 27
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 28
Oracle University and ORACLE CORPORATION use only
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//adump Second: $ORACLE_HOME/rdbms/audit
– On Windows: Windows Application Event Log
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 29
Oracle University and ORACLE CORPORATION use only
Auditing the SYSDBA and SYSOPER Users
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 30
Oracle University and ORACLE CORPORATION use only
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:
[email protected] (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 …
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 31
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 32
Oracle University and ORACLE CORPORATION use only
– 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s file. The file permissions of the log file are never changed by syslog—this 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 33
Oracle University and ORACLE CORPORATION use only
– 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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 system—for 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 34
Oracle University and ORACLE CORPORATION use only
– 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)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 35
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 36
Oracle University and ORACLE CORPORATION use only
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 user’s change is made.
A record is inserted into an audit trail table.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 37
Oracle University and ORACLE CORPORATION use only
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 38
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 39
Oracle University and ORACLE CORPORATION use only
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 40
Oracle University and ORACLE CORPORATION use only
-- 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));
In this lesson, you should have learned how to: • 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 41
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Applying database auditing • Enabling auditing of the SYS user • Capturing audit records with syslog
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 4 - 42
Oracle University and ORACLE CORPORATION use only
Practice 4 Overview: Implementing Basic Auditing
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Auditing DML Statements
After completing this lesson, you should be able to do the following: • Implement fine-grained auditing (FGA) • Maintain FGA policies • Implement an FGA audit event handler • Read FGA audit events from the FGA audit trail
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 2
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 3
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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'
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 4
Oracle University and ORACLE CORPORATION use only
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 argument—for 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 5
Oracle University and ORACLE CORPORATION use only
•
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 6
Oracle University and ORACLE CORPORATION use only
•
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 7
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: c
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 9
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 definer’s rights.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 10
Oracle University and ORACLE CORPORATION use only
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_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary' );
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 11
Oracle University and ORACLE CORPORATION use only
•
BEGIN dbms_fga.drop_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 12
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 13
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 14
Oracle University and ORACLE CORPORATION use only
– 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 15
Oracle University and ORACLE CORPORATION use only
Maintaining the Audit Trail
In this lesson, you should have learned how to: • Implement FGA • Maintain FGA policies • Implement an FGA audit event handler • Read FGA audit events from the FGA audit trail
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 16
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Creating an FGA policy • Observing audited records in the database audit table • Creating an FGA policy with an event handler
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 5 - 17
Oracle University and ORACLE CORPORATION use only
Practice 5 Overview: Implementing Fine-Grained Auditing
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Basic User Authentication
After completing this lesson, you should be able to do the following: • Authenticate users with passwords • Protect passwords • Authenticate users with the operating system (OS) • Protect database link passwords
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-2
Oracle University and ORACLE CORPORATION use only
Objectives
User Authentication
– Database user identified by a password – Database user identified by the operating system
• Strong authentication • Enterprise User Security • Proxy authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-3
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-4
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 connections—that 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-5
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 switch—for 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-6
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-7
Oracle University and ORACLE CORPORATION use only
A user that is authenticated externally can execute a SQL*Plus script as follows: sqlplus / @
Fixed User Database Links • Create a public fixed database link:
• Use a public database link: SELECT * FROM emp@TEST;
connect scott/tiger
Finance
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6-9
Oracle University and ORACLE CORPORATION use only
• 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 10
Oracle University and ORACLE CORPORATION use only
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 definer’s 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 definer’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 11
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 12
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 13
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 14
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 15
Oracle University and ORACLE CORPORATION use only
PASSWORD:****
In this lesson, you should have learned how to: • Authenticate users with passwords • Protect passwords • Authenticate users with the OS • Protect database link passwords
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 16
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Implementing an OS-authenticated user connecting locally without a password • Observing the stored password for a fixed database link
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 6 - 17
Oracle University and ORACLE CORPORATION use only
Practice 6 Overview: Using Basic Authentication Methods
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Strong Authentication
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 2
Oracle University and ORACLE CORPORATION use only
After completing this lesson, you should be able to do the following: • Describe strong authentication that uses:
User Authentication
– Database user identified by a password – Database user identified by the operating system
• • •
Strong authentication Enterprise User Security Proxy authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
User Authentication User authentication is a basic security requirement. The user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 3
Oracle University and ORACLE CORPORATION use only
Identify the user in the following ways: • Basic authentication
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 4
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 5
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 6
Oracle University and ORACLE CORPORATION use only
• • •
Public Key Infrastructure (PKI) Tools
– Oracle wallet – Oracle Advanced Security – Oracle Identity Management Infrastructure
•
Management tools: – Oracle Wallet Manager
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 7
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Certificates Certificates are digital documents that are used to provide proof of identity. For example, a certificate from a bank’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 8
Oracle University and ORACLE CORPORATION use only
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 9
Oracle University and ORACLE CORPORATION use only
1. Install the required components. 2. Configure the server for SSL. 3. Configure the server-side Oracle Net files:
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 request—in 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 system’s 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.” THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 10
Oracle University and ORACLE CORPORATION use only
Configuring SSL on the Server
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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=)))
where 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 = ) (PORT = 2484)) ) ) THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 11
Oracle University and ORACLE CORPORATION use only
Configuring Oracle Net Files on the Server
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 12
Oracle University and ORACLE CORPORATION use only
Configuring SSL on the Client
On the client, specify: • The server’s distinguished name • The TCPS protocol listener port • The client wallet location
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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=))) SSL_CLIENT_AUTHENTICATION =TRUE SSL_SERVER_DN_MATCH=(ON)
where 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 13
Oracle University and ORACLE CORPORATION use only
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) ) )
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 14
Oracle University and ORACLE CORPORATION use only
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 '';
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.” THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 15
Oracle University and ORACLE CORPORATION use only
•
Connecting to the Database
CONNECT /@SSL_ORCL;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 16
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: c, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 17
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 18
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Administrator’s 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/
[email protected]
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 19
Oracle University and ORACLE CORPORATION use only
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: "
[email protected]": (password does not display) Re-enter password for principal: "
[email protected]": (password does not display) kadmin.local: exit
9. Create an externally authenticated Oracle user. SQL> CONNECT / AS SYSDBA; SQL> CREATE USER "
[email protected]" IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO "
[email protected]";
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 20
Oracle University and ORACLE CORPORATION use only
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. 4. Get an initial ticket for the Kerberos and Oracle user.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Administrator’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 21
Oracle University and ORACLE CORPORATION use only
How to Use KDC with Windows 2000 for Authentication
$ sqlplus /@orcl
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
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,
[email protected]. 4. Get an initial ticket for the Kerberos and Oracle user. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Administrator’s Guide. From the user’s 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 user’s 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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 23
Oracle University and ORACLE CORPORATION use only
RADIUS Authentication: Overview
Secure External Password Store
vkrama/?????@DEV RAMA
CONNECT /@DEV
ramav/????@prod_db.acme.com
PROD
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 24
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Configuring the Wallet If the wallet does not exist, create the client wallet: mkstore -wrl -create
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: Enter password again:
Add the database connection credentials to the wallet using: $ mkstore -wrl -createCredential []
where 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 /@) must be identical. $ mkstore -wrl $ORACLE_BASE/admin/wallet -createCredential hr_orcl hr hr Enter password: Create credential oracle.security.client.connect_string1
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 25
Oracle University and ORACLE CORPORATION use only
•
Configuring sqlnet.ora
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /home/rama/admin/orcl/wallet))) SQLNET.WALLET_OVERRIDE = TRUE
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 26
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Managing the External Password Store To list the contents of the external password store, enter the following command at the command line: mkstore -wrl -listCredential
To add database login credentials to an existing client wallet, enter the following command: mkstore -wrl \ -createCredential
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 . 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 \ -modifyCredential
To delete database login credentials, enter the following command: mkstore -wrl -deleteCredential
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 27
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 28
Oracle University and ORACLE CORPORATION use only
In this lesson, you should have learned how to: • Describe strong authentication that uses:
This practice covers the following topics: • Configuring the external secure password store • Implementing a user connecting remotely without a password • Viewing the contents of the wallet
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 7 - 29
Oracle University and ORACLE CORPORATION use only
Practice 7 Overview: Configuring the External Secure Password Store
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Enterprise User Security
After completing this lesson, you should be able to do the 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)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 2
Oracle University and ORACLE CORPORATION use only
Objectives
User Authentication
– Database user identified by a password – Database user identified by the operating system
• • •
Strong authentication Enterprise User Security Proxy authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 3
Oracle University and ORACLE CORPORATION use only
Identify the user in the following ways: • Basic authentication
•
• • • •
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Enterprise User Security 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 4
Oracle University and ORACLE CORPORATION use only
Enterprise User Security
Oracle Identity Management Infrastructure: Default Deployment
SSO
DAS
OCA
Oracle Internet Directory Server
Identity Management Infrastructure Database
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 5
Oracle University and ORACLE CORPORATION use only
sso.mydomain.com
Oracle Database: Enterprise User Security Architecture
OracleAS Metadata Repository
OID
Client
Verifies the user Applies roles
Username and password
Oracle DB
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 6
Oracle University and ORACLE CORPORATION use only
Oracle Identity Management
Enterprise User Security supports the following authentication methods: • Password authentication • Secure sockets layer (SSL) authentication • Kerberos authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Administrator’s 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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 7
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 9
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 10
Oracle University and ORACLE CORPORATION use only
Quiz
Setting Up Enterprise User Security
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Setting Up Enterprise User Security In the following slides, the steps required to set up Enterprise User Security are described.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 11
Oracle University and ORACLE CORPORATION use only
1. Install Oracle Application Server Infrastructure. 2. Register the database.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 12
Oracle University and ORACLE CORPORATION use only
Installing Oracle Application Server Infrastructure
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 13
Oracle University and ORACLE CORPORATION use only
Registering the Database
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 14
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 15
Oracle University and ORACLE CORPORATION use only
•
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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://:/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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 16
Oracle University and ORACLE CORPORATION use only
Creating an Enterprise User in the Directory
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 mapping—for 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 17
Oracle University and ORACLE CORPORATION use only
Creating a Schema Mapping Object in the Directory: Subtree
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 18
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 19
Oracle University and ORACLE CORPORATION use only
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 20
Oracle University and ORACLE CORPORATION use only
Oracle Identity Management
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 21
Oracle University and ORACLE CORPORATION use only
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 Administrator’s Guide.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 22
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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 user’s 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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 23
Oracle University and ORACLE CORPORATION use only
Enterprise-User Auditing
In this lesson, you should have learned how to: • 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 24
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Setting up Enterprise User Security • Creating an Enterprise User with a database schema • Configuring enterprise users to use a shared schema
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 8 - 25
Oracle University and ORACLE CORPORATION use only
Practice 8 Overview: Implementing Enterprise User Security
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Proxy Authentication
After completing this lesson, you should be able to do the following: • Describe how proxy authentication works • Manage users authenticated by proxy authentication • Audit users authenticated by proxy
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-2
Oracle University and ORACLE CORPORATION use only
Objectives
User Authentication
– Database user identified by a password – Database user identified by the operating system
• Strong authentication • Enterprise User Security • Proxy authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-3
Oracle University and ORACLE CORPORATION use only
Identify the user in the following ways: • Basic authentication
Security Challenges of Three-Tier Computing
User
Application server
Database
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-4
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-5
Oracle University and ORACLE CORPORATION use only
• The database server needs the end-user identity for the following security functions:
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-6
Oracle University and ORACLE CORPORATION use only
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 user’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-7
Oracle University and ORACLE CORPORATION use only
Common Implementations of Authentication
Distinguished name (DN) Certificate
Proxy authentication is covered in detail later in this lesson.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-8
Oracle University and ORACLE CORPORATION use only
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 user—in this case, a global user—is 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 user’s 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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9-9
Oracle University and ORACLE CORPORATION use only
User Reauthentication
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 10
Oracle University and ORACLE CORPORATION use only
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 SSL—that 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 user’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 11
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 12
Oracle University and ORACLE CORPORATION use only
Proxy authentication solutions depend on the type of the end user: • Known to the database:
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 13
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b, c, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 14
Oracle University and ORACLE CORPORATION use only
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 user’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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).
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 15
Oracle University and ORACLE CORPORATION use only
•
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 16
Oracle University and ORACLE CORPORATION use only
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 user’s 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 user’s 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 user’s 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.
Using Proxy Authentication 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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 17
Oracle University and ORACLE CORPORATION use only
• 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 18
Oracle University and ORACLE CORPORATION use only
ALTER USER phall GRANT CONNECT THROUGH APPSVR AUTHENTICATION REQUIRED PASSWORD;
Using Proxy Authentication 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';
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 19
Oracle University and ORACLE CORPORATION use only
• 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 AUTHENTICATED USING CERTIFICATE
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 AUTHENTICATED USING CERTIFICATE 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 20
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user—in this case, APPSVR. In both cases, notice that the session is for the user named in the "[ ]".
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 21
Oracle University and ORACLE CORPORATION use only
CONNECT APPSVR[PHALL]/appsvr_pwd
Enterprise User Proxy
CONNECT george[APPSVR]/george_pwd
george[APPSVR] APPSVR george
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 22
Oracle University and ORACLE CORPORATION use only
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 23
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 24
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 clause.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 25
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 tier—for 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 user’s identity and authentication, for auditing purposes. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 26
Oracle University and ORACLE CORPORATION use only
• • •
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 27
Oracle University and ORACLE CORPORATION use only
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…”
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 28
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 client’s behalf. The value PROXY MAY ACTIVATE ROLES indicates that only selected roles may be activated. • ROLE: Role referenced in authorization constraint
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 29
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 30
Oracle University and ORACLE CORPORATION use only
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'.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 31
Oracle University and ORACLE CORPORATION use only
• 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 32
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 33
Oracle University and ORACLE CORPORATION use only
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 Oracle Advanced Security – PROXY: Authentication by another user
– EXTERNAL NAME: The distinguished name (DN) of the Enterprise User Security (EUS) user
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 34
Oracle University and ORACLE CORPORATION use only
Data Dictionary Views: DBA_AUDIT_TRAIL
In this lesson, you should have learned how to: • Describe how proxy authentication works • Manage users authenticated by proxy authentication • Audit users authenticated by proxy
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 35
Oracle University and ORACLE CORPORATION use only
Summary
Practice 9 Overview: Implementing Proxy Authentication
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 9 - 36
Oracle University and ORACLE CORPORATION use only
This practice covers the following topics: • Implementing and testing database proxy authentication • Implementing EUS proxy
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Privileges and Roles
After completing this lesson, you should be able to do the following: • Implement database roles • Implement enterprise roles • Use procedures to secure objects • Manage roles and users by using secure application roles
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 2
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 3
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Privileges A privilege is a right to execute a particular type of SQL statement or to access another user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 4
Oracle University and ORACLE CORPORATION use only
Privileges
Roles
Users
Roles
Privileges
Girard
HR_MGR
Delete employees
Vance
HR_CLERK
Select employees
Update employees
Insert employees
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 5
Oracle University and ORACLE CORPORATION use only
Neena
• • • •
Easier privilege management Dynamic privilege management Selective availability of privileges Can be granted through the operating system
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 definer’s rights must have the privileges required for the subprogram granted directly and not through a role. For a subprogram with invoker’s rights, roles are enabled unless the subprogram is invoked directly or indirectly from a definer’s right subprogram. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 6
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 7
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 8
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 GRANT CONNECT THROUGH appsrv 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 GRANT CONNECT THROUGH appsrv WITH NO ROLES;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 9
Oracle University and ORACLE CORPORATION use only
•
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: c, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 10
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 11
Oracle University and ORACLE CORPORATION use only
Enterprise roles can be used similar to job descriptions. • Define the application or database roles required. • Assign the database roles to an enterprise role.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 12
Oracle University and ORACLE CORPORATION use only
Creating an Enterprise Role
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 13
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 definer’s 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 invoker’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 14
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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 Administrator’s Guide 11g Release 2 (11.2) for information about Oracle Database Vault secure application roles.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 15
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 16
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 17
Oracle University and ORACLE CORPORATION use only
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; /
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Step 2.a: Create the Package Specification Because procedures with definer’s rights always execute with the privileges of the owner, secure application roles can be enabled only inside procedures with invoker’s rights. The AUTHID CURRENT_USER clause defines a procedure with invoker’s 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 definer’s rights procedure called from the secure procedure that sets the role. Create a definer’s rights package to return a list of roles from the table (via an open cursor) to the invoker’s rights procedure. Then, fetch from the cursor the list of roles to be enabled.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 18
Oracle University and ORACLE CORPORATION use only
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'); ...
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 19
Oracle University and ORACLE CORPORATION use only
Step 2.b: Create the Package Body
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 20
Oracle University and ORACLE CORPORATION use only
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 user’s session. Example:
GRANT execute ON oe_roles TO appsrv;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 21
Oracle University and ORACLE CORPORATION use only
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 user’s role
•
Set the user’s role by using:
sec.oe_roles.set_sales_rep_role;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 22
Oracle University and ORACLE CORPORATION use only
– 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>
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 23
Oracle University and ORACLE CORPORATION use only
Viewing Dictionary Information for Secure Application Roles
In this lesson, you should have learned how to: • Implement database roles • Implement enterprise roles • Use procedures to secure objects • Manage roles and users by using secure application roles
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 24
Oracle University and ORACLE CORPORATION use only
Summary
Practice 10 Overview: Implementing the Secure Application Role
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 10 - 25
Oracle University and ORACLE CORPORATION use only
This practice covers the following topics: • Implementing the secure application role • Configuring an enterprise role
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Using Application Contexts
After completing this lesson, you should be able to do the 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 2
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 attribute’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 3
Oracle University and ORACLE CORPORATION use only
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 );
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 4
Oracle University and ORACLE CORPORATION use only
• 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s IP address. You would use the USERENV context to access the user’s 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 user’s 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 user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 5
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.”
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 6
Oracle University and ORACLE CORPORATION use only
•
•
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')
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 7
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 8
Oracle University and ORACLE CORPORATION use only
– 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 user’s 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 user’s 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')
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 9
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 10
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s email address. It is assumed for this example that the user’s database account name is the same as the user’s email ID.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 11
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 12
Oracle University and ORACLE CORPORATION use only
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 “Implementing Virtual Private Database” 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 13
Oracle University and ORACLE CORPORATION use only
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 );
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 DBMS_SESSION.SET_CONTEXT ('hrapp', 'emp_id', 0); END; END; / ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS THESE eKIT MATERIALS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 14
Oracle University and ORACLE CORPORATION use only
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; /
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s context must be set before the user accesses any data: CREATE OR REPLACE TRIGGER hr_context_logon AFTER LOGON ON phall.SCHEMA BEGIN hr_context.set_emp_id(); 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: CREATE OR REPLACE TRIGGER hr_context_logon AFTER LOGON ON DATABASE BEGIN hr_context.set_emp_id(); END; /
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 15
Oracle University and ORACLE CORPORATION use only
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');
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Step 4: Read the Context Attribute in the Application Access the application context attributes and use them where they are needed in your application.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 16
Oracle University and ORACLE CORPORATION use only
•
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Application Context Accessed Globally By default, the memory for the application context is allocated from the session’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 17
Oracle University and ORACLE CORPORATION use only
• • •
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 session’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 18
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 19
Oracle University and ORACLE CORPORATION use only
2. Logs in
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 20
Oracle University and ORACLE CORPORATION use only
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 session—for 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);
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 21
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 22
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 23
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 24
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 25
Oracle University and ORACLE CORPORATION use only
CREATE CONTEXT hrapp USING hr_context ACCESSED GLOBALLY;
Step 2: Establish a Session
dbms_session.set_context (context, attr, value, username, client_id); dbms_session.set_context ('hrapp','id','phall','APPSMGR', 12345 ); dbms_session.set_context ('hrapp','dept','sales','APPSMGR', 12345 );
3. Set the session client identifier: dbms_session.set_identifier( 12345 );
4. Save the client identifier in a cookie.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 26
Oracle University and ORACLE CORPORATION use only
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();
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 27
Oracle University and ORACLE CORPORATION use only
dbms_session.set_identifier( 12345 );
Step 4: End a Session
EXEC dbms_session.clear_context ('HRAPP', '12345');
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 28
Oracle University and ORACLE CORPORATION use only
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>
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 29
Oracle University and ORACLE CORPORATION use only
SQL> CREATE CONTEXT hrapp USING hr_context;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 30
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 31
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 32
Oracle University and ORACLE CORPORATION use only
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.
In this lesson, you should have learned how to: • Use an application context • Access the sources of application context values • Implement a local context • Implement an application context that is accessed globally
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 33
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Creating an application context • Setting the context with a secure package • Testing the application context
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 11 - 34
Oracle University and ORACLE CORPORATION use only
Practice 11 Overview: Creating an Application Context
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Implementing Virtual Private Database
After completing this lesson, you should be able to do the following: • Describe fine-grained access control • Describe Virtual Private Database (VPD) • Implement VPD • Group policies
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 2
Oracle University and ORACLE CORPORATION use only
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
SELECT * FROM orders; SELECT * FROM orders WHERE sales_rep_id = 152; Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s statement—transparently to the user or application—so 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 3
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 4
Oracle University and ORACLE CORPORATION use only
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');
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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: SELECT * FROM orders; 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 5
Oracle University and ORACLE CORPORATION use only
Understanding Fine-Grained Access Control Policy Execution
Understanding Fine-Grained Access Control Policy Execution (continued) 4. The Oracle server dynamically modifies the user’s 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 customer’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 6
Oracle University and ORACLE CORPORATION use only
SELECT * FROM orders 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 7
Oracle University and ORACLE CORPORATION use only
– 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 8
Oracle University and ORACLE CORPORATION use only
Virtual Private Database
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')
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 9
Oracle University and ORACLE CORPORATION use only
– 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 user’s query from SELECT * FROM orders to: SELECT * FROM orders 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: SELECT * FROM orders 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')
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 10
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b, c
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 11
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 12
Oracle University and ORACLE CORPORATION use only
– SYS_CONTEXT: Returns context attributes – DBMS_SESSION: Manages:
Tools to Implement Virtual Private Database (continued) DBMS_RLS
Enterprise Manager Alternatively, you can use Enterprise Manager’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 13
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Enterprise Manager Enterprise Manager is the GUI administration tool for the following features: • Oracle Label Security • Virtual Private Database • Application context
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 14
Oracle University and ORACLE CORPORATION use only
Enterprise Manager
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 15
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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).
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 16
Oracle University and ORACLE CORPORATION use only
•
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 17
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 18
Oracle University and ORACLE CORPORATION use only
• •
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; /
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 19
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 20
Oracle University and ORACLE CORPORATION use only
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');
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 variable—that is, the value returned by the function may change, but the cursor remains the same. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 21
Oracle University and ORACLE CORPORATION use only
Static Policies
Context-Sensitive Policies •
The policy function is evaluated for each session when:
•
The resulting policy predicate is cached in the user’s 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');
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 22
Oracle University and ORACLE CORPORATION use only
– The statement is first parsed – There is a related change in the local application context
departments
Same policy function
countries
emp_v
employees
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 company’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 23
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 24
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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? THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 25
Oracle University and ORACLE CORPORATION use only
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 Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 26
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 = SYS_CONTEXT('USERENV', 'SESSION_USER'); DBMS_SESSION.SET_CONTEXT('oeapp', 'cust_id', v_cust_id); EXCEPTION WHEN no_data_found THEN DBMS_SESSION.SET_CONTEXT('oeapp', 'cust_id', NULL); END; END;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 27
Oracle University and ORACLE CORPORATION use only
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 28
Oracle University and ORACLE CORPORATION use only
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; Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 29
Oracle University and ORACLE CORPORATION use only
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 user’s 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 FUNCTION cust_order ( object_schema VARCHAR2, object_name VARCHAR2 ) RETURN VARCHAR2; END; / CREATE OR REPLACE 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_p; /
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 30
Oracle University and ORACLE CORPORATION use only
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')
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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')
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 31
Oracle University and ORACLE CORPORATION use only
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';
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Writing a Function That Returns Different Predicates In reality, you may have several different predicates based on a user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 32
Oracle University and ORACLE CORPORATION use only
•
CREATE OR REPLACE PACKAGE BODY oe_security_p AS FUNCTION cust_order ( 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;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 33
Oracle University and ORACLE CORPORATION use only
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 user’s 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 34
Oracle University and ORACLE CORPORATION use only
4. Create the policy:
To implement Virtual Private Database, you must create a PL/SQL package to set the context. a. True b. False
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: a
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 35
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 manager’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 36
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 37
Oracle University and ORACLE CORPORATION use only
Implementing Policy Groups (continued) Each user accesses different data, based on entirely different policies. The security enforcement is transparent to the user—for 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 38
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 39
Oracle University and ORACLE CORPORATION use only
• • •
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.
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 40
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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;
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 41
Oracle University and ORACLE CORPORATION use only
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 DBMS_SESSION.SET_CONTEXT ('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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 42
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Making the Context a Driving Context 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. Making the Context a Driving Context Define the driving context for the ORDERS table: DBMS_RLS.ADD_POLICY_CONTEXT ('OE', 'ORDERS' , 'APP_DRIVER', 'ACTIVE_APP');
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 43
Oracle University and ORACLE CORPORATION use only
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 SELECT customer_id INTO v_cust_id FROM oe.customers WHERE cust_first_name || '_' || cust_last_name = SYS_CONTEXT('USERENV', 'SESSION_USER'); DBMS_SESSION.SET_CONTEXT('oe', 'cust_id', v_cust_id); apps_context.set_driver('OE_GRP');-- set the driver EXCEPTION WHEN no_data_found THEN 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 44
Oracle University and ORACLE CORPORATION use only
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' );
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 45
Oracle University and ORACLE CORPORATION use only
•
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'); Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 46
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 47
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 48
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 49
Oracle University and ORACLE CORPORATION use only
•
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 user’s 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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 50
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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: SELECT customer_id INTO v_cust_id FROM oe.customers WHERE cust_first_name || '_' || cust_last_name = SYS_CONTEXT('USERENV', 'SESSION_USER'); 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')
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 51
Oracle University and ORACLE CORPORATION use only
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 WHERE cust_first_name || '_' || cust_last_name = 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 52
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 53
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 54
Oracle University and ORACLE CORPORATION use only
Policy Views
Checking for Policies Applied to SQL Statements SQL> SELECT distinct policy, predicate, sql_text FROM v$vpd_policy p,
3
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 55
Oracle University and ORACLE CORPORATION use only
2
In this lesson, you should have learned how to: • Describe VPD • Implement VPD • Group policies
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 56
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Creating a policy function • Enabling the policy • Testing the policy
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 12 - 57
Oracle University and ORACLE CORPORATION use only
Practice 12 Overview: Implementing a Virtual Private Database Policy
Oracle University and ORACLE CORPORATION use only THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Label Security Concepts
Objectives
– Label concepts – Access mediation
• Determine when to use Oracle Label Security
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Administrator’s Guide.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 2
Oracle University and ORACLE CORPORATION use only
After completing this lesson, you should be able to do the 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Access Control: Overview Access control defines the user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 3
Oracle University and ORACLE CORPORATION use only
Oracle provides two complementary access control models: • Discretionary access control (DAC)
Discretionary Access Control
Joe REVOKE SELECT ON emp FROM fred;
Fred Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 Fred’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 4
Oracle University and ORACLE CORPORATION use only
GRANT SELECT ON emp TO joe;
Oracle Label Security
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Oracle Label Security 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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 5
Oracle University and ORACLE CORPORATION use only
SQL request
How Sensitivity Labels Are Used
Authorizations
Access mediation
Data
Labels Data sensitivity
Secret
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s “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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 6
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 7
Oracle University and ORACLE CORPORATION use only
Installing Oracle Label Security
Oracle Label Security is used as an alternative to discretionary access control. a. True b. False
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 9
Oracle University and ORACLE CORPORATION use only
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 10
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 11
Oracle University and ORACLE CORPORATION use only
– 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
Oracle Database Vault
User clearance may be used as a factor to control access.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 12
Oracle University and ORACLE CORPORATION use only
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 Oracle Database Vault
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 13
Oracle University and ORACLE CORPORATION use only
• Identify application tables that need Oracle Label Security:
Summary
– Label concepts – Access mediation
• Determine when to use Oracle Label Security
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED Oracle Database 11g: Security 13 - 14
Oracle University and ORACLE CORPORATION use only
In this lesson, you should have learned how to: • Describe Oracle Label Security
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Implementing 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 2
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 3
Oracle University and ORACLE CORPORATION use only
Implementing an Oracle Label Security Solution
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 4
Oracle University and ORACLE CORPORATION use only
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 Security–enabled 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 Administrator’s 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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 5
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 6
Oracle University and ORACLE CORPORATION use only
– 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 7
Oracle University and ORACLE CORPORATION use only
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 session’s 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 8
Oracle University and ORACLE CORPORATION use only
•
• •
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 9
Oracle University and ORACLE CORPORATION use only
Defining Levels by Using Enterprise Manager
BEGIN SA_COMPONENTS.CREATE_LEVEL( POLICY_NAME =>'FACILITY', LEVEL_NUMBER => '100', SHORT_NAME => 'P', LONG_NAME => 'PUBLIC'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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);
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 10
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.)
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 11
Oracle University and ORACLE CORPORATION use only
Defining Groups by Using Enterprise Manager
BEGIN SA_COMPONENTS.CREATE_GROUP( POLICY_NAME =>'FACILITY', GROUP_NUMBER => '1000', SHORT_NAME => 'WR_SAL', LONG_NAME => 'WR_SALES', PARENT_NAME => 'WR'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 ( policy_name IN VARCHAR2, group_num IN INTEGER, short_name IN VARCHAR2, long_name IN VARCHAR2, parent_name IN VARCHAR2 DEFAULT NULL); Example BEGIN SA_COMPONENTS.CREATE_GROUP('FACILITY',1000, 'WR','WESTERN_REGION'); SA_COMPONENTS.CREATE_GROUP('FACILITY',1200, 'WR_FIN','WR_FINANCE','WR'); SA_COMPONENTS.CREATE_GROUP('FACILITY',1210, 'WR_AP','WR_ACCT_PAYABLE','WR_FIN'); END; THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 12
Oracle University and ORACLE CORPORATION use only
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:
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 13
Oracle University and ORACLE CORPORATION use only
Defining Compartments by Using Enterprise Manager
BEGIN SA_COMPONENTS.CREATE_COMPARTMENT( POLICY_NAME =>'FACILITY', COMP_NUMBER => '85', SHORT_NAME => 'FIN', LONG_NAME => 'Financial'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 ( policy_name IN VARCHAR2, comp_num IN INTEGER, short_name IN VARCHAR2, long_name IN VARCHAR2);
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 14
Oracle University and ORACLE CORPORATION use only
Creating Compartments
Identifying Data Labels
LEVEL:COMPARMENT:GROUP ---------------------------------------------SENSITIVE:FINANCIAL,CHEMICAL:WESTERN_REGION CONFIDENTIAL:FINANCIAL:WR_SALES SENSITIVE:: HIGHLY_SENSITIVE:FINANCIAL: SENSITIVE::WESTERN_REGION
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 15
Oracle University and ORACLE CORPORATION use only
Create a set of data labels from the components already defined.
BEGIN SA_LABEL_ADMIN.CREATE_LABEL( POLICY_NAME =>'FACILITY', LABEL_TAG => '201000', LABEL_VALUE => 'S::WR'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 _DBA role can create labels by using the CREATE_LABEL procedure in the SA_LABEL_ADMIN package or by using Enterprise Manager. The _DBA role is created when the policy is created. Syntax PROCEDURE CREATE_LABEL ( policy_name IN VARCHAR2, 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; THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 16
Oracle University and ORACLE CORPORATION use only
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
X
Location
Storage
OLS Label
Nevada
Conventional
Sensitive
Montana
Nuclear
Highly Sens.
Colorado
Medical
Confidential
Sensitive
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 17
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 person’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 18
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 19
Oracle University and ORACLE CORPORATION use only
• • •
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;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 IN VARCHAR2 DEFAULT NULL, label_function IN VARCHAR2 DEFAULT NULL, predicate IN VARCHAR2 DEFAULT NULL); THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 20
Oracle University and ORACLE CORPORATION use only
• •
A user is assigned: • Maximum and minimum labels • A default session label • A row label for inserts BEGIN SA_USER_ADMIN.SET_USER_LABELS ( POLICY_NAME =>'FACILITY', USER_NAME => 'MYCO_MGR', MAX_READ_LABEL =>'S::US,EU,ASIA'); END;
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 21
Oracle University and ORACLE CORPORATION use only
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 user’s maximum authorized read label. It is composed of the user’s 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 user’s maximum authorized write label. It is composed of the user’s 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 user’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 22
Oracle University and ORACLE CORPORATION use only
Step 6: Assign User Authorization Labels (continued) Specify the user’s 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 SA_USER_ADMIN.SET_USER_LABELS ( 'FACILITY','MYCO_EMP','P'); SA_USER_ADMIN.SET_USER_LABELS ( 'FACILITY','MYCO_MGR','S::US,EU,ASIA'); SA_USER_ADMIN.SET_USER_LABELS ( '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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: c, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 23
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 row’s 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 Administrator’s Guide.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 24
Oracle University and ORACLE CORPORATION use only
Oracle Label Security Special User Privileges
Example: READ Privilege
All rows returned
READ privilege SELECT
Labeled data rows Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 25
Oracle University and ORACLE CORPORATION use only
User-label authorizations None
Example: FULL Privilege
Labeled data rows
FULL privilege Any DML All rows affected
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 26
Oracle University and ORACLE CORPORATION use only
User-label authorizations Any
Example: COMPACCESS Privilege
Data label Compartment = OP, Group=Any
COMPACCESS privilege
Labeled data rows Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Example: COMPACCESS Privilege The COMPACCESS privilege allows a session to access rows on the basis of the row’s 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 situations—for example, where a compartment is created for a project that crosses groups but does not include all members of each group.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 27
Oracle University and ORACLE CORPORATION use only
User-label authorizations 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 28
Oracle University and ORACLE CORPORATION use only
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);
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 29
Oracle University and ORACLE CORPORATION use only
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 _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'); Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 _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 user’s Oracle Label Security privileges. This allows the total purchases to be calculated.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 30
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 31
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 _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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 32
Oracle University and ORACLE CORPORATION use only
• •
• • •
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 33
Oracle University and ORACLE CORPORATION use only
Performance Tips
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 34
In this lesson, you should have learned how to: • Creating policies • Defining labels • Setting up user authorizations • Applying policies to tables
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 35
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • Creating a label security solution for a given scenario • Creating policies • Creating labels • Applying policies • Testing access control
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 14 - 36
Oracle University and ORACLE CORPORATION use only
Practice 14 Overview: Implementing Oracle Label Security
Copyright © 2010, Oracle. All rights reserved.
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
Using the Data Masking Pack
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
Copyright © 2010, Oracle. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 2
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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 data’s properties, such as width, type, and format.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 3
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 4
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
Using the Data Masking Pack 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 5
Oracle University and ORACLE CORPORATION use only
Using the Data Masking Pack
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 6
Oracle University and ORACLE CORPORATION use only
• •
• • •
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
Copyright © 2010, Oracle. All rights reserved.
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 Pack’s central definition for common data masking formats, you can apply data privacy rules consistently to all production data and ensure compliance with regulations.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 7
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
Data Masking: Best Practices Create a library of data format masks that can be used consistently across databases.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 8
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
Implementing Data Masking 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 9
Oracle University and ORACLE CORPORATION use only
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.
Oracle University and ORACLE CORPORATION use only
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 10
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'; Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 11
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
Answer: a, b, d
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 12
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 13
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 14
Oracle University and ORACLE CORPORATION use only
Managing the Data Mask Format Library
Using Oracle-Supplied Mask Formats
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 15
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 16
Oracle University and ORACLE CORPORATION use only
Types of Built-in Masking Primitives and Routines
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 17
Oracle University and ORACLE CORPORATION use only
Types of Built-in Masking Primitives and Routines
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 18
Oracle University and ORACLE CORPORATION use only
EMPLOYEE_ID
Creating Data Mask Formats
Copyright © 2010, Oracle. All rights reserved.
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 Driver’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 19
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle. All rights reserved.
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 user’s 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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 20
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 21
Oracle University and ORACLE CORPORATION use only
• •
• • • • • •
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 22
Oracle University and ORACLE CORPORATION use only
Creating Data Masking Definitions
Using Masking Formats
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 23
Oracle University and ORACLE CORPORATION use only
Create a masking definition by using built-in format entries:
Automatic Identification of Related Columns
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 24
Oracle University and ORACLE CORPORATION use only
The masking definition automatically includes foreign keys.
Adding Dependent Columns
Copyright © 2010, Oracle. All rights reserved.
Adding Dependent Columns If the relationships between tables are defined in the application, you can use the Dependent Column feature to add associated columns.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 25
Oracle University and ORACLE CORPORATION use only
Implement data masking for application-based referential integrity by adding dependent columns:
Importing Formats
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 26
Oracle University and ORACLE CORPORATION use only
Create the masking definition by using a previously defined format:
Importing Formats and Modifying Properties
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 27
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 28
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 29
Oracle University and ORACLE CORPORATION use only
Using Compound Masking
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 30
Oracle University and ORACLE CORPORATION use only
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;
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 31
Oracle University and ORACLE CORPORATION use only
Creating a Post-Processing Function
Implementing a Post-Processing Function
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 32
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 33
Oracle University and ORACLE CORPORATION use only
•
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 34
Oracle University and ORACLE CORPORATION use only
Viewing the Data Masking Impact Report
Copyright © 2010, Oracle. All rights reserved.
Viewing the Data Masking Script The script generation step produces a script that you can review and save.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 35
Oracle University and ORACLE CORPORATION use only
Viewing the Data Masking Script
•
Schedule immediately after script generation:
•
Schedule on the Data Masking Definitions page:
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 36
Oracle University and ORACLE CORPORATION use only
Scheduling the Data Masking Job
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 37
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 38
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 39
Oracle University and ORACLE CORPORATION use only
Creating an Application Masking Template
Importing Data Masking Definitions Import a previously exported masking definition. Masking definition is imported into the Enterprise Manager repository.
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 40
Oracle University and ORACLE CORPORATION use only
• •
• • • • •
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
Copyright © 2010, Oracle. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 41
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle. All rights reserved.
Creating Custom Reports for Auditors The Data Masking Pack enables you to create custom reports to monitor and audit data masking operations.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 42
Oracle University and ORACLE CORPORATION use only
•
Copyright © 2010, Oracle. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 43
Oracle University and ORACLE CORPORATION use only
Creating Custom Reports for Auditors
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 44
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 45
Oracle University and ORACLE CORPORATION use only
Summary
This practice covers the following topics: • 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
Copyright © 2010, Oracle. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 15 - 46
Oracle University and ORACLE CORPORATION use only
Practice 15 Overview: Implementing Data Masking
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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
Encryption Concepts
After completing this lesson, you should be able to do the 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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 2
Oracle University and ORACLE CORPORATION use only
Objectives
Understanding Encryption •
Data is encrypted and decrypted:
•
Key management is critical. – Secure transmission – Secure storage (avoiding loss)
Encrypt/Decrypt
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 3
Oracle University and ORACLE CORPORATION use only
– With an encryption algorithm – Using a key or “secret”
What Problems Does Encryption Solve?
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 4
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 employee’s 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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 5
Oracle University and ORACLE CORPORATION use only
– 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 6
Oracle University and ORACLE CORPORATION use only
• • •
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. Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 7
Oracle University and ORACLE CORPORATION use only
•
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 8
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 9
Oracle University and ORACLE CORPORATION use only
What to Encrypt
Encryption enables you to control who has access to the encrypted data. a. True b. False
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Answer: b
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 10
Oracle University and ORACLE CORPORATION use only
Quiz
Data Encryption: Challenges Key management: – – – –
•
Generation Changing Transmission Storage
Encrypting special types of data: – Indexed – Large objects (LOBs)
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 11
Oracle University and ORACLE CORPORATION use only
•
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 12
Oracle University and ORACLE CORPORATION use only
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
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 13
Oracle University and ORACLE CORPORATION use only
– 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 14
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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 THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 15
Oracle University and ORACLE CORPORATION use only
Storing the Key in the Database
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 16
Oracle University and ORACLE CORPORATION use only
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 User’s 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 key–foreign 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 17
Oracle University and ORACLE CORPORATION use only
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 18
Oracle University and ORACLE CORPORATION use only
Letting the User Manage the Key
Solutions Oracle Database Vault Transparent Data Encryption (TDE) File encryption – RMAN backup encryption – Oracle Secure Backup
•
Application encryption
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
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. THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 19
Oracle University and ORACLE CORPORATION use only
• • •
In this lesson, you should have learned how to: • Discuss the issues of encryption • Discuss the challenges of encryption • Describe key management solutions • Describe the encryption options available with Oracle Database 11g
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Oracle Database 11g: Security 16 - 20
Oracle University and ORACLE CORPORATION use only
Summary
