SQL Server-Security, Teil 4: Schutz mit Datenbankrollen

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.

Die optimale Datenbankrolle db_owner

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).

Datenbankrollen für Datenbankentwickler

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.

Datenbankrollen für Supportmitarbeiter

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).

Viel hilft viel

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.

Die Folgen von

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.

Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...

Workplace

Jahresabonnement TestzugangOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar