Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Um einen wirkungsvollen Schutz der Vertraulichkeit und Integrität der Daten einer Datenbank zu erreichen, müssen eine Reihe von Maßnahmen umgesetzt werden. Neben einer Zugangskontrolle der Datenbank, die in M 2.128 Zugangskontrolle einer Datenbank beschrieben wird, sind dies im wesentlichen die folgenden Möglichkeiten der Zugriffskontrolle:
Es sollte eine logische Zuordnung der Datenbankobjekte, also der Tabellen, Indizes, Datenbankprozeduren, etc., zu den Anwendungen erfolgen, die diese Objekte benutzen. Die daraus entstehenden Gruppen von Datenbankobjekten je Anwendung werden eigens hierfür einzurichtenden Kennungen zugeordnet. Damit können die Zugriffsberechtigungen der Datenbankobjekte so eingestellt werden, daß nur über diese speziellen Kennungen eine Modifikation der Objekte stattfinden kann. Greifen mehrere Anwendungen auf dieselben Datenbankobjekte zu, sollten diese als eigene Gruppe isoliert werden.
Werden beispielsweise die Daten zweier Anwendungen A und B in der Datenbank verwaltet, so legt man zwei Datenbankkennungen AnwA und AnwB an. Alle Datenbankobjekte, die eindeutig der Anwendung A zugeordnet werden können, werden mit der Datenbankkennung AnwA angelegt und verwaltet. Analog wird mit den Datenbankobjekten von Anwendung B verfahren.
Ein Beispiel für ein zentrales Datenbankobjekt, das von beiden Anwendungen benutzt wird, sei eine Tabelle, die alle ansteuerbaren Drucker beinhaltet. Datenbankobjekte dieser Kategorie sollten nicht einer Kennung der Anwendungen (AnwA oder AnwB) zugeordnet werden, statt dessen sollten solche Datenbankobjekte unter einer eigenen Kennung (z. B. Druck) zusammengefaßt und mit dieser zentralen Kennung verwaltet werden.
Diese speziellen Kennungen sind nicht personenbezogen. Statt dessen erhalten eigens hierfür autorisierte Personen (z. B. der Datenbankadministrator oder der Administrator der zugehörigen Anwendung) das Paßwort der benötigten Kennung, falls Modifikationen an den Datenbankobjekten vorgenommen werden müssen.
Durch eine Definition von Views können spezielle Benutzer-Sichten erzeugt werden, so daß die Daten der Datenbank nach bestimmten Kriterien sichtbar gemacht bzw. unsichtbar gehalten werden. Über einen View wird explizit festgelegt, welche Felder aus einer oder mehreren Tabellen ein Benutzer zu sehen bekommt. Durch die restriktive Vergabe von Zugriffsrechten (den im folgenden beschriebenen Grants) auf solche Views können vertrauliche Daten vor unberechtigtem Zugriff geschützt werden.
Es müssen Zugriffsrechte (Grants) auf Tabellen, Views oder sogar einzelne Felder einer Tabelle vergeben werden. Diese Rechte sind immer an bestimmte Benutzer, Rollen oder Benutzergruppen gebunden. Zugriffsrechte sollten jedoch immer für Benutzergruppen oder Rollen und nicht für einzelne Personen vergeben werden, da dies sonst bei einer großen Anzahl von Benutzern zu einem hohen administrativen Aufwand führt. Es können Zugriffsberechtigungen lesender (read), ändernder (update), löschender (delete) oder neu einfügender (insert) Art unterschieden werden. Mit der Vergabe von Zugriffsberechtigungen sollte so sparsam wie möglich umgegangen werden, da man sonst sehr schnell den Überblick über die aktuellen Zugriffsrechte verliert und damit Sicherheitslücken geschaffen werden. Insbesondere sollte die Möglichkeit, Rechte an alle zu vergeben (GRANT ... TO PUBLIC), nicht genutzt werden.
Im allgemeinen ist es nur dem Besitzer eines Datenbankobjektes erlaubt, Zugriffsberechtigungen an andere Benutzer weiterzugeben. Einige Datenbanksysteme stellen jedoch die Möglichkeit zur Verfügung, daß der Besitzer eines Datenbankobjektes auch das Recht, Zugriffsrechte weiterzugeben, an andere Benutzer vergeben kann. Von dieser Möglichkeit sollte nur in begründeten Ausnahmefällen Gebrauch gemacht werden, da man auf diese Weise die Kontrolle über den Zugriff auf die Daten bzw. die Datenbankobjekte verliert.
Anwendungen sollten einen restriktiven Zugriff auf die Daten unterstützen, d. h. in Abhängigkeit der Benutzerkennung und der Gruppenzugehörigkeit sollten nur diejenigen Funktionalitäten und Daten zur Verfügung gestellt werden, die ein Benutzer für die Ausführung seiner Aufgaben benötigt. Eine Form der Realisierung ist hier die Verwendung von sogenannten Stored Procedures.
Stored Procedures sind Abfolgen von SQL-Anweisungen, die in der Datenbank voroptimiert gespeichert werden. Beim Aufruf einer Stored Procedure müssen nur ihr Name und eventuelle Parameter angegeben werden, um die dahinterstehenden SQL-Anweisungen auszuführen. Dies hat zum einen den Vorteil, daß nicht die gesamten SQL-Anweisungen zum Datenbankserver übertragen werden müssen, was bei komplexeren Operationen die Netzbelastung vermindert. Zum anderen kann das Datenbanksystem die SQL-Anweisungen in einer optimierten Form ablegen, so daß sie schneller ausgeführt werden. Die stärkste Einschränkung bei der Rechtevergabe ist die Vergabe von Zugriffsrechten auf Stored Procedures statt auf Tabellen oder Views. Wenn Zugriffsrechte nur auf Stored Procedures vergeben werden, können die Benutzer nur die von den Datenbankverantwortlichen ausgewählten Operationen ausführen.
Beispiele:
1. In MS Access können verschiedene Berechtigungen vergeben werden, die sich entweder auf die Datenbank selbst (Öffnen/Ausführen, Exklusiv, Verwalten) oder auf die Tabellen und Abfragen beziehen (Daten lesen, Daten aktualisieren, Daten löschen, Daten einfügen). Diese Berechtigungen können dann unterschiedlichen Benutzern oder Benutzergruppen zugeordnet werden. Standardmäßig sind bei MS Access die Gruppen "Administratoren" und "Benutzer" eingerichtet, wobei die Gruppe "Benutzer" die Berechtigungen "Daten lesen" und "Daten aktualisieren" für Tabellen und Abfragen und die Berechtigung "Öffnen/Ausführen" für Datenbanken enthält. Für eine detailliertere Kontrolle der Zugriffsrechte können eigene Gruppen definiert werden, an die unterschiedliche Berechtigungen vergeben werden können. Dies kann im Menü Extras unter Zugriffsrechte und Benutzer und Gruppenkonten durchgeführt werden.
2. In einer Oracle-Datenbank kann mit dem folgendem Kommando die Gruppe "Abteilung_1" erstellt werden:
CREATE ROLE Abteilung_1 IDENTIFIED BY <Paßwort>;
Im folgenden Beispiel wird der Gruppe "Abteilung_1" die Berechtigung erteilt, eine Verbindung zur Datenbank herzustellen sowie eine Session zu eröffnen:
GRANT CONNECT, CREATE SESSION TO Abteilung_1;
Im folgenden Beispiel würde derselben Gruppe die Berechtigung gegeben, ein SELECT auf die Tabelle "Test" durchzuführen:
GRANT SELECT ON Test TO Abteilung_1;
Im folgenden Beispiel würde dieser Gruppe die Berechtigung erteilt, für die Spalte "Kommentar" der Tabelle "Test" Änderungen durchzuführen:
GRANT UPDATE (Kommentar) ON Test TO Abteilung_1;
3. Ein Beispiel für eine Stored Procedure unter Oracle mit PL/SQL Anweisungen sieht wie folgt aus:
PROCEDURE Example (PArtikelnr IN NUMBER, PPreis OUT NUMBER) IS
BEGIN
BEGIN
SELECT preis INTO PPreis
FROM TabB
WHERE artikelnr=PArtikelnr
END Block;
END;Die Prozedur "Example" liest aus der Tabelle TabB den Preis eines Artikels nach Angabe der Artikelnummer. Mitarbeiter, die auf die Tabelle TabB ausschließlich mit dieser Methode zugreifen können sollen, erhalten nur das Nutzungsrecht für die Stored Procedure und keinerlei Rechte auf die Tabelle. Damit werden z. B. auch zeitaufwendige Suchoperationen verhindert.
Ergänzende Kontrollfragen:
© Copyright by Bundesamt für Sicherheit in der Informationstechnik 2000.