Jeder, der Skripte zur Überwachung einer Oracle Datenbank oder für Prozessabläufe in Zusammenspiel mit einer Oracle Datenbank einsetzt, kennt das Problem:
Wohin mit dem Passwort meines Datenbankbenutzers?
In Klartext will man es eigentlich nicht in die Skripte schreiben.
Und eine klassische Remoteverbindung ohne Passwort, gesteuert über die Datenbank-Parameter remote_os_authent und os_authent_prefix, will der DBA (korrekterweise) aber auch nicht einrichten.
Beides stellen Sicherheitsrisiken dar, die viele Firmen in einer Zeit, die von Compliance und Security bestimmt wird, nicht mehr eingehen können.
Abhilfe kann hier ein weithin recht unbekanntes Feature schaffen, das Oracle mit der Datenbankversion 10.2 eingeführt hat: Secure External Password Store.
Ein solcher Secure External Password Store besteht aus einem Oracle Wallet, das ein oder mehrere TNS-Alias/Benutzername/Passwort-Kombinationen aufnehmen kann. Ein Wallet wiederum ist eine mit 3DES verschlüsselte Datei, die zudem über Betriebssystemberechtigungen geschützt werden kann.
Das Schönste daran aber ist sicherlich, dass man – trotz Einsatz von Wallets – keine teure Oracle Advanced Security Option (ASO) dafür benötigt, sondern dieses Feature kostenfrei in der Enterprise Edition nutzen kann.
Im folgenden Artikel werden die einzelnen Schritte erläutert, um eine solche Verbindung einrichten zu können.
Es sind keine speziellen Anpassungen an der Datei TNSNAMES.ORA der Clients notwendig. Der für die Verbindung zur Datenbank verwendete Eintrag (TNS-Alias) muss darin aber natürlich enthalten sein.
Ein Beispiel:
O112 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)
(HOST = donald.muniqsoft.de)
(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = O112)
)
)
Testen des TNS-Alias:
C:\> tnsping o112
[…]
Adapter TNSNAMES zur Auflösung des Alias benutzt
Verbindungsversuch mit (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = donald.muniqsoft.de)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = O112)))
OK (20 ms)
Bevor der Oracle Client ein Wallet nutzen kann, muss er wissen, wo das Wallet liegt. Dazu definiert man das Verzeichnis für das Wallet clientseitig in der Datei SQLNET.ORA:
WALLET_LOCATION =
(SOURCE = (METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = C:\Oracle\product\11.2.0\client_1\NETWORK\ADMIN)))
SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT.AUTHENTICATION = FALSE
Der Eintrag SQLNET.WALLET_OVERRIDE sorgt dafür, dass alle Benutzerkonfigurationen aus anderen Wallets (z. B. ASO-SSL-Wallets) überschrieben werden.
Es gibt zwei Möglichkeiten, um ein Wallet zu erstellen.
C:\>cd C:\Oracle\product\11.2.0\client_1\NETWORK\ADMIN
C:\...\ADMIN>mkstore -wrl "." –create
Kennwort eingeben
Kennwort eingeben
Das Wallet Passwort sollte aus Sicherheitsgründen komplex sein.
Wenn es zu einfach ist, erhält man die Fehlermeldung:
PKI-01002: Ungültiges Kennwort
Die folgenden Dateien wurden durch diesen Befehl neu erstellt:
14.10.2011 11:54 3.589 cwallet.sso
14.10.2011 11:54 3.512 ewallet.p12
Hinweis:
Unter Linux haben die beiden Dateien die Zugriffsmaske: 600
Ein Nachteil dieser Methode ist, dass ein Datenbankzugriff über dieses Wallet auch funktioniert, wenn es auf einen anderen Server kopiert wird. Um dieses Sicherheitsproblem umgehen zu können, wurde in Oracle 11.2 das ORAPKI Tool um die Option AUTO_LOGIN_LOCAL erweitert.
C:\>cd C:\Oracle\product\11.2.0\client_1\NETWORK\ADMIN
C:\...\ADMIN>orapki wallet create -wallet "." -auto_login_local
Kennwort eingeben
Kennwort eingeben
Das Wallet Passwort sollte aus Sicherheitsgründen komplex sein.
Die folgenden Dateien wurden durch diesen Befehl neu erstellt:
14.10.2011 12:14 3.589 cwallet.sso
14.10.2011 12:14 3.512 ewallet.p12
Hinweis:
Unter Linux haben die beiden Dateien die Zugriffsmaske: 600
Durch die Option AUTO_LOGIN_LOCAL kann dieses Wallet nur noch auf dem Server benutzt werden, auf dem es erstellt wurde. Ein kleiner Wermutstropfen: Leider kann dadurch auch nur der Ersteller das Wallet für Zugriffe auf Datenbanken nutzen, unabhängig von den Betriebssystemberechtigungen dieser Datei(en).
Unberechtigte Benutzer oder Server erhalten bei der Benutzung dieses Wallets eine Fehlermeldung:
ERROR:
ORA-12578: TNS:wallet open failed
Um das Wallet sinnvoll nutzen zu können, müssen nun noch Einträge für TNS-Aliase, Benutzernamen und zugehörige Passwörter vorgenommen werden.
Dies geschieht in beiden Fällen mit dem Tool MKSTORE.
mkstore -wrl <Wallet-Loc> -createCredential <TNS-Alias> <USERNAME>
Ein Beispiel (der Benutzer MONITOR wurde in der Zieldatenbank bereits als Benutzer mit einem Passwort und entsprechenden Berechtigungen angelegt):
C:\>cd C:\Oracle\product\11.2.0\client_1\NETWORK\ADMIN
C:\...\ADMIN>mkstore -wrl . -createCredential o112 monitor
[…]
Ihr Schlüssel/Kennwort fehlt in der Befehlszeile
Geben Sie Ihren Schlüssel/Ihr Kennwort ein:
Geben Sie Ihren Schlüssel/Ihr Kennwort erneut ein
Wallet-Kennwort eingeben:
Hinweis:
Neben dem Passwort für den Benutzer muss am Ende auch das Wallet-Passwort angegeben werden.
Jetzt kann man sich als Benutzer MONITOR durch einfache Eingabe von „/@o112“ an der Remote-Datenbank anmelden, ohne ein Passwort angeben zu müssen. Dieses Passwort wird vom Client automatisch über das Wallet extrahiert.
C:\>sqlplus /@o112
[…]
SQL> show user
USER ist "MONITOR"
SQL> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------
db_name string O112
Dadurch, dass der TNS-Alias innerhalb des Wallets einen Primary Key definiert, kann pro Datenbank-Alias auch nur ein Benutzername hinterlegt werden. Wer also für eine Datenbank einen weiteren Benutzerzugang benötigt, legt am einfachsten einen weiteren TNS-Alias für diese Datenbank an.
C:\...\ADMIN>mkstore -wrl . -createCredential o112_2nd audit
Wen interessiert, was im Wallet bereits definiert ist, kann dies mit dem Tool MKSTORE auslesen, sofern er das Wallet-Passwort kennt:
C:\...\ADMIN>mkstore -wrl . -listCredential
[…]
Wallet-Kennwort eingeben:
List credential (index: connect_string username)
2: o112_2nd audit
1: o112 monitor
Das Passwort bestehender Einträge kann auch verändert werden:
mkstore -wrl . -modifyCredential <TNS-Alias> <USERNAME> <PWD>
Bestehende Einträge können natürlich auch wieder gelöscht werden:
mkstore -wrl . –deleteCredential <TNS-Alias>
Beim Einsatz von Java Anwendungen muss der JDBC-OCI Treiber verwendet werden.
Connection conn = DriverManager.getConnection ("jdbc:oracle:oci:/@o112");
Da in der Praxis aus Sicherheitsaspekten häufig nur ein Einsatz mit aktiver AUTO_LOGIN_LOCAL Option in Frage kommt, ist man dadurch leider auf einen einzigen Betriebssystem-Benutzer pro Remote-Server festgelegt.
Wen das aber nicht stört, der hat mit diesem Feature ein sehr praktikables Werkzeug, wenn man eine skript-basierte Überwachung oder Jobsteuerung auf einem Remote-Server laufen lassen will, ohne dass Passwörter im Klartext hinterlegt oder Benutzern mitgeteilt werden müssen.
Weitere Details zu diesem und vielen anderen sicherheitsrelevanten Themen erhalten Sie in unseren 
Security-Schulungen oder direkt durch einen unserer erfahrenen Oracle Consultants.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.
