Berechtigungen für Access-Objekte per SQL Server I: Datenmodell

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Im Beitrag “SQL Server: Sicherheit und Benutzerverwaltung” haben wir gezeigt, wie Sie die Sicherheitsfunktionen für den Zugriff auf SQL Server und SQL Server-Datenbanken für Benutzergruppen und Benutzer einrichten. Damit ist der Zugriff auf die Elemente des SQL Servers geregelt. Was aber ist mit den Objekten im Access-Frontend – also beispielsweise mit Formularen, Schaltflächen, Ribbon-Einträgen und so weiter Wenn wir schon Benutzer und Benutzergruppen im SQL Server einrichten, möchten wir diese ja auch nutzen, um die Elemente der Benutzeroberfläche je nach der Anmeldung für Benutzergruppe oder Benutzer freizugeben oder auch nicht. Ein Beispiel dafür, wie Sie dies realisieren können, liefert der vorliegende Beitrag. In diesem ersten Teil erstellen wir das Datenmodell für die Berechtigungsverwaltung.

Mit dem Anlegen von Anmeldungen für Benutzer und Benutzergruppen auf Windows-Basis oder für Benutzer auf SQL-Server-Basis, deren Zuweisung an die verschiedenen Datenbanken und dem Einstellen der Berechtigungen für die Elemente dieser Datenbanken haben Sie schon einen großen Schritt getan: Sie haben dafür gesorgt, dass jeder Benutzer nur auf die Daten zugreifen darf, die für die jeweilige Anmeldung freigegeben sind.

Nun besitzt eine moderne Access-Anwendung ein Ribbon, mit dem sich die einzelnen Funktionen der Anwendung aufrufen lassen. Normalerweise sind alle Befehle des Ribbons aktiviert und sichtbar. Wenn Sie eine Anwendung erstellen, die von verschiedenen Benutzergruppen genutzt wird, wollen Sie aber möglicherweise nicht immer alle Funktionen für alle Benutzergruppen freischalten. So könnte ein Datenbank-Frontend gleichzeitig die Formulare, Berichte und Funktionen enthalten, die nur für die Bestellannahme erforderlich sind. Die dortigen Mitarbeiter sollen aber vielleicht nicht die Auswertungen sehen, die etwa für das Management interessant sind. Also wollen wir verschiedene Dinge erreichen: Erstens sollen Bereiche, die für bestimmte Benutzergruppen nicht vorgesehen sind, nicht zu öffnen sein. Zweitens sollen auch gar keine Steuer-elemente im Ribbon oder auch in Formularen vorhanden sein, um diese Bereiche zu öffnen – oder zumindest sollen diese deaktiviert werden.

Berechtigungen je Benutzergruppe

Die folgende Lösung orientiert sich an der Windows-Authentifizierung, wie wir sie im Beitrag SQL Server: Sicherheit und Benutzerverwaltung (www.access-im-unternehmen.de/1154) vorgestellt haben. Das heißt, dass wir die Berechtigungen mit der Benutzergruppen abgleichen, denen die jeweiligen Benutzer angehören.

Im Einzelnen soll der Ablauf so aussehen, dass der Benutzer sich über seine Windows-Anmeldung und die zugeordnete Benutzergruppe an den SQL Server anmeldet. Dort haben wir bereits ausschließlich Anmeldungen auf Basis der vorhandenen Benutzergruppen vorgesehen. Wenn nun das Ribbon für einen Benutzer geladen wird, soll die Anwendung in einer Tabelle auf dem SQL Server prüfen, ob die Benutzergruppe, welcher der Benutzer angehört, die Berechtigungen zur Anzeige der Steuer-elemente des Ribbons besitzt. Dazu verwenden wir drei Tabellen. Die erste enthält alle Ribbon-Steuerelemente, Formulare, Formular-Steuerelemente und Berichte, für die Berechtigungen geprüft werden sollen. Die zweite enthält die verschiedenen Berechtigungsstufen, in diesem Fall Keine, Lesen und Alle. Damit sollten alle wichtigen Fälle abgedeckt sein. Sie können diese Tabelle aber nach Bedarf selbst erweitern. Die dritte Tabelle ist eine Verknüpfungstabelle zwischen den beiden ersten Tabellen und legt für jedes in der ersten Tabelle aufgeführte Element die Berechtigung aus der zweiten Tabelle fest.

Nun benötigen wir noch auf Access-Seite entsprechende Prozeduren, die vor dem Anzeigen eines Ribbons, eines Formulars oder eines Berichts aufgerufen werden und für die jeweiligen Elemente prüfen, ob die Benutzergruppe des aktuellen Benutzers diese Elemente nutzen darf. Voraussetzung für die Sicherheit dieser Vorgehensweise ist, dass der Benutzer den Quellcode in der Access-Anwendung nicht einsehen kann.

Benutzergruppen und Benutzer unter Windows anlegen

Damit Sie die folgenden Beispiele reproduzieren können, legen Sie zwei Benutzergruppen namens Bestellannahme und Management an sowie zwei Benutzer namens Harry Klein und Peter Gross. Diese ordnen Sie jeweils einer Benutzergruppe zu. Dabei brauchen Sie nicht umständlich in der Windows-Systemsteuerung zu arbeiten, sondern können dies bequem über die Kommandozeile erledigen. Diese öffnen Sie wie im Beitrag SQL Server: Sicherheit und Benutzerverwaltung im Administrator-Modus. Danach brauchen Sie nur noch die folgenden sechs Anweisungen einzugeben und per Eingabetaste auszuführen:

net.exe USER /ADD "Harry Klein" password
net.exe USER /ADD "Peter Gross" password
net.exe LOCALGROUP /ADD Bestellannahme
net.exe LOCALGROUP /ADD Management
net.exe LOCALGROUP Management /ADD "Peter Gross"
net.exe LOCALGROUP Bestellannahme /ADD "Harry Klein"

Dann legen Sie wie im gleichen Beitrag beschrieben zwei Anmeldungen im SQL Server Management Studio für die beiden Benutzergruppen Bestellannahme und Management an. Das können Sie über den Dialog erledigen, aber Sie haben auch die Möglichkeit, schnell ein Skript zu schreiben (oder dieses hier zu kopieren – nicht vergessen, den Platzhalter zu ersetzen). Das folgende Skript legt eine neue Anmeldung für die Windows-Benutzergruppe Management an und stellt die Standarddatenbank auf Suedsturm_SQL ein. Dann erstellt das Skript einen neuen Benutzer für die Datenbank Suedsturm_SQL für die Anmeldung der Benutzergruppe Management. Das Skript führen Sie im SQL Server Management Studio in einem neuen Abfragefenster für die Datenbank Suedsturm_SQL aus:

USE [master]
GO
CREATE LOGIN [<Server>\Management] FROM WINDOWS WITH DEFAULT_DATABASE=[Suedsturm_SQL]
GO
USE [Suedsturm_SQL]
GO
CREATE USER [<Server>\Management] FOR LOGIN [<Server>\Management]
GO
ALTER ROLE [db_datareader] ADD MEMBER [<Server>\Management]
GO
ALTER ROLE [db_datawriter] ADD MEMBER [<Server>\Management]
GO

Das gleiche Skript können Sie noch einmal in leicht geänderter Form ausführen. Diesmal verwenden wir die Anmeldung \Bestellannahme.

Berechtigungen einstellen

Danach legen wir einige Berechtigungen für die beiden Benutzergruppen fest. Die Benutzergruppe Management soll alle Daten lesen können, aber nicht ändern. Nicht, dass die Manager was kaputtmachen … Die Benutzergruppe Bestellverwaltung soll einige Tabellen nur lesen können – zum Beispiel tblAnreden, tblArtikel oder tblKategorien zum Beispiel. Andere Tabellen müssen die Mitglieder dieser Benutzergruppe natürlich auch bearbeiten können – zum Beispiel tblBestellungen oder tblBestelldetails. Wenn Sie keine Lust haben, in den Dialogen zu arbeiten, können Sie auch hier einige Anweisungen absetzen, was vielleicht übersichtlicher ist – zumal Sie in den Dialogen immer nur die Berechtigungen für eine Tabelle gleichzeitig festlegen können. Um beispielsweise Leserechte für die Tabelle tblArtikel für die Benutzergruppe Bestellannahme festzulegen, reicht in einem neuen Abfragefenster der Datenbank Suedsturm_SQL die folgende Anweisung:

GRANT SELECT ON [dbo].[tblArtikel] TO [<Server>\Bestellannahme]
GO

Um das Lesen, Anlegen, ändern oder Löschen von Datensätzen in der Tabelle tblBestellungen festzulegen, verwenden Sie diese Anweisungen:

GRANT UPDATE ON [dbo].[tblBestellungen] TO [<Server>\Bestellannahme]
GO
GRANT SELECT ON [dbo].[tblBestellungen] TO [<Server>\Bestellannahme]
GO
GRANT INSERT ON [dbo].[tblBestellungen] TO [<Server>\Bestellannahme]
GO
GRANT DELETE ON [dbo].[tblBestellungen] TO [<Server>\Bestellannahme]
GO

Tabellen für die Berechtigungen der Benutzergruppen an den Objekten definieren

Als Nächstes benötigen wir die drei bereits weiter oben beschriebenen Tabellen, in denen wir die Elemente der Benutzeroberfläche, die Berechtigungsstufen und die Verknüpfungen zwischen diesen Elementen speichern.

Die Tabelle tblBerechtigungsstufen soll die Felder BerechtigungsstufeID und Bezeichnung enthalten. Die Tabelle legen wir im SQL Server Management Studio wie in Bild 1 an. Um diesen Dialog zu öffnen, wählen Sie im Kontextmenü Tabelle… des Eintrags Suedsturm_SQL|Tabellen aus. Nachdem Sie die beiden Felder wie in der Abbildung hinzugefügt haben, legen Sie in den Eigenschaften noch die Identitätsspezifikation für das Feld BerechtigungsstufeID fest. Auf diese Weise versehen Sie das Feld mit einem Autowert.

Anlegen der Tabelle tblBerechtigungsstufen

Bild 1: Anlegen der Tabelle tblBerechtigungsstufen

Außerdem müssen Sie das Feld BerechtigungsstufeID noch als Primärschlüsselfeld markieren. Das erledigen Sie über den Kontextmenü-Eintrag Primärschlüssel festlegen (siehe Bild 2).

Festlegen des Primärschlüsselfeldes per Kontextmenü

Bild 2: Festlegen des Primärschlüsselfeldes per Kontextmenü

Anschließend fügen wir noch die drei vorgesehenen Werte zur Tabelle hinzu. Dazu öffnen wir diese nach dem Speichern mit dem Kontextmenü-Eintrag Oberste 200 Zeilen bearbeiten. Dies öffnet eine Art Datenblattansicht der Tabelle, wo Sie die drei Datensätze wie in Bild 3 eingeben.

Hinzufügen von Datensätzen zur Tabelle tblBerechtigungsstufen

Bild 3: Hinzufügen von Datensätzen zur Tabelle tblBerechtigungsstufen

Objekte und Elemente speichern

Die zweite Tabelle heißt tblObjekte und soll alle Formulare, Berichte, Formularsteuerelemente und Ribbon-Steuerelemente aufnehmen, für welche Berechtigungen festgelegt werden sollen. Hier benötigen wir außerdem ein Feld, welches den Objekttyp speichert – also ob es sich um ein Formular, einen Bericht, ein Steuer-element in einem Formular oder eines in einem Ribbon handelt. Zu diesem Zweck legen wir noch eine weitere Tabelle an, welche die unterschiedlichen Objekttypen aufnimmt. Diese Tabelle heißt tblObjekttypen und soll die beiden Felder Objekttyp-ID und Bezeichnung aufnehmen.

Auch für das Primärschlüsselfeld dieser Tabelle legen wir eine Identitätsspezifikation fest, damit sich das Feld wie ein Autowert-Feld unter Access verhält. Und natürlich soll auch hier das Feld ObjekttypID als Primärschlüsselfeld markiert werden. Der Entwurf der Tabelle sieht wie in Bild 4 aus.

Anlegen der Tabelle tblObjekttypen

Bild 4: Anlegen der Tabelle tblObjekttypen

Anschließend füllen wir die Tabelle wie in Bild 5.

Füllen der Tabelle tblObjekttypen

Bild 5: Füllen der Tabelle tblObjekttypen

Hinweis: Speichern von änderungen

Wenn Sie eine Tabelle einmal gespeichert haben und dann noch änderungen wie etwa das ändern von Datentypen, Indizes et cetera vornehmen, kann es sein, dass dies nicht möglich ist – SQL Server Management Studio zeigt dann eine Meldung, dass die änderung nur durch Löschen und Neuanlegen der Tabelle möglich ist und das aktuell nicht funktioniert. Wie Sie dieses Problem lösen, erfahren Sie im Beitrag SQL Server: Tabellendefinition ändern (www.access-im-unternehmen.de/1163).

Tabelle zum Speichern der Objekte

Die nächste Tabelle soll tblObjekte heißen. Sie enthält neben dem Primärschlüsselfeld, dem Feld Bezeichnung und dem Feld Uebergeordnet ein Fremdschlüsselfeld, mit dem die Einträge der Tabelle tblObjekttypen referenziert werden können. Das Feld Uebergeordnet nimmt im Falle eines Formulars den Formularnamen auf.

Um das Fremdschlüsselfeld anzulegen, fügen wir zunächst ein Feld namens ObjekttypID mit dem Datentyp int hinzu. Um das Fremdschlüsselfeld einzurichten, klicken Sie mit der rechten Maustaste auf das Feld ObjekttypID und wählen aus dem Kontextmenü den Eintrag Bezeichnungen… aus (siehe Bild 6).

Entwurf der Tabelle tblObjekte

Bild 6: Entwurf der Tabelle tblObjekte

Es erscheint der Dialog Fremdschlüsselbeziehungen. Hier klicken Sie auf Hinzufügen. Der folgende Dialog (siehe Bild 7) bietet über die Schaltfläche mit den drei Punkten rechts neben der Eigenschaft Tabellen- und Spaltenspezifikation die Möglichkeit, einen weiteren Dialog zu öffnen.

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

Schreibe einen Kommentar