News
DBA-Tipp: Proxy Authentication – Database Links von Passwortänderungen entkoppelt

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

Datenbank Links sind aus DBA-Sicht ein hervorragendes Werkzeug, wenn es darum geht, aus einer Oracle Datenbank direkt auf Daten in einer anderen Oracle-Datenbank zuzugreifen. Aus technischer Sicht ist ein Zugriff über einen Datenbank Link nichts anderes als eine Client-Server-Sitzung, in der die entfernte Datenbank den Server darstellt und die Datenbank, in welcher der Link definiert ist, als Client fungiert. Folglich muss in der Definition des Datenbank Links hinterlegt sein, mit welchen Credentials sich der Link an der entfernten Datenbank anmeldet. Folglich sind sie dem Sicherheitsbeauftragten regelmäßig ein Dorn im Auge.

Man unterscheidet folgende zwei Typen von Datenbank Links:

fixed user database link: Die Accountdaten (Username, Passwort) für die Anmeldung an der entfernten Datenbank sind in der Linkdefinition abgelegt.

connected user database link: Mit den Credentials des lokal angemeldeten Users wird eine Verbindung zum gleichnamigen User auf der entfernten Datenbank hergestellt. Der Benutzer auf der lokalen Datenbank muss folglich mit gleichem Namen und Passwort auch in der entfernten Datenbank existieren.

Beiden Linktypen ist ein erhebliches Problem gemeinsam. Wird das Kennwort des Linkziels auf der entfernten Seite geändert, muss auch das Kennwort auf der lokalen Seite geändert werden. Andernfalls ist keine Verbindung mehr über diesen Datenbank Link möglich. Erschwerend kommt der Umstand hinzu, dass Kennworte in fixed user database links nicht geändert werden können. Solche Links müssen gelöscht und mit geändertem Kennwort neu angelegt werden. Nicht selten stehen dem Verfügbarkeitsanforderungen entgegen. Aufgrund der erheblichen Restriktionen wird das Kennwort der Link-Benutzer in der Praxis zu selten, zuweilen auch gar nicht geändert. Daraus kann ein erhebliches Sicherheitsproblem resultieren, da insbesondere der Account auf der entfernten Seite tatsächlich Zugriff auf, unter Umständen sensible, Datenbankobjekte hat und damit eigentlich ein typischer Kandidat für sehr restriktive Passwort-Policies und häufigen Passwortwechsel sein müsste.

Das geschilderte Problem lässt sich durch Einsatz der Proxy Authentication umgehen. Kernpunkt dieses Konzeptes ist es, dass sich ein Benutzer nicht mehr mit seinen eigenen Credentials bei einer Datenbank anmeldet, sondern dafür die Credentials eines anderen Accounts mit nur minimalen Privilegien nutzt.

Wie kann uns dieser Mechanismus nun helfen, den Wartungsaufwand für Datenbank Links zu reduzieren und sie so ein wenig sicherer zu machen?

Ein Beispiel: Wir benötigen im Schema XY einer lokalen Datenbank Zugriff auf das OE-Schema einer entfernten Datenbank. Die herkömmliche Verfahrensweise wäre, einen fixed user database link im XY-Schema anzulegen, der die OE-Credentials der entfernten Datenbank abspeichert.

SQL local-db> CREATE DATABASE LINK remote_oe CONNECT TO oe IDENTIFIED BY "volatile_password" USING 'remote_db';

Database link created.

SQL local-db> SELECT SUM(order_total) FROM orders@remote_oe;

SUM(ORDER_TOTAL)
----------------
       3668054.7

Wird auf der entfernten Datenbank das Kennwort des OE-Users geändert, ist der Link allerdings nicht mehr verwendbar, müsste gelöscht und mit dem neuen Kennwort neu angelegt werden.

SQL remote-db> ALTER USER oe IDENTIFIED BY "a_new_password";

User altered.

SQL remote-db>


SQL local-db> SELECT SUM(order_total) FROM orders@remote_oe;
SELECT SUM(ORDER_TOTAL) FROM ORDERS@REMOTE_OE
                                    *
ERROR at line 1:
ORA-01017: invalid username/password; logon denied
ORA-02063: preceding line from REMOTE_OE

SQL local-db>

Anders sieht die Verfahrensweise bei Verwendung der Proxy Authentication aus. Man erstellt auf der Remote-Datenbank einen Proxy User mit einem hinreichend sicheren Passwort und weist ihm lediglich die CONNECT-Rolle zu. Mehr Rechte benötigt ein Proxy User nicht.

SQL remote-db> CREATE USER proxy_user IDENTIFIED BY "very_secure_password";

User created.

SQL remote-db> GRANT connect TO proxy_user;

Grant succeeded.

SQL remote-db>

Zusätzlich vergibt man dem entfernten OE-User das Privileg, sich über den dort eingerichteten Proxy-User anzumelden.

SQL remote-db> ALTER USER oe GRANT CONNECT THROUGH proxy_user;

User altered.

SQL remote-db>

Der Datenbank Link auf der lokalen Seite wird nun für Proxy Authentisierung eingerichtet. Beachten Sie dabei, dass im Link jetzt nicht mehr das Kennwort des sensiblen OE-Schemas, sondern das Kennwort des minimal privilegierten Proxy-Accounts gespeichert wird. Proxy Authentisierung wird durch das Accountkonstrukt „foo[bar]“ angesprochen, in dem ausgedrückt wird, dass sich der User „bar“ mit den Credentials des Users „foo“ anmeldet.

SQL local-db> DROP DATABASE LINK remote_oe;

Database link dropped.

SQL local-db> CREATE DATABASE LINK remote_oe CONNECT TO "proxy_user[oe]" IDENTIFIED BY "very_secure_password" USING 'remote_db';


Database link created.

SQL local-db> SELECT SUM(order_total) FROM orders@remote_oe;

SUM(ORDER_TOTAL)
----------------
       3668054.7

Das Kennwort des Users „OE“ auf der Remote-Datenbank kann nun den unternehmensinternen Passwort-Policies folgend beliebig geändert werden, ohne dass das Einfluss auf den Datenbank Link hätte.

Zwei Schwachstellen hat das Konzept trotz des Gewinns an Sicherheit und Wartbarkeit allerdings:

Eine etwaige Änderung des Proxy-User-Kennworts erfordert wie gehabt das Löschen und Neuanlegen des Datenbank Links nach sich. Da der Proxy-User jedoch nur über minimale Privilegien (idealerweise nur connect-Rolle) verfügt, muss sein Kennwort ggf. nur sehr selten, z.B. innerhalb geplanter Wartungsfenster, geändert werden.
Proxy Authentisierung ist nicht für connected user database links anwendbar.

Und noch eine Randbemerkung: Da beim Zugriff auf die Remote-Datenbank nicht das Kennwort des „OE“-Benutzers verwendet wird, funktioniert der Link natürlich auch noch bei abgelaufenem „OE“-Kennwort. Erst das Sperren des „OE“-Accounts (oder Passwortablauf / Sperre am Proxy-User-Account) sperrt den Zugriff über den Datenbank Link.

FAZIT:
Mit Einsatz von Proxy Authentication kann die Sicherheit und Wartbarkeit von Zugriffen über Datenbank Links erhöht werden. Häufige Passwortänderungen für Schemaowner (die ein Bestandteil einer vernünftigen Sicherheitsstrategie sein sollten) wirken sich nicht mehr hinderlich auf die Verfügbarkeit von Datenbank Links aus.