Bernd Jungbluth, Horn
Der Zugriff von Access auf die Daten einer SQL Server-Datenbank erfolgt über eine Authentifizierung im SQL Server. Hierfür wird gerne die SQL Server-Anmeldung sa verwendet, ist sie doch standardmäßig in jeder SQL Server-Installation vorhanden. So verlockend diese Anmeldung auch sein mag, für einen Zugriffsschutz ist sie nicht empfehlenswert. Der dritte Teil dieser Reihe zeigt Ihnen eine Alternative.
Die Alternative ist recht einfach: Sie verwenden anstelle der Anmeldung sa eine eigene Anmeldung. Doch bevor Sie eine neue Anmeldung im SQL Server anlegen, sollten Sie sich zuerst um die Anmeldung sa kümmern.
Die Anmeldung sa
sa steht für System Administration. Mit der Anmeldung sa werden Sie zum Datenbank-Administrator Ihres SQL Servers. Sie dürfen Datenbanken anlegen und löschen, Rechte vergeben und entziehen, alle Daten lesen und ändern und vieles mehr. Kurz gesagt gibt es mit der Anmeldung sa für Sie keine Grenzen in Ihrem SQL Server. Das ist auch gut so. Wie sonst könnten Sie den Aufgaben eines Datenbank-Administrators nachkommen Als solcher sind Sie verantwortlich für die Verfügbarkeit des SQL Servers und der dort enthaltenen Datenbanken. Dies ist nicht nur eine technische Anforderung, sie wird sogar in verschiedenen Gesetzen wie der DSGVO verlangt. Soweit der technische Aspekt. Es geht aber noch weiter. Als Datenbank-Administrator sind Sie schlicht und ergreifend verantwortlich für die Daten. Dies mag zwar nicht zur Definition eines Datenbank-Administrators gehören, aber mal Hand aufs Herz, bei wem steht der Geschäftsführer nach einem Datenverlust oder wenn die Daten durch einen Fremden verfälscht wurden Richtig, beim Datenbank-Administrator – und der gerät in solchen Situationen schnell in Erklärungsnot.
Sie sollten sich Ihrer Verantwortung als Datenbank-Administrator bewusst sein. Es gehört zu Ihren Aufgaben, die Daten vor unerlaubtem Zugriff und vor Verlust zu schützen. Ob nun ein Fremder gewollt auf die Daten zugreifen oder ein Angestellter aufgrund zu hoher Rechte die Daten aus Versehen löschen will: Sie müssen entsprechende Maßnahmen treffen, um unerlaubte Zugriffe oder Datenverlust zu verhindern.
Im SQL Server ist das erste Ziel solcher Maßnahmen die Anmeldung sa. Geben Sie dieser Anmeldung ein komplexes Kennwort. Dabei gibt es eine einfache Regel zu beachten: Das Kennwort taugt nichts, wenn Sie oder einer Ihrer Kollegen es kennt. Am besten generieren Sie das Kennwort in einem Password-Safe und speichern es dort auch. Nur Sie und die anderen Datenbank-Administratoren haben einen Zugriff auf diesen Password-Safe.
Die Änderung des Kennworts erfolgt im SQL Server Management Studio. In dessen Anmeldedialog wählen Sie als Authentifizierung die SQL Server-Authentifizierung und geben als Anmeldenamen sa mitsamt dem zugehörigen Kennwort ein (siehe Bild 1). Nach einem Klick auf Verbinden haben Sie Zugriff auf den Objekt-Explorer.
Bild 1: Authentifizierung am SQL Server mit sa
Die folgenden Beispiele beziehen sich auf die früheren Beiträge dieser Reihe. Im Fall der Anmeldung bedeutet dies, dass der „Gemischte Modus“ verwendet wird und Sie sich sowohl mit Ihrer Windows-Authentifizierung als auch mit einer SQL Server-Authentifizierung zum SQL Server verbinden können. Sollte dies nicht der Fall sein, beachten Sie bitte die Installationsanleitung der Beispieldateien.
Hinweis 1: Gemischter Modus – Windows- und SQL Server-Authentifizierung
Im Objekt-Explorer navigieren Sie zum Ordner Sicherheit und erweitern den Unterordner Anmeldungen. Per Doppelklick auf den Eintrag sa öffnen Sie den Dialog Anmeldungseigenschaften (siehe Bild 2). Hier geben Sie das neue Kennwort in den Eingabefeldern Kennwort und Kennwort bestätigen ein. Die zusätzliche Eingabe des alten Kennworts ist für Sie als Datenbank-Administrator nicht erforderlich. Das alte Kennwort müssen Sie nur angeben, wenn Sie ohne administrative Rechte am SQL Server angemeldet sind und ihr eigenes Kennwort ändern möchten beziehungsweise die Kennwörter von anderen Anmeldungen, für die Sie die entsprechenden Freigaben besitzen.
Bild 2: Eigenschaften der Anmeldung sa
Aktivieren Sie unbedingt die Option Kennwortrichtlinie erzwingen. Nur so ist sichergestellt, dass Ihr neues Kennwort den Windows-Kennwortrichtlinien entspricht. Die Windows-Kennwortrichtlinien verwalten Sie in den lokalen Gruppenrichtlinien (siehe Bild 3) oder aber Ihr IT-Systemadministrator legt diese global für alle Computer in Ihrem Unternehmen fest. Diese Option ist sehr hilfreich. Gerade im aktuellen Fall erinnert sie Sie daran, der Anmeldung sa ein komplexes Kennwort zu vergeben.
Bild 3: Kennwortvorgaben per Gruppenrichtlinien
Die Option Ablauf des Kennworts erzwingen orientiert sich ebenfalls an den Windows-Kennwortrichtlinien. Bei aktivierter Option müssen Sie das Kennwort in regelmäßigen Abständen ändern. Der Abstand ergibt sich aus den Angaben zum Kennwortalter in den Windows-Kennwortrichtlinien.
Ist es nicht übertrieben, ein generiertes Kennwort, das zudem noch in einem Password-Safe verwahrt wird, regelmäßig zu ändern Natürlich nicht! Sollte wider Erwarten jemand Unbefugtes das Kennwort wissen, kann er es nur bis zur nächsten Neuvergabe nutzen. Danach muss er sich wieder die Mühe machen, das Kennwort zu erraten oder es sich per Social Engineering zu erschleichen.
Durch die Aktivierung der Option Ablauf des Kennworts erzwingen wird die Option Benutzer muss das Kennwort bei der nächsten Anmeldung ändern eingeblendet und aktiviert. Diese Option ist nur interessant, wenn das Kennwort beim ersten Anmeldevorgang durch den Anwender geändert werden soll. In diesem Fall sind Sie selbst der Anwender der Anmeldung und da Sie gerade ein neues Kennwort vergeben, müssen Sie es beim nächsten Anmeldevorgang nicht gleich wieder ändern. Aus diesem Grund können Sie das Häkchen wieder entfernen.
Die restlichen Optionen sind für die Neuvergabe des Kennworts nicht relevant. Speichern Sie die Änderung mit einem Klick auf OK. Das Kennwort der Anmeldung wurde erfolgreich geändert. Da Sie aktuell diese Anmeldung verwenden, sollten Sie die Verbindung trennen und neu erstellen. Dazu beenden Sie die Verbindung mit der Schaltfläche aus Bild 4.
Bild 4: Trennen der Verbindung
Anschließend starten Sie den Anmeldedialog direkt wieder mit der Schaltfläche aus Bild 5. Hier wählen Sie erneut die SQL Server-Authentifizierung und geben sa als Anmeldenamen ein. In Ihrem Password-Safe kopieren Sie das Kennwort und fügen es in das Feld Kennwort ein. Mit einem Klick auf Verbinden melden Sie sich erneut am SQL Server an.
Bild 5: Herstellen der Verbindung
Das war doch einfach. Anmeldedialog starten, sa eingeben, Kennwort kopieren und einfügen. Gut, in Zukunft müssen Sie erst noch den Password-Safe öffnen, dort das Kennwort eingeben und innerhalb des Safes den Eintrag sa finden. Ist allein der Gedanke daran nicht schon mühsam Da gibt es eine gute Nachricht. Sie müssen nicht jedes Mal das Kennwort im Password-Safe suchen. Denn die Anmeldung sa ist ab jetzt für Sie und alle anderen Datenbank-Administratoren tabu. Nur in absoluten Ausnahme- und Notfällen dürfen Sie es verwenden.
Anmeldung für Datenbank-Administratoren
Administrative Tätigkeiten erledigen Sie mit Ihrem Windows-Benutzerkonto. Die erforderlichen Rechte dazu haben Sie sich vielleicht schon bei der Installation vom SQL Server gegeben. Dort konnten Sie bei der Serverkonfiguration die SQL Server-Administratoren festlegen. Mit einem Klick auf die Schaltfläche Aktuellen Benutzer hinzufügen wurden Sie zum Datenbank-Administrator des SQL Servers und über die Schaltfläche Hinzufügen waren Sie in der Lage, weitere Kollegen als Datenbank-Administratoren aufzunehmen (siehe Bild 6).
Bild 6: Definition eines Datenbank-Administrators bei der Installation
Wenn dem so ist, sehen Sie im Ordner Anmeldungen unter Sicherheit einen Eintrag mit Ihrem Windows-Benutzerkonto. Diese Anmeldung besitzt die gleichen Rechte wie die Anmeldung sa. Sie haben also keinerlei Nachteile, wenn Sie in Zukunft die Anmeldung zu Ihrem Windows-Benutzerkonto verwenden.
Um wie beim letzten Teil dieser Reihe eine Verwirrung bezüglich der Begriffe Anwender, Benutzer und Anmeldung zu vermeiden, gelten ab hier die wie folgt definierten Begriffe:
- Anmeldung: Die Windows- oder SQL Server-Authentifizierung am SQL Server
- Benutzer: Der Datenbankbenutzer einer SQL Server-Anmeldung
- Anwender: Die Person am Rechner
- Benutzerkonto: Das Benutzerkonto der Person am Rechner
Sollten Sie wider Erwarten keine Anmeldung mit Ihrem Benutzerkonto sehen, können Sie dieses jetzt anlegen.
Wählen Sie hierzu im Kontextmenü des Eintrags Anmeldungen den Eintrag Neue Anmeldung.
Im Dialog Anmeldung – Neu klicken Sie auf Suchen. Die Suche ist abhängig vom Suchpfad, den Sie über die Schaltfläche Pfade festlegen (siehe Bild 7). Handelt es sich bei Ihrem Benutzerkonto um ein lokales Konto, stellen Sie den Suchpfad auf den Namen des Computers ein. Ist es ein Konto aus Ihrem Active Directory, wählen Sie Ihre Domäne als Suchpfad.
Bild 7: Suche eines Windows-Benutzerkontos
Anschließend tragen Sie Ihren Benutzernamen ein und klicken auf Namen überprüfen. Bei einer korrekten Eingabe wird der Benutzername mit dem Namen des Computers oder der Domäne ergänzt. Klicken Sie auf OK und wechseln Sie zur Seite Serverrollen. Hier markieren Sie den Eintrag sysadmin und bestätigen die Auswahl mit OK.
Nun existiert eine SQL Server-Anmeldung mit einem Verweis auf Ihr Benutzerkonto. Durch die Zuordnung zur Serverrolle sysadmin haben Sie mit dieser Anmeldung die gleichen Rechte wie die Anmeldung sa. Es spricht also nichts dagegen, ab jetzt diese Anmeldung zu verwenden.
Die Verbindung zum SQL Server können Sie mit den Ihnen bereits bekannten Schaltflächen trennen und wiederherstellen. Im Anmeldedialog wählen Sie dann bei Authentifizierung die Windows-Authentifizierung und klicken auf Verbinden. Ein Kennwort müssen Sie dabei nicht eingeben. Die Authentifizierung am SQL Server erfolgt mit Ihrer aktuellen Anmeldung am Betriebssystem. Möglicherweise haben Sie bei der Installation nicht Ihr Benutzerkonto als Datenbank-Administrator angegeben, sondern ein anderes und allgemeineres wie zum Beispiel SqlAdministrator. Solche Benutzerkonten können Sie natürlich auch für die Administration des SQL Servers verwenden. Jedoch ist das Anmelden mit einem anderen Benutzerkonto am SQL Server Management Studio nicht so einfach.
Der Anmeldedialog bietet diese Möglichkeit schlicht und ergreifend nicht an. Es bleibt Ihnen nichts anderes übrig, als das gewünschte Benutzerkonto bereits beim Start des SQL Server Management Studios zu verwenden. Dazu melden Sie sich entweder mit dem Benutzerkonto an Ihrem Computer an oder Sie starten das SQL Server Management Studio über die Option Als anderer Benutzer ausführen. Dies funktioniert am besten über die Verknüpfung zum SQL Server Management Studio. Klicken Sie die Verknüpfung bei gedrückter Umschalt-Taste mit der rechten Maustaste an und wählen Sie dort den Eintrag Als anderer Benutzer ausführen. In dem folgenden Dialog geben Sie den Benutzernamen und das zugehörige Kennwort ein.
Das SQL Server Management Studio stellt nun die Verbindung zum SQL Server mit den Rechten des angegebenen Benutzerkontos her. Diese Möglichkeit zeigt einmal mehr, warum Anwender mit hohen Rechten sehr vorsichtig mit Ihren Kennwörtern umgehen sollten. Dies gilt ebenso für Kennwörter von Sammelkonten wie SqlAdministrator.
Grundsätzlich sollten Sie auf Sammelkonten wie SqlAdministrator verzichten. Wer ist nochmal verantwortlich für die Daten Richtig, die Datenbank-Administratoren. Arbeiten alle mit ein und demselben Benutzerkonto, lässt sich nicht nachvollziehen, wer welche administrativen Tätigkeiten im SQL Server durchgeführt hat.
Waren Sie es oder einer Ihrer Kollegen oder gar ein Unbekannter, der sich das Kennwort des Sammelkontos erschlichen hat
Dies gilt insbesondere dann, wenn es sich bei dem Sammelkonto nicht um eine Windows-Authentifizierung, sondern um eine speziell dafür erstellte SQL Server-Authentifizierung handelt. Wobei die Idee an sich schon unsinnig ist. Wo bitte liegt der Vorteil, anstelle der Anmeldung sa eine eigene SQL Server-Authentifizierung mit Administrationsrechten zu nutzen Eine solche Anmeldung bringt eher Nachteile mit sich, denn mit ihr gibt es eine weitere Anmeldung mit administrativen Rechten, um die Sie sich kümmern müssen.
Sammelkonten sind tabu! Wie sieht es mit Windows-Gruppen aus In Windows können Sie mehrere Benutzerkonten in Gruppen zusammenfassen. Da ist es doch naheliegend, die Benutzerkonten der Datenbank-Administratoren in eine Windows-Gruppe zu packen und im SQL Server für diese Windows-Gruppe eine Anmeldung mit administrativen Rechten anzulegen. Das ist tatsächlich möglich. SQL Server erlaubt Windows-Gruppen als Anmeldungen. Das Erstellen einer solchen Anmeldung ist identisch mit der eines Benutzerkontos, nur dass Sie anstelle des Benutzerkontos die Windows-Gruppe wählen.
Mit einer Anmeldung basierend auf einer Windows-Gruppe lässt sich keine Verbindung zum SQL Server herstellen. Eine solche Anmeldung definiert lediglich die Rechte für die Mitglieder der Windows-Gruppe. Auf diese Weise können sich die Mitglieder der Windows-Gruppe am SQL Server anmelden und dort mit den zugewiesenen Rechten agieren. Dabei arbeiten diese im SQL Server nicht unter dem Namen der Windows-Gruppe, sondern unter dem ihres eigenen Windows-Benutzerkontos.
Das Konzept der Windows-Gruppen als Anmeldungen im SQL Server ist sehr effektiv und wird in einem gesonderten Beitrag ausführlicher beschrieben. Bei Datenbank-Administratoren jedoch sind Windows-Gruppen nicht zu empfehlen.
Die Pflege der Windows-Gruppen gehört zu den Aufgaben des IT-Systemadministrators. Er kann Mitglieder aus der Gruppe entfernen und neue aufnehmen. Zum Beispiel könnte er der Windows-Gruppe der Datenbank-Administratoren sein eigenes oder besser noch ein komplett neues Benutzerkonto hinzufügen. Wodurch er im SQL Server mit seinem eigenen oder dem speziell dafür angelegen Benutzerkonto uneingeschränkte Rechte hätte. Er wäre somit in der Lage, alle Daten zu lesen und diese auch zu seinen Gunsten zu ändern.
Wer ist nochmal verantwortlich für die Daten Sie als Datenbank-Administrator! Verwenden Sie als Anmeldung für die Datenbank-Administratoren eine Windows-Gruppe, geben Sie schlicht und ergreifend die Kontrolle ab. Sie haben keinen Einfluss darauf, wer wann und für wie lange Mitglied dieser Windows-Gruppe ist. Für Anmeldungen mit administrativen Rechten sind Windows-Gruppen genauso tabu wie Sammelkonten.
Es gibt eine einfache und klare Empfehlung für Anmeldungen mit administrativen Rechten: Jeder Datenbank-Administrator erhält im SQL Server seine eigene Anmeldung. Diese Anmeldung verweist auf das persönliche Benutzerkonto des Datenbank-Administrators. Heißen Ihre Datenbank-Administratoren Hesselbach und Hoppenstett, gibt es im SQL Server eine Anmeldung mit dem Verweis zum Benutzerkonto Hesselbach und eine weitere mit dem Verweis zum Benutzerkonto Hoppenstett.
Diese Sorgfalt hat noch einen weiteren Vorteil. Erfolgt der Zugang über eine Windows-Gruppe, können sich die Datenbank-Administratoren recht einfach vom SQL Server aussperren. Ist ein Datenbank-Administrator über eine Windows-Gruppe mit dem SQL Server verbunden, kann er die Anmeldung zur Windows-Gruppe ohne weiteres löschen. Worauf ihm beim nächsten Verbindungsversuch der Zugang verwehrt wird, denn ohne die Anmeldung der Windows-Gruppe fehlt ihm die Legitimation.
Ist der Datenbank-Administrator über sein persönliches Benutzerkonto angemeldet, kann er weder seine Anmeldung noch die seiner ebenfalls angemeldeten Kollegen löschen. Anmeldungen mit aktiven Verbindungen lassen sich nicht entfernen, Anmeldungen ohne aktuelle Verbindungen aber durchaus. Auf diese Weise wäre es zwar denkbar, dass sich die Datenbank-Administratoren gegenseitig die Anmeldungen löschen, wenn der jeweilige Kollege gerade nicht angemeldet ist. Es bleibt dabei aber immer eine Anmeldung mit administrativen Rechten übrig und über diese lassen sich die gelöschten Anmeldungen wieder neu erstellen.
Der IT-Systemadministrator hingegen kann durchaus alle Datenbank-Administratoren vom SQL Server aussperren. Dazu braucht er nur versehentlich ihre Benutzerkonten im Active Directory zu löschen. Das erneute Anlegen eines der Benutzerkonten wäre keine Lösung, da hierbei eine neue Security Identifier, kurz SID, erstellt wird – und eine SQL Server-Anmeldung über die Windows-Authentifizierung basiert genau auf dieser SID.
Für den Fall, dass sich keiner der Datenbank-Administratoren mehr mit dem SQL Server verbinden kann, steht eine Art Ersatzschlüssel zur Verfügung: die Anmeldung sa.
Das ist aber auch der einzige legitime Anwendungsfall für diese Anmeldung. Sollten sich tatsächlich alle Datenbank-Administratoren vom SQL Server ausgesperrt haben, darf sich einer von ihnen mit der Anmeldung sa zum SQL Server verbinden und den Fehler beheben. Sobald die Datenbank-Administratoren wieder ihre eigenen Anmeldungen besitzen, erhält die Anmeldung sa ein neues per Password-Safe generiertes Kennwort. Ab dann arbeiten alle Datenbank-Administratoren wieder mit ihren eigenen Anmeldungen.
Eigentlich ist die Anmeldung sa nicht einmal für eine solche Ausnahmesituation erforderlich. Sogar für diesen unwahrscheinlichen Fall bietet SQL Server eine Lösung. In einer ruhigen Minute, wenn kein Anwender mehr am SQL Server angemeldet ist, schließen Sie Ihr SQL Server Management Studio. Anschließend öffnen Sie den SQL Server-Konfigurations-Manager, navigieren zum Ordner SQL Server-Dienste und beenden dort den SQL Server-Dienst (siehe Bild 8). Falls Sie nicht mit der SQL Server Express Edition arbeiten, beenden Sie auch den Dienst vom SQL Server-Agent. Sie finden den SQL Server-Konfigurations-Manager in der Programmgruppe des SQL Servers.
Bild 8: Der SQL Server-Dienst im SQL Server Konfigurations-Manager
Nun öffnen Sie per Doppelklick auf den SQL Server-Dienst dessen Eigenschaften-Dialog und wechseln zur Registerkarte Startparameter. Unter Startparameter angeben tragen Sie -m ein und klicken auf Hinzufügen (siehe Bild 9). Durch diesen Parameter startet der SQL Server-Dienst im Einzelbenutzermodus. Nach einem Klick auf Übernehmen werden Sie darauf hingewiesen, dass die Änderung erst nach einem Neustart des Diensts wirksam wird.
Bild 9: Die Startparameter des SQL Server-Diensts
Bestätigen Sie die Meldung und schließen Sie den Dialog mit OK. Anschließend wählen Sie im Kontextmenü des SQL Server-Diensts den Eintrag Starten.
Nachdem der Dienst neu gestartet ist, klicken Sie mit der rechten Maustaste auf die Verknüpfung zu Ihrem SQL Server Management Studio und wählen Als Administrator ausführen. Im Anmeldedialog erstellen Sie die Verbindung zum SQL Server mit der Windows-Authentifizierung. Über diesen Umweg haben Sie nun administrative Rechte im SQL Server und können ungehindert die fehlenden Anmeldungen anlegen.
Sind alle fehlenden Anmeldungen wiederhergestellt, müssen Sie den Einzelbenutzermodus wieder beenden. Dazu schließen Sie das SQL Server Management Studio und wechseln zum SQL Server Konfigurations-Manager. Dort entfernen Sie in den Eigenschaften des SQL Server-Diensts den Eintrag -m und starten den Dienst erneut. Denken Sie dabei auch an den Neustart des Diensts vom SQL Server-Agent.
Der Ersatzschlüssel
Wenn selbst ein solch außergewöhnlicher Fall ohne die Anmeldung sa gelöst werden kann, stellt sich die Frage, wofür sie denn überhaupt benötigt wird. Welchen Vorteil oder Nutzen bietet die Anmeldung sa einem Datenbank-Administrator
Nicht wenige Datenbank-Administratoren fühlen sich schlicht und ergreifend wohler, wenn ein Ersatzschlüssel in Form der Anmeldung sa existiert. Im beschriebenen Fall ist die Lösung mit dem Ersatzschlüssel auch weniger aufwendig. Anstatt erst alle Anwender aufzufordern, die Applikationen mit Zugriff zum SQL Server zu beenden, um dann den SQL Server im Einzelbenutzermodus starten zu können, melden Sie sich einfach per sa an und stellen die gelöschten Anmeldungen wieder her.
Auf der anderen Seite ist die Anmeldung sa eine nicht unwesentliche Sicherheitslücke. Diese Anmeldung existiert in jedem SQL Server. Möchte sich ein Fremder Zugang zum SQL Server verschaffen, muss er nicht erst mühsam einen Anmeldenamen für seine Attacke ermitteln. Er kann sich darauf verlassen, dass es eine Anmeldung namens sa gibt. Das reduziert seinen Aufwand um die Hälfte, weshalb er sich mit aller Energie direkt auf den zweiten Teil konzentrieren wird – das Kennwort.
Zugunsten der Sicherheit sollten Sie auf den Ersatzschlüssel verzichten und die Anmeldung sa deaktivieren. Dies ist übrigens die offizielle Empfehlung von Microsoft. Das Deaktivieren findet im Eigenschaften-Dialog der Anmeldung sa statt. Dort finden Sie in der Seite Status die Option Deaktiviert (siehe Bild 10). Eine bessere Alternative ist die Deaktivierung mittels der Systemprozedur sp_SetAutoSAPasswordAndDisable. Hierüber erhält die Anmeldung sa ein zufällig generiertes Kennwort, bevor sie dann letztendlich deaktiviert wird.
Bild 10: Deaktivieren der Anmeldung sa
Der Unterschied beider Vorgehensweisen liegt in dem zufällig erzeugten Kennwort. Bei einem einfachen Deaktivieren bleibt das ursprüngliche Kennwort erhalten. Nach einem erneuten Aktivieren der Anmeldung sa können Sie direkt wieder mit dem bekannten Kennwort eine Verbindung zum SQL Server herstellen. Dies ist nach einem Deaktivieren über die Systemprozedur nicht so einfach möglich. Das dabei vergebene Kennwort ist weder bekannt noch lässt es sich ermitteln. Beim Reaktivieren der Anmeldung sa müssen Sie dieser zuerst ein neues Kennwort vergeben.
Weitere Möglichkeiten zum Verhindern des Zugriffs mit der Anmeldung sa gibt es nicht. Die Anmeldung lässt sich ebenso wenig löschen, wie Sie ihr die administrativen Rechte entziehen können.
Vielleicht haben Sie ein ungutes Gefühl beim Deaktivieren der sa-Anmeldung oder wollen auch nicht so recht auf den Ersatzschlüssel verzichten. Für diesen Fall gibt es eine weitere Alternative. Geben Sie der Anmeldung sa doch einfach einen anderen Namen. Dazu markieren Sie die Anmeldung im Objekt-Explorer, wählen im Kontextmenü Umbenennen (siehe Bild 11) und vergeben einen unscheinbaren Anmeldenamen. Wie wäre es mit LogReader
Bild 11: Umbenennen der Anmeldung sa
Die Anmeldung sa existiert zwar weiterhin mit den administrativen Rechten, jedoch nicht mehr unter dem bekannten Namen. Ein Verbindungsversuch mit sa liefert die Fehlermeldung aus Bild 12. Melden Sie sich hingegen mit der Anmeldung LogReader an, stehen Ihnen die administrativen Rechte zur Verfügung.
Bild 12: Fehlerhafter Anmeldeversuch mit der Fake-Anmeldung
Durch die Umbenennung erhöht sich der Aufwand für einen Angreifer. Er muss nun den herkömmlichen Weg gehen und zunächst den Anmeldenamen ermitteln. Dabei wird er sich auf die Anmeldungen per SQL Server-Authentifizierung konzentrieren, denn bei einer dieser Anmeldungen muss es sich um die eigentliche Anmeldung sa handeln.
Bei einem gezielten Angriff wird er früher oder später die umbenannte Anmeldung erkennen und sich an das zugehörige Kennwort geben. Warum also all der Aufwand Geben Sie dem Angreifer doch was er möchte! Legen Sie eine neue Anmeldung namens sa an.
Dazu öffnen Sie den Dialog Anmeldung – Neu über den Kontextmenüeintrag Neue Anmeldung des Ordners Anmeldungen. Im Eingabefeld Anmeldung tragen Sie den Namen sa ein und aktivieren anschließend die Option SQL Server-Authentifizierung. Jetzt vergeben Sie ein Kennwort, das den Kennwortrichtlinien entspricht und deaktivieren die Option Ablauf des Kennworts erzwingen. In diesem Fall ist die Neuvergabe des Kennworts nicht sinnvoll. Ist das Kennwort abgelaufen, darf der Anwender ein neues Kennwort vergeben. So einfach möchten Sie es dem Angreifer nun auch wieder nicht machen. Mehr gibt es für diese Anmeldung nicht zu konfigurieren. Mit einem Klick auf OK legen Sie die Fake-Anmeldung sa an.
Jetzt haben Sie einen zufriedenen Angreifer, denn für seinen unbefugten Zugriff steht ihm eine Anmeldung namens sa zur Verfügung. Er macht sich also direkt daran, das Kennwort für diese Anmeldung in Erfahrung zu bringen. Sollte er es tatsächlich schaffen, wird er enttäuscht feststellen, dass er mit dieser Anmeldung keine administrativen Rechte hat. Nicht nur das, denn er hat so gut wie keine Rechte im SQL Server.
Er darf sich lediglich zum SQL Server verbinden, Daten lesen oder gar ändern ist ihm nicht gestattet.
In der Zwischenzeit haben Sie bereits bemerkt, dass es mehrere fehlerhafte Verbindungsversuche mit der Anmeldung sa gab. Schließlich werden diese erfolglosen Versuche standardmäßig in den SQL Server-Protokollen eingetragen.
Die Konfiguration für diese Anmeldeüberwachung finden Sie in den Eigenschaften der SQL Server-Instanz. Klicken Sie mit der rechten Maustaste auf den ersten Eintrag im Objekt-Explorer und wählen Sie im Kontextmenü den Eintrag Eigenschaften (siehe Bild 13).
Bild 13: Der Weg zur Anmeldungsüberwachung im SQL Server
Im Dialog Servereigenschaften wechseln Sie zur Seite Sicherheit. Dort sehen Sie in der Gruppe Anmeldungsüberwachung die Option Nur fehlerhafte Anmeldungen (siehe Bild 14). Sollte die Option wider Erwarten nicht ausgewählt sein, aktivieren Sie diese und schließen Sie den Dialog mit einem Klick auf OK.
Bild 14: Die Anmeldungsüberwachung im SQL Server
Jetzt schlüpfen Sie in die Rolle des Angreifers und testen den Anmeldevorgang mit sa. Dazu klicken Sie im Objekt-Explorer auf Verbinden und wählen in der Auswahl den Eintrag Datenbank-Engine.
Im folgenden Anmeldedialog legen Sie die SQL Server-Authentifizierung fest, verwenden den Anmeldenamen sa und geben eine willkürliche Zeichenfolge als Kennwort ein. Nach einem Klick auf Verbinden erhalten Sie die bereits bekannte Meldung.
Dieser erfolglose Verbindungsversuch wurde in den SQL Server-Protokollen notiert. Um den entsprechenden Eintrag zu sehen, schließen Sie den Anmeldedialog mit einem Klick auf Abbrechen und navigieren im Objekt-Explorer über Verwaltung zum Eintrag SQL Server-Protokolle. Dort öffnen Sie das Protokoll mit der Bezeichnung Aktuell per Doppelklick. Der Protokolldatei-Viewer zeigt Ihnen unter anderem den Eintrag zum fehlerhaften Verbindungsversuch (siehe Bild 15).
Bild 15: Der Protokolldatei-Viewer
Die Einträge zu allen fehlgeschlagenen Verbindungsversuchen finden Sie am schnellsten über die Suche. Dazu aktivieren Sie die Suche über die gleichnamige Schaltfläche und geben den Suchbegriff Login failed ein. Über die Schaltfläche Suche springen Sie dann zu den einzelnen Einträgen.
Mit der Fake-Anmeldung sa sind Sie nicht nur in der Lage, einen Angriff zu erkennen. Sie können diesen auch beobachten. Erlauben Sie der Fake-Anmeldung, sich mit den einzelnen Datenbanken zu verbinden, hat der Angreifer zwar Zugriff zu den Datenbanken, dort aber keine weiteren Rechte.
Sie jedoch sehen, ob er gezielt eine bestimmte Datenbank anvisiert oder ob er sich eher ziellos in allen Datenbanken umschaut.
Je nach der Vorgehensweise des Angreifers lassen sich eventuell Rückschlüsse auf sein Ziel und vielleicht sogar auf seinen Auftraggeber ziehen.
Zu guter Letzt runden Sie die Sache noch ab und verabschieden sich vom Ersatzschlüssel. Öffnen Sie über die Schaltfläche Neue Abfrage eine Registerkarte und geben Sie dort den folgenden Befehl ein:
EXEC sp_SetAutoSAPasswordAndDisable;
Mit einem Klick auf Ausführen erhält die Anmeldung LogReader ein neues Kennwort und wird deaktiviert. Ihre Fake-Anmeldung sa bleibt von der Systemprozedur unberührt.
Eine eigene Anmeldung
Mit den beschriebenen Maßnahmen haben Sie die sa-Anmeldung unter Kontrolle. Ein Missbrauch ist so gut wie ausgeschlossen. Ausgeschlossen ist dadurch leider auch die Beispielapplikation WaWi. Diese Access-Applikation stellt die Verbindung zum SQL Server über die ODBC-Verbindung WaWi_SQL her. Aktuell wird hierbei noch die Anmeldung sa verwendet.
Das Anlegen der SQL Server-Datenbank, der Zugriff von der Beispielapplikation zum SQL Server und das Erstellen der ODBC-Verbindung wurde in Teil 2 der Beitragsreihe ausführlich beschrieben. Sollte die Umgebung auf Ihrem Testsystem nicht (mehr) existieren, können Sie diese anhand der Installationsanleitung zu den Beispieldateien erstellen.
Hinweis 2: Access, SQL Server und die ODBC-Verbindung
Die Beispielapplikation WaWi lässt sich zwar ohne weiteres starten, jedoch wird jeder Datenzugriff mit einem Fehler quittiert (siehe Bild 16). Das war zu erwarten, schließlich sind die Tabellen noch mit dem alten Kennwort der sa-Anmeldung eingebunden. Zudem handelt es sich inzwischen bei der Anmeldung sa um eine Fake-Anmeldung. Selbst wenn das Kennwort stimmen würde, die Anmeldung hätte keine Rechte für den Zugriff zur Datenbank WaWi_SQL.
Bild 16: Fehlerhafter Datenzugriff in Access
Der Zugriff auf die Daten der SQL Server-Datenbank muss jetzt also über eine andere Anmeldung erfolgen. Eine Anmeldung, mit der die Access-Beispielapplikation WaWi über die ODBC-Datenquelle eine Verbindung zum SQL Server und dort zur Datenbank WaWi_SQL herstellt. Somit wird sie indirekt von allen Mitarbeitern verwendet, die mit der Applikation WaWi arbeiten. Aus diesem Grund soll die neue Anmeldung WaWiMa heißen, wobei Ma für Mitarbeiter steht.
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