Oracle Database 11g Security

Table of Contents Security: New Features ...1-2 Chapter 1Security: New Features ...1-2 Objectives...1-3 Secure Password Support ...1-4 Automatic Secure Configuration ...1-5 Password Conf

Oracle Database 11g: Security

Copyright © 2007, Oracle All rights reserved

This documentation contains proprietary information of Oracle Corporation It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law Reverse engineering of the software is prohibited If this documentation is delivered to a U.S Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988)

This material or any portion of it may not be copied in any form or by any means without the express prior written permission of the Education Products group of Oracle Corporation Any other copying is a violation of copyright law and may result in civil and/or criminal penalties

If this documentation is delivered to a U.S Government Agency not within the Department of Defense, then it is delivered with

“Restricted Rights,” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987)

The information in this document is subject to change without notice If you find any problems in the documentation, please report them

in writing to Worldwide Education Services, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065 Oracle Corporation does not warrant that this document is error-free

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates Other names may be

trademarks of their respective owners

Author

James Spiller

Technical Contributors and Reviewers

Amith Mahalingaiah, Hozefa Palitanawala, Sudheesh Varma

This book was published using: oracletutor

Table of Contents

Security: New Features 1-2

Chapter 1Security: New Features 1-2 Objectives 1-3 Secure Password Support 1-4 Automatic Secure Configuration 1-5 Password Configuration 1-6 Enable Built-in Password Complexity Checker 1-7 Managing Default Audits 1-8 Adjust Security Settings 1-10 Setting Security Parameters 1-11 Using RMAN Security Enhancements 1-13 Creating and Using Virtual Private Catalogs 1-14 Using RMAN Virtual Private Catalogs 1-15 Summary 1-17

11g Security Optional New Features 2-2

Chapter 211g Security Optional New Features 2-2 Objectives 2-3 Transparent Data Encryption 2-4 Using Tablespace Encryption 2-6 TDE and LogMiner 2-7 TDE and Logical Standby 2-8 TDE and Streams 2-9 Hardware Security Module 2-10 Using a Hardware Security Module with TDE 2-11 Encryption for LOB Columns 2-12 Using Kerberos Enhancements 2-13 Enterprise Manager Security Management 2-14 Managing TDE with Enterprise Manager 2-15 Managing Tablespace Encryption with Enterprise Manager 2-16 Managing Virtual Private Database 2-17 Managing Label Security with Enterprise Manager 2-18 Managing Label Security with Oracle Internet Directory 2-19 Managing Enterprise Users with Enterprise Manager 2-20 Enterprise Manager Policy Trend 2-21 Oracle Audit Vault Enhancements 2-22 Managing Fine-Grained Access to External Network Services 2-23 Demonstration 2-25 Summary 2-26

Security: New Features

Chapter 1Security: New Features

Security: New Features

Objectives

Objectives

After completing this lesson, you should be able to:

• Configure strong authentication for privileged users

• Create a virtual private catalog for RMAN

Secure Password Support

Secure Password Support

More Secure Password Support Passwords

• Are case sensitive

• Contain more characters

• Use more secure hash algorithm

• Use salt in the hash algorithm

Usernames are still Oracle identifiers (up to 30 characters,

case insensitive)

You must use more secure passwords to meet the demands of compliance to various security and privacy regulations Passwords that very short and passwords that are 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 is handled differently than in previous versions;

• Passwords are case sensitive Upper and lower case characters are now different characters when used in a password

• Passwords may contain multibyte characters without quoting Only the ‘$’,’_’, and ‘#’

special characters are allowed in the password without quoting the password

• Passwords are always passed through a hash algorithm, then stored as a user credential When the user presents a password, it is hashed then compared to the stored credential In

Oracle Database 11g the hash algorithm is SHA-1 of the public algorithm used in previous

versions of the database SHA-1 is a stronger algorithm using 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 insure the output

credential in unique

Automatic Secure Configuration

Automatic Secure Configuration

• Default password profile

• Default auditing

• Built-in Password complexity checking

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 10gR2 default installation; 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

Password Configuration

Password Configuration

By default:

• Default password profile is enabled

• Account is locked after 10 failed login attempts

In upgrade:

• Passwords are case insensitive until changed

• Passwords become case sensitive by ALTER USER

On creation:

• Passwords are case sensitive

When creating a custom database 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, the instance delays each login after the third try This protection applies for attempts made from different IP

addresses or multiple client connections Afterwards, it gradually increases the time before the user can try another password, up to a maximum of about ten seconds

The default password profile is enabled with these 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 10g is upgraded, passwords are case insensitive until the ALTER USER… command is used to change the password

When the database is created, the passwords will be case sensitive by default

Enable Built-in Password Complexity Checker

Enable Built-in Password Complexity Checker

Execute the utlpwdmg.sql script to create the password

verify function:

Alter the default profile:

ALTER PROFILE DEFAULT

verify_function are included in the utlpwdmg.sql file

To enable the 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 nor create users The solution is to set the PASSWORD_VERIFY_FUNCTION to NULL in the profile, until the problem is solved

The verify_function11g function checks that the password: contains at least 8 characters, contains at least one number and one alphabetic character, and differs from the previous password

by at least 3 characters The function also checks that the password is not: a username or

username appended with an number 1 to 100, a username reversed, a server name or server name appended with 1-100, or one of a set of well know and common passwords such as 'welcome1', 'database1', 'oracle123', or oracle(appended with 1-100), etc

Managing Default Audits

Managing Default Audits

Review Audit logs:

• Default audit options cover important security

privileges

Archive Audit records

• Export

• Copy to another table

Remove archived audit records

Review the audit logs By default, auditing is enabled in Oracle Database 11g for certain

privileges that are very important to security The audit trail is recorded in the database AUD$

table by default; the AUDIT_TRAIL parameter is set to DB These audits should not have a large impact on database performance, for most sites Oracle recommends the use of OS audit trail files

Archive audit records To retain audit records export using Datapump export, or use the

SELECT statement to capture a set of audit records into a separate table

Remove archived audit records Remove audit records from the SYS.AUD$ table after review and archive Audit records take up space in the SYSTEM tablespace If the SYSTEM tablespace cannot grow, and there is not more space for audit records errors will be generated for each audited statement Since CREATESESSION is one of the audited privileges, no new sessions may be created except by a user connected ASSYSDBA Archive the audit table with the export utility using the QUERY option to specify WHERE clause with a range of dates, or SCNs, then delete from the audit table using the same WHERE clause

When AUDIT_TRAIL=OS separate files are created for each audit record in the directory

specified by AUDIT_FILE_DEST All files as of a certain time can be copied, then removed

Note: the SYSTEM tablespace is created with the autoextend on option So the SYSTEM

tablespace will grow as needed until there is no more space available on the disk

The following privileges are audited for all users on success and failure, and by access:

CREATE EXTERNAL JOB CREATE ANY JOB GRANT ANY OBJECT PRIVILEGE EXEMPT ACCESS POLICY

CREATE ANY LIBRARY GRANT ANY PRIVILEGE DROP PROFILE

ALTER PROFILE DROP ANY PROCEDURE ALTER ANY PROCEDURE CREATE ANY PROCEDURE ALTER DATABASE

GRANT ANY ROLE CREATE PUBLIC DATABASE LINK DROP ANY TABLE

ALTER ANY TABLE CREATE ANY TABLE DROP USER

ALTER USER CREATE USER CREATE SESSION AUDIT SYSTEM ALTER SYSTEM

The following statements are audited for all users on success and failure, and by access:

SYSTEM AUDIT ROLE

Adjust Security Settings

Adjust Security Settings

Need Beta 5 Screenshot

When you create a database using the DBCA tool, you are offered a choice of security settings:

• Keep the enhanced 11g default security settings (recommended) These settings include

enabling auditing and new default password profile

• Revert to pre-11g default security settings To disable a particular category of enhanced

settings for compatibility purposes choose from the following:

- Revert audit settings to pre-11g defaults

- Revert password profile settings to pre-11g defaults

These settings can also be changed after the database is created using DBCA Some applications may not work properly under the 11g default security settings

Secure permissions on software are always set It is not impacted by user’s choice for ‘Security Settings’ option

Setting Security Parameters

Setting Security Parameters

Use case sensitive passwords

A set of new parameters have been added to the Oracle Database 11g to enhance the default

security of the database These parameters are system wide and static

Use case sensitive passwords to improve security

A new parameter SEC_CASE_SENSITIVE_LOGON allows you to set the case sensitivity of user passwords Oracle recommends that you retain the default setting of TRUE You can specify case insensitive passwords for backward compatibility by setting this parameter to FALSE:

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE

Note: Disabling case sensitivity increases vulnerability to brute force attacks

Protect against denial of Service (DoS) attacks

The two parameters shown specify the actions to be taken when the database receives bad packets from a client The assumption is that the bad packets are from a possible malicious client The

SEC_PROTOCOL_ERROR_FURTHER_ACTION parameter specifies what action is to be taken with the client connection: Continue, drop the connection, or delay accepting requests The other parameter SEC_PROTOCOL_ERROR_TRACE_ACTION specifies a monitoring action: NONE,

TRACE, LOG, or ALERT

Protect Against Brute Force Attacks

A new initialization parameter SEC_MAX_FAILED_LOGIN_ATTEMPTS, which has a default setting of 10, causes a connection to be automatically dropped after the specified number of attempts This parameter is enforced even when the password profile is not enabled

This parameter prevents a program from making a database connection and then attempting to authenticate by trying hundreds or thousands of passwords

Using RMAN Security Enhancements

Using RMAN Security Enhancements

• Configure backup shredding:

• Use backup shredding:

RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON;

RMAN> DELETE FORCE;

Backup shredding is a key management feature that allows the DBA to delete the encryption key

of transparent encrypted backups, without physical access to the backup media The encrypted backups are rendered inaccessible if the encryption key is destroyed This does not apply to password-protected backups

Configure backup shredding with:

CONFIGURE ENCRYPTION FOR DATABASE ON;

Or

SET ENCRYPTION ON;

The default setting is OFF, and backup shredding is not enabled To shred a backup, no new command is needed, simply use:

DELETE FORCE;

Protect against brute force attacks

A new initialization parameter SEC_MAX_FAILED_LOGIN_ATTEMPTS that has a default setting of 10 causes a connection to be automatically dropped after the specified number of

attempts This parameter is enforced even when the password profile is not enabled

This helps to prevent automated password crackers from making a connection and attempting hundreds or thousands of passwords

Creating and Using Virtual Private Catalogs

RMAN base catalog

Virtual private catalogs (VPC)

Enhances security

by restricting access

to metadata

Databases registered in RMAN catalog

Creating and Using Virtual Private Catalogs

This feature allows a consolidation of RMAN repositories and maintains a separation of

responsibilities, which is a basic security requirement

The RMAN catalog has been enhanced to create virtual private RMAN catalogs for groups of databases and users The catalog owner creates the base catalog and grants the

RECOVERY_CATALOG_OWNER privilege to the owner of the virtual catalog The catalog owner can either grant access to a registered database or grant the REGISTER privilege to the virtual catalog owner The virtual catalog owner can then connect to the catalog for a particular target or register a target database After this configuration, the VPC owner uses the virtual private catalog just like a standard base catalog

As catalog owner, you can access all the registered database information in the catalog You can list all databases registered with the SQL*Plus command:

SELECT DISTINCT db_name FROM DBINC;

As virtual catalog owner, you can see only the databases to which you have been granted access

Note: If a catalog owner has not been granted SYSDBA or SYSOPER on the target database, then most RMAN operations cannot be performed

Using RMAN Virtual Private Catalogs

Using RMAN Virtual Private Catalogs

1 Create an RMAN base catalog:

2 Grant RECOVERY_CATALOG_OWNER to VPC owner:

3a Grant REGISTER to the VPC owner, or:

3b Grant CATALOG FOR DATABASE to the VPC owner:

RMAN> CONNECT CATALOG catowner/oracle@catdb;

RMAN> CREATE CATALOG;

SQL> CONNECT SYS/oracle@catdb AS SYSDBA

SQL> GRANT RECOVERY_CATALOG_OWNER to vpcowner

RMAN> CONNECT CATALOG catowner/oracle@catdb;

RMAN> GRANT REGISTER DATABASE TO vpcowner;

RMAN>GRANT CATALOG FOR DATABASE db10g TO vpcowner

You create virtual private RMAN catalogs for groups of databases and users

1 The catalog owner creates the base catalog

2 The DBA on the catalog database creates the user that will own the virtual private catalog (VPC) and grants him or her the RECOVERY_CATALOG_OWNER privilege

3 The base catalog owner can grant access for previously registered databases to the VPC owner or grant REGISTER to the VPC owner The GRANT CATALOG command is:

GRANT CATALOG FOR DATABASE prod1, prod2 TO vpcowner;

The GRANTREGISTER command is:

GRANT REGISTER DATABASE TO vpcowner;

The virtual catalog owner can then connect to the catalog for a particular target or register a target database After the VPC is configured, the VPC owner uses it just like a standard base catalog

Using RMAN Virtual Private Catalogs

Using RMAN Virtual Private Catalogs

4a. Create a virtual catalog for 11g clients, or:

4b. Create a virtual catalog for pre-11g clients:

5 Register a new database in the catalog:

6 Use the virtual catalog:

RMAN> CONNECT CATALOG vpcowner/oracle@catdb;

RMAN> CREATE VIRTUAL CATALOG;

SQL> CONNECT vpcowner/oracle@catdb

SQL> exec catowner.dbms_rcvcat.create_virtual_catalog;

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;

RMAN> REGISTER DATABASE;

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb;

RMAN> BACKUP DATABASE;

4 Create a virtual private catalog

a If the target database is an Oracle Database 11g database and the RMAN client is an 11g

client, you can use the RMAN command:

CREATE VIRTUAL CATALOG;

b If the target database is Oracle Database 10g Release 2 or earlier (using a compatible

client), you must execute the supplied procedure from SQL*Plus:

base_catalog_owner.dbms_rcvcat.create_virtual_catalog;

5 Connect to the catalog using the VPC owner login, and use it as a normal catalog

6 The virtual catalog owner can see only those databases that have been granted For most RMAN operations, you additionally need the SYSDBA or SYSOPER privileges on the target database

Summary

Summary

In this lesson, you should have learned how to:

• Configure strong authentication for privileged users

• Create a virtual private catalog for RMAN

11g Security Optional New

Features

Chapter 211g Security Optional New Features

11g Security Optional New Features