Schema Nutzer oder persönliche Benutzer

Dieses Konzept führt dazu, dass Änderungen am Datenmodell bzw. an Datenbankobjekten als der Besitzer der Objekte durchgeführt werden. Anders ausgedrückt, man meldet sich als der Besitzer der Objekte an der Datenbank an. Arbeiten also mehrere Personen an einem Projekt, so ist jeder im Besitz der Zugangsdaten für diesen Datenbankbenutzer. Außerdem ist man dann relativ anonym in der Datenbank. Herauszufinden, welche Person als Schema Eigner (Besitzer der Objekte) angemeldet ist, kann sich recht aufwändig gestalten.

Natürlich könnte man für jede Person, die Änderungen am Datenmodell durchführen soll, einen separaten Datenbankbenutzer erstellen und diesen mit Berechtigungen auf die Objekte im Schema ausstatten. Allerdings kann man dann immer noch keine neuen Objekte in fremden Schemas erstellen. Das geht nur, wenn man über das ensprechende ANY Privilege, wie z.B. CREATE ANY TABLE, verfügt. Solche mächtigen Berechtigungen sollten aber unbedingt vermieden werden. Was kann man also tun?

Um das Schema, in dem man arbeitet, und die Authentifizierung, also die Anmeldung an der Datenbank, zu trennen, hat Oracle das Konzept der Proxy User etabliert. Als Proxy User kann man sich an fremden Datenbankschemas anmelden, sofern man über das entsprechende Recht verfügt. Ist das der Fall, kann arbeiten, als wäre man direkt am Datenbankschema angemeldet. 

Im Beispiel wird ein Schemaeigner sowie ein persönlicher Datenbankbenutzer erstellt. Dabei wird das neue 18c Feature der passwortlosen Accounts für den Schemaeigner zum Einsatz gebracht. Es genügt aber auch, den Account des Schemaeigners zu sperren.

SYS @ ORCL19:PDB1:>create user app_owner no authentication default tablespace users quota unlimited on users;


User APP_OWNER created.

SYS @ ORCL19:PDB1:>grant create session, create table, create view to app_owner;

Grant succeeded.

SYS @ ORCL19:PDB1:>create user marco identified by "S3cr3T" ;

User MARCO created.

SYS @ ORCL19:PDB1:>grant create session to marco;

Grant succeeded.

Der Schemaeigner hat also Berechtigungen zum Anlegen von Tabellen und Views während der persönliche Benutzer sich lediglich anmelden darf. Wie kann sich der persönliche Benutzer nun am anderen Schema anmelden? Dazu wird der persönliche Benutzer zum Proxy User für den Schemaeigner gemacht.

SYS @ ORCL19:PDB1:>alter user app_owner grant connect through marco;

User APP_OWNER altered.

  Wenn man sich nun einfach nur wie gewohnt mit dem persönlichen Nutzer anmeldet, dann kann man erst einmal nicht viel tun.

SYS @ ORCL19:PDB1:>conn marco/"S3cr3T"@vm160:1521/PDB1.support.robotron.de
Connected.

MARCO @ ORCL19:PDB1:>create table emp(id number, emp_name varchar2(100));

Error starting at line : 1 in command -
create table emp(id number, emp_name varchar2(100))
Error report -
ORA-01031: insufficient privileges

Aber man wilj auch gar keine Objekte im eigenen Schema anlegen sondern im Applikationsschema. Dazu muss man die Verbindung zur Datenbank anders aufbauen, um als Proxy User agieren zu können.

SYS @ ORCL19:PDB1:>conn marco[app_owner]/"S3cr3T"@vm160:1521/PDB1.support.robotron.de
Connected.
APP_OWNER @ ORCL19:PDB1:>show user
USER is "APP_OWNER"

APP_OWNER @ ORCL19:PDB1:>create table emp(id number, emp_name varchar2(100));

Table EMP created.

APP_OWNER @ ORCL19:PDB1:>create table dept(id number, depname varchar2(30));

Table created.

Wie man sieht, bewegt man sich nach der Anmeldung so, als hätte man sich direkt am Schema angemeldet. Und man sieht auch, dass man nun offenbar auch über die Berechtigungen des Schemaeigners verfügt, denn man kann Tabellen erstellen. 

Wie kommt man nun an die Information, wer wann im Schema etwas verändert hat bzw. angemeldet war? Dazu kommt eine Audit Policy zum Einsatz, die alle Anmeldungen protokolliert. Oracle bringt zwar bereits eine Policy mit, diese protokolliert aber lediglich die fehlgeschlagenen Anmeldungen.

SYS @ ORCL19:PDB1:>create audit policy ap_logons actions logon, logoff;

Audit POLICY created.

SYS @ ORCL19:PDB1:>audit policy ap_logons;

Audit succeeded.

Zum Testen versucht man entsprechende Verbindungen zur Datenbank aufzubauen, einmal direkt als Schemaeigner, einmal mit dem persönlichen Benutzer und einmal als Proxy User.

SYS @ ORCL19:PDB1:>conn app_owner/"S3cr3T"@vm160:1521/PDB1.support.robotron.de
  USER          = app_owner
  URL           = jdbc:oracle:oci8:@vm160:1521/PDB1.support.robotron.de
  Error Message = ORA-01017: invalid username/password; logon denied
  USER          = app_owner
  URL           = jdbc:oracle:thin:@vm160:1521/PDB1.support.robotron.de
  Error Message = ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

SYS @ ORCL19:PDB1:>conn marco/"S3cr3T"@vm160:1521/PDB1.support.robotron.de
Connected.

MARCO @ ORCL19:PDB1:>conn marco[app_owner]/"S3cr3T"@vm160:1521/PDB1.support.robotron.de
Connected.

Im Audit Trail der Datenbank spiegeln sich diese Versuche dann wie folgt wider:

SYS @ ORCL19:PDB1:>select  EVENT_TIMESTAMP, USERHOST, DBUSERNAME, DBPROXY_USERNAME, CLIENT_PROGRAM_NAME, ACTION_NAME, RETURN_CODE, CLIENT_IDENTIFIER, UNIFIED_AUDIT_POLICIES from unified_audit_trail
  2* where EVENT_TIMESTAMP>trunc(current_timestamp) order by 1;

               EVENT_TIMESTAMP                     USERHOST    DBUSERNAME    DBPROXY_USERNAME                           CLIENT_PROGRAM_NAME             ACTION_NAME    RETURN_CODE    CLIENT_IDENTIFIER           UNIFIED_AUDIT_POLICIES
______________________________ ____________________________ _____________ ___________________ _____________________________________________ _______________________ ______________ ____________________ ________________________________
17.05.24 11:16:35,640086000    vm160.support.robotron.de    APP_OWNER                         java@vm160.support.robotron.de (TNS V1-V3)    LOGON                             1017                      ORA_LOGON_FAILURES, AP_LOGONS
17.05.24 11:16:37,090726000    vm160.support.robotron.de    APP_OWNER                         SQLcl                                         LOGON                             1017                      ORA_LOGON_FAILURES, AP_LOGONS
17.05.24 11:16:54,933830000    vm160.support.robotron.de    MARCO                             java@vm160.support.robotron.de (TNS V1-V3)    LOGON                                0                      AP_LOGONS
17.05.24 11:17:00,898739000    vm160.support.robotron.de    MARCO                             java@vm160.support.robotron.de (TNS V1-V3)    PROXY AUTHENTICATION                 0                      AP_LOGONS
17.05.24 11:17:00,906957000    vm160.support.robotron.de    APP_OWNER     MARCO               java@vm160.support.robotron.de (TNS V1-V3)    LOGON                                0                      AP_LOGONS
17.05.24 11:17:00,923093000    vm160.support.robotron.de    MARCO                             java@vm160.support.robotron.de (TNS V1-V3)    LOGOFF                               0                      AP_LOGONS
17.05.24 11:17:09,595957000    vm160.support.robotron.de    APP_OWNER     MARCO               java@vm160.support.robotron.de (TNS V1-V3)    LOGOFF                               0                      AP_LOGONS

Man sieht den ersten fehlgeschlagenen Anmeldeversuch als Schemaeigner mit dem Fehlercode 1017. Danach folgt die erfolgreiche Anmeldung mit dem persönlichen Benutzer. Die letzten vier Zeilen stellen die Anmeldung als Proxy User dar. Man sieht, dass zuerst die Anmeldung mit dem persönlichen Account erfolgt, gefolgt vom Wechsel in das Anwendungsschema per PROXY AUTHENTICATION. Die Abmeldung besteht dann ebenfalls wieder aus zwei Schritten.