2021-05

Datum: 19.05.2021
Thema: Datensicherheit einer Access-Datenbank (Gastvortrag von Bernd Jungbluth), Hilfe bei Problemen und allgemeine Diskussion – alles wieder virtuell

Zum Mai-Termin bekam der Access-Stammtisch virtuellen Besuch von Bernd Jungbluth.

Vielen dürfte er bekannt sein als Sprecher auf Konferenzen, als Referent und Veranstalter von Workshops und Seminaren oder auch als Autor und Co-Autor verschiedener Bücher rund um die Themen Access und SQL-Server.

Zunächst gab es einen Exkurs in das Thema „Datensicherheit“, das z.B. den technischen Schutz von Daten einer Unternehmens betrifft. Das Stichwort dazu heißt TOM – also technisch-organisatorische Maßnahmen, wie Verschlüsselung oder Pseudonymisierung.

Einhergehend mit Datensicherheit ist auch der Datenschutz, also der Schutz von personenbezogenen Daten eines Unternehmens.

Bernd wies im Vortrag auf die Notwendigkeit einerseits (Schutz von Geschäftsinformationen, Schutz vor Cyberangriffen) und die Anforderungen andererseits (Vertragliche Vereinbarungen, DSGVO) hin.

An dieser Stelle sei auf das DSGVO-Whitepaper von Karl Donaubauer, Bernd Jungbluth und Philipp Stiefel hingewiesen: http://donkarl.com/DSGVO/.

In Access gibt es verschiedene Ansätze zu Datensicherheit. Dies kann z.B. ein Datenbank-Kennwort sein, das Verschlüsseln des VBA-Quellcodes oder das Ausführen einer accde/mde im Runtime-Modus.

Jedoch lassen sich einige Sicherheitseinstellungen in einer Access-Datenbank umgehen.

Anhand einer Beispiel-Anwendung zeigte er uns, wie einfach es ist, das Datenbank-Kennwort einer verschlüsselten Datenbank auszulesen. Im Szenario konnte die eingebundene Tabelle einer kennwort-geschützten Backend-Datenbank im Direktbereich der Frontend-Datenbank mittels

?CurrentDb.TableDefs("<Tabellenname>").Connect

ausgelesen werden. Damit wird auch das gesetzte Kennwort im Klartext angezeigt.

Auch die Möglichkeit, den VBA-Code mit Kennwort schützen, lässt sich relativ leicht aushebeln: Mit einem Hex-Editor kann man das VBA-Kennwort sehen. Dazu muss man nach der Zeichenkette DPB suchen und dann dort das „B“ z.B. in „y“ ändern.

In Access werden zunächst einige Fehler angezeigt. Im VBA-Editor kann man nun jedoch irgendein Kennwort eingeben und schon ist man wieder im Code.

Gezeigt wurde auch eine Methode, die Access-Spezialtasten zu unterbinden. Hierzu gibt es die Eigenschaft AllowBypassKey. Auf http://www.donkarl.com?FAQ1.8 gibt es dazu eine gute Erläuterung.

Fazit des interessanten Vortrags war, das eine Access-Datenbank, die über die Runtime gestartet wird und deren Front- bzw. Backend jeweils passwortgesichert sind, einigermaßen geschützt ist 🛡

Im Anschluss schloss sich die offene Diskussion an. Karl Donaubauer erwähnt, von seinen Erfahrungen, ein Frontend-Passwort zu „hacken“. Dazu gibt es ein Video von Karl und Philipp Stiefel:

Einen anderen Ansatz, den Karl im Kundeneinsatz verfolgt, ist die Ausführung von Access-Datenbanken im Runtime-Modus in einem Terminal-Server.

Uwe bedankt sich bei Bernd für den interessanten Beitrag und bemerkt, das Access nicht wirklich ein abgesichertes Tool ist (was länger zu befürchten war). Er fragt nach, ob der Aspekt sich mehr darauf bezieht, Anwendungen und Daten vor Sabotage aus den eigenen Reihen zu schützen.

Das ist aber für Bernd relativ zu sehen. Uwe erinnert sich daran, das Karl vor einigen Jahren in einem Vortrag offenen Datenbanken propagierte. Das bestätigt Karl auch so, jedoch sieht es bei schützenswerten Daten und Anwendungen wieder anders aus.

Uwe berichtet vom Konzept bei der TUI, Access-Anwendungen in dedizierten Netzwerk-Shares bereitzustellen. In Corona-Zeiten wird verstärkt im Home Office gearbeitet. Daher setzt man auf Citrix-Lösungen, um eine einigermaßen gute Performance zu erreichen.

Aus seiner Praxis berichtet Uwe weiter, das er noch nie mutwillige Angriffe auf die Access-Anwendungen erlebt hat.

Hier interveniert Bernd und gibt zu bedenken, das man es ja evtl. nicht weiß, ob jemand die Datenbanken angegriffen hat. Hacks und Krypto-Trojaner bekommt man mit. Die eigentlichen Attacken, die schwerwiegend sind, sind die, die man nicht mitbekommt.

Bernd fragt in die Runde, ob jemand ein Budget für unwichtige Daten hat und es folgt rasch die Erkenntnis, das es eigentlich keine unwichtigen Daten gibt.

Gundo will wissen, ob man auch an die Kennwörter von verknüpften SQL-Server-Tabellen erhalten kann. Lt. Bernd ist das prinzipiell auf dem gleichen Weg möglich.

Karl berichtet von einem weiteren Variante, bei dem im Frontend nichts eingebunden wurde. Der SQL-String stand im Code und somit war der Code die Schutzfunktion. Das geht aus Performancegründen jedoch nur für wenige Tabellen.

Klaus meint, das Kernproblem ist am Ende, solange man irgendwie Zugriff auf den Direktbereich bekommt, ist die Datenbank „verloren“. Im Endeffekt dreht es sich darum, diesen Zugriff noch zu verhindern. Oder man geht aufwändig daran, den Speicher zu analysieren.

Bernd erinnert sich hier an eine Möglichkeit, die Runtime auszutricksen, die Philipp Stiefel vorgestellt wird.

Gundo fragt, was man bei Microsoft einfordern kann, um Access sicherer zu machen.

Karl berichtet, das hier schon lange nichts mehr investiert wird und stattdessen auf den SQL-Server verwiesen wird.

Vorsicht sollte man auch mit dem Einsatz des SQL-Server Express als Access-Backend walten lassen. Weil das Systemadministrator-Konto auf jedem SQL-Server verfügbar ist wird es gern genommen. Dann bindet man die Tabellen mit dem Kennwort vom Systemadministrator ein. D.h., man hat das nun Kennwort zum Konto, mit dem man alles auf dem SQL-Server machen darf.

Daher behauptet Bernd, das die Aussage „Nehmen Sie einen SQL-Server als Backend, dann wird’s sicherer“ im ersten Moment unsicherer ist.

Bei der TUI geht man daher den Weg, im Active Directory Application Groups definieren und dann über die Windows-Authentifizierung (die Gruppen) den Datenbankzugriff gewähren, berichtet Uwe. Jedoch schützt das nicht vor dem Missbrauch durch berechtigte User.

Setzt man Citrix ein, kann man z.B. eine begrenzte Oberfläche darstellen (ohne Windows Explorer z.B.), sondern nur die entsprechende Applikation.

So macht man es lt. Uwe bei der TUI, indem man den Usern, die sich über Citrix anmelden, keinen Desktop gibt. Stattdessen startet eine kleine Access-Applikation, die wiederum einen Launcher für andere Access-Datenbanken darstellt.

Selbst wenn die User einen vollwertigen Desktop haben, kann man die Access-Anwendung z.B. über einen Terminal Server oder Citrix-Server in einem Fenster laufen lassen, führt Klaus aus. Damit hat man die Schutzfunktion des Citrix-Servers und die übrigen Programme auf dem Desktop.

Bernd fragt, wo liegt Citrix preislich. Klaus weist darauf hin, das es erstmal eine Rolle eines Windows Server ist. Hinzu kommen noch Client Access-Lizenzen (CAL), die aber nicht so teuer sind. Da stellt sich für Bernd die Frage „was kostet uns das ganze“.

Uwe fragt, wer ein richtig gutes Konzept für den Access-Betrieb in der Cloud hat?

Es gab da den einen oder anderen Betrag bei Karl, z.B. den Einsatz von SharePoint. Hier hat Uwe aber ein Experiment gemacht und das Backend im SharePoint gelagert, was einen Performance-Rückgang mit Faktor 50 bis 100 zur Folge hatte.

Bernd empfahl dazu Dieter Liessmanns Access-Hosting und verwies auf den entsprechenden Beitrag der AEK 17.

Bernd hatte mal eine Anfrage, eine Access-Datenbank mit dem Migrations-Assistenten direkt nach Azure SQL zu migrieren. Jedoch riet er davon ab und empfahl, eine SQL-Server Express-Edition zu installieren und diese zu migrieren. Durch die Kombination Frontend/Backend „tickt“ der SQL-Server etwas anders und Access ruft die Daten nach altem Prinzip. Und dort hat man auch ein Server Admin-Konto. Der zentrale Zugang zur Azure-Datenbank sind dann im Access-Frontend, wenn man Tabellen eingebunden hat. Damit stehen die Daten dann erstmal in der Welt.

Uwe berichtet von Bestrebungen, in die Amazon-Cloud umzuziehen.

Karl stellt einen Vortrag auf der nächste AEK zu Access auf Virtuellen Rechnern in Aussicht.

Stefan erwähnt deskMate, der virtuelle Rechner – z.B. für Schulungen – bereitstellt.

In der Runde kamen wir dann auf die Aussichten zur nächsten AEK, die voraussichtlich Ende September 2021 auch wieder in Hannover stattfinden soll (vorausgesetzt, die Leute wollen sich noch treffen bzw. die Corona-Lage lässt es zu).

Noch einmal wurde das Thema „Terminal Server“ aufgegriffen: Bernd hat aus der Diskussionsrunde herausgehört, das man mit dem Terminal Server einmal die Sicherheit und einmal die Performance erhöhen kann.

Karl hat gute Erfahrungen damit und Stefan erwähnt, das man Terminal Server auch gut virtualisieren kann.

Im Gegensatz zum MS Virtual Desktop lässt sich ein Terminal Server einfacher betreiben. Virtual Desktop ist zu schwierig in der Konfiguration, weiß Karl zu berichten.

Ulrich schneidet das Thema „Access als Alleinstellungsmerkmal“ an. Alternativen sind übersichtlich (FileMaker, OpenOffice Base) und in vielen Bereichen ist Access in der RAD-Entwicklung überlegen.

Uwe berichtet vom Hype auf die Power Platform von Microsoft und fragt, ob jemand Erfahrung damit hat. Karl hatte auf einigen Konferenzen Einsatzmöglichkeiten vorgestellt.

Für kleine Anwendungen können z.B. Power Apps durchaus sinnvoll sein.

Auf die Frage, ob Power Apps irgendwann einmal Access ablösen können, weist Bernd auf die unterschiedliche Architektur hin: Access ist eine Desktop-Anwendung; bei Power Apps ist Microsoft 365 oder Azure im Hintergrund. Auch Power Automate benötigt eine Verbindung zu DataVerse, also man ist immer von der Cloud abhängig.

Sein Fazit: Kombinierbar sind die zwei Welten womöglich, abgelöst wird Access durch die Power Platform jedoch nicht.

Solange es den Desktop gibt, wird Access weiterleben, ist Klaus überzeugt. Und überhaupt: Access wird .NET überleben, ist sich Bernd sicher.

Zum Ende der Runde wurde über Zoom und MS Teams diskutiert und es wurde – mit Blick auf die Abhängigkeit von amerikanischen Clouddiensten und europäischen Digitalisierungsbemühungen – philosophisch.

Werbung