This preface contains:
The following are changes in Oracle Database Security Guide for Oracle Database 12c Release 1 (12.1.0.2):
The following features are new in this release:
Use of ADMIN and DELEGATE Options for Code Based Access Control User Role Grants
USERENV Namespace UNIFIED_AUDIT_SESSIONID Parameter to Capture the Unified Audit Session ID
New READ Object Privilege and READ ANY TABLE System Privilege for SELECT Operations
New orapki Command for Converting an Oracle Wallet to Use the AES256 Algorithm
Oracle Database 12c Release 1 (12.1.0.2) uses the SHA-512 cryptographic hash to generate the 12C password version. In addition, both Oracle Call Interface (OCI) and thin JDBC client now support the 12C password version 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 Password Version
Oracle Database PL/SQL Packages and Types Reference for details about SHA-2 support in the DBMS_CRYPTO PL/SQL package
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 Password Version for more information.
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.
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.
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:
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.
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:
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 Oracle Database FIPS 140 Settings for more information.
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.
The following are changes in Oracle Database Security Guide for Oracle Database 12c Release 1 (12.1.0.1):
The following features are new in this release:
Transparent Sensitive Data Protection to Protect Categories of Data
Ability to Control Whether a Procedure Caller's Privileges Can Be Used
Ability to Accommodate Invoker's Rights Behavior in Referenced Views
RESOURCE Role No Longer Grants the UNLIMITED TABLESPACE Privilege
SELECT ANY DICTIONARY Privilege No Longer Accesses Some SYS Data Dictionary Tables
Controlling the Evaluation of Oracle Virtual Private Database Context Sensitive Policies
Support for Long Identifiers for the Virtual Private Database DBMS_RLS Package and Views
Changes to Configuring Fine-Grained Access to Services and Wallets
Oracle ACFS Auditing and Support for Importing Audit Data into the Oracle Audit Vault Server
User_ Privilege_ and Role Support for the Oracle Multitenant Option
Ability to Use Password Files for Automatic Storage Management
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 Using Transparent Sensitive Data Protection , for more information.
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:
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:
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:
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
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.
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.
Being able to configure the extproc agent to run as a designated operating system credential 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:
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
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
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.
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.
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.
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.
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 "Context-Sensitive Policy for Application Context Attributes That Change" for more information.
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 Using Oracle Virtual Private Database to Control Data Access , for more information about Oracle Virtual Private Database.
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:
| Previous DBMS_NETWORK_ACL_ADMIN Procedure | New Equivalent Procedure |
|---|---|
|
|
|
|
N/A |
|
|
N/A |
|
|
|
|
|
|
None |
|
|
None |
|
N/A |
|
|
N/A |
|
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:
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.
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.
In previous releases of Oracle Database, there were separate audit trails for individual components.
These components are 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.
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.
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.
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.
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.
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.
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.
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:
Oracle Database Administrator's Guide for detailed information about PDBs
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.
The following Secure Sockets Layer cipher suites are available starting with this release:
| Cipher Suites | Authentication | Encryption | Data Integrity |
|---|---|---|---|
|
SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
ECDHE_ECDSA |
AES 128 CBC |
SHA-1 |
|
SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
ECDHE_ECDSA |
AES 128 CBC |
SHA256 (SHA-2) |
|
SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
ECDHE_ECDSA |
AES 128 GCM |
SHA256 (SHA-2) |
|
SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
ECDHE_ECDSA |
AES 256 CBC |
SHA-1 |
|
SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
ECDHE_ECDSA |
AES 256 CBC |
SHA384 (SHA-2) |
|
SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
ECDHE_ECDSA |
AES 256 GCM |
SHA384 (SHA-2) |
|
SSL_RSA_WITH_AES_128_CBC_SHA256 |
RSA |
AES 128 CBC |
SHA256 (SHA-2) |
|
SSL_RSA_WITH_AES_128_GCM_SHA256 |
RSA |
AES 128 GCM |
SHA256 (SHA-2) |
|
SSL_RSA_WITH_AES_256_CBC_SHA256 |
RSA |
AES 256 CBC |
SHA256 (SHA-2) |
|
SSL_RSA_WITH_AES_256_GCM_SHA384 |
RSA |
AES 256 GCM |
SHA384 (SHA-2) |
See Table 18-1 for a full list of supported Secure Sockets Layer cipher suites.
The following features are deprecated in this release:
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:
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
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.
See Also:
"How Case Sensitivity Affects Password Files" for more information about case sensitivity in password files
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:
Oracle Database Reference for reference information about the SEC_CASE_SENSITIVE_LOGON parameter
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:
This section contains:
The following Secure Sockets Layer cipher suites are desupported.
| Cipher Suites | Authentication | Encryption | Data Integrity |
|---|---|---|---|
|
SSL_DH_anon_WITH_DES_CBC_SHA |
DH anon |
DES CBC |
SHA-1 |
|
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA |
RSA |
DES40 CBC |
SHA-1 |
|
SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
RSA |
RC4 40 |
MD5 |
|
SSL_RSA_WITH_DES_CBC_SHA |
RSA |
DES CBC |
SHA-1 |
See Table 18-1 for a full list of supported Secure Sockets Layer cipher suites.
Oracle Advanced Security has been repackaged for greater availability. The following features are now no longer part of Oracle Advanced Security and are provided with the default Oracle Database installation.
Thin JDBC Client Network support
RADIUS strong authentication
Kerberos strong authentication
Secure Sockets Layer (SSL) strong authentication
Multiple strong authentication support
For detailed information about these features, see this guide.
The following features are part of Oracle Advanced Security and are covered in Oracle Database Advanced Security Guide:
Transparent Data Encryption
Oracle Data Redaction
As part of this change, Oracle Database Advanced Security Administrator's Guide has been renamed to Oracle Database Advanced Security Guide.