Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Laut Microsoft ist das Sicherheitssystem von Access in Datenbanken im .accdb-Format gestorben. Wir haben herausgefunden, das dies aber mitnichten so ist: Zwar gibt es keine Dialoge mehr, um die Sicherheit einzustellen und Benutzer und Gruppen zu verwalten, und auch bei hoch konvertierten Datenbanken älterer Versionen reagiert das Sicherheitssystem nicht wie erwartet, aber das ist kein Grund zum Verzweifeln: Mit ein paar kleinen Tricks schützen Sie mit dem guten alten Sicherheitssystem zumindest noch die Tabellen Ihrer Anwendung.
Die Nachricht, dass Access 2007 in Datenbanken, die im neuen Format erstellt werden, das Sicherheitssystem nicht mehr unterstützt, fand gemischten Anklang: Die einen interessierte dies nicht, weil das Sicherheitssystem ohnehin keinen hundertprozentigen Schutz mehr bot, die anderen waren verunsichert und fragten sich, wie sie ihre Daten zumindest rudimentär vor unbefugtem lesenden oder auch schreibenden Zugriff schützen. Eine Alternative gibt es für diesen Fall: Man muss die Datenbank dazu in eine SQL Server-Datenbank migrieren (unabhängig davon, ob man nun den Microsoft SQL Server oder ein Konkurrenzprodukt wie etwa MySQL verwendet).
Es ist allerdings nach wie vor möglich, eine Datenbank im Access 2007-Format zu schützen – auch wenn sich dieser Schutz nur auf Tabellen bezieht. Aber die übrigen Objekte kann man schließlich auch per Code schützen, indem man beim Öffnen den aktuellen Benutzer abfragt und das Objekt dann entweder öffnet oder dem Benutzer den Zugriff verweigert – Sie müssen die Datenbank dann nur in eine .accde-Datei umwandeln, damit der Benutzer den schützenden Code nicht ändern und somit unwirksam machen kann.
Das Schützen der Tabellen erfordert allerdings eine Menge Mehraufwand gegenüber älteren Access-Versionen, wobei der größte Teil daraus resultiert, dass Sie die Funktionen der Dialoge zum Hinzufügen von Benutzern und Benutzergruppen sowie zum Setzen der Berechtigungen per VBA nachprogrammieren müssen.
Dies allein reicht allerdings nicht aus: Selbst wenn Sie sich passende Routinen zurechtlegen und eine Datenbank schützen, erfolgt der Zugriff auf die Tabellen ohne Probleme. Was also ist der Trick Dazu holen wir ein wenig aus: Beim Herumspielen mit einer .accdb-Datenbank fiel auf, dass der schreibende Zugriff auf die Systemtabellen wie MSysObjects nach wie vor nicht möglich ist. Es erschien unwahrscheinlich, dass Access auch in früheren Versionen zwei verschiedene Sicherheitssysteme enthielt, welche die Systemtabellen auf der einen und die benutzerdefinierten Tabellen auf der anderen Seite schützten. Wenn also eine Systemtabelle in einer .accdb-Datei noch geschützt ist, muss das Sicherheitssystem noch vorhanden. Dafür sprechen auch die zwar ausgeblendeten, aber immer noch vorhandenen Einträge zum Bearbeiten von Benutzern, Benutzergruppen und Berechtigungen in der DAO 12.0-Bibliothek.
Eine benutzerdefinierte Tabelle lässt sich relativ einfach in eine Systemtabelle umwandeln: dazu braucht man nur eine Eigenschaft zu ändern. Das Ganze haben wir an einer vom .mdb-Format zum .accdb-Format migrierten Beispieldatenbank ausprobiert, die eine einzige geschützte Tabelle enthielt. Und siehe da: Vor dem Umwandeln in eine Systemtabelle war diese Tabelle erwartungsgemäß ungeschützt, danach aber wurde der Zugriff wie gewünscht eingeschränkt!
Ein letzter Test war ebenfalls noch notwendig: Der Benutzer darf natürlich nicht die Eigenschaften der in eine Systemtabelle umgewandelten Tabelle ändern, da er diese sonst wieder zu einer normalen Tabelle machen kann. Aber auch dies funktionierte reibungslos, wenn man dem Benutzer die änderung des Entwurfs untersagte.
Wir zeigen Ihnen in den folgenden Abschnitten, wie Sie eine .accdb-Anwendung schützen können.
Systemtabellen für normale Daten
Die einzige Frage, die sich stellt, ist die, ob es irgendwelche Probleme mit Tabellen gibt, die zum Zwecke der Aktivierung des Schutzes in Systemtabellen umgewandelt wurden. Es gibt noch keine umfassenden Erfahrungen, aber zumindest auch noch keine negativen: Der Zugriff erfolgt von allen Access-Objekten wie Abfragen, Formularen und Berichten genauso wie von VBA aus für den mit Berechtigung angemeldeten User ohne Probleme.
Der einzige Nachteil ist natürlich, dass die Tabellen im Navigationsbereich nur mit den eingebauten Systemtabellen zusammen entweder ein- oder ausgeblendet werden können. Dies ist allerdings kein Nachteil, da die Systemtabellen beim Entwickeln wohl kaum stören und der Endanwender diese ohnehin nicht zu Gesicht bekommen soll.
Datenbank schützen
Vor dem Schützen einer Datenbank sollten Sie vorsichtshalber eine Sicherheitskopie derselben anlegen.
Anschließend starten Sie den Arbeitsgruppenadministrator (siehe Bild 1) über den folgenden Befehl, den Sie im Direktfenster des VBA-Editors (Strg + G) absetzen:
Bild 1: Der Arbeitsgruppenadministrator von Access
DoCmd.RunCommand acCmdWorkgroupAdministrator
Immerhin ist dieser, im Gegensatz zu den Dialogen zum Verwalten von Benutzern und Benutzergruppen sowie der Berechtigungen, noch verfügbar – und zwar auch für .accdb-Datenbanken.
Dort klicken Sie auf die Schaltfläche Erstellen, woraufhin der Dialog aus Bild 2 erscheint. Dort tragen Sie Ihren Namen, die Firma und eine Arbeitsgruppen-ID ein. Die Informationen zeigt Access später noch einmal an, damit Sie sich diese notieren können.
Bild 2: Festlegen des Arbeitsgruppenbesitzers
Im folgenden Dialog geben Sie den Namen der zu verwendenden Arbeitsgruppen-Informationsdatei an, die vermutlich neu erstellt werden soll (siehe Bild 3).
Bild 3: Anlegen einer
Nachdem Sie sich auf diese Weise an die Arbeitsgruppen-Informationsdatei angeschlossen haben, erscheinen nochmals alle wichtigen Informationen (siehe Bild 4).
Bild 4: Informationen zur
Nun ist es aber so, dass diese Arbeitsgruppen-Informationsdatei standardmäßig mit Access verwendet wird. Sie sollten also im Anschluss wieder der Standard-Arbeitsgruppen-Informationsdatei (System.mdw) beitreten.
Damit die neue Arbeitsgruppen-Informationsdatei in Zusammenhang mit der zu schützenden Anwendung geöffnet wird, verwenden Sie zum Öffnen eine entsprechende Verknüpfung, die etwa folgenden Inhalt hat:
"C:\Programme\Microsoft Office\Office12\MSACCESS.EXE" c:\Sicher.accdb /wrkgrp c:\Sicher.mdw
Später geben Sie hier zusätzlich den Namen des Benutzers und sein Kennwort an.
Schließen Sie die Anwendung und öffnen Sie diese mit der oben beschriebenen Verknüpfung erneut. Fragen Sie dann ab, ob die Anwendung die richtige Arbeitsgruppen-Informationsdatei verwendet. Dies erledigen Sie ganz einfach über die folgende Anweisung im Direktfenster:
Debug.Print SysCmd(acSysCmdGetWorkgroupFile) c:\Sicher.mdw
Datenbank absichern
Unter Access 2003 und älter würden Sie nun den Menübefehl Extras|Sicherheit|Benutzer- und Gruppenkonten… auswählen, um den Dialog Benutzer- und Gruppenkonten zu öffnen. Da das Sicherheitssystem mit .accdb-Dateien offiziell nicht mehr unterstützt wird, hat Microsoft natürlich keinen solchen Befehl eingebaut, und auch der ersatzweise verwendbare VBA-Befehl
docmd.RunCommand acCmdUserAndGroupAccounts
steht nicht zur Verfügung – er löst schlicht einen Fehler aus, der darauf hinweist, dass dieser Befehl derzeit nicht verfügbar ist (wenn Sie eine .mdb-Datenbank bearbeiten, funktioniert dies hingegen schon). Also müssen Sie alles per VBA erledigen, und zwar über die entsprechenden Elemente der DAO-Bibliothek.
IntelliSense für verborgene Elemente aktivieren
Die Elemente von DAO, die unter Access 2007 nur noch aus Kompatibilitätsgründen vorliegen, werden von IntelliSense nicht mehr berücksichtigt und auch im Objektkatalog nicht mehr angezeigt – zumindest nicht, bis man deren Anzeige nicht über den Kontextmenüeintrag Verborgene Elemente anzeigen aktiviert. Anschließend erscheinen diese Elemente sowohl im Objektkatalog als auch unter IntelliSense in hellgrauer Schrift. Diesen Vorgang müssen Sie übrigens nach jedem Neustart von Access wiederholen (siehe Bild 5).
Bild 5: Einblenden verborgener Elemente
Benutzer ausgeben
Die folgende kleine Routine gibt beispielsweise alle Benutzer des aktuellen Workspace-Objekts aus, in dessen Kontext die Datenbankanwendung läuft.
Optional geben Sie die Gruppe an, deren Benutzer die Routine ausgeben soll:
Public Sub ShowUsers(Optional _
strGroup As Variant)
Dim wrk As DAO.Workspace
Dim usr As DAO.User
Dim grp As DAO.Group
Set wrk = DBEngine.Workspaces(0)
If IsMissing(strGroup) Then
For Each usr In wrk.Users
Debug.Print usr.Name
Next usr
Else
Set grp = wrk.Groups(strGroup)
For Each usr In grp.Users
Debug.Print usr.Name
Next usr
End If
End Sub
Gruppen ausgeben
Auch die Gruppen lassen sich leicht auflisten:
Public Sub ShowGroups()
Dim wrk As DAO.Workspace
Dim grp As DAO.Group
Set wrk = DBEngine.Workspaces(0)
For Each grp In wrk.Groups
Debug.Print grp.Name
Next grp
End Sub
Um die Datenbank initial abzusichern, müssen Sie dem admin-Konto ein Kennwort zuweisen. Das erledigt die NewPassword-Funktion, die durch folgende Routine gekapselt wird:
Public Function SetPassword(strUsername As _
String, strPasswordOld As String, _
strPasswordNew As String)
Dim wrk As DAO.Workspace
Dim usr As DAO.User
Set wrk = DBEngine.Workspaces(0)
Set usr = wrk.Users(strUsername)
usr.NewPassword strPasswordOld, _
strPasswordNew
End Function
Der Aufruf bei leerem Kennwort lautet beispielsweise so:
SetPassword "admin", "", "Kennwort"
Beim nächsten Öffnen der Datenbank erscheint ein Dialog, der zum Eingeben des Kennworts auffordert (siehe Bild 6). Entfernen können Sie das Kennwort durch Setzen einer leeren Zeichenkette als Kennwort:
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo