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
Nur zwei Informationen im nun erscheinenden Dialog sind obligatorisch: der Benutzername und das Passwort.
Die weiteren Felder können Sie optional ausfüllen, damit eventuell später ein anderer Datenbankverwalter mehr sprechende Informationen zum Konto hat.
In Bild 6 ist ein neuer Benutzer SuedsturmUser angelegt worden. Behalten Sie im Sinn, dass es sich für die hier beschriebene Vorgehensweise im Grunde nicht um einen einzelnen User handelt, sondern um einen Gruppen-Account, dem später mehrere User der Tabelle tblUser zugeschlagen werden, die sich indirekt alle mit diesem Benutzernamen am Server anmelden werden. Nur für den Login am Frontend gibt es Unterscheidungen für einzelne Benutzeranmeldungen.
Abb.5: Kontextmenü für Benutzer im MySQL-Administrator
Rechte verwalten über GUI-Tools
Ein neu angelegter MySQL-Benutzer hat noch keine Rechte. Das Einzige, was ihm erlaubt ist, ist die Anmeldung am Server.
Zugriffe auf Datenbanken und Tabellen sind ihm noch verwehrt. Entsprechende Versuche enden in der ODBC-Fehlermeldung Access denied in verschiedensten Varianten. Also sind nun Rechte zu vergeben, die sich auf mehrere Zugriffsebenen erstrecken, wovon die globalen Berechtigungen und die Schema-Berechtigungen die wichtigsten sind.
Tatsächlich gibt es auch noch die Möglichkeit, Berechtigungen gesondert für Tabellen und sogar deren einzelne Felder zu setzen. Die Oberfläche des MySQL-Administrators allerdings sieht dafür kein Werkzeug vor.
Globale Berechtigungen haben den Geltungsbereich des ganzen Servers, erstrecken sich also auf alle dort vorhandenen Datenbanken. Ist hier für einen Benutzer etwa die Berechtigung SELECT eingetragen (siehe Bild 7), dann kann er sich den Inhalt aller Tabellen aller Datenbanken ansehen, jedoch noch nicht manipulieren.
Bild 7: Globale Benutzerberechtigungen, im MySQL-Administrator eingestellt
Dazu wären Berechtigungen wie INSERT, UPDATE und DELETE nötig. Der gemeine User Ihrer Datenbank braucht solche Berechtigungen normalerweise nicht, denn er soll ja nur mit der einen für ihn vorgesehenen Datenbank Südsturm arbeiten.
Die Berechtigungen für eine einzelne Datenbank lassen sich setzen, nachdem Sie den Reiter Schema-Berechtigungen im MySQL-Administrator angeklickt und ein Datenbankschema auf der linken Seite des Dialogs markiert haben (siehe Bild 8).
Bild 8: Benutzerberechtigungen für eine Datenbank, im MySQL-Administrator eingestellt
Fügen Sie hier über die Pfeilschaltflächen diejenigen Berechtigungen hinzu, die für das Bearbeiten der Daten in Formularen und über VBA-Code notwendig sind. Später wird noch ausführlicher davon die Rede sein, welche Berechtigungen hierfür infrage kommen.
Wie erwähnt, kann der MySQL Administrator keine Berechtigungen auf Tabellen- oder Feldebene steuern. Das könnte allerdings in einigen Fällen notwendig werden, wenn Sie etwa sichergehen wollen, dass ein Benutzer unter keinen Umständen den Inhalt einer Tabelle Bankkonten zu sehen bekommt.
In diesem Fall sind Sie auf Unterstützung durch GUI-Tools wie etwa den EMS-MySQL-Manager (siehe Bild 9) oder SQLYog angewiesen – oder Sie machen das einfach über SQL-Anweisungen, die Sie über Passthrough-Abfragen oder ADO-Connections absetzen.
Bild 9: Berechtigungen auf Tabellen- und Feldebene, mit einem Tool von EMS gesetzt
User anlegen per VBA und SQL
Die zuvor erwähnten Tools steuern die Benutzer- und Rechteverwaltung über SQL-Anweisungen an den Server. Was diese können, das ist Ihnen natürlich nicht vorenthalten.
Dazu setzen Sie etwa SQL-Kommandos im MySQL Query Browser [1] ab oder legen einfach eine Passthrough-Abfrage unter Access an, für die Sie allerdings zunächst eine Windows-ODBC-Datenquelle (DSN) angelegt haben müssen, die JET über ein authentifiziertes Konto, wie root, mit dem MySQL-Server verbindet. Dieses Konto muss bereits über Berechtigungen zur Verwaltung von Benutzern verfügen.
Einen neuen Benutzer legen Sie mit dieser einfachen Anweisung an:
CREATE USER "Leitung' IDENTIFIED BY "aiu2008'
Hier wird nicht nur der Benutzername Leitung übergeben, sondern auch gleich sein Zugangspasswort aiu2008. Sie können den IDENTIFIED-Teil aber auch weglassen und das Passwort separat setzen:
SET PASSWORD FOR "Leitung' = PASSWORD("aiu2008')
Wichtig: In diesem Fall muss der Passwort-String erst mit der MySQL-Funktion PASSWORD() codiert werden, denn selbstverständlich speichert MySQL Passwörter nicht im Klartext in seinen Systemtabellen. Heraus kommt dabei so etwas wie 574a23930c57b781. Dieser Binärstring lässt sich übrigens nicht zurückverwandeln.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo