Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 1/2009.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie das Rechtesystem von MySQL und seine Zusammenarbeit mit Access kennen.

Techniken

DAO, ADO, SQL (GRANT) , ODBC

Voraussetzungen

Access 2000 und höher

Beispieldateien

MySQLBerechtigungen.zip

Shortlink

649

Access, MySQL und Berechtigungsverwaltung

Sascha Trowitzsch, Berlin

Im vorherigen Beitrag zum Thema Access und MySQL wurde unsere Südsturm-Datenbank auf einen MySQL-Server migriert und das Frontend zur Zusammenarbeit mit ihm überredet. Dabei blieb eine Kleinigkeit auf der Strecke: Die Anmeldung am Server lief über einen Administrator-Account, was im Alltag so besser nicht vorkommen sollte. Sehen wir also in dieser Ausgabe, wie dem unbeschränkten Zugriff Riegel vorgeschoben werden können.

Datensicherheit

Ein häufig geäußertes Argument gegen ein JET-Datei-Backend ist die mangelhafte Datensicherheit, die es mit sich bringt. Auch Backends, die mit dem Sicherheitssystem von Access, also einer eigenen MDW und der User Level Security ausgestattet sind, lassen sich mit frei verfügbaren Tools in Sekundenschnelle knacken. Da jeder Benutzer außerdem prinzipbedingt immer Vollzugriff auf das Backend-Verzeichnis haben muss, steht dem Kopieren der Datendatei auf einen USB-Stick und anschließender heimischer Analyse nichts im Wege.

Das alles lässt ein SQL-Server nicht zu. Auf die physischen Tabellen haben die Benutzer keinen und auf die Datenbanken und Tabellen nur so viel Zugriff, wie es der Serveradministrator gewährt.

Ganz so rosig, wie es manchmal dargestellt wird, verhält es sich allerdings nicht. Sobald Sie ODBC-verknüpfte Tabellen im Frontend haben, könnten User, die sich auskennen, den AllowBypassKey-Schutz aushebeln und hätten damit direkten Zugriff auf die Tabellen über das Datenbankfenster. Die Daten könnten dann kopiert und manipuliert werden.

Wer vor solcher Unbill ganz sicher sein will, der muss ein Frontend entwickeln, das ganz ohne verlinkte ODBC-Tabellen auskommt und in dem der Zugriff auf die Daten rein über ADO-Recordsets gestaltet wird. Den Aufwand hierfür werden Sie mit Recht scheuen, weil eine solche Entwicklung diesen leicht ins Vielfache steigern kann.

Natürlich können Sie den Zugriff auf bestimmte MySQL-Tabellen genau so beschränken, wie das mit dem Sicherheitssystem (User Level Security, ULS) von JET per Arbeitsgruppendatei (MDW) möglich ist. MySQL erlaubt noch weitaus fein abgestuftere Zugriffsberechtigungen auf verschiedenen Ebenen - so weit, so gut.

Bevor Sie sich nun frohlockend an die Implementierung eines Zugriffssystems auf Server-Ebene machen, sollten Sie sich die Kehrseite der Medaille vergegenwärtigen. Die Berechtigungen sind zwar schnell vergeben, der Umgang mit ihnen im Frontend ist jedoch nicht ganz trivial. Denn wenn ein Zugriff vom Server verweigert wird, zeigt sich das zunächst lediglich in einer hässlichen ODBC-Fehlermeldung, mit der der Benutzer herzlich wenig anfangen kann - siehe Abb. 1.

Access_Denied.png

Abb. 1: Der MySQL-Server weist einen Datenzugriff mit einer ODBC-Fehlermeldung ab.

Es braucht auf der Seite des Frontends daher einen nicht unerheblichen Programmieraufwand, um solche Fehler abzufangen und für die Zugriffsbeschränkungen sinnvolle Folgeaktionen oder aussagekräftige Meldungen zu implementieren.

Was folgt aus diesen Ausführungen? Vor allem die Tatsache, dass man sich bereits vor der Entwicklung des Frontends ausführlich Gedanken über ein Benutzer- und Berechtigungskonzept machen sollte. Nachdem also das Datenmodell einer Datenbank steht, kommt als Nächstes die Frage an die Reihe, welcher Schutz aus welchen Gründen und für welche Daten vorgesehen werden muss. Das wiederum hängt ganz von den Anforderungen an die Datenbank ab, oder denen, die Ihnen der Auftraggeber oder dessen Datenschutzbeauftragter vorgeben.

Berechtigungskonzept

Nun ist es in der Realität eher unwahrscheinlich, dass Sie mit Access eine Datenbank entwickeln müssen, die höchsten Sicherheitsanforderungen genügt. Vermutlich werden Sie nicht in die Verlegenheit kommen, ein System für den BND oder auch nur eine Bank entwickeln zu müssen.

Für viele IT-Verantwortliche solcher Branchen reicht bereits das Erwähnen des Begriffs Access aus, um abzuwinken.

In den meisten Unternehmen wird jedoch auch nur mit Wasser gekocht. Die Möglichkeiten, die etwa das Sicherheitssystem von JET vorsieht, kombiniert mit einer einfacheren Rechtevergabe auf Serverebene, sollten hinreichend sein.

Machen Sie sich klar, dass es im Prinzip drei Ebenen gibt, auf die die Berechtigungssteuerung verteilt werden kann:

  • Die Serverebene: Zugriff auf Datenbanken, deren Objekte, Tabellen und sogar Felder sind unter MySQL steuerbar.
  • Die JET-Ebene (ULS): Zugriff auf alle Datenbankobjekte im Frontend ist über eine Arbeitsgruppendatei (MDW) steuerbar.
  • Implementationsebene: Über VBA können Sie unabhängig vom DBMS selbst ein Berechtigungssystem programmieren. So können Sie etwa den Aufruf von bestimmten Formularen unterbinden, wenn ein Benutzer dafür nicht autorisiert ist. Die Steuerung dieser Berechtigungen kann über zusätzliche Tabellen geschehen.

Welche dieser Möglichkeiten Sie bevorzugen und ob Sie sie in beliebigem Verhältnis kombinieren möchten, bleibt Ihnen überlassen. Eine allgemeine Empfehlung lässt sich hier schlecht aussprechen.

Ganz persönlich würde ich aber vom zusätzlichen Einsatz der ULS eher absehen. Außer dem Anmeldedialog, der bei ihrem Einsatz automatisch erscheint und somit einen CurrentUser verfügbar macht, bringt sie kaum Gewinn. Auch sind dann JET-User- und SQL-User-Konten nur noch schwer zu überblicken oder zu synchronisieren.

Um Aussagen zum Berechtigungskonzept machen zu können, muss man natürlich zunächst wissen, welche Möglichkeiten die einzelnen Ebenen erlauben. Und da es hier nur um den MySQL-Server gehen soll, wird im Folgenden dessen Rechtesystem veranschaulicht.

Berechtigungsstufen und Rollen

Das, was unter MySQL am ehesten Kopfzerbrechen bereitet, ist die flache Berechtigungshierarchie. Unter JET etwa werden einzelne Benutzer den Benutzergruppen zugeordnet. Ab Werk existieren die Gruppen Administratoren und Benutzer.

Man kann das je nach Anforderung auf weitere Gruppen, wie Hauptbenutzer, Gäste etc., ausweiten - ähnlich, wie bei den Benutzergruppen unter Windows. Berechtigungen werden dann seltener dem einzelnen User zugeordnet, als vielmehr eben diesen Gruppen, über die der einzelne User dann indirekt seine Rechte erhält.

Solch ein rollenbasiertes System, das in sehr differenzierter Form etwa beim Microsoft SQL Server vorliegt, fehlt MySQL leider. Hier gibt es einfach nur Benutzer, aber keine Gruppen oder Rollen.

Einem Benutzer können Sie zwar ebenfalls sehr differenzierte Rechte vergeben, doch besonders übersichtlich ist es nicht, jedem neuen User jeweils den kompletten Satz von Berechtigungen zuweisen zu müssen, anstatt das nur einmal zu Beginn für eine Gruppe vorzunehmen, der Benutzer angehören.

Daraus folgen für einen Workaround die möglichen Szenarien:

  • Entweder, man definiert separat in Access künstliche Gruppen, für die Berechtigungen gespeichert sind, und weist neuen Usern jeweils den entsprechenden Satz spezifischer Berechtigungen zu. Das sähe schematisch etwa so aus wie in Abb. 2. Man könnte nach diesem System in einem Access-Formular neue Benutzer anlegen (tblUser), die zugehörige Gruppe (GruppenID) auswählen und nach Klick auf eine Übernehmen-Schaltfläche auf dem Server zunächst den User exportieren und in einem weiteren Schritt die passenden Berechtigungen einstellen, welche aus der Tabelle tblGruppen kommen. Die könnte etwa einen Inhalt wie in Abb. 3 haben. Jeder Benutzer der Datenbank wird also auch tatsächlich auf dem Server angelegt und seine Rechte werden so eingestellt, wie das in der Tabelle tblGruppen vorgegeben wurde. Beim Start des Frontends wird der Benutzer reell mit seinem Namen am Server angemeldet.
  • system1tabelle.png

    Abb. 2: Berechtigungsgruppen und zugeordnete Benutzer in zusätzlichen Tabellen

    system1.png

    Abb. 3: Inhalt der Tabelle tblGruppen und verknüpfte User im Unterdatenblatt

  • Oder man definiert unter MySQL nur wenige Benutzer, die quasi Gruppencharakter haben, und verwaltet die User ebenfalls unter Access, schlägt dabei aber die einzelnen User jeweils einem "Gruppen-Account" von MySQL zu. Das ließe sich ungefähr so veranschaulichen wie in Abb. 4.

    system2.png

    Abb. 4: Benutzer und zugeordnete Gruppen für Gruppenanmeldung am Server

    Der Unterschied besteht hier darin, dass die Benutzer (Gruppenname) auf dem Server bereits angelegt wurden, die Berechtigungen auf einzelne Objekte schon vergeben sind, und beim Start der Datenbank keine Anmeldung über den Benutzernamen stattfindet, sondern über den Gruppennamen. Der Login am Frontend wird hingegen über VBA realisiert. Stimmen Anmeldename und Passwort (tblUser), so steht auch die zugehörige Gruppe über die GruppenID fest und die Verbindung wird über den gespeicherten Gruppennamen und das Gruppenpasswort (tblGruppen) hergestellt.

Verbreiteter ist Variante 2. Der Grund hierfür ist, dass Benutzer auf dem MySQL-Server global sind und nicht nur für eine spezielle Datenbank angelegt werden können - lediglich die Berechtigungen für einzelne Datenbanken können gesteuert werden.

Werden mehrere Datenbanken auf dem Server betrieben, so kommen im Lauf der Zeit Massen von Usern zusammen, über deren Zugehörigkeit zu einer einzelnen Datenbank man schnell den Überblick verliert.

Unter Sicherheitsaspekten hat die zweite Variante allerdings einen Nachteil. Da die Tabellen tblUser und tblGruppen ja im Prinzip im Frontend sichtbar sind, könnte deren Inhalt leicht ausspioniert werden. Bei Variante 1 ist das kein Problem, da die User-Tabelle im Frontend nicht wirklich vorhanden sein muss - Abb. 2 stellt nur ein Schema dar.

Aus diesem Grund sollte die Gruppentabelle besser nicht als verknüpfte Tabelle sichtbar sein, sondern nur per VBA und eine ADO-Server-Connection verarbeitet werden. Das führt indessen zu einem weiteren Problem.

Pferdefuß: Neuverknüpfen von Tabellen

Wenn Sie das Frontend weitergeben, dann wird es notwendig, dass die Server-Tabellen neu verknüpft werden - schließlich hat der MySQL-Server beim Kunden wahrscheinlich eine andere IP, als Ihr Entwicklungsserver.

Dazu ist aber bereits eine Verbindung zum Server Voraussetzung, die nur über eine Anmeldung zustande kommen kann. Wenn jedoch die Anmeldeinformationen (tblGruppen) selbst auf dem Server liegen, dann beißt sich die Katze in den Schwanz: Ohne Serververbindung keine Anmeldetabelle, ohne Anmeldetabelle keine Verbindung.

Das lässt sich praktisch nur lösen, indem ein Account im Frontend fest eingebaut ist. Das kann zum Beispiel über einen hartkodierten Connection-String in VBA gelöst werden. Die Rechte für diesen Zugang müssen so weit ausreichen, um die Servertabellen neu verknüpfen zu können - nicht mehr, nicht weniger. Welche Rechte das genau sind, erfahren Sie später.

Im Folgenden gehen wir nur auf die zweite Variante ein. Sie findet sich in der Beispieldatenbank suedsturm_mysql4.mdb umgesetzt.

User verwalten über GUI-Tools

Wenn Sie Ihren MySQL-Server neu aufgesetzt haben, dann existiert genau ein User, der meist den Namen root mit unbeschränkten Administratorrechten besitzt und dessen Passwort möglicherweise noch leer ist. Diesen Umstand sollten Sie dann übrigens schleunigst ändern. Die Verwaltung der Benutzer lässt sich sowohl über SQL realisieren, wie über diverse GUI-Tools, die bereits im ersten Teil dieser MySQL-Reihe Erwähnung fanden. Da der MySQL-Administrator [1] kostenlos ist, besprechen wir hier die Benutzerverwaltung über diese Anwendung.

Nach deren Start klicken Sie im linken Menü auf Benutzerverwaltung. Daraufhin werden unterhalb des Menüs die bereits vorhandenen Benutzerkonten angezeigt.

Sie können nun ein Konto markieren und dessen Eigenschaften bearbeiten oder über die Schaltfläche Neuen Benutzer anlegen ein neues Konto erzeugen. Das Kontextmenü für einen Benutzer (s. Abb. 5) erlaubt weitere Aktionen.

UserMyAdmin.png

Abb. 6: Angaben zu einem Benutzer im MySQL-Administrator

Nur zwei Informationen im nun erscheinenden Dialog sind obligatorisch: der Benutzername und das Passwort.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Benutzerverwaltung

Der DBMS-Connection-Wizard

Performanter Webzugriff auf MySQL-Datenbanken

Anmeldung an SQL Server und Co.

Von Access nach MySQL, Teil 2

DBMS-unabhängiger Zugriff auf SQL Server und Co.

Von Access nach MySQL

Access, MySQL und Datenzugriff

Änderungsdaten protokollieren

Verschlüsselung und Komprimieren im Backend

Datensicherung mit dem MS SQL Server

Modale Dialoge mal anders

Benutzerdefinierte Funktionen im MS SQL Server

Benutzer mit Access verwalten

Access 2007: Sicherheitssystem einsetzen

© 2003-2015 André Minhorst Alle Rechte vorbehalten.