| Oracle® Database Security Guide 11g Release 2 (11.2) Part Number E16543-14 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Security Guide 11g Release 2 (11.2) Part Number E16543-14 |
|
|
PDF · Mobi · ePub |
The Oracle Database 11g Release 2 (11.2) security features and enhancements described in this section comprise the overall effort to provide superior access control, privacy, and accountability with this release of Oracle Database.
The following sections describe new security features of Oracle Database 11g Release 2 (11.2) and provide pointers to additional information:
Oracle Database 11g Release 2 (11.2.0.2) New Security Features
Oracle Database 11g Release 2 (11.2.0.1) New Security Features
This section contains:
Enhancements to Fine-Grained Access to External Services and Wallets
Support for MERGE INTO Statements for Virtual Private Database Policies
BY ACCESS Audit Trail Option Now the Default for AUDIT Statements
New DBMS_SCHEDULER PL/SQL Package Global Scheduler Attributes
In this release, when you use fine-grained access control to configure external network services and wallets, you now can control access to the DBMS_LDAP PL/SQL package. In a default database installation, this package is created with the EXECUTE privilege granted to PUBLIC users. This release enhances the security of this package by enabling you to control access to applications in the database that use this package. As part of this enhancement, the DBMS_LDAP package is now an invoker's rights package. Before a user can connect to a remote network host, he or she must be granted the connect privilege in the access control list that was assigned to the remote network host.
See Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_LDAP package.
In previous releases of Oracle Database, when you created an Oracle Virtual Private Database policy on an application that included the MERGE INTO statement, the MERGE INTO statement would be prevented with an ORA-28132: Merge into syntax does not support security policies error, due to the presence of the Virtual Private Database policy. In this release, you can create policies on applications that include MERGE INTO operations. To do so, in the DBMS_RLS.ADD_POLICY statement_types parameter, include the INSERT, UPDATE, and DELETE statements, or just omit the statement_types parameter altogether.
See "Enforcing Policies on Specific SQL Statement Types" for more information.
Starting with this release, the standard audit records will by default be generated using the BY ACCESS clause functionality of the AUDIT statement. Both the BY ACCESS and BY SESSION clauses write an individual audit record for each audited event, but BY ACCESS captures more detail about the audited event.
See "Benefits of Using the BY ACCESS Clause in the AUDIT Statement" for more information.
Starting with this release, the UTL_SMTP PL/SQL package has the following new functionality:
You now can configure the UTL_SMTP PL/SQL package for use on both Transport Layer Security (TLS) and Secure Sockets Layer (SSL) servers.
UTL_SMTP now provides support for the PLAIN, LOGON and CRAM_MD5 password authentication schemes.
See Oracle Database PL/SQL Packages and Types Reference for more information about the UTL_SMTP package.
The DBMS_SCHEDULER PL/SQL package the following two new global scheduler attributes, which are used to control encryption for connections to a mail server:
email_server_credential, which enables you to specify the schema and name of an existing credential object on which user SYS has the EXECUTE object privilege
email_server_encryption, which enables you to set one of three encryption settings for your mail server:
ssl_tls, which uses SSL or TLS to encrypt the connection to the mail server form the beginning of the connection
starttls, in which the connection to the mail server starts as unencrypted but switches to an encrypted connection
none, in which no encryption is used to connect to the mail server
See Oracle Database Administrator's Guide for more information about Scheduler preferences.
1n previous releases, when you revoked the UNLIMITED TABLESPACE system privilege from users, then the explicit quotas again took effect. Starting with this release, after you revoke the UNLIMITED TABLESPACE system privilege, you must explicitly grant quotas to individual tablespaces.
See "Granting Users the UNLIMITED TABLESPACE System Privilege" for more information about the UNLIMITED TABLESPACE system privilege.
This section contains:
Enhancements to Fine-Grained Access to External Services and Wallets
Support for MERGE INTO Statements for Virtual Private Database Policies
Global Application Contexts Available Across Oracle RAC Instances
The previous release of Oracle Database introduced the ability to create fine-grained access control to external network services and wallets. In this release, the following enhancements are available:
Updates to the UTL_HTTP PL/SQL package. You now can configure network services to use the Amazon Simple Storage Service (S3) scheme, which configures access to the Amazon.com Web site. In addition, an individual application can make HTTP requests by using its private wallet and HTTP cookie table that will not be shared with other applications in the same database session. This feature also offers protection of the wallet using the access control list (ACL) privileges in place of the password credential.
Support for IP Version 6 (IPv6) addresses. The DBMS_NETWORK_ACL_ADMIN and DBMS_NETWORK_ACL_UTILTIY packages, and the PL/SQL network utility packages (such as UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR), now support both IP Version 4 (IPv4) and IPv6 addresses.
See "Managing Fine-Grained Access in PL/SQL Packages and Types" for more information.
In this release, changes to global application context values are automatically accessible across all Oracle Real Application Clusters (Oracle RAC) instances.
See "Using Global Application Contexts" for more information about creating a global application context.
Starting with Oracle Database 11g Release 2 (11.2), SSL version 2 is no longer included in the default list of default supported protocols. If your applications must use SSL version 2, then you can do so by explicitly setting SSL version 2 while maintaining the connection.
See Oracle Database Advanced Security Administrator's Guide for more information.
This section contains:
You now can grant users the EXECUTE privilege on directory objects that contain a user-supplied preprocessor program for use by the ORACLE_LOADER access driver. This prevents the user from accidentally or maliciously corrupting the preprocessor program. The SQL statements that are affected by the EXECUTE privilege are GRANT and REVOKE. The ORACLE_LOADER access parameters now include the PREPROCESSOR clause, which you can use to specify the name and location of a preprocessor program that modifies the contents of a data file so that the ORACLE_LOADER access driver can read it.
For more information about using the ORACLE_LOADER access driver preprocessor, see the following:
Oracle Database Utilities for more information about the ORACLE_LOADER access driver
"Granting System Privileges and Roles" for the syntax of granting the EXECUTE privilege for a directory object
Oracle Database SQL Language Reference for updates to the GRANT and REVOKE SQL statements
You now can audit the EXECUTE privilege on directory objects. This enables you to monitor users who run a preprocessor program (which is used by the ORACLE_LOADER access driver) that has been added to a directory object.
See "Auditing Directory Objects" for more information.
This section contains:
In this release, the master encryption key for transparent tablespace encryption and transparent column encryption are now combined to one unified master encryption key. Combining these keys enables transparent re-key operations for both of these transparent data encryption features, regardless of whether the master encryption key is stored in the Oracle Wallet or in one of the certified Hardware Security Modules offered by RSA, SafeNet, Thales (including nCipher), and Utimaco.
For more information about transparent data encryption, see Oracle Database Advanced Security Administrator's Guide.
In this release, Oracle Advanced Security enables you to change the master key that protects the encryption keys used to encrypt Oracle Database tablespaces. Industry initiatives, such as the Payment Card Industry Data Security Standard (PCI DSS), mandate periodic rotation of encryption keys associated with credit card data.
For more information about tablespace encryption, see Oracle Database Advanced Security Administrator's Guide.
Starting with this release, the master encryption key is copied to the intelligent storage cells, where data encrypted with transparent tablespace encryption or transparent column encryption is now decrypted before the pre-filtering of the result set takes place. This feature improves performance in databases that use transparent data encryption.
For more information about Oracle Exadata, see Oracle Database High Availability Overview.
When you now open or close an Oracle wallet or re-key the master encryption key on one Oracle RAC instance, then the changes you make automatically are propagated to all other Oracle RAC instances.
For more information, see Oracle Database Advanced Security Administrator's Guide.
Oracle Database 11g Release 2 (11.2) introduces several enhancements to the audit trail cleanup process. In this release, you can:
Timestamp audit trail records based on their archive date. Later on, you can purge all records that were created before this archive date.
See "Step 4: Optionally, Set an Archive Timestamp for Audit Records" for more information.
Purge audit trail records in one operation or create a purge job. You can purge all audit trail records in the system, or audit trail records of an individual type, such as all fine-grained audit trail records within the database audit trail. The purge operation will either remove audit trail records that were created before their timestamped archive date, or it will remove all audit trail records of the specified audit trail type. The purge job enables you to purge records based on a time interval, and also can remove records based on their timestamped archive date.
See the following sections:
Move the database audit trail table from the SYSTEM tablespace to a different tablespace. You can move the standard audit trail table, the fine-grained audit trail table, or both standard and fine-grained audit trail tables together. Consider moving the database audit trail from the SYSTEM tablespace if it is too busy.
See "Moving the Database Audit Trail to a Different Tablespace" for more information.
Set a batch size for the database audit trail records so that when they are purged, the purge operation deletes each batch. In a purge operation, you remove all or some of the audit trail records. Typically, you do this after you archive the audit trail. Afterwards, the audit trail will resume collecting audit data. The batching process enables you remove the records in groups, for example, 10,000 records at a time, rather than deleting all records at a time.
See "Step 6: Optionally, Configure the Audit Trail Records to be Deleted in Batches" for more information.
Set a maximum size and age for the operating system audit trail. When the current audit file reaches this maximum, Oracle Database stops populating the current file and creates a new file for the subsequent audit trail records.
See the following sections:
DB_EXTENDED Setting for the AUDIT_TRAIL Parameter Deprecated
Database Configuration Assistant No Longer Provides Default Security Settings
The DB_EXTENDED setting in the AUDIT_TRAIL initialization parameter has been deprecated. Instead, use the DB, EXTENDED setting in its place.
See "Configuring Standard Auditing with the AUDIT_TRAIL Initialization Parameter" for more information.
The WKUSER role and the WKSYS, WKTEST, WKPROXY schemas have been deprecated. For more information about Oracle Ultra Search, see Oracle Ultra Search Administrator's Guide.
In the previous release of Oracle Database, you could use Database Configuration Assistant (DBCA) to add password security and audit options to a new database. This option is not available in this release. In this release, DBCA automatically adds audit options and password policies to new databases.
See the following sections for more information:
The AUTHENTICATED USING PASSWORD clause of the ALTER USER statement has been deprecated for this release. If you use this clause, Oracle Database converts it to the AUTHENTICATION REQUIRED clause. If you do not specify the AUTHENTICATION REQUIRED clause, then Oracle Database uses either the AUTHENTICATED USING CERTIFICATE clause or the AUTHENTICATED USING DISTINGUISHED NAME clause.
See Oracle Database SQL Language Reference for more information about the ALTER USER statement options.
Setting a password for the listener.ora file has been deprecated for this release, because it is no longer needed. In the next release, the listener password will not be supported.
This section contains:
When you create a new database, you can use Database Configuration Assistant (DBCA) to automatically create a more secure configuration than in previous releases of Oracle Database. You can enable the following secure configuration settings in one operation:
Password-specific settings in the default profile. This feature enables you to enforce password expiration and other password policies. See "Configuring Password Settings in the Default Profile" for more information.
Auditing. This feature enables auditing for specific events such as database connections. See "Using Default Auditing for Security-Relevant SQL Statements and Privileges" for more information.
To configure your database for greater security, follow the guidelines in Chapter 10, "Keeping Your Oracle Database Secure."
Oracle Database now includes the following new password protections:
Easy ability to find default passwords. If you have upgraded from an earlier release of Oracle Database, you may have user accounts that still have default passwords. For greater security, you should find and change these passwords. See "Finding User Accounts That Have Default Passwords" for more information.
Password complexity verification. Password complexity verification ensures that users set complex passwords when setting or resetting passwords. You can enforce password complexity by using the default settings provided by Oracle Database, or create custom requirements to further secure the password complexity requirements for your site.
"Enforcing Password Complexity Verification" describes built-in password verification.
Enforced case sensitivity. See "Enabling or Disabling Password Case Sensitivity" for more information.
Stronger password hashing algorithm. This enhancement enables users to create passwords that contain mixed case or special characters. See "Ensuring Against Password Security Threats by Using the SHA-1 Hashing Algorithm" for more information.
You can now use the Secure Sockets Layer (SSL) and Kerberos strong authentication methods to authenticate users who have the SYSDBA and SYSOPER privileges.
See "Strong Authentication and Centralized Management for Database Administrators" for more information.
The SYSASM system privilege has been added to Oracle Database 11g Release 2 (11.2), to be used exclusively to administer Automatic Storage Management (ASM). Use the SYSASM privilege instead of the SYSDBA privilege to connect to and administer ASM instances.
See Oracle Automatic Storage Management Administrator's Guide for more information about the SYSASM privilege.
This section describes the following enhancements in encryption:
Intelligent LOB Compression, Deduplication, and Encryption with SecureFiles
Transparent Data Encryption with Hardware Security Module Integration
Oracle Database supports a new, faster, and scalable Large Object (LOB) storage paradigm called SecureFiles. SecureFiles, in addition to performance, supports efficient compression, deduplication (that is, coalescing duplicate data), and encryption. LOB data can now be encrypted with Oracle Database, and is available for random reads and writes.
For more information about SecureFiles, see Oracle Database SecureFiles and Large Objects Developer's Guide. See also Oracle Database SQL Language Reference for updates in the CREATE TABLE and ALTER TABLE statements to support this feature.
In this release, you can use Oracle Data Pump to compress and encrypt an entire dump file set. You can optionally compress and encrypt the data, metadata, or complete dump file set during an Oracle Data Pump export.
For more information, see Oracle Database Utilities.
Transparent data encryption (TDE) stores the master key in an encrypted software wallet and uses this key to encrypt the column keys, which in turn encrypt column data. While this approach to key management is sufficient for many applications, it may not be sufficient for environments that require stronger security. TDE has been extended to use hardware security modules (HSMs). This enhancement provides high assurance requirements of protecting the master key.
This release enables you to store the TDE master encryption key within a hardware security module (HSM) at all times, leveraging its key management capabilities. Only the table keys (for TDE column encryption) and tablespace keys (for TDE tablespace encryption) are decrypted on the HSM, before they are returned to the database; the encryption and decryption of application data remains with the database. Oracle recommends that you encrypt the traffic between HSM device and databases. This new feature provides additional security for transparent data encryption, because the master encryption key cannot leave the HSM, neither in clear text nor in encrypted format. Furthermore, it enables the sharing of the same key between multiple databases and instances in an Oracle Real Applications Clusters (Oracle RAC) or Data Guard environment.
To configure transparent data encryption with hardware security module integration, see Oracle Database Advanced Security Administrator's Guide.
Transparent tablespace encryption enables you to encrypt entire application tablespaces, encrypting all the data within these tablespaces. When a properly authorized application accesses the tablespace, Oracle Database transparently decrypts the relevant data blocks for the application.
Transparent tablespace encryption provides an alternative to TDE column encryption: It eliminates the need for granular analysis of applications to determine which columns to encrypt, especially for applications with a large number of columns containing personally identifiable information (PII), such as Social Security numbers or patient health care records. If your tables have small amounts of data to encrypt, then you can continue to use the TDE column encryption solution.
For an introduction to transparent encryption, see Oracle Database 2 Day + Security Guide. For detailed information about transparent tablespace encryption, see Oracle Database Advanced Security Administrator's Guide.
Oracle Database provides a set of PL/SQL utility packages, such as UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR, that are designed to enable database users to access network services on the database. Oracle Database PL/SQL Packages and Types Reference describes the PL/SQL utility packages in detail.
In a default database installation, these packages are created with EXECUTE privileges granted to PUBLIC users. This release enhances the security of these packages by providing database administrators the ability to control access to applications in the database that use these packages.
See "Managing Fine-Grained Access in PL/SQL Packages and Types" for more information.
The BY SESSION clause of the AUDIT statement now writes one audit record for every audited event. In previous releases, BY SESSION wrote one audit record for all SQL statements or operations of the same type that were executed on the same schema objects in the same user session. Now, both BY SESSION and BY ACCESS write one audit record for each audit operation. In addition, there are separate audit records for LOGON and LOGOFF events. If you omit the BY ACCESS clause, then BY SESSION is used as the default.
The audit record that BY SESSION generates is different from the BY ACCESS audit record. Oracle recommends that you include the BY ACCESS clause for all AUDIT statements, which results in a more detailed audit record. In the case of LOGOFF events, the timestamp for the audit record has a greater precision than in previous releases.
Be aware that this change applies to schema object audit options, statement options, and system privileges that audit SQL statements other than data definition language (DDL) statements. Oracle Database has always audited using the BY ACCESS clause on all SQL statements and system privileges that audit a DDL statement.
See the following sections for more information:
This section contains:
Security objects are now stored in the Oracle XML DB repository as XMLType objects. These security objects can contain strings that need to be translated to different languages so that they can be searched or displayed in those languages. Developers can store translated strings with the XMLType and retrieve and operate on these strings depending on the language settings of the user. The advantage of this feature is that it reduces the costs associated with developing applications that are independent of the target preferred language of the user.
To configure security for XMLType objects, see Oracle XML DB Developer's Guide.
You can now use the Oracle XML DB HTTP server for service-oriented architecture (SOA) operations. This allows the database to be treated as simply another service provider in an SOA environment. Security administrators can control user access to Oracle Database Web services and their associated database objects by using the XDB_WEBSERVICES, XDB_WEBSERVICES_OVER_HTTP, and XDB_WEBSERVICES_WITH_PUBLIC predefined roles.
To configure Oracle Database Web services, see Oracle XML DB Developer's Guide.For information on this feature's predefined roles, see Table 4-3, "Oracle Database Predefined Roles".
In this release, administrators can now disallow anonymous access to database service information in a directory and require clients to authenticate when performing LDAP directory-based name look-ups. If you are using Microsoft Active Directory-based name lookups, then Oracle Database uses the native operating system-based authentication. If you are using Oracle Internet Directory (OID)-based name lookups, then Oracle Database performs authentication by using wallets.
To configure directory security, see Oracle Database Net Services Reference.
The following security enhancements are available for Oracle Call Interface (OCI):
Reporting bad packets that may come from malicious users or intruders
Terminating or resuming the client or server process on receiving a bad packet
Configuring the maximum number of authentication attempts
Controlling the display of the Oracle database version banner, to prevent intruders from finding information about the security vulnerabilities present in the database software based on the version
Adding banner information, such as "Unauthorized Access" and "User Actions Audited," to server connections so that clients can display this information
Database administrators can manage these security enhancements for Oracle Call Interface developers by configuring a set of new initialization parameters. See Parameters for Enhanced Security of Database Communication for more information. See also Oracle Call Interface Programmer's Guide for detailed information on Oracle Call Interface.
|
 Copyright © 2006, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
