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.
Der Eintrag hat zunächst keinerlei Konsequenzen. Erst der Befehl
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
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
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:
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
|