Logo Oracle Deutschland   DBA Community  -  September 2015
External Password Stores - Ohne Benutzername und Passwort sicher einloggen
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Client-Server-Anwendungen und Batch Jobs, aber auch privilegierte Benutzer wie DBAs, die Werkzeuge wie SQL*Plus nutzen, loggen sich unter Angabe von Benutzername und Passwort auf Datenbanken ein. Die Steuerdateien der Batch-Jobs bergen ein Sicherheitsrisiko, denn sie enthalten häufig Benutzernamen und Passwörter. Auf UNIX-Systemen kann sogar jeder, der Zugriff auf das System hat, die im Skript enthaltenen oder eingegebenen Passwörter in der Prozessliste im Klartext sehen.

Der Beitrag zeigt, wie sowohl Batch Jobs als auch Benutzer sich mittels sogenannter external password stores sicher und ohne Eingabe von Benutzername und Passwort bei der Datenbank anmelden können.

External password stores (eps) sind ein Feature, das in allen Editionen der Datenbank zur Verfügung steht. Implementiert wird das Feature über Einträge in den Dateien sqlnet.ora und tnsnames.ora sowie über ein Wallet. Dieses Wallet ist das eigentliche external password store - eine nur wenige KB große verschlüsselte Datei, die durch ein Passwort gesichert ist. External password stores werden meistens auf der Clientseite eingesetzt, aber sie funktionieren auch direkt auf dem Server. Das Beispiel unten implementiert sie auf dem Server.

Vorgehensweise

In vier Schritten richtet man das Verwenden von external password stores ein
  1. Anlegen und Einrichten des Wallet
  2. Servicenamen in tnsnames.ora eintragen
  3. sqlnet.ora anpassen
  4. Skripte anpassen / Einloggen ohne Passwort

1. Anlegen und Einrichten des Wallet

Im ersten Schritt wird das Wallet in einem beliebigen Verzeichnis des Betriebssystems angelegt, auf das der Eigentümer der Oracle Software Zugriff hat. In diesem Verzeichnis darf kein anderes Oracle Wallet gespeichert sein - zum Beispiel kein Wallet, das für die Verschlüsselung von Daten mit dem Feature transparent data encryption (TDE) der Advanced Security Option (ASO) verwendet wird (in Oracle Database 12c werden die TDE Wallets auch als Keystores bezeichnet). Die Erklärung für die Einschränkung ist banal: ALLE von Oracle angelegten Wallets / Keystores tragen den Dateinamen ewallet.p12. Das Anlegen eines Wallet in einem Verzeichnis mit vorhandenem Wallet / Keystore würde ein vorhandenes Wallet / Keystore überschreiben.

Zum Anlegen des Wallet wird das Werkzeug mkstore verwendet. Der Aufruf zum Anlegen des Wallet könnte folgendermassen aussehen
mkstore -wrl $ORACLE_HOME/network -create
Es wird ein Passwort abgefragt, mit dem das Wallet vor unbefugtem Öffnen geschützt wird. Entspricht das eingegebene Passwort nicht den Anforderungen - es muss mindestens 8 Zeichen lang sein und dabei mindestens 1 numerisches Zeichen oder 1 Sonderzeichen enthalten - erhält der Benutzer die Fehlermeldung
PKI-01002: Invalid password:Passwords must have a minimum length of eight 
characters and contain alphabetic characters combined with numbers or special 
characters. 
Hier soll als Passwort community1 verwendet werden.

Das Wallet wird - wie oben bereits angemerkt - mit dem Namen ewallet.p12 angelegt. Ausserdem wird im selben Verzeichnis eine ebenfalls verschlüsselte Datei namens cwallet.sso angelegt. Diese Datei enthält das Passwort für das Wallet und wird von Oracle zum Zugriff auf das Wallet genutzt. Das Wallet wird durch diesen Mechanismus zu einem sogenannten auto open wallet. Das bedeutet, dass das Wallet mit dem Öffnen der Datenbank verfügbar ist.

Nun können die Einträge gemacht werden, die es später erlauben, sich ohne Passworteingabe bei der Datenbank anzumelden. Benötigt werden - man könnte fast sagen logischerweise
  • ein beliebiger, frei vergebbarer Servicename, der mit einem vorhandenen Servicenamen identisch sein kann
  • ein Benutzername, der in der Datenbank angelegt sein muss
  • das in der Datenbank vorhandene Passwort für den angegebenen Benutzernamen
Die Einträge erfolgen wiederum mit mkstore
mkstore -wrl $ORACLE_HOME/network -createCredential epsservice scott
Im Beispiel ist also epsservice der Servicename, scott der allseits bekannte Benutzername. mkstore reagiert mit einer Eingabeaufforderung nach dem Datenbankpasswort von Scott. Geht man davon aus, dass dieses Passwort noch das Standardpasswort der Datenbankinstallation ist (eine schlechte Praxis, aber hilfreich für diesen Beitrag), gibt man hier also das bekannte Passwort tiger an. Um Fehleingaben abzufangen wird das Datenbankpasswort ein zweites Mal abgefragt, dann folgt die Abfrage des Passwortes für den Zugriff auf das Wallet (community1). Ist alles korrekt angegeben, wird der Eintrag im Wallet erzeugt. Ausdrücklich sei darauf hingewiesen, dass nach einer Änderung des Passwortes in der Datenbank das Passwort auch im Wallet geändert werden muss. Dies geschieht ebenfalls über mkstore. Details dazu und darüber, wie man die im Wallet vorhandenen Einträge auflistet (Passwörter werden dabei nicht angezeigt), Einträge löscht und Passwörter sowie Servicenamen ändert, liefert das Handbuch Database Security Guide).

Ein Benutzername kann auch mit mehreren Servicenamen verbunden werden. Ebenso ist es möglich, mehrere Benutzer in einem Wallet mit mehreren Servicenamen zu verbinden. Wichtig ist, dass jeder Servicename pro Wallet nur einmal vergeben wird. Man könnte sich also die Einträge im Wallet als Zeilen einer Tabelle vorstellen, die aus drei Spalten (Servicenamen, Benutzernamen, Passwörter) besteht und deren Primärschlüssel der Servicename ist. Jede Zeile bzw. jeder Servicename wird einzeln mit mkstore im Wallet angelegt.

2. Servicenamen in tnsnames.ora eintragen

Die im Wallet angegebenen Servicenamen müssen nun über Einträge in der Datei tnsnames.ora spezifiziert werden. Dazu könnte man der Einfachheit halber zum Beispiel einen vorhandenen Eintrag duplizieren und modifizieren. Der Eintrag für den Servicenamen epsservice, der im Beispielwallet oben angelegt wurde, könnte etwa so aussehen
epsservice =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = hwf.de.oracle.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.de.oracle.com)
    )
  )

3. Verwendung des Wallet über sqlnet.ora einrichten

Nachdem das Wallet angelegt und mit Einträgen versehen ist sowie die Servicenamen in der Datei tnsnames.ora spezifiziert sind, muss noch bekannt gemacht werden, in welchem Verzeichnis das Wallet gespeichert ist. Ausserdem muss festgelegt werden, dass das Wallet auch tatsächlich zum Verbindungsaufbau benutzt werden soll. Das geschieht durch zwei Einträge in der Datei sqlnet.ora. Benutzt werden dazu die Parameter wallet_location und sqlnet.wallet_override. Für das Beispiel sieht der Eintrag demnach so aus
wallet_location = (SOURCE = 
                    (METHOD = FILE)
                    (METHOD_DATA =
                      (DIRECTORY = $ORACLE_HOME/network/)
                     )
                   )
sqlnet.wallet_override = TRUE
Damit sind alle Komponenten für die Verwendung von external password stores eingerichtet. Hier noch einmal alles zur Zusammenfassung als Schaubild

Zusammenspiel der Komponenten

4. Anpassen von Skripten / Einloggen ohne Passwort

Nun müssen nur noch die Skripte der Batch Jobs modifiziert werden. Dazu wird jeweils das connect BENUTZERNAME/PASSWORT ersetzt durch connect /@servicename, um im Beispiel zu bleiben also durch connect /@epsservice. Der Aufruf von SQL*Plus auf der Kommandozeile erfolgt entsprechend, wie man an der folgenden Darstellung erkennen kann
orcl /home/oracle> 
orcl /home/oracle> whoami
oracle
orcl /home/oracle> sqlplus /@epsservice

SQL*Plus: Release 12.1.0.2.0 Production on Sat Aug 15 08:29:15 2015

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Last Successful login time: Sat Aug 15 2015 08:27:09 +02:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics, Real Application Testing
and Unified Auditing options

SQL epsservice> show user
USER is "SCOTT"
SQL epsservice> 
Zum Abschluss sei darauf hingewiesen, dass es sich natürlich empfiehlt, die beteiligten Dateien zusätzlich vor dem Zugriff durch Unbefugte zu sichern - unter UNIX etwa durch eine restriktive Vergabe der Lese- und Schreibberechtigungen.

Weitere Informationen

Database Security Guide: Das Handbuch mit den vollständigen Informationen zum Thema secure external password stores.

Support Dokument 340559.1 "Using The Secure External Password Store": Technische Anleitung und Hinweis darauf, dass das Feature KEIN Feature von ASO ist und in allen Editionen der Datenbank verfügbar ist.

Support Dokument 1441745.1 "Using a Secure External Password Store with the JDBC Thin Driver": Besonderheiten bei Thin Client Anwendungen.

Zurück zur Community-Seite