Sichere Remote Verbindung ohne Passworteingabe

05.
November
2011
Veröffentlicht von: Hans Wesnitzer

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?

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.


Anpassungen an der TNSNAMES.ORA

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)

 

Anpassungen an der SQLNET.ORA

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.

 

Erstellen des Wallet

Es gibt zwei Möglichkeiten, um ein Wallet zu erstellen.

Das Tool MKSTORE

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.

Das Tool ORAPKI

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


Definieren von TNS-Alias/Benutzername/Passwort-Kombinationen

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.


Testen der Verbindung

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


Weitere Tipps

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");


Zusammenfassung

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 Opens internal link in current windowSecurity-Schulungen oder direkt durch einen unserer erfahrenen Oracle Consultants.

Jede Menge Know-how für Sie!

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.