11 Oracle Key Vault Use Case Scenarios

Typical Oracle Key Vault use cases include the upload and download of security objects, the use of an Online Master Key, and TDE-configured Oracle databases.

Note that the term Online Master Key replaces TDE direct connect.

Topics:

11.1 Uploading and Downloading Oracle Wallets

In order to store and share Oracle wallets you must upload them to Key Vault. You can then create a new virtual wallet in Key Vault, and add security objects to it that you want to share. You must grant endpoints access to the virtual wallet before they can download it.

Topics:

11.1.1 About Uploading and Downloading Oracle Wallets

The okvutil utility comes packaged with the endpoint software that you install at the endpoint. You can use the okvutil upload and okvutil download commands to upload and download Oracle wallets between Oracle Key Vault and its endpoints.

The Oracle Key Vault endpoint software can read an Oracle wallet at the granularity level of an individual security object. It therefore uploads the wallet contents as individual items. During download you can recreate the original wallet with the same set of security objects, or create a new wallet with different set of security objects.

You can upload and download both password-based wallets and auto-login wallets. The wallet contents can be downloaded later into a new wallet of either type. For example, an uploaded password-protected wallet can be downloaded as an auto-login wallet, or an uploaded auto-login wallet can be downloaded as a password-protected wallet.

You can use Oracle Key Vault to construct a new virtual wallet containing security objects from previously uploaded Oracle wallets. For example, given a previously uploaded Oracle wallet containing five symmetric keys and three opaque objects, you can create a new virtual wallet consisting of only three of the original five symmetric keys and one of the three original opaque objects. This virtual wallet can be downloaded like the original wallet to provide the endpoint with access to only a subset of the keys. This process does not modify the original wallet.

11.1.2 Uploading Oracle Wallets

Uploading wallets to Key Vault is done with the okvutil upload command. Everything in the Oracle wallet, security objects and their metadata is uploaded to Key Vault, so that the wallet can be reconstructed during the download process. The Oracle wallet typically contains TDE master keys, historical TDE master keys, SSL or TLS certificates and their metadata (stored in Key Vault as opaque objects), wallet metadata, as well as keys that you have explicitly added.

To upload an Oracle wallet:

  1. Ensure that the server containing the Oracle wallet has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that the endpoint has access to the virtual wallet that you want to use.

    The endpoint must have Read, Modify, and Manage Wallet access to the virtual wallet in Oracle Key Vault.

  3. Run the okvutil upload command to upload the wallet.

    For example:

    okvutil upload -l "/etc/oracle/wallets" -t wallet -g "HRWallet"
    Enter wallet password (<enter> for auto-login): password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    Upload succeeeded
    

    In this example:

    • -l specifies the directory location of the wallet that you are uploading.

    • -t indicates the type, in this case, an Oracle wallet.

    • -g specifies the Key Vault virtual wallet that was configured in Step 2, so that this wallet can be part of that virtual wallet.

    • Password prompts for the password-protected Oracle wallet, and the endpoint password.

At this point, the upload is complete. You can now share the virtual wallet with other users and endpoints.

11.1.3 Downloading Oracle Wallets

You can use the okvutil download command to download an Oracle wallet from the Oracle Key Vault server to an endpoint.

To download an Oracle wallet:

  1. Ensure that the endpoint has Read access on the virtual wallet that you want to download.
  2. Run the okvutil download command to download the wallet.

    For example:

    okvutil download -l "/etc/oracle/wallets/orcl/" -t WALLET -g HRWallet
    Enter new wallet password(<enter> for auto-login): Oracle_wallet_password
    Confirm new wallet password: Oracle_wallet_password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the location of the wallet to be created.

    • -t indicates the type, in this case, an Oracle wallet.

    • -g specifies the Oracle Key Vault virtual wallet that was configured in Step 1.

    • Password prompts for the password-protected Oracle wallet, and the endpoint password.

    If the wallet already exists and you did not use the -o parameter to overwrite the existing wallet, then the following actions take place:

    • The existing wallet is renamed to a backup name of the format ewallet.p12.current_timestamp where the timestamp is number of seconds since epoch.

    • The newly downloaded wallet is given the name ewallet.p12.

  3. If the Oracle wallet that you downloaded from Oracle Key Vault is to be used as a TDE wallet, then close the existing wallet before downloading and, if it is password-protected, then reopen it afterward. (Auto-login wallets are automatically opened the next time that they are accessed.)

    Closing and then reopening the wallet loads the wallet contents into the TDE database.

    • For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "Oracle_wallet_password"; 
      
      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Oracle_wallet_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "Oracle_wallet_password";
      
      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Oracle_wallet_password";
      
  4. If you are operating in a shared server configuration such as Oracle RAC, then restart the database.

See Also:

11.1.4 Recommendations for Uploading and Downloading Oracle Wallets

Oracle provides recommendations for when you upload and download Oracle wallets.

  • If there is a change to the content of the original wallet, such as a key rotation or a rekey operation, then upload the wallet again to Oracle Key Vault so that Key Vault has the latest copy of the wallet.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option because it overwrites data in the virtual wallet that conflicts with the data to be uploaded. Before you use the -o option, you should create a local backup of the wallet file.

  • Do not try to upload the same physical Oracle wallet to more than one virtual wallet on the Oracle Key Vault server. If you want to share an Oracle wallet with multiple endpoints, then create an endpoint group.

11.2 Uploading and Downloading JKS and JCEKS Keystores

You can use the okvutil upload and okvutil download commands to upload and download JKS and JCEKS keystores.

Topics:

11.2.1 About Uploading and Downloading JKS and JCEKS Keystores

You can upload both JKS and JCEKS keystores to Oracle Key Vault for long-term retention, recovery, and sharing, and when you need them, download them to an endpoint.

Similar to wallets, when you upload a JKS or JCEKS keystore, Oracle Key Vault can read each item within the keystore. It uploads the keystore contents as individual items.

11.2.2 Uploading JKS or JCEKS Keystores

You can use the okvutil upload command to upload a Java keystore (JKS) or Java Cryptography Extension keystore (JCEKS) to the Oracle Key Vault server.

To upload a Java keystore:

  1. Ensure that the server containing the Java keystore has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that access control has been configured for the endpoint.

    If you are uploading the keystore to a virtual wallet, then ensure that the endpoint has the Read, Modify, and Manage Wallet access to this wallet.

  3. Run the okvutil upload command to upload the keystore.

    The following examples show how to upload the keystore to a virtual wallet:

    This example shows how to upload a JKS keystore:

    okvutil upload -l "/etc/oracle/fin_jks.jks" -t JKS -g "FinanceGrp"
    Enter source Java keystore password: Java_keystore_password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    Upload succeeded
    

    In this example:

    • -l is the location of the Java keystore that is being uploaded.

    • -t is the type of JKS or JCEKS keystore. Ensure that you upload the correct type of Java keystore when you upload and later on, when you download.

    • -g is the virtual wallet in Oracle Key Vault where the Java keystore contents will be uploaded.

    • Password prompts for the keystore and endpoint.

    This example shows how to upload a JCEKS keystore:

    okvutil upload -l "/etc/oracle/hr_jceks.jceks" -t JCEKS -g "HRGrp"
    Enter source Java keystore password: password
    Enter Oracle Key Vault endpoint password: password
    Upload succeeded
    

At this point, the upload is complete. You are now ready to share or download the Java keystore as needed.

See Also:

11.2.3 Downloading JKS or JCEKS Keystores

You can use the okvutil download command to download an uploaded JKS or JCEKS keystore.

To download a Java keystore:

  1. Ensure that the endpoint has the Read access on the virtual wallet that you want to download.
  2. As an endpoint administrator, from the command line, run the okvutil download command to download the Java keystore.

    For example:

    okvutil download -l "/etc/oracle/new_java_files/hr_jceks.jceks" -t JCEKS
    Enter new Java keystore password: password
    Confirm new Java keystore password: password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory to which you want to download the uploaded Java keystore.

    • -t is the type of JKS or JCEKS keystore. Ensure that you download the correct type of Java keystore.

    • Password prompts for keystore and endpoint password.

11.2.4 Recommendations for Uploading and Downloading JKS and JCEKS Keystores

Oracle provides recommendations for when you upload and download JKS and JCEKS keystores.

  • If there is a change to the content of the original JKS or JCEKS keystore, then upload the keystore again to Oracle Key Vault so that Key Vault has the latest copy of the keystore.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option because it overwrites the file. You may want to create backups of the keystores before downloading them.

  • Do not try to upload the same physical JKS or JCEKS keystore to more than one virtual wallet on the Oracle Key Vault server. If you want to share a Java keystore with multiple endpoints, then create an endpoint group.

    See Also:

    "Manage Endpoint Groups" for more instructions to create an endpoint group

11.3 Uploading and Downloading Credential Files

You can use the okvutil upload and okvutil download commands to upload and download credential files.

Topics:

11.3.1 About Uploading and Downloading Credential Files

Credential files are uploaded and stored as opaque objects in Key Vault, which means that Key Vault does not parse the contents of the file like an Oracle wallet or Java keystore. The upload process does not alter the credential file.

Examples of opaque objects are as follows:

  • Files that contain X.509 certificates

  • Kerberos keytabs

  • Files containing passwords

  • Files containing SSH keys

Uploading these credential files provides a central, secure location for long-term retention. After you have uploaded a credential file, you can download it in the same server location or share it with other trusted server locations. Oracle Key Vault supports credential files up to 128 KB in size.

The credential file can be located anywhere in your server infrastructure (which includes database servers and application servers) that is accessible by an Oracle Key Vault endpoint.

11.3.2 Uploading a Credential File

To upload a credential file with okvutil upload:

  1. Ensure that the server that contains the credential file has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that access control has been configured for the endpoint.

    If you are uploading the credential file to a virtual wallet, then ensure that the endpoint has Read, Modify, and Manage Wallet access to the wallet.

  3. Run the okvutil upload command.

    For example:

    okvutil upload -l "/etc/oracle/app/creds/hr.keytab" -t kerberos -g HRWallet -d "Kerberos keytab file for HR group, 06_11_14"
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory path to the hr.keytab credential file that is being uploaded. Enclose the directory location in double quotation marks.

    • -t specifies the type of credential file, which in this example is a Kerberos keytab file. In addition to KERBEROS, other types that you can specify are as follows:

      • SSH for an SSH key file

      • OTHER for other files that store secrets, such as uploaded or downloaded files

    • -g adds the credential file to the HRWallet group, which already exists. This parameter enables you to upload the credential to a wallet that is specifically for the HR application users' needs, rather than to the default virtual wallet. In this example, HRWallet is the Key Vault virtual wallet to which access control was configured in Step 2.

    • -d is an optional description. As a best practice, include a brief description of what the credential file is used for and the date you performed the upload. This information helps for future reference and tracking of the credential file. You can modify this description later on in the Oracle Key Vault management console if necessary.

    • Password prompts: Enter the endpoint password and confirm it.

    The following output should appear:

    Upload succeeded
    

11.3.3 Downloading a Credential File

To download a credential file using okvutil download:

  1. Find the unique ID of the credential file that you must download, by using one of the following methods:
    • Oracle Key Vault management console: Log in as a user who has been granted the Key Administrator role or a user who has the necessary access to the virtual wallet. In the Oracle Key Vault management console, from the Keys & Wallets tab, select All Items to find the uploaded files. Note the unique ID of the uploaded file that you want to download. Credential files are listed as opaque objects.

    • okvutil list command: Run the okvutil list command from an endpoint that has access to the credential file or a virtual wallet that contains the credential file. Locate the unique ID of the credential file that you must download based on the description that you provided when you uploaded the file.

  2. From the command line, run the okvutil download command to download the uploaded credential file.

    For example:

    okvutil download -l "/etc/oracle/app/newcreds/hr.keytab" -t kerberos -i 6ba7b810-9dad-11d1-80b4-00c04fd430c8
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory to which you want to download the uploaded credential.

    • -t specifies the type of credential file, which in this example is a Kerberos keytab file. In addition to KERBEROS, other types that you can specify are as follows:

      • SSH for an SSH key file

      • OTHER for other files that store secrets, such as uploaded or downloaded files

    • -i is the unique ID of the credential file.

    Output similar to the following appears:

    Download succeeded
    

11.3.4 Recommendations for Uploading and Downloading Credential Files

Oracle provides recommendations for when you upload and download credential files.

  • After you complete the upload, upload credential file again the next time it is changed. Otherwise, the uploaded (and subsequent downloaded version) file will be outdated. Periodically, you should compare the last modification date of the credential file with the timestamp of the uploaded version.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option, because it overwrites the uploaded credential file. You may want to create backups of the credential files before beginning the upload and download processes.

  • You can share one credential file among multiple server endpoints. Add the opaque object to a virtual wallet and then ensure that all of the endpoints have access to that virtual wallet. Optionally, define an endpoint group and then make all the server endpoints members of that group. Upload the credential file that you would like to share using this common wallet into Oracle Key Vault as a group, using the -g option of the okvutil upload command. Define a wallet and attach it to the endpoint group. All the members of the group will have access to that wallet.

11.4 Using an Online Master Key with Oracle Key Vault

You can configure Transparent Data Encryption (TDE) to perform a direct connection to an endpoint to centrally manage TDE master keys.

Note that the term Online Master Key replaces TDE direct connect.

Topics:

11.4.1 About Using an Online Master Key with Oracle Key Vault

For Oracle Database 11g Release 2 (11.2) and later, you can use an Online Master Key to centrally manage Transparent Data Encryption (TDE) master keys over a network connection as an alternative to using local Oracle wallet files.

The connection configuration entails using a PKCS#11 library to connect to Oracle Key Vault. After you perform the configuration, all future TDE master keys will be stored and managed in Oracle Key Vault. This section explains two scenarios that you can use:

  • If the database does not yet have TDE wallets.

  • If the database has already been configured for TDE.

TDE key management operates with Oracle Key Vault in the same way that it operates with hardware security modules (HSMs). You must open the wallet before encryption and decryption. After you close the wallet, encrypted data in tables and tablespaces is unavailable to you. You should rotate the TDE master encryption key regularly to remain in compliance with the applicable regulations.

Oracle Key Vault supports the SQL statements that were used to administer earlier TDE releases, specifically the use of the ALTER SYSTEM and ADMINISTER KEY MANAGEMENT SQL statements.

11.4.2 Other Oracle Database Features That Oracle Key Vault Supports

You can deploy 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:

  • 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:

  • Oracle Active Data Guard

  • Oracle Real Application Clusters (Oracle RAC)

  • Oracle GoldenGate

11.4.3 Configuring a Connection Between Oracle Key Vault and a New TDE-Enabled Database

You can configure a connection between Oracle Key Vault and a database that has not yet been configured for Transparent Data Encryption.

Before you start configuring the connection, ensure that the Oracle Key Vault installation environment is the same as the Database runtime environment. The environment variables ORACLE_HOME, ORACLE_BASE, and ORACLE_SID, if used, must be set to the same values in svrctl and OS environments. This also applies if you are using the Oracle Key Vault RESTful Services utility to enroll endpoints.

Configure the connection as follows:

  1. Ensure that the ORACLE_BASE environment variable is set before you start the oracle process manually. This is very important.

    If the ORACLE_BASE environment variable is not present, create a soft link from the:

    $ORACLE_BASE/okv/$ORACLE_SID/okvclient.ora file

    to the:

    key_vault_endpoint_installation_dir/conf/okvclient.ora file.

    In an Oracle Real Application Clusters environment, perform this step on all database instances.

    Note:

    To learn more about using environment variables in SQLNET.ORA please see the See Also section at the end of this procedure.

  2. Ensure that the COMPATIBILITY initialization parameter is set to 11.2.0.0 or later.

  3. Enroll and provision the endpoint for the TDE-enabled database that contains the TDE data.

    When you initially enroll the endpoint, select Oracle Database as the endpoint type for integration with TDE.

  4. Ensure that the endpoint has access to the virtual wallet that you want to use.

    The endpoint must have the Read, Modify, and Manage Wallet access.

  5. Configure the sqlnet.ora file on this database to point to Oracle Key Vault as follows:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM))
    

    Transparent Data Encryption uses HSM as the parameter value for all external key management systems, including Oracle Key Vault. Therefore the configuration settings and administrative commands are similar to those used for an HSM.

    By default, the sqlnet.ora file is located in the ORACLE_HOME/network/admin directory or in the location set by the TNS_ADMIN environment variable. Endpoints use the PKCS#11 library support to manage TDE master encryption keys.

    Note:

    At this stage, Oracle Key Vault can use TDE and all the TDE-related SQL statements are available. For all TDE commands and statements, use the Key Vault endpoint password that was specified during the endpoint enrollment process.

  6. Reconnect to the database if you are in SQL*Plus.

    The changes will appear after you log out of the current SQL*Plus session and then reconnect again.

  7. Query the V$ENCRYPTION_WALLET dynamic view to ensure that the METHOD_DATA setting in the sqlnet.ora file changed.

    The output of the query should now show HSM.

    SELECT * FROM V$ENCRYPTION_WALLET;
    
  8. Configure TDE to integrate with Key Vault, so that Key Vault can directly manage the TDE master keys as follows:

    1. On UNIX platforms, run the root.sh script as the root user to copy the liborapkcs.so file (located in the lib directory) to the /opt/oracle/extapi/64/hsm/oracle/1.0.0 directory.

      The persistent master key cache feature is implemented in the Oracle Key Vault PKCS#11 library and improves the availability of the database during intermittent network disruptions or Oracle Key Vault upgrade.

      By default, the PKCS#11 library is located in the $OKV_HOME/bin/liborapkcs.so file. Copy it to the following location on a UNIX system:

      /opt/oracle/extapi/64/hsm/oracle/1.0.0
      

      On Windows platforms, run the root.bat script as the root user to copy the liborapkcs.dll file (located in the lib directory) to the C:\oracle\extapi\64\hsm\1.0.0 directory. Provide the database version when prompted.

    2. For password-protected wallets on the database, open the wallet. (Auto-login wallets are automatically opened.)

      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, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    3. Set the master encryption key.

      For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "Key_Vault_endpoint_password"; 
      

      For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "Key_Vault_endpoint_password";
      

The TDE configuration is complete at this stage. You can now encrypt tables or create encrypted tablespaces in the database.

If you have configured the sqlnet.ora file correctly along with the rest of the TDE configuration, a TDE master key is created in Oracle Key Vault when you set the encryption key using one of the following commands:

  • ALTER SYSTEM SET ENCRYPTION KEY

  • OR

  • ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY

Limitations to TDE Endpoint Integration

The limitations to TDE endpoint integration are as follows:

  • All endpoints on the same machine must use the same version of the Oracle Key Vault library. There is only one location per machine for the liborapkcs.so file, which is:

    /opt/oracle/expapi/64/hsm/oracle/1.0.0/liborapkcs.so
    
  • On the same machine it is best to use the same external key manager for Oracle Database, either Oracle Key Vault or HSM. Using Oracle Key Vault for one Oracle Database and HSM for another Oracle Database can cause the wrong PKCS#11 library to be loaded, because Oracle Database picks up the first PKCS#11 library while traversing the subtree:

     /opt/oracle/expapi/64/hsm/
    

Caution:

Oracle strongly recommends NEVER to remove keys from a wallet or the wallet itself after TDE is setup. Loss of keys will result in the loss of encrypted data and hamper the normal functioning of the database. This is true even:
  • If there is no encrypted data in the system

  • If all of the encrypted data has been decrypted

  • If you have migrated your keys and wallets to a hardware security module

See Also:

11.4.4 Migrating Existing TDE Wallets to Oracle Key Vault

You can migrate an existing TDE wallet to Oracle Key Vault, and if necessary, restore the database contents that were previously encrypted by TDE, by using an Oracle wallet.

Topics:

11.4.4.1 About Migrating Existing TDE Wallets to Oracle Key Vault

When the TDE wallets already exist, you must modify the sqlnet.ora file to recognize Oracle Key Vault before you can migrate the existing TDE wallets to Key Vault.

Along with the current TDE master key, Oracle wallets maintain historical TDE master keys that are replaced by each rekey operation that rotates the TDE master key. These historical TDE master keys help to restore Oracle Database backups that were previously made using one of the historical TDE master keys. During the TDE migration from an Oracle wallet file to Oracle Key Vault, Key Vault generates new master keys. After this master key generation, Oracle Key Vault maintains all new keys.

Oracle recommends that you upload the Oracle wallet to Key Vault, before you perform the migration. This enables you to keep a backup of the wallet with all of the historical key information, before you begin the migration. When the migration is complete, manually delete the old wallet on the client system.

If you are operating in a shared server or an Oracle RAC configuration, then you must restart the database so that the new TDE master key is updated to all the endpoint database nodes in the shared server configuration.

11.4.4.2 Migrating an Existing TDE Wallet to Oracle Key Vault

You can use the okvutil upload command to migrate an existing TDE wallet to Oracle Key Vault. It is very important that you close the software wallet and open the HSM wallet before migrating the wallet in the same SQLPLUS session, as outlined in steps 7 and 8 below:

  1. Back up the database that contains the data that you want to migrate.

  2. Complete the enrollment of the endpoint.

  3. If you have not done so already, then upload the existing Oracle wallet to Key Vault, by using the okvutil upload command.

    This step ensures that Oracle Key Vault has a copy of the wallet that contains all of the historical TDE master keys.

  4. Configure the Oracle Database sqlnet.ora file for the HSM as follows:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)(METHOD_DATA=(DIRECTORY=wallet_location)))
    

    By default, the sqlnet.ora file is located in the ORACLE_HOME/network/admin directory or in the location set by the TNS_ADMIN environment variable.

  5. Reconnect to the database if you are in SQL*Plus.

    The changes do not appear until you restart the database session.

  6. Query the V$ENCRYPTION_WALLET dynamic view to ensure that the METHOD_DATA setting in the sqlnet.ora file changed. The output of the query should now show METHOD=HSM.

    SELECT * FROM V$ENCRYPTION_WALLET;
    
  7. If the endpoint is a Release 11gR2 Oracle database, then close the local Oracle wallet and open the HSM wallet as follows:

    1. Close the local Oracle wallet using these steps:

      1. If the auto-login wallet is open, execute the following commands:

        oracle$ cd <wallet location>
        oracle$ mv cwallet.sso cwallet.sso.bak
        sqlplus> alter system set wallet close;
        
      2. If the password-protected wallet is open, execute the following command:

        sqlplus> alter system set wallet close identified by "<wallet password>";
        
    2. Open the HSM wallet:

      sqlplus> alter system set wallet open identified by "<HSM connect string>";
      
  8. Migrate from TDE wallets to Oracle Key Vault.

    • For Oracle Database 11g Release 2:

      If you entered a password for the wallet while installing the endpoint client software, then execute this command:

      sqlplus> alter system set encryption key identified by "<endpoint password>" migrate using "<wallet password>"; 
      

      If you chose the auto-login option while installing the endpoint client software, then execute this command:

      sqlplus> alter system set encryption key identified by "null" migrate using  "<wallet password>";
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      sqlplus> administer key management set encryption key identified by "<endpoint password>" MIGRATE USING "<wallet password>" with backup; 
      

      Note:

      While the with backup clause is required for the administer key management command, it is ignored by TDE in Oracle Key Vault

  9. Open the wallet. If the endpoint requires a password to connect to Oracle Key Vault, then enter the password.

    • For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password";
      
  10. After you complete the migration, if you are using an auto-login wallet, then re-enable it by renaming the cwallet.sso.bak file to cwallet.sso.

11.4.4.3 Restoring Database Contents Previously Encrypted by TDE Using an Oracle Wallet

When an Oracle database endpoint is converted from a local Oracle wallet file to using Oracle Key Vault, there may be a subsequent need to restore backups that were encrypted using a key from this local wallet file.

In this case, you must download the necessary key from Oracle Key Vault to a local wallet file to be used when you decrypt the backup during the restore process. For example, suppose that the Finance_DB database had recently migrated to use an Online Master Key to Oracle Key Vault after you have uploaded the premigration wallet. If a system failure forces you to restore from a database backup taken before the migration to Oracle Key Vault, you can still restore the contents of the database by using an Oracle wallet downloaded from the Oracle virtual wallet that contains the Finance_DB wallet data that you had uploaded earlier.

To restore previously TDE-encrypted database contents using an Oracle wallet:

  1. Download this Oracle wallet from Oracle Key Vault by using the okvutil download command.
  2. On the endpoint where you downloaded the Oracle wallet, add the following settings to the sqlnet.ora file.
    METHOD_DATA=wallet_file_path
    
    METHOD=FILE
    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=wallet_file_path)))
    

    Put the ENCRYPTION_WALLET_LOCATION setting on one line.

  3. If you created a password-protected wallet in Step 1, then open the wallet using the password you specified.
    • 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 "wallet_password"; 
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password";
      

    Opening the wallet enables the server to read the contents of the updated sqlnet.ora file. At this point, the endpoint server has been restored to a state where it now can run with the original version of the wallet.

11.4.5 Persistent Master Key Cache

The persistent master key cache feature enables databases to be operational when the Oracle Key Vault server is unavailable for any reason. The TDE master key is cached in the persistent master key cache in addition to the in-memory cache, to make the master key available across database processes. It eliminates the need for databases to contact the Oracle Key Vault server for every new process, redo log switch, or database startup.

Topics:

11.4.5.1 About Persistent Master Key Cache

The persistent master key cache ensures the availability of TDE master keys by reducing dependence on the state of the Oracle Key Vault server.

The following are the benefits of ensuring availability of TDE master keys:

  • Continuous operation of endpoints during upgrade, High Availability configuration, switchover, failover, and other procedures that require a database restart.

  • Less load on the Oracle Key Vault server when multiple sessions of a single database request the same master key.

  • Improved scalability of Oracle Key Vault.

11.4.5.2 About Oracle Key Vault Persistent Master Key Cache Architecture

The Oracle Key Vault persistent master key cache is implemented in Oracle Key Vault’s PKCS#11 library. When the persistent master key cache feature is configured, the Oracle Key Vault PKCS#11 library will create the persistent master key cache when the first master key is retrieved from Oracle Key Vault.

The persistent master key cache is an auto-login wallet or a password-based wallet, depending on how Oracle Key Vault is installed:
  • If Oracle Key Vault is installed with a password specified, the persistent master key cache is a password-based wallet.

  • If Oracle Key Vault is installed without a password specified, the persistent master key cache is an auto-login wallet.

The PKCS#11 library also implements an in-memory master key cache. When the in-memory master key cache feature is configured, the master key is cached in the process memory of the process that loaded the library into memory. The in-memory and persistent master key caches are independent of each other. They can be enabled and disabled independently.

For operations that involve encryption and decryption, PKCS#11 attempts to look up the master key in the in-memory master key cache. If it is not found, PKCS#11 then looks up the master key in the persistent master key cache. If the master key is not found in the in-memory or the persistent master key cache, then it is retrieved from the Oracle Key Vault server, if the server is online.

Caching Master Keys in the Persistent Master Key Cache

When the master key is first fetched from the Oracle Key Vault server, or created in the Oracle Key Vault server, the master key is stored in the persistent master key cache. If the persistent cache exists, it will be used. If the persistent cache does not exist, it is created. When the key is fetched and stored in the cache, all future sessions will retrieve it from the persistent cache. When the master key is deleted by the endpoint, it will be removed from the persistent master key cache. 

Storage Location of Persistent Master Key Cache

The persistent master key cache is created in the same location as the configuration file okvclient.ora. The default location for the okvclient.ora file is the directory $OKV_HOME/conf.

If the environment variable ORACLE_BASE is set, the persistent cache is created in $ORACLE_HOME/okv/$ORACLE_SID.

If ORACLE_BASE is not set, but ORACLE_HOME is set, the persistent cache is created in $ORACLE_HOME/okv/$ORACLE_SID.

If neither ORACLE_BASE or ORACLE_HOME are set, and OKV_HOME is set, then the persistent cache is created in OKV_HOME.

If none of the following environment variables are set, the persistent cache will be created in the current working directory of the process, which for database processes is the data-file directory:

  • ORACLE_BASE

  • ORACLE_HOME

  • OKV_HOME/conf

Note:

Ensure that the directory in which the persistent cache is created is secure and has restricted permissions.

11.4.5.3 Persistent Master Key Cache Modes of Operation

In Oracle Key Vault 12.2.0.5.0 and later, the persistent master key cache operates in two modes:

The difference between the two modes is the order in which the persistent master key cache and Oracle Key Vault are looked up to retrieve the master key.

11.4.5.3.1 Oracle Key Vault First Mode

Oracle Key Vault First mode is the only mode of operation available in Oracle Key Vault 12.2.0.3.0 and 12.2.0.4.0.

In Oracle Key Vault First mode, the endpoints attempt to retrieve the master key from the Oracle Key Vault server. If the Oracle Key Vault server is offline, the endpoints attempt to retrieve the master key from the persistent master key cache.

The endpoints need to determine the status of the Oracle Key Vault server, and if it is offline, the endpoints then attempt to retrieve the master key from the persistent master key cache. Hence, database operations that require access to master keys will experience a delay.

Note:

In Oracle Key Vault 12.2.0.4.0 and earlier, endpoints in time zones where DST is active are unable to retrieve master keys from the Persistent Master Key cache. This effectively turns off the Persistent Master Key cache for such endpoints.

To fix this issue, request and apply the patch file for the Oracle Key Vault 12.2.0.4.0 PKCS#11 library. For more information about applying the patch file, see this Knowledge Base article on the My Oracle Support website.

11.4.5.3.2 Persistent Master Key Cache First Mode

Persistent Master Key Cache First mode is an additional mode of operation available in Oracle Key Vault 12.2.0.5.0 and later.

In Persistent Master Key Cache First mode, the endpoints attempt to retrieve the master key from the persistent master key cache. If the master key is not available in the persistent master key cache, the endpoints attempt to retrieve the master key from the Oracle Key Vault server.

The modifications to the master keys on the Oracle Key Vault server will not be applied until the key expires in the persistent master key cache.

Note:

In Oracle Key Vault 12.2.0.5.0 and later, persistent master key cache first mode is the default option. The default value for PKCS11_PERSISTENT_CACHE_FIRST is 1.

11.4.5.4 Persistent Master Key Cache - Refresh Window

The Refresh Window feature of the Persistent Master Key Cache further minimizes endpoint downtime.

In Oracle Key Vault 12.2.0.5.0 and earlier, if the Oracle Key Vault server is not available, the PKCS#11 library retrieves master key from the Persistent Master Key Cache if set. However, in the unlikely scenario that the Key Vault Servers are still not available, and if the persistent master key cache time limit specified by the PKCS11_PERSISTENT_CACHE_TIMEOUT has expired, the PKCS#11 library attempt to refresh the master key fails and the endpoint database operations are affected.

The Refresh Window feature of the Persistent Master Key Cache enables the database endpoint to make multiple attempts to refresh the expired master key from the OKV server. In that sense, the endpoint waits for the OKV server to be back online for the master key refresh to complete. Meanwhile, if the master key refresh attempt fails, the keys are retrieved from the persistent cache for the duration of the refresh window.

The Refresh Window feature of the Persistent Master Key Cache thus extends the duration for which the master key is available after it is cached in the persistent master key cache. At the same time the endpoints can refresh the key during the refresh window instead of once at the end of the cache time. This addresses the possibility that persistent cache expires in the window when the Oracle Key Vault is unavailable such as when HA switchover is in progress. The refresh window terminates and the cache period begins as soon as the key is refreshed.

In the okvclient.ora file, the parameter PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW is used to extend the duration for which the master key is available after it is cached in the persistent master key cache. This value reflects the amount of time it takes for the Oracle Key Vault server to recover and come back online. The value is specified in minutes. The default value for PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW is 30 (minutes).

For more information about the Persistent Cache Refresh Window, see PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW.

11.4.5.5 Persistent Master Key Cache Parameters

The following are the parameters used to configure the Persistent Master Key Cache:

11.4.5.5.1 PKCS11_PERSISTENT_CACHE_TIMEOUT

In the okvclient.ora file, the parameter PKCS11_PERSISTENT_CACHE_TIMEOUT is used to specify the duration for which the master key is available after it is cached in the persistent master key cache. The value is specified in minutes. When the specified duration of time elapses, the master key expires. Expired master keys are not deleted from the persistent master key cache.

The Cache Start Time and Maximum Use Time values displayed in the OKV Persistent Cache entries list is updated when the master key is refreshed.

The default value for PKCS11_PERSISTENT_CACHE_TIMEOUT is 1440 (minutes).

The persistent master key cache can be disabled by setting the PKCS11_PERSISTENT_CACHE_TIMEOUT value to zero.

Note:

The parameter PKCS11_PERSISTENT_CACHE_TIMEOUT and its default value has been explicitly added to the okvclient.ora file.
11.4.5.5.2 PKCS11_PERSISTENT_CACHE_FIRST

In the okvclient.ora file, the parameter PKCS11_PERSISTENT_CACHE_FIRST is used to specify the mode of operation of the persistent master key cache. The following are the modes of operation:

  • Oracle Key Vault First Mode

    To enable Oracle Key Vault First mode, set the value of the PKCS11_PERSISTENT_CACHE_FIRST parameter to 0 (zero).

    For more information about Oracle Key Vault First mode, see Oracle Key Vault First Mode.

  • Persistent Master Key Cache First Mode

    Persistent Master Key Cache First mode is the default mode.

    To enable Persistent Master Key Cache First mode, set the value of the PKCS11_PERSISTENT_CACHE_FIRST parameter to 1.

    For more information about Persistent Master Key Cache First mode, see Persistent Master Key Cache First Mode.

11.4.5.5.3 PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW

In the okvclient.ora file, the parameter PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW is used to extend the duration for which the master key is available after it is cached in the persistent master key cache. The value is specified in minutes.

The default value for PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW is 30 (minutes).

The persistent master key cache can be disabled by setting the PKCS11_PERSISTENT_CACHE_REFRESH_WINDOW value to zero.

11.4.5.6 Listing the Contents of the Persistent Master Key Cache

After installing the endpoint software, endpoint administrators can use the command-line utility okvutil to communicate with Oracle Key Vault to view, upload, and download security objects.

The okvutil list command also allows you to list the master keys cached in the persistent master key cache.

The following example shows how to list the master keys cached in the persistent master key cache:

$ ./okvutil list -t okv_persistent_cache -l $ORACLE_HOME/okv/$ORACLE_SID
Enter Oracle Key Vault endpoint password:  

OKV Persistent Cache entries:
Current Persistent Cache Timeout is 600 seconds
Version Unique ID                            TDE Master Key Identifier          Cache Start Time    Maximum Use Time  Maximum Refresh Window  Status
02      55D745B1-2F30-667F-E053-0100007FAFDB 0636846AAF88F74FC6BF1DB68538797B69 22:38:12 2017-08-03 600 seconds       0 seconds                Expired
02      55D745B1-2F2E-667F-E053-0100007FAFDB 063AC48E9433734F7EBF97180276E719C4 22:37:10 2017-08-03 600 seconds       180 seconds              Available
02      55D745B1-2F2D-667F-E053-0100007FAFDB 0604425983989C4F6ABF7BD9E1D55459C4 22:37:00 2017-08-03 600 seconds       180 seconds              Available
02      55D70FA4-81D1-5C8A-E053-0100007F8217 06172EACB79F4C4F32BFB7D50B0ACA7101 03:44:22 2017-08-03 300 seconds       0 seconds                Expired
02      55D745B1-2F2B-667F-E053-0100007FAFDB 06983C4664FFC04F6ABF72F961A15AD943 22:36:49 2017-08-03 600 seconds       300 seconds              Available
02      55D745B1-2F29-667F-E053-0100007FAFDB 0639E05D58B27B4FFDBFAEC5EAA08DB301 03:26:40 2017-08-03 300 seconds       0 seconds                Expired
02      55D745B1-2F28-667F-E053-0100007FAFDB 06A29F4039E1B74FDCBFA687E0608EEEBA 03:19:17 2017-08-03 300 seconds       0 seconds                Expired
02      55D745B1-2F27-667F-E053-0100007FAFDB 0678287C2877B74FF3BF0BA33A17A59F94 03:19:21 2017-08-03 300 seconds       0 seconds                Expired

The following table lists the columns in the OKV Persistent Cache entries list:

Column Name Description

Version

Persistent master key cache version

Unique ID

KMIP identifier assigned to the master key

TDE Master Key Identifier

Database ID assigned to the master key

Cache Start Time

Time at which the master key was cached

Maximum Use Time

Duration for which the master key was/is cached

Maximum Refresh Window

Extended duration for which the master key is available after it is cached in the persistent master key cache

Status

Indicates whether the master key is available or expired

11.4.5.7 Oracle Database Deployments and Persistent Master Key Cache

Database Restart when the Oracle Key Vault Server is Offline

When Oracle Key Vault is configured to use an auto-login wallet, the database connects to the Oracle Key Vault server on database restart. If the Oracle Key Vault server is offline when the database restarts, the database retrieves master keys from the persistent master key cache. Database operations resume normally if the master keys are active and have not expired

Ensure that the passwords of the persistent master key cache and the Oracle Key Vault endpoint wallet are synchronized.

Note:

The persistent master key cache must be deleted when the endpoint wallet credentials are modified.

Using Persistent Master Key Cache in an Oracle RAC Environment

In an Oracle Real Application Cluster (Oracle RAC) environment, each RAC node is an unique database endpoint, and uses an unique persistent master key cache.

In an Oracle RAC Environment, you need to query the database from each RAC node in order to cache the most recent version of the master key in the persistent master key cache of each RAC node.

Using Persistent Master Key Cache in an Active Data Guard Environment

Rotation of the master key in the primary server’s database caches the master key in the persistent master key cache of the primary server’s database.

The standby server retrieves and caches the new master key in the persistent master key cache of the standby server’s database after the new REDO logs from the primary server are applied on the standby server. To avoid disruptions, it is recommended that you synchronize the primary and standby servers immediately after the rotation of the master key in the primary server’s database.

11.4.6 Minimizing Downtime

Business-critical operations require data to be accessible and recoverable with minimum downtime. You can configure Oracle Key Vault to ensure minimum downtime in the following ways:

  • Configuring High Availability: High Availability is configured by adding redundancy in the form of a standby server. The standby server takes over from the primary server in the event of a failure, thus eliminating single points of failure, and minimizing downtime. For more information about configuring High Availability, see Configuring High Availability.

  • Enabling Read-Only Restricted Mode: High Availability Read-Only Restricted mode ensures endpoint operational continuity when primary or standby Oracle Key Vault servers are affected by server, hardware, or network failures. When an unplanned shutdown causes the standby server to become unreachable, the primary server is still available to the endpoints.

    If High Availability Read-Only Restricted mode is disabled, the primary server will become unavailable and stop accepting requests in the event of a standby failure. Endpoints connected to Oracle Key Vault are unable to retrieve keys until connectivity is restored between primary and standby servers.

    To ensure endpoint operational continuity in the event of a primary or standby server failure, enable Read-Only Restricted mode.

  • Enabling Persistent Master Key Cache: The Persistent Master Key Cache ensures that the endpoints can access keys in the event of a primary or standby server failure. While the surviving server is taking over from the failed peer, the endpoints can retrieve keys from the persistent cache and continue operations normally. For more information about Persistent Master Key Cache, see Persistent Master Key Cache.

  • Apply the TDE Heartbeat database patch on endpoints: Apply the database patch for Bug 22734547 to tune the Oracle Key Vault heartbeat.

It is highly recommended that you back up Key Vault data regularly on a schedule. This practice ensures that backups are current and hold the most recent data. The backup can be used to restore a new or existing Key Vault server and be fully operational with minimum downtime and data loss.

If the OKV installation uses an online master key (formerly known as TDE direct connect), then during an upgrade, ensure that you upgrade database endpoints in parallel to reduce total downtime.

11.5 Using an User-Defined Key as the TDE Master Encryption Key

You can now import your generated key to be used as the Transparent Data Encryption (TDE) master encryption key in Oracle Key Vault.

Key Administrators can upload this user-defined key to the groups that they have write access to. This feature provides Key Administrators with more control on creation of the master key used to encrypt TDE data encryption keys.

The type parameter of the okvutil upload command features a new option TDE_KEY_BYTES that allows you to upload a user-defined key to Oracle Key Vault. The key is then registered as a TDE master encryption key by running the ADMINISTER KEY MANAGEMENT command on the database. For more information about activating a TDE master encryption key, see Activating TDE Master Encryption Keys.

Perform the following steps to upload and activate a user-defined key as the TDE master encryption key:

11.5.1 Uploading the User-Defined Key

User-defined keys are uploaded to Oracle Key Vault using the okvutil upload command. The raw bytes data of the user-defined key is stored in a text file and uploaded to Oracle Key Vault.

To upload the user-defined key:

  1. Create a text file containing the raw bytes data of the user-defined key.

    Use the following format:

    TDE Master Key Identifier: <contiguous TDE Master Key Identifier bytes encoded in hex (32 bytes long)>
    TDE Master Key: <contiguous TDE Master Key bytes encoded in hex (64 bytes long)>
    

    Example:

    TDE Master Key Identifier: 1F1E1D1C1B1A10191817161514131210
    TDE Master Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
    
  2. Save the file as tde_key_bytes.txt.
  3. Use the okvutil upload command to upload tde_key_bytes.txt.

    The format of the okvutil upload command is:

    okvutil upload [--overwrite] --location location --type type [--group group] [--
    description description] [--verbose verbosity_level]
    

    Example:

    $OKV_HOME/bin/okvutil upload -l /home/oracle/tde_key_bytes.txt -t TDE_KEY_BYTES -g "FIN_DATABASE_VIRTUAL_WALLET" -d "This key was created for Financial database use on 1st Jan 2018" 
    

    In this example:

    • -l specifies the path to the tde_key_bytes.txt file

      .
    • -t specifies the data type of the object to upload. To upload a user-defined key, specify the type as TDE_KEY_BYTES.

    • -g specifies the name of an Oracle Key Vault virtual wallet to which the key is added.

    • -d specifies a description for the key.

  4. Specify the required parameters and press Enter.
  5. Enter the Oracle Key Vault endpoint password and press Enter.
    The message Upload succeeded is displayed.
    $OKV_HOME/bin/okvutil upload -l /home/oracle/tde_key_bytes.txt -t TDE_KEY_BYTES -g "FIN_DATABASE_VIRTUAL_WALLET" -d "This key was created for Financial database use on 1st Jan 2018" 
    Enter Oracle Key Vault endpoint password:
    Upload succeeded
    
The raw bytes data of the user-defined key is uploaded. The next step is to activate the user-defined key as a TDE master encryption key.

11.5.2 Activating the User-Defined Key as a TDE Master Encryption Key

After uploading the user-defined key, activate the key as a TDE master encryption key.

To activate the user-defined key:

  1. Get the Key ID of the user-defined key from the Item Details page.
    1. Log in to the Oracle Key Vault management console as a user with the Key Administrator role or as a user with access to the virtual wallet.
    2. Click the tab Keys & Wallets. The Wallets page appears.
    3. Click All Items in the left sidebar. The All Items page appears displaying all the security objects in Key Vault.
    4. Click the pencil icon in the Details column corresponding to the user-defined key. The Item Details page appears displaying the attributes of the key.
    5. Click Advanced to view the cryptographic attributes of the key.
    6. The required Key ID is displayed. The Key ID is prefixed with ORACLE.TDE.HSM.MK.

      Example:

      ORACLE.TDE.HSM.MK.067DCC199171BE4F89BF21405833F9947F
      
    7. Copy and store the Key ID displayed after the prefix ORACLE.TDE.HSM.MK..

      Example:

      067DCC199171BE4F89BF21405833F9947F
      
  2. Connect to the database and activate the key as a TDE master encryption key using the ADMINISTER KEY MANAGEMENT command.

    The format of the ADMINISTER KEY MANAGEMENT command is:

     ADMINISTER KEY MANAGEMENT USE [ENCRYPTION] KEY <Key ID for activation> 
           [USING TAG <tag>] 
           IDENTIFIED BY <keystore_password> 
           [WITH BACKUP [USING <backup_id>]];
    

    Example:

    $ORACLE_HOME/bin/sqlplus / as sysdba
    SQL> Administer key management use key '067DCC199171BE4F89BF21405833F9947F' identified by "Welcome_1";
    
The user-defined key is activated as a TDE master encryption key.

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

In a TDE-configured Oracle database, if you upload Oracle wallets in an Oracle Real Application Cluster (Oracle RAC) environment, then the nodes within the cluster must share a virtual wallet.

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

  • Define a virtual wallet as a shared default wallet for all of the nodes in the cluster.

  • If each node in the cluster has a separate default wallet, then grant each node access to every other node's default wallet to have the same effect. An endpoint group may be used to simplify the process of granting each node access to the default wallets of the other nodes.

    The advantage of this approach over the first is that if you had several nodes that already had default wallets and you wanted them to share wallets, then you would not have to reassign their default wallets. This is particularly important because in the first approach, in order to reassign an endpoint's default wallet, you must reenroll the endpoint. An endpoint group can be used to simplify the process of granting each node access to the default virtual wallets of the other nodes.

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, you must explicitly open the wallets on each of these nodes.

Each RAC node is a different end point of the database and has its own individual persistent cache. For RAC databases, a query should be initiated from each RAC node to cache the latest master key in the RAC node for uninterrupted operations

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

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

Topics:

11.7.1 About Uploading Oracle Wallets in an Oracle GoldenGate Environment

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 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 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 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 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. Note that the two Oracle TDE-enabled databases, source and target, do not need to have the same master key in the Oracle wallet. If you configure this target database as a new Key Vault endpoint, then you can upload and download wallets to and from Oracle Key Vault as you normally would with any independent Key Vault endpoint. No additional configuration is necessary.

11.7.2 Using an Online Master Key in an Oracle GoldenGate Deployment

Note, that the term Online Master Key replaces the term TDE direct connect.

There are two configuration steps to using the Online 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 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 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 this procedure is performed. The other Oracle GoldenGate shared secrets are stored in Oracle Key Vault.

See Also:

11.7.3 Migrating TDE Wallets on an Oracle GoldenGate Deployment to Oracle Key Vault

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

Note that target databases (if they are Oracle TDE-enabled databases) that are used in this Oracle GoldenGate environment can also be configured to use Oracle Key Vault or continue to use 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 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.

See Also:

"Migrating Existing TDE Wallets to Oracle Key Vault" to migrate the Oracle wallet to Key Vault

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

You can perform the following activities in an Oracle Active Data Guard environment: upload Oracle wallets to an Oracle Key Vault server, use Online Master Keys, migrate wallets between endpoints, and migrate and check TDE wallets for a logical standby database.

Topics:

11.8.1 About Uploading Oracle Wallets in an Oracle Active Data Guard Environment

In an Oracle Active Data Guard environment with a TDE-enabled primary and a standby database using an Oracle wallet, you must physically copy the Oracle wallet file from the primary database to the standby after the initial TDE configuration and later, whenever you rekey the master key on the primary database.

Whereas, when using Oracle Key Vault with a TDE-enabled Active Data Guard database, the primary and standby databases must be registered in Oracle Key Vault as endpoints. You must ensure that the endpoints that are registered for both the primary and standby databases have same default virtual wallet in Oracle Key Vault.

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

Persistent Cache in an Active Data Guard Environment

A REKEY on the primary database will cache the Master 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 OKV 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. It is recommended that the primary and standby be synchronized as soon as possible after the REKEY.

11.8.2 Uploading Oracle Wallets in an Oracle Active Data Guard Environment

You can upload an Oracle wallet to an Active Data Guard environment as follows:

  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.

11.8.3 Performing an Online Master Key Connection in an Oracle Active Data Guard Environment

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

11.8.4 Migrating Oracle Wallets in an Oracle Active Data Guard Environment

You can migrate an Oracle wallet in an Oracle Active Data Guard environment as follows:

  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.
  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, 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, 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.

See Also:

11.8.5 Reverse Migrating Oracle Wallets in an Active Data Guard Environment

To reverse migrate an Oracle wallet in an Active 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.

    See Oracle Database Advanced Security Guide for more information about performing reverse migrations.

  3. Close the existing Oracle wallet on the standby database.
    • For Oracle Database 11gR2:

      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      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.

    See Oracle Database Advanced Security Guide for more information.

  5. Open the Oracle wallet on the standby database.
    • For Oracle Database 11gR2:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password";
      
  6. Start the apply process on the standby database.

    See Oracle Data Guard Concepts and Administration for information about starting the apply process on the standby database.

Note:

If the endpoint password and the local TDE wallet password are different, then use the auto-login HSM feature. See Oracle Database Advanced Security Guide for more information about configuring auto-login wallets.

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

If you have a logical standby database configured and are using Oracle Database Release 12c, then you can migrate a TDE wallet to Oracle Key Vault as follows:

  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.
  5. To check that the status the that migration was successful, query the V$ENCRYPTION_WALLET dynamic view.

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

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 by querying the WRL_TYPE and WALLET_ORDER columns of the V$ENCRYPTION_WALLET dynamic view.

By querying the V$ENCRYPTION_WALLET view, you can track 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 key is located. Consider the following queries.

In the following query, only a single wallet is configured:

SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;

WRL_TYPE             WALLET_OR
-------------------- ---------
FILE                 SINGLE

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

SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;
 
WRL_TYPE             WALLET_OR
-------------------- ---------
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.

11.9 MySQL Integration with Oracle Key Vault

Oracle Key Vault supports integration with MySQL from Release 12.2 onwards.

Note:

MySQL Windows databases are not supported.

Oracle Key Vault 12.2 and above can manage MySQL TDE encryption keys.

11.10 Upload a Keystore 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, which is described here.

Uploading a keystore from ASM to Oracle Key Vault is a two step process:
  1. Copy the keystore from ASM to the file sytem.

  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.
You can use the ADMINISTER KEY MANAGEMENT statement to move a software keystore out of Automatic Storage Management (ASM) as follows:
  1. Initialize a target keystore on the file system with the following command:
    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"; 
    

    Where '/etc/ORACLE/KEYSTORE/DB1/' is the path to the target keystore in the file system and “destination_password” is the keystore password.

    The keystore from ASM can now be copied 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 using the okvutil upload command.
    $  okvutil upload -l location -t type
    

    Where:

    • 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
    
The keystore is now copied from ASM to Oracle Key Vault.

To copy a keystore from Oracle Key Vault to ASM you would reverse the steps:

  1. Initialize a target keystore on the file system, if it does not exist. If it exists, skip this step.

  2. Copy the keystore from Key Vault to the target keystore on the file system using the okvutil download command.

    $  okvutil download -l location -t type
    

    Where:

    • 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. Copy the keystore from the target keystore to ASM.