Changes in This Release for Oracle Database Security Guide

This preface contains:

Changes in Oracle Database Security 20c

Oracle Database Security Guide for Oracle Database 20c has new security features.

Force Upgraded Password File to be Case Sensitive

Starting in Oracle Database 20c, the parameter to enable or disable password file case sensitivity is removed. All passwords in new password files are case-sensitive.

Case-sensitive password files provide more security than older password files that are case insensitive. Oracle recommends that you use case-sensitive password files. However, upgraded password files from earlier Oracle Database releases can retain their original case-insensitivity. You can force your password files to be case-sensitive by migrating password files from one format to another.

Ability to Specify the Location of the CMU Wallet and dsi.ora File with a Database Property

You now can specify a location of centrally managed users (CMU) wallet and dsi.ora files for an individual PDB by using a database property on the PDB.

This enhancement enables a PDB administrator to specify a location to store these files rather than being limited by the sqlnet.ora WALLET_LOCATION parameter or having to use the default wallet locations. This feature works almost exactly as using WALLET_LOCATION or the default wallet location except that users with administrative privileges will not be able to start the database because directory objects are part of the database. To store the CMU wallet and dsi.ora files in the location path specified by a database directory object, you must set the CMU_WALLET database property to this directory object.

After you have set the CMU_WALLET database property to a directory object for an individual PDB, you should store the CMU wallet and dsi.ora files for this PDB in the location specified by the directory object, so that they can be accessed through the corresponding file systems.

Addition of USER_APPLICATION_ROLES Data Dictionary View

Starting with this release, the USER_APPLICATION_ROLES data dictionary view will provide a subset of roles that are available in DBA_APPLICATION_ROLES that only apply to the current user.

USER_APPLICATION_ROLES enables the current user to see all the application roles that have been granted to the user instead of the list of all possible application roles available in DBA_APPLICATION_ROLES.

Related Topics

New System Privilege and Initialization Parameter for Diagnostic Events

This release introduces better security controls for the setting of debug-events (events++, error-numbers) and debug-actions through ALTER SESSION and ALTER SYSTEM operations.

To support this enhancement, the following features are available:

  • ENABLE DIAGNOSTICS system privilege
  • DIAGNOSTICS_CONTROL initialization parameter

Some debug-events and debug-actions are not safe and should be exposed to users with caution. In previous releases, privilege control for the usage of these diagnostics was not sufficient. With this new privilege control, regular users can be blocked from using these diagnostics to better support separation of duty.

Multiple Wallet Support for Distinct SSL Connections in One Process

Starting with Oracle Database 20c, you can configure database clients to maintain multiple Secure Sockets Layer (SSL) sessions using different SSL certificates.

This feature allows multi-threaded clients use multiple wallets with different certificates for simultaneous SSL sessions.

This enhancement enables the database client to connect simultaneously with different external identities. This allows multi-threaded clients to use multiple wallets with different certificates for simultaneous SSL sessions.

Oracle SQL*Loader Support for Object Store Credentials

Starting with Oracle Database 20c, Oracle SQL*Loader accesses data in an object store by presenting user-defined credentials.

Oracle SQL*Loader now enables you to specify credentials that you define allowing files in an object store to be loaded into an Oracle database.

Unified Audit Policy Configuration Changes Effective Immediately

Starting with this release, changes that are made to a unified audit policy will become effective immediately in the current session and in all other on-going active sessions.

In previous releases, users who were affected by a changed unified audit policy had to log out of and then back into the session in order for the unified audit policy to take effect.

Unified Audit Policies Enforced on the Current User

Starting with this release, unified audit policies are enforced on the current user who executes the SQL statement.

In previous releases, unified audit policies were enforced on the user who owned the top-level user session (that is, the login user session) in which the SQL statement is executed.

Scenarios in which the current user is different from the login user include but is not limited to the following:

  • Trigger execution
  • Definer rights procedure execution
  • Functions and procedures that are executed during the evaluation of views

Predefined Unified Audit Policies for Security Technical Implementation Guides Compliance

Starting with this release, you can audit for Security Technical Implementation Guides (STIG) compliance by using new predefined unified audit policies.

These polices are as follows:


SYSLOG Destination for Common Unified Audit Policies

Certain predefined columns of unified audit records from common unified audit policies can be written to the UNIX SYSLOG destination.

To enable this feature, you set UNIFIED_AUDIT_COMMON_SYSTEMLOG, a new CDB level init.ora parameter. This enhancement enables all audit records from common unified audit policies to be consolidated into a single destination.

This feature is available only on UNIX platforms, not Windows.

Auditing for Oracle XML DB HTTP and FTP Services

Starting with this release, you can create unified audit policies for database connections made using the database protocol servers for HTTP, HTTPS, and FTP.

A unified audit policy can track requests that have been made to servlets, such as those used by Oracle Enterprise Manager Express, Oracle Database Native Web Services, and HTTP and FTP that use the Oracle XML DB Repository.

This enhancement enables you to track and monitor access to Oracle Database provided by the HTTP, HTTPS, and FTP protocols, including access by WebDAV clients

Deprecation of Traditional Auditing

Traditional auditing is deprecated in Oracle Database 20c. Oracle recommends that you use unified auditing, which enables selective and more effective auditing inside Oracle Database.

Oracle introduced unified auditing with Oracle Database 12c. In addition to providing built-in audit operation support, unified auditing simplifies management of auditing within the database, provides the ability to accelerate auditing based on conditions, and increases the security of audit data generated by the database. Unified auditing and traditional auditing (mixed mode) has been the default auditing mode from Oracle Database 12c onward. Mixed mode auditing was offered to enable you to become familiar with unified auditing, and to transition from traditional auditing. With the deprecation of traditional auditing in this release, Oracle recommends that you migrate to unified auditing.

Changes in Oracle Database Security 19c

Oracle Database Security Guide for Oracle Database 19c has new security features.

Signature-Based Security for LOB Locators

Starting with this release, you can configure signature-based security for large object (LOB) locators.

This feature strengthens the security of Oracle Database LOBs, particularly when instances of LOB data types (CLOB and BLOB) are used in distributed environments.

LOB signature keys can be in both multitenant PDBs or in standalone, non-multitenant databases. You can enable the encryption of the LOB signature key credentials by executing the ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS SQL statement; otherwise, the credentials are stored in obfuscated format. If you choose to store the LOB signature key in encrypted format, then the database or PDB must have an open TDE keystore.

Default User Accounts Now Schema Only

Using the schema only account feature from Oracle Database release 18c, most of the Oracle Database supplied schemas (users) now have their passwords removed to prevent users from authenticating to these accounts.

This enhancement does not affect the sample schemas. Sample schemas are still installed with their default passwords.

For the default schemas that are schema only, administrators can still alter these accounts with passwords if they need to authenticate to the schema, but Oracle recommends changing the schemas back to a schema-only account afterward.

The benefit of this feature is that administrators no longer have to periodically rotate the passwords for these Oracle Database-provided schemas. This feature also reduces the security risk of attackers using default passwords to hack into these accounts.

Privilege Analysis Documentation Moved to Oracle Database Security Guide

The documentation for privilege analysis has moved from Oracle Database Vault Administrator’s Guide to Oracle Database Security Guide.

See Oracle Database Licensing Information User Manual for privilege analysis licensing information.

Ability to Grant or Revoke Administrative Privileges to and from Schema-Only Accounts

Administrative privileges such as SYSOPER and SYSBACKUP can now be granted to schema-only (passwordless) accounts.

Existing user accounts (active, rarely accessed, and unused users) that are currently granted administrative privileges can be altered to be schema-only accounts. This enhancement prevents administrators from having to manage the passwords of these accounts.

Automatic Support for Both SASL and Non-SASL Active Directory Connections

Starting with this release, both Simple Authentication and Security Layer (SASL) and Transport Layer Security (TLS) binds are supported for Microsoft Active Directory connections.

For centrally managed users, the Oracle database will initially try to connect to Active Directory using SASL bind. If the Active Directory server rejects the SASL bind connection, then the Oracle database will automatically attempt the connection again without SASL bind but still secured with TLS.

The Active Directory administrator is responsible for configuring the connection parameters for Active Directory server, but does not need to configure the database to match this new Active Directory connection enhancement. The database will automatically adjust from using SASL to not using SASL bind.

Support for Oracle Native Encryption and SSL Authentication for Different Users Concurrently

In previous releases, Oracle Database prevented the use of both Oracle native encryption (also called Advanced Networking Option (ANO) encryption) and Secure Sockets Layer (SSL) authentication together.

Starting with this release, you can set a new parameter, SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS, to TRUE to ignore the SQLNET.ENCRYPTION_CLIENT or SQLNET.ENCRYPTION_SERVER when there is a conflict between the use of a TCPS client and either of these two parameters are set to required.

Support for Host Name-Based Partial DN Matching for Matching for Server Certificates

This new support for partial DN matching adds the ability for the client to further verify the server certificate.

The earlier ability to perform a full DN match with the server certificate during the Secure Sockets Layer (SSL) handshake is still supported. The client supports both full and partial DN matching. If the server DN matching is enabled, then partial DN matching is the default.

Allowing partial and full DN matching for certificate verification enables more flexibility based on how the certificates were created.

Ability to Audit Only Top-Level SQL Statements

The unified auditing top-level statements feature enables you to audit top level user (or, direct user) activities in the database but without collecting indirect user activity audit data.

You can use this feature to audit only the top-level user directly issued events, without the overhead of indirect SQL statements. Top-level statements are SQL statements that users directly issue. These statements can be important for both security and compliance. SQL statements run from within PL/SQL procedures or functions are not considered top level, so they may be less relevant for auditing purposes.

Improved Read Performance for the Unified Audit Trial

The AUDSYS.AUD$UNIFIED system table, which stores the unified audit trail records, has been redesigned to use partition pruning to improve read performance.

This redesign entailed the addition of a new column to the AUDSYS.AUD$UNIFIED table. The UNIFIED_AUDIT_TRAIL data dictionary view, which enables you to query the AUDSYS.AUD$UNIFIED table audit records, now has the EVENT_TIMESTAMP_UTC column to correspond with the new AUDSYS.AUD$UNIFIED table column. As part of this enhancement, the data type of the EVENT_TIMESTAMP column in the GV$UNIFIED_AUDIT_TRAIL view has changed TIMESTAMP(6).

Oracle recommends that when you query the UNIFIED_AUDIT_TRAIL view, to include the EVENT_TIMESTAMP_UTC column in the WHERE clause to achieve partitioning pruning.

PDB_GUID as Audit Record Field Name for SYSLOG and the Windows Event Viewer

The audit record fields for SYSLOG and the Windows Event Viewer now have a new field, PDB_GUID, to identify the pluggable database associated with a unified audit trail record.

In a multitenant database deployment, the pluggable database that generated a unified audit trail record must be identified in the audit trail. Starting with this release, the SYSLOG and Windows Event Viewer will have a new field, PDB_GUID, to capture this information. The data type is VARCHAR2.