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 Bild 1.
Bild 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 Bild 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 Bild 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.
- 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 Bild 4.
Bild 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.
Bild 2: Berechtigungsgruppen und zugeordnete Benutzer in zusätzlichen Tabellen
Bild 3: Inhalt der Tabelle tblGruppen und verknüpfte User im Unterdatenblatt
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 (siehe Bild 5) erlaubt weitere Aktionen.
Bild 6: Angaben zu einem Benutzer im MySQL-Administrator
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
