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.

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 is now available as part of Oracle Database Enterprise Edition.

Privilege analysis runs dynamic analysis of users and applications to find privileges and roles that are used and unused. Privilege analysis reduces the work to implement least privilege best practices by showing you exactly what privileges are used and not used by each account. Privilege analysis is highly performant and designed to work in test, development, and production databases.

As part of this change, the documentation for privilege analysis has moved from Oracle Database Vault Administrator’s Guide to Oracle Database Security Guide.

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.

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.

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.

For example, if you set the SQLNET.ENCRYPTION_CLIENT parameter on the client to required and SQLNET.ENCRYPTION_SERVER on the server to required, and if a TCPS listener is used, then the ORA-12696 Double Encryption Turned On, login disallowed error appeared. 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.

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.

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.

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.

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.

You now can create schema only accounts, for object ownership without allowing clients to log in to the schema.

A user (or other client) cannot log in to the database schema unless the account is modified to accept an authentication method. However, this type of schema user can proxy in a single session proxy.

Starting with this release, you can authenticate and authorize users directly with Microsoft Active Directory.

With centrally managed users (CMU) Oracle database users and roles can map directly to Active Directory users and groups without using Oracle Enterprise User Security (EUS) or another intermediate directory service. EUS is not being replaced or deprecated; this new feature is another simpler option if you only want to authenticate and authorize users with Active Directory. Centrally managed users is designed to be extended to work with other LDAP version 3–compliant directory services, but Microsoft Active Directory is the only service that is supported in this release.

The direct integration with directory services supports better security through simpler configuration with the enterprise identity management architecture. In the past, users may have avoided the security practice of integrating the database with directory services due to the difficulty and complexity. With the direct integration, you can improve your security posture by more easily integrating the Database to the enterprise directory service.

Starting with this release, you can encrypt sensitive credential data that is stored in the data dictionary SYS.LINK$ and SYS.SCHEDULER$_CREDENTIAL system tables.

In previous releases, and by default in this release, the data in these tables is obfuscated. However, because of the rise of de-obfuscation algorithms that are available on the Internet, it is important to use a more secure solution to protect this type of sensitive data. You can manually encrypt this data by using the ALTER DATABASE DICTIONARY SQL statement.

This release introduces several enhancements for PDB lockdown profiles.

These enhancements are as follows:

• You now can create PDB lockdown profiles in the application root, as well as in the CDB root. In previous releases, you only could create the profile in the CDB root. The ability to create a PDB lockdown profile in an application container enables you to more finely control access to the applications that are associated with the application container.

• You now can create a PDB lockdown profile that is based on another PDB lockdown profile, either a static base profile or a dynamic base profile. You can control whether subsequent changes to the base profile are reflected in the newly created profile that uses the base profile.

• Three default PDB lockown profiles have been added for this release: PRIVATE_DBAAS, SAAS, and PUBLIC_DBAAS. These profiles benefit Cloud environments.

• A new dynamic data dictionary view, V$LOCKDOWN_RULES, is available. This view enables the local user to see the lockdown rules that are applicable in the PDB.

This feature benefits environments that need enforced security and isolation in PDB provisioning.

This release introduces four new parameters that can be used to strengthen security on the database.

The new parameters are as follows:

• The ADD_SSLV3_TO_DEFAULT sqlnet.ora parameter controls the use of the Secure Sockets Layer version 3, which can be vulnerable to Padding Oracle On Downgraded Legacy Encryption (POODLE) attacks

• The ADG_ACCOUNT_INFO_TRACKING initialization parameter controls login attempts on Oracle Data Guard standby databases by enabling you to maintain a single global copy of user account information across all Data Guard primary and standby databases.

  The ACCEPT_MD5_CERTS sqlnet.ora parameter enables or disables the MD5 algorithm.

• The ACCEPT_SHA1_CERTS sqlnet.ora parameter enables or disables the SHA-1 algorithm.

Starting with this release you can write unified audit trail records to SYSLOG on UNIX or the Windows Event Viewer on Microsoft Windows.

On Microsoft Windows, you can enable or disable this behavior. On UNIX systems, you can specify the SYSLOG facility to use and the type logging category for the unified audit record, such as whether it is an alert or for an emergency. To configure this behavior, you can set the UNIFIED_AUDIT_SYSTEMLOG initialization parameter.

Starting with this release, you can include the unified audit trail in either full or partial export and import operations using Oracle Data Pump.

There is no change to the user interface. When you perform the export or import operation of a database, the unified audit trail is automatically included in the Data Pump dump files.

This feature benefits users who, as in previous releases, must create dump files of audit records.