1. Learning Database New Features
  2. Security Solutions

7 Security Solutions

Advanced Security

Parent topic: Security Solutions

Ability to Control Heartbeats in United Mode and Isolated Mode PDBs

You now can control the size of the batch of heartbeats that use Oracle Key Vault or OCI KMS (OCI Vault) for centralized key management.

The HEARTBEAT_BATCH_SIZE initialization parameter, new with this release, enables you to set the heartbeat batch size. The duration of the heartbeat period defaults to 3 seconds.

This enhancement benefits the situation where you have a very large deployment of PDBs (for example, 1000) that use Oracle Key Vault. By setting the heartbeat batch size, you can stagger the heartbeats across batches of PDBs to ensure that for each batch a heartbeat can be completed for each PDB within the batch during the heartbeat period, and also ensure that PDB keys can be reliably fetched from an Oracle Key Vault server and cached in the persistent state.

Related Topics

Parent topic: Advanced Security

Ability to Set the Default Tablespace Encryption Algorithm

You now can set the TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM dynamic parameter to define the default encryption algorithm for tablespace creation operations.

For example, if you set TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM to AES256, then future tablespace creation operations will use AES256 as the default encryption algorithm. TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM applies to both offline and online tablespace encryption operations. In addition, when you create a new tablespace using Database Configuration Assistant (DBCA), you can set the default tablespace encryption algorithm by using the DBCA command line for silent installations.

Supported encryption algorithms are AES128, AES192, AES256, 3DES168, ARIA128, ARIA192, ARIA256, SEED128, and GOST256. If you do not set TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM, then the default encryption algorithm is the default that was used in previous releases: AES128.

Related Topics

Parent topic: Advanced Security

Enhanced Database Availability with Zero Downtime to Switch Over to an Updated PKCS#11 Library

Starting with this release, Oracle Database can switch over to an updated PKCS#11 library without incurring any system downtime.

This release introduces a new ADMINISTER KEY MANAGEMENT SWITCHOVER LIBRARY FOR ALL CONTAINERS statement, which will enable an Oracle database to switch over from the PKCS#11 library that it is currently using to the updated PKCS#11 library.

In previous releases, it was necessary to completely shut down any TDE-enabled database that used an online TDE master encryption key in Oracle Key Vault before an update to the Oracle Key Vault endpoint software could be installed. After the updated PKCS#11 library was installed, the TDE-enabled database would need to be started up again. This complete shut down followed by a start up of the database instance was necessary because long-running background processes of the database instance could not be told to unload the earlier PKCS#11 library and load the updated one.

Starting with this release, to switch over the database server to use an updated endpoint shared PKCS#11 library, you execute the following statement to initiate the switch over operation:
ADMINISTER KEY MANAGEMENT SWITCHOVER TO LIBRARY 'fully_qualified_file_name_of_library' FOR ALL CONTAINERS;

Related Topics

Parent topic: Advanced Security

Improved Performance with Large Numbers of TDE Keys in Wallets or Oracle Key Vault

Oracle Database 21c introduces improved performance for Transparent Data Encryption (TDE).

This enhancement enables faster wallet loading and key rotations in multitenant databases. It allows for faster execution of TDE administration tasks and PDB cloning operations.

Parent topic: Advanced Security

Sharing of TDE Master Encryption Key Across Oracle Processes

Starting with this release, you can enable sharing of Transparent Data Encryption (TDE) master encryption keys across Oracle processes.

This enhancement allows TDE-enabled Oracle databases to have their TDE master encryption keys managed by the Oracle Cloud Infrastructure (OCI) key management service (KMS). To control this functionality, you set the TDE_KEY_CACHE initialization parameter.

Related Topics

Parent topic: Advanced Security

Database Vault

Parent topic: Security Solutions

Ability to Prevent Local Oracle Database Vault Policies from Blocking Common Operations

Starting with this release, a DV_OWNER common user in the CDB root can prevent local users from creating Oracle Database Vault controls on common objects in a pluggable database (PDB).

Blocking common users from common operations can prevent the execution of SQL commands that are necessary for managing the application or CDB database. To prevent this situation, a user who has the DV_OWNER role in the root can execute the DBMS_MACADM.ALLOW_COMMON_OPERATION procedure to control whether local PDB users can create Database Vault controls on common users' objects (database or application).

In previous releases, in a multitenant environment, a local Oracle Database Vault user could create Database Vault policies that could potentially block application or common operations. Blocking common users from common operations can prevent the execution of SQL commands that are necessary for managing the application or CDB database. To prevent this situation, a user who has the DV_OWNER role in the root can execute the DBMS_MACADM.ALLOW_COMMON_OPERATION procedure to control whether local PDB users can create Database Vault controls on common users' objects (database or application).

Related Topics

Parent topic: Database Vault

ADMINISTER KEY MANAGEMENT Statement Now Protected by Oracle Database Vault Command Rules

You now can protect the ADMINISTER KEY MANAGEMENT statement with Oracle Database Vault command rules.

The ADMINISTER KEY MANAGEMENT statement manages Transparent Data Encryption (TDE) features.

Related Topics

Parent topic: Database Vault

DBA_DV_SIMULATION_LOG View Columns REALM_NAME and RULE_SET_NAME Now VARCHAR2 Data Type

Starting with this release, the REALM_NAME and RULE_SET_NAME columns will use the VARCHAR2 data type instead of being in nested tables.

This enhancement enables multiple realm names and rule set names to be separated by a comma in a VARCHAR2 data type instead of using a nested table in the columns. In the unlikely situation where you may have so many realms or rule set names protecting a single object in which the VARCHAR2 data exceeds 4000 characters, Oracle Database Vault will truncate the list of realms or rule sets at 4000 characters in the column and if the full set is needed, it can be retrieved from the nested table in the DVSYS.SIMULATION_LOG$ base table.

Storing realm names and rule set names as a VARCHAR2 data type makes it easier for you to read the realm name or rule set name in the simulation log. Most users only use a single realm or rule set to protect their sensitive data objects and even if they do use multiple realms or rule sets, it is easier to read data in a VARCHAR2 data type rather than a nested table.

Related Topics

Parent topic: Database Vault

No Need to Disable Oracle Database Vault Before Upgrades

Starting with this release, you do not need to disable Oracle Database Vault in every container before upgrading from an earlier release to the current release.

You only need to grant the DV_PATCH_ADMIN role to SYS commonly before you perform the upgrade. After the upgrade is complete the Database Vault controls work as before. Then revoke the DV_PATCH_ADMIN role from SYS commonly.

Alternatively, you can explicitly disable Oracle Database Vault in all containers before the upgrade, and then after the upgrade, explicitly enable Oracle Database Vault in all the containers.

Related Topics

Parent topic: Database Vault

Uninstalling and Installing Oracle Label Security and Oracle Database Vault Now Supported

You now can install and uninstall Oracle Database Vault and Oracle Label Security in PDBs.

To install a feature into a PDB requires that the feature already be installed in the CDB root.

This enhancement enables you to configure your own databases with Oracle Label Security and Oracle Database Vault to meet your site's requirements.

Related Topics

Parent topic: Database Vault

Security

Parent topic: Security Solutions

Oracle Blockchain Table

Blockchain tables are append-only tables in which only insert operations are allowed. Deleting rows is either prohibited or restricted based on time. Rows in a blockchain table are made tamper-resistant by special sequencing and chaining algorithms. Users can verify that rows have not been tampered. A hash value that is part of the row metadata is used to chain and validate rows.

Blockchain tables can be used to implement blockchain applications where the participants trust the Oracle Database provider, but want means to verify that their data hasn’t been tampered with. The participants are different database users who trust the Oracle Database provider to maintain a verifiable, tamper-resistant blockchain of transactions. All participants must have privileges to insert data into the blockchain table. The contents of the blockchain table are defined and managed by the application, with a few added metadata fields maintained by Oracle Database. By leveraging a trusted provider with verifiable crypto-secure data management practices, such applications can avoid the distributed consensus requirements. This provides most of the protection of the distributed peer-to-peer blockchains, but with much higher throughput and lower transaction latency compared to peer-to-peer blockchains using distributed consensus.

Related Topics

Parent topic: Security

Immutable Tables

Immutable tables are insert-only tables in which existing data cannot be modified. Deleting rows is either prohibited or restricted based on the insertion time of the rows.

Immutable tables protect data against unauthorized modification by insiders. This includes database administrators or compromised users who have access to insider credentials. Immutable tables also prevent accidental data modification that may be caused by human error.

Related Topics

Parent topic: Security

Authentication and Authorization

Parent topic: Security

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

You now can specify the location of the 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.

Related Topics

Ability to Use Multiple Kerberos Principals with a Single Database Client

Starting with this release, when you configure Kerberos authentication for an Oracle Database client, you can specify multiple Kerberos principals with a single Oracle Database client.

To enable this functionality, you will need to create a separate credential cache for each user in the client and then use the connect string to specify the user.

In previous releases, you were restricted to one Kerberos principal for each Oracle Database client.

Related Topics

Addition of USER_APPLICATION_ROLES Data Dictionary View

Starting with this release, the USER_APPLICATION_ROLES data dictionary view provides 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

Connect to Multiple Databases with Different Certificates from a Single Client

Starting with this release, you can configure database clients to maintain multiple Secure Sockets Layer (SSL) sessions using different SSL certificates.

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

This enhancement is especially useful for database clients simultaneously connecting to multiple cloud databases, each with a different certificate.

Related Topics

Enterprise User Manager Support for Per-PDB Directory Service Connections

Enterprise User Security (EUS) is now able to connect a different directory service for each pluggable database (PDB). Previously in a multitenant database, all the containers connected to a single directory service.

This feature enables a large Oracle Database deployment to have different directory services. It also enables independent software vendors to allocate an individual PDB to connect to the appropriate customer's directory service.

Related Topics

Force Upgraded Password File to be Case Sensitive

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.

Related Topics

Gradual Database Password Rollover for Applications

Starting with this release, an application can change its database passwords without an administrator having to schedule downtime.

To accomplish this, a database administrator can associate a profile having a non-zero limit for the PASSWORD_ROLLOVER_TIME password profile parameter, new with this release, with an application schema. This allows the database password of the application user to be altered while allowing the older password to remain valid for the time specified by the PASSWORD_ROLLOVER_TIME limit. During the rollover period of time, the application instance can use either the old password or the new password to connect to the database server. When the rollover time expires, only the new password is allowed.

Before this enhancement, an administrator normally took the application down when the application database password was being rotated. This is because the password update requires changes on both the database and the application side. With the gradual database password rollover enhancement, the application can continue to use the older password until the new password is configured in the application.

In addition to the new clause PASSWORD_ROLLOVER_TIME in the CREATE PROFILE and ALTER PROFILE statements, the ALTER USER statement has a new clause, EXPIRE PASSWORD ROLLOVER PERIOD. The ACCOUNT_STATUS column of the DBA_USERS and USER_USERS data dictionary views have several new statuses indicating values to indicate rollover status.

Related Topics

Minimum Password Length Enforcement for All PDBs

Starting with this release, you can enforce a minimum password length on all PDBs by setting a mandatory profile in the CDB root.

The mandatory profile is a generic profile and can only have the PASSWORD_VERIFY_FUNCTION parameter in the CREATE MANDATORY PROFILE statement to define the password length.

This profile adds a minimum password length to the local profiles with which the PDB user is associated. Because a common user sets the mandatory profile in the CDB, a PDB administrator cannot remove the password length requirement from local profiles and allow users to set insecure short passwords.

To use this profile, you create a password verification function to define the password length, execute the CREATE MANDATORY PROFILE PL/SQL procedure to use the PASSWORD_VERIFY_FUNCTION function in a profile, and then set the MANDATORY_USER_PROFILE initialization parameter in the CDB root to apply it to all containers.

Related Topics

New and Updated Password User Profiles for STIG and CIS

This release introduces a new user profile and an updated user profile to comply with STIG and CIS standards for password management.

The ora_stig_profile user profile has been updated with the latest Security Technical Implementation Guide's (STIG) guidelines, and the ora_cis_profile, new for this release, has the latest Center for Internet Security (CIS) guidelines for passwords. You can use these user profiles directly with their database users or use them as part of your own user profiles. Oracle keeps these profiles up to date to make it easier for you to implement password policies that meet STIG and CIS guidelines.

Related Topics

Oracle Database Connections to Kerberos Servers Now Default to TCP

In previous releases, Oracle Database connections to Kerberos servers defaulted to start with User Datagram Protocol (UDP).

If you prefer the Oracle Database connections to start with UDP connections, then you can modify the Kerberos krb5.conf configuration file to start the connections using UDP.

This enhancement speeds the authentication process for environments that have many Kerberos Key Distribution Center (KDC) servers.

Related Topics

Windows Authentication No Longer Uses NTLM by Default

For Microsoft Windows installations with AUTHENTICATION_SERVICES=NTS, starting with this release, the SQLNET.NO_NTLM parameter setting in the sqlnet.ora file will default to TRUE.

In previous releases, the default for this parameter was FALSE. SQLNET.NO_NTLM controls whether NTLM can be used with NTS authentication. A TRUE setting means that NTLM cannot be used in NTS authentication. Because NTLM does not normally provide mutual authentication and is hence less secure, a TRUE setting for SQLNET.NO_NTLM makes the database and client more secure.

The SQLNET.NO_NTLM parameter is used on both the server and the client. If you have upgraded a Microsoft Windows installation of an Oracle database or a client in which SQLNET.NO_NTLM had not been set, then its default will be TRUE.

Related Topics

Encryption

Parent topic: Security

Updated Support for Micro Edition Suite (MES) for FIPS 140.2

Starting with this release, Oracle Database supports Micro Edition Suite (MES) version 4.5 for FIPS 140.2.

The Micro Edition Suite (MES) version 4.5 updates include four new CVEs in the RSA BSAFE MES library, support for the rules that FIPS 140.2 requires, and access to the updated NZ/ZT library from the Crypto Foundation.

This enhancement enables the Oracle Database FIPS 140.2 configuration to benefit from new features and security improvements available from the latest RSA BSAFE MES library.

Related Topics

Parent topic: Encryption

Support for DBMS_CRYPTO Asymmetric Key Operations

Starting with this release, the DBMS_CRYPTO PL/SQL package supports asymmetric key operations, in addition to the existing support for symmetric key operations.

To implement the support for asymmetric key operations, the following procedures have been added to the DBMS_CRYPTO package:

  • PKENCRYPT
  • PKDECRYPT
  • SIGN
  • VERIFY

Related Topics

Parent topic: Encryption

Audit

Parent topic: Security

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 WebDAV operations that use 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.

Related Topics

Parent topic: Audit

Predefined Unified Audit Policies for Security Technical Implementation Guide (STIG) Compliance

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

These policies are as follows:

  • ORA_STIG_RECOMMENDATIONS
  • ORA_ALL_TOPLEVEL_ACTIONS
  • ORA_LOGON_LOGOFF

Related Topics

Parent topic: Audit

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.

Related Topics

Parent topic: Audit

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 are not limited to the following:

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

Related Topics

Parent topic: Audit

Unified Audit Policy Configuration Changes Effective Immediately

Starting with this release, changes made to a unified audit policy 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.

Related Topics

Parent topic: Audit

Unified Auditing on an Editioned Object Now Applies to All Its Editions

Unified audit policies, if configured for auditing actions on an editioned object, apply to all editions of the object.

This support enables consistent audit policy definition and enforcement in all object editions, whether they are existing or new. Applications which rely on edition-based redefinition can take advantage of the availability of the audit policies to audit all editioned objects in a consistent manner.

Related Topics

Parent topic: Audit