Datenverschlüsselung

Unsichere Datenbanken

Die Absicherung einer Access-Datenbank über eine Arbeitsgruppendatei (MDW) beschränkt zwar den Kreis der Zugriffsberechtigten auf Nutzer, die sich mit Benutzername und Kennwort einloggen müssen. Mit einigen zusätzlichen Vorkehrungen wie dem Ausblenden des Datenbankfensters, Erstellen einer MDE-Datenbank, Deaktivieren der Umschalttaste beim Start der Anwendung und dem Einsatz einer Access-Runtime statt der Vollversion scheint der Datenzugriff zwar auf die Präsentationsschicht, also Formulare und Berichte, begrenzt zu sein. Was aber sollte einen neugierigen Nutzer davon abhalten, sich eine Kopie des Backends und der MDW, auf die nun mal systembedingt alle User Vollzugriff haben müssen, zu erstellen und dann in Ruhe seine Access-Vollversion an die MDW anzuschließen und sich nach Eingabe seiner Anmeldedaten in aller Ruhe die Tabellen anzusehen

Sicher, es gibt noch ausgefeiltere Methoden, die Tabellen vor dem User zu schützen, etwa der Einsatz von WITH-OWNERACCESS-OPTION-Abfragen, die nur dem Entwickler (Owner) oder dem VBA-Code den Zugriff erlauben. Das nutzt aber alles nichts, wenn er ein Datenrettungs-Tool wie AccessRecovery über das Backend laufen lässt, das im Stande ist, unter Umgehung der MDW-Absicherung die Tabellen binär auszulesen und ungeschützt wiederherzustellen.

Das ist auch der Grund dafür, dass viele Organisationen Access-Datenbanken prinzipbedingt als unsicher ablehnen. Es gibt aber auch Datenschutzbeauftragte, die eine Access-Datenbank akzeptieren, wenn sichergestellt ist und plausibel gemacht werden kann, dass die Daten verschlüsselt sind. Ohne einen speziellen Zugriffsschlüssel sind die Tabellen dann unbrauchbar. Das zu realisieren ist gar nicht so schwer.

Sicherere Datenbanken

Tabellenfelder, die etwa Namen und Adressen von Klienten enthalten, die nicht öffentlich einsehbar sein sollen, können Sie mit verschiedenen Algorithmen verschlüsseln. Die Tabelle enthält dann nur sinnlose Zeichenfolgen, mit denen keiner etwas anfangen kann. Schwieriger ist es, Felder anderer Datentypen wie Date oder Long zu verschlüsseln, denn das Ergebnis der Verschlüsselung muss ja dann den gleichen Datentyp aufweisen, damit es im Feld gespeichert werden kann. Oder man muss andere Felder wie Binärtypen einsetzen, um das Verschlüsselungsergebnis aufnehmen zu können. Da es jedoch für Zahlenwerte höchst selten einen Grund zur Verschlüsselung geben dürfte, beschäftigen sich die folgenden Techniken fast ausschließlich mit Strings und Textfeldern.

Texte verschlüsseln

Es gibt zahllose Methoden, um einen String zu verschlüsseln. Das Ziel ist zunächst, aus einem Text einen anderen zu machen, der keine Rückschlüsse auf den ursprünglichen Inhalt mehr zulässt. Umgekehrt muss aus dem verschlüsselten Text genauso wieder der Ursprungstext zu errechnen sein. Ein Beispiel für eine sehr simple Routine zeigt Listing 1.

Listing 1: Textzeichen durcheinanderbringen

Function ScrambleString(sIn As String) As String
     Dim i As Long, lLen As Long, 
     Dim sChr As String, iChr As Integer
     lLen = Len(sIn)
     ScrambleString = String(lLen, 0)
     For i = 1 To lLen
         sChr = Mid(sIn, i, 1)
         iChr = Asc(sChr)
         sChr = Chr$(iChr Xor 255)
         Mid(ScrambleString, i, 1) = sChr
     Next i
     ScrambleString = StrReverse(ScrambleString)
End Function

Dabei wird jedes Zeichen des Strings in sChr zwischengespeichert, daraus die Ordinalzahl ermittelt (iChr) und diese mit der boolschen Operation Xor 255 bearbeitet. Hieraus wird ein neuer String mit den Zeichen der neuen Ordinalzahlen iChr erstellt, der anschließend noch mit der Funktion StrReverse umgedreht wird. Heraus kommt, wenn Sie der Funktion beispielsweise den Text "Unternehmen“ übergeben, die Zeichenkette “ ‚š“-š’š<‚ª“. An diesem String lässt sich wohl nichts mehr erkennen, was auf die Ausgangszeichenkette „Unternehmen“ schließen ließe.

Der Clou an der Funktion ist, dass Sie ihr umgekehrt genauso den verschlüsselten String übergeben können, um wieder an den korrekten Text zu kommen: Aus “ ‚š“-š’š<‚ª“ wird dann wieder „Unternehmen“.

Dennoch ist die Methode zu einfach, um einem gewieften Hacker die Arbeit wirklich schwer zu machen. Beispielsweise wird jedes Zeichen im Quelltext in jeweils genau das gleiche Zielzeichen im verschlüsselten Text umgewandelt. Im Beispiel wird ein „n“ immer zu „š“. über stochastische Analyseverfahren etwa lässt sich für einen Krypto-Experten hieraus leicht das Verschlüsselungsverfahren ermitteln.

Deshalb haben sich verschiedene standardisierte Verfahren etabliert, nach denen Texte sicherer verschlüsselt werden können, wobei zur Verschlüsselung meist noch ein eindeutiger Key zum Einsatz kommt, ohne den man den Text nicht mehr zurückverwandeln kann. Diese Algorithmen tragen Namen wie RC2, RC4, DES, Blowfish, TEA, Serpent oder Gost und kennen jeweils mehrere Derivate. Sie unterscheiden sich im Grad der Verschlüsselung – quasi dem „Sicherheitsgrad“ – und auch im Berechnungsaufwand. Der Aufruf sieht in Pseudo-Code meist so aus:

Verschlüsselter Text = KryptoFunktion (UrsprungsText, Schlüssel)

Tabellenfelder verschlüsseln

In Datenbanken, wo etwa über Abfragen große Datenmengen auszuwerten sind, ist man auf einen Kompromiss zwischen Verschlüsselungsstärke und Verarbeitungsgeschwindigkeit angewiesen. Deshalb sollten hier Algorithmen zum Einsatz kommen, die relativ schnell arbeiten, aber ausreichend sicher sind. Das wohl am häufigsten eingesetzte Verfahren ist die RC4-Verschlüsselung. Ein Vorteil der Methode ist, dass Windows entsprechende API-Funktionen mitbringt, die flott zu Werke gehen. Man kann zweifellos jedes Verschlüsselungsverfahren auch in VBA-Code nachbauen; weil aber Stringverarbeitung unter VB eine etwas lahme Angelegenheit ist, kommt man mit Aufrufen auf Funktionen in separaten DLLs erheblich besser weg.

Die Beispieldatenbank zu diesem Beitrag enthält ein Modul mdlEncrypt, in dem Sie die Prozeduren TestDeEncrypt und TestDeEncryptVBA ausführen können. Beide verschlüsseln und entschlüsseln nach dem RC4-Verfahren in einer Schleife 20.000 Strings. TestDeEncryptVBA macht das aber über reinen VBA-Code, die andere bemüht dazu API-Funktionen der Windows-Bibliothek advapi32.dll. Sie werden feststellen, dass die Crypto-Routinen der advapi32.dll etwa dreimal so schnell sind wie die von VBA. Pro Sekunde lassen sich auf einem aktuellen Rechner damit etwa 100.000 Strings verschlüsseln.

Die RC4-Crypto-Methoden von advapi32 kommen übrigens an vielen Stellen von Windows selbst zum Einsatz – und auch in Access: Die Verschlüsselung von Passwörtern im Sicherheitssystem von JET über die PIDs benutzt sie ebenfalls.

Der Code für die Verschlüsselungsmethoden ist in den zwei Klassenmodulen clsRC4 (VBA pur) und clsCypto (Verwendung der advapi32) untergebracht. Die Ergebnisse sind nicht ganz kompatibel: Ein verschlüsselter Text der einen Klasse kann nicht mit den Routinen der anderen wiederhergestellt werden.

RC4 hat noch einen weiteren Vorteil: Die Ergebnis-Strings sind genauso lang, wie die Eingabe-Strings. Damit ist sichergestellt, dass die für Textfelder in den Eigenschaften eingestellte Feldgröße nicht überschritten wird, wenn ein Textinhalt darin verschlüsselt wird.

Die genaue Funktionsweise der beiden Klassen soll hier nicht weiter erläutert werden. Verschlüsselungsverfahren sind ein Thema für Vorlesungen eines ganzen Semesters.

Was soll ich verschlüsseln

Das hängt wohl vom Einsatzzweck ab. Erwähnt wurden schon Adressfelder: Namen, Straßen- und Ortsbezeichnungen. Oder weitere Personendaten: Telefonnummern, E-Mail-Adressen oder auch Memofelder, die Anmerkungen zu den Personen enthalten. Falls die Datenbank ein programmiertes Berechtigungssystem enthält, mit dem etwa der Zugriff auf bestimmte Elemente je nach Benutzer gesteuert wird, kämen für die Verschlüsselung noch in Tabellen gespeicherte Benutzernamen und Kennwörter in Frage.

Vorhandene Tabellen ver- und entschlüsseln

Wie Daten nachträglich verschlüsselt werden können, zeigt die Beispieldatenbank anhand der Tabelle tblKunden in zunächst unverschlüsselter Form. über die Anfügeabfrage qry_EncryptKunden können Sie die Daten in die in identischem Aufbau vorliegende Tabelle tblKundenEncrypt transferieren. Leeren Sie dazu die Tabelle zuerst mit der Löschabfrage qry_DelEncryptKunden.

Nicht alle Felder der Ursprungstabelle werden dabei verschlüsselt. Es sind gerade so viele, dass die Datensätze anschließend nicht mehr nachvollziehbaren Inhalt wiedergeben. Sehen wir uns an, wie etwa das Feld Firma mit der Abfrage verschlüsselt wird:

INSERT INTO tblKundenEnrypt (Firma)
SELECT EncryptString([tblKunden].[Firma],GetCryptKey())
FROM tblKunden

Das Feld Firma der Tabelle tblKunden wird der Verschlüsselung per öffentlicher benutzerdefinierter Funktion EncryptString des Moduls mdlEncrypt unterzogen. Sie erwartet als Parame-ter einerseits den Eingangs-String, andererseits den Verschlüsselungs-Key. Der wird hier aber nicht hartkodiert in die Abfrage geschrieben, sondern seinerseits über eine benutzerdefinierte Funktion GetCryptKey erhalten, die so aussieht:

Function GetCryptKey() As String
 GetCryptKey = StrReverse("60TFOSssom")
End Function 

Das ist gleichsam der Generalschlüssel für die Datenbankverschlüsselung. Dies ist sicher nicht der Weisheit letzter Schluss und wurde der Einfachheit halber so eingesetzt. Der hartkodierte Schlüssel steckt hier im Code verborgen, indem der String „60TFOSssom“ mit der Funktion StrReverse zu „mossSOFT06“ gemacht wird. Alle verschlüsselten Felder der Tabelle tblKundenEncrypt sind also mit dem RC4-Key „mossSOFT06“ bearbeitet.

Um die verschlüsselte Tabelle komplett in entschlüsselter Datenblattansicht anzuzeigen, rufen Sie die Auswahlabfrage qry_DecryptKunden auf. Das Feld Firma wird in dieser so entschlüsselt:

SELECT DecryptString([tblKundenEnrypt].[Firma],GetCryptKey()) AS Firma
FROM tblKundenEnrypt

Die benutzerdefinierte Funktion DecryptString arbeitet analog zu EncryptString und stellt die korrekten Texte wieder mit unserem supergeheimen Key „mossSOFT06“ her.

Die Tabelle tblKunden können Sie anschließend aus der Datenbank entfernen – sie wird nun nicht mehr gebraucht.

Verschlüsselte Daten und Formulare

Wenn die Daten der Tabellen verschlüsselt sind, dann ist ein nicht unerheblicher Mehraufwand bei der Gestaltung der Formulare zu beachten. Schließlich können die Formularfelder nicht mehr einfach, wie gewohnt, an die Tabellenfelder gebunden werden. Sie würden ja dann nur den verschlüsselten Inhalt wiedergeben. Die entsprechenden Textboxen müssen deshab ungebunden vorliegen und ihnen sind Strings per VBA zuzuweisen. Das ist im Formular frmKunden der Beispieldatenbank realisiert, zu dem Sie über das Intro-Formular gelangen, nachdem Sie eine ermüdende Login-Prozedur durchlaufen haben …

Login

Falls Sie die Umschalttaste beim öffnen der Beispieldatenbank nicht gedrückt halten, zeigt sich das Intro-Formular von Access-im-Unternehmen. Ein Klick auf „Start“ leitet Sie dann zu einem Eingabedialog, der Ihren Benutzernamen abfragt. Ist der korrekt, muss ein Kennwort angegeben werden. Falls das ebenfalls stimmt, wird das Formular frmKunden geöffnet. Das fragt seinerseits nach dem Generalschlüssel, den Sie bereits kennen. Nach gültiger Eingabe können Sie endlich die Daten der Tabelle tblKundenEncrypt unverschlüsselt ansehen und bearbeiten. Andernfalls werden Sie nur Kauderwelsch zu Gesicht bekommen.

Damit Sie nicht nachforschen müssen: Versuchen Sie es mit „Leser“ als Benutzername und Kennwort sowie dem Key „mossSOFT06“ für das Formular frmKunden.

Das alles ist Spielerei, soll aber verdeutlichen, wie Anmeldeinformationen in verschlüsselten Tabellen verwendet werden können. Hier sind sie in der Tabelle tblLogin gespeichert, wobei nur das Feld Passwort mit dem RC4-Key „mossSOFT06“ verschlüsselt wird.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo