This preface contains:
Changes in Oracle Database Security 12c Release 2 (126.96.36.199)
Oracle Database Security Guide for Oracle Database 12c release 2 (188.8.131.52) has both new and deprecated security features.
The following features are new for this release:
Ability to Create Application Common Objects, Users, Roles, and Profiles
You now can create application common objects (metadata-linked and object-linked), users, roles, and profiles.
These common objects reside in the application root. This guide explains how to manage security for application common users, roles, and profiles.
Application Container Security Features
Application containers affect several default security features, such as privilege grants to application common users, how application contexts are used, and so on.
The following functionality is affected:
Application common users: In addition to other privileges, you can grant the
SYSOPERadministrative privileges to application common users.
Application contexts: When you create an application in the application root, you can create an application context for use with this application. This application context resides in the application root.
Oracle Virtual Private Database: You can create Virtual Private Database policies that protect application common objects. These policies reside in the application root.
Transparent Sensitive Data Protection: You can apply Transparent Sensitive Data Protection (TSDP) policies to the current pluggable database (PDB) or to the current application PDB only.
Transport Layer Security: If you are using Secure Sockets Layer (SSL) and plan to use the upgraded version of SSL, which is Transport Layer Security (TLS), then you must ensure that each PDB is able to use its own wallet with its own certifications for TLS authentication.
Auditing: In a multitenant environment for application containers, traditional, unified auditing, and fine-grained auditing are all affected by the use of application containers.
- SYSDBA and SYSOPER Privileges for Standard Database Operations
- Application Contexts in a Multitenant Environment
- Oracle Virtual Private Database in a Multitenant Environment
- How a Multitenant Environment Affects Transparent Sensitive Data Protection
- Using Transport Layer Security in a Multitenant Environment
- Unified Audit Policies or AUDIT Settings in a Multitenant Environment
- Fine-Grained Auditing in a Multitenant Environment
Addition of SYSRAC Administrative Privilege for Oracle Real Application Clusters
Starting with this release, the Oracle Real Applications (Oracle RAC) clusterware agent that manages Oracle RAC uses the
SYSRAC administrative privilege.
Administrative User Authentication Enhancements
Administrative user account authentication now has enhancements for password files, password profile parameters, Secure Sockets Layer (SSL), Kerberos, and multitenant environments.
These enhancements are as follows:
You can create password files for external users who have been granted the
SYSKMadministrative privileges in addition to the
SYSOPERadministrative privileges. This enhancement is available in a multitenant environment, for both local and common external administrative users, and for external users in an SSL or Kerberos authentication configuration.
SYSDGadministrative privilege can be used in a sharding environment.
You can use password profile parameters, such as
PASSWORD_LIFE_TIME, for administrative user authentication.
Enhancements for the Management of Administrative Passwords
This release introduces better security for the management of administrative passwords, by enforcing the associated administrative user’s profile password limits.
Examples of these profile limits are
You now can create a password file that can apply to both administrative users and non-administrative users. When you create a password profile using the
PASSWORD_VERIFY_FUNCTION clause of the
CREATE PROFILE statement, this setting now applies to administrative users as well as non-administrative users, as long as you create the password file with the
FORMAT parameter set to
In addition, for the
ORAPWD utility, the restriction for the entries argument for the operating system password file has been removed.
STIG Compliance Features
To meet Security Technical Implementation Guides (STIG) compliance, Oracle Database now provides two new user security features.
These features are as follows:
ora12c_stig_verify_functionpassword complexity function
The following initialization parameters have changed to accommodate STIG requirements:
The default for
The default for
The default for
SQL92_SECURITY PARAMETERis now
Better Security for Password Versions
In this release, Oracle Database provides several enhancements for password authentication versions.
The default for the
SQLNET.ALLOWED_LOGON_VERSION_SERVERparameter is now
12(Exclusive Mode) instead of
11. A setting of
12Cpassword versions. If you want to restrict the generation to the
12Cpassword version, which increases security for the passwords, then you can set
Be aware that you should check the versions of the clients that connect to the server to ensure that these clients use the
O5L_NPability. All Oracle Database release 184.108.40.206 and later clients have the
O5L_NPability. If you have an earlier Oracle Database client, then you must install the CPUOct2012 patch.
12Cpassword version is now generated automatically. In previous releases, the
10Gpassword version was generated automatically.
Oracle Database Upgrade Guide for information about how password case sensitivity is affected by Oracle Database upgrades
Ability to Automatically Lock Inactive Database User Accounts
Starting with this release, you can configure user accounts to automatically lock if they have been inactive over a period of time.
CREATE USER and
ALTER USER SQL statements enable you to set a new profile parameter,
INACTIVE_ACCOUNT_TIME, which enables you to automatically lock inactive accounts.
More Flexibility in Controlling Database Link Access
Starting with this release, you have greater control in managing database link access by users.
You can enable or disable database link access in the following areas:
Protecting the database from man-in-the-middle attacks that access the database through database links: To control this functionality, you can set the
Controlling the ability of users to use LDAP to access data through global database links: You can set the
For more information, see Network Connection Security.
Ability to Control Definer's Rights Privileges for Database Links
INHERIT REMOTE PRIVILEGES and
INHERIT ANY REMOTE PRIVILEGES privileges control definer’s rights privileges for procedures that users accesse through a database link.
These privileges are similar to the
INHERIT PRIVILEGES and
INHERIT ANY PRIVILEGES privileges.
PDB Lockdown Profiles to Restrict Operations on PDBs
In a multitenant environment, you now can use PDB lockdown profiles to restrict functionality available to users in a given PDB.
PDB lockdown profiles enable you to restrict the access the user has to a set of features individually or in a group. This feature is designed to enhance security for situations in which identities are shared among PDBs.
Ability to Set the Identity of the Operating System User for PDBs
For multitenant environments, the
PDB_OS_CREDENTIAL initialization parameter enables a different operating system user to execute external procedures using the
In the previous release,
EXTPROC was used to create a credential object using
DBMS_CREDENTIAL for authenticating and invoking external procedures. This functionality now is available on PDB level by associating a
CREDENTIAL for the entire PDB, which will be automatically used for any
EXTPROC external procedures executed by a database user in the PDB.
This feature enhances security for the multitenant environment by enabling each PDB to have its own operating system user account, instead of relying on one user, the
oracle operating system user, for all PDBs in the environment. The root will continue to use the oracle operating system user account.
See Configuring Operating System Users for a PDB for more information.
Updated Kerberos Utilities
Oracle Database now supports the updated version of the Kerberos tools from MIT Kerberos 1.8.
In previous releases, Oracle clients needed to be manually configured by an administrator who configures a
krb5.conf file. In this release, Oracle Database provides a generic
krb5.conf file, which is used by default. The
kerb5.conf file has parameters that enable realm and KDC information to be automatically retrieved from the DNS information. The auto-discovery of the realm and KDC information reduces the amount of work that you must perform to configure a client endpoint to use Kerberos.
This enhancement provides updates to the
okdstry Kerberos adapter command-line utilities, and provides a new utility,
okcreate, which enables you to automate the creation of keytabs from either the KDC or a service endpoint.
Additional Security Feature Support for Transparent Sensitive Data Protection
You now can create Transparent Sensitive Data Protection policies to use unified auditing policies, fine-grained auditing policies, and Transparent Data Encryption column encryption.
In the previous release, you could create Transparent Sensitive Data Protection policies that use the Oracle Data Redaction and Oracle Virtual Private Database security features.
In addition, you now can use a separate wallet password for each pluggable database (PDB) in a multitenant environment so that each PDB is able to use its own wallet with its own certificates for Transparent Sensitive Data Protection authentication. The ability to specify a distinct wallet password for each PDB enables you to better restrict administrative access to the wallet. This functionality provides the necessary isolation between the tenants in a multitenant environment. These tenants can be individual companies or they can be different business units in a large corporation.
Ability to Enable Unified Auditing for Groups of Users Through Roles
Starting with this release, you can enable audit policies on database roles.
This feature enables the policy to be in effect for all users who have been directly granted the role. The policy remains effective for the user as long as the user is granted the role, and as long as the role exists.
To accommodate this enhancement, the following changes have been made:
NOAUDITstatements now have a new clause,
BY USERS WITH GRANTED ROLES.
DBA_XS_ENB_AUDIT_POLICIESdata dictionary views have the following new columns:
ENTITY_NAMEcaptures the user name or role name.
ENTITY_TYPEindicates if the entity name is a
EXCEPTfor policies that are enabled on users, but displays
INVALIDfor policies that are enabled on roles.
The possible output for the
AUDIT_UNIFIED_ENABLED_POLICIES.ENABLED_OPTIONcolumn is now
BY GRANTED ROLE, and
New Audit Events for Oracle Database Real Application Security
This release provides two new audit events for Oracle Real Application Security unified audit policies.
AUDIT_GRANT_PRIVILEGEaudits use of the
AUDIT_REVOKE_PRIVILEGEaudits use of the
Ability to Capture Oracle Virtual Private Database Predicates in the Audit Trail
Oracle Virtual Private Database (VPD)-generated predicates now can be captured in the audit trail.
This enhancement applies to the unified audit trail, fine-grained audit trail, and if unified auditing is not enabled, the standard audit trail (
DBA_AUDIT_TRAIL). To accommodate this enhancement, the following data dictionary views have a new column,
DBA_AUDIT_TRAIL(used for environments that are not yet migrated to unified auditing)
V$XML_AUDIT_TRAIL(used for environments that are not yet migrated to unified auditing)
DBA_FGA_AUDIT_TRAIL(used for environments that are not yet migrated to unified auditing)
If multiple VPD policies are enforced on a single object, then all of the VPD policy types, policy schema, policy names, and predicates are concatenated and stored in a single column. To separate the VPD predicate information for each VPD policy into individual rows in the view, a new PL/SQL package is available,
Oracle Database PL/SQL Packages and Types Reference for more information about the
Enhancements for the AUDSYS Audit Schema
AUDSYS schema, which stores unified audit records, now has better security and better read performance for unified auditing.
In previous releases, users who had the
SELECT ANY TABLE system privilege were able to query objects in the
AUDSYS schema. Starting with this release, users who have this privilege are no longer able to query
AUDSYS schema objects. Users who have been granted the
SELECT ANY DICTIONARY system privilege can access objects in the
In addition, a new internal table is available in the
AUDSYS schema. This table stores the unified audit trail records and is designed to improve the read performance of the unified audit trail. If you migrated to unified auditing in the previous release and still have audit records in the previous location, then you can transfer the unified audit records that were created in that release to this new internal table. The
DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQL procedure, also new for this release, can be used to transfer these records to the new internal relational table.
The following features have been deprecated for this release:
Deprecated Columns from the AUDIT_UNIFIED_ENABLED_POLICIES and DBA_XS_ENB_AUDIT_POLICIES Views
ENABLED_OPT columns of the
DBA_XS_ENB_AUDIT_POLICIES data dictionary views are deprecated for this release.
In this release, the
USER_NAME column continues to show the names of users on whom the policy is enabled, but for policies that are enabled on roles, the
USER_NAME column displays
ENABLED_OPT column displays
EXCEPT for policies that are enabled on users, but displays
INVALID for policies that are enabled on roles. This column is replaced by the
Deprecation of the sqlnet.ora KERBEROS5_CONF_MIT Parameter
KERBEROS5_CONF_MIT parameter has been deprecated starting with this release.
This parameter specifies whether the new Kerberos configuration format is used. In previous releases, the default for the
KERBEROS5_CONF_MIT parameter was
FALSE. If the value is
TRUE, then Oracle Database uses the new Kerberos functionality that is available with this release. If the value is set to
FALSE, then non-MIT settings are used. Because this parameter is now deprecated, only the new configuration is supported. For backward compatibility, the
okdstry Kerberos utilities will work with
KERBEROS5_CONF_MIT set to
FALSE, thereby enabling them to use the earlier versions of these utilities. Oracle recommends that you set
TRUE so that you can take advantage of the new Kerberos functionality.
Deprecated Password Verification Functions
VERIFY_FUNCTION_11G password verify functions have been deprecated for this release.
These functions are deprecated because they enforce the weaker password restrictions from earlier releases. Instead, you should use the
ORA12C_STRONG_VERIFY_FUNCTION functions, which enforce stronger, more up-to-date password verification restrictions.
Deprecation of the UNIFIED_AUDIT_SGA_QUEUE_SIZE Initialization Parameter
UNIFIED_AUDIT_SGA_QUEUE_SIZE initialization parameter has been deprecated.
This parameter is no longer necessary because starting with this release, Oracle Database auditing no longer depends on the system global area (SGA)-based queues to write unified audit records.
Deprecation of the CONTAINER_GUID Parameter from the DBMS_AUDIT_MGMT Package
As part of an internal redesign to improve audit performance, the
CONTAINER_GUID parameter has been deprecated from
DBMS_AUDIT_MGMT PL/SQL package.
This parameter is no longer necessary. This deprecation affects the following
Oracle Database PL/SQL Packages and Types Reference for more information about the
Deprecation of Settings to Flush Audit Trail Records to Disk
You no longer need to manually flush audit records to disk because they are now automatically written to a new internal relational table.
This enhancement enables the flushing process to bypass the common logging infrastructure queues. The deprecated settings are as follows:
AUDIT_TRAIL_WRITEmode of the
AUDIT_TRAIL_PROPERTYparameter of the