Security labels remain in effect. You can use these and other security features in tandem with Transparent Data Encryption encryption.
3. Are there any known Transparent Data Encryption limitations or incompatibilities?
■ TDE column encryption: TDE column encryption encrypts and decrypts data
transparently when data passes through the SQL layer. Some features of Oracle will bypass the SQL layer, and hence cannot benefit from TDE column encryption. The following are known database features that TDE column encryption does not support, and their relevant software version numbers:
– Materialized View Logs (not supported prior to Oracle Database 11g Release 2)
– Streams (not supported prior to Oracle Database 11g Release 1)
– Synchronous and asynchronous change data capture for data warehousing (CDC)
– Transportable Tablespaces
– LOBs
Note that Secure Files were introduced in Oracle Database 11g Release 1, so it is not supported with TDE column encryption prior to that release
■ TDE tablespace encryption: TDE tablespace encryption encrypts all content
that is stored in the tablespace at the block level in storage, and it generally does not conflict with other database features. TDE tablespace encryption does not have any of the limitations that TDE column encryption has. However, you should be aware of the following:
– For Transportable Tablespaces (TTS) that use TDE tablespace encryption, the origin database can be encrypted with TDE, but it requires that the destination database is not encrypted with TDE. This is because you would have to overwrite the Oracle Wallet on the destination database with the origin database’s Oracle Wallet, thus losing access to existing encrypted data on the destination. Also, the origin and destination databases both must share the same endianness.
– Do not attempt to encrypt database internal objects such as the SYSTEM, SYSAUX, UNDO, or TEMP tablespaces using TDE tablespace encryption. You should focus TDE tablespace encryption on tablespaces that hold application data, not on these core components of the Oracle database.
Performance Questions About Transparent Data Encryption
1. What is the typical performance overhead from Transparent Data Encryption?
There are many different variables involved in the creation of an accurate
Transparent Data Encryption performance test. The results can vary depending on the test environment, test case or workload, measurement metrics or methods, and so on. Oracle cannot guarantee a specific performance overhead percentage that can apply in all possible scenarios. In practice, the performance tests by many Transparent Data Encryption customers are often in the low single digits as a percentage, but that is not universally the case. Two customer examples that cite 1 percent and 2 percent overhead respectively are published on Oracle Technology Network in the following URLs:
Performance Questions About Transparent Data Encryption
■ http://streaming.oracle.com/ebn/podcasts/media/12740910_ColumbiaU_ 120312.mp3
■ http://www.oracle.com/us/corporate/customers/customersearch/ets-1-adva nced-security-ss-454388.html
If possible, use Oracle Real Application Testing (Oracle RAT) to capture a real production workload and then replay it against Transparent Data Encryption to get a true indication of the performance overhead that the you can expect within your environment.
See also:
■ "Performance and Storage Overhead of Transparent Data Encryption" on
page 5-3
■ Oracle Database Testing Guide for more information about the Oracle Real
Application Testing option
2. How can I tune for optimal Transparent Data Encryption performance? ■ TDE column encryption:
– Limit the crypto processing by only encrypting the subset of columns that are strictly required to be protected. In addition, turn off the optional integrity checking feature.
– After you apply column encryption, rebuild the column indexes.
■ TDE tablespace encryption: TDE tablespace encryption improves
performance by caching unencrypted data in memory in the SGA buffer cache. This feature reduces the number of crypto operations that must be performed when users run SELECT queries, which draw from the SGA instead of drawing from disk. (Drawing from disk forces the database to perform decrypt
operations.) Ensure that the size of the SGA buffer cache is large enough to take full advantage of this performance optimization.
Another major performance boost comes from using hardware and software that supports CPU-based cryptographic acceleration available in Intel AES-NI and Oracle SPARC T4/T5. To take advantage of this feature, you must be running a recent version of the database, have a recent version of the operating system installed, and be using hardware that includes crypto acceleration circuitry within its CPUs/cores.
Database compression further speeds up Transparent Data Encryption performance because the crypto processing occurs on data that already is compressed, resulting in less total data to encrypt and decrypt.
■ In general:
– Ensure that you have applied the latest patches, which you can download from My Oracle Support at
https://support.oracle.com
– When you specify an encryption algorithm, remember that AES is slightly faster than 3DES. Use AES128 where possible. Be aware that the
performance benefit is small.
– Use Exadata, which includes additional performance benefits. For more information about Oracle Exadata, see Oracle Database Testing Guide.
3. Are there specific issues that may slow down TDE performance, and if so, how do I avoid them?
Performance Questions About Transparent Data Encryption
TDE tablespace performance is slower if the database cannot use CPU-based hardware acceleration on the host machine due to factors such as older hardware, an older database version, or an older operating system.
Note the following with regard to specific database workloads:
■ Encrypting the whole data set at once (for example, while doing “Bulk Data Load” into an Oracle data warehouse): Lower crypto performance has been observed during bulk load of new data into the database or data warehouse. New data cannot be cached in SGA, so TDE tablespace encryption
performance optimizations are bypassed. Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation.
Follow these guidelines:
– Ensure that the database is running on servers with CPU-based
cryptographic acceleration. This accelerates not only decrypt operations, but also encrypt operations as well (for loading new data). Take the crypto processing out of band by pre-encrypting the data set and then using Transportable Tablespaces (TTS) to load into the database. Try to parallelize this procedure where possible. This requires the database instance to copy the required TDE key to the keystore on the destination database. The procedure may not be feasible when there is a fixed time window for encryption and loading, and these must be done serially.
– Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.
■ Decrypting an entire data set at once (for example, while performing a full table scan by reading directly from disk, with no reading from SGA):
Lower crypto performance is observed when running full table scan queries where data is read directly from storage. Certain performance optimizations of TDE tablespace encryption are bypassed (no caching). Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation. Follow these guidelines:
– Ensure that the database is running on servers with CPU-based cryptographic acceleration.
– Retest the full table scan queries with a larger SGA size to measure performance when data is read from cache. Try setting the Oracle event number 10949 to disable direct path read.
– Partition the database so that less data is scanned by full table scan operations. Production databases often use partitioning for this kind of scenario (that is, to limit the total amount of data scanned).
– Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.
Part II
Part II
Using Oracle Data Redaction
Part II contains the following chapters:
■ Chapter 8, "Introduction to Oracle Data Redaction" ■ Chapter 9, "Configuring Oracle Data Redaction Policies"
■ Chapter 10, "Using Oracle Data Redaction with Other Oracle Products" ■ Chapter 11, "Guidelines for Using Oracle Data Redaction"
8
8