<\/p>\n
Bernd Jungbluth, Horn<\/b><\/p>\n
In Teil 4 dieser Beitragsreihe wurden die Zugriffsrechte der Anwender auf die Datenbank begrenzt. In der Datenbank jedoch gibt es für die Anwender keine Grenzen. Durch die Zuordnung zur Datenbankrolle db_owner besitzen sie dort administrative Rechte. Dies erlaubt ihnen u.a. das Anlegen und Löschen von Tabellen sowie das Lesen und Ändern aller Daten. Wie Sie die Rechte mit Hilfe der Datenbankrollen weiter eingrenzen, lesen Sie in diesem Beitrag.<\/b><\/p>\n
Warnung<\/b><\/p>\n
Die beschriebenen Aktionen haben Auswirkungen auf Ihre SQL Server-Installation. Führen Sie die Aktionen nur in einer Testumgebung aus. Verwenden Sie unter keinen Umständen Ihren produktiven SQL Server!<\/p>\n
In der aktuellen Beispielumgebung verwendet der Anwender, sprich die Person am Rechner, zur Authentifizierung am SQL Server die Anmeldung WaWiMa<\/b>. Durch die Zuordnung dieser Anmeldung zum gleichnamigen Benutzer in der Datenbank WaWi_SQL <\/b>ist der Anwender für den Zugriff auf diese Datenbank autorisiert. Innerhalb der Datenbank erlaubt die Mitgliedschaft des Benutzers zur Datenbankrolle db_owner <\/b>dem Anwender das Lesen und Ändern der Daten. Soweit in Kurzform die Beschreibung der derzeitigen Rechtevergabe.<\/p>\n
Datenbank-Administratoren nutzen die Datenbankrolle db_owner <\/b>gerne, um Anwendern innerhalb einer Datenbank administrative Tätigkeiten zu erlauben. Auf diese Weise lassen sich Aufgaben an einen oder mehrere Anwender übertragen. Zum Beispiel an die Mitarbeiter des Supports. Sie geben neuen Kollegen die entsprechenden Rechte für den Datenzugriff und kümmern sich um die Datenbanksicherung. Datenbankobjekte wie Tabellen, gespeicherte Prozeduren und Sichten müssen sie jedoch weder anlegen, noch ändern oder gar löschen. Das sind eher die Tätigkeiten der Datenbankentwickler. Diese findet man in der Praxis ebenfalls oft in der Datenbank-rolle db_owner<\/b>. Für die Installation neuer Datenbankversionen brauchen Sie die Rechte zum Anlegen, Ändern und Löschen von Datenbankobjekten. Allumfassende Lese- und Schreibzugriffe sind dafür allerdings nicht erforderlich.<\/p>\n
Obwohl es sich in beiden Fällen um administrative Tätigkeiten handelt, haben die Anwender dennoch zu viele Rechte. Es gibt keinen Grund für eine Mitgliedschaft in der Datenbankrolle db_owner<\/b>. Weder für den Support, noch für die Datenbankentwickler, noch für irgendeinen anderen Anwender. Schließlich stellt SQL Server noch neun weitere Datenbankrollen zur Verfügung. Diese reichen fürs Erste, um den Anwendern die Rechte zu geben, die Sie für die Realisierung ihrer Aufgaben benötigen. Und falls diese wider Erwarten nicht genügen, können Sie eigene Datenbankrollen anlegen und dort die Rechte gezielt vergeben. <\/p>\n
Die Datenbankrolle db_owner <\/b>hingegen sollte nur ein einziges Mitglied enthalten: den Datenbankbesitzer, kurz den Benutzer dbo <\/b>(siehe Bild 1). Dieser Benutzer ist standardmäßig in der Datenbankrolle eingetragen und lässt sich nicht entfernen. Die Unterschiede der Datenbankrolle db_owner <\/b>zum Datenbankbesitzer dbo <\/b>wurden im letzten Beitrag beschrieben.<\/p>\n
<\/p>\n
Bild 1: Die optimale Datenbankrolle db_owner<\/span><\/b><\/p>\n Rechte für den Datenbankentwickler<\/b><\/p>\n Datenbankentwickler erstellen neue Versionen bestehender Datenbanken in ihrer Entwicklungsumgebung und installieren das Ergebnis im produktiven SQL Server. Dies erfolgt über eigens dafür erzeugte SQL-Skripte oder über die Möglichkeiten der SQL Server Data Tools.<\/p>\n Für die Installation der Änderungen sind nur eine Handvoll Rechte notwendig. Neue Objekte werden mit CREATE <\/b>angelegt, bestehende mit ALTER <\/b>geändert und nicht mehr benötigte mit DELETE <\/b>gelöscht. Bei diesen SQL-Anweisungen handelt es sich um DDL-Befehle. DDL steht für Data Definition Language – und die Datenbankrolle db_ddladmin <\/b>erlaubt ihren Mitgliedern die Ausführung dieser Befehle. Der Datenbankentwickler muss also nur dieser Datenbankrolle zugeordnet werden und schon hat er die notwendigen Rechte zur Bereitstellung einer neuen Datenbankversion.<\/p>\n Beinhaltet die neue Datenbankversion eine detaillierte Rechtevergabe auf den Datenbankobjekten, braucht der Datenbankentwickler weitere Rechte. Mit GRANT <\/b>vergibt er Rechte, mit REVOKE <\/b>entzieht er diese und mit DENY <\/b>verbietet er den Zugriff. Die Rechte für diese Befehle sind nicht in der Datenbankrolle db_ddladmin <\/b>enthalten. Dafür gibt es die Datenbankrolle db_securityadmin<\/b>. Ein Datenbankentwickler benötigt somit keine Zuordnung zur Rolle db_owner<\/b>. Die beiden Datenbankrollen db_ddladmin <\/b>und db_securityadmin <\/b>sind für seine Aufgaben vollkommen ausreichend (siehe Bild 2).<\/p>\n Bild 2: Datenbankrollen für Datenbankentwickler<\/span><\/b><\/p>\n Möglicherweise trägt der Datenbank-entwickler in einer Tabelle die neue Versionsnummer der Datenbank ein. Dazu braucht er Lese- und Schreibrechte. Jedoch nur an der entsprechenden Tabelle. Die Rechtevergabe an Tabellen wird später beschrieben.<\/p>\n Rechte für den Support<\/b><\/p>\n Eine Datenbank gehört zu einer Applikation. Ob es sich hierbei um eine Datenbank zu einer IT-Inventursoftware, einer Lagerverwaltung oder einem ERP-System handelt, die Anwender verwalten die Daten immer über ein zugehöriges Frontend. Für die Applikation selbst steht ein Support zur Verfügung. Dieser klärt Fragen, analysiert und behebt Fehler, verwaltet Zugriffsberechtigungen und führt Datenbanksicherungen durch. <\/p>\n Einige Applikationen beinhalten eine eigene Benutzerverwaltung. Hier trägt der Support den neuen Kollegen als Anwender für die Applikation ein, worauf im SQL Server ein neuer Benutzer in der Datenbank mit entsprechenden Rechten angelegt wird. Vorausgesetzt, der Datenbankadministrator hat bereits die Anmeldung angelegt, mit der sich der neue Kollege am SQL Server authentifiziert. Diese Aufgabe findet außerhalb der Datenbank statt und obliegt somit weiterhin dem Datenbankadministrator. Innerhalb der Datenbank benötigt der Support die entsprechenden Rechte zur Verwaltung der Benutzer und deren Zugriffsrechte. Als Mitglied der bereits erwähnten Datenbankrolle db_securityadmin <\/b>darf der Support die Zugriffsrechte direkt an den Datenbankobjekten wie auch über eigene Datenbank-rollen vergeben. Für die Rechte zum Anlegen, Ändern und Löschen von Benutzern benötigt er zusätzlich noch die Zuordnung zur Datenbankrolle db_accessadmin<\/b>. <\/p>\n Die Möglichkeit zur Sicherung und Wiederherstellung der Daten gehört bei vielen Applikationen ebenfalls zum Funktionsumfang. Hierzu benötigt der Support die Rechte zur Ausführung der T-SQL-Befehle BACKUP <\/b>und RESTORE<\/b>. Diese Rechte beinhaltet die Datenbankrolle db_backupoperator<\/b>.<\/p>\n Als Mitglied dieser drei Datenbankrollen besitzt der Support alle Rechte die er für seine Aufgaben benötigt (siehe Bild 3). Die Zuordnung zur Datenbankrolle db_owner ist nicht erforderlich.<\/p>\n Bild 3: Datenbankrollen für Supportmitarbeiter<\/span><\/b><\/p>\n Sie fragen sich, wie der Support Fehler analysieren soll, wenn er die Daten der Datenbank nicht lesen darf. Die Antwort ist recht einfach. Die Fehleranalyse findet nicht in der Produktivdatenbank, sondern in einer Testdatenbank statt.<\/p>\n Dort kann der Support anhand von Testdaten das Szenario nachstellen und die Ursache für den Fehler finden. Durch diese Trennung verhindern Sie ein versehentliches Ändern der Echtdaten.<\/p>\n Datenbankrolle public<\/b><\/p>\n Die Datenbankrolle mit der Zwangsmitgliedschaft. Jeder Benutzer einer Datenbank ist der Datenbankrolle public <\/b>zugeordnet. Diese Zuordnung ist fest vorgegeben und lässt sich nicht ändern. Der ursprüngliche Sinn dieser Datenbankrolle liegt in der Definition von Zugriffsrechten, die für jeden Benutzer mindestens erforderlich sind. Eine solche Art der Rechtevergabe birgt jedoch einige Sicherheitsrisiken. Diese lernen Sie in einem der nächsten Beiträge kennen. Am besten folgen Sie der bewährten Sicherheitsempfehlung und ignorieren die Datenbankrolle public<\/b>. <\/p>\n Lese- und Schreibrechte<\/b><\/p>\n Es bleiben noch vier Datenbankrollen übrig. Diese beziehen sich auf die Lese- und Schreibrechte – die Rechte für die SQL-Anweisungen SELECT<\/b>, INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>.<\/p>\n Mitglieder der Datenbankrolle db_datareader<\/b> dürfen alle Daten der Datenbank lesen und Mitglieder der Datenbankrolle db_datawriter <\/b>alle Daten ändern und löschen sowie neue hinzufügen. Für die meisten Anwender der Datenbank ist eine Zuordnung zu diesen beiden Datenbankrollen absolut ausreichend. Anwender, die Daten lediglich auswerten, benötigen sogar nur die Zuordnung zur Datenbankrolle db_datareader<\/b>. <\/p>\n Nun haben Sie einen Überblick über die Rechte der einzelnen Datenbankrollen. Datenbankadministratoren ohne dieses Wissen wählen am Anfang gerne alle Datenbankrollen aus (siehe Bild 4).<\/p>\n Bild 4: Viel hilft viel<\/span><\/b><\/p>\n Viel hilft viel – eine Aussage, die in diesem Fall nicht stimmt. Eine SELECT<\/b>-Anweisung auf eine x-beliebige Tabelle der Datenbank liefert bei einer solchen Definition die Meldung aus Bild 5.<\/p>\n Bild 5: Die Folgen von „Viel hilft viel“<\/span><\/b><\/p>\n Mit dieser Rechtevergabe werden dem Benutzer nicht nur Rechte gewährt, sondern auch verweigert. Die Zuordnung zu den Datenbankrollen db_denydatareader <\/b>und db_denydatawriter <\/b>verbietet dem Benutzer jegliche Lese- und Schreibzugriffe. Im Hintergrund der beiden Datenbankrollen steht der Befehl DENY<\/b>. Ein Verweigern per DENY <\/b>überwiegt alle erteilten Rechte, sogar die der Datenbankrolle db_owner<\/b>. <\/p>\n Die Auswahl aller Datenbankrollen ist nicht selten der Grund, warum die zum Benutzer gehörende Anmeldung letztendlich in der Serverrolle sysadmin <\/b>landet. Für Mitglieder dieser Serverrolle gibt es im SQL Server keine Grenzen. Da verhindert auch kein DENY <\/b>den Datenzugriff. Jedoch beinhaltet diese Zuordnung jegliche Rechte an den Datenbanken und vor allem an den dort gespeicherten Daten. Schneller können Sie Ihr mühsam erstelltes Sicherheitskonzept nicht zerstören.<\/p>\n Fehlende Zugriffsrechte in einer Datenbank lösen Sie bitte innerhalb der Datenbank. Die Serverrolle sysadmin ist in solchen Fällen für Sie tabu.<\/p>\n Wählen Sie die Datenbankrollen bewusst aus. Dies gilt insbesondere für die Datenbankrollen db_denydatareader <\/b>und db_denydatawriter<\/b>. Die beiden sollten Sie nur nutzen, wenn Sie den Lese- beziehungsweise Schreibzugriff unter allen Umständen verhindern möchten. <\/p>\n Mögliche Kandidaten für die Datenbankrolle db_denydatawriter <\/b>sind Anwender, die Daten lediglich analysieren und auswerten. Um sicherzustellen, dass sie definitiv keine Daten hinzufügen, ändern oder löschen können, ordnen Sie den zugehörigen Benutzer der Datenbankrolle db_denydatawriter <\/b>zu. Auf diese Weise können die Anwender in Access die Daten der SQL Server-Datenbank über eingebundene Tabellen auswerten, ohne Gefahr zu laufen, die Daten versehentlich zu ändern oder zu löschen. <\/p>\n Wozu die Mühe Reicht es nicht, wenn der Benutzer nur zur Datenbankrolle db_datareader <\/b>gehört Grundsätzlich schon. Erhält der Benutzer aber versehentlich das Recht zum Anlegen von Daten in einer Tabelle, verhindert dessen Mitgliedschaft in db_denydatawriter <\/b>dieses Schreibrecht. Dies gilt ebenso für eine irrtümliche Zuordnung des Benutzers zu db_datawriter <\/b>oder gar zu db_owner<\/b>.<\/p>\n Das klingt recht sicher und durchdacht – zum Zeitpunkt der Rechtevergabe. Zu einem späteren Zeitpunkt ist das Konzept der Mitgliedschaft zu den Datenbankrollen db_denydatareader <\/b>und db_denydatawriter <\/b>vielleicht nicht mehr so einfach nachzuvollziehen. Deshalb sollten Sie sich den Grund für die Verwendung dieser beiden Datenbankrollen gut dokumentieren. <\/p>\n Angenommen, Sie müssen einem Anwender den lesenden Zugriff auf eine Tabelle gewähren. Das ist schnell getan. Sie gehen zur Tabelle, wählen dort über die Berechtigungen den zum Anwender gehörenden Benutzer aus und erteilen ihm das Recht für die SELECT<\/b>-Anweisung. Bei dieser Art der Rechtevergabe sehen Sie die bestehende Zuordnung des Benutzers zur Datenbankrolle db_denydatareader <\/b>nicht. Sie werden auch nicht darauf hingewiesen. Der Anwender möchte nun die Daten der Tabelle lesen. Er erhält jedoch nur Fehlermeldungen. Jetzt kommt Hektik auf, denn das Problem muss wie immer schnell gelöst werden. Sie überprüfen die Datenbankrollen des Benutzers und sehen die Zuordnung zur Datenbankrolle db_denydatareader<\/b>. Dazu gab es bestimmt mal einen guten Grund. Nur ohne Dokumentation fehlt Ihnen die Argumentation, warum Sie diese Zuordnung nicht so ohne weiteres ändern können. Um das Problem zu lösen, ordnen Sie den Benutzer der Datenbankrolle db_owner <\/b>zu. Dann kann er erst mal arbeiten. Um die tatsächlichen Rechte kümmern Sie sich später. Doch es bleibt bei den Fehlermeldungen, denn die Zuordnung zur Datenbankrolle db_denydatareader <\/b>überwiegt den Rechten der Datenbankrolle db_owner<\/b>. Eine Lösung muss her und zwar schnell. Also ordnen Sie die Anmeldung des Benutzers der Serverrolle sysadmin <\/b>zu. Das Problem ist gelöst, denn mit diesen Rechten darf der Anwender im SQL Server alles – sogar die Daten der vorgesehenen Tabelle lesen. Natürlich ist diese Zuordnung nur vorübergehend. Sobald Sie Zeit haben, die Rechtevergabe neu zu überdenken und anzupassen, werden Sie die Anmeldung aus der Serverrolle sysadmin <\/b>wieder entfernen. Dabei sollten Sie die Zuordnung zur Datenbankrolle db_owner <\/b>nicht vergessen. Die Frage, wann Sie die Zeit haben und wie lange dieses vorübergehend anhält, dürfen Sie sich gerne selbst beantworten. Dieses Beispiel ist nicht erfunden. Vielmehr zeigt es den Grund, warum in der Praxis Anmeldungen in der Serverrolle sysadmin <\/b>sowie Benutzer in der Datenbankrolle db_owner <\/b>zu finden sind.<\/p>\n Erstellen Sie sich eine Dokumentation Ihres Berechtigungskonzepts. Diese beinhaltet nicht nur die Mitgliedschaft der Benutzer in den Datenbankrollen, sondern auch den Grund für diese Zuordnungen. Jegliche Anforderung, die Änderungen an den Zugriffsrechten erfordert, prüfen Sie zuerst gegen Ihre Dokumentation. Passen die Anforderungen nicht zu Ihrem Berechtigungskonzept, wehren Sie sich so gut wie möglich gegen die geforderten Rechte. <\/p>\n Sie haben den Überblick zur aktuellen Rechtevergabe und Sie als Datenbankadministrator sind verantwortlich für die Daten. Ob nun Daten versehentlich gelöscht oder bewusst von einem Anwender manipuliert wurden, Sie müssen gute Argumente haben, warum Sie dies nicht verhindern konnten. Mit dem Argument, Sie haben die Rechte nur vorübergehend erteilt, um die Anforderungen der Abteilung zu erfüllen, werden Sie nicht weit kommen. Sie sind der Fachmann und es gehört zu Ihren Aufgaben, die möglichen Folgen einer Rechtevergabe einzuschätzen und zu bewerten.<\/p>\n Es ist wie immer bei der Definition von Zugriffsrechten. Das Berechtigungskonzept sollte gut durchdacht und dokumentiert sein. Diese Dokumentation ist Ihr Leitfaden. Jede neue Anforderung an Zugriffsrechte muss mit Ihrem Berechtigungskonzept vereinbar sein. Ist dies nicht der Fall, stellen Sie das aktuelle Konzept in Frage und definieren Sie bei Bedarf ein neues. <\/p>\n Zum Schluss ein kleiner Tipp für Ihr Berechtigungskonzept: Die Zuordnung eines Benutzers zu den Datenbankrollen db_datareader <\/b>und db_denydatareader <\/b>sowie db_datawriter <\/b>und db_denydatawriter <\/b>oder gar zu allen vieren ist schlicht und ergreifend sinnlos.<\/p>\n Lese- und Schreibrechte für WaWiMa <\/b><\/p>\n Genug der Theorie. In der Beispieldatenbank WaWi_SQL <\/b>ist der Benutzer WaWiMa <\/b>aktuell der Datenbankrolle db_owner <\/b>zugeordnet. Diese zu hohen Rechte werden Sie nun eingrenzen.<\/p>\n Mit diesem Beitrag gibt es eine neue Version der SQL Server-Beispieldatenbank und der Access-Applikation. Sollten Sie die Beispiele bereits installiert haben, löschen Sie diese und installieren Sie die neuen Versionen. Eine Installationsanleitung finden Sie am Ende des Artikels.<\/p>\n Öffnen Sie das SQL Server Management Studio und melden Sie sich an Ihrem SQL Server als Datenbankadministrator an. Danach erweitern Sie den Ordner der Datenbank WaWi_SQL <\/b>und gehen zum Ordner Sicherheit<\/b>. Hier gibt es jetzt zwei Möglichkeiten zur Rechtevergabe per Datenbankrollen. Sie können den Benutzer in den jeweiligen Datenbankrollen hinzufügen beziehungsweise entfernen oder beim Benutzer selbst die Zuordnung vornehmen.<\/p>\n <\/p>\n Schauen Sie sich zunächst den Weg über die Datenbankrollen an. Dazu erweitern Sie den Ordner Rollen <\/b>und danach den Ordner Datenbankrollen <\/b>(siehe Bild 6). Öffnen Sie per Doppelklick den Dialog zur Datenbankrolle db_owner<\/b>.<\/p>\n Bild 6: Datenbankrollen einer Datenbank<\/span><\/b><\/p>\n Dort können Sie unter Mitglieder dieser Rolle den Eintrag WaWiMa <\/b>markieren und mit einem Klick auf die Schaltfläche Entfernen (siehe Bild 7) die Mitgliedschaft beenden. Danach besitzt der Benutzer WaWiMa <\/b>in der Datenbank keinerlei Zugriffsrechte mehr. Sollten Sie dies in einer produktiven Umgebung vorhaben, stellen Sie sich schon einmal auf diverse Anrufe und E-Mails ein.<\/p>\n Bild 7: Verwalten der Mitglieder einer Datenbankrolle<\/span><\/b><\/p>\n Eine weitaus bessere Vorgehensweise ist die Änderung der Mitgliedschaft über den Benutzer. Wechseln Sie dazu zum Ordner Benutzer <\/b>und öffnen Sie mit einem Doppelklick auf WaWiMa <\/b>den Dialog Datenbankbenutzer<\/b>. In der Seite Mitgliedschaft <\/b>sehen Sie die aktuelle Zuordnung des Benutzers zu den Datenbankrollen. <\/p>\n Entfernen Sie das Häkchen bei der Datenbankrolle db_owner <\/b>und aktivieren Sie die Datenbankrollen db_datareader <\/b>und db_datawriter <\/b>(siehe Bild 8). Mit einem Klick auf die Schaltfläche OK<\/b> bestätigen Sie die neuen Zugriffsrechte. Der Benutzer WaWiMa<\/b> besitzt in der Datenbank nun keine administrativen Rechte mehr. Er darf nur noch Daten lesen und ändern. <\/p>\n Bild 8: Verwalten der Datenbankrollen eines Benutzers<\/span><\/b><\/p>\n In der Access-Beispielapplikation WaWi <\/b>hat die Änderung der Zugriffsrechte keine Auswirkung. Die Verbindung zum SQL Server wird weiterhin über die Anmeldung WaWiMa <\/b>hergestellt. Diese Anmeldung ist in der Datenbank WaWi_SQL <\/b>dem gleichnamigen Benutzer zugeordnet. Durch die Mitgliedschaft des Benutzers in den Datenbankrollen db_datareader <\/b>und db_datawriter <\/b>darf der Anwender die Daten der Datenbank lesen und ändern. <\/p>\n Testen Sie es einfach mal. Öffnen Sie die Beispielapplikation WaWi<\/b>. Sie werden keinen Unterschied feststellen. Trotz der geringeren Rechte sehen Sie alle Daten.<\/p>\n Ein Klick auf die Schaltfläche Kunden <\/b>liefert Ihnen die Daten der Tabelle Kunden<\/b>. Sie können diese Daten nicht nur lesen, Sie dürfen auch neue hinzufügen sowie bestehende ändern und löschen. <\/p>\n Die Anmeldung WaWiMa <\/b>erlaubt Ihnen den Zugriff auf alle Daten der Datenbank WaWi_SQL<\/b>. Ob nun per eingebundener Tabelle wie im Formular Aufträge <\/b>oder per ADO wie im Formular Artikel<\/b>, die Art und Technik des Datenzugriffs spielt dabei keine Rolle.<\/p>\n Es gibt jedoch Ausnahmen, wie ein Klick auf die Schaltfläche Geburtstagsliste <\/b>zeigt (siehe Bild 9).<\/p>\n Bild 9: Fehler beim Datenzugriff<\/span><\/b><\/p>\n EXECUTE-Rechte für WaWiMa <\/b><\/p>\n Das Formular Geburtstagsliste <\/b>basiert auf der Pass Through-Abfrage ptSelectGeburtstagsliste<\/b>, die wiederum die gespeicherte Prozedur dbo.pSelectGeburtstagsliste <\/b>ausführt. Hier liegt die Ursache für den Fehler, genauer gesagt bei den Rechten zum Ausführen der gespeicherten Prozedur. <\/p>\n Der Benutzer WaWiMa <\/b>besitzt mit der Zuordnung zur Datenbankrolle db_datareader <\/b>das Recht für die SQL-Anweisung SELECT <\/b>zum Lesen der Daten und mit der Datenbankrolle db_datawriter <\/b>die Rechte zum Ändern der Daten per INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>. Keine der beiden Datenbankrollen beinhaltet das Recht für die SQL-Anweisung EXECUTE <\/b>zur Ausführung von gespeicherten Prozeduren. Ergo muss der Benutzer WaWiMa <\/b>zusätzlich das Recht für EXECUTE <\/b>erhalten. <\/p>\n Bitte denken Sie jetzt nicht an die Datenbankrolle db_owner <\/b>oder gar an die Serverrolle sysadmin<\/b>. Wie schon erwähnt, wäre dies zwar eine schnelle Lösung des Problems, aber auch die mit Abstand schlechteste. Es ist nicht erforderlich, dem Anwender alle Rechte zu geben. Ihm fehlt ja nur ein Recht – das Recht für die SQL-Anweisung EXECUTE<\/b>.<\/p>\n Microsoft empfiehlt den Einsatz von gespeicherten Prozeduren unter anderem aus Gründen der besseren Performance und der Datensicherheit. Da ist der Gedanke naheliegend, dass SQL Server eine entsprechende Datenbankrolle anbietet. Leider gibt es eine solche Datenbankrolle nicht, obwohl sie seit vielen Jahren vermisst und auch immer wieder gefordert wird.<\/p>\n Sie müssen sich selbst helfen. Konkret bedeutet dies, dass Sie eine eigene Datenbankrolle für diese Rechtevergabe anlegen. Also zurück zum SQL Server Management Studio und dort zum Ordner Rollen <\/b>der Datenbank WaWi_SQL<\/b>. Hier klicken Sie mit der rechten Maustaste auf den Ordner Datenbankrollen <\/b>und wählen den Eintrag Neue Datenbankrolle <\/b>(siehe Bild 10).<\/p>\n Bild 10: Eine eigene Datenbankrolle<\/span><\/b><\/p>\n Im Dialog Datenbankrolle – Neu <\/b>geben Sie als erstes den Namen der Datenbankrolle im Feld Rollenname <\/b>ein. Der Name ist frei wählbar. Sie können die Nomenklatur der fixen Datenbankrollen beibehalten und die Bezeichnung db_execute <\/b>verwenden oder Sie legen für Ihre Datenbankrollen eine eigene Namensgebung fest. Wie wäre es mit der Bezeichnung edb_execute<\/b><\/p>\n Die neue Datenbankrolle soll wie alle anderen Objekte der Datenbank dem Datenbankbesitzer gehören. Tragen Sie dazu dbo <\/b>in das Feld Besitzer <\/b>ein. Nun klicken Sie auf die Schaltfläche Hinzufügen <\/b>und wählen im darauffolgenden Dialog über Durchsuchen den Benutzer WaWiMa <\/b>aus (siehe Bild 11). Bestätigen Sie die Auswahl mit einem Klick auf OK<\/b>. Der Benutzer WaWiMa <\/b>ist jetzt Mitglied Ihrer Datenbankrolle.<\/p>\n Bild 11: WaWiMa als Mitglied der eigenen Datenbankrolle <\/span><\/b><\/p>\n Das war der erste Teil der Definition – und der einfachste. Jetzt müssen Sie noch jede Ihrer gespeicherten Prozeduren der Datenbankrolle zuordnen und diesen dann einzeln die SQL-Anweisung EXECUTE <\/b>erlauben. Dazu wechseln Sie zur Seite Sicherungsfähige Elemente<\/b>. Über Suchen <\/b>öffnen Sie den Dialog Objekte hinzufügen<\/b>. Hier haben Sie verschiedene Möglichkeiten, die Suche nach den gewünschten Datenbankobjekten einzugrenzen.<\/p>\n Wählen Sie die Option Alle Objekte des Typs <\/b>(siehe Bild 12) und klicken Sie auf OK. Es öffnet sich der Dialog Objekttypen auswählen<\/b>.<\/p>\n Bild 12: Filtern der Datenbankobjekte<\/span><\/b><\/p>\n Hier entscheiden Sie sich für den Objekttyp Gespeicherte Prozeduren <\/b>(siehe Bild 13).<\/p>\n Bild 13: Auswahl der Objekttypen<\/span><\/b><\/p>\n Nach einem Klick auf OK <\/b>sind Sie wieder im Ausgangsdialog, der Ihnen nun im oberen Teil unter Sicherungsfähige Elemente <\/b>alle gespeicherte Prozeduren der Datenbank auflistet (siehe Bild 14). Dies beinhaltet auch die systeminternen gespeicherten Prozeduren. Für Ihre Datenbankrolle brauchen Sie allerdings nur die benutzerdefinierten gespeicherten Prozeduren aus dem Schema dbo<\/b>. Konkret sind dies die beiden gespeicherten Prozeduren dbo.pSelectAnsprechpartnerZuMitarbeiter <\/b>und dbo.pSelectGeburtstagsliste<\/b>. <\/p>\n Bild 14: Gespeicherte Prozeduren zur Auswahl<\/span><\/b><\/p>\n Als erstes erlauben Sie den Mitgliedern Ihrer Datenbankrolle die gespeicherte Prozedur dbo.pSelectGeburtstagsliste <\/b>per EXECUTE <\/b>auszuführen. Dazu markieren Sie die gespeicherte Prozedur und aktivieren im unteren Bereich des Dialogs für den Befehl Ausführen <\/b>das Recht Erteilen <\/b>(siehe Bild 15).<\/p>\n Bild 15: Erteilen des Rechts Ausführen<\/span><\/b><\/p>\n Diese Auswahl dürfen Sie nun für die Gespeicherte Prozedur dbo.pSelect-An-sprech-part-ner-Zu-Mit-ar-beit-er <\/b>wiederholen. Sparen Sie sich den Versuch, mehrere gespeicherte Prozeduren auf einmal auszuwählen, um so allen gleichzeitig das Recht Ausführen <\/b>zu erteilen. Es funktioniert nicht. Sie müssen tatsächlich die Rechte für jede gespeicherte Prozedur einzeln vergeben.<\/p>\n Über den gleichen Weg können Sie den Mitgliedern Ihrer Datenbankrolle die Ausführung einer gespeicherten Prozedur verbieten. Dazu aktivieren Sie für den Befehl Ausführen <\/b>den Eintrag Verweigern<\/b>. Eine Kombination von Erteilen und Verweigern ist nicht sinnvoll, weshalb der Dialog eine solche Auswahl nicht unterstützt. <\/p>\n Durch Aktivieren der Option Mit Erteilung <\/b>dürfen die Mitglieder dieser Datenbankrolle anderen Benutzern das Recht Ausführen<\/b> für die markierte gespeicherte Prozedur gewähren. Diese Art der Rechtevergabe ist auf das Erteilen eines Rechts für genau die eine gewählte gespeicherte Prozedur begrenzt. Mit den umfangreichen Rechten der Datenbankrolle db_securityadmin <\/b>ist sie nicht vergleichbar.<\/p>\n Nachdem Sie für beide gespeicherte Prozeduren zum Befehl Ausführen <\/b>die Option Erteilen <\/b>aktiviert haben, können Sie den Dialog mit einem Klick auf OK <\/b>beenden. Die neue Datenbankrolle ist jetzt im Ordner Datenbankrollen <\/b>zu sehen. <\/p>\n Öffnen Sie mit einem Doppelklick auf die Datenbankrolle edb_execute <\/b>den zugehörigen Dialog erneut. Die Seite Sicherungsfähige Elemente <\/b>beinhaltet jetzt nur noch gespeicherte Prozeduren, zu denen in dieser Datenbank-rolle Rechte definiert sind. Die Rechte selbst sehen Sie nach Markieren der jeweiligen gespeicherten Prozedur im unteren Bereich des Dialogs. Allerdings ist die Anzeige etwas verwirrend, zeigt diese doch zwei Zeilen für den Befehl Ausführen <\/b>(siehe Bild 16).<\/p>\n Bild 16: Aktuelle Rechte einer gespeicherten Prozedur<\/span><\/b><\/p>\n Die beiden Zeilen sollen Sie beim Ändern der vergebenen Rechte unterstützen. In der ersten Zeile ändern Sie die Berechtigung und vergleichen dabei die Werte mit dem Ist-Zustand der zweiten Zeile. Sie können die Änderung auch direkt in der zweiten Zeile vornehmen. Wie gesagt, der Dialog ist an dieser Stelle verwirrend. Beenden Sie den Dialog ohne Änderungen mit einem Klick auf OK<\/b>.<\/p>\n Nun wissen Sie, wie eine Datenbankrolle erstellt wird und wie Sie den Mitgliedern dort Rechte an Datenbankobjekten erteilen oder verweigern. Dabei ist es gleich, ob es sich bei dem Datenbankobjekt um eine gespeicherte Prozedur, eine Sicht oder eine Tabelle handelt. Die Vorgehensweise ist immer dieselbe, lediglich die Rechte unterscheiden sich. Bei gespeicherten Prozeduren ist es das Recht Ausführen<\/b>, bei Tabellen und Sichten sind es die Rechte Auswählen<\/b>, Aktualisieren<\/b>, Einfügen <\/b>und Löschen<\/b>.<\/p>\n Erinnern Sie sich noch an die geforderten Lese- und Schreibrechte für die Datenbankentwickler Wie eingangs beschrieben, wird bei der Installation einer neuen Datenbankversion die zugehörige Versionsnummer gerne in einer dafür vorgesehenen Tabelle eingetragen. Der Datenbankentwickler benötigt hierzu die Rechte zum Lesen und Ändern dieser Daten. Dazu erstellen Sie eine weitere Datenbankrolle und fügen dieser den Benutzer zur Anmeldung des Datenbankentwicklers hinzu. Anschließend markieren Sie unter Sicherungsfähige Elemente <\/b>die Tabelle und erteilen ihr die Rechte Auswählen <\/b>und Aktualisieren<\/b>. Dadurch können die Datenbankentwickler die Daten dieser Tabelle nur lesen und überschreiben. Für das Löschen oder Hinzufügen von Daten in der Tabelle oder gar zum Lesen und Schreiben in den anderen Tabellen haben sie keine Berechtigung.<\/p>\n Sie sehen, die Vergabe von Rechten an Datenbankobjekten in einer Datenbankrolle besteht aus mehreren Schritten, beinhaltet viele Klicks und das in einem nicht sonderlich hilfreichen Dialog.<\/p>\n Da stellt sich die Frage nach einer Alternative. Die gibt es tatsächlich, denn schließlich lösen die Klicks im Dialog letztendlich T-SQL-Befehle aus:<\/p>\n Diese SQL-Anweisung legt eine Datenbankrolle namens edb_execute <\/b>mit dem Besitzer dbo <\/b>an. Den Benutzer WaWiMa <\/b>fügen Sie mit der folgenden Anweisung der Datenbankrolle hinzu:<\/p>\n Gut, diese beiden Aktionen lassen sich auch im Dialog ohne große Hürden umsetzen. Beim Erteilen des Rechts Ausführen für eine gespeicherte Prozedur ist der T-SQL-Befehl jedoch eine willkommene Alternative:<\/p>\n Mit dieser SQL-Anweisung erhalten die Mitglieder der Datenbankrolle edb_execute <\/b>das Recht zur Ausführung der gespeicherten Prozedur dbo.pSelectAnsprechpartnerZuMitarbeiter<\/b>. Um das Recht für die zweite gespeicherte Prozedur zu erteilen, kopieren Sie die Zeile und ersetzen dort den Namen. Auf diese Weise ergibt sich nicht nur ein Skript zur Rechtevergabe, sondern auch gleich eine Dokumentation.<\/p>\n Bei einer geringen Anzahl von gespeicherten Prozeduren mag diese Vorgehensweise noch überschaubar sein. Mit steigender Anzahl jedoch wird diese Art der Rechtevergabe schnell aufwendig und fehleranfällig.<\/p>\n Zum Glück geht es noch einfacher. Die Systemsicht sys.procedures <\/b>liefert Ihnen alle gespeicherten Prozeduren der Datenbank. Warum also nicht mit einem kleinen SQL-Skript die Rechte auf einen Schlag vergeben:<\/p>\n Das SQL-Skript ermittelt in der Systemsicht sys.procedures <\/b>nur die benutzerdefinierten gespeicherten Prozeduren. Durch die WHERE<\/b>-Bedingung is_ms_shipped = 0 <\/b>sind die systeminternen gespeicherten Prozeduren im Ergebnis nicht enthalten. Zu jeder ermittelten gespeicherten Prozedur wird eine Zeichenfolge erstellt, die den T-SQL-Befehl zur Rechtevergabe enthält. Letztendlich führt die Systemprozedur sp_execute_sql <\/b>den so erstellten T-SQL-Befehl aus.<\/p>\n Für einen Test dieser Rechtevergabe öffnen Sie im SQL Server Management Studio über die Schaltfläche Neue Abfrage <\/b>eine neue Registerkarte. Achten Sie darauf, dass Sie sich in der Datenbank WaWi_SQL <\/b>befinden. Als nächstes entfernen Sie die eben manuell erteilten Rechte. Hierzu geben Sie die beiden folgenden SQL-Anweisungen in der neuen Registerkarte ein und klicken dann auf die Schaltfläche Ausführen<\/b>.<\/p>\n Die Datenbankrolle edb_execute <\/b>enthält nun keine Rechte mehr zur Ausführung der gespeicherten Prozeduren. Sie können dies im Dialog zur Datenbankrolle prüfen. Auf der Seite Sicherungsfähige Elemente <\/b>sind keine gespeicherten Prozeduren mehr aufgelistet.<\/p>\n Jetzt folgt die Rechtevergabe per T-SQL-Skript. Dazu öffnen Sie über Datei|Öffnen|Datei <\/b>das Skript Rechtevergabe per T-SQL<\/b>. Sie finden das Skript in den Beispieldateien. Starten Sie die Rechtevergabe mit einem Klick auf Ausführen<\/b>.<\/p>\n Anschließend öffnen Sie den Dialog zur Datenbankrolle edb_execute <\/b>erneut. Auf der Seite Sicherungsfähige Elemente <\/b>sehen Sie die beiden gespeicherten Prozeduren mit dem erteilten Recht Ausführen<\/b>.<\/p>\n Mit diesen Rechten erhalten Sie in der Access-Beispielapplikation WaWi <\/b>nun auch die Daten der Pass Through-Abfragen. Wechseln Sie zur Beispielapplikation und klicken Sie im Start<\/b>-Formular auf die Schaltfläche Geburtstagsliste<\/b>. Das Formular zeigt Ihnen die Geburtstage der Mitarbeiter.<\/p>\n Der Fall Bienlein<\/b><\/p>\n Frau Bienlein ist frisch aus dem Urlaub zurück. Eigentlich wollte sie sich direkt an die Arbeit machen. Aber so kurz nach dem Urlaub fehlt ihr doch etwas der Elan und außerdem etwas Geld. So ein Urlaub in Deutschland ist schon teuer. Da wäre eine kleine Gehaltserhöhung nicht schlecht. Also öffnet Sie Ihre eigene Access-Datenbank und klickt auf die eingebundene Tabelle dbo_Mitarbeiter<\/b>. Sie gönnt sich wie beim letzten Mal eine kleine Gehaltserhöhung von 5 Euro und schließt die Tabelle wieder. <\/p>\n Wenn Sie schon mal dabei ist, kann sie sich ja nochmal den Spaß gönnen und die Tabelle Bewerber <\/b>löschen. Das anschließende Gewusel in der IT-Abteilung findet sie einfach zu amüsant. Sie erstellt eine Pass Through-Abfrage mit der SQL-Anweisung DROP TABLE Bewerber<\/b>. Nach einem Klick auf Ausführen wählt Sie die ODBC-Datenquelle WaWi_SQL<\/b>, tippt anschließend das Kennwort ein und klickt auf OK<\/b>. Es folgt die ihr bekannte Fehlermeldung (siehe Bild 17). Aber Moment mal, diese Fehlermeldung kam doch sonst erst bei der zweiten Ausführung der Pass Through-Abfrage<\/p>\n Bild 17: Keine Rechte für Frau Bienlein<\/span><\/b><\/p>\n Neugierig ändert Frau Bienlein die SQL-Anweisung in SELECT * FROM Bewerber <\/b>und klickt erneut auf Ausführen. Nach der Auswahl der OBDC-Datenquelle und der Kennworteingabe sieht sie die Daten der Bewerber. Die Tabelle wurde also nicht gelöscht. „Da ist man mal zwei Wochen nicht da.“ ärgert sich Frau Bienlein. Was solls, dann löscht sie die Tabelle halt nicht. Es geht schließlich auch anders.<\/p>\n Routiniert klickt sie sich durch Externe Daten|Neue Datenquelle|Aus Datenbank|Aus SQL Server <\/b>zum Dialog Externe Daten – ODBC-Datenquelle <\/b>und aktiviert dort die zweite Option. Nach einem Klick auf OK <\/b>wählt Sie die ODBC-Datenquelle WaWi_SQL <\/b>aus.<\/p>\n Es folgt die Aufforderung zur Kennworteingabe, der sie nachkommt, um dann im nächsten Dialog letztendlich die Tabelle dbo_Bewerber <\/b>zu markieren. Bevor sie die Tabelle mit einem Klick auf OK <\/b>einbindet, aktiviert sie noch die Option Kennwort speichern<\/b>. Die Frage, ob das Kennwort gespeichert werden soll, findet sie immer noch drollig. Lächelnd bestätigt sie die Meldung. <\/p>\n Das Navigationsfenster zeigt nun neben der Tabelle dbo_Mitarbeiter <\/b>auch die Tabelle dbo_Bewerber<\/b>. Per Doppelklick öffnet sie die Tabelle in der Datenblattansicht, drückt die Tastenkombination STRG + A <\/b>und anschließend auf die Taste ENTF<\/b>. Die Warnung, dass dadurch die Datensätze der Tabelle gelöscht werden, ignoriert sie mit einem Klick auf Ja<\/b>. Fertig. Geht doch. Die Daten der Tabelle dbo_Bewerber <\/b>sind gelöscht.<\/p>\n Nach diesem Erfolgserlebnis ist sie bereit für etwas Produktives. Oder vielleicht doch nicht. Vorher könnte man ja noch die E-Mails der letzten beiden Wochen lesen. Bereits bei der dritten E-Mail findet Frau Bienlein dies keine gute Idee mehr. Ihr Abteilungsleiter informiert sie über eine Neuverteilung der Regionen. Sie soll nach ihrem Urlaub zusätzlich die Region Bayern betreuen. Ausgerechnet Bayern. Nichts gegen Bayern, immerhin war sie da im Urlaub. Nur gibt es in Bayern viele Kunden mit geringem Umsatz. Das bedeutet viel Arbeit für wenig Lohn.<\/p>\n Die E-Mail informiert sie ebenso über eine neue Funktion in der Auftragsverwaltung. Dort sehen die Sachbearbeiter jetzt nur noch die Ansprechpartner ihrer Kunden. Sie startet die Auftragsverwaltung WaWi <\/b>und öffnet das Formular Ansprechpartner<\/b>. Vor ihr erscheint eine für sie gefühlt endlose Liste.<\/p>\n Wenn sie nur eine gute Ausrede hätte. Wenn diese Liste nur nicht so lang wäre. Wenn man diese Liste ändern könnte. Moment mal, für jemanden, der Inhalte von Tabellen löschen kann, sollte das doch kein Problem sein!<\/p>\n Frau Bienlein wechselt zu ihrer Datenbank und navigiert sich über den bekannten Weg zur Auswahl der Tabellen. Irgendwo muss die regionale Zuordnung der Kunden zu den Mitarbeiten ja gespeichert sein. Sie bemerkt die Tabellen dbo_Regionen <\/b>und dbo_Gebietszuordnungen<\/b>, fühlt sich auf dem richtigen Weg und bindet die beiden Tabellen in ihre Datenbank ein. Als erstes öffnet sie die Tabelle dbo_Gebietszuordnungen<\/b>. Dort sieht sie jedoch nur Zahlen in den Spalten GebietszuordnungenID<\/b>, MitarbeiterID <\/b>und RegionenID <\/b>(siehe Bild 18). <\/p>\n Bild 18: Die Regionen der Sachbearbeiter<\/span><\/b><\/p>\n Ob das eine Zuordnungstabelle ist Frau Bienlein erinnert sich dunkel an ihre Access-Schulung. Da war doch was mit Zuordnungstabellen und Access-Abfragen. Sie erstellt eine neue Abfrage und fügt dieser die Tabellen dbo_Gebietszuordnungen <\/b>und dbo_Mitarbeiter <\/b>hinzu. Sicherheitshalber ergänzt sie die Auswahl noch mit der Tabelle dbo_Regionen<\/b>. Anschließend wählt sie in den Tabellen die Felder MitarbeiterID<\/b>, Nachname<\/b>, RegionenID <\/b>und Region <\/b>aus (siehe Bild 19). Sie klickt auf Ausführen<\/b>. <\/p>\n Bild 19: Frau Bienleins Abfrage<\/span><\/b><\/p>\n Das Ergebnis bestätigt ihre Vermutung. Sie sieht alle Sachbearbeiter mit den zugeordneten Regionen. Frau Bienlein markiert den Eintrag mit ihrem Namen und der Region Bayern <\/b>und drückt die Taste ENTF<\/b>. Die folgende Warnung bestätigt sie mit einem Klick auf Ja<\/b>. Ab jetzt ist sie für die Kunden in Bayern nicht mehr zuständig. Ein kurzer Blick in das Formular Ansprechpartner <\/b>der Applikation WaWi <\/b>liefert ihr den Beweis. Dort sind jetzt nur noch ihre altbewährten Kunden zu sehen (siehe Bild 20).<\/p>\n Bild 20: Frau Bienleins Kunden<\/span><\/b><\/p>\n Sie hatte kurz überlegt, ob sie die Region Bayern nicht einem anderen Sachbearbeiter zuordnen sollte. Aber das würde zu schnell auffallen. So muss sie sich nur ruhig verhalten und abwarten bis die ersten bayrischen Kunden nach dem fehlenden Support fragen.<\/p>\n Wenn sie dann von ihrem Abteilungsleiter darauf angesprochen wird, kann sie sich unbedarft mit ihm zusammen wundern, warum ihr die Region noch nicht zugeteilt wurde. Natürlich ist ihr bewusst, dass sie danach die Region Bayern erneut erhält. Aus diesem Grund speichert Frau Bienlein ihre neue Abfrage. Zum gegebenen Zeitpunkt löscht sie den Eintrag einfach noch einmal.<\/p>\n Fazit und Zusammenfassung<\/b><\/p>\n Ein weiterer Schritt im Zugriffsschutz ist getan. Nachdem beim letzten Mal der Zugang der Anmeldung WaWiMa <\/b>auf die Datenbank begrenzt wurde, gibt es jetzt zusätzliche Einschränkungen in der Datenbank.<\/p>\n Der Benutzer WaWiMa <\/b>ist nicht mehr in der Datenbankrolle db_owner <\/b>enthalten und besitzt somit keine administrativen Rechte mehr. Durch seine Mitgliedschaft in den Datenbankrollen db_datareader <\/b>und db_datawriter <\/b>sind seine Rechte auf das Lesen und Schreiben der Daten begrenzt. Dies ist jedoch nicht genug, denn keine der beiden Datenbankrollen beinhaltet das Recht zum Ausführen von gespeicherten Prozeduren. Die Rechte hierzu erhält der Benutzer WaWiMa <\/b>durch die Mitgliedschaft in der eigens dafür angelegten Datenbankrolle edb_execute<\/b>. <\/p>\n Das Sicherheitsniveau mag sich mit diesen Maßnahmen zwar um einen weiteren Schritt erhöht haben, ausreichend ist es jedoch noch nicht. Die Lese- und Schreibrechte gelten für alle Daten der Datenbank. Frau Bienlein ist weiterhin in der Lage, Daten in den Tabellen direkt zu ändern und zu löschen. Um dies zu verhindern, sind detaillierte und fachbezogene Zugriffsberechtigungen erforderlich. Wie Sie diese Anforderungen mit den Datenbankrollen realisieren, erfahren Sie in der nächsten Ausgabe.<\/p>\n Installationsanleitung für die Beispielumgebung<\/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<\/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<\/p>\n Enthaltene Beispieldateien:<\/p>\n Rechtevergabe per T-SQL.sql<\/p>\n WaWi.accdb<\/p>\n WaWi_SQL.sql<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
CREATE ROLE edb_execute AUTHORIZATION dbo;<\/pre>\n
ALTER ROLE edb_execute ADD MEMBER WaWiMa;<\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnsprechpartnerZuMitarbeiter TO edb_execute;<\/pre>\n
GRANT EXECUTE ON dbo.pSelectAnsprechpartnerZuMitarbeiter TO edb_execute;\r\nGRANT EXECUTE ON dbo.pSelectGeburtstagsliste TO edb_execute;<\/pre>\n
DECLARE @Name AS SYSNAME,\r\n @Sql AS NVARCHAR(1000);\r\nDECLARE curGPs CURSOR FOR\r\n SELECT CONCAT(SCHEMA_NAME(schema_id),'.',[name])\r\n FROM sys.procedures \r\n WHERE is_ms_shipped = 0\r\n FOR READ ONLY;\r\nOPEN curGPs;\r\nFETCH NEXT FROM curGPs INTO @Name;\r\nWHILE @@FETCH_STATUS = 0\r\nBEGIN\r\n SET @Sql = 'GRANT EXECUTE ON ' + @Name + ' TO edb_execute;'\r\n EXEC sp_executesql @Sql;\r\n FETCH NEXT FROM curGPs INTO @Name;\r\nEND\r\nCLOSE curGPs;\r\nDEALLOCATE curGPs;<\/pre>\n
REVOKE EXECUTE ON dbo.pSelectAnsprechpartnerZuMitarbeiter TO edb_execute;\r\nREVOKE EXECUTE ON dbo.pSelectGeburtstagsliste TO edb_execute;<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
\n
\n
\n
\n
\n
\n
Downloads zu diesem Beitrag<\/h3>\n