SSL-Test und Orapki is your friend

Transkript

1 SSL-Test und Orapki is your friend Autor: Perter Hulm, Trivadis GmbH DOAGNews Q4_2005 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, bei auch nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

2 Integritätsgeschützte und verschlüsselte Datenübertragung mittels Secure Socket Layer (SSL) kennen wir aus dem täglichen Umgang mit Web-Browsern etwa beim Online Shopping. Das symbolische Schloss sowie das in der URL sind unverkennbare Zeichen einer sicheren Kommunikationsverbindung mit dem jeweiligen Server. Eine spezielle Konfiguration ist dazu normalerweise nicht erforderlich. Mit der Oracle Advanced Security Option (ASO) verfügen wir über unterschiedliche Möglichkeiten, auch Oracle Net-Verbindungen entsprechend abzusichern. Die folgenden Ausführungen behandeln ausschließlich die SSL-Variante, bietet diese doch zusätzlich auch noch die Möglichkeit der passwortfreien Anmeldung mittels Zertifikaten (Client- Authentifizierung). Den Wunsch, die Möglichkeiten SSL-geschützter Datenbank-Verbindungen selbst auszuprobieren, hatten sicher schon viele Administratoren. Einige haben es auch versucht und manche sogar geschafft. Gestaltet sich die Konfiguration tatsächlich so schwierig? Nein, aber bislang war der DBA meistens mangels ausreichenden Security-Kenntnissen bereits bei den ersten Versuchen auf Unterstützung aus dem Security-Bereich angewiesen. Aber gerade sensible Umgebungen könnten von den Möglichkeiten profitieren, und welcher DBA hätte nicht gerne einen sicheren Remote-Zugang ohne Passwortabfrage zu seinen Datenbanken? Dieser Artikel skizziert eine einfache Vorgehensweise (Kochrezept) für ihren ersten Test. Zu-nächst kurz zur Architektur. Im Rahmen der folgenden Konfigurationsbeschreibung werden verschiedene Parameter-Dateien angepasst. Auf der Client-Seite ist eine spezielle TCPS-Verbindung zu definieren. In unserem Beispiel setzen wir eine Namensauflösung mittels tnsnames.ora voraus. In der Praxis existieren hierbei natürlich unterschiedliche Möglichkeiten. Das Gegenstück der Verbindung, der Oracle- Listener, muss einen entsprechend sicheren TCPS-Verbindungsaufbau ebenfalls unterstützen. Generelle Einstellungen erfolgen auf beiden Seiten der Verbindung innerhalb der sqlnet.ora-konfigurationsdatei. Zudem muss die lizenzpflichtige Oracle Advanced Security Option (ASO) auf allen Clients und Servern installiert sein. Zusätzlich werden so genannte Oracle-Wallets und Zertifikate benötigt. Da sind sie wieder, die scheinbar unüberwindbaren Stolpersteine auf dem Weg zu SSL mit Oracle-Net. Spätestens an dieser Stelle der Konfiguration ist spezifisches Security-Know how gefragt, das dem Datenbank-Administrator oftmals fehlt. Betrachten wir dazu nochmals das eingangs erwähnte Beispiel der https-verbindung. Dabei handelt es sich konkret um eine SSL-verschlüsselte Verbindung ohne Client-Authentifizierung. Ein Client-Zertifikat wird dazu nicht benötigt. Der Web-Server des Shops verfügt selbstverständlich über ein Zertifikat, das er uns beim Verbindungsaufbau auch übermittelt. Unser Browser verfügt implizit (in der Standardeinstellung) über eine Liste von Zertifizierstellen, denen wir vertrauen. Wenn also das Server-Zertifikat von einer dieser Zertifizierstellen ausgestellt wurde, dann ist eine verschlüsselte Verbindung etabliert. Im Prinzip funktioniert dies mit einer Oracle-Net-Verbindung genauso, nur dass sich die Zertifikate als auch die Liste der vertrauenswürdigen Zertifizierstellen in Oracle-Wallets befinden. Im Rahmen der SSL-Verschlüsselung verwendet der Client das Wallet nur als Verzeichnis der vertrauenswürdigen Zertifizierstellen. Zur Client-Authentifizierung benötigt allerdings jeder Client zusätzlich ein eigenes Zertifikat.

3 Wollte man bis einschließlich Oracle Version 9i erste einfache Tests mit SSL und Oracle-Net unternehmen, dann musste sich der DBA entweder a) mit openssl auseinandersetzen und selbst Zertifikate ausstellen, b) einen Security-Spezialisten damit beauftragen oder c) Zertifikate von einer externen Zertifizierstelle (CA) beschaffen. Das Orapki-Utility Ab Oracle 10g besteht mit dem neuen kleinen Utility Orapki die Möglichkeit, Wallets per Kommandozeile, also auch per Script, zu erzeugen, sowie zu Testzwecken selbst signierte Zertifikate auszustellen. Da die Advanced Security Option (ASO) ab Oracle 10g auch gleich noch automatisch im Rahmen einer EE-Installation enthalten ist, benötigen sie tatsächlich nur noch die hier beschriebenen Schritte um eine erste Test-SSL-Verbindung zu etablieren. Damit können DBAs schon mal vorab, ohne Unterstützung der Security-Abteilung, die Möglichkeiten und Grenzen der Technologie evaluieren. Eine produktive Einführung bedingt die gleichen Rahmenbedingungen (PKI, Infrastruktur, etc.) wie bisher auch, was auf keinen Fall unterschätzt werden darf. Wallets erzeugen Der erste Schritt besteht darin, die notwendigen Wallets und Zertifikate zu generieren. Bisher war dazu der grafische Wallet-Manager notwendig.

4 1.1: Erzeugen der Oracle-Wallets für Client und Server Die Option auto_login bedeutet, dass die Zertifikate und der private Schlüssel unverschlüsselt abgelegt sind und ohne weitere Passwortangabe benutzt werden können. In einer produktiven Umgebung ist dies praktisch undenkbar, hier muss man Konzepte wie z.b. Hardware-Token evaluieren, bei denen die Zertifikate nicht auf der Festplatte abgelegt sind. 1.2: Generieren der self signed -Zertfikate Im Grunde benötigen wir zur asymmetrischen Verschlüsselung ein Schlüsselpaar bestehend aus dem so genannten privaten und dem öffentlichen Schlüssel. Als Zertifikat bezeichnen wir einen öffentlichen Schlüssel, der von einer Zertifizierungsstelle signiert wurde. Die Zertifizierungsstelle bestätigt mit der Signatur die Echtheit des öffentlichen Schlüssels. Normalerweise werden zunächst beide Schlüssel innerhalb des Wallets erzeugt. Der öffentliche Schlüssel wird dann in Form eines Zertifikat-Request exportiert und anschließend von einer Zertifizierstelle signiert. Jetzt haben wir das Zertifikat, das nur noch in unser Wallet importiert werden muss. Die Kommunikationspartner vertrauen im Rahmen der Prüfung solcher Zertifikate auf die Zertifizierstelle. Welchen Zertifizierstellen bei der Oracle-Net-Kommunikation vertraut wird, ermittelt Oracle aus der Liste der Trusted Zertifkate im Wallet. In unserer ersten Testkonfiguration erzeugen wir ein self-signed Zertifikat. Wir stellen uns selbst ein Zertifikat aus. Dabei werden sowohl ein entsprechendes Trusted -Zertifikat als auch unter gleichem Namen das User-Zertifikat generiert (siehe Grafik).

5 : Austausch der Zertifikate Im nächsten Schritt gilt es, die jeweiligen Trusted Zertifikate auszutauschen. Dazu werden die Zertifikate zunächst mit dem cert-parameter exportiert, zum Kommunikationspartner kopiert und dort importiert. Schließlich muss der Kommunikationspartner die Zertifizierungsstelle (den Aussteller des Zertifikates) ja auch kennen. Der Eintrag des Trusted-Zertifikates, also der Zertifizierstelle des Clients (siehe ) wird dabei nur im Falle einer Client-Authentifizierung benötigt. Die Schritte 1.2 bis 1.6 dürfen in dieser Form selbstverständlich nur zu Testzwecken verwendet werden! Integrität / Verschlüsselung Nachdem beide Kommunikationspartner über Wallets und Zertifikate verfügen, beleuchten wir zunächst ausschließlich die Konfigurationsschritte hinsichtlich Verschlüsselung und Integritätsprüfung. Eine Authentifizierung des Clients folgt später.

6 2.1: Sqlnet.ora mit Wallet-Datei ergänzen 2.2: Korrekten Connect-String mit TCPS-Protokoll erstellen 2.3: Listener-Konfiguration ergänzen Auch hier wird nochmals die Wallet-Datei des Servers definiert. Zusätzlich benötigen wir dann noch das Gegenstück zu unserem TCPS-Connect-String, den entsprechenden TCPS-Listener. 3: Test der verschlüsselten Verbindung Hierzu gibt es mehrere Alternativen. In unserem Beispiel benutzen wir den SQL-Trace. In der Trace-Datei finden wir jetzt hoffentlich eine so genannte Cipher-Suite. Es handelt sich dabei um eine Kombination unterschiedlicher Algorithmen zur Verschlüsselung und Integritätsprüfung. Ohne spezielle Konfiguration (sqlnet.ora) wird in unserem Beispiel per Default mit 3DES verschlüsselt und SHA zur Prüfung der Integrität verwendet. Vertiefende Informationen zum Thema Cipher- Suites finden sie in der Oracle-Dokumentation. Server -/Client-Authentifizierung Bei der Authentifizierung unterscheiden wir zwei Möglichkeiten, die auch prinzipiell unabhängig voneinander aktiviert werden können. Ohne Server-Authentifizierung kann man allerdings genauso gut ganz normale symmetrische Verschlüsselung nehmen (viel einfacher), SSL ist dann unnötig. Das diese Möglichkeit überhaupt existiert, lässt sich bestenfalls mit einer Erleichterung der Fehlersuche begründen. Also, wenn das Ganze nicht so funktioniert wie gewünscht, erst einmal eine Variante und dann die Kombination testen. In produktiven Umgebungen ist mindestens die Server-Authentifizierung einzusetzen.

7 4.1: Server-Authentifizierung Mit der zusätzlichen Einstellung SSL_SERVER_DN_MATCH = TRUE wird festgelegt, dass der Client die Identität des Servers überprüft. Dabei wird der DN im zusätzlich notwendigen Security- Parameter der Connect-Definition mit dem Namen des Serverzertifikat-Inhabers verglichen. Dadurch ist sichergestellt, dass der Client tatsächlich mit dem gewünschten Server kommuniziert, was eine unabdingbare Voraussetzung einer sicheren Kommunikation darstellt. 4.2: Client-Authentifizierung Die Client-Authentifizierung wird ebenfalls in der Sqlnet.ora, allerdings serverseitig aktiviert. 4.3: Global identifizierter Datenbank-User Jetzt brauchen wir nur noch einen global authentifizierten Datenbank Account. Damit verfügen wir über die Möglichkeit, eine Datenbank-Verbindung ohne Passwort aufzubauen. Im Gegensatz zu der alternativ möglichen Methode mittels remote_os_authent = true, die ein erhebliches Sicherheitsrisiko darstellt, handelt es sich dabei um eine sichere Kommunikationsverbindung. Gerade hoch privilegierte Administrations-Accounts gewinnen dadurch die Möglichkeit, beispielsweise Monitoring-Skripte remote ohne gespeicherte Passwörter auszuführen. Richten wir den gleichen Account auf mehreren oder allen unseren Datenbanken ein, dann verfügen wir über eine Art Single-Sign-On (SSO). Für ein richtiges SSO müsste die Applikation, in unserem Falle Oracle-Net, das Wallet-Passwort temporär zwischenspeichern (Caching-Verfahren), um das Manko mit auto_login (siehe auch 1.1) zu vermeiden.

8 Zusammenfassung Mit Hilfe von Orapki besteht die Möglichkeit, Oracle-Wallets mittels Kommandozeile und damit auch mit Skripten zu verwalten. Selbst signierte Zertifikate erleichtern den Einstieg, die ersten Schritte auf dem Weg zur SSL geschützten Oracle-Net-Kommunikation. Insbesondere DBAs sind damit in der Lage, schnell und pragmatisch erste Erfahrungen zu sammeln. Ein kleiner Fehler in Orapki (es handelt sich dabei um ein Skript, das implizit die Java-Klassen des OWM aufruft), verhindert aktuell (in Version 10.1.x) das Erzeugen selbst signierter Zertifikate (siehe hierzu Metalink Bug ). Der Fehler ist allerdings mit einem simplen Workaround zu beheben und sollte in 10g Release 2 gefixt sein. Die Anforderungen an produktive Umgebungen sind nach wie vor umfangreich. Fundiertes Knowhow im Security-Umfeld sowie eine geeignete PKI-Infrastruktur sind unabdingbare Voraussetzungen. Oracle bietet hierzu ab der IAS Version 10g die OracleAS Certificate Authority (OCA). Literaturverweise Oracle10g Advanced Security Administrator s Guide Part No. B DOAG Vortrag: ASO wieso? SSL =SSO? Fachartikel: Sichere Datenübertragung mit Oracle Kontakt: Peter Hulm peter.hulm@trivadis.com