{"id":55001315,"date":"2021-08-01T00:00:00","date_gmt":"2021-07-31T10:13:36","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1315"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"SQL_ServerSecurity_Teil_6_ODBCDatenquellen_und_gespeicherte_Kennwoerter","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/SQL_ServerSecurity_Teil_6_ODBCDatenquellen_und_gespeicherte_Kennwoerter\/","title":{"rendered":"SQL Server-Security, Teil 6: ODBC-Datenquellen und gespeicherte Kennwörter"},"content":{"rendered":"

\"\"<\/p>\n

Bernd Jungbluth, Horn – www.berndjungbluth.de<\/p>\n

Die Verbindung von Access zum SQL Server erfolgt in der Regel über ODBC. Hierzu wird vorab eine ODBC-Datenquelle erstellt und unter einem Data Source Name – kurz DSN – gespeichert. Für den Datenzugriff liefert die ODBC-Datenquelle die Bezeichnung des SQL Servers und den Namen der Datenbank. Der Anmeldename und das Kennwort hingegen kommen direkt aus der Access-Applikation. Dabei sind die in Access gespeicherten Anmeldedaten ein nicht zu unterschätzendes Sicherheitsrisiko. Dieser Beitrag beschreibt die Risiken und zeigt Mittel und Wege, wie Sie diese vermeiden können. <\/b><\/p>\n

Warnung<\/h2>\n

Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!<\/p>\n

ODBC-Datenquellen<\/h2>\n

Die Definition einer ODBC-Datenquelle für den Zugriff auf eine SQL Server-Datenbank besteht im Wesentlichen aus den Angaben zum SQL Server, zur Datenbank und den Anmeldedaten. Bei Bedarf lassen sich noch weitere Optionen ergänzen, zum Beispiel zur Verschlüsselung der Datenübertragung. Der ODBC-Datenquelle geben Sie im ODBC-Datenquellen-Editor einen Namen, den sogenannten Data Source Name oder kurz DSN. Mit diesem DSN binden Sie die Tabellen der SQL Server-Datenbank in die Access-Applikation ein und definieren die ODBC-Verbindung der Pass Through-Abfragen.<\/p>\n

In der Beispielumgebung verwendet die ODBC-Datenquelle den DSN WaWi_SQL<\/b>. Sind Sie der Installationsanleitung zur Beispielumgebung gefolgt, enthält der DSN die Anmeldung WaWiPersonal<\/b>. Sollte dies nicht der Fall sein, passen Sie die Anmeldedaten in der ODBC-Datenquelle an. Nur mit dieser Anmeldung haben Sie Zugriff auf alle Tabellen und gespeicherten Prozeduren. Die Installationsanleitung zur Beispielumgebung finden Sie am Ende des Beitrags.<\/p>\n

Der Data Source Name <\/h2>\n

Die ODBC-Datenquelle mit dem DSN WaWi_SQL <\/b>ermöglicht Ihnen den Zugriff auf die Daten der gleichnamigen SQL Server-Datenbank. Dabei ist es Ihnen überlassen, mit welcher Applikation Sie auf die Daten zugreifen. So können Sie die Daten unter anderem in Excel auswerten oder in einer eigenen Access-Datenbank verarbeiten. Der Vorgang für den Datenzugriff ist immer der gleiche. Sie wählen den DSN der ODBC-Datenquelle und geben das Kennwort zur Anmeldung ein. Beides ist in der Access-Applikation WaWi <\/b>nicht mehr notwendig. Hier haben Sie bereits beim Einbinden der Tabellen den DSN WaWi_SQL <\/b>gewählt sowie das Kennwort eingegeben und es in Access gespeichert. Dadurch gehört der DSN mitsamt dem Kennwort zu den Eigenschaften einer eingebundenen Tabelle. Diese können Sie sich in der Entwurfsansicht anschauen.<\/p>\n

Starten Sie die Access-Applikation WaWi <\/b>und öffnen Sie die Tabelle Artikel <\/b>in der Entwurfsansicht. Nach Bestätigen der Meldung mit einem Klick auf Ja <\/b>blenden Sie mit der Taste F4 <\/b>das Eigenschaftenblatt ein. In der Eigenschaft Beschreibung <\/b>sehen Sie die Informationen zur Datenquelle der eingebundenen Tabelle (siehe Bild 1). Neben dem Verweis zum DSN zeigt die Eigenschaft<\/b> noch weitere Angaben:<\/p>\n

\"Beschreibung<\/p>\n

Bild 1: Beschreibung zur Datenquelle<\/span><\/b><\/p>\n

ODBC; DSN=WaWi_SQL; UID=WaWiPersonal; Trusted_Connection=No; APP=Microsoft Office; DATABASE=WaWi_SQL; ; TABLE=dbo.Artikel <\/pre>\n
Mit dem Namen der Datenbank im Parameter DATABASE<\/b>, dem Anmeldenamen unter UID <\/b>sowie der Bezeichnung der Originaltabelle im Parameter TABLE <\/b>enthält die Eigenschaft drei wesentliche Informationen zur externen Datenquelle. Der Eintrag Trusted_Connection=No <\/b>zeigt, dass für die Verbindung eine Anmeldung per SQL Server-Authentifizierung verwendet wird. Das Kennwort zur Anmeldung ist an dieser Stelle aus Sicherheitsgründen nicht zu sehen. Als ergänzende Information ist im Parameter APP <\/b>noch der Name der Applikation aufgeführt. <\/p>\n
Neben den eingebundenen Tabellen bieten Ihnen zwei Pass Through-Abfragen den Zugriff auf die Daten der SQL Server-Datenbank. Diese enthalten in ihren Eigenschaften ebenso die Informationen zum DSN der ODBC-Datenquelle. Öffnen Sie die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>in der Entwurfsansicht und aktivieren Sie dort das Eigenschaftenblatt.<\/p>\n
Hier ist es die Eigenschaft ODBC-Verbindung<\/b>, die Ihnen die Informationen zur Datenquelle zeigt: <\/p>\n
ODBC; DSN=WaWi_SQL; UID=WaWiPersonal; PWD=SicherIn2020!; Trusted_Connection=No; APP=Microsoft Office; DATABASE=WaWi_SQL;<\/pre>\n
Der Eintrag unterscheidet sich zu dem einer eingebundenen Tabelle in zwei Parametern. Zum einen fehlt logischerweise der Verweis zur Originaltabelle und zum anderen ist hier das Kennwort klar und deutlich zu sehen. Im Gegensatz zur Tabelle sind diese Informationen weitaus mehr als eine Beschreibung, sie gehören vielmehr zur Definition der Pass Through-Abfrage. Über die Schaltfläche am Ende der Eigenschaft ODBC-Verbindung <\/b>können Sie diese Definition ändern. Klicken Sie auf die Schaltfläche und wählen Sie im folgenden Dialog in der Registerkarte Computerdatenquelle <\/b>die ODBC-Datenquelle über den DSN WaWi_SQL <\/b>aus. Beim Anmeldedialog verwenden Sie die Anmelde-ID WaWiMa <\/b>mit dem zugehörigen Kennwort SicherIn2020!<\/b>. Es folgt die Frage, ob Sie das Kennwort speichern möchten. Mit einem Klick auf Ja <\/b>übernehmen Sie das Kennwort sowie den Verweis zum DSN in die Eigenschaft ODBC-Verbindung<\/b>. Diese zeigt nun folgenden Inhalt: <\/p>\n
ODBC; DSN=WaWi_SQL; UID=WaWiMa; PWD=SicherIn2020!; Trusted_Connection=No; APP=Microsoft Office; DATABASE=WaWi_SQL;<\/pre>\n
Sie sehen zum einen den DSN WaWi_SQL <\/b>und zum anderen unter UID <\/b>und PWD <\/b>die Anmeldedaten zur Anmeldung WaWiMa<\/b>. Indirekt stehen nun zwei Anmeldungen zur Verfügung, die Anmeldung WaWiPersonal <\/b>im DSN und der direkte Eintrag zur Anmeldung WaWiMa <\/b>in den Eigenschaften der Pass Through-Abfrage. <\/p>\n
Welche Anmeldung wird denn nun beim Datenzugriff verwendet Ein Klick auf Ausführen<\/b> beantwortet diese Frage. Anstelle der Geburtstage der Mitarbeiter sehen Sie eine Fehlermeldung. Das ist korrekt und es entspricht der aktuell gültigen Rechtevergabe der Beispielumgebung. Der Anmeldung WaWiMa <\/b>wird das Ausführen der gespeicherten Prozedur pSelectGeburtstagsliste <\/b>verweigert. Für den Datenzugriff sind also die Anmeldedaten der Pass Through-Abfrage maßgebend. Die im DSN gespeicherten Anmeldedaten hingegen spielen dabei keine Rolle. Eine Abweichung der Anmeldedaten ist auch bei eingebundenen Tabellen möglich. Dazu geben Sie beim Einbinden der Tabellen nach der Auswahl der ODBC-Datenquelle einfach andere Anmeldedaten an. <\/p>\n
Gerade solche abweichenden Konfigurationen führen schnell zu einer falschen Bewertung des Zugriffsschutzes. So könnte ein Blick in den DSN eine Anmeldung mit geringen Zugriffsrechten zeigen, in Access jedoch wird eine andere Anmeldung mit weitaus höheren Rechten verwendet. Also gerade umgekehrt zum aktuellen Beispiel, dafür aber mit schlimmeren Folgen. Der Anwender agiert mit mehr Rechten als der Administrator dies nach einem Blick in den DSN vermutet. Wenn das kein gutes Argument ist, in Zukunft auf den DSN zu verzichten!<\/p>\n
Ohne Data Source Name – DSN-less<\/h2>\n
Aktuell stellt der DSN WaWi_SQL <\/b>die Bezeichnungen zum verwendeten Treiber, zu Ihrem SQL Server und zur Datenbank bereit. Für einen Datenzugriff werden diese Informationen mit den in Access gespeicherten Anmeldedaten ergänzt und in einer Verbindungszeichenfolge zusammengefasst. Diese ebenso als Connection-String bekannte Verbindungszeichenfolge ist die Basis für die Verbindung zur externen Datenquelle. Sie beinhaltet im Grunde genommen die Wegbeschreibung, in diesem Fall die Route zur Ihrem SQL Server und dort zur Datenbank WaWi_SQL<\/b>. Dabei enthält sie eigentlich nur Informationen, die Sie ebenso gut direkt in Access speichern können. Sie kennen den verwendeten ODBC-Treiber, Ihren SQL Server und die Datenbank. Es fehlt Ihnen nur noch die Syntax der Verbindungszeichenfolge.<\/p>\n
Die Syntax lässt sich recht einfach ermitteln. Dazu erstellen Sie eine weitere ODBC-Datenquelle, dieses Mal jedoch als Datei-DSN. Öffnen Sie den ODBC-Datenquellen-Editor in der bewährten Art und Weise über die Windows-Taste und der Eingabe ODBC<\/b>. Das Suchergebnis zeigt zwei Einträge. Hier wählen Sie je nach installierter Access-Version den Eintrag ODBC-Datenquellen (32-Bit) <\/b>oder ODBC-Datenquellen (64-Bit)<\/b>.<\/p>\n
Im ODBC-Datenquellen-Administrator wechseln Sie zur Registerkarte Datei-DSN<\/b>. Dort klicken Sie auf Hinzufügen <\/b>und wählen im folgenden Dialog den Treiber ODBC Driver 17 for SQL Server <\/b>aus. Informationen zu diesem Treiber finden Sie in der Installationsanleitung der Beispielumgebung. Nach einem Klick auf Weiter <\/b>legen Sie den Speicherort und Dateinamen fest. Vielleicht nennen Sie die Datei WaWi_SQL <\/b>und speichern sie im Ordner der Beispieldateien. Bestätigen Sie die bisherigen Angaben mit einem Klick auf Weiter <\/b>und anschließend mit der Schaltfläche Fertig stellen<\/b>. <\/p>\n
Jetzt beginnt die eigentliche Definition der ODBC-Datenquelle. Dabei geben Sie im ersten Schritt im Eingabefeld Server <\/b>den Namen Ihres SQL Servers ein. In Schritt 2 legen Sie mit der dritten Option die Anmeldung per SQL Server-Authentifizierung fest und ergänzen diese Auswahl mit dem Anmeldenamen WaWiPersonal <\/b>im Eingabefeld Anmelde-ID <\/b>und dem zugehörigen Kennwort im Eingabefeld Kennwort<\/b>. Die Datenbank WaWi_SQL <\/b>wählen Sie in Schritt 3 aus, nachdem Sie dort die Option Die Standarddatenbank ändern auf <\/b>aktiviert haben. Mit einem Klick auf Weiter <\/b>und anschließend auf Fertig stellen <\/b>schließen Sie die Definition der ODBC-Datenquelle ab. Es folgt der Dialog zum Test der Verbindung. Nach einem letzten Klick auf OK <\/b>beenden Sie das Erstellen der Datei-DSN.<\/p>\n
Nun öffnen Sie die Datei-DSN mit einem Texteditor. Sie sehen die einzelnen Parameter zur Verbindungszeichenfolge (siehe Bild 2). Bevor Sie diese Informationen in Access nutzen können, sind noch ein paar Anpassungen notwendig. Als Erstes löschen Sie die eckigen Klammern rund um den Begriff ODBC<\/b>. Danach entfernen Sie die Einträge der Parameter TrustServerCertificate<\/b>, WSID <\/b>und APP<\/b>. Jetzt fügen Sie an jedes Zeilenende ein Semikolon ein und löschen den Zeilenumbruch. Als Ergebnis sehen Sie die Verbindungszeichenfolge in einer einzelnen Zeile. Diese ergänzen Sie mit dem Parameter PWD <\/b>und dem Kennwort SicherIn2020!<\/b>. Mit Ausnahme des Werts im Parameter Server <\/b>müsste Ihre Verbindungszeichenfolge nun der in Bild 3 entsprechen.<\/p>\n
\"Die<\/p>\n
Bild 2: Die Verbindungszeichenfolge<\/span><\/b><\/p>\n
\"Inhalt<\/p>\n
Bild 3: Inhalt einer Datei-DSN<\/span><\/b><\/p>\n
Kopieren Sie die Verbindungszeichenfolge und gehen Sie zurück zur Access-Applikation WaWi<\/b>. Dort öffnen Sie die Pass Through-Abfrage ptSelectGeburtstagsliste <\/b>in der Entwurfsansicht und überschreiben den Inhalt der Eigenschaft ODBC-Verbindung <\/b>mit der kopierten Verbindungszeichenfolge.  Speichern Sie die Änderungen und klicken Sie auf Ausführen<\/b>. Als Ergebnis sehen Sie die Geburtstage der Mitarbeiter – und das ohne DSN.<\/p>\n
Wenn Sie schon dabei sind, ändern Sie doch direkt noch die Pass Through-Abfrage ptSelectAnsprechpartnerZuMitarbeiter<\/b>. Überschreiben Sie hier ebenfalls die Eigenschaft ODBC-Verbindung <\/b>mit dem Inhalt Ihrer Datei-DSN. Glückwunsch! Ab jetzt erfolgt der Datenzugriff der Pass Through-Abfragen ohne Verweis zu einem DSN. Beide arbeiten nun DSN-less. Alle für den Datenzugriff notwendigen Informationen sind direkt in den Pass Through-Abfragen gespeichert. Leider enthält die Eigenschaft ODBC-Verbindung <\/b>immer noch das Kennwort im Klartext. Doch dazu später mehr. <\/p>\n
Vorher soll das Prinzip DSN-less <\/b>noch bei den eingebundenen Tabellen angewendet werden. Nur ist das hier nicht so einfach wie bei den Pass Through-Abfragen. Zwar enthält eine eingebundene Tabelle ebenfalls den Verweis zum DSN, dieser lässt sich dort aber nicht ändern.<\/p>\n
Die Entwurfsansicht eingebundener Tabellen ist schreibgeschützt. Zudem zeigt die Eigenschaft Beschreibung <\/b>lediglich eine Dokumentation zur Datenquelle. Der eigentliche Speicherort der Verbindungszeichenfolge ist die Spalte Connect <\/b>in der Access-Systemtabelle MSysObjects<\/b>. Dort gibt es zu jeder eingebundenen Tabelle den folgenden Eintrag – und an dieser Stelle sogar mit lesbarem Kennwort.<\/p>\n
DSN=WaWi_SQL; UID=WaWiPersonal; PWD=SicherIn2020!; Trusted_Connection=No; APP=Microsoft Office; DATABASE=WaWi_SQL;<\/pre>\n
Die Daten sind hier ebenfalls schreibgeschützt. Die Verbindungszeichenfolge können Sie nur ändern, indem Sie die Tabellen neu einbinden. Doch da gibt es gleich die nächste Hürde. Die Dialoge über den Menüpunkt Externe Daten <\/b>bieten keine Möglichkeit, die Tabellen ohne einen DSN einzubinden. In den Access-Versionen 2019 und 365 hat der Tabellenverknüpfungs-Manager jedoch eine Lösung für Sie.<\/p>\n
DSN-less per Tabellenverknüpfungs-Manager <\/h2>\n
Mit dem neuen Tabellenverknüpfungs-Manager lässt sich der DSN recht einfach mit einer eigenen Verbindungszeichenfolge ersetzen. Starten Sie den Tabellenverknüpfungs-Manager über das Ribbon Externe Daten<\/b>, aktivieren Sie dort den Eintrag ODBC <\/b>(siehe Bild 4) und klicken Sie auf Bearbeiten<\/b>.<\/p>\n
\"Der<\/p>\n
Bild 4: Der Tabellenverknüpfungs-Manager<\/span><\/b><\/p>\n
Im folgenden Dialog überschreiben Sie das Eingabefeld Verbindungszeichenfolge <\/b>mit dem Inhalt Ihrer Datei-DSN (siehe Bild 5) und bestätigen dies mit einem Klick auf Speichern<\/b>. Zurück im Tabellenverknüpfungs-Manager klicken Sie auf Aktualisieren<\/b>. Das war es schon. Sie können den Tabellenverknüpfungs-Manager wieder schließen. <\/p>\n
\"DSN-less<\/p>\n
Bild 5: DSN-less per Tabellenverknüpfungs-Manager<\/span><\/b><\/p>\n
Der Datenzugriff über eine eingebundene Tabelle erfolgt jetzt ebenfalls ohne DSN. Testen Sie es einmal. Öffnen Sie die Tabelle Kunden <\/b>in der Entwurfsansicht und schauen Sie in die Eigenschaft Beschreibung<\/b>. Dort sehen Sie Ihre Verbindungszeichenfolge. Das Kennwort wird aus Sicherheitsgründen weiterhin nicht angezeigt. <\/p>\n
Der neue Tabellenverknüpfungs-Manager macht vieles einfacher. Sollten Sie noch eine ältere Version von Access verwenden, bleibt Ihnen diese Möglichkeit verwehrt. Alternativ können Sie die Tabellen per VBA einbinden.<\/p>\n
DSN-less per VBA<\/h2>\n
Zum Einbinden der Tabellen mit einer eigenen Verbindungszeichenfolge bietet Ihnen die neue Version der Access-Applikation WaWi <\/b>die Funktion fTabellenEinbinden<\/b>. Schauen Sie sich einmal die Funktion an. Sie finden sie im Modul Tabellen<\/b>.<\/p>\n
Die Funktion legt zuerst die Verbindungszeichenfolge fest. Dies erfolgt mit einer weiteren Funktion namens fOdbcPerFunction<\/b>.<\/p>\n
Mit einem Rechtsklick auf den Funktionsnamen und anschließender Auswahl des Eintrags Definition <\/b>wechseln Sie direkt zur Funktion im Modul ODBC<\/b>. Hier überschreiben Sie den Eintrag Ihre Verbindungszeichenfolge mit dem Inhalt Ihrer Datei-DSN (siehe Bild 6). Ein erneuter Rechtsklick und der Auswahl des Eintrags Letzte Position<\/b> bringt Sie wieder zurück zur Funktion fTabellenEinbinden<\/b>. <\/p>\n
\"Die<\/p>\n
Bild 6: Die Funktion fOdbcPerFunction<\/span><\/b><\/p>\n
Dort wird Ihre Verbindungszeichenfolge in der Variablen strODBC <\/b>gespeichert. Anschließend löschen die folgenden Zeilen alle eingebundenen Tabellen und aktualisieren danach den neuen Stand der Tabellendefinitionen:<\/p>\n
For Each tdf In CurrentDb.TableDefs\r\n     If <\/span>Left<\/span>(tdf.Connect, 5) = \"ODBC;\" Then<\/span>\r\n         CurrentDb.TableDefs.Delete tdf.Name\r\n     End If<\/span>\r\nNext<\/span>\r\nCurrentDb.TableDefs.Refresh<\/pre>\n
Es folgt das Neueinbinden der Tabellen. Die Bezeichnungen der Tabellen liefert eine temporäre Pass Through-Abfrage. <\/p>\n
Set<\/span> ptqry = CurrentDb.CreateQueryDef(\"\")\r\nWith<\/span> ptqry\r\n     .Connect = strODBC\r\n     .SQL = \" SELECT [name] As <\/span>Tabelle, SCHEMA_NAME( [schema_id]) + ''.'' + [name] As <\/span>Originaltabelle  FROM sys.objects WHERE [type] = ''U'';\"\r\n     .ReturnsRecords = True<\/span>\r\nEnd With<\/span><\/pre>\n
Die Pass Through-Abfrage verwendet als Verbindungszeichenfolge den Inhalt der Variablen strODBC <\/b>und führt somit auf Ihrem SQL Server in der Datenbank WaWi_SQL <\/b>diese SQL-Anweisung aus: <\/p>\n
SELECT [name] As <\/span>Tabelle, SCHEMA_NAME([schema_id]) + ''.''  + [name] As <\/span>Originaltabelle  FROM sys.objects WHERE [type] = ''U'';<\/pre>\n
Die SELECT<\/b>-Anweisung ermittelt in der Tabelle sys.objects <\/b>alle Systemobjekte vom Typ U<\/b>. U <\/b>steht an dieser Stelle für User<\/b>-Table und kennzeichnet die vom Datenbankentwickler erstellten Tabellen. Das Ergebnis umfasst zwei Spalten, den Namen der Tabelle ohne Schema und den Namen der Tabelle mit Schema. <\/p>\n
Sie möchten sich diese Daten einmal anschauen Dann öffnen Sie das SQL Server Management Studio und melden Sie sich dort mit der Anmeldung WaWiPersonal <\/b>an. Eventuell müssen Sie hierzu den Anmeldetyp in SQL Server-Authentifizierung <\/b>ändern (siehe Bild 7).<\/p>\n
\"Die<\/p>\n
Bild 7: Die Anmeldung am SSMS<\/span><\/b><\/p>\n
Nach der Anmeldung erweitern Sie den Objekt-Explorer, markieren die Datenbank WaWi_SQL <\/b>mit der rechten Maustaste und wählen aus dem Kontextmenü den Eintrag Neue Abfrage<\/b>. Sie erhalten eine leere Registerkarte, in der Sie die SELECT<\/b>-Anweisung eingeben und dann mit der Taste F5 <\/b>ausführen. Das Ergebnis listet alle Tabellen auf, zu denen die Anmeldung WaWiPersonal <\/b>entsprechende Zugriffsrechte besitzt (siehe Bild 8). Dabei enthält die Spalte Originaltabelle <\/b>neben dem Tabellennamen auch den Namen des Schemas. Das ist in der aktuellen Beispieldatenbank das Standardschema dbo<\/b>. Welche Vorteile Sie bei der Verwendung verschiedener Schemata haben, erfahren Sie in einer der nächsten Ausgaben.<\/p>\n
\"Die<\/p>\n
Bild 8: Die Tabellen der Anmeldung WaWiPersonal<\/span><\/b><\/p>\n
Die Definition der temporären Pass Through-Abfrage endet mit der Zuweisung ReturnsRecords = True<\/b>. Diese sorgt für die Rückgabe der ermittelten Daten zur Weiterverarbeitung in VBA. Die nächste Anweisung erstellt das Recordset rsObjekte <\/b>und füllt es mit den Daten der Pass Through-Abfrage:<\/p>\n
Set<\/span> rsObjekte = ptqry.OpenRecordset<\/pre>\n
Zu jedem Eintrag des Recordsets wird dann eine neue Tabellendefinitionen erstellt. <\/p>\n
Do While<\/span> Not<\/span> rsObjekte.EOF\r\n     ''Tabelle einbinden\r\n     On Error GoTo<\/span> 0\r\n     Set<\/span> tdf = CurrentDb.CreateTableDef(rsObjekte!Tabelle,  dbAttachSavePWD, rsObjekte!Originaltabelle,  strODBC)\r\n     CurrentDb.TableDefs.Append tdf\r\n     CurrentDb.TableDefs(rsObjekte!Tabelle).RefreshLink\r\n     rsObjekte.MoveNext<\/span>\r\nLoop<\/span><\/pre>\n
Die Parameter der Anweisung CurrentDb.CreateTableDef <\/b>beinhalten alle wichtigen Informationen für den späteren Datenzugriff. Dabei übergibt der Parameter rsObjekte!Tabelle <\/b>den Namen, unter dem die eingebundene Tabelle später in Access zu sehen ist, während der Parameter dbAttachSavePWD <\/b>das Kennwort der Anmeldedaten in Access speichert. Die Bezeichnung der Originaltabelle liefert der Parameter rsObjekte!Originaltabelle <\/b>und den Weg dorthin beschreibt die Verbindungszeichenfolge im Parameter strODBC<\/b>. <\/p>\n
Mit den nächsten beiden Anweisungen wird die Tabellendefinition der Access-Applikation hinzugefügt und die Informationen zur neu eingebundenen Tabelle aktualisiert:<\/p>\n
CurrentDb.TableDefs.Append tdf\r\nCurrentDb.TableDefs(rsObjekte!Name). RefreshLink<\/pre>\n
Dieser Vorgang wiederholt sich nun für alle Tabellen, die mit der Pass Through-Abfrage ermittelt wurden. Dabei spielt die Verbindungszeichenfolge der Pass Through-Abfrage eine wichtige Rolle. Mit den Anmeldedaten der Anmeldung WaWiPersonal <\/b>werden alle Tabellen der Datenbank eingebunden. Bei der Anmeldung WaWiMa <\/b>hingegen sind es nur acht Tabellen. Im aktuellen Berechtigungskonzept ist dieser Anmeldung der Zugriff auf die Tabellen Bewerber<\/b>, Mitarbeiter <\/b>und Stellen <\/b>verweigert – und ohne Rechte kann die Pass Through-Abfrage diese Tabellen nicht ermitteln. Die Funktion bindet also nur die Tabellen ein, zu denen die dabei verwendete Anmeldung entsprechende Zugriffsrechte besitzt. Ein nicht zu unterschätzender Sicherheitsaspekt.<\/p>\n
<\/p>\n
Nachdem alle Tabellen der Datenbank hinzugefügt sind, wird der Navigationsbereich aktualisiert und die offenen Objekte geschlossen:<\/p>\n
Application.RefreshDatabaseWindow\r\nrsObjekte.Close\r\nSet<\/span> rsObjekte = Nothing\r\nptqry.Close\r\nSet<\/span> ptqry = Nothing<\/pre>\n
Soweit die Theorie, es folgt die Praxis. Dazu aktivieren Sie per Tastenkombination Strg + G <\/b>den VBA-Direktbereich und führen dort die Funktion fTabellenEinbinden <\/b>aus. Anschließend wechseln Sie zum Navigationsbereich in Access und öffnen die Tabelle Kunden <\/b>in der Entwurfsansicht. Die Eigenschaft Beschreibung <\/b>enthält jetzt Ihre Verbindungszeichenfolge. Ein Klick auf die Datenblattansicht liefert Ihnen die Daten der Kunden. Sie sehen, der Datenzugriff über eingebundene Tabellen funktioniert auch ohne DSN. Wodurch die ODBC-Datenquelle WaWi_SQL <\/b>für die Beispielapplikation entbehrlich ist. Sie kann gelöscht werden. Natürlich nur, wenn Sie diese nicht in anderen Applikationen wie Excel oder weiteren Access-Datenbanken verwenden. <\/p>\n
Für eine Installation der Access-Applikation WaWi <\/b>auf einem neuen Rechner ist die ODBC-Datenquelle nicht mehr erforderlich. In Zukunft müssen Sie dort lediglich den ODBC-Treiber und die Access-Applikation installieren. Das reduziert nicht nur den Arbeits- und Pflegeaufwand, es schließt gleich noch eine Sicherheitslücke. Denn ohne die ODBC-Datenquelle sind auch keine unerwünschten Datenzugriffe möglich. Apropos Sicherheitslücke: Ihre Datei-DSN enthält das Kennwort im Klartext und da Sie die Datei nicht mehr benötigen, sollten Sie diese umgehend löschen.<\/p>\n
Das Kennwort zur Anmeldung<\/h2>\n
Kennwort ist ein gutes Stichwort. Aktuell ist das Kennwort zur Anmeldung in der Funktion fObdcPerFunction <\/b>hinterlegt und somit für jeden sichtbar, der in den Quellcode schauen darf. Das muss nicht sein, denn das Kennwort lässt sich recht einfach verstecken. <\/p>\n
Die Access-Applikation WaWi <\/b>arbeitet bereits mit einem versteckten Kennwort. Im Formular Artikel <\/b>erfolgt die Datenermittlung per ADO. Die hierfür notwendige Verbindungszeichenfolge setzt die Funktion fAdoPerTabelle <\/b>zusammen. Diese ermittelt in der lokalen Tabelle ADO <\/b>die Bezeichnung des SQL Servers, den Namen der Datenbank und die Anmeldedaten.<\/p>\n
Die Tabelle ist als Systemobjekt definiert. Dadurch ist sie zum einen schreibgeschützt und zum anderen im Navigationsbereich nicht ohne weiteres zu sehen. Zusätzlich ist das Kennwort in der Tabelle mit dem Eingabeformat Kennwort <\/b>maskiert und daher in der Datenblattansicht nicht lesbar.<\/p>\n
Ein perfektes Szenario, das sich ebenso gut zum Einbinden der Tabellen per ODBC verwenden lässt. Dann ist allerdings der Name ADO <\/b>nicht mehr so treffend. Aus diesem Grund wurde die Tabelle in Datenquellen <\/b>umbenannt. <\/p>\n
Um das Einbinden der Tabellen an die neue Vorgehensweise anzupassen, müssen Sie lediglich die Funktion zum Erstellen der Verbindungszeichenfolge austauschen. So wird in der Funktion fTabellenEinbinden <\/b>aus der Zeile strODBC = fOdbcPerFunction <\/b>die Zeile strODBC = fOdbcPerTabelle <\/b>(siehe Bild 9). Die Funktion fOdbcPerTabelle <\/b>ermittelt in der Tabelle Datenquellen<\/b> die Informationen zur Verbindung und erstellt die Verbindungszeichenfolge. Alles weitere bleibt unverändert.<\/p>\n
\"Einbinden<\/p>\n
Bild 9: Einbinden mit fOdbcPerTabelle<\/span><\/b><\/p>\n
Die Bezeichnung Ihres SQL Servers haben Sie bereits bei der Installation der Beispielumgebung in die Tabelle Datenquellen<\/b> eingetragen. Sie können die Änderung also direkt testen. Dazu führen Sie im VBA-Direktbereich die Funktion fTabellenEinbinden <\/b>erneut aus. Anschließend klicken Sie auf die einzelnen Schaltflächen im Formular Start<\/b>. Da Sie die Anmeldung WaWiPersonal <\/b>verwenden, liefert Ihnen jede Schaltfläche die entsprechenden Daten. <\/p>\n
Das Kennwort liegt jetzt geschützt in einer versteckten Tabelle. So richtig vollständig ist der Kennwortschutz aber noch nicht. Dazu müssen Sie erst noch die Funktion fOdbcPerFunction <\/b>löschen. Denn dort ist das Kennwort immer noch zu sehen. <\/p>\n
Die gespeicherte Anmeldung<\/h2>\n
Für den Datenzugriff per ADO und für das Einbinden der Tabellen mag das Kennwort zwar gut versteckt sein. Nach dem Einbinden der Tabellen steht es aber wieder lesbar in der Spalte Connect <\/b>der Systemtabelle MSysObjects<\/b>. Eine einfache DLookup<\/b>-Anweisung auf diese Systemtabelle liefert Ihnen die Verbindungszeichenfolge inklusive Kennwort (siehe Bild 10). In der Eigenschaft ODBC-Verbindung <\/b>der beiden Pass Through-Abfragen ist es ebenfalls zu sehen. Aktuell lässt sich das nicht vermeiden.<\/p>\n
\"Das<\/p>\n
Bild 10: Das Kennwort zur eingebundenen Tabelle<\/span><\/b><\/p>\n
Für einen direkten Datenzugriff ist das gespeicherte Kennwort sowohl bei den eingebundenen Tabellen wie auch bei den Pass Through-Abfragen erforderlich. Ohne gespeichertes Kennwort müsste es beim Öffnen einer eingebundenen Tabelle wie beim Ausführen einer Pass-Through-Abfrage erst einmal vom Anwender eingegeben werden. Es ist eher unwahrscheinlich, dass bei dieser Vorgehensweise das Kennwort besser geschützt ist. <\/p>\n
Dennoch ist es kein schlechter Gedanke, auf das Speichern des Kennworts zu verzichten. Access verlangt zwar dann beim Zugriff auf die Daten die Eingabe des Kennworts, dies allerdings nur beim ersten Datenzugriff nach dem Start der Access-Applikation. Mit dem eingegebenen Kennwort wird die Verbindungszeichenfolge ergänzt und anschließend die Verbindung zum SQL Server hergestellt. Genau diese Verbindung speichert Access und verwendet sie für alle folgenden Datenzugriffe. <\/p>\n
In der aktuellen Version wird das Kennwort noch beim Einbinden der Tabellen gespeichert. Um dies zu ändern, wechseln Sie zur Funktion fTabellenEinbinden <\/b>und ersetzen in der Anweisung den Parameter dbAttachSavePWD <\/b>mit dbAppendOnly <\/b>(siehe Bild 11):<\/p>\n
\"Einbinden<\/p>\n
Bild 11: Einbinden der Tabellen ohne Kennwort<\/span><\/b><\/p>\n
Set<\/span> tdf = CurrentDb.CreateTableDef(rsObjekte!Name, dbAttachSavePWD, rsObjekte!Tabelle, strODBC)<\/pre>\n
Danach führen Sie im VBA-Direktbereich die Funktionen fTabellenEinbinden <\/b>und fPassThroughVerbindungen <\/b>aus. Die Funktion fPassThroughVerbindungen <\/b>kennen Sie bereits aus der Installationsanleitung der Beispielumgebung. Sie überträgt die Verbindungszeichenfolge einer eingebundenen Tabelle in die Eigenschaften der Pass Through-Abfragen. Nachdem Sie die beiden Funktionen ausgeführt haben, ist das Kennwort weder in den Eigenschaften der eingebundenen Tabellen noch in denen der Pass Through-Abfragen gespeichert. Jetzt starten Sie Access neu und öffnen die Tabelle Kunden <\/b>mit einem Doppelklick. Sie erhalten den Anmeldedialog aus Bild 12.<\/p>\n
\"Der<\/p>\n
Bild 12: Der Anmelde-Dialog beim ersten Datenzugriff<\/span><\/b><\/p>\n
Hier tragen Sie den Anmeldenamen WaWiPersonal <\/b>mitsamt dem zugehörigen Kennwort ein und bestätigen die Eingabe mit einem Klick auf OK<\/b>. Mit diesen Anmeldedaten wird jetzt eine Verbindung zum SQL Server hergestellt und die Daten der Tabelle Kunden <\/b>ermittelt. Das Ergebnis sehen Sie in der Datenblattansicht. Access verwendet die eben erstellte Verbindung nun für alle weiteren Datenzugriffe. Ein Doppelklick auf die Tabelle Mitarbeiter <\/b>liefert Ihnen ebenso Daten wie ein Doppelklick auf die Pass Through-Abfrage ptSelectGeburtstagsliste<\/b>.<\/p>\n
So weit so gut. Nur geht die Verbindung bei einem Neustart von Access verloren. Starten Sie die Access-Applikation WaWi <\/b>noch einmal und klicken Sie auf die Schaltfläche Artikel<\/b>. Wider Erwarten sehen Sie direkt die Daten der Artikel<\/b>. Eine Anmeldung wurde nicht verlangt. Ist die Verbindung doch noch gespeichert Nein. Die Eingabe der Anmeldedaten ist in diesem Fall nicht notwendig. Im Formular Artikel <\/b>erfolgt der Datenzugriff per ADO. Alle erforderlichen Informationen für eine Verbindung per ADO liefert die lokale Tabelle Datenquellen<\/b>. <\/p>\n
Die Kennworteingabe wird nur bei einem Datenzugriff über eine eingebundene Tabelle oder einer Pass Through-Abfrage verlangt, wie ein Klick auf die Schaltfläche Aufträge <\/b>beweist: Hier erhalten Sie den erwarteten Anmeldedialog. Erst nach der Eingabe der Anmeldedaten sehen Sie die Aufträge. Danach liefern Ihnen alle anderen Schaltflächen die gewünschten Daten und das ohne weitere Anmeldungen. <\/p>\n
Soweit ist das doch recht komfortabel. Sie müssen nur noch diesen Anmeldedialog loswerden. Kein Problem. Alles, was Sie dazu benötigen ist ein Anmeldevorgang am SQL Server kurz nach dem Start der Access-Applikation. Ein einfacher kleiner Zugriff auf den SQL Server reicht vollkommen aus und sei es nur zum Ermitteln der aktuellen Uhrzeit. Sie können die erste Verbindung natürlich auch für etwas Sinnvolleres nutzen. Warum nicht zum Einbinden der Tabellen Dann erfolgt der erste Datenzugriff immer mit der temporären Pass Through-Abfrage, die in der SQL Server-Datenbank die Bezeichnungen der einzubindenden Tabellen ermittelt. Die hierzu erforderliche Verbindungszeichenfolge ergibt sich aus den Daten der lokalen Tabelle Datenquellen<\/b>. So wie es beim Datenzugriff per ADO der Fall ist. Die dabei erstellte Verbindung liefert Ihnen nicht nur die Tabellen, die den Zugriffsrechten der verwendeten Anmeldung entsprechen, vielmehr steht sie danach mit denselben Rechten für alle weiteren Datenzugriffe zur Verfügung.<\/p>\n
Das ist doch einen Test wert. Starten Sie die Access-Applikation WaWi <\/b>erneut und wechseln Sie direkt zum VBA-Direktbereich. Dort führen Sie die Funktionen fTabellenEinbinden <\/b>und fPassThroughVerbindungen <\/b>aus. Danach wechseln Sie zum Start<\/b>-Formular und klicken auf die Schaltfläche Mitarbeiter<\/b>. Sie sehen die Daten der Mitarbeiter – und das ohne eine Kennworteingabe. Perfekt. Jetzt müssen Sie nur noch dafür sorgen, dass die Funktion fTabellenEinbinden <\/b>immer als erstes ausgeführt wird. Am besten abhängig vom angemeldeten Anwender. Das lässt sich mit recht wenig Aufwand realisieren. <\/p>\n
Doch vorher noch ein Hinweis zur gespeicherten Verbindung. Denn dieser Vorteil kann ebenso gut ein Nachteil sein. Möglicherweise bietet Ihre Access-Applikation einen Anmeldedialog. Über diesen melden sich mehrere Anwender abwechselnd mit Benutzernamen und Kennwort an, ohne dabei Access neu zu starten. Nach dem Anmeldevorgang werden die Tabellen eingebunden und durch eine Benutzersteuerung die entsprechenden Formulare, Menüs und Schaltflächen angeboten. Nun mag die Benutzersteuerung dafür sorgen, dass der Anwender sich im richtigen Bereich der Applikation bewegt. Die Datenzugriffe erfolgen jedoch immer noch mit den Rechten der Anmeldung, die bei der ersten Verbindung zum SQL Server verwendet wurde. Ein tatsächlicher Wechsel der Anmeldung und somit der Zugriffsrechte findet erst nach einem Neustart von Access statt. Dabei reicht das einfache Schließen der Datenbank innerhalb einer aktiven Access-Session nicht aus. Sie müssen Access komplett beenden. Erst dann existiert die Verbindung nicht mehr. Leider lässt sich dieser Neustart nicht umgehen. Aktuell ist keine Methode bekannt, mit der eine bestehende Verbindung getrennt und mit anderen Anmeldedaten wieder neu erstellt werden kann. <\/p>\n
Eine Applikation für alle<\/h2>\n
Der erste Datenzugriff nach dem Start der Access-Applikation soll beim Einbinden der Tabellen erfolgen und zwar mit der Anmeldung, die zum Benutzerkonto des aktuellen Anwenders passt. Diese Funktionalität bietet die Access-Applikation WaWi v2<\/b>. Die Erweiterungen dieser Version sind schnell beschrieben. Gekennzeichnet durch die Spalte DatenquellenID <\/b>enthält die Tabelle Datenquellen <\/b>jetzt die Anmeldedaten beider Anmeldungen (siehe Bild 13).<\/p>\n
\"Die<\/p>\n
Bild 13: Die Tabelle Datenquellen<\/span><\/b><\/p>\n
In der neuen lokalen Tabelle Benutzer <\/b>sind die Benutzerkonten der Anwender hinterlegt und über die Spalte DatenquellenID <\/b>einer Datenquelle und somit einer Anmeldung zugeordnet (siehe Bild 14). Die Tabelle Benutzer <\/b>ist wie die Tabelle Datenquellen <\/b>als Systemobjekt definiert.<\/p>\n
\"Die<\/p>\n
Bild 14: Die Tabelle Benutzer<\/span><\/b><\/p>\n
Das Erstellen der Verbindungszeichenfolge findet weiterhin in den Funktionen fOdbcPerTabelle <\/b>und fAdoPerTabelle <\/b>statt. Jedoch werden die Daten zur Anmeldung nicht mehr direkt in der Tabelle Datenquellen <\/b>ermittelt, sondern mit der Access-Abfrage Anmeldedaten (siehe Bild 15). Dort liefert die Funktion fOSUserName <\/b>das Benutzerkonto des angemeldeten Anwenders und filtert mit diesem Wert die Einträge der Tabelle Benutzer<\/b>. Das Ergebnis wird über die Verknüpfung zur Tabelle Datenquellen <\/b>mit den zugehörigen Anmeldedaten ergänzt. In der Beispielumgebung ist das die Anmeldung WaWiMa <\/b>für Frau Bienlein und WaWiPersonal <\/b>für Herrn Stromberg.<\/p>\n
\"Die<\/p>\n
Bild 15: Die Abfrage Anmeldedaten<\/span><\/b><\/p>\n
Nach dem Start der Access-Applikation wird automatisch das unsichtbare Formular Verbindung <\/b>geöffnet. Dessen Ereignis Form_Open <\/b>führt die Funktion fTabellenEinbinden <\/b>mitsamt der Funktion fPassThroughVerbindungen <\/b>aus. Die hierzu gültige Verbindungszeichenfolge liefert die Funktion fOdbcPerTabelle <\/b>anhand der Abfrage Anmeldedaten<\/b>. So ist sichergestellt, dass nur die Tabellen eingebunden werden, mit denen der Anwender tatsächlich arbeiten darf. Nach dem Einbinden der Tabellen und dem Anpassen der Pass Through-Abfragen wird das Formular Start <\/b>geöffnet und das unsichtbare Formular Verbindung geschlossen.<\/p>\n
Bevor Sie nun das neue Anmeldeverfahren testen, müssen Sie zuerst die Daten der Tabellen Benutzer <\/b>und Datenquellen <\/b>an Ihre Umgebung anpassen. Starten Sie die Access-Applikation WaWi v2 <\/b>und öffnen Sie die beiden Tabellen. Der Einfachheit halber sind diese noch nicht als Systemobjekte definiert. In der Tabelle Benutzer <\/b>geben Sie Ihr Benutzerkonto ein. Die Anmeldedaten mit den höchsten Rechten erhalten Sie mit dem Wert 1 <\/b>in der Spalte DatenquellenID<\/b>. Anschließend überschreiben Sie in der Tabelle Datenquellen <\/b>noch die Inhalte der Spalte Server <\/b>mit der Bezeichnung Ihres SQL Servers.<\/p>\n
Jetzt sind Sie bereit für den Test. Beenden Sie die Access-Applikation WaWi v2 <\/b>und starten Sie sie direkt wieder. Ein Klick auf die Schaltfläche Geburtstagsliste <\/b>im Start<\/b>-Formular zeigt die Geburtstage der Mitarbeiter. Für einen Test der Anmeldung WaWiMa <\/b>öffnen Sie nochmals die Tabelle Benutzer<\/b>. Dort ändern Sie in dem Datensatz mit Ihrem Benutzerkonto den Wert der Spalte DatenquellenID <\/b>in 2<\/b>. Nach einem weiteren Neustart der Access-Applikation klicken Sie auf die Schaltfläche Geburtstagsliste<\/b>. Jetzt erhalten Sie entsprechend der Rechtevergabe eine Fehlermeldung (siehe Bild 16).<\/p>\n
\"Fehler<\/p>\n
Bild 16: Fehler beim Datenzugriff<\/span><\/b><\/p>\n
Öffnen Sie die Tabelle Benutzer <\/b>ein weiteres Mal und setzen Sie den Wert der Datenquellen-ID zurück auf 1<\/b>. So haben Sie nach dem nächsten Start der Access-Applikation wieder die vollen Zugriffsrechte. Vor dem Neustart definieren Sie noch die beiden Tabellen Benutzer <\/b>und Datenquellen <\/b>als Systemtabellen. Dazu führen Sie im VBA-Direktbereich nacheinander die folgenden Anweisungen aus:<\/p>\n
fTabelleAlsSystemObjekt \"Benutzer\", True<\/span> \r\nfTabelleAlsSystemObjekt \"Datenquellen\", True<\/span> <\/pre>\n
Im Vergleich zur ursprünglichen Version reduziert die Version WaWi v2 <\/b>den Installationsaufwand und die Fehleranfälligkeit enorm. Es ist nicht mehr notwendig, pro Abteilung eine Access-Applikation zu erstellen und dabei die Tabellen mit der zugehörigen Anmeldung einzubinden. Ebenso entfällt das Anpassen der Anmeldedaten in der lokalen Tabelle Datenquellen<\/b>. Mit der Version WaWi v2 <\/b>haben Sie eine Access-Applikation für alle Abteilungen. Sie müssen lediglich die Tabelle Benutzer <\/b>auf dem aktuellen Stand halten. <\/p>\n
Ein verschlüsseltes Kennwort<\/h2>\n
Ein maskiertes Kennwort in einer versteckten Tabelle ist Ihnen nicht sicher genug Das ist eine gute Einstellung. Immerhin lässt sich das Kennwort trotz des bisherigen Aufwands recht einfach ermitteln. Alles was Sie dazu benötigen, ist ein Texteditor. Öffnen Sie die ACCDB der Access-Applikation WaWi v2 <\/b>doch einmal in einem Texteditor und suchen Sie dort nach dem Anmeldenamen WaWiPersonal<\/b>. Gleich der erste Treffer zeigt Ihnen den Inhalt der Tabelle Datenquellen <\/b>(siehe Bild 17). Um das Kennwort zu ermitteln, muss ein Angreifer also lediglich einen der Anmeldenamen kennen. Dazu reicht in der Regel ein Blick in die gespeicherten ODBC-Datenquellen.<\/p>\n
\"Die<\/p>\n
Bild 17: Die ACCDB im Texteditor<\/span><\/b><\/p>\n
Ein weiterer guter Grund sich davon zu trennen. Selbst wenn dem Angreifer der Anmeldename nicht bekannt ist, liefern die Suchergebnisse nach den Begriffen Kennwort <\/b>und K e n n w o r t <\/b>hilfreiche Hinweise. Versuchen Sie es mal. Sie werden erstaunt sein, welche Informationen Sie so entdecken. <\/p>\n
Es wird nicht lange dauern, bis der Angreifer den Begriff Kennwort <\/b>als Spalte der Tabelle Datenquellen <\/b>erkennt. Den Rest liefert die Access-Applikation selbst. Dazu ist nur die folgende DLookup<\/b>-Anweisung im VBA-Direktbereich auszuführen:<\/p>\n
  DLookup(\"Kennwort\",\"Datenquellen\") <\/pre>\n
Das Ergebnis zeigt das Kennwort des ersten Datensatzes im Klartext. Nebenbei bemerkt ist die Suche im Texteditor wie das Ausführen von Funktionen im VBA-Direktbereich ebenso gut in einer ACCDE möglich. Ein besserer Schutz des Kennworts ist also eine sehr gute Idee. Mit ein wenig Aufwand lässt es sich verschlüsselt in einer lokalen Tabelle speichern. Eine Sicherheitsmaßnahme, die in der Praxis oft und gerne angewendet wird.<\/p>\n
In der Access-Applikation WaWi v2 <\/b>übernimmt die Verschlüsselung des Kennworts die Funktion fKennwortErstellen<\/b>. Der Einfachheit halber besteht die Verschlüsselungsmethode aus dem Reversieren des Kennworts. So wird aus SicherIn2020! <\/b>der Wert !0202nIrehciS<\/b>. Dazu führen Sie im VBA-Direktbereich die Funktion fKennwortErstellen <\/b>wie folgt aus:<\/p>\n
  fKennwortErstellen(\"SicherIn2020!\", \"WaWiMa\")<\/pre>\n
Die Funktion verschlüsselt das Kennwort und schreibt den verschlüsselten Wert in den Datensatz zur Anmeldung WaWiMa <\/b>der Tabelle Datenquellen<\/b>. Wiederholen Sie den Vorgang doch gleich noch für die Anmeldung WaWiPersonal<\/b>. Anschließend lassen Sie sich das verschlüsselte Kennwort mit dieser DLookup<\/b>-Anweisung ausgeben (siehe Bild 18). <\/p>\n
\"Das<\/p>\n
Bild 18: Das verschlüsselte Kennwort<\/span><\/b><\/p>\n
DLookup(\"Kennwort\",\"Datenquellen\",\"Benutzer=\"\"WaWiPersonal\"\"\") <\/pre>\n
Vor dem Erstellen der Verbindungszeichenfolge muss der verschlüsselte Wert natürlich wieder entschlüsselt werden. Dazu erweitern Sie die beiden Funktionen fAdoPerTabelle<\/b> und fOdbcPerTabelle <\/b>mit der Funktion fKennwortLesen<\/b>. Bild 19 zeigt diese Ergänzung exemplarisch in der Funktion fOdbcPerTabelle<\/b>. Die Funktion fKennwortLesen <\/b>erhält als Eingabeparameter den verschlüsselten Wert aus der Tabelle Datenquellen <\/b>und liefert als Ergebnis das Kennwort im Klartext. <\/p>\n
\"Die<\/p>\n
Bild 19: Die Anpassung in fOdbcPerTabelle<\/span><\/b><\/p>\n
Das war es schon. Speichern Sie die Änderungen und schließen Sie die Access-Applikation. Nach einem Neustart stellen Sie keine Besonderheiten fest. Jede Schaltfläche des Start-Formulars liefert wie gewohnt die angeforderten Daten. Dennoch hat sich etwas gravierend verändert. Die lokale Tabelle Datenquellen <\/b>speichert das Kennwort nicht mehr im Klartext.<\/p>\n
Ob Sie in die Tabelle Datenquellen schauen, es per DLookup <\/b>im VBA-Direktbereich oder gar mit einem Texteditor direkt in der ACCDB versuchen, Sie sehen lediglich das verschlüsselte Kennwort. Wie stark Sie das Kennwort verschlüsseln, ist Ihnen freigestellt. Sie müssen nur die Funktionen fKennwortErstellen <\/b>und fKennwortLesen <\/b>an Ihren Verschlüsselungsalgorithmus anpassen.<\/p>\n
Der Fall Bienlein<\/h2>\n
Es gibt eine neue Version. WaWi v2<\/b>. Hört sich an wie eine Rakete, denkt Frau Bienlein und öffnet erwartungsvoll die Applikation. Enttäuscht stellt sie keinerlei Änderungen fest. Alles sieht aus wie bisher. Es gibt nichts Neues zu entdecken. Ob das noch die alte Version ist Frau Bienlein ruft in der IT-Abteilung an und fragt nach der neuen Version. Irgendwie scheint es in ihrer aktuellen Installation keine neuen Funktionen zu geben. Der IT-Mitarbeiter beruhigt sie und erklärt, dass es dieses Mal nur technische Änderungen gibt. Unter anderem habe man das Anmeldeverfahren vereinfacht. Für Frau Bienlein sind das schon mehr Informationen als sie sich erhofft hatte. Sie bedankt sich und beendet das Gespräch.<\/p>\n
Das Anmeldeverfahren wurde also geändert. Ob die Anmeldung in Ihrer Datenbank davon betroffen ist Sie öffnet ihre eigene Access-Datenbank und klickt doppelt auf die eingebundene Tabelle dbo_Mitarbeiter<\/b>. Das hatte sie befürchtet. Anstelle der Daten sieht sie eine Fehlermeldung (siehe Bild 20). Ok, den Fall hatte sie schon öfter. Routiniert klickt sie sich durch Externe Daten|Neue Datenquelle|Aus Datenbank|Aus SQL Server <\/b>zum Dialog Externe Daten – ODBC Datenbank <\/b>und aktiviert dort die zweite Option. Nach einem Klick auf OK <\/b>sieht sie den Dialog Datenquelle auswählen <\/b>und wechselt dort zur Registerkarte Computerdatenquelle<\/b>. Jetzt noch schnell den Eintrag WaWi_SQL <\/b>auswählen und schon lassen sich die Anmeldedaten prüfen. Aber wo ist der Eintrag Die Datenquelle WaWi_SQL <\/b>wird nicht mehr angezeigt.<\/p>\n
\"Fehlermeldung<\/p>\n
Bild 20: Fehlermeldung für Frau Bienlein<\/span><\/b><\/p>\n
Frau Bienlein bricht die Aktion ab. Ihre Vermutung wurde aufs Übelste bestätigt. Wie soll sie nur ohne die Datenquelle an die Personaldaten kommen Und wie funktioniert dieses neue Anmeldeverfahren Alles was Sie braucht, ist die Tabelle Mitarbeiter <\/b>und die zugehörigen Anmeldedaten. Sie öffnet die Access-Applikation WaWi v2 <\/b>mit gedrückter Umschalt-Taste. Im Navigationsbereich schaut sie nach der Tabelle Mitarbeiter<\/b>. Nichts. Weder die Tabelle Mitarbeiter <\/b>noch die anderen Tabellen der Personalabteilung sind in der Auflistung enthalten. <\/p>\n
Wie sieht es mit den Anmeldedaten aus Beim letzten Mal hatte sie den Anmeldenamen und das Kennwort in den Eigenschaften der Pass Through-Abfragen entdeckt. Sie erweitert den Ordner Abfragen <\/b>und öffnet eine der Pass Through-Abfragen in der Entwurfsansicht. Doch von Anmeldedaten ist hier nichts zu sehen. Die zweite Pass Through-Abfrage enthält ebenfalls keine Informationen zu einer Anmeldung. Neben den beiden Pass Through-Abfragen entdeckt Frau Bienlein eine neue Access-Abfrage. Ob die weiterhilft Ein Doppelklick auf die Abfrage zeigt ihr einen Datensatz mit Informationen zur Anmeldung WaWiMa <\/b>(siehe Bild 22). Sie wechselt zur Entwurfsansicht der Abfrage und entdeckt das Filterkriterium fOsUserName<\/b>.<\/p>\n
\"Die<\/p>\n
Bild 21: Die Anmeldedaten der Kollegen<\/span><\/b><\/p>\n
Frau Bienlein sieht gerne das große Ganze. Sie entfernt den Filter und führt die Abfrage erneut aus. Die Datenblattansicht listet jetzt alle Anmeldedaten auf. Dort entdeckt sie den Eintrag WaWiPersonal<\/b>. Eine erste Spur. Ihr ist bekannt, dass die Personalabteilung mit dieser Anmeldung arbeitet. Genau diese Anmeldung hatte sie vor ein paar Monaten in den Eigenschaften der Pass Through-Abfragen entdeckt. Seitdem konnte sie problemlos auf die Daten der Personalabteilung zugreifen. Bis diese ärgerliche neue Version kam. <\/p>\n
Jetzt fehlt ihr noch das Kennwort. Zwar enthält die Datenblattansicht eine Spalte namens Kennwort<\/b>, der Inhalt ist aber nicht lesbar. Das ist kein Problem für Frau Bienlein. Sie kennt die Option, mit der die Ausgabe einer Spalte maskiert wird. Sie muss nur die zugehörige Tabelle finden und die Maskierung entfernen. Zurück in der Entwurfsansicht erkennt sie, dass die Anmeldedaten aus der Tabelle Datenquellen <\/b>stammen. Sie erweitert den Navigationsbereich und sucht die Tabelle Datenquellen<\/b>. Ohne Erfolg. Dort gibt es die Tabelle nicht. <\/p>\n
Dann muss es halt die Abfrage hergeben. Frau Bienlein ergänzt die Ausgabe mit allen Spalten der Tabelle Benutzer<\/b>. In der Datenblattansicht erkennt sie den Zusammenhang. Der Datensatz mit ihrem Namen zeigt die Datenquellen-ID 2<\/b>. Dieser ID ist die Anmeldung WaWiMa <\/b>zugeordnet. Beim Kollegen Stromberg aus der Personalabteilung enthält der Datensatz den Anmeldenamen WaWiPersonal <\/b>und in der Spalte DatenquellenID <\/b>den Wert 1 <\/b>(siehe Bild 21). Sehr schön. Die Anmeldung WaWiPersonal <\/b>wird also weiterhin in der Personalabteilung verwendet.<\/p>\n
\"Die<\/p>\n
Bild 22: Die Anmeldedaten für Frau Bienlein<\/span><\/b><\/p>\n
Ob sich die Datenquellen-ID in ihrem Datensatz überschreiben lässt Sie ändert den Wert von 2 <\/b>in 1<\/b>. Ohne zu speichern schließt sie die Abfrage und startet sie erneut mit einem Doppelklick. Der Datensatz zeigt nun den Anmeldenamen WaWiPersonal<\/b>. Und jetzt Reboot tut gut, denkt Frau Bienlein und startet die Access-Applikation neu. Dabei hält sie die Umschalt-Taste gedrückt. Nach dem Neustart schaut sie erwartungsvoll in den Navigationsbereich. Doch die Tabelle Mitarbeiter <\/b>ist immer noch nicht zu sehen. Womöglich hatte die Änderung der Datenquellen-ID doch keine Auswirkung oder liegt es vielleicht an der Umschalt-Taste<\/p>\n
Frau Bienlein startet die Access-Applikation noch einmal. Jetzt ohne die Umschalt-Taste. Sie sieht das Start<\/b>-Formular wie gewohnt mit den aktiven Schaltflächen für den Vertrieb und den inaktiven für die Personalabteilung (siehe Bild 23). Wieder nichts. Insgeheim hatte sie gehofft, dass durch die Änderung der Datenquellen-ID die Schaltflächen der Personalabteilung verfügbar wären. <\/p>\n
\"Frau<\/p>\n
Bild 23: Frau Bienleins Start-Formular<\/span><\/b><\/p>\n
Sie startet die Access-Applikation aufs Neue. Dabei hält sie nochmal die Umschalt-Taste gedrückt. Ohne große Erwartungen erweitert sie den Navigationsbereich. Was ist das denn Jetzt zeigt der Navigationsbereich die Tabelle Mitarbeiter<\/b>. Sogar die beiden anderen Tabellen der Personalabteilung sind zu sehen. Irgendetwas muss sich seit dem letzten Start der Access-Applikation verändert haben. Vielleicht hat es ja doch etwas mit der Umschalt-Taste zu tun<\/p>\n
Egal, Frau Bienlein ist viel mehr an der Tabelle Mitarbeiter <\/b>interessiert. Aber ein Doppelklick auf die Tabelle bremst sie erneut aus. Anstelle der Daten sieht sie nur einen Anmeldedialog mit ihrem Namen (siehe Bild 24). Sie denkt kurz nach. Was sagte der IT-Kollege Das Anmeldeverfahren wurde geändert Von den Anmeldedaten war keine Rede. Frau Bienlein überschreibt Ihren Namen mit WaWiPersonal <\/b>und gibt dann das Kennwort ein, das sie bisher für ihre geheimen Zugriffe verwendet hat. <\/p>\n
\"Frau<\/p>\n
Bild 24: Frau Bienlein kurz vor dem Ziel<\/span><\/b><\/p>\n
Sie klickt gespannt auf OK <\/b>– und kann sich das Grinsen nicht verkneifen. Die Tabelle Mitarbeiter <\/b>zeigt alle Daten. Frau Bienlein navigiert direkt zur Spalte AktuellesGehalt <\/b>und erhöht ihr Gehalt erneut um 5 Euro. Danach öffnet sie die Tabelle Bewerber <\/b>und ändert den Vornamen des Bewerbers Meier <\/b>von Brigitte <\/b>in Klaus<\/b>. Bei dem Bewerbungsgespräch wäre sie nur zu gerne dabei.<\/p>\n
Um ihre Spuren zu verwischen, öffnet Sie die Abfrage Anmeldedaten <\/b>im Entwurfsmodus und ergänzt die Ausgabe mit der Spalte DatenquellenID <\/b>der Tabelle Benutzer<\/b>. Anschließend führt sie die Abfrage aus und ändert die Datenquellen-ID von 2 <\/b>in 1<\/b>. Danach beendet Sie die Abfrage ohne ihre Änderungen zu speichern und startet sie per Doppelklick erneut. Das Ergebnis zeigt jetzt ihren Namen zusammen mit der Anmeldung WaWiMa<\/b>. Der Urzustand wäre somit wiederhergestellt. Zufrieden schließt sie die Access-Applikation und geht auf einen Plausch zu den Kollegen in die Personalabteilung. <\/p>\n
Fazit und Bewertung<\/h2>\n
Dieses Mal haben Sie das Sicherheitsniveau der Access-Applikation gleich um drei Stufen erhöht. Mit Stufe 1 vermeiden Sie die ODBC-Datenquelle WaWi_SQL <\/b>auf den Rechnern der Anwender. Das verhindert unerlaubte Datenzugriffe mit nicht gewünschten Applikationen. Durch Stufe 2 wird das Kennwort nicht mehr in den Eigenschaften der eingebundenen Tabellen und Pass Through-Abfragen gespeichert. Stufe 3 sorgt zudem dafür, dass das Kennwort für den Datenzugriff verschlüsselt in einer versteckten Tabelle liegt. <\/p>\n
Alle Informationen für den Datenzugriff sind nun in der Access-Applikation gespeichert. Abhängig vom angemeldeten Anwender werden beim ersten Datenzugriff die Anmeldedaten sowie die Bezeichnung des SQL Servers und der Name der Datenbank in einer Verbindungszeichenfolge zusammengestellt. Mit dieser erfolgt die Verbindung zum SQL Server und das anschließende Einbinden der Tabellen. Die dabei erstellte Verbindung bleibt danach für alle weiteren Datenzugriffe bestehen. <\/p>\n
Trotz der erhöhten Sicherheit gibt es noch eine Schwachstelle. Die Access-Applikation selbst ist nicht ausreichend geschützt. Frau Bienlein konnte recht einfach die Abfrage in der Entwurfsansicht öffnen und sich so die notwendigen Informationen für die weitere Vorgehensweise verschaffen. Das Ausblenden des Navigationsbereichs alleine ist kein wirksamer Schutz. Vielmehr sollte die Access-Applikation mit weiteren Maßnahmen abgesichert werden. Ob Sie nun eine ACCDE verwenden, die Access-Funktionstasten und die Umschalt-Taste unterbinden, es stehen Ihnen einige Möglichkeiten zur Verfügung. Leider lassen sich diese allesamt umgehen, wie Sie bereits im ersten Teil dieser Beitragsreihe erfahren haben.<\/p>\n
Solange das Kennwort in der Access-Applikation gespeichert ist, lässt es sich dort mit etwas Ehrgeiz auch ermitteln. Dazu müssen Sie lediglich die ACCDB oder ACCDE in einem Texteditor öffnen. Sie haben bereits gesehen, wie einfach sich dort entsprechende Hinweise finden lassen. In der ACCDB der Access-Applikation WaWi v2 <\/b>liefern Ihnen die Suchbegriffe Kennwort <\/b>und K e n n w o r t <\/b>zum einen das Ergebnis fKennwortLesen <\/b>und zum anderen im UPDATE<\/b>-Befehl der Funktion fKennwortErstellen <\/b>den Namen der Tabelle Datenquellen<\/b>. Eine weitere Suche nach dem Begriff D a t e n q u e l l e n <\/b>verrät Ihnen die Bezeichnung des SQL Servers und den der Datenbank sowie den Anmeldenamen und das verschlüsselte Kennwort. Es braucht nur ein wenig Fantasie und Kombinationsgabe, um letztendlich im VBA-Direktbereich mit der Funktion fKennwortLesen <\/b>das Kennwort zu entschlüsseln. Das Lesen der ACCDB oder ACCDE in einem Texteditor können Sie recht einfach verhindern. Dazu schützen Sie die Access-Applikation mit einem Datenbank-Kennwort. In einem Texteditor sehen Sie dann nur noch den verschlüsselten Inhalt. Suchvorgänge nach bestimmten Begriffen sind hier erfolglos. Leider hat auch diese Variante eine Schwachstelle. Um mit der Access-Applikation arbeiten zu können, muss der Anwender das Datenbank-Kennwort eingeben. Es ist eine Frage der Sensibilisierung der Mitarbeiter, wie sicher diese mit dem Datenbank-Kennwort umgehen. Fällt es in die falschen Hände, lässt sich das Kennwort zur SQL Server-Anmeldung mit ein wenig krimineller Energie innerhalb der Access-Applikation ermitteln. Das hierzu keine speziellen technischen Kenntnisse erforderlich sind, haben Sie ebenfalls im ersten Teil dieser Beitragsreihe erfahren.<\/p>\n
Alles in allem ist der Schutz des Kennworts zur SQL Server-Anmeldung mit einem hohen Aufwand verbunden – und dennoch ist es nicht ausreichend geschützt. Dabei könnten Sie sich eigentlich den ganzen Aufwand sparen und einfach auf das Kennwort verzichten.<\/p>\n
Der SQL Server bietet hierzu die Windows-Authentifizierung. Die Vorteile dieser Authentifizierungsmethode lernen Sie im nächsten Teil dieser Beitragsreihe kennen.<\/p>\n
Installationsanleitung der Beispielumgebung<\/h2>\n
SQL Server – Wechsel in den Gemischten Modus:<\/p>\n