Entropy Database Security

Born encrypted: Oracle AI Database 26ai TDE has come a long way; from the humble beginnings of TDE column encryption in Oracle Database 10gR2 in July 2005 to automated and mandatory encryption for all Oracle databases that are controlled by OCI. Starting with Oracle database 21c, DBCA (Database Configuration Assistant) can create encrypt ed (primary and standby) databases; this is do cumented here  for 21c and here  for 26ai (did you notice that TDE in 26ai has its own documentation book, separated from Data Redaction?) Here is the 26ai dbca code part that encrypts your new database:     -configureTDE TRUE  \     -tdeWalletRoot /local/directory/for/TDE/  \     -tdeWalletLoginType LOCAL_AUTO_LOGIN  \     -TdeWalletPassword <TDE wallet password>  \     -encryptTablespaces SYSTEM:true,SYSAUX:true,USERS:true  \     -createTDESepsWallet Some remarks: Default for "-encryptTablespaces": USERS t...

Did you miss the "TDE Academy"? A long time ago, I published three videos on YouTube that go through a complete upgrade of encrypted PDBs from 12.1.0.2, 12.2.0.1 and 18c databases to 19c. At one point, they were made private. Here are the links: Upgrade encrypted PDBs to 19c from 18c: https://youtu.be/onIQ3CDsjik 12.2.0.1.: https://youtu.be/oJipexiHBXk 12.1.0.2.: https://youtu.be/ql6352lmi24 You can also find those links in chapter 7.8.3.4. of the 19c Advanced Security Guide. Happy upgrading !! 

Encryption and Compression in Exadata: How It Really Works After a great vacation, I'm finally back with a new blog post. This one is about two weeks later than my usual Thursday schedule, but I hope you'll find it worth the wait. Today's topic is a question that comes up surprisingly often: how do compression and Transparent Data Encryption (TDE) actually work in Oracle Exadata? The answer is actually quite simple - with one important exception. Everything described here applies equally to Oracle Exadata and all of its deployment models, including ExaDB-C@C, ADB-C@C, ADB-D, and ExaDB-D, whether deployed on-premises, in OCI, or in supported third-party clouds. The Normal Data Path The fundamental rule is simple: Compression always happens before encryption. This has to be the case because encrypted data is essentially random and therefore cannot be compressed efficiently. Oracle's implementation of TDE tablespace encryption is fully compatible with Oracle compression t...

This video explains "split TDE", which was introduced in Oracle Database 19.16 and simplifies on-prem to cloud migration (and repatriation) for customers who do not have an on-prem TDE license but are subject to an encryption mandate for their Oracle cloud databases (The encryption mandate applies to all Oracle databases that are manged by OCI, regardless of the cloud provider, unless you choose to manually install your databases in a cloud compute node).

  Oracle AI Database 26ai has been made available to all customers (on-prem or any cloud). With this, the "upgrade" question will come sooner rather than later. Upgrading to Oracle AI Database 26ai  is only possible from 19c and 21c , older releases cannot be directly upgraded to 26ai. If your 19c or 21c databases are encrypted, and TDE is set up with the old (desupported) sqlnet.ora parameters (ENCRYPTION_WALLET_LOCATION), upgrades will be blocked and pre-upgrade checks will fail with 'TDE_WALLET_ROOT_NOT_IN_USE'. You need to have WALLET_ROOT and TDE_CONFIGURATION set before the upgrade. Also, the GOST and ARIA encryption algorithms are desupported in 26ai; before upgrading, online-rekey those tablespaces to AES with XTS cipher mode; for upgrades via database links to 26ai CDBs, we have introduced the "rekey using" parameter: SQL> create pluggable database "FINANCE" from FINANCE@dblink rekey using 'AES256' MODE 'XTS'; ...

TDE HEALTHCHECK  The TDE health-check was planned to give Oracle Support personnel a quick overview about your TDE setup, but eventually it was decided to include it in recent Oracle Database RUs in 19c and 26ai. In Oracle database 19c before 19.30, you need to apply patch 38486044 . It is very easy to use: First, compile it with: SQL> @$ORACLE_HOME/rdbms/admin/tde_healthcheck.sql To get the complete results, simply execute: SQL> execute tde_healthcheck.get_tde_healthcheck_report; Individual checks allow for a more targeted validation: SQL> exec tde_healthcheck.get_wallet_root; Display WALLET_ROOT from gv$parameter.  SQL> exec tde_healthcheck.get_wallet_ location; Where are my TDE wallets? Usually in WALLET_ROOT/tde   SQL> exec tde_healthcheck.get_tde_config; Shows the value of the parameter TDE_CONFIGURATION. SQL> exec tde_healthcheck.get_props_ details; Read the TDE configuration from internal tables.  SQL> exec tde_healthcheck.valida...

  As organizations continue to strengthen their database security posture, centralizing encryption key management has become an increasingly important operational and compliance requirement. Oracle Key Vault (OKV) provides a secure, scalable platform for managing Transparent Data Encryption (TDE) master keys across enterprise database environments. When migrating existing encrypted Oracle RAC databases from traditional wallet-based key management to OKV, careful planning can help ensure a smooth transition while preserving access to both current and historical encryption keys.  Before migrating an encrypted, RAC-enabled database from a shared local TDE wallet to OKV, it is recommended to leverage OKV's unique capability and upload the current and all retired TDE keys to OKV. In Oracle RAC, only shared wallets (for example stored in ACFS or directly in ASM) that can be accessed by all RAC instances are supported. Using individual TDE wallets for each RAC node is ...