6 Minuten Lesezeit (1232 Worte)

Oracle Network Encryption - Sichere Übertragung von Daten zwischen Client und Server

Dienstag, 11. Juli 2017

Datenbanken enthalten oft sensible und schützenswerte Daten. Anwendungen greifen in der Regel über das Netzwerk auf diese Informationen zu. Eine Standard-Datenbank-Installation überträgt solche Informationen unverschlüsselt zwischen Client und Server. Dieser Umstand bietet potenziellen Angreifern die Möglichkeit, den Datenverkehr zu belauschen. Deshalb ist die Absicherung des Netzwerkverkehrs genauso wichtig, wie die der Datenbank selbst. Oracle bietet hier zum einen die Netzwerkverschlüsselung über SQL*Net oder über SSL/TSL. Selbstverständlich kann die Netzwerkübertragung auch mit einem Fremdprodukt auf der Netzwerkebene verschlüsselt werden. In diesem Artikel werden wir eine Lizenzübersicht geben und die Möglichkeiten mit Oracle-Mitteln kurz darstellen.

Lizenzsituation

Oracle bietet die Netzwerkverschlüsselung über SQL*Net oder über SSL/TLS an. Beides war Teil der „Advanced Security Option" und steht mit Erscheinen von Oracle 12cR1 im Juni 2013 in den kostenpflichtigen Datenbank-Editionen (Standard/Enterprise), aller aktuell unterstützten Releases als Datenbank-Feature, zur Verfügung.

Überblick

Mit beiden Verschlüsselungsmethoden ist es möglich den Netzwerkverkehr zu verschlüsseln. Sie unterscheiden sich hinsichtlich der Art ihrer Implementierung und den notwendigen Voraussetzungen. Oracle hat den Secure-Hash-Algorithmus SHA2 zur Sicherstellung der Datenintegrität mit Oracle 12c eingeführt. Einen Überblick über die wichtigsten Algorithmen sehen Sie in Abbildung 1.

Abb. 1: Lizenzübersicht (Secure-Hash-Algorithmus SHA2 mit Version 12c eingeführt)

Vorüberlegungen

Bei der Aktivierung der Oracle-Netzwerkverschlüsselung muss vorab noch zwischen der Übertragung von Daten nach dem Aufbau einer neuen User Session und der Datenübertragung einer eventuell noch bestehenden User Session unterschieden werden. Im ersten Fall werden die Daten verschlüsselt übertragen. Hier besteht kein Handlungsbedarf.

Anders ist es bei der Übertragung der Daten einer bestehenden User Session. Diese Daten werden nicht automatisch verschlüsselt und die Verbindung bleibt unverschlüsselt und damit für einen potenziellen Angreifer im Klartext lesbar. Alle verbundenen User Sessions müssen bei der Aktivierung der Netzwerkverschlüsselung getrennt und neu verbunden werden. Nur so wird eine Absicherung gegen das Mitlesen des Netzwerkverkehrs erreicht.

Abb. 2: Verschlüsselungsmatrix (SQL*Net)

Ziel

Ziel der Netzwerkverschlüsselung ist es, basierend auf einem Schlüssel, den Klartext in unlesbaren Text umzuwandeln und es damit einem Angreifer zu erschweren, den Datenverkehr mitzulesen. Um dies zu erreichen kann eine der beiden Verschlüsselungsmethoden über SQL*Net oder über SSL/TLS zum Einsatz kommen. Netzwerkverschlüsselung und zusätzliche Integritätsprüfung bieten:

Schutz der Daten als auch der Datenintegrität bei der Übertragung zwischen Client und Server
Schutz vor packet sniffing
Schutz vor man-in-the-middle-Angriffen

Allerdings entsteht auch Aufwand bei Einrichtung, Konfiguration und Test der Verschlüsselung. Bei SSL/TLS-Verschlüsselung müssen zusätzlich Zertifikate erstellt werden und eine Public Key Infrastructure (PKI) zur Verfügung stehen. Eventuell müssen auch Programme und Verbindungsparameter angepasst werden.

Verschlüsselung über SQL*Net

Diese Verschlüsselungsmethode wird auch als native-Oracle-Verschlüsselung bezeichnet. Sie benötigt keine Public Key Infrastructure (PKI) und verwendet zur Erzeugung sicherer Schlüssel den Diffie-Hellman-Algorithmus. Auf beiden Seiten wird ein temporärer Schlüssel erzeugt. Dieser wird benutzt, um daraus einen symmetrischen Session-Schlüssel zu erzeugen (Einwegfunktion), mit dem die eigentliche Kommunikation verschlüsselt wird. Hierbei macht man sich die Tatsache zunutze, dass es zwar sehr einfach ist, eine Zahl zu potenzieren, dass es jedoch nur mit sehr großem Aufwand möglich ist, den diskreten Logarithmus einer Zahl zu berechnen.

Datenintegrität

Durch Verschlüsselung kann die Integrität der Daten nicht gewährleistet werden, daher ist es ratsam, diese durch Checksummen sicherzustellen. Sämtliche Modifikationen am Datenverkehr können somit aufgedeckt werden und führen zur Beendigung der Session.
Dabei kann zwischen drei Verfahren gewählt werden: SHA2 (ab Oracle 12c), SHA1 und MD5. Da mittlerweile Schwächen in MD5 aufgedeckt wurden, sollte dieser Algorithmus nicht mehr verwendet werden. SHA2 ist hierbei der modernste Algorithmus und die bessere Alternative, sofern Client und Server diesen Algorithmus unterstützen. Dazu müssen beide Seiten Oracle 12c verwenden.

Aktivierung

Für die Aktivierung sind in der sqlnet.ora des Servers und ggf. des Clients zusätzliche Parameter zu setzen.

Die Parameter SQLNET.ENCRYPTION_SERVER und SQLNET.CRYPTO_CHECKSUM_SERVER können dabei jeweils vier verschiedene Werte annehmen. Je nachdem, ob der Server eine Verschlüsselung/Integritätsprüfung verlangt (REQUIRED), anfragt (REQUESTED), akzeptiert (ACCEPTED) oder zurückweist (REJECTED). Da die Encryption-Parameter SQLNET.ENCRYPTION_CLIENT und SQLNET.CRYPTO_CHECKSUM_CLIENT ebenfalls auf dem Client gesetzt werden können, ergeben sich 4*4=16 Möglichkeiten. Es ist empfehlenswert, Verschlüsselung und Integritätsprüfung auf dem Server jeweils auf REQUIRED zu setzen, um so eine verschlüsselte Verbindung zu erzwingen, ohne die eine Session nicht ausgehandelt werden kann. Die Matrix beschreibt dies für jeden der 16 möglichen Fälle (siehe Abbildung 2).

Die Art der Verschlüsselung kann mittels der Parameter SQLNET.ENCRYPTION_TYPES_SERVER und SQLNET.ENCRYPTION_TYPES_CLIENT eingestellt werden. Hier gilt: Je höher die Bitrate, desto sicherer ist die Verschlüsselung. Allerdings steigt natürlich mit einer höheren Bitrate auch der Aufwand für die CPU. AES256 und 3DES168 haben sich in der Praxis bewährt und sind zu empfehlen. Wobei letzterer Algorithmus 3DES168 weniger performantals AES256 ist und auch deutlich CPU-intensiver. Stromverschlüsselung RC4 ist ein sehr performanter Algorithmus, und es wird davon abgeraten. Im Zweifelsfall gilt, besser schlecht verschlüsselt als überhaupt nicht verschlüsselt.

Den Parameter SQLNET.CRYPTO_SEED sollten Kunden, die native-Oracle-Verschlüsselung einsetzen, auf jeden Fall verwenden und einen zufälligen Wert mit maximaler Länge konfigurieren, um eine höhere Absicherung zu erreichen.

Verschlüsselung über SLT/TSL

Um bei der Nutzung von asymmetrischen Kryptosystemen den Einsatz falscher (z.B. untergeschobener) Schlüssel zu verhindern, wird eine Garantie benötigt, dass der verwendete, öffentliche Schlüssel auch zum designierten Empfänger der verschlüsselten Nachricht bzw. zum Sender einer elektronisch signierten Nachricht gehört. Diese Garantie stellt eine vertrauenswürdige Stelle in Form eines digitalen Zertifikates aus. Oracle unterstützt die sogenannte Public Key Infrastructure (PKI) und bietet die Möglichkeit, die erstellten Zertifikate bequem im Oracle-Internet-Directory oder typischerweise im Dateisystem (Wallet) abzulegen.

Für den Einsatz von SSL-Verbindungen über Oracle Net sind die folgenden Konfigurationsschritte durchzuführen:

Anlegen eines Wallets
Erstellung eines Zertifikats-Requests
Export eines Zertifikats-Requests in eine Datei
Zertifizierungsanforderung unterschreiben/beglaubigen lassen
Zertifikatskette und Zertifikat importieren
Konfiguration eines zusätzlichen SSL Listeners

Auf jedem Client muss ebenfalls mindestens ein Wallet/Zertifikats-Store angelegt und dort die Zertifikatskette importiert werden. Gegebenenfalls sollten auch Client-Zertifikate verwendet werden – in diesem Fall müssen für jeden Client ebenfalls Zertifikats-Requests erstellt und das Zertifikat importiert werden.

Die Absicherung von Oracle-Verbindungen mittels SSL ermöglicht das Erreichen einer hohen Sicherheitsstufe. Nachteilig anzusehen ist der hohe administrative Aufwand und die dafür benötigten Kenntnisse im Bereich der Public Key Infrastructure.

Fazit

Oracle bietet mit Netzwerkverschlüsselung über SQL*Net oder SSL/TLS zwei Varianten der Netzwerkverschlüssel-ung in allen aktuell unterstützten Releases an. Netzwerkverschlüsselung nimmt in immer mehr Sicherheitskon-zepten eine zentrale Rolle ein. Auch in Ihrem? Bei der Analyse Ihres Systems und der Implementierung von Sicherheitsrichtlinien unterstützen wir Sie gerne. Wir empfehlen jedem Kunden, der sich mit dieser Thematik auseinandersetzen möchte, einen PoC aufzusetzen, in dem der erwartete Overhead gemessen und verifiziert wird.

Glossar

Die Oracle Enterprise Edition bietet sowohl in Cluster- als auch in Einzelsystemen branchenweit führende Skalierbarkeit und Zuverlässigkeit. Sie verfügt über umfassendste Funktionen für OLTP und Business Intelligence und bietet gleichzeitig die niedrigste TCO.

PKI

Mit Public Key Infrastructure (PKI) bezeichnet man in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Absicherung rechnergestützter Kommunikation verwendet.

PoC

Im Projektmanagement ist ein Proof of Concept (PoC) ein Meilenstein, an dem die prinzipielle Durchführbarkeit eines Vorhabens belegt ist.

SE2

Oracle Standard Edition - Aus der Perspektive der Software handelt es sich bei der Oracle Standard Edition 2 (SE2) um die gleichen Binaries wie bei den Vorgänger-Editionen, jedoch ist sie aus lizenzrechtlicher Sicht ein eigenständiges, neues Produkt mit neuen Limitationen und bewährten Funktionalitäten.

SSL/TLS

Transport Layer Security (TLS), weitläufiger bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung.