<\/p>\n
Bernd Jungbluth, Horn<\/b><\/p>\n
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. <\/b><\/p>\n
Die Alternative ist recht einfach: Sie verwenden anstelle der Anmeldung sa <\/b>eine eigene Anmeldung. Doch bevor Sie eine neue Anmeldung im SQL Server anlegen, sollten Sie sich zuerst um die Anmeldung sa <\/b>kümmern.<\/p>\n
Die Anmeldung sa<\/b><\/p>\n
sa <\/b>steht für System Administration<\/b>. Mit der Anmeldung sa <\/b>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 <\/b>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.<\/p>\n
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. <\/p>\n
Im SQL Server ist das erste Ziel solcher Maßnahmen die Anmeldung sa<\/b>. 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.<\/p>\n
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 <\/b>mitsamt dem zugehörigen Kennwort ein (siehe Bild 1). Nach einem Klick auf Verbinden <\/b>haben Sie Zugriff auf den Objekt-Explorer.<\/p>\n
<\/p>\n
Bild 1: Authentifizierung am SQL Server mit sa<\/span><\/b><\/p>\n 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. <\/p>\n Hinweis 1: Gemischter Modus – Windows- und SQL Server-Authentifizierung<\/b><\/p>\n Im Objekt-Explorer navigieren Sie zum Ordner Sicherheit <\/b>und erweitern den Unterordner Anmeldungen. Per Doppelklick auf den Eintrag sa<\/b> öffnen Sie den Dialog Anmeldungseigenschaften<\/b> (siehe Bild 2). Hier geben Sie das neue Kennwort in den Eingabefeldern Kennwort <\/b>und Kennwort bestätigen <\/b>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.<\/p>\n Bild 2: Eigenschaften der Anmeldung sa<\/span><\/b><\/p>\n Aktivieren Sie unbedingt die Option Kennwortrichtlinie erzwingen<\/b>. 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 <\/b>ein komplexes Kennwort zu vergeben.<\/p>\n Bild 3: Kennwortvorgaben per Gruppenrichtlinien<\/span><\/b><\/p>\n Die Option Ablauf des Kennworts erzwingen <\/b>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. <\/p>\n 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.<\/p>\n Durch die Aktivierung der Option Ablauf des Kennworts erzwingen <\/b>wird die Option Benutzer muss das Kennwort bei der nächsten Anmeldung ändern <\/b>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.<\/p>\n Die restlichen Optionen sind für die Neuvergabe des Kennworts nicht relevant. Speichern Sie die Änderung mit einem Klick auf OK<\/b>. 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.<\/p>\n Bild 4: Trennen der Verbindung<\/span><\/b><\/p>\n 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 <\/b>als Anmeldenamen ein. In Ihrem Password-Safe kopieren Sie das Kennwort und fügen es in das Feld Kennwort <\/b>ein. Mit einem Klick auf Verbinden <\/b>melden Sie sich erneut am SQL Server an.<\/p>\n Bild 5: Herstellen der Verbindung<\/span><\/b><\/p>\n Das war doch einfach. Anmeldedialog starten, sa <\/b>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 <\/b>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 <\/b>ist ab jetzt für Sie und alle anderen Datenbank-Administratoren tabu. Nur in absoluten Ausnahme- und Notfällen dürfen Sie es verwenden.<\/p>\n Anmeldung für Datenbank-Administratoren<\/b><\/p>\n 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 <\/b>wurden Sie zum Datenbank-Administrator des SQL Servers und über die Schaltfläche Hinzufügen <\/b>waren Sie in der Lage, weitere Kollegen als Datenbank-Administratoren aufzunehmen (siehe Bild 6).<\/p>\n Bild 6: Definition eines Datenbank-Administrators bei der Installation<\/span><\/b><\/p>\n Wenn dem so ist, sehen Sie im Ordner Anmeldungen <\/b>unter Sicherheit <\/b>einen Eintrag mit Ihrem Windows-Benutzerkonto. Diese Anmeldung besitzt die gleichen Rechte wie die Anmeldung sa<\/b>. Sie haben also keinerlei Nachteile, wenn Sie in Zukunft die Anmeldung zu Ihrem Windows-Benutzerkonto verwenden.<\/p>\n Um wie beim letzten Teil dieser Reihe eine Verwirrung bezüglich der Begriffe Anwender<\/b>, Benutzer <\/b>und Anmeldung <\/b>zu vermeiden, gelten ab hier die wie folgt definierten Begriffe:<\/p>\n Sollten Sie wider Erwarten keine Anmeldung mit Ihrem Benutzerkonto sehen, können Sie dieses jetzt anlegen.<\/p>\n Wählen Sie hierzu im Kontextmenü des Eintrags Anmeldungen <\/b>den Eintrag Neue Anmeldung<\/b>.<\/p>\n Im Dialog Anmeldung – Neu <\/b>klicken Sie auf Suchen<\/b>. Die Suche ist abhängig vom Suchpfad, den Sie über die Schaltfläche Pfade <\/b>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. <\/p>\n Bild 7: Suche eines Windows-Benutzerkontos<\/span><\/b><\/p>\n Anschließend tragen Sie Ihren Benutzernamen ein und klicken auf Namen überprüfen<\/b>. Bei einer korrekten Eingabe wird der Benutzername mit dem Namen des Computers oder der Domäne ergänzt. Klicken Sie auf OK <\/b>und wechseln Sie zur Seite Serverrollen<\/b>. Hier markieren Sie den Eintrag sysadmin <\/b>und bestätigen die Auswahl mit OK<\/b>.<\/p>\n Nun existiert eine SQL Server-Anmeldung mit einem Verweis auf Ihr Benutzerkonto. Durch die Zuordnung zur Serverrolle sysadmin <\/b>haben Sie mit dieser Anmeldung die gleichen Rechte wie die Anmeldung sa<\/b>. Es spricht also nichts dagegen, ab jetzt diese Anmeldung zu verwenden. <\/p>\n 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 <\/b>die Windows-Authentifizierung und klicken auf Verbinden<\/b>. 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<\/b>. 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.<\/p>\n 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<\/b>. 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<\/b>. In dem folgenden Dialog geben Sie den Benutzernamen und das zugehörige Kennwort ein. <\/p>\n 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<\/b>.<\/p>\n Grundsätzlich sollten Sie auf Sammelkonten wie SqlAdministrator <\/b>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.<\/p>\n Waren Sie es oder einer Ihrer Kollegen oder gar ein Unbekannter, der sich das Kennwort des Sammelkontos erschlichen hat<\/p>\n 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 <\/b>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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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 <\/b>und Hoppenstett<\/b>, gibt es im SQL Server eine Anmeldung mit dem Verweis zum Benutzerkonto Hesselbach <\/b>und eine weitere mit dem Verweis zum Benutzerkonto Hoppenstett<\/b>.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/b>, erstellt wird – und eine SQL Server-Anmeldung über die Windows-Authentifizierung basiert genau auf dieser SID<\/b>. <\/p>\n 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<\/b>. <\/p>\n 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 <\/b>zum SQL Server verbinden und den Fehler beheben. Sobald die Datenbank-Administratoren wieder ihre eigenen Anmeldungen besitzen, erhält die Anmeldung sa <\/b>ein neues per Password-Safe generiertes Kennwort. Ab dann arbeiten alle Datenbank-Administratoren wieder mit ihren eigenen Anmeldungen.<\/p>\n Eigentlich ist die Anmeldung sa <\/b>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 <\/b>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.<\/p>\n Bild 8: Der SQL Server-Dienst im SQL Server Konfigurations-Manager<\/span><\/b><\/p>\n Nun öffnen Sie per Doppelklick auf den SQL Server-Dienst dessen Eigenschaften<\/b>-Dialog und wechseln zur Registerkarte Startparameter<\/b>. Unter Startparameter angeben <\/b>tragen Sie -m <\/b>ein und klicken auf Hinzufügen <\/b>(siehe Bild 9). Durch diesen Parameter startet der SQL Server-Dienst im Einzelbenutzermodus. Nach einem Klick auf Übernehmen <\/b>werden Sie darauf hingewiesen, dass die Änderung erst nach einem Neustart des Diensts wirksam wird.<\/p>\n Bild 9: Die Startparameter des SQL Server-Diensts<\/span><\/b><\/p>\n Bestätigen Sie die Meldung und schließen Sie den Dialog mit OK<\/b>. Anschließend wählen Sie im Kontextmenü des SQL Server-Diensts den Eintrag Starten<\/b>. <\/p>\n 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<\/b>. 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.<\/p>\n 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<\/b> und starten den Dienst erneut. Denken Sie dabei auch an den Neustart des Diensts vom SQL Server-Agent.<\/p>\n Der Ersatzschlüssel<\/b><\/p>\n Wenn selbst ein solch außergewöhnlicher Fall ohne die Anmeldung sa <\/b>gelöst werden kann, stellt sich die Frage, wofür sie denn überhaupt benötigt wird. Welchen Vorteil oder Nutzen bietet die Anmeldung sa <\/b>einem Datenbank-Administrator<\/p>\n Nicht wenige Datenbank-Administratoren fühlen sich schlicht und ergreifend wohler, wenn ein Ersatzschlüssel in Form der Anmeldung sa <\/b>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 <\/b>an und stellen die gelöschten Anmeldungen wieder her. <\/p>\n Auf der anderen Seite ist die Anmeldung sa <\/b>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 <\/b>gibt. Das reduziert seinen Aufwand um die Hälfte, weshalb er sich mit aller Energie direkt auf den zweiten Teil konzentrieren wird – das Kennwort.<\/p>\n Zugunsten der Sicherheit sollten Sie auf den Ersatzschlüssel verzichten und die Anmeldung sa <\/b>deaktivieren. Dies ist übrigens die offizielle Empfehlung von Microsoft. Das Deaktivieren findet im Eigenschaften<\/b>-Dialog der Anmeldung sa <\/b>statt. Dort finden Sie in der Seite Status <\/b>die Option Deaktiviert <\/b>(siehe Bild 10). Eine bessere Alternative ist die Deaktivierung mittels der Systemprozedur sp_SetAutoSAPasswordAndDisable<\/b>. Hierüber erhält die Anmeldung sa <\/b>ein zufällig generiertes Kennwort, bevor sie dann letztendlich deaktiviert wird. <\/p>\n Bild 10: Deaktivieren der Anmeldung sa<\/span><\/b><\/p>\n 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 <\/b>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 <\/b>müssen Sie dieser zuerst ein neues Kennwort vergeben. <\/p>\n <\/p>\n Weitere Möglichkeiten zum Verhindern des Zugriffs mit der Anmeldung sa <\/b>gibt es nicht. Die Anmeldung lässt sich ebenso wenig löschen, wie Sie ihr die administrativen Rechte entziehen können. <\/p>\n Vielleicht haben Sie ein ungutes Gefühl beim Deaktivieren der sa<\/b>-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 <\/b>doch einfach einen anderen Namen. Dazu markieren Sie die Anmeldung im Objekt-Explorer, wählen im Kontextmenü Umbenennen <\/b>(siehe Bild 11) und vergeben einen unscheinbaren Anmeldenamen. Wie wäre es mit LogReader<\/b><\/p>\n Bild 11: Umbenennen der Anmeldung sa<\/span><\/b><\/p>\n Die Anmeldung sa <\/b>existiert zwar weiterhin mit den administrativen Rechten, jedoch nicht mehr unter dem bekannten Namen. Ein Verbindungsversuch mit sa <\/b>liefert die Fehlermeldung aus Bild 12. Melden Sie sich hingegen mit der Anmeldung LogReader <\/b>an, stehen Ihnen die administrativen Rechte zur Verfügung.<\/p>\n Bild 12: Fehlerhafter Anmeldeversuch mit der Fake-Anmeldung<\/span><\/b><\/p>\n 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.<\/p>\n 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 <\/b>an.<\/p>\n Dazu öffnen Sie den Dialog Anmeldung – Neu <\/b>über den Kontextmenüeintrag Neue Anmeldung <\/b>des Ordners Anmeldungen<\/b>. Im Eingabefeld Anmeldung <\/b>tragen Sie den Namen sa <\/b>ein und aktivieren anschließend die Option SQL Server-Authentifizierung<\/b>. Jetzt vergeben Sie ein Kennwort, das den Kennwortrichtlinien entspricht und deaktivieren die Option Ablauf des Kennworts erzwingen<\/b>. 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 <\/b>legen Sie die Fake-Anmeldung sa <\/b>an.<\/p>\n Jetzt haben Sie einen zufriedenen Angreifer, denn für seinen unbefugten Zugriff steht ihm eine Anmeldung namens sa <\/b>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.<\/p>\n Er darf sich lediglich zum SQL Server verbinden, Daten lesen oder gar ändern ist ihm nicht gestattet.<\/p>\n In der Zwischenzeit haben Sie bereits bemerkt, dass es mehrere fehlerhafte Verbindungsversuche mit der Anmeldung sa <\/b>gab. Schließlich werden diese erfolglosen Versuche standardmäßig in den SQL Server-Protokollen eingetragen. <\/p>\n 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 <\/b>(siehe Bild 13). <\/p>\n Bild 13: Der Weg zur Anmeldungsüberwachung im SQL Server<\/span><\/b><\/p>\n Im Dialog Servereigenschaften <\/b>wechseln Sie zur Seite Sicherheit<\/b>. Dort sehen Sie in der Gruppe Anmeldungsüberwachung <\/b>die Option Nur fehlerhafte Anmeldungen <\/b>(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<\/b>.<\/p>\n Bild 14: Die Anmeldungsüberwachung im SQL Server<\/span><\/b><\/p>\n Jetzt schlüpfen Sie in die Rolle des Angreifers und testen den Anmeldevorgang mit sa<\/b>. Dazu klicken Sie im Objekt-Explorer auf Verbinden <\/b>und wählen in der Auswahl den Eintrag Datenbank-Engine<\/b>.<\/p>\n Im folgenden Anmeldedialog legen Sie die SQL Server-Authentifizierung fest, verwenden den Anmeldenamen sa <\/b>und geben eine willkürliche Zeichenfolge als Kennwort ein. Nach einem Klick auf Verbinden <\/b>erhalten Sie die bereits bekannte Meldung.<\/p>\n 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 <\/b>und navigieren im Objekt-Explorer über Verwaltung <\/b>zum Eintrag SQL Server-Protokolle<\/b>. Dort öffnen Sie das Protokoll mit der Bezeichnung Aktuell <\/b>per Doppelklick. Der Protokolldatei-Viewer zeigt Ihnen unter anderem den Eintrag zum fehlerhaften Verbindungsversuch (siehe Bild 15). <\/p>\n Bild 15: Der Protokolldatei-Viewer<\/span><\/b><\/p>\n 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 <\/b>ein. Über die Schaltfläche Suche <\/b>springen Sie dann zu den einzelnen Einträgen.<\/p>\n Mit der Fake-Anmeldung sa <\/b>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.<\/p>\n Sie jedoch sehen, ob er gezielt eine bestimmte Datenbank anvisiert oder ob er sich eher ziellos in allen Datenbanken umschaut.<\/p>\n Je nach der Vorgehensweise des Angreifers lassen sich eventuell Rückschlüsse auf sein Ziel und vielleicht sogar auf seinen Auftraggeber ziehen.<\/p>\n Zu guter Letzt runden Sie die Sache noch ab und verabschieden sich vom Ersatzschlüssel. Öffnen Sie über die Schaltfläche Neue Abfrage <\/b>eine Registerkarte und geben Sie dort den folgenden Befehl ein:<\/p>\n Mit einem Klick auf Ausführen <\/b>erhält die Anmeldung LogReader <\/b>ein neues Kennwort und wird deaktiviert. Ihre Fake-Anmeldung sa <\/b>bleibt von der Systemprozedur unberührt.<\/p>\n Eine eigene Anmeldung <\/b><\/p>\n Mit den beschriebenen Maßnahmen haben Sie die sa<\/b>-Anmeldung unter Kontrolle. Ein Missbrauch ist so gut wie ausgeschlossen. Ausgeschlossen ist dadurch leider auch die Beispielapplikation WaWi<\/b>. Diese Access-Applikation stellt die Verbindung zum SQL Server über die ODBC-Verbindung WaWi_SQL <\/b>her. Aktuell wird hierbei noch die Anmeldung sa <\/b>verwendet. <\/p>\n 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.<\/p>\n Hinweis 2: Access, SQL Server und die ODBC-Verbindung<\/b><\/p>\n Die Beispielapplikation WaWi <\/b>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<\/b>-Anmeldung eingebunden. Zudem handelt es sich inzwischen bei der Anmeldung sa <\/b>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<\/b>.<\/p>\n Bild 16: Fehlerhafter Datenzugriff in Access<\/span><\/b><\/p>\n 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<\/b> über die ODBC-Datenquelle eine Verbindung zum SQL Server und dort zur Datenbank WaWi_SQL <\/b>herstellt. Somit wird sie indirekt von allen Mitarbeitern verwendet, die mit der Applikation WaWi <\/b>arbeiten. Aus diesem Grund soll die neue Anmeldung WaWiMa <\/b>heißen, wobei Ma <\/b>für Mitarbeiter steht.<\/p>\n Die neue Anmeldung legen Sie im SQL Server Management Studio an. Dort navigieren Sie zum Ordner Sicherheit <\/b>und wählen im Kontextmenü des Ordners Anmeldungen <\/b>den Eintrag Neue Anmeldung<\/b> aus. Geben Sie der Anmeldung den Namen WaWiMa <\/b>und aktivieren Sie die Option SQL Server-Authentifizierung<\/b>.<\/p>\n Natürlich könnte die neue Anmeldung auch eine Windows-Authentifizierung sein. Doch diese Möglichkeit ist Thema in einem späteren Beitrag dieser Artikelreihe.<\/p>\n Es folgt die Kennworteingabe. Diese sollte sich an den Kennwortrichtlinien orientieren, weshalb Sie die aktivierte Option Kennwortrichtlinie erzwingen <\/b>beibehalten. Grundsätzlich können Sie an dieser Stelle wieder mit einem generierten Kennwort arbeiten. Sie verwenden das Kennwort später lediglich in der ODBC-Verbindung und beim Einbinden der Tabellen. Weitere Eingaben im täglichen Betrieb sind nicht absehbar.<\/p>\n Bei der Kennwortvergabe sollten Sie jedoch beachten, dass Sie das Kennwort während der Entwicklung der Access\/SQL Server-Applikation öfter benötigen. Da kann ein generiertes Kennwort schnell lästig werden. Das gilt auch für mögliche Supportfälle im späteren Betrieb. Handelt es sich um ein generiertes Kennwort in einem Password-Safe, müssen die Supportmitarbeiter auch Zugriff zu diesem Safe haben. Je nach Password-Safe sehen die Mitarbeiter dann vielleicht auch Kennwörter, die sie besser nicht sehen sollten. Nun können Sie von den Supportmitarbeitern durchaus erwarten, dass sie sich das Kennwort selbst notieren. Verwenden diese jedoch keinen eigenen Password-Safe, landet das generierte Kennwort früher oder später in einer ungeschützten Datei oder auf einem Zettel. Generierte Kennwörter kann sich halt niemand merken.<\/p>\n Alternativ können Sie ein weniger sicheres, dafür aber einfacheres Kennwort vergeben. Eine gute Variante sind die Anfangsbuchstaben und Satzzeichen eines Satzes. So erhalten Sie aus dem Satz „Der Support und die Entwicklung verwenden seit 2020 eine neue Anmeldung!“ das Kennwort „DSudEvs2020enA!“. Die Mitarbeiter merken sich den Satz und leiten daraus das Kennwort ab. Für einen Fremden jedoch ist der Satz und somit das Kennwort nur schwer zu erraten. Um die folgenden Schritte in diesem Beispiel nicht unnötig zu komplizieren, geben Sie als Kennwort SicherIn2020! <\/b>ein.<\/p>\n Die Option Ablauf des Kennworts erzwingen <\/b>ist für den geplanten Anwendungsfall strittig. Es ist grundsätzlich sinnvoll, Kennwörter regelmäßig zu ändern. Kennt jemand Unbefugtes das Kennwort, so darf er sich nach einer Neuvergabe nochmal die Mühe machen, dass Kennwort zu erraten. <\/p>\n Diese Anmeldung jedoch soll in erster Linie in einem Access-Frontend und der zugehörigen ODBC-Verbindung verwendet werden. Eine Neuvergabe des Kennworts wird da recht schnell aufwendig. Immerhin müssen Sie dann zum einen im Access-Frontend die Tabellen neu einbinden und zum anderen das neue Kennwort in jeder bestehenden ODBC-Verbindung ändern. Je nach Anzahl der Clients ist das eine mühselige Aufgabe. Zudem wissen Sie nicht, wann ein neues Kennwort erwartet wird. Ist das Kennwort abgelaufen, erhält der Anwender eine Fehlermeldung oder die Aufforderung, dass Kennwort zu ändern.<\/p>\n Selbst wenn er ein neues Kennwort eingeben kann, so dürfte die Änderung mangels Rechte abgelehnt werden. Wie auch immer, bei einem abgelaufenen Kennwort kann sich mit der zugehörigen Anmeldung kein Anwender mehr am SQL Server anmelden.<\/p>\n Auf der anderen Seite erhöhen Sie die Sicherheit, wenn Sie das Kennwort in regelmäßigen Abständen ändern. Wie wäre es mit einem Kompromiss Bei jeder neuen Version des Access-Frontends ändern Sie das Kennwort der Anmeldung. Wenn Sie ohnehin ein neues Access-Frontend auf den Clients verteilen müssen, können Sie dabei auch die Tabellen neu einbinden und die zugehörige ODBC-Verbindung anpassen.<\/p>\n Zum Schluss deaktivieren Sie noch die Option Benutzer muss das Kennwort bei der nächsten Anmeldung ändern<\/b>. Sie sind die einzige Person, die das Kennwort vergibt und in Zukunft ändert. Soweit so gut. Fürs Erste ist die Definition der Anmeldung abgeschlossen. Speichern Sie die Anmeldung mit einem Klick auf OK<\/b>.<\/p>\n Nun müssen Sie noch die ODBC-Verbindung WaWi_SQL <\/b>an die neue Anmeldung anpassen. Dazu drücken Sie die Windows-Taste und geben den Suchbegriff ODBC <\/b>ein. In dem Suchergebnis wählen Sie den Eintrag ODBC-Datenquellen (32-bit)<\/b>, sofern Sie mit der 32-Bit-Version von Access arbeiten. Verwenden Sie die 64-Bit-Version von Access, klicken Sie auf den Eintrag ODBC-Datenquellen (64-bit)<\/b>.<\/p>\n Die ODBC-Verbindung WaWi_SQL <\/b>finden Sie in der Registerkarte System-DSN<\/b>. Markieren Sie die ODBC-Verbindung und klicken Sie auf Konfigurieren<\/b>. Im Assistenten wechseln Sie über die Schaltfläche Weiter <\/b>zum zweiten Schritt. Hier tragen Sie den Namen der neuen Anmeldung und das Kennwort in den Eingabefeldern Anmelde-ID <\/b>und Kennwort <\/b>ein (siehe Bild 17).<\/p>\n Bild 17: Neukonfiguration der ODBC-Datenquelle<\/span><\/b><\/p>\n Danach klicken Sie so oft auf Weiter <\/b>bis Sie die Schaltfläche Fertig stellen <\/b>sehen. Ein Klick auf diese Schaltfläche liefert Ihnen einen Dialog, über den Sie die Verbindung testen können. Das sollten Sie auch tun. Klicken Sie auf die Schaltfläche Datenquelle testen<\/b>. Liefert der Test eine allgemeingültige Meldung wie Fehler bei der Anmeldung, haben Sie sich vielleicht beim Anmeldenamen oder beim Kennwort vertippt. <\/p>\n Bevor Sie nun mühsam mit der Schaltfläche Zurück <\/b>zu den Eingabefeldern Anmelde-ID <\/b>und Kennwort <\/b>navigieren, sollten Sie sich die Fehlermeldung genau anschauen. Entspricht die Meldung der aus Bild 18, haben Sie alles richtig gemacht. Diese Fehlermeldung war zu erwarten.<\/p>\n Bild 18: Fehlerhafter Verbindungstest<\/span><\/b><\/p>\n Die Anmeldung WaWiMa <\/b>ist im SQL Server zwar vorhanden, sie besitzt dort jedoch nur wenig Rechte. Genau genommen hat sie für die Datenbank WaWi_SQL <\/b>gar keine Rechte. <\/p>\n Für die Rechtevergabe wechseln Sie erneut zum SQL Server Management Studio und öffnen dort den Eigenschaften<\/b>-Dialog der Anmeldung WaWiMa<\/b>. Hier gehen Sie zur Seite Serverrollen <\/b>und aktivieren die Serverrolle sysadmin<\/b>.<\/p>\n Sie zögern Sehr gut! Durch diese Auswahl erhält die Anmeldung administrative Rechte im SQL Server. Sie ist dann der ursprünglichen sa<\/b>-Anmeldung sowie Ihrer Anmeldung als Datenbank-Administrator gleichgestellt. <\/p>\n Obwohl die Auswirkungen der Serverrolle sysadmin <\/b>recht bekannt sind, ist diese Art der Rechtevergabe nicht selten. Verbindungsprobleme werden in der Praxis oft mit der Zuordnung der Anmeldung zur Serverrolle sysadmin behoben. Es ist ja auch zu einfach. Ein Häkchen und es gibt keinerlei Probleme mehr. Dabei wird jedoch übersehen, welche Möglichkeiten den Anwendern mit dieser Rechtevergabe an die Hand gegeben wird.<\/p>\n Sie dürfen diese irrsinnige Rechtevergabe gerne testen. Speichern Sie die Anmeldung und wechseln Sie zurück zur ODBC-Datenquelle. Dort klicken Sie nochmal auf die Schaltfläche Datenquelle testen<\/b>. Sollten Sie nun eine Meldung mit dem Hinweis Kommunikationsverbindungsfehler <\/b>erhalten, müssen Sie den Dialog zunächst schließen. Danach öffnen Sie die OBDC-Datenquelle wieder, wechseln mit Weiter <\/b>zum zweiten Schritt des Assistenten und geben erneut das Kennwort ein. Anschließend gehen Sie über die Schaltfläche Weiter <\/b>zum Ende des Assistenten und klicken dort auf Fertig stellen<\/b>. Nun können Sie den Verbindungstest wiederholen.<\/p>\n Der Test ist erfolgreich. Das war auch zu erwarten. Wen soll diese Anmeldung denn aufhalten Sie hat im SQL Server alle Rechte. Die Zuordnung der Anmeldung WaWiMa <\/b>zur Serverrolle sysadmin <\/b>ist keine Lösung! Es gibt auch keinerlei Rechtfertigung für diese Freigabe. Neben der Serverrolle sysadmin <\/b>bietet SQL Server noch weitere Serverrollen. Eine kurze Übersicht sehen Sie hier:<\/p>\n Die Rechte dieser Serverrollen sind alle administrativer Art. Der Datenzugriff in einer Datenbank lässt sich mit keiner davon regulieren. Somit sind die Serverrollen für die Anmeldung WaWiMa <\/b>nicht zu gebrauchen. Mit dieser Anmeldung soll lediglich ein Zugriff auf die Datenbank WaWi_SQL <\/b>möglich sein. Natürlich muss sie sich dazu mit dem SQL Server verbinden dürfen. Alle weiteren Rechte sind jedoch auf die Datenbank WaWi_SQL <\/b>zu begrenzen. Dies erreichen Sie, indem Sie die Anmeldung der Datenbank zuordnen. Danach ist die Anmeldung in der Datenbank als Benutzer zu sehen. Das ist das Prinzip der mehrstufigen Sicherheitsarchitektur von SQL Server. Kurz gesagt besteht sie aus der Authentifizierung am SQL Server und der Autorisierung für die Datenbank.<\/p>\n Die Authentifizierung erfolgt mit der Anmeldung, die Autorisierung durch den zugehörigen Benutzer in der Datenbank. Auf diese Weise können Sie eine Anmeldung mehreren Datenbanken zuordnen und diese dort mit unterschiedlichen Rechten ausstatten. Die Sicherheitsarchitektur wurde im Beitrag SQL Server-Security – Teil 2: Zugriffsberechtigung <\/b>(www.access-im-unterenehmen.de\/1246<\/b>) behandelt.<\/p>\n Die Zuordnung der Anmeldung zur Datenbank lässt sich innerhalb der Datenbank oder bei der Anmeldung selbst vornehmen. Die einfachste und übersichtlichste Methode bietet der Eigenschaften<\/b>-Dialog der Anmeldung. Wechseln Sie also wieder zurück zum SQL Server Management Studio und öffnen Sie dort per Doppelklick auf die Anmeldung WaWiMa <\/b>den Eigenschaften<\/b>-Dialog.<\/p>\n Als erstes entfernen Sie die Zuordnung zur Serverrolle sysadmin <\/b>auf der Seite Serverrollen<\/b>. Danach gehen Sie zur Seite Benutzerzuordnung <\/b>und aktivieren im oberen Bereich die Datenbank WaWi_SQL<\/b>. Durch die Auswahl wird neben dem Datenbanknamen nun der Name des Benutzers angezeigt. Unter diesem Namen steht die Anmeldung in der Datenbank als Benutzer zur Verfügung. <\/p>\n Mit welchem Rechten der Benutzer innerhalb der Datenbank agieren darf, legen Sie im unteren Bereich fest. Auf dieser Ebene erfolgt die Rechtevergabe über Datenbankrollen. SQL Server bietet hierzu verschiedene Systemdatenbankrollen an. Für den Anfang wählen Sie die Systemdatenbankrolle db_owner <\/b>(siehe Bild 19).<\/p>\n Bild 19: Die Zuordnung der Anmeldung zur Datenbank<\/span><\/b><\/p>\n Ein Klick auf OK <\/b>legt in der Datenbank WaWi_SQL <\/b>den Benutzer WaWiMa <\/b>für die gleichnamige Anmeldung an. Mit dieser Zuordnung haben Sie die Anmeldung WaWiMa <\/b>für den Zugang zur Datenbank autorisiert.<\/p>\n Der Benutzer ist nun auch in der Datenbank zu sehen. Erweitern Sie den Ordner Datenbanken<\/b>, anschließend den Ordner der Datenbank WaWi_SQL <\/b>und dort den Ordner Sicherheit<\/b>. Im Ordner Benutzer <\/b>sehen Sie den Eintrag WaWiMa <\/b>(siehe Bild 20). <\/p>\n Bild 20: Benutzer in der Datenbank<\/span><\/b><\/p>\n Mit einem Doppelklick auf den Eintrag öffnen Sie den Eigenschaften<\/b>-Dialog des Benutzers. Die Seite Allgemein <\/b>zeigt Ihnen den Namen des Benutzers und den der zugehörigen Anmeldung (siehe Bild 21).<\/p>\n Bild 21: Eigenschaften des Benutzers<\/span><\/b><\/p>\n Auf der Seite Mitgliedschaft <\/b>sehen Sie die eben vergebene Zuordnung zur Systemdatenbankrolle db_owner <\/b>(siehe Bild 22).<\/p>\n Bild 22: Rechte des Benutzers<\/span><\/b><\/p>\n Durch diese Mitgliedschaft agiert der Benutzer in der Datenbank mit ähnlichen Rechten wie der Datenbankbesitzer. Der Besitzer einer Datenbank ist der Anwender, der die Datenbank angelegt hat. An dieser Stelle dürfen Sie Anwender <\/b>nicht mit Benutzer <\/b>und Besitzer <\/b>nicht mit Besitzer <\/b>verwechseln. <\/p>\n Ein Beispiel soll dies verdeutlichen. Der Anwender Meier <\/b>verbindet sich mit seinem SQL Server. Dabei verwendet er eine Anmeldung, die auf seinem Windows-Benutzerkonto DomäneMeier <\/b>basiert. Dann legt er eine neue Datenbank an. In dieser Datenbank wird er als Datenbankbesitzer eingetragen und er erhält dort auch einen Benutzer für seine Anmeldung. Der Benutzer heißt jetzt allerdings nicht DomäneMeier<\/b>, sondern schlicht dbo<\/b>.<\/p>\n dbo <\/b>steht für database owner<\/b>. Für den Besitzer einer Datenbank gibt es innerhalb der Datenbank keine Grenzen. Er kann unter anderem Objekte wie Tabellen und Sichten anlegen, ändern und löschen, Rechte vergeben und alle Daten lesen und ändern. Der Name der Systemdatenbankrolle db_owner <\/b>steht ebenfalls für Datenbankbesitzer.<\/p>\n Dennoch sind die Mitglieder dieser Rolle keine Besitzer der Datenbank. Sie haben nicht einmal die gleichen Rechte wie der Datenbankbesitzer. Zwar umfassen diese Rechte auch administrative Tätigkeiten, aber gerade bei den Lese- und Schreibzugriffen gibt es einen gravierenden Unterschied.<\/p>\n Der Datenbankbesitzer wie auch die Datenbank-Administratoren können den Mitgliedern der Systemdatenbankrolle db_owner <\/b>das Lese- und Schreibrecht in der Datenbank verweigern. Dies ist bei dem tatsächlichen Datenbankbesitzer nicht möglich. Sogar der Datenbank-Administrator kann ihm das Lesen und Ändern der Daten nicht verbieten.<\/p>\n Neben dem Benutzernamen dbo<\/b> als Bezeichnung für den Datenbankbesitzer und der Systemdatenbankrolle db_owner <\/b>gibt es in der Datenbank noch das Schema dbo<\/b>. Dieses Schema ist dem Benutzer WaWiMa <\/b>als Standardschema zugewiesen. Da die Objekte der Datenbank ebenfalls dem Schema dbo <\/b>zugeordnet sind, hat dies hier keine weitere Auswirkung. Was es mit den Schemata und insbesondere mit dem Schema dbo <\/b>auf sich hat, lesen Sie in einer der nächsten Ausgaben.<\/p>\n Jetzt aber beenden Sie den Eigenschaften-Dialog des Benutzers WaWiMa <\/b>und kehren zur ODBC-Datenquelle zurück. Dort wiederholen Sie den Verbindungstest. Sie erhalten die Erfolgsmeldung aus Bild 23. Die Änderung der Anmeldung in der ODBC-Datenquelle ist hiermit abgeschlossen. <\/p>\n Bild 23: Erfolgreicher Verbindungstest<\/span><\/b><\/p>\n Die neue Anmeldung in Access<\/b><\/p>\n In der Beispielapplikation sind die Tabellen der SQL Server-Datenbank bereits eingebunden. Um nicht bei jedem Start der Applikation das Kennwort der Anmeldung sa <\/b>eingeben zu müssen, wurde beim Einbinden der Tabellen das Kennwort in Access gespeichert. In der aktuellen Version des Access-Frontends ist also noch das Kennwort der Anmeldung sa <\/b>hinterlegt.<\/p>\n Folglich müssen Sie die Tabellen erneut einbinden. Öffnen Sie die Beispielapplikation WaWi <\/b>und entfernen Sie dort als erstes alle eingebundenen Tabellen.<\/p>\n Danach gehen Sie über Externe Daten|Neue Datenquelle|Aus Datenbank|Aus SQL Server <\/b>zum Dialog Externe Daten – ODBC-Datenbank<\/b>. Hier aktivieren Sie die zweite Option und klicken auf OK<\/b>. Im folgenden Dialog wählen Sie in der Registerkarte Computerdatenquelle <\/b>die ODBC-Datenquelle WaWi_SQL <\/b>per Doppelklick aus (siehe Bild 24). <\/p>\n Bild 24: Die Auswahl der ODBC-Datenquelle<\/span><\/b><\/p>\n Der nächste Dialog erwartet ein Kennwort von Ihnen. Geben Sie das Kennwort zur Anmeldung WaWiMa <\/b>ein und bestätigen Sie es mit OK<\/b>. Jetzt endlich dürfen Sie die Tabellen der Datenbank WaWi_SQL <\/b>auswählen. Markieren Sie alle Tabellen mit dem Schema dbo <\/b>und aktivieren Sie die Option Kennwort speichern<\/b>. Auf diese Weise wird das Kennwort der Anmeldung WaWiMa <\/b>in Access hinterlegt. Nach einem Klick auf OK <\/b>beginnt das Einbinden der Tabellen. Dabei ist das Speichern des Kennworts pro Tabelle mit der Schaltfläche Kennwort speichern <\/b>zu bestätigen.<\/p>\n Die vollständige Bezeichnung einer SQL Server-Tabelle besteht aus dem Namen des Schemas und dem der Tabelle. Die korrekte Bezeichnung der Tabelle Ansprechpartner <\/b>lautet somit dbo.Ansprechpartner<\/b>. Access unterstützt im Objektnamen jedoch keine Punkte, weshalb die SQL Server-Tabelle unter der Bezeichnung dbo_Ansprechpartner <\/b>eingebunden wurde. Die Formulare der Beispielapplikation verwenden als Datenherkunft jedoch die Tabellen ohne dieses Präfix. Es muss also entfernt werden. Dazu öffnen Sie mit der Tastenkombination Strg + G<\/b> das VBA-Direktfenster und führen dort die Funktion fTabellenUmbenennen <\/b>aus.<\/p>\n Starten Sie auch gleich noch die Funktion fPassThroughVerbindungen<\/b>. Diese Funktion speichert die neue Anmeldung in den Verbindungszeichenfolgen der Pass Through-Abfragen. Sie finden beide Funktionen im Modul Tabellen<\/b>. Jetzt müssen Sie noch den Datenzugriff per ADO anpassen. Dies erfolgt mit den Einträgen der lokalen Tabelle ADO<\/b>. Diese Tabelle ist als Systemtabelle definiert und somit schreibgeschützt. Mit der folgenden Funktion deaktivieren Sie den Schreibschutz:<\/p>\n Nachdem Sie die Funktion im VBA-Direktfenster ausgeführt haben, sehen Sie im Navigationsbereich die Tabelle ADO<\/b>. Öffnen Sie die Tabelle und passen Sie dort die Spalten Benutzer <\/b>und Kennwort <\/b>an die neue Anmeldung an (siehe Bild 25). Danach schließen Sie die Tabelle wieder und wechseln zurück zum VBA-Direktbereich. Mit der folgenden Anweisung definieren Sie die Tabelle ADO <\/b>wieder zur Systemtabelle.<\/p>\n Bild 25: Die Konfiguration für den Datenzugriff per ADO<\/span><\/b><\/p>\n Mehr Details zum Einbinden der Tabellen per ODBC, dem Anpassen der Pass Through-Abfragen, der Notwendigkeit der Tabelle ADO <\/b>und zu den hier verwendeten VBA-Funktionen lesen Sie in SQL Server-Security – Teil 2: Zugriffsberechtigung <\/b>(www.access-im-unterenehmen.de\/1246<\/b>).<\/p>\n Hinweis 3: Das Einbinden der Tabellen, ADO und die VBA-Funktionen<\/b><\/p>\n Es ist geschafft. Öffnen Sie das Start-Formular und klicken Sie auf die Schaltfläche Stellen<\/b>. Als Ergebnis sehen Sie die Daten der Tabelle Stellen<\/b> aus der Datenbank WaWi_SQL <\/b>Ihres SQL Servers (siehe Bild 26).<\/p>\n Bild 26: Erfolgreicher Datenzugriff in Access<\/span><\/b><\/p>\n Sie als Anwender der Applikation WaWi <\/b>arbeiten jetzt in der Datenbank WaWi_SQL <\/b>mit den Rechten der Anmeldung WaWiMa<\/b>. Diese hat durch die Zuordnung zum gleichnamigen Benutzer in der Datenbank und dessen Mitgliedschaft in der Systemdatenbankrolle db_owner<\/b> dort aktuell alle Rechte. <\/p>\n Trotz dieser hohen Rechte innerhalb der Datenbank haben Sie das Sicherheitsniveau des Datenzugriffs schon um einiges verbessert. Im Gegensatz zur bisher verwendeten Anmeldung sa <\/b>sind die Rechte nun auf die Datenbank WaWi_SQL <\/b>begrenzt. <\/p>\n Der Fall Bienlein<\/b><\/p>\n Frau Bienlein fühlt sich geschmeichelt. Ihre Änderungen in den Personaldaten kamen bei den Mitarbeitern der amerikanischen Geschäftsstelle gut an. Einige fanden es sogar sehr treffend, dass der Kollege Robert King auf einmal den Nachnamen Looser hatte. Motiviert möchte Sie heute noch weitere Personaldaten ändern. Auch wenn niemand weiß, dass sie dafür verantwortlich ist, so genießt sie doch den geheimen Ruhm. <\/p>\n Wohlgemut startet sie ihre eigene kleine Access-Datenbank und öffnet die eingebundene Tabelle Personal<\/b>. Doch anstelle der Daten sieht Sie nur eine Fehlermeldung (siehe Bild 27).<\/p>\n Bild 27: Frau Bienleins erfolgloser Datenzugriff<\/span><\/b><\/p>\n So etwas Banales wie eine Fehlermeldung hält Frau Bienlein noch lange nicht auf. Dann wird die Tabelle halt neu eingebunden. Sie löscht die Tabelle und navigiert sich durch den ihr inzwischen gut bekannten Weg Externe Daten|Neue Datenquelle|Aus Datenbank|Aus SQL Server <\/b>zum Dialog Externe Daten – ODBC-Datenbank<\/b>. Dort markiert sie die zweite Option, klickt auf OK <\/b>und wählt im nächsten Dialog die OBDC-Datenquelle WaWi_SQL<\/b>.<\/p>\n Im Dialog SQL Server-Anmeldung <\/b>tippt sie das Kennwort ein und klickt dann auf Optionen<\/b>, um die Datenbank der amerikanischen Kollegen auszuwählen. Der Klick auf die Auswahlliste Datenbank <\/b>wird jedoch mit einer Fehlermeldung quittiert. Zwar zeigt die Meldung nun etwas mehr Text, für Frau Bienlein ist der Inhalt jedoch unverständlich (siehe Bild 28). Es gibt anscheinend einen Fehler mit dem Benutzer WaWiMa<\/b>. WaWiMa<\/b> Diesen Benutzer kennt Frau Bienlein nicht. Wo ist denn der Benutzer sa <\/b>geblieben Damit hat es doch gut funktioniert.<\/p>\n Bild 28: Frau Bienleins zweiter erfolgloser Datenzugriff<\/span><\/b><\/p>\n Also ändert sie im Eingabefeld Anmelde-ID <\/b>den Eintrag von WaWiMa <\/b>in sa <\/b>und gibt erneut das Kennwort ein. Zuversichtlich klickt sie wieder auf die Auswahlliste Datenbank<\/b>. Das Ergebnis ist die gleiche Meldung, nur dass diese jetzt auf einen Fehler beim Benutzer sa <\/b>hinweist.<\/p>\n Frau Bienlein gibt enttäuscht auf. Schade, wie gerne hätte Sie ihrem amerikanischen Publikum noch etwas Unterhaltung gegönnt. Aber was solls. Es gibt Wichtigeres zu tun, denn heute möchte sie sich die nächste inoffizielle Gehaltserhöhung gönnen.<\/p>\n Sie schließt den Anmeldedialog und klickt auf die eingebundene Tabelle Mitarbeiter<\/b>. Wieder gibt es eine Fehlermeldung. Leicht genervt löscht Frau Bienlein nun auch die Tabelle Mitarbeiter <\/b>und bindet sie auf dem altbekannten Weg aufs Neue ein. Im Anmeldedialog fällt ihr der Eintrag WaWiMa <\/b>auf (siehe Bild 29). Etwas unsicher überschreibt sie diesen Eintrag mit sa <\/b>und tippt das Kennwort ein. Gespannt klickt Sie auf OK<\/b>. Wieder nichts, nur diese lästige Fehlermeldung. Mag es an diesem WaWiMa <\/b>liegen <\/p>\n Bild 29: Frau Bienlein auf dem Weg zum erfolgreichen Datenzugriff<\/span><\/b><\/p>\n Flexibel wie sie ist, geht sie zurück zum Eingabefeld Anmelde-ID <\/b>und ändert den Eintrag in WaWiMa<\/b>. Bei der Kennworteingabe zögert sie kurz und tippt dann frei nach ihrem Lebensmotto „Frechheit siegt“ das ihr bekannte Kennwort ein.<\/p>\n Beinahe hätte Frau Bienlein erfreut in die Hände geklatscht. Aber das wäre dann doch zu auffällig gewesen. Leicht geduckt wählt sie im Dialog Tabellen verknüpfen <\/b>die Tabelle dbo.Mitarbeiter <\/b>aus und aktiviert mit einem Schmunzeln die Option Kennwort speichern<\/b>. Nach einem Klick auf OK <\/b>bestätigt sie die folgende Meldung noch mit der Schaltfläche Kennwort speichern<\/b>. <\/p>\n Fertig. Frau Bienlein schaut zufrieden auf die eingebundene Tabelle dbo_Mitarbeiter<\/b>. Für was dieses dbo <\/b>wohl stehen mag Egal, denn noch ist nicht klar, ob sie die Tabelle öffnen kann. Nach einem Doppelklick sieht Frau Bienlein die Daten der Mitarbeiter. Amüsiert übersetzt sie sich das Kürzel dbo <\/b>als „die Bienlein Option“ und erhöht ihr Gehalt um fünf Euro.<\/p>\n An dieser Stelle sei wieder erwähnt, dass das Beispiel konstruiert ist und eine solche Art der Gehaltserhöhung schnell auffallen sollte. Nicht konstruiert ist jedoch die Wiederverwendung des Kennworts. Es kommt in der Praxis recht oft vor, dass für mehrere Anmeldungen ein und dasselbe Kennwort genutzt wird. <\/p>\n Was soll in diesem Fall schon passieren Ob nun die Anmeldung sa <\/b>oder WaWiMa<\/b>, die Anmeldungen waren beziehungsweise sind nur für den Zugriff zur Datenbank WaWi_SQL <\/b>vorgesehen. Zudem ist die eigentliche sa<\/b>-Anmeldung inzwischen deaktiviert. Dann kann man das Kennwort doch beibehalten. <\/p>\n Nein! Das Kennwort kann und sollte man nicht beibehalten. Ein Kennwort gehört zu einer Anmeldung und nicht zu einer Applikation. Dies gilt nicht nur für die Beispiel-applikation, sondern insbesondere für E-Mail-Konten, Online-Zugänge und ähnliches. Zu jeder Anmeldung gibt es ein eigenes Kennwort, sogar für die deaktivierte sa<\/b>-Anmeldung.<\/p>\n Frau Bienlein hat durch diese Bequemlichkeit nicht nur Zugang zur Tabelle Mitarbeiter<\/b>, sondern zu allen Daten und Objekten der Datenbank WaWi_SQL<\/b>. <\/p>\n Ein eigenes Kennwort für die Anmeldung WaWiMa <\/b>würde ihr diesen Zugang zumindest erschweren. Leider nur erschweren und nicht verhindern, denn das Kennwort lässt sich recht einfach ermitteln. Es ist im Klartext in der ACCDB gespeichert. Frau Bienlein muss das Access-Frontend nur mit einem einfachen Texteditor öffnen und dort nach der Bezeichnung der ODBC-Verbindung suchen. Eine Suche nach W a W i _ S Q L<\/b> liefert ihr das Kennwort. Ein unsicheres wie auch ein nicht ausreichend gesichertes Kennwort ist und bleibt eine Sicherheitslücke. <\/p>\n Diese Sicherheitslücke nutzt Frau Bienlein jetzt aus, denn so richtig hat sie den verwehrten Zugriff auf die Datenbank der amerikanischen Kollegen noch nicht verkraftet. Diese Niederlage muss mit einem Erfolgserlebnis ausgeglichen werden. War da nicht letztens die Rede von neuen Bewerbungsgesprächen Dem kann man entgegenwirken. Routiniert erstellt Frau Bienlein eine Pass Through-Abfrage, tippt den Befehl DROP TABLE Bewerber <\/b>ein und klickt auf Ausführen<\/b>.<\/p>\n Nach der Auswahl der ODBC-Datenquelle und der Eingabe des Kennworts erscheint der Hinweis, dass die Pass Through-Abfrage keine Datensätze zurückgegeben hat. Muss sie auch nicht, weshalb Frau Bienlein die Meldung mit OK <\/b>bestätigt. Zur Sicherheit klickt sie erneut auf Ausführen<\/b>. Nach Auswahl der ODBC-Datenquelle und der Kennworteingabe liest sie die erwartete Meldung Löschen des Tabellen-Objekts Bewerber nicht möglich, weil das Objekt nicht vorhanden ist oder Sie nicht die erforderliche Berechtigung haben<\/b>. Das reicht Frau Bienlein als Bestätigung, dass die Tabelle Bewerber <\/b>nicht mehr existiert. Zufrieden schließt sie ihre Datenbank und geht in den wohlverdienten Feierabend.<\/p>\n Für die Mitarbeiter der IT verschiebt sich der Feierabend heute etwas. Gerade eben gab es von der Personalabteilung einen ärgerlichen Anruf. Wieder einmal gibt es Fehlermeldungen in der Bewerberdatenbank. Die Mitarbeiter der IT vermuten die Ursache bereits – und tatsächlich, die Tabelle Bewerber <\/b>ist wie beim letzten Mal auf ominöse Art und Weise verschwunden. Es beginnt das mühsame Prozedere zur Wiederherstellung der Tabelle. Ein kleiner Trost bleibt den Mitarbeitern der IT. Inzwischen sind sie in der Vorgehensweise routiniert.<\/p>\n Fazit und Zusammenfassung<\/b><\/p>\n Mit der neuen SQL Server-Anmeldung wird die bisherige Schwachstelle beseitigt und das Sicherheitsniveau um einiges verbessert. Die Verbindung von Access zum SQL Server erfolgt nun mit der Anmeldung WaWiMa<\/b>. Die bisher verwendete Anmeldung sa<\/b> mitsamt ihren administrativen Rechten steht den Anwendern nicht mehr zur Verfügung.<\/p>\n Mehr noch – die Anmeldung sa <\/b>ist deaktiviert und die Datenbank-Administratoren verwenden ihre persönlichen Windows-Benutzerkonten. Auf diese Weise besitzt nur ein kleiner und überschaubarer Kreis von Anwendern administrative Rechte im SQL Server. Diese beinhalten nicht nur das Recht zum Anlegen, Ändern und Löschen von Objekten, sondern auch zum Lesen und Ändern aller Daten der im SQL Server verwalteten Datenbanken.<\/p>\n Das alles ist der Anmeldung WaWiMa <\/b>nicht erlaubt. Sie darf lediglich eine Verbindung zum SQL Server herstellen und eine Übersicht der Datenbanken sehen. Beides ist notwendig für den Zugriff auf eine Datenbank. Jedoch ist dieser erst nach der Zuordnung der Anmeldung zur Datenbank gestattet. Durch die Zuordnung wird für die Anmeldung ein Benutzer in der Datenbank angelegt. Im Beispiel ist dies in der Datenbank WaWi_SQL <\/b>der Benutzer WaWiMa <\/b>für die gleichnamige Anmeldung.<\/p>\n Die Rechte innerhalb der Datenbank erhält der Benutzer aktuell durch seine Mitgliedschaft in der Systemdatenbankrolle db_owner<\/b>. Eine viel zu hohe Rechtevergabe für die Anwender der Beispielapplikation WaWi<\/b>, beinhaltet diese doch administrative Rechte in der Datenbank. <\/p>\n Mit diesen Rechten ist Frau Bienlein in der Lage, alle Daten der Datenbank zu lesen und zu ändern. Sie kann unter anderem auch Tabellen löschen, was nun wirklich nicht zu ihrem Aufgabengebiet als Verkäuferin gehört. Um Frau Bienlein davon abzuhalten, müssen die Rechte innerhalb der Datenbank noch weiter eingrenzt werden. Wie Sie diese nächste Stufe der Zugriffsberechtigungen in SQL Server erreichen, lesen Sie in der nächsten Ausgabe. <\/p>\n Warnung<\/b><\/p>\n Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Aus diesem Grund führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!<\/p>\n Installation<\/b><\/p>\n SQL Server – Wechsel in den Gemischten Modus<\/p>\n Sollte diese Option bereits aktiviert sein, können Sie die Änderung hier abbrechen. Die folgenden Schritte müssen Sie dann nicht ausführen.<\/p>\n Installation der Beispieldatenbank WaWi_SQL<\/b><\/p>\n ODBC-Datenquelle WaWi_SQL<\/b><\/p>\n Wenn Sie den Treiber in der Auswahl nicht sehen, müssen Sie diesen zunächst installieren.<\/p>\n Sie finden den Treiber im Microsoft Downloadbereich <\/b>unter dem Suchbegriff ODBC Driver 17 for SQL Server<\/b>.<\/p>\n Beispielapplikation WaWi<\/b><\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
EXEC sp_SetAutoSAPasswordAndDisable;<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
fTabelleAlsSystemObjekt \"ADO\", False<\/span> <\/pre>\n<\/p>\n
fTabelleAlsSystemObjekt \"ADO\", True<\/span> <\/pre>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
\n
\n
\n
\n
\n