<\/p>\n
Wenn Sie eine Access-Datenbank mit einem Kennwortschutz versehen, kann der Benutzer ohne Kennwort nicht darauf zugreifen (außer mit gegebenenfalls vorhandener krimineller Energie). Wie aber sieht es aus, wenn Sie mit mehreren Benutzern auf die Daten einer Anwendung zugreifen wollen und diese deshalb in Frontend und Backend aufteilen wollen Wir zeigen, welche Sicherheitslücken dadurch entstehen können und wie Sie diese – allerdings nicht ohne Aufwand – beheben können.<\/b><\/p>\n
Die folgende Situation ist alltäglich: Sie möchten die Daten einer Datenbank, die auf dem Server liegt, schützen. Nur zugriffsberechtigte Mitarbeiter sollen darauf zugreifen können. Am besten noch so, dass verschiedene Mitarbeitergruppen nur auf bestimmte Tabellen zugreifen können.<\/p>\n
Dummerweise besteht nicht die Möglichkeit, einen SQL Server einzurichten – mit diesem wäre das Vorhaben nämlich umsetzbar (zwar auch nicht in kurzer Zeit, denn dazu ist durchaus etwas Vorbereitungs- und Umsetzungsarbeit einzuplanen). Also müssen Sie sich mit einer reinen Access-Lösung behelfen.<\/p>\n
Normalerweise besteht diese dann aus folgendem Szenario: Sie teilen die Datenbank in Frontend- und Backend auf und speichern dabei die Tabellen im Backend und legen entsprechende Tabellenverknüpfungen im Frontend der Datenbank an, über die Sie auf die Tabellen im Backend zugreifen können.<\/p>\n
Frontend-Kennwort<\/b><\/p>\n
Unerfahrere Benutzer versehen dann vielleicht jedes einzelne Frontend mit einem Kennwort, das nur der jeweilige Benutzer kennt. Der Benutzer meldet sich an und kann dann über die Verknüpfungen auf die Tabellen im Backend zugreifen.<\/p>\n
Dummerweise liegt das Backend so immer noch völlig ungeschützt auf dem Server – das Kennwort haben Sie ja schließlich für die Frontend-Datenbank angelegt und nicht für das Backend.<\/p>\n
Beim Anlegen der Verknüpfung fragt Access Sie dann nach dem Kennwort und speichert dieses mit der Verknüpfung.<\/p>\n
In der Beispieldatenbank BE.mdb <\/b>finden Sie eine Beispieltabelle namens tblTest <\/b>mit ein paar Beispielfeldern.<\/p>\n
Dieser fügen wir nun zuerst ein Datenbankkennwort hinzu. In neueren Access-Versionen verschlüsseln Sie die Datenbank somit gleichzeitig.<\/p>\n
Exklusiv öffnen<\/b><\/p>\n
Bevor Sie dies erledigen, sollten Sie jedoch sicherstellen, dass Sie die Datenbank im Exklusiv-Modus geöffnet haben. Dies erledigen Sie etwa unter Access 2010, indem Sie im öffnen<\/b>-Dialog den Eintrag Exklusiv öffnen <\/b>der öffnen-Schaltfläche auswählen (s. Bild 1).<\/p>\n
![\"öffnen](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_001.png\")
<\/p>\n
Bild 1: öffnen einer Datenbank-Datei im Exklusiv-Modus<\/span><\/b><\/p>\n Dies gelingt übrigens nur mit Datenbanken, die noch nicht anderweitig geöffnet sind. Ist dies doch der Fall, erhalten Sie eine entsprechende Meldung (s. Bild 2).<\/p>\n Bild 2: Nur noch nicht geöffnete Datenbanken können exklusiv geöffnet werden.<\/span><\/b><\/p>\n Datenbank verschlüsseln<\/b><\/p>\n Wenn Sie die Datenbank im Exklusiv-Modus geöffnet haben, können Sie etwa unter Access 2010 im Datei<\/b>-Bereich unter Informationen <\/b>die Schaltfläche Mit Kennwort verschlüsseln <\/b>aufrufen (s. Bild 3).<\/p>\n Bild 3: Zuweisen eines Datenbank-Kennwortes und Verschlüsseln der Datenbank<\/span><\/b><\/p>\n Access fragt dann per Dialog das Kennwort ab, wobei der Benutzer dieses zur Sicherheit zwei Mal eingeben muss (s. Bild 4).<\/p>\n Bild 4: Datenbankkennwort festlegen<\/span><\/b><\/p>\n Keine Sperrung auf Datensatzebene<\/b><\/p>\n Gegebenenfalls liefert dies eine Fehlermeldung wie in Bild 5. Sie brauchen dann nichts weiter zu tun – Access ignoriert dann einfach die Sperrung auf Datensatzebene.<\/p>\n Bild 5: Keine Kompatibilität mit Sperrung auf Datensatzebene<\/span><\/b><\/p>\n Kennwort testen<\/b><\/p>\n Schließen Sie nun die Beispieldatenbank und öffnen Sie sie erneut. Es sollte nun ein Dialog erscheinen, der Sie zum Eingeben des Kennworts auffordert (s. Bild 6). <\/p>\n Bild 6: Abfrage des Datenbankkennworts<\/span><\/b><\/p>\n Tabelle verknüpfen<\/b><\/p>\n Die einfachste Möglichkeit, per Frontend-Datenbank auf eine Tabelle in einer verschlüsselten und kennwortgeschützten Backend-Datenbank zuzugreifen, ist das Anlegen einer Verknüpfung.<\/p>\n Also schließen Sie die Backend-Datenbank und öffnen die zukünftige Frontend-Datenbank. Führen Sie die zum Verknüpfen mit einer externen Datenbanktabelle nötigen Schritte durch. Wenn Sie die Backend-Datenbank ausgewählt haben, erscheint wiederum der Dialog zur Eingabe des Datenbank-Kennworts. Nach der Eingabe zeigt Access schließlich die in der Backend-Datenbank enthaltenen Tabellen an (s. Bild 7). Wählen Sie die Tabelle tblTest <\/b>aus und klicken Sie auf die Schaltfläche OK<\/b>.<\/p>\n <\/p>\n Bild 7: Verknüpfen mit der Tabelle der verschlüsselten Datenbank<\/span><\/b><\/p>\n Sie können nun wie gewohnt auf die Daten der verknüpften Tabelle zugreifen. Nun schließen Sie Access und die Frontend-Datenbank und öffnen beide erneut. Sie können nun auf die Tabelle des Backends zugreifen, ohne erneut das Kennwort eingeben zu müssen.<\/p>\n Das ist interessant – das Kennwort scheint also irgendwo in der Datenbank gespeichert worden zu sein.<\/p>\n Kennwort in MSysObjects<\/b><\/p>\n Die Frage nach dem Speicherort für das Kennwort ist schnell beantwortet: Sie finden dieses an der gleichen Stelle, an der sich auch die Verknüpfungseigenschaften befinden – nämlich in der Tabelle MSysObjects<\/b>.<\/p>\n Diese sieht ausschnittsweise wie in Bild 8 aus. Dort wird das Kennwort gleich im Klartext aufgeführt. Wer auf diese Tabelle zugreifen kann, kann sich also auch direkten Zugriff auf die komplette Backend-Datenbank verschaffen. Sicherheitstechnisch ist das natürlich keine besonders gute Lösung – wer sich ein klein wenig mit Access auskennt, kann diesen Mechanismus aushebeln.<\/p>\n Bild 8: Das Kennwort der Backend-Datenbank wird in der Tabelle MSysObjects gespeichert.<\/span><\/b><\/p>\n Kennwort verbergen<\/b><\/p>\n Welche Möglichkeit gibt es also nun, das Kennwort vor den Augen des Nutzers der Frontend-Datenbank zu verbergen Es gibt wohl keine einfache Variante, die Verknüpfungen zu den Tabellen des Backends liefert und so einen einfachen Zugriff von Formularen, Berichten und VBA aus ermöglicht.<\/p>\n Abfrage mit Kennwort<\/b><\/p>\n Eine Idee lautete, einfach Abfragen zu erstellen, die auf die Tabellen der Backend-Datenbank zugreifen. An sich keine schlechte Idee. Eine solche Abfrage erstellt man mit Programmcode wie dem aus Listing 1. Die Prozedur erstellt ein neues QueryDef-Objekt und verwendet dabei eine SQL-Abfrage, die nicht auf eine lokale Tabelle zugreift, sondern auf die Tabelle im Backend – etwa so:<\/p>\n Listing 1: Erstellen einer Abfrage auf eine Tabelle im kennwortgeschützten Backend<\/span><\/b><\/p>\n Mit dem Parameter PWD <\/b>wird dabei das Kennwort festgelegt. Der Zugriff über die Abfrage gelingt, und das Kennwort kann auch nicht über die Systemtabelle MSys-Objects <\/b>ausgelesen werden. Allerdings finden sich die Eigenschaften mit der Angabe der Quelldatenbank sowie dem Kennwort im Entwurf der Abfrage wieder, wie Bild 9 zeigt. Um diese Eigenschaften zu sehen, klicken Sie auf die Tabelle im oberen Bereich der Entwurfsansicht.<\/p>\n Bild 9: Abfrage mit einer Tabelle aus einer kennwortgeschützten Backend-Datenbank<\/span><\/b><\/p>\n Genau wie die Tabelle MSysObjects ist auch dies für Otto Normalverbraucher schwer zu finden, aber ein Access-Entwickler wird das Kennwort der Backend-Datenbank schnell ermitteln können.<\/p>\n Der Wunsch, dass die Entwurfsansicht der Abfrage wie bei Formularen, Berichten und Modulen in einer zu einer .mde <\/b>oder .accde <\/b>umgewandelten Datenbankdatei nicht mehr zu öffnen ist, erfüllt sich nicht – der Entwurf von Tabellen und Abfragen steht dem Benutzer einer .mde<\/b>– oder .accde<\/b>-Datenbank offen.<\/p>\n Backend-Zugriff per VBA<\/b><\/p>\n Die Idee mit der .mde<\/b>– oder .accde<\/b>-Datei ist allerdings nicht allzu schlecht: Die einzige Möglichkeit, das Kennwort zuverlässig vor den Augen des Benutzers zu schützen, ist das Verstecken des Kennworts im Code und anschließendes Umwandeln in eine .mde<\/b>\/.accde<\/b>-Datenbank. Dass auch diese wiederum dekompiliert werden kann, lassen wir an dieser Stelle außen vor – es gibt nur sehr wenige kommerzielle Anbieter, die eine solche Dienstleistung offerieren, und die prüfen in der Regel zuvor, ob der Auftraggeber der tatsächliche Eigentümer der Datenbank ist.<\/p>\n Aber wie bekommen wir das Kennwort, das wir beispielsweise als Konstante in einem Standardmodul untergebracht haben, in die Tabelle oder Abfrage Die Antwort lautet: gar nicht. Zumindest nicht, ohne dass der Benutzer das Kennwort anschließend wieder über die Systemtabelle MSysObjects <\/b>oder über den Abfrageentwurf ermitteln kann.<\/p>\n Damit steht fest: Wenn Sie auf Daten aus einer kennwortgeschützten Backend-Datenbank zugreifen möchten, können Sie gar nicht mit Tabellen oder Abfragen arbeiten.<\/p>\n Recordset mit Kennwort<\/b><\/p>\n Zum Glück bieten aber sowohl Formulare als auch Berichte und auch Steuer-elemente wie das Kombinationsfeld oder das Listenfeld eine Recordset<\/b>-Eigenschaft zum Füllen mit Daten an. Dieser Eigenschaft können Sie beim öffnen des Formulars\/Berichts oder auch zur Laufzeit ein per VBA erstelltes Recordset zuweisen, das die gewünschten Daten enthält.<\/p>\n Im Beispiel des Formulars frmTest<\/b> aus Bild 10 implementieren wir die Ereignisprozedur Beim Laden<\/b>. Diese soll einige Zeilen Code enthalten, die ein Recordset auf Basis der Tabelle tblTest <\/b>der kennwortgeschützten Backend-Datenbank öffnet und der Recordset<\/b>-Eigenschaft des Formulars zuweist.<\/p>\n Bild 10: Dieses Formular wird erst beim öffnen über ein Recordset befüllt.<\/span><\/b><\/p>\n Listing 2 zeigt den Aufbau der benötigten Prozedur. Diese füllt zunächst das Database<\/b>-Objekt db <\/b>mit einem Verweis auf die Backend-Datenbank, wobei sie die OpenDatabase<\/b>-Methode verwendet. Diese erwartet als Parameter zunächst den Pfad zu der zu verwendenden Datenbank-Datei.<\/p>\n Listing 2: öffnen einer Abfrage mit übergabe des Kennworts<\/span><\/b><\/p>\n Die beiden folgenden Parameter legen fest, ob die Datenbank im Exklusiv-Modus geöffnet werden (hier False<\/b>) und ob die Datenbank nur zum Lesen geöffnet werden soll (ebenfalls False<\/b>). Der letzte Parameter erwartet einen Hinweis auf die Art der zu öffnenden Datenbank sowie das Kennwort, das durch das Name-Wert-Paar PWD=test <\/b>übergeben wird.<\/p>\n Das Formular lässt sich auf diese Weise problemlos öffnen und zeigt die Daten der Tabelle tblTest <\/b>an – diese können auch bearbeitet werden.<\/p>\n Viel Arbeit<\/b><\/p>\n Wenn Sie eine Backend-Datenbank tatsächlich auf diese Weise schützen wollen, müssen Sie jede einzelne Datenherkunft\/Datensatzherkunft von Formularen, Unterformularen, Berichten, Kombinationsfeldern und Listenfeldern anpassen.<\/p>\n Das Aktualisieren der Datenherkünfte\/Datensatzherkünfte ist dann nicht nur auf das öffnen von Formularen beschränkt. Wenn ein Formular ein Unterformular enthält, dessen Daten vom aktuell im Hauptformular angezeigten Datensatz abhängen, müssen Sie die Datenherkunft des Unterformulars bei jedem Datensatzwechsel im Hauptformular wechseln. Gleiches gilt etwa bei abhängigen Kombinations- und Listenfeldern – aber hier ist ja ohnehin bereits der Einsatz des Ereignisses Nach Aktualisierung <\/b>des übergeordneten Kombinationsfeldes gefragt, um die Datensatzherkunft des abhängigen Kombinationsfeldes zu ändern.<\/p>\n Sollten Sie ein solches Vorhaben durchführen, legen Sie am besten eine Standard-Prozedur an, welche das Recordset öffnet und zuweist.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Verschlüsselte Backends machen nur so lange Sinn, bis ein Benutzer das Kennwort erfährt. Um dieses zuverlässig zu verbergen, ist großer Aufwand nötig. Abgesehen davon wäre noch zu prüfen, wie sich die üblichen Tricks zur Steigerung der Performance (Aufrechterhalten einer Verbindung zum Backend et cetera) für diesen Fall umsetzen lassen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n BE.mdb<\/p>\n FE.mdb<\/p>\n![\"Nur](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_003.png\")
<\/p>\n![\"Zuweisen](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_002.png\")
<\/p>\n![\"Datenbankkennwort](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_004.png\")
<\/p>\n![\"Keine](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_005.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_006.png\")
<\/p>\n![\"Verknüpfen](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_007.png\")
<\/p>\n![\"Das](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_008.png\")
<\/p>\nPublic Sub <\/span>AbfrageErstellen()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> db = CurrentDb\r\n On Error Resume Next<\/span>\r\n db.QueryDefs.Delete \"qryTest\"\r\n On Error GoTo<\/span> 0\r\n Set<\/span> qdf = db.CreateQueryDef(\"qryTest\", \"SELECT * FROM [;PWD=test;DATABASE=\" _\r\n & CurrentProject.Path & \"\\BE.accdb].tblTest\")\r\n Set<\/span> rst = qdf.OpenRecordset\r\n Do While<\/span> Not<\/span> rst.EOF\r\n Debug.Print<\/span> rst.Fields(0)\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\nEnd Sub<\/span><\/pre>\nSELECT * FROM [;PWD=test;DATABASE=c:\\BE.accdb].tblTest\")<\/pre>\n
![\"Abfrage](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_009.png\")
<\/p>\n![\"Dieses](\"..\/fileadmin\/_temp_\/2014_01\/pic_920_010.png\")
<\/p>\nPrivate Sub <\/span>Form_Load()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> db = OpenDatabase(CurrentProject.Path & \"\\BE.accdb\", False, False, \"MS Access;PWD=test;\")\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblTest\", dbOpenDynaset)\r\n Set<\/span> Me.Recordset = rst\r\nEnd Sub<\/span><\/pre>\nDownloads zu diesem Beitrag<\/h3>\n