Berechtigungen (Datenbankmodul)

Benennungskonventionen für Berechtigungen

Im Folgenden werden die allgemeinen Konventionen beschrieben, die beim Benennen von Berechtigungen befolgt werden:

• CONTROL

  Überträgt besitzähnliche Funktionen an den Empfänger. Der Empfänger verfügt über alle definierten Berechtigungen für das sicherungsfähige Element. Ein Prinzipal, dem die Berechtigung CONTROL erteilt wurde, kann auch Berechtigungen für das sicherungsfähige Element erteilen. Da es sich bei dem SQL Server-Sicherheitsmodell um ein hierarchisches Modell handelt, beinhaltet CONTROL für einen bestimmten Gültigkeitsbereich implizit auch CONTROL für alle sicherungsfähigen Elemente in diesem Gültigkeitsbereich. CONTROL für eine Datenbank impliziert alle Berechtigungen für die Datenbank, alle Berechtigungen für alle Assemblys in der Datenbank, alle Berechtigungen für alle Schemas in der Datenbank sowie alle Berechtigungen für Objekte innerhalb aller Schemas in der Datenbank.

• ALTER

  Überträgt die Berechtigung, die Eigenschaften, mit Ausnahme des Besitzes, eines bestimmten sicherungsfähigen Elements zu ändern. Wenn ALTER für einen Gültigkeitsbereich erteilt wird, wird damit auch die Berechtigung zum Ändern, Erstellen oder Löschen eines sicherungsfähigen Elements erteilt, das in diesen Bereich fällt. So beinhaltet die Berechtigung ALTER für ein Schema auch die Berechtigung zum Erstellen, Ändern und Löschen von Objekten aus dem Schema.

• ALTER ANY <Server Securable>, wobei Server Securable ein beliebiges sicherungsfähiges Element auf Serverebene sein kann.

  Überträgt die Berechtigung zum Erstellen, Ändern oder Löschen einzelner Instanzen des Server Securable. So überträgt z. B. ALTER ANY LOGIN die Berechtigung zum Erstellen, Ändern oder Löschen einer beliebigen Anmeldung in der Instanz.

• ALTER ANY <Database Securable>, wobei Database Securable ein beliebiges sicherungsfähiges Element auf Datenbankebene sein kann.

  Überträgt die Berechtigung zum Erstellen, Ändern oder Löschen (CREATE, ALTER oder DROP) einzelner Instanzen des Database Securable. So überträgt z. B. ALTER ANY SCHEMA die Berechtigung zum Erstellen, Ändern oder Löschen eines beliebigen Schemas in der Datenbank.

• TAKE OWNERSHIP

  Ermöglicht dem Empfänger, Besitzer des sicherungsfähigen Elements zu werden, für das die Berechtigung erteilt wird.

• IMPERSONATE <Login>

  Ermöglicht dem Empfänger, die Identität des Anmeldenamens anzunehmen.

• IMPERSONATE <User>

  Ermöglicht dem Empfänger, die Identität des Benutzers anzunehmen.

• CREATE <Server Securable>

  Überträgt dem Empfänger die Berechtigung zum Erstellen des Server Securable.

• CREATE <Database Securable>

  Überträgt dem Empfänger die Berechtigung zum Erstellen des Database Securable.

• CREATE <Schema-contained Securable>

  Überträgt die Berechtigung zum Erstellen des im Schema enthaltenen sicherungsfähigen Elements. Es wird jedoch die Berechtigung ALTER für das Schema benötigt, um das sicherungsfähige Element in einem bestimmten Schema zu erstellen.

• VIEW DEFINITION

  Gewährt dem Empfänger Zugriff auf Metadaten.

• REFERENCES

  Die REFERENCES-Berechtigung für eine Tabelle ist erforderlich, um eine FOREIGN KEY-Einschränkung zu erstellen, die auf die betreffende Tabelle verweist.

  Die REFERENCES-Berechtigung ist für ein Objekt erforderlich, um eine FUNCTION oder VIEW mit der WITH SCHEMABINDING-Klausel zu erstellen, die auf das betreffende Objekt verweist.

Übersicht über SQL Server-Berechtigungen

Eine Übersicht aller Database Engine (Datenbankmodul)-Berechtigungen im PDF-Posterformat finden Sie unter https://go.microsoft.com/fwlink/?LinkId=229142.

Berechtigungen für bestimmte sicherungsfähige Elemente

Die folgende Tabelle enthält eine Liste der wichtigsten Berechtigungsklassen und der sicherungsfähigen Elemente, für die sie erteilt werden können.

SQL Server-Berechtigungen

Die folgende Tabelle enthält eine vollständige Liste der SQL Server-Berechtigungen.

Zusammenfassung des Algorithmus zur Berechtigungsprüfung

Die Prüfung von Berechtigungen kann sehr komplex sein. Der Algorithmus für die Berechtigungsprüfung umfasst überlappende Gruppenmitgliedschaften und Besitzverkettung, explizite und implizite Berechtigungen und kann von den Berechtigungen für sicherungsfähige Klassen, in denen die sicherungsfähige Entität enthalten ist, beeinflusst werden. Die allgemeine Vorgehensweise des Algorithmus besteht darin, alle relevanten Berechtigungen zu sammeln. Wenn keine blockierende DENY-Anweisung gefunden wird, sucht der Algorithmus nach einer GRANT-Anweisung mit ausreichenden Zugriffsberechtigungen. Der Algorithmus enthält drei wesentliche Elemente, den Sicherheitskontext, den Berechtigungsbereich und die erforderliche Berechtigung.

Hinweis
Berechtigungen können nicht für sa, dbo, den Entitäts-Besitzer, information_schema, sys oder für den Benutzer selbst erteilt, verweigert oder aufgehoben werden.

• Sicherheitskontext

  Dies ist die Gruppe von Prinzipalen, die Berechtigungen für die Zugriffsüberprüfung einbringen. Diese Berechtigungen beziehen sich auf den aktuellen Anmeldenamen oder Benutzer, es sei denn, der Sicherheitskontext wurde mithilfe der EXECUTE AS-Anweisung in einen anderen Anmeldenamen oder Benutzer geändert. Der Sicherheitskontext schließt die folgenden Prinzipale ein:

  • Anmeldenamen

  • Benutzer

  • Rollenmitgliedschaften

  • Windows-Gruppenmitgliedschaften

  • Bei Verwendung der Modulsignierung sind dies ein beliebiger Anmeldename oder ein beliebiges Benutzerkonto für das Zertifikat, das zum Signieren des vom Benutzer derzeit ausgeführten Moduls verwendet wird, und die zugehörigen Rollenmitgliedschaften dieses Prinzipals.

• Berechtigungsbereich

  Dies sind die sicherungsfähige Entität und alle sicherungsfähigen Klassen, in denen das sicherungsfähige Element enthalten ist. Eine Tabelle (eine sicherungsfähige Entität) ist z. B. in der sicherungsfähigen Klasse des Schemas und in der sicherungsfähigen Klasse der Datenbank enthalten. Berechtigungen auf Tabellen-, Schema-, Datenbank- und Serverebene können sich auf den Zugriff auswirken. Weitere Informationen finden Sie unter Berechtigungshierarchie (Datenbankmodul).

• Erforderliche Berechtigung

  Die Art der erforderlichen Berechtigung. Beispielsweise INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL usw.

  Für den Zugriff können wie in den folgenden Beispielen mehrere Berechtigungen erforderlich sein:

  • Eine gespeicherte Prozedur kann sowohl die EXECUTE-Berechtigung für die gespeicherte Prozedur als auch die INSERT-Berechtigung für mehrere Tabellen erfordern, auf die von der gespeicherten Prozedur verwiesen wird.

  • Eine dynamische Verwaltungssicht kann sowohl die VIEW SERVER STATE-Berechtigung als auch SELECT-Berechtigung für die Sicht erfordern.

Allgemeine Schritte des Algorithmus

Beispiele

In den folgenden Beispielen wird veranschaulicht, wie Sie Berechtigungsinformationen abgerufen werden.

A. Zurückgeben der vollständigen Liste erteilbarer Berechtigungen

SELECT * FROM fn_builtin_permissions(default);
GO

B. Zurückgeben der Berechtigungen für eine bestimmte Objektklasse

SELECT * FROM fn_builtin_permissions('assembly');
GO  

C. Zurückgeben der Berechtigungen, die dem ausführenden Prinzipal für ein Objekt erteilt wurden

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D. Zurückgeben von Berechtigungen, die auf ein angegebenes Objekt angewendet werden können

SELECT * FROM sys.database_permissions 
    WHERE major_id = OBJECT_ID('Yttrium');
GO

Siehe auch

Verweis

Konzepte