Kategorie: Sicherheit

Wir haben in den letzten Wochen einige Datenbanken von Kunden untersucht und erhebliche Mängel bei der Sicherheit der Daten festgestellt. Primär haben wir uns angeschaut, ob ein Mitarbeiter ohne Weiteres auf die in der Datenbank gespeicherten Daten zugreifen kann. In den meisten Fällen konnte er sich einfach die Backend-Datenbank kopieren und so in den Besitz wichtiger Daten des Unternehmens gelangen. Oft war zumindest das Backend durch ein Kennwort geschützt, sodass man nur über das Frontend auf die Daten zugreifen kann. Ob das sicher ist, schauen wir uns im vorliegenden Beitrag an. Um es vorwegzunehmen: Es ist nicht sicher.

Access-Datenbanken, die man als .accdb bereitstellt, können dem Benutzer immer noch Elemente eröffnen, mit denen dieser auf Bereiche zugreift, die er eigentlich nicht sehen soll. Wir sprechen dabei vor allem vom Navigationsbereich oder von den eingebauten Ribbon-Befehlen, mit denen Elemente in der Entwurfsansicht angezeigt oder sogar bearbeitet werden können. Durch die Umwandlung in eine .accde-Datenbank lässt sich zumindest die Bearbeitung von Formularen, Berichten und VBA-Code verhindern. An die übrigen Elemente kommt der Benutzer aber dennoch heran. Dieser Beitrag zeigt, wie wir für den Benutzer noch einige Möglichkeiten dieser Art sperren können – und wie wir die größtmögliche Sicherheit erreichen.

Das Signieren von VBA-Projekten ist ein 2024 erneut eingeführter Sicherheitsprozess, bei dem wir ein VBA-Projekt mit einem digitalen Zertifikat versehen. Dieses Zertifikat bestätigt, dass der Code von uns stammt und seit der Signierung nicht verändert wurde. Das Signieren ist besonders wichtig, wenn VBA-Makros in sensiblen oder gemeinsam genutzten Umgebungen ausgeführt werden, zum Beispiel in Unternehmensnetzwerken. In diesem Beitrag schauen wir uns an, welche Arten von Zertifikaten es gibt, wie diese funktionieren und wie wir ein VBA-Projekt mit einer digitalen Zertifikat versehen können. Außerdem betrachten wir, ob das signieren mit einem Zertifikat überhaupt sinnvoll ist.

In Ausgabe 3/2019 haben wir einige Elemente vorgestellt, die den Zugriff auf die Daten einer Datenbank einschränken sollen – zum Beispiel eine einfache Benutzerverwaltung und die Möglichkeit, den Zugriff auf Tabellen per Datenmakro einzuschränken. Im vorliegenden Beitrag wollen wir zeigen, wie Sie diese Techniken abrunden und den direkten Zugriff des Benutzers auf die Tabellen der Datenbank endgültig verhindern. Dazu exportieren wir diese in eine Backend-Datenbank, auf die wir diesmal nicht wie gewohnt per Verknüpfung zugreifen – sondern ausschließlich per VBA. Das hat den Vorteil, dass wir das Backend mit einem Kennwort versehen können, das nur im Code des Frontends zum Einsatz kommt – und diesen können wir durch Umwandlung in eine .mde- beziehungsweise .accde-Datenbank vor den Augen des Benutzers verbergen.

Wenn Sie in einer Access-Anwendung Benutzer verwalten wollen, die sich per Benutzername und Kennwort an die Anwendung anmelden, sollten Sie sehr sensibel mit den in der Anwendung gespeicherten Kennwörtern umgehen. Das geht am einfachsten, wenn Sie die Kennwörter nur verschlüsselt speichern. Damit verringern Sie die Wahrscheinlichkeit, dass jemand die Kennwörter entschlüsselt und für seine Zwecke nutzen kann, erheblich. Dieser Artikel stellt eine kleine Benutzerverwaltung vor, mit der Sie Benutzer und Benutzergruppen verwalten und auch Berechtigungen für verschiedene Tabellen vergeben können.

Im Beitrag „Benutzerverwaltung mit verschlüsselten Kennwörtern“ stellen wir eine Lösung vor, in der wir die Berechtigungen von Benutzergruppen an Datenbankobjekten definieren. Dort benötigen wir ein Formular, mit dem wir die Berechtigungen für die einzelnen Objekte für die jeweilige Benutzergruppe definieren wollen. Dazu wollen wir eine Matrix anzeigen, welche die Berechtigungen und die Objekte als Spalten- und Zeilenüberschriften anzeigt und die Möglichkeit bietet, in den Zellen anzugeben, ob die Berechtigung gesetzt ist oder nicht. Dies erledigen wir mit einem Webbrowser-Steuerelement, indem wir die notwendigen Elemente per HTML darstellen.

In den Beiträgen „Benutzerverwaltung mit verschlüsselten Kennwörtern“ und „Berechtigungen per HTML verwalten“ haben wir die Voraussetzungen für eine Benutzerverwaltung geschaffen. Im vorliegenden Beitrag bauen wir darauf auf und legen ein Anmeldeformular an, mit dem der Benutzer sich an der Anwendung anmelden kann. Außerdem stellen wir die Funktion vor, mit der wir aus den Tabellen zur Verwaltung der Berechtigungen aufgrund des Benutzernamens die Berechtigung an einer bestimmten Tabelle ermitteln.

Es gibt verschiedene Möglichkeiten, auf Basis des aktuell angemeldeten Benutzers sicherzustellen, dass dieser nur die für ihn vorgesehenen Aktionen mit Daten durchführen darf – beispielsweise durch eine Prüfung in den Ereignisprozeduren, die durch Ereignisse wie „Vor Aktualisierung“ ausgelöst werden. Noch praktischer wäre es allerdings, wenn diese Prüfung nicht in jedem Formular programmiert werden müsste, sondern anwendungsweit verfügbar wäre – also auch dann, wenn der Benutzer es schafft, ohne Formulare auf die Tabellen mit den Daten zuzugreifen. Das gelingt mit Datenmakros. Wie genau, zeigt der vorliegende Beitrag.

Für den einen oder anderen Zweck möchten Sie vielleicht Kennwörter generieren oder in einer Benutzeroberfläche die Möglichkeit zum Generieren von Kennwörtern anbieten. Wenn Sie etwa Benutzer zu einer Benutzerverwaltung hinzufügen, sollten Sie ein initiales Kennwort definieren, dass der Benutzer dann bei der ersten Anmeldung ändert. Das Generieren von Kennwörtern wird allerdings umso komplizierter, je mehr Anforderungen es gibt. Einfach nur ein paar Zeichen zufällig auszuwählen ist noch einfach, aber wenn es Bedingungen gibt, wie sie in sensiblen Umgebungen vorherrschen, soll ein Kennwort beispielsweise mindestens einen Kleinbuchstaben, einen Großbuchstaben, eine Zahl und ein Sonderzeichen enthalten. Diese Anforderungen wollen wir in der hier vorgestellten Funktion natürlich auch unterstützen.

Dass Access nicht den größtmöglichen Schutz für Ihre Daten bietet, ist allgemein bekannt. Diesen erhalten Sie bestenfalls, wenn Sie den SQL Server oder Ähnliches als Datenbank-Backend verwenden und von Access aus darauf zugreifen. Nun sind aber nicht alle Benutzer darauf aus, Ihre Daten auszuspähen. Dennoch möchten Sie vielleicht sicherstellen, dass der Benutzer nicht alle Elemente der Datenbank überblicken darf – geschweige denn, auf diese zugreifen. Dieser Beitrag zeigt die grundlegenden Maßnahmen für einen Schutz und offenbart ein interessantes Problem, das erst mit Access 2013 eingeführt wurde.