Die bekannte Beispielinstallation des Schema SCOTT bildet wieder den Ausgangspunkt. Die Daten sind unverschlüsselt gespeichert. Der Benutzer SCOTT soll die Objekte seines Schemas nun verschlüsselt exportieren. Wie im oben erwähnten Tipp zu Data Pump beschrieben, sind dazu zunächst für SCOTT die Voraussetzungen zu schaffen: Es wird ein Verzeichnis angelegt und der Zugriff auf dieses Verzeichnis freigegeben.

CREATE OR REPLACE DIRECTORY expdir AS '/home/oracle'
/
GRANT read, write ON DIRECTORY expdir TO scott
/

Zunächst wird zur Kontrolle ein unverschlüsselter Export durchgeführt. Durchsucht man diesen zum Beispiel nach dem Tabellennamen EMP oder dem Namen MILLER, findet man problemlos den Tabellennamen EMP einige Male und den Namen MILLER einmal. Nun startet SCOTT den verschlüsselten Export mit folgendem Aufruf von Data Pump (das Passwort für SCOTT wird nach dem Passwort Prompt von Data Pump eingegeben).

expdp scott parfile=encrex.par

Die Parameterdatei encrex.par hat nur folgende Einträge:

DIRECTORY=expdir
DUMPFILE=szenario1.dmp
LOGFILE=szenario1.log
ENCRYPTION=ALL              -- Alternativ DATA_ONLY, ENCRYPTED_COLUMNS_ONLY, METADATA_ONLY, NONE]
ENCRYPTION_ALGORITHM=AES192 -- Alternativ AES128 (Default) und AES 256
ENCRYPTION_MODE=PASSWORD    -- Alternativ DUAL und TRANSPARENT
ENCRYPTION_PASSWORD=einpasswort

Die Log Datei gibt keine Auskunft darüber, ob der Export verschlüsselt durchgeführt wurde oder nicht. Allerdings ist ein Durchsuchen des Exports nach den Zeichenketten EMP und MILLER erfolglos. Das soll als Beleg dafür genügen, dass das dump file set in der Tat verschüsselt ist.

Nun zu den verwendeten Parametern zur Steuerung der Verschlüsselung: Es bestehen Abhängigkeiten zwischen den Parametern ENCRYPTION, ENCRYPTION_MODE und ENCRYPTION_PASSWORD. So ist es sicherlich logisch, dass nach dem Setzen des Parameters ENCRYPTION_MODE auf PASSWORD der Parameter ENCRYPTION_PASSWORD ebenfalls besetzt werden muss. Aber auch andere Abhängigkeiten bestehen, deren Erläuterung jedoch den Rahmen dieses Tipps überschreitet. Stattdessen sei dazu auf die Seiten des Utility Guide verwiesen, auf denen alle Parameter und ihre Abhängigkeiten untereinander detailliert beschrieben werden.

Während die alternativen Werte, die die Parameter ENCRYPTION und ENCRYPTION_ALGORITHM annehmen können, weitestgehend selbsterklärend sind und der Parameter ENCRYPTION_PASSWORD eindeutig sein dürfte, müssen die Werte DUAL und TRANSPARENT für ENCRYPTION_MODE erläutert werden.

• Steht der Wert auf DUAL muss ENCRYPTION_PASSWORD ebenfalls besetzt werden. Beim späteren Import kann dieses Passwort verwendet werden - zum Beispiel nach dem Transport des dump file set auf ein anderes System. Allerdings kann auch ohne Angabe eines Passwortes gearbeitet werden, und zwar dann, wenn man auf das TDE Wallet zurückgreifen kann, das zum Verschlüsseln der exportierten Daten in der Quelldatenbank benutzt wurde. Das Wallet kann man zum Beispiel verwenden, wenn die Daten in die gleiche Datenbank importiert werden, aus der sie exportiert wurden (Quelldatenbank = Zieldatenbank). Das könnte nötig sein, wenn man den Eigentümer eines Schemas ändern oder Daten nachträglich verschlüsseln will oder wenn der Export mit dem Ziel durchgeführt wird, die Daten in anderer Form zu reorganisieren.
• Ist ENCRYPTION_MODE auf TRANSPARENT gesetzt, wird die Verschlüsselung ausschliesslich durch Rückgriff auf das TDE Wallet der Quelldatenbank durchgeführt. Dazu muss das Wallet sowohl beim Export als auch beim Import geöffnet sein. TRANSPARENT bietet sich zum Beispiel an, wenn Export und Import ohne Anwenderintervention erfolgen sollen. Bei Verwendung von TRANSPARENT würde die gleichzeitige Verwendung des Parameters ENCRYPTION_PASSWORD zu einer Fehlermeldung führen.

Der Einfachheit halber legen wir ein verschlüsseltes Tablespace mit dem Namen ENCRYPTEDUSERS an, auf das SCOTT Zugriff erhält. Eine Abfrage auf die View USER_TABLESPACES bestätigt, dass das Tablespace tatsächlich verschlüsselt angelegt ist.

SQL orcl> SELECT tablespace_name, encrypted
  2  FROM dba_tablespaces;

TABLESPACE_NAME                ENCRYPTED                                               
------------------------------ ---------                                               
SYSTEM                         NO                                                
...                                           
ENCRYPTEDUSERS                 YES                                               

7 rows selected.

In diesem verschlüsselten Tablespace legt SCOTT über ein CREATE TABLE AS SELECT eine Kopie der Tabelle EMP namens ANGESTELLTE an. Diese Tabelle wird selbstverständlich bei einem Schema Export ebenfalls exportiert. Es ist zu beachten, dass dazu das Wallet geöffnet sein muss!

Das Vorgehen bei dieser Variante unterscheidet sich im Weiteren in keiner Weise von der vorangegangenen Vorgehensweise. Das bedeutet also, dass der Export mit der identischen Parameterdatei durchgeführt werden kann.

Der Ausschnitt aus der Log Datei zeigt, dass das Schema SCOTT einschließlich der Tabelle ANGESTELLTE aus dem verschlüsselten Tablespace exportiert wurde.

Export: Release 11.2.0.3.0 - Production on Sun Jan 6 16:44:30 2013
...
Starting "SCOTT"."SYS_EXPORT_SCHEMA_01":  scott/******** parfile=encrex.par
...
. . exported "SCOTT"."ANGESTELLTE"                       8.578 KB      14 rows
. . exported "SCOTT"."DEPT"                              5.937 KB       4 rows
. . exported "SCOTT"."EMP"                               8.570 KB      14 rows
...
Job "SCOTT"."SYS_EXPORT_SCHEMA_01" successfully completed at 16:45:04

Um zu zeigen, wie der Export verschlüsselter Daten in ein unverschlüsseltes dump file set durchzuführen ist, wird die Parameterdatei bearbeitet: Alle Parameter, die die Verschlüsselung steuern, werden aus der Datei gelöscht. Dann wird der Export durchgeführt wie zuvor.

Der Inhalt der Log Datei unterscheidet sich nicht von der, die im vorangegangenen Abschnitt zu sehen ist. Es wird daher wie oben das dump file set nach dem Namen MILLER durchsucht, um einen Hinweis darauf zu finden, ob verschlüsselt wurde oder nicht. Wie erwartet findet sich der Name zweimal: Einmal aus der Tabelle EMP und einmal aus der Tabelle ANGESTELLTE.

Daten können in einer Quelldatenbank verschlüsselt oder unverschlüsselt abgelegt sein. Data Pump Export kann beide Formen exportieren. Man kann mit Fug und Recht behaupten, dass es für das Arbeiten mit Data Pump Export völlig unerheblich ist, ob die Daten der Quelldatenbank verschlüsselt sind oder nicht. Die Bezeichnung Transparent Data Encryption trifft also nicht nur für das Verschlüsseln von Daten in der Datenbank selbst, sondern auch für das Exportieren dieser Daten zu. Wichtig ist hier ausschliesslich, dass im Rahmen des Arbeitens mit Data Pump Export gesteuert wird, ob das Ergebnis des Exports, das dump file set, verschlüsselt ist oder nicht.

Dieses Szenario wird in mehreren Schritten getestet. Zunächst wird das verschlüsselte dump file set aus dem Szenario in Abschnitt 1 verwendet. In diesem Szenario gab es das verschlüsselte Tablespace ENCRYPTEDUSERS sowie die Tabelle ANGESTELLTE noch nicht. Um das Gelingen des Imports nachweisen zu können wird die Tabelle EMP mit DROP gelöscht. Die Parameter Datei encimp.par enthält folgende Einträge:

DIRECTORY=expdir
DUMPFILE=szenario1.dmp
LOGFILE=impscott1.log
ENCRYPTION_PASSWORD=einpasswort

Aufgerufen wird der Import mit

impdp scott parfile=encimp.par

Auch Data Pump Import verlangt zunächst nach dem Passwort von SCOTT. Der Import gelingt erwartungsgemäß, die Tabelle EMP ist wieder verfügbar.

Der Parameter ENCRYPTION_PASSWORD ist der einzige verschlüsselungsrelevante Parameter, den Data Pump Import kennt. Seine Bedeutung ist eindeutig: Es muss das Passwort angegeben werden, das auch beim Export angegeben wurde.

Im nächsten Schritt soll der Export aus dem Szenario 3 importiert werden. Dieser Export enthält auch Definition und Daten der Tabelle ANGESTELLTE. Weil diese Tabelle aus dem Tablespace ENCRYPTEDUSERS exportiert wurde, muss dieses Tablespace vor dem Import mit ausreichender Quote für SCOTT angelegt werden. Es wird hier allerdings als unverschlüsseltes Tablespace angelegt! Nachdem die Tabelle EMP mit DROP TABLE gelöscht wurde, wird der Import mit folgenden Parametern durchgeführt:

DIRECTORY=expdir
DUMPFILE=szenario3.dmp
LOGFILE=impscott3.log
ENCRYPTION_PASSWORD=einpasswort

Auch dieser Import gelingt, wie die Abfragen auf die Tabellen EMP und ANGESTELLTE belegen. Bemerkenswert ist natürlich, dass die Tabelle ANGESTELLTE zwar aus einem verschlüsselten Tablespace in ein verschlüsseltes dump file set exportiert wurde, aber offensichtlich auch in ein unverschlüsseltes Tablespace gleichen Namens importiert werden kann.

Zur Vorbereitung wird die Tabelle EMP mit DROP TABLE wieder gelöscht. Ausserdem wird das im vorangegangenen Abschnitt angelegte unverschlüsselte Tablespace ENCRYPTEDUSERS zunächst mit DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES gelöscht und nach den notwendigen Vorbereitungsschritten (sqlnet.ora anpassen, Wallet anlegen) wieder neu, aber als verschlüsseltes Tablespace angelegt.

Data Pump Import wird nun genauso aufgerufen wie im letzten Abschnitt (Abschnitt 5). Auch hier zeigen SELECTs auf EMP und ANGESTELLTE, dass die Tabellen importiert worden. Ausserdem zeigt ein SELECT auf USER_TABLES erneut, dass die Tabelle ANGESTELLTE im verschlüsselten Tablespace ENCRYPTED_USERS liegt

SQL orcl> SELECT table_name, tablespace_name
  2  FROM user_tables
  3* WHERE table_name like 'ANG%'

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
ANGESTELLTE                    ENCRYPTEDUSERS

Es macht hier im Übrigen keinen Unterschied, ob das vorliegende dump file set verschlüsselt ist oder nicht. Deshalb wird an dieser Stelle auf eine detailliertere Beschreibung verzichtet.

Erwartungsgemäß bereitet das Importieren verschlüsselter oder unverschlüsselter dump file sets in verschlüsselte oder unverschlüsselte Datenstrukturen keinerlei Probleme. Das Format der ursprünglichen Datenspeicherung - verschlüsselt oder unverschlüsselt - und des dump file sets - verschlüsselt oder unverschlüsselt - spielt für den Erfolg des Imports keine Rolle. Sollen die Daten nach dem Import auf jeden Fall verschlüsselt sein, müssen die Tablespaces, in die diese Daten geladen werden, zum Zeitpunkt des Imports bereits als verschlüsselte Tablespaces existieren.

Wir führen nun als Ergänzung einen Export aus, für den die Parameter Datei des Exports aus Abschnitt 1 modifiziert wird: Der Eintrag ENCRYPTION_PASSWORD wird gelöscht und ENCRYPTION_MODE auf TRANSPARENT gesetzt. Nach erfolgreichem Export werden erneut die Tabellen EMP und ANGESTELLTE mit DROP TABLE gelöscht.

Der Import wird nun ohne Angabe eines Passwortes durchgeführt. Erneut wird mit SELECTs auf die zuvor gelöschten Tabellen und die View USER_TABLES verifiziert, dass die Aktion gelungen ist.

Dieser Tipp ersetzt nicht die Beschäftigung mit den relevanten Kapiteln aus dem Utility Guide und dem Handbuch Packages and Types.