Introduction

This guide describes the integration of the Entrust KeyControl Database Vault with an Oracle database. KeyControl Database Vault acts as an Extensible Key Management (EKM) solution that securely manages keys and encrypts sensitive data using Transparent Data Encryption (TDE).

The Oracle feature Transparent Data Encryption (TDE) provides data-at-rest encryption for sensitive information held by the Oracle database, while at the same time allowing authorized clients to use the database.

Integrated Oracle and Entrust technology has been tested to support Oracle TDE for tablespace encryption, or column encryption, or concurrently for both.

This guides shows support for non-multitenant and multitenant databases. For Oracle version 21C, only multitenant Oracle database types are supported. Oracle does not support the creation of non-multitenant database types on version 21C. For more information on the multitenant support only by Oracle, see the Oracle multitenant documentation.
If using Oracle 18c or later, the sqlnet.ora file is officially deprecated and you should use the WALLET_ROOT and TDE_CONFIGURATION parameters.

Using this guide

This Integration Guide covers UNIX/Linux based systems. It provides:

  • An overview of how the Oracle database software and Entrust KeyControl Database Vault work together to enhance security.

  • Configuration and installation instructions.

  • Depending on your current Oracle setup, how to:

    • Migrate encryption from an existing Oracle wallet or keystore to KeyControl protection.

    • Begin using KeyControl protection immediately if no Oracle software wallet or keystore already exists.

  • Examples and advice on how the product may be used.

  • Troubleshooting advice.

It is assumed the reader has a good knowledge of Oracle database technology.

Assuming you already have your Oracle database installed, after installing and configuring the Entrust KeyControl Database Vault, there is no other software required. However, some minor configuration changes will be needed.

This guide cannot anticipate all configuration requirements a customer may have. Examples shown in this guide are not exhaustive, and may not necessarily show the simplest or most efficient methods of achieving the required results. The examples should be used to guide integration of the Entrust KeyControl Database Vault with an Oracle database, and should be adapted to your own circumstances.

Entrust accepts no responsibility for loss of data, or services, incurred by use of examples, or any errors in this guide. For your own reassurance, it is recommended you thoroughly check your own solutions in safe test conditions before committing them to a production environment. If you require additional help in setting up your system, contact Entrust Support.

Entrust accepts no responsibility for information in this guide that is made obsolete by changes or upgrades to the Oracle product.

This integration guide assumes that you have already reviewed the documentation for KeyControl Database Vaults and have a basic understanding of the setup processes involved in configuring Oracle database TDE. Familiarity with these concepts will ensure a smoother implementation of the integration.

Product configuration

Entrust has successfully tested the following software version:

Product Version Certification

KeyControl Vault

10.1

FIPS 140 Level 1

Entrust has successfully tested Entrust KeyControl Database Vault with the following configurations:

OS Version Kernel Oracle Version

Red Hat Enterprise Linux 8.7 (Ootpa)

Linux 4.18.0-240.el8.x86_64

Oracle Database 21c Enterprise Edition - 21.10.0.0.0

Red Hat Enterprise Linux 8.7 (Ootpa)

Linux 4.18.0-425.10.1.el8_7.x86_64

Oracle Database 19c Enterprise Edition - 19.19.0.0.0

Conventions used in this document

Multitenant and non-multitenant

Descriptions in this Integration Guide may cover non-multitenant databases and multitenant databases. Keep in mind that creation of non-multitenant databases are not supported anymore from Oracle 21C. This guide will use the terms appropriate to the database type under discussion, as outlined:

  • Non-multitenant databases are on Oracle version 11g or earlier. Multitenant databases start from Oracle version 12c.

  • Non-multitenant database software can only create and use non-multitenant databases. If non-multitenant databases are the subject matter, use the non-multitenant and SQL terminology as shown below.

  • Database software supporting multitenant databases may also optionally support non-multitenant databases (pre-21c). In this case, if a non-multitenant mode is the subject matter, then use the non-multitenant terminology and SQL shown below. If a multitenant mode is the subject matter, then use the multitenant terminology and SQL.

  • Non-Multitenant (non-container)

    1. Terminology for Oracle software based encryption key repository.

      ALTER SYSTEM SET ENCRYPTION …​

  • Multitenant (container)

    1. Terminology for Oracle software based encryption key repository

      Software keystore

    2. SQL preamble for encryption related commands

      ADMINISTER KEY MANAGEMENT, etc

Where such terminology applies equally to a software wallet or software keystore, the default terminology software keystore is used to cover both descriptive instances.

Database connections

You must be a user with correct permissions to access a database, and also have the correct privileges to perform the required operations when connected to that database. Your system administrator should be able to create users and grant suitable permissions and privileges according to your organization’s security policies.

Entrust recommends that you allow only unprivileged connections unless you are performing administrative tasks.

Example 2

  • <database-user> is the user identity making the connection.

  • <database-identifier> is the database to make the connection to.

For the purpose of examples in this guide, the following database users and database identifiers should be sufficient.

  • <database-user>. This guide will use one following users for connecting to databases:

    • sysdba, Oracle’s standard sysdba user.

    • system, Oracle’s standard system user.

    • Non-Mutitenant:

      • TESTER, as a local user.

    • Multitenant:

      • C##TESTER, as a common user for container (CDB) and the PDBs it contains.

      • CDB<n>PDB<k>TESTER, as a local user for a PDB<k> within container CDB<n>.

        Where <n> and <k> are distinguishing digits.

  • <database-identifier>. This guide will use one following database identifies during a connection:

    • Non-Multitenant databases:

      • DB, in practice usually the ORACLE_SID of the database. For example:

        CONNECT sysdba@DB
CONNECT TESTER@DB

    • Multitenant databases:

      • CDB<n> indicates a container database where <n> is a distinguishing digit.

      • PDB<k> indicates a pluggable database where <k> is a distinguishing digit.

      Multitenant database identifiers will be:

      • CDB<n>, to connect to the $CDB<n>$ROOT for a particular container CDB<n>.

      • CDB<n>PDB<k>, to connect to PDB<k> within CDB<n>.

      For example:

      CONNECT sysdba@CDB1
CONNECT C##TESTER@CDB1
CONNECT C##TESTER@CDB1PDB2
CONNECT CDB1PDB1TESTER@CDB1PDB1

When you are using a multitenant database, the connection implies that you must alter a session if you are not already connected to the required container. For example:

  • Example 1:

    CONNECT C##TESTER@CDB<n>

    This implies that, if you are not already connected to CDB<n>, then alter the session:

    ALTER SESSION SET CONTAINER = CDB<n>$ROOT;

  • Example 2:

    CONNECT CDB<n>PDB<k>TESTER@CDB<n>PDB<k>

    This implies that, if you are not already connected to CDB<n>PDB<k>, then alter the session:

    ALTER SESSION SET CONTAINER = CDB<n>PDB<k>;

Examples of sqlplus connection syntax for different users:

  • sqlplus / as sysdba

  • sqlplus / as sysdba@CDB1ROOT

  • sqlplus CDB1PDB1TESTER/Tester@//localhost:1521/CDB1PDB1.interop.com

Key migration and legacy keys

KeyControl serves as a software wallet or keystore, utilizing the HSM keystore configuration when setting up the wallet type. However, it’s important to note that KeyControl is a software-based solution and not a physical hardware security module (HSM).

KeyControl provides two configurations for key management:

  • The first configuration entails using pure software-based keys.

  • The second configuration utilizes a Hardware Security Module (HSM) as the backend for key creation and operations.

KeyControl offers support for various HSMs, including nShield, Luna, and cloud HSMs.

For more information on HSM configuration with KeyControl, please refer to Hardware Security Modules with KeyControl Vault

Encryption master keys can be migrated between an existing Oracle keystore and KeyControl serving as the wallet. In this case, 'key migration' refers to the transfer of responsibility for holding the master keys.

The encryption keys themselves are not copied or imported between a software keystore and KeyControl wallet Instead, fresh master key(s) are created within the software keystore or KeyControl wallet during the migration. Subsidiary keys that are being protected are re-encrypted using the fresh master key(s). Any new master keys are subsequently created in the current key protector to which you have migrated.

During the re-key process, the previous master keys, or legacy keys, remain in the software keystore or KeyControl wallet where they were originally created. After performing a key migration, you can retain access to the legacy keys in the software keystore or KeyControl wallet you migrated from by setting its passphrase to be the same as the current key protector’s passphrase. This allows both the software keystore and KeyControl wallet to be open simultaneously, providing access to the encryption keys they contain. If you do not follow this approach, you will only be able to access keys in the current key protector. If you are using both a software keystore and KeyControl wallet concurrently, the current key protector is referred to as the primary.

Overview

Transparent Data Encryption (TDE) is used to encrypt an entire database without requiring changes to existing queries and applications.

When a database encrypted with TDE is loaded into memory from disk storage, it is automatically decrypted, allowing clients to query the database within the server environment without needing to perform any decryption operations. The database is encrypted again when saved to disk storage.

There are several advantages to using KeyControl for managing Transparent Data Encryption (TDE) within the Oracle environment. Firstly, it increases visibility into TDE keys, providing administrators with better oversight and control. KeyControl supports the use of in-house Hardware Security Modules (HSMs) for generating cryptographic material, ensuring a secure and trusted key management process. Administrators also have granular control over TDE key usage, with the ability to revoke access if database keys are suspected to be compromised.

Furthermore, KeyControl provides the advantage of storing keys externally to the Oracle Server, offering an additional layer of protection. Access control is strengthened through the validation of the Oracle Server VM’s certificate by KeyControl, enhancing overall security. Encryptions keys are securely stored on a FIPS 140 Level 1 certified Encrypted Object store, ensuring compliance with stringent security standards.

KeyControl also enables geo-location-based access control when boundary control is enabled, allowing for fine-grained access restrictions based on geographical locations. Additionally, audit logs are generated in KeyControl, providing a comprehensive record of key management activities for compliance and auditing purposes. Overall, leveraging KeyControl for TDE management enhances security, control, and compliance within the Oracle environment.