Changes in This Release for Oracle Database Advanced Security Guide
This preface contains:
Changes in Oracle Database Advanced Security 18c
The following are changes in Oracle Database Advanced Security Guide for Oracle Database 18c.
- Ability to Create a Keystore for Each Pluggable Database
Each pluggable database (PDB) can now have its own keystore instead of there only being one keystore for the entire container database (CDB). - Ability to Create a User-Defined Master Encryption Key
This release introduces the ability to create a user-defined master encryption key, also known as “bring your own key.” - Ability to Use Encrypted Passwords for Database Links with Oracle Data Pump
The behavior for handling database link passwords has changed in this release.
Ability to Create a Keystore for Each Pluggable Database
Each pluggable database (PDB) can now have its own keystore instead of there only being one keystore for the entire container database (CDB).
In previous releases, PDBs shared the keystore with the entire container database (CDB), which included the CDB root and all the PDBs. This keystore stored the master encryption keys for the CDB as well as all the PDBs. In this release, a PDB can either continue to share the same keystore with the entire CDB as before, or have a separate keystore. This design offers greater isolation between PDBs, because each separate keystore can be administered independently. For instance, each keystore can be protected by a different password.
The additional advantage of this feature is that it enables independent key management operations to be performed by each tenant (PDB) in a multitenant environment rather than having to share a keystore at the CDB root level. This feature benefits both multitenant and non-multitenant environments because it provides parameters to facilitate the configuration of the keystore location and the keystore type, eliminating the need for editing the sqlnet.ora
file.
This feature provides the following new functionality:
-
For multitenant environments, the following two modes:
-
United mode, in which the keystores and master encryption keys are primarily managed from the CDB root, and can be accessed from the united mode PDB. Within the PDB, the keystore can be opened and closed just for that PDB. You also can create a PDB-specific master encryption key for this keystore.
-
Isolated mode, in which the keystore and encryption keys are managed in an individual PDB. This way, each PDB can configure its own keystore type independently, and create and manage this keystore after configuring it.
You can mix these two modes. For example, suppose you have 1 CDB and 10 PDBs. You can run 3 of these PDBs in united mode and the remaining 7 in isolated mode. This design offers the highest flexibility depending on your environment and site requirements.
To accommodate these modes, the
ADMINISTER KEY MANAGEMENT
SQL statement has been enhanced to behave differently in the two modes. -
-
For both non-multitenant and multitenant environments, the following new features:
-
Addition of the
WALLET_ROOT
static instance initialization parameter, to specify the keystore path. In this guide,WALLET_ROOT
refers to the configuration of software keystores, hardware keystores, and Oracle Key Vault keystores, but this parameter can be used to designate the wallet location for other products as well: Enterprise User Security, Secure Sockets Layer, Oracle XML DB, and Secure External Password Store. -
Addition of the
TDE_CONFIGURATION
dynamic instance initialization parameter, to specify the type of keystore to use. You can set this parameter for TDE software keystores, hardware security module keystores (HSMs), and Oracle Key Vault. -
Modification to the behavior of the
SQLNET.ENCRYPTION_WALLET_LOCATION
parameter. When theWALLET_ROOT
parameter has been set, thenWALLET_ROOT
overridesSQLNET.ENCRYPTION_WALLET_LOCATION
. IfWALLET_ROOT
has not been set, thenSQLNET.ENCRYPTION_WALLET_LOCATION
is the default.
-
This design offers greater isolation between PDBs. The additional advantage of this feature is that it enables independent key management operations to be performed by each tenant (PDB) in a multitenant environment rather than having to share a keystore at the CDB root level. This feature benefits both multitenant and non-multitenant environments because it provides parameters to facilitate the configuration of the keystore location and the keystore type, eliminating the need for editing the sqlnet.ora
file.
Ability to Create a User-Defined Master Encryption Key
This release introduces the ability to create a user-defined master encryption key, also known as “bring your own key.”
Instead of requiring that TDE master encryption keys always be generated in the database, Oracle Database now supports the use of master encryption keys that have been generated outside the database.
To create the user-defined key, you supply your own master key identification value when you create the master encryption key by using the ADMINISTER KEY MANAGEMENT SET [ENCRYPTION] KEY
or ADMINISTER KEY MANAGEMENT CREATE [ENCRYPTION] KEY
statements. This enhancement applies to master encryption keys that are used in software keystores only, not hardware keystores. It can be used in non-multitenant, standalone environments and in multitenant environments.
This feature particularly benefits Oracle Fusion Applications Software-as-a-Service deployments. You can create these keys in your own environment. If you want to insert a key that you trust for encryption but later on decide that you must replace the key, then you can insert another key without the intervention of the Cloud provider.
To complement this feature, you can configure the automatic removal of inactive master encryption keys from an Oracle Data Guard standby database.
Ability to Use Encrypted Passwords for Database Links with Oracle Data Pump
The behavior for handling database link passwords has changed in this release.
Passwords in database links are now encrypted. Oracle Data Pump handles the export and import of these passwords. Import operations from older versions and export operations to older versions can still be used.
The benefit of this feature is that it prevents an intruder from decrypting an encrypted database link password.
Related Topics
Changes in Oracle Database Advanced Security 12c Release 2 (12.2)
The following are changes in Oracle Database Advanced Security Guide for Oracle Database 12c release 2 (12.2).
- 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, and 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 hardware keystore. - Ability to Use an External Store for Software Keystore Passwords
You now can configure a software or a hardware keystore to use an external store for its password. - 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 beNULL
. - Enhanced Support for Redacting Unstructured Data
You now can define regular expression-based redaction (DBMS_REDACT.REGEXP
) policies on columns of theCLOB
andNCLOB
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 tablespaces. However, this new feature enables you to encrypt both offline and online tablespaces. To encrypt a database, you encrypt the Oracle-supplied tablespaces, such as SYSTEM
and SYSAUX
. Offline tablespace conversion can be used for tablespaces in Oracle Database 11g release 1 (11.1) and Oracle Database 12g release 1 (12.1). You can perform encryption conversion operations in parallel and perform the encryption in an Oracle Data Guard environment. You can configure all future tablespaces to be automatically encrypted, which is beneficial for an Oracle Cloud environment.
Related Topics
Additional Supported Encryption Algorithms
You now can use the ARIA, GOST, and SEED encryption algorithms for column and tablespace encryption, and 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 of 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.
Related Topics
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 hardware keystore.
In previous releases, for many keystore operations, you had to manually open the software 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.
Related Topics
Ability to Use an External Store for Software Keystore Passwords
You now can configure a software or a hardware keystore to use an external store for its password.
This feature enables you to store the password in a separate location where it can be centrally managed and accessed. To use this functionality, you must first set the EXTERNAL_KEYSTORE_CREDENTIAL_LOCATION
initialization parameter to a location where the external keystore credential will be stored. Afterward, you can include the EXTERNAL STORE
setting in the IDENTIFIED BY
clause when you run the ADMINISTER KEY MANAGEMENT
statement for the following operations: opening, closing, backing up the keystore; adding, updating, or deleting a secret keystore; creating, using, rekeying, tagging, importing, exporting encryption keys.
Related Topics
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 WALLET_LOCATION
parameter to point to OKV
.
Related Topics
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.
Related Topics
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.
Related Topics
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
.
Related Topics