Moderne Softwarearchitekturen weisen auch in Verbindung mit SOA-Konzepten (service-oriented architecture) eine Drei-Schichten-Architektur mit Daten-, Applikations- und Anwenderschicht auf. Oft ist die Applikationsschicht weitgehend datenbankunabhängig implementiert. Die Verwaltung von Datenzugriffsberechtigungen wird hier vorgenommen, der Zugriff auf die Datenbank erfolgt mit einem so genannten technischen Login, der datenbankseitig wenigen Einschränkungen unterliegt.
Ist der Komplexitätsgrad der zu erstellenden Anwendung nicht sehr hoch, können Teile der Applikationsschicht mit SQL-Bordmitteln implementiert werden.
Das Drei-Schichten-Prinzip bleibt dabei erhalten, es erfolgt kein direkter Zugriff aus der Anwender-schicht auf die Objekte (Tabellen) der Datensicht. Auch die Zugriffsberechtigungen bleiben in der Applikationsschicht. Im Folgenden wird beschrieben, wie im SQL-Server eine satzweise Berechtigung für Tabellendaten implementiert werden kann.
Grundsätzliche Vorgehensweise
Der lesende Zugriff auf Tabellen durch die Anwenderschicht wird über eine Sicht (View) ausgeführt, der schreibende Zugriff erfolgt durch SQL-Prozeduren.
Dies ist unabhängig von der hier vorgestellten Zugriffskontrolle eine dringend zu empfehlende Abstraktionsstufe zwischen Tabellenlayout und Anwenderschicht. Änderungen in der Tabellenstruktur können in der Abstraktionsschicht, den Sichten und Prozeduren, abgefangen werden, sodass keine Anpassung in der Anwenderschicht notwendig ist. Weiterhin können für schreibende Zugriffe zusätzliche Schritte wie z.B. Datenprüfung und Protokollierung in den Zugriffsprozeduren implementiert werden.
Für die Berechtigungen sind weitere Tabellen vorzuhalten, die die Beziehungen zwischen den Datenbank-Anwendern und den Daten herstellen. Dies wird im untenstehenden Beispiel weiter ausgeführt.
Die Prüfung der Zugriffsberechtigung wird für lesende Zugriffe über einen einfachen join zwischen Datentabelle(n) und Berechtigungstabellen implementiert. Für schreibende Zugriffe wird in der Prozedur die Berechtigungstabelle geprüft und bei fehlenden Berechtigungen der Vorgang mit einer Fehlermeldung abgebrochen.
Grundsätzlich ist natürlich für jeden Anwender ein Login in der Datenbank anzulegen. Ob dies über einen direkten Login oder die Mitgliedschaft in einer Datenbankrolle oder über einen Windows-Gruppenlogin erfolgt, spielt keine Rolle. Auch mit SQL-Server Logins kann das Vorgehen umgesetzt werden.
Für diese Logins sind Leseberechtigungen für die Sichten (Views) und Ausführungsberechtigungen für die Prozeduren (Procs) zu vergeben. Berechtigungen für die Tabellen sind nicht notwendig.
Anwendungsbeispiel
In einer relationalen Anwendung soll der Zugriff auf die Daten über die Dimensionsebene Productgroup eingeschränkt werden. Die Beschränkung soll sowohl für die Dimensionsdaten (Tabellen T_S_Productgroup und T_S_Product), als auch für die Faktendaten (Tabelle T_D_Sales) gelten.
Im Beispiel sollen zwei Benutzer Zugriff auf die folgenden drei Produktgruppen haben:
Zunächst sind die Benutzer in die Tabelle T_SEC_USER einzutragen. Dabei können Windows-User (User 1) und SQL-Server Logins (User 2 und 3) gemischt werden.
Im nächsten Schritt sind die Berechtigungen in der Tabelle T_SEC_ProductGroup einzutragen.
User 1 soll Zugriff auf die Produktgruppen 10 und 20 haben. User 2 hat nur Zugriff auf die Gruppe 30. User 3 hat keinen Zugriff.
Die Kodierung der Zugriffberechtigungen kann frei gewählt werden. Im Beispiel wird für lesenden Zugriff UserRights = 1 definiert, für lesenden und schreibenden Zugriff UserRights = 2.
Definition der Zugriffsobjekte
Die zentrale Rolle bei der Implementierung der Zugriffsobjekte spielt die SQL-Funktion system_user, die den Namen des aktuellen Benutzers zurückgibt.
Für die Zugriffsprüfung werden nun Datentabellen, Berechtigungstabellen und der aktuelle Benutzer in einer Abfrage zusammengefasst:
Die Zugriffsobjekte für die weiteren Tabellen können nun basierend auf dieser View implementiert werden:
Der schreibende Zugriff auf die Daten erfolgt über Prozeduren. Exemplarisch wird hier für die Datentabelle die Berechtigungsprüfung bei einem UPDATE-Vorgang gezeigt. Alle anderen Prozeduren sind entsprechend zu implementieren. Zunächst sind jedoch weitere Sichten zu definieren, welche die Produktgruppen bzw. Produkte zurückliefern, für die der User Schreibrechte hat. Die Definitionen sind, abgesehen von der die Rechte einschränkenden WHERE-Bedingung (sec.UserRights = 2), mit den Sichten V_S_Productgroup bzw. V_S_Product identisch und daher hier nicht weiter ausgeführt.
In der Zugriffsprozedur wird die im Parameter übergebene Produktgruppe gegen die Sicht geprüft:
Ergänzende Hinweise
Das hier gezeigte Vorgehen zeigt das Grundprinzip der Berechtigungsimplementierung mit Sichten und Prozeduren. Die folgenden Hinweise erleichtern die Übertragung in die Praxis.
In der Praxis wird oft mit feineren Berechtigungsstufen gearbeitet. Zusätzlich zu Lese- und Schreibberechtigungen von Bewegungsdaten wird oft die Stammdatenpflege, das Hinzufügen und Löschen von Produkten und Produktgruppen und Zuordnungen geregelt.
Auch die Pflege der Berechtigungstabelle kann nach demselben Grundprinzip gestaltet werden. Da-mit werden Fachadministratoren in der Lage versetzt, die Berechtigungen selbst zu verwalten.
Die verschachtelte Definition der Sichten (die Sicht V_S_Product basiert auf der Sicht V_S_Productgroup) hat den Vorteil, dass die Verbindung zu den Berechtigungstabellen nur an einer Stelle definiert ist. Dies ist bei Änderungen vorteilhaft. Aus Performancegründen ist es jedoch manchmal sinnvoll auf die Verschachtelung zu verzichten.
Die hier gezeigte Datenzugriffsprozedur ist nur beispielhaft definiert. In der Praxis werden hier Typprüfungen, inhaltliche Prüfungen, Protokollierungen und UNDO-Mechanismen ergänzt.
Bei der Verwendung von DeltaMaster als Frontend folgen die Datenzugriffsprozeduren einer definierten und von DeltaMaster erwarteten Nomenklatur. In DeltaMaster Modeler sind Prozeduren zur Erzeugung der Datenzugriffsprozeduren enthalten.
Der SQL-Sprachumfang kennt neben dem Befehl system_user auch noch andere Befehle wie z.B. user.
Zum Test von Berechtigungen sind die Befehle EXECUTE AS USER und REVERT hilfreich.
