Blog Name
  • Januar 2019
Freitag, 18.01.2019

Grundlagen des TDE Key Managements

Spätestens bei der Verwendung eines Oracle Database Cloud Services kommt man nicht mehr drum herum. Plötzlich muss man sich mit dem Thema Key-Management auseinandersetzen. Ohne Key-Management war doch alles viel einfacher! Doch ist das wirklich so? Key-Management: Für manche Anwender bereits ein alter Hut, für viele andere allerdings noch Neuland.

Konsens herrscht darüber, dass in der Cloud jede gespeicherte Information verschlüsselt sein muss. Denn Verschlüsselung ist die effektivste Methode, Informationen vor unberechtigten Zugriffen zu schützen. Das gilt natürlich nicht nur für die Cloud, sondern auch bei der Speicherung von Informationen im eigenen Rechenzentrum.

Daher werden bei den Oracle Datenbank Cloud Services alle Daten standardmäßig verschlüsselt. Unabhängig davon, ob es sich bei dem genutzten Oracle Datenbank Cloud Service um eine Standard-Edition oder um eine Enterprise-Edition handelt. Die Verschlüsselung mittels der Oracle Transparent Data Encryption (TDE) ist immer aktiv und lässt sich auch nicht deaktivieren, zumindest nicht in der Oracle Cloud. Als Standard kommt hier der AES-128bit Verschlüsselungs-Algorithmus zum Einsatz. Das bedeutet, dass zum Beispiel beim Erstellen eines Tablespaces keine speziellen Angaben zur Verschlüsselung gemacht werden müssen. Im Prinzip reicht ein einfaches „Create Tablespace #tbs_name#;“ aus, um den Tablespace verschlüsselt zu erstellen. Also sind zumindest hier keine Mehraufwände zu erwarten. Jedoch braucht jede Verschlüsselung einen Schlüssel. Das gilt auch für den Oracle Datenbank Cloud Service. Generell werden Schlüssel in sogenannten Keystores gespeichert. Keystores ermöglichen die Verwaltung und den Schutz von geheimen Schlüsseln. Der wohl bekannteste Keystore ist der Java Keystore (JKS), der überwiegend bei Web-Servern - die mit HTTPS arbeiten - eingesetzt wird. Der von der Oracle Datenbank-Verschlüsselung verwendete Keystore zur Speicherung des TDE-Master Keys, ist eine mit AES-256bit durch ein Passwort verschlüsselte PKCS#12 Datei (ewallet.p12). Das sogenannte Oracle Wallet. Wird eine Oracle Datenbank On-Premises angelegt, muss das Oracle Wallet manuell angelegt werden und der TDE-Master Key durch Ausführung eines SQL-Befehls erstellt werden. Wie das genau funktioniert, steht in diesem Dojo : Daten verschlüsseln.

Ein wenig anders sieht es bei der Verwendung eines Oracle Datenbank Cloud Services aus. Wie bereits beschrieben, werden in der Oracle Cloud grundsätzlich alle Daten verschlüsselt. Das bedeutet, dass bei Erstellung einer Oracle Cloud Datenbank automatisch ein Oracle Wallet und die entsprechenden TDE-Master Keys erstellt werden. Da es sich bei der Oracle Cloud Datenbank um eine Single Tenant Datenbank handelt, wird sowohl für den Container als auch für die Pluggable- Database jeweils ein TDE-Master Key erstellt. Diese TDE-Master Keys werden im Oracle Wallet gespeichert.

Im Folgenden beschreibe ich die wichtigsten Datenbankaktivitäten im Zusammenspiel mit der TDE Datenbank-Verschlüsselung und zeige auf, dass es weniger Aufwand bedeutet als angenommen.

Oracle Wallet

Bereits bei der Erstellung des Datenbank Cloud Services muss ein Passwort angegeben werden.

Abbildung 1: Datenbank und Oracle Wallet Passwort

Dieses Passwort wird für die Datenbankbenutzer SYS und SYSTEM verwendet. Es wird jedoch auch für das Oracle Wallet verwendet, indem sich die TDE-Master Keys befinden. Nachdem der Datenbank Cloud Service bereitgestellt wurde, verschaffen wir uns einen Überblick über die TDE Konfiguration. Dazu verbinden wir uns mit dem entsprechenden Datenbank Cloud Service mittels eines SSH-Clients und dem Benutzer OPC. Durch ein „sudo su - oracle“ arbeiten wir schließlich als Oracle Benutzer weiter.

$ssh opc@xxx.xxx.xxx.137
Last login: Tue Jan 15 06:37:54 2019 from xxx.xxx.xxx.57
[opc@dbcs1 ~]$ sudo su - oracle
[oracle@dbcs1 ~]$

Alle notwendigen Umgebungsvariablen sind bereits gesetzt.

[oracle@dbcs1 ~]$ env | grep ORA
ORACLE_UNQNAME=cdb1_fra37m
ORACLE_SID=cdb1
ORACLE_HOME=/u01/app/oracle/product/18.0.0.0/dbhome_1

Um zu ermitteln, wo sich das Oracle Wallet befindet, haben wir zwei Möglichkeiten. Entweder schauen wir uns den Parameter ENCRYPTION_WALLET in der SQLNET.ORA an.

[oracle@dbcs1 ~]$ cat $ORACLE_HOME/network/admin/sqlnet.ora
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

Oder wir nutzen die Dictionary View V$ENCRYPTION_WALLET dafür. Diese View enthält neben dem Speicherort des Oracle Wallets, zusätzliche interessante Informationen zum Keystore. Sollte es sich bei der Datenbank um eine RAC-Instanz handeln, sollte die GV$ENCRYPTION_WALLET View dazu verwendet werden.

[oracle@dbcs1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on Tue Jan 15 08:47:42 2019
Version 18.3.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.


Connected to:
Oracle Database 18c EE High Perf Release 18.0.0.0.0 - Production
Version 18.3.0.0.0

SQL> set linesize window
SQL> col WRL_TYPE format a10
SQL> col status format a10
SQL> col WRL_PARAMETER format a50
SQL> col WALLET_TYPE format a10
SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet; 

WRL_TYPE   STATUS     WRL_PARAMETER					      WALLET_TYP KEYSTORE     CON_ID
---------- ---------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN       /opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/    AUTOLOGIN  NONE		   1
FILE	   OPEN 							      AUTOLOGIN  UNITED 	   2
FILE	   OPEN 							      AUTOLOGIN  UNITED 	   3

SQL>

Hier kann man erkennen, dass der Keystore der CDB-Root (CON_ID 1), PDB1 (CON_ID 3) und der PDB$SEED (CON_ID 2) geöffnet ist und sich im Verzeichnis „/opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m“ befindet. Der Keystore-Mode UNITED bedeutet, dass momentan alle PDBs einen gemeinsamen Keystore verwenden. Dies ist die Standardeinstellung. Es besteht auch die Möglichkeit, die Keystores voneinander isoliert zu betreiben. Dies habe ich in dem Tipp: Keystore pro Pluggable-Database beschrieben.

Der Keystore-Type AUTOLOGIN bedeutet, dass sich der Keystore automatisch beim Starten der Datenbank öffnet und somit die TDE-Master Keys der Datenbank zur Verfügung stehen. Also komplett ohne Benutzerinteraktion. Ist dies nicht gewünscht, muss lediglich das Oracle Autologin-Wallet (cwallet.sso) gelöscht werden. Diese Datei befindet sich ebenfalls im Verzeichnis des Oracle Wallets. Aus Verfügbarkeitsgründen sollte jedoch davon abgesehen werden, weil dann die Daten nach einem Neustart des Datenbank Cloud Services, ohne ein manuelles Öffnen des Keystores, nicht zur Verfügung stehen. Das Autologin-Wallet (cwallet.sso) kann allerdings jeder Zeit wieder neu erstellt werden. Wird kein Oracle Autologin-Wallet benutzt, zeigt die V$ENCRYPTION_WALLET View den Keystore-Type PASSWORD an.

Das Oracle Wallet (ewallet.p12) selber, ist jedoch eine der wichtigsten Dateien der Datenbank. Der Verlust dieser Datei bedeutet gleichzeitig ein Datenverlust.

Löschen des Autologin-Wallets

[oracle@dbcs1 ~]$ cd /opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m
[oracle@dbcs1 cdb1_fra37m]$ ls -la
total 140
drwx------ 2 oracle oinstall 20480 Jan 14 16:51 .
drwx------ 3 oracle oinstall 20480 Jan 11 18:08 ..
-rw------- 1 oracle asmadmin  6088 Jan 14 16:51 cwallet.sso
-rw------- 1 oracle oinstall     0 Jan 14 16:44 cwallet.sso.lck
-rw------- 1 oracle asmadmin  6043 Jan 14 16:51 ewallet.p12
-rw------- 1 oracle oinstall     0 Jan 14 16:44 ewallet.p12.lck
-rw------- 1 oracle asmadmin  2555 Jan 11 18:09 ewallet_2019011118090561_defaultTag.p12
-rw------- 1 oracle asmadmin  5819 Jan 14 16:51 ewallet_2019011416510980.p12

[oracle@dbcs1 cdb1_fra37m]$ rm cwallet.sso

Nach dem Löschen der cwallet.sso Datei muss der Keystore einmal geschlossen und wieder geöffnet werden.

Alle Key-Management Operationen werden mit dem SQL-Befehl ADMINISTER KEY MANAGEMENT durchgeführt. Hierzu muss der Benutzer das SYSKM Recht besitzen. Eine umfangreiche Beschreibung des Befehls finden Sie in der Oracle Dokumentation.

SQL> administer key management set keystore close;

keystore altered.

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS     WRL_PARAMETER					      WALLET_TYP KEYSTORE     CON_ID
---------- ---------- ------------------------------------------------------- ---------- -------- ----------
FILE	   CLOSED     /opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/    UNKNOWN	 NONE		   1
FILE	   CLOSED							      UNKNOWN	 UNITED 	   2
FILE	   CLOSED							      UNKNOWN	 UNITED 	   3

SQL> administer key management set keystore open identified by "Password1" container=all;

keystore altered.

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS     WRL_PARAMETER					      WALLET_TYP KEYSTORE     CON_ID
---------- ---------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN       /opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/    PASSWORD	 NONE		   1
FILE	   CLOSED							      UNKNOWN	 UNITED 	   2
FILE	   OPEN 							      PASSWORD	 UNITED 	   3

Ab jetzt muss jedoch nach jedem Neustart der Datenbank der Keystore manuell mit dem Keystore-Passwort geöffnet werden. Da dies ungünstig für die Verfügbarkeit der Daten ist, erstelle ich das Autologin-Wallet wieder neu.

Erstellen eines Autologin-Wallets

Dies wird ebenfalls mit dem ADMINISTER KEY MANAGEMENT Befehl durchgeführt. Dazu muss man wissen wo das Oracle Wallet gespeichert ist - WRL_PARAMETER in der V$ENCRYPTION_WALLET View – und natürlich das Passwort kennen.

SQL> administer key management create AUTO_LOGIN keystore from keystore '/opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m' identified by "Password1";

keystore altered.
SQL> administer key management set keystore close identified by "Password1";

keystore altered.

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS     WRL_PARAMETER					      WALLET_TYP KEYSTORE     CON_ID
---------- ---------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN       /opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/    AUTOLOGIN  NONE		   1
FILE	   OPEN 							      AUTOLOGIN  UNITED 	   2
FILE	   OPEN 							      AUTOLOGIN  UNITED 	   3

Jetzt ist der Originalzustand wiederhergestellt.

Re-Keying

Der Keystore beinhaltet neben den aktuellen TDE-Master Keys auch alle historischen Schlüssel der entsprechenden Datenbank. Wird bei einem Re-Keying ein neuer Schlüssel erstellt, wird der alte Schlüssel im Oracle Wallet automatisch historisiert. Nur so ist das Wiederherstellen von Datenbanken aus älteren Datenbank-Backups, die gegebenenfalls einen älteren TDE-Master-Key verwenden, möglich. Deshalb bleibt das Oracle Wallet ständiger Begleiter einer mit TDE verschlüsselten Oracle Datenbank, ein Datenbank-Leben lang.

TDE-Master Key Informationen lassen sich über die Dictionary View V$ENCRYPTION_KEYS abfragen. Diese View zeigt alle bisher verwendeten TDE-Master Keys an.

SQL> col KEY_ID format a60
SQL> col TAG format a15
SQL> col KEY_USE format a20
SQL> select KEY_ID,TAG,KEY_USE from v$encryption_keys;

KEY_ID							     TAG	     KEY_USE
------------------------------------------------------------ --------------- --------------------
AQGq2sRCgU9Av7zZiSHWK9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB
AWNk7PkfaE9xv9JdeJ4Zp7kAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB

Möchte oder muss ein Re-Keying durchgeführt werden, wird das mittels des ADMINISTER KEY MANAGEMENT Befehls durchgeführt. Zu beachten ist hier, dass bei Nutzung des Autologin-Wallets immer die Klausel FORCE KEYSTORE im ADMINISTER KEY MANAGEMENT Befehl verwendet werden muss. Wird dies nicht gemacht, erscheint eine Fehlermeldung. Die Klausel WITH BACKUP am Ende des ADMINISTER KEY MANAGEMENT Befehls bewirkt, dass das Oracle Wallet vor der eigentlichen Operation gesichert wird. Die Angabe dieser Klausel ist bei allen Key-Management Operationen, die das Oracle Wallet aktuallisieren, obligatorisch.

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "Password1" WITH BACKUP;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "Password1"
*
ERROR at line 1:
ORA-28417: password-based keystore is not open

Das gleiche nochmal, nur jetzt mit Verwendung der FORCE KEYSTORE Klausel.

SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "Password1" WITH BACKUP;

keystore altered.

In der V$ENCRYPTION_KEYS View sind nun die Informationen des gerade erstellten Keys sichtbar.

SQL> select KEY_ID,TAG,KEY_USE from v$encryption_keys;

KEY_ID							     TAG	     KEY_USE
------------------------------------------------------------ --------------- --------------------
AWNk7PkfaE9xv9JdeJ4Zp7kAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB
AQGq2sRCgU9Av7zZiSHWK9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB
AWWv6DoQUU/9v3tJg4Be9S0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA			     TDE IN PDB

Diese Vorgehensweise wird auch in der Pluggable-Database angewendet.

 SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
SQL> alter session set container=pdb1;

Session altered.

SQL> select KEY_ID,TAG,KEY_USE from v$encryption_keys;

KEY_ID							     TAG	     KEY_USE
------------------------------------------------------------ --------------- --------------------
AWNk7PkfaE9xv9JdeJ4Zp7kAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB

SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "Password1" WITH BACKUP;

keystore altered.

SQL> select KEY_ID,TAG,KEY_USE from v$encryption_keys;

KEY_ID							     TAG	     KEY_USE
------------------------------------------------------------ --------------- --------------------
AWNk7PkfaE9xv9JdeJ4Zp7kAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	     defaultTag      TDE IN PDB
AVJfWuQlnE//vyZc+gHuRRYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA			     TDE IN PDB

Mit der Dictionary View V$DATABASE_KEY_INFO lässt sich der aktuelle TDE-Master Key ermitteln. Die Master-Key ID wird hier in Hexadezimal angezeigt. Damit die Werte leichter vergleichbar sind, konvertieren wir die Master-Key IDs aus der V$ENCRYPTION_KEYS vom BASE64 zum RAW Format.

SQL> select substr(UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(KEY_ID)),3,32) mk_id from v$encryption_keys;

MK_ID
--------------------------------------------------------------------------------------------------------------------------------
6364ECF91F684F71BFD25D789E19A7B9
525F5AE4259C4FFFBF265CFA01EE4516

SQL> select ENCRYPTIONALG, MASTERKEYID, MASTERKEY_ACTIVATED, CON_ID from V$DATABASE_KEY_INFO;

ENCRYPT MASTERKEYID			 MAS	 CON_ID
------- -------------------------------- --- ----------
AES128	525F5AE4259C4FFFBF265CFA01EE4516 YES	      3

Zudem zeigt der Wert der ENCRYPTIONALG Spalte den von der Datenbank verwendete Standard Verschlüsselungs-Algorithmus an. Dieser wird zum Beispiel bei Erstellung eines Tablespaces verwendet, wenn keine zusätzliche Storage Encryption Klausel angegeben wird.

Erstellen eines Tablespaces

Unter Zuhilfenahme der Dictionary Views V$ENCRYPTED_TABLESPACES und TS$ lässt sich ermitteln, mit welchen Verschlüsselungsalgorithmen die Tablespaces verschlüsselt wurden.

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

NAME			       ENCRYPT MASTERKEYID
------------------------------ ------- --------------------------------
USERS			       AES128  525F5AE4259C4FFFBF265CFA01EE4516

Als nächstes erstellen wir einen Tablespace ohne Angabe eines alternative Verschlüsselungs-Algorithmus und einen weiteren Tablespace mit AES-256bit, durch Verwendung der Storage Encryption Klausel ( DEFAULT STORAGE ( ENCRYPT ) ENCRYPTION USING 'AES256' ).

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

NAME			       ENCRYPT MASTERKEYID
------------------------------ ------- --------------------------------
USERS			       AES128  525F5AE4259C4FFFBF265CFA01EE4516

SQL> create tablespace data01;     

Tablespace created.

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

NAME			       ENCRYPT MASTERKEYID
------------------------------ ------- --------------------------------
USERS			       AES128  525F5AE4259C4FFFBF265CFA01EE4516
DATA01			       AES128  525F5AE4259C4FFFBF265CFA01EE4516

SQL> create tablespace data02 DEFAULT STORAGE ( ENCRYPT ) ENCRYPTION USING 'AES256';

Tablespace created.

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

NAME			       ENCRYPT MASTERKEYID
------------------------------ ------- --------------------------------
USERS			       AES128  525F5AE4259C4FFFBF265CFA01EE4516
DATA01			       AES128  525F5AE4259C4FFFBF265CFA01EE4516
DATA02			       AES256  525F5AE4259C4FFFBF265CFA01EE4516

Passwortänderung des Keystores (Oracle Wallet)

Bei Bedarf ist es möglich, dass Passwort des Keystores zu ändern. Dies wird mit der Klausel ALTER KEYSTORE des ADMINISTER KEY MANAGEMENT Befehls durchgeführt. Da im Standard lediglich nur ein Keystore existiert, kann dieser Befehl nur in der Container Datenbank (cdb$root) angewendet werden.

SQL> alter session set container=cdb$root;

Session altered.

SQL> administer key management alter keystore password force keystore identified by "Password1" set "Password2" with backup;

keystore altered.

Das entsprechende Autologin-Wallet wird damit ebenfalls neu generiert. Es sind somit keine weiteren Aktionen notwendig.

Klonen einer verschlüsselten Pluggable-Database

Wird die Oracle Multitenant-Option oder ein Oracle Database Cloud Service High Performance oder größer verwendet, besteht die Möglichkeit weitere Pluggable-Databases in der Container Datenbank anzulegen. Dies kann durch Klonen einer bestehenden Pluggable-Database geschehen. Die Vorgehensweise beim Klonen einer verschlüsselten Pluggable-Database unterscheidet sich nicht wesentlich zur Vorgehensweise einer unverschlüsselten Pluggable-Database. Hinzu kommt lediglich die Klausel KEYSTORE IDENTIFIED zum CREATE PLUGGABLE DATABASE Befehls. Empfohlen ist, dass nach dem Klonen eine Re-Keying innerhalb der geklonten Pluggable-Database durchgeführt werden sollte. So wird vermieden, dass zwei Pluggable-Databases den selben TDE-Master Key haben.

SQL> show pdbs;

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO

SQL> create pluggable database pdb2 from pdb1 keystore identified by "Password2";

Pluggable database created.

SQL> alter pluggable database pdb2 open;

Pluggable database altered.

SQL> show pdbs;

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 6 PDB2 			  READ WRITE NO
SQL> alter session set container=pdb2;

Session altered.

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS     WRL_PARAMETER					      WALLET_TYP KEYSTORE     CON_ID
---------- ---------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN 							      AUTOLOGIN  UNITED 	   6

SQL> select ENCRYPTIONALG, MASTERKEYID, MASTERKEY_ACTIVATED, CON_ID from V$DATABASE_KEY_INFO;

ENCRYPT MASTERKEYID			 MAS	 CON_ID
------- -------------------------------- --- ----------
AES128	525F5AE4259C4FFFBF265CFA01EE4516 YES	      6

SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "Password2" with backup;

keystore altered.

SQL> select ENCRYPTIONALG, MASTERKEYID, MASTERKEY_ACTIVATED, CON_ID from V$DATABASE_KEY_INFO;

ENCRYPT MASTERKEYID			 MAS	 CON_ID
------- -------------------------------- --- ----------
AES128	3EF216040E1D4F32BF578B18FE4059DF YES	      6

Erstellen einer neuen Pluggable-Database

Wird eine Pluggable-Database komplett neu erstellt, besitzt sie noch keinen TDE-Master Key. Dieser muss nach der Fertigstellung generiert werden. Beim Versuch einen Tablespace in der neuen Pluggable-Database zu erstellen, ohne einen TDE-Master Key zu haben, erscheint eine Fehlermeldung.

SQL> alter session set container=cdb$root;

Session altered.

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 6 PDB2 			  READ WRITE NO

SQL> CREATE PLUGGABLE DATABASE pdb3 ADMIN USER pdb_admin IDENTIFIED BY Password2;

Pluggable database created.

SQL> show pdbs;

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 4 PDB3 			  MOUNTED
	 6 PDB2 			  READ WRITE NO

SQL> alter pluggable database pdb3 open;

Pluggable database altered.

SQL> col status format a20
SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS		WRL_PARAMETER						WALLET_TYP KEYSTORE	CON_ID
---------- -------------------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN 		/opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/	AUTOLOGIN  NONE 	     1
FILE	   OPEN 									AUTOLOGIN  UNITED	     2
FILE	   OPEN 									AUTOLOGIN  UNITED	     3
FILE	   OPEN_NO_MASTER_KEY								AUTOLOGIN  UNITED	     4
FILE	   OPEN 									AUTOLOGIN  UNITED	     6


SQL> alter session set container=pdb3;

Session altered.

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

no rows selected

SQL> create tablespace data01;
create tablespace data01
*
ERROR at line 1:
ORA-28361: master key not yet set


SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "Password2" with backup;

keystore altered.

SQL> create tablespace data01;

Tablespace created.

SQL> SELECT NAME, ENCRYPTIONALG, MASTERKEYID FROM V$ENCRYPTED_TABLESPACES, TS$ where TS$.TS#=V$ENCRYPTED_TABLESPACES.TS#;

NAME			       ENCRYPT MASTERKEYID
------------------------------ ------- --------------------------------
DATA01			       AES128  EF1973CA15AE4F65BF212A786FC2AC5C

UNPLUG und PLUGIN einer Pluggable Database

Ist beabsichtigt eine Pluggable-Database über UNPLUG von einer Container Datenbank in eine andere Container Datenbank zu bringen, muss der dazugehörige TDE-Master Key ebenfalls exportiert werden. Der Export des TDE-Master Keys wird mit der EXPORT Klausel des ADMINISTER KEY MANAGEMENT Befehls durchgeführt. Dabei wird der TDE-Master Key in einen separaten Export-Keystore kopiert. Der Export-Keystore wird mit dem im Befehl verwendeten Passwort geschützt.

SQL> show pdbs;

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 4 PDB3 			  READ WRITE NO
	 6 PDB2 			  READ WRITE NO

SQL> alter session set container=PDB2;

Session altered.

SQL> ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "password" TO '/tmp/cdb1_pdb2_key_export.p12' force keystore IDENTIFIED BY "Password2";

keystore altered.

SQL> !ls -la /tmp/cdb1_pdb2_key_export.p12
-rw-r--r-- 1 oracle asmadmin 2612 Jan 15 13:29 /tmp/cdb1_pdb2_key_export.p12
SQL> alter session set container=cdb$root;

Session altered.

SQL> alter pluggable database pdb2 close;

Pluggable database altered.

SQL> alter pluggable database pdb2 unplug into '/tmp/cdb1_pdb2.xml';

Pluggable database altered.

SQL> drop pluggable database pdb2;

Pluggable database dropped.

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 4 PDB3 			  READ WRITE NO

Dieser Export-Keystore wird dann zusammen mit der Pluggable-Database (Datenfiles, cdb1_pdb2_key_export.p12 und cdb1_pdb2.xml) zum Ziel-Container transportiert. Nachdem die Pluggable-Database in den Ziel-Container gebracht wurde, muss die Pluggable-Database geöffnet werden. Beim Öffnen erscheint eine Fehlermeldung - Warning: PDB altered with errors - . Diese ignorieren wir und wechseln die Session in die gerade eingestöpselte Pluggable-Database. Jetzt muss nur noch der TDE-Master Key aus dem Export-Keystore in den Keystore des Ziel-Containers kopiert werden. Hierzu verwenden wir die IMPORT Klausel des ADMINISTER KEY MANAGEMENT Befehls. Abschließend die Pluggable-Database schließen und wieder öffnen.

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 4 PDB3 			  READ WRITE NO

SQL> create pluggable database pdb5 using '/tmp/cdb1_pdb2.xml' NOCOPY keystore identified by Password2;

Pluggable database created.

SQL> ALTER PLUGGABLE DATABASE pdb5 OPEN READ WRITE;

Warning: PDB altered with errors.

SQL> alter session set container=pdb5;

Session altered.

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS		WRL_PARAMETER						WALLET_TYP KEYSTORE	CON_ID
---------- -------------------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN 									AUTOLOGIN  UNITED	     5
SQL> ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "password" from '/tmp/cdb1_pdb2_key_export.p12' force keystore IDENTIFIED BY "Password2" with backup;

keystore altered.

SQL> shutdown 

Pluggable Database closed.

SQL> startup

Pluggable Database opened.

SQL> alter session set container=cdb$root;

Session altered.

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
	 4 PDB3 			  READ WRITE NO
	 5 PDB5 			  READ WRITE NO

SQL> select WRL_TYPE,status,WRL_PARAMETER,WALLET_TYPE,KEYSTORE_MODE,con_id from v$encryption_wallet;

WRL_TYPE   STATUS		WRL_PARAMETER						WALLET_TYP KEYSTORE	CON_ID
---------- -------------------- ------------------------------------------------------- ---------- -------- ----------
FILE	   OPEN 		/opt/oracle/dcs/commonstore/wallets/tde/cdb1_fra37m/	AUTOLOGIN  NONE 	     1
FILE	   OPEN 									AUTOLOGIN  UNITED	     2
FILE	   OPEN 									AUTOLOGIN  UNITED	     3
FILE	   OPEN 									AUTOLOGIN  UNITED	     4
FILE	   OPEN 									AUTOLOGIN  UNITED	     5

Fazit

Damit wären die Grundlagen und die wesentlichen Eigenschaften einer mit TDE verschlüsselten Datenbank dargestellt. Ich hoffe gezeigt zu haben, dass es nicht wirklich aufwendiger ist eine Datenbank mit TDE-Verschlüsselung zu betreiben. Unabhängig davon, ob es sich um eine On-Premises Datenbank oder einen Oracle Database Cloud Service handelt.

Lizenzhinweis

Um die Transparent Data Encrytion On-Premises nutzen zu dürfen, benötigen Sie, neben einer Oracle Datenbank in der Enterprise Edition, auch die Oracle Advanced Security Option. Bei Verwendung des Oracle Database Cloud Services ist die Nutzung von Transparent Data Encrytion in jeder Datenbank-Edition bereits in der Subscription enthalten.

Um Oracle Multitenant On-Premises nutzen zu dürfen, benötigen Sie, neben einer Oracle Datenbank in der Enterprise Edition, auch die Oracle Multitenant Option. Bei Verwendung des Oracle Database Cloud Services ist die Nutzung von Oracle Multitenant ab der Datenbank-Enterprise Edition High Performance bereits in der Subscription enthalten.

 
Verfügbarkeit und Download

Weitere Informationen

 

Zurück zur Community-Seite
 

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services