12.2 RAC: Erste Erfahrungen mit TDE und Wallets

Um die Inhalte der Datenbank zu entschlüsseln muss dafür gesorgt werden, dass das Wallet offen ist. Dazu muss die Datenbank-Instanz wissen wo das Wallet-File liegt. Den Pfad dazu teilt man der Instanz über die SQLNET.ORA Datei mit. 

Über SQL-Befehle kann das Wallet geöffnet und geschlossen werden. Außerdem können darüber noch weitere administrative Operationen wie z.B. das Erneuern des Master-Keys ausgeführt werden. 

Seit der Oracle Datenbank Version 12.2.0.1 ist es zudem möglich die bereits vorhandenen Tablespaces SYSTEM und SYSAUX online zu verschlüsseln. Das gibt uns erstmalig die Möglichkeit die gesamte Datenbank zu verschlüsseln. 

Bei der Administration der Datenbank - ob komplett verschlüsselt oder nicht - muss jedoch auf ein paar Feinheiten geachtet werden. 

Wallet Speicherort bei Oracle RAC

Anfangs stellt sich die Frage, wo das Wallet eigentlich liegen soll, denn jede Instanz im RAC benötigt ja Zugriff darauf. 

ASM

Zuerst dachten wir, dass es am besten wäre, das Wallet ins ASM zu legen. Denn hier haben automatisch alle Instanzen Zugriff und das Wallet ist durch die Redundanz der Diskgroup mehrfach gesichert. 

Leider gibt es seit der Datenbank-Version 12.1.0.2 einen Bug, der die Kopie des Wallets korrumpiert, sobald es mit dem Tool „asmcmd“ von ASM auf das lokale Filesystem kopiert wird. Merken wird man das aber leider erst zu spät, denn das Kopieren an sich ist erfolgreich.

Mehr dazu im MOS: 

Cannot open wallet from local filesystem after cp from ASM with asmcd (Doc ID 2085607.1)

Stellen Sie sich vor, Sie sichern im Rahmen ihres DR-Konzepts das Wallet außerhalb von ASM, wobei keine Fehler gemeldet werden. Im DR-Fall wollen sie nun das gesicherte Wallet und damit die zurückgespielte Datenbank wieder öffnen und erhalten plötzlich folgende Fehlermeldung: 

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN identified by <passwd>
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN identified by <passwd>
*
ERROR at line 1:
ORA-28353: failed to open wallet

Ein Schock für jeden, der das nicht schon bei Tests erkannt hat. 

Lokales Filesystem

Also legen wir das Wallet lieber doch pro Instanz in das lokale Filesystem des jeweiligen Servers. 

Es ist beachten, dass man in diesem Fall zuerst das Wallet auf einer Instanz anlegt und den Master-Key mit der „… SET KEY …“ Option setzt. Danach kann das Wallet auf die übrigen Server verteilt werden. Am Ende gibt es also mehrere identische Kopien des Wallets. Bei allen zukünftigen Änderungen am Wallet muss daran gedacht werden, das Wallet wieder auf die anderen Server zu verteilen. 

Der Wallet-Eintrag in der Datei sqlnet.ora könnte wie folgt aussehen: 

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/oracle/admin/$ORACLE_DBNAME/wallet)))

Durch die Variable ORACLE_DBNAME wird das Wallet für jede Datenbank in einem anderen Verzeichnis erstellt/gesucht. 

Sollte die gesamte Datenbank verschlüsselt sein ist noch folgendes zu beachten: 

Bereits beim Starten der Datenbank muss der SYSTEM Tablespace entschlüsselt werden. Dazu ist es zwingend notwendig, dass die Variable $ORACLE_DBNAME vor dem Instanzstart immer richtig gesetzt ist. 

Bei Benutzung von SQLPLUS zum Starten der DB muss sie immer als Umgebungsvariable gesetzt werden. Bei Verwendung von SRVCTL (bei RAC wohl eher üblich) oder einem Clusterstart muss sie in der Cluster-OCR hinterlegt werden: 

srvctl setenv database -db testdb -env "ORACLE_DBNAME=testdb"

Wallet Typ

Es gibt drei verschiedene Wallet-Typen. 

• Normales Wallet:
  Zum Öffnen des Wallets muss manuell das Wallet-Passwort eingegeben werden. Dies ist in den meisten Fällen nicht praktikabel.

• Auto-Login Wallet:
  Wie der Name schon vermuten lässt, muss das Wallet hier nicht manuell geöffnet werden. Stattdessen wird das Wallet-Passwort in gehashter Form in eine zweite Datei geschrieben. Diese Datei ist sozusagen der Schlüssel zum Öffnen des Wallets. Solange sie im selben Verzeichnis wie das Wallet liegt, kann das Wallet automatisch geöffnet werden.
  Daraus ergibt sich allerdings auch der Nachteil, dass diese Datei extrem kritisch für die Sicherheit der Daten ist. Gelangt sie in die falschen Hände, kann damit alles entschlüsselt werden. 

• Local Auto-Login Wallet:
  Diese Erweiterung behebt das Problem, dass das Auto-Login-Wallet File auf jedem Server zum Entschlüsseln verwendet werden kann.
  „Local“ bedeutet hier, dass bei der Erzeugung des Auto-Login Wallets zusätzlich noch Parameter des Servers hinterlegt werden, so dass das Auto-Login Wallet nicht auf einem anderen Server verwendet werden kann. Das erhöht natürlich die Sicherheit der verschlüsselten Daten immens.

Wir verwenden in unserem Fall ein local Auto-Login Wallet.

Verteilen des Wallets

Sobald das Wallet erstellt wurde und einen Master-Key beinhaltet, kopiert man das Wallet auf die restlichen Server des RACs. 

Auf jedem Server muss jetzt zusätzlich noch das local Auto-Login Wallet generiert werden. Dieses ist dann natürlich für jeden Server unterschiedlich. 

Weitere Besonderheiten

Beim Erstellen des Wallets (unabhängig ob RAC oder Single Instance) ist noch etwas zu beachten: 

Erstellen Sie zuerst den Master-Key und erst danach das Auto-Login Wallet. In der Oracle Dokumentation werden Sie das in der falschen Reihenfolge beschrieben finden. Denn sonst laufen Sie in dieses Problem: 

TDE Wallet Problem in 12c: Cannot do a Set Key operation when an auto-login wallet is present (Doc ID 1944507.1)

Die View gv$encryption_wallet ist der zentrale Ort, an dem Sie den Status des Wallets überprüfen können. Auch hier ist Vorsicht geboten, denn Sie dürfen sich nicht auf alle angezeigten Werte verlassen! 

Beispielsweise wurde in unseren Tests der Wert von WALLET_TYPE (Mögliche Werte: PASSWORD | AUTOLOGIN | LOCAL_AUTOLOGIN) nie auf allen Servern einheitlich korrekt angezeigt. 

Erst nach einem Neustart der gesamten Datenbank wurde der Wert wieder korrekt angezeigt. Allerdings war die Spalte WRL_PARAMETER, welche den Wallet-Pfad anzeigt stets korrekt.

Fazit

Wenn man die oben beschriebenen Feinheiten beachtet, steht einem verschlüsselten RAC nichts mehr im Wege. 

Vor allem im Zusammenspiel mit dem neuen Parameter ENCRYPT_NEW_TABLESPACES, mit dem jeder neu angelegte Tablespace automatisch verschlüsselt wird, erhalten Sie eine dauerhafte und solide Verschlüsselung ihrer sensiblen Datenbanken. Allerdings werden automatisch verschlüsselte Tablespaces nur mit dem Algorithmus AES 128 verschlüsselt. Wer mehr will, muss dies doch explizit angeben.