Oracle Objektberechtigungen

Objektberechtigungen durch einen Datenbank- oder Anwendungsadministrator verwalten zu lassen, kann zu unerwarteten Effekten führen, wenn nicht rechtzeitig in der Planung alle Details in der Implementierung der Oracle-Berechtigungsverwaltung bedacht werden. Der folgende Artikel diskutiert die beiden Möglichkeiten und deren Folgen für den Betrieb.

Ein oft eingesetzter Mechanismus zur Erteilung von Objektberechtigungen an Datenbankbenutzer ist die Möglichkeit, dass der Objekteigentüer die Berechtigung an einen „Anwendungs-Administrator” mit GRANT OPTION vergibt. Die Variante, die Objektberechtigungen über Rollen zu vergeben, soll hier nicht diskutiert werden. Folgende Datenbankbenutzer seien beteiligt:

APPOWNER

Besitzer aller Datenbankobjekte einer Anwendung. Es kann nur einen davon geben.

APPADMIN

Ein Anwendungs-Administrator, der die Objektpriviliegien verwalten soll.

APPADMIN2

Ein weiterer Anwendungs-Administrator, der die Objektpriviliegien verwalten soll.

SYSADMIN

Ein Datenbank-Administrator, der ebenfalls Objektprivilegien vergeben kann, allerdings mit einem anderen Mechanismus. Er besitzt das Systemprivileg GRANT ANY OBJECT PRIVILEGE. Es kann mehrere davon geben

APPUSER1

Ein Anwendungs-Benutzer, der die Objektprivilegien erhät. In der Regel gibt es viele davon.

Folgende Skripte erzeugen unseren Testfall:

install.sql:
define u=APPOWNER
-- Benutzer APPOWNER, APPADMIN, APPADMIN2, SYSADMIN und APPUSER1 erzeugen
@users/cr_users
-- Objekte des Benutzers APPOWNER erzeugen (hier nur eine Tablle)
@tables/cr_tables &&u
-- Zugriffsrechte auf die Tablle an den APPADMIN mit GRANT OPTION vergeben
@users/grant_permissions &&u

Dieses Skript berechtigt und zeigt die Berechtigungen an:

grant.sql:
define u=&1
-- Grant durch den Applikationsadministrator (GRANT OPTION)
connect appadmin/appadmin$2010
grant select on &&u..testtable to appuser1;
-- Grant durch den Systemadministrator  (GRANT ANY OBJECT PRIVILEGE)
connect sysadmin/sysadmin$2010
grant update on &&u..testtable to appuser1;
-- Berechtigungen ansehen
@sel_privs &&u
-- Applikationsadministrator entfernen
prompt drop user appadmin
drop user appadmin;
-- Verbliebene Berechtigungen ansehen
@sel_privs &&u

mit folgendem Ergebnis:

SQL> @grant
Connect durchgefuhrt.
alt   1: grant select on &&u..testtable to appuser1
neu   1: grant select on APPOWNER.testtable to appuser1
Benutzerzugriff (Grant) wurde erteilt.
Connect durchgefuhrt.
alt   1: grant update on &&u..testtable to appuser1
neu   1: grant update on APPOWNER.testtable to appuser1
Benutzerzugriff (Grant) wurde erteilt.
GRANTEE    TABLE_NAME GRANTOR    PRIVILEGE  GRA
---------- ---------- ---------- ---------- ---
APPUSER1   TESTTABLE  APPOWNER   UPDATE     NO
APPADMIN   TESTTABLE  APPOWNER   SELECT     YES
APPUSER1   TESTTABLE  APPADMIN   SELECT     NO
drop user appadmin
Benutzer wurde geloscht.
GRANTEE    TABLE_NAME GRANTOR    PRIVILEGE  GRA
---------- ---------- ---------- ---------- ---
APPUSER1   TESTTABLE  APPOWNER   UPDATE     NO
SQL> connect /
Connect durchgefuhrt.
SQL> drop user sysadmin;
Benutzer wurde geloscht.
SQL> @sel_privs APPOWNER
GRANTEE    TABLE_NAME GRANTOR    PRIVILEGE  GRA
---------- ---------- ---------- ---------- ---
APPUSER1   TESTTABLE  APPOWNER   UPDATE     NO

Wir erkennen dabei, dass die Berechtigungen, die über einen Anwendungsadministrator vergeben werden, dann verschwinden, wenn der Anwendungsadministrator gelöscht wird. Dagegen bleiben die Berechtigungen bestehen, wenn die Berechtigung von einem DBA vergeben worden ist, auch wenn die DBA-Kennung gelöscht wird.

Im Falle des Anwendungsadminstrators ist in den Katalogviews ersichtlich wer das Recht vergeben hat. DBA_TAB_PRIVS enthält als GRANTOR den Namen des Anwendungsadministrators.

Im Falle des Systemadministrators ist in den Katalogviews nicht ersichtlich wer das Recht vergeben hat. DBA_TAB_PRIVS enthält als GRANTOR den Namens des Objekteigentümers.

Die Berechtigungsvergabe durch einen Systemadministrator ist am wenigsten störanfällig. Wenn die Nachvollziehbarkeit der Berechtigungsvergabe aus Gründen der Revisionsfähigkeit ein entscheidendes Kriterium ist, kann der Weg über den Anwendungsadministrator gegangen werden. Allerdings dürfen Anwendungsadministratoren dann entweder nicht gelöscht werden, oder vor dem Löschen müssen die Berechtigungen an einen anderen Anwendungsadministrator übergeben werden. Das kann beispielsweise mit folgendem Skript geschehen:

transfer_privs.sql:
set serveroutput on
define from_user=&1
define to_user=&2
declare
  cmd varchar2(4000);
begin
  for p in (select owner, table_name, privilege from dba_tab_privs where
    upper(grantee) = upper('&&from_user') and grantable = 'YES') loop
    cmd := 'grant ' || p.privilege || ' on "' || p.owner || '"."' || p.table_name || '" to &&to_user with grant option';
    execute immediate cmd;
  end loop;
  for p in (select owner, table_name, privilege, grantee from dba_tab_privs where
    upper(grantor) = upper('&&from_user')) loop
    cmd := 'grant ' || p.privilege || ' on "' || p.owner || '"."' || p.table_name || '" to ' || p.grantee;
    dbms_output.put_line(cmd);
  end loop;
end;
/

Das Skript muss als DBA ausgeführt werden mit APPADMIN und APPADMIN2 als Parameter. Es vergibt die Berechtigungen an den APPADMIN2 (mit GRANT OPTION). Der Output muss von APPADMIN2 ausgeführt werden. Damit werden die Berechtigungen an den Endbenutzer vergeben. APPADMIN kann jetzt gelöscht werden, die Endbenutzerberechtigungen bleiben erhalten, in den Katalogviews ist APPADMIN2 als GRANTOR eingetragen.