News zu Oracle

DBA Tipp: Arbeiten mit Datenbanklinks? Aber sicher!

Datenbanklinks sind aus DBA-Sicht ein hervor­ra­gendes Werkzeug, wenn es darum geht, aus einer Oracle Datenbank direkt auf Daten in einer anderen Oracle-Datenbank zuzugreifen. Aus techni­scher Sicht ist ein Zugriff über einen Datenbanklink 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 Links hinterlegt sein, mit welchen Credentials sich dieser an der entfernten Datenbank anmeldet. Aus diesem Grund sind sie dem Sicherheitsbeauftragten regel­mäßig ein Dorn im Auge.

Zugewinn an Sicherheit und Wartbarkeit

Was aber, wenn sich die Sicherheit und Wartbarkeit von Zugriffen über Datenbanklinks ohne großen Aufwand erhöhen ließe? Um das zu erklären tauchen wir noch etwas tiefer in die Materie ein. Man unter­scheidet folgende zwei Link-Typen:

  • 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 angemel­deten Users wird eine Verbindung zum gleich­na­migen User auf der entfernten Datenbank herge­stellt. Der Benutzer auf der lokalen Datenbank muss folglich mit gleichem Namen und Passwort auch in der entfernten Datenbank existieren.


Beiden Linktypen ist ein erheb­liches 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 Datenbanklink 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 erheb­lichen Restriktionen wird das Kennwort der Link-Benutzer in der Praxis zu selten bis gar nicht geändert. Daraus kann ein erheb­liches Sicherheitsproblem resul­tieren, da insbe­sondere der Account auf der entfernten Seite tatsächlich Zugriff auf unter Umständen sensible Datenbankobjekte hat. Damit wäre er ein typischer Kandidat für sehr restriktive Passwort-Policies und häufigen Passwortwechsel.

Einsatz der Proxy Authentication als Lösung

Das geschil­derte 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 Datenbanklinks 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ömm­liche 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 aller­dings 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 hinrei­chend 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 einge­rich­teten Proxy-User anzumelden. 
SQL remote-db> ALTER USER oe GRANT CONNECT THROUGH proxy_user;

User altered.

SQL remote-db>

Der Datenbanklink auf der lokalen Seite wird nun für Proxy Authentisierung einge­richtet. Beachten Sie dabei, dass im Link jetzt nicht mehr das Kennwort des sensiblen OE-Schemas, sondern das Kennwort des minimal privi­le­gierten Proxy-Accounts gespei­chert wird. Proxy Authentisierung wird durch das Accountkonstrukt „foo[bar]“ angesprochen, in dem ausge­drü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 unter­neh­mens­in­ternen Passwort-Policies folgend beliebig geändert werden, ohne dass das Einfluss auf den Datenbanklink hätte.

Was zu beachten ist

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 Datenbanklinks. Da der Proxy-User jedoch nur über minimale Privilegien (idealer­weise nur connect-Rolle) verfügt, muss sein Kennwort ggf. nur sehr selten, z.B. innerhalb geplanter Wartungsfenster, geändert werden.

Proxy Authentisierung ist darüber hinaus 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, funktio­niert der Link natürlich auch noch bei abgelau­fenem „OE“-Kennwort. Erst das Sperren des „OE“-Accounts (oder Passwortablauf / Sperre am Proxy-User-Account) sperrt den Zugriff über den Link.

Fazit

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

Hier findest du weitere inter­es­sante DBA Tipps oder Posts zum Thema Oracle Datenbank aus unserem News und Insights Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email