Transparent Data Encryption enables you to encrypt sensitive data, such as credit card numbers or Social Security numbers.
2.1 What Is Transparent Data Encryption?
Transparent Data Encryption (TDE) enables you to encrypt sensitive data that you store in tables and tablespaces.
After the data is encrypted, this data is transparently decrypted for authorized users or applications when they access this data. TDE helps protect data stored on media (also called data at rest) in the event that the storage media or data file is stolen.
Oracle Database uses authentication, authorization, and auditing mechanisms to secure data in the database, but not in the operating system data files where data is stored. To protect these data files, Oracle Database provides Transparent Data Encryption (TDE). TDE encrypts sensitive data stored in data files. To prevent unauthorized decryption, TDE stores the encryption keys in a security module external to the database, called a keystore.
You can configure Oracle Key Vault as part of the TDE implementation. This enables you to centrally manage TDE keystores (called virtual wallets in Oracle Key Vault) in your enterprise. For example, you can upload a software keystore to Oracle Key Vault, migrate the database to use Oracle Key Vault as the default keystore, and then share the contents of this keystore with other primary and standby Oracle Real Application Clusters (Oracle RAC) nodes of that database to streamline daily database adminstrative operations with encrypted databases.
2.2 How Configuring Transparent Data Encryption Works
To configure Transparent Data Encryption, you must perform a one-time setup before you create keystores and encrypt data.
Before you can begin to encrypt data, you must perform a one-time configuration using the static
WALLET_ROOT parameter and the dynamic
TDE_CONFIGURATION parameter to designate the location and type of keystores that you plan to use.
WALLET_ROOT parameter specifies the keystore directory location. Before you set
WALLET_ROOT, ensure that you have an existing directory that you can use to store keystores (for example,
WALLET_ROOT can be set to the existing directory
TDE_CONFIGURATION parameter specifies the type of keystore (software keystore or Oracle Key Vault). After you set the type of keystore using
TDE_CONFIGURATION, when you create the keystore, Oracle Database creates a directory within the
WALLET_ROOT location for the keystore type. For example, if you set
FILE, then Oracle Database creates a TDE wallet in
WALLET_ROOT/tde. To use Oracle Key Vault, install the Oracle Key Vault client software into
WALLET_ROOT/okv and set
OKV. To establish an auto-open Oracle Key Vault configuration, add the Oracle Key Vault password into an auto-open wallet in
WALLET_ROOT/tde, and set
OKV|FILE. If you want to migrate from one keystore type to another, then you must first set
TDE_CONFIGURATION parameter to the keystore type that you want to use, and then use the
ADMINISTER KEY MANAGEMENT statement to perform the migration. For example, you can migrate from a TDE wallet to Oracle Key Vault.
KEYSTORE_MODE column of the
V$ENCRYPTION_WALLET dynamic view shows whether united mode or isolated mode has been configured.
Note:In previous releases, the
SQLNET.ENCRYPTION_WALLET_LOCATIONparameter was used to define the keystore directory location. This parameter has been deprecated. Oracle recommends that you use the
WALLET_ROOTstatic initialization parameter and
TDE_CONFIGURATIONdynamic initialization parameter instead.
2.3 Benefits of Using Transparent Data Encryption
Transparent Data Encryption (TDE) ensures that sensitive data is encrypted, meets compliance requirements, and provides functionality that streamlines encryption operations.
Benefits are as follows:
As a security administrator, you can be sure that sensitive data is encrypted and therefore safe in the event that the storage media or data file is stolen, or when an intruder tries to access the data files from the operating system, bypassing the access controls of the database.
Using TDE helps you address security-related regulatory compliance issues.
You do not need to create auxiliary tables, triggers, or views to decrypt data for the authorized user or application. Data from tables is transparently decrypted for the database user and application. An application that processes sensitive data can use TDE to provide strong data encryption with little or no change to the application.
Data is transparently decrypted for database users and applications that access this data. Database users and applications do not need to be aware that the data they are accessing is stored in encrypted form.
Using online or offline encryption of existing un-encrypted tablespaces enables you to implement Transparent Data Encryption with little or no downtime.
You do not need to modify your applications to handle the encrypted data. The database manages the data encryption and decryption.
Oracle Database automates TDE master encryption key and keystore management operations. The user or application does not need to manage TDE master encryption keys.
2.4 Who Can Configure Transparent Data Encryption?
To configure Transparent Data Encryption (TDE), you must be granted either the
SYSKM administrative privilege or the
ADMINISTER KEY MANAGEMENT system privilege.
A user can authenticate as a security administrator in two ways, which are quite different, and both authentication approaches allow the security administrator to issue the
ADMINISTER KEY MANAGEMENT statement. To check if a user is allowed to perform a TDE operation, Oracle Database checks whether the user has the
ADMINISTER KEY MANAGEMENT privilege or was authenticated using the
SYSKM administrative privilege. Any
ADMINISTER KEY MANAGEMENT statement will be allowed for the following users:
- A user who is granted the
SYSKMadministrative privilege (this grant is recorded in the password file) and issues the
ADMINISTER KEY MANAGEMENTstatement from a session that connected to the database using the
AS SYSKMclause. For example:
sqlplus c##sec_admin AS SYSKM Enter password: password
The reason for this is that
ADMINISTER KEY MANAGEMENTstatements need to be supported when the Oracle data dictionary is not available. The only way to do the necessary privilege check in that situation is to check for the
SYSKMadministrative privilege in the password file. Note that the system needs to be configured with a password file in order to be able to grant the
SYSKMadministrative privilege to a user. If the user needs to perform
ADMINISTER KEY MANAGEMENToperations such as opening the TDE keystore when the Oracle database is in the
MOUNTEDstate, then the user must be granted the
- A user who has been granted the
ADMINISTER KEY MANAGEMENTsystem privilege, and logs in to the database without the
AS SYSKMclause. For example:
sqlplus c##sec_officer Enter password: password
To use TDE, you do not need the
ADMINISTER KEY MANAGEMENT privileges. You must have the following privileges to encrypt table columns and tablespaces:
ALTER TABLESPACE(for online and offline tablespace encryption)
ALTER DATABASE(for offline tablespace encryption)
2.5 Types and Components of Transparent Data Encryption
Transparent Data Encryption can be applied to individual columns or entire tablespaces.
2.5.1 About Transparent Data Encryption Types and Components
You can encrypt sensitive data at the column level or the tablespace level.
At the column level, you can encrypt sensitive data in application table columns. TDE tablespace encryption enables you to encrypt all of the data that is stored in a tablespace.
Both TDE column encryption and TDE tablespace encryption use a two-tiered key-based architecture. Unauthorized users, such as intruders who are attempting security attacks, cannot read the data from storage and back up media unless they have the TDE master encryption key to decrypt it.
2.5.2 How Transparent Data Encryption Column Encryption Works
Transparent Data Encryption (TDE) column encryption protects confidential data, such as credit card and Social Security numbers, that is stored in table columns.
TDE column encryption uses the two-tiered key-based architecture to transparently encrypt and decrypt sensitive table columns. The TDE master encryption key is stored in an external keystore, which can be an Oracle wallet, Oracle Key Vault, or the Oracle Cloud Infrastructure key management service (KMS). This TDE master encryption key encrypts and decrypts the TDE table key, which in turn encrypts and decrypts data in the table column.
Figure 2-1 shows an overview of the TDE column encryption process.
Figure 2-1 TDE Column Encryption Overview
Description of "Figure 2-1 TDE Column Encryption Overview"
As shown in Figure 2-1, the TDE master encryption key is stored in an external security module that is outside of the database and accessible only to a user who was granted the appropriate privileges. For this external security module, Oracle Database uses an Oracle software keystore (wallet, in previous releases) or an external key manager keystore. Storing the TDE master encryption key in this way prevents its unauthorized use.
Using an external security module separates ordinary program functions from encryption operations, making it possible to assign separate, distinct duties to database administrators and security administrators. Security is enhanced because the keystore password can be unknown to the database administrator, requiring the security administrator to provide the password.
When a table contains encrypted columns, TDE uses a single TDE table key regardless of the number of encrypted columns. Each TDE table key is individually encrypted with the TDE master encryption key.
2.5.3 How Transparent Data Encryption Tablespace Encryption Works
Transparent Data Encryption (TDE) tablespace encryption enables you to encrypt an entire tablespace.
All of the objects that are created in the encrypted tablespace are automatically encrypted. TDE tablespace encryption is useful if your tables contain sensitive data in multiple columns, or if you want to protect the entire table and not just individual columns. You do not need to perform a granular analysis of each table column to determine the columns that need encryption.
In addition, TDE tablespace encryption takes advantage of bulk encryption and caching to provide enhanced performance. The actual performance impact on applications can vary.
TDE tablespace encryption encrypts all of the data stored in an encrypted tablespace including its redo data. TDE tablespace encryption does not encrypt data that is stored outside of the tablespace. For example,
BFILE data is not encrypted because it is stored outside the database. If you create a table with a
BFILE column in an encrypted tablespace, then this particular column will not be encrypted.
All of the data in an encrypted tablespace is stored in encrypted format on the disk. Data is transparently decrypted for an authorized user having the necessary privileges to view or modify the data. A database user or application does not need to know if the data in a particular table is encrypted on the disk. In the event that the data files on a disk or backup media is stolen, the data is not compromised.
TDE tablespace encryption uses the two-tiered, key-based architecture to transparently encrypt (and decrypt) tablespaces. The TDE master encryption key is stored in a security module (Oracle wallet, Oracle Key Vault, or Oracle Cloud Infrastructure (OCI) key management service (KMS)). This TDE master encryption key is used to encrypt the TDE tablespace encryption key, which in turn is used to encrypt and decrypt data in the tablespace.
Figure 2-2 shows an overview of the TDE tablespace encryption process.
Figure 2-2 TDE Tablespace Encryption
Description of "Figure 2-2 TDE Tablespace Encryption"
The encrypted data is protected during operations such as
SORT. This means that the data is safe when it is moved to temporary tablespaces. Data in undo and redo logs is also protected.
TDE tablespace encryption also allows index range scans on data in encrypted tablespaces. It does not interfere with ExaData Hybrid Columnar Compression (EHCC), Oracle Advanced Compression, or Oracle Recovery Manager (Oracle RMAN) compression. This is not possible with TDE column encryption.
2.5.4 How the Keystore for the Storage of TDE Master Encryption Keys Works
To control the encryption, you use a keystore and a TDE master encryption key.
184.108.40.206 About the Keystore Storage of TDE Master Encryption Keys
Oracle Database provides a key management framework for Transparent Data Encryption (TDE) that stores and manages keys and credentials.
The key management framework includes the keystore to securely store the TDE master encryption keys and the management framework to securely and efficiently manage keystore and key operations for various database components.
The Oracle keystore stores a history of retired TDE master encryption keys, which enables you to rotate the TDE master encryption key, and still be able to decrypt data (for example, for incoming Oracle Recovery Manager (Oracle RMAN) backups) that was encrypted under an earlier TDE master encryption key.
220.127.116.11 Benefits of the Keystore Storage Framework
The key management framework provides several benefits for Transparent Data Encryption.
Enables separation of duty between the database administrator and the security administrator who manages the keys. You can grant the
ADMINISTER KEY MANAGEMENTor
SYSKMprivilege to users who are responsible for managing the keystore and key operations.
Facilitates compliance, because it helps you to track encryption keys and implement requirements such as keystore password rotation and TDE master encryption key re-key operations. Both wallet password rotations and TDE master key re-key operation do not require database or application downtime.
Facilitates and helps enforce keystore backup requirements. A backup is a copy of the password-protected software keystore that is created for all of the critical keystore operations.
WITH BACKUPclause of the
ADMINISTER KEY MANAGEMENTstatement creates a backup of the password-protected wallet before the changes are applied to the original password-protected wallet.
Enables the keystore to be stored on an Oracle Automatic Storage Management (Oracle ASM) file system. This is particularly useful for Oracle Real Application Clusters (Oracle RAC) environments where database instances share a unified file system view. In Oracle RAC, you must store the Oracle wallet in a shared location (Oracle ASM or Oracle Advanced Cluster File System (ACFS)), to which all Oracle RAC instances that belong to one database, have access to. Individual TDE wallets for each Oracle RAC instances are not supported.
Enables reverse migration from an external keystore to a file system-based software keystore. This option is useful if you must migrate back to a software keystore.
18.104.22.168 Types of Keystores
Oracle Database supports software keystores, Oracle Key Vault, and other PKCS#11 compatible key management devices.
Figure 2-3 Oracle Database Supported Keystores
Description of "Figure 2-3 Oracle Database Supported Keystores"
These keystores are as follows:
Auto-login software keystores: Auto-login software keystores are protected by a system-generated password, and do not need to be explicitly opened by a security administrator. Auto-login software keystores are automatically opened when accessed. Auto-login software keystores can be used across different systems. If your environment does not require the extra security provided by a keystore that must be explicitly opened for use, then you can use an auto-login software keystore. Auto-login software keystores are ideal for unattended scenarios (for example, Oracle Data Guard standby databases).
Local auto-login software keystores: Local auto-login software keystores are auto-login software keystores that are local to the computer on which they are created. Local auto-login keystores cannot be opened on any computer other than the one on which they are created. This type of keystore is typically used for scenarios where additional security is required (that is, to limit the use of the auto-login for that computer) while supporting an unattended operation. You cannot use local auto-open wallets in Oracle RAC-enabled databases, because only shared wallets (in ACFS or ASM) are supported.
Password-protected software keystores: Password-protected software keystores are protected by using a password that you create. You must open this type of keystore before the keys can be retrieved or used.
Software keystores can be stored in Oracle Automatic Storage Management (Oracle ASM), Oracle Advanced Cluster File System (Oracle ACFS), or regular file systems.
Under External Keystore Manager are the following categories:
Oracle Key Vault (OKV): Oracle Key Vault is a software appliance that provides continuous key availability and scalable key management through clustering with up to 16 Oracle Key Vault nodes, potentially deployed across geographically distributed data centers. It is purpose-build for Oracle Database and its many deployment models (Oracle RAC, Oracle Data Guard, Exadata, multitenant environments). In addition, Oracle Key Vault provides online key management for Oracle GoldenGate encrypted trail files and encrypted ACFS. It is also certified for ExaDB-C@C and Autonomous Database (dedicated) (ADB-C@C). Oracle Key Vault is also available in the OCI Marketplace and can be deployed in your OCI tenancy quickly and easily (watch video).
- OCI Vault - Key Management: This is a fully managed service and provides centralized management of your encryption keys to protect your data stored only in OCI. The vision of Key Management is to support different types of encryption keys (symmetric and asymmetric) and generic set of workloads including Oracle Database TDE and non-database workloads. OCI Vault is the native Gen2 Cloud encryption service.
2.5.5 Supported Encryption and Integrity Algorithms
The supported Advanced Encryption Standard cipher keys, including tablespace and database encryption keys, can be either 128, 192, or 256 bits long.
Tablespace and database encryption use AES128 by default, unless the default encryption algorithm is changed to AES192 or AES256 with the
TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM dynamic initialization parameter.
For TDE column encryption, salt is added by default to plaintext before encryption unless specified otherwise. You cannot add salt to indexed columns that you want to encrypt. For indexed columns, choose the
NO SALT parameter for the SQL
For TDE tablespace encryption and database encryption, the default encryption algorithm is AES128. By default, TDE column encryption uses the AES192.
You can change encryption algorithms and encryption keys on existing encrypted columns by setting a different algorithm with the SQL
Table 2-1 lists the supported encryption algorithms.
Table 2-1 Supported Encryption Algorithms for Transparent Data Encryption
|Algorithm||Key Size||Parameter Name|
Advanced Encryption Standard (AES)
Triple Encryption Standard (DES)
For integrity protection of TDE column encryption, the
SHA-1 hashing algorithm is used. (Starting with Oracle Database release 21c,
SHA-1 is deprecated. If you use TDE column encryption, then Oracle recommends that you implement TDE tablespace encryption instead.)
2.6 Transparent Data Encryption in a Multitenant Environment
In a multitenant environment, you can configure keystores for either the entire container database (CDB) or for individual pluggable databases (PDBs).
Oracle Database supports the following multitenant modes for the management of keystores:
United mode enables you to configure one keystore for the CDB root and any associated united mode PDBs. United mode operates much the same as how TDE was managed in an multitenant environment in previous releases.
Isolated mode enables you to create and manage both keystores and TDE master encryption keys in an individual PDB. Different isolated mode PDBs can have different keystore types.
You can use these modes to configure software keystores, external keystores, and Oracle Key Vault keystores.
Depending on your site’s needs, you can use a mixture of both united mode and isolated mode. For example, if you want most of the PDBs to use one type of a keystore, then you can configure the keystore type in the CDB root (united mode). For the PDBs in this CDB that must use a different type of keystore, then you can configure the PDB itself to use the keystore it needs (isolated mode). The isolated mode setting for the PDB will override the united mode setting for the CDB.
Before you can configure keystores for use in united or isolated mode, you must perform a one-time configuration by using initialization parameters. To configure keystores for united mode and isolated mode, you use the
ADMINISTER KEY MANAGEMENT statement. After you restart the database, where you can use the
ADMINISTER KEY MANAGEMENT statement commands will change. For example, before the configuration, you could not use the
EXTERNAL STORE clause in the
ADMINISTER KEY MANAGEMENT statement in the CDB root, but after the configuration, you can.
2.7 Transparent Data Encryption Keystore Search Order
The search order for the TDE keystore depends on how you have set either the instance initialization parameters, the
sqlnet.ora parameters, or the environment variables.
Oracle Database retrieves the keystore by searching in these locations, in the following order:
The location set by the
WALLET_ROOTinstance initialization parameter, when the
KEYSTORE_CONFIGURATIONattribute of the
TDE_CONFIGURATIONinitialization parameter is set. Oracle recommends that you use this parameter to configure the keystore location.
KEYSTORE_CONFIGURATIONattribute of the
TDE_CONFIGURATIONinitialization parameter is not set or
WALLET_ROOTis not set, then the location specified by the
ENCRYPTION_WALLET_LOCATIONsetting (now deprecated in favor of
WALLET_ROOT) in the
If none of these parameters are set, and if the
ORACLE_BASEenvironment variable is set, then the
ORACLE_BASEis not set, then