Wenn Sie ein Abonnement des Magazins 'Access im Unternehmen' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.
Sicherer RDBMS-Zugriff
Wenn Sie Verknüpfungen auf die Tabellen oder Daten etwa einer SQL Server- oder MySQL-Datenbank anlegen, haben Sie zwei Möglichkeiten: Entweder Sie speichern die Verknüpfung ohne Kennwort und geben Sie diese beim ersten Zugriff einer Sitzung jeweils erneut ein. Oder Sie speichern die Benutzerdaten im Klartext in der Datenbank. Das eine ist aufwendig, das andere unsicher. Dieser Beitrag zeigt einen Weg auf, wie Sie komfortabel und sicher auf die Daten Ihrer Backend-Datenbank zugreifen. Voraussetzung ist, dass Sie das Frontend in eine .mde- beziehungsweise .accde-Anwendung umwandeln.
In den beiden Beiträgen RDBMS-Tabellen manuell verknüpfen (www.access-im-unternehmen.de/973) und RDBMS-Tabellen per VBA verknüpfen (www.access-im-unternehmen.de/974) haben wir uns verschiedene Methoden angesehen, wie Sie die Tabellen einer Datenbank, die von einem relationalen Datenbankmanagementsystem verwaltet wird, in eine Access-Datenbank einbinden und so auf die enthaltenen Daten zugreifen können.
Die dort vorgestellten Techniken haben allerdings den Nachteil, dass der Benutzer entweder für jede neue Sitzung die Benutzerdaten neu eingeben oder aber diese unverschlüsselt in der Systemtabelle MSysObjects speichern muss (dies gilt natürlich nicht für die Windows-Authentifizierung, die Sie allerdings nur mit dem Microsoft SQL Server nutzen können – für diesen Fall benötigen Sie die hier vorgestellten Techniken nicht).
Grundsätzlich ist anzumerken, dass ein Frontend, das die Benutzerdaten für das RDBMS-Backend speichert, nur dann sicher ist, wenn sich der Benutzer immer vom Rechner, auf dem sich das Frontend befindet, abmeldet und diesen nicht unbeaufsichtigt lässt, wenn er eingeloggt ist.
Außerdem muss natürlich sichergestellt sein, dass der Zugriff auf die entsprechende Access-Datei nur dann möglich ist, wenn der Benutzer sich an dem Rechner angemeldet hat.
Konzept für ein sicheres Speichern der Benutzerdaten
Wie aber wollen wir die Benutzerdaten überhaupt sicher in der Frontend-Datenbank speichern? Dazu nutzen wir eine zweistufige Sicherung. Die erste besagt, dass die Datenbank als .mde- oder .accde-Datenbank gesichert sein muss.
Die zweite legt fest, dass die zu sichernden Daten, in diesem Fall der Benutzername und insbesondere das Kennwort, in verschlüsselter Form gespeichert werden sollen.
Das wäre grundsätzlich der Fall, wenn Benutzername und Kennwort im Quellcode fest codiert werden und die Datenbank als .mde oder .accde gesichert wird. Allerdings ist es wenig sinnvoll, Daten wie diese fest im Code zu verdrahten, da sich diese von Zeit zu Zeit ändern könnten.
Wie also können wir solche Daten sicher in der Datenbank speichern und dem Benutzer dennoch die Möglichkeit geben, diese nach Wunsch zu ändern?
Das ist kein Problem: Wozu gibt es schließlich die Algorithmen zum Ver- und Entschlüsseln von Daten? Also bauen wir einfach entsprechende Routinen in die Datenbank ein, die Benutzername und Kennwort nach der erstmaligen Eingabe beziehungsweise Änderung verschlüsseln und so in einer Tabelle der Datenbank speichern. Bei der Anmeldung an das RDBMS soll die Anwendung die Daten dann wieder entschlüsseln und für die Anmeldung nutzen.
Dabei darf man natürlich nicht außer Acht lassen, dass es durchaus Dienstleister im Internet gibt, die das Entschlüsseln von .mde-Datenbanken anbieten.
Alle Tabellen neu verknüpfen?
Die sichere Speicherung der Benutzerdaten erfordert, dass die Verknüpfung der Tabellen mit jeder neuen Sitzung neu erstellt werden muss. Sonst würden diese doch nicht unter Angabe der aktuellen Benutzerdaten geöffnet werden, oder?
Dies könnte man annehmen, aber es ist anders: Wenn Sie eine einzige Tabelle dieser Datenbank neu verknüpfen, dann sind auch alle anderen Tabellen, für welche die gleichen Verbindungsdaten (also Server, Datenbank und Port) angegeben sind und für die die gleichen Benutzerdaten gelten, verfügbar.
Genau genommen brauchen Sie noch nicht einmal eine Tabelle der RDBMS-Datenbank zu öffnen. Es reicht aus, wenn Sie innerhalb der aktuellen Sitzung eine DAO-Verbindung zu dieser Datenbank aufbauen. Sie brauchen diese auch nicht in einer entsprechenden Variablen aufzubewahren!
Also werden wir mit den nachfolgend beschriebenen Techniken schlicht und einfach einmalig eine Verbindung zur Quelldatenbank herstellen.
Ein denkbarer Fall, bei dem dies nicht ausreichen könnte, liegt vor, wenn das Frontend mit Tabellen aus verschiedenen RDBMS verknüpft ist. Merkt sich Access dann tatsächlich die Verbindungen zu verschiedenen RDBMS oder nur die zuletzt hergestellte Verbindung?
Wie ein Text mit verknüpften Tabellen von verschiedenen Servern zeigt, ist Access hier durchaus flexibel: Wir haben die Verbindung zu beiden RDBMS aufgebaut und konnten die Tabellen, für die wir in einer vorherigen Sitzung entsprechende Verknüpfungen erstellt haben, ohne erneute Anforderung der Benutzerdaten öffnen.
Im Rahmen des vorliegenden Beitrags wollen wir die Lösung jedoch nicht unnötig kompliziert machen, da die meisten Frontends ihre Daten wohl nur aus einem einzigen RDBMS beziehen dürften.
Ablauf
Sobald die Benutzerdaten einmal in der dafür vorgesehenen Tabelle gespeichert sind, soll die Datenbankanwendung beim Öffnen einmalig die Verbindung zur angegebenen Tabelle herstellen.
Gelingt diese Verbindung nicht, soll ein Formular zur Eingabe der Benutzerdaten geöffnet werden. Mit diesem kann der Benutzer dann Benutzername und Kennwort eingeben. Nach der Eingabe entscheidet er dann, ob die Daten nur in der dafür vorgesehenen Tabelle gespeichert werden sollen oder ob die Verbindung auch neu hergestellt werden soll.
Formular zur Eingabe der Benutzerdaten
Das Formular zur Eingabe der Benutzerdaten soll frmBenutzerdaten heißen. Es enthält zwei Textfelder und drei Schaltflächen.
Die beiden Textfelder statten Sie mit den Namen txtBenutzername und txtKennwort aus. Die drei Schaltflächen sollen cmdSpeichern, cmdSpeichernUndVerknuepfen und cmdSchliessen heißen. Die Steuerelemente ordnen Sie etwa wie in Bild 1 an.
Damit das Formular wie ein reiner Dialog aussieht, stellen Sie die Eigenschaften Navigationsschaltflächen, Datensatzmarkierer, Trennlinien und Bildlaufleisten auf den Wert Nein ein. Außerdem soll das Formular in der Mitte des Access-Fensters erscheinen, daher stellen Sie die Eigenschaft Automatisch zentrieren auf den Wert Ja ein.
Damit andere Personen das Kennwort bei der Eingabe nicht ablesen können, passen wir das Textfeld txtKennwort noch so an, dass es statt des eingegebenen Textes ausschließlich das Sternchen-Zeichen anzeigt (*).
Dazu klicken Sie einmalig in die Eigenschaft Daten|Eingabeformat des Eigenschaftsfensters und dann auf die nun erscheinende Schaltfläche mit den drei Punkten rechts neben der Eigenschaft.
Dies öffnet den Dialog aus Bild 2.
Nachdem Sie hier den Eintrag Kennwort ausgewählt haben, können Sie direkt auf die Schaltfläche Fertigstellen klicken. Beim Öffnen des Formulars frmBenutzerdaten ersetzt dieses eingegebene Zeichen für das Kennwort durch das Sternchen (s. Bild 3).
Nun schauen wir uns die Prozeduren an, die durch die verschiedenen Schaltflächen ausgelöst werden.
Die einfachste schließt einfach das Formular:
Private Sub cmdSchliessen_Click()
DoCmd.Close acForm, Me.Name
End Sub
Interessanter ist schon die Schaltfläche, mit der wir die Benutzerdaten in der Tabelle tblBenutzerdaten speichern wollen.
Diese enthält nur eine einzige Anweisung, die aber eine weitere Routine namens BenutzerdatenSpeichern aufruft und dabei den Benutzernamen und das Kennwort aus den beiden Textfeldern übergibt:
Private Sub cmdSpeichern_Click()
BenutzerdatenSpeichern Nz(Me!txtBenutzername), _
Nz(Me!txtKennwort)
End Sub
Die letzte Prozedur des Formulars speichert zuerst die Benutzerdaten und aktualisiert dann mit einem Aufruf der Routine VerknuepfungenAktualisierenVerschluesselt die Verbindung:
Private Sub cmdVerknuepfen_Click()
BenutzerdatenSpeichern Nz(Me!txtBenutzername), _
Nz(Me!txtKennwort)
If VerknuepfungenAktualisierenVerschluesselt Then
MsgBox "Verknüpfung erfolgreich."
End If
End Sub
Tabelle zum Speichern der Benutzerdaten
Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.