oracle database 11g security_d52365

Oracle Database 11 g: Security

Student Guide

D52365GC10

Edition 1.0

October 2007

PRODUCTION

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: oracle tutor


Oracle Database 11g: Security Table of Contents i

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


Oracle Database 11g: Security Table of Contents ii


Security: New Features Chapter 0 - Page 1

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 user s• 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 ch aracters, 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 passw ord verify function:

Alter the default profile:

ALTER PROFILE DEFAULTLIMIT PASSWORD_VERIFY_FUNCTION verify_function_11g;

SQL> CONNECT / as SYSDBASQL> @?/rdbms/admin/utlpwdmg.sql

The verify_function_11g is a sample PL/SQL function that can be easily modified to enforce the password complexity policies at your site. This function does not require special characters to be embedded in the password. Both the verify_function_11g and the older 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

privilegesArchive 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 CREATE SESSION is one of the audited privileges, no new sessions may be created except by a user connected AS SYSDBA. 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 passwordsSEC_CASE_SENSITIVE_LOGON

Protect against DoS attacksSEC_PROTOCOL_ERROR_FURTHER_ACTION

SEC_PROTOCOL_ERROR_TRACE_ACTION

Protect against brute force attacksSEC_MAX_FAILED_LOGIN_ATTEMPTS

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

RMANbase

catalog

Virtual private catalogs (VPC)

Enhances securityby 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


1. Create an RMAN base catalog:

2. Grant RECOVERY_CATALOG_OWNERto VPC owner:

3a. Grant REGISTERto the VPC owner, or:

3b. Grant CATALOG FOR DATABASEto the VPC owner:

RMAN> CONNECT CATALOG catowner/oracle@catdb; RMAN> CREATE CATALOG;

SQL> CONNECT SYS/oracle@catdb AS SYSDBASQL> 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 GRANT REGISTER 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.





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

4b. Create a virtual catalog for pre-11 g 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@catdbSQL> exec catowner.dbms_rcvcat.create_virtual_catal og;

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catd b;RMAN> REGISTER DATABASE;

RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catd b;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_catal og;

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 user s• Create a virtual private catalog for RMAN


11g Security Optional New Features Chapter 0 - Page 1

11g Security Optional New Features



Chapter 211g Security Optional New Features

11g Security Optional New Features



Objectives

Objectives

After completing this lesson, you should be able to :• Encrypt a tablespace• Use a Hardware Security Module with TDE• Use Enterprise Manager to manage security options • Configure fine-grained access to network services



Transparent Data Encryption

Transparent Data Encryption

New features in TDE include:• Tablespace Encryption• Support for LogMiner• Support for Logical Standby• Support for Streams• Support for Asynchronous Change Data Capture• Hardware based Master key protection• Encryption for LOB columns• Encryption / compression for Data Pump data

Several new features enhance the capabilities of Transparent Data Encryption, and build on the same infrastructure. The changes in LogMiner to support TDE provide the infrastructure for change capture engines used for Logical Standby, Streams, and Asynchronous Change Data Capture. LogMiner requires access to the Wallet, through a mounted instance and a open wallet. LogMiner does not support Hardware Security Module (HSM) or user held keys. For Logical Standby, the logs may be mined either on the source or target database, thus the wallet must be the same for both databases. Encrypted columns are handled the same way in both Streams and the Streams based Change Data Capture. The redo records are mined at the source, where the wallet exists. The data is transmitted unencrypted to the target and encrypted using the wallet at the target. The data can be encrypted in transit using Advanced Security Option to provide network encryption. Oracle Database 11g introduces a completely reengineered large object (LOB) data type called SecureFiles offering compression and transparent encryption. Oracle Database 11g extends Data Pump compression capability so that you can now compress table data on export. Data Pump compression is an inline operation, so the reduced dump file size means a significant savings in disk space. Unlike operating system or file system compression utilities, Data Pump compression is fully inline on the import side as well, so there is no need to uncompress a dump file before importing it. You get full Data Pump functionality using a compressed file. Any command that you would use on a regular file also works on a compressed file.



In Oracle Database 11g, Data Pump supplies more encryption options for more flexible and robust security. The most important new encryption feature for Data Pump is the ability to encrypt dump file sets. You can select encryption for the data, the metadata, or the entire dump file as your needs require. Please refer to the Oracle® Database Utilities 11g Release 1 (11.1) guide for more information on Data Pump.



Using Tablespace Encryption

Using Tablespace Encryption

Create an encrypted tablespace1. Create or open the encryption wallet

2. Create a tablespace with the encryption keywords

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "welcome1";

SQL> CREATE TABLESPACE encrypt_ts2> DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100 M3> ENCRYPTION USING '3DES168'4> DEFAULT STORAGE (ENCRYPT);

Tablespace encryption is based on block level encryption that encrypts on write and decrypts on read. The data is not encrypted in memory. The only encryption penalty is associated with I/O. The SQL access paths are unchanged and all data types are supported. To use tablespace encryption the encryption wallet must be open. The CREATE TABLESPACE command has an ENCRYPTION clause that sets the encryption properties, and an ENCRYPT storage parameter that causes the encryption to be used. You specify USING 'encrypt_algorithm' to indicate the name of the algorithm to be used. Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES128. You can view the properties in the V$ENCRYPTED_TABLESPACES view. The encrypted data is protected during operations like JOIN and SORT. This means that the data is safe when it is moved to temporary tablespaces. Data in undo and redo logs is also protected. Encrypted tablespaces are transportable if the platforms have same endianess and the same wallet.

Restrictions: • Temporary and undo tablespaces cannot be encrypted. (selected blocks are encrypted)

• Bfiles and external tables are not encrypted.

• Transportable tablespaces across different endian platforms is not supported.

• The key for an encrypted tablespaces cannot be changed at this time. A workaround is: create a tablespace with the desired properties and move all objects to the new tablespace.



TDE and LogMiner

TDE and LogMiner

LogMiner supports Transparent Data Encryption encrypted columns. Restrictions:• The wallet holding the TDE master keys must be open• Hardware Security Modules are not supported• User Held Keys are not supported

With Transparent Data Encryption (TDE), the encrypted column data is encrypted in the data files, the undo segments and the redo logs. Oracle Logical Standby depends on the LogMiner ability to transform redo logs into SQL statements for SQL Apply. LogMiner has been enhanced to support TDE. This enhancement provides the ability to support TDE on a logical standby database. The wallet containing the master keys for TDE must be open for LogMiner to decrypt the encrypted columns. The database instance must be mounted to open the wallet, therefore LogMiner cannot populate V$LOGMNR_CONTENTS to support TDE if the database instance is not mounted. LogMiner populates V$LOGMNR_CONTENTS for tables with encrypted columns, displaying the column data unencrypted for rows involved in DML statements. Note that this is not a security violation: TDE is a file-level encryption feature and not an access control feature. It does not prohibit DBAs from looking at encrypted data. At Oracle Database 11g, LogMiner does not support TDE with hardware security module (HSM) for key storage. User held keys for TDE are PKI public and private keys supplied by the user for TDE master keys. User held keys are not supported by LogMiner.



TDE and Logical Standby

TDE and Logical Standby

Logical Standby database with TDE:• Wallet on the standby is a copy of the wallet on th e

primary• Master key may be changed only on the primary• Wallet open and close commands are not replicated• Table key may be changed on the standby• Table encryption algorithm may be changed on the

standby

The same wallet is required for both databases. The wallet must be copied from the primary database to the standby database every time the master key has been changed using the "alter system set encryption key identified by <wallet_pas sword> “. An error is raised if the DBA attempts to change the master key on the standby database. If auto-login wallet is not used. The wallet must opened on the standby. Wallet open and close commands are not replicated on standby. A different password can be used to open the wallet on the standby. The wallet owner can change the password to be used for the copy of the wallet on the standby. The DBA will have the ability to change the encryption key or the encryption algorithm of a replicated table at the logical standby This does not require a change to the master key or wallet.. This operation is performed with:

ALTER TABLE table_name REKEY USING '3DES168';

There can be only one algorithm per table. Changing the algorithm at the table changes the algorithm for all the columns. A column on the standby can have a different algorithm than the primary or no encryption. To change the table key the guard setting must be lowered to NONE. TDE can be used on local tables in the logical standby independently of the primary, if encrypted columns are not replicated into the standby.



TDE and Streams

TDE and Streams

Oracle Streams now provides the ability to transpar ently:• Decrypt values protected by TDE for filtering and

processing• Re-encrypt values so that they are never in clear t ext

while on disk

ApplyStagingCapture

In Oracle Database 11g, Oracle Streams supports TDE. Oracle Streams now provides the ability to transparently:

• Decrypt values protected by TDE for filtering, processing and so on.

• Re-encrypt values so that they are never in clear text while on disk (as opposed to memory).

If the corresponding column in the apply database has TDE support, the applied data is transparently re-encrypted using the local database’s keys. If the column value was encrypted at the source, and the corresponding column in the apply database is not encrypted, the apply process raises an error unless the apply parameter ENFORCE_ENCRYPTION is set to FALSE. Whenever logical change records(LCRs) are stored on disk, such as due to queue or apply spilling and apply error creation, the data is encrypted if the local database supports TDE. This is performed transparently without any user intervention. LCR message tracing does not display clear text of encrypted column values.



Hardware Security Module



Database ServerClient

Encrypt and decrypt operationsare performed on the hardware security module

Encrypted Data

A hardware security module (HSM) is a physical device that provides secure storage for encryption keys. It also provides secure computational space (memory) to perform encryption and decryption operations. HSM is a more secure alternative to the Oracle wallet. Transparent data encryption can use HSM to provide enhanced security for sensitive data. An HSM is used to store the master encryption key used for transparent data encryption. The key is secure from unauthorized access attempts as the HSM is a physical device and not an operating system file. All encryption and decryption operations that use the master encryption key are performed inside the HSM. This means that the master encryption key is never exposed in insecure memory. There are several vendors that provide Hardware Security Modules. The vendor must supply the appropriate libraries.



Using a Hardware Security Module with TDE

Using a Hardware Security Modulewith TDE

1. Configure sqlnet.ora

2. Copy the PKCS#11 library to the correct path3. Set up the HSM4. Generate a master encryption key for HSM-based

encryption

5. Ensure that the HSM Is accessible6. Encrypt and decrypt data

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM) (METHOD_DATA= (DIRECTORY=/app/oracle/admin/SID1/wallet)))

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY user_Id:password

Using HSM involves an initial setup of the HSM device. You also need to configure transparent data encryption to use HSM. Once the initial setup is done, HSM can be used just like an Oracle software wallet. The following steps discuss configuring and using hardware security modules:

1. Set the ENCRYPTION_WALLET_LOCATION Parameter in sqlnet.ora ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)

(METHOD_DATA=(DIRECTORY=/app/oracle/admin/SID1/wa llet)))

The directory is required to find the old wallet when migrating from a software based wallet.

2. Copy the PKCS#11 Library to It's Correct Path

3. Set Up the HSM per the instruction provided by the HSM vendor. A user account is required for the database to interact with the HSM.

4. Generate a Master Encryption Key for HSM-Based Encryption ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY user_ Id:password [MIGRATE USING wallet_password]

The user_Id:password refers to the user account in step 3. The MIGRATE clause is used when the TDE is already in place. MIGRATE decrypts the existing column encryption keys and then encrypts them with the newly created, HSM-based, master encryption key.

5. Ensure that the HSM Is Accessible ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY user_Id: password

6. Encrypt and decrypt data as you would with a software wallet.



Encryption for LOB Columns

Encryption for LOB Columns

• LOB encryption is allowed only for SecureFiles• All LOBs in the LOB column are encrypted • LOBs can be encrypted on per-column or per-partitio n

basis– Allows for the co-existence of SecureFiles and Basic Files

LOBs

CREATE TABLE test1 (doc CLOBENCRYPT USING 'AES128') LOB(doc) STORE AS SECUREFILE (CACHE NOLOGGING );

Oracle Database 11g introduces a completely reengineered large object (LOB) data type that dramatically improves performance, manageability, and ease of application development. This Secure Files implementation (of LOBs) offers advanced, next-generation functionality such as intelligent compression and transparent encryption. The encrypted data in SecureFiles is stored in-place and is available for random reads and writes. You must create the LOB with the SECUREFILE parameter, with encryption enabled(ENCRYPT) or disabled(DECRYPT—the default) on the LOB column. The current TDE syntax is used for extending encryption to LOB data types. LOB implementation from prior versions is still supported for backward compatibility and is now referred to as BasicFiles. If you add a LOB column to a table, you can specify whether it should be created as SECUREFILES or BASICFILES . The default LOB type is BASICFILES to ensure backward compatibility. Valid algorithms are 3DES168, AES128, AES192, and AES256. The default is AES192. Note: For a further discussion on SecureFiles, please see the 11g: Infrastructure Grid - Performance eStudy.



Using Kerberos Enhancements

Using Kerberos Enhancements

• Use stronger encryption algorithms (no action required)

• Interoperability between MS KDC and MIT KDC (no Action required)

• Longer principal name

• Convert a DB user to Kerberos user

CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS '[email protected]';

ALTER USER DBUSER IDENTIFIED EXTERNALLY AS '[email protected]';

The Oracle client Kerberos implementation now makes use of secure encryption algorithms like 3DES and AES in place of DES. This makes using Kerberos more secure. The Kerberos authentication mechanism in Oracle Database now supports the following encryption types:

• DES3-CBC-SHA (DES3 algorithm in CBC mode with HMAC-SHA1 as checksum)

• RC4-HMAC (RC4 algorithm with HMAC-MD5 as checksum)

• AES128-CTS (AES algorithm with 128-bit key in CTS mode with HMAC-SHA1 as checksum)

• AES256-CTS (AES algorithm with 256-bit key in CTS mode with HMAC-SHA1 as checksum)

The Kerberos implementation has been enhanced to interoperate smoothly with Microsoft and MIT Key Distribution Centers. The Kerberos principal name can now contain more than 30 characters. It is no longer restricted by the number of characters allowed in a database user name. If the Kerberos principal name is longer than 30 characters use:

CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS '[email protected]';

Database users can be converted to Kerberos users without requiring a new user to be created using the ALTER USER syntax:

ALTER USER DBUSER IDENTIFIED EXTERNALLY AS '[email protected]';



Enterprise Manager Security Management

Enterprise Manager Security Management

Manage Security through EM• Policy Manager replaced for

– Virtual Private Database– Application Context– Oracle Label Security

• Enterprise User Security pages added

• TDE pages added

Security management has been integrated into Enterprise Manager. The Policy Manager Java console based tool has been superseded. Oracle Label Security, Application Contexts, and Virtual Private Database previous administered through Oracle Policy Manager tool are managed through the Enterprise Manager. The Oracle Policy Manager tool is still available. The Enterprise Manager Security tool has been superseded by Enterprise Manager features. Enterprise User Security is also now managed though Enterprise Manager. The menu item for Enterprise manage will appear as soon as the ldap.ora file is configured. See the Enterprise User Administrator's Guide for configuration details. The Enterpriser Security Manager tool is still available. Transparent Data Encryption can now be managed through Enterprise Manager, including Wallet management. You can create, open, and close the Wallet from Enterprise manager pages.



Managing TDE with Enterprise Manager

Managing TDE withEnterprise Manager

The administrator using Enterprise Manager can open and close the wallet, move the location of the wallet and generate a new master key. The example shows that TDE options are part of the Create or Edit Table processes. Table encryption options allow you to choose the encryption algorithm and salt. The table key can also be reset. The other place where TDE changed the management pages is Export and Import Data. If TDE is configured, the wallet is open, and the table to exported has encrypted columns, the export wizard will offer data encryption. The same arbitrary key(password) that was used on export must be provided both on import in order to import any encrypted columns. A partial import that does not include tables that contain encrypted columns does not require the password.



Managing Tablespace Encryption with Enterprise Manager

Managing Tablespace Encryptionwith Enterprise Manager

You can manage tablespace encryption from the same console as you manage Transparent Database Encryption. Once encryption has been enabled for the database, the DBA can set the encryption property of a tablespace on the Edit Tablespace page or create



Managing Virtual Private Database

Managing Virtual Private Database

With Enterprise Manager 11g you can now manage the Virtual Private Database policies from the console. You can enable, disable, add, and drop polices. The console also allows you to manage application contexts. The application context page is not shown.



Managing Label Security with Enterprise Manager

Managing Label Security with Enterprise Manager

Oracle Label Security (OLS) Management is integrated with Enterprise Manager Database Control. The Database Administrator can manage OLS from the same console that is used for managing the database instances, listeners and host. The differences between database control and grid control are minimal. Oracle Label Security (OLS) Management is integrated with Enterprise Manager Grid control. The Database Administrator can manage OLS from the same console that is used for managing the database instances, listeners and other targets.



Managing Label Security with Oracle Internet Directory

Managing Label Security with Oracle Internet Directory

Oracle Label Security policies can now be created and stored in the Oracle Internet Directory, then applied to one or more databases. A database will subscribe to a policy making the policy available to the database, and the policy can be applied to tables and schemas in the database. Label authorizations can be assigned to enterpriser users in the form of profiles.



Managing Enterprise Users with Enterprise Manager

Managing Enterprise Userswith Enterprise Manager

The functionality of the Enterprise Security Manager has been integrated into Enterprise Manager. Enterprise Manager allows you to create and configure enterprise domains, enterprise roles, user schema mappings and proxy permissions. Databases can be configured for enterprise user security after they have been registered with OID. The registration is performed through the DBCA tool. Enterprise Users and groups can also be configured for enterprise user security. The creation of enterprise users and groups can be done through Delegated Administration Service (DAS). Administrators for the database can be created and given the appropriate roles in OID through Enterprise Manager. Enterprise Manager allows you to manage enterprise users and roles, schema mappings, domain mappings, and proxy users.



Enterprise Manager Policy Trend

Enterprise ManagerPolicy Trend

Enterprise Manager Policy Trend allows you to view the compliance of your database configuration against a set of Oracle security best practices.



Oracle Audit Vault Enhancements

Oracle Audit Vault Enhancements

Audit Vault enhancements to Streams• Harden Streams configuration• DML/DDL capture on SYSand SYSTEMschemas• Capture changes to SYS.AUD$and SYS.FGA_LOG$

Oracle Audit Vault provides auditing in a heterogeneous environment. Audit Vault consists of a secure database to store and analyze audit information from various sources such as databases, OS audit trails etc. Oracle Streams is an asynchronous information sharing infrastructure that facilitates sharing of events within a database or from one database to another. Events could be DML or DDL changes happening in a database. These events are captured by Streams implicit capture and are propagated to a queue in a remote database where they are consumed by a subscriber which is typically the Streams apply process. Oracle Streams has been enhanced to support Audit Vault. The Streams configurations are controlled from the Audit Vault location. Once the initial configuration has been completed, Streams setup at both the Audit Source and Audit Vault will be completely driven from the Audit Vault. This prevents configurations from being changed at the Audit Source. Oracle Streams has been enhanced to allow capture of changes to the SYS, and SYSTEM schemas. Oracle Streams already captures for user schemas all DML on participating tables and all DDL to the database. Streams is enhanced to capture the events that change the database audit trail, forwarding that information to Audit Vault.



Managing Fine-Grained Access to External Network Services


1. Create an ACL and its privileges

BEGINDBMS_NETWORK_ACL_ADMIN.CREATE_ACL (

acl => 'us-oracle-com-permissions.xml', description => ‘Permissions for oracle network',principal => ‘SCOTT',is_grant => TRUE, privilege => 'connect');

END;

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 using higher level protocols built on raw TCP. A user either did or did not have EXECUTE privilege on these packages and there was no control over which network hosts were accessed. The new package DBMS_NETWORK_ACL_ADMIN allows fine-grained control using access control lists (ACL) implemented by XML DB.

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 the 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 timestamp for these privileges. To add more users and privileges to this ACL use the ADD_PRIVILEGE procedure.





2. Assign an ACL to one or more network hosts

BEGINDBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (

acl => ‘us-oracle-com-permissions.xml',host => ‘*.us.oracle.com', lower_port => 80,upper_port => null);

END

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 wild card character for the host name to assign the ACL to all the hosts of a domain. The use of wild cards affect 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 sub-domains are evaluated before the top level 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.



Demonstration

Demonstration

For further understanding, click on the link in the notes below for Oracle By Example demonstration on the following functionality:• Using Transparent Data Encryption

Click the following link for a demonstration on:

• Using Transparent Data Encryption[http://www.oracle.com/technology/obe/11gr1_db/security/tde/tde.htm]

Please note that this OBE was created under Oracle Database 11g Beta 4.



Summary

Summary

In this lesson, you should have learned how to:• Encrypt a tablespace• Use a Hardware Security Module with TDE• Use Enterprise Manager to manage security options• Configure fine-grained access to network services

oracle database 11g security_d52365

Documents

oracle database

oracle parkway

restricted rights software

restricted rights legend

security settings

security parameters

rman security enhancements

technical data