Daten verschlüsseln mit Transparent Data Encryption (TDE)
von Heinz-Wilhelm Fabry, ORACLE Deutschland GmbH

Im August 2008 wurde in einem Tipp der Community bereits vorgestellt, wie man in allen Editionen der Datenbank mit dem Package DBMS_CRYPTO Daten in der Datenbank prozedural ver- und entschlüsselt. Es gibt eine wesentlich einfachere Möglichkeit, mit verschlüsselten Daten zu arbeiten, wenn man sich entschließen kann, die Advanced Security Option (ASO) einzusetzen. Damit fallen zwar zusätzliche Lizenzgebühren an, aber der Erwerb einer Lizenz für ASO erlaubt im Rahmen des Feature Transparent Data Encryption (TDE) neben der Verschlüsselung von Benutzerdaten die Verschlüsselung von

  • Backups mit RMAN (nicht zur verschlüsselten Speicherung ohnehin verschlüsselter Daten, sondern zur Verschlüsselung z.B. des Backups der Tablespaces SYSTEM und SYSAUX oder anderer Datenbank-Backups auf dem gleichen Knoten)
  • Exports mit Data Pump
Als Exkurs sei zusätzlich darauf hingewiesen, dass der Einsatz von ASO es außerdem ermöglicht
  • den kompletten Datenverkehr von und zur Datenbank zu verschlüsseln.
  • LDAP-Verzeichnisse zur Benutzerverwaltung der Datenbankbenutzer einzubinden - sicherlich ein wesentliches Element zum Aufbau sicherer IT-Umgebungen
  • Mechanismen zur starken Authentisierung der Benutzer - z.B. in Form von Smartcards - einzusetzen
In diesem Beitrag wird beschrieben, wie man TDE einsetzt, um Benutzerdaten zu verschlüsseln.

Einleitung

TDE wurde in Oracle Database 10g eingeführt. Es ist damit möglich, Tabellenspalten zu verschlüsseln. Allerdings gibt es bei dieser Variante der Verschlüsselung eine ganze Reihe von Einschränkungen. Sie betreffen z.B. die Datentypen, die verschlüsselt werden können, oder auch die Indizes, die auf eine verschlüsselte Spalte gelegt werden dürfen. Ebenso ist es beispielsweise unmöglich, Fremdschlüsselspalten zu verschlüsseln.

Mit Oracle Database 11g kann man nun ganze Tablespaces verschlüsseln. Dabei gibt es keinerlei Einschränkungen bezüglich Datentypen, Indizes, usw. Weil das Ver- und Entschlüsseln von Tablespaces im Rahmen der Ein- / Ausgabeoperation erfolgt, ist es auch noch performanter als das Verschlüsseln vieler einzelner Spalten. Es ist deshalb sicherlich verständlich, dass der Tablespace-Verschlüsselung im Allgemeinen der Vorzug gegeben wird. Zu beachten ist lediglich, dass ein Tablespace nicht nachträglich verschlüsselt werden kann, sondern immer als verschlüsselt angelegt werden muß. Vorhandene Daten müßten also mit einem CREATE TABLE AS SELECT, mit einem Export / Import oder anderen Verfahren in ein verschlüsseltes Tablespace verschoben werden.

Vorbereitung: Wallets, Passwörter und Schlüssel

Es mag vielleicht auf den ersten Blick verwundern, aber den größten Raum beansprucht in diesem Beitrag der Umgang mit sogenannten Wallets, Passwörtern und Schlüsseln. Das liegt aber daran, dass das eigentliche Verschlüsseln sehr einfach deklarativ beim Anlegen oder Ändern der zu verschlüsselnden Objekte veranlasst wird. Dagegen erfordert der Umgang mit Wallets, Passwörtern und Schlüsseln schon einige Vorüberlegungen.

Verschlüsselungsverfahren wie AES oder Blowfish sind jedermann zugänglich. Es ist kein Geheimnis, wie sie funktionieren. Allerdings verwenden diese Verfahren einen vom Anwender zu ergänzenden Wert, der das Ergebnis der Verschlüsselung bestimmt, den sogenannten Schlüssel. Wer den Schlüssel kennt und weiß, welches Verfahren zur Verschlüsselung angewendet wurde, hat Zugriff auf die verschlüsselten Informationen. Da die Bestimmung des Verschlüsselungsverfahrens z.B. für einen Hacker relativ einfach ist, liegt die Sicherheit verschlüsselter Informationen im Schlüssel. Darum ist auch die Sicherung (Verwaltung) und ausreichende Komplexität (Erzeugung) der Schlüssel absolut entscheidend.

Verwaltung und Erzeugung der Schlüssel erfolgen im Rahmen von TDE immer komplett durch die Datenbank. Dabei wird nicht zwischen der Spalten- und Tablespace-Verschlüsselung unterschieden. Das Verfahren ist zweistufig: Jede Tabelle und jedes Tablespace verfügt über einen eigenen Schlüssel, mit dem die dazugehörigen Daten ver- und entschlüsselt werden. Dieser Schlüssel wird nach den Vorgaben des Anwenders von Oracle erzeugt und innerhalb der Tabelle bzw. des Tablespace gespeichert. Die zweite Stufe ist der sogenannte Master Key, ein Schlüssel, der ausschließlich dazu dient, die Schlüssel der Tabellen und Tablespaces zu ver- und zu entschlüsseln. Auch dieser Schlüssel wird durch die Datenbank automatisch erzeugt, allerdings ohne irgendeine Einflußnahme des Anwenders. Ausserdem wird dieser Master Key ausserhalb der Datenbank gespeichert.

Zur Speicherung des Master Keys wird entweder eine kleine, selbstverständlich verschlüsselte Datei, ein sogenanntes Wallet, auf der Betriebssystemebene genutzt oder ab Oracle Database 11g - selten und nur bei sehr hohen Sicherheitsanforderungen - ein eigenes Stück Hardware, ein sogenanntes Hardware Security Modul (HSM). In der Datei sqlnet.ora wird festgelegt, welche Variante genutzt wird. Im folgenden Beispiel wird angegeben, dass der Master Key in einem Wallet angelegt und verwaltet wird und in welchem Verzeichnis dieses Wallet anzulegen bzw. zu finden ist. Obwohl es für unterschiedliche Betriebssysteme unterschiedliche Default-Einstellungen für den Speicherort des Wallet gibt, ist es dennoch empfehlenswert den Speicherort explizit zu benennen.
ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE)
                             (METHOD_DATA = (DIRECTORY = $ORACLE_HOME/network/admin))
                             )
Der Eintrag hat zunächst keinerlei Konsequenzen. Erst der Befehl
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "daspasswort"
vollendet den Arbeitsschritt. Das Datenbanksystem legt nun in dem in der sqlnet.ora angegebenen Verzeichnis eine verschlüsselte Datei mit dem Namen ewallet.p12 an und speichert in dieser Datei den Master Key, der NICHT identisch ist mit dem Passwort daspasswort aus dem Befehl ALTER SYSTEM oben. Wird das Passwort ohne Anführungszeichen eingegeben, muss es später in Großbuchstaben eingegeben werden. Eine Änderung des Master Key ist über den gleichen ALTER SYSTEM-Befehl möglich (mit gültigen Passwort!). Der neue Master Key wird ebenfalls in der Datei ewallet.p12 gespeichert.

Der folgende Screenshot zeigt, dass das Anlegen des Wallet und das Erzeugen des Master Key auch im Enterprise Manager (hier Database Control) möglich ist. Im Screenshot wird als Speicherort vom Default Gebrauch gemacht, eine Ergänzung der sqlnet.ora um den Parameter ENCRYPTION_WALLET_LOCATION erfolgt hier nicht.


Zum Vergrößern bitte auf das Bild klicken

Nach den Erläuterungen oben ist sicherlich klar, dass in administrativer Hinsicht das Wallet das zentrale Element von TDE darstellt. Deshalb sind einige Hinweise zum Wallet unbedingt angebracht.

Zugriff auf verschlüsselte Daten erhält man nur über ein geöffnetes Wallet. Das Öffnen erfolgt bei jedem Start der Datenbank über den Befehl
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "daspasswort"
Es muss das Passwort verwendet werden, das beim Anlegen des Wallet angegeben wurde bzw., falls das Passwort zwischenzeitlich verändert wurde, muss natürlich das letzte gültige Passwort angegeben werden. Sofern die Sensitivität der Daten es erfordert, kann im Rahmen der Aufgabenverteilung und Funktionstrennung die Eingabe des Befehls einem eigenen DBA übergeben werden, den man auch als Security-DBA bezeichnet. Nur dieser würde das zum Öffnen des Wallet nötige Passwort kennen.

Nach dem Öffnen des Wallet wird der Master Key ausgelesen und in der SGA vorgehalten. Das Wallet selbst wird deshalb von der laufenden Datenbank nicht mehr benötigt - was z.B. die Möglichkeit eröffnet, das Wallet auf einem Stick zu speichern und diesen Stick, nach der Öffnung der Datenbank, vom Rechner abzuziehen und an einer sicheren Stelle aufzubewahren.

Es ist möglich, das Wallet automatisch bei jedem Start zu öffnen. Man spricht dann von einem sogenannten auto open oder auto login wallet. In der Regel wird man diese Möglichkeit eher auf Test- und Entwicklungsumgebungen nutzen und nicht in produktiven Umgebungen. Das automatische Öffnen des Wallet ist mit dem Oracle Wallet Manager (owm) zu veranlassen. Es wird dann im selben Verzeichnis, in dem auch die Datei ewallet.p12 liegt, eine Datei ewallet.sso angelegt, in der das benötigte Passwort verschlüsselt gespeichert ist. Mit dem owm ist auch das Passwort für das Wallet zu ändern, das, um nochmals darauf hinzuweisen, NICHT identisch ist mit dem Master Key. Beide Möglichkeiten, Änderung des Passwortes und der auto login-Eigenschaft, sind im folgenden Screenshot angedeutet.


Zum Vergrößern bitte auf das Bild klicken

Der Master Key kann mit dem Befehl
ALTER SYSTEM SET ENCRYPTION WALLET CLOSE -- OHNE identified by "daspasswort"!
aus der SGA entfernt werden. Um einen Zugriff auf verschlüsselte Daten wieder zu ermöglichen, muss das Wallet erneut explizit geöffnet werden.

Das Wallet sollte immer gesichert werden, nachdem das Passwort oder der Master Key geändert wurden. Es gibt KEINE Möglichkeit (kein Hintertürchen oder sogenanntes backdoor), verschlüsselte Daten ohne den Master Key aus dem Wallet zu entschlüsseln. Geht das Wallet verloren, sind auch die Daten verloren. Auch im Rahmen des normalen Backup der Datenbank sollte man sich eine Strategie für das Sichern des Wallet überlegen. Vor allem bei Verwendung eines auto login-Wallets wird dringend davon abgeraten, das Wallet zusammen mit dem Backup abzulegen: Der Diebstahl des Backups würde dazu führen, dass der Dieb ganz einfach Zugriff auf die verschlüsselten Daten erlangen kann.

Tabellenspalten, SecureFile LOBs und Tablespaces verschlüsseln

Nach dem Anlegen des Wallet und des Master Key können Tabellenspalten, SecureFile LOBs und auch ganze Tablespaces verschlüsselt werden - ganz einfach indem beim Anlegen der Objekte die Verschlüsselungsklausel genutzt wird:
CREATE TABLE tabellenname (spaltenname varchar2(2000) ENCRYPT USING 'AES256' SALT,
                           lobspalte blob) LOB (lobspalte) STORE AS SECUREFILE (ENCRYPT USING 'AES256') 
...
CREATE TABLESPACE sicheristsicher 
                  DATAFILE '/app/oracle/oradata/dateiname.dbf' SIZE 10G 
                  ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT)
Alle Daten, die in die Tabelle oder in das Tablespace eingefügt bzw. dort manipuliert werden, werden unter Beibehaltung der bekannten Befehle ohne weitere Klauseln - in der Oracle-Terminologie 'transparent' - ver- bzw. entschlüsselt. Neben dem in den Beispielen genannten zur Zeit stärksten in der Datenbank verfügbaren Verschlüsselungsalgorithmus AES256 sind folgende Algorithmen verfügbar: 3DES168 sowie AES128 und AES192. Andere Algorithmen oder Open Source-Verfahren wie Blowfish können nicht verwendet werden. Innerhalb einer Tabelle muss für alle verschlüsselten Spalten der gleiche Algorithmus zur Verschlüsselung gewählt werden.

Der Benutzer kann bei der Spaltenverschlüsselung zwischen salt und no salt wählen. Soll ein Index auf die Spalte gelegt werden, ist nur NO SALT möglich. Die Option salt veranlasst, dass dem zu verschlüsselnden Wert zusätzliche Zeichen hinzugefügt werden. Dadurch ergibt die Verschlüsselung gleicher Werte bei gleichem Verschlüsselungsverfahren und gleichem Schlüssel jeweils ein anderes Verschlüsselungsergebnis. Das erhöht zwar die Sicherheit, läßt allerdings auch die Datenmenge pro verschlüsseltem Wert um 16 Bytes anwachsen. Sofern die Datenmenge ein Problem darstellt, kann bei der Spaltenverschlüsselung auch darüber nachgedacht werden, das standardmäßig aktivierte Prüfsummenverfahren SHA-1 zu deaktivieren. Dieses Deaktivieren erfolgt bei der Spaltendeklaration über einen Parameter mit Namen NOMAC. Ein Verzicht auf die Prüfung auf Manipulation der verschlüsselten Daten reduziert die Datenmenge noch einmal um 20 Bytes pro verschlüsseltem Wert.

Während Tabellenspalten mit ALTER TABLE auch nachträglich verschlüsselt werden können und die Verschlüsselung nachträglich auch komplett aufgehoben werden kann, ist eine nachträgliche Änderung oder Aufhebung der Verschlüsselung eines Tablespace nicht möglich. Auch eine nachträgliche Schlüsseländerung - die z.B. nach dem Pseudostandard PCI-DSS der Kreditkartenbranche in regelmäßigen Abständen durchgeführt werden muss - ist bis zu Oracle Version 11.1.0.7 nur bei der spaltenweisen Verschlüsselung erlaubt. Ob diese Einschränkung mit Version 11.2 fällt, bleibt abzuwarten.

Eine Schlüsseländerung für Tabellenspalten kann sowohl auf der Ebene des Master Key als auch auf der Ebene der Tabelle durchgeführt werden. Bei der Änderung des Master Key werden lediglich die Tabellenschlüssel neu verschlüsselt, was natürlich wenig zeitaufwändig ist. Wird ein Tabellenschlüssel geändert oder eine Spalte nachträglich verschlüsselt, ist zu beachten, dass eine Neuverschlüsselung des Tabelleninhalts durch ein UPDATE auf alle Zeilen erfolgt, die in einer verschlüsselten Spalte einen Wert enthalten. Je nach Größe der Tabelle kann das selbstverständlich extrem viel Zeit beanspruchen und zusätzlich Endanwender behindern, die im Rahmen ihrer Aufgaben Zeilen ändern müssen.


Zurück zur Community-Seite