<\/p>\n
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.<\/b><\/p>\n
Datensicherheit<\/b><\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/b>-Schutz aushebeln und hätten damit direkten Zugriff auf die Tabellen über das Datenbankfenster. Die Daten könnten dann kopiert und manipuliert werden.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
![\"Access_Denied.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/Access_Denied_opt.jpeg\")
<\/p>\n
Bild 1: Der MySQL-Server weist einen Datenzugriff mit einer ODBC-Fehlermeldung ab.<\/span><\/b><\/p>\n 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.<\/p>\n 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.<\/p>\n Berechtigungskonzept<\/b><\/p>\n 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.<\/p>\n Für viele IT-Verantwortliche solcher Branchen reicht bereits das Erwähnen des Begriffs Access aus, um abzuwinken.<\/p>\n 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.<\/p>\n Machen Sie sich klar, dass es im Prinzip drei Ebenen gibt, auf die die Berechtigungssteuerung verteilt werden kann:<\/p>\n 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.<\/p>\n 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 <\/b>verfügbar macht, bringt sie kaum Gewinn. Auch sind dann JET-User- und SQL-User-Konten nur noch schwer zu überblicken oder zu synchronisieren.<\/p>\n 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.<\/p>\n Berechtigungsstufen und Rollen<\/b><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Daraus folgen für einen Workaround die möglichen Szenarien:<\/p>\n Bild 2: Berechtigungsgruppen und zugeordnete Benutzer in zusätzlichen Tabellen<\/span><\/b><\/p>\n Bild 3: Inhalt der Tabelle tblGruppen und verknüpfte User im Unterdatenblatt<\/span><\/b><\/p>\n Bild 4: Benutzer und zugeordnete Gruppen für Gruppenanmeldung am Server<\/span><\/b><\/p>\n 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<\/b>), so steht auch die zugehörige Gruppe über die GruppenID fest und die Verbindung wird über den gespeicherten Gruppennamen und das Gruppenpasswort (tblGruppen<\/b>) hergestellt.<\/li>\n<\/ul>\n 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.<\/p>\n 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.<\/p>\n Unter Sicherheitsaspekten hat die zweite Variante allerdings einen Nachteil. Da die Tabellen tblUser <\/b>und tblGruppen <\/b>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.<\/p>\n 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.<\/p>\n Pferdefuß: Neuverknüpfen von Tabellen<\/b><\/p>\n 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.<\/p>\n Dazu ist aber bereits eine Verbindung zum Server Voraussetzung, die nur über eine Anmeldung zustande kommen kann. Wenn jedoch die Anmeldeinformationen (tblGruppen<\/b>) selbst auf dem Server liegen, dann beißt sich die Katze in den Schwanz: Ohne Serververbindung keine Anmeldetabelle, ohne Anmeldetabelle keine Verbindung.<\/p>\n 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. <\/p>\n Im Folgenden gehen wir nur auf die zweite Variante ein. Sie findet sich in der Beispieldatenbank suedsturm_mysql4.mdb <\/b>umgesetzt.<\/p>\n User verwalten über GUI-Tools<\/b><\/p>\n Wenn Sie Ihren MySQL-Server neu aufgesetzt haben, dann existiert genau ein User, der meist den Namen root <\/b>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.<\/p>\n Nach deren Start klicken Sie im linken Menü auf Benutzerverwaltung. Daraufhin werden unterhalb des Menüs die bereits vorhandenen Benutzerkonten angezeigt.<\/p>\n Sie können nun ein Konto markieren und dessen Eigenschaften bearbeiten oder über die Schaltfläche Neuen Benutzer anlegen <\/b>ein neues Konto erzeugen. Das Kontextmenü für einen Benutzer (siehe Bild 5) erlaubt weitere Aktionen.<\/p>\n Bild 6: Angaben zu einem Benutzer im MySQL-Administrator<\/span><\/b><\/p>\n <\/p>\n Nur zwei Informationen im nun erscheinenden Dialog sind obligatorisch: der Benutzername und das Passwort.<\/p>\n Die weiteren Felder können Sie optional ausfüllen, damit eventuell später ein anderer Datenbankverwalter mehr sprechende Informationen zum Konto hat.<\/p>\n In Bild 6 ist ein neuer Benutzer SuedsturmUser<\/b> 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 <\/b>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.<\/p>\n Abb.5: Kontextmenü für Benutzer im MySQL-Administrator<\/span><\/b><\/p>\n Rechte verwalten über GUI-Tools<\/b><\/p>\n Ein neu angelegter MySQL-Benutzer hat noch keine Rechte. Das Einzige, was ihm erlaubt ist, ist die Anmeldung am Server.<\/p>\n Zugriffe auf Datenbanken und Tabellen sind ihm noch verwehrt. Entsprechende Versuche enden in der ODBC-Fehlermeldung Access denied <\/b>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.<\/p>\n 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.<\/p>\n 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 <\/b>eingetragen (siehe Bild 7), dann kann er sich den Inhalt aller Tabellen aller Datenbanken ansehen, jedoch noch nicht manipulieren.<\/p>\n Bild 7: Globale Benutzerberechtigungen, im MySQL-Administrator eingestellt<\/span><\/b><\/p>\n Dazu wären Berechtigungen wie INSERT<\/b>, UPDATE <\/b>und DELETE <\/b>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.<\/p>\n Die Berechtigungen für eine einzelne Datenbank lassen sich setzen, nachdem Sie den Reiter Schema-Berechtigungen <\/b>im MySQL-Administrator angeklickt und ein Datenbankschema auf der linken Seite des Dialogs markiert haben (siehe Bild 8).<\/p>\n Bild 8: Benutzerberechtigungen für eine Datenbank, im MySQL-Administrator eingestellt<\/span><\/b><\/p>\n 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.<\/p>\n 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 <\/b>zu sehen bekommt.<\/p>\n 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.<\/p>\n Bild 9: Berechtigungen auf Tabellen- und Feldebene, mit einem Tool von EMS gesetzt<\/span><\/b><\/p>\n User anlegen per VBA und SQL<\/p>\n 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.<\/p>\n Dazu setzen Sie etwa SQL-Kommandos im MySQL Query Browser <\/b>[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<\/b>, mit dem MySQL-Server verbindet. Dieses Konto muss bereits über Berechtigungen zur Verwaltung von Benutzern verfügen.<\/p>\n Einen neuen Benutzer legen Sie mit dieser einfachen Anweisung an:<\/p>\n Hier wird nicht nur der Benutzername Leitung <\/b>übergeben, sondern auch gleich sein Zugangspasswort aiu2008<\/b>. Sie können den IDENTIFIED<\/b>-Teil aber auch weglassen und das Passwort separat setzen:<\/p>\n Wichtig: In diesem Fall muss der Passwort-String erst mit der MySQL-Funktion PASSWORD() <\/b>codiert werden, denn selbstverständlich speichert MySQL Passwörter nicht im Klartext in seinen Systemtabellen. Heraus kommt dabei so etwas wie 574a23930c57b781<\/b>. Dieser Binärstring lässt sich übrigens nicht zurückverwandeln.<\/p>\n Kurz und bündig lässt sich der Benutzer schließlich mit folgendem Statement löschen:<\/p>\n Übrigens sind hier nur die Kurzformen der Anweisungen wiedergegeben. Tatsächlich lautet das korrekte Kommando zum Anlegen eines Benutzers so:<\/p>\n Dem Benutzernamen ordnet MySQL nämlich immer auch einen Hostnamen zu, der nach dem @ angegeben werden kann. Der Hostname ist der Rechner, von dem aus sich der Benutzer mit dem Server verbindet, etwa dessen IP. Im Grunde identifiziert sich ein Benutzer also durch die Kombination aus User-Name und Rechnername.<\/p>\n Da man aber üblicherweise kaum weiß, welche Rechner in einem Firmenumfeld so ans Netz gehen, wäre das Verfahren mühsam und fehleranfällig, für jeden Rechner gesondert Berechtigungen zu vergeben. Deshalb wird statt des Rechnernamens das Wildcard-Zeichen „%‘ angehängt, was bedeutet, dass sich der Benutzer von jeglichem Rechner aus anmelden kann. Lässt man das @’%‘ weg, so hängt es MySQL intern automatisch hinten dran, was die beschriebene Kurzsyntax gültig macht.<\/p>\n Rechte einstellen über SQL<\/b><\/p>\n Die SQL-Zauberworte im Zusammenhang mit der Vergabe von Berechtigungen lauten GRANT <\/b>und REVOKE<\/b>. Sind die Anweisungen für das Verwalten von Usern noch ziemlich simpel, so gibt es hier eine sehr umfangreiche Syntax mit vielen möglichen Spezialfällen. Hier können nur die grundlegenden Anweisungen beschrieben werden.<\/p>\n Die ausführliche Dokumentation finden Sie in der MySQL-Referenz [2], nachdem Sie dort im Index den Begriff GRANT eingegeben haben.<\/p>\n GRANT<\/b><\/p>\n Das Prinzip für ein GRANT-Statement sieht so aus:<\/p>\n oder<\/p>\n Ein einfaches Beispiel, das dem Benutzer Leitung das Anzeigen und Bearbeiten aller Tabellen der Datenbank suedsturm <\/b>erlaubt:<\/p>\n Hierbei wird eine Schema-Berechtigung erteilt. Sollen die gleichen Rechte für alle Datenbanken auf dem Server wirken, soll also eine globale Berechtigung vergeben werden, dann ändert sich die Syntax so:<\/p>\n Die Einschränkung für eine einzelne Tabelle können Sie sich nun wahrscheinlich denken:<\/p>\n Den Umgang mit Rechten für einzelne Felder von Tabellen lassen wir hier außen vor. Es gibt kaum Anwendungsfälle dafür und die Fehlermeldungen im Frontend (siehe Bild 1), die solche Feldeinschränkungen mit sich bringen, sind nur aufwendig zu handeln.<\/p>\n REVOKE<\/b><\/p>\n Gewährte Rechte muss man auch wieder entziehen können. Das geschieht nicht etwa durch das erneute Absetzen von GRANT<\/b>, sondern über eine REVOKE<\/b>-Anweisung.<\/p>\n Nach Ausführen dieses Statements steht der Benutzer Leitung wieder so rechtelos da, wie nach dem Anlegen über CREATE USER<\/b>. Sollen Benutzerrechte etwa komplett neu vergeben werden, dann ist das unter Umständen gar keine schlechte Idee. Meist jedoch sollen nur Einschränkungen an bestimmten Datenbanken oder Tabellen und außerdem nur für bestimmte Rechteformen ausgeführt werden. Das könnte nun etwa so aussehen:<\/p>\n Die Zeile bewirkt, dass der Benutzer Leitung anschließend keine Datensätze in jeglichen Tabellen der Datenbank Südsturm<\/b> mehr einfügen oder löschen kann. <\/p>\n Wirkungsweise<\/b><\/p>\n An sich ist die Art, wie MySQL intern Benutzer und Rechte verwaltet, ziemlich überschaubar.<\/p>\n Da gibt es zunächst die Systemtabelle mysql.user<\/b>, die im Verein mit der Zusatztabelle mysql.user_info <\/b>alle Benutzer enthält.<\/p>\n In der user<\/b>-Tabelle sind auch gleich noch die globalen Berechtigungen abgespeichert – pro Berechtigungsart ein Feld, das entweder den Wert Y <\/b>oder N <\/b>annehmen kann.<\/p>\n Im Prinzip können Sie, wenn die Rechte ausreichen, diese Tabelle auch direkt bearbeiten und damit in einem Schwung Benutzer anlegen und globale Rechte vergeben. Sie sollten davon besser Abstand nehmen. Es gibt nichts, was sich nicht durch GRANT<\/b>– und REVOKE<\/b>-Anweisungen sicherer und ohne Nebenwirkungen lösen ließe.<\/p>\n Die Tabelle mysql.db <\/b>hingegen enthält die Berechtigungen für einzelne Datenbanken. Die einzelnen Berechtigungsarten verteilen sich hier jeweils auf Datensätze einer Kombination aus Hostname, Datenbankname und Benutzername.<\/p>\n Für die Berechtigungsebenen darunter sind die Tabellen mysql.tables_priv <\/b>und mysql.column_priv <\/b>zuständig.<\/p>\n Man sollte sich vor allem eines klar machen: Die Berechtigungen der einzelnen Ebene wirken additiv. Hat ein Benutzer die globale Berechtigung SELECT<\/b>, dann hat er sie selbstverständlich auch für die Datenbank Südsturm<\/b>.<\/p>\n Ein REVOKE <\/b>dieser Berechtigung, wie oben beschrieben, ändert daran gar nichts. <\/p>\n Im Betrieb lädt MySQL die Berechtigungen für einen Benutzer, der sich mit dem Server verbindet, übrigens in Speichertabellen. Sie finden diese in der Systemdatenbank information_schema<\/b>.<\/p>\n Dort ist bei fast allen Tabellen als Engine der Typ MEMORY <\/b>verzeichnet. Setzt der Benutzer etwa ein SELECT<\/b>-Statement ab, so schlägt MySQL zunächst in diesen Speichertabellen nach, ob er ausreichende Rechte an den beteiligten Tabellen besitzt. Nur im positiven Fall wird die Abfrage auch ausgeführt. Ansonsten gibt MySQL eine Fehlermeldung über den ODBC-Treiber zurück.<\/p>\n Auch wenn dieses Nachschlagen in den Speichertabellen sehr schnell vonstatten geht, benötigt es zusätzliche Zeit, die selbstverständlich mit der Größe dieser Tabellen anwächst. Die Performance eines MySQL-Servers, auf dem Abertausende von kleinsten Berechtigungen auf Feldebene vergeben sind, sinkt damit deutlich. Ein Grund mehr, es mit den Sicherheitsvorkehrungen nicht zu weit zu treiben.<\/p>\n Die Tatsache, dass der Server die Rechtetabellen bei Verbindung eines Benutzers lädt, macht übrigens verständlich, warum neu vergebene Rechte für einen Benutzer erst dann greifen, nachdem er sich erneut am Server angemeldet hat.<\/p>\n GRANT<\/b> führt schlicht nicht dazu, dass der Server seine information_schema <\/b>-Speichertabellen aktualisiert. Neue Anmeldung heißt unter Access entweder Neustart des Frontends oder Neuverknüpfen der Tabellen.<\/p>\n Berechtigungen im Einzelnen<\/b><\/p>\n Im Überblick folgen hier die wichtigsten Rechtearten, die über GRANT<\/b>-Anweisungen vergeben werden können:<\/p>\n Diese Einstellung ergibt zudem nur für einen Datenbankadministrator Sinn.<\/li>\n Die Berechtigung GRANT OPTION <\/b>ist übrigens ein Spezialfall. Erstens führt sie automatisch dazu, dass auch CREATE USER <\/b>gesetzt wird, und zweitens benötigt sie eine andere Syntax:<\/p>\n GRANT SELECT ON suedsturm.* TO sLeitung‘ WITH GRANT OPTION<\/p>\n Sie kann also nicht alleinstehend gesetzt werden, sondern nur kombiniert mit einer anderen Berechtigungsart – hier dem SELECT<\/b>.<\/p>\n Anders verhält es sich mit REVOKE<\/b>. Hier kann das Recht separat entzogen werden:<\/p>\n REVOKE GRANT OPTION ON suedsturm.* FROM „Leitung‘<\/p>\n Und noch etwas: GRANT OPTION <\/b>bedeutet nicht, dass ein so ausgestatteter User beliebige Berechtigungen an andere User vergeben könnte. Vielmehr sind es maximal nur jene, die er auch selbst besitzt. Hat er nur SELECT<\/b>-Rechte an den Tabellen einer Datenbank, so führt GRANT OPTION <\/b>dazu, dass er anderen Benutzern eben auch nur ein SELECT-GRANT <\/b>erteilen kann. Alles andere führt zu Fehlermeldungen.<\/p>\n Noch ein Hinweis zum hier öfters verwendeten Begriff Datenbankadministrator<\/b>: Damit ist nicht der Verwalter des MySQL-Servers gemeint, wie etwa root<\/b>, sondern der Verwalter der fraglichen Datenbank. Ein Administrator für die Datenbank suedsturm<\/b> kann volle Berechtigungen auf diese haben, jedoch andere Datenbanken auf dem Server noch nicht mal zu sehen bekommen.<\/p>\n In der Demodatenbank suedsturm_ mysql4.mdb <\/b>ist das der Super-User SuedsturmAdmin<\/b>. Er sollte alle möglichen Rechte auf die Datenbank Südsturm <\/b>besitzen.<\/p>\n Für das Neuverknüpfen der Frontend-Tabellen zum Server ist in unserem Beispiel übrigens nur eine einzige Berechtigung nötig: SELECT <\/b>auf die Datenbank suedsturm<\/b>. Das reicht, um eine Connection herzustellen und die Tabellen tblUser <\/b>und tblGruppen <\/b>auszulesen.<\/p>\n Südsturm-Demo<\/b><\/p>\n Nachdem Sie das beigepackte SQL-Skript, ein Backup der Südsturm-Datenbank, über die Wiederherstellen<\/b>-Funktion des MySQL-Administrators <\/b>eingelesen haben, sollte dem Einsatz der Frontend-MDB nichts im Wege stehen.<\/p>\n Die Beschreibung der Funktionen des Frontends kann hier nur sehr verkürzt erfolgen. Schauen Sie sich bei weitergehendem Interesse einfach die enthaltenen Module genauer an. Es sollte auch erwähnt werden, dass die Demo nur einen von vielen möglichen Wegen aufzeigt, wie ein Berechtigungssystem im Frontend realisiert werden kann.<\/p>\n Beim Start des Frontends wird über das AutoExec<\/b>-Makro zunächst die Prozedur StartDB <\/b>im Modul mdlMain <\/b>aufgerufen. Sie hat eigentlich nur die Aufgabe, eine Verbindung zum Server aufzunehmen, die Tabellen und Passthrough-Abfragen neu zu verknüpfen und schließlich den Südsturm-Benutzer anzumelden – richtiger: den Zugang der Gruppe, der er über die Tabellen tblGruppen <\/b>und tblUser <\/b>angehört.<\/p>\n Dazu werden über das ODBC-API erst mal Verbindungstests ausgeführt. Für eine Verbindung sind drei Angaben zwingend erforderlich: Benutzername, Passwort und Serverinstanz. Als Server ist in der Demo der localhost<\/b> hartcodiert. Gibt es diesen Server nicht, so fordert ein Dialog zur Eingabe der korrekten IP auf.<\/p>\n Woher aber kommen Benutzername und Passwort Man könnte die beiden Angaben auch weglassen, was dazu führt, dass der treibereigene Dialog von MyODBC erscheint, mit dem Ihre Anwender wohl eher nicht glücklich werden. Stattdessen sind die beiden Angaben initial fest in die Datenbank eingebaut, und zwar als benutzerdefinierte Eigenschaften AdminUser <\/b>und AdminPassword <\/b>von CurrentDb<\/b>.<\/p>\n Sie könnten die Strings auch hartcodiert im Code hinterlegen, was aber den Nachteil hat, dass sie damit nicht mehr veränderbar sind. Benutzerdefinierte Datenbankeigenschaften dagegen lassen sich jederzeit neu setzen, bleiben aber dem Auge des Anwenders dennoch verborgen.<\/p>\n Da Ihr MySQL-Server die Benutzergruppen der Tabelle tblGruppen <\/b>sicherlich nicht kennt, wird beim ersten Start zum Neuverknüpfen der Tabellen ein Dialog erscheinen, der die Angabe eines Accounts mit ausreichenden Rechten verlangt. Danach werden die Tabellen verlinkt, wodurch überhaupt erst die Tabellen tblUser <\/b>und tblGruppen <\/b>verfügbar werden. Erst jetzt startet das Login-Formular, über das sich der Anwender an Südsturm anmelden kann (siehe Bild 10).<\/p>\n Bild 10: Login an der Demo-Datenbank über ein eigenes Formular<\/span><\/b><\/p>\n So unscheinbar dieses Formular auch wirkt, verbirgt sich dahinter doch einiger Code. Denn der eingegebene Benutzername ist ja nicht der, mit dem der User an MySQL angemeldet werden soll.<\/p>\n Vielmehr muss erst ermittelt werden, welcher Benutzergruppe er angehört, deren Name und Passwort ausgelesen und erst dann eine erneute Verbindung unter anderem Namen am Server vollzogen werden. Dies geschieht über ADO-Connections und -Recordsets. Neue Verbindung Man hat leider keinerlei Einfluss auf die interne Verbindung, die JET zum ODBC-Treiber aufbaut, und man kann sie auch nicht so einfach beenden.<\/p>\n Infolge des internen Connection-Poolings bleibt sie für etwa 10 Minuten bestehen. Werden die Tabellen aber neu verknüpft, dann ändert sich auch diese Connection wieder.<\/p>\n Genau das passiert nach dem Schließen des Login-Formulars. Die Tabellen und Abfragen werden nochmals neu verknüpft, aber diesmal unter dem Gruppennamen des Users. Ab da greifen auch die für die Gruppe vergebenen Rechte und Einschränkungen auf die verknüpften Tabellen oder auf Daten in Recordsets.<\/p>\n Damit Sie nicht erst alle Südsturm-Gruppen-Accounts auf Ihrem Server einrichten müssen, enthält die Datenbank mit dem Formular frmAdministration <\/b>(siehe Bild 11) ein besonderes Schmankerl.<\/p>\n Bild 11: Formular zur Verwaltung von Gruppen und Benutzern in der Demo-Datenbank<\/span><\/b><\/p>\n Über das Formular können neue Benutzer angelegt sowie deren Berechtigungen gesetzt werden – sowohl globale wie Südsturm-Berechtigungen. Zum Einsatz kommen dabei die oben beschriebenen SQL-Anweisungen zur Berechtigungssteuerung.<\/p>\n Wenn Sie den Code des Klassenmoduls studieren, dann achten Sie auf das Zusammensetzen von SQL-Strings und das Absetzen dieser über ADO-Connections. Man könnte dafür zwar auch ODBCDirect-Arbeitsbereiche einsetzen, sollte sich im Hinblick auf Access 2007 und Folgeversionen, die dies nicht mehr unterstützen, aber eher an ADO gewöhnen.<\/p>\n Zusammenfassung<\/b><\/p>\n Wenn Sie die begleitende Demo-Datenbank suedsturm_ mysql4.mdb <\/b>ausprobieren möchten, so beachten Sie bitte die Ausführungen in der Textdatei readme.txt<\/b>. Dort stehen, vor allem für Leser, die nicht über die früheren Folgen der MySQL-Reihe verfügen, genauere Installationshinweise.<\/p>\n Hier konnte nur ein kurzer Einstieg in die Benutzer- und Berechtigungsverwaltung von MySQL gegeben werden, da das Thema doch recht komplex ist. Weiterführende Informationen erhalten Sie vor allem, wenn Sie im Index des MYSQL-Referenzhandbuchs [2] den Begriff GRANT <\/b>eingeben.<\/p>\n Mit den Informationen dieses Beitrags im Gepäck sollten Sie nochmals in sich gehen und vor allem eines tun: sich Gedanken über das Berechtigungskonzept Ihrer aktuellen und zukünftigen MySQL-Datenbanken machen. Was von vornherein gut geplant ist, das bereitet später umso weniger Kopfzerbrechen.<\/p>\n Links<\/p>\n [1] MySQL Administrator und andere Tools: http:\/\/dev.mysql.com\/downloads\/gui-tools\/5.0.html<\/p>\n [2] MySQL-Handbuch 5.1: http:\/\/dev.mysql.com\/doc\/refman\/5.1\/de\/index.html<\/p>\n Enthaltene Beispieldateien:<\/p>\n readme.txt<\/p>\n Suedsturm_Backup4.sql<\/p>\n Suedsturm_mysql4.mdb<\/p>\n\n
\n
![\"system1tabelle.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/system1tabelle_opt.jpeg\")
<\/p>\n![\"system1.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/system1_opt.jpeg\")
<\/p>\n![\"system2.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/system2_opt.jpeg\")
<\/p>\n![\"UserMyAdmin.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/UserMyAdmin_opt.jpeg\")
<\/p>\n![\"myadmin_context.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/myadmin_context_opt.jpeg\")
<\/p>\n![\"UserMyAdmin_Global.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/UserMyAdmin_Global_opt.jpeg\")
<\/p>\n![\"UserMyAdmin_Schema.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/UserMyAdmin_Schema_opt.jpeg\")
<\/p>\n![\"UserMyAdmin_EMS.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/UserMyAdmin_EMS_opt.jpeg\")
<\/p>\nCREATE USER \"Leitung' IDENTIFIED BY \"aiu2008'<\/pre>\n
SET PASSWORD FOR \"Leitung' = PASSWORD(\"aiu2008')<\/pre>\n
DROP USER \"Leitung'<\/pre>\n
CREATE USER \"Leitung'@'%'<\/pre>\n
Gewähre BerechtigungSoundso AUF DatenbankA AN UserA<\/pre>\n
GRANT <Zugriffsrecht> ON <Datenbankobjekt> TO <Username>[@<Host>]<\/pre>\n
GRANT SELECT, INSERT, UPDATE ON suedsturm.* TO \"Leitung'@'%'<\/pre>\n
GRANT SELECT, INSERT, UPDATE ON *.* TO \"Leitung'@'%'<\/pre>\n
GRANT SELECT, INSERT, UPDATE ON suedsturm.tblKunden TO \"Leitung'<\/pre>\n
REVOKE ALL PRIVILEGES FROM \"Leitung'<\/pre>\n
REVOKE INSERT, DELETE ON suedsturm.* FROM \"Leitung'<\/pre>\n
\n
\n
![\"Userlogin.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/Userlogin_opt.jpeg\")
<\/p>\n![\"DemoUserAdmin.png\"](\"..\/fileadmin\/_temp_\/2009_01\/MySQLBerechtigungen-web-images\/DemoUserAdmin_opt.jpeg\")
<\/p>\nDownloads zu diesem Beitrag<\/h3>\n