it-swarm.com.de

Kann SET IDENTITY_INSERT mit weniger Berechtigungen als db_ddladmin zugelassen werden?

Ich habe ein System geerbt, auf dem die Anwendung unter dem Konto sysadmin ausgeführt wird. Ich habe dieses Konto auf db_datareader + db_datawriter + EXECUTE für alle Datenbanken beschränkt und die Sitzung extended events festgelegt, um permission errors auf dem Server abzufangen.
Es war für mich sehr überraschend, dass einige inserts fehlgeschlagen sind, selbst wenn der Benutzer Mitglied von db_datawriter ist und keine detaillierten Einschränkungen für Tabellen angewendet werden.

Dann stelle ich fest, dass nur Einfügungen, die IDENTITY_INSERT setzen, fehlgeschlagen sind. Die betreffende Datenbank ist voll mit identity und der Code enthält zu viel SET IDENTITY_INSERT. Der Code bedeutet nicht nur modules auf dem Server gespeichert, sondern auch C# Code.

Um identity_insert festlegen zu können, muss der Benutzer die Tabelle besitzen oder die Berechtigung ALTER für die Tabelle haben. Tatsache ist jedoch, dass Sie können ALTER NICHT nur für Tabellen gewähren, ich bin gezwungen, ALTER für eine ganze Datenbank diesem user zu gewähren (ich werde diesen Benutzer zum Mitglied von db_ddladmin machen Rolle, die nur 42 Berechtigungen (!!!) vs 51 Berechtigungen hinzufügt, die zu Benutzerberechtigungen hinzugefügt werden können, indem ALTER für die Datenbank erteilt wird)

Ich bin nicht daran interessiert, die Datenbank mit sequence umzugestalten (Serverversion ist 2014, damit ich es theoretisch tun kann), und ich kann nicht einfach execute as dbo zu jedem SP hinzufügen, der identity_insert verwendet, weil es gibt Ich frage mich nur, warum Microsoft ein so seltsames Berechtigungsdesign erstellt, dass db_datawriteridentity_insert nicht festlegen kann.

Gibt es eine andere Möglichkeit, den Benutzer in die Lage zu versetzen, identity_insert festzulegen, die weniger Berechtigungen als db_ddladmin hinzufügt?


AKTUALISIEREN

Ich habe die von LowlyDBA mit synonyms angebotene Lösung ausprobiert:

create table dbo.t(id int identity);
go

alter schema sch transfer dbo.t;
go

create synonym dbo.t for sch.t;
go

set IDENTITY_INSERT dbo.t on;

Dies verursacht den Fehler

Meldung 1088, Ebene 16, Status 11, Zeile 1 Das Objekt "dbo.t" kann nicht gefunden werden, da es nicht vorhanden ist oder Sie keine Berechtigungen haben.

(enter image description here


Die Lösung von Antoine Hernandez, um dem Benutzer ALTER nur auf Schema zu gewähren, scheint weniger böse zu sein, also akzeptiere ich es

4
sepupic

Ich schlage vor, dass Sie eine benutzerdefinierte Datenbankrolle erstellen, indem Sie mit der rechten Maustaste auf den Datenbankrollenordner klicken.

enter image description here

Daraufhin wird die Datenbankrolle angezeigt, die Sie dann anpassen können. Auf dem ersten Bildschirm können Sie der Rolle den Namen und den Eigentümer Ihrer Wahl geben. Sie können auch den Benutzer hinzufügen, der Mitglied dieser Rolle sein soll. enter image description here

Sobald dies erledigt ist, können Sie auf Securables klicken, um auszuwählen, was gewährt werden soll. enter image description here

Objekte hinzufügen wird angezeigt und ich schlage vor, die Option "Alle Objekte des Typs ..." auszuwählen und auf "OK" zu klicken. enter image description here

Scrollen Sie unter Objekttypen auswählen nach unten, um Schemas zu finden, aktivieren Sie das Kontrollkästchen und klicken Sie dann auf OK. enter image description here

Jetzt wird eine Liste der Schemas angezeigt. Wählen Sie daher die Schemas aus, die die Objekte enthalten, denen Sie Berechtigungen erteilen möchten, und zeigen Sie die Berechtigungen für dieses Schema unten an. enter image description here

In diesem Beispiel habe ich das dbo-Schema gewählt. Ich habe die Größe des Standardbildschirms geändert, um mehr auf einmal anzuzeigen. enter image description here

In diesem Fall würde ich höchstwahrscheinlich Alter gewähren, weil laut Microsoft "ALTER, wenn es für einen Bereich gewährt wird, auch die Möglichkeit bietet, Änderungen vorzunehmen, zu erstellen oder zu löschen (Hervorhebung meiner) alle in diesem Bereich enthaltenen Sicherungen . " Basierend auf der Infografik zu Datenbankberechtigungen, die sich befindet hier und unten Wenn Sie "Änderung am Schema" gewähren, wird "Änderung für Aggregat", "Standard", "Funktion", "Prozedur", "Warteschlange", "Regel", "Synonym", "Tabelle" und "Ansicht" gewährt: Microsoft link https://aka.ms/sql-permissions-poster Da ich mich zu diesem Zeitpunkt für dieselbe Rolle befinde, würde ich wahrscheinlich auch Execute gewähren, damit das Rollenmitglied auch jede gespeicherte Prozedur ausführen kann. Wenn also neue Tabellen oder gespeicherte Prozeduren zur Datenbank hinzugefügt werden, würde ich dies tun Sie müssen keine Sicherheit ändern, damit die neuen Objekte wie die vorhandenen Objekte funktionieren. Die Auswahl würde also nach Abschluss folgendermaßen aussehen: enter image description here

Ich hätte noch einen Schritt weiter gehen und auch Auswählen, Einfügen, Aktualisieren und Löschen gewähren können, und es hätte höchstwahrscheinlich alles abgedeckt, was die Rolle zum Lesen, Einfügen, Löschen und Aktualisieren einer Tabelle sowie zum Ausführen einer gespeicherten Prozedur erfordern würde ohne alle anderen Berechtigungen erteilen zu müssen, die die Rolle db_ddladmin gewährt. Auf diese Weise auf Schemaebene kann die Sicherheitsverwaltung in gewisser Weise vereinfacht werden, insbesondere wenn ein bestimmter Benutzer viele, wenn nicht alle Zugriffe auf Schemaebene benötigt, aber auch die Anforderung erfüllt, keine Änderungen am Ganzen zu gewähren Datenbank. Wenn diese Konfiguration andere Berechtigungen enthält, die die Rolle nicht benötigt, können Sie bei Bedarf DENY-Berechtigungen hinzufügen.

6