Benutzer mit den meisten Antworten
Benutzer nur Zugriff auf bestimmte Objekte gewähren

Frage
-
Hallo,
ich entwickle gerade eine kleine Web-Anwendung, die auf unsere Kundendatenbank zugreift. Ich habe mir gedacht, dass ich einen Benutzer erstelle der nur für die Leute verwendet wird, die diese Anwendung verwenden. Hierbei habe ich drei Stored Procedures erstellt, für die drei Aktionen, die dieser Web-Benutzer durchführen kann. Den Zugriff auf alle anderen Datenbankobjekte etc. möchte ich allerdings verweigern, sodass er wirklich nur diese drei Procedures ausführen kann, sonst nichts. Habt ihr irgendwelche Tips, wie man das am besten umsetzt? Es ist wahrscheinlich eine eher gewöhnliche Aufgabe, aber ich hatte noch nie mit SQL Server Sicherheit und Benutzerverwaltung zu tun, deswegen bin ich mir sehr unsicher hierbei.
Danke für eure Zeit :)
Antworten
-
Wenn Du ein Login, der keiner Serverrolle zugeordnet ist, Zugriff auf eine Datenbank erteilst, ist er immer Mitglied der Rolle "public" und hat nur dessen Rechte, und das sind im Standard keine.
Wenn der User trotzdem auf Tabellen zugreifen kann, dann müssen die Rechte ja irgendwo her kommen. Entweder ist der User noch in einer anderen Rolle wie "db_datareader" oder die Rechte der Standard Rolle "public" wurden verändert oder (was ganz schlimm wäre) der User ist in einer Server-Rolle wie womöglich SysAdmin; das wäre ganz schlecht.
Wäre es die Rolle "db_datareader" dürfte der Account keine SP / FN ausführen; ist es womöglich "db_owner"? Auch ganz schlecht.Wie gesagt, wenn er keiner weiteren Rolle angehört oder explizit Rechte bekommen hat, hat ein User per se keine Rechte innerhalb einer Datenbank, ausser das zu dieser wechseln darf. Rechte explizit verweigert werden sie aber auch nicht, das würde bedeuten, das anderweitig gesetzte Rechte sozusagen überschrieben werden; verweigern geht vor erlauben.
Ok, bei zugriffen von Usern ausserhalb der Domäne ist die Windows-Authentifizierung schwierig, aber Du solltest dann trotzdem jedem User einen eigenen SQL Account geben.
Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:55
-
Hallo Urbain,
mit Funktionen wie fn_my_permissions kannst Du Dir die Rechte auflisten lassen,
die ein Benutzerkonto hat (siehe Beispiel "D" für das Abfragen für einen anderen Benutzer).Ansonsten gilt, was Olaf schreibt:
Ein Benutzer hat zunächst nur die Rechte, die er über die Gruppe public erhält - dort ist jeder Benutzer enthalten.
Weitere Rechte erhält er über Server-, Datenbankrollen usw., siehe Berechtigungshierarchie
Verweigerte Rechte (DENY) haben wiederum Vorrang vor allen erteilten (GRANT) Rechten.Für die Rechtevergabe empfiehlt es sich, dies über Datenbankrollen zu machen
und dort die Benutzer einzutragen, das ist i. a. übersichtlicher als jeden Benutzer
einzeln die Rechte zu erteilen.Nutzt man Windows Sicherheit, so kann man den Datenbankrollen Windowsgruppen zuordnen,
um dem (Windows-)Systemadministrator das Leben zu erleichtern - er kann dann die Verwaltung
über das Active-Directory alleine vornehmen, in dem er Windows Konten in die Gruppen einträgt.Im Falle einer Web-Anwendung wie bei Dir solltest Du Dir den Abschnitt zu ASP.NET
Verwalten der Autorisierung mithilfe von Rollen durchlesen.Gruß Elmar
- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:54
-
Der Einfachheit halber würde ich vielleicht darüber nachdenken, diese 3 Prozeduren in ein eigenes Schema zu packen auf das Du dann die entsprechende EXECUTE Berechtigung erteilst. Dadurch sparst Du Dir die Vergabe der Rechte auf die einzelnen Prozeduren und brauchst Dich auch nicht darum zu kümmern, falls mal eine 4. oder 5. Prozedur hinzukommt.
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:54
- Tag als Antwort aufgehoben Urbain de Puce Sonntag, 5. Dezember 2010 13:54
- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:55
Alle Antworten
-
Hallo Urbain,
statt eine SQL Account für die 3 Benutzer zu erstellen, würde ich eher empfehlen, eine Datenbankrolle anzulegen, der die benötigten Rechte zu geben und die 3 Benutzer über deren Windows Authentifizierung der Rolle zuordnen.
Account und Passwort des SQL Accounts können weitergegeben werden (nach dem Motto, ich habe Urlaub, Kollege mach Du das mal) und so hast Du eine bessere Kontrolle, wer wirklich zugreift.
Kommt ein User hinzu, musst Du ihn nur der Rolle zuordnen.Die Rechte kannst Du für die Rolle oder einem User auf die SP ganz einfach mit
GRANT EXECUTE ON [dbo].[spDeineSP] TO [User_Oder_Rolle]
einrichten; dann dürfen sie die SP ausführen. Rechte auf die zugrundeliegenden Tabellen oder andere Objekte sind dann nicht nötig, das läuft dann über die Besitzverkettung.
Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de- Als Antwort vorgeschlagen Yury Iwtschenko Freitag, 3. Dezember 2010 12:35
-
Um sicherzustellen, dass die Benutzer wirklich nur Berechtigung auf diese Procedures haben muss ich nichts mehr machen? Ich hatte das schon so gemacht, dass ich eine Execute-Berechtigung für die Procedures vergeben hatte. Allerdings konnten die Benutzer noch immer die Tabellen und Views abfragen und andere Procedures und Functions ausführen. Wenn ich allerdings grundsätzlich das Recht auf Ausführen aller Procedures verweigere, dann nützt mir das Gestatten auf einzelne Procedures auch nichts, weil ein verweigertes Recht mehr wiegt als ein Erlaubtes.
Wenn ich nicht explizit eine Berechtigung erteile, wird diese dann automatisch verweigert?
PS: Das mit der Windows-Authentifizierung funktioniert glaube ich nicht, weil die Benutzer eigentlich über eine Internet-Seite auf die Datenbank zugreifen. Sie befinden sich nicht bei uns in der Domäne oder im Netzwerk.
-
Wenn Du ein Login, der keiner Serverrolle zugeordnet ist, Zugriff auf eine Datenbank erteilst, ist er immer Mitglied der Rolle "public" und hat nur dessen Rechte, und das sind im Standard keine.
Wenn der User trotzdem auf Tabellen zugreifen kann, dann müssen die Rechte ja irgendwo her kommen. Entweder ist der User noch in einer anderen Rolle wie "db_datareader" oder die Rechte der Standard Rolle "public" wurden verändert oder (was ganz schlimm wäre) der User ist in einer Server-Rolle wie womöglich SysAdmin; das wäre ganz schlecht.
Wäre es die Rolle "db_datareader" dürfte der Account keine SP / FN ausführen; ist es womöglich "db_owner"? Auch ganz schlecht.Wie gesagt, wenn er keiner weiteren Rolle angehört oder explizit Rechte bekommen hat, hat ein User per se keine Rechte innerhalb einer Datenbank, ausser das zu dieser wechseln darf. Rechte explizit verweigert werden sie aber auch nicht, das würde bedeuten, das anderweitig gesetzte Rechte sozusagen überschrieben werden; verweigern geht vor erlauben.
Ok, bei zugriffen von Usern ausserhalb der Domäne ist die Windows-Authentifizierung schwierig, aber Du solltest dann trotzdem jedem User einen eigenen SQL Account geben.
Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:55
-
Hallo Urbain,
mit Funktionen wie fn_my_permissions kannst Du Dir die Rechte auflisten lassen,
die ein Benutzerkonto hat (siehe Beispiel "D" für das Abfragen für einen anderen Benutzer).Ansonsten gilt, was Olaf schreibt:
Ein Benutzer hat zunächst nur die Rechte, die er über die Gruppe public erhält - dort ist jeder Benutzer enthalten.
Weitere Rechte erhält er über Server-, Datenbankrollen usw., siehe Berechtigungshierarchie
Verweigerte Rechte (DENY) haben wiederum Vorrang vor allen erteilten (GRANT) Rechten.Für die Rechtevergabe empfiehlt es sich, dies über Datenbankrollen zu machen
und dort die Benutzer einzutragen, das ist i. a. übersichtlicher als jeden Benutzer
einzeln die Rechte zu erteilen.Nutzt man Windows Sicherheit, so kann man den Datenbankrollen Windowsgruppen zuordnen,
um dem (Windows-)Systemadministrator das Leben zu erleichtern - er kann dann die Verwaltung
über das Active-Directory alleine vornehmen, in dem er Windows Konten in die Gruppen einträgt.Im Falle einer Web-Anwendung wie bei Dir solltest Du Dir den Abschnitt zu ASP.NET
Verwalten der Autorisierung mithilfe von Rollen durchlesen.Gruß Elmar
- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:54
-
Der Einfachheit halber würde ich vielleicht darüber nachdenken, diese 3 Prozeduren in ein eigenes Schema zu packen auf das Du dann die entsprechende EXECUTE Berechtigung erteilst. Dadurch sparst Du Dir die Vergabe der Rechte auf die einzelnen Prozeduren und brauchst Dich auch nicht darum zu kümmern, falls mal eine 4. oder 5. Prozedur hinzukommt.
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:54
- Tag als Antwort aufgehoben Urbain de Puce Sonntag, 5. Dezember 2010 13:54
- Als Antwort markiert Urbain de Puce Sonntag, 5. Dezember 2010 13:55