• Doku
• HowTo
  • Oracle
   • Admin
   • Install
   • Encrypt
   • Defrag
   • Tuning
   • External Calls
  • MaxDB
  • HowTo CVS
  • Linux (Unix)
  • IBM(AIX)
  • Windows
  • OpenSSL
  • Setup Server
• Australien
• Links
• Impressum

TDE (Transparen Data Encryption)

Verschlüsselung von Spalten innerhalb der Datenbank

Mit der Version 10g Release 2 hat Oracle die (für Applikationen) transparent Verschlüsselung einzelner Spalten eingeführt. Bisher war es möglich, z.B durch gestohlene Backup-Medien an die original-Daten einer Tabelle/Spalte zu kommen.
Um dies zu verhindern bietet sich die Verschlüsselung einzelner Spalten an. Dies war bisher nur durch externe Tools oder Packages möglich. Mit der TDE bietet nun Oracle einen sehr eleganten Weg an, transparent für alle bereits bestehenden Applikationen einzelne Spalten zu verschlüsseln.
Eigendlich muss man nur die zu verschlüsselde Spalte als zu verschlüsseln Markieren. Alles ander erledigt die Datenbank für einen
(na ja .... fast alles, schließlisch wollen DBA's auch von irgend etwas leben)
aber sehn wir einmal selbst.

{Grundprinzip}
Das Grunzrinzip ist relativ einfach. Für jede zu verschlüsselnde Spalte erstellt Oracle intern einen kryptogrphisch sicheren Schlüssel mit der die Spalte Ver- und Entschlüsselt werden kann. Dieser Schlüssel wird im Data-Dictionary (also innerhalb der Datanbank) gespeichert.
Da dieser Schlüssel natürlich nicht als Klartext in der Datenbank hinterlegt sein darf, werden alle Spaltenschlüssel mit einen "Master-Key" verschlüsselt bevor sie im Data-Dictionary gespeichert werden.
Dieser "Master-Key" befindet sich in einem sog. Wallet, welches sich NICHT innerhalb der Datenbank befindet (z.B. in einem File auf dem Datenbank-Server).

Falls ein User nun Daten in eine verschlüsselte Spalte einfügt werden folgende Aktionen innerhalb der Datenbank ausgelöst:

• Oracle liest dem "Master-Key" aus dem Wallet
• Der Spaltenschlüssel wir mit Hilfe des "Master-Keys" entschlüsselt
• Der nun entschlüsselte Spaltenschlüssel wird verwendet um die Daten zu verschlüsseln bevor sie in die Spalte geschrieben werden.

Beim lesen der Spalte wird auf dem gleichen Weg entschlüsselt:

• Oracle liest dem "Master-Key" aus dem Wallet
• Der Spaltenschlüssel wir mit Hilfe des "Master-Keys" entschlüsselt
• Der nun entschlüsselte Spaltenschlüssel wird verwendet um die gelesenen Daten zu entschlüsseln bevor sie an die Applikation geliefert werden.

Da nun in der Datenbank verschlüsselte Daten stehen sind bei allen downstream Komponenten (Backup, Archive-Log's ...) nur die verschlüsselten Daten sichtbar, mit denen ein Dieb ohne den Master-Key nicht sehr viel anfangen kann. Da das Wallet nicht Teil der Datenbank oder des Backups ist ist der Master-Key relativ sicher.

{Einmaliges Setup}

Um TDE zu verwenden sollten wir zuerst den Platz festlegen, an dem sich unser Wallet befindet. Dies können wir (auf dem Datenbank-Server ) in der Datei sqlnet.ora festlegen
(Default $ORACLE_HOME/network/admin)

ENCRYPTION_WALLET_LOCATION =
  (SOURCE=
    (METHOD=file)
    (METHOD_DATA=
      (DIRECTORY=/orawall)))

legt z.B. fest das sich die Wallet-Datei im Verzeichnis /orawall befindet.
Falls in der sqlnet.ora keine Lokation für das Wallet angeben wird, geht Oracle von $ORACLE_BASE/admin/$ORACLE_SID/wallet aus.

Das Wallet sollte auch regeläsig gesichert werden (Aber bitte auf ein anderes Band, als die Datenbank)

Nun müssen wir das Wallet erzeugen. Die machen wir mit:

alter system set encryption key authenticated by "password";

Dieser Befehl:

• Erzeugt ein Wallet an der festgelegten Stelle.
• Setzt das Passwort des Wallets auf "password".
• Öffnet das Wallet, damit es von TDE benutzt werden kann.

Das Passwort ist Case-Sensitiv und MUSS in doppelten anführungszeichen angegeben werden.

Hinweis: Das Passwort des Wallets erscheint NIRGENDS als Klartext. Auch nicht in irgendwelchen dynamische Views oder Logs
Das Wallet brauch nur einmal erstellt werden, daher müssen die obigen Schritte auch nur einmal ausgeführt werden.
Allerdings muss man nun jedesman nach eine Shutdown der Datenbank das Wallet erneut öffnen:

alter system set encryption wallet open authenticated by "password";

Das Wallet kann wie folgt geschlossen werden:

alter system set encrption wallet close;

Damit TDE arbeiten kann muss das Wallet geöffnet sein. Wenn das Wallet geschlossen ist kann auf alle nichtverschlüsselten Spalten zugegriffen werden, aber nich auf verschlüsselte Spalten.

{Spalten verschlüsseln}
Um Spalten zu verschlüsseln muss nur die ENCRYPT Clause beim Erstellen der Spalte mit angegben werden.

Gehen wir von folgenden Beispiel aus:

ACC_NO    NUMBER
ACC_NAME  VARCHAR2(30)
SSN       VARCHAR2(9)

Im obigen Zustand stehen alle Daten der Tabelle als Klartext im Datenfile. Um nun die SSN (Social Security Number) zu verschlüsseln geben wir folgendes ein:

alter table accounts modify (ssn encrypt);

Dieser Befehl bewirkt zwei Dinge:

• Er generiert eine Spaltenschlüssel. (Alle Spalten innerhalb einer Tabelle werden mit dem gleichen Schlüssel verschlüsselt)
.
• Alle Werte die sich bereits in der Spalte der Tabelle befinden werden verschlüsselt

Diese Statement ändert weder den Datentyp noch die größe der Spalte. Es wird auch kein trigger oder View erzeugt.
Die Default Verschlüsselung ist AES mit 192 Bit Schlüssel. Wir können verschiedene Verschlüsselungsmethoden murch eine additionalen Parameter angeben.

alter table accounts modify (ssn encrypt using 'AES128');

obiges statement verwendet AES128 (Advances Encryprion Standard 128 Bit Key) um die Spalte zu verschlüsseln

Nach der Verschlüsselung liefert uns desc folgenden Ausgabe

ACC_NO    NUMBER
ACC_NAME  VARCHAR2(30)
SSN       VARCHAR2(9) ENCRYPT

Hinweis
Um verschlüsselte Spalten in der Datenbank zu finden kann der View DBA_ENCRYPTED_COLUMNS verwendet werden.

{Performance / Geschwindigkeit}
Natürlich verbraucht die Ent- und Verschlüsselung CPU-Zeit und beeinflusst daher auch die Performance des Systems.
Der Zugriff auf nicht Verschlüsselte Spalten ändert sich aber nicht. Falls daher die verschlüsselung einer Spalte nicht mehr notwendig sein sollte, kann man sie mit

alter table accounts modify (ssn decrypt);

beenden.

Ein sehr interresanter Punkt ist die Verwendung von verschlüsselten Spalten in Indices. Gehen wir dazu einmal davon aus, das auf der Spalte SSN ein Index mit dem Namen in_accounts_ssn liegt.

Falls das SQL einen Istgleich-Operator verwendet:

select * from accounts
where ssn = '123456789';

wir der index in_accounts_ssn auch benutzt. Falls aber das LIKE predikat verwendet wird

select * from accounts
where ssn like '1234%';

wird der Index ignoriert und ein Full-Table-Scan durchgeführt.
Der Grund dafür ist einfach:
Der b-Baum eines Indexes stellt sicher das gleiche Werte stetes beieinander liegen ("fraternal" bei "fraternity"). Daher wählt der Optimizer bei einem Like-Predikat immer den Index.
Wenn die Spalte aber verschlüsselt ist, haben ähnliche Werte verschiedene (weil verschlüsselt) Werte und sind daher nicht beieinander sonde wild im Index verteilt. Aus diesem Grund sind Index-Scans "teuerer" als Full-Table-Scans.

Dies sollte auch bei der Entscheidung, welche Spalten verschlüsselt werden ein Rolle spielen.

{Schlüssel und Passwort Management}
Was passiert wenn jemand eine Spaltenschlüssel kennt, oder man den Verdacht hat das jemand die Schlüsen decodiert hat?
Wir generieren uns einfach neue Schlüssel für die Tabelle (rekey) und verschlüsseln alle Werte der Spalten mit dem neuen Schlüssel.
Und da wir schon einmal dabei sind wollen wir auch einen anderen Verschlüselungs-Algorithmus verwenden.
Das kann durch folgenden einfachen Befehl erreicht werden:

alter table accounts rekey using 'aes256';

Und was ist zu tun wenn wir das Wallet-Passwort ändern wollen?.
Dieses Passwort können wir mit Hilfe des "Oracle Wallet Managers" ändern.
Dieses Grafische Tool kann durch die Eeingabe von OWM gestartet. In diesem Tool muß man nur noch das Wallet (die Datei) offnen und kann dann das Passwort ändern.

{Schlüssel "Salzen"}
Bei der Verschlüsselung von Daten geht es darum die Daten unkendlich zu machen, aber manchmal ist es einfach den Wert zu erraten, vor allem wenn sich die gleichen Werte oft wiederholen.
z.B könnet man, wenn einen ein Wert bekannt ist, alle anderen erkennen die den Gleichen Wertr haben (Gehalt usw...)
Hier kommt das "Salzen" ins Spiel. Im Endeffekt bedeudet "Salzen" nur, das geiche Werte bei gleichen Schlüssel unterschiedliche Verschlüsselte Daten ergeben, so das nicht mehr von einem Wert auf andere geschlossen werden kann.

Leider können Indizierte Spalten nicht gesalzen werden (siehe auch im Abschnitt Performance).
Es ist daher auch nicht möglich eine Saplte zu salzen hinter der ein implziter Index steht (Primary Key, Foreign Key oder Unique Key)

alter table accounts modify (ssn encrypt no salt);

Das obige Kommando schaltet das Salzen for die Spalte SSN ab.
Falls man das no salt mit salte ersetzt wir das salzen eingeschaltet.

{Datapump mit TDE}
Wenn wir die Data-Pump mit den Default-Einstellungen benutzen werden alle verschlüsselten Werte als unverschlüsselter Klartext im Dump-File abgelegt -- und wir erhalten ein Warning ----

$expdp scott/tiger tables=accounts

ORA-39173: Encrypted data has been
stored unencrypted in dump file set.

Das ist nur eine Warnung, die Spalten wurden alle korrekt exportiert.
Um unsere Verschlüsselten Daten in den Dump-Files zu schützen können wir unsere Dump-Files durch ein Password schützen. Dieses Passwort, welches als Parameter ENCRYPTION_PASSWORD dem EXPDP übergeben hat NICHTS mit dem Wallet zu tun. Es ist nur für diesen einen Export gültig.

Beim Import des Dump-Files muss das Passwort dann auf die gleiche weise mit übergeben werden:

impd scott/tiger ENCRYPRUIN_PASSWORD=pooh tables=accounts

Hinweis:
Das orginal Export-Utility (EXP) kann Tabellen mit verschlüsselten Werten NICHT exportieren.