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
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
