Changes in This Release for Oracle Database Advanced Security Guide

This preface contains:

• Changes in Oracle Database Advanced Security 12c Release 2 (12.2.0.1)
  

Changes in Oracle Database Advanced Security 12c Release 2 (12.2.0.1)

The following are changes in Oracle Database Advanced Security Guide for Oracle Database 12c release 2 (12.2.0.1).

• New Features
  

New Features

The following features are new to this release:

• Ability to Encrypt Existing Tablespaces and Fully Encrypt Databases
  Starting with this release, you can encrypt existing tablespaces and fully encrypt databases.
• Additional Supported Encryption Algorithms
  You now can use the ARIA, GOST, and SEED encryption algorithms for column and tablespace encryption, in addition to the AES and DES encryption standards.
• Ability to Force Software Keystore Operations
  You now can force a keystore operation that is prevented because of an in-use auto-login keystore or a closed software or an external keystore.
• Ability to Use an External Store for Software Keystore Passwords
  You can now configure the database to use an external keystore to hide the password to a TDE software keystore or an external keystore from the SQL*Plus command line.
• New Way to Specify Oracle Key Vault as a Keystore
  As an alternative to third-party hardware security modules, you now can specify Oracle Key Vault as a keystore.
• Ability to Redact Data Based on Different Runtime Conditions
  You now can define and associate different Data Redaction policy expressions with different columns within the same table or view.
• Ability to Centrally Manage Data Redaction Policy Expressions within a Database
  This new feature applies to named Oracle Data Redaction policy expressions.
• Ability to Use NULL as the Redacted Value
  Starting with this release, the redacted value can be NULL.
• Enhanced Support for Redacting Unstructured Data
  You now can define regular expression-based redaction (DBMS_REDACT.REGEXP) policies on columns of the CLOB and NCLOB data types.

Ability to Encrypt Existing Tablespaces and Fully Encrypt Databases

Starting with this release, you can encrypt existing tablespaces and fully encrypt databases.

In previous releases, you could only encrypt new application tablespaces. However, this new feature enables you to encrypt existing application tablespaces in an offline or online method. To encrypt a database, you encrypt the Oracle-supplied tablespaces, such as SYSTEM and SYSAUX with the online method. Offline tablespace encryption can be used for tablespaces in Oracle Database 11g release 2 (11.2.0.4) and Oracle Database 12g release 1 (12.1.0.2). You can perform encryption and decryption operations in parallel and perform the encryption in an Oracle Data Guard environment to minimize the application downtime to the time it takes to perform a Data Guard switchover. You can configure all future tablespaces to be automatically encrypted, which is beneficial for an Oracle Cloud environment.

Additional Supported Encryption Algorithms

You now can use the ARIA, GOST, and SEED encryption algorithms for column and tablespace encryption, in addition to the AES and DES encryption standards.

The main benefit of these new encryption standards is that they meet the national standards for their respective countries.

• ARIA uses the same block sizes as AES. It is designed for lightweight environments and the implementation in hardware. ARIA meets the standards used in Korea.

• GOST is very similar to DES except that it has a large number of rounds and secret S-boxes. GOST meets the standards used in Russia.

• SEED is used by several standard protocols: S/MIME, TLS/SSL, IPSec, and ISO/IEC. SEED meets the standards used in Korea.

Ability to Force Software Keystore Operations

You now can force a keystore operation that is prevented because of an in-use auto-login keystore or a closed software or an external keystore.

In previous releases, for many keystore operations, you had to manually open the software or external keystore before performing the operation. In this release, you can perform these two actions in one ADMINISTER KEY MANAGEMENT statement execution by including the FORCE KEYSTORE clause.

The operations that you can use the FORCE KEYSTORE clause on are as follows: changing a keystore password; creating, using, rekeying, tagging, importing, exporting, migrating, or reverse migrating encryption keys; opening or backing up keystores; adding, updating, or deleting secret keystores.

Ability to Use an External Store for Software Keystore Passwords

You can now configure the database to use an external keystore to hide the password to a TDE software keystore or an external keystore from the SQL*Plus command line.

This feature enables you to hide the keystore password from the SQL*Plus command line. That increases separation of duties between database administrators and keystore administrators. To use this functionality, you first create an auto-login wallet in an existing directory with this new syntax: ADMINISTER KEY MANAGEMENT ADD SECRET 'Oracle_Key_Vault_password' FOR CLIENT 'OKV_PASSWORD' TO [LOCAL] AUTO_LOGIN KEYSTORE '/existing/directory'. Then you set the EXTERNAL_KEYSTORE_CREDENTIAL_LOCATION initialization parameter to the directory in which the auto-login wallet was created. Afterward, you can you can replace the password in the ADMINISTER KEY MANAGEMENT .... IDENTIFIED BY password statement with EXTERNAL STORE for the following operations: opening, closing, backing up the keystore; adding, updating, or deleting a secret; creating, using, rekeying, tagging, importing, exporting encryption keys.

New Way to Specify Oracle Key Vault as a Keystore

As an alternative to third-party hardware security modules, you now can specify Oracle Key Vault as a keystore.

To configure Oracle Key Vault as a keystore, you can edit the sqlnet.ora file METHOD setting in the ENCRYPTION_WALLET_LOCATION parameter to point to OKV.

Ability to Redact Data Based on Different Runtime Conditions

You now can define and associate different Data Redaction policy expressions with different columns within the same table or view.

This feature provides greater flexibility for anyone who creates Data Redaction policies.

For example, this feature enables you to share a single Data Redaction policy expression with multiple Data Redaction policies.

When you create the policy expression, you can apply it to any table or view column that is included in an existing Data Redaction policy. If you change the policy expression, the change is reflected in all Data Redaction policies that redact the associated table or view columns.

Ability to Centrally Manage Data Redaction Policy Expressions within a Database

This new feature applies to named Oracle Data Redaction policy expressions.

This feature facilitates the maintenance and administration of policy expressions. When you modify the named policy expression, the changes are automatically applied to all tables and views in the database that use the expression.

Ability to Use NULL as the Redacted Value

Starting with this release, the redacted value can be NULL.

For example, you can use this feature to hide data.

When you define an Oracle Data Redaction policy, you can set the function_type parameter to DBMS_REDACT.NULLIFY to ensure that the redacted value to always be NULL.

Enhanced Support for Redacting Unstructured Data

You now can define regular expression-based redaction (DBMS_REDACT.REGEXP) policies on columns of the CLOB and NCLOB data types.