SQL Server: Sicherheit für Entwickler

Anwendungsrollen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Anwendungsrollen erlauben die Entwicklung von Applikationen, die über andere Rechte als deren Anwender verfügen. Anwendungsrollen verfügen über einen Namen und ein Kennwort. Beides muss bekannt sein, um über die Rechte der Rolle zu verfügen.
06:05

Transkript

Sicherlich erinnern Sie sich noch daran, dass es auf Ebene einer Datenbank 2 unterschiedliche Arten von Rollen gab. Es gab einmal die Datenbankrollen und es gab Anwendungsrollen. Und zu den hatte ich eigentlich noch gar nichts bis jetzt gesagt, das möchte ich nun nachholen. Anwendungsrollen erlauben es einer Anwendung andere Rechte zu geben, als der Benutzer, der sie verwendet. Das heißt, ich habe eine Anwendung, die auf Daten zugreifen darf oder vielleicht auf eine gewisse Art auf Daten zugreifen darf, auf die der Benutzer, wenn er die Anwendung nicht verwendet, entsprechend nicht zugreifen darf. Ich habe damit ein Sicherheitsloch geschlossen, was viele Anwendungen haben, und zwar wenn ich so etwas wie Windows-Authentifizierung oder auch SQL-Server-Authentifizierung verwende, dann habe ich nie ausgeschlossen, dass der Benutzer beispielsweise meine Anwendung gar nicht nutzt, sondern Access oder Excel verwendet, um direkt auf die Daten zu gehen und dann möglicherweise die Daten irgendwie zu exportieren oder in einer Art auszuwerten, die nicht unbedingt in meinem Interesse ist. Insofern habe ich die Möglichkeit, mit Anwendungsrollen da dem ein Riegel vorzuschieben. Die Anwendungsrolle besteht nämlich aus einem Namen und ein Kennwort, und nachdem ich mich authentifiziert habe und autorisiert habe, um auf die Datenbank zuzugreifen, muss ich dann entsprechend diesen Namen und dieses Kennwort noch kennen. Das sind dann Informationen, die irgendwo, ich kann jetzt Ihnen nicht genau sagen, wie Sie das realisieren in Ihrem konkreten Fall, aber die die Anwendung entsprechend irgendwo abgelegt haben muss, nach der Möglichkeit verschlüsselt natürlich, und entsprechend für die Ausführung einer Anweisung in den Sicherheitskontext dieser Anwendungsrolle wechselt, indem es den Namen und das Kennwort angibt. Damit kann ich dann normale Berechtigung wie gewöhnliche Rollen vergeben, also da sind Anwendungsrollen und Datenbankrollen relativ Ähnlich. Sie haben allerdings die Einschränkung, dass nach deren Aktivierung einer Anwendungsrolle, sie die Datenbank nicht mehr wechseln können, weil das könnte der SQL Server nicht mehr abbilden. Das heißt, wenn Sie sich einmal in einer Anwendungsrolle befinden, dann können Sie die natürlich wieder verlassen, dann ist die Sache in Ordnung, dann können Sie auch die Datenbank wechseln. Aber solange Sie sich in der Rolle befinden, können Sie die Datenbank nicht wechseln, was für die meisten Anwendungen nicht wirklich eine große Einschränkung ist. Ich möchte sie nur erwähnt haben für den Fall, dass Sie eine Anwendung haben, die auf mehrere Datenbanken gleichzeitig zugreift. Das geht da nicht mit ein und demselben Verbindung. Dann zeige ich Ihnen mal, wie das im SQL Server Management Studio aussieht und was Sie in Ihrer Anwendung da möglicherweise implementieren müssten. Das Skript applicationrole.sql hat alles, was wir für eine Demo brauchen. Zunächst einmal wird eine Datenbank angelegt und in dieser Datenbank wird eine Anwendungsrolle erstellt. Das kann ich entweder so machen oder ich kann Ihnen zeigen, wie das über die Oberfläche aussieht muss ich kurz einmal aktualisieren, dann kann ich hier unten Security > Roles, rechte Maustaste, New Application Role, der Roller kann ich einen Namen geben, ich muss ihr auch ein Kennwort geben. Ich kann festlegen, welche Schemata ihr gehören sollen, ich kann ein Standardschema festlegen. Standardmäßig würde es sonst einfach dbo, das ist auch okay so. Und dann kann ich hier Securables auswählen und dann, wie gehabt, auf gewisse Objekte zugreifen, Tabellen, was auch immer, und kann da Rechte vergeben. Es ist genau das Gleiche, was ich vorher auch in den Datenbankrollen hatten. Ich entscheide mich jetzt doch für diesen Weg. Wenn ich jetzt hier aktualisiere, tada, habe ich meine Anwendungsrolle. Das muss ich einmal quasi am Anfang einrichten und dann kann ich in den Kontext dieser Rolle mit dem Aufruf auf sp_setapprole wechseln. Dieses Stored Procedure bekommt einige Parameter, unter anderem den Namen und das Kennwort. Ich muss also beides irgendwo möglichst verschlüsselt oder sicher, wie auch immer, in meiner Anwendung parat haben, dann kann ich sagen, ich möchte ein Cookie erzeugen und entsprechend auch einen Return-Parameter übergeben für einen entsprechenden Wert, den dieser Cookie haben wird. Der Hintergrund zu diesem Cookie ist, dass ich mittels dieses Cookies quasi aus der Anwendungsrolle wieder hinauskomme. Warum sollte ich das machen? Ich könnte die Verbindung einfach terminieren, dann hätte ich den gleichen Effekt. Allerdings, wenn Sie Anwendung mit .NET schreiben, dann können Connections, die sich in dem Kontext einer Anwendungsrolle befinden, nicht zurück in den Connectionpool gelegt werden muss. Das ist eine Performance-Frage. Insofern macht es Sinn, wirklich sich ein Cookie geben zu lassen und zum Schluss auch wieder aus dem Kontext der Anwendungsrolle rauszukommen. Ich lasse das Ganze einmal kurz im Block laufen, damit die Variable hier oben nicht ihre Gültigkeit verliert. Und Sie sehen, die Ausgabe sieht folgendermaßen aus: Er gibt meinen Benutzernamen aus, in dem Fall den User, den ich hier habe, aber als Zweites dann in der Tat die Anwendungsrolle, die bestimmt auch entsprechend, welche Rechte ich denn tatsächlich habe. Und das realisiere ich, indem ich halt entweder auf SUSER_SNAME oder auf USER_NAME zugreife beziehungsweise die beiden Funktionen aufrufe. Und das ermöglicht mir, dass der SQL Server zum einen weiß, wer ich im Original bin und zum anderen aber die Berechtigung, die ich habe, über den Sicherheitskontext dieser Anwendungsrolle steigern kann. Das ist eine ganz feine Sache. Das heißt, damit könnte ich theoretisch mir Anwendungen überlegen, die vor jedem Aufruf dieses sp_setapprole starten, zum Schluss sp_unsetapprole, da war man also nicht besonders kreativ bei dem Namen, entsprechend aufrufen und dazwischen halte Dinge aufrufen, Dinge auf dem SQL Server tun, die der User selber nicht tun dürfte, der muss einfach nur Connect-Recht haben zur Datenbank, damit er sich damit überhaupt verbinden darf. Das heißt, damit können Sie wirklich Anwendungen schreiben, die völlig auseinandergehen in dem Sinne, dass der Benutzer sich nicht an der Anwendung vorbeischummeln kann, sondern die wirklich so weit gehen, dass der Zugriff, den der User auf der Datenbank macht, völlig anders ist und völlig konträr zu dem ist, was die Anwendung möglicherweise tun darf. Eine ganz nette Sache, wenn man Hochsicherheitsanwendungen schreiben möchte.

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!