Verschlüsselung in der Oracle-Datenbank (2/2)

Transparente Datenverschlüsselung in der Oracle-Datenbank

In diesem Teil der Reihe geht es um die transparente Verschlüsselung von Daten in einer Oracle-Datenbank. In Teil 1 wurde bereits besprochen, wie Daten programmatisch verschlüsselt werden.

Transparente Verschlüsselung (engl. Transparent Data Encryption – TDE) ist eine Art der Verschlüsselung, die innerhalb der Datenbank passiert. Wir als Anwender merken davon erstmal nichts. Aber warum sollte man überhaupt TDE verwenden?

Der Blick auf das Schaubild zeigt, dass es verschiedene Angriffspunkte (Targets) gibt. Rot umrandet sehen wir dabei die Targets, die einen direkten Zugriff auf die Daten darstellen. Mit der programmatischen Verschlüsselung haben wir bereits den Fall abgedeckt, dass ein DBA oder jegliche abfragende Instanz Zugriff auf den Inhalt der enthaltenen Daten bekommt, wenn diese Person bereits Zugriff auf das Datenbanksystem hat.

Transparente Verschlüsselung hilft uns nun dabei, weitere Targets zu schützen. Beispielsweise wird es unmöglich gemacht, über das Betriebssystem an die Daten zu kommen. Auch ein Diebstahl der Hardware oder eine Kopie der Data Files würde es den Angreifern nicht ermöglichen, die Daten auszulesen.

Voraussetzungen für transparente Verschlüsselung 

Anzumerken ist, dass die transparente Verschlüsselung nur mit Erwerb der „Advanced Security Option" on-Premises verfügbar ist. In der Oracle Cloud Infrastructure ist eine transparente Verschlüsselung immer aktiviert.

Für die Verschlüsselung muss zunächst ein Keystore erstellt werden. Über den Befehl...

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY PASSWORD; 

...wird ein Keystore angelegt. Hierbei ist darauf zu achten, dass ein regelkonformes Passwort gewählt wird. Es stellt sich wieder die Frage, wo und wie dieses Passwort gespeichert/abgelegt wird. Wer dieses Passwort besitzt, kann den Zugriff auf die Daten ermöglichen.

Ist der Keystore angelegt, so können Master Keys generiert und anschließend verwendet werden. Ein Master Key ist der Schlüssel, den die Datenbank intern benötigt, um die Daten zu verschlüsseln. Dieser wird pro Datenbank angelegt. Bei der Multi-Tenant-Architektur wird ein Master Key pro Container angelegt. Ausgenommen ist die PDB „PDB$SEED". Somit haben wir selbst bei einer einzigen PDB zwei Keys.

Um Keys anzulegen wird der Befehl CREATE KEY verwendet. 

ADMINISTER KEY MANAGEMENTE CREATE KEY 
[USING TAG ‘KEY‘] 
[USING ALGORITHM ‘AES192‘]
IDENTIFIED BY PASSWORD 
[CONTAINER=ALL/CURRENT]; 

Durch die Verwendung der Container=ALL -Klausel werden in diesem Schritt n Keys, gemäß der Anzahl der Container, generiert. Durch die Verwendung eines Tags kann dann leicht herausgefunden werden, welcher Key durch dieses Statement generiert wurde. Die erstellten Keys können über die View V$ENCRYPTION_KEYS abgefragt werden. Mit der dort hinterlegten ID können dann die Keys pro Container aktiviert und verwendet werden. Bei der Aktivierung des Keys kann die Container=ALL – Klausel nicht verwendet werden.

ALTER SESSION SET CONTAINER=PDB1;
ADMINISTER KEY MANAGEMENT USE KEY ‘KEY_ID‘ IDENTIFIED BY PASSWORD; 

Damit sind die Vorbereitungen für TDE abgeschlossen.

transparent verschlüsseln 

Grundsätzlich kann bei der transparenten Verschlüsselung auf Spalten- und Tablespace-Ebene verschlüsselt werden. Hierbei wird eine Vielzahl an Verschlüsselungsalgorithmen zur Verfügung gestellt, namentlich ARIA, SEED, GOST, 3DES und AES. Die Unterschiede in diesem Artikel zu erläutern würde den Rahmen des Blog-Beitrages sprengen. Empfohlen werden können aber aktuell die Algorithmen AES192 und AES256, sowie ARIA192 und ARIA256.

Um eine Spalte in einer schon vorhandenen Tabelle zu verschlüsseln, muss diese lediglich mit einem ALTER TABLE - Kommando angepasst werden:

ALTER TABLE T_ENC_1 MODIFY (a ENCRYPT USING ‘AES256‘); 

Hierbei gibt es ebenfalls die Möglichkeit, das Ganze mit ein wenig Salz zu verfeinern. Salz? Ja, richtig gelesen. Mit dem Parameter SALT wird erreicht, dass sich identischer Klartext nach der Verschlüsselung unterscheidet. Somit können die verschlüsselten Daten nicht verglichen und damit auch keine Rückschlüsse auf die darin enthaltenen Daten gezogen werden.

ALTER TABLE T_ENC_1 MODIFY (a ENCRYPT USING ‘AES256‘ SALT); 

Der Nachteil des Salt-Verfahrens ist, dass pro Datensatz 16 Bit mehr Speicherplatz belegt werden und wegen anderer Sortierung im Index die Performance leiden kann.

Tablespace verschlüsselung 

Bei der transparenten Tablespace-Verschlüsselung wird auf Block-Ebene verschlüsselt. Das bietet den Vorteil, dass es hierbei kaum zu Performance-Einbußen kommt. Die Online-Verschlüsselung ist ab der Version 12.2 möglich. Hierbei sind die Algorithmen identisch zu denen der Spalten-Verschlüsselung. Bei einer Offline-Verschlüsselung können lediglich ab der Version 19c alle Algorithmen verwendet werden. Bei allen Versionen <19c ist der Algorithmus AES128 vorgegeben. Um ein verschlüsseltes Tablespace anzulegen, wird der folgende Befehl verwendet:

CREATE TABLESPACE ts_encrypt DATAFILE […] ENCRYPTION USING ‘AES256‘ ENCRYPT; 

Ob nun einzelne Spalten oder gleich ganze Tablespaces verschlüsselt werden, ist eine Frage der Priorisierung. Die praktische Anwendung dieser Technologien und weitere Wege der Verschlüsselung in und um die Oracle Datenbank werden in unserem kostenlosen Webinar „Oracle Verschlüsselung"  und in unserem Seminar „Oracle Security" erläutert.