Oracle Database 10g Die Umfassende Referenz

Transkript

1 Oracle Database 10g Die Umfassende Referenz Kevin Loney ISBN Leseprobe Weitere Informationen oder Bestellungen unter sowie im Buchhandel

2 18 18 Grundlegendes zur Sicherheit bei Oracle Informationen sind für den Erfolg unerlässlich. Geraten sie allerdings in die falschen Hände, kann der Erfolg in Frage gestellt sein. Oracle bietet sehr viele Sicherheitsmerkmale und verhindert damit, dass Ihre Daten von Fremden eingesehen oder vorsätzlich beschädigt werden. Die Sicherheitsmerkmale werden über die Zuteilung oder den Widerruf von Berechtigungen auf der Basis von Personen und Berechtigungen gewährleistet. Diese Maßnahmen ergänzen die Sicherheitsmaßnahmen, die standardmäßig vom Betriebssystem angeboten werden. Oracle kontrolliert den Zugriff auf die Daten über die Befehle create user, create role und grant. In diesem Kapitel stellen wir Ihnen die grundlegenden Sicherheitsmerkmale von Oracle vor. Siehe Kapitel 19 für erweiterte Sicherheitsfunktionen wie die Virtual Private Database Benutzer, Rollen und Berechtigungen Jeder Oracle-Benutzer hat einen Namen, ein Passwort und besitzt seine eigenen Tabellen, Views und andere Ressourcen, die von ihm angelegt wurden. Eine Oracle-Rolle ist ein Set von Berechtigungen (oder der Zugriffstyp, den jeder Benutzer in Abhängigkeit von seinem Status und seiner Verantwortlichkeit erhält). Sie können einer Rolle bestimmte Rechte zuordnen und diese danach den entsprechenden Anwendern zuweisen. Außerdem kann ein Benutzer anderen Benutzern direkt bestimmte Berechtigungen erteilen. Die Datenbank-Systemberechtigungen ermöglichen Ihnen das Ausführen von definierten Befehlen. Mit der CREATE TABLE-Berechtigung können Sie beispielsweise Tabellen anlegen. Die GRANT ANY PRIVILEGE-Berechtigung erlaubt Ihnen, jede beliebige

3 Grundlegendes zur Sicherheit bei Oracle Systemberechtigung zu erteilen. Mehr zu diesem Thema erfahren Sie in der Alphabetischen Referenz unter dem Stichwort Berechtigungen. Mit den Datenbank-Objektberechtigungen können Sie auf bestimmte Objekte ausgewählte Operationen auszuführen. So können Sie mit der DELETE-Berechtigung beispielsweise Zeilen aus Tabellen und Views löschen. Mit der SELECT-Berechtigung fragen Sie Daten aus Tabellen, Views, Sequenzen und Snapshots (materialisierten Views) ab. Eine vollständige Übersicht zu den Berechtigungen finden Sie in der Alphabetischen Referenz Einen Benutzer anlegen Das Oracle-System wird mit zwei vorkonfigurierten Benutzerberechtigungen ausgeliefert: SYSTEM und SYS. Dem Benutzer SYS gehören die zentralen internen Tabellen, mit denen Oracle die Datenbank verwaltet; SYSTEM gehören zusätzliche Tabellen und Views. Sie können sich beim Benutzer SYSTEM anmelden und legen mit dieser Berechtigung andere Benutzer an, da SYSTEM diese Berechtigung besitzt. Bei der Installation von Oracle legen Sie (oder der Systemverwalter) als Erstes einen Benutzer für sich selbst an. Das Format des create user-befehls sieht wie folgt aus: create user user identified {by password externally globally as 'extnm'}; Mit diesem Befehl lassen sich noch andere Account-Charakteristiken setzen. Mehr dazu in der Alphabetischen Referenz unter dem Stichwort create user. Um die Benutzerkennungen und Passwörter Ihres Betriebssystems in die Oracle-Sicherheit einzubinden und dafür zu sorgen, dass für Host-basierte Benutzer nur eine Anmeldung notwendig ist, vergeben Sie kein Passwort, sondern verwenden den Begriff externally. Ein Systemadministrator (der jede Menge Berechtigungen besitzt), kann als zusätzliche Sicherheit ein Passwort besitzen. In den folgenden Beispielen soll der Systemverwalter Dora heißen: create user Dora identified by avocado; Doras Account ist angelegt und durch ein Passwort geschützt. Sie können einem Benutzer auch bestimmte Tablespaces (Platz auf den Laufwerken für die Benutzertabellen) einrichten, und ihm für den Plattenplatz und die Ressourcennutzung bestimmte Kontingente (Quotas) zuweisen. Informationen zum Thema Ressourcen und Tablespaces finden Sie in der Alphabetischen Referenz unter dem Stichwort create user sowie in den Kapiteln 17 und 20.

4 18.1 Benutzer, Rollen und Berechtigungen 391 Zur Änderung eines Passworts verwenden Sie den alter user-befehl: alter user Dora identified by psyche; Jetzt besitzt Dora statt avocado das neue Passwort psyche. Dora kann sich bei ihrem Account erst anmelden, wenn sie die Systemberechtigung CREATE SESSION besitzt: grant CREATE SESSION to Dora; Im Verlauf des Kapitels stellen wir weitere Beispiele zu den Systemberechtigungen vor Die Passwortverwaltung Passwörter können verfallen und die Accounts nach mehreren vergeblichen Anmeldeversuchen gesperrt werden. Wenn Sie Ihr Passwort ändern, wird eine Passwort-History geführt, mit der ausgeschlossen wird, dass man die alten Passwörter erneut verwendet. Die Verfallscharakteristiken für das Passwort Ihres Accounts werden von dem Profil bestimmt, das Ihrem Account zugewiesen wurde. Profile, die mit dem create profile- Befehl angelegt werden, verwaltet der DBA. Mehr Informationen zu create profile finden Sie in der Alphabetischen Referenz unter dem Stichwort CREATE PROFILE. Abhängig von den Passwörtern und den Account-Zugriffen können Profile Folgendes erzwingen: Die Lebenszeit Ihres Passworts, mit der festgelegt wird, wie oft Ihr Passwort geändert werden muss. Die Schon- oder Gnadenfrist, die Ihnen nach dem Verfallsdatum Ihres Passworts zur Änderung des Passworts verbleibt. Die Anzahl der aufeinander folgenden Fehlversuche bei der Anmeldung, bevor der Account gesperrt wird. Die Anzahl Tage, die der Account gesperrt bleibt. Die Anzahl Tage, die vergehen müssen, bis ein Passwort erneut verwendet werden darf. Die Anzahl der Passwortänderungen, die bis zur Wiederverwendung eines Passworts vergehen müssen. Über zusätzliche Merkmale der Passwortverwaltung legen Sie die minimale und maximale Länge und die Komplexität der Passwörter fest. Außer dem alter user-befehl können Sie in SQL*Plus zum Ändern Ihres Passworts den password-befehl benutzen. Wenn Sie mit dem password-befehl arbeiten, wird das neue Passwort bei der Eingabe nicht angezeigt. DBAs können mit dem password-be-

5 Grundlegendes zur Sicherheit bei Oracle fehl die Passwörter eines beliebigen Benutzers ändern, während alle anderen Anwender nur ihr eigenes Passwort modifizieren können. Wenn Sie den password-befehl eingeben, werden Sie nach dem alten und dem neuen Passwort gefragt: connect dora/psyche password Changing password for dora Old password: New password: Retype new password: Wurde das Passwort erfolgreich geändert, erhalten Sie folgende Rückmeldung: Password changed Das Ablaufdatum des Passworts erzwingen Mit Hilfe von Profilen lässt sich das Verfallsdatum, die Wiederverwendung und die Komplexität von Passwörtern vorgeben. So können Sie die Geltungsdauer eines Passworts einschränken und einen Account sperren, dessen Passwort zu alt ist. Zudem lässt sich die Komplexität des Passworts vorgeben und man kann Accounts sperren, bei denen mehrere Anmeldeversuche scheiterten. Setzen Sie beispielsweise die Ressource FAILED_LOGIN_ATTEMPTS des Benutzers auf 5, sind vier aufeinander folgende Fehlversuche beim Login zulässig. Beim fünften Fehlversuch wird der Account gesperrt. Hinweis: Wird beim fünften Versuch das richtige Passwort eingegeben, wird der 'failed login attempt count' auf 0 zurückgesetzt. Damit sind vor dem Sperren des Accounts fünf weitere Fehlversuche möglich. Im folgenden Listing wird für den Benutzer Jane das Profil LIMITED_PROFILE angelegt: create profile LIMITED_PROFILE limit FAILED_LOGIN_ATTEMPTS 5; create user JANE identified by EYRE profile LIMITED_PROFILE; grant CREATE SESSION to JANE;

6 18.1 Benutzer, Rollen und Berechtigungen 393 Scheitern fünf Anmeldeversuche für den JANE-Account, wird er von Oracle automatisch gesperrt. Geben Sie danach für den JANE-Account das richtige Passwort ein, erhalten Sie eine Fehlermeldung: connect jane/eyre ERROR: ORA-28000: the account is locked Um den Account wieder freizugeben, nutzen Sie die account unlock-klausel des alter user-befehls (von einem DBA-Account): alter user JANE account unlock; Nach dem Entsperren des Accounts sind wieder Verbindungen zum JANE-Account möglich. Mit der account lock-klausel des alter user-befehls lässt sich ein Account manuell sperren: alter user JANE account lock; Hinweis: Sie können account lock auch im create user-befehl angeben. Wird ein Account wegen wiederholter Fehlversuche bei der Anmeldung gesperrt, so entsperrt ihn Oracle automatisch nach Ablauf des Werts PASSWORD_LOCK_TIME, der vom Profil vorgegeben ist. Ist PASSWORD_LOCK_TIME beispielsweise auf 1 gesetzt, würde in unserem Beispiel der JANE-Account für einen Tag gesperrt und danach wieder freigegeben. Mit Hilfe der PASSWORD_LIFE_TIME-Ressource im Profil definieren Sie für das Passwort eine maximale Lebensdauer. Damit könnten Sie z. B. die Benutzer des Profils LIMITED_PROFILE zwingen, das Passwort alle 30 Tage zu ändern. alter profile LIMITED_PROFILE limit PASSWORD_LIFE_TIME 30; In diesem Beispiel wurde mit dem alter profile-befehl das Profil LIMITED_PROFILE geändert. Der Wert für PASSWORD_LIFE_TIME ist auf 30 gesetzt. Damit verfällt bei jedem Account, dem das Profil zugewiesen wurde, das Passwort nach 30 Tagen. Ist das Passwort abgelaufen, ist es bei der nächsten Anmeldung zu ändern es sei denn, im Profil ist für abgelaufene Passwörter eine Gnadenfrist definiert. Der Parameter für die Gnadenfrist heißt PASSWORD_GRACE_TIME. Wird das Passwort innerhalb der Gnadenfrist nicht geändert, verfällt der Account. Hinweis: Sollten Sie den Parameter PASSWORD_LIFE_TIME einsetzen, benötigen die Benutzer eine einfache Möglichkeit zum Ändern des Passworts.

7 Grundlegendes zur Sicherheit bei Oracle Ein abgelaufener Account ist etwas anderes als ein gesperrter Account. Einen gesperrten Account kann man nach Ablauf eines Zeitraums automatisch entsperren. Ein abgelaufener Account muss vom DBA wieder reaktiviert werden. Hinweis: Nutzen Sie die Verfallsmöglichkeit für Passwörter, sollten Sie sicherstellen, dass die Accounts, die den Applikationen gehören, andere Einstellungen haben. Andernfalls werden sie gesperrt und die Anwendung ist nicht mehr verfügbar. Um einen abgelaufenen Account zu reaktivieren, führen Sie den alter user-befehl aus. In diesem Beispiel deaktiviert der DBA manuell das Passwort von Jane: alter user jane password expire; User altered. Danach versucht JANE, ihren Account zu ändern. Bei Eingabe des Passworts wird sie sofort ausgefordert, für den Account ein neues Passwort anzugeben. connect jane/eyre ERROR: ORA-28001: the password has expired Changing password for jane New password: Retype new password: Password changed Connected. Sie können die Benutzer auch zwingen, dass beim ersten Zugriff auf den Account das Passwort zu wechseln ist. Dazu nutzen Sie die password expire-klausel des create user-befehls. Beim create user-befehl können Sie allerdings kein Verfallsdatum für das vom Benutzer gesetzte Passwort vorgeben. Dazu müssen Sie den Profile-Parameter PASSWORD_LIFE_TIME aus dem letzten Beispiel einsetzen. Um das Verfallsdatum der Accounts zu sehen, fragen Sie die Expiry_Date-Spalte der Data Dictionary View DBA_USERS ab. Benutzer, die das Verfallsdatum für ihr Passwort wissen möchten, fragen die Expire_Date-Spalte der Data Dictionary View USER_USERS ab (entweder mit SQL*Plus oder einem clientbasierten Abfrage-Tool). Die Wiederverwendung des Passworts einschränken Damit sich Passwörter nicht erneut verwenden lassen, bietet Oracle zwei Profile-Parameter: PASSWORD_REUSE_MAX oder PASSWORD_REUSE_TIME. Diese beiden Parameter schließen sich gegenseitig aus: Setzen Sie den einen Parameter, muss der andere UNLIMITED sein.

8 18.1 Benutzer, Rollen und Berechtigungen 395 Der Parameter PASSWORD_REUSE_TIME definiert die Anzahl Tage, die bis zum erneuten Einsatz eines Passworts vergehen müssen. Setzen Sie PASSWORD_REUSE_ TIME beispielsweise auf 60, kann man das Passwort in diesem Zeitraum nicht mehr verwenden. Der Parameter PASSWORD_REUSE_MAX definiert die Anzahl der Passwortänderungen, die vor dem erneuten Einsatz eines Passworts stattfinden müssen. Ist dieses Limit nicht erreicht, weist Oracle die Passwortänderung zurück. So können Sie beispielsweise PASSWORD_REUSE_MAX für das oben angelegte Profil LIMITED_PROFILE setzen: alter profile LIMITED_PROFILE limit PASSWORD_REUSE_MAX 3 PASSWORD_REUSE_TIME UNLIMITED; Probiert JANE nun, ihr altes Passwort zu verwenden, scheitert der Versuch. Angenommen, JANE möchte ihr Passwort wie folgt ändern: alter user JANE identified by austen; Und ändert es danach noch einmal: alter user JANE identified by whitley; Bei der nächsten Passwortänderung versucht sie, wieder ein altes Passwort einzusetzen. Dieser Versuch scheitert allerdings. alter user jane identified by austen; alter user jane identified by austen * ERROR at line 1: ORA-28007: the password cannot be reused Sie kann keines der alten Passwörter wiederverwenden und muss sich deshalb ein neues Passwort ausdenken Standardrollen Nachdem Dora einen Account besitzt, stellt sich die Frage, was sie damit in Oracle alles machen kann. Zum jetzigen Zeitpunkt nichts sie hat keine Systemberechtigungen außer CREATE SESSION. Applikationsbenutzer erhalten Berechtigungen häufig über Rollen. Sie können Systemberechtigungen und Objektzugriffe in Rollen gruppieren, die spezifisch für die Anforderungen der Applikationsbenutzer sind. Zudem können Sie eigene Rollen für Applikationsprozesse anlegen und mit den Oracle-Standardrollen die

9 Grundlegendes zur Sicherheit bei Oracle Anforderungen für den Systemzugriff einsetzen. Die wichtigsten Standardrollen, die zusammen mit der Datenbank angelegt werden, sind wie folgt: CONNECT, RESOURCE und DBA DELETE_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, SELECT_CATALOG_ROLE EXP_FULL_DATABASE, IMP_FULL_DATABASE AQ_USER_ROLE, AQ_ADMINISTRATOR_ROLE SNMPAGENT RECOVERY_CATALOG_OWNER SCHEDULER_ADMIN Stehen aus Gründen der Abwärtskompatibilität mit älteren Oracle-Versionen zur Verfügung. Diese Rollen bieten den Zugriff auf Data Dictionary Views und Packages. Diese Rollen sind speziell für die Dienstprogramme Export und Import gedacht. Diese Rollen benötigt man für das Oracle Advanced Queuing. Diese Rolle nutzt der Enterprise Manager Intelligent Agent. Diese Rolle benötigt man zum Anlegen eines Recovery Catalog-Schemaeigentümers. Diese Rolle erlaubt dem Berechtigungsempfänger das Ausführen der Prozeduren im DBMS_SCHEDULER- Package; sollte auf DBAs beschränkt sein. CONNECT, RESOURCE und DBA werden nur noch aus Gründen der Abwärtskompatibilität angeboten und sollten nicht mehr eingesetzt werden. Mit CONNECT können sich Benutzer anmelden und Basisfunktionen ausführen. Benutzer mit CON- NECT können Tabellen, Views, Sequenzen, Cluster, Synonyme und Datenbank-Links anlegen. Benutzer mit RESSOURCE können eigene Tabellen, Sequenzen, Prozeduren, Trigger, Datentypen, Operatoren, Indextypen, Indizes und Cluster einrichten. Benutzer mit der RESOURCE-Rolle haben auch die Systemberechtigung UNLIMITED TA- BLESPACE, womit sie die Kontingente auf alle Tablespaces umgehen können. Benutzer mit der DBA-Rolle können Funktionen der Datenbankadministration ausführen, inklusive dem Anlegen und Ändern von Benutzern, Tablespaces und Objekten. Anstelle von CONNECT, RESOURCE und DBA sollten Sie Ihre eigenen Rollen anlegen, die alle notwendigen Berechtigungen zur Ausführung von spezifischen Systemberechtigungen besitzen. In den folgenden Abschnitten erfahren Sie, wie man Benutzern und Rollen Berechtigungen vergibt Das Format des grant-befehls Nachfolgend sehen Sie den grant-befehl zur Erteilung von Systemberechtigungen:

10 18.1 Benutzer, Rollen und Berechtigungen 397 grant {system privilege role all [privileges] } [, {system privilege role all [privileges] }...] to {user role} [, {user role}]... [identified by password ] [with admin option] Mit dem grant-befehl weisen Sie Anwendern oder public Berechtigung oder Rollen zu. Die with admin option-klausel erlaubt dem Berechtigungsempfänger, die Berechtigungen an andere Rollen oder Benutzer weiterzugeben. Die all-klausel gewährt dem Benutzer oder der Rolle alle Berechtigungen bis auf die Systemberechtigung SELECT ANY DICTIONARY. Der Benutzer, der die Berechtigungen vergibt, kann sie mit revoke auch wieder entziehen Berechtigungen entziehen Einmal erteilte Rechte können wieder entzogen werden. revoke hat gewisse Ähnlichkeiten mit dem grant-befehl: revoke {system privilege role all [privileges] } [, {system privilege role all [privileges] }...] from {user role} [, {user role}]... Eine Person mit der DBA-Rolle kann jedem Benutzer die CONNECT-, RESOURCE-, DBA- oder jede andere Berechtigung und Rolle entziehen, einschließlich einem anderen DBA. Das ist natürlich gefährlich, und aus diesem Grund sollte man DBA-Berechtigungen nur sehr wenigen Personen erteilten. Hinweis: Entzieht man einem Anwender sämtliche Berechtigungen, werden weder der Benutzer noch dessen Tabellen gelöscht: dieser Benutzer kann nur nicht mehr darauf zugreifen. Andere Anwender, die auf diese Tabellen zugreifen dürfen, können damit normal weiterarbeiten. Um einen Benutzer und sämtliche ihm zugeteilte Ressourcen zu löschen, verwenden Sie den drop user-befehl: drop user username [cascade]; Die cascade-option löscht den Anwender zusammen mit allen seinen Objekten, inklusive der referenziellen Integritäts-Constraints. Diese Option macht die Views, Synonyme, gespeicherten Prozeduren, Funktionen oder Packages ungültig, die die Objekte im gelöschten Benutzerschema referenzieren. Wenn Sie die cascade-option nicht einsetzen und für den Anwender noch einige Objekte vorhanden sind, löscht Oracle den Benutzer nicht und gibt stattdessen eine Fehlermeldung zurück.

11 Grundlegendes zur Sicherheit bei Oracle 18.2 Was ein Anwender weitergeben kann Ein Benutzer kann für jedes Objekt, das ihm gehört, Berechtigungen erteilen. Der DBA kann alle Systemberechtigungen erteilen. Angenommen, dem Anwender Dora gehört die COMFORT-Tabelle und sie ist ein Datenbankadministrator. Sie legt die neuen Benutzer Bob und Judy mit den folgenden Berechtigungen an: create user Judy identified by sarah; User created. grant CREATE SESSION to Judy; Grant succeeded. create user Bob identified by carolyn; User created. grant CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SYNONYM to bob; Grant succeeded. alter user bob default tablespace users quota 5m on users; User altered. Diese Befehlssequenz gibt sowohl Bob als auch Judy die Möglichkeit, sich mit Oracle zu verbinden, und weist Bob einige zusätzliche Fähigkeiten zu. Kann jetzt einer von beiden etwas mit Doras Tabellen machen? Nicht ohne expliziten Zugriff. Um anderen den Zugriff auf Ihre Tabellen zu gewähren, setzen Sie eine zweite Form des grant-befehls ein: grant { object privilege all [privileges] } [(column [, column]...)] [, { object privilege all [privileges] } [(column [, column]...)] ]... on object to {user role} [with grant option] [with hierarchy option]; Zu den Berechtigungen, die ein Anwender erteilen kann, gehören folgende:

12 18.2 Was ein Anwender weitergeben kann 399 Auf Benutzertabellen, Views und materialisierte Views: FLASHBACK INSERT UPDATE (alle oder bestimmte Spalten) DELETE SELECT Die Berechtigungen INSERT, UPDATE und DELETE können nur auf aktualisierbare materialisierte Views gewährt werden. Für Informationen zum Anlegen von materialisierten Views siehe Kapitel 24. Auf Tabellen können Sie außerdem erteilen: ALTER (Tabelle alle oder spezifische Spalten) DEBUG REFERENCES INDEX (Spalten in einer Tabelle) ON COMMIT REFRESH QUERY REWRITE ALL (alle aufgeführten Berechtigungen) Auf Prozeduren, Funktionen, Packages, abstrakte Datentypen und Bibliotheken, Indextypen und Operatoren: EXECUTE DEBUG Auf Sequenzen: SELECT ALTER Auf Verzeichnisse (für die BFILE LOB-Datentypen und externe Tabellen): READ WRITE Auf abstrakte Datentypen und Views: UNDER (zum Anlegen von Subviews und Subtypen)

13 Grundlegendes zur Sicherheit bei Oracle Wenn Sie die Prozeduren oder Funktionen eines anderen Benutzers ausführen, werden diese üblicherweise mit den Berechtigungen des Besitzers ausgeführt. Das bedeutet, dass Sie keinen expliziten Zugriff auf die Daten benötigen, die von der Prozedur oder der Funktion benutzt werden: Sie sehen lediglich das Ergebnis der Ausführung und nicht die darunter liegenden Daten. Zudem können Sie Prozesse anlegen, die unter den Berechtigungen des aufrufenden Benutzers und nicht mit den Berechtigungen des Prozedureigentümers ausgeführt werden. Einzelheiten dazu siehe Kapitel 31. Dora gewährt Bob den SELECT-Zugriff auf die COMFORT-Tabelle: grant select on COMFORT to Bob; Grant succeeded. Die with grant option-klausel des grant-befehls ermöglicht dem Berechtigungsempfänger, die gewährten Berechtigungen an andere Benutzer weiterzugeben. Gewährt der Benutzer Dora dem Anwender Bob mit with grant option Berechtigungen auf ihre Tabellen, kann Bob jedem anderen Benutzer die Berechtigungen auf Doras Tabellen weitergeben (allerdings nur jene Berechtigungen, die ihm gewährt wurden). Falls Sie beabsichtigen, Views basierend auf den Tabellen von anderen Benutzern zu erstellen und weiteren Benutzern den Zugriff auf diese Views zu ermöglichen, muss Ihnen für die Basistabelle der Zugriff mit with grant option erteilt worden sein Den Benutzer mit connect wechseln Um den Erfolg des grant-befehls zu testen, wechselt Dora mit Hilfe des connect-befehls zum Benutzernamen von Bob. Für diesen Befehl lässt sich eine der folgenden Methoden einsetzen: Sie geben in der gleichen Zeile zusammen mit dem Befehl sowohl den Benutzernamen als auch das Passwort ein Sie geben nur den Befehl ein und antworten auf die gestellten Fragen Sie geben den Befehl und den Benutzernamen ein und antworten auf die Passwortabfrage. Die beiden letztgenannten Methoden unterdrücken die Anzeige des Passworts und sind infolgedessen wesentlich sicherer. Das folgende Listing zeigt eine Beispielanbindung mit der Datenbank: connect Bob/carolyn Connected. Nachdem Dora verbunden ist, wählt sie die Tabelle aus, für die Bob der SELECT-Zugriff erteilt wurde.

14 18.2 Was ein Anwender weitergeben kann 401 Hinweis: Wird kein Synonym benutzt, ist dem Tabellennamen der Benutzername des Tabelleneigentümers voranzustellen. Andernfalls erhalten Sie von Oracle die Meldung, dass die Tabelle nicht existiert. select * from Dora.COMFORT; CITY SAMPLEDAT NOON MIDNIGHT PRECIPITATION SAN FRANCISCO 21-MAR SAN FRANCISCO 22-JUN SAN FRANCISCO 23-SEP SAN FRANCISCO 22-DEC KEENE 21-MAR KEENE 22-JUN KEENE 23-SEP KEENE 22-DEC Es wird eine View namens COMFORT erstellt, die lediglich ein select auf die Tabelle Dora.COMFORT ist. create view COMFORT as select * from Dora.COMFORT; View created. Ein select auf diese View führt zum gleichen Ergebnis wie ein select von Dora.COM- FORT: select * from COMFORT; CITY SAMPLEDAT NOON MIDNIGHT PRECIPITATION SAN FRANCISCO 21-MAR SAN FRANCISCO 22-JUN SAN FRANCISCO 23-SEP SAN FRANCISCO 22-DEC KEENE 21-MAR KEENE 22-JUN KEENE 23-SEP KEENE 22-DEC Jetzt wechselt Dora wieder zu ihrem eigenen Benutzernamen und erstellt eine View, die nur einen Teil der COMFORT-Tabelle selektiert: connect Dora/psyche Connected. create view SOMECOMFORT as

15 Grundlegendes zur Sicherheit bei Oracle select * from COMFORT where City = 'KEENE'; View created. Danach erteilt sie Bob auf diese View sowohl die SELECT- als auch die UPDATE-Berechtigung, und entzieht ihm mit revoke gleichzeitig alle Berechtigungen für die COMFORT-Tabelle: grant select, update on SOMECOMFORT to Bob; Grant succeeded. revoke all on COMFORT from Bob; Revoke succeeded. Danach kehrt Dora zum Benutzernamen von Bob zurück und testet die Auswirkungen dieser Änderung: connect Bob/carolyn Connected. select * from COMFORT; * ERROR at line 1: ORA-04063: view "BOB.COMFORT" has errors Der Versuch, ein select auf diese COMFORT-View auszuführen, scheitert, weil die darunter liegende Tabelle, die in Bobs View genannt wurde, Dora.COMFORT war. Der Versuch, ein select auf Dora.COMFORT auszuführen, würde zur gleichen Fehlermeldung führen. Als Nächstes wird der Versuch unternommen, ein select auf Dora.SOMECOMFORT auszuführen: select * from Dora.SOMECOMFORT; CITY SAMPLEDAT NOON MIDNIGHT PRECIPITATION KEENE 21-MAR KEENE 22-JUN KEENE 23-SEP KEENE 22-DEC Obwohl der direkte Zugriff auf die COMFORT-Tabelle widerrufen wurde, funktioniert alles perfekt, da Dora Bob durch die SOMECOMFORT-View Zugriff auf einen Teil von COMFORT gewährte. Es handelt sich um den Teil der Tabelle, die zu KEENE gehört. Das zeigt uns ein leistungsfähiges Sicherheitsmerkmal von Oracle: Sie können eine View mit beinahe allen gewünschten Einschränkungen anlegen oder innerhalb der

16 18.2 Was ein Anwender weitergeben kann 403 Spalten beliebige Berechnungen ausführen. Statt anderen Benutzern den Zugriff auf die darunter liegende Tabelle zu erteilen, gewähren Sie ihnen den Zugriff auf diese View. Damit sehen die Benutzer nur Informationen, die in der View zur Verfügung stehen. Das kann so weit gehen, dass man diese Informationen sogar benutzerspezifisch definiert. Am Ende dieses Kapitel wird die Sicherheit nach Benutzern noch ausführlicher besprochen. Jetzt wird unter dem Benutzernamen Bob die View LITTLECOMFORT eingerichtet, die auf der View SOMECOMFORT aufsetzt: create view LITTLECOMFORT as select * from Dora.SOMECOMFORT; View created. Die Zeile für den 23. September 2003 wird aktualisiert: update LITTLECOMFORT set Noon = 88 where SampleDate = '23-SEP-03'; 1 row updated. Fragt man die LITTLECOMFORT-View ab, sieht man den Effekt der Aktualisierung: select * from LITTLECOMFORT; CITY SAMPLEDAT NOON MIDNIGHT PRECIPITATION KEENE 21-MAR KEENE 22-JUN KEENE 23-SEP KEENE 22-DEC Eine Abfrage auf Dora.SOMECOMFORT führt zum gleichen Ergebnis wie die Abfrage auf die COMFORT-Tabelle, die Dora selbst mit dem eigenen Benutzernamen ausführt. Das update wurde erfolgreich auf die darunter liegende Tabelle ausgeführt, obwohl der ganze Vorgang über zwei Views lief (LITTLECOMFORT und SOMECOMFORT). Hinweis: Sie müssen den Benutzern für alle Tabellen den SELECT-Zugriff gewähren, in denen sie Daten aktualisieren oder löschen können. Das geht konform mit den neuen ANSI-Standards und bezieht sich auf den Umstand, dass ein Anwender, der nur die UPDATEoder DELETE-Berechtigung besitzt, die Rückmeldungen der Datenbank dazu benutzen könnte, auf Informationen in den darunter liegenden Tabellen zu schließen.

17 Grundlegendes zur Sicherheit bei Oracle create synonym Eine Alternative zum Anlegen einer View, die eine vollständige Tabelle oder View eines anderen Benutzers beinhaltet, ist das Anlegen eines Synonyms: create synonym LITTLECOMFORT for Dora.SOMECOMFORT; Das Synonym wird wie eine View behandelt. Informationen dazu erhalten Sie in der Alphabetischen Referenz unter dem Stichwort create synonym Nicht erteilte Berechtigungen nutzen Angenommen, wir möchten die gerade aktualisierte Zeile löschen: delete from LITTLECOMFORT where SampleDate = '23-SEP-03'; * ERROR at line 1: ORA-01031: insufficient privileges Da Bob von Dora keine DELETE-Berechtigung erhielt, scheiterte dieser Versuch Berechtigungen weitergeben Bob kann anderen Benutzern die Berechtigung zur Nutzung seiner Tabellen gewähren, was bei einer Tabelle, die ihm nicht gehört, unmöglich ist. Hier versucht er, Judy die INSERT-Berechtigung zuzuweisen: grant insert on Dora.SOMECOMFORT to Judy; * ERROR at line 1: ORA-01031: insufficient privileges Da Bob diese Berechtigung nicht besitzt, kann seinem Wunsch nicht entsprochen werden. Danach versucht Bob, eine seiner Berechtigungen, SELECT, weiterzugeben: grant select on Dora.SOMECOMFORT to Judy; * ERROR at line 1: ORA-01031: insufficient privileges Auch diese Berechtigung kann er nicht weitergeben, da er nicht Eigentümer der SO- MECOMFORT-View ist. Wären ihm die Berechtigungen für den Zugriff auf SOME- COMFORT mit with grant option erteilt worden, dann wäre der grant-befehl erfolgreich gewesen. Da ihm die LITTLECOMFORT-View gehört, kann er versuchen, Judy eine Berechtigung für diese View weiterzugeben:

18 18.2 Was ein Anwender weitergeben kann 405 grant select on LITTLECOMFORT to Judy; ERROR at line 1: ORA-01720: grant option does not exist for 'DORA.SOMECOMFORT' Da LITTLECOMFORT auf Doras View basiert, und Bob für diese View nicht die Berechtigung SELECT with grant option erteilt wurde, kann sein Ansinnen nicht ausgeführt werden. Zusätzlich wird jetzt eine neue Tabelle eingerichtet, deren Eigentümer Bob ist, und mit den aktuellen Informationen aus seiner LITTLECOMFORT-View geladen: create table NOCOMFORT as select * from LITTLECOMFORT; Table created. Auch Judy wird die SELECT-Berechtigung gewährt: grant select on NOCOMFORT to Judy; Grant succeeded. Um die Berechtigungen zu testen, wechseln wir mit connect zum Benutzernamen von Judy: connect Judy/sarah Connected. Jetzt führen wir aus Judys Account Abfragen auf die Tabelle aus, für die Bob die SE- LECT-Berechtigung erteilte: connect Judy/sarah select * from Bob.NOCOMFORT; CITY SAMPLEDAT NOON MIDNIGHT PRECIPITATION KEENE 21-MAR KEENE 22-JUN KEENE 23-SEP KEENE 22-DEC Dieses grant war erfolgreich. Die Tabelle NOCOMFORT wurde angelegt und sie gehört dem Benutzernamen von Bob. Er konnte die Zugriffsberechtigung auf diese Tabelle erfolgreich weitergeben. Falls Dora möchte, dass Bob die Berechtigungen an andere weitergeben kann, fügt sie in die grant-anweisung eine weitere Klausel ein:

19 Grundlegendes zur Sicherheit bei Oracle connect Dora/psyche grant select, update on SOMECOMFORT to Bob with grant option; Grant succeeded. Die with grant option-klausel erlaubt Bob die Weitergabe der Zugangsberechtigung für SOMECOMFORT an Judy mit Hilfe seiner LITTLECOMFORT-View. Der Versuch eines anderen Benutzers, ohne die notwendige SELECT-Berechtigung auf eine Tabelle zuzugreifen, wird immer mit dieser Fehlermeldung quittiert: ERROR at line 1: ORA-00942: table or view does not exist Da immer diese Meldung erscheint und kein Hinweis darauf, dass unzureichende Zugriffsberechtigungen vorliegen, erfährt der Betreffende nicht, dass die Tabelle überhaupt existiert Eine Rolle anlegen Neben den oben vorgestellten Standardrollen können Sie in Oracle auch Ihre eigenen Rollen anlegen. Diese Rollen können System- oder Tabellenberechtigungen, oder eine Kombination aus beiden enthalten. In den folgenden Abschnitten zeigen wir, wie man diese Rollen anlegt und verwaltet. Zum Anlegen einer Rolle benötigen Sie die Systemberechtigung CREATE ROLE. Die Syntax zum Anlegen einer Rolle lautet wie folgt: create role role_name [not identified identified {by password using [schema.]package externally globally }]; Wird eine Rolle zum ersten Mal angelegt, sind mit dieser Rolle keinerlei Berechtigungen verbunden. Die Passwortoptionen der Rollen werden weiter unten erörtert. Nachfolgend finden Sie zwei Beispiele für den create role-befehl: create role CLERK; create role MANAGER; Der erste Befehl legt eine Rolle namens CLERK, und der zweite eine Rolle namens MANAGER an, die in den folgenden Beispielen eingesetzt werden Einer Rolle Berechtigungen zuweisen Nach dem Anlegen können Sie einer Rolle Berechtigungen zuweisen. Die Syntax für den grant-befehl ist für Benutzer und für Rollen dieselbe. Wenn Sie einer Rolle eine

20 18.2 Was ein Anwender weitergeben kann 407 Berechtigung zuweisen, setzen Sie den Namen der Rolle in der to-klausel des grant- Befehls ein: grant select on COMFORT to CLERK; Wie in diesem Beispiel zu sehen ist, nimmt der Rollenname im grant-befehl die Stelle des Benutzernamens ein. Die Berechtigung zur Auswahl von Daten aus der COM- FORT-Tabelle steht nun allen Benutzern der CLERK-Rolle zur Verfügung. Wenn Sie ein DBA sind oder Ihnen die Systemrolle GRANT ANY PRIVILEGE zugewiesen wurde, können Sie an Rollen Systemberechtigungen weitergeben wie CREA- TE SESSION, CREATE SYNONYM und CREATE VIEW. Diese Berechtigungen stehen danach allen Benutzern der entsprechenden Rolle zur Verfügung. Die Fähigkeit zum Anmelden bei der Datenbank wird mit der Systemberechtigung CREATE SESSION erteilt. Im folgenden Beispiel wird diese Berechtigung der CLERK- Rolle erteilt. Der MANAGER-Rolle wird die gleiche Berechtigung, und zusätzlich die Systemberechtigung CREATE DATABASE LINK zugewiesen: grant CREATE SESSION to CLERK; grant CREATE SESSION, CREATE DATABASE LINK to MANAGER; Einer anderen Rolle eine Rolle zuweisen Rollen können auch anderen Rollen zugewiesen werden. Dazu arbeiten Sie wie im folgenden Beispiel mit dem grant-befehl: grant CLERK to MANAGER; In diesem Beispiel wird die CLERK-Rolle der MANAGER-Rolle zugewiesen. Obwohl Sie der MANAGER-Rolle nicht direkt Tabellenberechtigungen erteilt haben, erbt sie alle Berechtigungen der CLERK-Rolle. Diese Organisationsform ist typisch für das Design in hierarchischen Organisationen. Möchten Sie einer Rolle eine andere Rolle zuweisen (oder, wie im folgenden Abschnitt, einem Benutzer), nutzen Sie die with admin option-klausel: grant CLERK to MANAGER with admin option; Mit dieser Klausel hat der Berechtigungsempfänger das Recht, die Rolle an andere Rollen oder Benutzer weiterzugeben. Der Berechtigungsempfänger kann diese Rolle ändern (mit alter) oder löschen (mit drop). Einem Benutzer eine Rolle zuweisen Benutzern kann man Rollen zuweisen. In diesem Fall sollte man sich die Rollen als ein mit Namen versehenes Set von Berechtigungen vorstellen. Anstatt jedem Benutzer die Berechtigungen einzeln zu erteilen, weisen Sie die Berechtigungen erst einer Rolle, und

21 Grundlegendes zur Sicherheit bei Oracle diese dann jedem Benutzer zu. Mit diesem Verfahren vereinfacht sich die Verwaltung der Berechtigungen wesentlich. Hinweis: Berechtigungen, die Benutzern über Rollen erteilt werden, können nicht als Grundlage für Views, Prozeduren, Packages oder Fremdschlüssel verwendet werden. Beim Anlegen dieser Datenbankobjekttypen müssen Sie die notwendigen Berechtigungen direkt zuweisen. Das Zuweisen einer Rolle an einen Benutzer erfolgt mit dem grant-befehl: grant CLERK to Bob; Der Benutzer Bob erhält in diesem Beispiel alle Berechtigungen, die der CLERK-Rolle zugewiesen wurden (CREATE SESSION und SELECT für COMFORT). Beim Zuweisen einer Rolle an einen Benutzer können Sie auch die with admin option- Klausel einsetzen: grant MANAGER to Dora with admin option; Dora besitzt nun die Berechtigung, die MANAGER-Rolle an andere Benutzer weiterzugeben, die Rolle zu löschen oder zu ändern Einer Rolle ein Passwort geben Mit dem alter role-befehl können Sie nur Berechtigungen ändern, die zur Aktivierung der Rolle benötigt werden. Standardmäßig besitzen Rollen kein Passwort. Die Sicherheitsmechanismen für eine Rolle aktivieren Sie mit dem alter role-befehl und dem Schlüsselwort identified. Zur Implementierung dieser Sicherheit gibt es zwei Möglichkeiten. Um ein Passwort zu spezifizieren, setzen Sie im alter role-befehl die identified by- Klausel ein: alter role MANAGER identified by cygnusxi; Jedes Mal, wenn ein Anwender versucht, diese Rolle zu aktivieren, wird das Passwort verlangt. Wurde diese Rolle für den Benutzer als Standardrolle eingerichtet, muss der Anwender beim Anmelden kein Passwort angeben. Mehr zu diesen Themen im weiteren Verlauf dieses Kapitels unter der Überschrift Rollen aktivieren und deaktivieren. Rollen lassen sich auch mit Systemberechtigungen verknüpfen. Sollte Ihr Betriebssystem diese Möglichkeit anbieten, setzen Sie im alter role-befehl die identified externally-klausel ein. Ist die Rolle aktiviert, prüft Oracle für Ihren Zugang das Betriebssystem

22 18.2 Was ein Anwender weitergeben kann 409 ab. Das Ändern einer Rolle, die mit diesem Sicherheitsmerkmal arbeitet, wird im folgenden Beispiel gezeigt: alter role MANAGER identified externally; Bei den meisten UNIX-Systemen arbeitet dieser Prozess mit der Datei /etc/group. Damit der Prozess bei allen Betriebssystemen funktioniert, muss man in der Datei init.ora den Datenbank-Startup-Parameter OS_ROLES auf TRUE setzen. Das folgende Beispiel für diesen Verifikationsprozess gilt für eine Datenbankinstanz namens Local auf einem UNIX-System. Die Datei /etc/group soll folgenden Eintrag enthalten: ora_local_manager_d:none:1:dora Dieser Eintrag weist dem Account namens Dora die MANAGER-Rolle zu. Das Suffix _d weist darauf hin, dass diese Rolle Dora beim Anmelden standardmäßig zugewiesen wird. Das Suffix _a würde darauf hinweisen, dass diese Rolle mit with admin option aktiviert wird. Ist die Rolle gleichzeitig die Standardrolle des Benutzers, lautet das Suffix _ad. Ordnet man diese Rolle mehr als einem Benutzer zu, fügt man die zusätzlichen Benutzernamen in /etc/group ein: ora_local_manager_d:none:1:dora,judy Sollten Sie mit dieser Option arbeiten, werden alle Rollen in der Datenbank über das Betriebssystem aktiviert Das Passwort aus der Rolle löschen Um ein Passwort aus einer Rolle zu löschen, nutzen Sie im alter role-befehl die not identified-klausel (siehe folgendes Listing). Standardmäßig arbeiten Rollen ohne Passwort. alter role MANAGER not identified; Rollen aktivieren und deaktivieren Wird der Account eines Anwenders geändert, kann man für diesen Benutzer eine Liste mit Standardrollen anlegen. Dazu nutzen Sie im alter user-befehl die default role- Klausel. Die Standardaktion dieses Befehls setzt alle Rollen eines Benutzers als Standardrollen, und aktiviert sie bei jeder Anmeldung. Hinweis: Über den Datenbankinitialisierungsparameter MAX_ENABLED_ROLES geben Sie an, wie viele Rollen ein Benutzer gleichzeitig aktiviert haben kann.

23 Grundlegendes zur Sicherheit bei Oracle Die Syntax für diesen Teil des alter user-befehls ist: alter user username default role {[role1, role2] [all all except role1, role2][none]}; Wie die Syntax zeigt, kann man einen Benutzereintrag so ändern, dass spezielle Rollen, alle Rollen, alle Rollen mit Ausnahme bestimmter Rollen oder standardmäßig keine Rollen aktiviert werden. Im folgenden Beispiel wird bei jeder Anmeldung von Bob die CLERK-Rolle aktiviert: alter user Bob default role CLERK; Um eine nicht standardmäßige Rolle zu aktivieren, nutzen Sie den set role-befehl: set role CLERK; Daneben können Sie auch die im alter user-befehl angebotenen Klauseln all und all except verwenden: set role all; set role all except CLERK; Wurde eine Rolle mit einem Passwort verknüpft, muss man das Passwort in einer identified by-klausel angeben: set role MANAGER identified by cygnusxi; Um in Ihrer Sitzung eine Rolle zu deaktivieren, benutzen Sie den Befehl set role none (siehe folgendes Listing). Damit werden in Ihrer aktuellen Sitzung alle Rollen deaktiviert. Nach dem Deaktivieren aller Rollen können Sie die gewünschten Rollen neu aktivieren. set role none; Soll der set role none-befehl nur ab und zu ausgeführt werden, sollten Sie den Benutzern die CREATE SESSION-Berechtigung nicht über eine Rolle, sondern direkt zuweisen Einer Rolle Berechtigungen entziehen Um einer Rolle eine Berechtigung zu entziehen, verwenden Sie den weiter oben beschriebenen revoke-befehl. Dazu definieren Sie wie im folgenden Beispiel die Berechtigung, den Objektnamen (falls es sich um eine Objektberechtigung handelt) und den Rollennamen: revoke SELECT on COMFORT from CLERK;

24 18.2 Was ein Anwender weitergeben kann 411 Die Benutzer der CLERK-Rolle können jetzt die COMFORT-Tabelle nicht mehr abfragen Eine Rolle löschen Zum Löschen einer Rolle verwenden Sie den drop role-befehl: drop role MANAGER; drop role CLERK; Damit wird die spezifizierte Rolle mit allen verbundenen Berechtigungen aus der Datenbank gelöscht Das Aktualisieren bestimmter Spalten zulassen Sie können Benutzern die SELECT-Berechtigungen auf bestimmte Spalten gewähren und gleichzeitig dafür sorgen, dass die UPDATE-Berechtigung für weitaus weniger Spalten gilt. Da man die SELECT-Spalten über eine View einschränken kann, benötigen Sie für die weitere Einschränkung der Spalten, auf die über update zugegriffen werden darf, eine spezielle Form des grant-befehls. Hier ein Beispiel für zwei Spalten in der COMFORT-Tabelle: grant update (Noon, Midnight) on COMFORT to Judy; Berechtigungen widerrufen Einmal erteilte Berechtigungen kann man auch wieder entziehen: revoke { object privilege all [privileges]} [(column [, column]... )] [, { object privilege all [privileges]} [(column [, column]... )]]...] on object from {user role} [,{user role}] [cascade constraints] [force]; revoke all löscht alle zuvor aufgeführten Berechtigungen von SELECT bis INDEX. Beim Löschen ausgewählter Berechtigungen bleiben die restlichen Berechtigungen erhalten. Die with grant option wird mit den Berechtigungen widerrufen, mit denen sie erteilt wurde. Hat ein Benutzer für ein Objekt einen referenziellen Integritäts-Constraint definiert, löscht Oracle diese Constraints dann, wenn Sie die Berechtigungen für dieses Objekt mit der Option cascade constraints löschen. Die force-option gilt für benutzerdefinierte Datentypen (siehe Kapitel 33). Die force-option widerruft die EXECUTE-Be-

25 Grundlegendes zur Sicherheit bei Oracle rechtigung auf benutzerdefinierte Datentypobjekte mit Tabellen- oder Typabhängigkeiten; alle abhängigen Objekte werden als ungültig markiert, und die Daten in abhängigen Tabellen bleiben solange unzugänglich, bis die notwendigen Berechtigungen erneut zugewiesen wurden Sicherheit nach Benutzern Der Zugriff auf eine Tabelle kann jedem Benutzer speziell erteilt werden Tabelle für Tabelle und View für View. Daneben gibt es allerdings noch eine zusätzliche Technik, mit der sich dieser Prozess in einigen Fällen wesentlich vereinfachen lässt. Vielleicht erinnern Sie sich noch an die Datensätze in BOOKSHELF_CHECKOUT: select Name, SUBSTR(Title,1,30) from BOOKSHELF_CHECKOUT; NAME SUBSTR(TITLE,1,30) JED HOPKINS INNUMERACY GERHARDT KENTGEN WONDERFUL LIFE DORAH TALBOT EITHER/OR EMILY TALBOT ANNE OF GREEN GABLES PAT LAVAY THE SHIPPING NEWS ROLAND BRANDT THE SHIPPING NEWS ROLAND BRANDT THE DISCOVERERS ROLAND BRANDT WEST WITH THE NIGHT EMILY TALBOT MIDNIGHT MAGIC EMILY TALBOT HARRY POTTER AND THE GOBLET OF PAT LAVAY THE MISMEASURE OF MAN DORAH TALBOT POLAR EXPRESS DORAH TALBOT GOOD DOG, CARL GERHARDT KENTGEN THE MISMEASURE OF MAN FRED FULLER JOHN ADAMS FRED FULLER TRUMAN JED HOPKINS TO KILL A MOCKINGBIRD DORAH TALBOT MY LEDGER GERHARDT KENTGEN MIDNIGHT MAGIC Um jedem Ausleiher den Zugriff auf diese Tabelle zu ermöglichen, aber gleichzeitig dafür zu sorgen, dass jeder nur seine eigenen Daten sehen kann, könnten Sie 19 eigenständige Views anlegen. Dafür müssten Sie in der where-klausel für jede View den entsprechenden Namen hinterlegen und jedem Ausleiher für seine View eine Berechtigung zuweisen. Alternativ können Sie beim Einrichten der View mit der where-klausel die Pseudospalte User anlegen: create view MY_CHECKOUT as select * from BOOKSHELF_CHECKOUT where SUBSTR(Name,1,INSTR(Name,' ')-1) = User;

26 18.2 Was ein Anwender weitergeben kann 413 Der Eigentümer der BOOKSHELF_CHECKOUT-Tabelle kann diese View anlegen und den Benutzern den SELECT-Zugriff gewähren. Danach können die Anwender die BOOKSHELF_CHECKOUT-Tabelle über die MY_CHECKOUT abfragen. Die where-klausel findet den Benutzernamen in der Name-Spalte (siehe die where-klausel), und liefert lediglich die Datensätze dieses Benutzers zurück. Im folgenden Beispiel wird ein Benutzer namens Jed angelegt und erhält den Zugriff auf die MY_CHECKOUT-View. Ein select auf die View liefert nur die von ihm ausgeliehenen Bücher zurück. create user jed identified by hop; User created. grant CREATE SESSION to jed; Grant succeeded. grant select on MY_CHECKOUT to jed; Grant succeeded. connect jed/hop Connected. select * from Practice.MY_CHECKOUT; NAME TITLE CHECKOUTD RETURNEDD JED HOPKINS INNUMERACY 01-JAN JAN-02 JED HOPKINS TO KILL A MOCKINGBIRD 15-FEB MAR-02 Bei jeder Abfrage liefert MY_CHECKOUT die Datensätze in Abhängigkeit von der Pseudospalte User zurück jenes Benutzers von SQL*Plus, der die View gerade abfragt.

27 Grundlegendes zur Sicherheit bei Oracle Public den Zugriff gewähren Anstatt jedem Ausleiher den Zugang zu gewähren, lässt sich der grant-befehl mit public auch so parametrisieren, dass jeder auf diese View zugreifen kann: grant select on MY_CHECKOUT to public; Damit kann jeder auf diese View zugreifen, was übrigens auch für später angelegte Benutzer gilt. Um Zugriff zu dieser View zu erhalten, muss man allerdings noch den Benutzernamen des Eigentümers als Präfix benutzen. Um das zu umgehen, kann der DBA ein öffentliches Synonym anlegen (das einen Namen einrichtet, der für alle Benutzer zugänglich ist dieses Synonym steht für Practice.MY_CHECKOUT): create public synonym MY_CHECKOUT for Practice.MY_CHECKOUT; Ab sofort kann jeder auf MY_CHECKOUT zugreifen, ohne den Schemaeigentümer voranzustellen (in diesem Fall Practice). Dieser Ansatz bietet in punkto Sicherheit eine immense Flexibilität. So können Angestellte in einer Tabelle, die die Gehältern aller Mitarbeiter enthält, beispielsweise nur das eigene Gehalt sehen. Richtet ein Benutzer jedoch eine Tabelle oder View mit demselben Namen wie ein öffentliches Synonym ein, greifen alle zukünftigen SQL-Anweisungen dieses Anwenders auf die neue Tabelle oder View zu, und nicht mehr auf die ursprüngliche Tabelle, für die das öffentliche Synonym angelegt wurde. Hinweis: Alle diese Zugriffe und Aktionen auf Systemebene (beispielsweise Logins) sollte man mit dem Auditing überwachen. Mehr dazu in der Alphabetischen Referenz unter dem Stichwort AUDIT Begrenzte Ressourcen zuweisen Zur Zuweisung bestimmter Ressourcenkontingente in einer Oracle-Datenbank wird im create user- oder alter user-befehl der Parameter quota eingesetzt. In unserem Beispiel wird Bob im Tablespace USERS ein Kontingent von 100MB eingerichtet: alter user Bob quota 100M on USERS; Die Platzkontingente für einen Benutzer können beim Anlegen des Anwenders mit create user festgelegt werden. Soll es für einen Benutzer bezüglich des Speicherplatzes keine Einschränkungen geben, können Sie ihm die Systemberechtigung UNLIMITED TABLESPACE erteilen. Mehr zu diesem Thema finden Sie in der Alphabetischen Referenz unter den Stichwörtern create user und alter user.

28 18.3 Begrenzte Ressourcen zuweisen 415 Mit Profilen lassen sich auch andere Ressourcenbeschränkungen erzwingen. Beispiele sind die CPU-Zeit, die eine Anfrage an Oracle verbrauchen darf. Dazu wird zuerst ein Profil mit den entsprechenden Einstellungen angelegt, und dann einem oder mehreren Benutzern zugewiesen. Mehr dazu in der Alphabetischen Referenz unter create profile und alter user.