SQL Server: Sicherheit für Entwickler

Was ist Authentifizierung?

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Authentifizierung ist der Mechanismus, der dem SQL Server erlaubt, zu erkennen, wer hinter dem Verbindungsaufbau steht. Dabei kann es sich um SQL-Server-Authentifizierung oder Windows-Authentifizierung handeln. Beim Zugriff auf den SQL Server wird bei Erfolg ein Login zugeordnet.
11:32

Transkript

Für die Authentifizierung stehen im SQL Server prinzipiell 2 Möglichkeiten offen: Entweder die Windows-Authentifizierung oder die SQL-Server-Authentifizierung. Beides sind letztendlich Logins auf Server-Ebene. Während die Windows-Authentifizierung jedoch sich auf die Anmeldeprozesse verlässt, die der Benutzer hinter sich gebracht hat, als er sich an seinem Client eine Domäne angemeldet hat, ist bei der SQL-Server-Authentifizierung notwendig, dass der SQL Server sowohl den Benutzernamen, als auch ein Hash des Kennwortes speichert. Das bedeutet, ich kann, wenn ich mich mit unterschiedlichen Servern verbinde, entsprechend unterschiedliche Benutzernamen und Kennwort-Kombinationen haben, was vielleicht für ganz normale Benutzer nicht besonders optimal ist. Insofern Windows-Authentifizierung ist so ein bisschen der einfachere Ansatz für den Anwender. Die SQL-Server-Authentifizierung ist durchaus aber eine gute Lösung in Situationen, wo der SQL Server beispielsweise im DMZ steht oder in anderen Szenarien, wo nicht direkt ein Domain-Controller in der Nähe ist, vielleicht aus Sicherheitsgründen wiederholen. Und ich beispielsweise ein Service oder eine Webapplikation oder Ähnliches habe, die auf diesen SQL Server zugreift, dann macht es durchaus Sinn, vielleicht einen SQL-Login anzulegen und dieses Login entsprechend mit einem Kennwort zu versehen und beides dann in der Konfiguration des Webservices oder der Webanwendung zu vergraben an der Stelle. Beides, sowohl Windows als auch SQL-Server-Authentifizierung basiert darauf, dass es auf Server-Ebene einen entsprechenden Login gibt. Wobei interessant ist, wenn Sie Windows-Authentifizierung benutzen, kann dieses Login auch eine Windows-AD-Gruppe sein, sodass Sie nicht jeden einzelnen Windows-User entsprechend auffüllen müssen. Das wiederum ist sehr interessant in Szenarien, wo ich sehr viele User habe und nicht jeden einzelnen wirklich berichtigen möchte. War die Authentifizierung erfolgreich, sprich, war das Windows-Konto, mit dem der Benutzer zugegriffen hat, dem SQL Server bekannt, sei es direkt oder sei es indirekt als Mitglied einer AD-Gruppe oder konnte den Benutzer eine gültige Kombination aus Benutzername und Kennwort vorweisen, dann mündet das auf Server-Ebene in einen Prozess oder eine Session, je nachdem, welchen Begriff man da bevorzugt. Und dieser wiederum ist mit dem entsprechenden Login assoziiert. Und wenn dort weiter auf die Datenbank oder auf eine beliebige Datenbank zugegriffen werden soll, dann entsprechend wird aus dem Login später ein User. Und innerhalb der Datenbank hat der User Rechte, auf dem gesamten Server hat das Login Rechte. Aber erst einmal ist hier an der Authentifizierung für den SQL Server wichtig, dass er nur solche Benutzer zugreifen lässt, die er in irgendeiner Form kennt. Wie Sie das Ganze konfigurieren können, zeige ich Ihnen jetzt im SQL Server Management Studio, das ich nun öffne. So hier sind wir dann im SQL Server Management Studio. Die Einstellung der Authentifizierung kann ich hier als Eigenschaften auf dem Server festlegen. Ich gehe auf Properties, hier entsprechend auf Security und habe hier die Wahl entweder zwischen Windows Authentication mode oder SQL Server and Windows Authentication mode, sogenannter gemischter Modus. Also unterm Strich, die Windows-Authentifizierung ist immer aktiv. Die SQL-Server-Authentifizierung muss ich erst bei Bedarf zuschalten. Das heißt, ich muss es hier umschalten, einmal auf OK klicken, er sagt mir, dass ich den SQL Server neu starten muss, sprich, der Dienst muss neu gestartet werden. Das mache ich über das Configuration-Manager-Tool. So neu gestartet, damit ist diese Einstellung aktiv erstmal sichtbar. Passiert jetzt nichts an der Stelle. Ich habe nach wie vor die Einstellung hier auf SQL Server and Windows Authentication, also nichts Erkennbares, Dann brech ich einfach mal den Dialog noch mal ab. So ich kann mir dann mal anschauen, was für Logins denn auf diesem Server existieren und welche Möglichkeiten ich habe, um neue Logins anzulegen. Beides ist möglich hier im SQL Server Management Studio über den Security-Ordner. Achten Sie bitte darauf, es gibt auch ein Security-Ordner in jeder Datenbank. Schauen Sie, dass Sie auf dem richtigen Ordner klicken, bevor Sie sich wundern, dass es hier anders aussieht, zum Beispiel hier auf Server-Ebene finden Sie Logins, während in der Datenbank finden Sie Users. Das werden wir später sehen. Hier können Sie aber hingehen und erstmal ein Einblick auf alle bereits existierenden Logins werfen, die es schon gibt. Ist eine ganze Reihe. Sie können neue anlegen, indem Sie sagen rechte Maustaste New Login. Sie haben hier die Wahl zwischen Windows-Authentifizierung und SQL-Server-Authentifizierung. Nehmen wir zuerst einmal die Windows-Authentifizierung, da kann ich dann hingehen und sagen Search für Suchen, gucken, ob wir zufällig jemanden haben, der Bernd heißt, in der Tat haben wir, den kann ich angeben. Und das, was Ihr hier findet, ist genau das, was ich zum Beispiel auch in der Computer-Verwaltung in dem Fall finde oder in der Domain-Verwaltung. Das heißt, hier finde ich alle lokalen User und alle lokalen Gruppen kann ich hier finden. Das heißt, hier habe ich die Möglichkeit zu konfigurieren. Normalerweise geschieht das natürlich in der Domän. Insofern das ist jetzt die lokale Computer-Verwaltung beziehungsweise die lokalen Benutzer und Gruppen. Aber letztendlich ist es genau das Gleiche, was technisch stattfindet, wenn Sie in einer Domäne unterwegs sind. Ich kann ihn also entsprechend anlegen. Und was passiert? Hier sollte ganz am Ende der Bernd auftauchen. Dann kann ich ein SQL-Server-Login anlegen. Also ich kann hingehen, sagen New Login, hier die Auswahl machen SQL-Server-Authentifizierung. Und zusätzlich zu dem Namen, den ich hier oben anlege, muss ich jetzt auch ein Kennwort festlegen. Und ich kann mich den lokalen Richtlinien, bezüglich Passwortstärke, bezüglich Ablauf des Passworts und so weiter und so fort, unterwerfen. Das mache ich jetzt an der Stelle mal nicht. Ich habe hier jetzt die Möglichkeit, frei Einnahmen zu definieren, der halt noch nicht vorhanden ist, zum Beispiel UserA und kann dem ein Kennwort geben, das ich keinem verrate, und entsprechend auf OK klicken. Und auch dieses Login sollte hier unten auftauchen. Sehr häufig hat man diesen Umstand: Ich habe einen Login angelegt, aber meistens spricht man dann doch wieder vom User. Insofern Sie können sich quasi zugutehalten, ich bin auch in die Falle reingetappt beziehungsweise ich möchte natürlich zeigen, dass das hier auch geht, dass ich hier natürlich im Wesentlichen auch auf User-Ebene Logins anlegen kann, das heißt, für einzelne User auch einzelne Logins. Und das passiert in sehr vielen Fällen natürlich. Also ich habe selten so etwas wie Gruppen-Login für mehrere User. Es ist natürlich durchaus möglich, hat aber den Nachteil, dass dann der SQL Server die einzelnen Usern auch nicht mehr auseinanderhalten kann, weil meldet sich ja alles mit dem gleichen Login an. So wahrscheinlich wollen Sie das neue Login auch mal ausprobieren. Kein Problem, ich kann ohne Weiteres das UserA-Login verwenden, da muss ich mich auch gar nicht neu in der Station hier anmelden. Ich gehe einfach über Connect > Database Engine, wähle hier nicht Windows-Authentifizierung aus, sondern SQL-Server-Authentifizierung, sage dann ich möchte mich als UserA anmelden, ich kenne natürlich das Kennwort und konnektiere nämlich damit. Und Sie sehen hier, das SQL Server Management Studio zeigt mir das ohne Weiteres an. UserA, ich kann mal schauen, was ich denn hier so sehe. So weit komme ich an der Stelle nicht. Ich kann zwar sehen, welche Datenbanken vorhanden sind, aber ich habe keine Chance auf diese Datenbank zuzugreifen und es ist wahrscheinlich auch erst ganz gut so. Anderseits ich habe dem Login ja auch noch keine Rechte in irgendwelche Datenbank gegeben. Es gibt noch kein Mapping zu irgendwelchen Usern oder Ähnliches. Insofern ich kann die Registrierung hier entsprechend bestehen lassen und ich kann einfach hingehen und sagen, ich möchte hier Disconnect durchführen. So, damit habe ich getestet, dieses Login funktioniert. Ich kann mir mal anschauen, welche Eigenschaften so ein Login vielleicht noch hat, die mich interessieren könnten. Wir hatten ja hier gesehen, dass Sie entsprechendes Kennwort festlegen können für ein SQL-Server-Login. Sie können nicht hingehen und es im Nachhinein wechseln, also Sie können nicht sagen, ich mache aus einem SQL-Server-Login ein Windows oder aus einem Windows ein SQL-Server-Login. Das funktioniert nicht. Sie können das Kennwort hier festlegen. Sie können festlegen, was der entsprechende Login auf dem Server darf, sprich, welchen Servergruppen er zugeordnet ist. Sie können in einzelnen Datenbanken zuordnen, welche Securables er benutzen darf. Securables waren ja die Objekte, die ich entsprechend mit Sicherheit verschließen kann, beziehungsweise wo ich drauf Rechte vergeben kann. Und ich kann ein Status definieren. Ich kann sagen, darf sich anmelden und ist aktiv, das heißt, ich kann ihn sowohl ausschalten, als auch ihm explizit das Recht nehmen, entsprechend sich anmelden zu dürfen. Beides relativ starkes Recht, damit schließe ich ihn komplett vom SQL Server aus. So Sie fragen sich wahrscheinlich, warum es 2 Möglichkeiten gibt, einem Login den Zugriff auf den Datenbankserver zu verwehren. Der Umstand ist eigentlich relativ einfach, die Erklärung ist ein bisschen kompliziert, aber nur von der Wortwahl, weil die sich teilweise widerspricht zwischen SQL Server und Active Directory. Und zwar folgendermaßen: Sie können sich vorstellen, Sie haben einen Active-Directory-User, der hier ein Login hat. Und Sie können gleichzeitig vorstellen, dass dieser User Mitglied einer Active-Directory-Gruppe ist und diese Gruppe hat ebenfalls Zugriff auf den SQL Server. Jetzt ist es so, dass dieser User ja durch sein eigenes Login und das Login der Gruppe entsprechend Zugriff hat. Ich kann jetzt aber hingehen und dem Login des Benutzers das Anmelderecht nehmen und dann bedeutet das für ihn, obwohl er Mitglied der Active-Directory-Gruppe ist, die Zugriff auf den Server hat, darf er trotzdem nicht. Das ist hier schon mal ein negatives Recht an der Stelle, um sich überhaupt anzumelden. Das heißt, das ist der eigentliche Schalter, mit dem ich ihn dann ausschließe an der Stelle. Das hier unten ist eigentlich nur ihren Schalter, der das Login ein- oder ausschaltet. Zum Beispiel ist es gute Praxis, dass das SA-Konto entsprechend ein spezielles Login an der Stelle deaktiviert wird für den Fall, dass man es denn überhaupt gar nicht braucht und sowieso auf Windows-Authentifizierung setzt. In dem Moment würde man hingehen und entsprechend die SA an der Stelle deaktivieren. Hier unten gibt es sogar noch einen Schalter, nämlich, wenn ich entsprechend ein SQL-Server-Login habe und ich habe hier auf General angegeben Enforce password policy, dann kann es natürlich sein, dass ich zu oft beispielsweise das falsche Kennwort eingebe, in dem Moment wird das Login gesperrt. Und ich sehe hier eine Checkbox, die dann mit einem gesetzten Haken dasteht und ich kann quasi diesen Haken wegnehmen und auf OK drücken, quasi entsperren an der Stelle. Und damit gilt es wieder, dass das Login ganz normal auch wieder verwendet werden kann. So und da haben Sie gesehen, wie Sie Logins anlegen können, wie Sie entsprechend Logins auflisten können, also Sie sehen, welche Logins auf dem Server existieren. Sie haben natürlich auch die Möglichkeit, Logins zu löschen, rechte Maustaste und Delete. Das war es. Oder Rename, auch das ist relativ einfach, das heißt, die ganz normalen einfachen Aufgaben kann ich hier über das SQL Server Management Studio relativ elegant erledigen.

SQL Server: Sicherheit für Entwickler

Lernen Sie, wie sich das Thema Sicherheit im Entickleralltag mit Microsofts Datenbankserver umsetzen lässt.

2 Std. 31 min (25 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Exklusiv für Abo-Kunden
Erscheinungsdatum:15.01.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!