<\/p>\n
SQL Server bietet eine Vielzahl an Möglichkeiten und Funktionen im Bereich Security – von Zugriffsberechtigungen auf Objekte und Daten über verschiedene Verschlüsselungsmethoden bis hin zur Protokollierung von Datenzugriffen und Datenänderungen. Viele der Funktionen ähneln sich und haben zum Teil die gleichen Auswirkungen. Da ist es nicht einfach, einen Überblick zu erhalten. Also von Anfang an. Als erstes lernen Sie die Sicherheitsarchitektur von SQL Server und die Anmeldung „sa“ kennen.<\/b><\/p>\n
Der SQL Server arbeitet mit einer mehrstufigen Sicherheitsarchitektur. <\/p>\n
Die erste Stufe ist die Authentifizierung des Anwenders am SQL Server selbst. Dies erfolgt mit der sogenannten Anmeldung. Die Anmeldung alleine erlaubt dem Anwender noch keinen Zugriff auf die Daten.<\/p>\n
Das wäre auch zu unsicher, schließlich kann eine SQL Server-Instanz mehrere Datenbanken verwalten und nicht jeder Anwender darf alle Daten lesen und ändern.<\/p>\n
Der Zugang zu einer Datenbank ist die zweite Stufe der Sicherheitsarchitektur. Dem Anwender wird der Zugang zu einer Datenbank nur gewährt, wenn seine Anmeldung der Datenbank zugeordnet ist. Die Anmeldung ist dann in der Datenbank als Benutzer zu sehen. <\/p>\n
Der Benutzer ist die Basis für die dritte Stufe der Sicherheitsarchitektur. Er besitzt die Zugriffsrechte an den Datenbankobjekten, wie Tabellen, Sichten und Gespeicherten Prozeduren, und somit letztendlich die Lese- und Schreibrechte für die Daten. <\/p>\n
Die SQL Server-Sicherheitsarchitektur<\/b><\/p>\n
Ein Vergleich mit dem echten Leben soll dies verdeutlichen. Angenommen, Sie haben einen Termin in einem größeren Unternehmen. Sie betreten das Firmengebäude und gehen zur Anmeldung. Dort stellen Sie sich vor und teilen der Empfangsdame mit, dass Sie einen Termin mit Herrn Müller von der Abteilung Einkauf <\/b>haben. Sie erhalten ein Namensschild mit der Aufschrift Besucher <\/b>und werden gebeten, es sich in der Sitzgruppe gemütlich zu machen, während Sie auf Herrn Müller warten.<\/p>\n
In diesem Vergleich steht das Firmengebäude für die SQL Server-Instanz und Ihr Namensschild mitsamt der Genehmigung, sich in der Lobby aufzuhalten, entspricht der SQL Server-Anmeldung Besucher<\/b>.<\/p>\n
Herr Müller lässt nicht lange auf sich warten. Er begrüßt Sie höflich und nimmt Sie mit in die Abteilung Einkauf<\/b>. Dort sollen Sie in seinem Auftrag Daten lesen, einfügen, ändern und löschen.<\/p>\n
Der Zutritt zur Abteilung Einkauf <\/b>ist in der SQL Server-Instanz vergleichbar mit der Zuordnung der Anmeldung Besucher <\/b>zur Datenbank Einkauf<\/b>. In der Datenbank existiert jetzt der Benutzer Besucher<\/b>, dem Lese- und Schreibrechte für alle Daten erteilt wurden<\/p>\n
Beim Mittagessen treffen Sie Herrn Schmidt. Er braucht noch weitere Auswertungen und Sie sollen doch bitte um 15 Uhr zu ihm in die Personalabteilung kommen. Gegen 15 Uhr gehen Sie zu Herrn Schmidt und erstellen ihm die gewünschten Auswertungen.<\/p>\n
Dieser Abteilungswechsel entspricht der Zuordnung der Anmeldung Besucher <\/b>zu einer weiteren Datenbank der SQL Server-Instanz – der Datenbank Personal<\/b>. Dort gibt es nun auch einen Benutzer namens Besucher<\/b>. Allerdings besitzt dieser nur Leserechte.<\/p>\n
Zusammengefasst zeigt das Beispiel eine SQL Server-Instanz mit der Anmeldung Besucher<\/b>. Diese ist den Datenbanken Einkauf <\/b>und Personal <\/b>zugeordnet.<\/p>\n
Die Datenbank Einkauf <\/b>enthält den Benutzer Besucher <\/b>mit Lese- und Schreibrechten. In der Datenbank Personal <\/b>gibt es ebenfalls einen Benutzer namens Besucher<\/b>, dieser besitzt jedoch nur Leserechte.<\/p>\n
Beide Benutzer existieren nur innerhalb ihrer Datenbanken. Auch wenn beide den gleichen Namen verwenden, haben sie bis auf eine Ausnahme nichts miteinander zu tun. Sie verweisen beide auf die Anmeldung Besucher <\/b>und somit letztendlich auf den Anwender, der diese Anmeldung verwendet.<\/p>\n
Das ist das Prinzip der mehrstufigen Sicherheitsarchitektur. Über die Anmeldung erhält ein Anwender Zugang zur SQL Server-Instanz und kann dort in mehreren Datenbanken mit unterschiedlichen Rechten arbeiten.<\/p>\n
SQL Server-Instanzen<\/b><\/p>\n
Möglicherweise fragen Sie sich, was genau eine SQL Server-Instanz ist. Die Antwort ist recht einfach. Es ist das Ergebnis Ihrer SQL Server-Installation. <\/p>\n
Mit der einfachen Installation des SQL Servers erstellen Sie die Standardinstanz. Diese lässt sich dann mit dem Namen des Rechners ansprechen. Lautet der Rechnername PC01<\/b>, verbinden Sie sich mit der SQL Server-Instanz PC01<\/b>. <\/p>\n
Sie dürfen die Installation auf dem gleichen Rechner nochmals ausführen. Jedoch müssen Sie jetzt einen Instanznamen angeben. Nennen Sie die Instanz zum Beispiel Entwicklung<\/b>, steht nach der Installation eine weitere eigenständige SQL Server-Instanz unter dem Namen PC01Entwicklung<\/b> zur Verfügung.<\/p>\n
Eine sogenannte benannte Instanz kennen Sie vielleicht von der SQL Server Express Edition, wird diese doch immer mit einem Instanznamen installiert. Der Name einer SQL Server Express Edition auf dem Rechner PC01<\/b> wäre PC01SQLEXPRESS<\/b>.<\/p>\n
Insgesamt können Sie mit einer Lizenz 50 Instanzen auf einem Rechner installieren, eine Standardinstanz und benannte Instanzen. Dabei gibt es zwischen einer Standardinstanz und den benannten Instanzen keine Unterschiede. Jede SQL Server-Instanz bietet den gleichen Funktionsumfang. Sie können dort mehrere Datenbanken verwalten und natürlich auch eigene Anmeldungen festlegen. <\/p>\n
Eine Anmeldung namens Müller <\/b>in der SQL Server-Instanz PC01<\/b> lässt sich nur für den Zugang zu dieser Instanz verwenden. Eine Verbindung zur Instanz PC01Entwicklung<\/b> ist mit dieser Anmeldung nicht möglich. <\/p>\n
Existiert in der SQL Server-Instanz PC01Entwicklung<\/b> ebenfalls eine Anmeldung namens Müller, ermöglicht diese zwar den Zugang zur Instanz PC01Entwicklung<\/b>, aber eben nicht zur Instanz PC01<\/b>. Die beiden Anmeldungen haben schlicht und ergreifend nichts miteinander zu tun.<\/p>\n
Durch die eigenen Anmeldungen lassen sich SQL Server-Instanzen sehr gut zur Trennung von Daten unterschiedlicher Sicherheitsstufen einsetzen. So legen Sie zum Beispiel die Datenbanken mit den Daten der Produktion auf die Standardinstanz und auf eine weitere SQL Server-Instanz namens PC01Forschung<\/b> die Datenbanken mit den sensiblen Daten der Forschungsabteilung. <\/p>\n
Im oben verwendeten Vergleich mit dem Besucher im Unternehmen stellt die Standardinstanz die Zentrale des Unternehmens dar und die Instanz PC01Forschung<\/b> deren Forschungszentrum. Das Forschungszentrum ist in einem eigenen Gebäude. Wechselt der Besucher von der Zentrale zum Forschungszentrum, muss er sich dort beim Empfang erneut anmelden.<\/p>\n
Begrifflichkeiten<\/b><\/p>\n
Die im SQL Server verwendeten Begriffe Anmeldung <\/b>und Benutzer <\/b>sind nicht besonders geeignet für eine Artikelserie zum Thema Security<\/b>. Beide Begriffe haben mehrere Bedeutungen.<\/p>\n
Bei einer Anmeldung kann es sich um eine SQL Server-Anmeldung oder auch um die Anmeldung am Clientrechner handeln. Der Begriff Benutzer <\/b>steht für die Person am Rechner wie für die Zuordnung einer SQL Server-Anmeldung zu einer Datenbank.<\/p>\n
Um Missverständnisse zu vermeiden, beschreibt von nun an der Begriff Anwender <\/b>die Person am Rechner und Benutzerkonto <\/b>die von der Person verwendete Anmeldung am Betriebssystem.<\/p>\n
Zudem wird der Einfachheit halber ab jetzt der Begriff SQL Server anstatt SQL Server-Instanz verwendet.<\/p>\n
Authen-ti-fi-zie-rungs-methoden<\/b><\/p>\n
SQL Server bietet zwei Authentifizierungsmethoden – die Windows-Authentifizierung und die SQL Server-Authentifizierung. Bereits bei der Installation dürfen Sie entscheiden, ob Sie nur die Windows-Authentifizierung oder eine Kombination der beiden nutzen möchten.<\/p>\n
Dabei ist die Windows-Authentifizierung als Standard vorausgewählt. Nicht ohne Grund, denn diese Authentifizierungsmethode wird von Microsoft empfohlen. Sie erlaubt als SQL Server-Anmeldungen ausschließlich Benutzerkonten von Windows-Benutzern und Windows-Gruppen. <\/p>\n
Für den Anwender ist dies sogar von Vorteil. Er muss sich am SQL Server nicht erneut anmelden. Da sein Benutzerkonto mit einer SQL Server-Anmeldung verbunden ist, erhält er den direkten Zugang zum SQL Server.<\/p>\n
Wenn Sie sich bei der Installation für die Windows-Authentifizierung entscheiden, sollten Sie mit der Schaltfläche Hinzufügen <\/b>ein Benutzerkonto als Administrator aufnehmen (siehe Bild 1). Nur mit diesem Benutzerkonto haben Sie nach der Installation entsprechende Adminis-trationsrechte im SQL Server.<\/p>\n
<\/p>\n
Bild 1: Administrator bei der Windows-Authentifizierung<\/span><\/b><\/p>\n Reicht Ihnen die Windows-Authentifizierung nicht aus, können Sie zusätzlich noch die SQL Server-Authentifizierung aktivieren.<\/p>\n Diese Kombination wird Gemischter Modus <\/b>genannt. <\/p>\n Der gemischte Modus erlaubt Ihnen die Definition eigener Anmeldungen mit Benutzernamen und Kennwort. Diese Art der Authentifizierung ist vor allem in Umgebungen notwendig, die keine Windows-Benutzerkonten unterstützen, wie ein SQL Server auf einem Linux-System ohne Anbindung an ein Active Directory oder ein SQL Server als Backend eines Webshops. <\/p>\n Entscheiden Sie sich für den gemischten Modus, müssen Sie der SQL Server-Anmeldung sa <\/b>ein Kennwort vergeben (siehe Bild 2). sa <\/b>steht für System Administrator <\/b>und beinhaltet alle administrativen Rechte für den SQL Server. <\/p>\n Bild 2: sa-Konto bei der SQL Server-Authentifizierung<\/span><\/b><\/p>\n Die Anmeldung sa <\/b>ist jedoch nicht nur den Administratoren vorbehalten. Jeder Anwender kann sie nutzen. Er muss nur das korrekte Kennwort eingeben und schon hat er alle Rechte im SQL Server. Es gibt für ihn dort keinerlei Einschränkungen. Aus diesem Grund sollten Sie unbedingt ein komplexes und starkes Kennwort verwenden.<\/p>\n Jetzt haben Sie vielleicht Ihren SQL Server schon installiert und würden gerne im Nachhinein die Authentifizierungsmethode wechseln. Das ist kein Problem, denn Sie können dies im SQL Server Management Studio jederzeit ändern.<\/p>\n Dazu starten Sie das SQL Server Management Studio und melden sich mit der Ihnen bekannten Anmeldung am SQL Server an. Nach der Anmeldung sehen Sie auf der linken Seite den Objekt-Explorer. Dort klicken Sie mit der rechten Maustaste auf den ersten Eintrag, den mit dem Namen Ihres SQL Servers (siehe Bild 3).<\/p>\n Bild 3: Die SQL Server-Instanz im Objekt-Explorer<\/span><\/b><\/p>\n Im Kontextmenü wählen Sie dann den Eintrag Eigenschaften <\/b>und wechseln im folgenden Dialog zur Seite Sicherheit<\/b>. Unter Serverauthentifizierung <\/b>können Sie nun zwischen den einzelnen Modi wechseln (siehe Bild 4). <\/p>\n Bild 4: Wechsel der Authentifizierungsmethode<\/span><\/b><\/p>\n Nach einem Klick auf OK <\/b>werden Sie darauf hingewiesen, dass die Änderungen erst nach einem Neustart des SQL Server-Diensts wirksam sind. Dazu öffnen Sie im SQL Server Management Studio das gleiche Kontextmenü wie eben und wählen dort den Eintrag Neu starten<\/b>. <\/p>\n Es folgt die Sicherheitsabfrage aus Bild 5. Aus gutem Grund, denn während des Neustarts steht der SQL Server nicht zur Verfügung. Angemeldete Anwender werden in dieser Zeit entsprechende Fehlermeldungen erhalten. Sie sollten also den SQL Server nur dann neu starten, wenn Sie sich sicher sind, dass außer Ihnen niemand sonst angemeldet ist.<\/p>\n Bild 5: Neustart der SQL Server-Instanz<\/span><\/b><\/p>\n Für die Beispiele in diesem Artikel benötigen Sie den gemischten Modus. Verwenden Sie aktuell die reine Windows-Authentifizierung, ändern Sie die Einstellung wie oben beschrieben auf SQL Server- und Windows-Authentifizierung.<\/p>\n Nach dem Wechsel der Authentifizierungsmethode müssen Sie die Anmeldung sa<\/b> noch aktivieren und ihr ein Kennwort vergeben. Dazu navigieren Sie zum Ordner Sicherheit<\/b>, erweitern den Unterordner Anmeldungen <\/b>und öffnen per Doppelklick auf den Eintrag sa <\/b>den Dialog Anmeldungseigenschaften<\/b>.<\/p>\n Hier wechseln Sie zur Seite Status <\/b>und aktivieren unter Anmeldename <\/b>die Option Aktiviert <\/b>(siehe Bild 6). Danach geben Sie der Anmeldung in der Seite Allgemein <\/b>ein Kennwort und speichern die Änderungen mit einem Klick auf OK<\/b>. Jetzt können Sie sich am SQL Server mit der Authentifizierungsmethode SQL Server-Authentifizierung<\/b>, dem Anmeldename sa <\/b>und dem eben erstellten Kennwort anmelden (siehe Bild 7).<\/p>\n Bild 6: Authentifizierung mit der Anmeldung sa<\/span><\/b><\/p>\n Bild 7: Aktivieren der Anmeldung sa<\/span><\/b><\/p>\n Die SQL Server-Anmeldung „sa“<\/b><\/p>\n Entgegen der Empfehlung von Microsoft wird gerade für die Verbindung vom Access-Frontend zum SQL Server-Backend selten die Windows-Authentifizierung verwendet. In vielen Fällen findet dies über die SQL Server-Authentifizierung statt – und dabei oft mit der SQL Server-Anmeldung sa<\/b>.<\/p>\n Es bietet sich ja auch an. Die Anmeldung sa <\/b>ist fester Bestandteil des SQL Servers. Sie ist allen SQL Servern verfügbar und man kann sie nach der Installation direkt verwenden. Zudem gibt es mit dieser Anmeldung im SQL Server keinerlei Einschränkungen.<\/p>\n Bei der Migration von Access nach SQL Server ist dies von Vorteil. Schließlich gibt es genügend Punkte zu beachten und Neues zu lernen. Da möchte man sich nicht mit den Widrigkeiten fehlender Rechte aufhalten.<\/p>\n Leider bleibt es in vielen Fällen dann bei dieser Authentifizierung. Die sa<\/b>-Anmeldung ist nicht nur in Entwicklungs- und Testumgebungen zu finden, sondern auch in vielen Produktivumgebungen.<\/p>\n Falls Sie in Ihrer Access und SQL Server-Applikation bereits eine andere Anmeldung verwenden, haben Sie schon einen höheren Zugriffsschutz erreicht. Nutzen Sie allerdings die sa<\/b>-Anmeldung, sollten Ihnen die Möglichkeiten klar sein, die Sie Ihren Anwendern damit in die Hand geben. Genau diese werden Sie nun kennenlernen.<\/p>\n Es gibt in Access mehrere Methoden die Daten einer SQL Server-Datenbank zu verarbeiten. In den meisten Fällen findet dies wohl mit eingebundenen Tabellen statt, gefolgt von Pass Through-Abfragen per DAO in VBA und mittels Direktzugriff über ADO. ADO benötigt für den Datenzugriff einen OLE DB-Treiber, für eingebundene Tabellen und Pass Through-Abfragen hingegen ist ein ODBC-Treiber erforderlich.<\/p>\n Beiden Treibern muss für den Datenzugriff neben dem Benutzernamen auch das Kennwort der SQL Server-Anmeldung übergeben werden. Doch wie übergibt man das Kennwort<\/p>\n Die einfachste Variante verlangt die Kennworteingabe vom Anwender. Dies ist mit Abstand aber auch die unsicherste Variante. Schließlich kann sich der Anwender mit dieser Anmeldung direkt am SQL Server anmelden. Dazu benötigt er nur ein Frontend, wie eine eigene Access-Datenbank oder das kostenlose SQL Server Management Studio.<\/p>\n Mit der Anmeldung sa <\/b>erhält der Anwender im SQL Server die Rechte eines Administrators. Denkt man über die hiermit verbundenen Möglichkeiten nach, fallen einem in erster Linie administrative Tätigkeiten ein, wie Berechtigungen ändern, Datenbanken löschen et cetera. <\/p>\n Apropos Datenbanken löschen. Das Löschen von Daten-banken ist zwar ärgerlich, es ist aber auch lösbar. Sie werden recht schnell mitbekommen, wenn die Datenbank nicht mehr existiert.<\/p>\n Alles halb so wild, ist die Datenbank doch mit der letzten Datensicherung schnell wiederhergestellt – sofern es eine aktuelle und fehlerfreie Datensicherung gibt. An dieser Stelle sei die Frage erlaubt, wann Sie Ihre Datensicherung das letzte Mal getestet haben<\/p>\n <\/p>\n Unrechtmäßige administrative Vorgänge lassen sich in der Regel beheben, wenn man sie denn erkannt hat. Viel riskanter aber ist das heimliche Lesen oder gar Ändern von Daten.<\/p>\n Mit der Anmeldung sa <\/b>hat der Anwender nicht nur administrative Rechte, er besitzt auch vollen Zugang zu allen Daten des SQL Servers. Es hindert ihn niemand daran, die Daten zu lesen und zu seinen Gunsten zu ändern.<\/p>\n Folgendes Beispiel soll dies verdeutlichen. Ein Anwender legt in der entsprechenden Datenbank einen Lieferanten an und erfasst danach in unregelmäßigen Abständen zugehörige Eingangsrechnungen unterhalb der Budgetfreigabegrenze. Da er dabei eine ihm bekannte Bankverbindung angegeben hat, erhält er von der nichtsahnenden Buchhaltung einen kleinen Nebenverdienst.<\/p>\n Sie haben in Ihrer Datenbank keine Lieferantendaten Aber vielleicht liegen diese in einer anderen Datenbank auf dem gleichen SQL Server. Auch wenn es bereits erwähnt wurde: Für die Anmeldung sa <\/b>gibt es im SQL Server keine Grenzen.<\/p>\n Der Anwender kann die Daten aller Datenbanken einsehen und ändern! Dem Benutzer das Kennwort für die Anmeldung sa <\/b>mitzuteilen, mag eine einfache Lösung sein.<\/p>\n Sie ist aber, wie so oft bei einfachen Lösungen, die unsicherste Methode, die Sie verwenden können.<\/p>\n Access und das Kennwort<\/b><\/p>\n Eine weitaus bessere Variante bietet Ihnen Access. Beim Einbinden der Tabellen wie auch beim Erstellen der Pass Through-Abfragen können Sie das Kennwort der SQL Server-Anmeldung speichern. Danach ist die Kennwort-eingabe nicht einmal mehr beim Start der Access-Applikation erforderlich.<\/p>\n Hierzu brauchen Sie eine ODBC-Verbindung. Diese erstellen Sie am besten vorab als Systemdatenquelle über den ODBC-Dialog des Betriebssystems. Auf diese Weise steht die ODBC-Datenquelle jedem Anwender zur Verfügung, der sich an dem Rechner anmeldet. Anhand der ODBC-Datenquelle wird die Verbindung von Ihrem Access-Frontend zur Datenbank Ihres SQL Servers hergestellt. Somit ist das Einrichten dieser ODBC-Datenquelle auf jedem Rechner erforderlich, auf dem auch Ihr Access-Frontend installiert ist.<\/p>\n Die Konfiguration der ODBC-Datenquelle können Sie anhand der Beispielapplikation WaWi<\/b> nachvollziehen. Dazu installieren Sie zunächst die Datenbank WaWi_SQL <\/b>in Ihrem SQL Server. <\/p>\n Öffnen Sie im SQL Server Management Studio die Datei WaWi_SQL.sql <\/b>und starten Sie das Skript mit einem Klick auf Ausführen <\/b>(siehe Bild 8). Nachdem die Datenbank angelegt ist, sehen Sie in der Registerkarte Meldungen die Ausgabe Fertig!.<\/b><\/p>\n Bild 8: Installation der Beispieldatenbank<\/span><\/b><\/p>\n Nun drücken Sie die Windows-Taste, geben als Suchbegriff ODBC <\/b>ein und wählen den Eintrag ODBC-Datenquellen (32-Bit)<\/b>. Im Dialog ODBC-Datenquellen-Administrator <\/b>aktivieren Sie die Registerkarte System-DSN <\/b>und klicken dort auf die Schaltfläche Hinzufügen <\/b>(siehe Bild 9).<\/p>\n Bild 9: Anlegen der ODBC-Datenquelle<\/span><\/b><\/p>\n Es folgt die Auswahl des ODBC-Treibers (siehe Bild 10). Hier haben Sie die Qual der Wahl. Für den Zugriff auf SQL Server gibt es mehrere ODBC-Treiber. Abhängig von der Version bietet er neben einer besseren Performance auch die Unterstützung neuer SQL Server-Funktionen, insbesondere im Bereich Security. <\/p>\n Bild 10: Auswahl des ODBC-Treibers<\/span><\/b><\/p>\n Aus diesem Grund sollten Sie die neueste Version verwenden. Aktuell ist dies ODBC Driver 17 for SQL Server<\/b>. Falls Sie diesen Treiber in Ihrer Auswahl nicht sehen, müssen Sie ihn zunächst installieren. Sie finden den Treiber im Microsoft Downloadbereich <\/b>unter dem Suchbegriff ODBC Driver 17 for SQL Server<\/b>.<\/p>\n Bitte verwenden Sie nicht die ODBC-Treiber SQL Server und SQL Server Native Client. Die Treiber werden von Microsoft weder weiterentwickelt noch gibt es entsprechende Fehlerbehebungen oder gar Sicherheitsupdates. <\/p>\n Somit stellen diese beiden Treiber eine Sicherheitslücke dar. Mit einem veralteten Treiber ist die sichere Kommunikation zwischen Access-Frontend und SQL Server-Back-end nicht gewährleistet. Unbefugte könnten heimlich Mithören oder gar Mitreden, im Sinne von Daten lesen, ändern und löschen.<\/p>\n Leider werden genau diese beiden Treiber in vielen Access und SQL Server-Applikationen eingesetzt. Der Grund hierfür ist recht einfach. Die Treiber sind bereits vorinstalliert und müssen nicht extra auf den Rechnern der Anwender verteilt werden. <\/p>\n Doch zurück zur Treiber-auswahl. Nachdem Sie den ODBC Driver 17 for SQL Server <\/b>ausgewählt haben, klicken Sie auf die Schaltfläche Weiter<\/b> und im folgenden Dialog auf Fertig <\/b>stellen.<\/p>\n Jetzt beginnt die eigentliche Definition der ODBC-Datenquelle. Im ersten Schritt des Assistenten geben Sie dem Treiber die Bezeichnung WaWi_SQL <\/b>und tragen dann im Eingabefeld Server den Namen Ihres SQL Servers ein.<\/p>\n Die genaue Bezeichnung Ihres SQL Servers können Sie im SQL Server Management Studio ermitteln. Öffnen Sie mit einem Klick auf die Schaltfläche Abfrage <\/b>eine neue Registerkarte (siehe Bild 11) und geben Sie dort die folgende T-SQL-Anweisung ein:<\/p>\n Bild 11: Der Name der SQL Server-Instanz<\/span><\/b><\/p>\n Mit einem Klick auf Ausführen <\/b>erhalten Sie den Servernamen, den Sie kopieren und in das Eingabefeld Server <\/b>der ODBC-Konfiguration einfügen.<\/p>\n Ein Klick auf Weiter <\/b>führt Sie zum nächsten Schritt. Hier wird die Anmeldung zum SQL Server festgelegt.<\/p>\n Als erstes aktivieren Sie die Option Mit SQL Server-Authentifizierung <\/b>anhand der vom Benutzer eingegebenen Anmelde-ID und des Kennworts. Danach geben Sie im Feld Anmelde-ID <\/b>die Anmeldung sa<\/b> sowie im Feld Kennwort <\/b>das zugehörige Kennwort ein (siehe Bild 12). <\/p>\n Bild 12: Anmeldung in der ODBC-Datenquelle<\/span><\/b><\/p>\n Im nächsten Schritt des Assistenten bestimmen Sie die SQL Server-Datenbank, zu der der ODBC-Treiber die Verbindung herstellen soll. Dazu aktivieren Sie die Option Die Standarddatenbank ändern auf <\/b>und wählen in der zugehörigen Auswahlliste die eben installierte Beispieldatenbank WaWi_SQL<\/b> aus. <\/p>\n Eigentlich legen Sie hier nur die Standarddatenbank für diese ODBC-Verbindung fest. Diese wird später in den entsprechenden Auswahldialogen als Vorauswahl angeboten. Was nicht bedeutet, dass man bei der Anmeldung nicht auch eine andere Datenbank wählen könnte. Doch dazu später mehr.<\/p>\n Die Auswahl der Standarddatenbank ist gleichzeitig auch ein Verbindungstest. Können Sie die Datenbank nicht auswählen, haben Sie sich vielleicht bei der Eingabe des Kennworts vertippt. Dann müssen Sie im Assistenten einen Schritt zurück und dort das Kennwort erneut eingeben.<\/p>\n Nach erfolgreicher Auswahl der Standarddatenbank klicken Sie erneut auf Weiter<\/b>. Die nun angebotenen Optionen sind für das aktuelle Beispiel nicht relevant, weshalb Sie die Konfiguration der ODBC-Datenquelle mit einem Klick auf Fertig stellen <\/b>abschließen. <\/p>\n Es folgt noch ein weiterer Dialog, der Ihnen den Test der Datenquelle anbietet. Dieser Test ist nicht mehr erforderlich. Sie haben ihn mit der Auswahl der Standarddatenbank bereits erfolgreich durchgeführt. Ohne korrekte Zugangsdaten wäre die Auswahl nicht möglich gewesen. <\/p>\n Speichern Sie die Konfiguration mit einem Klick auf OK<\/b>. Der ODBC-Datenquellen-Administrator zeigt Ihnen die neu erstellte ODBC-Verbindung. Hiermit ist die Konfiguration nun wirklich abgeschlossen. Sie können den Dialog beenden. <\/p>\n Als nächstes öffnen Sie das Access-Frontend der Beispielapplikation WaWi <\/b>und navigieren dort über Externe Daten|Neue Datenquelle|Aus Datenbank <\/b>zum Eintrag Aus SQL Server<\/b>.<\/p>\n In dem folgenden Dialog Externe Daten – ODBC-Datenbank <\/b>wählen Sie die zweite Option namens Erstellen Sie eine Verknüpfung zur Datenquelle<\/b>, in dem Sie eine verknüpfte Tabelle erstellen und klicken auf Ok<\/b>. <\/p>\n Jetzt sollen Sie die Datenquelle auswählen, die die Verbindung zur SQL Server-Datenbank herstellt. Sie finden Ihre eben angelegte ODBC-Datenquelle in der Registerkarte Computerdatenquelle<\/b>. Wählen Sie die Datenquelle per Doppelklick aus.<\/p>\n Zurück in Access wird als erstes die Eingabe des Kennworts zur Anmeldung sa <\/b>von Ihnen erwartet (siehe Bild 13). Nach erfolgreicher Kennworteingabe dürfen Sie im Dialog Tabellen verknüpfen <\/b>die Tabellen der SQL Server-Datenbank auswählen. <\/p>\n Bild 13: Anmeldung in Access<\/span><\/b><\/p>\n Markieren Sie alle Tabellen mit dem Präfix dbo<\/b>. Hierbei handelt es sich um das Schema dbo<\/b>. Was es mit den Schemata und insbesondere mit dem Schema dbo <\/b>auf sich hat, erfahren Sie in einem der nächsten Artikel.<\/p>\n Aktivieren Sie unbedingt noch die Option Kennwort speichern<\/b>. Nur so wird das Kennwort in der Access-Datenbank gespeichert und Sie müssen es in Zukunft beim Start der Access-Applikation nicht mehr eingeben. <\/p>\n Diese Vorgehensweise mag zwar eleganter sein, als dem Anwender das Kennwort mitzuteilen. Sie ist jedoch bei weitem nicht sicher. Das teilt Ihnen auch Access mit einer entsprechenden Meldung mit (siehe Bild 14). <\/p>\n Bild 14: Sicherheitsabfrage beim Einbinden der Tabellen<\/span><\/b><\/p>\n Das Kennwort wird im Klartext in der ACCDB gespeichert und lässt sich recht einfach auslesen. Dazu öffnen Sie die Access-Datenbank in einem Editor und suchen nach der Bezeichnung Ihrer ODBC-Datenquelle. Die Bezeichnung geben Sie dabei mit einer Leerstelle nach jedem Buchstaben ein. Eine Suche nach W a W i _ S Q L<\/b> liefert Ihnen die Stelle der ODBC-Verbindungszeichenfolge mitsamt dem Kennwort. Ein Risiko, dass Sie für dieses Beispiel in Kauf nehmen und daher die Meldung mit einem Klick auf die Schaltfläche Kennwort speichern <\/b>bestätigen. Dies müssen Sie für jede gewählte Tabelle wiederholen.<\/p>\n Die Tabellen der SQL Server-Datenbank sind nun mitsamt dem Schemanamen eingebunden. Die ursprünglich eingebundenen Tabellen des Access-Backends hatten den gleichen Namen, allerdings ohne den Zusatz dbo_<\/b>. Jegliche Objekte des Access-Frontends mit direkter Bindung an die Tabellen verwenden jedoch die alten Bezeichnungen. <\/p>\n Um ein funktionierendes Frontend zu erhalten, muss das Präfix dbo_ <\/b>aus den Bezeichnungen der eingebundenen Tabellen entfernt werden. Dazu verwenden Sie am besten die Funktion fTabellenUmbenennen <\/b>im Modul Tabellen<\/b>. Starten Sie die Funktion über den Direktbereich im VBA-Editor. <\/p>\n Nachdem die Tabellen ihre ursprünglichen Bezeichnungen wiederhaben, aktualisieren Sie noch die Verbindungen der beiden Pass Through-Abfragen. Dazu öffnen Sie eine der beiden Abfragen im Entwurfsmodus und gehen dort zu den Eigenschaften. <\/p>\n In der Option ODBC-Verbindung <\/b>wählen Sie Ihre eben erstellte ODBC-Datenquelle aus und geben im folgenden Anmeldedialog das Kennwort der Anmeldung sa <\/b>ein. Es folgt ein erneuter Sicherheitshinweis (siehe Bild 15), den Sie mit einem Klick auf Ja<\/b> bestätigen. <\/p>\n Bild 15: Sicherheitsabfrage beim Speichern der Pass Through-Abfrage<\/span><\/b><\/p>\n Diesen Vorgang müssen Sie bei jeder Pass Through-Abfrage wiederholen. Bei zwei Abfragen mag dies noch vertretbar sein, bei mehreren wäre eine automatische Anpassung wünschenswert. <\/p>\n Hierzu gibt es die Funktion fPassThroughVerbindungen <\/b>im Modul Tabellen<\/b>. Sie ermittelt die ODBC-Verbindung der ersten per ODBC eingebundenen Tabelle und weist diese allen Pass Through-Abfragen zu. Der Clou hierbei ist, dass das gespeicherte Kennwort über diesen Weg ebenfalls zugewiesen wird.<\/p>\n Mit der Zuordnung der ODBC-Datenquelle zu den Pass Through-Abfragen ist die Konfiguration der Verbindung zum SQL Server abgeschlossen. <\/p>\n Das Access-Frontend arbeitet nun mit den Tabellen und mittels der Pass Through-Abfragen mit den Gespeicherten Prozeduren der SQL Server-Datenbank. Dabei müssen Sie das Kennwort für die Verbindung nicht mehr eingeben.<\/p>\n Testen Sie es einfach. Schließen Sie die Access-Applikation und starten Sie sie direkt wieder. Die Schaltflächen im Formular Start <\/b>liefern Ihnen die entsprechenden Access-Formulare mit den Daten der SQL Server-Datenbank WaWi_SQL<\/b>. Mit Ausnahme des Formulars Artikel, denn hier erfolgt der Datenzugriff per ADO.<\/p>\n ADO und das Kennwort<\/b><\/p>\n Mit ADO erstellen Sie eine Verbindung zu einer externen Datenquelle. Es spielt keine Rolle, ob Sie dabei auf eine Tabelle einer SQL Server-Datenbank oder auf eine lokale Tabelle des Access-Frontends zugreifen. Für ADO handelt es sich dabei um ein externes Objekt. Im Gegensatz zu ODBC verwenden Sie für den Datenzugriff also keine lokalen Access-Tabellen und Pass Through-Abfragen, sondern direkt die Tabellen und Gespeicherten Prozeduren der SQL Server-Datenbank. <\/p>\n Somit fehlt für den Datenzugriff eine entscheidende Komponente. Bei ODBC speichern Sie mit der ODBC-Datenquelle die Verbindungsdaten in den Eigenschaften des lokalen Access-Objekts und zusätzlich das Kennwort in der ACCDB. Diese Möglichkeit gibt es für einen Zugriff per ADO nicht. Zudem wird die Verbindung zum SQL Server nicht über einen ODBC-Treiber, sondern über einen OLE DB-Treiber hergestellt. Wie bei ODBC sollten Sie auch hier den neuesten Treiber verwenden. <\/p>\n Microsoft bietet seit 2018 eine neue Version des OLE DB-Treibers an. Die aktuelle Version ist Microsoft OLE DB Driver 18.3 for SQL Server<\/b>. Sie finden den Treiber im Microsoft-Downloadbereich unter dem Suchbegriff Microsoft OLE DB Driver for SQL Server <\/b>oder mit dem Kürzel MSOLEDBSQL<\/b>.<\/p>\n Die Beispielapplikation WaWi <\/b>verwendet diesen neuen OLE DB-Treiber. Sollten Sie den Treiber noch nicht installiert haben, holen Sie dies am besten noch vor dem Test des ADO-Beispiels nach.<\/p>\n Die alten OLE DB-Treiber SQL Server <\/b>und SQL Server Native Client<\/b>, auch bekannt unter den Kürzeln SQLOLEDB <\/b>und SQLNCLI<\/b>, werden von Microsoft nicht mehr unterstützt. Es gibt weder eine Weiterentwicklung noch entsprechende Fehlerbehebungen oder gar Sicherheitsupdates. Denken Sie daran, Treiber ohne Herstellersupport stellen ein Sicherheitsrisiko dar. Aus diesem Grund sollten Sie keinen der beiden Treiber verwenden.<\/p>\n Doch zurück zu den Verbindungsdaten. Für jeden Datenzugriff per ADO wird der Name des SQL Servers und der Datenbank sowie die Anmeldung und das zugehörige Kennwort benötigt. Im Gegensatz zu ODBC fehlt jedoch die Möglichkeit, diese Informationen in Access direkt zu speichern. Da ist es naheliegend, die Anmeldedaten in einer eigenen lokalen Tabelle des Access-Frontends zu hinterlegen. Beim Datenzugriff werden die Daten ermittelt und zur Anmeldung am SQL Server verwendet.<\/p>\n Die Tabelle wie auch das Kennwort sollten Sie vor dem Anwender verstecken. Hierzu maskieren Sie die entsprechende Spalte der Tabelle mit dem Eingabeformat Kennwort<\/b>. Ergänzend dazu aktivieren Sie an der Tabelle die Eigenschaft Ausgeblendet<\/b>. Die Tabelle ist dann im Navigationsbereich nicht mehr ohne Weiteres sichtbar. Zugegeben, diese Einstellungen sind keine großen Hürden. Aber es ist immer noch besser als nichts.<\/p>\n Etwas effektiver ist die Definition der Tabelle als Systemtabelle. Systemtabellen sind schreibgeschützt und im Navigationsbereich nur sichtbar, wenn deren Anzeige explizit aktiviert ist. Das Frontend der Beispielapplikation enthält die Tabelle ADO<\/b>. Dort tragen Sie den Namen Ihres SQL Servers und das Kennwort der Anmeldung sa <\/b>ein. Die Tabelle ist als Systemobjekt definiert und somit erst einmal nicht zu sehen. Um mit der Tabelle arbeiten zu können, müssen Sie zunächst die Anzeige der Systemobjekte aktivieren. Dazu klicken Sie mit der rechten Maustaste in den Kopf des Navigationsbereichs, wählen dort den Eintrag Navigationsoptionen<\/b> und aktivieren im folgenden Dialog die Option Systemobjekte anzeigen<\/b>.<\/p>\n Jetzt ist die Tabelle ADO <\/b>zwar sichtbar, aber immer noch schreibgeschützt. Bevor Sie Ihre Verbindungsdaten in die Tabelle eintragen können, müssen Sie diese erst wieder als Benutzertabelle definieren. Für diese Änderung gibt es die Funktion fTabelleAlsSystemObjekt <\/b>im Modul ADO<\/b>. Öffnen Sie den VBA-Direktbereich und führen Sie die Funktion wie folgt aus:<\/p>\n Nun öffnen Sie die Tabelle ADO und geben in dem Feld Server <\/b>den Namen Ihres SQL Servers sowie in der Spalte Kennwort <\/b>Ihr Kennwort zur Anmeldung sa <\/b>ein.<\/p>\n Danach schützen Sie Ihre Eingaben vor unerlaubten Änderungen, indem Sie die Tabelle wieder als Systemtabelle definieren. Dazu führen Sie im VBA-Direktbereich diese Anweisung aus:<\/p>\n Wenn Sie jetzt noch die Tabelle im Navigationsbereich ausblenden, kann ein Anwender nicht ohne weiteres direkt auf die Verbindungsdaten zugreifen. Deaktivieren Sie dazu die Option Systemobjekte anzeigen <\/b>im Dialog Navigationsoptionen<\/b>. Die Daten der Tabelle ADO werden im Formular Artikel <\/b>verwendet. Dort erfolgt der Datenzugriff im Ereignis Beim Öffnen<\/b>. Die hierzu benötigte Verbindungszeichenfolge erstellt die Funktion fAdoPerTabelle <\/b>aus dem Modul ADO<\/b>.<\/p>\n Die Verbindungszeichenfolge kennen Sie vielleicht auch unter dem Namen ConnectionString<\/b>. Diese enthält den Namen des verwendeten Treibers, den Namen des SQL Servers und der Datenbank plus die Anmeldung und das zugehörige Kennwort.<\/p>\n Mit einem Klick auf die Schaltfläche Artikel <\/b>im Formular Start <\/b>testen Sie Ihre Angaben in der Tabelle ADO<\/b>. Bei korrekter Konfiguration sehen Sie die Daten der Tabelle Artikel <\/b>aus der SQL Server-Datenbank WaWi_SQL<\/b>.<\/p>\n Soweit so gut. Sicher ist diese Vorgehensweise jedoch nicht. Das Kennwort können Sie recht einfach im VBA-Direktbereich mit folgendem Code auslesen: <\/p>\n Das Ergebnis ist das Kennwort im Klartext.<\/p>\n Alternativ lässt sich die komplette Verbindungszeichenfolge als Konstante in einer VBA-Funktion hinterlegen. Die Beispieldatenbank zeigt diese Vorgehensweise in der Funktion fAdoPerFunction<\/b>. Sie können dies einfach testen. Öffnen Sie den VBA-Editor und wechseln Sie im Modul ADO <\/b>zur Funktion fAdoPerFunction<\/b>. Dort passen Sie die Verbindungszeichenfolge an Ihre Umgebung an. Dazu überschreiben Sie den Eintrag IHR SQL SERVER <\/b>mit Namen Ihres SQL Servers und beim Parameter Password <\/b>ersetzen Sie IHR KENNWORT <\/b>mit dem Kennwort Ihrer sa<\/b>-Anmeldung.<\/p>\n Nun öffnen Sie den Quellcode des Formulars Artikel <\/b>und gehen zum Ereignis Form_Open<\/b>. Hier tauschen Sie bei der Definition der Verbindungszeichenfolge den Funktionsaufruf fAdoPerTabelle <\/b>mit der Funktion fAdoPerFunction <\/b>aus: <\/p>\n Speichern Sie Ihre Änderungen und wechseln Sie zurück zu Access. Dort klicken Sie im Formular Start<\/b> auf die Schaltfläche Artikel. Als Ergebnis sehen Sie wieder die Daten der Tabelle Artikel<\/b>. Das Sicherheitsniveau verbessert sich bei dieser Variante jedoch nicht. Ein Aufruf der Funktion im VBA-Direktbereich liefert die Verbindungszeichenfolge mit dem Kennwort im Klartext. <\/p>\n Zudem speichern beide Varianten das Kennwort lesbar in der ACCDB. Um das Kennwort zu ermitteln, müssen Sie die ACCDB lediglich in einem Editor öffnen und nach dem Namen Ihres SQL Servers suchen. Als Ergebnis sehen Sie das Kennwort in unmittelbarer Nähe zum SQL Server-Namen.<\/p>\n Das lässt sich natürlich verhindern, indem Sie das Access-Frontend mit einem Datenbank-Kennwort verschlüsseln. In der letzten Ausgabe haben Sie diese und weitere Möglichkeiten kennengelernt, mit denen Sie das Access-Frontend soweit absichern, dass ein Anwender nicht ohne weiteres geschützte Informationen auslesen kann. Sie haben dort aber auch erfahren, wie Sie auf Informationen zugreifen können, die per Datenbank-Kennwort verschlüsselt sind – und Sie haben Frau Bienlein kennengelernt.<\/p>\n Der Fall Bienlein<\/b><\/p>\n Frau Bienlein ist irritiert. Neuerdings haben ihre Änderungen in den Daten des Access-Backends keine Wirkung mehr. Irgendetwas scheint anders zu sein. Ob es an der neuen Version der Auftragsverwaltung liegt Die Kollegen der IT-Abteilung sprechen in letzter Zeit sehr oft von der neuen Auftragsverwaltung und diskutieren dabei immer über den ominösen Begriff SQL<\/b>.<\/p>\n Leicht desillusioniert klickt sich Frau Bienlein in ihrer eigenen Access-Datenbank durch die Menüs. Sie braucht etwas Neues zum Entdecken. Da sieht sie den Eintrag Neue Datenquellen<\/b>. Gut, den Eintrag kennt sie schon, schließlich hat sie hierüber den Zugang zu den Tabellen der alten Auftragsverwaltung erhalten. Aber es gibt dort ja noch weitere Funktionen wie den Eintrag Aus SQL Server<\/b>. Ob es das SQL ist, von dem die IT-Kollegen sprechen Sie klickt auf den Eintrag Aus SQL Server <\/b>und sieht einen alten Bekannten, den Dialog Externe Daten<\/b>. Die zweite Option mit der umständlichen Bezeichnung kennt sie bereits, weshalb sie die Option aktiviert und auf Ok <\/b>klickt. <\/p>\n Der nächste Dialog ist neu für Frau Bienlein. Er zeigt eine leere Registerkarte namens Dateidatenquelle<\/b>. Etwas unsicher schaut sie in der Registerkarte Computerdatenquelle <\/b>nach und findet dort den Eintrag WaWi_SQL<\/b>. Das kommt ihr bekannt vor. WaWi <\/b>ist der Name der Auftragsverwaltung, mit der sie täglich arbeitet, und da ist auch schon wieder dieses SQL<\/b>. Sie fühlt sich auf dem richtigen Weg und wählt den Eintrag WaWi_SQL <\/b>per Doppelklick aus. Es erscheint ein Anmeldedialog. Frau Bienlein fühlt sich herausgefordert und gibt als erstes das ihr bekannte Kennwort der Auftragsverwaltung ein. Jetzt ist sie enttäuscht. Das schon der erste Versuch funktioniert, hätte sie nicht erwartet.<\/p>\n Tatsächlich hat sich der Entwickler das Leben einfach gemacht und das bisher bekannte Kennwort weiterhin verwendet. Warum auch nicht, es ist ja dieselbe Applikation. Nein, dieser Gedanke ist nicht naheliegend. Er ist fahrlässig!<\/p>\n Durch seine Bequemlichkeit bietet der Entwickler Frau Bienlein eine offene Sicherheitslücke, die sie auch voller Tatendrang nutzt. Im Auswahldialog Tabellen verknüpfen <\/b>wird ihr unter anderem die Tabelle Mitarbeiter <\/b>angeboten. Sie wählt die Tabelle aus, aktiviert leicht amüsiert die Option Kennwort speichern <\/b>und klickt auf OK<\/b>. Jetzt erhält Frau Bienlein eine Meldung mit dem Hinweis, dass das Kennwort unverschlüsselt in der Datei gespeichert wird. Zuerst ist sie etwas irritiert von der Meldung, doch dann klickt sie auf die Schaltfläche Kennwort speichern<\/b>. Natürlich soll das Kennwort gespeichert werden. Ob es dabei verschlüsselt wird, ist ihr herzlich egal.<\/p>\n „Da bist du ja wieder.“ denkt sich Frau Bienlein und öffnet die Tabelle Mitarbeiter<\/b>. Sie ändert Ihr Gehalt von 2.500 auf 2.550 Euro.<\/p>\n Ein paar Tage später hat sie wieder etwas Zeit und geht mit ihrer Access-Datenbank erneut auf Entdeckungsreise. Routiniert steuert sie den Menüpunkt Externe Daten|Neue Datenquellen|Aus Datenbank|Aus SQL Server <\/b>an, aktiviert im Dialog Externe Daten <\/b>die zweite Option und wählt anschließend die ODBC-Datenquelle WaWi_SQL <\/b>aus. Wieder öffnet sich der Anmeldedialog. Sie gibt das Kennwort ein und klickt auf Optionen<\/b>. Der Anmeldedialog erweitert sich (siehe Bild 16). Neugierig öffnet sie die Auswahlliste Datenbank <\/b>und wählt den Eintrag WaWi_US<\/b> aus. Nach einem Klick auf OK <\/b>erscheint wie erwartet eine Auswahl von Tabellen. Hier ist Frau Bienlein sehr interessiert an der Tabelle Personal<\/b>.<\/p>\n Bild 16: Auswahl einer Datenbank<\/span><\/b><\/p>\n Nach der Auswahl ist die Tabelle im Navigationsbereich zu sehen. Ein Doppelklick öffnet nicht nur die Tabelle, sondern er liefert Frau Bienlein auch die Informationen über Ihre amerikanischen Kollegen. Das sind jetzt nicht besonders spannende Informationen für Frau Bienlein.<\/p>\n Aber für einen kleinen Spaß reicht es allemal. Sie sagt James King indirekt was sie von ihm hält und ändert seinen Nachnamen in Looser, und da ihrer Meinung nach Frau Miller eh die ganze Arbeit macht, überschreibt sie in der Spalte Position <\/b>den Wert Sales Manager <\/b>mit CEO<\/b>. <\/p>\n Die Änderungen machen in der amerikanischen Geschäftsstelle schnell die Runde. Die US-Kollegen haben tatsächlich viel Spaß mit den Anpassungen. Bis auf Robert King, der die Kollegen der Personalabteilung in Verdacht hat und dort auch seinen Unmut auslässt.<\/p>\n Frau Bienlein agiert mit der Anmeldung sa<\/b>. Somit gibt es für sie keinerlei Einschränkungen im SQL Server. Sie darf die Daten aller Datenbanken lesen und ändern. Sie darf noch weitaus mehr, wie sie ein paar Tage später eindrucksvoll demonstriert.<\/p>\n Im Internet hat Frau Bienlein von Pass Through-Abfragen gelesen. Ein spannendes Konzept, das sie so schnell wie möglich testen möchte. Dabei folgt sie der Anweisung eines Blog-Eintrags. In ihrer Access-Datenbank erstellt sie über Erstellen|Abfrageentwurf <\/b>eine neue Abfrage. Das erscheinende Auswahlfenster Tabelle anzeigen <\/b>schließt sie direkt wieder und klickt im Menü auf Pass-Through<\/b>. In dem leeren Abfrageeditor gibt sie dann diese Anweisung ein:<\/p>\n Sie klickt auf Ausführen<\/b> und erhält den ihr bekannten Auswahldialog der Datenquelle. Hier wählt sie die Datenquelle WaWi_SQL <\/b>aus und gibt im folgenden Dialog das Kennwort für die Anmeldung sa <\/b>ein. Nach Eingabe des Kennworts zeigt die Pass Through-Abfrage die Daten der aktuellen Bewerber. Dabei handelt es sich bestimmt auch um Bewerber für die geplanten Stellen im Verkauf. Frau Bienlein mag keine Konkurrenz und wechselt zur SQL-Ansicht der Pass Through-Abfrage. Hier gibt sie die folgende Anweisung ein:<\/p>\n Erneut klickt sie auf Ausführen<\/b>, wählt die Datenquelle WaWi_SQL <\/b>aus und gibt das Kennwort ein. Umsonst, denn sie erhält lediglich die Meldung aus Bild 17. <\/p>\n Bild 17: Hinweis beim Ausführen der Pass Through-Abfrage<\/span><\/b><\/p>\n Enttäuscht tippt sie wieder den Befehl SELECT * FROM Bewerber <\/b>ein. Nach einem erneuten Klick auf Ausführen<\/b>, der Auswahl der Datenquelle und der Eingabe des Kennworts erhält sie keine Daten, sondern die Meldung, dass der Name Bewerber <\/b>ungültig ist (siehe Bild 18). Die Tabelle wurde nicht gefunden. Das Löschen hat also doch funktioniert.<\/p>\n Bild 18: Hinweis auf Tabelle Benutzer<\/span><\/b><\/p>\n Eine Stunde später kommt in der IT-Abteilung etwas Hektik auf. Die Personalabteilung hat angerufen und sich über einen Fehler in der Bewerberdatenbank beschwert. Laut Fehlermeldung wird die Tabelle Bewerber <\/b>nicht gefunden. An fehlenden Zugriffsrechten kann es nicht liegen. Den Kollegen der IT-Abteilung ist durchaus bewusst, dass alle Mitarbeiter volle Rechte haben. Ein Blick in die Datenbank zeigt, dass die Tabelle tatsächlich nicht mehr existiert. Es beginnt ein mühsames Verfahren.<\/p>\n Die Tabelle Bewerber <\/b>wird neu angelegt und anschließend die letzte Datensicherung der Datenbank unter einem anderen Namen wiederhergestellt. Danach werden die Datensätze der Tabelle Bewerber <\/b>der wiederhergestellten Datenbank in die neue Tabelle importiert. <\/p>\n Ein aufwendiges Szenario, das umso ärgerlicher ist, da Frau Bienlein nun wirklich keine Konkurrenz mag und die Tabelle Bewerber <\/b>zwei Tage später aufs Neue löscht. Überhaupt ist Frau Bienlein begeistert davon, wie einfach sie etwas löschen kann. Deswegen erstellt sie sich eine weitere Pass Through-Abfrage und gibt dort den Befehl DROP DATABASE WaWi_US <\/b>ein. Worauf es am späten Nachmittag in der IT-Abteilung extrem hektisch und laut wird.<\/p>\n Fazit<\/b><\/p>\n Der Fall Bienlein ist natürlich wie beim letzten Mal konstruiert. Eine derart dreiste Gehaltserhöhung sollte schnell auffallen. Alle anderen beschriebenen Aktionen sind jedoch durchaus denkbar. Die Schwachstelle in diesem Szenario ist die Verwendung der Anmeldung sa<\/b>. Vielen Entwicklern ist diese Tatsache bekannt – und dennoch gibt es in der Realität nicht wenige Access und SQL Server-Applikationen, in denen die Anmeldung sa <\/b>recht naiv verwendet wird.<\/p>\n Der Zugriffsschutz lässt sich bereits um einiges erhöhen, wenn das Kennwort alleine den Administratoren vorbehalten ist und es sich dabei um ein komplexes Kennwort handelt. Die Anwender sollten es weder kennen noch leicht erraten können. Nichtsdestotrotz bleibt es bei einer unsicheren Vorgehensweise. Ist das Kennwort für den Datenzugriff in der Access-Applikation gespeichert, kann es dort auch ausgelesen werden. Die Möglichkeiten hierzu wurden in diesem und im vorherigen Artikel beschrieben. Im nächsten Teil der Beitragsreihe lernen Sie eine Alternative zur Anmeldung sa <\/b>kennen – und Sie erfahren, was Frau Bienlein davon hält.<\/p>\n Enthaltene Beispieldateien:<\/p>\n WaWi.accdb<\/p>\n WaWi_SQL.sql<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
SELECT @@Servername;<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
fTabelleAlsSystemObjekt \"ADO\", False<\/span> <\/pre>\nfTabelleAlsSystemObjekt \"ADO\", True<\/span> <\/pre>\nDLookup(\"Kennwort\", \"ADO\")<\/pre>\n
cn.ConnectionString = fAdoPerFunction<\/pre>\n
<\/p>\n
SELECT * FROM Bewerber;<\/pre>\n
DROP TABLE Bewerber;<\/pre>\n
<\/p>\n
<\/p>\n
Downloads zu diesem Beitrag<\/h3>\n