Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt.

Insel-Lösungen oder zentrales Verzeichnis?

Auch wenn Identity Management (IDM) in den letzten Jahren an Verbreitung gewonnen hat und in den meisten Firmen eingeführt worden ist, sind in heutigen IT-Landschaften immer noch Inselsysteme vorhanden, die ihre Anwender lokal und nicht über den unternehmensweiten Verzeichnisdienst authentifizieren. Meist sind dies Legacy-Systeme aus vergangenen Zeiten, oft aber auch Oracle-Datenbanken. In anderen Fällen wurden mehrere, konkurrierende IDM Systeme eingeführt (AD und SAP, oder AD für Windows und LDAP für UNIX).

Verfügt ein und dieselbe Person über mehrere Kennungen zum gleichen oder zu verschiedenen Systemen, steigt nicht nur der individuelle Aufwand, sich mehrere Zugangskennungen und deren Passwörter zu merken, sondern es müssen auch unterschiedliche Passwort-Ablauf-Intervalle und Komplexitätsrichtlinien bedacht werden. Oft sinkt auch die Qualität der verwendeten Passwörter, weil die Anwender es leid sind, sich gleich mehrere gute Passwörter auszudenken und diese regelmäßig zu ändern. Also wird das gleiche Kennwort oder eine einfache Iteration davon mehrfach verwendet. Wird so ein mehrfach genutztes Kennwort gleichzeitig in einem wichtigen und in einem vielleicht unwichtigeren System verwendet, ist auch das wichtige System kompromittiert, wenn das unwichtige “gehackt” wird. Letztlich pflegt der Anwender verschiedene Listen und erledigt eine Arbeit, für die eigentlich Computer erfunden wurden. Das Ganze erschwert bis verunmöglicht die klare Zuordnung zwischen einer Person und ihrer digitalen Identität. Der Entzug von Zugangsberechtigungen kann nicht sicher und in Echtzeit erfolgen, wenn er in mehreren System ausgeführt werden muss, und oft bleiben Schatten-Benutzer in nachgelagerten System bestehen.

Ein weiterer Nachteil solcher heterogenen und verteilten Strukturen ist, dass Zusatzmodule nur langsam und aufwändig ausgerollt werden können. Die optimale Benutzerauthentifikation ist immer noch durch eine Two-Factor-Authentication gegeben, also ein (gutes) Passwort (“something you know”) und etwas, das der Anwender besitzt (“something you have”). Letzteres ist in der Regel entweder eine SmartCard, eine TAN/OTP-Liste oder ein Token-Generator. Werden die Benutzer an einer zentralen Stelle authentifiziert, ist es mit relativ Aufwand möglich, solche Verfahren einzuführen.

Oft sind es gar keine persönlichen Berechtigungen, die vergeben werden, sondern technische Accounts, zu deren der Zugang verwaltet wird (etwa SYS, SYSTEM, root oder Administrator). Die Verwendung von lokalen Passwörtern bringt hier noch weitere Nachteile mit sich, denn es ist so überhaupt nicht mehr nachvollziehbar, wer wann welche Änderungen an den Systemen durchgeführt hat. Einmal durch das Verteilen von Passwörtern erteilte Zugangsberechtigungen können, etwa beim Ausscheiden eines Mitarbeiters, nur noch durch eine globale Passwortänderung entzogen werden – diese muss dann aber mit viel Aufwand ausgerollt und kommuniziert werden. Oder aber diese Passwörter werden gar nicht von Personen benutzt, sondern sind in Skripten oder Applikationen hinterlegt. In diesem Fall wird aus dem Rechteentzug für einen Mitarbeiter ein technischer Change mit entsprechenden Test-Zyklen, denn oft ist gar nicht mehr bekannt, wo ein solches Passwort überhaupt eingearbeitet wurde, und welche Anwendungen vielleicht nach einer Änderung nicht mehr funktionieren. Ein schwer überschaubares Risiko ist entstanden und zementiert das Weiter benutzen alter Passwörter. Das betroffene System weiß nicht, wer sich anmelden kann, und es ist nicht möglich, die Zugriffssicherheit zu beurteilen, da nicht bekannt ist, wie gut die jeweiligen Skripte geschützt sind.

Eine andere, äußerst beliebte Möglichkeit, Zugänge zu verwalten, sind Passwort-Manager wie 1Password oder KeePass. Während 1Password vor allem auf IOS-Geräten für die persönliche Passwortverwaltung Anwendung findet, wird KeePass häufig eingesetzt, um gruppen- oder firmenweit Passwörter zu verwalten, indem die KeePass-Datei auf einem gemeinsam zugänglichen Share abgelegt und mit einem Passwort gesichert wird. Andere Systeme wie WebPasswortSafe sind web-basiert, so das keine Datei geteilt werden muss. Jeder Anwender braucht sich also nur noch ein Passwort zu merken (das des Passwort Managers), dennoch können die einzelnen Passwörter der eigentlichen Systeme sicher gestaltet werden. Die meisten Passwort-Manager bieten hierfür einen eigenen Passwort-Generator an. Trotz dieser Vorteile bleibt das Problem, dass alle Passwörter geändert werden müssen, wenn das Master-Passwort in falsche Hände gerät, oder ein Mitglied die Gruppe verlässt – was zu einem unkalkulierbaren Aufwand werden kann. Auch alle anderen oben angesprochenen Probleme werden nicht gelöst.

Die Oracle Datenbank speichert lokale Passwörter als Hashes im Data Dictionary ab. Je nachdem, welche Datenbank-Version Verwendung findet (10i, 11i oder 12c), werden verschiedene Hash-Algorithmen verwendet. Die Hash-Werte werden in der Tabelle SYS.USER$ abgelegt; in der Datenbank Version 10i als 3DES-Hash in der Spalte “PASSWORD”, ab 11g in der Spalte “SPARE4”. Bei der Authentifikation ab 11g existiert eine vielbeachtete Sicherheitslücke im O5LOGON Protokoll, die es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Der 10i-DES-Hash wird auch bei neueren Datenbanken bei jeder Passwort-Änderung von der Datenbank neu erzeugt. Die Hashes sind in keinem Fall besonders gesichert, jeder Benutzer mit DBA-Berechtigungen kann sie auslesen. Auch in den Datenbankdateien stehen sie unverschlüsselt.

Es ist generell mit Hilfe von Bruce-Force oder Rainbow-Tabellen möglich, die ursprünglichen Kennwörter von gängigen Hashes zu bestimmen, wenn die Hashes bekannt sind. Der Schwierigkeitsgrad für diese Rückrechnung zeichnet den verwendeten Hash-Algorithmus aus. Viele der in den letzten Jahren im Internet verbreiteten “gehackten” Passwort-Listen sind durch solche Rückrechnung entstanden, der Angreifer konnte beispielsweise über SQL Injection oder einen anderen Angriffsweg Passwort-Hashes auslesen und hat dann entweder die Hash-Listen oder gleich die daraus errechenbaren Klartext-Passwörter veröffentlicht. Auch hier entsteht ein Mehrfach-Schaden, wenn die  Anwender Ihre Passwörter auch für andere Systeme verwendet haben.

Um zu verhindern, das der Hash-Wert für ein und dasselbe Passwort in verschiedenen System gleich ist und so das Klartext-Passwort über eine Rainbow-Table bestimmt werden kann, werden Salts verwendet. Hierfür wird das Kennwort für dem Bilden das Hashes mit einem Zufallswert ergänzt. Dies funktioniert aber nur, wenn der Zufallswert, das Salt, nicht vorhersagbar ist, was beim Oracle-11-Passwort-Mechanismus allerdings leider der Fall ist. Beim Oracle-10-Mechanismus wird gar kein Salt verwendet, und auch diese alten Hashes werden von der Datenbank mitgepflegt, wenn dies nicht gesondert abgeschaltet wurde. Sie können daher als Angriffsweg verwendet werden. Die gesamte Entschlüsselungsprozedur kann mittlerweile mit kommerziellen Tools unterstützt werden.

Kann also die Tabelle SYS.USER$ einer Oracle-Datenbank ausgelesen werden, sind die Hashes und in der Regel auch bald die Klartext-Passwörter verfügbar. Untersuchungen haben ergeben, dass über 90% der bei Deutschen Firmen angetroffenen Oracle-Datenbank-Passwörter einfach genug waren, um sie aus den Hashes zu bestimmen.

Oracle Datenbanken an Verzeichnisdienste anbinden

Die ideale Lösung ist also, Authentifizierung und Authentisierung (also das Überprüfen der Identität einer Person und das Verwalten der Zugriffsrechte dieser Person) nicht in den Systemen selbst zu implementieren, sondern in einer zentralen Instanz, dem Verzeichnisdienst. Doch wie genau werden Oracle Datenbanken an die gängigen Verzeichnisdienste angeschlossen?

Die Grundvoraussetzung für extern authentifizierte Benutzerkonten bringt jede Oracle-Datenbank in Form von Enterprise User Security (EUS) bereits mit. Mittels

CREATE USER "..." IDENTIFIED GLOBALLY;

lässt sich ein Datenbank-Benutzer anlegen, der über einen externen Dienst authentifiziert wird. Wie genau dieser funktioniert, wird in der TNS-Konfiguration sowie mit Hilfe des Database Configuration Assistant (DBCA) geregelt – es stehen mehrere Möglichkeiten zu Auswahl, die in der Konfigurationsdatei “ldap.ora” im TNS-Verzeichnis angegeben werden können.

EUS steht nur für die Enterprise Edition (EE), nicht für die Standard-Edition zur Verfügung. Vor 11g erforderte der Einsatz von EUS die Lizenzierung der Advanced Security Option (ASO), seitdem heißt es:

Oracle Internet (OID) oder Unified Directory (OUD)

Oracle Internet Directory ist ein LDAPv3-kompatiber Verzeichnisdienst, der bereits seit Oracle 9i mit der Oracle Datenbank ausgeliefert wurde. Oracle hat mittlerweile auch den von Sun geerbten Oracle Directory Server Enterprise Edition (DSEE) im Portfolio und ebenso Oracle Unified Directory (OUD), einen in Java geschriebenen LDAP-Server, der langfristig die jetzt bestehenden Produkte ablösen wird.

Jedes LDAP-Verzeichnis kann neben den Anmeldeinformationen (Identity Management) generell auch weitere Daten zur Verfügung stellen, beispielsweise Host- und Netzwerkinformationen, um die Pflege einer TNSNames-Datei überflüssig zu machen. Überhaupt entstanden ist LDAP als Nachfolger anderer Verzeichnisdienste wie YP/NIS aus dem Sun-Umfeld.

Für die Verwendung mit Oracle Datenbanken sind OID und OUD derzeit am besten geeignet, da die für den sogenannten OracleContext nötigen LDAP-Schema-Erweiterungen bereits mitgeliefert werden. OID ist über mehrere Knoten skalierbar und der Informationsaustausch kann über SSL abgesichert werden. Die Verzeichnisinformationen selbst speichert OID in einer (Oracle) Repository-Datenbank, sensible Informationen treten also nur an einer Stelle auf und können hier separat geschützt werden – beispielsweise mittels Transparent Data Encryption (TDE).

Die Lizenzierung von OID oder OUD erfordert eine “Directory Services Plus”-Lizenz, die mit etwa $50k pro Prozessor zu Buche schlägt, oder eine Lizenzierung im Rahmen von Fusion Middleware. Eine Lizenzierung pro Benutzer ist ebenfalls möglich und für kleine Installationen günstiger. Für die Verwendung ausschließlich als Verzeichnisdienst für Oracle-Datenbanken ist es allerdings nicht notwendig, OID separat zu lizensieren:

“A restricted-use license for Oracle Internet Directory (OID) is included with all editions (except for Oracle Database Express Edition) if users use the Directory Naming feature to configure Oracle Net Services. OID may not be used or deployed for other uses” 

Diese Lizenz schliesst die Verwendung als Identity Management Provider allerdings nicht mit ein. Ist OID separat lizensiert, ist der Betrieb einer Repository-Datenbank in der Lizenz enthalten.

Funktionsweise

Normalerweise erfolgt die Authentifikation an einem LDAP-Server über “ldap bind”. Entweder wird das Passwort übertragen, oder es wird SASL verwendet. Für EUS wird stattdessen der Hash aus dem Directory ausgelesen und direkt in der Datenbank mit einem dort erzeugten Hash des vom Anwender angegebenen Passwortes verglichen. Das Directory wird also nur als Datensenke, nicht zentrale Authentifizierungsinstanz verwendet. Die Authentifikation selbst erfolgt in der Datenbank.

Installation und Einrichtung

Während für OID fast der gesamte Fusion Middleware Identity Management Stack inklusive einer Repository-Datenbank installiert werden muss, ist für OUD nur folgendes notwendig:

• OUD (11.1.2.3.0)
• WebLogic Server (10.3.6)
• ADF (11.1.1.9.0)

da OUD intern einfach eine Berkeley-DB verwendet, um die LDAP-Informationen zu speichern.

Verwendet man die richtigen Versionen, ist die Installation schnell erledigt. Oracle liefert eine Excel-Tabelle aus, um die Zertifizierungen der zusammengehörigen Komponenten darzustellen. Wird eine Oracle Linux Version > 5 verwendet, so müssen die Betriebssystem-Prüfungen des ADF-Installers ignoriert werden.  Es existieren eine Reihe von Einrichtungsvarianten für Skalierung und Hochverfügbarkeit wie Proxy-Server und Replikation, auf die hier nicht näher eingegangen werden soll.

Daten- Aufzucht und Pflege

OID und OUD können wir alle LDAP-Server bestehende Daten als LDIF-Dateien lesen. So können Daten aus einem bestehenden OpenLDAP oder beispielsweise MacOSX Server Verzeichnis übernommen werden. Vorher muss allerdings sichergestellt werden, das das Datenmodell übereinstimmt, also die LDAP-Schemata abgeglichen worden sind.

Die individuelle Verwaltung erfolgt mittels ODSM, einer Web-GUI, die in der Fusion Middleware verankert ist. Mit ihrer Hilfe kann das Schema verändert, können Erweiterungen installiert, Attribute gepflegt und einzelne Einträge verändert werden.

In der Regel wird das Verzeichnis neben der Datenbank-Anmeldung weitere Aufgaben übernehmen. Mittels eines Oracle-Frameworks namens OAS können UNIX-Systeme integriert werden, so dass eine Passwort-Änderung mit den UNIX-Tools (passwd) eine Änderung der Directory-Attribute bewirkt. Für eine weitreichendere Verzeichnis-pflege wird man aber auf weitere Hilfsmittel angewiesen sein. In einem Unternehmen oder einer sonstigen Einrichtung geht es ja in der Regel darum, bestimmte Workflows abzubilden (Mitarbeiter kommt in die Firma, Mitarbeiter verlässt die Firma, Forscher arbeitet in dieser Universität, etc.). Die kann mittels Skripten abgebildet werden, oder über das LDIF-Format in eine bestehende Applikation integriert werden. Oracle bietet auch hier eine komplette Identity Management Suite an. Eine weitere, elegante Möglichkeit ist, das Apache Directory Studio als GUI für den Datenbestand im LDAP zu verwenden. Dies funktioniert vor allem mit dem OUD ausgezeichnet.

Registrierung einer Datenbank

Für die Einrichtung wird zunächst mit dem Network Configuration Assistant (netca) oder per Hand die Konfigurationsdatei ldap.ora im TNS-Verzeichnis angelegt. Diese Datei weist den Weg auf den oder die verfügbaren LDAP-Server:

cat $TNS_ADMIN/ldap.ora
# ldap.ora Network Configuration File: /u01/app/11.2.0/grid/network/admin/ldap.ora
# Generated by Oracle configuration tools.
DIRECTORY_SERVERS= (linux4:3060:3131)
DEFAULT_ADMIN_CONTEXT = "dc=loopback,dc=org"
DIRECTORY_SERVER_TYPE = OID

Im nächsten Schritt kann die Datenbank mit dem Database Configuration Assistant (DBCA) unter “Configure Database Options” am Verzeichnis registriert werden.

Für die Kommunikation zwischen LDAP-Server und Datenbank wird in der Regel eine Transportverschlüsselung auf Netzwerkebene eingesetzt: SSL. Denn die Hashes werden vom LDAP-Server zur Datenbank übertragen und könnten andernfalls im Netzwerk mitgelesen werden. Für die SSL-Verschlüsselung müssen auf dem Datenbank-Server und auf dem Directory-Server sogenannte Wallets eingerichtet werden: geschützte Schlüsselbunde, die die SSL-Zertifikate und deren private Schlüssel enthalten. Auf der Datenbank-Seite legt der DBCA das Wallet beim Registrieren der Datenbank automatisch an. Der Speicherort des Wallets wird in der SQLNet-Konfigurationsdatei festgelegt:

WALLET_LOCATION=  
 (SOURCE=
     (METHOD=file)
     (METHOD_DATA=  
        (DIRECTORY=/u01/app/oracle/admin/loopds/wallet)))

Für die SSL-Kommunikation sollten die Zertifikate der Datenbank und des Directories signiert werden, sonst kann es zum allgemeinen Fehler

ORA-28030: Server encountered problems accessing LDAP directory service

kommen. Hierfür müssen die Certificate-Requests der beiden Server entweder von einem Trust Center, der eigenen PKI oder einfach selbstsigniert mit OpenSSL unterschrieben werden:

openssl ca -policy policy_anything -config loopca-url.cnf -out Certs/$1.pem -infiles Reqs/$1.req

Der Certificate Request kann mit dem Oracle Wallet Manager (OWM) oder mit “orapki” erzeugt werden. Diese Tools sind bereits mit der Datenbank-Standardinstallation installiert.

Konfiguration von Enterprise User Security

Im nächsten Schritt erfolgt die Zuordnung von Datenbank-Objekten zu Objekten aus der externen Authentifizierungsquelle. Hierfür müssen sogenannte Schema Mappings eingerichtet werden. Diese legen fest, wie LDAP-Credentials zu Datenbankbenutzern in Beziehung gesetzt werden sollen. Sie können am Einfachsten im Enterprise Manager eingerichtet werden. Dort lässt sich ein Abschnitt “Administration/Security/Enterprise User Security” finden. Hier kann man sich als Administrator am Verzeichnis anmelden (cn=orcladmin im OID). Dann muss in “Enterprise Domains” die “Oracle Default Domain” eingerichtet werden. Diese bestimmt den Einstiegspunkt im LDAP-Verzeichnisbaum, ab dem nach Daten für EUS gesucht werden soll.

Danach kann für einzelne Benutzer oder ganze Rollen ein Mapping erstellt werden. Dabei ist es möglich, für jeden Anwender einen einzelnen Datenbank-Benutzer anzulegen und die die Authentifikation über LDAP zu regeln, oder, ein Sammel-Schema einzurichten, welches bestimmten LDAP-Benutzern oder Gruppen zugewiesen wird. Es ist also möglich, beispielsweise im LDAP die Gruppen “Admins” und “Users” anzulegen und dann EUS so einzurichten, dass alle LDAP-Accounts, die einer dieser Gruppen angehören, zu entsprechenden Datenbank-Benutzern zugewiesen werden.

Im unserem Beispiel werden alle LDAP-Benutzer dem Datenbank-Account GLOBAL_IDENT zugewiesen. Diesem können nun ganz normal mittels GRANT Objekt-, Rollen- und System-Privilegien zugewiesen werden. Das Konto GLOBAL_IDENT selbst wird wie andere Konten auch mittels “CREATE USER”, aber dann unter Angabe von “IDENTIFIED GLOBALLY” in der Datenbank angelegt:

SYS@loopds1> create user global_ident identified globally;
User created.
SYS@loopds1> grant connect to global_ident; 
Grant succeeded.

Anschließend kann die Anmeldung getestet werden:

oracle@linux10 ~]$ sqlplus test/geheim
SQL*Plus: Release 11.2.0.3.0 Production on Sun Oct 14 11:53:38 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
GLOBAL_IDENT@loopds1> show user
USER is "GLOBAL_IDENT"

In diesem Beispiel existiert ein LDAP-Benutzer mit dem Namen “uid=test, dc=loopback, dc=org”, aber kein Datenbank-Benutzer namens TEST.

Die EUS-Mapping können übrigens auch ohne den Enterprise Manager mit dem Tool “eusm” vorgenommen werden:

eusm createMapping realm_dn="dc=loopback,dc=org" ldap_port=3060 ldap_host=oraldap1 ldap_user_dn="cn=orcladmin" ldap_user_password=XXX database_name="pkilab" map_type="ENTRY" map_dn="cn=test,cn=Users,dc=loopback,dc=org" schema=GLOBAL_CONNECT

Die Mappings können wie folgt ausgelesen und gesichert bzw. überprüft werden:

[oracle@oraldap1]$ eusm listMappings realm_dn="dc=loopback,dc=org" ldap_port=3060 ldap_host=oraldap1 ldap_user_dn="cn=orcladmin" ldap_user_password=XXX database_name=pkilab

LIST OF DATABASE SCHEMA MAPPINGS::
------------------------------------
Mapping Name: MAPPING0
Mapping Type: SUBTREE
Mapping DN: cn=Users,dc=loopback,dc=org
Mapping schema:PUBLIC_DATASET
Mapping Level :DATABASE 
Mapping Name: MAPPING1
Mapping Type: ENTRY
Mapping DN: cn=test,cn=Users,dc=loopback,dc=org

Microsoft Active Directory (AD)

Für die Integration von Microsoft Active Directory als Identity-Provider für Oracle-Accounts und als Name Service für die TNS-Konfiguration existieren zwei verschiedene Ansätze. Am einfachsten ist die Anbindung über Windows Native Authentication (WNA), mit der es möglich ist, Windows-Benutzern die Anmeldung an Oracle-Datenbanken über Active Directory Konten zu erlauben. Hierfür sind neben der Oracle Datenbank und dem AD keine weiteren Komponenten nötig. Diese Konfiguration funktioniert ohne EUS, aber funktioniert nur von Windows-PC’s aus.

Alternativ ist es möglich, OID und AD Verzeichnisse nebeneinander zu betreiben und zu synchronisieren. Hierfür ist von Oracle ein spezielles Tool erhältlich: Directory Integration Platform (DIP). Diese Methode erfordert, ein Tool, den “Active Directory Password Filter”, auf jedem AD-Kontroller zu installieren. Eine weitere Möglichkeit ist, AD direkt als LDAP-Server für die Datenbank zu verwenden. Hierzu ist es aber erforderlich, die Oracle LDAP-Schemaerweiterungen, den sogenannten OracleContext, in den AD-Server zu integrieren. Diese Lösung scheitert in der Praxis oft daran, dass das Schema auf dem AD-Server modifiziert werden muss. Außerdem muss dort ein Zusatztool installiert werden, um die Oracle-Hashes zu pflegen (siehe unten).

Weiterhin können OID, Oracle Virtual Directory (OVD) und AD zusammen verwendet werden. OID speichert die Schemaerweiterungen für EUS, AD die Benutzerkonten und die Authentifizierung über AD, und OVD mischt beide Quellen. Die Oracle Datenbank kann direkt gegen das OVD als LDAP-Server konfiguriert werden. OVD kann auch mehrere Verzeichnisdienste wie etwa AD und einen UNIX-LDAP-Server zusammenfassen und als einen einheitlichen LDAP-Baum darstellen, so dass sich Benutzer an einer Datenbank anmelden können, die entweder im LDAP oder im AD registriert sind.

Das grundsätzliche Problem bei diesen Ansätzen ist, das Oracle und Windows (Active Directory) unterschiedliche Hash-Algorithmen verwenden, und das diese nicht ineinander umgerechnet werden können, ohne das Klartext-Passwort zu kennen. Für die Integration ist es also notwendig, neben dem AD-Hash den Hash für Oracle zu speichern und vor allem bei jeder Passwort-Änderung im AD zu pflegen. Moderne Domänencontroller auf Windows Server 2008-Basis verwenden AES-Keys, erzeugen aber in der Regel auch ältere NTLM-Hashes. Ein AD-Controller erlaubt normalerweise nur internen, schreibenden Zugriff auf Passwort-Hashes, daher wird der Austausch mit Oracle-Tools innerhalb der AD-Welt in der Regel als kritisch angesehen, zumal die AD-Hashes ebenfalls nicht mit einem Salt versehen sind. Microsoft wird spätestens nach dem Bekanntwerden verschiedener Angriffsvektoren voraussichtlich NTLM ganz durch Kerberos ersetzen.

Auch die Verwendung von Kerberos ist für das Datenbank-Login möglich. Dies setzt allerdings voraus, das der Anwender bereits einen Kerberos Token erhalten hat, bevor er sich an der Datenbank anmeldet. Dementsprechend erfordert diese Lösung Windows Clients in einer AD-Domäne, oder vollständig mit Kerberos gegen den AD-Controller konfigurierte Linux-Workstations. Die EUS Metadaten werden hier in einem OUD oder einem OID mit OVD gespeichert. Eine Installation von Zusatz-Komponenten auf den AD Controllern entfällt. Die Konfiguration von Kerberos, insbesondere in einer heterogenen Umgebung, die auch Linux als Betriebssystem für Datenbanken und Client-PCs vorsieht, ist allerdings nicht ganz trivial. In einer Windows-Umgebung lässt sich mit Kerberos allerdings eine echt Single-Sign-On-Umgebung einrichten, in der es einem in Windows angemeldeten Anwender möglich ist, sich an der Datenbank anzumelden, ohne überhaupt ein Passwort einzugeben.

Für die Verbindung mit dem OUD wird im AD neben einem Test-Benutzeraccount ein Host-Account für den Datenbank-Server benötigt. Als “Vorname” sollte hier der FQDN-Servername des Datenbank-Servers eingetragen und das Password-Expiration-Flag sollte nicht gesetzt werden. Im nächsten Schritt muss auf dem AD-Server ein Host-Key für den Datenbankserver extrahiert werden. Dies geschieht mit:

ktpass.exe -princ oracle/db12c.loopback.org@PKILAB -mapuser PKILAB\db12c.loopback.org -crypto all -pass XXX -out c:\TEMP\keytab

Die erzeugte Datei muss auf den Datenbankserver kopiert werden.

Auf dem OUD-Server muss nun das Proxy Setup ausgeführt werden:

$MW_HOME/Oracle_OUD1/oud-proxy-setup

SSL sollte im Konfigurationsdialog stets eingeschaltet werden. Die weitere Konfiguration geschieht über:

• Configure EUS
• Backend Server Type: Microsoft Active Directory
• AD server instance eintragen
• Naming Context eintragen

Anschliessend muss die Abschlusskonfiguration mittels des Tools “dsconfig” im OUD-bin-Verzeichnis erfolgen:

dsconfig set-workflow-element-prop 
--element-name proxy-we1 
--set remote-root-dn:CN=Administrator,CN=Users,DC=pkilab,DC=loopback,DC=org
--set remote-root-password:XXX 
--hostname localhost 
--port 6444 
--trustAll 
--bindDN cn=Directory\ Manager 
--bindPasswordFile pwd.txt 
--no-prompt

dsconfig set-workflow-element-prop 
--element-name proxy-we1 
--add exclude-list:cn=directory\ manager 
--add exclude-list:cn=oraclecontext,dc=pkilab,dc=loopback,dc=org 
--set remote-ldap-server-bind-dn:CN=Administrator,CN=Users,DC=pkilab,DC=loopback,DC=org
--set remote-ldap-server-bind-password:XXX 
--hostname localhost 
--port 6444 
--trustAll 
--bindDN cn=directory\ manager 
--bindPasswordFile pwd.txt 
--no-prompt

Und es sind noch einige Änderungen am im OUD vorhandenen Schema nötig. Die Vorlage hierfür befindet sich bereits in der Datei “$MW_HOME/Oracle_OUD1/config/EUS/modifyRealm.ldif”. Es müssen hier der Naming Context angepasst werden (in unserem Beispiel dc=pkilab,dc=loopback,dc=org) sowie die Namen der Elemente “ou=people” und “ou=groups” mit denen aus dem Active Directory ersetzt werden. Dann können diese Änderungen eingepflegt werden:

ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file -f modifyRealm.ldif

Anschließend kann der Datenbank-Server für Kerberos eingerichtet werden. In der Datenbank muss der Parameter OS_AUTH_PREFIX gelöscht werden. Dann wird SQLNet für Kerberos eingerichtet:

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /app/db1
SQLNET.KERBEROS5_KEYTAB=/app/kerberos/keytab
SQLNET.KERBEROS5_CONF=/app/kerberos/krb5.conf
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

Die angesprochene Datei krb5.conf muss erstellt werden:

[libdefaults]
default_realm = PKILAB
[realms]
PKILAB = {
kdc = ad.pkilab:88
}
[domain_realm]
.pkilab = PKILAB
pkilab = PKILAB

Nun wird der Network Konfiguration Assistant verwendet und die Verzeichnis-Anbindung wird konfiguriert:

• Directory Usage Configuration
• Directory Type OID
• Hostname, Port and SSL Port des OUD Servers
• Oracle Context auswählen

Hierbei wird folgende “ldap.ora”-Datei erzeugt:

DIRECTORY_SERVERS= (oud.pkilab.loopback.org:4389:4636)
DEFAULT_ADMIN_CONTEXT = "dc=loopback,dc=org"
DIRECTORY_SERVER_TYPE = OID

Auf dem Client müssen ebenfalls die Dateien sqlnet.ora und krb5.conf wie oben beschrieben modifiziert werden. Die weitere Konfiguration von EUS entspricht der bei direkter LDAP-Anbindung (siehe oben). Die gesamte Installation ist sehr gut von Carsten Mützlitz beschrieben.

Authentifizierung mit PKI

Die Authentifikation über LDAP hat den Nachteil, das jeder Anwender zwar nur noch ein Passwort hat, dieses auch an einer zentralen Stelle verwaltet wird, aber eben immer noch eingegeben werden muss. Eine ganz andere, wenn auch ergänzend einsetzbare Möglichkeit, Authentifizierung aus der Datenbank selbst auszulagern, besteht in der Nutzung einer Public Key Infrastruktur (PKI). Hierfür müssen Benutzerzertifikate erstellt und verteilt werden, die von einer zentrale Autorität als gültig erklärt und signiert worden sind. Diese Methode hat den Vorteil, dass die Authentifizierung den Besitz des Zertifikates erfordert. Zusammen mit einem Mechanismus, der das Zertifikat mit einer PIN oder einem Passwort sichert, wird also immer eine Zwei-Faktor-Authentifizierung implementiert. In Unternehmen werden die Benutzerzertifikate oft auf SmartCards ausgebracht, die gleichzeitig den Mitarbeiterausweis, die Zugangskontrolle oder ein Bezahlsystem beinhalten können. Es ist aber auch möglich, die Zertifikate mit dem Desktop-Betriebssystem auf den Arbeitsplatzrechnern zu installieren oder im verwendeten Web-Browser bzw. einer beliebigen geeigneten Anwendung zu hinterlegen. Hier eröffnet sich auch ein Lösungsansatz für das Problem der maschinellen bzw. Skript-gesteuerten Datenbank-Anmeldung.

PKI Architektur

Eine Public Key Infrastructure (PKI) regelt die Verteilung von Vertrauen in einer Organisation. Eine zentrale Stelle, die sogenannte Certification Authority (CA), beglaubigt die Identitäten von Mitarbeitern, Maschinen oder auch Authentizität von Dokumenten, indem sie diese unterschreibt (signiert). Die CA besteht aus einem Handling-Mechanismus beziehungsweise damit betrauten Mitarbeitern sowie einem öffentlichen Wurzel-Zertifikat und einem geheimen Schlüssel. Mit diesem Schlüssel signiert sie die Zertifikate der zu beglaubigenden Dokumente. Mit Hilfe des öffentlichen Wurzelzertifikates (Root-CA Zertifikat) kann die Echtheit der Unterzertifikate von allen beteiligten Parteien geprüft und bestätigt werden. Ihre Autorität kann die CA auch delegieren, um zum Beispiel das Ausstellen von Zertifikaten für einen Unterbereich der Organisation von einer untergeordneten CA durchführen zu lassen. Hierzu erhält diese Sub-CA ein Zwischenzertifikat der Root-CA.

Dieser Mechanismus ist durch SSL bekannt und wird weltweit als Standard für die allgemeine Authentizitätsprüfung von Webseiten und Emails verwendet. Hier ist allerdings das Problem, das es keine weltweit anerkannte Instanz gibt, die überhaupt genügend allgemeines Vertrauen besitzt, um die Identität der beteiligten Parteien glaubhaft zu bestätigen. Der Aufbau des Internet sieht keine Legitimation im Rahmen von beispielsweise Domain-Vergabe (NIC) oder Domain Name System (DNS) vor. Es gibt daher in Desktop-Betriebssystemen und Web-Browsern eine stattliche Liste von staatlichen oder auch privaten CAs, denen diese vertrauen. Wie die Praxis gezeigt hat, ist dieses Vertrauen oft nicht berechtigt gewesen, daher ist das ganze System von SSL-Zertifikaten öffentlich in Verruf geraten und in weiten Teilen nutzlos geworden.

In Unternehmen und Organisationen mit geregeltem Aufbau hingegen ist es möglich, eine Stelle zu finden, die als Certification Authority funktionieren und die Identität ihrer Mitarbeiter, Prozesse, Adressen oder Dokumente bestätigen kann. Die Mitarbeiter erhalten ein eigenes Zertifikat, das von der CA unterschrieben wird. Genauer gesagt erstellen sie einen Antrag auf Zertifizierung (Certification Request), der als Datei erstellt wird. Dieser wird von der CA signiert und in Form des individuellen Zertifikates an den Benutzer ausgegeben. In der Regel wird dieser Prozess im Format X.509 implementiert, einem ITU-Standard für eine Public-Key-Infrastruktur zum Erstellen digitaler Zertifikate. X.509 beinhaltet außerdem einen Standard für die Handhabung von widerrufenen Zertifikaten über Rückruflisten (Revocation Lists). X.509-Zertifikate werden verbreitet imPKCS#12-Format als Datei gespeichert oder im PKCS#11-Format auf Token oder Smartcards aufgebracht. Die PKCS-Familie ist ein RSA-Standard und definiert eine Reihe von Methoden für den Umgang mit digitalen Zertifikaten.

Es existieren eine Reihe von Software-Produkten für die Implantation einer PKI. Ebenso ist es möglich, den Prozess mit Hilfe von OpenSSL komplett ohne kommerzielle Software abzubilden. Außerdem existieren mehrere Open Source PKI Lösungen. In vielen Unternehmen wird eine PKI im Zusammenhang mit der Active Directory Administration oder der Ausweisstelle bereits vorhanden sein.

SSL-PKI Anmeldung an der Datenbank mit Wallets

Oracle bietet mit Wallets einen PKCS#12-basierten Container an, in dem SSL-Zertifikate hinterlegt werden können. Hat ein Anwender oder ein Skript Lese-Zugriff auf die Wallet-Datei und gegebenenfalls das Wallet-Passwort, kann er das Zertifikat auslesen und sich damit an der Datenbank anlegen. Eine weitere Passwort-Abfrage ist nicht mehr nötig.

Das Wallet auch direkt zum Ablegen von Passwörtern verwendet werden, dies wird “Secure External Password Store” genannt und ermöglicht es beispielweise Skripten, sich mit der Datenbank zu verbinden, ohne ein Passwort im Klartext enthalten zu müssen. Da dies aber keine zentrale Authentifikation darstellt, soll diese Methode hier nicht weiter beleuchtet werden.

Für eine zertifikatsbasierte Anmeldung muss zunächst auf dem Datenbank-Server ein Wallet angelegt werden:

$ mkdir $ORACLE_BASE/admin/loopds/pki
$ orapki wallet create -wallet $ORACLE_BASE/admin/loopds/pki -auto_login -pwd XXX

Nun muss ein Request erstellt und exportiert werden:

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -dn ‘CN=db12c’ -keysize 2048 -pwd XXX

$ orapki wallet export -wallet $ORACLE_BASE/admin/loopds/pki -dn ‘CN=db12c’ -request ~/db12c.csr

Nach dem Signieren des Requests durch die CA wird das gelieferte User Certificate zusammen mit der Root-CA, dem sogenannten Trusted Certificate, importiert:

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -cert myca.pem –trusted_cert –pwd XXX

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -cert db12c.pem –user_cert –pwd XXX

Als nächstes werden auf dem Datenbank-Client (PC oder Applikationsserver) ebenfalls ein Wallet und ein Request erzeugt und exportiert:

$ orapki wallet create -wallet $ORACLE_HOME/owm/wallets/client -auto_login -pwd XXX

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client -dn ‘CN=jans’ -keysize 2048 -pwd XXX

$ orapki wallet export -wallet $ORACLE_HOME/owm/wallets/client -dn ‘CN=jans’ -request ~/jans.csr

Nachdem die CA den Request signiert hat, können User und Trusted Certificate auch hier importiert werden:

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client \
-cert myca.pem –trusted_cert –pwd XXX

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client \
-cert jans.pem –user_cert –pwd XXX

Der Inhalt des Wallets kann jederzeit angezeigt werden:

[oracle@linux11 ~]$ orapki wallet display -wallet /u01/app/oracle/product/11.2.0/dbhome_1/network/pki
Oracle PKI Tool : Version 11.2.0.3.0 - Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
Requested Certificates:
User Certificates:
Subject:        CN=LOOPDS
Trusted Certificates:
Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        CN=LBO Root Certificate II,OU=LoopCA,O=Loopback.ORG GmbH,O=Loopback.ORG,L=Hamburg,ST=No-State,C=DE
Subject:        OU=Secure Server Certification Authority,O=RSA Data Security\, Inc.,C=US
Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US

Nun muss das Wallet zur Benutzung noch in der TNS-Konfiguration eingetragen werden.

Auf dem Server:

listener.ora:

SSL_CLIENT_AUTHENTICATION = TRUE
WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
 (DIRECTORY = $ORACLE_BASE/admin/loopds/pki)
 )
 )
LISTENER =
 (DESCRIPTION_LIST =
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCP)(HOST = db12c.loopback.org)(PORT = 1521))
 )
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCPS)(HOST = db12c.loopback.org)(PORT = 2484))
 )
 )

sqlnet.ora:

SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)
NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME)
SSL_CLIENT_AUTHENTICATION = TRUE
WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
 (DIRECTORY = $ORACLE_BASE/admin/loopds/pki)
 )
 )

Auf dem Client:

sqlnet.ora:

SQLNET.AUTHENTICATION_SERVICES= (TCPS)
SSL_VERSION = 0
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SSL_SERVER_DN_MATCH = Yes
SSL_CLIENT_AUTHENTICATION = TRUE
WALLET_LOCATION =
 (SOURCE =
 (METHOD = FILE)
 (METHOD_DATA =
 (DIRECTORY = $ORACLE_HOME/owm/wallets/client)
 )
 )

tnsnames.ora:

DB12C =
 (DESCRIPTION =
 (ADDRESS_LIST =
 (ADDRESS = (PROTOCOL = tcps)(HOST = db12c.loopback.org)(PORT = 2484))
 )
 (CONNECT_DATA =
 (SERVER = DEDICATED)
 (SERVICE_NAME = DB12C)
 )
 (SECURITY =
 (SSL_SERVER_CERT_DN="CN=db12c"))
 )

Die Datenbank-Parameter OS_AUTHENT_PREFIX und REMOTE_OS_AUTHENT dürfen auch hier nicht gesetzt sein. Die weitere Konfiguration von EUS erfolgt ähnlich wie oben beschrieben:

SQL> create user JANS identified externally as 'CN=jans';
SQL> grant create session to JANS;
SQL> alter user JANS identified externally as 'CN=jans';

Nun kann sich der User, der Zugriff auf das oben angelegte Client Wallet besitzt, direkt anmelden:

$ sqlplus /@DB12C
Connected.
SQL>

Mit SYS_CONTEXT kann im User Environment nachgesehen werden, ob die aktuelle Anmeldung a) SSL-transportverschlüsselt (“tcps”) und b) über ein PKI-Zertifikat (“SSL”) statt eines Passwortes (“PASSWORD”) erfolgt ist:

$ sqlplus user/pwd@DB12C
Connected.
SQL> select sys_context('USERENV', 'NETWORK_PROTOCOL') from dual;
SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
------------------------------------------------------------------------
tcps
SQL> select sys_context('USERENV', 'AUTHENTICATION_METHOD') from dual;
SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD')
------------------------------------------------------------------------
PASSWORD
$ sqlplus /@DB12C
Connected.
SQL> select sys_context('USERENV', 'AUTHENTICATION_METHOD') from dual;
SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD')
-----------------------------------------------------
SSL

Die Verbindung zur Datenbank kann mit sqlplus, OCI oder JDBC erfolgen. JDBC wird wie folgt konfiguriert:

String url = "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)
(HOST=servernam e)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=servicename)))");
 Properties props = new Properties();
 props.setProperty("user", "scott");
 props.setProperty("password", "tiger"); props.setProperty("javax.net.ssl.trustStore",
"/truststore/ewallet.p12"); props.setProperty("javax.net.ssl.trustStoreType","PKCS12");
props.setProperty("javax.net.ssl.trustStorePassword","welcome123"); Connection conn = DriverManager.getConnection(url, props);

Die Konfiguration des SQL Developer mit SSL-Wallets ist in MOS Note: 401251 beschrieben.

Datenbanklogin mit Smartcard

Die bereits oben verwendeten X.509-Zertifikate können statt in der Oracle Wallet Datei auch auf einer Smartcard abgelegt werden. Hier werden zwei Vorteile kombiniert: Das Zertifikat kann nicht mehr einfach kopiert werden und es wird eine Hardware-Authentication realisiert. Das auf der Karte gespeicherte Zertifikat muss im weiteren Betrieb die Karte nicht mehr zu verlassen und kann nicht mehr mit Betriebssystem-Mitteln auf dem Client kopiert werden. Viren oder Trojaner können es nicht mehr stehlen oder missbräuchlich verwenden. Der Benutzer ist als Besitzer der Karte identifiziert. Wird die Karte gezogen, kann auch das Zertifikat nicht mehr verwendet werden.

Voraussetzung für den Einsatz von Smartcards ist neben einer existierenden PKI das Vorhandensein geeigneter Hardware (Smartcard-Reader) und Software. In der Regel ist ein Hardware-Treiber für das Lesegerät erforderlich, sowie eine sogenannte Middleware, welche die Kommunikation zwischen Karte und dem Oracle Client über das PKCS#11-Protokoll implementiert. Des Weiteren natürlich die Karten selbst. Sie müssen in der Lage sein, X.509-Zertifikate zu speichern.

Konfiguration der Clients

Nach dem Initialisieren der Karte wird ein Oracle Wallet angelegt oder ein bestehendes erweitert. Es wird nun ein Dummy-Eintrag erstellt, der auf die Karte verweist:

orapki wallet p11_add -wallet . -p11_lib "c:\Windows\System32\opensc-pkcs11.dll" -pwd Oracle1234

Die restliche Konfiguration von SSL und EUS erfolgt wie oben beschrieben. Danach kann sich auch hier direkt an der Datenbank angemeldet werden.

sqlplus /@db12c

Das Smartcard-Wallet lässt sich überprüfen:

orapki wallet p11_verify -wallet . pkcs11_wallet -pwd Oracle1234
Oracle PKI Tool : Version 11.2.0.4.0 – Production
Number of certificates found on token = 1
Cert with subject name:
   CN=Stapff Pablo has a matching private key on token.
Cert with subject name:
   CN=Stapff Pablo installed as user cert in wallet.

Fazit

Eine eindeutige Identifikation von Personen und Zugriffsrechten ist am Besten über ein zentrales Verzeichnis oder eine PKI-CA möglich, an die sämtliche Systeme angeschlossen sind. Applikatorische Insellösungen und Mehrfachidentitäten stellen eine erhebliche Gefahrenquelle für die Daten- und Systemsicherheit dar.

Oracle Datenbanken lassen sich bereits mit überschaubarem Aufwand in ein LDAP oder AD-Verzeichnis integrieren. Der Aufwand hierfür kann sich gegenüber der manuellen Verwaltung von Datenbankbenutzern bereits nach kurzer Zeit rentieren, Lizenzkosten bei der Verwendung von Verzeichnissen müssen allerdings berücksichtigt werden. Die Ablösung von Passwörtern für technische Benutzer ist in vielen Fällen mit SSL-Wallets möglich.

Eher Projektcharakter haben komplexere Lösungen mit mehreren Verzeichnissen oder Smartcards.

---

Dieser Artikel erschien zuvor als Vortrag auf der DOAG Konferenz 2015.