Entropy Database Security

Why this matters - Executive summary:   New Oracle AI database 26ai can be encrypted and have its encryption keys centrally managed from creation, not through a separate migration project later. That's eliminating, not just reducing, complexity: the same dbca command with a few more lines replaces a follow-on project. Ask your team how key management is handled today; if the answer involves a spreadsheet or a wallet file on a server, you have your answer. _____________________________________________________________________________________________   Two weeks ago I talked about " born encrypted " for Oracle Databases 21c and 26ai. Many readers have asked about key management in such a scenario. That makes sense; when all databases are encrypted from the start, proper key management becomes a requirement. With Oracle, you are in good hands: This dbca code in Oracle AI database 26ai will encrypt your database while it is being built, and the TDE master keys live in Or...

Why this matters - Executive summary: New Oracle AI database 26ai can be encrypted the moment they're created, not "later" when all stars align. That closes a real exposure window regulators and auditors specifically look for, with far less engineering effort than the manual approach. If your team is building new databases and isn't already doing this by default, that's a gap worth closing now.  ____________________________________________________________________________________________ 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?) ...

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 !!  __________________________________________________________________________________________ Contact me via email or WhatsApp , I read every message.

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 technologies, including Exadata Hybrid Columnar Compression ...

  Why this matters - Executive summary: Not having an on-prem TDE license no longer hinders your plans into or out of a cloud. Split TDE meets OCI's encryption mandate directly, without a license purchase blocking the migration or the repatriation. _____________________________________________________________________________________________  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). __________________________________________________________________________________________ Contact me via email or WhatsApp , I read every message.

  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...