TDE transparently encrypts data at rest in Oracle Databases. It stops unauthorized attempts from the operating system to access database data stored in files, without impacting how applications access the data using SQL. TDE can encrypt entire application tablespaces or specific sensitive columns. TDE is fully integrated with Oracle database. Encrypted data remains encrypted in the database, whether it is in tablespace storage files, temporary tablespaces, undo tablespaces, or other files that Oracle Database relies on such as redo logs. Also, TDE can encrypt entire database backups (RMAN) and Data Pump exports.
TDE is transparent to business applications and does not require application changes. Encryption and decryption occur at the database storage level, with no impact to the SQL interface that applications use (neither inbound SQL statements, nor outbound SQL query results).
Note that TDE is certified for use with common packaged applications. These certifications are mainly for profiling TDE performance under different application workloads and for capturing application deployment tips, scripts, and best practices. Some application vendors do a deeper integration and provide TDE configuration steps using their own toolkits.
Our recommendation is to use TDE tablespace encryption. TDE tablespace encryption has better, more consistent performance characteristics in most cases. Moreover, tablespace encryption in particular leverages hardware-based crypto acceleration where it is available, minimizing the performance impact even further to the 'near-zero' range. Support for hardware-based crypto accelaration is available since Oracle Database 11g Release 2 Patchset 1 (11.2.0.2) for Intel chipsets with AES-NI and modern Oracle SPARC processors.
For more details on TDE column encryption specific to your Oracle Database version, please see the Advanced Security Guide under Security on the Oracle Database product documentation that is available here.
| TDE tablespace encryption (Oracle Database 11g+) | |
|---|---|
| Storage | No additional storage overhead. |
| Performance | According to internal benchmarks and feedback from our customers running production workloads, the performance overhead is typically in the single digits. Starting with Oracle Database 11g Release 2 Patchset 1 (11.2.0.2), the hardware crypto acceleration based on AES-NI available in recent Intel processors is automatically leveraged by TDE tablespace encryption, making TDE tablespace encryption a 'near-zero impact' encryption solution. |
No, it is not possible to plug-in other encryption algorithms. Oracle provides encryption algorithms that are broadly accepted, and will add new standard algorithms as they become available.
Begining with Oracle Database 18c, you can create a user-defined master encryption key instead of requiring that TDE master encryption keys always be generated in the database. This is often referred in the industry to as bring your own key (BYOK).
For more details on BYOK, please see the Advanced Security Guide under Security on the Oracle Database product documentation that is available here.
There are no limitations for TDE tablespace encryption.
For information TDE column encryption restrictions, refer to the Advanced Security Guide section titled "About Encrypting Columns in Tables" that is under Security on the Oracle Database product documentation that is available here.
Data encrypted with TDE is decrypted when it is read from database files. If this data goes on the network, it will be in clear-text. However, the data in transit can be encrypted using Oracle's Native Network Encryption or TLS. This will encrypt all data traveling to and from an Oracle Database over SQL*Net.
It is always good to know what sensitive data is stored in your databases and to do that Oracle provides the Oracle Database Security Assessment Tool, Enterprise Manager Application Data Modelling, or if you have Oracle Databases in the Cloud - Data Safe. This identification is key to apply further controls to protect your data but not essential to start your encryption project. Due the latest advances in chipsets that accelerate encrypt/decrypt operations, evolving regulatory landscape, and the ever evolving concept of what data is considered to be sensitive, most customers are opting to encrypt all application data using tablespace encryption and storing the master encryption key in Oracle Key Vault.
DBMS_CRYPTO package can be used to manually encrypt data within the database. However, the application must manage the encryption keys and perform required encryption and decryption operations by calling the API. This approach requires significant effort to manage and incurs performance overhead. TDE tablespace encryption doesn't require changes to the application, is transparent to the end users, and provides automated, built-in key management.
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.
The TDE master encryption key is stored in an external security module (software or hardware keystore). By default, TDE stores its master key in an Oracle Wallet, a PKCS#12 standards-based key storage file. Wallets provide an easy solution for small numbers of encrypted databases. Customers with many Oracle databases and other encrypted Oracle servers can license and use Oracle Key Vault, a security hardened software appliance that provides centralized key and wallet management for the enterprise. It uses industry standard OASIS Key Management Interoperability Protocol (KMIP) for communications. Customers can keep their local Oracle Wallets and Java Keystores, using Key Vault as a central location to periodically back them up, or they can remove keystore files from their environment entirely in favor of always-on Key Vault connections. All network connections between Key Vault and database servers are encrypted and mutually authenticated using SSL/TLS. TDE master keys can be rotated periodically according to your security policies with zero downtime and without having to re-encrypt any stored data. Historical master keys are retained in the keystore in case encrypted database backups must be restored later. Master keys in the keystore are managed using a set of SQL commands (introduced in Oracle Database 12c). For separation of duties, these commands are accessible only to security administrators who hold the new SYSKM administrative privilege or higher. In addition to using SQL commands, you can manage TDE master keys using Oracle Enterprise Manager 12c or 13c.
TDE supports AES256, AES192 (default for TDE column encryption), AES128 (default for TDE tablespace encryption), ARIA128, ARIA192, ARIA256, GOST256, SEED128, and 3DES168.
TDE master key management uses standards such as PKCS#12 and PKCS#5 for Oracle Wallet keystore. Oracle Key Vault uses OASIS Key Management Interoperability Protocol (KMIP) and PKCS #11 standards for communications. Customers can choose Oracle Wallet or Oracle Key Vault as their preferred keystore.
The cryptographic library that TDE uses in Oracle Database 19c is validated for U.S. FIPS 140-2. See here for the library’s FIPS 140 certificate (search for the text “Crypto-C Micro Edition”; TDE uses version 4.1.2). Also, see here for up-to-date summary information regarding Oracle Database certifications and validations.
TDE tablespace encryption leverages Oracle Exadata to further boost performance. For example, Exadata Smart Scans parallelize cryptographic processing across multiple storage cells, resulting in faster queries on encrypted data. TDE also benefits from support of hardware cryptographic acceleration on server processors in Exadata. TDE integration with Exadata Hybrid Columnar Compression (EHCC) compresses data first, improving cryptographic performance by greatly reducing the total amount of data to encrypt and decrypt.
Oracle provides additional data at rest encryption technologies that can be paired with TDE to protect unstructured file data, storage files of non-Oracle databases, and more as shown in the table below.
Other encryption technologies
| Use Case | Oracle Technology |
|---|---|
| Encrypt files (non-tablespace) using Oracle file systems and operating systems |
|
| Encrypt files (non-tablespace) using Oracle Database |
|
| Encrypt data programmatically in the database tier |
|
| Encrypt data programmatically in the application tier |
|
Oracle provides solutions to encrypt sensitive data in the application tier – although this has implications for databases that you must consider in advance (see details here). Note that TDE is the only recommended solution specifically for encrypting data stored in Oracle Database tablespace files.
Oracle Transparent Data Encryption and Oracle RMAN
| Application data | Backup with RMAN compression | Backup with RMAN encryption | Backup with RMAN compression and encryption |
|---|---|---|---|
| Not encrypted | Data compressed | Data encrypted | Data compressed first, then encrypted |
| Encrypted with TDE column encryption | Data compressed; encrypted columns are treated as if they were not encrypted | Data encrypted; double encryption of encrypted columns | Data compressed first, then encrypted; encrypted columns are treated as if they were not encrypted; double encryption of encrypted columns |
| Encrypted with TDE tablespace encryption | Encrypted tablespaces are decrypted, compressed, and re-encrypted | Encrypted tablespaces are passed through to the backup unchanged | Encrypted tablespaces are decrypted, compressed, and re-encrypted |
An Oracle Advanced Security license is required to encrypt RMAN backups to disk, regardless if the TDE master encryption key or a passphrase is used to encrypt the file.
Yes, but it requires that the wallet containing the master key is copied (or made available, for example using Oracle Key Vault) to the secondary database. If the tablespace is moved and the master key is not available, the secondary database will return an error when the data in the tablespace is accessed.
Customers using TDE tablespace encryption get the full benefit of compression (standard and Advanced Compression, as well as Exadata Hybrid Columnar Compression (EHCC)) because compression is applied before the data blocks are encrypted. Customers using TDE column encryption will get the full benefit of compression only on table columns that are not encrypted. Individual table columns that are encrypted using TDE column encryption will have a much lower level of compression because the encryption takes place in the SQL layer before the advanced compression process.
TDE provides multiple techniques to migrate existing clear data to encrypted tablespaces or columns. Solutions are available for both online and offline migration. Existing tablespaces can be encrypted online with zero downtime on production systems or encrypted offline with no storage overhead during a maintenance period. Online tablespace conversion is available on Oracle Database 12.2.0.1 and above whereas offline tablespace conversion has been backported on Oracle Database 11.2.0.4 and 12.1.0.2.
Alternatively, you can copy existing clear data into a new encrypted tablespace with Oracle Online Table Redefinition (DBMS_REDEFINITION). It copies in the background with no downtime. This approach works for both 11g and 12c databases. This approach includes certain restrictions described in Oracle Database 12c product documentation. Customers with Oracle Data Guard can use Data Guard and Oracle Data Pump to encrypt existing clear data with near zero downtime (see details here). This procedure encrypts on standby first (using DataPump Export/Import), switches over, and then encrypts on the new standby. Database downtime is limited to the time it takes to perform Data Guard switch over. Multiple synchronization points along the way capture updates to data from queries that executed during the process. If you plan to migrate to encrypted tablespaces offline during a scheduled maintenance period, then you can use Data Pump to migrate in bulk. You also can use SQL commands such as ALTER TABLE MOVE, ALTER INDEX REBUILD (to move an index), and CREATE TABLE AS SELECT to migrate individual objects. With TDE column encryption, you can encrypt an existing clear column in the background using a single SQL command such as ALTER TABLE MODIFY. This is a fully online operation.
Starting in Oracle Database 11g Release 2, customers of Oracle Advanced Security Transparent Data Encryption (TDE) optionally may store the TDE master encryption key in an external device using the PKCS11 interface. In this setup, the master key is stored directly in the third-party device rather than in the included Oracle Wallet.
When using PKCS11, the third-party vendor provides the storage device, PKCS11 software client library, secure communication from the device to the PKCS11 client (running on the database server), authentication, auditing, and other related functionality. The vendor also is responsible for testing and ensuring high-availability of the TDE master encryption key in diverse database server environments and configurations. Customers should contact the device vendor to receive assistance for any related issues.
TDE is part of the Oracle Advanced Security, which also includes Data Redaction. It is available as an additional licensed option for the Oracle Database Enterprise Edition. In Oracle Autonomous Databases and Database Cloud Services it is included, configured, and enabled by default.
For more information about the benefits of TDE, please see the product page on Oracle Technology Network. A variety of helpful information is available on this page including product data sheet, customer references, videos, tutorials, and more.
For more best practices for your specific Oracle Database version, please see the Advanced Security Guide under Security on the Oracle Database product documentation that is available here.