Oracle Strong Authentication
Die Seite gibt einen Überblick über ausgewählte kostenfreie Features, die vormals Bestandteil der Advanced Security Option für Enterprise Edition waren.
Die Seite gibt einen Überblick über ausgewählte kostenfreie Features, die vormals Bestandteil der Advanced Security Option für Enterprise Edition waren.
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.
Besonders gut geeignet für
Weniger gut geeignet für
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.
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.
Besonders gut geeignet für
Weniger gut geeignet für
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.
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.
Wertvoller Seiteneffekt dieser Authentisierungsvariante ist, dass auch der gesamte nachfolgende Netzverkehr zwischen Client und Server – nicht nur das Login - SSL-verschlüsselt bleibt.
Besonders gut geeignet für
Weniger gut geeignet für
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.