How to encrypt plugged PDB inside a encrypted CDB

 Encrypting a plugged Pluggable Database (PDB) inside an encrypted Container Database (CDB) in Oracle involves using Transparent Data Encryption (TDE). The PDB you are plugging into an encrypted CDB will inherit the encryption settings of the CDB if done correctly. Below is a step-by-step guide on how to do this.

Pre-requisites:

  • Oracle Advanced Security: You need Oracle Advanced Security option (or the Oracle Database Vault option) to use Transparent Data Encryption (TDE).
  • TDE Wallet Setup: Your CDB must already be encrypted, which means that TDE and the encryption wallet are configured at the CDB level.

Steps to Encrypt a Plugged PDB Inside an Encrypted CDB:

1. Ensure the CDB is Encrypted:

First, confirm that the CDB into which you are plugging the PDB is already encrypted and using TDE.

Check Wallet Status: Connect to the CDB and run the following SQL query to check the TDE wallet status:

SQL> SELECT * FROM v$encryption_wallet;
 

The wallet should show the status OPEN.

Check Encryption Algorithm: Verify that TDE encryption is enabled for the CDB tablespaces:

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE encrypted = 'YES';
 

This will confirm that the tablespaces in the CDB are encrypted.

2. Plug in the PDB:

If the PDB is not yet plugged in, follow these steps to plug it into the encrypted CDB.

Unplug the PDB from the source CDB (if required):

SQL> ALTER PLUGGABLE DATABASE PDB_NAME CLOSE IMMEDIATE;
SQL> ALTER PLUGGABLE DATABASE PDB_NAME UNPLUG INTO '/path/to/pdb.xml';


Plug the PDB into the encrypted CDB:

SQL> CREATE PLUGGABLE DATABASE PDB_NAME USING ‘/path/to/pdb.xml’ MOVE FILE_NAME_CONVERT = ('/old/path', '/new/path');

Open the PDB:

SQL> ALTER PLUGGABLE DATABASE PDB_NAME OPEN;
 

3. Encrypt Tablespaces of the PDB:

If the PDB was not encrypted in its previous environment, you will need to encrypt its tablespaces manually after plugging it into the encrypted CDB.

Identify the PDB’s tablespaces: Connect to the PDB and check the tablespaces that are not encrypted:

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE encrypted = 'NO';
 

Encrypt the tablespaces: You can encrypt tablespaces in the PDB by using the ALTER TABLESPACE command. For example:

SQL> ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
 

This command encrypts the users tablespace using the AES256 encryption algorithm. Repeat this for all unencrypted tablespaces.

4. Check the Encryption Status:

After encrypting the tablespaces, verify that all tablespaces in the PDB are now encrypted:

SQL> SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE encrypted = 'YES';
 

5. Verify Encryption Settings:

Confirm that TDE encryption is working properly in the plugged PDB. You can run the following command to check the encryption keys used by the PDB:

SQL> SELECT key_id, con_id FROM v$encryption_keys;
 

The con_id value will help you identify the encryption key associated with the specific PDB.

6. Backup the TDE Wallet:

Since the encryption keys are stored in the TDE wallet, make sure you back up the wallet after plugging and encrypting the PDB. The wallet is critical for restoring access to encrypted data in case of recovery.

The default location of the TDE wallet is typically:

$ORACLE_BASE/admin/<db_unique_name>/wallet/
 

To back up the wallet, simply copy it to a secure location:

cp /path/to/wallet/* /path/to/backup/location/
 

Key Considerations:

  • Performance Impact: Encrypting tablespaces can have a slight impact on performance, especially if large amounts of data are encrypted online.
  • Data Safety: TDE ensures that data at rest (i.e., on disk) is encrypted. However, data is decrypted in memory when queried, so this will not affect query performance significantly.
  • PDB Compatibility: If the source PDB was encrypted, you need to ensure that the encryption algorithm used is compatible with the encryption setup of the CDB.
     

Additional Notes:

If the PDB you are plugging into the encrypted CDB is already encrypted, ensure that the TDE master keys from the original PDB’s wallet are migrated to the new CDB’s wallet. You can use the ADMINISTER KEY MANAGEMENT command to copy or merge the encryption keys between wallets.

Example:

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '/path/to/source_wallet' INTO KEYSTORE '/path/to/cdb_wallet';
 

Conclusion:

Plugging a PDB into an encrypted CDB in Oracle involves making sure that the CDB is properly configured with TDE and that the PDB's tablespaces are encrypted if they are not already. Once the PDB is plugged in, you can encrypt any unencrypted tablespaces and manage the TDE encryption keys through the CDB.
 

 

Comments

Post a Comment

Popular posts from this blog

Creating Physical Standby using RMAN Duplicate Without Shutting down The Primary

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.4 - Release: 10.1 to 10.2 Information in this document applies to any platform. Oracle Server Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 Goal  - Ref Metalink ID - 789370.1 The following note describes step-by-step procedure to create physical standby by using RMAN duplicate without shutting down the primary (Production) database. Database Name :- prim Primary db_unique_name :- prim standby db_unique_name :- stdby Primary Hostname :- raca.idc.oracle.com standby Hostname :- core1.idc.oracle.com Solution 1.Enable force logging. 2.Create SRL(standby redo logs). 3.Make proper changes in the parameter file of primary. 4.Backup the database that includes backup of datafiles, archivelogs and controlfile for standby and copy the backups to standby server. 5.Create the parameter file for standby, 6.Establish the connectivity from primary to standby. 7. Move backup to standby. 8 and 9. Start the standby instance. 10.U
Read more

How to Configure Logging for EM 12c Management Agent

The goal of this article is to provide instruction on how to enable logging for the Enterprise Manager 12c Management Agent.. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The logging properties for the agent are stored in $EMSTATE/sysman/config/emd.properties file, same as in 11.1. But the properties that control logging follow the log4j configuration syntax instead of the syntax supported by the 11.1 agent. To active changes to the logging parameters, you can use either of the emctl commands: emctl reload agent emctl setproperty agent Overview Agent logging entries look similar to the standard log4j logging, with the only significant difference being the prefix 'Logger.' that you will see on each line. For example: # logging properties Logger.log4j.appender.Rolling=org.apache.log4j.RollingFileAppender Logger.lo
Read more

index rebuild candidates oracle

Steps... CREATE TABLE index_log (  owner          VARCHAR2(30),  index_name     VARCHAR2(30),  last_inspected DATE,  leaf_blocks    NUMBER,     target_size    NUMBER,  idx_layout     CLOB); ALTER TABLE index_log ADD CONSTRAINT pk_index_log PRIMARY KEY (owner,index_name); CREATE TABLE index_hist (  owner          VARCHAR2(30),  index_name     VARCHAR2(30),  inspected_date DATE,  leaf_blocks    NUMBER,     target_size    NUMBER,  idx_layout     VARCHAR2(4000)); ALTER TABLE index_hist ADD CONSTRAINT pk_index_hist PRIMARY KEY  (owner,index_name,inspected_date); CREATE OR REPLACE PACKAGE index_util AUTHID CURRENT_USER IS vMinBlks     CONSTANT POSITIVE := 1000; vScaleFactor CONSTANT NUMBER := 0.6; vTargetUse   CONSTANT POSITIVE := 90;  -- equates to pctfree 10  vHistRet     CONSTANT POSITIVE := 10;  -- (#) records to keep in index_hist  procedure inspect_schema (aSchemaName IN VARCHAR2);  procedure inspect_index (aIndexOwner IN VARCHAR2, aIndexName IN VARCHAR2, a
Read more