Changes in This Release for Oracle Database Security Guide

SHA-2 Support for 12C Password Verifier

Oracle Database 12c Release 1 (12.1.0.2) uses the SHA-512 cryptographic hash to generate the 12C password verifier. In addition, both Oracle Call Interface (OCI) and thin JDBC client now support the 12C password verifier for authentication. You can use the SHA-256, SHA-384, and SHA-512 hash functions for network checksumming. To calculate SHA-256, SHA-384, and SHA-512 hash digests, use the DBMS_CRYPTO PL/SQL package.

See the following for more information:

• "Ensuring Against Password Security Threats by Using the 12C Verifier"

• Oracle Database PL/SQL Packages and Types Reference for details about SHA-2 support in the DBMS_CRYPTO PL/SQL package

Support for SHA-2 Cryptographic Hash Functions

In the previous release, Oracle Database included support for most of the SHA-2 cryptographic hash functions. In addition to network checksumming (SHA-256 and SHA-384 functions) and the DBMS_CRYPTO PL/SQL package, you can use these functions in the following areas:

• Verifier used for database password-based authentication (SHA-512 function)

• Network checksumming (SHA-256, SHA-384, and SHA-512 functions)

• Password files (SHA-512 function)

See "Ensuring Against Password Security Threats by Using the 12C Verifier" for more information.

Use of ADMIN and DELEGATE Options for Code Based Access Control User Role Grants

Users who perform code based access control grants to their program units must now, in addition to the requirements in the previous release, have the GRANT ANY ROLE privilege, or the ADMIN or DELEGATE option for the roles that they want to grant to program units. This feature adds a layer of security when these program units are executed by other users.

See "Using Code Based Access Control for Definer's Rights and Invoker's Rights" for more information.

Support for Audit Trail Cleanup in Read-Only Databases

In previous releases, the audit trail cleanup was available only in read-write databases. Starting with this release, it is available in read-only databases as well. To accommodate this enhancement, the following changes have been made:

• The DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP and DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedures now work on both read-write and read-only databases.

• The DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY procedure also works for both read-write and read-only databases. For read-only databases, this procedure sets the value directly in the SGA. In addition, for read-only databases, you cannot set the configuration parameters CLEANUP_INTERVAL and DB_DELETE_BATCH_SIZE.

• The DBMS_AUDIT_MGMT.GET_AUDIT_TRAIL_PROPERTY_VALUE function has been added. This function enables users to view in-memory values of configuration parameters, and can be used with both read-write and read-only databases.

• DBMS_AUDIT.MGMT.GET_LAST_ARCHIVE_TIMESTAMP function has been added to retrieve the timestamp configured in read-only databases.

• The following parameters for the DBMS_AUDIT_MGMT.AUDIT_TRAIL_TYPE parameter do not apply for read-only databases, because you cannot modify the AUD$ and FGA_LOG$ system tables:

  • AUDIT_TRAIL_AUD_STD

  • AUDIT_TRAIL_FGA_STD

  • AUDIT_TRAIL_DB_STD

  • AUDIT_TRAIL_ALL

• Audit trail purge information for read-only databases is written to the alert log of the database instance instead of the DBA_AUDIT_MGMT_CLEAN_EVENTS data dictionary view.

See "Purging Audit Trail Records" for more information about the audit trail cleanup feature.

New Predefined Unified Audit Policies

Two new predefined unified audit policies are available with this release. They are as follows:

• ORA_CIS_RECOMMENDATIONS performs audits that are recommended by the Center for Internet Security (CIS).

• ORA_DV_AUDPOL audits actions that are performed on the Oracle Database Vault DVSYS and DVF schema objects and the Oracle Label Security LBACSYS schema objects.

See the following sections for more information:

• "Center for Internet Security Recommendations Predefined Unified Audit Policy"

• "Oracle Database Vault Predefined Unified Audit Policy"

USERENV Namespace UNIFIED_AUDIT_SESSIONID Parameter to Capture the Unified Audit Session ID

You now can use the new USERENV namespace UNIFIED_AUDIT_SESSION parameter to track the unified audit session ID for the current user session. This parameter is designed for mixed mode auditing, because in that environment, the SESSIONID parameter returns a different value from UNIFIED_AUDIT_SESSIONID. In a pure unified audit environment, both of these values are the same.

See "Creating a Condition for a Unified Audit Policy" for more information about creating unified audit policies that have conditions.

New READ Object Privilege and READ ANY TABLE System Privilege for SELECT Operations

You now can use the READ object privilege to enable users query database tables, views, materialized views, and synonyms. You still can use the SELECT object privilege, but remember that in addition to enabling users to query objects, the SELECT object privilege allows users to perform the following operations, which enables them to lock the rows of a table:

• LOCK TABLE table_name IN EXCLUSIVE MODE;

• SELECT ... FROM table_name FOR UPDATE;

The READ object privilege does not provide these additional privileges. For better security, grant users the READ object privilege if you want to restrict them to performing queries only.

In addition to the READ object privilege, you can grant users the READ ANY TABLE privilege to enable them to query any table in the database.

When a user who as been granted the READ object privilege wants to perform a query, the user still must use the SELECT statement. There is no accompanying READ SQL statement for the READ object privilege.

The GRANT ALL PRIVILEGES TO user SQL statement includes the READ ANY TABLE system privilege. The GRANT ALL PRIVILEGES ON object TO user statement includes the READ object privilege.

See the following sections for more information:

• "READ and SELECT Object Privileges"

• "Auditing SELECT and the READ ANY TABLE or SELECT ANY TABLE Privilege"

FIPS-Certified Cryptographic Modules

Starting with this release, you can enable or disable Federal Information Processing Standard (FIPS) 140-2 mode in Transparent Data Encryption and the DBMS_CRYPTO PL/SQL package program units by setting the FIPS_140 initialization parameter to TRUE. If you set it to FALSE, then depending on the platform on which you installed Oracle Database, a different standard will be used to protect data.

See Appendix E, "Oracle Database FIPS 140 Settings" for more information.

New orapki Command for Converting an Oracle Wallet to Use the AES256 Algorithm

Starting with this release, you can convert Oracle wallet (also called keystores) from the 3DES algorithm to the AES256 algorithm, which is stronger than the 3DES algorithm.

See "Converting an Oracle Wallet to Use the AES256 Algorithm" for more information.

Transparent Sensitive Data Protection to Protect Categories of Data

You can create Transparent Sensitive Data Protection policies that protect categories of data as a whole. Transparent Sensitive Data Protection enables you to quickly find all table columns in a database that hold sensitive data (such as credit card or Social Security numbers), classify this data, and then create a policy that protects this data as a whole for a given class. This feature enables you to create uniform policies for data throughout your organization.

See Chapter 11, "Using Transparent Sensitive Data Protection," for more information.

New Password Verification Functions

In previous releases, Oracle Database provided a password verification function, verify_function_11G, in the script utlpwdmg.sql. For this release, the script has been enhanced with the following two new additional functions that provide stronger levels of password verification:

• ora12c_verify_function function checks for requirements such as the minimum number of characters in a password, that it is different from the previously set password, and so on.

• ora12c_strong_verify_function function checks for the recommended requirements by the Department of Defense Database Security Technical Implementation Guide.

See the following sections for more information:

• "How Oracle Database Checks the Complexity of Passwords"

• "About Customizing Password Complexity Verification"

Ability to Attach Roles to Program Units

You now can attach database roles to the program units functions, procedures, and PL/SQL packages. This feature enables you to temporarily elevate privileges in the PL/SQL code without granting the role directly to the invoker of the code. The benefit of this feature is that it increases security for applications and helps to enforce the principle of least privilege.

See the following sections for more information:

• "Granting and Revoking Roles to and from Program Units"

• "Using Code Based Access Control for Definer's Rights and Invoker's Rights"

Ability to Control Whether a Procedure Caller's Privileges Can Be Used

When a user runs an invoker's rights procedure (or program unit), it runs with the privileges of the invoking user. As the procedure runs, the procedure's owner temporarily has access to the invoking user's privileges. In the situation where a procedure owner has fewer privileges than an invoking user, the procedure owner could potentially modify the procedure to use the invoking user's privileges to perform operations unintended by or forbidden to its owner.

In previous releases, the invoking user had no control over who could have this access when he or she runs an invoker's rights procedure. Starting with this release, invoker's rights procedure calls only can run with the privileges of the invoker if the procedure's owner has the INHERIT PRIVILEGES privilege on the invoker or if the procedure's owner has the INHERIT ANY PRIVILEGES privilege.

The benefit of this feature is that it gives invoking users control over who has access to their privileges when they run invoker's rights procedures or query BEQUEATH CURRENT_USER views.

See the following sections for more information:

• "Controlling Invoker's Rights Privileges for Procedure Calls and View Access"

• "Ability to Accommodate Invoker's Rights Behavior in Referenced Views"

Ability to Accommodate Invoker's Rights Behavior in Referenced Views

In previous releases of Oracle Database, referenced invoker's rights functions in user-created views ran with the privileges of the user who defined the view, that is, with the view acting as definer's rights. Starting with this release, you can configure your views to run these functions with the view acting as either definer's rights or invoker's rights.

See the following for more information:

• "Definer's Rights and Invoker's Rights in Views" for more information

• Oracle Database Real Application Security Administrator's and Developer's Guide for information about using the new Real Application Security-related functions that are associated with this feature

Better Security for External Procedures

For safety reasons, Oracle external procedures run in a process that is physically separate from the Oracle database. When you invoke an external procedure, Oracle Database creates the extproc operating system process (or agent), by using the operating system privileges of the user that started the listener for the database instance.

With this release, you can configure the extproc agent to run as a designated operating system credential instead of using the operating system privileges of the listener user or the Oracle server process. This feature enables you to define a credential to be associated with the extproc process, which then can authenticate impersonate (that is, run on behalf of the supplied user credential) before loading a user-defined shared library and executing a function. To configure the extproc user credential, you use a new PL/SQL package, DBMS_CREDENTIAL. As part of this new feature, the CREATE LIBRARY statement has been enhanced to enable you to associate the extproc user credential with a library.

See the following for more information:

• "Securing External Procedures"

• Oracle Database PL/SQL Packages and Types Reference for detailed information about using the DBMS_CREDENTIAL package to configure an extproc process

• Oracle Database SQL Language Reference for information about the CREATE LIBRARY statement

Support for SHA-2 Cryptographic Hash Functions

Oracle Database now supports most of the SHA-2 cryptographic hash functions. You can use these functions in the following areas:

• Network checksumming (SHA-256 and SHA-384 functions)

• DBMS_CRYPTO PL/SQL package

Kerberos Enhancements

The Oracle Advanced Security Kerberos adapter is enhanced to make it more secure and easier to use. The new Kerberos adapter enables the following features:

• Security enhancements that were introduced in the MIT Kerberos Release 1.8 distribution

• Simplified Kerberos client configuration through auto-discovery of the KDC and Kerberos Realm

• Latest and broadest compatibility with Kerberos servers on various host operating systems

See "Configuring Kerberos Authentication" for details about Kerberos enhancements and new, updated list of sqlnet.ora parameters.

Changes to Privileges for Greater Separation of Duty

For better separation of duty, Oracle Database now provides task-specific privileges to handle standard administration duties for Oracle Recovery Manager (Oracle RMAN), Oracle Data Guard, and Transparent Data Encryption. The new privileges are based on the least privilege principle, in which a user is granted only the absolutely necessary privileges required to perform a specific function, and no more. This feature alleviates the need to unnecessarily grant the SYSDBA administrative privilege for many tasks.

See "Managing Administrative Privileges" for more information about managing administrative privileges.

RESOURCE Role No Longer Grants the UNLIMITED TABLESPACE Privilege

Starting with this release, the RESOURCE role will no longer grant the UNLIMITED TABLESPACE system privilege by default. If you want users to have this system privilege, then you must manually grant it to them.

See "Predefined Roles in an Oracle Database Installation" for more information about default roles.

SELECT ANY DICTIONARY Privilege No Longer Accesses Some SYS Data Dictionary Tables

For better security, the SELECT ANY DICTIONARY system privilege no longer permits you to query the SYS schema system tables DEFAULT_PWD$, ENC$, LINK$, USER$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, and XS$VERIFIERS. Only user SYS has access to these tables, but user SYS can grant object privileges (such as GRANT SELECT ON USER$ TO sec_admin) to other users.

See Oracle Database SQL Language Reference for more information about system and object privileges.

Controlling the Evaluation of Oracle Virtual Private Database Context Sensitive Policies

In previous releases, when you created Oracle Virtual Private Database (VPD) context-sensitive policies, Oracle Database evaluated the policy every time that any attribute of any context changed, even if the application context attribute did not affect the VPD context-sensitive policy. Starting with this release, you can enable Oracle Database to evaluate the VPD context-sensitive policy only if the associated application context attribute changes. You can associate application contexts and their attributes to specific VPD policies, which enables the VPD policies to generate new predicates only when the associated application context attributes change.

See "Use of a Context-Sensitive Policy for Application Context Attributes That Change" for more information.

Support for Long Identifiers for the Virtual Private Database DBMS_RLS Package and Views

In previous releases of Oracle Database, the maximum length for object names (such as names of tables, schemas, policies, and functions) specified in the Oracle Virtual Private Database DBMS_RLS PL/SQL package procedures and in the related views for this package has been 30 bytes. Starting with this release, the maximum length is 128 bytes.

See Chapter 10, "Using Oracle Virtual Private Database to Control Data Access," for more information about Oracle Virtual Private Database.

Changes to Configuring Fine-Grained Access to Services and Wallets

In this release, the procedures to configure fine-grained access to external network services and to Oracle wallets have been simplified. The DBMS_NETWORK_ACL_ADMIN PL/SQL package has changed as follows:

To accommodate these changed procedures, the following new data dictionary views are introduced in this release:

• DBA_HOST_ACLS

• DBA_HOST_ACES

• USER_HOST_ACES

See the following sections for more information:

• Chapter 6, "Managing Fine-Grained Access in PL/SQL Packages and Types"

• "Deprecated DBMS_NETWORK_ACL_ADMIN Package Procedures and Views"

Significant Redesign in Auditing Functionality

For this release, the auditing functionality has been significantly redesigned from the functionality used in previous releases. When you install a new Release 12 Oracle database, the full set of auditing enhancement features (unified auditing) are automatically available. If you upgrade from a previous release, then you are given the option of using some of the new audit features and the audit functionality from the release that you upgraded from. Oracle strongly recommends that you migrate to the full set of latest audit features.

See Oracle Database Upgrade Guide for information about migrating to the new auditing capabilities.

Faster Audit Performance

This release provides a much faster audit performance than in previous releases of Oracle Database. You also can control how the audit records are written to the audit trail, whether immediately or queued to memory.

See "Writing the Unified Audit Trail Records to the AUDSYS Schema" for more information.

Unified Audit Data Trail

In previous releases of Oracle Database, there were separate audit trails for individual components: SYS.AUD$ for the database audit trail, SYS.FGA_LOG$ for fine-grained auditing, DVSYS.AUDIT_TRAIL$ for Oracle Database Vault, Oracle Label Security, and so on. In this release, these audit trails are all unified into one, viewable from the UNIFIED_AUDIT_TRAIL data dictionary view for single-instance installations Oracle Database Real Application Clusters environments.

A consolidated audit data trail has many advantages. This way, you can run analysis reports on an entire set of audit data in one operation, rather than having to first gather them into one location before performing the analysis. Audit mining tools such as Oracle Audit Vault now can look at one location rather than several in order to gather audit records. A unified audit trail ensures that the audit information is consistently formatted and contains consistent fields.

See "Managing the Unified Audit Trail" for more information.

New Schema for the Unified Audit Trail

As part of the unified audit trail enhancement, a new schema, AUDSYS, will be used solely for storage of the unified audit trail data table. The existing audit data in the AUD$ and FGA_LOG$ system tables, audit metadata, and audit PL/SQL packages, will continue to reside in the SYS schema.

See "Managing the Unified Audit Trail" for more information.

Separation of Duties for Audit Administration

For better separation of duty, two new database roles are now available for use with auditing: AUDIT_ADMIN, for audit configuration and audit trail administration, and AUDIT_VIEWER, for viewing and analyzing audit data.

See "Who Can Perform Auditing?" for more information.

Ability to Create Named Unified Audit Policies

You now can create named unified audit policies. A unified audit policy contains a set of audit options and it is stored in the database as an object. The advantage of creating a named unified audit policy is that it reduces the number of commands that are required to create a database audit policy, and it simplifies the implementation of an audit configuration for security and compliance.

The following new SQL statements enable you to manage audit policies:

• CREATE AUDIT POLICY

• ALTER AUDIT POLICY

• DROP AUDIT POLICY

In addition, the existing AUDIT and NOAUDIT statements now allow you to enable or disable unified audit policies, apply user to or exclude users from the policy, and set whether an audit record is created if the audited behavior fails, succeeds, or both.

See "Auditing Activities with Unified Audit Policies and the AUDIT Statement" for more information.

Ability to Audit Any Role

Starting with this release, you can audit any database role, including user-created roles. This enables you to audit all system privileges that have been granted to the role. The benefit of this feature is that it simplifies to a single command all activity that has been granted to a role. This eliminates the need to update a unified audit policy each time you update the role with new privileges or when new database users are added to the database and granted a role.

See "Auditing Roles" for more information.

Mandatory Recording of Auditing Actions

In this release, all actions that are associated with the audit capabilities are always audited. Auditing the audit administrator's actions helps to ensure the integrity of the audit policies that have been implemented in the Oracle database, for both security and compliance requirements.

See "Activities That Are Mandatorily Audited" for more information.

Oracle ACFS Auditing and Support for Importing Audit Data into the Oracle Audit Vault Server

This feature provides auditing for Oracle Automatic Storage Management Cluster File System (ACFS) security and encryption. In addition, this feature also generates an XML file containing the Oracle ACFS audit trail data which can be imported by the Oracle Audit Vault Server. This way, you can take advantage of the Oracle Audit Vault functionality for the storage and reporting of Oracle ACFS audit data.

See Oracle Automatic Storage Management Administrator's Guide for more information.

User, Privilege, and Role Support for the Oracle Multitenant Option

This release of Oracle Database introduces the Oracle Multitenant option, which enables an Oracle database to contain a portable set of schemas and non-schema objects (such as editions, roles, and so on) that appears to users and applications as if it were a separate database. Each set of these objects is called a pluggable database (PDB) and the database that stores these PDBs is called a multitenant container database (CDB).

Oracle Database 12c Release 1 (12.1) supports both CDBs and non-CDBs. This guide explains how to manage CDB and non-CDB user accounts, privileges, and roles.

See the following for more information:

• "About Common Users and Local Users"

• "About Commonly and Locally Granted Privileges"

• "Managing Common Roles and Local Roles"

• Oracle Database Administrator's Guide for detailed information about PDBs

Ability to Use Password Files for Automatic Storage Management

Oracle Automatic Storage Management (ASM) now supports storing password files inside ASM disk groups.

See Oracle Automatic Storage Management Administrator's Guide for more information about managing password files for Automatic Storage Management.

New Secure Sockets Layer Cipher Suites

The following Secure Sockets Layer cipher suites are available starting with this release:

See Table 18-1 for a full list of supported Secure Sockets Layer cipher suites.

Deprecation of the SQLNET.ALLOWED_LOGON_VERSION Parameter

Starting with this release, the Oracle Net Services SQLNET.ALLOWED_LOGON_VERSION parameter is being deprecated. The following two parameters replace it:

• SQLNET.ALLOWED_LOGON_VERSION_SERVER

• SQLNET.ALLOWED_LOGON_VERSION_CLIENT

By having a server version and a client version of the SQLNET.ALLOWED_LOGON_VERSION parameter, you have more flexibility when you must configure servers that use database links. When you process a query that involves a connected database link, the server acts as a client to the target database of the database link. For example, suppose you have an Oracle Database 12c Release 1 (12.1) database that connects to an Oracle 9i database. By setting the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter to 11 and the SQLNET.ALLOWED_LOGON_VERSION_CLIENT parameter to 8, you restrict connections to the Oracle Database 12c database to only clients running Oracle Database Release 11 or later. However, these setting still enable the Oracle Database 12c server to act as a client to the older Oracle 9i database.

See the following for more information:

• "Support for SHA-2 Cryptographic Hash Functions"

• Oracle Database Net Services Reference for reference information about the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter

• Oracle Database Net Services Reference for reference information about the SQLNET.ALLOWED_LOGON_VERSION_CLIENT parameter

Deprecation of the ORAPWD Utility IGNORECASE Argument

Starting with this release, the IGNORECASE argument of the ORAPWD utility, which you use to create password files, is deprecated. By default, IGNORECASE is set to N (no), which makes passwords case sensitive.

Deprecation of the SEC_CASE_SENSITIVE_LOGON Initialization Parameter

The SEC_CASE_SENSITIVE_LOGON initialization parameter, which enables or disables case sensitivity for passwords, is deprecated because the standards-based verifiers (SHA-1) do not support case sensitive password matching. However, for backward compatibility reasons, this parameter is available for this release. For better security, ensure that this parameter is set to TRUE, so that database logon passwords are case sensitive.

See the following for more information:

• "Enabling Password Case Sensitivity"

• Oracle Database Reference for reference information about the SEC_CASE_SENSITIVE_LOGON parameter

Deprecated DBMS_NETWORK_ACL_ADMIN Package Procedures and Views

The following procedures in the DBMS_NETWORK_ACL_ADMIN PL/SQL package have been deprecated:

• CREATE_ACL

• ADD_PRIVILEGE

• DELETE_PRIVILEGE

• ASSIGN_ACL

• UNASSIGN_ACL

• DROP_ACL

• ASSIGN_WALLET_ACL

• UNASSIGN_WALLET_ACL

• CHECK_PRIVILEGE

• CHECK_PRIVILEGE_ACLID

The following DBMS_NETWORK_ACL_ADMIN package-related data dictionary views have been deprecated:

• DBA_NETWORK_ACLS

• DBA_NETWORK_ACL_PRIVILEGES

• USER_NETWORK_ACL_PRIVILEGES

See the following sections for more information:

• "Changes to Configuring Fine-Grained Access to Services and Wallets"

• Chapter 6, "Managing Fine-Grained Access in PL/SQL Packages and Types"

Deprecation of the DELETE_CATALOG_ROLE Role

The DELETE_CATALOG_ROLE role is deprecated in Oracle Database 12c Release 1 (12.1).

Desupported Secure Sockets Layer Cipher Suites

The following Secure Sockets Layer cipher suites are desupported.

See Table 18-1 for a full list of supported Secure Sockets Layer cipher suites.