Copy TDE wallets out of and into ASM with kscopy

 

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

Uploading the TDE keys from wallets in ASM required a few extra steps, since okvutil doesn't understand the ASM syntax. 

First, create a new wallet on the local file system:

SQL> administer key management create keystore '/future/wallet/root/tde/' identified by "new wallet password";

Then, merge the content of the ASM wallet into the new wallet, effectively copying the TDE keys into the new wallet:

SQL> administer key management merge keystore '+DATA/$DB_NAME/tde' into existing keystore '/future/wallet/root/tde/' identified by "new wallet password" with backup;

Instead of the above commands, you can use (in recent 19c DB RUs and 26ai):

$ asmcmd kscopy +DATA/$DB_NAME/tde/ewallet.p12 /future/wallet/root/tde/

kscopy can copy auto-login wallets, but I prefer to create a LOCAL auto-login wallet from the password-protected wallet.

Link to LinkedIn post.

Location: San Diego, Kalifornien, USA

Comments

Post a Comment

Popular posts from this blog

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

Upgrade encrypted databases to 26ai

  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'; ...
Read more