Oracle transparent data encryption (TDE) real-world use analysis, oracletde

Oracle transparent data encryption (TDE) real-world use analysis, oracletde

Since the R2 version of Oracle Database 1Og, a feature called TDE makes data encryption extremely easy. All we need to do is to declare a column as encrypted, and the rest is done by Oracle. When a user inputs data, the column value is intercepted and encrypted, and then saved in the encrypted format. Then, when this column is queried, the column value is automatically decrypted, And the decrypted text (plaintext) is returned to the user. Users do not even need to know That encryption and decryption have occurred-that is, transparent. All are completed internally by the Oracle code without any triggers or complicated process logic.

The following is an example of using TDE:

To declare the SSN column in the table ACCOUNTS as encrypted, you only need to declare it as follows:

ALTER TABLE accounts MODIFY  (ssn ENCRYPT  USING  'AES256')

The Oracle database uses the AES algorithm and a 256-bit key to encrypt the SSN-column immediately. The key is stored in the data dictionary table. To prevent theft, the key is encrypted with a CMK, which is stored in a separate wallet location. This wallet is available at $ ORACLE_BASE/admin/$ ORACLE-SID/wallet. However, you can specify a different location in the SQLNET. ORA file.

When you use the following statement to insert data:

 INSERT INTO accounts (ssn) VALUES (’123456789’)

The actual value is stored in the data file, redo log, and archive log in encrypted format, so it is also stored in the backup file. When a user queries this data in the future, the encrypted value is automatically decrypted and the initial value is displayed. Before executing the preceding statements, the DBA or security administrator must open the wallet.

TDE has only one purpose: Encrypt Sensitive data at the minimum cost to avoid possible damage to data file theft. However, note that the emphasis is on transparency-that is, encryption is performed automatically and decryption is the same. In the database. Oracle does not differentiate users. When a user queries a database, Oracle will give the user a plaintext value no matter who the user is verified.

TDE also has some limitations:

On the one hand, TDE cannot be used for external key columns, which is indeed a limitation for many enterprise applications. On the other hand, we can only create B-tree indexes for columns that use TDE. However, if we use PL/SQL to implement our own encryption process, these restrictions will not matter. Automation is another aspect that we must consider when determining whether TDE can meet our goals. For TDE, the wallet (where the master key is stored) must be opened by the DBA using a command similar to the following:

ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY "pooh"

The password of the preserved bag is "pooh ". If the database data files (or redo log files, or backup files of these files) are stolen, because the thief does not know that the contents of the "pool" encryption column of the password are still encrypted, with this password, he can open his wallet. After each database is started, the wallet must be opened explicitly by the DBA before encryption can be used for insertion or access. If the wallet is not opened, insertion and access to these columns will fail. Therefore, this is an additional step after the database is opened. In addition, we must ensure that the person in charge of opening the database knows the password of the wallet.
To make this step easier and more automated, we generally consider creating a database startup trigger and calling the alter system Command (shown earlier) to open the wallet. However, if you do this, the trigger will remove the unique protection for the wallet, followed by the encrypted column. Therefore, if we use TDE, we will never be able to use such a start trigger. We must prepare to execute an additional step after each database startup. However, if we build our own encryption infrastructure, it will be available as long as the database starts, no additional steps are required, and no wallet password needs to be remembered and input.
In general. TDE has limited functions. It provides a quick and easy way to encrypt data files, redo logs, and backup files. However, it does not protect data based on different users; its decryption is based on access. If we need more control over the decryption process, we need to rely on our own encryption infrastructure.

In many cases, we still need to construct a more complex system. In this system, only when the user sending the request is indeed authorized to read the data, the decrypted plaintext is displayed to him. If not, the encrypted value is returned. It is impossible to use TDE to meet this requirement, because TDE decrypts all data indiscriminately. However, we can build our own architecture to achieve this goal.