News zu Oracle
Datenbanklinks 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 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 regelmäßig ein Dorn im Auge.
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 unterscheidet folgende zwei Link-Typen:
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 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 erheblichen Restriktionen wird das Kennwort der Link-Benutzer in der Praxis zu selten bis 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. Damit wäre er ein typischer Kandidat für sehr restriktive Passwort-Policies und häufigen Passwortwechsel.
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 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ö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 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> 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>
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 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 Datenbanklink 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 Datenbanklinks. 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 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, 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 Link.
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ünftigen Sicherheitsstrategie sein sollten) wirken sich nicht mehr hinderlich auf die Verfügbarkeit der Links aus.
Share this article