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.
Der SQL Server arbeitet mit einer mehrstufigen Sicherheitsarchitektur.
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.
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.
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.
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.
Die SQL Server-Sicherheitsarchitektur
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 haben. Sie erhalten ein Namensschild mit der Aufschrift Besucher und werden gebeten, es sich in der Sitzgruppe gemütlich zu machen, während Sie auf Herrn Müller warten.
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.
Herr Müller lässt nicht lange auf sich warten. Er begrüßt Sie höflich und nimmt Sie mit in die Abteilung Einkauf. Dort sollen Sie in seinem Auftrag Daten lesen, einfügen, ändern und löschen.
Der Zutritt zur Abteilung Einkauf ist in der SQL Server-Instanz vergleichbar mit der Zuordnung der Anmeldung Besucher zur Datenbank Einkauf. In der Datenbank existiert jetzt der Benutzer Besucher, dem Lese- und Schreibrechte für alle Daten erteilt wurden
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.
Dieser Abteilungswechsel entspricht der Zuordnung der Anmeldung Besucher zu einer weiteren Datenbank der SQL Server-Instanz – der Datenbank Personal. Dort gibt es nun auch einen Benutzer namens Besucher. Allerdings besitzt dieser nur Leserechte.
Zusammengefasst zeigt das Beispiel eine SQL Server-Instanz mit der Anmeldung Besucher. Diese ist den Datenbanken Einkauf und Personal zugeordnet.
Die Datenbank Einkauf enthält den Benutzer Besucher mit Lese- und Schreibrechten. In der Datenbank Personal gibt es ebenfalls einen Benutzer namens Besucher, dieser besitzt jedoch nur Leserechte.
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 und somit letztendlich auf den Anwender, der diese Anmeldung verwendet.
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.
SQL Server-Instanzen
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.
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, verbinden Sie sich mit der SQL Server-Instanz PC01.
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, steht nach der Installation eine weitere eigenständige SQL Server-Instanz unter dem Namen PC01Entwicklung zur Verfügung.
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 wäre PC01SQLEXPRESS.
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.
Eine Anmeldung namens Müller in der SQL Server-Instanz PC01 lässt sich nur für den Zugang zu dieser Instanz verwenden. Eine Verbindung zur Instanz PC01Entwicklung ist mit dieser Anmeldung nicht möglich.
Existiert in der SQL Server-Instanz PC01Entwicklung ebenfalls eine Anmeldung namens Müller, ermöglicht diese zwar den Zugang zur Instanz PC01Entwicklung, aber eben nicht zur Instanz PC01. Die beiden Anmeldungen haben schlicht und ergreifend nichts miteinander zu tun.
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 die Datenbanken mit den sensiblen Daten der Forschungsabteilung.
Im oben verwendeten Vergleich mit dem Besucher im Unternehmen stellt die Standardinstanz die Zentrale des Unternehmens dar und die Instanz PC01Forschung 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.
Begrifflichkeiten
Die im SQL Server verwendeten Begriffe Anmeldung und Benutzer sind nicht besonders geeignet für eine Artikelserie zum Thema Security. Beide Begriffe haben mehrere Bedeutungen.
Bei einer Anmeldung kann es sich um eine SQL Server-Anmeldung oder auch um die Anmeldung am Clientrechner handeln. Der Begriff Benutzer steht für die Person am Rechner wie für die Zuordnung einer SQL Server-Anmeldung zu einer Datenbank.
Um Missverständnisse zu vermeiden, beschreibt von nun an der Begriff Anwender die Person am Rechner und Benutzerkonto die von der Person verwendete Anmeldung am Betriebssystem.
Zudem wird der Einfachheit halber ab jetzt der Begriff SQL Server anstatt SQL Server-Instanz verwendet.
Authen-ti-fi-zie-rungs-methoden
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.
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.
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.
Wenn Sie sich bei der Installation für die Windows-Authentifizierung entscheiden, sollten Sie mit der Schaltfläche Hinzufügen ein Benutzerkonto als Administrator aufnehmen (siehe Bild 1). Nur mit diesem Benutzerkonto haben Sie nach der Installation entsprechende Adminis-trationsrechte im SQL Server.
Bild 1: Administrator bei der Windows-Authentifizierung
Reicht Ihnen die Windows-Authentifizierung nicht aus, können Sie zusätzlich noch die SQL Server-Authentifizierung aktivieren.
Diese Kombination wird Gemischter Modus genannt.
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.
Entscheiden Sie sich für den gemischten Modus, müssen Sie der SQL Server-Anmeldung sa ein Kennwort vergeben (siehe Bild 2). sa steht für System Administrator und beinhaltet alle administrativen Rechte für den SQL Server.
Bild 2: sa-Konto bei der SQL Server-Authentifizierung
Die Anmeldung sa 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.
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.
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).
Bild 3: Die SQL Server-Instanz im Objekt-Explorer
Im Kontextmenü wählen Sie dann den Eintrag Eigenschaften und wechseln im folgenden Dialog zur Seite Sicherheit. Unter Serverauthentifizierung können Sie nun zwischen den einzelnen Modi wechseln (siehe Bild 4).
Bild 4: Wechsel der Authentifizierungsmethode
Nach einem Klick auf OK 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.
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.
Bild 5: Neustart der SQL Server-Instanz
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.
Nach dem Wechsel der Authentifizierungsmethode müssen Sie die Anmeldung sa noch aktivieren und ihr ein Kennwort vergeben. Dazu navigieren Sie zum Ordner Sicherheit, erweitern den Unterordner Anmeldungen und öffnen per Doppelklick auf den Eintrag sa den Dialog Anmeldungseigenschaften.
Hier wechseln Sie zur Seite Status und aktivieren unter Anmeldename die Option Aktiviert (siehe Bild 6). Danach geben Sie der Anmeldung in der Seite Allgemein ein Kennwort und speichern die Änderungen mit einem Klick auf OK. Jetzt können Sie sich am SQL Server mit der Authentifizierungsmethode SQL Server-Authentifizierung, dem Anmeldename sa und dem eben erstellten Kennwort anmelden (siehe Bild 7).
Bild 6: Authentifizierung mit der Anmeldung sa
Bild 7: Aktivieren der Anmeldung sa
Die SQL Server-Anmeldung „sa“
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.
Es bietet sich ja auch an. Die Anmeldung sa 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.
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.
Leider bleibt es in vielen Fällen dann bei dieser Authentifizierung. Die sa-Anmeldung ist nicht nur in Entwicklungs- und Testumgebungen zu finden, sondern auch in vielen Produktivumgebungen.
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-Anmeldung, sollten Ihnen die Möglichkeiten klar sein, die Sie Ihren Anwendern damit in die Hand geben. Genau diese werden Sie nun kennenlernen.
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.
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
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.
Mit der Anmeldung sa 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.
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.
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
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.
Mit der Anmeldung sa 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.
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.
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 gibt es im SQL Server keine Grenzen.
Der Anwender kann die Daten aller Datenbanken einsehen und ändern! Dem Benutzer das Kennwort für die Anmeldung sa mitzuteilen, mag eine einfache Lösung sein.
Sie ist aber, wie so oft bei einfachen Lösungen, die unsicherste Methode, die Sie verwenden können.
Access und das Kennwort
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.
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.
Die Konfiguration der ODBC-Datenquelle können Sie anhand der Beispielapplikation WaWi nachvollziehen. Dazu installieren Sie zunächst die Datenbank WaWi_SQL in Ihrem SQL Server.
Öffnen Sie im SQL Server Management Studio die Datei WaWi_SQL.sql und starten Sie das Skript mit einem Klick auf Ausführen (siehe Bild 8). Nachdem die Datenbank angelegt ist, sehen Sie in der Registerkarte Meldungen die Ausgabe Fertig!.
Bild 8: Installation der Beispieldatenbank
Nun drücken Sie die Windows-Taste, geben als Suchbegriff ODBC ein und wählen den Eintrag ODBC-Datenquellen (32-Bit). Im Dialog ODBC-Datenquellen-Administrator aktivieren Sie die Registerkarte System-DSN und klicken dort auf die Schaltfläche Hinzufügen (siehe Bild 9).
Bild 9: Anlegen der ODBC-Datenquelle
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.
Bild 10: Auswahl des ODBC-Treibers
Aus diesem Grund sollten Sie die neueste Version verwenden. Aktuell ist dies ODBC Driver 17 for SQL Server. Falls Sie diesen Treiber in Ihrer Auswahl nicht sehen, müssen Sie ihn zunächst installieren. Sie finden den Treiber im Microsoft Downloadbereich unter dem Suchbegriff ODBC Driver 17 for SQL Server.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo