Unser Newsletter rund um technische Themen,
das Unternehmen und eine Karriere bei uns.

3 Minuten Lesezeit (628 Worte)

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

Die Sicherheit der Daten in der Datenbank spielt eine große Rolle. Wie kann man die Daten schützen? Was passiert, wenn Hardware verloren geht? Dürfen Datenbank-Administratoren alles sehen? All dies sind Fragen, die mit verschiedenen Lösungen beantwortet werden können.

Eine dieser Lösungen ist die Verschlüsselung der Daten innerhalb der Datenbank. Dies kann transparent oder intransparent zum Anwender erfolgen. 

Unterschied Transparente und Intransparente Datenverschlüsselung

Eine intransparente oder auch programmatische Datenverschlüsselung bedeutet, dass die Daten bei einer Abfrage verschlüsselt angezeigt werden.

Bei einer transparenten Verschlüsselung hingegen werden die Daten innerhalb der Datenbank verschlüsselt. Somit ist für den Anwender, beziehungsweise gegenüber der abfragenden Instanz, keine Verschlüsselung spürbar.

Der Use-Case dieser Varianten ist daher unterschiedlich, da die programmatische Verschlüsselung gegen unberechtigten Zugriff auf bestimmte Daten innerhalb der Datenbank hilft. Die transparente Verschlüsselung hilft dagegen nicht. Sie dient zum Schutz vor Dateneinsicht, wenn beispielsweise Hardware gestohlen wurde oder ein Angreifer Zugriff über das Betriebssystem auf das Filesystem bekommt. In der folgenden Abbildung sind verschiedene Angriffsziele (Targets) dargestellt, bei denen die Angreifer direkten Zugriff auf die Daten erlangen können. Rot umrandet sind dabei die Targets, die wir gezielt mit der Verschlüsselung innerhalb der Datenbank sichern können.

Targets: Angriffspunkte mit direktem Datenzugriff

Intransparente / Programmatische Verschlüsselung In der Oracle-Datenbank

Für die programmatische Verschlüsselung der Daten innerhalb der Oracle-Datenbank können die PL/SQL-Pakete DBMS_OBFUSCATION_TOOLKIT und DBMS_CRYPTO verwendet werden. Zu beachten ist hierbei, dass DBMS_OBFUSCATION_TOOLKIT ab der Version 12.1 als veraltet gilt und von Oracle nicht weiterentwickelt wird. Der Nachfolger DBMS_CRYPTO umfasst alle Funktionalitäten dieses Pakets und bietet darüber hinaus einiges mehr. Im Folgenden wird demnach die programmatische Verschlüsselung mit DBMS_CRYPTO beschrieben.

DBMS_CRYPTO bietet sowohl allgemeine Verschlüsselungs- also auch Hash- und Keyed Hash (MAC-) Prozeduren an. Zusätzlich bietet dieses Paket die Möglichkeit einen randomisierten Schlüssel bestehend aus Bytes, Binären Integers oder Numbers zu generieren. Verschlüsselt werden können die Datentypen CLOB, BLOB und RAW, weshalb eine Konvertierung des zu verschlüsselnden Wertes durchgeführt werden muss. Die Konvertierung wird mit der Methode UTL_I18N.STRING_TO_RAW durchgeführt.

Für die allgemeine Verschlüsselung der Daten werden die Algorithmen RC4, DES, 3DES, 3DES_2KEY und AES128/192/256 angeboten. Bei der Auswahl des Algorithmus sollte darauf geachtet werden, dass die Schlüssellänge mehr als 164 Bit beträgt. Eine simple Verschlüsselung eines Datensatzes kann dem folgenden Quellcode-Ausschnitt entnommen werden:

DECLARE
-- 256 Bit Schlüssel
  v_schluessel    	RAW(32) := DBMS_CRYPTO.RANDOMBYTES (32);    
-- zu verschlüsselnder Text
  v_klartext          	VARCHAR2(2000) := 'ORDIX Blog Beitrag'; 
-- Verschlüsselungsalgorithmus
  v_algorithmus   	NUMBER := DBMS_CRYPTO.ENCRYPT_AES256        
                                   -- Blockchiffre
        					      + DBMS_CRYPTO.CHAIN_CBC  
        					       -- Padding
                               	  + DBMS_CRYPTO.PAD_PKCS5;
-- verschlüsselter Text für die Zwischenspeicherung
  v_text_verschluesselt RAW(2000);

BEGIN
  v_text_verschluesselt := DBMS_CRYPTO.ENCRYPT (
     src => UTL_I18N.STRING_TO_RAW (v_klartext, 'AL32UTF8'), -- Konvertierung in RAW
     typ => v_algorithmus,
     key => v_schluessel
  );
  -- Insert des verschlüsselten Textes in eine RAW(2000) Spalte
  insert into test1_enc(crypto_test)
    values (v_text_verschluesselt);
END;
/ 

Dabei entsteht beispiehaft der folgende Wert:

SELECT * FROM test1_enc;
RpQioSFIA2nJx2IU/YOSK10jLAaDjZ44zg7PHWvwz0I= 

Somit wurde der Klartext „ORDIX Blog Beitrag" verschlüsselt und ist nicht mehr zu erkennen. Da ein eigens festgelegter, wahlweise generierter Schlüssel benötigt wird, muss sich hierbei die Frage gestellt werden: Wo lege ich meinen Schlüssel ab? Wo ist dieser Schlüssel für die Entschlüsselung dauerhaft verfügbar? Wo ist er sicher?

In dem nächsten Blogbeitrag beschäftigen wir uns mit dem Thema „Transparente Verschlüsselung", auch TTE (Transparent Tablespace Encryption) oder TDE (Transparent Data Encryption) genannt.

{loadmoduleid 179}
 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Sonntag, 22. Dezember 2024

Sicherheitscode (Captcha)

×
Informiert bleiben!

Bei Updates im Blog, informieren wir per E-Mail.