{"id":55000616,"date":"2008-08-01T00:00:00","date_gmt":"2021-02-11T21:21:36","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=616"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Access_2007_Sicherheitssystem_einsetzen","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Access_2007_Sicherheitssystem_einsetzen\/","title":{"rendered":"Access 2007: Sicherheitssystem einsetzen"},"content":{"rendered":"

\"\"<\/p>\n

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.<\/b><\/p>\n

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).<\/p>\n

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.<\/p>\n

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.<\/p>\n

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 <\/b>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.<\/p>\n

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!<\/p>\n

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.<\/p>\n

Wir zeigen Ihnen in den folgenden Abschnitten, wie Sie eine .accdb-Anwendung schützen können.<\/p>\n

Systemtabellen für normale Daten<\/b><\/p>\n

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.<\/p>\n

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.<\/p>\n

Datenbank schützen<\/b><\/p>\n

Vor dem Schützen einer Datenbank sollten Sie vorsichtshalber eine Sicherheitskopie derselben anlegen.<\/p>\n

Anschließend starten Sie den Arbeitsgruppenadministrator (siehe Bild 1) über den folgenden Befehl, den Sie im Direktfenster des VBA-Editors (Strg + G<\/b>) absetzen:<\/p>\n

\"pic001.tif\"<\/p>\n

Bild 1: Der Arbeitsgruppenadministrator von Access<\/span><\/b><\/p>\n

DoCmd.RunCommand acCmdWorkgroupAdministrator<\/pre>\n
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.<\/p>\n
Dort klicken Sie auf die Schaltfläche Erstellen<\/b>, 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.<\/p>\n
\"pic002.tif\"<\/p>\n
Bild 2: Festlegen des Arbeitsgruppenbesitzers<\/span><\/b><\/p>\n
Im folgenden Dialog geben Sie den Namen der zu verwendenden Arbeitsgruppen-Informationsdatei an, die vermutlich neu erstellt werden soll (siehe Bild 3).<\/p>\n
\"pic004.tif\"<\/p>\n
Bild 3: Anlegen einer <\/span><\/b><\/p>\n
Nachdem Sie sich auf diese Weise an die Arbeitsgruppen-Informationsdatei angeschlossen haben, erscheinen nochmals alle wichtigen Informationen (siehe Bild 4).<\/p>\n
\"pic006.tif\"<\/p>\n
Bild 4: Informationen zur <\/span><\/b><\/p>\n
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<\/b>) beitreten.<\/p>\n
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:<\/p>\n
"C:\\Programme\\Microsoft Office\\Office12\\MSACCESS.EXE" c:\\Sicher.accdb \/wrkgrp c:\\Sicher.mdw<\/pre>\n
Später geben Sie hier zusätzlich den Namen des Benutzers und sein Kennwort an.<\/p>\n
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:<\/p>\n
Debug.Print SysCmd(acSysCmdGetWorkgroupFile)\r\nc:\\Sicher.mdw<\/pre>\n
Datenbank absichern<\/b><\/p>\n
Unter Access 2003 und älter würden Sie nun den Menübefehl Extras|Sicherheit|Benutzer- und Gruppenkonten… <\/b>auswählen, um den Dialog Benutzer- und Gruppenkonten <\/b>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<\/p>\n
docmd.RunCommand acCmdUserAndGroupAccounts<\/pre>\n
<\/p>\n
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.<\/p>\n
IntelliSense für verborgene Elemente aktivieren<\/b><\/p>\n
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 <\/b>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).<\/p>\n
\"pic003.tif\"<\/p>\n
Bild 5: Einblenden verborgener Elemente<\/span><\/b><\/p>\n
Benutzer ausgeben<\/b><\/p>\n
Die folgende kleine Routine gibt beispielsweise alle Benutzer des aktuellen Workspace<\/b>-Objekts aus, in dessen Kontext die Datenbankanwendung läuft.<\/p>\n
Optional geben Sie die Gruppe an, deren Benutzer die Routine ausgeben soll:<\/p>\n
Public Sub ShowUsers(Optional _\r\n    strGroup As Variant)\r\n    Dim wrk As DAO.Workspace\r\n    Dim usr As DAO.User\r\n    Dim grp As DAO.Group\r\n    Set wrk = DBEngine.Workspaces(0)\r\n    If IsMissing(strGroup) Then\r\n        For Each usr In wrk.Users\r\n            Debug.Print usr.Name\r\n        Next usr\r\n    Else\r\n        Set grp = wrk.Groups(strGroup)\r\n        For Each usr In grp.Users\r\n            Debug.Print usr.Name\r\n        Next usr\r\n    End If\r\nEnd Sub<\/pre>\n
Gruppen ausgeben<\/b><\/p>\n
Auch die Gruppen lassen sich leicht auflisten:<\/p>\n
Public Sub ShowGroups()\r\n    Dim wrk As DAO.Workspace\r\n    Dim grp As DAO.Group\r\n    Set wrk = DBEngine.Workspaces(0)\r\n    For Each grp In wrk.Groups\r\n        Debug.Print grp.Name\r\n    Next grp\r\nEnd Sub<\/pre>\n
Um die Datenbank initial abzusichern, müssen Sie dem admin<\/b>-Konto ein Kennwort zuweisen. Das erledigt die NewPassword<\/b>-Funktion, die durch folgende Routine gekapselt wird:<\/p>\n
Public Function SetPassword(strUsername As _\r\n        String, strPasswordOld As String, _\r\n        strPasswordNew As String)\r\n    Dim wrk As DAO.Workspace\r\n    Dim usr As DAO.User\r\n    Set wrk = DBEngine.Workspaces(0)\r\n    Set usr = wrk.Users(strUsername)\r\n    usr.NewPassword strPasswordOld, _\r\n        strPasswordNew\r\nEnd Function<\/pre>\n
Der Aufruf bei leerem Kennwort lautet beispielsweise so:<\/p>\n
SetPassword "admin", "", "Kennwort"<\/pre>\n
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:<\/p>\n
\"pic005.tif\"<\/p>\n
Bild 6: Dieser Dialog erscheint, wenn man dem Administratorkonto ein Kennwort zugewiesen hat.<\/span><\/b><\/p>\n
SetPassword "admin", "Kennwort", ""<\/pre>\n
Neuen Benutzer anlegen<\/b><\/p>\n
Sie benötigen einen Benutzer, der als neuer Administrator fungieren wird. Dem bestehenden Administratorkonto admin <\/b>entziehen Sie später alle Rechte und entfernen es aus der Gruppe der Administratoren. Die folgende Routine legt einen neuen Benutzer an:<\/p>\n
Public Function AddUser(strUsername As String, _\r\n        strPID As String, _\r\n        strPassword As String) As Boolean\r\n    Dim wrk As DAO.Workspace\r\n    Dim usr As DAO.User\r\n    On Error GoTo AddUser_Err\r\n    Set wrk = DBEngine.Workspaces(0)\r\n    Set usr = wrk.CreateUser(strUsername, _\r\n        strPID, strPassword)\r\n    wrk.Users.Append usr\r\n    AddUser = True\r\nAddUser_Exit:\r\n    Exit Function\r\nAddUser_Err:\r\n    Select Case Err.Number\r\n        Case 3390 'User schon vorhanden\r\n            Resume AddUser_Exit\r\n        Case Else\r\n            MsgBox Err.Number & " " _\r\n                & Err.Description\r\n    End Select\r\n    Resume AddUser_Exit\r\nEnd Function<\/pre>\n
Benutzer löschen<\/b><\/p>\n
Auch das Löschen von Benutzern ist möglich; aus Platzgründen drucken wir den notwendigen Code hier nicht ab. Sie finden ihn aber in der Routine DeleteUser <\/b>im Modul mdlSecurity <\/b>der Beispieldatenbanken.<\/p>\n
Benutzer zur Gruppe hinzufügen<\/b><\/p>\n
Nun fügen Sie den neuen Benutzer zur Gruppe admins <\/b>hinzu. Dies erledigt die Funktion AddUserToGroup<\/b>, die Sie mit folgender Anweisung aufrufen:<\/p>\n
AddUserToGroup "aiuadmin", "admins"<\/pre>\n
Die Funktion sieht so aus:<\/p>\n
Public Function AddUserToGroup(strUsername As _\r\n        String, strGroup As String) As Boolean\r\n    Dim wrk As DAO.Workspace\r\n    Dim grp As DAO.Group\r\n    Dim usr As DAO.User\r\n    On Error GoTo AddUserToGroup_Err\r\n    Set wrk = DBEngine(0)\r\n    Set grp = wrk.Groups(strGroup)\r\n    Set usr = grp.CreateUser(strUsername)\r\n    grp.Users.Append usr\r\n    AddUserToGroup = True\r\n    AddUserToGroup_Exit:\r\n    Exit Function\r\nAddUserToGroup_Err:\r\n    Select Case Err.Number\r\n        Case 3032 'User schon in Gruppe\r\n            Resume AddUserToGroup_Exit\r\n        Case 3265 'Gruppe nicht vorhanden\r\n            Resume AddUserToGroup_Exit\r\n        Case 3030 'User nicht vorhanden\r\n            Resume AddUserToGroup_Exit\r\n        Case Else\r\n            MsgBox Err.Number & " " _\r\n                & Err.Description\r\n    End Select\r\n    Resume AddUserToGroup_Exit\r\nEnd Function<\/pre>\n
Benutzer aus Gruppe entfernen<\/b><\/p>\n
Anschließend entfernen Sie das bisher einzige in der Gruppe admins <\/b>enthaltene Benutzerkonto aus dieser Gruppe.<\/p>\n
Public Function RemoveUserFromGroup(strUsername _\r\n        As String, strGroup As String)\r\n    Dim wrk As DAO.Workspace\r\n    Dim usr As DAO.User\r\n    Dim grp As DAO.Group\r\n    On Error GoTo RemoveUserFromGroup_Err\r\n    Set wrk = DBEngine(0)\r\n    Set grp = wrk.Groups(strGroup)\r\n    grp.Users.Delete strUsername\r\n    RemoveUserFromGroup = True\r\nRemoveUserFromGroup_Exit:\r\n    Exit Function\r\nRemoveUserFromGroup_Err:\r\n    Select Case Err.Number\r\n        Case 3265 'User oder Group n. vorhanden\r\n            Resume RemoveUserFromGroup_Exit\r\n        Case Else\r\n            MsgBox Err.Number & " " _\r\n                & Err.Description\r\n    End Select\r\n    Resume RemoveUserFromGroup_Exit\r\nEnd Function<\/pre>\n
Um sicherzugehen, dass der neue Benutzer der einzige Eintrag in der Gruppe admins <\/b>ist, verwenden Sie die bereits weiter oben vorgestellte Routine ShowUsers<\/b>. Auf diese Weise können Sie alle Benutzer einer Gruppe ausgeben lassen.<\/p>\n
Als neuer Administrator anmelden<\/p>\n
Nun melden Sie sich unter dem neuen Administratorkonto an der Datenbank an. Dazu muss Access beendet werden (das Schließen der Datenbank reicht nicht aus) und Sie öffnen die Datenbank dann erneut mit der oben angegebenen Verknüpfung. Im Anmeldedialog geben Sie nun, soweit diese Informationen nicht Bestandteil der Verknüpfung sind, Name und Kennwort des neuen Administrators ein.<\/p>\n
Administrator als Besitzer aller Objekte <\/b><\/p>\n
festlegen<\/pre>\n
Noch hat der neue Administrator wenig zu sagen: So ist er zum Beispiel noch nicht Besitzer der bestehenden Objekte der Datenbank. Dies holen Sie nun nach, indem Sie zunächst eine neue, leere Datenbank anlegen und öffnen. Auch hier erscheint nun der Anmeldedialog, denn die Workgroup-Datei, die Sie vorhin angelegt haben, ist immer noch die gültige und so werden alle neuen Datenbanken zunächst dieser Datei angeschlossen.<\/p>\n
Melden Sie sich unter dem neuen Administratorkonto an und importieren Sie alle Objekte der anderen Datenbank.<\/p>\n
Benutzer entmachten<\/p>\n
Die Mitglieder der Benutzergruppe Benutzer <\/b>(users<\/b>) besitzen standardmäßig volle Zugriffsrechte auf alle Datenbankobjekte. Neue Benutzer werden automatisch dieser Gruppe zugeordnet. Daher müssen Sie dieser Gruppe pauschal alle Berechtigungen entziehen.<\/p>\n
Tabellen in Systemtabellen umwandeln<\/b><\/p>\n
Bevor Sie nun Berechtigungen für die einzelnen Benutzer\/Benutzergruppen und Access-Tabellen festlegen, sollten Sie die Tabellen zunächst in Systemtabellen umwandeln – sonst zeigen die gesetzten Zugriffsrechte nämlich keine Wirkung. Dies erledigt die folgende Routine für alle Tabellen:<\/p>\n
Public Function MakeSystemObjects()\r\n    Dim db As DAO.Database\r\n    Dim tdf As DAO.TableDef\r\n    Set db = DBEngine(0)(0)\r\n    For Each tdf In db.TableDefs\r\n        If (tdf.Attributes And _\r\n            TableDefAttributeEnum. _\r\n            dbSystemObject) = False Then\r\n                tdf.Attributes = tdf.Attributes _\r\n                    Or TableDefAttributeEnum. _\r\n                    dbSystemObject\r\n        End If\r\n    Next tdf\r\nEnd Function<\/pre>\n
Wo sind die Objekte<\/b><\/p>\n
Wer bereits eine Menge Objekte in der aktuellen Datenbank angelegt hat, erschrickt nun möglicherweise, falls der Navigationsbereich kein einziges Objekt mehr anzeigt – egal, welche Einstellungen man im Dialog Navigationsoptionen <\/b>(Kontextmenü des Navigationsbereich-Kopfes|Navigationsoptionen<\/b>) einstellt. Sie können sich aber davon überzeugen, dass die Objekte noch vorhanden sind, indem Sie beispielsweise die Anzahl der Datensätze einer der Tabellen im Direktfenster ausgeben lassen:<\/p>\n
 CurrentDB.TableDefs("tblArtikel").RecordCount<\/pre>\n
Dabei stellen Sie auch fest, dass die VBA-Entwicklungsumgebung weiterhin alle Module aufführt. Wenn Sie sich wieder unter dem alten Administratorkonto anmelden, zeigt Access die Objekte wieder vollständig an. Neuen Admin zum Besitzer aller Objekte machen<\/b><\/p>\n
Damit der neue Administrator-Benutzer wirklich die kompletten Rechte an den Objekten der Tabelle hat, muss er Ersteller der Objekte sein. Dies erreichten Sie, indem Sie Access im Kontext des neuen Administratorkontos öffneten und alle Objekte der ungeschützten Datenbank in die neue Datenbank importierten – der aktuelle Benutzer wird automatisch Ersteller der Objekte.<\/p>\n
Berechtigungen setzen<\/b><\/p>\n
Schließlich müssen Sie noch die Berechtigungen der einzelnen Benutzer oder Benutzergruppen für die Tabellen festlegen. Dafür liefert die Beispieldatenbank im Modul mdlSecurity <\/b>zwei Routinen. Die erste heißt SetPermissions <\/b>und stellt die Berechtigungen für den angegebenen Benutzer beziehungsweise die Benutzergruppe in Bezug auf die Datenbank selbst ein. Die zweite Routine namens SetPermissionsObject <\/b>legt die Berechtigungen des angegebenen Benutzers oder der Benutzergruppe für das im zweiten Parameter festgelegte Objekt fest.<\/p>\n
Der letzte Parameter beider Routinen erwartet die Berechtigungsstufe, die Sie durch die folgenden Konstanten oder einer additiven Kombination derer angeben können:<\/p>\n