This preface contains:
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
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
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.
For example, if you set the
SQLNET.ENCRYPTION_CLIENT parameter on the client to
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,
TRUE to ignore the
SQLNET.ENCRYPTION_SERVER when there is a conflict between the use of a TCPS client and either of these two parameters are set to
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
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
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
Changes in Oracle Database Security 18c
Oracle Database Security Guide for Oracle Database 18c has new security features.
Ability to Create Schema Only Accounts
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.
Integration of Active Directory Services with Oracle Database
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.
Ability to Encrypt Sensitive Credential Data in the Data Dictionary
Starting with this release, you can encrypt sensitive credential data that is stored in the data dictionary
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.
PDB Lockdown Profile Enhancements
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:
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.
New Authentication and Certification Parameters
This release introduces four new parameters that can be used to strengthen security on the database.
The new parameters are as follows:
sqlnet.oraparameter controls the use of the Secure Sockets Layer version 3, which can be vulnerable to Padding Oracle On Downgraded Legacy Encryption (POODLE) attacks
ADG_ACCOUNT_INFO_TRACKINGinitialization 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.
sqlnet.oraparameter enables or disables the MD5 algorithm.
sqlnet.oraparameter enables or disables the SHA-1 algorithm.
Ability to Write Unified Audit Trail Records to SYSLOG or the Windows Event Viewer
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.
Ability to Use Oracle Data Pump to Export and Import the Unified Audit Trail
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.