Changes in This Release for Oracle Database Security Guide
This preface contains:
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.
Related Topics
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.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.
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:
PRIVATE_DBAAS
,SAAS
, andPUBLIC_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.
Related Topics
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:
-
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.
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.
Changes in Oracle Database Security 12c Release 2 (12.2)
Oracle Database Security Guide for Oracle Database 12c release 2 (12.2) has both new and deprecated security features.
New 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
SYSDBA
andSYSOPER
administrative 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.
Related Topics
- 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
SYSASM
,SYSBACKUP
,SYSDG
, andSYSKM
administrative privileges in addition to theSYSDBA
andSYSOPER
administrative 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. -
The
SYSDG
administrative 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 FAILED_LOGIN_COUNT
, PASSWORD_LOCK_TIME
, PASSWORD_GRACE_TIME
, and PASSWORD_LIFE_TIME
.
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 ORAPWD
utility FORMAT
parameter set to 12.2
.
In addition, for the ORAPWD
utility, the restriction for the entries argument for the operating system password file has been removed.
Related Topics
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_function
password complexity function -
ora_stig_profile
user profile -
The following initialization parameters have changed to accommodate STIG requirements:
-
The default for
SEC_PROTOCOL_ERROR_FURTHER_ACTION
is now(DROP,3)
. -
The default for
SEC_MAX_FAILED_LOGIN_ATTEMPTS
is now3
. -
The default for
SQL92_SECURITY PARAMETER
is nowTRUE
.
-
See Also:
-
Oracle Database Reference for more information about initialization parameters
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_SERVER
parameter is now12
(Exclusive Mode) instead of11
. A setting of12
generates both11G
and12C
password versions. If you want to restrict the generation to the12C
password version, which increases security for the passwords, then you can setSQLNET.ALLOWED_LOGON_VERSION_SERVER
to12a
.Be aware that you should check the versions of the clients that connect to the server to ensure that these clients use the
O5L_NP
ability. All Oracle Database release 11.2.0.3 and later clients have theO5L_NP
ability. If you have an earlier Oracle Database client, then you must install the CPUOct2012 patch. -
The
12C
password version is now generated automatically. In previous releases, the10G
password version was generated automatically.
See Also:
-
Ensuring Against Password Security Threats by Using the 12C Password Version
-
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.
The 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.
Related Topics
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
OUTBOUND_DBLINK_PROTOCOLS
initialization parameter. -
Controlling the ability of users to use LDAP to access data through global database links: You can set the
ALLOW_GLOBAL_DBLINKS
initialization parameter.
For more information, see Network Connection Security.
Ability to Control Definer's Rights Privileges for Database Links
The 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.
Related Topics
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.
Related Topics
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 EXTPROC
process.
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 okinit
, oklist
, and 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.
Related Topics
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:
-
The
AUDIT
andNOAUDIT
statements now have a new clause,BY USERS WITH GRANTED ROLES
. -
The
AUDIT_UNIFIED_ENABLED_POLICIES
andDBA_XS_ENB_AUDIT_POLICIES
data dictionary views have the following new columns:-
ENTITY_NAME
captures the user name or role name. -
ENTITY_TYPE
indicates if the entity name is aUSER
or aROLE
. -
ENABLED_OPTION
displaysBY
andEXCEPT
for policies that are enabled on users, but displaysINVALID
for policies that are enabled on roles.
-
-
The possible output for the
AUDIT_UNIFIED_ENABLED_POLICIES.ENABLED_OPTION
column is nowBY USER
,EXCEPT USER
,BY GRANTED ROLE
, andINVALID
.
See Also:
-
Enabling and Applying Unified Audit Policies to Users and Roles
-
Oracle Database Reference for information about the
AUDIT_UNIFIED_ENABLED_POLICIES
andDBA_XS_ENB_AUDIT_POLICIES
data dictionary views
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_PRIVILEGE
audits use of theGRANT_SYSTEM_PRIVILEGE
privilege. -
AUDIT_REVOKE_PRIVILEGE
audits use of theREVOKE_SYSTEM_PRIVILEGE
privilege.
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, RLS_INFO
:
-
UNIFIED_AUDIT_TRAIL
-
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, DBMS_AUDIT_UTIL
.
See Also:
-
Fine-Grained Auditing on Tables or Views That Have Oracle VPD Policies
-
Oracle Database Reference for information about the
UNIFIED_AUDIT_TRAIL
,DBA_AUDIT_TRAIL
,V$XML_AUDIT_TRAIL
, andDBA_FGA_AUDIT_TRAIL
data dictionary views -
Oracle Database PL/SQL Packages and Types Reference for more information about the
DBMS_AUDIT_UTIL
PL/SQL package
Enhancements for the AUDSYS Audit Schema
The 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 AUDSYS
schema.
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.
See Also:
-
What Is Auditing? for more information about the
AUDSYS
schema -
Oracle Database Upgrade Guide for information about transferring unified audit records
Deprecated Features
The following features have been deprecated for this release:
Deprecated Columns from the AUDIT_UNIFIED_ENABLED_POLICIES and DBA_XS_ENB_AUDIT_POLICIES Views
The USER_NAME
and ENABLED_OPT
columns of the AUDIT_UNIFIED_ENABLED_POLICIES
and 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 NULL
.
The ENABLED_OPT
column displays BY
and EXCEPT
for policies that are enabled on users, but displays INVALID
for policies that are enabled on roles. This column is replaced by the ENABLED_OPTION
column.
Deprecation of the sqlnet.ora KERBEROS5_CONF_MIT Parameter
The sqlnet.ora
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 okinit
, oklist
, and 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 KERBEROS5_CONF_MIT
to TRUE
so that you can take advantage of the new Kerberos functionality.
Related Topics
Deprecated Password Verification Functions
The VERIFY_FUNCTION
and 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_VERIFY_FUNCTION
and 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
The 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.
Related Topics
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 DBMS_AUDIT_MGMT
procedures:
-
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL
-
DBMS_AUDIT_MGMT.CLEAR_LAST_ARCHIVE_TIMESTAMP
-
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP
See Also:
-
Oracle Database PL/SQL Packages and Types Reference for more information about the
DBMS_AUDIT_MGMT
PL/SQL package
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:
-
DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL
procedure -
AUDIT_TRAIL_WRITE
mode of theAUDIT_TRAIL_PROPERTY
parameter of theDBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY
procedure
Related Topics