• Sie haben „Bauchschmerzen“ damit, Passworte für Datenbankaccounts im Klartext in Scripts, Konfigurationsfiles usw. abzulegen.
• Sie benutzen grafische SQL-Frontends, die Passworte der eingerichteten Connections speichern wollen, misstrauen aber der Sicherheit der Passwortablage.
• Sie möchten oder können nicht den Aufwand einer Anbindung an ein zentrales Benutzermanagement treiben, möchten aber trotzdem Passworte in gewissem Maße zentralisiert ablegen und verwalten.
• Um die Passworte regelmäßig zu ändern, können Sie kurze Downtimes in Kauf nehmen.

Die Authentisierung über SEPS erfolgt unverändert mit Username und Passwort. Allerdings werden diese Credentials in ein Oracle Wallet eingeschlossen und sind somit nicht mehr im Klartext sichtbar.

1. Der Client fordert anhand des Connectdescriptors (=Schlüsselkriterium im Password Store) die Credentials aus dem Wallet an.
2. Der Client authentisiert sich mit dem aus dem Wallet erhaltenen Username und Passwort bei der Datenbank.
3. Sind die Credentials korrekt, wird eine Verbindung zwischen Client und Datenbank für den übermittelten User aufgebaut

• Passworte sind nicht mehr im Klartext sichtbar. Sie sind somit weder auf dem System direkt, noch in Backups des Systems sichtbar.
• Es ist keine Anpassung innerhalb der Datenbank oder an der Datenbankkonfiguration erforderlich.
• Wallets können zentral abgelegt und damit von mehreren Systemen genutzt werden.

Besonders gut geeignet für

• Skripts, die Benutzername/Passwort für eine Anmeldung an der Datenbank benötigen (Backup, Export/Import, Duplicate, wiederkehrende Tasks etc)
• vorübergehende Bereitstellung von Datenbankzugriffen, z.B. an Dienstleister, ohne Offenlegung der Passworte
• Credentials, die an vielen Stellen hinterlegt sind aber zentral gewartet werden sollen, ohne den Mehraufwand für die Anbindung an spezielle Authentication Services zu betreiben

• Die Passwortpolicy muss weiterhin in jeder Datenbank einzeln konfiguriert und von jeder Datenbank einzeln durchgesetzt werden.
• Passworte müssen in der Datenbank und im Wallet geändert werden. In der Zeit, bis beide Passworte (in der Datenbank und dem Wallet) geändert sind, kann das Wallet nicht genutzt werden. Passwortänderung erfordert also unter Umständen eine Downtime. Das wäre aber bei Verwendung von Klartextpassworten ebenso.
• Wer in den Besitz des Wallets gelangt, die Credential-Indexes kennt und, bei Verwendung von Net Service Names, die richtigen Connectinformationen rekonstruieren kann, hat Zugang zur Datenbank.
• Es handelt sich um ein reines Authentisierungsverfahren. Der Netzverkehr wird per se nicht verschlüsselt. Hierfür müssen zusätzlich andere Technologien zur Anwendung kommen, zum Beispiel das ebenfalls kostenfrei nutzbare „Transparent Network Encryption“.

Weniger gut geeignet für

• Accounts, die in dauerhaftem Zugriff sind (z.B. technische Accounts, die durch Application Server genutzt werden)
• Durchsetzung zentraler Passwortrichtlinien

Der Aufwand für die Einführung von SEPS ist minimal. Er beschränkt sich auf das Anlegen und Füllen des Wallets und einige wenige Anpassungen in sqlnet.ora und tnsnames.ora des Clients. Bei Nutzung von OCI oder JDBC, und unter Umständen ODBC, müssen die Datenbankconnects im Anwendungscode angepasst werden.

Personen, die Zugang zum betreffenden System, Kopien oder Backups des Systems haben, gelangen nicht mehr in Besitz von Accountpassworten. Die erfolgreiche Kompromittierung der Datenbank mittels gestohlenem Wallet erfordert Kenntnisse über die Ablage der Credentials im Wallet. Grundsätzlich kann das Wallet auch aus dem Backup ausgeschlossen werden, da es sich im Zweifel nach Verlust vergleichsweise schnell neu erstellen lässt.

• Sie müssen Account Policies im Hinblick auf Passwortstärke und -änderungszyklen auch für Datenbankaccounts durchsetzen, möchten Policies aber nicht redundant pflegen.
• Sie sind nicht in der Lage, die Account Policies vollumfänglich in einer Oracle Datenbank abzubilden.
• Sie müssen sicherstellen, dass das Sperren von Accounts zuverlässig – möglichst automatisch – auch in die Datenbanken des Unternehmens provisioniert wird.
• Sie schätzen die erfolgreiche Anmeldung an einer Windows Domäne als ausreichend sichere Authentisierung ein, um damit auch den Zugang zu einer Datenbank zu gewähren.

Die Authentisierung des Datenbankbenutzers wird nicht in der Datenbank selbst vorgenommen. Anstelle dessen wird der Datenbankbenutzer mit einem Directoryaccount verknüpft und die Authentisierung an einen Kerberosdienst delegiert, z.B. Active Directory, Novell eDirectory oder Linux Kerberos 5. Die Anmeldung an der Datenbank erfolgt damit letztlich über den Besitz eines gültigen Kerberos Tickets und nicht über die Überprüfung eines Kennwortes.

1. Der Client bezieht ein auf sein Principal ausgestelltes Ticket Granting Ticket (TGT) beim Kerberos Server. Erfolgt die Betriebssystemanmeldung bereits über Kerberos, liegt dieses Ticket in aller Regel nach der Anmeldung am Client schon vor. Das TGT hat typischerweise eine Gültigkeit von mehreren Stunden, es wird also nicht bei jedem Connect angefordert.
2. Der Client verbindet sich zum Datenbankserver und fordert von diesem den SQLNET.AUTHENTICATION_KERBEROS5_SERVICE an.
3. Der Client fordert mit seinem TGT ein Service Ticket für den Service Principal aus SQLNET.AUTHENTICATION_KERBEROS5_SERVICE an.
4. Der Client sendet das Service Ticket an den Datenbankserver.
5. Der Datenbankserver validiert das Service Ticket und ermittelt aus seiner internen Nutzerverwaltung den Datenbankaccount, der mit dem  Ticket verknüpft ist. Anschließend erstellt er eine Datenbanksitzung zwischen Client und Server für diesen Benutzer.

• Account Policies müssen nicht zusätzlich in der Datenbank abgebildet werden. Es werden implizit die Policies eines zentralen Verzeichnisdienstes genutzt.
• Das Account Management erfolgt zentralisiert. Insbesondere das Sperren und Löschen von Benutzern im Verzeichnisdienst wird zuverlässig auch in die Datenbanken provisioniert. Da für jeden Connect ein neues Service Ticket angefordert wird, wirkt eine Accountsperrung/-Löschung sofort und es werden keine neuen Verbindungen zur Datenbank mehr gestattet.
• Eine Downtime wegen einer Passwortänderung kann in der Regel vermieden werden, da das neue Passwort erst für die Erneuerung des TGT benötigt wird.

Besonders gut geeignet für

• personifizierte Accounts, die den Policies des Unternehmens unterliegen
• technische Accounts, für die aus Sicherheits- oder Verfügbarkeitsgründen SEPS nicht infrage kommt
• Accounts, die in dauerhaftem Zugriff sind (z.B. technische Accounts, die durch Application Server genutzt werden)

• Der erfolgreiche Zugang zur Datenbank ist an die Verfügbarkeit des Kerberos Dienstes gebunden.
• Sowohl die Datenbankkonfiguration als auch die Benutzerverwaltung innerhalb der Datenbank müssen modifiziert werden.
• Technische Accounts müssen in aller Regel unabhängig von einer expliziten Anmeldung an einer Domäne o.ä. funktionieren. Es kann dafür also nicht auf eine Passwortauthentisierung für den Bezug eines Kerberos Tickets zurückgegriffen werden. Anstelle dessen muss auf dem Client eine Kerberos Keytab abgelegt werden, die wiederum gut gegen Fremdzugriff geschützt werden muss.
• Es handelt sich um ein reines Authentisierungsverfahren. Der Netzverkehr wird per se nicht verschlüsselt. Hierfür müssen zusätzlich andere Technologien zur Anwendung kommen, zum Beispiel das ebenfalls kostenfrei nutzbare „Transparent Network Encryption“.

Weniger gut geeignet für

• Accounts, die zwingend verfügbar bleiben müssen, auch wenn die Verfügbarkeit des Kerberos Dienstes gestört ist.

Der Aufwand für die Umstellung auf Kerberos-basierte Authentisierung ist höher als für SEPS, allerdings durchaus noch überschaubar. Muss – insbesondere für technische Accounts – auf Keytabs zurückgegriffen werden, kann der Aufwand für Rollout und Pflege dieser Keytabs abhängig von der Häufigkeit der Passwortänderung signifikant steigen, sofern die Keytabs nicht sicher zentral abgelegt werden können. In jedem Fall sind Konfigurationsarbeiten am Kerberos Server, an den Datenbankservern und an den Clients erforderlich.

Es entfällt die Notwendigkeit, zusätzlich zur Domänenanmeldung Passworte für die Datenbankanmeldungen vergeben zu müssen. Damit wird für diesen Teil der Unternehmenssicherheit die Gefahr ausgeräumt, dass aus „Bequemlichkeit“ unsichere Passworte verwendet oder Passworte notiert werden. Die im Verzeichnisdienst implementierten Policies gelten implizit auch für die Datenbanken. Technische Accounts profitieren von Kerberos, da ihre Credentials nicht mehr in Skripts oder SEPS-Wallets hinterlegt werden müssen. Die anstelle dessen verwendeten Keytabs sind zwar sicherheitskritisch, müssen aber z.B. nicht zwingend ins Backup eingebunden werden und gelangen somit nicht auf „externe“ Medien.

• Sie möchten sich über Account Policies im Hinblick auf Passwortstärke und -änderungszyklen für technische Datenbankaccounts keine Gedanken machen.
• Sie müssen sicherstellen, dass das Sperren von technischen Accounts zuverlässig – möglichst automatisch – auch in die Datenbanken des Unternehmens provisioniert wird.
• Sie haben Authentisierungsdaten auf mehreren Mid-Tier-Servern abgelegt. Eine gleichzeitige, unterbrechungsfreie Änderung ist bisher nicht möglich; das sukzessive Ändern würde zu einer längeren Downtime einzelner oder aller Mid-Tier-Server führen.

Die Authentisierung des Datenbankbenutzers wird nicht in der Datenbank selbst vorgenommen. Statt dessen werden sowohl für Datenbankserver als auch Datenbankclient SSL-Zertifikate von einer den beiden bekannten CA, zum Beispiel einer Unternehmens-CA ausgegeben. Clients, die Zertifikate einer CA vorlegen, die auch vom Server als vertrauenswürdig eingestuft ist, erhalten Zugriff auf die Datenbank.

1. Sowohl für Server als auch Client werden Zertifikate erstellt, die von einer von beiden als vertrauenswürdig eingestufen CA signiert werden. Ein Zertifikat einer zentralen Unternehmens-CA ist vollkommen ausreichend. Auch eine separat für diesen Zweck erstellte CA tut ihren Dienst vollkommen. Die hierzu erforderlichen Tools sind Bestandteil der Oracle-Serversoftware. Es muss also auf keinen Fall ein teures Zertifikat von einer offiziellen CA bezogen werden.
2. Der Oracle-Datenbankaccount wird dann innerhalb der Datenbank mit dem Distinguished Name (DN) des Client-Zertifikats verknüpft. Der Client legt dieses Zertifikat später beim Login dem Datenbankserver vor.
3. Optional kann der Client vom Server ein Zertifikat anfordern, mit dem der Server nachweist, dass er den offerierten SERVICE_NAME anbieten darf. Ein Server kann so nicht mit einem anders lautenden Zertifikat ein Fake-Identität bzgl des angebotenen Services annehmen.
4. Legen sowohl Client als auch Server ein gültiges Zertifikat vor und beide wurden (direkt oder über eine Trust Chain) von der selben CA signiert, wird dem Client der Zugriff auf die Datenbank gewährt.

Wertvoller Seiteneffekt dieser Authentisierungsvariante ist, dass auch der gesamte nachfolgende Netzverkehr zwischen Client und Server – nicht nur das Login - SSL-verschlüsselt bleibt.

• Da keine Passworte mehr für die Authentisierung benutzt werden, sind sämtliche Passwortrichtlinien obsolet. Zertifikate können nichts desto trotz regelmäßig erneuert werden.
• Da SSL komplett auf Kennworte verzichtet, sind für technische Accounts - anders als bei Kerberos - keine Keytabs erforderlich.
• Die Authentisierung ist im Gegensatz zu Kerberos nicht von einer weiteren Infrastruktur abhängig und damit weniger störanfällig.
• Implementiert man zusätzlich eine zentrale Certificate Revocation List und macht man sich die Mühe, für jeden Client ein eigenes Zertifikat auszustellen, kann zudem bei Diebstahl, Missbrauchsverdacht oder anderem wichtigen Grund ein einzelnes Zertifikat auch jederzeit für ungültig erklärt werden.
• Der Austausch eines ablaufenden Zertifikates kann komplett ohne Downtime erfolgen. Das neue Zertifikat wird in einem separaten Wallet vorbereitet und das alte Wallet dann durch das neue ersetzt. Es besteht – im Gegensatz zum Austauschen von Passworten – keine Notwendigkeit, die Zertifikate auf allen Clients gleichzeitig auszutauschen. Alte und neue Zertifikaten können vielmehr nebeneinander verwendet werden. Es muss lediglich organisatorisch sichergestellt werden, dass alle Zertifikate vor Ablauf ihrer Gültigkeit ersetzt werden.
• Der Netzverkehr erfolgt auch nach dem Login weiter SSL-verschlüsselt.

Besonders gut geeignet für

• Umgebungen mit hohen Sicherheitsanforderungen, in denen unbefugte Clientzugriffe nicht durch Netzwerkmitteln (Firewall, Listener-Regeln etc) durchgesetzt werden können
• Umgebungen, in denen die Vorteile einer zentralen Authentisierung genutzt werden sollen, in denen aber keine Kerberos—Infrastruktur verfüg- oder zuverlässig nutzbar ist
• Freigabe oder Sperrung von Clients auf Gerätebasis statt auf Basis bestimmter Accounts
• technische Accounts, für die aus Sicherheits- oder Verfügbarkeitsgründen SEPS nicht infrage kommt
• Accounts, die in dauerhaftem Zugriff sind (z.B. technische Accounts, die durch Application Server genutzt werden)

• Der Verwaltungs- und Rollout-Aufwand ist vergleichsweise hoch. Des weiteren muss für jeden Datenbankaccount ein eigenes Wallet verwaltet werden. Es können nicht die Zertifikate für mehrere Accounts in ein und dem selben Wallet zusammengefasst werden. SSL-Authentisierung eignet sich daher meist weniger gut für Umgebungen mit vielen Clients oder zahlreichen Accounts, sondern eher für Mid-Tier-Server in 3-Tier-Umgebungen.
• Sowohl die Datenbankkonfiguration als auch die Benutzerverwaltung innerhalb der Datenbank müssen modifiziert werden.
• Da der Zugang einzig und allein auf Basis des Besitzes eines bestimmten Zertifikates erfolgt, ist selbiges sehr anfällig für Diebstahl und Missbrauch. Aus technischen Gründen werden die Zertifikate zudem in auto-login-Wallets abgelegt. Das heißt, sie können ohne Kenntnis des Wallet-Passwortes benutzt werden. Zertifikate sollten deshalb nie in Backups eingebunden werden, bzw. sollte wenigstens das Passwortfile cwallet.sso ausgeklammert werden. Ein rudimentärer Schutz gegen den Missbrauch gestohlener Wallets ist mit dem auto-login-local Wallet gegeben. Da dieser aber auf recht simpel manipulierbaren Umgebungsinformationen beruht, bietet das eher trügerische Sicherheit.

Weniger gut geeignet für

• Umgebungen mit vielen Clients oder vielen Accounts

Der Aufwand für SSL-basierte Authentisierung ist vergleichsweise hoch. Neben der Bereitstellung einer CA sind für jeden Client Zertifikatsrequests zu erzeugen, Zertifikate auszustellen und letztendlich am Client bereitzustellen. Setzt man konsequenterweise Certificate Revocation Lists ein, müssen zudem die Seriennummern der ausgestellten Zertifikate dokumentiert werden, um einen gezielten Rückruf eines bestimmten Zertifikates zu ermöglichen. Darüber hinaus muss penibel auf die Ablauffristen aller Zertifikate geachtet werden, um den ununterbrochenen Zugriff durch die Clients zu gewährleisten.

Das leidige Thema sicherer Passworte wird, sieht man vom Walletpasswort ab, bei Nutzung von SSL-Authentisierung komplett eliminiert. SSL-Zertifikate können aktuell mit bis zu 4096bit verschlüsselt werden und sind somit ausreichend sicher. Darüber hinaus werden der Netzverkehr zwischen Client und Server auch nach erfolgter Authentisierung weiterhin SSL-verschlüsselt.

Eine optionale Überprüfung des Serverzertifikates durch den Client stellt zudem sicher, dass ein von einem bestimmten Server angebotener SERVICE_NAME auch durch ein Zertifikat gedeckt ist. Das erschwert das Abgreifen von Clientsitzungen durch Fake-Server.

Da Zertifikate unterbrechungsfrei und innerhalb ihrer Gültigkeitsdauer jederzeit und ohne Downtime ausgetauscht werden können, ist die Hemmschwelle für ihren Einsatz im Vergleich zu SEPS oder Kerberos geringer.

Unter Berücksichtigung des breiten Spektrums an Strong Authentication Mechanismen in der Oracle Datenbank Software und der Tatsache, das selbige komplett kostenfrei als Bestandteil aller Datenbankeditionen verfügbar sind, sollte keine Ausrede mehr für die Verwendung unsicherer Passworte bzw deren Ablage im Klartext in Configfiles oder im Programmcode erlauben.

In Fällen, in denen Anpassungen im Programmcode notwendig sind, um Strong Authentication einsetzen zu können, gehen Sie auf Ihre Anwendungshersteller zu und fordern Sie die zusätzliche Sicherheit aktiv ein.

In den übrigen Fällen stehen wir Ihnen bei der Planung, Umsetzung und Pflege Ihrer Authentisierungs-Infrastruktur gern zur Seite.