CTF - Capture the Flag: Die Machen das mit “Links”!

Die ORDIX AG nimmt auch in diesem Jahr an der DOAG-Konferenz teil – einem der wichtigsten Treffpunkte der deutschen Oracle Community. Doch dieses Mal wollen wir nicht "nur" wie gewohnt Fachvorträge halten, sondern etwas Neues machen: Eine interaktive Vortragsreihe mit dem Fokus auf Datenbank-Security! In diesem Artikel geht es um das Thema Datenbanklinks.

Passwörter von Links sind häufig eine kritische Hürde bei Migrationen von Datenbanken; gerade bei der Anpassung der hinterlegten Zielinformationen. Diese sind erforderlich, um die Datenbankverbindungen korrekt zu rekonstruieren. Doch häufig sind gerade Passwörter der Zielbenutzer nicht verfügbar. Aus Sicherheitsgründen werden diese nicht abgelegt oder nicht dokumentiert. Diese Situation kann den Migrationsprozess erheblich verkomplizieren und den Aufwand für die Administration steigern. In diesem Artikel beleuchten wir, warum dieses Problem auftritt und welche Lösungsansätze es gibt, um diese Herausforderung zu meistern.

Das Problem

Wie häufig kommt es im Datenbankumfeld zu Migrationen? Oft sind es Hardwaremigrationen, die Verschiebungen von Pluggable Databases zwischen Containern aber auch die Trennung von Teilapplikationen, die eine Migration erforderlich machen. Diese administrativen Aufgaben erfordern es, die Metadaten von Datenbanklinks anzupassen. Die notwendige Adaption liegt in der Definition eines Datenbanklinks begründet.

Generell wird in vier verschiedene Arten von Datenbanklinks unterschieden. Das erste Unterscheidungsmerkmal ist, ob der Link als "Public" definiert ist oder lediglich für einen dedizierten Benutzer verwendbar ist. Für die Migrationsstrategie spielt dieser Unterschied keine Rolle. Aus sicherheitsrelevanten Gründen wird jedoch empfohlen, auf die Verwendung von öffentlichen Links zu verzichten.

Von entscheidender Bedeutung für die Verlagerung von Datenbanken oder Datenbankschemata ist die Unterscheidung, ob die Links auf den aktuellen Benutzer verweisen oder einen zentralen, in der Zieldatenbank zu definierenden Benutzer ansprechen. IIm ersten Fall muss der Ausgangsbenutzer dem Zielschema im Namen als auch im Passwort entsprechen. In der Praxis wird dieses Konstrukt selten verwendet, ist aber technisch valide. Die zweite Option, den Link auf einen zentralen Benutzer auf der Remoteseite zu definieren, erfordert das Passwort der Gegenseite.

Ein weiterer entscheidender Aspekt, der sich auf die Migrationsstrategie von Datenbanklinks auswirkt, ist die Definition des Zielservers. Der Angabe eines TNSNAMES-Alias steht der Möglichkeit, die Verbindungsinformationen fest in der Linkdefinition zu übergeben, gegenüber.

Durch eine Migration können sich Datenbankname, Servicename, Hostname, der Port oder das Protokoll ändern. Für den Fall der Fälle, dass der Link über einen TNS-Alias definiert ist, kann dieser im einfachsten Falle geändert werden. Dieses Vorgehen kann bei standardisierten Namenskonventionen jedoch zu Inkonsistenzen führen. Sollten die Details zur Remotedatenbank im Link definiert sein, muss dieser neu erzeugt werden. In der Praxis ist das Passwort wegen unzureichender Dokumentationen oder aus Sicherheitsgründen nicht in jedem Fall bekannt. Die Datenbanklinks können also nicht einfach neu erstellt werden.

Gibt es nun eine Möglichkeit, die Links, ohne eine Passwortänderung des Zielschemas zu erstellen?

Die Lösung

Ja, es ist möglich. Die Passwörter und die "Salts" mit denen sie erweitert werden, sind in der Datenbank hinterlegt. Eine Prozedur zum Entschlüsseln der Datenbank-Link Passwörter findet man unter
https://github.com/hatem-mahmoud/scripts/blob/master/db_link_password_decrypt.sql .

Die Prozedur db_link_password_decrypt erwartet zwei Übergabeparameter, die aus der Datenbank ausgelesen werden können.

Wert der Spalte value$ für NO_USER_ID_SALT der Tabelle sys.props$
Wert der Spalte Passwordx für den entsprechenden Databaselink Namen der Tabelle sys.link$

Beides sind Tabellen der internen Schicht des Data Dictionary. Die Porperties-Tabelle (props$) liefert Datenbankgrundeinstellungen, wie in diesem Falle den Salt, mit dem die Link-Passwörter erweitert werden. Die Link-Tabelle (link$) speichert die Metadaten der gespeicherten Linkobjekte, wie unter anderem auch Namen und Passwort.

Mit den zwei ermittelten Werten kann die Prozedur ausgeführt werden und man erhält das entschlüsselte Passwort des Zielbenutzers der Ferndatenbank. Links können jetzt mit diesen Informationen nach erfolgter Migration der Datenbank entsprechend neu aufgebaut werden, auch wenn die Dokumentation dieser Passwörter nicht erfolgt ist.

Fazit

Ist es nötig Datenbanklinks auf der Ausgangsseite des Links anzupassen, müssen diese in der Datenbank neu erstellt werden. Die Definition mit den Passwort Hashes ist syntaktisch wie bei Benutzern (identified by values) nicht möglich. Sollten sich Namenskonventionen oder Zieldatenbanknamen ändern, ist es nicht sauber, wenn Standards aufgebrochen werden. Alle nötigen Informationen werden in der Datenbank vorgehalten. Die beschriebene Lösung hilft die Hindernisse der Linkmigration aufzuweichen und zu einer erfolgreichen Migrationsstrategie beizusteuern.