Access und SQL Server-Security – Teil 8: Berechtigungskonzept per Datenbankrollen

Bernd Jungbluth, Horn (info@berndjungbluth.de)

Berechtigungskonzepte sind mit einer Vielzahl von Fachbegriffen verbunden. Separation of Duties, Principle of Least Privilege, Role Based Access Control, Discretionary Access Control etc. pp. Sie behandeln die Vergabe von Zugriffsrechten auf unterschiedlichen Sicherheitsniveaus. Im Kern jedoch dient jede dieser Methoden der Vertraulichkeit und Integrität der Daten. Die Anwender dürfen nur auf die Ressourcen zugreifen, die sie zum Erfüllen ihrer Aufgaben benötigen. Dabei gilt es Überschneidungen von Zuständigkeiten und somit den Missbrauch von Daten zu vermeiden. SQL Server unterstützt zur Umsetzung dieser Anforderungen gleich mehrere Konzepte.

In den bisherigen Beiträgen dieser Reihe haben Sie einige Varianten möglicher Berechtigungskonzepte kennengelernt. Das aktuelle Berechtigungskonzept der Beispielumgebung basiert auf der Windows-Authentifizierung und drei Datenbankrollen. Die Anwender melden sich mit ihren Windows-Benutzerkonten am SQL Server an. Wobei im SQL Server als Anmeldungen nicht die Benutzerkonten der Anwender hinterlegt sind, sondern die der Windows-Gruppen Personal und Vertrieb. So authentifiziert sich Frau Bienlein als Mitglied der Windows-Gruppe Vertrieb über die gleichnamige Anmeldung am SQL Server. Ähnlich ist es beim Anwender Stromberg. Er ist Mitglied der Windows-Gruppe Personal und für diese gibt es im SQL Server die Anmeldung Personal.

Der eigentliche Datenzugriff ist in der Datenbank geregelt. Zu jeder Anmeldung existiert dort ein entsprechender Benutzer. Die beiden Benutzer Personal und Vertrieb sind Mitglieder der Datenbankrollen db_datareader, db_datawriter und edb_execute. Durch diese Zuordnung dürfen die Benutzer und somit letztendlich die Mitglieder der Windows-Gruppen die Daten aller Tabellen lesen, ändern, ergänzen und löschen sowie alle gespeicherten Prozeduren ausführen. Lediglich den Vertriebsmitarbeitern ist der Zugriff auf die Daten der Personalabteilung nicht gestattet. Das wird mit einer erweiterten Rechtevergabe sichergestellt. Diese verweigert dem Benutzer Vertrieb den Zugriff auf die Tabellen Bewerber, Mitarbeiter und Stellen sowie der gespeicherten Prozedur pSelectGeburtstagsliste.

Dieses Berechtigungskonzept bietet bereits ein recht hohes Sicherheitsniveau. Dennoch ist es nicht detailliert genug. Die Anwender der Windows-Gruppe Vertrieb haben zwar keinen Zugriff auf die Personaldaten, auf alle anderen Daten können sie jedoch zugreifen. Um diese Sicherheitslücke zu schließen, bedarf es einer dedizierten Vergabe der Zugriffsrechte. Ein solch detailliertes Berechtigungskonzept benötigt man, wenn die Datenbank Informationen für verschiedene Zwecke speichert. Die Beispieldatenbank WaWi_SQL enthält neben den Daten des Vertriebs und der Personalabteilung die Daten des Einkaufs. Die Zugriffsrechte zu diesen Daten sollen aus Gründen der Datensicherheit und des Datenschutzes getrennt werden.

Datensicherheit und Datenschutz

Wie wichtig eine Trennung aus Gründen der Datensicherheit ist, haben Sie in den letzten Beiträgen anhand der Aktionen von Frau Bienlein gesehen. Aktuell hat sie Zugriff auf die Daten des Einkaufs und kann Lieferanten mitsamt Eingangsrechnungen und Wareneingängen anlegen. Der monatliche Zahlungslauf der Buchhaltung überweist dann die Beträge der nicht realen Eingangsrechnungen an das Bankkonto des fiktiven Lieferanten, also an Frau Bienlein. Das neue Berechtigungskonzept soll Datenmissbrauch dieser Art verhindern.

Eine detaillierte Rechtevergabe ist ebenso aus Gründen des Datenschutzes erforderlich. Aktuell haben die Mitarbeiter der Personalabteilung vollen Zugriff auf alle Daten der Datenbank. Hierunter fallen die Daten der Kunden und deren Ansprechpartner. Dieser Datenzugriff ist nicht datenschutzkonform. Die Daten der Kunden und Ansprechpartner werden zum Zweck der Vertragserfüllung und Kundenbindung in der Datenbank gespeichert. Ein Zugriff der Personalabteilung lässt sich mit diesem Zweck nicht vereinbaren.

Somit wird die Zweckbindung als einer der Grundsätze zur Verarbeitung von personenbezogenen Daten mit dem aktuellen Berechtigungskonzept nicht erfüllt.

Datensicherheit und Datenschutz sind zwei Aspekte zur Bewertung des Sicherheitsniveaus. Beide fordern die Vertraulichkeit und Integrität der Daten. Aber was genau verbirgt sich hinter dieser Forderung?

Vertraulichkeit und Integrität der Daten

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) betrachtet die Vertraulichkeit und Integrität der Daten zusammen mit deren Verfügbarkeit als die “Schutzziele oder auch Grundwerte der Informationssicherheit”.

Vertraulichkeit beschreibt das BSI als den “Schutz vor unbefugter Preisgabe von Informationen” oder etwas konkreter mit “Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein.”.

Integrität “bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten und der korrekten Funktionsweise von Systemen”. Daten verlieren ihre Integrität, wenn “diese unerlaubt verändert” wurden.

Die hier aufgeführten Definitionen stammen aus dem Glossar des IT Grundschutz Kompendium. Ein relevantes Werk zum Thema IT-Sicherheit.

Eine Maßnahme zur Gewährleistung der Vertraulichkeit und Integrität der Daten ist ein Berechtigungskonzept. Wobei dessen Detaillierungsgrad von Ihren Sicherheitsanforderungen abhängt. Der Aufwand in einem Bioladen wird geringer sein als in einem Krankenhaus. Das Sicherheitsniveau Ihres Unternehmens stellt also die Grundlage des Berechtigungskonzepts dar. Zur Umsetzung beginnt man mit einer Bestandsaufnahme.

Ein detailliertes Berechtigungskonzept

Ziel der Bestandsaufnahme ist eine Aufstellung der im Unternehmen anfallenden Aufgaben sowie deren Aufgabenträger. Sie müssen also herausfinden, wer im Unternehmen welche Aufgaben erledigt. Die ersten Fragen lauten daher: Wer macht hier eigentlich was? Und warum? Auf der Suche nach der Antwort erleben Sie möglicherweise die eine oder andere Überraschung.

Sie werden feststellen, dass Personen Aufgaben erledigen, von denen Sie das nicht erwartet hätten. Und Sie werden sehen, dass manche Aufgabe doppelt und dreifach von Personen in unterschiedlichen Abteilungen bearbeitet wird. Wohingegen sich um einige Aufgaben niemand kümmert. Sie werden erleben, wie sich Personen an Aufgaben klammern und wie andere wiederum die Aufgaben so schnell wie möglich loswerden möchten. Die menschliche Komponente beim Erstellen eines Berechtigungskonzepts sollten Sie nicht unterschätzen.

Das klingt jetzt nicht so erfreulich für Sie? Dann betrachten Sie es mal von einer anderen Seite. Eine Übersicht der Tätigkeiten Ihrer Kollegen bietet einige Vorteile. Vielleicht erkennen Sie Datenzugriffe, die es aus Gründen der Datensicherheit oder des Datenschutzes gar nicht geben dürfte. Möglicherweise entdecken Sie einiges an Verbesserungspotential in der Aufgabenverteilung. Eine Neustrukturierung der Aufgaben wiederum kann Ihnen Einsparmöglichkeiten aufzeigen. Sie brauchen vielleicht nicht auf allen Rechnern zwingend eine Access-Lizenz und eventuell ist eine Lizenzierung des SQL Servers nach Client Access Licence günstiger als eine Lizenzierung pro Prozessor.

Bei der Bestandsaufnahme sollten Sie neben den menschlichen Aufgabenträgern ebenso die maschinellen Aufgabenträger berücksichtigen. Im Hinblick auf ein Berechtigungskonzept für Datenbanken spielen hierbei die Applikationen eine wichtige Rolle. Welche Applikationen werden zur Bewältigung welcher Aufgaben eingesetzt? Welche Datenbanken gehören zu den Applikationen? Und natürlich stellt sich letztendlich die Frage, welche Anwender mit diesen Applikationen arbeiten.

Was die Anwender betrifft, ist für Sie als Datenbankadministrator bereits ein Teil der Arbeit getan. Deren Windows-Benutzerkonten sind in den meisten Fällen in Windows-Gruppen zusammengefasst. Der IT-Systemadministrator hat sich bei der Gruppenbildung bereits Gedanken über die Gruppenzugehörigkeit der Anwender gemacht. Nicht selten werden in diesen Gruppen die Abteilungen des Unternehmens abgebildet. Eine weitere Art der Gruppenbildung basiert auf Arbeitsabläufen und Prozessen, insbesondere wenn hierbei mehrere Abteilungen involviert sind.

Des Weiteren gibt es Gruppen zur Funktionstrennung, um Interessenskonflikte beziehungsweise Überschneidungen von Zuständigkeiten zu vermeiden. Wie auch immer, Sie als Datenbankadministrator sollten zunächst prüfen, ob Sie die Windows-Gruppen ohne weiteres übernehmen können. Sind die Gruppierungen nicht detailliert genug, erstellen Sie zusammen mit Ihrem IT-Systemadministrator weitere Gruppen.

Im SQL Server legen Sie zu den einzelnen Windows-Gruppen die Anmeldungen an und ordnen diese der Datenbank zu. Sie kennen diese Vorgehensweise bereits. Durch die Zuordnungen werden in der Datenbank die Benutzer zu den Anmeldungen erstellt. Dort erfolgt dann durch die Mitgliedschaft der Benutzer in den einzelnen Datenbankrollen die eigentliche Berechtigungsvergabe.

Eine Datenbankrolle enthält die Zugriffsrechte an den Tabellen, die die Daten für die Aufgaben speichern und an der Geschäftslogik, die in den gespeicherten Prozeduren definiert ist. So bestimmen Sie letztendlich, an welchen Tabellen die Mitglieder der Datenbankrolle eines, mehrere oder gar alle der Rechte SELECT, INSERT, UPDATE und DELETE besitzen. Ebenso definieren Sie in der Datenbankrolle welche gespeicherten Prozeduren per EXECUTE ausgeführt werden dürfen. Wie Sie vom aktuellen Berechtigungskonzept her wissen, können Sie auf diese Art nicht nur Rechte vergeben, sondern auch explizit verweigern.

Dieses Rollenprinzip ist als Role Based Access Control (RBAC) bekannt. Natürlich ist eine Vergabe der Rechte ebenso direkt am Benutzer selbst möglich. Im aktuellen Berechtigungskonzept ist dies bei dem Benutzer Vertrieb der Fall. Ihm ist der Zugriff auf die Tabellen und gespeicherten Prozeduren der Personalabteilung explizit verweigert. Discretionary Access Control (DAC) lautet die Bezeichnung für diese direkte Art der Rechtevergabe. In den meisten Fällen ist sie jedoch nicht empfehlenswert. Angenommen, die Außendienstmitarbeiter sollen die gleichen Zugriffsrechte wie die Vertriebsmitarbeiter erhalten. Dazu legen Sie für die Windows-Gruppe ADM eine Anmeldung im SQL Server an und ordnen diese der Datenbank WaWi_SQL zu. Bei einer Rechtevergabe pro Benutzer müssten Sie die Rechte des Benutzers ADM an die des Benutzers Vertrieb anpassen. Jede Änderung der Zugriffsrechte wäre dann bei beiden Benutzern zu pflegen. Ist die Rechtevergabe jedoch in einer Datenbankrolle definiert, nehmen Sie zusätzlich zum Benutzer Vertrieb den neuen Benutzer ADM in die Datenbankrolle auf. Weitere Änderungen der Zugriffsrechte finden ausschließlich in der Datenbankrolle statt und stehen direkt für die dort zugeordneten Benutzer zur Verfügung, im Beispiel für die Vertriebsmitarbeiter und die Außendienstmitarbeiter. Am besten denken Sie immer in Datenbankrollen. Das erleichtert Ihnen die Pflege der Rechtevergabe.

Apropos erleichtern. Der wohl wichtigste Leitspruch in der Security lautet KISS – Keep It Simple, Stupid. Halten Sie Ihr Berechtigungskonzept so einfach und übersichtlich wie möglich. Je komplizierter es ist, desto eher wird im Falle eines fehlenden Zugriffsrechts die Rechtevergabe schnell mal erweitert. Hauptsache, der Anwender kann arbeiten. Die Nachjustierung im Sinne einer Korrektur der Zugriffsrechte erfolgt aus Zeitmangel eher selten. Wodurch die komplette Arbeit zur Rechtevergabe für die Katz ist.

Die Zugriffsberechtigungen nach Role Based Access Control (RBAC) und Discretionary Access Control (DAC) beziehen sich auf die Datenbankobjekte. Zugriffsrechte auf einzelne Datensätze sind hier nicht enthalten. Diese Art der Rechtevergabe fällt unter den Begriff Mandatory Access Control (MAC). Hier basieren die Zugriffsrechte auf Regeln. Regeln, die beispielsweise den Vertriebsmitarbeitern den Zugriff auf die Kundendaten ihrer Zuständigkeiten begrenzen. So kann ein Mitarbeiter nur seine Kunden sehen und nicht die seiner Kollegen. In SQL Server lässt sich ein derartiger Datenzugriff mittels Row Level Security (RLS) realisieren.

Der Werkzeugkasten

Das Berechtigungskonzept zur Datenbank WaWi_SQL soll dem Rollenprinzip entsprechen. Dazu fassen Sie einzelne Datenbankobjekte in Datenbankrollen zusammen und legen dort deren Zugriffsrechte fest. Hierbei orientieren Sie sich an den Aufgaben. Welche Datenbankobjekte werden zum Erfüllen der Aufgaben benötigt? Welche Rechte an den einzelnen Datenbankobjekten sind dazu erforderlich? Bildlich gesprochen nehmen Sie mit den Datenbankobjekten das benötigte Werkzeug und legen es in den Werkzeugkasten, in die Datenbankrolle. Welche Person letztendlich den Werkzeugkasten in die Hand nimmt und sich an die Aufgaben macht, ist für das Zusammenstellen des Werkzeugs irrelevant.

Wie kommt der Werkzeugkasten zur Person? Durch die Zuordnung des Benutzers zur Datenbankrolle. Wobei der Benutzer hier eher einer Stellenbeschreibung ähnelt. Wer diese Stelle besetzt, ergibt sich durch die Verknüpfung des Benutzers zur Anmeldung, welche wiederum auf eine Windows-Gruppe verweist. Somit haben alle Mitglieder der Windows-Gruppe Zugriff auf den Werkzeugkasten, sprich auf die Ressourcen, die sie zur Bewältigung ihrer Aufgaben benötigen. Nicht mehr und nicht weniger. Diese Einschränkung wird als Principle Of Least Privilege (PoLP) bezeichnet.

An dieser Stelle zeigt sich wieder einmal die Stärke der mehrstufigen Sicherheitsarchitektur des SQL Servers. Die zur Erfüllung der Aufgaben erforderlichen Zugriffsrechte sind innerhalb der Datenbank definiert. Während die Anmeldungen der für die Aufgaben zuständigen Personen außerhalb der Datenbanken verwaltet werden. Verweisen diese Anmeldungen auf Windows-Gruppen, findet deren Definition und Verwaltung nicht einmal im SQL Server statt. Eine klare Trennung von Aufgaben und Personen.

Eine solche Trennung bietet einige Vorteile, zum Beispiel im Fall einer Urlaubsvertretung. Für die Rechtevergabe reicht es aus, dass der IT-Systemadministrator das Windows-Benutzerkonto der Urlaubsvertretung in die entsprechende Windows-Gruppe aufnimmt. Dadurch erhält der Anwender alle erforderlichen Zugriffsrechte an den Ressourcen, die er zum Bewältigen der vorübergehenden Aufgaben benötigt, inklusive der Rechte für die Datenzugriffe in den Datenbanken. Ein Nachjustieren der Zugriffsrechte innerhalb der Datenbanken ist in der Regel nicht erforderlich.

Der wohl wichtigste Aspekt bei der Zuordnung der Personen zu den Aufgaben ist das Prinzip der Funktionstrennung. Es gilt, Interessenskonflikte sowie die Möglichkeit krimineller Handlungen zu vermeiden. Dieses als Separation of Duties (SoD) oder Segregation of Duties bekannte Prinzip fordert, dass mehrere zusammenhängende Teilaufgaben nicht von ein und derselben Person durchgeführt werden. So sollte ein und dieselbe Person nicht für die Umsetzung einer Aufgabe und gleichzeitig für deren Abschluss beziehungsweise Kontrolle verantwortlich sein. Zum Beispiel für das Anlegen von Lieferanten und das Erfassen von Bestellungen und Wareneingängen.

Nach dem Prinzip der Funktionstrennung wäre es somit in der Beispielumgebung erforderlich, die Zugriffsrechte zu den Daten der Lieferanten von denen der Bestellungen und Wareneingänge zu trennen. Ohne diese Trennung sind die Mitarbeiter wie zuletzt Frau Bienlein in der Lage, einen fiktiven Lieferanten mitsamt Bestellungen anzulegen und den zugehörigen Wareneingang zu buchen. Vermeiden Sie unbedingt derartige Überschneidungen von Zuständigkeiten und somit den Missbrauch von Daten. Verteilen Sie die Zugriffsrechte in mehrere Datenbankrollen und ordnen Sie diesen unterschiedlichen Benutzer zu.

Sie sehen, ein Berechtigungskonzept kann schnell vielschichtig werden. Hinzu kommt, dass in einer über Jahre gewachsenen Datenbank-Applikation die Definition der Datenbankrollen gar mal nicht so einfach ist. Sie stoßen mit hoher Wahrscheinlichkeit auf Datenbankobjekte, die für mehrere Aufgaben erforderlich sind. In diesen Fällen sind Sie bei der Rechtevergabe bitte nicht zu großzügig. Folgen Sie weiterhin dem Principle Of Least Privilege und erteilen Sie den Anwendern nur die Rechte, die sie für ihre tägliche Arbeit benötigen. Vergeben Sie zu viele Rechte, ermöglichen Sie unerlaubte Zugriffe und den Missbrauch der Daten. Vergeben Sie zu wenig Rechte, können die Mitarbeiter ihre Aufgaben nicht wahrnehmen. Die Folge ist eine Fehlermeldung und die Lösung zu diesem Fehler meist eine zu hohe Rechtevergabe wie die Zuordnung des Benutzers zur Datenbankrolle db_owner oder gar der Anmeldung zur Serverrolle sysadmin.

Bestandsaufnahme

Genug der Theorie und Fachbegriffe. Wie gehen Sie am besten an die Bestandsaufnahme heran? Insbesondere im Hinblick auf das Berechtigungskonzept einer Datenbank? Schauen Sie sich den Sinn und Zweck der Applikationen zur Datenbank an. Welche Aufgaben werden mit diesen Applikationen erfüllt? In der Beispielapplikation sind es die des Vertriebs, des Einkaufs, des Personalwesens und der Buchhaltung. Diese vier Abteilungen sind eine gute Basis für die Definition der Windows-Gruppen und der Datenbankrollen.

Jeder Mitarbeiter dieser Abteilungen besitzt ein eigenes Windows-Benutzerkonto. Diese sind in Windows-Gruppen zusammengefasst. Frau Bienlein gehört zur Windows-Gruppe Vertrieb, Herr Stromberg zur Windows-Gruppe Personal, Herr Eberhofer zur Windows-Gruppe Einkauf und Frau Kling zur Windows-Gruppe Buchhaltung.

Im SQL Server gibt es zu jeder dieser Windows-Gruppen eine Anmeldung. Die Anmeldungen sind der Datenbank WaWi_SQL zugeordnet, wodurch es dort zu jeder Anmeldung und somit indirekt zu jeder Windows-Gruppe einen Benutzer gibt. Das aktuelle Berechtigungskonzept basiert auf einer pauschalen Rechtevergabe per Systemdatenbankrollen und einer eigenen allgemeingültigen Datenbankrolle zur Ausführung von gespeicherten Prozeduren. Das werden Sie nun ändern. Die Datenzugriffe sollen ausschließlich über eigene Datenbankrollen mit dedizierten Rechten erfolgen.

Als ersten Schritt entfernen Sie die bestehende Rechtevergabe. Beginnen Sie mit dem Benutzer Personal. Öffnen Sie das SQL Server Management Studio mit den Rechten eines Datenbankadministrators und navigieren Sie im Objekt-Explorer über den Eintrag Datenbanken| WaWi_SQL|Sicherheit zum Ordner Benutzer. Wie Sie in Bild 2. sehen, setzt sich der Benutzername aus der Bezeichnung der Domäne und der Windows-Gruppe zusammen. Wobei in Ihrer Umgebung natürlich die Bezeichnung Ihrer Domäne beziehungsweise Ihres Rechners enthalten ist. Der Einfachheit halber wird im folgenden Text auf die Benennung der Domäne verzichtet und ein Benutzer lediglich mit dem Namen der Windows-Gruppe beschrieben.

Bild 1: Die Benutzer in der Datenbank

Per Doppelklick auf den Benutzer Personal öffnen Sie dessen Eigenschaften-Dialog. Auf der Seite Mitgliedschaft entfernen Sie die Häkchen zu den Datenbankrollen db_datareader, db_datawriter und edb_execute. Mit einem Klick auf OK entziehen Sie dem Benutzer jegliche Zugriffsrechte.

Dem Benutzer Vertrieb nehmen Sie die Rechte auf ähnliche Weise. Öffnen Sie dessen Eigenschaften-Dialog und beenden Sie wie eben die Mitgliedschaft des Benutzers zu den Datenbankrollen db_datareader, db_datawriter und edb_execute. Jetzt ist noch die gesonderte Rechtevergabe des Benutzers aufzulösen. Dazu gehen Sie zur Seite Sicherungsfähige Elemente. Markieren Sie als erstes den Eintrag zur Tabelle Bewerber und entfernen Sie im unteren Bereich in der Spalte Verweigern die Häkchen in den Zeilen Aktualisieren, Auswählen, Einfügen und Löschen (siehe Bild 1). Wiederholen Sie den Vorgang für die Tabellen Mitarbeiter und Stellen. Danach markieren Sie die gespeicherte Prozedur pSelectGeburtstagsliste und deaktivieren die Rechtevergabe Verweigern zum Recht Ausführen. Bestätigen Sie die Änderungen mit einem Klick auf OK. Der Benutzer Vertrieb besitzt nun ebenfalls keinerlei Zugriffsrechte mehr. Um die Benutzer Einkauf und Buchhaltung müssen Sie sich nicht kümmern. Diese Benutzer haben aktuell noch keine Rechte.

Bild 2: Entfernen des Rechts Verweigern

Nun geht es an das Erstellen der neuen Datenbankrollen. Den Datenbankrollen mit den Datenbankobjekten und Zugriffsrechten, die die Anwender zum Erfüllen ihrer Aufgaben benötigen. Den Inhalt dieser Datenbankrollen gilt es zu ermitteln.

In der Beispielumgebung ist die Access-Applikation WaWi v2 die einzige Applikation zur Datenbank. Somit findet hier die Bestandsaufnahme für das Berechtigungskonzept statt. Nach einem Start der Beispielapplikation zeigt Ihnen das Start-Formular die Schaltflächen mit den Funktionen für die Abteilungen Vertrieb, Einkauf und Personal (siehe Bild 3). Auf den ersten Blick lässt dies auf drei Datenbankrollen schließen. Aber ist es so einfach? Reichen drei Datenbankrollen für eine gute Funktionstrennung und somit zur Vermeidung eines Datenmissbrauchs? Sie kennen die Antwort bereits. Solange Mitarbeiter die Daten der Lieferanten und die der Bestellungen mitsamt den Wareneingängen verwalten können, ist die Möglichkeit eines Datenmissbrauchs gegeben. Dieser lässt sich durch eine zusätzliche Aufteilung der Aufgaben in eine weitere Datenbankrolle vermeiden.

Bild 3: Das Start-Formular der Beispielapplikation

Unabhängig von den Missbrauchsmöglichkeiten steht noch eine Erweiterung der Zugriffsrechte an. Die Mitarbeiter haben sich bereit erklärt, dass jeder im Unternehmen die Geburtstagsliste einsehen darf. Bisher ist dies nur den Mitarbeitern im Personal erlaubt.

Dann werden es wohl mehr als drei Datenbankrollen. In den nächsten Schritten legen Sie die einzelnen Datenbankrollen an, bestimmen pro Datenbankrolle die Datenbankobjekte und definieren die erforderlichen Zugriffsrechte. Oder bei dem Beispiel von eben zu bleiben: Sie öffnen den Werkzeugkasten einer Abteilung und legen das benötigte Werkzeug hinein. Doch vorher brauchen Sie den Werkzeugkasten.

Datenbankrolle Personalwesen

Ran ans Werk. Beginnen Sie mit der Datenbankrolle für die Personalabteilung. Dazu navigieren Sie im SQL Server Management Studio in der Datenbank WaWi_SQL über Sicherheit|Rollen zum Eintrag Datenbankrollen. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie den Befehl Neue Datenbankrolle.

Im folgenden Dialog geben Sie als erstes die Bezeichnung Personalwesen in das Feld Rollenname ein. Achten Sie bei der Namensvergabe darauf, dass nicht bereits ein Benutzer mit dem Namen existiert. Datenbankrollen und Benutzer sind im SQL Server beides Prinzipale. Sie können einen Namen entweder für eine Datenbankrolle oder für einen Benutzer vergeben. Eine doppelte Vergabe wird mit einer Fehlermeldung quittiert. So gesehen könnten Sie ebenso den Rollennamen Personal verwenden. Dieser Name wäre noch frei, da die Bezeichnungen der Benutzer den Domänennamen enthalten. Allerdings wird der Einfachheit halber in diesem Text der Benutzer ohne Domänenname beschrieben. Um nun Missverständnisse mit dieser verkürzten Schreibweise und einer gleichlautenden Datenbankrolle zu vermeiden, erhält die Datenbankrolle die Bezeichnung Personalwesen.

Bei dem Besitzer der Datenbankrolle folgen Sie dem Grundsatz KISS. Halten Sie es einfach und geben Sie das Kürzel dbo ein. dbo steht für database owner und somit ist der Besitzer der Datenbankrolle identisch mit dem der Datenbank. Es ist ebenso möglich, als Besitzer einen anderen Benutzer einzutragen. Dies kommt jedoch selbst in komplexeren Berechtigungskonzepten eher selten vor.

Anschließend klicken Sie auf die Schaltfläche Hinzufügen und wählen im folgenden Dialog über Durchsuchen den Benutzer Personal aus (siehe Bild 4). Ein Klick auf OK übernimmt Ihre Auswahl in die Vorauswahl, ein weiterer Klick auf OK in den Dialog zur Datenbankrolle. Jetzt gerade eben haben Sie die Anwender definiert, die mit der Datenbankrolle oder um beim Vergleich zu bleiben mit dem Werkzeugkasten Personalwesen arbeiten dürfen.

Bild 4: Auswählen des Benutzers Personal

Fehlt noch das Werkzeug selbst, sprich die Datenbankobjekte mitsamt den Zugriffsrechten. Diese legen Sie in der Seite Sicherungsfähige Elemente fest. Doch welche Objekte benötigen die Mitarbeiter der Personalabteilung? Das zeigt die Bestandsaufnahme in der Beispielapplikation. Das Start-Formular enthält auf der rechten Seite die Schaltflächen für die Personalabteilung. Hierüber lassen sich die Daten der Mitarbeiter und Bewerber sowie neuer Stellenausschreibungen verwalten. Die Datenpflege erfolgt über Access-Formulare. Diese wiederum sind an Datenquellen gebunden. Genau diese Datenquellen bieten die Grundlage zur Rechtevergabe.

Beginnen Sie die Analyse mit den Mitarbeiterdaten. Dazu öffnen Sie mit der Schaltfläche Mitarbeiter das Formular zur Mitarbeiterverwaltung. Im Formular wechseln Sie in die Entwurfsansicht und aktivieren das Eigenschaftenblatt. Die Datenquelle des Formulars finden Sie in der Eigenschaft Datensatzquelle der Registerkarte Daten. Dort sehen Sie den Eintrag Mitarbeiter (siehe Bild 5).Das kann nun eine lokale Tabelle, eine eingebundene Tabelle, eine Access-Abfrage oder eine Pass Through-Abfrage sein. Was sich genau dahinter verbirgt, verrät Ihnen der Navigationsbereich. Eine Suche im Navigationsbereich zeigt Ihnen den Eintrag Mitarbeiter in der Rubrik Tabellen.

Bild 5: Die Datenquelle Mitarbeiter

Anhand des Symbols ist es als eingebundene Tabelle zu erkennen (siehe Bild 6). Oder ist es eine eingebundene Sicht? Eine Antwort auf diese Frage werden Sie in Access nicht finden. Access behandelt eine eingebundene Sicht wie eine Tabelle. Diese Frage lässt sich nur im SQL Server Management Studio beantworten. Dort ist das Datenbankobjekt Mitarbeiter entweder bei den Tabellen oder bei den Sichten zu finden. Zum Glück müssen Sie das Objekt nicht mühsam in den Ordnern des Objekts-Explorers suchen. Der Dialog der Datenbankrolle bietet Ihnen eine Suche über mehrere Objekttypen.

Bild 6: Die eingebundene Tabelle Mitarbeiter

Gehen Sie also zurück zum Dialog Datenbankrolle – Neu und wechseln Sie zur Registerkarte Sicherungsfähige Elemente. Hier klicken Sie auf Suchen und übernehmen in dem folgenden Dialog die vorgewählte Option Bestimmte Objekte. Es öffnet sich ein weiterer Dialog. Ein Klick auf die Schaltfläche Objekttypen bringt Sie zur nächsten Auswahlmöglichkeit. Dort aktivieren Sie die beiden Einträge Tabellen und Sichten und bestätigen diese mit OK. Zurück im Dialog Objekte auswählen geben Sie in das Eingabefeld den Wert Mitarbeiter ein und klicken auf Namen überprüfen. Sie erhalten einen weiteren Auswahldialog, der die Tabelle Mitarbeiter enthält (siehe Bild 7). Aktivieren Sie den Eintrag und übernehmen Sie die Auswahl mit OK. Den Dialog Objekte auswählen bestätigen Sie ebenfalls mit OK.

Bild 7: Auswählen der Tabelle Mitarbeiter

Zurück im Dialog zur Datenbankrolle sehen Sie nun die Tabelle Mitarbeiter in der oberen Auflistung. Die Zugriffsrechte zur Tabelle definieren Sie im unteren Bereich. Die Beispielapplikation erlaubt das Lesen, Anlegen, Ändern und Löschen der Mitarbeiterdaten. Zur Vergabe dieser Rechte aktivieren Sie als erstes in der Zeile Auswählen die Spalte Erteilen. Hierüber wird das Recht SELECT zum Lesen der Daten dieser Tabelle vergeben. Auf die gleiche Weise aktivieren Sie mit einem Klick in Erteilen bei den Zeilen Einfügen und Löschen die Rechte INSERT und DELETE. Seien Sie vorsichtig bei der Vergabe des Rechts zum Ändern der Daten. Dieses Recht wird gerne in der Zeile Ändern vergeben. Allerdings steht Ändern in diesem Fall für den Befehl ALTER, also das Recht, die Struktur der Tabelle zu ändern beziehungsweise diese zu löschen. Zur Vergabe des Rechts UPDATE müssen Sie die Option Erteilen in der Zeile Aktualisieren aktivieren.

So weit so gut. Das waren allerdings nur die Zugriffsrechte zu einer Schaltfläche der Beispielapplikation. Allein für die Personalabteilung gibt es dort noch drei weitere. Was im Vergleich zu vielen Access-Applikationen eher lachhaft ist. Zu jeder dieser Schaltflächen ist nun die Datenquelle zu ermitteln und im Dialog zur Datenbankrolle die entsprechenden Zugriffsrechte zu vergeben. Bei dem Klickaufwand wird das mit dem Dialog eine mühsame und zeitaufwendige Angelegenheit.

Sie haben die letzten Beiträge dieser Reihe gelesen? Dann wissen Sie was jetzt kommt. Klicken Sie im Dialog zur Datenbankrolle auf die Schaltfläche Skript (siehe Bild 8). Dieser Klick öffnet im SQL Server Management Studio eine neue Registerkarte und füllt diese mit T-SQL-Anweisungen.

Bild 8: Erstellen des Rechte-Skripts

Mit diesen Anweisungen legen Sie später die Datenbankrolle mitsamt den Mitgliedern und den eben vergebenen Rechten zur Tabelle Mitarbeiter an. Dieses Skript ist die Basis für die gesamte weitere Rechtevergabe.

Daher speichern Sie zunächst das Skript unter Rechtevergabe WaWi_SQL und beenden dann den Dialog zur Datenbankrolle mit Abbrechen. Jetzt räumen Sie das Skript ein wenig auf. Fassen Sie die einzelnen Zeilen zur Rechtevergabe der Tabelle Mitarbeiter in einer Zeile zusammen und verschieben Sie die Aufnahme des Benutzers in die Datenbankrolle an das Ende des Skripts:

USE WaWi_SQL;
GO
CREATE ROLE Personalwesen AUTHORIZATION dbo;
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen;
ALTER ROLE Personalwesen ADD MEMBER [BJSEMINARE\Personal];
GO

Der neue Aufbau des Skripts folgt im Gegensatz zum Dialog eher der anfangs beschriebenen Vorgehensweise. Die T-SQL-Anweisung CREATE ROLE erstellt die Datenbankrolle, also den Werkzeugkasten. Das Werkzeug selbst wird mit der Anweisung GRANT in den Werkzeugkasten gelegt, sprich die Tabelle Mitarbeiter mitsamt den Zugriffsrechen SELECT, INSERT, UPDATE und DELETE der Datenbankrolle zugeordnet. Zum Abschluss erlaubt die Anweisung ALTER ROLE einer oder mehreren Personen die Erlaubnis mit dem Werkzeugkasten zu arbeiten, in diesem Fall durch die Zuordnung des Benutzers Personal zur Datenbankrolle Personalwesen.

Das Skript werden Sie nun nach und nach mit den T-SQL-Anweisungen für die weiteren Datenbankrollen und deren Zugriffsrechte erweitern. Am Ende erhalten Sie die gesamte Rechtevergabe der Datenbank in einer übersichtlichen und lesbaren Form. Ergänzt mit aussagekräftigen Kommentaren ergibt sich daraus gleichzeitig die Dokumentation Ihres Berechtigungskonzepts (siehe Bild 9).

Bild 9: Die erste Version des Rechte-Skripts

Nicht nur das. Jedes Mal, wenn Sie das Skript starten, werden die kompletten Zugriffsrechte der Datenbank erneut vergeben. So stellen Sie mit jeder Skriptausführung sicher, dass die Vorgaben Ihres Berechtigungskonzepts erfüllt sind.

Allerdings liefert die T-SQL-Anweisung CREATE ROLE derzeit noch einen Fehler, sollte die angegebene Datenbankrolle bereits existieren. Aus diesem Grund ergänzen Sie die T-SQL-Anweisung CREATE ROLE mit der folgenden IF-Anweisung.

IF (SELECT DATABASE_PRINCIPAL_ID(''Personalwesen'')) IS NULL
BEGIN
    CREATE ROLE Personalwesen AUTHORIZATION dbo;
END

Jetzt wird die Datenbankrolle nur angelegt, wenn die Funktion DATABASE_PRINCIPAL_ID keinen Wert zurückgibt. Wobei diese Prüfung etwas unscharf ist, liefert die Funktion doch die interne ID eines Prinzipals. Wie eben erwähnt, gehören hierzu neben den Datenbankrollen auch die Benutzer. Sollte es also einen Benutzer namens Personalwesen geben, ist das Ergebnis ungleich NULL und die Datenbankrolle wird nicht erstellt.

Vielmehr erhält der Benutzer die Rechte zur Tabelle Mitarbeiter und die Anweisung ALTER ROLE erzeugt einen Fehler. Da in diesem Beispiel viel Wert auf die korrekte Benennung der Benutzer und Datenbankrollen gelegt wurde, soll an dieser Stelle die einfache Prüfung ausreichen. Schauen Sie mal in die Beispieldateien zu diesem Beitrag. Dort finden Sie in dem Skript WaWi_SQL – Berechtigungskonzept eine ausführlichere Version.

Username or Email

Passwort

Angemeldet bleiben