1. Administrator's Guide
  2. Using Oracle Key Vault with Other Features

19 Using Oracle Key Vault with Other Features

You can use Oracle Key Vault with other Oracle features and products, such as Oracle GoldenGate or Oracle Data Guard.

19.1 Using a TDE-Configured Oracle Database in an Oracle RAC Environment

Each Oracle RAC database has its own Oracle virtual wallet in Oracle Key Vault.

In an Oracle Real Application Clusters (Oracle RAC) environment, each Oracle RAC instance has its own endpoint in Oracle Key Vault; these endpoints share the same virtual wallet in Oracle Key Vault as their default wallet.

You can enable the cluster to share the virtual wallet by using either of the following approaches:

  • If the Oracle RAC database is using TDE with individual wallets, then confirm that these wallets have the identical content. Execute the mkstore -wrl /directory/to/TDE-wallet -list command to compare the content of each wallet. If they all contain the same keys, then upload the content of one of them into the shared virtual wallet in Oracle Key Vault.
  • If the Oracle RAC database is using TDE with a shared wallet (which is the recommended deployment), then upload that wallet to Oracle Key Vault.
  • Establish an auto-open connection with Oracle Key Vault.
  • Migrate the Oracle RAC database to Oracle Key Vault.

As with single-instance database environments, after you download a password-protected wallet, you must manually open it. If you have one wallet on the primary node and then download the wallet to the other nodes, then you must explicitly open the wallets on each of these nodes.

Each Oracle RAC node is a different endpoint of the database and has its own individual persistent cache. For Oracle RAC databases, you should initiate a query from each Oracle RAC node to cache the latest master encryption key in the Oracle RAC node for uninterrupted operations

Related Topics

Parent topic: Using Oracle Key Vault with Other Features

19.2 Using a TDE-Configured Oracle Database in an Oracle GoldenGate Environment

Oracle Key Vault supports the use of Oracle wallets with Oracle GoldenGate shared secrets.

You can upload or migrate Oracle wallets that contain Oracle GoldenGate shared secrets and TDE master encryption keys to the Oracle Key Vault server.

Parent topic: Using Oracle Key Vault with Other Features

19.2.1 Oracle Wallets in an Oracle GoldenGate Environment

An Oracle GoldenGate shared secret can be in the same Oracle wallet where master encryption keys are stored.

In an environment where Oracle Key Vault is not used and an Oracle TDE-enabled database is configured with an Oracle wallet with Oracle GoldenGate, this database (called the source database) stores an Oracle GoldenGate shared secret in the same Oracle wallet where master encryption keys are stored.

This means that when you configure the source database as an Oracle Key Vault endpoint, the Oracle GoldenGate shared secret is stored in Oracle Key Vault in the same virtual wallet where the master encryption keys are stored for the TDE-enabled source database.

When you migrate an Oracle wallet that contains an Oracle GoldenGate shared secret and TDE master encryption keys to Oracle Key Vault using the okvutil command-line utility, the default wallet for the TDE-enabled source database now stores the entire Oracle wallet migrated with shared secret and master encryption keys.

In addition, if the configured target database is an Oracle database, then you must ensure that this target database is TDE-enabled so that all the TDE commands can be replicated. The two Oracle TDE-enabled databases, source and target, do not need to have the same master encryption key in the Oracle wallet. If you configure this target database as a new Oracle Key Vault endpoint, then you can upload and download wallets to and from Oracle Key Vault as you normally would with any independent Oracle Key Vault endpoint. No additional configuration is necessary.

Parent topic: Using a TDE-Configured Oracle Database in an Oracle GoldenGate Environment

19.2.2 Online Master Keys in an Oracle GoldenGate Deployment

There are two configuration steps to using the oline master key in an Oracle GoldenGate deployment.

  1. Configure a connection between the source database in the GoldenGate deployment and Oracle Key Vault.
  2. Configure the storage of Oracle GoldenGate secrets in the Oracle wallet on the source database.

At this stage, the configuration is complete. If you have configured the sqlnet.ora file correctly and completed the other configuration steps required for TDE on the source database, then when you set the encryption key (using either ALTER SYSTEM SET ENCRYPTION KEY or ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY), a TDE master encryption key is created in Oracle Key Vault. You can encrypt tables or create encrypted tablespaces in the database. The encrypted data created in the source database continues to be replicated on the target database after you perform this procedure. The other Oracle GoldenGate shared secrets are stored in Oracle Key Vault.

See Also:

Parent topic: Using a TDE-Configured Oracle Database in an Oracle GoldenGate Environment

19.2.3 Migration of TDE Wallets in Oracle GoldenGate to Oracle Key Vault

Oracle wallets can contain both a TDE master encryption key and an Oracle GoldenGate shared secret.

In an Oracle GoldenGate environment with a TDE-configured database, an Oracle wallet contains both the TDE master encryption keys and the Oracle GoldenGate shared secret.

You can also configure target Oracle TDE-enabled databases that are used in this Oracle GoldenGate environment to use Oracle Key Vault or continue to use an Oracle wallet. You should treat these databases as you would any standalone TDE database endpoint.

After you complete this migration, the configuration is complete. If you have configured the sqlnet.ora file correctly and completed the other configuration required for TDE, then when you set the encryption key (using either ALTER SYSTEM SET ENCRYPTION KEY or ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY), a TDE master encryption key is created in Oracle Key Vault. You can continue to create and use encrypted tables or tablespaces in the database. The encrypted data created in the source database continues to be replicated on the target database after this procedure is performed.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle GoldenGate Environment

19.3 Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

You can perform the activities such as upoading Oracle wallets or using online master keys in an Oracle Data Guard environment.

Parent topic: Using Oracle Key Vault with Other Features

19.3.1 About Uploading Oracle Wallets in an Oracle Data Guard Environment

The upload operation enables both a primary and standby to benefit from the use of Oracle wallets.

In an Oracle Data Guard environment with a TDE-enabled primary and standby databases using an Oracle wallet, you must physically copy the Oracle wallet file from the primary database to the standby and restart the managed recovery process after the initial TDE configuration and later, when you rekey the master encryption key on the primary database.

Whereas, when using Oracle Key Vault with a TDE-enabled Oracle Data Guard database, you must register the primary and standby databases in Oracle Key Vault as endpoints. You must ensure that the endpoints for the primary and all standby databases share the same virtual wallet.

This way, the primary and standby databases can benefit from centralized key management without the need of a manual copy of the wallet file from the primary database to the standby database.

In an Oracle Data Guard environment, for a persistent cache, a rekey operation on the primary database will cache the master encryption key in its own persistent cache. When the new redo logs from the primary are applied on the standby, only then will the standby fetch the new key from the Oracle Key Vault and cache it in the persistent cache of the standby. There is a time lag between the caching of the key in primary and the caching of the key in standby. Oracle recommends that you synchronize the primary and standby as soon as possible after the rekey operation. In addition, you should confirm the content of the persistent cache on the primary and standby databases with the following command: 

$ okvutil list -t okv_peristent_cache -l /path_to_persistent_cache/

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.2 Uploading Oracle Wallets in an Oracle Data Guard Environment

You can upload an Oracle wallet to an Oracle Data Guard environment.

  1. Register one endpoint each for the primary and standby databases.
  2. Download the okvclient.jar file for each endpoint on the respective databases.
  3. Ensure that the endpoint password is the same as the TDE wallet password if you must perform a migration or a reverse migration.
  4. Ensure that both the primary and standby database endpoints use the same default virtual wallet.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.3 Performing an Online Master Key Connection in an Oracle Data Guard Environment

The procedure for performing a TDE direct connection in an Oracle Data Guard environment is the same as in a standard Oracle Database environment.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.4 Migrating Oracle Wallets in an Oracle Data Guard Environment

You can migrate an Oracle wallet in an Oracle Data Guard environment by using okvutil and SQL*Plus.

  1. Use the okvutil upload command to upload the contents of the local Oracle wallet that is on the primary database to Oracle Key Vault.
  2. Perform the steps to migrate the wallet, as described in Migrating an Existing TDE Wallet to Oracle Key Vault.
  3. Close the existing Oracle wallet on the standby database.
    • For Oracle Database 11g release 2, as a user who has been granted the ALTER SYSTEM system privilege:
      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE 
IDENTIFIED BY "Key_Vault_endpoint_password";
    • For Oracle Database 12c or later, as a user who has been granted the SYSKM administrative privilege:
      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE 
IDENTIFIED BY "Key_Vault_endpoint_password";
  4. Shut down the standby database.

    For example:

    SHUTDOWN IMMEDIATE
  5. Restart the standby database.

    For example:

    STARTUP
  6. Open the Oracle wallet.
    • For Oracle Database 11g release 2, as a user who has been granted the ALTER SYSTEM system privilege: 
      ALTER SYSTEM SET ENCRYPTION WALLET OPEN 
IDENTIFIED BY "Key_Vault_endpoint_password";
    • For Oracle Database 12c or 18c, as a user who has been granted the SYSKM administrative privilege:
      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
IDENTIFIED BY "Key_Vault_endpoint_password";
  7. Start the apply process on the standby database, as described in Oracle Data Guard Concepts and Administration.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.5 Reverse Migrating Oracle Wallets in an Oracle Data Guard Environment

You can use okvutil and SQL*Plus to reverse migrate an Oracle wallet in an Oracle Data Guard environment.

  1. Use the okvutil download command to download the Oracle wallet keys onto the primary database from Oracle Key Vault. Download these keys to a local keystore.
  2. Perform a reverse migration, as described in Oracle Database Advanced Security Guide.
  3. Close the existing Oracle wallet on the standby database.
    • For Oracle Database 11g release 2: 
      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE 
IDENTIFIED BY "Key_Vault_endpoint_password";
    • For Oracle Database 12c or 18c:
      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE 
IDENTIFIED BY "Key_Vault_endpoint_password";
  4. Copy the Oracle wallet from the primary database to the standby database, as described in Oracle Database Advanced Security Guide.
  5. Open the Oracle wallet on the standby database.
    • For Oracle Database 11g release 2:
      ALTER SYSTEM SET ENCRYPTION WALLET OPEN 
IDENTIFIED BY "Key_Vault_endpoint_password";
    • For Oracle Database 12c or 18c: 
      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
IDENTIFIED BY "Key_Vault_endpoint_password";
  6. Start the apply process on the standby database, as described in Oracle Data Guard Concepts and Administration.

If the endpoint password and the local TDE wallet password are different, then use the auto-login HSM feature.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.6 Migrating an Oracle TDE Wallet to Oracle Key Vault for a Logical Standby Database

You can migrate a TDE wallet to Oracle Key Vault to a logical standby database using Oracle Database release 12c or 18c.

  1. Register the primary and standby endpoints to have the same default virtual wallet.
  2. If necessary, download and install the okvclient.jar file to each endpoint.
  3. Perform the migration on the primary database.
  4. Complete the SQL apply process on the logical standby and then restart the standby database, as described in Oracle Data Guard Concepts and Administration.
  5. To check that the status the that migration was successful, query the V$ENCRYPTION_WALLET dynamic view.

Related Topics

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.3.7 Checking the Oracle TDE Wallet Migration for a Logical Standby Database

You use SQL*Plus to check the migration.

In an Oracle Database Release 12c environment, after you have migrated an Oracle TDE wallet in a logical standby configuration, you can check the configuration.
  1. In the standby database instance, log in to SQL*Plus.
    For example:
    sqlplus / as sysdba
  2. Query the WRL_TYPE and WALLET_ORDER columns of the V$ENCRYPTION_WALLET dynamic view.

    The V$ENCRYPTION_WALLET view tracks the primary keystore. If you have only a single wallet configured, then the WALLET_ORDER column is set to SINGLE. In a two-wallet or mixed configuration, the column is set to PRIMARY or SECONDARY, depending on where the active master encryption key is located.

    For example, in the following, only a single wallet is configured:
    SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;

WRL_TYPE             WALLET_ORDER
-------------------- ------------
FILE                 SINGLE

    In this query in a logical standby configuration, the active master encryption key has been migrated to an Oracle Key Vault virtual wallet:

    SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;
 
WRL_TYPE             WALLET_ORDER
-------------------- ------------
FILE                 SECONDARY
HSM                  PRIMARY

    This query should show the HSM as the PRIMARY wallet in both the primary and standby database for the logical configuration.

Parent topic: Using a TDE-Configured Oracle Database in an Oracle Data Guard Environment

19.4 Uploading Keystores from Automatic Storage Management to Oracle Key Vault

You can copy a keystore from Automatic Storage Management (ASM) to Oracle Key Vault and vice versa in a two-step process.

Parent topic: Using Oracle Key Vault with Other Features

19.4.1 About Uploading Keystores from Automatic Storage Management to Oracle Key Vault

Uploading a keystore from Oracle Automatic Storage Management (ASM) to Oracle Key Vault is a two-step process.

  1. Copy the keystore from ASM to the file system.

  2. Upload the keystore from the file system to Oracle Key Vault.

Copying a keystore from ASM to the file system or vice versa requires the keystore merge operation that merges one software keystore to an existing key store. Therefore, in order to copy a keystore from a source path to a target path, a keystore must exist at the target path.

Parent topic: Uploading Keystores from Automatic Storage Management to Oracle Key Vault

19.4.2 Uploading a Keystore from Automatic Storage Management to Oracle Key Vault

You can use the ADMINISTER KEY MANAGEMENT statement to move a software keystore out of Automatic Storage Management (ASM).

  1. Initialize a target keystore on the file system with the following SQL statement:
    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE targetKeystorePath 
IDENTIFIED BY targetKeystorePassword;

    In this specification:

    • targetKeystorePath is the directory path to the target keystore on the file system.

    • targetKeystorePassword is a password that you create for the keystore.

    For example:

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' 
IDENTIFIED BY "destination_password";

    In this specification, /etc/ORACLE/KEYSTORE/DB1/ is the path to the target keystore in the file system and destination_password is the keystore password.

    You now can copy the keystore from ASM to the target keystore.
  2. Copy the keystore from ASM to the target keystore that you just created.

    This step requires that you merge the keystore from ASM to the file system as follows:

    ADMINISTER KEY MANAGEMENT MERGE KEYSTORE srcKeystorePath 
IDENTIFIED BY srcKeystorePassword 
INTO EXISTING KEYSTORE targetKeystorePath 
IDENTIFIED BY targetKeystorePassword 
WITH BACKUP USING backupIdentifier;

    In this specification:

    • srcKeystorePath is the directory path to the source keystore.

    • srcKeystorePassword is the source keystore password.

    • targetKeystorePath is the path to the target keystore.

    • targetKeystorePassword is the target keystore password.

    • backupIdentifier is the backup identifier to be added to the backup file name.

    For example:

    ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '+DATAFILE' IDENTIFIED BY "srcPassword" INTO EXISTING KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' IDENTIFIED BY "destination_password" WITH BACKUP USING "bkup";
    The keystore is copied to the file system and can now be uploaded to Oracle Key Vault.
  3. Upload keystore from file system to Oracle Key Vault by using the okvutil upload command.
    $ okvutil upload -l location -t type

    In this specification:

    • location is the path to the target keystore in the file system

    • type is wallet

    For example:

    $ okvutil upload -l /etc/ORACLE/KEYSTORE/DB1 -t wallet

Parent topic: Uploading Keystores from Automatic Storage Management to Oracle Key Vault

19.4.3 Copying a Keystore from Oracle Key Vault to Automatic Storage Management

You use both okvutil download and SQL*Plus to complete the copy process.

To copy a keystore from Oracle Key Vault to Automatic Storage Management (ASM), use the reverse procedure from copying the keystore from ASM to Oracle Key Vault.
  1. Initialize a target keystore on the file system, if the keystore does not exist.
    If the keystore does exist on the file system, then bypass this step.
  2. Copy the keystore from Oracle Key Vault to the target keystore on the file system using the okvutil download command.
    $ okvutil download -l location -t type

    In this specifcation:

    • location is the path to the target keystore in the file system

    • type is wallet

    For example:

    $ okvutil download -l /etc/ORACLE/KEYSTORE/DB1 -t wallet
  3. Initialize a keystore on the ASM instance by using the following SQL statement:
    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE asmKeystorePath 
IDENTIFIED BY asmKeystorePassword;

    In this specification:

    • asmKeystorePath is the directory path for the keystore on the ASM file system.
    • asmKeystorePassword is a password that you create for the keystore.
  4. Copy the keystore to the initialized ASM keystore that you just created.

    This step requires that you merge the keystore from the file system to ASM as follows:

    ADMINISTER KEY MANAGEMENT MERGE KEYSTORE srcKeystorePath 
IDENTIFIED BY srcKeystorePassword 
INTO EXISTING KEYSTORE asmKeystorePath 
IDENTIFIED BY asmKeystorePassword 
WITH BACKUP USING backupIdentifier;

    In this specification:

    • srcKeystorePath is the directory path to the source keystore.
    • srcKeystorePassword is the source keystore password.
    • asmKeystorePath is the path to the ASM keystore.
    • asmKeystorePassword is the ASM keystore password.
    • backupIdentifier is the backup identifier to be added to the backup file name.

Parent topic: Uploading Keystores from Automatic Storage Management to Oracle Key Vault

19.5 MySQL Integration with Oracle Key Vault

You can manage TDE encryption keys in MySQL with Oracle Key Vault.

Oracle Key Vault supports integration with MySQL from Release 12.2 and later.

Note:

MySQL Windows databases are not supported.

Oracle Key Vault can manage MySQL TDE encryption keys.

Parent topic: Using Oracle Key Vault with Other Features

19.6 Other Oracle Database Features That Oracle Key Vault Supports

You can deploy Transparent Data Encryption (TDE) in multiple topologies with other database features that move or use clustered deployments.

Data movement and replication are major challenges for Oracle Advanced Security TDE because it must keep the master encryption key synchronized at both endpoints. To help with these challenges, Oracle Key Vault supports common Oracle Database features.

To move data, Oracle Key Vault supports the following:

  • Oracle Recovery Manager (RMAN) backup and recovery operations

  • Oracle Data Pump

  • Transportable tablespaces (Oracle Database 12c and later)

For clustered deployments, Oracle Key Vault supports the following:

  • Oracle Data Guard

  • Oracle Real Application Clusters (Oracle RAC)

  • Oracle GoldenGate

Parent topic: Using Oracle Key Vault with Other Features