<\/p>\n
Bernd Jungbluth, Horn (info@berndjungbluth.de)<\/p>\n
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. <\/b><\/p>\n
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 <\/b>und Vertrieb<\/b>. So authentifiziert sich Frau Bienlein als Mitglied der Windows-Gruppe Vertrieb <\/b>über die gleichnamige Anmeldung am SQL Server. Ähnlich ist es beim Anwender Stromberg<\/b>. Er ist Mitglied der Windows-Gruppe Personal <\/b>und für diese gibt es im SQL Server die Anmeldung Personal<\/b>. <\/p>\n
Der eigentliche Datenzugriff ist in der Datenbank geregelt. Zu jeder Anmeldung existiert dort ein entsprechender Benutzer. Die beiden Benutzer Personal <\/b>und Vertrieb <\/b>sind Mitglieder der Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute<\/b>. 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 <\/b>den Zugriff auf die Tabellen Bewerber<\/b>, Mitarbeiter <\/b>und Stellen <\/b>sowie der gespeicherten Prozedur pSelectGeburtstagsliste<\/b>.<\/p>\n
Dieses Berechtigungskonzept bietet bereits ein recht hohes Sicherheitsniveau. Dennoch ist es nicht detailliert genug. Die Anwender der Windows-Gruppe Vertrieb <\/b>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 <\/b>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. <\/p>\nDatensicherheit und Datenschutz<\/h2>\n
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.<\/p>\n
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.<\/p>\n
Somit wird die Zweckbindung als einer der Grundsätze zur Verarbeitung von personenbezogenen Daten mit dem aktuellen Berechtigungskonzept nicht erfüllt.<\/p>\n
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?<\/p>\n
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“. <\/p>\n
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.“. <\/p>\n
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.<\/p>\n
Die hier aufgeführten Definitionen stammen aus dem Glossar des IT Grundschutz Kompendiums. Ein relevantes Werk zum Thema IT-Sicherheit.<\/p>\n
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.<\/p>\n
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. <\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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. <\/p>\n
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<\/b>, INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>besitzen. Ebenso definieren Sie in der Datenbankrolle welche gespeicherten Prozeduren per EXECUTE <\/b>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. <\/p>\n
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 <\/b>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 <\/b>eine Anmeldung im SQL Server an und ordnen diese der Datenbank WaWi_SQL <\/b>zu. Bei einer Rechtevergabe pro Benutzer müssten Sie die Rechte des Benutzers ADM <\/b>an die des Benutzers Vertrieb <\/b>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 <\/b>den neuen Benutzer ADM <\/b>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. <\/p>\n
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.<\/p>\n
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. <\/p>\n
Das Berechtigungskonzept zur Datenbank WaWi_SQL <\/b>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. <\/p>\n
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. <\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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. <\/p>\n
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 <\/b>oder gar der Anmeldung zur Serverrolle sysadmin<\/b>. <\/p>\nBestandsaufnahme<\/h2>\n
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. <\/p>\n
Jeder Mitarbeiter dieser Abteilungen besitzt ein eigenes Windows-Benutzerkonto. Diese sind in Windows-Gruppen zusammengefasst. Frau Bienlein gehört zur Windows-Gruppe Vertrieb<\/b>, Herr Stromberg zur Windows-Gruppe Personal<\/b>, Herr Eberhofer zur Windows-Gruppe Einkauf <\/b>und Frau Kling zur Windows-Gruppe Buchhaltung<\/b>.<\/p>\n
Im SQL Server gibt es zu jeder dieser Windows-Gruppen eine Anmeldung. Die Anmeldungen sind der Datenbank WaWi_SQL <\/b>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.<\/p>\n
Als ersten Schritt entfernen Sie die bestehende Rechtevergabe. Beginnen Sie mit dem Benutzer Personal<\/b>. Ö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 <\/b>zum Ordner Benutzer<\/b>. 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.<\/p>\n
<\/p>\n
Bild 1: Die Benutzer in der Datenbank<\/span><\/b><\/p>\n Per Doppelklick auf den Benutzer Personal <\/b>öffnen Sie dessen Eigenschaften-Dialog. Auf der Seite Mitgliedschaft <\/b>entfernen Sie die Häkchen zu den Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute<\/b>. Mit einem Klick auf OK <\/b>entziehen Sie dem Benutzer jegliche Zugriffsrechte.<\/p>\n Dem Benutzer Vertrieb <\/b>nehmen Sie die Rechte auf ähnliche Weise. Öffnen Sie dessen Eigenschaften<\/b>-Dialog und beenden Sie wie eben die Mitgliedschaft des Benutzers zu den Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute<\/b>. Jetzt ist noch die gesonderte Rechtevergabe des Benutzers aufzulösen. Dazu gehen Sie zur Seite Sicherungsfähige Elemente<\/b>. Markieren Sie als erstes den Eintrag zur Tabelle Bewerber <\/b>und entfernen Sie im unteren Bereich in der Spalte Verweigern <\/b>die Häkchen in den Zeilen Aktualisieren<\/b>, Auswählen<\/b>, Einfügen <\/b>und Löschen <\/b>(siehe Bild 1). Wiederholen Sie den Vorgang für die Tabellen Mitarbeiter <\/b>und Stellen<\/b>. Danach markieren Sie die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>und deaktivieren die Rechtevergabe Verweigern <\/b>zum Recht Ausführen<\/b>. Bestätigen Sie die Änderungen mit einem Klick auf OK<\/b>. Der Benutzer Vertrieb <\/b>besitzt nun ebenfalls keinerlei Zugriffsrechte mehr. Um die Benutzer Einkauf <\/b>und Buchhaltung <\/b>müssen Sie sich nicht kümmern. Diese Benutzer haben aktuell noch keine Rechte. <\/p>\n Bild 2: Entfernen des Rechts Verweigern<\/span><\/b><\/p>\n 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.<\/p>\n In der Beispielumgebung ist die Access-Applikation WaWi v2 <\/b>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<\/b>, Einkauf <\/b>und Personal <\/b>(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. <\/p>\n Bild 3: Das Start-Formular der Beispielapplikation<\/span><\/b><\/p>\n 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. <\/p>\n 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.<\/p>\n 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 <\/b>über Sicherheit|Rollen <\/b>zum Eintrag Datenbankrollen<\/b>. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie den Befehl Neue Datenbankrolle<\/b>.<\/p>\n Im folgenden Dialog geben Sie als erstes die Bezeichnung Personalwesen <\/b>in das Feld Rollenname <\/b>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 <\/b>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<\/b>.<\/p>\n Bei dem Besitzer der Datenbankrolle folgen Sie dem Grundsatz KISS. Halten Sie es einfach und geben Sie das Kürzel dbo <\/b>ein. dbo <\/b>steht für database owner <\/b>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. <\/p>\n Anschließend klicken Sie auf die Schaltfläche Hinzufügen <\/b>und wählen im folgenden Dialog über Durchsuchen <\/b>den Benutzer Personal <\/b>aus (siehe Bild 4). Ein Klick auf OK <\/b>übernimmt Ihre Auswahl in die Vorauswahl, ein weiterer Klick auf OK <\/b>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 <\/b>arbeiten dürfen. <\/p>\n Bild 4: Auswählen des Benutzers Personal<\/span><\/b><\/p>\n Fehlt noch das Werkzeug selbst, sprich die Datenbankobjekte mitsamt den Zugriffsrechten. Diese legen Sie in der Seite Sicherungsfähige Elemente <\/b>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. <\/p>\n Beginnen Sie die Analyse mit den Mitarbeiterdaten. Dazu öffnen Sie mit der Schaltfläche Mitarbeiter <\/b>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 <\/b>der Registerkarte Daten<\/b>. Dort sehen Sie den Eintrag Mitarbeiter <\/b>(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 <\/b>in der Rubrik Tabellen<\/b>.<\/p>\n Bild 5: Die Datenquelle Mitarbeiter<\/span><\/b><\/p>\n 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 <\/b>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.<\/p>\n Bild 6: Die eingebundene Tabelle Mitarbeiter<\/span><\/b><\/p>\n Gehen Sie also zurück zum Dialog Datenbankrolle – Neu <\/b>und wechseln Sie zur Registerkarte Sicherungsfähige Elemente<\/b>. Hier klicken Sie auf Suchen <\/b>und übernehmen in dem folgenden Dialog die vorgewählte Option Bestimmte Objekte<\/b>. Es öffnet sich ein weiterer Dialog. Ein Klick auf die Schaltfläche Objekttypen <\/b>bringt Sie zur nächsten Auswahlmöglichkeit. Dort aktivieren Sie die beiden Einträge Tabellen und Sichten <\/b>und bestätigen diese mit OK<\/b>. Zurück im Dialog Objekte auswählen <\/b>geben Sie in das Eingabefeld den Wert Mitarbeiter <\/b>ein und klicken auf Namen überprüfen<\/b>. Sie erhalten einen weiteren Auswahldialog, der die Tabelle Mitarbeiter <\/b>enthält (siehe Bild 7). Aktivieren Sie den Eintrag und übernehmen Sie die Auswahl mit OK<\/b>. Den Dialog Objekte auswählen <\/b>bestätigen Sie ebenfalls mit OK<\/b>.<\/p>\n Bild 7: Auswählen der Tabelle Mitarbeiter<\/span><\/b><\/p>\n Zurück im Dialog zur Datenbankrolle sehen Sie nun die Tabelle Mitarbeiter <\/b>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 <\/b>die Spalte Erteilen<\/b>. Hierüber wird das Recht SELECT <\/b>zum Lesen der Daten dieser Tabelle vergeben. Auf die gleiche Weise aktivieren Sie mit einem Klick in Erteilen <\/b>bei den Zeilen Einfügen <\/b>und Löschen <\/b>die Rechte INSERT <\/b>und DELETE<\/b>. Seien Sie vorsichtig bei der Vergabe des Rechts zum Ändern der Daten. Dieses Recht wird gerne in der Zeile Ändern <\/b>vergeben. Allerdings steht Ändern <\/b>in diesem Fall für den Befehl ALTER<\/b>, also das Recht, die Struktur der Tabelle zu ändern beziehungsweise diese zu löschen. Zur Vergabe des Rechts UPDATE <\/b>müssen Sie die Option Erteilen <\/b>in der Zeile Aktualisieren <\/b>aktivieren.<\/p>\n 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. <\/p>\n 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 <\/b>(siehe Bild 8). Dieser Klick öffnet im SQL Server Management Studio eine neue Registerkarte und füllt diese mit T-SQL-Anweisungen.<\/p>\n Bild 8: Erstellen des Rechte-Skripts<\/span><\/b><\/p>\n Mit diesen Anweisungen legen Sie später die Datenbankrolle mitsamt den Mitgliedern und den eben vergebenen Rechten zur Tabelle Mitarbeiter <\/b>an. Dieses Skript ist die Basis für die gesamte weitere Rechtevergabe.<\/p>\n Daher speichern Sie zunächst das Skript unter Rechtevergabe WaWi_SQL <\/b>und beenden dann den Dialog zur Datenbankrolle mit Abbrechen<\/b>. Jetzt räumen Sie das Skript ein wenig auf. Fassen Sie die einzelnen Zeilen zur Rechtevergabe der Tabelle Mitarbeiter <\/b>in einer Zeile zusammen und verschieben Sie die Aufnahme des Benutzers in die Datenbankrolle an das Ende des Skripts:<\/p>\n Der neue Aufbau des Skripts folgt im Gegensatz zum Dialog eher der anfangs beschriebenen Vorgehensweise. Die T-SQL-Anweisung CREATE ROLE <\/b>erstellt die Datenbankrolle, also den Werkzeugkasten. Das Werkzeug selbst wird mit der Anweisung GRANT <\/b>in den Werkzeugkasten gelegt, sprich die Tabelle Mitarbeiter <\/b>mitsamt den Zugriffsrechen SELECT<\/b>, INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>der Datenbankrolle zugeordnet. Zum Abschluss erlaubt die Anweisung ALTER ROLE <\/b>einer oder mehreren Personen die Erlaubnis mit dem Werkzeugkasten zu arbeiten, in diesem Fall durch die Zuordnung des Benutzers Personal <\/b>zur Datenbankrolle Personalwesen<\/b>.<\/p>\n 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). <\/p>\n Bild 9: Die erste Version des Rechte-Skripts<\/span><\/b><\/p>\n 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.<\/p>\n Allerdings liefert die T-SQL-Anweisung CREATE ROLE <\/b>derzeit noch einen Fehler, sollte die angegebene Datenbankrolle bereits existieren. Aus diesem Grund ergänzen Sie die T-SQL-Anweisung CREATE ROLE <\/b>mit der folgenden IF<\/b>-Anweisung. <\/p>\n Jetzt wird die Datenbankrolle nur angelegt, wenn die Funktion DATABASE_PRINCIPAL_ID <\/b>keinen Wert zurückgibt. Wobei diese Prüfung etwas unscharf ist, liefert die Funktion doch die interne ID <\/b>eines Prinzipals. Wie eben erwähnt, gehören hierzu neben den Datenbankrollen auch die Benutzer. Sollte es also einen Benutzer namens Personalwesen <\/b>geben, ist das Ergebnis ungleich NULL <\/b>und die Datenbankrolle wird nicht erstellt.<\/p>\n Vielmehr erhält der Benutzer die Rechte zur Tabelle Mitarbeiter <\/b>und die Anweisung ALTER ROLE <\/b>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 <\/b>eine ausführlichere Version. <\/p>\n [<\/p>\n Die Anweisungen GRANT <\/b>und ALTER <\/b>ROLE benötigen keine vorherigen Prüfungen. Diese Aktionen lassen sich jederzeit wiederholen, selbst wenn die Rechte bereits erteilt und die Benutzer schon der Datenbankrolle zugeordnet sind. <\/p>\n Zurück zu den Zugriffsrechten für die Personalabteilung. Die weiteren benötigten Datenbankobjekte ermitteln Sie wieder in der Beispielapplikation. Hier gibt es noch die Schaltflächen Bewerber <\/b>und Stellen<\/b>. Den Weg zu den Datenquellen der zugehörigen Formulare kennen Sie bereits. Um es kurz zu machen: Dahinter verbergen sich die Tabellen Bewerber <\/b>und Stellen<\/b>. Die Mitarbeiter der Personalabteilung dürfen den Inhalt dieser beiden Tabellen lesen und ändern. Um diese Zugriffsrechte zu vergeben, kopieren Sie im Skript die folgende Zeile:<\/p>\n Fügen Sie die Kopie unter der Originalzeile zweimal ein und ändern Sie in der ersten neuen Zeile den Tabellennamen in Bewerber und in der zweiten in Stellen. Aktuell besteht die Rechtevergabe innerhalb der Datenbankrolle aus diesen Zeilen:<\/p>\n Ein Blick in die Beispielapplikation zeigt auf der Seite der Personalabteilung noch die Schaltfläche zur Geburtstagsliste. Wie bereits erwähnt, sollen die Daten dieser Liste in Zukunft für alle Mitarbeiter zugänglich sein. Nun könnten Sie das zugehörige Datenbankobjekt inklusive der Rechtevergabe einfach in die Datenbankrolle Personalwesen <\/b>und später in alle weiteren Datenbankrollen aufnehmen. Das aber wäre zum einen unübersichtlich und zum anderen erhöht es den Aufwand zukünftiger Änderungen. Allgemeingültige Zugriffsrechte fassen Sie am besten in einer eigenen Datenbankrolle zusammen. Es gibt mehrere Ansätze für derartige Rechtevergaben – und eine gern übersehene Sicherheitslücke. Doch dazu später mehr.<\/p>\n Abgesehen von den Rechten zur Geburtstagsliste enthält das Skript alle Anweisungen zur Rechtevergabe für die Personalabteilung. Mit einem Klick auf Ausführen <\/b>legen Sie die Datenbankrolle mitsamt den definierten Zugriffsrechten und dem Mitglied Personal <\/b>an. <\/p>\n Wie eben beschrieben, können Sie diese Rechtevergabe jederzeit wiederholen. Testen Sie es einmal und klicken Sie nochmal auf Ausführen<\/b>. Die Zugriffsrechte werden erneut vergeben und das Skript fehlerfrei beendet.<\/p>\n Das Ergebnis der neuen Rechtevergabe können Sie sich im Dialog zur Datenbankrolle anschauen. Doch vorher klicken Sie im Objekt-Explorer mit der rechten Maustaste auf den Eintrag Datenbankrollen <\/b>und wählen in dessen Kontextmenü den Eintrag Aktualisieren<\/b>. Erst jetzt sehen Sie in dem Ordner ihre neue Datenbankrolle namens Personalwesen<\/b>. Mit einem Doppelklick auf die Datenbankrolle öffnen Sie den Eigenschaften<\/b>-Dialog. Dieser zeigt Ihnen im unteren Bereich der Startseite die Mitglieder der Datenbankrolle, in diesem Fall den Benutzer Personal<\/b>. In der Seite Sicherungsfähige Elemente <\/b>sehen Sie die drei Tabellen und nach Markieren der einzelnen Tabellen im unteren Bereich die jeweils erteilten Zugriffsrechte. Soweit zur Kontrolle der Rechte. Sie können den Dialog wieder schließen.<\/p>\n Im alten Berechtigungskonzept war der Benutzer Personal <\/b>den drei Datenbankrollen db_datareader<\/b>, db_datawriter <\/b>und edb_execute <\/b>zugeordnet. Nach der neuen Rechtevergabe dürfte es nur noch die Zuordnung zur Datenbankrolle Personalwesen <\/b>geben. Um dies zu prüfen, öffnen Sie den Dialog zum Benutzer Personal <\/b>und wechseln dort zur Seite Mitgliedschaft<\/b>. Voila, es ist einzig und allein die Datenbankrolle Personalwesen <\/b>aktiviert (siehe Bild 10).<\/p>\n Bild 10: Datenbankrollen des Benutzers Personal<\/span><\/b><\/p>\n Zur Kontrolle neu vergebener Zugriffsrechte sind die Dialoge durchaus brauchbar. Zum Erteilen beziehungsweise zur Analyse der Rechte ist das Skript jedoch weitaus besser geeignet. Bitte ändern Sie die Rechtevergabe nicht in den Dialogen. Eine einzige Änderung an dieser Stelle und ihr Skript verliert seinen Wert. Ändern beziehungsweise erweitern Sie die Zugriffsrechte nur über das Skript.<\/p>\n Kontrolle ist gut, ein Test ist besser. Warum nicht direkt mit der Beispielapplikation WaWi v2<\/b>? Starten Sie diese mit den Rechten des Anwenders Stromberg<\/b>. Dazu klicken Sie mit der rechten Maustaste und gedrückter Umschalt<\/b>-Taste auf das Access-Symbol in Ihrer Taskleiste und wählen Als anderer Benutzer ausführen<\/b>. In dem folgenden Dialog geben Sie die Anmeldedaten des Benutzerkontos Stromberg <\/b>ein. Sollten Sie diese Anmeldung das erste Mal nutzen, bestätigen Sie in Access die Hinweise zu den Lizenzbedingungen und den Datenschutzeinstelllungen. Anschließend öffnen Sie die Access-Applikation WaWi v2 <\/b>und aktivieren bei Bedarf die vertrauenswürdigen Inhalte.<\/p>\n Leider zeigt die Beispielapplikation anstelle des gewünschten Start-Formulars eine Fehlermeldung (siehe Bild 11). Es fehlt das Recht EXECUTE<\/b> für die gespeicherte Prozedur pSelectAnmeldung<\/b>. Diese ermittelt beim Start der Applikation die Identität des angemeldeten Anwenders und bindet anhand der gewährten Zugriffsrechte nur die erlaubten Tabellen ein. Da war wohl die Bestandsaufnahme nicht vollständig. Es hilft alles nichts. Sie müssen Ihre Rechtevergabe erweitern. Dank des Skripts ist das aber kein großer Aufwand.<\/p>\n Bild 11: Fehlermeldung beim Start der Applikation <\/span><\/b><\/p>\n Wechseln Sie zurück zu Ihrem Skript im SQL Server Management Studio und gehen Sie zu dieser Zeile:<\/p>\n Direkt darunter fügen Sie eine neue Zeile mit der folgenden T-SQL-Anweisung ein:<\/p>\n Speichern Sie das Skript und führen Sie es erneut aus. Die Zugriffsrechte wurden nun um das EXECUTE<\/b>-Recht erweitert. Zum Beweis starten Sie die Beispielapplikation wieder mit den Rechten des Anwenders Stromberg<\/b>. Dieses Mal erhalten Sie das Start-Formular mit den aktivierten Schaltflächen zur Personalabteilung (siehe Bild 12). Mit einem Klick auf die jeweiligen Schaltflächen testen Sie die aktuelle Rechtevergabe. Jede der Schaltflächen zeigt Ihnen im zugehörigen Formular die gewünschten Daten. Entsprechend der erteilten Zugriffsrechte können Sie die Daten lesen, ändern, ergänzen und löschen. <\/p>\n Bild 12: Start-Formular der Personalabteilung<\/span><\/b><\/p>\n Lediglich die Schaltfläche Geburtstagsliste <\/b>liefert eine Fehlermeldung. Das war zu erwarten. Dieser Datenzugriff ist in der Datenbankrolle Personalwesen <\/b>nicht definiert und somit dem Anwender Stromberg <\/b>nicht gestattet. <\/p>\n Wie sieht es mit den anderen Datenzugriffen aus? Bisher durften die Mitarbeiter der Personalabteilung auf alle Daten zugreifen. Dies soll durch die dedizierte Vergabe der Rechte nicht mehr möglich sein. Um dies zu testen, erweitern Sie im Navigationsbereich die Rubrik Tabellen<\/b>. Dort sehen Sie nur die Tabellen Bewerber<\/b>, Mitarbeiter <\/b>und Stellen<\/b>.<\/p>\n Das entspricht dem Berechtigungskonzept, denn die Tabellen mit den Daten des Vertriebs oder des Einkaufs wurden aufgrund fehlender Zugriffsrechte nicht eingebunden. Als nächsten Test öffnen Sie die Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter<\/b>. Sie erhalten eine Fehlermeldung – und das ist auch gut so, entspricht es doch den Anforderungen Ihres Berechtigungskonzepts und nebenbei denen des Datenschutzes.<\/p>\n Auf zum nächsten Werkzeugkasten, zur Datenbankrolle mit den Zugriffsrechten der Vertriebsmitarbeiter. Es beginnt erneut mit der Bestandsaufnahme in der Beispielapplikation. Dort gibt es für den Vertrieb die vier Schaltflächen Aufträge<\/b>, Artikel<\/b>, Kunden <\/b>und Ansprechpartner<\/b>. <\/p>\n Die Datenquelle des Formulars Aufträge <\/b>ist schnell ermittelt. Es handelt sich um die gleichnamige eingebundene Tabelle. Bei den anderen Formularen ist es etwas aufwendiger. Das Formular Artikel <\/b>enthält in der Eigenschaft Datensatzquelle <\/b>keinen Eintrag. Die Datenermittlung erfolgt in diesem Fall per ADO. Um sich den Datenzugriff genauer anzuschauen, aktivieren Sie in den Eigenschaften des Formulars die Registerkarte Ereignis <\/b>und wechseln über die Eigenschaft Beim Öffnen <\/b>zur entsprechenden VBA-Routine.<\/p>\n Hier sehen Sie, dass die Daten per ADO-Recordset aus der Tabelle Artikel <\/b>der SQL Server-Datenbank gelesen werden. Der Cursortype adOpenStatic <\/b>verrät Ihnen, dass Sie die Daten lesen und ändern sowie Datensätze löschen und neue hinzufügen dürfen (siehe Bild 13).<\/p>\n Bild 13: Datenermittlung per ADO<\/span><\/b><\/p>\n Im Formular Kunden <\/b>erfolgt die Datenermittlung ebenfalls im Ereignis Beim Öffnen<\/b>. Allerdings wird hier ein DAO-Recordset verwendet. Dieses basiert auf der eingebundenen Tabelle Kunden <\/b>und stellt die Daten mittels der Option dbOpenDynaset <\/b>für einen lesenden wie schreibenden Zugriff bereit. <\/p>\n Das Formular Ansprechpartner <\/b>hingegen enthält wieder einen Eintrag in der Eigenschaft Datensatzquelle<\/b>. Dieser verweist auf die Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter<\/b>. Ein Blick in die Pass Through-Abfrage zeigt den Aufruf der gespeicherten Prozedur pSelectAnsprechpartnerZuMitarbeiter<\/b>.<\/p>\n Somit benötigen Sie für den Werkzeugkasten die Tabellen Aufträge<\/b>, Artikel <\/b>und Kunden <\/b>mit den Rechten SELECT<\/b>, INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>sowie die gespeicherte Prozedur pSelectAnsprechpartnerZuMitarbeiter <\/b>mit dem Recht EXECUTE<\/b>. Diese Zugriffsrechte erteilen Sie wieder per Skript. <\/p>\n Öffnen Sie Ihr Skript Rechtevergabe WaWi_SQL <\/b>und kopieren Sie den kompletten Block zur Datenbankrolle Personalwesen<\/b>. Danach gehen Sie ans Ende des Skripts, fügen erst ein paar Leerzeilen und dann den Text der Zwischenablage ein. Nun passen Sie die neuen Zeilen an die Rechtevergabe des Vertriebs an. <\/p>\n Es beginnt mit den Zeilen zum Anlegen der Datenbankrolle. Hier ändern Sie den Begriff Personalwesen <\/b>in Vertriebswesen<\/b>.<\/p>\n Die nächsten Zeilen legen die Zugriffsrechte an den Tabellen fest. Dort ersetzen Sie zum einen wieder den Begriff Personalwesen <\/b>in Vertriebswesen <\/b>und überschreiben die Tabellen Bewerber<\/b>, Mitarbeiter <\/b>und Stellen <\/b>mit Artikel<\/b>, Auftraege <\/b>und Kunden<\/b>.<\/p>\n Es folgt die Zeile zur Rechtevergabe der gespeicherten Prozedur pSelectAnmeldung<\/b>, in der Sie wieder den Begriff Personalwesen <\/b>mit Vertriebswesen <\/b>überschreiben. <\/p>\n Anschließend kopieren Sie die Zeile und fügen sie direkt als nächste Zeile ein. Hier ändern Sie den Namen der gespeicherten Prozedur in pSelectAnsprechpartnerZuMitarbeiter<\/b>.<\/p>\n Mit der neuen Zeile ist der Werkzeugkasten mit dem notwendigen Werkzeug befüllt oder um es etwas technischer auszudrücken, die Datenbankrolle Vertriebswesen <\/b>enthält die erforderlichen Datenbankobjekte mitsamt den Zugriffsrechten. <\/p>\n Fehlt noch die Zuordnung der Datenbankrolle zum Benutzer. Den zugehörigen T-SQL-Befehl sehen Sie in der letzten Zeile. Wieder einmal tauschen Sie den Begriff Personalwesen <\/b>mit Vertriebswesen <\/b>und ändern dann den Benutzernamen in Vertrieb<\/b>.<\/p>\n Abschließend passen Sie die Dokumentation der neuen Zeilen an, speichern das Skript und führen es mit der Taste F5 <\/b>aus. Das war es schon. Die Zugriffsrechte sind vergeben und gleichzeitig im Skript dokumentiert. <\/p>\n Bei einer größeren Access-Applikation wird der Analyseaufwand wie die Pflege des Skripts natürlich etwas aufwendiger sein. Möglicherweise sagt Ihnen die Vorgehensweise per Copy\/Paste nicht so zu und eventuell halten Sie es sogar für unprofessionell. Das mag sein und es ist ein durchaus berechtigter Einwand. Im Endeffekt aber liefert Ihnen das Skript eine bessere Übersicht und gleichzeitig eine Dokumentation Ihrer Rechtevergabe. Ein immenser Vorteil, den Ihnen der Dialog zur Datenbankrolle nicht bietet. <\/p>\n Den Dialog können Sie weiterhin gerne zur Kontrolle nutzen. Vorab müssen Sie wieder den Inhalt des Ordners Datenbankrollen <\/b>neu laden. Dazu wählen Sie in dessen Kontextmenü den Eintrag Aktualisieren<\/b>. Danach öffnen Sie den Dialog mit einem Doppelklick auf die Datenbankrolle Vertriebswesen<\/b>. In der ersten Seite sehen Sie unter Mitglieder <\/b>den Benutzer Vertrieb <\/b>und auf der Seite Sicherungsfähige Elemente <\/b>die drei Tabellen sowie die zwei gespeicherten Prozeduren mit den erteilten Rechten. <\/p>\n Nach der erfolgreichen Kontrolle folgt der Test der neuen Zugriffsrechte mit der Beispielapplikation. Dieses Mal starten Sie die Access-Applikation mit den Rechten des Anwenders Bienlein<\/b>. Im Start<\/b>-Formular klicken Sie nacheinander auf die Schaltflächen des Vertriebs. Entsprechend der Berechtigungsvergabe können Sie die Daten der Aufträge, Artikel und Kunden lesen, ändern, löschen und ergänzen.<\/p>\n Die Daten der Ansprechpartner hingegen sind nur lesbar. Die Datenermittlung basiert auf einer Pass Through-Abfrage und dieses Access-Objekt liefert die Daten immer schreibgeschützt. Ein Klick auf die Schaltfläche Geburtstagsliste <\/b>zeigt Ihnen korrekterweise wieder die Fehlermeldung mit dem Hinweis auf das nicht erteilte EXECUTE<\/b>-Recht. Bleibt noch der Test der nicht gewährten Zugriffsrechte. Dazu erweitern Sie den Navigationsbereich. Dort sehen Sie wie erwartet nur die Tabellen für den Vertrieb. Alles in allem ein zufriedenstellendes Testergebnis.<\/p>\n Mit den Mitarbeitern des Einkaufs gibt es neue Anwender für die Beispielapplikation. Diese arbeiten mit den Schaltflächen Bestellungen<\/b>, Produkte<\/b>, Lieferanten <\/b>und Wareneingang<\/b>. Die Formulare hinter den ersten drei Schaltflächen beinhalten als Datenherkunft die eingebundenen Tabellen Bestellungen<\/b>, Produkte <\/b>und Lieferanten<\/b>. Etwas komplexer ist es beim Formular Wareneingang<\/b>, welches auf der gleichnamigen Access-Abfrage basiert. Diese bereitet die Daten der eingebundenen Tabellen Bestellungen <\/b>und Lieferanten <\/b>auf. Letztendlich erfolgt der Datenzugriff im Einkauf also ausschließlich über eingebundene Tabellen.<\/p>\n Die Zugriffsrechte vergeben Sie wie eben bei der Datenbankrolle Vertriebswesen<\/b>. Wieder kopieren Sie den kompletten Block zur Datenbankrolle Personalwesen <\/b>und fügen diesen am Ende des Skripts ein. In den neuen Zeilen ersetzen Sie den Begriff Personalwesen <\/b>mit Bestellwesen<\/b>, passen die Tabellennamen an die Tabellen des Einkaufs an und überschreiben den Benutzer Personal <\/b>mit Einkauf<\/b>. Als Ergebnis sollten die T-SQL-Anweisungen zur Datenbankrolle Bestellwesen <\/b>wie folgt aussehen:<\/p>\n Nachdem Sie die Zeilen zur neuen Rechtevergabe ausführlich dokumentiert haben, speichern Sie das Skript und führen es per F5 <\/b>aus. Anschließend aktualisieren Sie in gewohnter Weise den Ordner Datenbankrollen <\/b>und öffnen den Eigenschaften-Dialog zur neuen Datenbankrolle Bestellwesen<\/b>. Hier sehen Sie den zugeordneten Benutzer Einkauf <\/b>und in der Seite Sicherungsfähige Elemente <\/b>die Tabellen und die gespeicherte Prozedur mit den eben erteilten Zugriffsrechten (siehe Bild 14).<\/p>\n Bild 14: Rechte der Datenbankrolle Bestellwesen<\/span><\/b><\/p>\n Zum Test der erweiterten Rechtevergabe starten Sie die Beispielapplikation mit den Rechten des Anwenders Eberhofer<\/b>. Jetzt bietet Ihnen das Start<\/b>-Formular die Schaltflächen Bestellungen<\/b>, Produkte<\/b>, Lieferanten<\/b>, Wareneingang <\/b>und Geburtstagsliste<\/b>. Jede dieser Schaltflächen erlaubt Ihnen in den zugehörigen Formularen den lesenden und schreibenden Datenzugriff. Bis auf die Schaltfläche Geburtstagsliste<\/b>, die Ihnen die bereits erwartbare Fehlermeldung liefert. Die nicht gewährten Rechte testen Sie in diesem Fall wieder mit der Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter<\/b>. Der Zugriff auf die Daten der Ansprechpartner der Kunden ist den Mitarbeitern im Einkauf nicht gestattet, weshalb Sie berechtigterweise eine Fehlermeldung erhalten.<\/p>\n Das sieht doch gut aus. Aber handelt es sich um eine wirklich gute Rechtevergabe? Entspricht diese den Vorgaben der Funktionstrennung oder bietet das aktuelle Berechtigungskonzept etwa noch die Möglichkeit eines Datenmissbrauchs? Denken Sie an den Fall Bienlein. Durch die neuen Zugriffsrechte ist es Frau Bienlein zwar nicht mehr möglich, auf die Daten der Lieferanten und auf die der Wareneingänge zuzugreifen. Doch was ist mit den Mitarbeitern im Einkauf? Denen steht nichts im Wege, fiktive Lieferanten anzulegen und fingierte Bestellungen inklusive Wareneingänge zu erfassen. Um dies zu vermeiden, sollten Sie die Rechtevergabe nochmals überdenken und dabei die Zuständigkeiten genauer berücksichtigen.<\/p>\n Natürlich kann man über die Zuständigkeiten des Einkaufs diskutieren. Betriebswirtschaftlich betrachtet gehört das Buchen von Wareneingängen nicht unbedingt zu den Aufgaben des Einkaufs. Nur gibt es in dem kleinen Beispielunternehmen einfach nicht genügend Personal und so übernimmt der Einkauf halt eben auch die Buchung der Wareneingänge. Die Verwaltung der Lieferanten liegt jedoch in der Obhut der Buchhaltung. Nur dort werden neue Lieferanten erfasst und freigegeben sowie bei Bedarf die Daten der bestehenden geändert. Für die Mitarbeiter im Einkauf reicht der lesende Zugriff auf die Lieferantendaten vollkommen aus. Aus diesem Grund sind die Funktionen zum Buchen der Wareneingänge von denen zur Verwaltung der Lieferanten zu trennen.<\/p>\n Diese neue Betrachtung erfordert eine Anpassung der bisherigen Rechtevergabe. Der Datenbankrolle Bestellwesen <\/b>sind für die Tabelle Lieferanten <\/b>die Rechte INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>zu entziehen. Dazu gehen Sie im Skript zur Rechtevergabe der Tabelle Lieferanten und kopieren die folgende Zeile:<\/p>\n Die Kopie fügen Sie direkt unterhalb der Zeile ein. In der Ursprungszeile löschen Sie die Einträge INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>. Übrig bleibt in dieser GRANT<\/b>-Anweisung nur das Recht SELECT<\/b>. <\/p>\n Mit der neu eingefügten Zeile entziehen Sie die bereits erteilten Rechte INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>. Ändern Sie dazu die T-SQL-Anweisung GRANT <\/b>in REVOKE<\/b>. Anschließend entfernen Sie in der Auflistung den Eintrag SELECT<\/b>:<\/p>\n Warum nun zwei SQL-Anweisungen für eine Rechtevergabe? Letztendlich braucht es doch nur die GRANT<\/b>-Anweisung für das SELECT <\/b>zur Tabelle Lieferanten<\/b>. Die bereits erteilten Rechte INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>könnte man doch einmalig per Dialog entziehen. Im Grunde genommen wäre das auch vollkommen ausreichend. <\/p>\n Auf der anderen Seite zeigen die beiden Zeilen wieder einmal die Vorteile des Skripts. Mit der REVOKE<\/b>-Anweisung stellen Sie sicher, dass die neu erkannte Anforderung an die Rechtevergabe mit jeder Ausführung des Skripts umgesetzt wird. Angenommen, ein Kollege erteilt per Dialog der Datenbankrolle Bestellwesen <\/b>die Rechte INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>an der Tabelle Lieferanten<\/b>. Spätestens mit der nächsten Ausführung des Skripts wird diese fehlerhafte Rechtevergabe gemäß den Vorgaben korrigiert. REVOKE <\/b>lässt sich wie GRANT <\/b>mehrmals ausführen und das unabhängig davon, ob das Recht erteilt ist oder nicht. <\/p>\n Ergänzen Sie die beiden Zeilen mit einer aussagekräftigen Dokumentation. Je besser Sie den Grund der geänderten Rechtevergabe beschreiben, umso einfacher können Sie die Änderung zu einem späteren Zeitpunkt nachvollziehen. <\/p>\n Mit dem aktuellen Stand des Berechtigungskonzepts darf keiner der Anwender die Daten der Lieferanten verwalten. Dazu ist eine weitere Datenbankrolle mit entsprechenden Rechten für die Mitarbeiter der Buchhaltung erforderlich. Das ist nun nichts Neues mehr für Sie. Um die Sache abzukürzen, kopieren Sie den Inhalt des Beispielskripts Rechtevergabe Buchhaltung <\/b>und übernehmen Sie diesen an das Ende Ihres Skripts. Sie müssen lediglich in der letzten Zeile die Domäne BJSEMINARE <\/b>mit dem Namen Ihrer Domäne überschreiben. Mit den neuen Zeilen ist das Skript zur Rechtevergabe bereit zur Ausführung. Speichern Sie das Skript und führen Sie es wieder einmal mit F5 <\/b>aus. <\/p>\n [50097]<\/p>\n Danach starten Sie die Beispielapplikation mit der Anmeldung Eberhofer<\/b> und klicken im Start<\/b>-Formular auf die Schaltfläche Lieferanten<\/b>. Zum Test der neuen Zugriffsrechte ändern Sie einen beliebigen Wert und wechseln zum nächsten Datensatz. Als Anwender Eberhofer <\/b>dürfen Sie die Daten der Lieferanten nur noch lesen, weshalb Ihre Datenänderung mit der Fehlermeldung aus Bild 15 quittiert wird. <\/p>\n Bild 15: Fehlende UPDATE-Rechte für den Einkauf<\/span><\/b><\/p>\n Wareneingänge dürfen Sie weiterhin buchen. Die Daten des Formulars Wareneingang <\/b>liefert die gleichnamige Access-Abfrage. Diese enthält neben der Tabelle Lieferanten <\/b>noch die Tabelle Bestellungen <\/b>mit den Informationen zu den Wareneingängen. Obwohl Sie die Daten der Bestellungen über die Access-Abfrage ändern können, gilt dies nicht für die Daten der Lieferanten. Versuchen Sie mal im Formular Wareneingänge <\/b>einen der Firmennamen zu ändern. Sie erhalten wieder die gleiche Fehlermeldung.<\/p>\n [51156]<\/p>\n Der schreibende Zugriff auf die Lieferantendaten ist den Mitarbeitern der Buchhaltung vorbehalten. Das können Sie ebenfalls testen. Starten Sie dazu die Beispielapplikation als Anwender Kling<\/b>. Im Start<\/b>-Formular sind jetzt nur die Schaltflächen Lieferanten <\/b>und Geburtstagsliste <\/b>aktiv. Ein Klick auf die Schaltfläche Lieferanten <\/b>öffnet das zugehörige Formular. Dort ändern Sie die Telefonnummer eines Lieferanten Ihrer Wahl und wechseln den Datensatz. Die Datenänderung wird ohne Weiteres übernommen. Schließlich dürfen Sie als Mitglied der Windows-Gruppe Buchhaltung <\/b>die Daten der Lieferanten lesen und ändern. <\/p>\n [51644]<\/p>\n [52255]<\/p>\n Das Berechtigungskonzept ist fast vollständig. Es fehlt noch die Freigabe der Geburtstagsliste. Ein Blick in die Beispielapplikation zeigt als Datengrundlage des Formulars Geburtstagsliste <\/b>eine Pass Through-Abfrage mit dem Aufruf der gespeicherten Prozedur pSelectGeburtstagsliste<\/b>. Da alle Anwender die Daten dieser Liste sehen dürfen, ist jedem Benutzer der Datenbank das Ausführen dieser gespeicherten Prozedur zu erlauben. Nun könnten Sie wie bei der gespeicherten Prozedur pSelectAnmeldung <\/b>das entsprechende EXECUTE<\/b>-Recht in jede Ihrer Datenbankrollen aufnehmen. Viel besser ist jedoch die bereits erwähnte zentrale Rechtevergabe, sprich ein EXECUTE<\/b>-Recht zu dieser gespeicherten Prozedur in einer Datenbankrolle. <\/p>\n [52281]<\/p>\n SQL Server bietet zur Definition solch allgemeingültiger Rechte die Systemdatenbankrolle public <\/b>an. In dieser Datenbankrolle ist jeder Benutzer standardmäßig Mitglied. Diese Mitgliedschaft ist fix und lässt sich nicht aufheben. Somit gelten die in der Datenbankrolle public <\/b>erteilten Zugriffsrechte für alle Benutzer der Datenbank. Das bietet sich doch für die EXECUTE<\/b>-Rechte der beiden gespeicherten Prozeduren pSelectGeburtstagsliste <\/b>und pSelectAnmeldung <\/b>geradezu an.<\/p>\n [53000]<\/p>\n Zur Rechtevergabe wechseln Sie im Objekt-Explorer zur Datenbankrolle public <\/b>der Datenbank WaWi_SQL <\/b>und öffnen per Doppelklick den zugehörigen Dialog. Die Seite Allgemein <\/b>zeigt im Bereich Mitglieder <\/b>dieser Rolle keine Benutzer. Lassen Sie sich davon nicht verwirren. Wie gesagt ist jeder Benutzer Mitglied dieser Datenbankrolle. Microsoft scheint eine Auflistung aller Benutzer an dieser Stelle für überflüssig zu halten, obwohl es durchaus aussagekräftiger wäre. Da Sie sich um die Verwaltung der Mitglieder keine Gedanken machen müssen, gehen Sie direkt zur Seite Sicherungsfähige Elemente<\/b>. Hier sehen Sie bereits erteilte SELECT<\/b>-Rechte an einigen Systemobjekten. Diese ergänzen Sie nun mit den Rechten zur gespeicherten Prozedur pSelectGeburtstagsliste<\/b>. Dazu klicken Sie auf Suchen<\/b>, wählen als Auswahlkriterium Alle Objekte des Typs <\/b>und aktivieren im Dialog Objekttypen auswählen <\/b>den Eintrag Gespeicherte Prozeduren<\/b>. Nach Bestätigen der Auswahl mit OK <\/b>sehen Sie im Dialog zur Datenbankrolle im oberen Bereich alle gespeicherten Prozeduren.<\/p>\n [53470]<\/p>\n Dort markieren Sie die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>und aktivieren im unteren Bereich in der Zeile Ausführen <\/b>die Option Erteilen<\/b>. Mit einem Klick auf OK <\/b>speichern Sie die Rechtevergabe. Sie haben richtig gelesen. In diesem Fall nehmen Sie die Rechtevergabe nicht in das Skript auf, sondern bestätigen den Dialog mit OK<\/b>. Warum in diesem Fall per Dialog? Weil es nicht bei dieser Art der Rechtevergabe bleiben wird. Das ist auch der Grund, warum Sie die Zugriffsrechte für die gespeicherte Prozedur pSelectAnmeldedaten <\/b>erst einmal ignorieren.<\/p>\n [54512]<\/p>\n Für den Test der neuen Zugriffsrechte starten Sie die Beispielapplikation als Anwender Eberhofer<\/b>. Nach einem Klick auf die Schaltfläche Geburtstagsliste <\/b>sehen Sie die Geburtstage aller Mitarbeiter. Weitere Tests mit den Anmeldungen Bienlein<\/b>, Stromberg <\/b>und Kling <\/b>liefern Ihnen das gleiche Ergebnis.<\/p>\n [55070]<\/p>\n Alle diese Anwender gehören zu Windows-Gruppen, zu denen im SQL Server entsprechende Anmeldungen existieren. Zu jeder dieser Anmeldungen gibt es in der Datenbank WaWi_SQL <\/b>einen Benutzer. Alle Benutzer der Datenbank sind standardmäßig der Datenbankrolle public <\/b>zugeordnet und diese besitzt das Recht EXECUTE <\/b>für die gespeicherte Prozedur pSelectGeburtstagsliste<\/b>. <\/p>\n [55368]<\/p>\n Wohlgemerkt, alle Benutzer der Datenbank! Das gilt genauso für Gäste. SQL Server bietet für Gastzugriffe den Benutzer guest <\/b>(siehe Bild 16). Dieser Benutzer erlaubt jeder Anmeldung im SQL Server den Zutritt zur Datenbank. Eine explizite Zuordnung der Anmeldung zur Datenbank ist in diesem Fall nicht erforderlich. Innerhalb der Datenbank darf ein Gast mit den Rechten der Datenbankrolle public <\/b>auf die Daten zugreifen. <\/p>\n Bild 16: Das Gast-Konto der Datenbank<\/span><\/b><\/p>\n Sie sind bestimmt ein guter Gastgeber und freuen sich über Gäste. Dennoch lassen Sie nicht jeden einfach ungefragt in Ihre Wohnung. Wie im echten Leben sollte auch beim SQL Server der Zugang eines Gasts erlaubt sein. Daher ist das Gastkonto einer Datenbank standardmäßig deaktiviert. Sie müssen den Gastzugang explizit freigeben. Doch das ist nicht so einfach. Weder der Dialog zum Benutzer guest<\/b> noch dessen Kontextmenü bietet hierzu eine Möglichkeit. Der Benutzer guest <\/b>lässt sich nur per T-SQL aktivieren. Dazu öffnen Sie über das Kontextmenü der Datenbank WaWi_SQL <\/b>eine neue Abfrage und führen diese T-SQL-Anweisung aus:<\/p>\n [56151]<\/p>\n [56776]<\/p>\n Anschließend wählen Sie im Kontextmenü des Ordners Benutzer <\/b>den Eintrag Aktualisieren<\/b>. Worauf Sie den Eintrag guest <\/b>nun als aktiven Benutzer sehen. <\/p>\n [56800]<\/p>\n Für einen Test des Gastzugangs legen Sie mit der folgenden T-SQL-Anweisung die Anmeldung TestPublic <\/b>an. <\/p>\n [56949]<\/p>\n [57054]<\/p>\n Die CREATE LOGIN<\/b>-Anweisung erstellt lediglich die Anmeldung. Es findet keine Zuordnung zur Datenbank WaWi_SQL <\/b>statt, weshalb es dort auch keinen entsprechenden Benutzer zur Anmeldung gibt. Dennoch können Sie mit der Anmeldung TestPublic <\/b>auf die Daten der Geburtstagsliste zugreifen. <\/p>\n [57111]<\/p>\n Diesen Datenzugriff testen Sie direkt im SQL Server Management Studio. Melden Sie sich über die Schaltfläche Verbinden <\/b>mit der Anmeldung TestPublic <\/b>an. Dabei verwenden Sie die Authentifizierungsmethode SQL Server-Authentifizierung (siehe Bild 17). <\/p>\n Bild 17: Neue Verbindung mit der Anmeldung TestPublic<\/span><\/b><\/p>\n Nach Bestätigen des Anmeldedialogs sehen Sie im Objekt-Explorer für die neue Verbindung einen eigenen Zweig (siehe Bild 18). Erweitern Sie dort den Eintrag Datenbanken <\/b>und wählen Sie im Kontextmenü der Datenbank WaWi_SQL <\/b>den Eintrag Neue Abfrage<\/b>. Sie erhalten eine neue Registerkarte basierend auf der Anmeldung TestPublic<\/b>. Hier führen Sie nun die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>aus:<\/p>\n Bild 18: Zugriff mit der Anmeldung TestPublic<\/span><\/b><\/p>\n [58043]<\/p>\n Als Ergebnis sehen Sie die Geburtstage der Mitarbeiter (siehe Bild 19). Und das ohne einen Benutzer zur Anmeldung TestPublic<\/b>. Der Datenzugriff erfolgt durch den aktiven Benutzer guest<\/b>. Diesem ist durch die Rechtevergabe der Datenbankrolle public <\/b>das Ausführen der gespeicherten Prozedur erlaubt. <\/p>\n Bild 19: Datenzugriff über Datenbankrolle public<\/span><\/b><\/p>\n Zur Erinnerung: Nicht nur die Anmeldung TestPublic <\/b>besitzt diese Zugriffsrechte, sondern jede Anmeldung in Ihrem SQL Server. Das allein ist schon unübersichtlich genug. Und es wird noch undurchsichtiger, basieren die Anmeldungen in der Regel doch auf Windows-Gruppen. Wie heißt es so schön? Rate mal, wer zum Essen kommt. Sie können sich auf eine Schar Gäste einrichten. <\/p>\n [58374]<\/p>\n Erkennen Sie die Dimension dieser Sicherheitslücke? Sie als Datenbankadministrator haben keinen Überblick, wer mit den Rechten der Datenbankrolle public<\/b> auf die Daten der Datenbank zugreift. <\/p>\n [58746]<\/p>\n Sie stufen einen allgemeinen Zugang auf eine Geburtstagsliste als vertretbar ein? Das diskutieren Sie mal mit Ihrem Datenschutzbeauftragten. Jeder Anwender mit einer direkten oder indirekten Anmeldung kann diese Daten lesen. Zum Beispiel externe Mitarbeiter, die in einer weiteren Datenbank ihre Arbeitszeiten erfassen. Grundsätzlich wären diese ebenso in der Lage, die Geburtstage der Mitarbeiter zu sehen. Das entspräche nicht den Anforderungen des Datenschutzes und möglicherweise auch nicht dem Wunsch des einen oder anderen Mitarbeiters.<\/p>\n [58938]<\/p>\n Allein durch die Leserechte der Datenbankrolle public <\/b>ist die Vertraulichkeit der Daten nicht mehr gegeben. Erhält die Datenbankrolle zudem noch Schreibrechte, lässt sich auch die Integrität der Daten nicht mehr gewährleisten. Dies soll ein weiteres Beispiel verdeutlichen.<\/p>\n [59481]<\/p>\n Der Einfachheit halber wurde der Benutzer guest <\/b>in der Datenbank zur Zeiterfassung der externen Mitarbeiter aktiviert. In dieser Datenbank besitzt die Datenbankrolle public <\/b>die vollen Lese- und Schreibrechte zu den Tabellen mit den Arbeitszeiten. Durch diese Rechtevergabe kann jeder Anwender mit einer gültigen Anmeldung im SQL Server, ob nun direkt über sein Windows-Benutzerkonto oder indirekt über eine oder mehrere Windows-Gruppen, die Daten dieser Tabellen zu seinen Gunsten manipulieren. <\/p>\n [59755]<\/p>\n Es gibt eine einfache Vorgabe zur Datenbankrolle public<\/b>. Ignorieren! Selbst Microsoft spricht diese Empfehlung aus. Das Benutzerkonto guest <\/b>lassen Sie deaktiviert. Weigern Sie sich es zu aktivieren. Es muss schon sehr gute Gründe dafür geben.<\/p>\n [60251]<\/p>\n Diese Empfehlungen gelten ebenso für die Datenbank WaWi_SQL<\/b>. Weshalb Sie den Gastzugang jetzt wieder schließen. Gehen Sie im Objekt-Explorer zu dem Zweig mit Ihrer administrativen Anmeldung, markieren Sie dort die Datenbank WaWi_SQL <\/b>und öffnen Sie über das Kontextmenü eine neue Abfrage. In der Registerkarte führen Sie diese T-SQL-Anweisung aus:<\/p>\n [60494]<\/p>\n [60841]<\/p>\n Anschließend entziehen Sie der Datenbankrolle public <\/b>die Zugriffsrechte. Öffnen Sie den Dialog zur Datenbankrolle und wechseln Sie dort zur Seite Sicherungsfähige Elemente<\/b>. Hier markieren Sie die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>und entfernen im unteren Bereich das erteilte Recht Ausführen<\/b>. Die Änderung übernehmen Sie mit einem Klick auf OK<\/b>.<\/p>\n [60866]<\/p>\n Bleibt noch die Anmeldung TestPublic<\/b>. Der Ordnung halber sollten Sie diese wieder löschen. Vorher aber trennen Sie noch die aktiven Verbindungen. Dazu schließen Sie die Registerkarte, mit der Sie die gespeicherte Prozedur pSelectGeburtstagsliste <\/b>ausgeführt haben. Danach markieren Sie im Objekt-Explorer den Zweig mit der Anmeldung TestPublic <\/b>und wählen im Kontextmenü den Eintrag Trennen <\/b>(siehe Bild 20).<\/p>\n Bild 20: Trennen der TestPublic-Verbindung <\/span><\/b><\/p>\n Obwohl augenscheinlich keine aktive Verbindung mehr besteht, lässt sich die Anmeldung noch nicht löschen. SQL Server hält die Verbindung noch einige Zeit offen. Warten Sie ein paar Minuten und entfernen Sie die Anmeldung dann mit dieser T-SQL-Anweisung:<\/p>\n [61629]<\/p>\n [61883]<\/p>\n So weit so gut. Die Sicherheitslücke ist geschlossen. Der Gastzugang zur Datenbank WaWi_SQL <\/b>ist deaktiviert und die Datenbankrolle public <\/b>besitzt keine Zugriffsrechte mehr. Womit allerdings die eigentliche Anforderung wieder offen wäre. Wie legen Sie in einer Datenbank allgemeingültige Zugriffsrechte fest? Die Antwort ist so einfach wie naheliegend. Mit einer eigenen Datenbankrolle. <\/p>\n [61906]<\/p>\n [62293]<\/p>\n Zum Erstellen der neuen Datenbankrolle nutzen Sie natürlich wieder das Skript. Erneut kopieren Sie die Zeilen zur Rechtevergabe der Datenbankrolle Personalwesen <\/b>und fügen diese ans Ende des Skripts ein. <\/p>\n [62322]<\/p>\n Als erstes löschen Sie in den neuen Zeilen die GRANT<\/b>-Anweisungen mit den Zugriffsrechten zu den Tabellen. Danach ersetzen Sie den Begriff Personalwesen <\/b>mit der Bezeichnung der neuen Datenbankrolle. Diese müssten Sie vorher noch festlegen. Sie sollte den Inhalt und somit die allgemeingültige Rechtevergabe widerspiegeln. Wie wäre es mit der Bezeichnung Allgemein<\/b>? Einverstanden? Dann ersetzen Sie in den neuen Zeilen den Begriff Personalwesen mit Allgemein<\/b>.<\/p>\n [62526]<\/p>\n Aktuell besteht die Rechtevergabe der neuen Datenbankrolle lediglich aus der GRANT<\/b>-Anweisung zur gespeicherten Prozedur pSelectAnmeldung<\/b>. Diese ist ebenfalls für alle Benutzer erforderlich und gehört exakt in diese Datenbankrolle. Für die Freigabe der Geburtstagsliste erstellen Sie eine Kopie dieser Zeile und platzieren sie direkt unter der Originalzeile. In der neuen Zeile ersetzen Sie den Namen der gespeicherten Prozedur mit pSelectGeburtstagsliste<\/b>. <\/p>\n [62984]<\/p>\n Zum Schluss kopieren Sie die ALTER ROLE<\/b>-Anweisung und fügen diese dreimal ein. Bei der ersten Kopie tauschen Sie den Benutzer Personal <\/b>mit dem Benutzer Vertrieb<\/b>, bei der zweiten mit dem Benutzer Einkauf <\/b>und bei der dritten mit dem Benutzer Buchhaltung<\/b>. Die angepassten T-SQL-Anweisungen sehen nun so aus:<\/p>\n [63441]<\/p>\n [63746]<\/p>\n [63801]<\/p>\n [63807]<\/p>\n [63852][63856]<\/p>\n [63857]<\/p>\n [63909][63968]<\/p>\n [63969]<\/p>\n [64024]<\/p>\n [64079]<\/p>\n [64133]<\/p>\n Die Rechtevergabe zur Datenbankrolle Allgemein <\/b>ist soweit komplett. Allerdings erhält die gespeicherte Prozedur pSelectAnmeldung <\/b>das EXECUTE<\/b>-Recht an mehreren Stellen im Skript. Die entsprechende GRANT<\/b>-Anweisung findet sich in der neuen wie in allen anderen Datenbankrollen. Für die Skriptausführung stellt dies kein Problem dar. Für die Lesbarkeit und somit für die Pflege des Skripts allerdings schon. Denken Sie an den Grundsatz KISS. Halten Sie die Rechtevergabe so einfach und klar wir möglich. <\/p>\n [64191]<\/p>\n Nun könnten Sie die ursprünglichen Zeilen in den einzelnen Datenbankrollen einfach löschen. Eine bessere Variante ist jedoch, den Datenbankrollen per REVOKE <\/b>das Recht zur Ausführung der gespeicherten Prozedur zu entziehen. Den Vorteil von REVOKE <\/b>kennen Sie bereits. Hiermit stellen Sie sicher, dass manuelle Änderungen dieser Rechte per Dialog bei der nächsten Skriptausführung wieder korrigiert werden. Dazu kommt, dass Sie anhand einer guten Dokumentation den Grund für diese Rechtevergabe jederzeit nachvollziehen können. <\/p>\n [64692]<\/p>\n Für die anstehenden Änderungen nutzen Sie eine der Grundfunktionen eines Editors. Mit Strg + F <\/b>öffnen Sie die Suche und tragen dort den Suchbegriff pSelectAnmeldung <\/b>ein. Starten Sie die Suche mit einem Klick auf den Pfeil (siehe Bild 21). Der erste Treffer ist die Rechtevergabe in der Datenbankrolle Personalwesen<\/b>. <\/p>\n Bild 21: Suchen im Rechte-Skript<\/span><\/b><\/p>\n [65535]<\/p>\n Hier überschreiben Sie die T-SQL-Anweisung GRANT <\/b>mit REVOKE<\/b>. <\/p>\n [65591]<\/p>\n [65653]<\/p>\n Dokumentieren Sie die Änderung, bevor Sie mit der Suche zum nächsten Ergebnis gehen. Diese führt Sie zur Datenbankrolle Vertriebswesen<\/b>. Hier ändern Sie ebenfalls die T-SQL-Anweisung GRANT <\/b>in REVOKE<\/b>. Die nächsten Suchergebnisse bringen Sie zu den Zeilen der Datenbankrollen Bestellwesen und Buchhaltung, in denen Sie wieder GRANT <\/b>mit REVOKE <\/b>ersetzen. Das letzte Suchergebnis ist die Rechtevergabe zur Datenbankrolle Allgemein. Diese bleibt unverändert. Das war es schon. Die Überarbeitung des Skripts ist abgeschlossen.<\/p>\n [65710]<\/p>\n Zugegeben, das waren jetzt überschaubare Anpassungen des Berechtigungskonzepts. Die vier Zeilen hätten Sie auch ohne die Suchfunktion gefunden. Das Beispiel zeigt aber einen weiteren Vorteil der Rechtevergabe per Skript. Angenommen, ein Anwender informiert Sie über eine Fehlermeldung. Diese weist auf das fehlende Zugriffsrecht SELECT <\/b>für die Tabelle Arbeitszeiten hin. In diesem Fall öffnen Sie Ihr Skript, drücken STRG + F<\/b> und suchen nach dem Begriff Arbeitszeiten<\/b>. Die Suche führt Sie zu jedem Eintrag, der in irgendeiner Form etwas mit dem Suchbegriff zu tun hat. Auf diese Weise prüfen Sie nach und nach die Rechtevergabe. Anhand Ihrer guten Dokumentation können Sie die erteilten beziehungsweise entzogenen Zugriffsrechte einfach nachvollziehen und erkennen schnell die Ursache für die Fehlermeldung. Sei es ein tatsächlich fehlendes Zugriffsrecht oder der Anwender darf aus gutem Grund nicht auf die Daten der Tabelle zugreifen.<\/p>\n [66229]<\/p>\n Ähnlich dem Entziehen von Rechten per REVOKE <\/b>verfahren Sie mit Anpassungen der Mitgliedschaften einer Datenbankrolle. Beispielsweise könnten Sie den Benutzer Buchhaltung<\/b> aus der Datenbankrolle Allgemein <\/b>mit dieser Anweisung entfernen.<\/p>\n [67166]<\/p>\n [67401]<\/p>\n Aus ADD MEMBER <\/b>wird DROP MEMBER<\/b>. Diese Anweisung lässt sich wie die anderen problemlos ausführen, selbst wenn der Benutzer nicht zur Datenbankrolle gehört. Wieder einmal genießen Sie den Vorteil des Skripts. Mit jeder Skriptausführung stellen Sie sicher, dass die Zugriffsrechte den Vorgaben Ihres Berechtigungskonzepts entsprechen. In diesem Fall, dass der Benutzer kein Mitglied der Datenbankrolle ist.<\/p>\n [67460]<\/p>\n Das Skript zur Rechtevergabe ist fertig. Ein letztes Mal speichern Sie die Änderungen und führen das Skript mit F5 <\/b>aus. Die neue Datenbankrolle und deren Zugriffsrechte können Sie sich wieder im Dialog anschauen. Dazu aktualisieren Sie wie gewohnt den Ordner Datenbankrollen <\/b>und öffnen anschließend den Dialog zur Datenbankrolle Allgemein<\/b>. Auf der ersten Seite sehen Sie im unteren Bereich als Mitglieder die Benutzer Buchhaltung<\/b>, Einkauf<\/b>, Personal <\/b>und Vertrieb <\/b>(siehe Bild 22).<\/p>\n Bild 22: Mitglieder der Datenbankrolle Allgemein<\/span><\/b><\/p>\n Die Seite Sicherungsfähige Elemente <\/b>listet die beiden gespeicherten Prozeduren auf, zu denen im unteren Teil das Recht EXECUTE <\/b>erteilt ist. <\/p>\n [68344]<\/p>\n Soweit die Kontrolle der erteilten Rechte. Wie sieht es mit den entzogenen Zugriffsrechten der gespeicherten Prozedur pSelectAnmeldung <\/b>aus? Zur Stichprobe öffnen Sie den Dialog der Datenbankrolle Personalwesen<\/b>. Dieser enthält in der Seite Sicherungsfähige Elemente <\/b>lediglich die Rechtevergabe zu den Tabellen. Das Recht zum Ausführen der gespeicherten Prozedur pSelectAnmeldung <\/b>ist nicht definiert. Somit bestätigt die Stichprobe die T-SQL-Anweisungen des Skripts. <\/p>\n [68485]<\/p>\n Der finale Test des Berechtigungskonzepts findet wieder mit der Beispielapplikation statt. Starten Sie die Applikation nach und nach mit den Rechten der Anwender Bienlein<\/b>, Stromberg<\/b>, Eberhofer <\/b>und Kling<\/b>. Unabhängig der verwendeten Anmeldung zeigt Ihnen die Beispielapplikation das Start<\/b>-Formular. Das allein bestätigt schon die korrekte Rechtevergabe zur gespeicherten Prozedur pSelectAnmeldung<\/b>. Ohne diese könnte der Anwender nicht identifiziert und die Tabellen mit den erlaubten Zugriffsrechten nicht eingebunden werden.<\/p>\n [68951]<\/p>\n Je verwendeter Anmeldung greifen Sie auf die unterschiedlichen Daten zu. Als Anwender Bienlein <\/b>steht Ihnen der Vollzugriff auf die Tabellen Aufträge<\/b>, Artikel <\/b>und Kunden <\/b>zur Verfügung, als Stromberg <\/b>für die Tabellen Mitarbeiter<\/b>, Bewerber <\/b>und Stellen<\/b>. Der Anwender Eberhofer <\/b>kann auf die Tabellen Bestellungen <\/b>und Produkte <\/b>lesend und schreibend zugreifen. Die Daten der Tabelle Lieferanten <\/b>hingegen darf er nur lesen. Das Ändern dieser Daten ist dem Anwender Kling <\/b>vorbehalten. Den Inhalt der Geburtstagsliste dürfen alle Anwender sehen.<\/p>\n [69475]<\/p>\n Der Test bestätigt das aktuelle Berechtigungskonzept. Es basiert auf fünf Datenbankrollen für die Mitarbeiter aus vier Abteilungen. Die zur Bewältigung der Aufgaben benötigten Datenbankobjekte und Zugriffsrechte sind pro Abteilung in eigenen Datenbankrollen definiert. Zu jeder Abteilung existiert in der Datenbank ein Benutzer.<\/p>\n [70011]<\/p>\n Entsprechend den Aufgaben sind die Benutzer einer der Datenbankrollen Personalwesen<\/b>, Vertriebswesen<\/b>, Bestellwesen <\/b>oder Buchhaltung <\/b>sowie zusätzlich der Datenbankrolle Allgemein <\/b>zugeordnet.<\/p>\n [70340]<\/p>\n Die Windows-Benutzerkonten der Anwender sind im Betriebssystem zu Windows-Gruppen zusammengefasst. Jede Gruppe enthält die Mitarbeiter einer Abteilung. Zu jeder Windows-Gruppe gibt es im SQL Server eine Anmeldung, die wiederum fest mit einem der Benutzer in der Datenbank verbunden ist. Somit stellt der Benutzer einer Datenbank letztendlich die Schnittstelle der Aufgaben zu den Aufgabenträgern dar. Über ihn erhält jedes Mitglied der Windows-Gruppen die erforderlichen Zugriffsrechte für seine Aufgaben.<\/p>\n [70529]<\/p>\n Zur Vermeidung von Interessenskonflikten wurden die Zuständigkeiten der Personen überprüft und als Folge einzelne Aufgaben auf mehrere Personenkreise verteilt. So ist das Verwalten der Lieferantendaten nach dem neuen Berechtigungskonzept ausschließlich der Buchhaltung erlaubt. Den anderen Mitarbeitern sind mögliche Manipulationen der Daten mit eigens angelegten Lieferanten nicht mehr möglich.<\/p>\n [71035]<\/p>\n Alles in allem ein recht rundes Berechtigungskonzept, das dem Prinzip der Funktionstrennung und dem Principle Of Least Privilege folgt – und das mit überschaubarem Aufwand.<\/p>\n [71431]<\/p>\n [71604]<\/p>\n Lustlos öffnet Frau Bienlein die neue Applikation Kundenbefragung<\/b>. Was hatte sie sich gegen diese Aufgabe gewehrt. Aber ihr Vorgesetzter Herr Hoppenstett blieb eisern. Er möchte, dass sie alle Kunden anruft, die in den letzten zwei Jahren nichts bestellt haben. Sie soll nach den Gründen fragen und vor allem das Interesse der Kunden wiedergewinnen. Das Ergebnis dieser Gespräche erwartet er am Ende jeden Quartals. <\/p>\n [71622]<\/p>\n Kundengespräche. Frau Bienlein ist nicht gerade für eine nette und freundliche Art der Kommunikation bekannt. Aber was soll“s. Missmutig klickt sie auf die Schaltfläche Befragung <\/b>– und lächelt erfreut. Denn anstelle der Kundenliste sieht sie eine Fehlermeldung. Ihr fehlt das Recht SELECT <\/b>für das Objekt Kundenbefragungen <\/b>(siehe Bild 23). Beruhigt bestätigt Frau Bienlein die Fehlermeldung mit OK <\/b>und schließt die Applikation. Für sie ist das Thema erst einmal erledigt. Schließlich kann sie ohne Zugriffsrechte keine Kunden anrufen. Bei Bedarf wird sich schon jemand melden. Dann ist es immer noch früh genug, auf die fehlenden Rechte hinzuweisen.<\/p>\n Bild 23: Fehlendes SELECT-Recht für Frau Bienlein<\/span><\/b><\/p>\n Am Ende des Quartals steht Herr Hoppenstett vor ihrem Schreibtisch und fragt nach den Ergebnissen der Kundenbefragung. Frau Bienlein erklärt ihm, dass sie die Aufgabe aufgrund fehlender Rechte nicht erledigen konnte und zeigt ihm die Fehlermeldung. Verärgert greift Herr Hoppenstett zum Telefon und ruft in der IT-Abteilung an. Er fordert die umgehende Rechtefreigabe für Frau Bienlein. Immerhin erwartet die Geschäftsführung die Ergebnisse dieser Aktion. Der IT-Mitarbeiter entschuldigt sich für die Umstände und verweist auf den Datenbankadministrator. Dieser sei aber noch zwei Wochen im Urlaub. Vorher könnte man keine Rechte freigeben. Herr Hoppenstett kann dies so nicht akzeptieren und ruft bei der Geschäftsführerin an. <\/p>\n [72688]<\/p>\n Kurz darauf klingelt in der IT-Abteilung das Telefon erneut. Nun möchte die Geschäftsführerin die Freigabe der Rechte, und zwar innerhalb der nächsten 30 Minuten. Mit dieser Vorgabe wendet sich der IT-Mitarbeiter an den IT-Leiter. Nur er besitzt neben dem Datenbankadministrator die erforderlichen Administrationsrechte im SQL Server. Leider hat er nur marginale Kenntnisse im Thema SQL Server-Security. An einen Hinweis seines Datenbankadministrators erinnert er sich jedoch sehr gut. Unter keinen Umständen dürfen Anmeldungen einfacher Anwender der Datenbankrolle db_owner <\/b>oder gar der Serverrolle sysadmin <\/b>zugeordnet werden.<\/p>\n [73417]<\/p>\n Der IT-Leiter startet das SQL Server Management Studio und navigiert im Objekt-Explorer zu den Anmeldungen. Er öffnet den Dialog zur Anmeldung Vertrieb <\/b>und prüft als erstes den Verweis zur Windows-Anmeldung. Dieser zeigt auf die gleichnamige Windows-Gruppe. Für den IT-Leiter eine plausible Einstellung. Er wechselt zur Seite Benutzerzuordnung<\/b>. <\/p>\n [74045]<\/p>\n Hier markiert er die Zeile zur Datenbank WaWi_SQL <\/b>und schaut in den unteren Teil des Dialogs. Dort sieht er die aktivierten Datenbankrollen Allgemein<\/b>, Vertriebswesen <\/b>und public<\/b>. Die Zugriffsrechte dieser Datenbankrollen scheinen nicht auszureichen. Es bedarf wohl einer genaueren Analyse der Datenbankrollen. Doch die Zeit drängt. Die 30 Minuten sind bald vorbei und einen weiteren Anruf der Geschäftsführung möchte er sich ersparen. Also erweitert er die Rechtevergabe mit den beiden Datenbankrollen db_datareader <\/b>und db_datawriter<\/b>. Das sollten ausreichend Rechte sein. Zu viele Rechte sind es seiner Meinung nach nicht. Schließlich hat er sich an die Vorgaben gehalten und weder die Datenbankrolle db_owner <\/b>noch die Serverrolle sysadmin <\/b>verändert. <\/p>\n [74391]<\/p>\n Er greift zum Telefon und ruft Frau Bienlein an. Sie soll es doch bitte noch einmal versuchen. Frau Bienlein klickt auf die Schaltfläche und sieht das Formular zur Kundenbefragung. Herr Hoppenstett ist zufrieden und informiert stolz die Geschäftsführung. Frau Bienlein mag seinen Enthusiasmus zwar nicht teilen, macht sich aber dennoch an die Arbeit. In der IT-Abteilung sind alle Beteiligten zufrieden und kümmern sich wieder um ihre Aufgaben. <\/p>\n [75142]<\/p>\n Nach den ersten Kundengesprächen braucht Frau Bienlein eine Pause. Diese Aufgabe ist einfach nichts für sie. Dafür müsste sie eigentlich eine Gehaltszulage verlangen. Gehaltszulage? Kein Problem. Frau Bienlein entscheidet sich für einen kleinen Nebenverdienst. Der Zeitpunkt ist günstig. Es ist es kurz vor Monatsende und der Zahlungslauf der Buchhaltung steht vor der Tür. Für ihren Nebenverdienst muss sie nur einen Lieferanten mit ihrer Bankverbindung sowie eine Bestellung inklusive Wareneingang anlegen. Das hat in den letzten Monaten hervorragend funktioniert.<\/p>\n [75588]<\/p>\n Sie startet die Access-Applikation WaWi v2 <\/b>mit gedrückter Umschalt<\/b>-Taste und geht direkt zum Navigationsbereich. Dort will sie die Tabelle Lieferanten <\/b>öffnen. Doch ein Blick in den Navigationsbereich hält sie erst einmal davon ab. Frau Bienlein ist ebenso irritiert wie erfreut. Neben den Tabellen des Vertriebs und des Einkaufs sieht sie alle anderen Tabellen der Datenbank, inklusive die der Personalabteilung. Neugierig klickt sie doppelt auf die Tabelle Mitarbeiter. „Yes!“ sagt Frau Bienlein laut und hält sich schnell die Hand vor den Mund. Ein kurzer Rundblick beruhigt sie. Niemand im Raum hat etwas von ihrem Gefühlsausbruch mitbekommen. <\/p>\n [76155]<\/p>\n Die Freude ist aber auch zu groß. Frau Bienlein sieht die Daten der Tabelle Mitarbeiter<\/b>. Zielsicher geht Sie zu ihrem Personaldatensatz und erhöht den Wert der Spalte AktuellesGehalt <\/b>um 5 Euro. Jetzt wird es nochmal spannend. Wird die Änderung akzeptiert oder gibt es eine Fehlermeldung? Frau Bienlein verlässt den Datensatz und lächelt zufrieden.<\/p>\n [76803]<\/p>\n Die Änderung wurde ohne weiteres angenommen. Gemäß dem Motto „Doppelt hält besser“ öffnet sie die Tabelle Lieferanten<\/b>. Ein paar Minuten später ist der fiktive Lieferant mitsamt Bestellung, Wareneingang und Rechnungsnummer angelegt. Der Zahlungslauf kann kommen. Frau Bienlein freut sich schon jetzt auf die Überweisung in den kommenden Tagen. Insgesamt war es dann doch noch ein guter Tag für sie. Schließlich hatte sie die Möglichkeit zu zwei Nebenverdiensten.<\/p>\n [77151]<\/p>\n [77613]<\/p>\n Das Erstellen eines Berechtigungskonzepts ist keine Kleinigkeit. Womöglich ist das einer der Gründe, warum diese Aufgabe immer wieder gerne verschoben wird. Obwohl die Vergabe von Zugriffsrechten elementar für ein Unternehmen ist. <\/p>\n [77620]<\/p>\n Die Vertraulichkeit und Integrität der Daten sollte für jedes Unternehmen eine Selbstverständlichkeit sein. Nicht nur um den Anforderungen diverser Gesetze nachzukommen, sondern vielmehr, um das Unternehmen vor Schaden zu bewahren.<\/p>\n [77852]<\/p>\n Eine mangelnde Datensicherheit führt unweigerlich zu wirtschaftlichen Schäden. Sei es ein Imageverlust wegen unfreiwilliger Veröffentlichung von Informationen oder die Manipulation der Daten durch nicht berechtigte Personen. <\/p>\n [78084]<\/p>\n Das Berechtigungskonzept der Beispielapplikation basiert auf bewährten Prinzipen. Es erfüllt das Priniciple of Least Privilege, nach dem jeder Anwender nur die Zugriffsrechte besitzt, die er für die Bewältigung seiner Aufgaben benötigt. Ebenso wird dem Prinzip der Funktionstrennung gefolgt, um Überschneidungen von Zuständigkeiten und den Missbrauch von Daten zu vermeiden. Somit sind Vertraulichkeit und Integrität der Daten gewährleistet.<\/p>\n [78310]<\/p>\n Solange man sich an das Berechtigungskonzept hält. Jegliche Vorgaben und Gründe für eine Änderung der Zugriffsrechte sind zu hinterfragen und deren Auswirkungen sorgfältig zu prüfen.<\/p>\n [78752]<\/p>\n Dies gilt nicht nur für den laufenden Betrieb. Das Berechtigungskonzept ist bereits bei der Datenbankentwicklung relevant. Jedes neue Datenbankobjekt muss in eine oder mehrere Datenbankrollen aufgenommen und dort mit den entsprechenden Rechten versehen werden.<\/p>\n [78935]<\/p>\n Ohne diese Rechtevergabe kann keiner der Anwender mit dem neuen Datenbankobjekt arbeiten.<\/p>\n [79196]<\/p>\n Die Folge ist eine Fehlermeldung mit dem Hinweis auf fehlende Rechte. So wie es Frau Bienlein mit der neuen Tabelle Kundenbefragungen <\/b>ergangen ist. Die nachträgliche Rechtevergabe erfolgte schnell und unüberlegt und führte letztendlich zu einem Aushebeln des Berechtigungskonzepts. Leider handelt es sich bei diesem Beispiel um ein alltägliches Szenario. <\/p>\n [79286]<\/p>\n Nun muss und darf ein Datenbankentwickler in seiner Entwicklungsumgebung gerne höhere Rechte als ein Anwender besitzen. Vor der Produktivsetzung aber sollte er einen Berechtigungstest durchführen.<\/p>\n [79642]<\/p>\n Dieser beinhaltet das Testen der neuen Funktionen mit mehreren Windows-Benutzerkonten, die den Zugriffsrechten der Anwender entsprechen. Auf diese Weise lassen sich sowohl fehlende wie auch zu viel erteilte Rechte erkennen.<\/p>\n [79839]<\/p>\n Die explizite Vergabe der Zugriffsrechte an neuen Datenbankobjekten darf durchaus als ein Nachteil der Datenbankrollen gewertet werden.<\/p>\n [80063]<\/p>\n Bei einer Rechtevergabe über die Schemata ist dies nicht erforderlich. Die Vor- und Nachteile dieser Art der Berechtigungsvergabe lernen Sie im nächsten Beitrag kennen.<\/p>\n [80199]<\/p>\n [80368]<\/p>\n 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!<\/p>\n [80376]<\/p>\n [80578]<\/p>\n Die im SQL Server verwendeten Begriffe Anmeldung<\/b> und Benutzer <\/b>haben in der IT mehrere Bedeutungen. Um Missverständnisse zu vermeiden, gelten für diese Beitragsreihe folgende Definitionen:<\/p>\n [80596]<\/p>\n [80784]<\/p>\n [80856]<\/p>\n [80921]<\/p>\n [80953]<\/ul>\n [81008]<\/p>\n Anlegen lokaler Windows-Benutzer und Windows-Gruppen, zuerst die Benutzer:<\/p>\n [81052]<\/p>\n [81127]<\/p>\n [81162]<\/p>\n [81217]<\/p>\n [81281]<\/p>\n [81320]<\/p>\n [81362]<\/p>\n [81450]<\/p>\n [81536]<\/p>\n [81605]<\/p>\n [81695]<\/ul>\n Nun folgt das Anlegen der Gruppen und die Zuordnung der Benutzer:<\/p>\n [81750]<\/p>\n [81816]<\/p>\n [81880]<\/p>\n [81916]<\/p>\n [81987]<\/p>\n [82079]<\/p>\n [82162]<\/p>\n [82265]<\/p>\n [82402]<\/p>\n [82440]<\/ul>\n SQL Server – Wechsel in den gemischten Modus:<\/p>\n [82476]<\/p>\n [82522]<\/p>\n [82568]<\/p>\n [82636]<\/p>\n [82717]<\/p>\n [82805]<\/ul>\n Sollte diese Option bereits aktiviert sein, können Sie die Änderung hier abbrechen und mit der Installation der Beispieldatenbank fortfahren.<\/p>\n [82874]<\/p>\n [83016]<\/p>\n [83051]<\/p>\n [83132]<\/ul>\n [83211]<\/p>\n [83255]<\/p>\n [83301]<\/p>\n [83373]<\/p>\n [83437]<\/p>\n [83537]<\/p>\n [83618]<\/p>\n [83682]<\/ul>\n [83787]<\/p>\n [83812]<\/ul>\n Sie finden den Treiber im Microsoft Downloadbereich unter dem Suchbegriff ODBC Driver 17 for SQL Server<\/b>.<\/p>\n [83900]<\/p>\n [84005]<\/ul>\n Sie finden den Treiber im Microsoft Downloadbereich <\/b>unter dem Suchbegriff MSOLEDBSQL<\/b>.<\/p>\n [84095]<\/p>\n [84181]<\/p>\n<\/p>\n
<\/p>\n
Datenbankrolle Personalwesen<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
USE WaWi_SQL;\r\nGO\r\nCREATE ROLE Personalwesen AUTHORIZATION dbo;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen;\r\nALTER ROLE Personalwesen ADD MEMBER [BJSEMINARE\\Personal];\r\nGO<\/pre>\n
<\/p>\n
IF (SELECT DATABASE_PRINCIPAL_ID(''Personalwesen'')) IS NULL\r\nBEGIN\r\n CREATE ROLE Personalwesen AUTHORIZATION dbo;\r\nEND<\/pre>\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen;<\/pre>\n
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Bewerber TO Personalwesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Stellen TO Personalwesen;<\/pre>\n
<\/p>\n
<\/p>\n
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Stellen TO Personalwesen;<\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Personalwesen;<\/pre>\n
<\/p>\n
Datenbankrolle Vertriebswesen<\/h2>\n
<\/p>\n
IF (SELECT DATABASE_PRINCIPAL_ID(''Vertriebswesen'')) IS NULL\r\nBEGIN\r\n CREATE ROLE Vertriebswesen AUTHORIZATION dbo;\r\nEND<\/pre>\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Artikel TO Vertriebswesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Auftraege TO Vertriebswesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Kunden TO Vertriebswesen; <\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Vertriebswesen;<\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnsprechpartnerZuMitarbeiter TO Vertriebswesen;<\/pre>\n
ALTER ROLE Vertriebswesen ADD MEMBER [BJSEMINARE\\Vertrieb];<\/pre>\n
Datenbankrolle Bestellwesen<\/h2>\n
IF (SELECT DATABASE_PRINCIPAL_ID(''Bestellwesen'')) IS NULL\r\nBEGIN\r\n CREATE ROLE Bestellwesen AUTHORIZATION dbo;\r\nEND\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Bestellungen TO Bestellwesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;\r\nGRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Produkte TO Bestellwesen;\r\nGRANT EXECUTE ON dbo.pSelectAnmeldung TO Bestellwesen;\r\nALTER ROLE Bestellwesen ADD MEMBER [BJSEMINARE\\Einkauf];<\/pre>\n<\/p>\n
Funktionstrennung<\/h2>\n
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;<\/pre>\n
GRANT SELECT ON dbo.Lieferanten TO Bestellwesen;<\/pre>\n
REVOKE INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;<\/pre>\n
<\/p>\n
Die Datenbankrolle public<\/h2>\n
<\/p>\n
GRANT CONNECT TO guest;<\/pre>\n
CREATE LOGIN TestPublic WITH PASSWORD=N''SicherIn2023!''; <\/pre>\n
<\/p>\n
<\/p>\n
EXEC dbo.pSelectGeburtstagsliste;<\/pre>\n
<\/p>\n
REVOKE CONNECT TO guest;<\/pre>\n
<\/p>\n
DROP LOGIN TestPublic;<\/pre>\n
Eine Datenbankrolle für alle<\/h2>\n
IF (SELECT DATABASE_PRINCIPAL_ID(''Allgemein'')) IS NULL<\/pre>\nBEGIN<\/pre>\n
CREATE ROLE Allgemein AUTHORIZATION dbo;<\/pre>\n
END<\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Allgemein;<\/pre>\n
GRANT EXECUTE ON dbo.pSelectGeburtstagsliste TO Allgemein;<\/pre>\n
ALTER ROLE Allgemein ADD MEMBER [BJSEMINARE\\Personal];<\/pre>\n
ALTER ROLE Allgemein ADD MEMBER [BJSEMINARE\\Vertrieb];<\/pre>\n
ALTER ROLE Allgemein ADD MEMBER [BJSEMINARE\\Einkauf];<\/pre>\n
ALTER ROLE Allgemein ADD MEMBER [BJSEMINARE\\Buchhaltung];<\/pre>\n
<\/p>\n
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Personalwesen;<\/pre>\n
REVOKE EXECUTE ON dbo.pSelectAnmeldung TO Personalwesen;<\/pre>\n
ALTER ROLE Allgemein DROP MEMBER [BJSEMINARE\\Buchhaltung];<\/pre>\n
<\/p>\n
Der Fall Bienlein<\/h2>\n
<\/p>\n
Fazit <\/h2>\n
Warnung<\/h2>\n
Begrifflichkeiten<\/h2>\n
\n
Installationsanleitung der Beispielumgebung<\/h2>\n
\n
\n
\n
\n
Installation der Beispieldatenbank WaWi_SQL<\/b><\/h2>\n
\n
Installation der Treiber<\/h2>\n
\n
\n
Beispielapplikation WaWi v2<\/h2>\n