Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
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 Kompendiums. 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.
[
Die Anweisungen GRANT und ALTER 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.
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 und Stellen. Den Weg zu den Datenquellen der zugehörigen Formulare kennen Sie bereits. Um es kurz zu machen: Dahinter verbergen sich die Tabellen Bewerber und Stellen. 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:
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen;
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:
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Mitarbeiter TO Personalwesen; GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Bewerber TO Personalwesen; GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Stellen TO Personalwesen;
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 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.
Abgesehen von den Rechten zur Geburtstagsliste enthält das Skript alle Anweisungen zur Rechtevergabe für die Personalabteilung. Mit einem Klick auf Ausführen legen Sie die Datenbankrolle mitsamt den definierten Zugriffsrechten und dem Mitglied Personal an.
Wie eben beschrieben, können Sie diese Rechtevergabe jederzeit wiederholen. Testen Sie es einmal und klicken Sie nochmal auf Ausführen. Die Zugriffsrechte werden erneut vergeben und das Skript fehlerfrei beendet.
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 und wählen in dessen Kontextmenü den Eintrag Aktualisieren. Erst jetzt sehen Sie in dem Ordner ihre neue Datenbankrolle namens Personalwesen. Mit einem Doppelklick auf die Datenbankrolle öffnen Sie den Eigenschaften-Dialog. Dieser zeigt Ihnen im unteren Bereich der Startseite die Mitglieder der Datenbankrolle, in diesem Fall den Benutzer Personal. In der Seite Sicherungsfähige Elemente 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.
Im alten Berechtigungskonzept war der Benutzer Personal den drei Datenbankrollen db_datareader, db_datawriter und edb_execute zugeordnet. Nach der neuen Rechtevergabe dürfte es nur noch die Zuordnung zur Datenbankrolle Personalwesen geben. Um dies zu prüfen, öffnen Sie den Dialog zum Benutzer Personal und wechseln dort zur Seite Mitgliedschaft. Voila, es ist einzig und allein die Datenbankrolle Personalwesen aktiviert (siehe Bild 10).
Bild 10: Datenbankrollen des Benutzers Personal
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.
Kontrolle ist gut, ein Test ist besser. Warum nicht direkt mit der Beispielapplikation WaWi v2? Starten Sie diese mit den Rechten des Anwenders Stromberg. Dazu klicken Sie mit der rechten Maustaste und gedrückter Umschalt-Taste auf das Access-Symbol in Ihrer Taskleiste und wählen Als anderer Benutzer ausführen. In dem folgenden Dialog geben Sie die Anmeldedaten des Benutzerkontos Stromberg 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 und aktivieren bei Bedarf die vertrauenswürdigen Inhalte.
Leider zeigt die Beispielapplikation anstelle des gewünschten Start-Formulars eine Fehlermeldung (siehe Bild 11). Es fehlt das Recht EXECUTE für die gespeicherte Prozedur pSelectAnmeldung. 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.
Bild 11: Fehlermeldung beim Start der Applikation
Wechseln Sie zurück zu Ihrem Skript im SQL Server Management Studio und gehen Sie zu dieser Zeile:
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Stellen TO Personalwesen;
Direkt darunter fügen Sie eine neue Zeile mit der folgenden T-SQL-Anweisung ein:
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Personalwesen;
Speichern Sie das Skript und führen Sie es erneut aus. Die Zugriffsrechte wurden nun um das EXECUTE-Recht erweitert. Zum Beweis starten Sie die Beispielapplikation wieder mit den Rechten des Anwenders Stromberg. 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.
Bild 12: Start-Formular der Personalabteilung
Lediglich die Schaltfläche Geburtstagsliste liefert eine Fehlermeldung. Das war zu erwarten. Dieser Datenzugriff ist in der Datenbankrolle Personalwesen nicht definiert und somit dem Anwender Stromberg nicht gestattet.
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. Dort sehen Sie nur die Tabellen Bewerber, Mitarbeiter und Stellen.
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. Sie erhalten eine Fehlermeldung – und das ist auch gut so, entspricht es doch den Anforderungen Ihres Berechtigungskonzepts und nebenbei denen des Datenschutzes.
Datenbankrolle Vertriebswesen
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, Artikel, Kunden und Ansprechpartner.
Die Datenquelle des Formulars Aufträge ist schnell ermittelt. Es handelt sich um die gleichnamige eingebundene Tabelle. Bei den anderen Formularen ist es etwas aufwendiger. Das Formular Artikel enthält in der Eigenschaft Datensatzquelle 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 und wechseln über die Eigenschaft Beim Öffnen zur entsprechenden VBA-Routine.
Hier sehen Sie, dass die Daten per ADO-Recordset aus der Tabelle Artikel der SQL Server-Datenbank gelesen werden. Der Cursortype adOpenStatic verrät Ihnen, dass Sie die Daten lesen und ändern sowie Datensätze löschen und neue hinzufügen dürfen (siehe Bild 13).
Bild 13: Datenermittlung per ADO
Im Formular Kunden erfolgt die Datenermittlung ebenfalls im Ereignis Beim Öffnen. Allerdings wird hier ein DAO-Recordset verwendet. Dieses basiert auf der eingebundenen Tabelle Kunden und stellt die Daten mittels der Option dbOpenDynaset für einen lesenden wie schreibenden Zugriff bereit.
Das Formular Ansprechpartner hingegen enthält wieder einen Eintrag in der Eigenschaft Datensatzquelle. Dieser verweist auf die Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter. Ein Blick in die Pass Through-Abfrage zeigt den Aufruf der gespeicherten Prozedur pSelectAnsprechpartnerZuMitarbeiter.
Somit benötigen Sie für den Werkzeugkasten die Tabellen Aufträge, Artikel und Kunden mit den Rechten SELECT, INSERT, UPDATE und DELETE sowie die gespeicherte Prozedur pSelectAnsprechpartnerZuMitarbeiter mit dem Recht EXECUTE. Diese Zugriffsrechte erteilen Sie wieder per Skript.
Öffnen Sie Ihr Skript Rechtevergabe WaWi_SQL und kopieren Sie den kompletten Block zur Datenbankrolle Personalwesen. 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.
Es beginnt mit den Zeilen zum Anlegen der Datenbankrolle. Hier ändern Sie den Begriff Personalwesen in Vertriebswesen.
IF (SELECT DATABASE_PRINCIPAL_ID(''Vertriebswesen'')) IS NULL
BEGIN
CREATE ROLE Vertriebswesen AUTHORIZATION dbo;
END
Die nächsten Zeilen legen die Zugriffsrechte an den Tabellen fest. Dort ersetzen Sie zum einen wieder den Begriff Personalwesen in Vertriebswesen und überschreiben die Tabellen Bewerber, Mitarbeiter und Stellen mit Artikel, Auftraege und Kunden.
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Artikel TO Vertriebswesen; GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Auftraege TO Vertriebswesen; GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Kunden TO Vertriebswesen;
Es folgt die Zeile zur Rechtevergabe der gespeicherten Prozedur pSelectAnmeldung, in der Sie wieder den Begriff Personalwesen mit Vertriebswesen überschreiben.
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Vertriebswesen;
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.
GRANT EXECUTE ON dbo.pSelectAnsprechpartnerZuMitarbeiter TO Vertriebswesen;
Mit der neuen Zeile ist der Werkzeugkasten mit dem notwendigen Werkzeug befüllt oder um es etwas technischer auszudrücken, die Datenbankrolle Vertriebswesen enthält die erforderlichen Datenbankobjekte mitsamt den Zugriffsrechten.
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 mit Vertriebswesen und ändern dann den Benutzernamen in Vertrieb.
ALTER ROLE Vertriebswesen ADD MEMBER [BJSEMINARE\Vertrieb];
Abschließend passen Sie die Dokumentation der neuen Zeilen an, speichern das Skript und führen es mit der Taste F5 aus. Das war es schon. Die Zugriffsrechte sind vergeben und gleichzeitig im Skript dokumentiert.
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.
Den Dialog können Sie weiterhin gerne zur Kontrolle nutzen. Vorab müssen Sie wieder den Inhalt des Ordners Datenbankrollen neu laden. Dazu wählen Sie in dessen Kontextmenü den Eintrag Aktualisieren. Danach öffnen Sie den Dialog mit einem Doppelklick auf die Datenbankrolle Vertriebswesen. In der ersten Seite sehen Sie unter Mitglieder den Benutzer Vertrieb und auf der Seite Sicherungsfähige Elemente die drei Tabellen sowie die zwei gespeicherten Prozeduren mit den erteilten Rechten.
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. Im Start-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.
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 zeigt Ihnen korrekterweise wieder die Fehlermeldung mit dem Hinweis auf das nicht erteilte EXECUTE-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.
Datenbankrolle Bestellwesen
Mit den Mitarbeitern des Einkaufs gibt es neue Anwender für die Beispielapplikation. Diese arbeiten mit den Schaltflächen Bestellungen, Produkte, Lieferanten und Wareneingang. Die Formulare hinter den ersten drei Schaltflächen beinhalten als Datenherkunft die eingebundenen Tabellen Bestellungen, Produkte und Lieferanten. Etwas komplexer ist es beim Formular Wareneingang, welches auf der gleichnamigen Access-Abfrage basiert. Diese bereitet die Daten der eingebundenen Tabellen Bestellungen und Lieferanten auf. Letztendlich erfolgt der Datenzugriff im Einkauf also ausschließlich über eingebundene Tabellen.
Die Zugriffsrechte vergeben Sie wie eben bei der Datenbankrolle Vertriebswesen. Wieder kopieren Sie den kompletten Block zur Datenbankrolle Personalwesen und fügen diesen am Ende des Skripts ein. In den neuen Zeilen ersetzen Sie den Begriff Personalwesen mit Bestellwesen, passen die Tabellennamen an die Tabellen des Einkaufs an und überschreiben den Benutzer Personal mit Einkauf. Als Ergebnis sollten die T-SQL-Anweisungen zur Datenbankrolle Bestellwesen wie folgt aussehen:
IF (SELECT DATABASE_PRINCIPAL_ID(''Bestellwesen'')) IS NULL
BEGIN
CREATE ROLE Bestellwesen AUTHORIZATION dbo;
END
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Bestellungen TO Bestellwesen;
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Produkte TO Bestellwesen;
GRANT EXECUTE ON dbo.pSelectAnmeldung TO Bestellwesen;
ALTER ROLE Bestellwesen ADD MEMBER [BJSEMINARE\Einkauf];
Nachdem Sie die Zeilen zur neuen Rechtevergabe ausführlich dokumentiert haben, speichern Sie das Skript und führen es per F5 aus. Anschließend aktualisieren Sie in gewohnter Weise den Ordner Datenbankrollen und öffnen den Eigenschaften-Dialog zur neuen Datenbankrolle Bestellwesen. Hier sehen Sie den zugeordneten Benutzer Einkauf und in der Seite Sicherungsfähige Elemente die Tabellen und die gespeicherte Prozedur mit den eben erteilten Zugriffsrechten (siehe Bild 14).
Bild 14: Rechte der Datenbankrolle Bestellwesen
Zum Test der erweiterten Rechtevergabe starten Sie die Beispielapplikation mit den Rechten des Anwenders Eberhofer. Jetzt bietet Ihnen das Start-Formular die Schaltflächen Bestellungen, Produkte, Lieferanten, Wareneingang und Geburtstagsliste. Jede dieser Schaltflächen erlaubt Ihnen in den zugehörigen Formularen den lesenden und schreibenden Datenzugriff. Bis auf die Schaltfläche Geburtstagsliste, die Ihnen die bereits erwartbare Fehlermeldung liefert. Die nicht gewährten Rechte testen Sie in diesem Fall wieder mit der Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter. Der Zugriff auf die Daten der Ansprechpartner der Kunden ist den Mitarbeitern im Einkauf nicht gestattet, weshalb Sie berechtigterweise eine Fehlermeldung erhalten.
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.
Funktionstrennung
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.
Diese neue Betrachtung erfordert eine Anpassung der bisherigen Rechtevergabe. Der Datenbankrolle Bestellwesen sind für die Tabelle Lieferanten die Rechte INSERT, UPDATE und DELETE zu entziehen. Dazu gehen Sie im Skript zur Rechtevergabe der Tabelle Lieferanten und kopieren die folgende Zeile:
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;
Die Kopie fügen Sie direkt unterhalb der Zeile ein. In der Ursprungszeile löschen Sie die Einträge INSERT, UPDATE und DELETE. Übrig bleibt in dieser GRANT-Anweisung nur das Recht SELECT.
GRANT SELECT ON dbo.Lieferanten TO Bestellwesen;
Mit der neu eingefügten Zeile entziehen Sie die bereits erteilten Rechte INSERT, UPDATE und DELETE. Ändern Sie dazu die T-SQL-Anweisung GRANT in REVOKE. Anschließend entfernen Sie in der Auflistung den Eintrag SELECT:
REVOKE INSERT, UPDATE, DELETE ON dbo.Lieferanten TO Bestellwesen;
Warum nun zwei SQL-Anweisungen für eine Rechtevergabe? Letztendlich braucht es doch nur die GRANT-Anweisung für das SELECT zur Tabelle Lieferanten. Die bereits erteilten Rechte INSERT, UPDATE und DELETE könnte man doch einmalig per Dialog entziehen. Im Grunde genommen wäre das auch vollkommen ausreichend.
Auf der anderen Seite zeigen die beiden Zeilen wieder einmal die Vorteile des Skripts. Mit der REVOKE-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 die Rechte INSERT, UPDATE und DELETE an der Tabelle Lieferanten. Spätestens mit der nächsten Ausführung des Skripts wird diese fehlerhafte Rechtevergabe gemäß den Vorgaben korrigiert. REVOKE lässt sich wie GRANT mehrmals ausführen und das unabhängig davon, ob das Recht erteilt ist oder nicht.
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.
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 und übernehmen Sie diesen an das Ende Ihres Skripts. Sie müssen lediglich in der letzten Zeile die Domäne BJSEMINARE 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 aus.
[50097]
Danach starten Sie die Beispielapplikation mit der Anmeldung Eberhofer und klicken im Start-Formular auf die Schaltfläche Lieferanten. Zum Test der neuen Zugriffsrechte ändern Sie einen beliebigen Wert und wechseln zum nächsten Datensatz. Als Anwender Eberhofer dürfen Sie die Daten der Lieferanten nur noch lesen, weshalb Ihre Datenänderung mit der Fehlermeldung aus Bild 15 quittiert wird.
Bild 15: Fehlende UPDATE-Rechte für den Einkauf
Wareneingänge dürfen Sie weiterhin buchen. Die Daten des Formulars Wareneingang liefert die gleichnamige Access-Abfrage. Diese enthält neben der Tabelle Lieferanten noch die Tabelle Bestellungen 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 einen der Firmennamen zu ändern. Sie erhalten wieder die gleiche Fehlermeldung.
[51156]
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. Im Start-Formular sind jetzt nur die Schaltflächen Lieferanten und Geburtstagsliste aktiv. Ein Klick auf die Schaltfläche Lieferanten ö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 die Daten der Lieferanten lesen und ändern.
[51644]
Die Datenbankrolle public
[52255]
Das Berechtigungskonzept ist fast vollständig. Es fehlt noch die Freigabe der Geburtstagsliste. Ein Blick in die Beispielapplikation zeigt als Datengrundlage des Formulars Geburtstagsliste eine Pass Through-Abfrage mit dem Aufruf der gespeicherten Prozedur pSelectGeburtstagsliste. 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 das entsprechende EXECUTE-Recht in jede Ihrer Datenbankrollen aufnehmen. Viel besser ist jedoch die bereits erwähnte zentrale Rechtevergabe, sprich ein EXECUTE-Recht zu dieser gespeicherten Prozedur in einer Datenbankrolle.
[52281]
SQL Server bietet zur Definition solch allgemeingültiger Rechte die Systemdatenbankrolle public 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 erteilten Zugriffsrechte für alle Benutzer der Datenbank. Das bietet sich doch für die EXECUTE-Rechte der beiden gespeicherten Prozeduren pSelectGeburtstagsliste und pSelectAnmeldung geradezu an.
[53000]
Zur Rechtevergabe wechseln Sie im Objekt-Explorer zur Datenbankrolle public der Datenbank WaWi_SQL und öffnen per Doppelklick den zugehörigen Dialog. Die Seite Allgemein zeigt im Bereich Mitglieder 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. Hier sehen Sie bereits erteilte SELECT-Rechte an einigen Systemobjekten. Diese ergänzen Sie nun mit den Rechten zur gespeicherten Prozedur pSelectGeburtstagsliste. Dazu klicken Sie auf Suchen, wählen als Auswahlkriterium Alle Objekte des Typs und aktivieren im Dialog Objekttypen auswählen den Eintrag Gespeicherte Prozeduren. Nach Bestätigen der Auswahl mit OK sehen Sie im Dialog zur Datenbankrolle im oberen Bereich alle gespeicherten Prozeduren.
[53470]
Dort markieren Sie die gespeicherte Prozedur pSelectGeburtstagsliste und aktivieren im unteren Bereich in der Zeile Ausführen die Option Erteilen. Mit einem Klick auf OK 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. 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 erst einmal ignorieren.
[54512]
Für den Test der neuen Zugriffsrechte starten Sie die Beispielapplikation als Anwender Eberhofer. Nach einem Klick auf die Schaltfläche Geburtstagsliste sehen Sie die Geburtstage aller Mitarbeiter. Weitere Tests mit den Anmeldungen Bienlein, Stromberg und Kling liefern Ihnen das gleiche Ergebnis.
[55070]
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 einen Benutzer. Alle Benutzer der Datenbank sind standardmäßig der Datenbankrolle public zugeordnet und diese besitzt das Recht EXECUTE für die gespeicherte Prozedur pSelectGeburtstagsliste.
[55368]
Wohlgemerkt, alle Benutzer der Datenbank! Das gilt genauso für Gäste. SQL Server bietet für Gastzugriffe den Benutzer guest (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 auf die Daten zugreifen.
Bild 16: Das Gast-Konto der Datenbank
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 noch dessen Kontextmenü bietet hierzu eine Möglichkeit. Der Benutzer guest lässt sich nur per T-SQL aktivieren. Dazu öffnen Sie über das Kontextmenü der Datenbank WaWi_SQL eine neue Abfrage und führen diese T-SQL-Anweisung aus:
[56151]
GRANT CONNECT TO guest;
[56776]
Anschließend wählen Sie im Kontextmenü des Ordners Benutzer den Eintrag Aktualisieren. Worauf Sie den Eintrag guest nun als aktiven Benutzer sehen.
[56800]
Für einen Test des Gastzugangs legen Sie mit der folgenden T-SQL-Anweisung die Anmeldung TestPublic an.
[56949]
CREATE LOGIN TestPublic WITH PASSWORD=N''SicherIn2023!'';
[57054]
Die CREATE LOGIN-Anweisung erstellt lediglich die Anmeldung. Es findet keine Zuordnung zur Datenbank WaWi_SQL statt, weshalb es dort auch keinen entsprechenden Benutzer zur Anmeldung gibt. Dennoch können Sie mit der Anmeldung TestPublic auf die Daten der Geburtstagsliste zugreifen.
[57111]
Diesen Datenzugriff testen Sie direkt im SQL Server Management Studio. Melden Sie sich über die Schaltfläche Verbinden mit der Anmeldung TestPublic an. Dabei verwenden Sie die Authentifizierungsmethode SQL Server-Authentifizierung (siehe Bild 17).
Bild 17: Neue Verbindung mit der Anmeldung TestPublic
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 und wählen Sie im Kontextmenü der Datenbank WaWi_SQL den Eintrag Neue Abfrage. Sie erhalten eine neue Registerkarte basierend auf der Anmeldung TestPublic. Hier führen Sie nun die gespeicherte Prozedur pSelectGeburtstagsliste aus:
Bild 18: Zugriff mit der Anmeldung TestPublic
EXEC dbo.pSelectGeburtstagsliste;
[58043]
Als Ergebnis sehen Sie die Geburtstage der Mitarbeiter (siehe Bild 19). Und das ohne einen Benutzer zur Anmeldung TestPublic. Der Datenzugriff erfolgt durch den aktiven Benutzer guest. Diesem ist durch die Rechtevergabe der Datenbankrolle public das Ausführen der gespeicherten Prozedur erlaubt.
Bild 19: Datenzugriff über Datenbankrolle public
Zur Erinnerung: Nicht nur die Anmeldung TestPublic 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.
[58374]
Erkennen Sie die Dimension dieser Sicherheitslücke? Sie als Datenbankadministrator haben keinen Überblick, wer mit den Rechten der Datenbankrolle public auf die Daten der Datenbank zugreift.
[58746]
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.
[58938]
Allein durch die Leserechte der Datenbankrolle public 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.
[59481]
Der Einfachheit halber wurde der Benutzer guest in der Datenbank zur Zeiterfassung der externen Mitarbeiter aktiviert. In dieser Datenbank besitzt die Datenbankrolle public 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.
[59755]
Es gibt eine einfache Vorgabe zur Datenbankrolle public. Ignorieren! Selbst Microsoft spricht diese Empfehlung aus. Das Benutzerkonto guest lassen Sie deaktiviert. Weigern Sie sich es zu aktivieren. Es muss schon sehr gute Gründe dafür geben.
[60251]
Diese Empfehlungen gelten ebenso für die Datenbank WaWi_SQL. 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 und öffnen Sie über das Kontextmenü eine neue Abfrage. In der Registerkarte führen Sie diese T-SQL-Anweisung aus:
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo