Oracle Database 11g: Security

Oracle Database 11g: Security Student Guide D52365GC10 Edition 1.0 October 2007 PRODUCTION

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...2-2 Chapter 2...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 i

Oracle Database 11g: Security Table of Contents ii

Security: New Features Security: New Features Chapter 0 - Page 1

Chapter 1Security: New Features Security: New Features Security: New Features Chapter 1 - Page 2

Objectives Objectives After completing this lesson, you should be able to: Configure strong authentication for privileged users Create a virtual private catalog for RMAN Security: New Features Chapter 1 - Page 3

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. Security: New Features Chapter 1 - Page 4

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. Security: New Features Chapter 1 - Page 5

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. Security: New Features Chapter 1 - Page 6

Enable Built-in Password Complexity Checker Enable Built-in Password Complexity Checker Execute the utlpwdmg.sql script to create the password verify function: SQL> CONNECT / as SYSDBA SQL> @?/rdbms/admin/utlpwdmg.sql Alter the default profile: ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION verify_function_11g; 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 Security: New Features Chapter 1 - Page 7

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 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: Security: New Features Chapter 1 - Page 8

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 Security: New Features Chapter 1 - Page 9

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. Security: New Features Chapter 1 - Page 10

Setting Security Parameters Setting Security Parameters Use case sensitive passwords SEC_CASE_SENSITIVE_LOGON Protect against DoS attacks SEC_PROTOCOL_ERROR_FURTHER_ACTION SEC_PROTOCOL_ERROR_TRACE_ACTION Protect against brute force attacks SEC_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. Security: New Features Chapter 1 - Page 11

This parameter prevents a program from making a database connection and then attempting to authenticate by trying hundreds or thousands of passwords. Security: New Features Chapter 1 - Page 12

Using RMAN Security Enhancements Using RMAN Security Enhancements Configure backup shredding: RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON; Use backup shredding: 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. Security: New Features Chapter 1 - Page 13

Creating and Using Virtual Private Catalogs Creating and Using Virtual Private Catalogs Databases registered in RMAN catalog RMAN base catalog Enhances security by restricting access to metadata Virtual private catalogs (VPC) 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. Security: New Features Chapter 1 - Page 14

Using RMAN Virtual Private Catalogs Using RMAN Virtual Private Catalogs 1. Create an RMAN base catalog: RMAN> CONNECT CATALOG catowner/oracle@catdb; RMAN> CREATE CATALOG; 2. Grant RECOVERY_CATALOG_OWNER to VPC owner: SQL> CONNECT SYS/oracle@catdb AS SYSDBA SQL> GRANT RECOVERY_CATALOG_OWNER to vpcowner 3a. Grant REGISTER to the VPC owner, or: RMAN> CONNECT CATALOG catowner/oracle@catdb; RMAN> GRANT REGISTER DATABASE TO vpcowner; 3b. Grant CATALOG FOR DATABASE to the VPC owner: 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. Security: New Features Chapter 1 - Page 15

Using RMAN Virtual Private Catalogs Using RMAN Virtual Private Catalogs 4a. Create a virtual catalog for 11g clients, or: RMAN> CONNECT CATALOG vpcowner/oracle@catdb; RMAN> CREATE VIRTUAL CATALOG; 4b. Create a virtual catalog for pre-11g clients: SQL> CONNECT vpcowner/oracle@catdb SQL> exec catowner.dbms_rcvcat.create_virtual_catalog; 5. Register a new database in the catalog: RMAN> CONNECT TARGET / CATALOG vpcowner/oracle@catdb; RMAN> REGISTER DATABASE; 6. Use the virtual catalog: 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. Security: New Features Chapter 1 - Page 16

Summary Summary In this lesson, you should have learned how to: Configure strong authentication for privileged users Create a virtual private catalog for RMAN Security: New Features Chapter 1 - Page 17

Security: New Features Chapter 1 - Page 18

11g Security Optional New Features Chapter 0 - Page 1

Chapter 2 Chapter 2 - Page 2

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 Chapter 2 - Page 3

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. Chapter 2 - Page 4

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. Chapter 2 - Page 5

Using Tablespace Encryption Using Tablespace Encryption Create an encrypted tablespace 1. Create or open the encryption wallet SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "welcome1"; 2. Create a tablespace with the encryption keywords SQL> CREATE TABLESPACE encrypt_ts 2> DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100M 3> 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. Chapter 2 - Page 6

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. Chapter 2 - Page 7

TDE and Logical Standby TDE and Logical Standby Logical Standby database with TDE: Wallet on the standby is a copy of the wallet on the 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_password>. 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. Chapter 2 - Page 8

TDE and Streams TDE and Streams Oracle Streams now provides the ability to transparently: Decrypt values protected by TDE for filtering and processing Re-encrypt values so that they are never in clear text while on disk Capture Staging Apply 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. Chapter 2 - Page 9

Hardware Security Module Hardware Security Module Encrypt and decrypt operations are performed on the hardware security module Hardware Security Module Encrypted Data Client Database Server 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. Chapter 2 - Page 10

Using a Hardware Security Module with TDE Using a Hardware Security Module with TDE 1. Configure sqlnet.ora ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM) (METHOD_DATA= (DIRECTORY=/app/oracle/admin/SID1/wallet))) 2. Copy the PKCS#11 library to the correct path 3. Set up the HSM 4. Generate a master encryption key for HSM-based encryption ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY user_id:password 5. Ensure that the HSM Is accessible 6. Encrypt and decrypt data 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/wallet))) 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. Chapter 2 - Page 11

Encryption for LOB Columns Encryption for LOB Columns CREATE TABLE test1 (doc CLOB ENCRYPT USING 'AES128') LOB(doc) STORE AS SECUREFILE (CACHE NOLOGGING ); LOB encryption is allowed only for SecureFiles All LOBs in the LOB column are encrypted LOBs can be encrypted on per-column or per-partition basis Allows for the co-existence of SecureFiles and BasicFiles LOBs 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. Chapter 2 - Page 12

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 CREATE USER KRBUSER IDENTIFIED EXTERNALLY AS 'KerberosUser@SOMEORGANIZATION.COM'; Convert a DB user to Kerberos user ALTER USER DBUSER IDENTIFIED EXTERNALLY AS 'KerberosUser@SOMEORGANIZATION.COM'; 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 'KerberosUser@SOMEORGANIZATION.COM'; 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 'KerberosUser@SOMEORGANIZATION.COM'; Chapter 2 - Page 13

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. Chapter 2 - Page 14

Managing TDE with Enterprise Manager Managing TDE with Enterprise 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. Chapter 2 - Page 15

Managing Tablespace Encryption with Enterprise Manager Managing Tablespace Encryption with 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 Chapter 2 - Page 16

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. Chapter 2 - Page 17

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. Chapter 2 - Page 18

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. Chapter 2 - Page 19

Managing Enterprise Users with Enterprise Manager Managing Enterprise Users with 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. Chapter 2 - Page 20

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

Oracle Audit Vault Enhancements Oracle Audit Vault Enhancements Audit Vault enhancements to Streams Harden Streams configuration DML/DDL capture on SYS and SYSTEM schemas 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. Chapter 2 - Page 22

Managing Fine-Grained Access to External Network Services Managing Fine-Grained Access to External Network Services 1. Create an ACL and its privileges 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; 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. Chapter 2 - Page 23

Managing Fine-Grained Access to External Network Services Managing Fine-Grained Access to External Network Services 2. Assign an ACL to one or more network hosts BEGIN DBMS_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. Chapter 2 - Page 24

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. Chapter 2 - Page 25

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 Chapter 2 - Page 26