Einer für Alle – Verbindungen an die Datenbank mit „connect through“

Hier nun die Beschreibung des Fachvortrages von Jens Behring, gehalten im November 2013 im Rahmen der Deutschen Oracle Anwender Konferenz in Nürnberg:

Der Umzug einer Datenbank in eine Regelbetriebsführung bringt die eine oder andere Umstellung mit sich. Neben architektonischen Vorgaben zu Tablespaces und div. Vorgaben zu Objektnamen und Programmierrichtlinien für PL/SQL – nur um hier eine kleine Auswahl zu nennen – sind auch Regeln hinsichtlich Zugriffsrechten und Kennwortkriterien einzuhalten. Speziell diesemletztgenannten Teil widmet sich dieser Vortrag.

Warum dieses Thema?
Die Idee zu diesem Vortrag entstand im Rahmen des Umzugs einer durch die Fachabteilung betriebsgeführten Datenbank in die Regelbetriebsführung eines IT-Dienstleisters. In diesem Zusammenhang mussten einige Vorgaben des Dienstleisters eingehalten werden. Von diesen Vorgaben sind folgend im Rahmen des Vortrages von Interesse:

  • Der Zugriff auf die Datenbank erfolgt nicht mit dem User-Namen des Objekteigentümers
  • Der Zugriff direkt auf die Datenbank erfolgt ausschließlich mit persönlichen Nutzern
  • Es gilt die Kennwortrichtlinie des Dienstleisters. Diese sieht kryptische Kennwörter vor, die sich auch zwischen den verschiedenen Instanzen (Entwicklung, Test, Abnahme, Produktion) unterscheiden)

Vor dem Umzug gab es keine persönlichen Nutzer. Dies hatte zur Folge, dass Datenänderungen unter einem anonymen Datenbanknutzer durchgeführt wurden. In solchen Fällen ist auch die Hemmschwelle niedrig Zugangsdaten weiterzugeben, da keinerlei persönliche Information in diesen Zugangsdaten enthalten ist.

Darüber hinaus war die bis dahin verwendete Kennwortregel relativ berechenbar, so dass von den Zugangsdaten eines Nutzers relativ einfach auf die Zugangsdaten eines anderen Nutzers Rückschlüsse möglich waren. Da sich die Kennwörter zwischen den Instanzen nicht unterschieden haben, war damit einem Zugriff auf Produktionsdaten Tür und Tor geöffnet.

Da auch im produktiven Umfeld aber eine Vielzahl von SQL-Skripten existiert, die erst im Rahmen einer Konsolidierungsphase im Anschluss an den Umzug abgelöst werden sollen, bestand und besteht die Notwendigkeit, Anwendern auch im Umfeld der Regelbetriebsführung den Zugang an die Datenbank zu ermöglichen.

Innerhalb dieser Skripte werden u.a. regelmäßig „Spatial Indexes“ gelöscht und neu angelegt. Dies muss zwingend unter dem Schema erfolgen, welches der Eigentümer des Spatial Indexes ist. Hier galt es, die Anforderungen des IT-Dienstleisters mit den Anforderungen der Fachseite in Übereinstimmung zu bringen.

Die Idee zur Lösung!
Um nun einerseits die Anforderungen des Dienstleisters erfüllen zu können, andererseits aber auch Szenarien, wie z.B. eine Post-It-Sammlung mit neuen Kennwörtern an Monitoren zu verhindern, wurden diverse Szenarien untersucht. Speziell die Anforderung, dass Skripte wegen der Spatial Indexes unter dem Schema des Objekteigentümers laufen müssen, verhinderte eine Lösung, die nur mit Berechtigungen funktioniert.

In diesem Zusammenhang wurde die Möglichkeit des sog. „connect through“ mit Hilfe eines sogenannten Proxynutzers in Oracle Datenbanken (wieder-)entdeckt, deren Nutzung einigen Bedenken ausräumen sowie die geforderten Funktionalitäten ermöglichen konnte.

Die Funktionalität dieser Lösung!
Ein Proxynutzer bietet die Möglichkeit, sich via eines dem Anwender bekannten Nutzers als ein weiterer Nutzer an der Datenbank anzumelden. Hierbei dient der Proxynutzer lediglich zur Authentifizierung. Die Möglichkeit als Proxynutzer zu dienen, muss natürlich als Berechtigung vergeben werden.

Zunächst wird ein Schema benötigt, welches die Daten vorhält, die später selektiert werden:

create user data_owner identified by nobody_knows;

In diesem Schema wird nun eine Tabelle mit Daten angelegt:

create table data_owner.important_data ( id number , value varchar2 (5) ); insert into data_owner.important_data values ( 1, ‚one‘ ); insert into data_owner.important_data values ( 2, ‚two‘ ); commit;

Nun wird ein Nutzer benötigt, der als Proxynutzer fungieren kann:

create user jens identified by secret; grant create session to jens;

Dieser bisher „normale“ Nutzer benötigt nun noch das Recht, als Proxynutzer verwendet werden zu dürfen. Dies geschieht über eine ALTER USER-Anweisung:

alter user data_owner grant connect through jens_as_proxy;

Nun sind die Voraussetzungen für einen ersten Test erfüllt. Da das Kennwort von DATA_OWNER niemand kennt, soll die Verbindung über den Proxynutzer erfolgen. Dies geschieht mit Hilfe des folgenden Connect-Strings:

connect jens[data_owner]/secret@datenbank

Die Eingabe von SHOW USER zeigt dann folgendes:

> show user

USER ist “DATA_OWNER”

Damit ist klar, dass, obwohl das Kennwort von DATA_OWNER nicht bekannt ist, dem Nutzer JENS die Möglichkeit gegeben wurde, sich als DATA_OWNER an die Datenbank zu verbinden.

Oracle bietet natürlich die Möglichkeit, sowohl den SESSION USER als auch den PROXY USER herauszufinden. Folgende Eingabe liefert das gleiche Ergebnis, wie zuvor die Abfrage SHOW USER:

> select sys_context('userenv', 'session_user') from dual;
 SYS_CONTEXT('USERENV','SESSION_USER')
 --------------------------------------------------------------------------
 DATA_OWNER

Der verwendete Proxynutzer lässt sich mit folgender Anfrage ermitteln:

> select sys_context('userenv', 'proxy_user') from dual;
 SYS_CONTEXT('USERENV','PROXY_USER')
 --------------------------------------------------------------------------
 JENS<em></em>
<pre>


Der Data Dictionary View DBA_PROXIES können Informationen zu allen Proxy Benutzern entnommen werden.

Den Vortrag hier zum Download

Jens Behring, Senior Professional its-people GmbH

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen:

its-people – wir machen Ihre IT moderner,
leistungsfähiger und sicherer

Erfahren Sie bei einem persönlichen Gespräch, wie wir Sie gewinnbringend unterstützen können. Suchen Sie sich einen passenden Zeitpunkt aus. Wir melden uns. Versprochen!