Bernd Jungbluth, Horn
In Teil 4 dieser Beitragsreihe wurden die Zugriffsrechte der Anwender auf die Datenbank begrenzt. In der Datenbank jedoch gibt es für die Anwender keine Grenzen. Durch die Zuordnung zur Datenbankrolle db_owner besitzen sie dort administrative Rechte. Dies erlaubt ihnen u.a. das Anlegen und Löschen von Tabellen sowie das Lesen und Ändern aller Daten. Wie Sie die Rechte mit Hilfe der Datenbankrollen weiter eingrenzen, lesen Sie in diesem Beitrag.
Warnung
Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!
In der aktuellen Beispielumgebung verwendet der Anwender, sprich die Person am Rechner, zur Authentifizierung am SQL Server die Anmeldung WaWiMa. Durch die Zuordnung dieser Anmeldung zum gleichnamigen Benutzer in der Datenbank WaWi_SQL ist der Anwender für den Zugriff auf diese Datenbank autorisiert. Innerhalb der Datenbank erlaubt die Mitgliedschaft des Benutzers zur Datenbankrolle db_owner dem Anwender das Lesen und Ändern der Daten. Soweit in Kurzform die Beschreibung der derzeitigen Rechtevergabe.
Datenbank-Administratoren nutzen die Datenbankrolle db_owner gerne, um Anwendern innerhalb einer Datenbank administrative Tätigkeiten zu erlauben. Auf diese Weise lassen sich Aufgaben an einen oder mehrere Anwender übertragen. Zum Beispiel an die Mitarbeiter des Supports. Sie geben neuen Kollegen die entsprechenden Rechte für den Datenzugriff und kümmern sich um die Datenbanksicherung. Datenbankobjekte wie Tabellen, gespeicherte Prozeduren und Sichten müssen sie jedoch weder anlegen, noch ändern oder gar löschen. Das sind eher die Tätigkeiten der Datenbankentwickler. Diese findet man in der Praxis ebenfalls oft in der Datenbank-rolle db_owner. Für die Installation neuer Datenbankversionen brauchen Sie die Rechte zum Anlegen, Ändern und Löschen von Datenbankobjekten. Allumfassende Lese- und Schreibzugriffe sind dafür allerdings nicht erforderlich.
Obwohl es sich in beiden Fällen um administrative Tätigkeiten handelt, haben die Anwender dennoch zu viele Rechte. Es gibt keinen Grund für eine Mitgliedschaft in der Datenbankrolle db_owner. Weder für den Support, noch für die Datenbankentwickler, noch für irgendeinen anderen Anwender. Schließlich stellt SQL Server noch neun weitere Datenbankrollen zur Verfügung. Diese reichen fürs Erste, um den Anwendern die Rechte zu geben, die Sie für die Realisierung ihrer Aufgaben benötigen. Und falls diese wider Erwarten nicht genügen, können Sie eigene Datenbankrollen anlegen und dort die Rechte gezielt vergeben.
Die Datenbankrolle db_owner hingegen sollte nur ein einziges Mitglied enthalten: den Datenbankbesitzer, kurz den Benutzer dbo (siehe Bild 1). Dieser Benutzer ist standardmäßig in der Datenbankrolle eingetragen und lässt sich nicht entfernen. Die Unterschiede der Datenbankrolle db_owner zum Datenbankbesitzer dbo wurden im letzten Beitrag beschrieben.
Bild 1: Die optimale Datenbankrolle db_owner
Rechte für den Datenbankentwickler
Datenbankentwickler erstellen neue Versionen bestehender Datenbanken in ihrer Entwicklungsumgebung und installieren das Ergebnis im produktiven SQL Server. Dies erfolgt über eigens dafür erzeugte SQL-Skripte oder über die Möglichkeiten der SQL Server Data Tools.
Für die Installation der Änderungen sind nur eine Handvoll Rechte notwendig. Neue Objekte werden mit CREATE angelegt, bestehende mit ALTER geändert und nicht mehr benötigte mit DELETE gelöscht. Bei diesen SQL-Anweisungen handelt es sich um DDL-Befehle. DDL steht für Data Definition Language – und die Datenbankrolle db_ddladmin erlaubt ihren Mitgliedern die Ausführung dieser Befehle. Der Datenbankentwickler muss also nur dieser Datenbankrolle zugeordnet werden und schon hat er die notwendigen Rechte zur Bereitstellung einer neuen Datenbankversion.
Beinhaltet die neue Datenbankversion eine detaillierte Rechtevergabe auf den Datenbankobjekten, braucht der Datenbankentwickler weitere Rechte. Mit GRANT vergibt er Rechte, mit REVOKE entzieht er diese und mit DENY verbietet er den Zugriff. Die Rechte für diese Befehle sind nicht in der Datenbankrolle db_ddladmin enthalten. Dafür gibt es die Datenbankrolle db_securityadmin. Ein Datenbankentwickler benötigt somit keine Zuordnung zur Rolle db_owner. Die beiden Datenbankrollen db_ddladmin und db_securityadmin sind für seine Aufgaben vollkommen ausreichend (siehe Bild 2).
Bild 2: Datenbankrollen für Datenbankentwickler
Möglicherweise trägt der Datenbank-entwickler in einer Tabelle die neue Versionsnummer der Datenbank ein. Dazu braucht er Lese- und Schreibrechte. Jedoch nur an der entsprechenden Tabelle. Die Rechtevergabe an Tabellen wird später beschrieben.
Rechte für den Support
Eine Datenbank gehört zu einer Applikation. Ob es sich hierbei um eine Datenbank zu einer IT-Inventursoftware, einer Lagerverwaltung oder einem ERP-System handelt, die Anwender verwalten die Daten immer über ein zugehöriges Frontend. Für die Applikation selbst steht ein Support zur Verfügung. Dieser klärt Fragen, analysiert und behebt Fehler, verwaltet Zugriffsberechtigungen und führt Datenbanksicherungen durch.
Einige Applikationen beinhalten eine eigene Benutzerverwaltung. Hier trägt der Support den neuen Kollegen als Anwender für die Applikation ein, worauf im SQL Server ein neuer Benutzer in der Datenbank mit entsprechenden Rechten angelegt wird. Vorausgesetzt, der Datenbankadministrator hat bereits die Anmeldung angelegt, mit der sich der neue Kollege am SQL Server authentifiziert. Diese Aufgabe findet außerhalb der Datenbank statt und obliegt somit weiterhin dem Datenbankadministrator. Innerhalb der Datenbank benötigt der Support die entsprechenden Rechte zur Verwaltung der Benutzer und deren Zugriffsrechte. Als Mitglied der bereits erwähnten Datenbankrolle db_securityadmin darf der Support die Zugriffsrechte direkt an den Datenbankobjekten wie auch über eigene Datenbank-rollen vergeben. Für die Rechte zum Anlegen, Ändern und Löschen von Benutzern benötigt er zusätzlich noch die Zuordnung zur Datenbankrolle db_accessadmin.
Die Möglichkeit zur Sicherung und Wiederherstellung der Daten gehört bei vielen Applikationen ebenfalls zum Funktionsumfang. Hierzu benötigt der Support die Rechte zur Ausführung der T-SQL-Befehle BACKUP und RESTORE. Diese Rechte beinhaltet die Datenbankrolle db_backupoperator.
Als Mitglied dieser drei Datenbankrollen besitzt der Support alle Rechte die er für seine Aufgaben benötigt (siehe Bild 3). Die Zuordnung zur Datenbankrolle db_owner ist nicht erforderlich.
Bild 3: Datenbankrollen für Supportmitarbeiter
Sie fragen sich, wie der Support Fehler analysieren soll, wenn er die Daten der Datenbank nicht lesen darf. Die Antwort ist recht einfach. Die Fehleranalyse findet nicht in der Produktivdatenbank, sondern in einer Testdatenbank statt.
Dort kann der Support anhand von Testdaten das Szenario nachstellen und die Ursache für den Fehler finden. Durch diese Trennung verhindern Sie ein versehentliches Ändern der Echtdaten.
Datenbankrolle public
Die Datenbankrolle mit der Zwangsmitgliedschaft. Jeder Benutzer einer Datenbank ist der Datenbankrolle public zugeordnet. Diese Zuordnung ist fest vorgegeben und lässt sich nicht ändern. Der ursprüngliche Sinn dieser Datenbankrolle liegt in der Definition von Zugriffsrechten, die für jeden Benutzer mindestens erforderlich sind. Eine solche Art der Rechtevergabe birgt jedoch einige Sicherheitsrisiken. Diese lernen Sie in einem der nächsten Beiträge kennen. Am besten folgen Sie der bewährten Sicherheitsempfehlung und ignorieren die Datenbankrolle public.
Lese- und Schreibrechte
Es bleiben noch vier Datenbankrollen übrig. Diese beziehen sich auf die Lese- und Schreibrechte – die Rechte für die SQL-Anweisungen SELECT, INSERT, UPDATE und DELETE.
Mitglieder der Datenbankrolle db_datareader dürfen alle Daten der Datenbank lesen und Mitglieder der Datenbankrolle db_datawriter alle Daten ändern und löschen sowie neue hinzufügen. Für die meisten Anwender der Datenbank ist eine Zuordnung zu diesen beiden Datenbankrollen absolut ausreichend. Anwender, die Daten lediglich auswerten, benötigen sogar nur die Zuordnung zur Datenbankrolle db_datareader.
Nun haben Sie einen Überblick über die Rechte der einzelnen Datenbankrollen. Datenbankadministratoren ohne dieses Wissen wählen am Anfang gerne alle Datenbankrollen aus (siehe Bild 4).
Bild 4: Viel hilft viel
Viel hilft viel – eine Aussage, die in diesem Fall nicht stimmt. Eine SELECT-Anweisung auf eine x-beliebige Tabelle der Datenbank liefert bei einer solchen Definition die Meldung aus Bild 5.
Bild 5: Die Folgen von „Viel hilft viel“
Mit dieser Rechtevergabe werden dem Benutzer nicht nur Rechte gewährt, sondern auch verweigert. Die Zuordnung zu den Datenbankrollen db_denydatareader und db_denydatawriter verbietet dem Benutzer jegliche Lese- und Schreibzugriffe. Im Hintergrund der beiden Datenbankrollen steht der Befehl DENY. Ein Verweigern per DENY überwiegt alle erteilten Rechte, sogar die der Datenbankrolle db_owner.
Die Auswahl aller Datenbankrollen ist nicht selten der Grund, warum die zum Benutzer gehörende Anmeldung letztendlich in der Serverrolle sysadmin landet. Für Mitglieder dieser Serverrolle gibt es im SQL Server keine Grenzen. Da verhindert auch kein DENY den Datenzugriff. Jedoch beinhaltet diese Zuordnung jegliche Rechte an den Datenbanken und vor allem an den dort gespeicherten Daten. Schneller können Sie Ihr mühsam erstelltes Sicherheitskonzept nicht zerstören.
Fehlende Zugriffsrechte in einer Datenbank lösen Sie bitte innerhalb der Datenbank. Die Serverrolle sysadmin ist in solchen Fällen für Sie tabu.
Wählen Sie die Datenbankrollen bewusst aus. Dies gilt insbesondere für die Datenbankrollen db_denydatareader und db_denydatawriter. Die beiden sollten Sie nur nutzen, wenn Sie den Lese- beziehungsweise Schreibzugriff unter allen Umständen verhindern möchten.
Mögliche Kandidaten für die Datenbankrolle db_denydatawriter sind Anwender, die Daten lediglich analysieren und auswerten. Um sicherzustellen, dass sie definitiv keine Daten hinzufügen, ändern oder löschen können, ordnen Sie den zugehörigen Benutzer der Datenbankrolle db_denydatawriter zu. Auf diese Weise können die Anwender in Access die Daten der SQL Server-Datenbank über eingebundene Tabellen auswerten, ohne Gefahr zu laufen, die Daten versehentlich zu ändern oder zu löschen.
Wozu die Mühe Reicht es nicht, wenn der Benutzer nur zur Datenbankrolle db_datareader gehört Grundsätzlich schon. Erhält der Benutzer aber versehentlich das Recht zum Anlegen von Daten in einer Tabelle, verhindert dessen Mitgliedschaft in db_denydatawriter dieses Schreibrecht. Dies gilt ebenso für eine irrtümliche Zuordnung des Benutzers zu db_datawriter oder gar zu db_owner.
Das klingt recht sicher und durchdacht – zum Zeitpunkt der Rechtevergabe. Zu einem späteren Zeitpunkt ist das Konzept der Mitgliedschaft zu den Datenbankrollen db_denydatareader und db_denydatawriter vielleicht nicht mehr so einfach nachzuvollziehen. Deshalb sollten Sie sich den Grund für die Verwendung dieser beiden Datenbankrollen gut dokumentieren.
Angenommen, Sie müssen einem Anwender den lesenden Zugriff auf eine Tabelle gewähren. Das ist schnell getan. Sie gehen zur Tabelle, wählen dort über die Berechtigungen den zum Anwender gehörenden Benutzer aus und erteilen ihm das Recht für die SELECT-Anweisung. Bei dieser Art der Rechtevergabe sehen Sie die bestehende Zuordnung des Benutzers zur Datenbankrolle db_denydatareader nicht. Sie werden auch nicht darauf hingewiesen. Der Anwender möchte nun die Daten der Tabelle lesen. Er erhält jedoch nur Fehlermeldungen. Jetzt kommt Hektik auf, denn das Problem muss wie immer schnell gelöst werden. Sie überprüfen die Datenbankrollen des Benutzers und sehen die Zuordnung zur Datenbankrolle db_denydatareader. Dazu gab es bestimmt mal einen guten Grund. Nur ohne Dokumentation fehlt Ihnen die Argumentation, warum Sie diese Zuordnung nicht so ohne weiteres ändern können. Um das Problem zu lösen, ordnen Sie den Benutzer der Datenbankrolle db_owner zu. Dann kann er erst mal arbeiten. Um die tatsächlichen Rechte kümmern Sie sich später. Doch es bleibt bei den Fehlermeldungen, denn die Zuordnung zur Datenbankrolle db_denydatareader überwiegt den Rechten der Datenbankrolle db_owner. Eine Lösung muss her und zwar schnell. Also ordnen Sie die Anmeldung des Benutzers der Serverrolle sysadmin zu. Das Problem ist gelöst, denn mit diesen Rechten darf der Anwender im SQL Server alles – sogar die Daten der vorgesehenen Tabelle lesen. Natürlich ist diese Zuordnung nur vorübergehend. Sobald Sie Zeit haben, die Rechtevergabe neu zu überdenken und anzupassen, werden Sie die Anmeldung aus der Serverrolle sysadmin wieder entfernen. Dabei sollten Sie die Zuordnung zur Datenbankrolle db_owner nicht vergessen. Die Frage, wann Sie die Zeit haben und wie lange dieses vorübergehend anhält, dürfen Sie sich gerne selbst beantworten. Dieses Beispiel ist nicht erfunden. Vielmehr zeigt es den Grund, warum in der Praxis Anmeldungen in der Serverrolle sysadmin sowie Benutzer in der Datenbankrolle db_owner zu finden sind.
Erstellen Sie sich eine Dokumentation Ihres Berechtigungskonzepts. Diese beinhaltet nicht nur die Mitgliedschaft der Benutzer in den Datenbankrollen, sondern auch den Grund für diese Zuordnungen. Jegliche Anforderung, die Änderungen an den Zugriffsrechten erfordert, prüfen Sie zuerst gegen Ihre Dokumentation. Passen die Anforderungen nicht zu Ihrem Berechtigungskonzept, wehren Sie sich so gut wie möglich gegen die geforderten Rechte.
Sie haben den Überblick zur aktuellen Rechtevergabe und Sie als Datenbankadministrator sind verantwortlich für die Daten. Ob nun Daten versehentlich gelöscht oder bewusst von einem Anwender manipuliert wurden, Sie müssen gute Argumente haben, warum Sie dies nicht verhindern konnten. Mit dem Argument, Sie haben die Rechte nur vorübergehend erteilt, um die Anforderungen der Abteilung zu erfüllen, werden Sie nicht weit kommen. Sie sind der Fachmann und es gehört zu Ihren Aufgaben, die möglichen Folgen einer Rechtevergabe einzuschätzen und zu bewerten.
Es ist wie immer bei der Definition von Zugriffsrechten. Das Berechtigungskonzept sollte gut durchdacht und dokumentiert sein. Diese Dokumentation ist Ihr Leitfaden. Jede neue Anforderung an Zugriffsrechte muss mit Ihrem Berechtigungskonzept vereinbar sein. Ist dies nicht der Fall, stellen Sie das aktuelle Konzept in Frage und definieren Sie bei Bedarf ein neues.
Zum Schluss ein kleiner Tipp für Ihr Berechtigungskonzept: Die Zuordnung eines Benutzers zu den Datenbankrollen db_datareader und db_denydatareader sowie db_datawriter und db_denydatawriter oder gar zu allen vieren ist schlicht und ergreifend sinnlos.
Lese- und Schreibrechte für WaWiMa
Genug der Theorie. In der Beispieldatenbank WaWi_SQL ist der Benutzer WaWiMa aktuell der Datenbankrolle db_owner zugeordnet. Diese zu hohen Rechte werden Sie nun eingrenzen.
Mit diesem Beitrag gibt es eine neue Version der SQL Server-Beispieldatenbank und der Access-Applikation. Sollten Sie die Beispiele bereits installiert haben, löschen Sie diese und installieren Sie die neuen Versionen. Eine Installationsanleitung finden Sie am Ende des Artikels.
Öffnen Sie das SQL Server Management Studio und melden Sie sich an Ihrem SQL Server als Datenbankadministrator an. Danach erweitern Sie den Ordner der Datenbank WaWi_SQL und gehen zum Ordner Sicherheit. Hier gibt es jetzt zwei Möglichkeiten zur Rechtevergabe per Datenbankrollen. Sie können den Benutzer in den jeweiligen Datenbankrollen hinzufügen beziehungsweise entfernen oder beim Benutzer selbst die Zuordnung vornehmen.
Schauen Sie sich zunächst den Weg über die Datenbankrollen an. Dazu erweitern Sie den Ordner Rollen und danach den Ordner Datenbankrollen (siehe Bild 6). Öffnen Sie per Doppelklick den Dialog zur Datenbankrolle db_owner.
Bild 6: Datenbankrollen einer Datenbank
Dort können Sie unter Mitglieder dieser Rolle den Eintrag WaWiMa markieren und mit einem Klick auf die Schaltfläche Entfernen (siehe Bild 7) die Mitgliedschaft beenden. Danach besitzt der Benutzer WaWiMa in der Datenbank keinerlei Zugriffsrechte mehr. Sollten Sie dies in einer produktiven Umgebung vorhaben, stellen Sie sich schon einmal auf diverse Anrufe und E-Mails ein.
Bild 7: Verwalten der Mitglieder einer Datenbankrolle
Eine weitaus bessere Vorgehensweise ist die Änderung der Mitgliedschaft über den Benutzer. Wechseln Sie dazu zum Ordner Benutzer und öffnen Sie mit einem Doppelklick auf WaWiMa den Dialog Datenbankbenutzer. In der Seite Mitgliedschaft sehen Sie die aktuelle Zuordnung des Benutzers zu den Datenbankrollen.
Entfernen Sie das Häkchen bei der Datenbankrolle db_owner und aktivieren Sie die Datenbankrollen db_datareader und db_datawriter (siehe Bild 8). Mit einem Klick auf die Schaltfläche OK bestätigen Sie die neuen Zugriffsrechte. Der Benutzer WaWiMa besitzt in der Datenbank nun keine administrativen Rechte mehr. Er darf nur noch Daten lesen und ändern.
Bild 8: Verwalten der Datenbankrollen eines Benutzers
In der Access-Beispielapplikation WaWi hat die Änderung der Zugriffsrechte keine Auswirkung. Die Verbindung zum SQL Server wird weiterhin über die Anmeldung WaWiMa hergestellt. Diese Anmeldung ist in der Datenbank WaWi_SQL dem gleichnamigen Benutzer zugeordnet. Durch die Mitgliedschaft des Benutzers in den Datenbankrollen db_datareader und db_datawriter darf der Anwender die Daten der Datenbank lesen und ändern.
Testen Sie es einfach mal. Öffnen Sie die Beispielapplikation WaWi. Sie werden keinen Unterschied feststellen. Trotz der geringeren Rechte sehen Sie alle Daten.
Ein Klick auf die Schaltfläche Kunden liefert Ihnen die Daten der Tabelle Kunden. Sie können diese Daten nicht nur lesen, Sie dürfen auch neue hinzufügen sowie bestehende ändern und löschen.
Die Anmeldung WaWiMa erlaubt Ihnen den Zugriff auf alle Daten der Datenbank WaWi_SQL. Ob nun per eingebundener Tabelle wie im Formular Aufträge oder per ADO wie im Formular Artikel, die Art und Technik des Datenzugriffs spielt dabei keine Rolle.
Es gibt jedoch Ausnahmen, wie ein Klick auf die Schaltfläche Geburtstagsliste zeigt (siehe Bild 9).
Bild 9: Fehler beim Datenzugriff
EXECUTE-Rechte für WaWiMa
Das Formular Geburtstagsliste basiert auf der Pass Through-Abfrage ptSelectGeburtstagsliste, die wiederum die gespeicherte Prozedur dbo.pSelectGeburtstagsliste ausführt. Hier liegt die Ursache für den Fehler, genauer gesagt bei den Rechten zum Ausführen der gespeicherten Prozedur.
Der Benutzer WaWiMa besitzt mit der Zuordnung zur Datenbankrolle db_datareader das Recht für die SQL-Anweisung SELECT zum Lesen der Daten und mit der Datenbankrolle db_datawriter die Rechte zum Ändern der Daten per INSERT, UPDATE und DELETE. Keine der beiden Datenbankrollen beinhaltet das Recht für die SQL-Anweisung EXECUTE zur Ausführung von gespeicherten Prozeduren. Ergo muss der Benutzer WaWiMa zusätzlich das Recht für EXECUTE erhalten.
Bitte denken Sie jetzt nicht an die Datenbankrolle db_owner oder gar an die Serverrolle sysadmin. Wie schon erwähnt, wäre dies zwar eine schnelle Lösung des Problems, aber auch die mit Abstand schlechteste. Es ist nicht erforderlich, dem Anwender alle Rechte zu geben. Ihm fehlt ja nur ein Recht – das Recht für die SQL-Anweisung EXECUTE.
Microsoft empfiehlt den Einsatz von gespeicherten Prozeduren unter anderem aus Gründen der besseren Performance und der Datensicherheit. Da ist der Gedanke naheliegend, dass SQL Server eine entsprechende Datenbankrolle anbietet. Leider gibt es eine solche Datenbankrolle nicht, obwohl sie seit vielen Jahren vermisst und auch immer wieder gefordert wird.
Sie müssen sich selbst helfen. Konkret bedeutet dies, dass Sie eine eigene Datenbankrolle für diese Rechtevergabe anlegen. Also zurück zum SQL Server Management Studio und dort zum Ordner Rollen der Datenbank WaWi_SQL. Hier klicken Sie mit der rechten Maustaste auf den Ordner Datenbankrollen und wählen den Eintrag Neue Datenbankrolle (siehe Bild 10).
Bild 10: Eine eigene Datenbankrolle
Im Dialog Datenbankrolle – Neu geben Sie als erstes den Namen der Datenbankrolle im Feld Rollenname ein. Der Name ist frei wählbar. Sie können die Nomenklatur der fixen Datenbankrollen beibehalten und die Bezeichnung db_execute verwenden oder Sie legen für Ihre Datenbankrollen eine eigene Namensgebung fest. Wie wäre es mit der Bezeichnung edb_execute
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo