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.