{"id":55000487,"date":"2025-10-01T00:00:00","date_gmt":"2025-12-28T17:10:17","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=487"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"SQL_ServerZugangsdaten_sicher_speichern","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/SQL_ServerZugangsdaten_sicher_speichern\/","title":{"rendered":"SQL Server-Zugangsdaten sicher speichern"},"content":{"rendered":"

\"\"Im Artikel “SQL Server: Tabellen verknüpfen” (www.vbentwickler.de\/485) haben wir gezeigt, wie wir die Tabellen eines SQL Servers per ODBC als Tabellenverknüpfung in Access-Datenbanken verfügbar machen können. Dabei gibt es zwei Varianten, um über entsprechende Verbindungszeichenfolgen auf die Tabellen des SQL Servers zuzugreifen: Windows-Authentifizierung und SQL Server-Authentifizierung. Bei der ersten werden die Zugangsdaten über den aktuellen Windows-Benutzer ermittelt. Dieses Kennwort kennt in der Regel nur der Benutzer und die Verknüpfung der Tabellen kann nach seiner Anmeldung am Rechner ohne weitere Interaktion erfolgen. Bei der SQL Server-Authentifizierung jedoch müssen zusätzlich die Zugangsdaten des Benutzers zum SQL Server angegeben werden. Damit der Benutzer diese nicht immer manuell eingeben muss, möchten wir diese sicher speichern – so, dass niemand diese auslesen kann, auch wenn er Zugriff zum Rechner des Benutzers hat. Wie das gelingt, zeigen wir in diesem Artikel.<\/b><\/p>\n

Wenn ein Benutzer sich an seinen Rechner angemeldet hat und seine Access-Anwendung geöffnet hat, muss er, um auf per ODBC verknüpfte SQL Server-Tabellen zuzugreifen, auf irgendeine Weise seine Zugangsdaten für den SQL Server und die entsprechende Datenbank angeben, damit diese zum Aktualisieren oder Neuanlegen der Tabellenverknüpfungen genutzt werden können. Wie das Aktualisieren oder Neuverknüpfen gelingt, haben wir in aller Ausführlichkeit im Artikel SQL Server: Tabellen verknüpfen <\/b>(www.vbentwickler.de\/485<\/b>) beschrieben. Dazu müssen der Benutzername und das Kennwort einmalig angegeben und in die Verbindungszeichenfolge zum Herstellen der Tabellenverknüpfungen eingetragen werden. Nach dem initialen Aktualisieren oder Neuanlegen der Tabellenverknüpfungen ist während der aktiven Access-Session keine weitere Eingabe dieser Daten erforderlich, da diese intern gespeichert werden. Erst wenn der Benutzer diese Access-Session durch Schließen der Anwendung beendet, werden die temporär gespeicherten Zugangsdaten aus dem Speicher gelöscht.<\/p>\n

Da jede Eingabe Zeit kostet, wollen wir hier eine Lösung vorstellen, mit der wir die Zugangsdaten an irgendeiner Stelle im System speichern können, damit der Benutzer diese nicht bei jedem Start der Anwendung manuell eingeben muss. Wir gehen an dieser Stelle davon aus, dass der Benutzer sich nach Feierabend von seinem Rechner abmeldet und diesen auch in kurzen Pausen sperrt. Ansonsten könnten andere Benutzer auf den Rechner zugreifen und die Daten der verknüpften Tabellen mühelos auslesen und in eine andere Datenbank kopieren.<\/p>\n

Dennoch würde er dazu eine gewisse Zeit benötigen. Sicherstellen wollen wir auf jeden Fall, dass ein Dritter sich keinen Zugang zu den von uns im System des Benutzers gespeicherten Zugangsdaten zum SQL Server zu verschaffen. Dies wäre kritisch, weil ein Dritter diese dann nutzen könnte, um von einem anderen Rechner in aller Ruhe auf die Tabellen der entsprechenden SQL Server-Datenbank zuzugreifen und diese zu kopieren, zu ändern oder zu löschen oder auch neue Daten hinzuzufügen.<\/p>\n

Die vorgestellte Lösung soll also nicht nur dazu dienen, dem Benutzer mehr Komfort beim Starten der Access-Anwendung zu bieten, indem er nicht jedes Mal seine SQL Server-Zugangsdaten eingeben muss. Sie soll auch dafür sorgen, dass diese Zugangsdaten so gespeichert werden, dass kein Dritter diese auslesen kann, auch wenn er uneingeschränkten Zugriff auf den Rechner hat.<\/p>\n

Geeignete Speicherorte<\/h2>\n

Es gibt verschiedene geeignete Speicherorte für solche Zugangsdaten. Der naheliegendste ist eine Optionentabelle in der Access-Anwendung selbst. Der Benutzer müsste einmal seine SQL Server-Zugangsdaten eingeben. Diese würden dann direkt nach der Eingabe in der entsprechenden Tabelle gespeichert werden.<\/p>\n

Eine weitere Option ist eine externe Datei – dabei kann es sich um eine simple Textdatei handeln oder auch eine XML- oder eine JSON-Datei, in die wir diese Informationen in strukturierter Form eintragen können.<\/p>\n

Schließlich gibt es noch die Registry. Diese bietet im Pfad HKEY_CURRENT_USER\\Software\\VB and VBA Program Settings <\/b>einen Bereich, der speziell per VBA oder VB leicht beschrieben oder ausgelesen werden kann, ohne dass wir Funktionen der Windows-API bemühen müssen.<\/p>\n

All diese Speicherorte haben Vor- und Nachteile gemeinsam. Der Vorteil ist, dass man diese nur auslesen kann, wenn man unter dem entsprechenden Benutzerkonto angemeldet ist. Voraussetzung dafür ist, dass sich die Dateien im jeweiligen Benutzerordner befinden. Bei dem angesprochenen Registry-Bereich ist das automatisch sichergestellt, da sich dieser unter dem Element HKEY_CURRENT_USER <\/b>befindet, der ohnehin nur im Kontext der entsprechenden Benutzeranmeldung auslesbar ist.<\/p>\n

Aber wenn der Benutzer einmal seinen Arbeitsplatz verlässt, zum Beispiel um sich einen Kaffee zu holen, ohne sich abzumelden oder den Bildschirm zu sperren, könnte ein Dritter diese Daten ebenfalls mühelos auslesen und anschließend von einem anderen Rechner über diesen Zugang auf den SQL Server zugreifen.<\/p>\n

Es gilt also, noch eine weitere Sicherheitsstufe zu integrieren.<\/p>\n

Sicheres Speichern der Zugangsdaten<\/h2>\n

Dies geschieht wiederum in zwei Stufen. Die erste Stufe ist, dass wir die Zugangsdaten nach der Eingabe und vor dem Speichern durch einen entsprechenden Algorithmus verschlüsseln. Dieser Algorithmus wird als Funktion in der Datenbankanwendung hinterlegt.<\/p>\n

Nun kann ein Dritter ohne weitere Maßnahmen immer noch das VBA-Projekt der Access-Anwendung öffnen und Einblick in diesen Algorithmus erhalten, um diesen dann auf einem anderen Rechner auszuführen. Hier folgt die zweite Stufe, indem wir sicherstellen, dass Benutzer keine ungesicherte .accdb<\/b>-Version der Access-Anwendung nutzen, sondern nur eine .accde<\/b>-Version, die keinen Einblick in den VBA-Code mehr gewährt. So ist sichergestellt, dass niemand den Verschlüsselungsalgorithmus ermitteln kann.<\/p>\n

Schließlich sollten wir nicht nur einfach den Benutzernamen und das Kennwort verschlüsseln, zum Beispiel mit SHA1. Das Problem ist: Wenn jemand Zugriff auf die Registry oder die Datei hat, in der die Zugangsdaten gespeichert sind, kann er einfach alle gängigen Algorithmen zur Entschlüsselung einmal durchgehen und wird so früher oder später auf die richtige Methode stoßen und kann die Zugangsdaten entschlüsseln.<\/p>\n

Das Zauberwort an dieser Stelle lautet Pepper. So nennt man eine Zeichenkette, die als zusätzlicher Faktor für die Verschlüsselung verwendet werden kann. Diesen Faktor speichern wir wiederum im VBA-Projekt, das wir durch Umwandeln der Datenbankdatei in eine .accde <\/b>weitgehend unlesbar machen.<\/p>\n

Weitgehend deshalb, weil es durchaus Unternehmen gibt, die .accde<\/b>-Dateien entschlüsseln können, so dass auch unsere Pepper-Zeichenkette ausgelesen werden kann. Solche Unternehmen lassen sich aber, wenn sie im legalen Bereich operieren, vom Auftraggeber bestätigen, dass sie berechtigt sind, das VBA-Projekt dieser Anwendung wieder lesbar zu machen.<\/p>\n

Verwenden von DPAPI zum Ver- und Entschlüsseln<\/h2>\n

In diesem Artikel verwenden wir keine der üblichen Verschlüsselungsmethoden wie SHA1 et cetera, sondern DPAPI. DPAPI steht für Data Protection API und ist ein integrierter Windows-Mechanismus, mit dem Anwendungen Daten einfach und sicher verschlüsseln können, ohne selbst Kryptographie implementieren zu müssen.<\/p>\n

Die Besonderheit von DPAPI ist, dass es einen Schlüssel verwendet, der an das Windows-Benutzerkonto oder an den Computer gebunden ist.<\/p>\n

Es gibt zwei Modi:<\/p>\n

    \n
  • USER-MODE<\/b>: Hier ist der Schlüssel ist an den aktuell angemeldeten Windows-Benutzer gebunden. Nur dieser Benutzer kann die Daten wieder entschlüsseln. Dazu kann er die API-Funktionen CryptProtectData <\/b>und CryptUnprotectData <\/b>nutzen.<\/li>\n
  • MACHINE-MODE<\/b>: Hier ist der Schlüssel ist an den Rechner gebunden. Damit kann jedes Programm unter jedem Benutzer kann entschlüsseln, was zum Beispiel für Serverdienste verwendet werden kann.<\/li>\n<\/ul>\n

    Für Access-Frontend-Anwendungen ist USER-MODE perfekt. Wenn wir die Funktion CryptProtectData <\/b>nutzen, wird die zu verschlüsselnde Zeichenkette in einen Datenblock gepackt. Windows verschlüsselt diesen Datenblock mit einem Schlüssel, der aus dem Windows-Benutzerpasswort und geheimen Systemschlüsselnabgeleitet wird. Dies liefert ein Byte-Array zurück, den wir dann zum Beispiel in der Registry speichern können.<\/p>\n

    Wenn wir später mit der Funktion CrypUnprotectData <\/b>entschlüsseln, übergeben wir das verschlüsselte Byte-Array. Windows prüft dann, ob der aktuelle Benutzer der gleiche Benutzer ist, der verschlüsselt hat. Wenn ja, wird der verschlüsselte Text unverschlüsselt wieder ausgegeben. Anderenfalls schlägt die Verschlüsselung fehl.<\/p>\n

    Code zum Ver- und Entschlüsseln<\/h2>\n

    Um eine Verschlüsselung mit einer Pepper-Zeichenkette zu nutzen, benötigen wir als Erstes eine Konstante, in der wir diese Zeichenkette speichern:<\/p>\n

    Private <\/span>Const APP_PEPPER As String<\/span> = \"DEIN_GEHEIMER_PEPPER\"<\/pre>\n
    Hier musst Du Deine eigene Pepper-Zeichenfolge eintragen.<\/p>\n
    Außerdem benötigen wir die Deklaration zweier API-Funktionen namens CryptProtectData <\/b>und CryptUnprotectData <\/b>und zwei weitere API-Funktionen namens RtlMoveMemory <\/b>und LocalFree<\/b>. Diese finden wir, neben dem Typ DATA_BLOB<\/b>, in Listing 1.<\/p>\n
    Private <\/span>Type DATA_BLOB\r\n     cbData As Long<\/span>\r\n     pbData As Long<\/span>Ptr\r\nEnd Type\r\n#If VBA7 Then\r\n     Private <\/span>Declare PtrSafe Function CryptProtectData Lib \"crypt32.dll\" ( _\r\n         ByRef pDataIn As <\/span>DATA_BLOB, _\r\n         ByVal szDataDescr As Long<\/span>Ptr, _\r\n         ByVal pOptionalEntropy As Long<\/span>Ptr, _\r\n         ByVal pvReserved As Long<\/span>Ptr, _\r\n         ByVal pPromptStruct As Long<\/span>Ptr, _\r\n         ByVal dwFlags As Long<\/span>, _\r\n         ByRef pDataOut As <\/span>DATA_BLOB) As Long<\/span>\r\n     Private <\/span>Declare PtrSafe Function CryptUnprotectData Lib \"crypt32.dll\" ( _\r\n         ByRef pDataIn As <\/span>DATA_BLOB, _\r\n         ByVal ppszDataDescr As Long<\/span>Ptr, _\r\n         ByVal pOptionalEntropy As Long<\/span>Ptr, _\r\n         ByVal pvReserved As Long<\/span>Ptr, _\r\n         ByVal pPromptStruct As Long<\/span>Ptr, _\r\n         ByVal dwFlags As Long<\/span>, _\r\n         ByRef pDataOut As <\/span>DATA_BLOB) As Long<\/span>\r\n     Private <\/span>Declare PtrSafe Sub RtlMoveMemory Lib \"kernel32\" ( _\r\n         ByRef Destination As <\/span>Any, _\r\n         ByVal Source As Long<\/span>Ptr, _\r\n         ByVal Length As Long<\/span>Ptr)\r\n     Private <\/span>Declare PtrSafe Function LocalFree Lib \"kernel32\" ( _\r\n         ByVal hMem As Long<\/span>Ptr) As Long<\/span>Ptr\r\n#End If<\/pre>\n
    Listing 1: API-Deklarationen für das Ver- und Entschlüsseln<\/span><\/b><\/p>\n
    Die Funktion ProtectString<\/h2>\n
    Die Funktion ProtectString<\/b> übernimmt die Aufgabe, unsere Zeichenkette, also zum Beispiel den Benutzernamen oder das Kennwort sicher zu verschlüsseln, bevor sie beispielsweise in der Registry gespeichert wird. Dabei kombiniert die Funktion den in APP_PEPPER<\/b> hinterlegten Pepper mit der Windows-internen DPAPI-Verschlüsselung (siehe Listing 2).<\/p>\n
    Public Function <\/span>ProtectString(ByVal s As String<\/span>) As String<\/span>\r\n     Dim <\/span>sWithPepper As String<\/span>\r\n     Dim <\/span>inBlob As <\/span>DATA_BLOB\r\n     Dim <\/span>outBlob As <\/span>DATA_BLOB\r\n     Dim <\/span>bytes() As Byte<\/span>\r\n     Dim <\/span>lRes As Long<\/span>\r\n     If <\/span>Len<\/span>(s) = 0 Then<\/span> Exit Function<\/span>\r\n     sWithPepper = APP_PEPPER & s\r\n     bytes = StrConv(sWithPepper, vbFromUnicode)\r\n     inBlob.cbData = UBound<\/span>(bytes) - LBound<\/span>(bytes) + 1\r\n     inBlob.pbData = VarPtr(bytes(LBound<\/span>(bytes)))\r\n     lRes = CryptProtectData(inBlob, 0, 0, 0, 0, 0, outBlob)\r\n     If <\/span>lRes <> 0 Then<\/span>\r\n         ReDim bytes(0 To outBlob.cbData - 1)\r\n         RtlMoveMemory bytes(0), outBlob.pbData, outBlob.cbData\r\n         Call<\/span> LocalFree(outBlob.pbData)\r\n         ProtectString = BytesToHex(bytes)\r\n     Else<\/span>\r\n         Debug.Print<\/span> \"CryptProtectData failed. LastDllError=\" & Err.LastDllError\r\n         ProtectString = \"\"\r\n     End If<\/span>\r\nEnd Function<\/span><\/pre>\n
    Listing 2: Funktion zum Verschlüsseln von Zeichenketten<\/span><\/b><\/p>\n
    Zunächst prüft die Funktion, ob der übergebene String überhaupt einen Wert enthält. Ist das nicht der Fall, bricht sie sofort ab und liefert einen leeren Rückgabewert.<\/p>\n
    Danach wird der Pepper aus APP_PEPPER<\/b> vor das eigentliche Klartextpasswort gesetzt. Dieser Pepper wird nicht mitgespeichert und dient als zusätzliche Schutzschicht, da ein Angreifer ohne Kenntnis dieses Werts den entschlüsselten Text nicht korrekt validieren könnte.<\/p>\n
    Anschließend wird die zusammengesetzte Zeichenkette (APP_PEPPER <\/b>plus Benutzername\/Kennwort) durch die Funktion StrConv <\/b>in ein ANSI-Byte-Array umgewandelt. DPAPI arbeitet intern mit Binärdaten, daher muss der String zunächst in ein Array von Bytes transformiert werden. Dieses Bytearray wird danach in eine DATA_BLOB<\/b>-Struktur übergeben, die lediglich aus der Anzahl der Bytes und einem Zeiger auf das erste Byte besteht. Wichtig ist hierbei, dass die Struktur nicht selbst Daten enthält, sondern direkt auf das vorhandene Array zeigt.<\/p>\n
    Nun kommt der zentrale Schritt: Die Funktion ruft CryptProtectData <\/b>auf, eine Windows-API-Funktion, die die Daten benutzergebunden verschlüsselt. Das bedeutet, dass nur derselbe Windows-Benutzer die Daten später wieder entschlüsseln kann – ideal für sichere lokale Speicherung.<\/p>\n
    Der Rückgabewert zeigt an, ob der Vorgang erfolgreich war. Bei Erfolg werden die verschlüsselten Bytes aus dem zurückgegebenen BLOB in ein eigenes Bytearray kopiert. Anschließend wird der durch die API belegte Speicher wieder freigegeben, um Speicherlecks zu vermeiden.<\/p>\n
    Zum Abschluss wandelt die Funktion das verschlüsselte Bytearray mit einer weiteren Funktion namens BytesToHex <\/b>in einen Hex-String um. Diese Darstellung eignet sich besonders gut für Registry-Einträge oder andere textbasierte Speicherorte, da sie keinerlei Sonderzeichen enthält und verlustfrei wieder zurückkonvertiert werden kann.<\/p>\n
    Falls die Verschlüsselung fehlschlägt, gibt die Funktion eine Debug-Meldung aus und liefert einen leeren String zurück.<\/p>\n
    Die Funktion BytesToHex <\/b>sieht wie folgt aus:<\/p>\n
    Private Function <\/span>BytesToHex(ByRef b() As Byte<\/span>) As String<\/span>\r\n     Dim <\/span>i As Long<\/span>\r\n     Dim <\/span>s As String<\/span>\r\n     For i = LBound<\/span>(b) To UBound<\/span>(b)\r\n         s = s & Right$(\"0\" & Hex$(b(i)), 2)\r\n     Next<\/span> i\r\n     BytesToHex = s\r\nEnd Function<\/span><\/pre>\n
    Entschlüsseln der Zugangsdaten<\/h2>\n
    Zum Entschlüsseln der Daten verwenden wir die Funktion UnprotectString<\/b> aus Listing 3.<\/p>\n
    Public Function <\/span>UnprotectString(ByVal s As String<\/span>) As String<\/span>\r\n     Dim <\/span>enc() As Byte<\/span>\r\n     Dim <\/span>dec() As Byte<\/span>\r\n     Dim <\/span>inBlob As <\/span>DATA_BLOB\r\n     Dim <\/span>outBlob As <\/span>DATA_BLOB\r\n     Dim <\/span>lRes As Long<\/span>\r\n     Dim <\/span>tmp As String<\/span>\r\n     If <\/span>Len<\/span>(s) = 0 Then<\/span> Exit Function<\/span>\r\n     enc = HexToBytes(s)\r\n     If <\/span>(UBound<\/span>(enc) < LBound<\/span>(enc)) Then<\/span> Exit Function<\/span>   '' leeres Array\r\n     inBlob.cbData = UBound<\/span>(enc) - LBound<\/span>(enc) + 1\r\n     inBlob.pbData = VarPtr(enc(LBound<\/span>(enc)))\r\n     lRes = CryptUnprotectData(inBlob, 0, 0, 0, 0, 0, outBlob)\r\n     If <\/span>lRes <> 0 Then<\/span>\r\n         ReDim dec(0 To outBlob.cbData - 1)\r\n         RtlMoveMemory dec(0), outBlob.pbData, outBlob.cbData\r\n         Call<\/span> LocalFree(outBlob.pbData)\r\n         tmp = StrConv(dec, vbUnicode)\r\n         If <\/span>Left$(tmp, Len<\/span>(APP_PEPPER)) = APP_PEPPER Then<\/span>\r\n             UnprotectString = Mid$(tmp, Len<\/span>(APP_PEPPER) + 1)\r\n         Else<\/span>\r\n            UnprotectString = \"\"\r\n         End If<\/span>\r\n     Else<\/span>\r\n         Debug.Print<\/span> \"CryptUnprotectData failed. LastDllError=\" & Err.LastDllError\r\n         UnprotectString = \"\"\r\n     End If<\/span>\r\nEnd Function<\/span><\/pre>\n
    Listing 3: Funktion zum Entschlüsseln von Zeichenketten<\/span><\/b><\/p>\n
    Sie erledigt die umgekehrte Aufgabe wie ProtectString<\/b>:Sie nimmt den verschlüsselten Text als Parameter als Hex-String entgegen, entschlüsselt ihn mit der Windows-DPAPI und entfernt anschließend den vorangestellten Pepper, sodass am Ende wieder das ursprüngliche Klartextkennwort übrigbleibt.<\/p>\n
    Zuerst werden einige Variablen deklariert:<\/p>\n
      \n
    • enc()<\/b> und dec()<\/b>: Bytearrays für die verschlüsselten beziehungsweise entschlüsselten Daten<\/li>\n
    • inBlob <\/b>und outBlob<\/b>: Strukturen, die die Windows-API-Funktionen CryptUnprotectData <\/b>verwenden<\/li>\n
    • lRes<\/b>: nimmt den Rückgabewert dieser Funktion auf<\/li>\n
    • tmp<\/b>: temporärer String für den entschlüsselten Text inklusive Pepper.<\/li>\n<\/ul>\n
      Ganz am Anfang prüft die Funktion, ob der Eingabestring s <\/b>überhaupt Zeichen enthält – ist er leer, steigt UnprotectString <\/b>direkt aus, weil es dann schlicht nichts zu entschlüsseln gibt.<\/p>\n
      Als Nächstes wird der Hex-String aus der Registry mit der Funktion HexToBytes <\/b>wieder in ein Bytearray zurückverwandelt. Diese Funktion definieren wir wie folgt:<\/p>\n
      Private Function <\/span>HexToBytes(ByVal s As String<\/span>) As Byte<\/span>()\r\n     Dim <\/span>b() As Byte<\/span>\r\n     Dim <\/span>i As Long<\/span>, n As Long<\/span>\r\n     n = Len<\/span>(s) \\ 2\r\n     If <\/span>n = 0 Then<\/span>\r\n         ReDim b(0 To -1) '' leeres Array\r\n         HexToBytes = b\r\n         Exit Function<\/span>\r\n     End If<\/span>\r\n     ReDim b(0 To n - 1)\r\n     For i = 0 To n - 1\r\n         b(i) = CByte(\"&H\" & Mid$(s, 2 * i + 1, 2))\r\n     Next<\/span> i\r\n     HexToBytes = b\r\nEnd Function<\/span><\/pre>\n
      HexToBytes <\/b>macht aus zwei Hex-Zeichen jeweils ein Byte. Danach folgt eine Sicherheitsprüfung: Wenn enc <\/b>ein leeres Array ist (Obergrenze < Untergrenze), wird ebenfalls sofort beendet - dann ist irgendetwas mit den Eingabedaten schiefgelaufen. Im Normalfall enthält enc<\/b> jetzt also genau die Bytes, die ProtectString<\/b> zuvor erzeugt und als Hex kodiert hatte.<\/p>\n
      Diese Bytes werden nun in die DATA_BLOB<\/b>-Struktur für die API überführt.<\/p>\n
      cbData <\/b>bekommt die Anzahl der Bytes, pbData <\/b>die Speicheradresse des ersten Array-Eelements. Wichtig ist hier: Der Blob zeigt direkt auf das aktuelle Array im Speicher, es wird nichts kopiert. Jetzt kann CryptUnprotectData <\/b>die Daten entschlüsseln.<\/p>\n
      Wenn lRes <\/b>ungleich 0 <\/b>ist, war der Aufruf erfolgreich und outBlob <\/b>enthält einen Zeiger auf die entschlüsselten Daten sowie deren Länge. Dann werden diese Bytes in ein eigenes Bytearray dec() <\/b>kopiert.<\/p>\n
      So gehören die entschlüsselten Bytes wirklich der VBA-Welt und liegen nicht mehr im von Windows verwalteten Speicher. Anschließend wird der von DPAPI angelegte Speicher mit der API-Funktion LocalFree <\/b>wieder freigegeben, damit es keine Leaks gibt.<\/p>\n
      Nun liegen die entschlüsselten Daten als ANSI-Bytefolge in dec()<\/b>. Um daraus wieder einen normalen VBA-String zu machen, werden die Bytes mit der Funktion StrConv <\/b>zurück in Unicode konvertiert.<\/p>\n
      In tmp <\/b>steht nun genau das, was ProtectString ursprünglich in Bytes gepackt hat, nämlich eine Zeichenkette aus APP_PEPPER <\/b>und der zu verschlüsselnden Zeichenkette. Der letzte Schritt besteht darin, diesen Pepper wieder zu entfernen. Dazu wird geprüft, ob der String tatsächlich mit dem erwarteten Pepper beginnt. <\/p>\n
      Stimmt das Präfix, schneidet Mid$ <\/b>den Pepper ab und gibt nur den Teil nach APP_PEPPER <\/b>zurück – das ist die ursprünglich verschlüsselte Zeichenkette. Passt das Präfix nicht, geht die Funktion auf Nummer sicher und liefert eine leere Zeichenkette zurück; dann sind vermutlich Daten manipuliert oder mit einem anderen Pepper verschlüsselt worden.<\/p>\n
      Falls bereits der API-Aufruf CryptUnprotectData <\/b>scheitert (lRes = 0<\/b>), wird im Else<\/b>-Zweig eine Meldung mit dem Fehlercode im Direktbereich ausgegeben und ebenfalls ein leerer String zurückgeliefert. Auf diese Weise bekommen wir entweder ein korrekt entschlüsseltes Passwort oder eine leere Zeichenkette, wenn irgendetwas mit den Daten oder der Umgebung nicht stimmt.<\/p>\n
      Damit haben wir nun das Werkzeug an der Hand, um die Verschlüsselung und Entschlüsselung durchzuführen.<\/p>\n
      Wahl des Speicherortes für die verschlüsselten Daten<\/h2>\n
      Nun müssen wir noch einen geeigneten Speicherort finden. Hier bevorzugen wir die Registry, und zwar den bereits erwähnten Bereich für VBA\/VB-Anwendungen.<\/p>\n
      Den Bereich finden wir in der Registry wie unter Bild 1 vor. Um hier einen Eintrag unterhalb von VB and VBA Program Settings <\/b>unter SQL Server|Mitarbeiterverwaltung <\/b>anzulegen, deklarieren wir zunächst zwei Konstanten:<\/p>\n
      \"Speichern<\/p>\n
      Bild 1: Speichern der verschlüsselten Benutzerdaten in der Registry<\/span><\/b><\/p>\n
      Public <\/span>Const cStrAppName As String<\/span> = \"SQL Server\"\r\nPublic <\/span>Const cStrSection As String<\/span> = \"Mitarbeiterverwaltung\"<\/pre>\n
      Dann erstellen wir eine Funktion namens SaveAppSetting<\/b>, die genau diese Konstanten verwendet, um darunter Name-Wert-Paare zu hinterlegen. Diese Funktion nutzt die eingebaute Funktion SaveSetting<\/b>, der wir als ersten und zweiten Parameter die Werte der jeweiligen Konstanten übergeben. Als dritten und vierten Wert übergeben wir den Namen und den Wert der Einstellung aus den beiden Parametern strKey <\/b>und strSetting<\/b>:<\/p>\n
      Public Sub <\/span>SaveAppSetting(strKey As String<\/span>, _\r\n         strSetting As String<\/span>)\r\n     SaveSetting cStrAppName, cStrSection, strKey, strSetting\r\nEnd Sub<\/span><\/pre>\n
      Zum Auslesen nutzen wir die Funktion aus Listing 4. Diese nimmt den Namen des auszulesenden Schlüssels entgegen sowie einen Standardwert, den wir hier allerdings nicht nutzen. Die Funktion springt in unserem Fall direkt in den Else<\/b>-Teil der If…Then<\/b>-Bedingung und liest den Wert mit der eingebauten Funktion GetSetting<\/b>, die wiederum die Werte der beiden Konstanten für die übergeordneten Elemente erwartet sowie den auszulesenden Schlüssel. Das Ergebnis schreiben wir in die Variable strTemp<\/b>, der wiederum als Rückgabewert der Funktion dient.<\/p>\n
      Bild 1Public Function GetAppSetting(strKey As String<\/span>, Optional<\/span> strDefault As String<\/span> = \"\", _\r\n         Optional<\/span> bolSaveIfNotExists As Boolean<\/span>) As String<\/span>\r\n     Dim <\/span>strTemp As String<\/span>\r\n     If <\/span>bolSaveIfNotExists Then<\/span>\r\n         strTemp = GetSetting(cStrAppName, cStrSection, strKey)\r\n         If <\/span>Len<\/span>(strTemp) = 0 Then<\/span>\r\n             SaveSetting cStrAppName, cStrSection, strKey, strDefault\r\n             strTemp = strDefault\r\n         End If<\/span>\r\n     Else<\/span>\r\n         strTemp = GetSetting(cStrAppName, cStrSection, strKey, strDefault)\r\n     End If<\/span>\r\n     GetAppSetting = strTemp\r\nEnd Function<\/span><\/pre>\n
      Listing 4: Funktion zum Auslesen von Werten aus der Registry<\/span><\/b><\/p>\n
      Damit die Werte für den Benutzernamen und das Kennwort initial in die Registry geschrieben werden, lesen wir diese im Beispiel mit InputBox<\/b>-Funktionen aus und speichern diese in den Variablen strUsername <\/b>und strPassword<\/b>:<\/p>\n
      Public Sub <\/span>Test_SaveAndEncodeUserAndPasswordInRegistry()\r\n     Dim <\/span>strUsername As String<\/span>\r\n     Dim <\/span>strPassword As String<\/span>\r\n         \r\n     strUsername = InputBox(\"Benutzername:\", _\r\n         \"SQL Server-Anmeldung\")\r\n     strPassword = InputBox(\"Kennwort:\", _\r\n         \"SQL Server-Anmeldung\")\r\n     \r\n     Call<\/span> SaveAndEncodeUsernameAndPasswordInRegistry( _\r\n         strUsername, strPassword)\r\nEnd Sub<\/span><\/pre>\n
      Damit rufen wir eine weitere Funktion auf, welche die eingegebenen Daten verschlüsselt und in die Registry schreibt. Diese nimmt folglich den Benutzernamen und das Kennwort entgegen und deklariert zwei Variablen für die entsprechenden verschlüsselten Zeichenketten.<\/p>\n
      Dann rufen wir für strUsername <\/b>und strPassword <\/b>jeweils die Funktion ProtectString <\/b>auf und speichern das Ergebnis in strUsernameProtected <\/b>beziehungsweise strPasswordProtected<\/b>.<\/p>\n
      Schließlich wird der Inhalt strUsernameProtected <\/b>mit SaveAppSetting <\/b>unter dem Namen Benutzername <\/b>in der Registry gespeichert und strPasswordProtected <\/b>unter dem Namen Kennwort<\/b>:<\/p>\n
      Public Sub <\/span>SaveAndEncodeUsernameAndPasswordInRegistry( _\r\n         strUsername As String<\/span>, strPassword As String<\/span>)\r\n     Dim <\/span>strUsernameProtected As String<\/span>\r\n     Dim <\/span>strPasswordProtected As String<\/span>\r\n     \r\n     strUsernameProtected = ProtectString(strUsername)\r\n     strPasswordProtected = ProtectString(strPassword)\r\n     \r\n     SaveAppSetting \"Benutzername\", strUsernameProtected\r\n     SaveAppSetting \"Kennwort\", strPasswordProtected\r\nEnd Sub<\/span><\/pre>\n
      Um diese Daten auszulesen und beispielsweise beim nächsten Start der Anwendung in die Variablen strUsername <\/b>und strPassword <\/b>zu schreiben, verwenden wir folgende Prozedur. <\/p>\n
      Public Sub <\/span>Test_ReadAndDecodeUsernameAndPasswordFromRegistry()\r\n     Dim <\/span>strUsername As String<\/span>\r\n     Dim <\/span>strPassword As String<\/span>\r\n     If ReadAndDecodeUsernameAndPasswordFromRegistry( _\r\n             strUsername, strPassword) = True<\/span> Then\r\n         Debug.Print<\/span> \"Benutzername: \" & strUsername\r\n         Debug.Print<\/span> \"Kennwort: \" & strPassword\r\n     Else<\/span>\r\n         MsgBox<\/span> \"Ermitteln von Benutzername und \" _\r\n             & \"Kennwort nicht erfolgreich.\"\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
      Diese übergibt der folgenden Funktion namens ReadAndDecodeUsernameAndPasswordFromRegistry <\/b>leere Parameter namens strUsername <\/b>und strPassword<\/b>. Diese liest zunächst die Werte für Benutzername und Kennwort in die Variablen strUsernameProtected <\/b>und strPasswordProtected <\/b>ein. Dann nutzt sie die Funktion UnprotectString<\/b>, um Benutzername und Kennwort aus den verschlüsselten Zeichenketten zu ermitteln:<\/p>\n
      Public Function <\/span>ReadAndDecodeUsernameAndPasswordFromRegistry(strUsername As String<\/span>, strPassword As String<\/span>) As Boolean<\/span>\r\n     Dim <\/span>strUsernameProtected As String<\/span>\r\n     Dim <\/span>strPasswordProtected As String<\/span>\r\n     strUsernameProtected = GetAppSetting(\"Benutzername\")\r\n     strPasswordProtected = GetAppSetting(\"Kennwort\")\r\n     strUsername = UnprotectString(strUsernameProtected)\r\n     strPassword = UnprotectString(strPasswordProtected)\r\n     If Not<\/span> Len<\/span>(strUsername) = 0 _\r\n             And Not<\/span> Len<\/span>(strPassword) = 0 Then\r\n         ReadAndDecodeUsernameAndPasswordFromRegistry _\r\n             = True<\/span>\r\n     End If<\/span>\r\nEnd Function<\/span><\/pre>\n
      Wurden sowohl strUsername <\/b>als auch strPassword <\/b>gefüllt, gibt die Funktion den Wert True <\/b>zurück.<\/p>\n
      Zusammenfassung und Ausblick<\/h2>\n
      Damit haben wir das Handwerkzeug für das Verschlüsseln und Speichern der Zugangsdaten in der Registry und für das Auslesen und Entschlüsseln der Benutzerdaten aus der Registry zusammen.<\/p>\n
      Damit können wir nun beim Start einer Anwendung versuchen, die benötigten Zugangsdaten aus der Registry auszulesen. War das nicht erfolgreich, würde man die Zugangsdaten per InputBox abfragen und dann verschlüsseln und in der Registry speichern. <\/p>\n
      Wurden die Zugangsdaten in der Registry gefunden, liegen diese in den Variablen strUsername<\/b> und strPassword <\/b>vor, die man gezielt dort nutzen wollte, wo Verbindungszeichenfolgen zusammengestellt werden, die für den Zugriff auf den SQL Server per SQL Server-Authentifizierung nötig sind.<\/p>\n
      Die Verschlüsselung ist recht sicher, da wir einen in der Datenbank im Code fest eingebundenen Wert als zusätzlichen Verschlüsselungsfaktor nutzen, sodass niemand, der diesen nicht kennt, den Text ohne größeren Aufwand so schnell wieder entschlüsseln kann.<\/p>\n
      Eine Schwachstelle könnte sein, dass der zusätzliche Faktor “nur” im Code verdrahtet und durch das Umwandeln in eine .accde<\/b> geschützt ist. Es gibt Dienstleister im Internet, die in der Lage sind, dies teilweise rückgängig zu machen.<\/p>\n
      Insgesamt erhalten wir so jedoch eine recht sichere Methode, um Benutzername und Kennwort bei Verwendung der SQL Server-Authentifizierung nicht immer wieder eingeben zu müssen.<\/p>\n
      Sicherer ist es ohnehin, mit der Windows-Authentifizierung zu arbeiten, aber das ist nicht in allen Umgebunden möglich.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Im Artikel “SQL Server: Tabellen verknüpfen” (www.vbentwickler.de\/485) haben wir gezeigt, wie wir die Tabellen eines SQL Servers per ODBC als Tabellenverknüpfung in Access-Datenbanken verfügbar machen können. Dabei gibt es zwei Varianten, um über entsprechende Verbindungszeichenfolgen auf die Tabellen des SQL Servers zuzugreifen: Windows-Authentifizierung und SQL Server-Authentifizierung. Bei der ersten werden die Zugangsdaten über den aktuellen Windows-Benutzer ermittelt. Dieses Kennwort kennt in der Regel nur der Benutzer und die Verknüpfung der Tabellen kann nach seiner Anmeldung am Rechner ohne weitere Interaktion erfolgen. Bei der SQL Server-Authentifizierung jedoch müssen zusätzlich die Zugangsdaten des Benutzers zum SQL Server angegeben werden. Damit der Benutzer diese nicht immer manuell eingeben muss, möchten wir diese sicher speichern – so, dass niemand diese auslesen kann, auch wenn er Zugriff zum Rechner des Benutzers hat. Wie das gelingt, zeigen wir in diesem Artikel.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662025,66052025,44000006],"tags":[],"yst_prominent_words":[],"class_list":["post-55000487","post","type-post","status-publish","format-standard","hentry","category-662025","category-66052025","category-SQL_Server_und_Co"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000487","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/comments?post=55000487"}],"version-history":[{"count":0,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000487\/revisions"}],"wp:attachment":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/media?parent=55000487"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/categories?post=55000487"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/tags?post=55000487"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/yst_prominent_words?post=55000487"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}