Für den Verantwortlichen einer Applikation existiert immer die Aufgabe der Vergabe von Berechtigungen für die einzelnen Objekte an die Anwender. Es stellt sich nun die Frage, welche Benutzer benötigen welche Privilegien? Außerdem gibt es die Empfehlung, nicht mit dem Schema-Owner der Applikation zu arbeiten.
Auch aus Gründen des Audits sollte immer ein separater Benutzer angelegt werden, dem die Rechte auf Objekte des Applikationsschemas zugewiesen werden.
Bis jetzt musste jede Berechtigung für jedes Datenbankobjekt an einen Benutzer oder an eine Rolle einzeln vergeben werden. Das kann für eine große Applikation sehr aufwendig und unübersichtlich sein. Dazu kommen während der Entwicklung der Applikation immer neue Objekte hinzu und das Szenario der Rechtevergabe muss für jedes neue Objekt wiederholt werden.
So ist es in der Vergangenheit immer wieder passiert, dass ANY-Privilegien als Systemprivileg datenbankweit vergeben wurden, was aus Sicht der Datenbank Security keine Lösung, sondern eher eine Katastrophe ist. Nun können stattdessen ab Oracle 23ai neue Schemaprivilegien genutzt werden, was ich an den folgenden vier Beispielen zeigen möchte:
Beispiel 1: Privilegien vergeben, wie bisher
Benutzer DEM01 (Schema-Owner mit den entsprechenden Privilegien)
SYS@PDB1> CONNECT DEM01/<password>@PDB1
DEM01@PDB1> CREATE table TAB1 (id number, Stadt varchar2(20));
DEM01@PDB1> INSERT into TAB1 values (1,'Dresden');
DEM01@PDB1> commit;
DEM01@PDB1> GRANT select on DEM01.TAB1 to DEM02;
Benutzer DEM02 besitzt keine Schema-Objekte, kann sich an der Datenbank anmelden. Er kann nun lesend auf die Tabellen DEM01.TAB1 zugreifen (siehe letztes grant).
DEM02@PDB1> SELECT * from DEM01.TAB1;
ID STADT
--- ---------
1 Dresden
Beispiel 2: Neues Objekt im Schema hinzufügen
SYS@PDB1> CONNECT DEM01/<password>@PDB1
DEM01@PDB1> CREATE table TAB2 (id number, BL varchar2(20));
DEM01@PDB1> INSERT into TAB2 values (1,'Sachsen');
DEM01@PDB1> commit;
Nun versucht Benutzer DEMO2, die neue Tabelle abzufragen.
DEM02@PDB1> SELECT * from DEM01.TAB2;
select * from DEM01.TAB2
*
ERROR at line 1:
ORA-00942: table or view "DEM01"."TAB2" does not exist
Benutzer DEM02 erhält eine Fehlermeldung, weil er keine Privilegien auf die neue Tabelle hat. Die ganze Prozedur geht von vorne los und für jedes neue Objekt müssen die einzelnen Privilegien an verschiedene Benutzer neu vergeben werden. Das ist aufwendig und kann auch unübersichtlich werden.
Beispiel 3: Die Lösung ist die Vergabe von Schemaprivilegien.
Der Vorteil ist, dass Berechtigungen für verschiedene Objekttypen in einem Schema nur einmal erteilt werden müssen. Alle neu erstellten Objekte desselben Typs erhalten automatisch die entsprechende Berechtigung.
DEM01@PDB1> GRANT read any table on Schema DEM01 to DEM02;
Der folgende Test zeigt, dass der Benutzer DEM02 ohne weitere Privilegien-Vergabe sofort auf die neue Tabelle DEM01.TAB2 zugreifen kann.
DEM02@PDB1> SELECT * from DEM01.TAB2;
ID BL
--- ---------
1 Sachsen
Beispiel 4: Jetzt wird das Schemaprivileg wieder entzogen.
DEM01@PDB1> REVOKE read any table on Schema DEM01 from DEM02;
DEM02@PDB1> SELECT * from DEM01.TAB2;
ORA-00942: table or view "DEM01"."TAB2" does not exist
Damit ist der ursprüngliche Zustand wieder hergestellt.
Einige System- und Admin-Rechte wie z.B. SYSDBA sind von Schemaprivilegien ausgeschlossen, diese müssen, wie bisher direkt an Benutzer vergeben werden.
Durch die mit Oracle 23ai eingeführten Schemaprivilegien vereinfacht sich die Vergabe von Privilegien deutlich, was auch zur Übersichtlichkeit von Applikationen beiträgt.
Cornelia Heyde
