Berechtigungen (Datenbankmodul)

Jeder sicherungsfähige SQL Server verfügt über zugeordnete Berechtigungen, die einem Prinzipal erteilt werden können. Dieses Thema enthält die folgenden Informationen:

• Benennungskonventionen für Berechtigungen

• Berechtigungen im Zusammenhang mit bestimmten Sicherungsobjekten

• SQL Server-Berechtigungen

• Berechtigungsüberprüfungsalgorithmus

• Beispiele

Benennungskonventionen für Berechtigungen

Im Folgenden werden die allgemeinen Konventionen beschrieben, die für Benennungsberechtigungen befolgt werden:

• Kontrolle

  Räumt dem Grantee eigentumsähnliche Funktionen ein. Der Berechtigungsempfänger verfügt effektiv über alle definierten Berechtigungen auf dem sicherbaren Objekt. Ein Prinzipal, dem Kontrolle gewährt wurde, kann auch Berechtigungen für das sicherbare Objekt erteilen. Da das SQL Server-Sicherheitsmodell hierarchisch ist, enthält CONTROL in einem bestimmten Bereich implizit CONTROL für alle sicherungsfähigen Elemente unter diesem Bereich. Beispielsweise impliziert CONTROL für eine Datenbank alle Berechtigungen für die Datenbank, alle Berechtigungen für alle Assemblys in der Datenbank, alle Berechtigungen für alle Schemas in der Datenbank und alle Berechtigungen für Objekte innerhalb aller Schemas innerhalb der Datenbank.

• ÄNDERN

  Ermöglicht die Änderung der Eigenschaften, mit Ausnahme der Besitzrechte, eines bestimmten sicherbaren Objekts. Wenn es auf einen Bereich angewendet wird, ermöglicht ALTER zudem das Ändern, Erstellen oder Löschen eines Sicherheitsobjekts, das in diesem Bereich enthalten ist. Die ALTER-Berechtigung für ein Schema umfasst beispielsweise die Möglichkeit zum Erstellen, Ändern und Ablegen von Objekten aus dem Schema.

• ALTER ANY <Server Securable>, wobei Server securable kann jeder Server sicherungsfähig sein.

  Ermöglicht das Erstellen, Ändern oder Ablegen einzelner Instanzen des Servers Securable. BEISPIELSWEISE ermöglicht ALTER ANY LOGIN das Erstellen, Ändern oder Ablegen von Anmeldungen in der Instanz.

• ALTER ANY <Database Securable>, wobei Database Securable jedes sicherbare Objekt auf Datenbankebene sein kann.

  Ermöglicht das ERSTELLEN, ALTER oder DROP einzelne Instanzen der Datenbank securable. Beispielsweise ermöglicht ALTER ANY SCHEMA das Erstellen, Ändern oder Ablegen eines Schemas in der Datenbank.

• VERANTWORTUNG ÜBERNEHMEN

  Ermöglicht es dem Begünstigten, das Sicherungselement zu übernehmen, auf das das Recht gewährt wird.

• < Nachahmen>

  Ermöglicht es dem Grantee, die Identität der Anmeldung zu imitieren.

• Benutzer imitieren <>

  Ermöglicht es dem Grantee, die Identität des Benutzers zu imitieren.

• CREATE <Server securable>

  Verleiht dem Grantee die Möglichkeit, den Server securable zu erstellen.

• CREATE-Datenbank <sicherungsfähig>

  Erteilt dem Grantee die Möglichkeit, die Datenbank sicherungsfähig zu erstellen.

• CREATE <Schema-enthaltene sichere Elemente>

  Ermöglicht die Erstellung der schemabasierten Sicherungsfähigkeit. Die ALTER-Berechtigung für das Schema ist jedoch erforderlich, um die sicherungsfähige Datei in einem bestimmten Schema zu erstellen.

• VIEW DEFINITION

  Ermöglicht dem Grantee den Zugriff auf Metadaten.

• REFERENZEN

  Die REFERENCES-Berechtigung für eine Tabelle ist erforderlich, um eine FOREIGN KEY-Einschränkung zu erstellen, die auf diese 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 dieses Objekt verweist.

Diagramm der SQL Server-Berechtigungen

Ein Poster-Diagramm mit allen Berechtigungen des Datenbankmoduls im PDF-Format finden Sie unter https://github.com/microsoft/sql-server-samples/blob/master/samples/features/security/permissions-posters/Microsoft_SQL_Server_2017_and_Azure_SQL_Database_permissions_infographic.pdf.

Berechtigungen, die für bestimmte Sicherungswerte gelten

In der folgenden Tabelle sind die wichtigsten Berechtigungsklassen und die Arten von Sicherungswerten aufgeführt, auf die sie angewendet werden können.

SQL Server- und SQL-Datenbankberechtigungen

Die folgende Tabelle enthält eine vollständige Liste der SQL Server-Berechtigungen. SQL-Datenbankberechtigungen sind nur für Basissicherheiten verfügbar, die unterstützt werden. Berechtigungen auf Serverebene können in der SQL-Datenbank nicht erteilt werden, in einigen Fällen sind jedoch stattdessen Datenbankberechtigungen verfügbar.

Zusammenfassung des Berechtigungsprüfungsalgorithmus

Das Überprüfen von Berechtigungen kann komplex sein. Der Berechtigungsüberprüfungsalgorithmus umfasst überlappende Gruppenmitgliedschaften und Besitzverkettung, sowohl explizite als auch implizite Berechtigungen und kann von den Berechtigungen für sicherungsfähige Klassen betroffen sein, die die sicherungsfähige Entität enthalten. Der allgemeine Prozess des Algorithmus besteht darin, alle relevanten Berechtigungen zu sammeln. Wird kein blockierendes DENY gefunden, sucht der Algorithmus nach einem GRANT, das hinreichenden Zugriff ermöglicht. Der Algorithmus enthält drei wesentliche Elemente, den Sicherheitskontext, den Berechtigungsbereich und die erforderliche Berechtigung.

• Sicherheitskontext

  Dies ist die Gruppe der Hauptakteure, die Berechtigungen für die Zugriffskontrolle gewähren. Dies sind Berechtigungen, die sich auf die aktuelle Anmeldung oder den aktuellen Benutzer beziehen, es sei denn, der Sicherheitskontext wurde mithilfe der EXECUTE AS Anweisung in einen anderen Anmelde- oder Benutzer geändert. Der Sicherheitskontext enthält die folgenden Prinzipale:

  • Die Anmeldung

  • Der Benutzer

  • Rollenmitgliedschaften

  • Windows-Gruppenmitgliedschaften

  • Wenn die Modulsignierung verwendet wird, wird jedes Anmelde- oder Benutzerkonto für das Zertifikat verwendet, mit dem das Modul signiert wird, das der Benutzer gerade ausführt, und die zugehörigen Rollenmitgliedschaften dieses Prinzipals.

• Berechtigungsraum

  Dies ist die sicherungsfähige Entität und alle sicherungsfähigen Klassen, die die sicherungsfähige Entität enthalten. Eine Tabelle (eine sicherungsfähige Entität) ist z. B. in der sicherungsfähigen Schemaklasse und in der sicherungsfähigen Datenbankklasse enthalten. Der Zugriff kann durch Berechtigungen auf Tabellen-, Schema-, Datenbank- und Serverebene beeinflusst werden. Weitere Informationen finden Sie unter Berechtigungshierarchie (Datenbankmodul).

• Erforderliche Berechtigung

  Die Art der erforderlichen Berechtigung. Zum Beispiel INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL und so weiter.

  Access kann mehrere Berechtigungen erfordern, wie in den folgenden Beispielen gezeigt:

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

  • Eine dynamische Verwaltungsansicht kann sowohl VIEW SERVER STATE- als auch SELECT-Berechtigung für diese Ansicht erfordern.

Allgemeine Schritte des Algorithmus

Wenn der Algorithmus bestimmt, ob der Zugriff auf eine sicherungsfähige Person zugelassen werden soll, können die genauen Schritte variieren, die sie verwendet, je nach den Prinzipalen und den sicherungsfähigen Daten, die beteiligt sind. Der Algorithmus führt jedoch die folgenden allgemeinen Schritte aus:

1. Umgehen Sie die Berechtigungsprüfung, ob die Anmeldung Mitglied der festen Serverrolle "sysadmin" ist oder ob der Benutzer der dbo-Benutzer in der aktuellen Datenbank ist.

2. Zugriff zulassen, wenn die Besitzkette anwendbar ist und die Zugriffsüberprüfung des Objekts weiter oben in der Kette die Sicherheitsüberprüfung bestanden hat.

3. Aggregieren Sie die Identitäten auf Serverebene, Datenbankebene und signiertes Modul, die dem Aufrufer zugeordnet sind, um den Sicherheitskontext zu erstellen.

4. Sammeln Sie für diesen Sicherheitskontext alle Berechtigungen, die für den Berechtigungsbereich erteilt oder verweigert werden. Die Berechtigung kann explizit als GRANT, GRANT MIT GRANT oder DENY angegeben werden; oder die Berechtigungen können eine stillschweigende oder übergreifende Berechtigung GRANT oder DENY sein. Beispielsweise impliziert die CONTROL-Berechtigung für ein Schema CONTROL über eine Tabelle. Und CONTROL in einer Tabelle impliziert SELECT. Wenn also CONTROL für das Schema gewährt wurde, wird SELECT in der Tabelle gewährt. Wenn CONTROL auf der Tabelle verweigert wird, wird SELECT auf der Tabelle ebenfalls verweigert.

   Hinweis

   Ein GRANT einer Berechtigung auf Spaltenebene setzt ein DENY auf Objektebene außer Kraft.

5. Identifizieren Sie die erforderliche Berechtigung.

6. Schlägt die Berechtigungsprüfung fehl, wenn die erforderliche Berechtigung direkt oder implizit einer der Identitäten im Sicherheitskontext für die Objekte im Berechtigungsbereich verweigert wird.

7. Übergeben Sie die Berechtigungsprüfung, ob die erforderliche Berechtigung nicht verweigert wurde, und die erforderliche Berechtigung enthält eine GRANT oder eine GRANT WITH-Berechtigung GRANT entweder direkt oder implizit an eine der Identitäten im Sicherheitskontext für jedes Objekt im Berechtigungsbereich.

Beispiele

Die Beispiele in diesem Abschnitt zeigen, wie Sie Berechtigungsinformationen abrufen.

Ein. Zurückgeben der vollständigen Liste der zulässigen Berechtigungen

Die folgende Anweisung gibt alle Berechtigungen des Datenbankmoduls mithilfe der fn_builtin_permissions Funktion zurück. Weitere Informationen finden Sie unter sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);  
GO  

B. Zurückgeben der Berechtigungen für eine bestimmte Klasse von Objekten

Im folgenden Beispiel werden fn_builtin_permissions alle Berechtigungen angezeigt, die für eine Kategorie von sicherbaren Objekten verfügbar sind. Das Beispiel gibt Berechtigungen für Assemblys zurück.

SELECT * FROM fn_builtin_permissions('assembly');  
GO    

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

Im folgenden Beispiel wird fn_my_permissions eine Liste der effektiven Berechtigungen zurückgegeben, die vom aufrufenden Prinzipal für ein angegebenes sicherungsfähiges Objekt gehalten werden. Das Beispiel gibt Berechtigungen für ein Objekt mit dem Namen Orders55zurück. Weitere Informationen finden Sie unter sys.fn_my_permissions (Transact-SQL).

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

D. Zurückgeben der berechtigungen, die für ein angegebenes Objekt gelten

Im folgenden Beispiel werden Berechtigungen zurückgegeben, die für ein Objekt gelten, das aufgerufen wird Yttrium. Beachten Sie, dass die integrierte Funktion OBJECT_ID verwendet wird, um die ID des Objekts Yttriumabzurufen.

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

Siehe auch

Berechtigungshierarchie (Datenbank-Engine)
sys.database_permissions (Transact-SQL)