In today’s digital landscape, organizations are increasingly reliant on data to drive their operations and decision-making processes. However, with the rise of cyber threats, it is crucial for organizations to understand the importance of securing data at rest. This blog will explore the why and how we can secure data at rest, will also see why securing data at rest is essential for organizations, the potential risks of neglecting this aspect of data security, and best practices for implementing effective data protection measures.
Any database saves the data on a physical disk drive and there is a chance of data theft and leak of sensitive information to the outer world. Data breaches can have devastating consequences for organizations, including financial loss, reputational damage, and legal repercussions. By implementing robust security measures for data at rest, organizations can significantly reduce the risk of unauthorized access and potential breaches. Data loss can disrupt business operations and lead to significant downtime. By securing data at rest, organizations can implement backup and recovery solutions that ensure data integrity and availability. This is crucial for maintaining business continuity and minimizing the impact of potential data loss incidents. Not all threats come from external sources; insider threats can be equally damaging. Employees or contractors with access to sensitive data may intentionally or unintentionally compromise that data. Implementing security measures for data at rest, such as encryption, can help mitigate the risks associated with insider threats.
How TDE Works
Data Encryption Process: When data is written to a table or tablespace that is protected by TDE, the Oracle Database automatically encrypts the data using either the TDE Table Key or the Tablespace Encryption Key, depending on the level of encryption applied (table or tablespace). The encryption process is transparent to the end-user, meaning that no changes are required in the application code or queries. The data is stored in an encrypted format in the data files.
Data Decryption Process: When an authorized user or application retrieves data from an encrypted table or tablespace, TDE automatically decrypts the data. The appropriate encryption key (TDE Table Key or Tablespace Encryption Key) is retrieved from the keystore, and the data is decrypted before being presented to the user or application. Again, this process is seamless and does not require any special handling by the user.
Keystore Management: The keystore, which houses the master encryption key and other related keys, must be securely managed. Administrators are responsible for ensuring that the keystore is accessible to the Oracle Database but protected from unauthorized access. Proper management of the keystore is critical because if the keystore is compromised or lost, the encrypted data may become inaccessible.
Advantage of TDE
- Data Protection at Rest: TDE ensures that sensitive data remains secure even when stored in the database’s physical files on the operating system. This protection is crucial for compliance with data protection regulations and safeguarding against data breaches.
- Seamless Implementation: Since TDE operates transparently at the database level, no modifications to existing applications or database schemas are required. The encryption and decryption processes are handled automatically by the database, simplifying the implementation of data security.
- Centralized Key Management: By using an external keystore for encryption key management, TDE provides centralized control over key usage and rotation. This centralization ensures that encryption keys are properly managed and protected, further enhancing data security.
TDE can be implemented in two ways as mentioned below, however for most modern Oracle environments, tablespace encryption is preferred due to simplicity and performance
(A) Tablespace-level data (entire tablespaces)
(B) Column-level data (specific columns like credit card numbers)
Here, we are going to discuss Tablespace level transparent data encryption.
Configure the Wallet Root
Create a directory, called wallet, in the < Wallet file location > directory.
Log in to the database as a user with the SYSDBA administrative privilege.
Set the WALLET_ROOT parameter.
Alter system set wallet_root=” scope=spfile;
Shut down and start up the database.
Set the TDE_CONFIGURATION parameter as follows:
alter system set TDE_CONFIGURATION=”KEYSTORE_CONFIGURATION=FILE”;
Create the password protected key store
Login to your Oracle database, and run the following commands to create a wallet and a master encryption key
#Only on Primary node#
administer key management create keystore identified by “xxxxx”;
Note: OPEN_NO_MASTER_KEY -> Keystore is already not OPEN use the below command to open
administer key management set keystore open identified by xxxxx”;
administer key management create LOCAL auto_login keystore from keystore ” identified by “xxxxxx”;
To Check the details, we can query gv$encryption_wallet data dictionary view.
Key Benefits of AI-Driven Compliance Reviews
The adoption of AI code reviews for compliance delivers significant benefits across both technical and business dimensions:
- Speed: Automated reviews complete in minutes, drastically reducing the time needed for audits.
- Accuracy: AI minimizes human oversight errors by applying consistent logic across the codebase.
- Security Posture: Early detection of vulnerabilities strengthens overall application security.
- Audit Readiness: Automated logs and reports simplify regulatory audits.
- Cost Savings: Catching issues early reduces expensive post-release remediation.
- Developer Productivity: Teams can focus on building features while AI handles compliance checks in the background.
Setup the Master Encryption Key
As we have opened the keystore, the status should reflect as OPEN. In Oracle 19c and above, we need to have a MASTER KEY as well which is why the STATUS column reflects as “OPEN_NO_MASTER_KEY” when gv$encryption_wallet view is queried.
So, create a MASTER KEY using the “administer key management” clause as stated below.
administer key management set key using tag
‘Encr_Tablespace_TDE1’ force keystore identified by “xxxxx” with backup using ‘TDE_backup’;
To Check the above details, we can query v$encryption_keys data dictionary view.
Once KEY is created, the status for the corresponding instance turns out to be OPEN when “gv$encryption_wallet” is queried.
As seen, the wallet file “ewallet.p12” does also contain the master key.
This needs to be copied on to the remaining nodes of the cluster and restart the instances respectively.
Copy this auto login wallet file (cwallet.sso) onto the second node as well and then start the database. Upon this, the wallets should be opened automatically for both the instances.
@STANDBY Site (This is the Disaster Recovery Site)
These steps need to run on standby sites.
Alter system set WALLET_ROOT=’ ‘ scope=spfile;
Let’s copy the wallet files from the primary node and then bounce the standby instances at one go.
SCP all the wallet files (master key file and autologin file) from any one of the primary nodes to the first standby node, post this restart the instance respectively.
Similarly, secure copy (using scp) the same wallet files from the primary node to the second node of the standby cluster as well:
Now it’s time to bounce the standby database and check the wallet status.
The wallets are opened on both the standby nodes and that the wallet type represents as “AUTOLOGIN”.
Testing the transparent data encryption
Here, we will create a normal tablespace post that will do online encryption of segments.
create tablespace no_encr_tbs datafile ‘+DATA’ size 50M;
select FILE_NAME, TABLESPACE_NAME from dba_data_files;
Online Encryption of Tablespace
alter tablespace encryption online encrypt;
create table test (snb number, real_exch varchar2(20)) tablespace NO_ENCR_TBS;
Insert some records to test the result later.
Now it’s time to convert normal tablespace to encrypted tablespace using an online encryption method. Post this the saved records will be in encrypted format.
To check the new changes, dba_tables and v$encrypted_tablespaces data dictionary views can be query.
To display the wallet contents and see if the keys match.
Finally, adopting Oracle Transparent Data Encryptions is not just a technical upgrade – it’s a strategic business decision. In a landscape where data is the new currency, protecting it with robust encryption like TDE is vital for building a resilient, compliant, and trusted banking environment.