Datenverschlüsselung in Oracle Multitenant Umgebungen Claudia Hüffer Oracle Deutschland B.V. & Co. KG Hamburg

Transkript

1 Datenverschlüsselung in Oracle Multitenant Umgebungen Claudia Hüffer Oracle Deutschland B.V. & Co. KG Hamburg Schlüsselworte Oracle 12c, Advanced Security Option, Transparent Data Encryption, Oracle Multitenant, Verschlüsselung, Data in Rest, Container Database, Pluggable Database Einleitung Mit Oracle 12c Release 1 wurde die neue Datenbank-Option Multitenant eingeführt. Daneben steht bereits seit der Version 10g Release 2 mit Transparent Data Encryption eine Möglichkeit zur Verschlüsselung von Datendateien bei der Datei-Ablage (Data in Rest) zur Verfügung. Im vorliegenden Konferenzbeitrag wird der Einsatz von Transparent Data Encryption in Multitenant Umgebungen beleuchtet. Dadurch, dass diese neue Datenbankarchitektur unter anderem auch das schnelle Kopieren/Verschieben ganzer Applikationsumgebungen (Pluggable Databases) von einer Container Datenbank in eine andere erlaubt, ergeben sich vor allem für das Schlüsselmanagement der Transparent Data Encryption neue Aufgabenstellungen. Im Folgenden werden zunächst kurz sowohl die Architektur von Transparent Data Encryption als auch von Oracle Multitenant erläutert. Nach einer kurzen Erläuterung der neuen Oracle 12c Release 1 Transparent Data Encryption Funktionalitäten vor allem dem erweiterten Schlüssel- und Keystore-Management werden verschiedene Szenarien in Multitenant Umgebungen betrachtet und die Besonderheiten, die sich in der Administration aus der Kombination von Transparent Data Encryption mit Multitenant ergeben, beschrieben. Im letzten Kapitel wird ein kurzer Ausblick auf die neuen Funktionalitäten von Transparent Data Encryption mit Oracle 12.2 gegeben. Zum Zeitpunkt der Erstellung des Beitrages stand Oracle 12.2 allerdings noch nicht On Premise zur Verfügung, sodass die Informationen hier auf der bereits verfügbaren Produktdokumentation ( beruhen und noch keine Praxistests enthalten. Oracle Transparent Data Encryption (TDE) Oracle Transparent Data Encryption (TDE) ist Bestandtteil der kostenpflichtigen Oracle Advanced Security Option. Zur Advanced Security Option (ASO) gehören seit Oracle 12c die beiden Komponenten Data Redaction und TDE. Data Redaction ermöglicht eine Laufzeit-Maskierung von Daten bei der Ausgabe. Das Muster der Maskierung wird in Form von Policys bei der Tabelle definiert und führt in Abhängigkeit des Session- Contextes zur gewünschten Maskierung der Daten, wobei das Originaldatum in der Datenbank nicht geändert wird. TDE als zweite Komponente der ASO ermöglicht die Verschlüsselung von Daten bei der Ablage im Storage.

2 Abb. 1: Funktionsumfang der Advanced Security Option TDE wurde mit Oracle 10g Release 2 zunächst in der Variante TDE Column Encryption eingeführt und ermöglichte dort das Verschlüsseln einzelner Tabellen-Spalten. Mit Oracle 11g wurde TDE dahingehend erweitert, dass mit TDE Tablespace Encryption jetzt ganze Benutzer-Tablespaces verschlüsselt werden können. TDE ist komplett transparent für die Applikationen. Benutzer mit Leserechten in der Datenbank, können ihre Daten wie bisher lesen. Angreifer, die jedoch versuchen Informationen aus den Datendateien zu ermitteln, können keine Klartextinformationen mehr in verschlüsselten Tablespaces aufstöbern. Dies gilt auch für Backups der Datenbank. Die folgende Abbildung zeigt die Architektur von TDE. Abb. 2: Architektur von Transparent Data Encryption

3 TDE arbeitet mit einem zweistufigen Schlüsselkonzept. Die Tabellen Keys, die zum Verschlüsseln der einzelnen Tabellenspalten bei TDE Column Encryption verwendet werden, werden verschlüsselt im Data Dictionary abgelegt. Der Schlüssel zum Verschlüsseln der Tabellen Keys ist der sogenannte Master Encryption Key. Der gleiche Master Encryption Key wird auch für das Verschlüsseln des Tablespace Keys für die TDE Tablespace Encryption verwendet. Der Tablespace Key wird verschlüsselt im Header des Tablespaces gespeichert. Der Master Encryption Key auch kurz Master Key genannt - wird außerhalb der Datenbank in einem Software oder Hardware Keystore abgelegt. Der Software Keystore wird auch als Oracle Wallet bezeichnet. Die Master Encryption Keys können alternativ auch in Oracle Key Vault gespeichert werden. Bei Verwendung von Software Keystores (Wallets) stehen drei Arten des Software Keystores zur Verfügung: der Password-Based Software Keystore, der Auto-Login Software Keystore und der Local Auto-Login Software Keystore, der nur auf der Maschine verwendet werden kann, auf der er erstellt wurde. Der Password-based Software Keystore erfordert bei allen Aktionen wie Öffnen, Schließen, Ändern, Sichern stets die Eingabe eines Passwortes. Bei den Auto-Login Wallets ist dies nicht notwendig. Erst, wenn ein Keystore und ein erster Master Encryption Key vorhanden sind, kann mit TDE gearbeitet werden. Jede Datenbank muss ihren eigenen separaten Keystore verwenden. Verschiedene Datenbanken dürfen sich keinen Keystore teilen, dies kann zu komplettem Datenverlust führen. Das Wallet ist die wichtigste Datei bei TDE. Geht sie verloren oder kann sie nicht mehr geöffnet werden, kann kein Zugriff mehr auf die verschlüsselten Daten erfolgen! Ein Wallet darf nie gelöscht werden! Zur Administration des Keystore steht das unten beschriebene Schlüsselmanagement zur Verfügung. Zentrales Statement ist das Statement mit seinen verschiedenen Klauseln. Notwendiges System-Privileg ist das ADMINISTER KEY MANAGAMENT Privileg oder die Zugehörigkeit zur mit Oracle 12c eingeführten Rolle SYSKM. Im Folgenden sind kurz die notwendigen Schritte für die Erstellung von verschlüsselten Tablespaces skizziert. Definition des Speicherortes des Keystores in der sqlnet.ora mit Hilfe des Parameters ENCRYPTION_WALLET_LOCATION: ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=FILE) (METHOD_DATA= (DIRECTORY= /etc/oracle/wallets/orcl)) ) ) Es wird dringend empfohlen, den Speicherort des Wallets explizit anzugeben. Werden auf dem System mit dem gleichen ORACLE_HOME mehrere Datenbanken betrieben, sollten Umgebungsvariablen wie $DB_UNIQUE_NAME oder $ORACLE_SID verwendet werden. Ab Oracle 12c kann das Wallet auch in ASM gespeichert werden. Ist der Speichort nicht definiert, prüft die Datenbank, ob ggf der Parameter ENCRYPTION_WALLET in der sqlnet.ora definiert ist. (Dieser wird oft eingesetzt, wenn das sogenante secure external password file verwendet wird. Das zu dieser Technologie gehörende Wallet sollte man jedoch nicht für TDE verwenden.)

4 Ist dieser Parameter auch nicht gesetzt, sucht die Datenbank unter den Standardverzeichnissen ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet oder im Verzeichnis ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet. DB_UNIQUE_NAME ist der unique Name der Datenbank. Den Ort, an dem die Datenbank das Wallet erwartet, kann man in V$ENCRYPTION_WALLET nachsehen. Liegt der Speicherort fest, kann der Keystore (das Wallet) in SQL*Plus mit folgendem Befehl angelegt werden: CREATE KEYSTORE '/etc/oracle/wallets/orcl' IDENTIFIED BY password; Der Keystore muss nun geöffnet werden, bevor im nächsten Schritt ein Master Encryption Key angelegt werden kann: SET KEYSTORE OPEN IDENTIFIED BY password; Der entsprechende Status wird in V$ENCRYPTION_WALLET (Spalte STATUS) angezeigt. Dieses Wallet ist anders als in Oracle 11g noch ohne Master Encryption Key, der mit folgendem Statement angelegt wird: SET KEY IDENTIFIED BY password WITH BACKUP USING 'emp_key_backup'; Für Passwort basierte Keystores ist die Verwendung der WITH BACKUP Klausel zwingend. So wird bei allen strukturellen Änderungen am Wallet das vorherige Backup des alten Wallets erzwungen. Jetzt sind die Voraussetzungen für TDE erfüllt und es können Tabellenspalten verschlüsselt werden und/oder neue leere verschlüsselte Tablespaces angelegt werden. Bis Oracle 12c Release 1 einschließlich können bestehende Tablespaces nicht nachträglich verschlüsselt werden, sondern müssen als leere neue Tablespaces verschlüsselt erstellt werden. Anschließend würde man die sensiblen Daten in dieses Tablespace übertragen (DataPump, Online Redefinition einzelner Tabellen, CTAS...). Oracle 12.2 wird die Möglichkeit eines nachträglichen Verschlüsselns bereitstellen (siehe weiter unten). Ein verschlüsseltes Tablespace kann jetzt z.b. mit folgendem Kommando angelegt werden: CREATE TABLESPACE securespace_1 DATAFILE '/u01/oradata/orcl/secure01.dbf' SIZE 150M ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT); Die in Oracle 12.1 zur Verfügung stehenden Algorithmen für die Tablespace Encryption sind: 3DES168, AES128, AES192, AES256. Bei Spaltenverschlüsselung wird zusätzlich noch mit SALT und Hashing (SHA-1) gearbeitet.

5 Oracle Multitenant Grundsätzlich besteht eine Oracle Datenbankumgebung aus der eigentlichen Database (den Datenbankdateien) und der Instanz. Die Instanz stellt die Datenbank-Prozesse und die System Global Area (SGA) also das notwendige Memory bereit. Bis Oracle 11g musste man beim Betrieb verschiedener Applikationen in separaten Datenbanken immer die jeweiligen Instanzen mit den zugehörigen Prozessen und Memory Strukturen bereitstellen. Eine Konsolidierung war teilweise wegen gleichnamiger User oder allgemeiner Pakete nicht möglich, weil es zu Namenskonflikten gekommen wäre. Oracle Multitenant, eingeführt mit Oracle 12.1 ist eine erweiterte Datenbankarchitektur, die die Konsolidierung von Datenbanken, die bessere Ressourcenausnutzung und ein agileres Datenbank-Management ermöglicht. Mit Oracle Multitenant können verschiedenste Applikationen mit ihren zugehörigen Datenbankobjekten (Daten und Geschäftslogik) und dem applikationspezifischen Benutzermanagement als gekapselte Datenbanken (pluggable database, PDB) in einer Container Datenbank (CDB) konsolidiert werden. Die Basis der Datenbank bildet die Container-Database mit ihrem Root-Container CDB$ROOT. Dieser stellt die Datenbank-Prozess und Memery Architektur bereit. Das dort enthaltene Data Dictionary enthält nur grundsätzliche Datenbank Informationen, aber keine applikationsspezifischen Informationen. Die einzelnen Applikationen werden in den sogenannten Pluggable Databases (PDBs) installiert, die in der CDB angelegt oder per Plugin eingeklinkt werden. Jede PDB hat ein PDB eigenes Data Dictionary in dem die ganzen Applikationsspezifischen Informationen vorgehalten werden (Tabellen- und Viewdefinitionen, Applikations Datenbank-User, PL/SQL der Applikation, etc.). Mit Oracle 12.1 können bis zu 250 PDBs in einer CDB betrieben werden. Der Vorteil der Multitenant Architektur liegt zum einen im geringeren Ressourcenverbrauch und zum anderen im effizienteren Management großer Dantenbank-Umgebungen. Wartungsarbeiten werden immer auf CDB Ebene durchgeführt. Also Backup/Recovery, Einrichten von HA und DR Umgebungen werden auf CDB Ebene einmalig für alle darin enthaltenen PDBs durchgeführt. Auch das Patchen kann einmalig für alle PDBs gleichzeitig erfolgen. Ein weiterer Vorteil ist die Möglichkeit einzelne PDBs aus einer CDB in eine andere verschieben zu können oder sehr schnell Kopien von PDBs in dergleichen oder in einer entfernten CDB zu erstellen. Dabei zieht die PDB mit all ihren Datendateien um. Abb. 3: Architektur von Oracle Multitenant Die Struktur der Datendateien in einer Multitenant Umgebung ist in der folgenden Abbildung dargestellt. Für die gesamte Container-Datenbank gibt es mit Oracle 12.1 auf Root-Ebene das

6 Datenbank Controlfile und die Online Redo Logs. Zusätzlich dazu gibt es im Root-Container die Tablespaces SYSTEM und SYSAUX sowie das das Gesamtsystem umspannende UNDO Tablespace und den TEMP Tablespace. Die einzelnen PDBs haben für den applikationsspezifischen Teil des Data Dictionary auch jeweils einen SYSTEM und SYSAUX Tablespace sowie die Tablespaces für die User/Applikationsdaten. Zusätzlich kann bei Bedarf auch auf PDB Ebene ein TEMP Tablespace angelegt werden. Abb. 4: Tablespace-Struktur bei Oracle Multitenant Oracle 12.1 Erweiterungen bei TDE Mit Oracle 12.1 wurde die Syntax für das Keystore Management und das Schlüsselmanagement erweitert. Wurde in Oracle 11g mit ALTER SYSTEM oder orapki Befehlen gearbeitet, wird mit Oracle 12c einheitlich mit dem neuen Befehl gearbeitet. Als konsequente Weiterentwicklung der Separation of duty (Trennung nach Zuständigkeiten) wurden die bereits bestehenden DB Rollen SYSDBA, SYSOPER, SYSASM durch weitere aufgabenbezogene (für BR, DG, TDE) erweitert. Für das Key Managament wurde hierzu die Rolle SYSKM eingeführt, die man explizit einem separatem DB-User zuweisen kann. Alternativ kann man auch das Privileg vergeben. Mit der neuen Syntax kann zum Einen der Keystore als solches administriert werden (Anlegen, Öffnen, Schließen, Migrieren und Zusammenfassen (merge)) als auch die Master Encryption Keys verwaltet werden (Erstellen, Aktivieren, Rotieren von Keys). Erstmalig ist es auch möglich einzelne Schlüssel mit ihren Metadaten aus dem Keystore zu exportieren und in einen anderen Keystore zu importieren.

7 Neben den bereits weiter oben aufgeführten Befehlen zum Erstellen und Öffnen des Keystore und Anlegen des Master Encryption Keys sind im Folgenden noch einige Beispiele zum Keystore Management aufgelistet. Erstellen eines Auto Login Software Keystore aus dem Password-Based Software Keystore: CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/etc/oracle/wallets/orcl' IDENTIFIED BY password; Merge zweier Software Keystores in einen dritten neuen: MERGE KEYSTORE '/etc/oracle/keystore/db1' AND KEYSTORE '/etc/oracle/keystore/db2' IDENTIFIED BY existing_password_for_keystore_2 INTO NEW KEYSTORE '/etc/oracle/keystore/db3' IDENTIFIED BY new_password_for_keystore_3; In dem obigen Beispiel handelt es sich beim ersten Keystore um einen Auto Login Keystore, daher ist für den ersten Keystore keine Angabe des Passwortes erforderlich. Merge eines Keystores in einen anderen: MERGE KEYSTORE 'keystore1_location' [IDENTIFIED BY software_keystore1_password] INTO EXISTING KEYSTORE 'keystore2_location' IDENTIFIED BY software_keystore2_password WITH BACKUP [USING 'backup_identifier]; Diese Funktionalität wird im Data Guard Umfeld benötigt, wenn man den Keystore der Primary in ASM ablegt und die Kopie des Keystores bei dem Aufbau der Standby-Umgebung benötigt. Das nächste Beispiel zeigt das Ändern des Keystore Passwortes. Mit Oracle 11g musste man das Passwort des Wallets mit dem orapki Utility ändern. ALTER KEYSTORE PASSWORD IDENTIFIED BY old_password SET new_password WITH BACKUP USING 'pwd_change'; Bei allen strukturellen Veränderungen am Keystore erzwingt Oracle 12c die Erstellung eines Backups des Keystores bevor die Änderungen durchgeführt werden. Die Klausel WITH BACKUP ist daher zwingend bei Password based Software Keystores. Die für Multitenant Umgebungen wichtige Export/Import Funktion, mit der einzelne Master Keys exportiert werden können, wird im nächsten Abschnitt mit einem Beispiel erläutert. Zusammenspiel Multitenant und TDE Bei einer Multitenant Umgebung gibt es grundsätzlich zwei Ebenen, auf den sich Administratoren anmelden können: die Ebene des Root-Containers CDB$ROOT und die einzelnen PDBs.

8 Auch, wenn die Userdaten innerhalb der einzelnen PDBs liegen, erfolgt die grundsätzliche Administration des zugehörigen Keystores auf Ebene des Root Containers, d.h. der Keystore wird für die gesamte Container Datenbank mit all ihren Pluggable Databases angelegt. Jede einzelne PDB hat aber ihre eigenen Master Encryption Keys (den aktuellen und die historischen). All diese Keys sind in einem gemeinsamen Keystore gespeichert. Genau wie mit Oracle 11g dürfen sich aber verschiedene Container-Datenbanken keinen Keystore teilen. Die Trennung erfolgt also auf CDB Ebene, nicht auf PDB-Ebene. Das Anlegen und Rotieren einzelner Master-Keys kann aus dem Root Container oder aus jeder PDB gesteuert werden. Ist man mit dem Root Container verbunden, kann man entscheiden, ob die jeweilige Aktion für alle PDBs oder nur für den Root-Container gelten soll. Ist man direkt an die PDB angemeldet, werden die Aktionen nur für die aktuelle PDB durchgeführt. Die meisten Keystore Management Aktionen müssen auf Ebene des Root-Containers durchgeführt werden. Dazu zählen: Anlegen eines Password-based Software Keystores mit CREATE KEYSTORE... Anlegen eines Auto-Login Software Keystores mit CREATE [LOCAL] AUTO_LOGIN KEYSTORE FROM KEYSTORE Ändern des Software Keystore Passwortes mit ALTER KEYSTORE PASSWORD... Mergen von Software Keystores mit MERGE KEYSTORE... Backup eines Software Keystores mit BACKUP KEYSTORE... Migration eines Software Keystore in einen Hardware Keystore und zurück mit SET ENCRYPTION KEY... MIGRATE USING bzw. SET ENCRYPTION KEY... REVERSE MIGRATE Zufügen, Aktualisieren und Löschen von sogenannten Secrets mit ADD UPDATE DELETE SECRET... Selektives Exportieren/Importieren einzelner Keys anhand eines Identifier oder einer Query Viele Master Encryption Key Management und einige Keystore Aktionen können wahlweise im Root-Container oder in der jeweiligen PDB durchgeführt werden. Auf Root-Ebene gibt die CONTAINER-Clause den Umfang der Aktion an. Beispiele hierfür sind: Öffnen/Schließen des Keystores (*) mit SET KEYSTORE OPEN/CLOSE Anlegen eines Tag (Bezeichner) für den Master Encryption Key mit SET TAG Erzeugen eines Master Encryption Keys (*) mit CREATE KEY Reset oder Rotate eines Master Encryption Keys (*) mit SET ENCRYPTION KEY Aktivierung eines Master Encryption Keys mit USE KEY Export/Import einzelner Master Encryption Keys mit EXPORT/IMPORT ENCRYPTION KEYS

9 Bei den mit (*) markierten Befehlen kann die Klausel CONTAINER = ALL CURRENT verwendet werden. Der Default ist CURRENT. Bei Verwendung von ALL wird die Aktion für alle PDBs durchgeführt, im Falle des Rekeying für alle offenen PDBs. Die oben erwähnte Möglichkeit einzelne Master Encryption Keys aus einem Keystore in einen anderen überführen zu können ist essentiell für Multitenant Umgebungen, wenn PDBs von einer CDB in eine andere bewegt werden und diese PDBs TDE verwenden. Wenn innerhalb einer PDB Spalten oder ganze Tablespaces mit TDE verschlüsselt werden, so wird der zugrundeliegende Table Key bzw Tablespace Key mit dem zur PDB gehörenden Master Encryption Key verschlüsselt. Alle Master Encryption Keys aller PDBs liegen in einerm gemeinsamen zur CDB gehörenden Keystore. Soll jetzt eine PDB durch unplug/plug in eine andere CDB verschoben werden, muss in irgendeiner Form auch der Master Encryption Key der PDB in den Keystore der Ziel CDB überführt werden. Dies geschieht mit den EXPORT/IMPRT Befehlen. Der Export kann entweder auf Root-Ebene oder in der PDB durchgeführt werden. Wird das Kommando in der PDB ausgeführt, werden nur die Master Key Informationen (Key und Metadaten) der PDB exportiert. Wird der Export auf Ebene Root durchgeführt, können entweder alle Keys oder selektiv einzelne Keys exportiert werden. Das folgende Beispiel zeigt den Export aller Keys: EXPORT ENCRYPTION KEYS WITH SECRET "my_secret" TO '/etc/tde/export.exp' IDENTIFIED BY password; Auf Root Ebene können selektiv einzelne Keys anhand ihres Identifiers (aus der View V$ENCRYPTION_KEYS) oder anhand einer Query exportiert werden: EXPORT ENCRYPTION KEYS WITH SECRET "my_secret" TO '/TDE/export.exp' IDENTIFIED BY password WITH IDENTIFIER IN 'AdoxnJ0uH08cv7xkz83ovwsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA', 'AW5z3CoyKE/yv3cNT5CWCXUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'; EXPORT ENCRYPTION KEYS WITH SECRET "my_secret" TO '/etc/tde/export.exp' IDENTIFIED BY password WITH IDENTIFIER IN (SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ROWNUM <3); Der Import von Keys erfolgt dann mit: IMPORT KEYS WITH SECRET "my_secret" FROM '/etc/tde/export.exp' IDENTIFIED BY password WITH BACKUP; Auch in der Export-Datei liegen die Keys grundsätzlich verschlüsselt vor. Dazu dient die Angabe des secret. Möchte man nun eine PDB mit verschlüsselten Daten aus einer CDB in eine andere übertragen, so sind dafür folgende Schritte notwendig: 1) Exportieren des Master Encryption Key der PDB, die verschoben werden soll

10 2) Unplug der PDB in der Quell CDB 3) Anlegen der PDB in der Ziel CDB durch Plugin Dabei wird erkannt, dass die PDB verschlüsselte Daten enthält und öffnet nur im RESTRICTED MODE 4) Import des exportierten Keys in den Keystore der Ziel CDB. Falls es hier noch keinen Keystore gibt, muss dieser zuerst angelegt werden. 5) Schließen und Wiederöffnen der PDB 6) Öffnen des Keystores 7) Reset des Master Encryption Key für die PDB Auch wenn jede PDB ihre eigenen Master Encryption Keys hat, bestehen doch Abhängigkeiten zum Root-Container: Ein Master Encryption Key für eine PDB kann erst angelegt werden, wenn für Root bereits ein Master Encryption Key existiert. Der Zugriff auf verschlüsselte Daten in der PDB kann nur erfolgen, wenn der Keystore explizit für diese PDB geöffnet wurde. Vorher muss aber der Keystore für den Root Container geöffnet worden sein. V$ENCRYPTION_WALLET zeigt den Status der Keystores für die einzelnen Container an und V$ENCRYPTION_KEYS zeit alle wichtigen Informationen für die Keys an. Ausblick TDE mit Oracle 12.2 Zum Zeitpunkt der Erstellung dieses Papiers (November 2016) steht Oracle 12c Release 2 als Exadata Express Service (Pluggable Database in einer Oracle 12.2 Umgebung auf Exadata) und im Rahmen des Database Cloud Services (ein Angebot aus dem Bereich PaaS) in der Oracle Cloud zur Verfügung. Es steht noch keine freigegebene Software für On Premise Installationen bereit, jedoch ist die Dokumentation schon veröffentlicht. Als neue Features für TDE mit Oracle 12.2 sind vorgesehen: Einführung zusätzlicher Verschlüsselungsalgorithmen ARIA, GOST und SEED: ARIA mit den gleichen Blockgrößen wie AES. ARIA ist für Lightweight Environments und Hardware Implementationen gedacht und erfüllt Standards, die in Korea verwendet werden. GOST ist zwar ähnlich zu DES, verwendet aber eine große Anzahl von Berechnungsrunden und geheime S-Boxen. GOST erfüllt Standards in Russland. SEED wird in etlichen Standard Protokollen verwendet: S/MIME, TLS/SSL, IPSec, and ISO/ IEC. SEED erfüllt Standards in Korea. Online und Offline Tablespace Encryption bestehender Tablespaces Bis Oracle 12.1 können nur neue Tablespaces verschlüsselt angelegt werden, eine nachträgliche Verschlüsselung ist nicht möglich. Mit Oracle 12.2 können nun auch gefüllte Tablespaces nachträglich verschlüsselt werden. Dabei stehen zwei Arten zur Verfügung: Offline Encryption und Online Encryption. Bei der Offline Encryption werden die Tablespaces zunächst OFFLINE gesetzt oder die Datenbank geschlossen und dann anschließend Inline verschlüsselt. Bei der Online Verschlüsselung bleibt das Tablespace online und wird im laufenden Betrieb verschlüsselt. Dazu wird eine Kopie der Datendateien angelegt. Beginnend mit Oracle 12.2 können nun auch die systemeigenen Tablespaces SYSTEM, SYSAUX und UNDO verschlüsselt werden. Das folgende Besipiel zeigt die Offline Verschlüsselung: ALTER TABLESPACE users OFFLINE NORMAL;

11 ALTER TABLESPACE users ENCRYPTION OFFLINE ENCRYPT; Da das Verschlüsseln inline erfolgt, ist es wichtig vorher ein Backup der Datendatei zu erstellen. Der verwendete Algorithmus ist der AES128, er kann nicht geändert werden. Mit einem DECRYPT Kommando kann ein Tablespace auch wieder entschlüsselt werden: ALTER TABLESPACE users ENCRYPTION OFFLINE DECRYPT; Das folgende Beispiel zeigt eine Online Verschlüsselung: ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES192' ENCRYPT FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf'); Anders als bei der Offline Verschlüsselung kann hier der Algorithmus ewählt werden. Die Verwendung der FILE_NAME_CONVERT Klausel ist obsolet bei Verwendung von Oracle Managed Files. Ansonsten gibt dieser Parameter die Namenskonvention an, nacher der die Tablespace Kopien angelegt werden sollen. Die Syntax ist (Original, Kopie, Original, Kopie,...). Dabei sind wie bei Data Guard auch Muster zulässig. Rekeying des Tablespace Keys Bis Oracle 12.1 konnte zwar ein Rekey des Master Encryption Keys gemacht werden, nicht jedoch ein Rekeying des ganzen Tablespaces. Dies wird jetzt mit Oracle 12.2 unterstützt. Das folgende Beispiel zeigt ein Rekey des Tablespace Keys: ALTER TABLESPACE users ENCRYPTION USING 'AES192' REKEY FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf'); Automatische Tablespace Verschlüsselung Alle Datenbanken des Oracle Database Could Service (DBCS) in der Oracle Cloud verwenden per Default verschlüsselte Tablespaces. Mit Oracle 12.2 wird ein neuer Initialisierungs- Parameter eingeführt, der dieses Verhalten steuert: ENCRYPT_NEW_TABLESPACE Der Parameter hat drei mögliche Werte: CLOUD_ONLY: Alle Tablespaces werden transparent verschlüsselt, wenn die Datenbank in der Oracle Cloud betrieben wird. Der verwendete Algorithmus ist AES128. ALWAYS: Alle neuen Tablespaces werden automatisch verschlüsselt angelegt. Wird kein Algorithmus angegegen, wird AES128 verwendet. DDL: Hier wird nur dann ein verschlüsselter Tablespace angelegt, wenn dies explizit beim CREATE TABLESPACE Befehl angegeben wird. Zusammenfassung Zusammenfassend lässt sich sagen, dass auch in Oracle Multitenant Umgebungen Daten bei der Ablage im Storage problemlos mit Transparent Data Encryption verschlüsselt werden können. Das mit Oracle 12c erweiterte Schlüssel- und Keystore Management bietet optimale Unterstützug auch in Situationen, wo ganze Applikations-Umgebungen in Form von Pluggable Database Unplu/Plug- Operationen zwischen verschiedenen Container-Datenbanken bewegt werden müssen. Das erweiterte Schlüsselmanagement ermöglicht die Mitnahme aller zur Pluggable Database gehörenden Schlüssel, sodass auch in der neuen Container-Datenbank auf die Daten der eingeklinkten Pluggable Database zugegriffen werden kann. Die View V$ENCRPTION_KEYS zeigt alle wichtigen Informationen über die Herkunft und die Historie der verschiedenen Master Encryption Keys für die einzelnen Pluggable Databases. So sind zum Beispiel auch die für Auditoren wichtigen Informationen über das letzte Rekey der Master Keys enthalten.

12 Kontaktadresse: Claudia Hüffer Oracle Deutschland B.V. & Co. KG Kühnehöfe 5 D Hamburg Telefon: +49 (0) Fax: +49 (0) claudia.hueffer@oracle.com Internet: Abkürzungsverzeichnis ASO Advanced Security Option ASM Automatic Storage Management CDB Container Database CTAS Create Table as Select PDB Pluggable Database SGA System Global Area TDE Transparent Data Encrytion TTS Transportable Tablespace