vorheriges KapitelInhaltsverzeichnisIndexInfoseitenächstes Kapitel



12


Datenbanksicherheit

Gesucht: Datenbank-Administrator

Populäre Datenbankprodukte und Sicherheit

Wie wird eine Datenbank sicher?

Personal Oracle8 und Sicherheit

Zusammenfassung

Fragen & Antworten

Workshop


Im Mittelpunkt des heutigen Tages steht die Datenbanksicherheit. Insbesondere sehen wir uns verschiedene SQL-Anweisungen und Konstruktionen an, mit denen sich eine relationale Datenbank effektiv verwalten läßt. Wie bei vielen bisher behandelten Themen hängt auch die Implementierung der Sicherheit stark vom verwendeten Datenbank-Managementsystem ab. Bei der Einführung dieses Themas konzentrieren wir uns auf das bekannte Produkt Oracle8. Diese Lektion zeigt Ihnen, wie man ...



Gesucht: Datenbank-Administrator

Sicherheit ist ein oft übersehener Aspekt des Datenbankentwurfs. Die meisten Computerprofis treten in die Computerwelt mit einigen Kenntnissen zur Programmierung oder der Hardware ein und konzentrieren sich vor allem auf diese Bereiche. Wenn Sie zum Beispiel den Auftrag erhalten, ein völlig neues Projekt auszuarbeiten, das offensichtlich in irgendeiner Form einen relationalen Datenbankentwurf erfordert, worin besteht dann Ihr erster Schritt? Nach der Wahl der grundlegenden Hardware- und Softwarekomponenten beginnen Sie wahrscheinlich mit dem Entwurf der grundlegenden Datenbank für das Projekt. Diese Phase wird nacheinander unter mehrere Mitarbeiter aufgeteilt - einer von ihnen ist ein Entwickler für grafische Benutzeroberflächen, ein anderer gestaltet die Routinen auf einer systemnahen Ebene. Vielleicht fällt Ihnen, nachdem Sie dieses Buch gelesen haben, die Aufgabe zu, die SQL-Abfragen als Kern der Anwendung bereitzustellen. Mit dieser Aufgabe ist gleichzeitig die Verantwortlichkeit für die eigentliche Verwaltung und Wartung der Datenbank verbunden.


Oftmals werden nur wenige Gedanken an die eigentliche Produktionsphase der Anwendung verschwendet. Was passiert, wenn vielen Benutzern erlaubt ist, die Anwendung über ein weites Netzwerk (WAN) zu verwenden? Mit den heute üblichen leistungsfähigen Softwarepaketen und mit Technologien wie ODBC von Microsoft kann jeder Benutzer mit Zugriff auf das Netzwerk einen Weg zu Ihrer Datenbank finden. (Wir reden hier gar nicht von der Komplexität, wenn Ihre Firma das LAN mit dem Internet oder einem anderen großflächigen Netzwerk verbinden will!) Sind Sie auf diese Situation vorbereitet?


Glücklicherweise stellen die Softwarehersteller die meisten Werkzeuge bereit, die Sie für die Behandlung dieses Sicherheitsproblems benötigen. Jede neue Version eines Netzwerkbetriebssystems stellt sich strengeren Sicherheitsanforderungen als seine Vorgänger. Außerdem bauen die meisten Datenbankanbieter bis zu einem gewissen Maße Sicherheitsvorkehrungen in ihre Produkte ein, die unabhängig von den Sicherheitsmechanismen des Betriebssystems oder Netzwerks arbeiten. Die Implementierung dieser Sicherheitsmerkmale variiert allerdings stark von Produkt zu Produkt.



Populäre Datenbankprodukte und Sicherheit

Wie Sie mittlerweile wissen, kämpfen viele relationale Datenbanksysteme um Ihre Gunst. Jeder Anbieter möchte Sie kurz- und langfristig binden. Während der Entwicklungsphase eines Projekts können Sie eventuell eine kleine Anzahl von Produktlizenzen für das Testen, die Entwicklung usw. erwerben. Allerdings kann die Gesamtzahl der Lizenzen, die für Ihre Produktionsdatenbank erforderlich ist, Hunderte oder sogar Tausende erreichen. Wenn Sie sich darüber hinaus für ein bestimmtes Datenbankprodukt entscheiden, werden Sie höchstwahrscheinlich mehrere Jahre damit arbeiten. Bei der Untersuchung dieser Produkte sollte man daher einige Punkte beachten:


Diese Produktübersicht soll verdeutlichen, daß nicht alle Programme für alle Anwendungen geeignet sind. Wenn Sie in einer Büroumgebung arbeiten, ist Ihr Handlungsspielraum vielleicht eingeschränkt. Faktoren wie Kosten und Leistung sind extrem wichtig. Ohne adäquate Sicherheitsmaßnahmen können allerdings alle Einsparungen an der Datenbank leicht von Sicherheitsproblemen zunichte gemacht werden.



Wie wird eine Datenbank sicher?

Bis jetzt haben Sie sich nicht um die »Sicherheit« der erzeugten Datenbank gekümmert. Ist es Ihnen schon einmal passiert, daß Sie andere Benutzer davon abhalten wollten, sich an den von Ihnen so sorgfältig eingegebenen Datenbankinformationen zu schaffen zu machen? Wie reagieren Sie, wenn Sie sich eines morgens auf dem Server anmelden und feststellen, daß die so mühevoll erstellte Datenbank gelöscht wurde? (Erinnern Sie sich, wie unauffällig der Befehl DROP DATABASE arbeitet.) In dieser Lektion beschäftigen wir uns näher damit, wie ein bekanntes Datenbank-Managementsystem (Personal Oracle8) die Einrichtung einer sicheren Datenbank erlaubt. Die hier gewonnenen Kenntnisse lassen sich auf andere Datenbank-Managementsysteme übertragen, so daß Sie dieses Kapitel auch lesen sollten, wenn Oracle nicht das System Ihrer Wahl darstellt.


Beachten Sie die folgenden Punkte, wenn Sie Ihr Sicherheitssystem planen:

  • Wer übernimmt die Rolle des Datenbank-Administrators (DBA)?
  • Wie viele Benutzer müssen voraussichtlich auf die Datenbank zugreifen?
  • Welche Benutzer benötigen welche Privilegien und welche Rollen?
  • Wie entfernen Sie Benutzer, die keinen Zugriff mehr auf Ihre Datenbank benötigen?

Personal Oracle8 und Sicherheit

Oracle8 implementiert die Sicherheit mit drei Konstruktionen:



Benutzer erzeugen

Benutzer sind Kontennamen, die sich auf der Oracle-Datenbank anmelden dürfen. Die SQL-Syntax für das Erstellen eines neuen Benutzers sieht folgendermaßen aus:


Wenn man die Option BY Kennwort wählt, fordert das System den Benutzer auf, bei jeder Anmeldung ein Kennwort einzugeben. Erzeugen Sie als Beispiel einen Benutzernamen für sich selbst:


SQL> CREATE USER Bryan IDENTIFIED BY CUTIGER;

Benutzer wurde angelegt.


Immer wenn ich mich mit Benutzername Bryan anmelde, werde ich aufgefordert, mein Kennwort einzugeben: CUTIGER.


Wählt man die Option EXTERNALLY, verläßt sich Oracle auf den Anmeldenamen und das Kennwort aus dem Computersystem des Benutzers. Mit der Anmeldung in Ihr System haben Sie sich praktisch auch bei Oracle angemeldet.


Einige Implementierungen erlauben die Verwendung des externen Kennworts bzw. des Systemkennworts als Standardkennwort bei Einsatz von SQL (IDENTIFIED EXTERNALLY). Allerdings empfehlen wir, daß Sie den Benutzer zur Eingabe eines Kennworts mit der Klausel IDENTIFIED BY auffordern (IDENTIFIED BY Kennwort).

Aus dem restlichen Teil der Syntax für CREATE USER läßt sich erkennen, daß man in Oracle auch Standardwerte für Tabellenbereiche und Quoten einrichten kann. Mehr zu diesen Themen entnehmen Sie bitte der Oracle-Dokumentation.


Wie bei jedem anderen CREATE-Befehl, den Sie bisher in diesem Buch kennengelernt haben, gibt es auch hier einen ALTER USER-Befehl:


Mit diesem Befehl lassen sich alle Optionen des Benutzers ändern, einschließlich Kennwort und Profil. Um zum Beispiel das Kennwort von Bryan zu ändern, geben Sie folgendes ein:


SQL> ALTER USER Bryan
2 IDENTIFIED BY ROSEBUD;

Benutzer wurde geändert.


Mit der folgenden Anweisung ändert man den Standardtabellenbereich:


SQL> ALTER USER RON
2 DEFAULT TABLESPACE USERS;

Benutzer wurde geändert.


Um einen Benutzer zu entfernen, führt man einfach den Befehl DROP USER aus, der den Eintrag für den Benutzer aus der Systemdatenbank löscht. Die Syntax für diesen Befehl lautet:


Die Option CASCADE löscht zusammen mit dem Benutzerkonto alle Objekte, die zu Benutzername gehören. Falls der Benutzer noch Objekte besitzt und die Option CASCADE nicht angegeben ist, wird der Benutzer nicht gelöscht.



Rollen erzeugen

Eine Rolle ist ein Privileg oder Satz von Privilegien, die einem Benutzer die Ausführung bestimmter Funktionen in der Datenbank erlauben. Mit der folgenden Syntax läßt sich einem Benutzer eine Rolle zuweisen:


Ist die Option WITH ADMIN OPTION angegeben, kann dieser Benutzer Rollen an andere Benutzer vergeben.


Wenn Sie sich mit dem bereits weiter oben erzeugten Konto im System anmelden, haben Sie den Spielraum Ihrer Berechtigungen ausgeschöpft. Sie können sich zwar anmelden, aber das ist schon alles. Oracle erlaubt Ihnen die Registrierung in einer von drei Rollen:


Diese drei Rollen beinhalten verschiedene Privilegstufen.


Wenn man über die geeigneten Privilegien verfügt, kann man eine eigene Rolle erzeugen, der Rolle Privilegien zuweisen und dann diese Rolle an einen Benutzer übertragen, um dessen Sicherheitsbefugnisse zu erweitern.


Die Connect-Rolle

Die Connect-Rolle (connect - verbinden) kann man sich als Rolle auf Eintrittsebene vorstellen. Einem Benutzer, dem der Zugriff in der Connect-Rolle gewährt wurde, lassen sich verschiedene Privilegien zuteilen, die ihm Aktionen mit einer Datenbank gestatten.


SQL> GRANT CONNECT TO Bryan;

Benutzerzugriff (Grant) wurde erteilt.


Mit der Connect-Rolle kann der Benutzer in Tabellen, die zu anderen Benutzern gehören, Datensätze auswählen, einfügen, aktualisieren und löschen (nachdem die geeigneten Berechtigungen erteilt wurden). Der Benutzer kann auch Tabellen, Sichten, Cluster und Synonyme erzeugen.



Die Resource-Rolle

Die Resource-Rolle gibt dem Benutzer erweiterten Zugriff auf Oracle-Datenbanken. Neben den Berechtigungen, die mit der Connect-Rolle verbunden sind, können Resource-Rollen auch die Berechtigungen zum Erstellen von Prozeduren, Triggern und Indizes umfassen.


SQL> GRANT RESOURCE TO Bryan;

Benutzerzugriff (Grant) wurde erteilt.



Die DBA-Rolle

Diese Rolle schließt alle Privilegien ein. Benutzer mit dieser Rolle können praktisch alle Operationen am Datenbanksystem ausführen. Man sollte die Anzahl der Benutzer mit dieser Rolle minimieren, um die Systemintegrität abzusichern.


SQL> GRANT DBA TO Bryan;

Benutzerzugriff (Grant) wurde erteilt.


Nach den drei obigen Schritten verfügt der Benutzer Bryan über die Rollen Connect, Resource und DBA. Da die DBA-Rolle die beiden anderen Rollen einschließt, kann man die Rollen Connect und Resource löschen:


SQL> REVOKE CONNECT FROM Bryan;

Benutzerzugriff wurde aufgehoben (Revoke).

SQL> REVOKE RESOURCE FROM Bryan;

Benutzerzugriff wurde aufgehoben (Revoke).


Bryan kann nun alle Operationen, die er für erforderlich hält, in seiner Rolle als DBA ausführen.



Benutzerprivilegien

Nachdem Sie festgelegt haben, welche Rollen Ihre Benutzer erhalten, entscheiden Sie als nächstes, welche Berechtigungen diese Benutzer in bezug auf Datenbankobjekte bekommen. (Oracle8 nennt diese Berechtigungen Privilegien.) Die Arten der Privilegien hängen von der jeweils zugeteilten Rolle ab. Wenn man ein Objekt erzeugt, kann man Privilegien auf diesem Objekt an andere Benutzer gewähren, solange deren Rolle den Zugriff auf dieses Privileg erlaubt. Oracle definiert zwei Typen von Privilegien, die sich Benutzern zuteilen lassen: Systemprivilegien und Objektprivilegien. (Siehe dazu die Tabellen 12.1 und 12.2.)


Systemprivilegien wirken systemweit. Die Syntax für die Gewährung eines Systemprivilegs lautet:


Die Option WITH ADMIN OPTION erlaubt dem Berechtigten, dieses Privileg einem anderen Benutzer zu übertragen.



Benutzerzugriff auf Sichten

Der folgende Befehl erlaubt allen Benutzern des Systems den CREATE VIEW-Zugriff innerhalb ihres eigenen Schemas.


SQL> GRANT CREATE VIEW
2 TO PUBLIC;


Benutzerzugriff (Grant) wurde erteilt.


Das Schlüsselwort PUBLIC (öffentlich) bedeutet, daß jeder Benutzer die Privilegien CREATE VIEW erhält. Diese Systemprivilegien bieten dem Berechtigten natürlich den Zugriff auf nahezu alle Systemeinstellungen. Daher sollte man Systemprivilegien nur speziellen Benutzern gewähren bzw. Benutzern, die tatsächlich über diese Privilegien verfügen müssen. Tabelle 12.1 zeigt einen Auszug der Systemprivilegien, die Sie in den Hilfedateien zu Personal Oracle8 finden.

Vergeben Sie öffentliche (public) Privilegien mit Bedacht. Damit erhalten nämlich alle Benutzer Zugriff auf Datenbankprivilegien, die Sie ihnen vielleicht gar nicht zugestehen möchten.

Tabelle 12.1: Systemprivilegien in Oracle8

Systemprivileg

Erlaubte Operationen

ALTER ANY INDEX

Erlaubt den Berechtigten, jeden Index in einem beliebigen Schema zu verändern.

ALTER ANY PROCEDURE

Erlaubt den Berechtigten, alle gespeicherten Prozeduren, Funktionen oder Pakete in einem beliebigen Schema zu verändern.

ALTER ANY ROLE

Erlaubt den Berechtigten, jede Rolle in der Datenbank zu ändern.

ALTER ANY TABLE

Erlaubt den Berechtigten, jede Tabelle oder Sicht in dem Schema zu ändern.

ALTER ANY TRIGGER

Erlaubt den Berechtigten, jeden Datenbank-Trigger in einem beliebigen Schema zu aktivieren, zu deaktivieren oder zu kompilieren.

ALTER DATABASE

Erlaubt den Berechtigten, die Datenbank zu ändern.

ALTER USER

Erlaubt den Berechtigten, jeden Benutzer zu ändern. Dieses Privileg autorisiert den Berechtigten, das Kennwort oder die Autorisierungsmethode eines anderen Benutzers zu ändern, einem beliebigen Tabellenbereich Quoten zuzuweisen, Standard- und temporäre Tabellenbereiche festzulegen sowie ein Profil und Standardrollen zuzuweisen.

CREATE ANY INDEX

Erlaubt den Berechtigten, einen Index auf einer beliebigen Tabelle in einem beliebigen Schema zu erzeugen.

CREATE ANY PROCEDURE

Erlaubt den Berechtigten, gespeicherte Prozeduren, Funktionen und Pakete in einem beliebigen Schema zu ändern.

CREATE ANY TABLE

Erlaubt den Berechtigten, Tabellen in einem beliebigen Schema zu erzeugen. Der Eigentümer des Schemas, das die Tabelle enthält, muß über Platzquoten auf dem Tabellenbereich zur Aufnahme der Tabelle verfügen.

CREATE ANY TRIGGER

Erlaubt den Berechtigten, einen Datenbank-Trigger in einem beliebigen Schema, das mit einer Tabelle in einem beliebigen Schema verbunden ist, zu erzeugen.

CREATE ANY VIEW

Erlaubt den Berechtigten, Sichten in einem beliebigen Schema zu erzeugen.

CREATE PROCEDURE

Erlaubt den Berechtigten, Prozeduren, Funktionen und Pakete in ihrem eigenen Schema zu erzeugen.

CREATE PROFILE

Erlaubt den Berechtigten, Profile zu erzeugen.

CREATE ROLE

Erlaubt den Berechtigten, Rollen zu erzeugen.

CREATE SYNONYM

Erlaubt den Berechtigten, Synonyme in ihren eigenen Schemas zu erzeugen.

CREATE TABLE

Erlaubt den Berechtigten, Tabellen in ihren eigenen Schemas zu erzeugen. Um eine Tabelle zu erzeugen, müssen die Berechtigten außerdem über Platzquoten auf dem Tabellenbereich für die Aufnahme der Tabelle verfügen.

CREATE TRIGGER

Erlaubt den Berechtigten, einen Datenbank-Trigger in ihren eigenen Schemas zu erzeugen.

CREATE USER

Erlaubt den Berechtigten, Benutzer zu erzeugen. Dieses Privileg erlaubt auch dem Erzeuger, einem beliebigen Tabellenbereich Quoten zuzuweisen, Standard- und temporäre Tabellenbereiche festzulegen sowie ein Profil als Teil einer CREATE USER-Anweisung zuzuweisen.

CREATE VIEW

Erlaubt den Berechtigten, Sichten in ihren eigenen Schemas zu erzeugen.

DELETE ANY TABLE

Erlaubt den Berechtigten, Zeilen aus Tabellen oder Sichten in einem beliebigen Schema zu löschen oder Tabellen in einem beliebigen Schema abzuschneiden.

DROP ANY INDEX

Erlaubt den Berechtigten, Indizes in einem beliebigen Schema zu löschen.

DROP ANY PROCEDURE

Erlaubt den Berechtigten, gespeicherte Prozeduren, Funktionen oder Pakete in einem beliebigen Schema zu löschen.

DROP ANY ROLE

Erlaubt den Berechtigten, Rollen zu löschen.

DROP ANY SYNONYM

Erlaubt den Berechtigten, private Synonyme in einem beliebigen Schema zu löschen.

DROP ANY TABLE

Erlaubt den Berechtigten, Tabellen in einem beliebigen Schema zu löschen.

DROP ANY TRIGGER

Erlaubt den Berechtigten, Datenbank-Trigger in einem beliebigen Schema zu löschen.

DROP ANY VIEW

Erlaubt den Berechtigten, Sichten in einem beliebigen Schema zu löschen.

DROP USER

Erlaubt den Berechtigten, Benutzer zu löschen.

EXECUTE ANY PROCEDURE

Erlaubt den Berechtigten, (eigenständige oder im Paket enthaltene) Prozeduren oder Funktionen auszuführen oder öffentliche Paketvariablen in einem beliebigen Schema zu referenzieren.

GRANT ANY PRIVILEGE

Erlaubt den Berechtigten, ein beliebiges Systemprivileg zuzuteilen.

GRANT ANY ROLE

Erlaubt den Berechtigten, eine beliebige Rolle in der Datenbank zuzuteilen.

INSERT ANY TABLE

Erlaubt den Berechtigten, Zeilen in Tabellen und Sichten in einem beliebigen Schema einzufügen.

LOCK ANY TABLE

Erlaubt den Berechtigten, Tabellen und Sichten in einem beliebigen Schema zu sperren.

SELECT ANY SEQUENCE

Erlaubt den Berechtigten, Sequenzen in einem beliebigen Schema zu referenzieren.

SELECT ANY TABLE

Erlaubt den Berechtigten, Tabellen, Sichten oder Snapshots in einem beliebigen Schema abzufragen.

UPDATE ANY ROWS

Erlaubt den Berechtigten, Zeilen in Tabellen zu aktualisieren.

Objektprivilegien sind Privilegien, die man bezüglich spezieller Datenbankobjekte anwenden kann. Tabelle 12.2 listet die Objektprivilegien in Oracle8 auf.


Tabelle 12.2: Unter Oracle8 aktivierbare Objektprivilegien

Privileg

ALL

ALTER

DELETE

EXECUTE

INDEX

INSERT

READ

REFERENCES

SELECT

UPDATE

Mit der folgenden Form der GRANT-Anweisung gewähren Sie anderen Benutzern Zugriff auf Ihre Tabellen:


Um die Objektprivilegien wieder zu löschen, die Sie anderen Benutzern gewährt haben, setzen Sie den REVOKE-Befehl mit der folgenden Syntax ein:



Vom Erzeugen einer Tabelle bis zum Gewähren von Rollen

Erzeugen Sie eine Tabelle namens GEHAELTER mit der folgenden Struktur:


SQL> CREATE TABLE GEHAELTER {
2 NAME CHAR(30),
3 GEHALT NUMBER,
4 ALT NUMBER);


Tabelle wurde angelegt.


In der Tabelle steht ALT für das Alter des Mitarbeiters. Wenn man die Bezeichnung ALTER verwendet, müßte man "ALTER" schreiben, da ALTER zu den Schlüsselwörtern von Oracle8 (und SQL) gehört und in Anführungszeichen zu setzen ist, wenn man diese Funktion aufheben möchte. Allerdings unterstützt Oracle8 Navigator keine Objektbezeichner in Anführungszeichen, so daß wir hier generell auf diese Schreibweise verzichten.

Erzeugen Sie nun die beiden Benutzer Jack und Jill:


SQL> CREATE USER Jack IDENTIFIED BY Jack;

Benutzer wurde angelegt.

SQL> CREATE USER Jill IDENTIFIED BY Jill;

Benutzer wurde angelegt.

SQL> GRANT CONNECT TO Jack;

Benutzerzugriff (Grant) wurde erteilt.

SQL> GRANT RESOURCE TO Jill;

Benutzerzugriff (Grant) wurde erteilt.


Bis jetzt haben Sie zwei Benutzer erzeugt und jedem eine andere Rolle zugeteilt. Diese Benutzer verfügen damit über unterschiedliche Möglichkeiten, mit der Datenbank zu arbeiten. Erzeugen Sie zunächst die Tabelle GEHAELTER mit den folgenden Informationen:

SQL> SELECT * FROM GEHAELTER;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 61000 55


Dieser Tabelle können Sie jetzt verschiedene Privilegien zuordnen. Für das Beispiel treffen wir willkürliche Annahmen. Momentan haben Sie DBA-Privilegien und können jedes Systemprivileg zuteilen. Selbst, wenn Sie nicht über DBA-Privilegien verfügen, können Sie trotzdem Objektprivilegien auf der Tabelle GEHAELTER gewähren, da Sie der Eigentümer dieser Tabelle sind (vorausgesetzt, daß Sie sie erzeugt haben).

Da Jack nur zur Connect-Rolle gehört, soll er auch nur SELECT-Privilegien erhalten.


SQL> GRANT SELECT ON GEHAELTER TO JACK;

Benutzerzugriff (Grant) wurde erteilt.


Da Jill zur Resource-Rolle gehört, erlauben Sie ihr, bestimmte Daten in der Tabelle auszuwählen und einzufügen. Um die Sache etwas spannender zu gestalten, erlauben Sie Jill, Werte nur im Feld GEHALT der Tabelle GEHAELTER zu aktualisieren.


SQL> GRANT SELECT, UPDATE(GEHALT) ON GEHAELTER TO JILL;

Benutzerzugriff (Grant) wurde erteilt.


Nachdem nun diese Tabelle und die Benutzer erzeugt wurden, müssen Sie darauf achten, wie ein Benutzer auf eine Tabelle, die durch einen anderen Benutzer erzeugt wurde, zugreift. Sowohl Jack als auch Jill haben SELECT-Zugriff auf die Tabelle GEHAELTER erhalten. Wenn Jack jedoch auf die Tabelle GEHAELTER zugreifen will, bekommt er die Mitteilung, daß die Tabelle nicht existiert, weil Oracle den Benutzernamen oder das Schema für den Besitzer der Tabelle vor dem Tabellennamen erwartet.



Eine Tabelle qualifizieren

Notieren Sie sich den Benutzernamen, den Sie beim Erzeugen der Tabelle GEHAELTER verwendet haben (meiner war Bryan). Damit Jack Daten in der Tabelle GEHAELTER selektieren kann, muß er die Tabelle GEHAELTER mit diesem Benutzernamen ansprechen.


SQL> SELECT * FROM GEHAELTER;
SELECT * FROM GEHAELTER
*
FEHLER in Zeile 1:
ORA-00942: Tabelle oder View nicht vorhanden


Hier erhält Jack eine Warnung, daß die Tabelle nicht existiert. Geben Sie nun den Benutzernamen des Eigentümers an, um die Tabelle zu identifizieren:


SQL> SELECT *
2 FROM Bryan.GEHAELTER;
NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 61000 55


Die Abfrage funktioniert demnach. Testen Sie nun die Zugriffsprivilegien von Jill. Zuerst melden Sie sich als Jack ab und melden sich wieder als Jill an (mit dem Kennwort Jill).

SQL> SELECT * FROM Bryan.GEHAELTER;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 61000 55


Das hat hervorragend geklappt. Versuchen Sie nun, einen neuen Datensatz in die Tabelle einzufügen.


SQL> INSERT INTO Bryan.GEHAELTER
2 VALUES('JOE',85000,38);
INSERT INTO Bryan.GEHAELTER
*
FEHLER in Zeile 1:
ORA-01031: Unzureichende Berechtigungen


Diese Operation ist gescheitert, da Jill nicht über INSERT-Privilegien für die Tabelle GEHAELTER verfügt.

SQL> UPDATE Bryan.GEHAELTER
2 SET ALT = 42
3 WHERE NAME = 'JOHN';
UPDATE Bryan.GEHAELTER
*
FEHLER in Zeile 1:
ORA-01031: Unzureichende Berechtigungen


Auch hier trifft das gleiche zu: Jill hat versucht, die ihr gewährten Privilegien zu umgehen. Natürlich fängt Oracle diesen Fehler ab und teilt ihr das unverzüglich mit.

SQL> UPDATE Bryan.GEHAELTER
2 SET GEHALT = 35000
3 WHERE NAME = 'JOHN';

1 Zeile wurde aktualisiert.

SQL> SELECT *
2 FROM Bryan.GEHAELTER;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 35000 55


Die Aktualisierung funktioniert nun, solange Jill bei den Privilegien bleibt, die ihr gewährt wurden.


Sichten für Sicherheitszwecke

Wie bereits in Lektion 10 erwähnt, sind Sichten virtuelle Tabellen, mit denen sich die Daten in einer von der physikalischen Speicherung in der Datenbank abweichenden Form darstellen lassen. Heute lernen Sie mehr darüber, wie man Sicherheitsmaßnahmen mit Hilfe von Sichten implementiert. Zuerst erläutern wir aber, wie man SQL-Anweisungen mit Sichten vereinfachen kann.


Im letzten Abschnitt haben Sie gelernt, daß der Referenz auf ein Objekt der Benutzername voranzustellen ist, wenn ein Benutzer auf eine Tabelle oder ein Datenbankobjekt zugreifen möchte und er nicht selbst der Eigentümer der Tabelle bzw. des Objekts ist. Dieses Verfahren ist recht umständlich - insbesondere wenn man mehrere SQL-Abfragen nacheinander schreibt. Schwerer wiegt aber der Nachteil, daß neue Benutzer den Eigentümer einer Tabelle erst bestimmen müssen, bevor sie den Inhalt einer Tabelle auswählen können. Und das möchte man natürlich den Benutzern ersparen. Eine einfache Lösung zeigt der folgende Absatz.



Eine Lösung für das Qualifizieren einer Tabelle oder Sicht

Nehmen wir an, daß Sie sich als Jack angemeldet haben, Ihr Freund aus den vorherigen Beispielen. Damit Jack den Inhalt der Tabelle GEHAELTER einsehen kann, muß er die folgende Anweisung verwenden:


SQL> SELECT *
2 FROM Bryan.GEHAELTER;


NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 35000 55


Wenn Sie eine Sicht namens GEHALT_SICHT erzeugen, kann ein Benutzer einfach aus dieser Sicht auswählen.


SQL> CREATE VIEW GEHALT_SICHT
2 AS SELECT *
3 FROM Bryan.GEHAELTER;

View wurde angelegt.

SQL> SELECT * FROM GEHALT_SICHT;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 35000 55


Die obige Abfrage gibt die gleichen Werte zurück wie die Datensätze aus Bryan.GEHAELTER.


Synonyme anstelle von Sichten

SQL stellt auch ein als Synonym bezeichnetes Objekt bereit. Ein Synonym ist ein Alias für eine Tabelle und vereinfacht die Eingabe (das heißt reduziert die erforderlichen Tastenbetätigungen), wenn man eine Tabelle in einer SQL-Anweisung verwendet. Es gibt zwei Typen von Synonymen: private und öffentliche (public). Jeder Benutzer mit der Resource-Rolle kann ein privates Synonym erzeugen. Andererseits kann nur ein Benutzer mit der DBA-Rolle ein öffentliches Synonym erzeugen.


Die Syntax für ein öffentliches Synonym lautet wie folgt:


Im obigen Beispiel könnten Sie das gleiche Ergebnis auch mit dem folgenden Befehl erhalten:


SQL> CREATE PUBLIC SYNONYM GEHALT FOR GEHAELTER;

Synonym wurde angelegt.


Melden Sie sich ab und wieder als Jack an. Geben Sie dann die folgende Anweisung ein:


SQL> SELECT * FROM GEHALT;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29
JILL 48000 42
JOHN 35000 55



Sicherheitsprobleme mit Sichten lösen

Nehmen wir an, daß Sie sowohl Jack als auch Jill den Zugang zur Tabelle GEHAELTER entziehen möchten. Diese geänderte Situation läßt sich mit Sichten realisieren. Damit haben dann Jack und Jill nur Zugriff auf die eigenen Informationen.


SQL> CREATE VIEW JACK_GEHALT AS
2 SELECT * FROM Bryan.GEHAELTER
3 WHERE NAME = 'JACK';

View wurde angelegt.


SQL> CREATE VIEW JILL_GEHALT AS
2 SELECT * FROM Bryan.GEHAELTER
3 WHERE NAME = 'JILL';

View wurde angelegt.


SQL> GRANT SELECT ON JACK_GEHALT
2 TO JACK;

Benutzerzugriff (Grant) wurde erteilt.


SQL> GRANT SELECT ON JILL_GEHALT
2 TO JILL;

Benutzerzugriff (Grant) wurde erteilt.


SQL> REVOKE SELECT ON GEHAELTER FROM JACK;

Benutzerzugriff wurde aufgehoben (Revoke).


SQL> REVOKE SELECT ON GEHAELTER FROM JILL;

Benutzerzugriff wurde aufgehoben (Revoke).


Melden Sie sich nun als Jack an, und testen Sie die für ihn erzeugte Sicht.


SQL> SELECT * FROM Bryan.JACK_GEHALT;

NAME GEHALT ALT
------------------------------ --------- ---------
JACK 35000 29


SQL> SELECT * FROM PERKINS.GEHAELTER;
SELECT * FROM PERKINS.GEHAELTER
*
FEHLER in Zeile 1:
ORA-00942: Tabelle oder View nicht vorhanden


Melden Sie sich von Jacks Konto ab, und testen Sie das Konto von Jill:


SQL> SELECT * FROM Bryan.JILL_GEHALT;

NAME GEHALT ALT
------------------------------ --------- ---------
JILL 48000 42


Der Zugriff auf die Tabelle GEHAELTER wird hier vollständig durch Sichten kontrolliert. SQL erlaubt es, diese Sichten nach Bedarf zu erzeugen und dann Berechtigungen an andere Benutzer zu vergeben - ein sehr flexibles Verfahren.

Es dürfte nun klar sein, warum man die Anzahl der Benutzer mit DBA-Rollen auf einem Minimum halten sollte. Einem Benutzer mit dieser Zugriffsebene stehen alle Befehle und Operationen innerhalb der Datenbank uneingeschränkt zur Verfügung. Beachten Sie jedoch, daß Sie bei Oracle und Sybase den Zugriff auf DBA-Ebene (oder SA-Ebene in Sybase) haben müssen, um Daten in die Datenbank zu importieren bzw. aus ihr zu exportieren.


Die Klausel WITH GRANT OPTION

Was passiert nun, wenn Jill ihr UPDATE-Privileg auf Jack zu übertragen versucht? Auf den ersten Blick sieht es so aus, daß Jill dieses Privileg an andere Benutzer weitergeben kann, da ihr ja das UPDATE-Privileg anvertraut wurde. Wenn man allerdings die GRANT-Anweisung wie weiter oben gezeigt verwendet, kann Jill ihre Privilegien nicht an andere weitergeben:


SQL> GRANT SELECT, UPDATE(GEHALT) ON Bryan.GEHAELTER TO Jill;


Die Syntax für die weiter oben angeführte GRANT-Anweisung lautet:


Es kommt auf die Klausel WITH GRANT OPTION am Ende der GRANT-Anweisung an. Wenn man Objektprivilegien gewährt und WITH GRANT OPTION angibt, lassen sich diese Privilegien an andere Benutzer weitergeben. Zum Beispiel erlauben Sie Jill mit der folgenden Anweisung, das UPDATE-Privileg an Jack weiterzugeben:


SQL> GRANT SELECT, UPDATE(GEHALT)
2 ON Bryan.GEHAELTER TO JILL
3 WITH GRANT OPTION;


Benutzerzugriff (Grant) wurde erteilt.


Jill könnte sich dann anmelden und den folgenden Befehl ausführen:


SQL> GRANT SELECT, UPDATE(GEHALT)
2 ON Bryan.GEHAELTER TO JACK;

Benutzerzugriff (Grant) wurde erteilt.



Zusammenfassung

Sicherheit ist ein oft vernachlässigtes Thema, das bei unzureichender Planung und Verwaltung viele Probleme in sich birgt. Zum Glück bietet SQL verschiedene Befehle, um Sicherheitsmechanismen in einer Datenbank zu realisieren.


Mit dem Befehl CREATE USER legt man einen Benutzer neu an und richtet damit einen Benutzernamen und ein Kennwort für den Benutzer ein. Nach dem Einrichten des Benutzerkontos ist diesem Benutzer eine Rolle zuzuweisen, damit er überhaupt Arbeiten ausführen kann. Oracle8 kennt die Rollen Connect, Resource und DBA. Jede Rolle verfügt über unterschiedliche Zugriffsebenen auf die Datenbank, wobei Connect die niedrigste Ebene darstellt und die DBA-Rolle uneingeschränkten Zugriff bietet.


Der Befehl GRANT gibt einem Benutzer Berechtigungen oder Privilegien. Mit dem Befehl REVOKE kann man dem Benutzer diese Berechtigungen oder Privilegien entziehen. Es gibt zwei Typen von Privilegien: Objektprivilegien und Systemprivilegien. Die Systemprivilegien sollten streng überwacht und nicht an unerfahrene Benutzer vergeben werden. Erhält ein unerfahrener Benutzer Zugriff auf alle Befehle, kann er (vielleicht auch versehentlich) Daten oder Datenbanken zerstören, die Sie sorgfältig im Schweiße Ihres Angesichts aufgebaut haben. Mit Objektprivilegien gewährt man den Benutzern Zugriff auf einzelne Objekte, die im Datenbankschema des Besitzers existieren.


Diese Methoden und SQL-Anweisungen bieten dem SQL-Benutzer eine breite Palette von Werkzeugen für das Einrichten der Systemsicherheit. Obwohl wir uns auf die Sicherheitsaspekte von Oracle8 konzentriert haben, kann man einen großen Teil des Gelernten auch auf andere Datenbanksysteme übertragen. Denken Sie einfach daran, daß es unabhängig vom konkret eingesetzten Datenbankprodukt allein darauf ankommt, ein bestimmtes Sicherheitsniveau durchzusetzen.



Fragen & Antworten

Frage:

Ich verstehe zwar den Bedarf an Sicherheit, aber treibt es Oracle nicht ein bißchen zu weit damit?

Antwort:

Nein, insbesondere in größeren Anwendungen mit mehreren Benutzern. Da verschiedene Benutzer unterschiedliche Arbeiten in der Datenbank zu verrichten haben, sollte man die Benutzer gezielt auf das einschränken, was sie tun dürfen und was nicht. Die Benutzer sollten nur die notwendigen Rollen und Privilegien erhalten, die sie für ihre Arbeit brauchen.

Frage:

Es scheint ein Sicherheitsproblem zu geben, weil der DBA, der meine ID erzeugt hat, auch über mein Kennwort informiert ist. Stimmt das?

Antwort:

Ja, das ist richtig. Der DBA erzeugt die IDs und die Kennwörter. Demzufolge sollten die Benutzer mit dem Befehl ALTER USER ihre ID und ihr Kennwort unmittelbar nach Erhalt dieser Daten ändern.


Workshop


Kontrollfragen

1. Was ist an der folgenden Anweisung falsch?


SQL> GRANT CONNECTION TO DAVID;


2. Richtig oder falsch (und warum): Das Löschen eines Benutzers bewirkt, daß alle Objekte, die dieser Benutzer besitzt, ebenfalls gelöscht werden.


3. Was passiert, wenn man eine Tabelle erzeugt und SELECT-Privilegien für diese Tabelle öffentlich gewährt?


4. Ist die folgende SQL-Anweisung korrekt?


SQL> CREATE USER RON
IDENTIFIED BY RON;


5. Ist die folgende SQL-Anweisung korrekt?


SQL> ALTER RON
IDENTIFIED BY RON;


6. Ist die folgende SQL-Anweisung korrekt?


SQL> GRANT CONNECT, RESOURCE TO RON;


7. Wer kann aus einer Tabelle auswählen, wenn Sie der Eigentümer dieser Tabelle sind?



Übung

Experimentieren Sie mit der Sicherheit Ihres Datenbanksystems, indem Sie eine Tabelle und einen Benutzer erzeugen. Geben Sie diesem Benutzer verschiedene Privilegien, und entziehen Sie sie ihm dann wieder.



Ein Imprint des Markt&Technik Buch- und Software-Verlag GmbH.
Elektronische Fassung des Titels: SQL in 21 Tagen, ISBN: 3-8272-2020-3


vorheriges KapitelTop Of PageInhaltsverzeichnisIndexInfoseitenächstes Kapitel