<\/p>\n
Schützen Sie Ihre Daten vor unerlaubtem Zugriff Wenn Sie es nicht tun, gibt es dafür bestimmt Gründe. Nur sind es mit hoher Wahrscheinlichkeit keine guten Gründe. Nicht selten liegt es an fehlendem Fachwissen oder einer falschen Einschätzung der Daten oder es ist schlicht und ergreifend Bequemlichkeit. Die Sache mit der Bequemlichkeit sollten Sie selbst hinterfragen, das Fachwissen vermittelt Ihnen dieser wie die noch folgenden Artikel der Serie „Access und SQL Server-Security“.<\/b><\/p>\n
„Die Daten dieser Datenbank sind nicht wichtig.“ Diese Aussage basiert meist auf einer falschen Einschätzung der Daten. Es gibt in Unternehmen keine unwichtigen Daten. Es mag zwar Daten geben, die nicht unternehmenskritisch sind, aber unwichtige Daten Hand aufs Herz, haben Sie Zeit oder gar Budget für unwichtige Daten In der Regel sind alle Daten eines Unternehmens relevant und somit auch vor fremden Zugriff zu schützen. Dies hat inzwischen auch der Gesetzgeber verstanden. In den letzten Jahren sind verschiedene Gesetze in Kraft getreten, die entsprechende Zugriffskontrollen einfordern, sei es der Datenschutz nach der DSGVO und dem neuen BDSG oder das IT-Sicherheitsgesetz. <\/p>\n
Es ist schon erstaunlich, dass es Gesetze braucht, um Unternehmen darauf hinzuweisen, dass ihre Daten und somit ihr Wissen schützenswert sind. Ob nun Produktionspläne, Forschungsergebnisse, Rezepturen, Patente, erfolgreiche Marketingaktionen, Kundenanalysen, Forecasts etc., bei all diesen Informationen handelt es sich um Wissen – relevantes Wissen für den täglichen Betrieb und zur Sicherung des Wettbewerbsvorteils eines Unternehmens.<\/p>\n
Gelangen diese Daten in falsche Hände, stellt dies in vielen Fällen ein indirektes oder gar direktes Risiko für das Unternehmen dar. Deshalb sollte jeder im Unternehmen, vom Geschäftsführer bis zum Angestellten, darauf achten, wer zu welchem Zweck Zugriff auf die Unternehmensdaten hat.<\/p>\n
Zugriffsschutz in Access<\/b><\/p>\n
Es sieht dürftig aus. Access bietet als Zugriffsschutz lediglich das Datenbank-Kennwort. Zwar gibt es immer noch die Möglichkeit einer MDW-Datei, doch funktioniert diese nur mit dem veralteten Datenbankformat MDB.<\/p>\n
Das Datenbank-Kennwort verschlüsselt die Access-Datenbank. Dabei ist es empfehlenswert, ein Kennwort zu verwenden, das aus Buchstaben, Zahlen und Sonderzeichen besteht und mindestens zehn Zeichen lang ist. <\/p>\n
Es sollte aber auch nicht länger als 19 Zeichen sein, wenn es sich bei der Datenbank um ein Backend handelt, deren Tabellen in ein Access-Frontend eingebunden werden. Zwar akzeptiert das Backend durchaus mehr als 19 Zeichen, jedoch wird ein solches Kennwort beim Einbinden der Tabellen in das Frontend mit der Meldung Kein zulässiges Kennwort<\/b> quittiert.<\/p>\n
Dem Datenbank-Kennwort wird nachgesagt, es sei einfach zu knacken. Das ist seit dem Wechsel von MDB nach ACCDB ab Access 2007 nicht mehr der Fall. Um das Kennwort zu ermitteln, bedarf es schon guter Crack-Tools mit der Möglichkeit von Brute-Force-Angriffen. Je länger und komplexer ein Kennwort, umso höher ist der Aufwand für einen solchen Angriff. <\/p>\n
Das Datenbank-Kennwort bietet also durchaus einen Zugriffsschutz. Dieser ist abhängig von der Länge und der Komplexität des Kennworts.<\/p>\n
Doch genug der Theorie. Jetzt wird die Backend-Datenbank der Beispiel-Applikation WaWi <\/b>verschlüsselt. Dazu öffnen Sie das Access-Backend WaWi_BE.accdb <\/b>exklusiv (siehe Bild 1).<\/p>\n
<\/p>\n
Bild 1: Exklusives Öffnen einer Datenbank<\/span><\/b><\/p>\n Hier wechseln Sie zum Menüpunkt Datei <\/b>und klicken auf Informationen<\/b>. Dort sehen Sie die Schaltfläche Mit Kennwort verschlüsseln <\/b>(siehe Bild 2).<\/p>\n Bild 2: Verschlüsseln einer Datenbank mit einem Kennwort<\/span><\/b><\/p>\n Ein Klick auf diese Schaltfläche liefert Ihnen einen Dialog (siehe Bild 3), in dem Sie im ersten Eingabefeld Ihr Kennwort eingeben und dies mit einer erneuten Eingabe im zweiten Eingabefeld bestätigen.<\/p>\n Bild 3: Festlegen des Kennworts<\/span><\/b><\/p>\n Ihr Kennwort sollte den oben genannten Empfehlungen entsprechen. Um bei diesem und den folgenden Beispielen nicht immer mühsam ein komplexes Kennwort einzugeben, tragen Sie als Kennwort den Begriff unsicher<\/b> ein. Danach erhalten Sie die Meldung aus Bild 4, die Sie darauf hinweist, dass eine Sperrung auf Datensatzebene mit der Verschlüsselung nicht kompatibel ist. Sollte eine Sperrung auf Datensatzebene für Sie unabdingbar sein, können Sie die Verschlüsselung nicht nutzen. Bestätigen Sie die Meldung, wird die Sperrung auf Datensatzebene in Zukunft ignoriert.<\/p>\n Bild 4: Hinweise zum Verschlüsseln<\/span><\/b><\/p>\n Soweit so gut – die Access-Datenbank ist nun verschlüsselt. Ab jetzt müssen Sie dieses Kennwort immer eingeben, wenn Sie die Datenbank öffnen. Testen Sie es einmal. Schließen Sie die Datenbank und öffnen Sie sie direkt wieder. Ohne Kennworteingabe ist der Zugriff auf die Daten nicht mehr möglich.<\/p>\n Dies gilt auch für das Access-Frontend, mit dem die Daten der nun verschlüsselten Datenbank verarbeitet werden. Die Daten stehen im Frontend nur nach Eingabe des Kennworts zur Verfügung. <\/p>\n Es gibt eine gute Nachricht. Sie müssen das Kennwort nicht jedes Mal eingeben. Der Einfachheit halber lässt sich das Kennwort beim Einbinden der Tabellen angeben und wird ab dann bei jedem Datenzugriff verwendet.<\/p>\n Leider ist der Tabellenverknüpfungs-Manager dabei keine Hilfe. Sie müssen die eingebundenen Tabellen aus dem Frontend entfernen und neu einbinden. <\/p>\n Öffnen Sie also das Frontend der Beispiel-Applikation WaWi <\/b>und entfernen Sie die eingebundenen Tabellen. Anschließend navigieren Sie über Externe Daten|Neue Datenquelle|Aus Datenbank|Access <\/b>zum Dialog Externe Daten<\/b>. Dort wählen Sie über die Schaltfläche Durchsuchen <\/b>die verschlüsselte Access-Datenbank aus und markieren die Option Erstellen Sie eine Verknüpfung zur Datenquelle, indem Sie eine verknüpfte Tabelle erstellen <\/b>(siehe Bild 5).<\/p>\n Bild 5: Erstellen einer Verknüpfung<\/span><\/b><\/p>\n Nach einem Klick auf OK <\/b>werden Sie aufgefordert, das Datenbank-Kennwort einzugeben (siehe Bild 6). Anschließend wählen Sie alle Tabellen aus und binden diese per OK<\/b> ein.<\/p>\n Bild 6: Abfrage des Kennworts<\/span><\/b><\/p>\n Die Eingabe des Kennworts ist eine einmalige Angelegenheit. Sie können dies einfach testen. Schließen Sie das Access-Frontend und öffnen Sie es direkt wieder. Ein Kennwort müssen Sie dabei nicht eingeben, auch nicht beim Öffnen einer Tabelle.<\/p>\n Allerdings ist das Kennwort für den Datenzugriff erforderlich. Es muss also in irgendeiner Art und Weise hinterlegt sein. Doch wo ist das Kennwort gespeichert<\/p>\n Um das herauszufinden, öffnen Sie mit der Tastenkombination Strg + G den Direktbereich im VBA-Editor. Hier führen Sie folgende Anweisung aus:<\/p>\n Der Direktbereich zeigt Ihnen die Connect<\/b>-Eigenschaft der eingebundenen Tabelle. Schon an zweiter Position ist das Kennwort zu sehen (siehe Bild 7). Es ist also kein Hexenwerk, das Datenbank-Kennwort einer verschlüsselten Datenbank zu ermitteln. <\/p>\n Bild 7: Kennwort ermitteln per Direktbereich<\/span><\/b><\/p>\n Das Auslesen des Kennworts lässt sich vermeiden, indem Sie auch das Access-Frontend verschlüsseln. Also öffnen Sie das Access-Frontend exklusiv, wechseln über das Menü Datei <\/b>zu Informationen <\/b>und klicken dort auf die Schaltfläche Mit Kennwort verschlüsseln<\/b>. <\/p>\n Als Kennwort geben Sie natürlich nicht das gleiche wie beim Backend an. Verwenden Sie ein anderes sicheres Kennwort, das beim Frontend auch mehr als 19 Zeichen haben darf. Für dieses Beispiel kann es gerne wieder etwas Einfaches sein. Wie wäre es mit dem Kennwort sicher<\/b> <\/p>\n Es folgt der bereits bekannte Hinweis, dass die Datensatzsperre in Zukunft ignoriert wird. Mit Bestätigen dieser Meldung ist nun auch das Frontend verschlüsselt. Dies können Sie testen, indem Sie das Frontend schließen und es direkt wieder öffnen. Als erstes wird von Ihnen die Eingabe des Kennworts verlangt.<\/p>\n Erst nach der Kennworteingabe lässt das Frontend den Zugriff auf das Startformular, die Access-Objekte und die eingebundenen Tabellen zu. Dieses Kennwort müssen Sie ab jetzt bei jedem Start des Frontends angeben. Aber nicht nur Sie, sondern jeder Anwender, der mit dieser Access-Applikation arbeitet. <\/p>\n Aus diesem Grund ist es wichtig, Frontend und Backend der Access-Applikation mit unterschiedlichen Kennwörtern zu verschlüsseln. Andernfalls wäre es für den Anwender recht einfach, das Access-Backend zu öffnen. Er muss dort nur das ihm bekannte Kennwort vom Frontend eingeben.<\/p>\n Ein sicheres Kennwort <\/b><\/p>\n Das von Ihnen gewählte Datenbank-Kennwort sollte den oben angeführten Regeln entsprechen. Allerdings muss es sich der Anwender auch merken können. Genau hier beginnt das Dilemma. Wer kann sich schon an ein komplexes Kennwort erinnern Die Lösung ist nicht selten eine Notiz am Bildschirm oder unter der Tastatur.<\/p>\n Dabei ist die Vergabe eines komplexen Kennworts recht einfach. Denken Sie sich einen Satz mit einer Zahl aus und nehmen Sie davon die Anfangsbuchstaben und die Satzzeichen. Fertig ist das sichere Kennwort. <\/p>\n Der Anwender merkt sich einen Satz wie Seit 2020 ist die Auftragsverarbeitung mit einem Kennwort geschützt!<\/b> und gibt als Kennwort S2020idAmeKg!<\/b> ein. Natürlich verwenden Sie bitte nicht dieses Beispiel als Ihr Kennwort. Denken Sie sich einen Satz aus, mit dem die Anwender etwas anfangen können. <\/p>\n Nimmt man es ganz genau, besitzt ein solch erstelltes Kennwort zwar einen hohen Sicherheitsgrad, es gilt dennoch als unsicher. Ein sicheres Kennwort ergibt sich aus der Zufälligkeit. Es sollte weder etwas mit der Applikation noch mit den Benutzern noch mit irgendetwas zu tun haben. Sichere Kennwörter erstellen Sie am besten mit einem Password-Generator. <\/p>\n <\/p>\n Ein generiertes Kennwort kann sich aber kein Mensch merken. Schon sind Sie wieder beim oben beschriebenen Dilemma und das Kennwort landet früher oder später als Notiz auf einem Zettel. So wird auch das sicherste Kennwort untauglich, ist es doch leicht zugänglich für jedermann.<\/p>\n Dann doch lieber ein Kennwort, das bereits einen hohen Sicherheitsgrad aufweist und das sich die Anwender merken können. <\/p>\n Auch sichere Kennwörter sollten Sie in regelmäßigen Abständen ändern. Kennt ein Unbefugter das Kennwort, darf er sich nach der Änderung erneut die Mühe machen, an das Kennwort heranzukommen.<\/p>\n Access-Funktionen unterbinden<\/b><\/p>\n Nach Eingabe des Datenbank-Kennworts stehen dem Anwender alle ihm erlaubten Access-Funktionen zur Verfügung. Er kann zum Beispiel den VBA-Editor öffnen und dort mittels der Connect<\/b>-Eigenschaft einer Tabelle das Kennwort des Access-Backends auslesen.<\/p>\n Aus diesem Grund darf der Zugriff auf den VBA-Editor nicht ohne weiteres möglich sein. Um dies zu erreichen, ersetzen Sie die Standard-Ribbons mit eigenen Ribbons und blenden über die Access-Optionen den Navigationsbereich aus (siehe Bild 8). Diese beiden Aktionen verbergen allerdings nur die Möglichkeiten zum Öffnen des VBA-Editors. Mit der Tastenkombination Alt + F11 <\/b>lässt er sich weiterhin öffnen.<\/p>\n Bild 8: Navigationsbereich ausblenden<\/span><\/b><\/p>\n Kennwort für VBA<\/b><\/p>\n Als weitere Maßnahme schützen Sie das VBA-Projekt mit einem Kennwort. Dieses Kennwort müssen Sie dann jedes Mal eingeben, wenn Sie Ihren VBA-Quellcode lesen oder ändern möchten. <\/p>\n Dazu wechseln Sie zum VBA-Editor und wählen im Menü Extras <\/b>den Eintrag Eigenschaften von<\/b>. In dem folgenden Dialog gehen Sie zur Registerkarte Schutz<\/b>, aktivieren die Option Projekt für die Anzeige sperren <\/b>und geben ein neues sicheres Kennwort in die beiden Eingabefelder ein (siehe Bild 9). <\/p>\n Bild 9: Schützen des VBA-Projekts<\/span><\/b><\/p>\n Bestätigen Sie die Eingabe mit OK<\/b> und schließen Sie Access. Öffnen Sie die Access-Datenbank wieder und wechseln Sie nach Eingabe des Datenbank-Kennworts zum VBA-Editor. Jetzt wird das Kennwort zum Schutz des VBA-Projekts abgefragt. Erst nach der Eingabe sehen Sie den VBA-Quellcode.<\/p>\n Sicher ist der Kennwortschutz des VBA-Projekts jedoch nur in Verbindung mit einem Datenbank-Kennwort. Durch das Datenbank-Kennwort ist der komplette Inhalt der Access-Datenbank verschlüsselt. <\/p>\n Bei einer unverschlüsselten Datenbank lässt sich das VBA-Kennwort recht einfach aushebeln. Dazu öffnen Sie die Access-Datenbank in einem Hex-Editor, suchen dort nach DPB<\/b> und ersetzen B<\/b> mit einem x-beliebigen Buchstaben. Speichern Sie die Änderung und schließen Sie den Hex-Editor. Danach öffnen Sie die Access-Datenbank regulär mit Access.<\/p>\n Beim Öffnen erhalten Sie eine Fehlermeldung, die Sie mit Ja <\/b>bestätigen. Jetzt wechseln Sie zum VBA-Editor. Sie erhalten einige Fehlermeldungen, die Sie alle mit OK <\/b>wegklicken. Anschließend vergeben Sie über den herkömmlichen Weg ein neues VBA-Kennwort. Danach steht Ihnen der Quellcode zur Verfügung.<\/p>\n Diese Vorgehensweise ist bei einer verschlüsselten Datenbank nicht möglich. Der Eintrag DBP<\/b> existiert dort nicht als Klartext. Folglich können Sie ihn weder finden noch ändern.<\/p>\n Access-Spezialtasten deaktivieren<\/b><\/p>\n Das Kennwort des VBA-Projekts mag zwar den Zugriffsschutz der Datenbank erhöhen, es verhindert jedoch nicht das Auslesen der Connect<\/b>-Eigenschaft.<\/p>\n Mit der Tastenkombination Strg + G <\/b>lässt sich in Access die Direkteingabe des VBA-Editors öffnen. Das VBA-Kennwort wird dabei nicht abgefragt. Das Auslesen der Connect<\/b>-Eigenschaft ist also weiterhin möglich.<\/p>\n Aus diesem Grund sollten Sie auch die Access-Spezialtasten deaktivieren. Die entsprechende Eigenschaft finden Sie in den Access-Optionen unter Aktuelle Datenbank <\/b>(siehe Bild 10). <\/p>\n Bild 10: Access-Spezialtasten deaktivieren<\/span><\/b><\/p>\n Am besten verhindern Sie gleich noch den Start von Access mit gedrückter Umschalt-Taste. Dies erreichen Sie durch Ausschalten der Datenbankeigenschaft AllowByPassKey<\/b>.<\/p>\n Hierzu erstellen Sie eine VBA-Funktion mit diesen Zeilen:<\/p>\n (Quelle: http:\/\/www.donkarl.comFAQ1.8)<\/p>\n Der folgende Aufruf deaktiviert die Datenbankeigenschaft und verhindert dadurch die Funktion der Umschalt-Taste:<\/p>\n Sie können den Code per Direkteingabe oder mit einer weiteren VBA-Funktion ausführen. Das Ergebnis ist dasselbe. Das Drücken der Umschalt-Taste hat keinerlei Auswirkung beim Start der Access-Applikation.<\/p>\n Das gilt für alle Benutzer. Auch für Sie, weshalb Sie vor dem Neustart von Access noch eine Möglichkeit einbauen sollten, über die sich die Umschalt-Taste wieder aktivieren lässt. Dies kann zum Beispiel eine versteckte Schaltfläche sein, die per Doppelklick die Anweisung EnableShift True<\/b> ausführt.<\/p>\n Die Funktionalität der Umschalt-Taste ist dann wieder aktiv, für Sie und für alle anderen Benutzer. Am besten sperren Sie die Umschalt-Taste immer unmittelbar nachdem Sie den Zugang zu den Access-Spezialtasten und zum Navigationsbereich nicht mehr benötigen.<\/p>\n Wobei das Sperren der Umschalt-Taste eigentlich kein ausreichender Schutz ist, lässt sich die Datenbankeigenschaft AllowByPassKey <\/b>doch leicht von außen ändern. Dazu legen Sie eine neue Access-Datenbank an und erstellen dort ein VBA-Modul mit der Funktion aus Listing 1.<\/p>\n Listing 1: Umschalt-Taste von außen wieder zulassen<\/span><\/b><\/p>\n Die Funktion öffnet per OpenDataBase <\/b>die geschützte Datenbank und ändert den Wert der Eigenschaft AllowByPassKey <\/b>in True<\/b>. Schon ist der Start der Access-Applikation mit gedrückter Umschalt-Taste wieder möglich.<\/p>\n Sie sehen, mit dem Verschlüsseln der Access-Datenbank alleine ist es nicht getan. Es gibt einige Einstellungen zu beachten, die einen unbefugten Zugriff auf das Datenbank-Kennwort und somit auf die Daten erschwert. <\/p>\n Zugriffsschutz innerhalb der Access-Applikation<\/b><\/p>\n Alles in allem bietet das Datenbank-Kennwort einen guten Zugriffsschutz. Dem Anwender wird nur nach Eingabe des korrekten Kennworts der Zugang zu den Daten gestattet. <\/p>\n Danach gibt es für ihn keine Einschränkung mehr. Er hat den vollen Zugriff auf alle Daten. Nun kann es aber durchaus notwendig sein, dass ein Anwender nicht alle Daten der Datenbank sehen oder gar ändern darf. <\/p>\n So auch in der Beispielapplikation WaWi<\/b>. Diese beinhaltet neben einer Auftragserfassung eine kleine Personalverwaltung. Natürlich sollen die Mitarbeiterinnen und Mitarbeiter des Verkaufs die Daten der Personalverwaltung nicht lesen oder gar ändern können.<\/p>\n Es ist somit auch innerhalb der Access-Applikation ein Zugriffsschutz zu erstellen – abhängig von den Anwendern und deren Aufgabengebiet.<\/p>\n Dies wird oft und gerne über eine Formularsteuerung realisiert. Abhängig vom angemeldeten Anwender werden Menüpunkte und Schaltflächen angezeigt oder ausgeblendet. In der Beispielapplikation findet dies im Start-Formular statt. Dort wird im Ereignis Beim Öffnen <\/b>die Funktion fBerechtigungen <\/b>ausgeführt.<\/p>\n Als erstes ermittelt die Funktion das Benutzerkonto des angemeldeten Anwenders. Dazu verwendet sie eine weitere Funktion namens fOSUserName<\/b>. Diese von Dev Ashish entwickelte Funktion kennen Sie vielleicht schon. Sie liefert Ihnen den Namen des verwendeten Benutzerkontos (siehe Bild 11). <\/p>\n Bild 11: Benutzername ermitteln per VBA<\/span><\/b><\/p>\n Dabei müssen Sie beachten, dass Sie die richtige Version verwenden. Es gibt eine Version für die 32-Bit-Variante von Access und eine weitere für die 64-Bit-Variante.<\/p>\n War die 64-Bit-Variante früher eher selten, ist sie bei Installationen über Office365 immer häufiger anzutreffen.<\/p>\n Am besten ersetzen Sie die Zeile<\/p>\n mit dieser Zeile:<\/p>\n Ausschlaggebend hierbei ist das Schlüsselwort PtrSafe<\/b>. Nur mit diesem Schlüsselwort wird die Deklaration in den 64-Bit-Varianten von Office akzeptiert. <\/p>\n Das Schlüsselwort gibt erst seit Access 2010. Möchten Sie den Code auch in einer älteren Version verwenden, sollten Sie beide Varianten berücksichtigen. Dies erreichen Sie mit einer bedingten Kompilierung.<\/p>\n Die Compiler-Konstante VBA7 <\/b>liefert dabei den Wert True<\/b>, wenn es sich um eine 64-Bit-Umgebung handelt. Der Quellcode sieht dann wie folgt aus:<\/p>\n Der Rest der Funktion fBerechtigungen <\/b>ist selbsterklärend. Abhängig vom ermittelten Anwender werden Schaltflächen ein- oder ausgeblendet, der Name der Applikation mit dem Namen des Anwenders ergänzt und die Hintergrundfarbe geändert.<\/p>\n Frau Bienlein als Verkäuferin sieht nach einer erfolgreichen Anmeldung die Access-Applikation wie in Bild 12.<\/p>\n Bild 12: Die Anwendung aus Sicht einer Verkäuferin …<\/span><\/b><\/p>\n Dagegen erhält die Personalchefin Frau Stromberg die Ansicht aus Bild 13. <\/p>\n Bild 13: … und aus Sicht der Personalchefin.<\/span><\/b><\/p>\n Um diese Auswirkungen bei beiden Anwendern zu testen, legen Sie sich die Windows-Benutzer Stromberg <\/b>und Bienlein <\/b>an. Anschließend starten Sie Access als anderer Benutzer. Dazu gibt es mehrere Möglichkeiten. Die einfachste funktioniert über eine Verknüpfung zu Access. <\/p>\n Erstellen Sie auf Ihrem Desktop eine Verknüpfung zur Datei msaccess.exe<\/b>. Danach klicken Sie die Verknüpfung mit der rechten Maustaste und gedrückter Umschalt-Taste an. In dem Kontextmenü wählen Sie Als anderer Benutzer ausführen <\/b>und tragen in dem folgenden Dialog den Benutzernamen und das zugehörige Kennwort ein. <\/p>\n Access wird nun im Kontext des angegebenen Benutzers und somit mit dessen Rechten gestartet. Öffnen Sie in Access das Frontend der Beispieldatenbank und geben Sie das Datenbank-Kennwort ein.<\/p>\n Wiederholen Sie den Vorgang mit dem zweiten Benutzer. Sie sehen nun zwei Access-Applikationen in unterschiedlichen Farben und mit abweichenden Schaltflächen.<\/p>\n Mit der Formularsteuerung und den oben beschriebenen Maßnahmen zum Schutz der Access-Applikation durch Deaktivieren der Access-Spezialtasten, Ausblenden des Navigationsbereichs und Verwenden eigener Ribbons erreichen Sie einen hohen Zugriffsschutz. Man fühlt sich nach all diesem Aufwand doch recht sicher. Wie sicher diese Maßnahmen tatsächlich sind, zeigt der Fall Bienlein.<\/p>\n Der Fall Bienlein<\/b><\/p>\n Aufgrund der geschützten Anwendungsoberfläche und der Formularsteuerung in der Access-Applikation WaWi <\/b>ist es Frau Bienlein nicht möglich, auf die Daten des Personalbereichs zuzugreifen. Dies ist jedoch nur ein vermeintlicher Schutz. <\/p>\n Mit Frau Bienlein arbeitet im Verkauf nicht nur eine gute Verkäuferin, sie ist auch sehr an Access interessiert und hat vor Kurzem aus privatem Interesse einen Access-Kurs besucht. Und da auf Ihrem Arbeitsrechner Access in der Vollversion und nicht als Runtime-Version installiert ist, nutzt Sie Access auch gerne während der Arbeitszeit. <\/p>\n Sie erstellt sich eine neue Datenbank und findet gerade heute den Menüpunkt Externe Daten <\/b>sehr interessant. Neugierig schaut sie sich die Möglichkeiten an und entscheidet sich für den Eintrag Aus Datenbanken <\/b>und dort wiederum für den Eintrag Access<\/b>.<\/p>\n Nach einem Klick auf Durchsuchen <\/b>navigiert sie etwas ziellos auf den standardmäßig verbundenen Netzwerk-Laufwerken umher, bis sie eine Datenbank namens WaWi_BE <\/b>findet. Das kommt ihr bekannt vor, ist der Name doch ähnlich der Auftragsverwaltung, mit der sie jeden Tag arbeitet.<\/p>\n Also wählt sie die Datenbank aus und da sie sich unter der Option Erstellen Sie eine Verknüpfung zur Datenquelle, indem Sie eine verknüpfte Tabelle erstellen <\/b>nun rein gar nichts vorstellen kann, aktiviert sie diese und klickt erwartungsvoll auf OK<\/b>.<\/p>\n Jetzt wird es für Frau Bienlein spannend. Sie muss ein Datenbank-Kennwort eingeben. Als erstes tippt sie das Kennwort ein, das Sie täglich bei der Auftragsverwaltung eingibt. Mit Erfolg, denn der Programmierer der Access-Applikation hat sich nicht die Mühe gemacht, für die Verschlüsselung des Frontends und des Backends unterschiedliche Kennwörter zu verwenden.<\/p>\n Frau Bienlein sieht alle Tabellen der Backend-Datenbank und ist dabei sehr interessiert an der Tabelle Mitarbeiter<\/b>. Sie markiert die Tabelle, klickt auf OK <\/b>und findet die Tabelle im Navigationsfenster wieder. Nach einem Doppelklick auf die eingebundene Tabelle schaut sich erst einmal unsicher um.<\/p>\n Nicht das jemand bemerkt, was sie da treibt! Schließlich sieht sie gerade die Daten aller Mitarbeiter inklusive der Gehälter. Ob man sich da vielleicht eine kleine Gehaltserhöhung verschaffen kann Frau Bienlein ändert ihr Gehalt von 2.500 Euro auf 2.550 Euro. <\/p>\n Natürlich ist der Fall konstruiert. In der Realität fällt eine solche Gehaltserhöhung bei der ersten Abrechnung auf – hoffentlich. Was aber, wenn die eigentliche Gehaltsabrechnung ein externer Dienstleister übernimmt, auf Basis übermittelter Daten, die aus der Tabelle Mitarbeiter <\/b>stammen<\/p>\n Es gibt für Frau Bienlein auch andere und weniger auffällige Möglichkeiten. Für einen weiteren Nebenverdienst benötigt sie zunächst einen imaginären Lieferanten. Also gibt sie in der Tabelle Lieferanten <\/b>einen neuen Lieferanten ein, mitsamt Bankverbindung zum Ausgleich der Eingangsrechnungen. Das angegebene Konto kommt ihr dabei natürlich zugute. Anschließend erfasst sie in unregelmäßigen Abständen Bestellungen und zugehörige Eingangsrechnungen, immer schön unterhalb der Budgetfreigabe-Grenze.<\/p>\n Den Rest erledigt die Buchhaltung bei ihrem monatlichen Zahlungslauf. Dieser Fall ist nicht erfunden. Solch illegalen Nebenverdienste wurden bereits in einigen Unternehmen aufgedeckt. <\/p>\n In beiden Fällen hat es Frau Bienlein recht einfach. Zum Schutz der Applikation wurde das gleiche Datenbank-Kennwort für Frontend und Backend verwendet. Aber auch bei unterschiedlichen Kennwörtern wäre sie in der Lage, die Daten direkt in den Access-Tabellen zu ändern. Mit etwas Aufwand könnte sie das Kennwort des Access-Backends ermitteln. Sie müsste dazu nur die erwähnten Schwachstellen ausnutzen.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Eine Formularsteuerung wie auch die beschriebenen Absicherungen der Anwenderoberfläche gelten nur im jeweiligen Frontend. Sie verhindern nicht den direkten Zugriff auf die Daten des Backends, ob nun per Access oder mit einer anderen Anwendung.<\/p>\n Es wird eine detailliertere und konkretere Zugriffssteuerung benötigt – und diese sollte direkt an den Tabellen festgelegt sein. Nur so lässt sich eine Umgehung der im Frontend definierten Zugriffsrechte vermeiden. Leider gibt es in Access diese Art der Zugriffssteuerung nicht.<\/p>\n SQL Server bietet im Bereich Zugriffssteuerung und Sicherheit im Allgemeinen weitaus mehr Möglichkeiten. Jedoch kann man sich auch hier schnell in einer vermeintlichen Sicherheit wähnen.<\/p>\n Dieser Artikel ist der Start einer Reihe zum Thema Access und SQL Server-Security<\/b>. In den nächsten Kapiteln lesen Sie, welchen Sicherheitsgrad Sie mit den Security-Möglichkeiten von SQL Server erreichen können und ob diese Frau Bienlein aufhalten.<\/p>\n Enthaltene Beispieldateien:<\/p>\n WaWi.accdb<\/p>\n WaWi_BE.accdb<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
CurrentDb.TableDefs(\"Ansprechpartner\").Connect<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Sub <\/span>EnableShift(blnFlag As Boolean<\/span>)\r\n On Error GoTo<\/span> Error_EnableShift\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>prp As <\/span>DAO.Property\r\n Set<\/span> db = CurrentDb\r\n 'Property mit übergebenem Parameter belegen\r\n db.Properties!AllowBypassKey = blnFlag\r\nExit_EnableShift:\r\n Set<\/span> prp = Nothing\r\n Exit Sub<\/span>\r\nError_EnableShift:\r\n 'Property erzeugen, falls noch nicht vorhanden\r\n If <\/span>Err = 3270 Then<\/span>\r\n Set<\/span> prp = db.CreateProperty(\"AllowBypassKey\", dbBoolean, blnFlag)\r\n db.Properties.Append prp\r\n Resume Next<\/span>\r\n Else<\/span>\r\n MsgBox<\/span> \"Ausnahme Nr. \" & Str(Err.Number) & \" \" & Err.Description\r\n Resume Exit_EnableShift\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nEnableShift False<\/span><\/pre>\nPrivate Sub <\/span>sAllowByPassKey()\r\n Dim <\/span>wrkAcc As <\/span>Workspace\r\n Dim <\/span>dbsWawi As <\/span>DAO.Database\r\n Set<\/span> wrkAcc = CreateWorkspace(\"\", \"admin\", \"\", dbUseJet)\r\n Set<\/span> dbsWawi = wrkAcc.OpenDatabase(\"D:WaWi.accdb\", False, False, \"MS Access;PWD=sicher\")\r\n 'Ohne Kennwort\r\n 'Set<\/span> dbsWawi = wrkAcc.OpenDatabase(\"D:WaWi.accdb\", True<\/span>)\r\n dbsWawi.Properties(\"AllowBypasskey\") = True<\/span>\r\n dbsWawi.Close\r\n wrkAcc.Close\r\n Set<\/span> dbsWawi = Nothing\r\n Set<\/span> wrkAcc = Nothing\r\nEnd Sub<\/span><\/pre>\n<\/p>\n
Private <\/span>Declare Function apiGetUserName Lib \"advapi32.dll\" Alias \"GetUserNameA\" (ByVal lpBuffer As String<\/span>, nSize As Long<\/span>) As Long<\/span><\/pre>\nPrivate <\/span>Declare PtrSafe Function apiGetUserName Lib \"advapi32.dll\" Alias \"GetUserNameA\" (ByVal lpBuffer As String<\/span>, nSize As Long<\/span>) As Long<\/span><\/pre>\n#If VBA7 Then\r\nPrivate <\/span>Declare PtrSafe Function apiGetUserName Lib \"advapi32.dll\" Alias \"GetUserNameA\" (ByVal lpBuffer As String<\/span>, nSize As Long<\/span>) As Long<\/span>\r\n#Else\r\nPrivate <\/span>Declare Function apiGetUserName Lib \"advapi32.dll\" Alias \"GetUserNameA\" (ByVal lpBuffer As String<\/span>, nSize As Long<\/span>) As Long<\/span>\r\n#End If<\/pre>\n<\/p>\n
<\/p>\n
Downloads zu diesem Beitrag<\/h3>\n