Verschlüsselung ist leicht, Schlüsselmanagement nicht

Transkript

1 Verschlüsselung ist leicht, Schlüsselmanagement nicht Schlüsselworte Hamid Habet (Allianz Technology SE) und Norman Sibbing (Oracle) Datenbank Sicherheit, Verschlüsselung, Schlüsselmanagement. Einleitung Nicht die Verschlüsselung, zum Beispiel mit der Oracle Transparent Data Encryption (TDE) an sich macht den Aufwand, sondern das Schlüsselmanagement. Wie wichtig und komplex Schlüsselmanagement sein kann, erfahren momentan viele unserer Kunden. Unabhängig davon, ob sich die verschlüsselte Datenbank in der Oracle Public Cloud oder On-Premise befindet, muss die Verfügbarkeit und die Sicherheit der Schlüssel zwingend gewährleistet sein. Tägliche administrative Aktivitäten wie das Backup und Recovery, das Klonen, das Verschieben und Upgraden von Datenbanken müssen trotz Verschlüsselung ohne weitere Anstrengungen möglich sein. Ebenso müssen Hochverfügbarkeits-Technologien wie RAC, Data Guard und Golden Gate unterstützt werden. Hier entscheidet das richtige Schlüsselmanagement den Erfolg oder Misserfolg dieser Sicherheitsmaßnahme. Im Weitern werden alle Aspekte des professionellen Schlüsselmanagements dargestellt zudem berichtet Hamid Habet (Allianz Technology SE), welche Herausforderungen das Schlüsselmanagement im echten Leben mit sich bringt. Verschlüsselung Die Verschlüsselung wurde bereits in der Antike eingesetzt. Julius Cäsar verwendete damals eine sogenannte Verschiebechiffre auch Cäsar-Chiffre genannt, um Botschaften zu transportieren. Der Überbringer der Botschaft sollte die darin enthaltenen Informationen weder verstehen noch deuten können. Bei der Cäsar-Chiffre war das Geheimnis (der Schlüssel), um wieviel Stellen die Buchstaben des Klartextes im Alphabet verschoben wurden, um den verschlüsselten Text zu erstellen. Nur dem Ersteller und dem Empfänger der Botschaft war dieses Geheimnis bekannt. Hier wurde also eine symmetrische Verschlüsselung verwendet. Aus heutiger Sicht zwar ein Rätzel auf Grundschul-Niveau, damals aber wohl sicher genug. Die Idee der Verschlüsselung ist bis heute das Fundament der IT- Sicherheit. Heutzutage natürlich mit modernsten Verschlüsselungs-Algorithmen, wie der Advanced Encryption Standard (AES) oder RAS-Algorithmus (Rivest Shamir Adleman). Die meisten Verschlüsselungs-Algorithmen sind nicht geheim, sondern für alle Interessierten öffentlich zugänglich. Entscheidend ist hier der Schlüssel. Wer den Schlüssel kennt und weiß, welches Verfahren zur Verschlüsselung angewandt wurde, hat Zugriff auf die verschlüsselten Informationen. Schlüssel und Keystores Die Sicherheit der verschlüsselten Information basiert im Wesentlichen auf die Stärke, Geheimhaltung und Verfügbarkeit des Schlüssels. Wobei die Stärke des Schlüssels durch seine Länge (128bit, 196bit, 256bit,...) und Erzeugung bestimmt wird. Bei den Verschlüsselungsverfahren unterscheiden wir zwischen asymmetrischen und symmetrischen Verschlüsselungsverfahren. Beim asymmetrischen Verschlüsselungsverfahren wird immer ein Schlüsselpaar benötigt, ein privater (geheimer) und ein öffentlicher Schlüssel. Hierbei wird der öffentliche Schlüssel zur Verschlüsselung der Nachricht und der private Schlüssel zur Entschlüsselung der Nachricht verwendet. Beim symmetrischen Verschlüsselungsverfahren existiert nur ein Schlüssel, sowohl zum Verschlüsseln als auch zum Entschlüsseln der Nachricht. Die geheimen Schlüssel müssen unbedingt vor unberechtigten Zugriffen geschützt werden und immer verfügbar sein. Sogenannte Keystores erleichtern hierbei die Verwaltung und den Schutz von geheimen Schlüsseln. Der bekannteste Keystore ist wohl der Java Keystore (JKS).

2 Der von der Oracle Datenbank-Verschlüsselung verwendete Keystore zur Speicherung des TDE Master Keys - das sogenannte Oracle Wallet - ist eine mit AES256-bit und Kennwort verschlüsselte PKCS#12 Datei (ewallet.p12). Wichtig ist hier ist zu beachten, dass jede Datenbank ihren eigenen Keystore besitzt. Alle Instanzen einer Real Application Cluster Datenbank müssen Zugriff auf denselben Keystore haben. Das gleiche gilt beim Einsatz des Oracle Data Guards, bei Wiederherstellung von Datenbanken und beim Klonen von Datenbanken, wenn TDE verwendet wird. Zudem beinhaltet der Keystore alle historischen Schlüssel der entsprechenden Datenbank. Wird bei einem Re-Keying ein neuer Schlüssel erstellt, muss der alte Schlüssel historisiert werden. Nur so ist das Wiederherstellen von Datenbanken aus älteren Datenbank-Backups, die gegebenenfalls einen älteren TDE-Master-Key verwenden, möglich. Das Oracle Wallet bleibt also ständiger Begleiter einer mit TDE verschlüsselten Oracle Datenbank, ein Datenbank-Leben lang. Der Speicherort des Oracle Wallets lässt sich durch Angabe des ENCRYPTION_WALLET_LOCATION Parameters in der SQLNET.ORA bestimmen. Die Verantwortung zum sorgfältigen Umgang mit dem Oracle Wallet ist enorm. Ist das Oracle Wallet weg, sprich der TDE Master-Key, sind die Daten verloren. Im Übrigen eine gute Art und Weise Daten zu vernichten. Bei einer überschaubaren Anzahl von verschlüsselten Oracle Datenbanken, in einer überwiegend statischen Datenbanklandschaft, ist gegen das Verwenden des Oracle Wallets als Keystore nichts einzuwenden. Das ändert sich schnell bei einer steigenden Anzahl von verschlüsselten Datenbanken in einer dynamischen Datenbanklandschaft, wie es zum Beispiel in einer Cloud-Architektur üblich ist. Gerade bei der Nutzung von Datenbank as a Service ist es umso wichtiger, alle Datenbanken zu verschlüsseln und dabei die Schlüssel im eigenen Haus zu behalten. Nur so behält man als Besitzer der Daten weiterhin die Kontrolle. Entscheidend ist hier Art und Weise wie die Schlüssel sicher gespeichert, verwaltet und zur Verfügung gestellt werden. Neben den Schlüsseln für die Oracle Datenbank-Verschlüsselung existiert eine Vielfalt weiterer Arten von Schlüsseln. RSA Keys, Oracle Wallets, MySQL Keys oder Kerberos Keytab-Files unterliegen den gleichen Anforderungen an Sicherheit, Verwaltung und Verfügbarkeit. Ohne ein zentrales Key Management System (KMS) können diese Anforderungen nicht erfüllt werden. Verwaltung der Schlüssel mit Oracle Key Vault Oracle Key Vault (OKV) bietet genau das. Eine moderne Umgebung zur sicheren und zuverlässigen Speicherung, Verwaltung und Bereitstellung von Schlüsseln. Ist also die perfekte Lösung zur Zentralisierung des Schlüsselmanagements. Oracle Key Vault wird als Software Appliance ausgeliefert. Der Kunde stellt einen X86-64bit-Rechner zur ausschließlichen Nutzung für OKV zur Verfügung. Auf dem Rechner wird die OKV-Software mittels ISO-Images installiert. Der gesamte installierte Software-Stack besteht aus einem gehärteten Oracle Enterprise Linux (OEL) als Betriebssystem, einer Oracle-Datenbank und einer grafischen Benutzeroberfläche, der Oracle Key Vault Management Console.

3 Abbildung 1: Oracle Key Vault High-Level Architektur Sicherheit von Oracle Key Vault Oracle Key Vault ist gemäß des Security Technical Implementation Guides (STIG) eingerichtet. Der Security Technical Implementation Guide (STIG) ist eine vom U.S. Department of Defense (DOD) erarbeitete Methodik, um Angriffsflächen von Computersystemen und Netzwerken auf ein Minimum zu reduzieren. Demzufolge, ist das von der OKV Appliance verwendete Oracle Linux Betriebssystem und die zur Speicherung und Verwaltung der Schlüssel verwendetet Oracle Datenbank bereits entsprechend gehärtet. Ein Remote-Zugriff auf die Datenbank ist nicht möglich. Eine lokale Linux- Firewall unterbindet jeglichen ungewollten Zugriff von außen. Im Standard sind nur der HTTPS-Port 443 für die Oracle Key Vault Management Console und der KMIP-Port 5659 (Key Management Interoperability Protocol) zum Schlüsselaustausch geöffnet. Für Wartungsarbeiten, zum Beispiel für das Patchen der OKV Appliance, kann der SSH-Port 22 kontrolliert über die Oracle Key Vault Management Console geöffnet werden. Die Schlüssel selber werden in einem mit AES256 bit verschlüsselten Tablespace gespeichert. Der hierfür benötigte TDE Master-Key der OKV Datenbank befinden sich selber in einem Oracle Wallet auf der Appliance. Es besteht allerdings die Möglichkeit, den OKV TDE Master-Key auf ein Hardware Security Modul (HSM) auszulagern, auch -Chain of Trust- genannt (Abbildung 2).

4 Abbildung 2: Chain of Trust Aktuell werden Hardware Security Module der Hersteller SafeNet (Luna) und Thales (nshield) unterstützt. Verwaltung der Schlüssel Zur System-Administration, Überwachung und zum Schlüsselmanagement werden bereits bei der Installation unterschiedliche Benutzer angelegt. Unter anderem: Ein Key-Administrator, der zum Beispiel den Zugriff auf die Schlüssel kontrolliert. Ein System-Administrator, der für die Verwaltung des OKV Systems zuständig ist, zum Beispiel für das Starten und Stoppen, für Backup und Recovery, Einrichten der Hochverfügbarkeit sowie Erstellung von Endpoints und Benutzern. Ein Audit-Manager, der den Audit-Trail des OKV verwaltet. Zur besseren Organisation der Schlüssel, werden sogenannte virtuelle Wallets - Virtual Wallet - verwendet. Dabei entspricht ein Virtual Wallet einem logischen Container, dem die unterschiedlichsten Schlüssel-Typen zugeordnet werden. Dabei können Schlüssel auch mehreren Virtual Wallets zugordnet werden. Abbildung 3 zeigt ein Virtual Wallet namens SSL_Listener und beinhaltet unter anderem Private/Public Keys sowie X.509 Zertifikate.

5 Abbildung 3: Virtual Wallet mit X.509 Zertifikat Die Zugriffsberechtigung auf einen Schlüssel findet indirekt auf Ebene des Virtual Wallets statt. Ein Endpoint (wird unten erläutert) erhält Zugriffsberechtigungen auf das Virtual Wallet, siehe Abbildung 3 Bereich Wallet Access Settings. Es findet keine Zugriffsberechtigung direkt auf Schlüssel-Ebene statt. Die Verwaltung und Organisation der Schlüssel kann entweder manuell über die Oracle Key Vault Management Console oder automatisiert über einen RESTful Service durchgeführt werden. Bereitstellung der Schlüssel Ziel-Systeme, die Oracle Key Vault (OKV) nutzen, werden Endpoints genannt. Damit ein System mit Oracle Key Vault kommunizieren kann, muss für ihn ein Endpoint erstellt werden. Der Endpoint stellt die notwendige Schnittstellen-Software zur Verfügung und muss auf dem System installiert werden. Die Software beinhaltet neben einer PKCS#11 Bibliothek, welche für die Kommunikation zwischen der Oracle Datenbank und dem Oracle Key Vault Server benötigt wird, ein Zeilenkommando- Werkzeug namens OKVUTIL zur Verfügung. OKVUTIL wird zum Beispiel für das Hoch beziehungsweise Runterladen von Oracle Wallets und anderen Keystores verwendet. Endpoints werden in Zusammenarbeit zwischen einem OKV-System-Administrator und einem Endpoint- Administrator, zum Beispiel dem Datenbank-Administrator, eingerichtet (siehe Abbildung 4). Zur Erstellung des Endpoints vergibt der OKV-System-Administrator einen Namen für den neuen Endpoint, legt Typ und Betriebssystem des Endpoints fest und erzeugt schließlich ein sogenanntes Token. Über das Token kann der Endpoint-Administrator den personalisierten Endpoint, über die OKV Download-Seite, runterladen. Ein Token ist nur einmal einsetzbar. Danach wird der Endpoint auf das Zielsystem übertragen und installiert. Ist das alles erfolgreich gewesen, kann das System auf

6 Schlüssel zugreifen, die für den jeweiligen Endpoint freigegeben wurden. Die Freigabe der Schlüssel erfolgt über das Virtual Wallet und wird durch den Key-Administrator durchgeführt. Abbildung 4: Installation des Endpoints Auch die Erstellung und Bereitstellung der Endpoints kann mit dem RESTful Service automatisiert werden. Verfügbarkeit des OKV Systems Wesentlich für ein zentrales Key Management System ist, dass es nahezu ununterbrochen zur Verfügung stehen muss. Sollte es ausfallen - geplant oder ungeplant, müssen die Schlüssel weiterhin dem Endpoint zur Verfügung stehen. Die Verfügbarkeit des OKV Systems wird durch den Einsatz von Oracle Data Guard gewährleistet. Dabei wird ein zweites OKV System installiert und dem primären OKV System als OKV Standby System bekannt gegeben. Steht das primäre OKV System nicht mehr zur Verfügung, nutzen die Endpoints automatisch das OKV Standby System. Während eines ungeplanten Failovers oder beim geplanten Switchover kommt es kurzeitig (ca. 10 min) zu einer Unterbrechung der Kommunikation zwischen den Endpoints und dem OKV System. Dies ist bei Schlüsseln, welche in Dateiform zur Verfügung gestellt werden, zum Beispiel Java Keystores und SSH-Keys, unproblematisch. Anders sieht das aus, wenn es sich um eine mit TDE verschlüsselte Oracle Datenbank handelt. Die Datenbank nutzt einen direkten Zugriff auf das Key Management System via PKCS#11 Bibliothek TDE Online Master-Key - und fordert den Schlüssel für verschiedene Datenbank-Operationen regelmäßig an. Unter anderem beim Redo-Logfile Switch, beim ersten Zugriff auf ein verschlüsseltes Datenfile und beim Checkpoint. Bei parallelen Zugriffen auf große Tabellen benötigen alle Child-Prozesse ebenfalls den aktuellen Master-Key. Zudem überprüft die Datenbank durch einen Heartbeat alle 3 Sekunden, ob der Keystore noch im Zugriff ist. In einer stark frequentierten Datenbank kommen so schnell tausende von Schlüsselanforderungen pro Sekunde zu Stande. Das Ganze natürlich pro Datenbank. Schnell wird klar, dass ein Ausfall des Key Management Systems oder ein Ausfall des dazwischenliegenden Netzwerkes katastrophale Folgen hat. Selbst die 10 Minuten beim Failover/Switchover des OKV Systems sind zu lang. Abhilfe schafft hier eine Funktionalität namens Persistent Master Key Cache. Bei Aktivierung des Persistent Master Key Caches wird der TDE Master-Key der Datenbank auf dem Endpoint in einem separaten PKCS#12 Container zwischengespeichert. Dies geschieht völlig transparent für die Datenbank. Ist der aktuelle

7 TDE Master-Key bereits im Cache vorhanden, verwendet die Datenbank diesen und es findet kein Zugriff auf des OKV-System statt. Ist der aktuelle TDE Master-Key nicht im Cache enthalten, wird er vom OKV-System angefordert und für alle weiteren Datenbank-Operationen zwischengespeichert. Die Lebensdauer des zwischengespeicherten TDE Master-Keys lässt sich konfigurieren. Der Wert wird in Minuten angegeben und ist im Standard auf 1440 Minuten = 24 Stunden eingestellt. Im schlimmsten Fall, darf das komplette OKV-System hier also für maximal 24 Stunden ausfallen, bevor die Datenbank nicht mehr auf verschlüsselte Daten zugreifen kann. Überwachung des OKV Systems Eine technische Überwachung des Oracle Key Vault Servers kann mittels Einbindung in ein vorhandenes System Management über SNMP v3 durchgeführt werden. Dabei werden Ressourcen wie Netzwerk, CPU-Auslastung, Speichernutzung und Prozesse überwacht. Es besteht neben der Verwendung von SNMP auch die Möglichkeit, Oracle Key Vault mit Oracle Cloud Control zu überwachen. Hierzu muss der Cloud Control Agent auf dem Oracle Key Vault Server installiert werden. Eine fachliche Überwachung wird von Oracle Key Vault bereits im Standard durchgeführt. Es werden alle administrativen Tätigkeiten auf dem Key Vault Server überwacht. Unabhängig davon, ob Aktivitäten über die Konsole oder über den RESTful Service durchgeführt werden. Zudem werden alle Aktivitäten der Endpoints protokolliert. Diese Auditdaten werden im Oracle Key Vault in einem Audit-Trail gespeichert. Zur Auswertung stehen diverse Berichte zur Verfügung. Bei Bedarf können die Auditdaten an ein zentrales Security Information and Event Management (SIEM) mittels einer SYSLOG-Integration weitergeleitet werden. Ebenfalls ist eine Integration mit Audit Vault vorhanden. Abbildung 5: Oracle Key Vault Umgebung

8 Use Cases Die meisten Use Cases und damit den größten Mehrwert bietet Oracle Key Vault als zentrales Key Management System für die Oracle Datenbank. Die direkte Integration über PKCS#11 / KMIP ermöglicht dem Datenbank-Administrator ein vollkommen transparentes Arbeiten mit einer verschlüsselten Oracle Datenbank. Das Backup, die Bereitstellung und die Sicherung des TDE Master- Keys sind hiermit nicht mehr Aufgabe des Datenbank-Administrators. Oracle Key Vault erleichtert den Umgang mit verschlüsselten Oracle Datenbank in vielen Bereichen: Klonen Import und Export Backup und Recovery Verteilte Datenbanken (Golden Gate) Real Application Cluster Umgebungen Standby Umgebungen (Data Guard) Umsetzung von Sicherheitsrichtlinien (Compliance) Datenbanken in der Cloud Abbildung 6: Use Cases Oracle Datenbank Oracle Key Vault ermöglicht zudem die in Haus (on Premise) Verwaltung und Speicherung der Schlüssel bei Verwendung von Cloud Services, wie zum Beispiel bei Database as a Service. Hierzu existiert ein spezieller Oracle Key Vault Endpoint, der ein sichere Verbindung vom Cloud Service aus zum Oracle Key Vault (on Premise) aufbaut. So kann der Datenbesitzer jederzeit den Zugriff auf seine in der Cloud betriebenen Daten unterbrechen.

9 Abbildung 7: Oracle Key Vault Hybrid Zusätzlich bietet Oracle Key Vault Unterstützung bei der Verwaltung und Verteilung diverser Schlüssel, wie zum Beispiel: Zertifikate: Java Key Stores Oracle Wallets (zum Beispiel für den Secure Enterprise Password Store) MySQL Encryption Key SSH Key-Files

10 Abbildung 8: Weitere Oracle Key Vault Use Cases Fazit Oracle Key Vault ist vielseitig und als Software Appliance schnell und sicher zum Einsatz zu bringen. Die Entlastung des Datenbank-Administrators ist enorm, da er sich um die Schlüsselspeicherung und Verfügbarkeit keine Gedanken machen muss. Sicherheitsrichtlinien für das Speichern von Schlüsseln können eingehalten werden. Durch den vorhandenen RESTful Service ist eine automatisierte Schlüsselverwaltung möglich. Oracle Key Vault ist bereits für den Betrieb als Hochverfügbarkeitssystem vorbereitet. Doch wie sieht das Ganze unter realen Bedingungen aus. Hält Oracle Key Vault das, was es verspricht. Hamid Habet von der Allianz Technology SE hat Oracle Key Vault lange getestet und berichtet von seinen Eindrücken. Kontaktadresse: Norman Sibbing ORACLE Deutschland B.V. & Co. KG Hamborner Str. 51 D Düsseldorf Telefon: +49 (0) Fax: +49 (0) Internet: