Architektur / Komponenten ASO SSL. sqlnet.ora sqlnet.ora

Transkript

1 Betrifft: Oracle NET - SSL Test and orapki is your friend Autor: Peter Hulm Art der Info: Technische Background Info (Juli 2005) Quelle Aus unserer Schulungs- und Beratungstätigkeit Integritätsgeschützte und verschlüsselte Datenübertragung mittels Secure Socket Layer (SSL) kennen wir aus dem täglichen Umgang mit Webbrowsern, z.b. 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 Datenbankverbindungen selbst auszuprobieren, hatten sicher schon viele Administratoren. Einige haben es dann tatsächlich 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. Eine schnelle unbürokratische Evaluierung wurde dadurch häufig erschwert. 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. Aller Anfang muss nicht unbedingt sprichwörtlich schwer sein Aber zunächst noch einmal kurz zur Architektur. Im Rahmen der folgenden Konfigurationsbeschreibung werden verschiedene Parameterdateien angepasst. Auf der Client-Seite ist eine spezielle TCPS - Verbindung zu definieren. In unserem einfachen 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. Des Weiteren muss die lizenzpflichtige Oracle Advanced Security Option (ASO) auf allen Clients und Servern installiert sein.

2 Architektur / Komponenten ASO SSL Client Wallet Server Wallet tnsnames.ora listener.ora sqlnet.ora sqlnet.ora 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 Datenbankadministrator oftmals fehlt. Keine Angst, die Themen Zertifikate und PKI Infrastrukturen will ich hier nicht noch einmal aufgreifen. Diese Themen wurden in früheren Publikationen und DOAG Vorträgen bereits hinreichend besprochen (siehe Literaturverweise) und würden den Rahmen dieses Artikels sprengen. Trotzdem möchte ich hier noch mal ganz kurz die wichtigsten Konzepte ansprechen. 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 Webserver 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 Serverzertifikat von einer dieser Zertifizierstellen ausgestellt wurde, dann wird eine verschlüsselte Verbindung etabliert. Im Prinzip funktioniert dies mit einer Oracle Net Verbindung genauso, nur die Zertifikate als auch die Liste der vertrauenswürdigen Zertifizierstellen befinden sich in Oracle Wallets. 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. 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.

3 Das Ganze meistens auch noch ohne genau zu wissen, was wirklich benötigt wird - oftmals ein ernüchterndes Erlebnis. 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 DBA s 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. 1 Wallets erzeugen ASO SSL Client Server orapki wallet create -wallet <client.wallet> -auto_login orapki wallet add -wallet <client.wallet> -dn "CN=Peter Hulm" -keysize self_signed -validity 365 orapki wallet export -wallet <client.wallet> -dn "CN=Peter Hulm" -cert PHU.cert copy orapki wallet add -wallet <client.wallet> -trusted_cert -cert SSLDB.cert orapki wallet create -wallet <server.wallet> -auto_login orapki wallet add -wallet <server.wallet> -dn "CN=SSLDB" -keysize self_signed -validity 365 orapki wallet export -wallet <server.wallet> -dn "CN=SSLDB" -cert DB.cert 1.3 copy orapki wallet add -wallet <server.wallet> -trusted_cert -cert PHU.cert : 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.

4 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 Zertifikatrequest 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 wird sowohl ein entsprechendes Trusted Zertifikat als auch unter gleichem Namen das User Zertifikat generiert (siehe Grafik) : 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

5 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. 2 Integrität / Verschlüsselung ASO SSL Client Server SQLNET.ORA WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <client.wallet>) ) ) 2.1 SQLNET.ORA WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <server.wallet>) ) ) TNSNAMES.ORA SSLDB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = langley)(port = 2484))) (CONNECT_DATA = (SERVICE_NAME = DB)) ) LISTENER.ORA WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <server.wallet>) ) ) SSL_LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS) (HOST = langley)(port = 2484))) 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.

6 3: Test der verschlüsselten Verbindung Hierzu gibt es mehrere Alternativen. In unserem Beispiel benutzen wir den SQL-Trace. 3 Test Integrität / Verschlüsselung > 3.1 SQL-Trace auf Client-Seite aktivieren: Dazu einfach die entsprechende Sqlnet.ora Datei ergänzen. # Sqlnet.ora TRACE_LEVEL_CLIENT = ADMIN TRACE_DIRECTORY_CLIENT = /tmp TRACE_FILE_CLIENT = Client > 3.2 Verbindung aufbauen sqlplus scott/tiger@db > 3.3 Überprüfen, ob tatsächlich eine verschlüsselte Verbindung erzeugt wurde Dazu suchen wir den String SSL Cipher Suite in unserer Tracedatei. Im Falle eines UNIX Betriebssystems könnte das folgendermaßen aussehen: Grep SSL Cipher Suite /tmp/client_*.trc client_7003.trc:[24-jul :18:38:910] nzos_trace_negotiated_cipher: The Final Negotiated SSL Cipher Suite is: SSL_RSA_WITH_3DES_EDE_CBC_SHA In der Tracedatei 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 von einander 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 Server / Client Authentifizierung ASO SSL Client Server SQLNET.ORA SSL_SERVER_DN_MATCH = TRUE SQLNET.ORA SSL_CLIENT_AUTHENTICATION = TRUE TNSNAMES.ORA SSLDB-CHECK = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = langley)(port = 2484))) (CONNECT_DATA = (SERVICE_NAME = SSLDB)) (SECURITY = (SSL_SERVER_CERT_DN = "CN=SSLDB")) ) 4.3 sqlplus / as sysdba > create user phu > identified globally as 'CN=Peter Hulm'; > grant dba to phu; exit; 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 Datenbankverbindung 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. 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 DBA s 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 Know How im Securityumfeld 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 Sollten sie sich jetzt doch noch nicht ganz sicher sein, dann beraten wir sie natürlich gerne - denn sicher ist sicher. Trivadis GmbH Mail: peter.hulm@trivadis.com Peter Hulm Freischützstraße 92 Tel: D München Fax: Internet: