Berechtigungen (Datenbank-Engine)

Geltend für:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL analytics endpoint in Microsoft FabricWarehouse in Microsoft FabricSQL database in Microsoft Fabric

Jedem sicherungsfähigen SQL Server-Element werden Berechtigungen zugeordnet, die einem Prinzipal erteilt werden können. Datenbank-Engine-Berechtigungen im Datenbankmodul werden sowohl auf dem Serverlevel, das den Anmeldeinformationen und Serverrollen zugewiesen ist, als auch auf dem Datenbanklevel verwaltet, das den Datenbankbenutzer und Datenbankrollen zugewiesen ist. Das Model für Azure SQL-Datenbank wendet dieses System auch auf die Datenbankberechtigungen an. Die Berechtigungen auf Serverebene sind jedoch nicht verfügbar. Dieser Artikel bietet eine vollständige Liste der Berechtigungen. Eine typische Implementierung der Berechtigungen finden Sie unter "Erste Schritte mit Datenbankmodulberechtigungen".

Die Gesamtzahl der Berechtigungen für SQL Server 2022 (16.x) beträgt 292. Azure SQL-Datenbank macht 292 Berechtigungen verfügbar. Die meisten Berechtigungen – jedoch nicht alle – gelten für alle Plattformen. Zum Beispiel können in Azure SQL-Datenbank die meisten Berechtigungen auf Serverebene nicht erteilt werden, und einige Berechtigungen sind nur für Azure SQL-Datenbank sinnvoll. Neue Berechtigungen werden nach und nach in neuen Releases eingeführt. SQL Server 2019 (15.x) macht 248 Berechtigungen verfügbar. SQL Server 2017 (14.x) hat 238 Berechtigungen verfügbar gemacht. SQL Server 2016 (13.x) hat 230 Berechtigungen verfügbar gemacht. SQL Server 2014 (12.x) hat 219 Berechtigungen verfügbar gemacht. SQL Server 2012 (11.x) hat 214 Berechtigungen verfügbar gemacht. SQL Server 2008 R2 (10.50.x) hat 195 Berechtigungen verfügbar gemacht. In dem Artikel sys.fn_builtin_permissions wird erläutert, welche Berechtigungen in aktuellen Versionen jeweils neu sind.

In der SQL-Datenbank in Microsoft Fabric werden nur Benutzer und Rollen auf Datenbankebene unterstützt. Anmeldeinformationen, Rollen und das sa Konto auf Serverebene sind nicht verfügbar. In SQL-Datenbanken in Microsoft Fabric ist Microsoft Entra ID für Datenbankbenutzer die einzige unterstützte Authentifizierungsmethode. Weitere Informationen finden Sie unter Autorisierung in der SQL-Datenbank in Microsoft Fabric.

Sobald Sie sich mit den erforderlichen Berechtigungen vertraut gemacht haben, können Sie die Anweisungen GRANT, REVOKE und DENY verwenden, um Berechtigungen auf Serverebene auf Anmeldungen oder Serverrollen und Berechtigungen auf Datenbankebene auf Benutzer oder Datenbankrollen anzuwenden. Zum Beispiel:

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

Tipps zum Planen eines Berechtigungssystems finden Sie unter "Erste Schritte mit Datenbankmodulberechtigungen".

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 Server Securable 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 es sich bei Database Securable um jedes beliebige sicherungsfähige Element auf Datenbankebene handeln 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.

• VERANTWORTUNG ÜBERNEHMEN

  Ermöglicht es dem Berechtigten, das Eigentum an dem verbrieften Gerät zu übernehmen, für das die Berechtigung erteilt wurde.

• 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 Absicherbar>

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

• CREATE <Sicherbare Datenbank>

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

• CREATE <Schema-enthaltene sichere Elemente>

  Ü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.

• REFERENZEN

  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.

Diagramm der SQL Server-Berechtigungen

Das folgende Bild zeigt die Berechtigungen und ihre Beziehungen zueinander. Einige der Berechtigungen auf höherer Ebene (z.B. CONTROL SERVER) sind mehrmals aufgeführt. In diesem Artikel ist nicht ausreichend Platz, um das Poster entsprechend darzustellen. Sie können das Poster zu den Datenbank-Engine-Berechtigungen im PDF-Format in voller Größe herunterladen.

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. Azure SQL-Datenbank-Berechtigungen sind nur für unterstützte sicherungsfähige Basiselemente verfügbar. Berechtigungen auf Serverebene können in Azure SQL-Datenbank nicht gewährt werden, in einigen Fällen sind jedoch stattdessen Datenbankberechtigungen verfügbar.

Neue granulare Berechtigungen, die SQL Server 2022 hinzugefügt wurden

Die folgenden Berechtigungen werden SQL Server 2022 hinzugefügt:

• 10 neue Berechtigungen wurden hinzugefügt, um den Zugriff auf Systemmetadaten zu ermöglichen.

• Für erweiterte Ereignisse wurden 18 neue Berechtigungen hinzugefügt.

• 9 neue Berechtigungen wurden in Bezug auf sicherheitsbezogene Objekte hinzugefügt.

• 4 Berechtigungen wurden für Ledger hinzugefügt.

• 3 zusätzliche Datenbankberechtigungen.

Weitere Informationen finden Sie unter Neue granulare Berechtigungen für SQL Server 2022 und Azure SQL, um die Einhaltung von PoLP zu verbessern.

Zugriff auf Berechtigungen für Systemmetadaten

Serverebene:

• ANZEIGEN EINER SICHERHEITSDEFINITION
• ANZEIGEN EINER BELIEBIGEN LEISTUNGSDEFINITION
• SICHERHEITSSTATUS DES SERVERS ANZEIGEN
• SERVERLEISTUNGSSTATUS ANZEIGEN
• ANZEIGEN EINER KRYPTOGRAFISCH GESICHERTEN DEFINITION

Datenbankebene:

• DATENBANKSICHERHEITSSTATUS ANZEIGEN
• DATENBANKLEISTUNGSSTATUS ANZEIGEN
• SICHERHEITSDEFINITION ANZEIGEN
• LEISTUNGSDEFINITION ANZEIGEN
• KRYPTOGRAFISCH GESICHERTE DEFINITION ANZEIGEN

Berechtigungen für erweiterte Ereignisse

Serverebene:

• CREATE ANY EVENT SESSION
• DROP ANY EVENT SESSION
• ALTER ANY EVENT SESSION OPTION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ALTER ANY EVENT SESSION ENABLE
• ALTER ANY EVENT SESSION DISABLE
• ALTER ANY EVENT SESSION ADD TARGET
• ALTER ANY EVENT SESSION DROP TARGET

Alle diese Berechtigungen unterliegen der gleichen übergeordneten Berechtigung: ALTER ANY EVENT SESSION

Datenbankebene:

• CREATE ANY DATABASE EVENT SESSION
• DROP ANY DATABASE EVENT SESSION
• ALTER ANY DATABASE EVENT SESSION OPTION
• ALTER ANY DATABASE EVENT SESSION ADD EVENT
• ALTER ANY DATABASE EVENT SESSION DROP EVENT
• ALTER ANY DATABASE EVENT SESSION ENABLE
• ALTER ANY DATABASE EVENT SESSION DISABLE
• ALTER ANY DATABASE EVENT SESSION ADD TARGET
• ALTER ANY DATABASE EVENT SESSION DROP TARGET

Alle diese Berechtigungen unterliegen der gleichen übergeordneten Berechtigung: ALTER ANY DATABASE EVENT SESSION

Sicherheitsbezogene Objektberechtigungen

• CONTROL (CREDENTIAL)
• LOGIN ERSTELLEN
• BENUTZER ERSTELLEN
• REFERENCES (CREDENTIAL)
• UNMASK (OBJECT)
• UNMASK (SCHEMA)
• ANZEIGEN EINES FEHLERPROTOKOLLS
• VIEW SERVER SECURITY AUDIT
• DATENBANKSICHERHEITSÜBERWACHUNG ANZEIGEN

Ledger-Berechtigungen

• ALTER LEDGER
• ALTER LEDGER CONFIGURATION
• LEDGER AKTIVIEREN
• VIEW LEDGER CONTENT

Andere Berechtigungen für Datenbank

• ÄNDERN EINES EXTERNEN AUFTRAGS
• ALTER ANY EXTERNAL STREAM
• EXECUTE ANY EXTERNAL ENDPOINT

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 Berechtigungsbereichund die erforderlichen Berechtigung.

• 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

  • Der 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 (Datenbank-Engine).

• erforderlichen 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

Wenn der Algorithmus ermittelt, ob Zugriff auf das sicherungsfähige Element erteilt werden soll, können die in diesem Zusammenhang ausgeführten Schritte sehr unterschiedlich sein. Dies hängt von den jeweiligen Prinzipalen und sicherungsfähigen Elementen ab. Der Algorithmus führt jedoch die folgenden allgemeinen Schritte aus:

1. Umgehen der Berechtigungsprüfung, wenn der Anmeldename ein Mitglied der festen Serverrolle sysadmin oder der Benutzer der dbo-Benutzer der aktuellen Datenbank ist.

2. Erteilen des Zugriffs, wenn die Besitzverkettung anwendbar ist und die Zugriffsprüfung für das Objekt an früherer Stelle in der Kette die Sicherheitsprüfung erfolgreich war.

3. Aggregieren der Identitäten, die dem Aufrufer zum Erstellen des Sicherheitskontexts zugeordnet sind, auf Server- und Datenbankebene sowie auf Ebene des signierten Moduls.

4. Sammeln aller Berechtigungen, die für diesen Berechtigungsbereicherteilt oder verweigert wurden, in diesem Sicherheitskontext. Die Berechtigung kann explizit als GRANT, GRANT WITH GRANT oder DENY angegeben werden; oder die Berechtigungen können als implizite oder abdeckende GRANT-Berechtigung oder DENY-Berechtigung angegeben werden. Die CONTROL-Berechtigung für ein Schema impliziert z. B. CONTROL für eine Tabelle. CONTROL für eine Tabelle impliziert SELECT. Wenn CONTROL für das Schema erteilt wurde, wird folglich SELECT für die Tabelle erteilt. Wenn CONTROL für die Tabelle verweigert wurde, wird SELECT für die Tabelle verweigert.

   Hinweis

   Durch eine GRANT-Berechtigung auf Spaltenebene wird eine DENY-Berechtigung auf Objektebene überschrieben. Weitere Informationen finden Sie unter DENY-Objektberechtigungen.

5. Identifizieren Sie die erforderlichen Berechtigung.

6. Die Berechtigungsprüfung ist nicht bestanden, wenn die erforderlichen Berechtigung für eine der Identitäten im Sicherheitskontext der Objekte im Berechtigungsbereich direkt oder implizit verweigert werden.

7. Die Berechtigungsprüfung ist bestanden, wenn die erforderlichen Berechtigung nicht verweigert wurde, und die erforderlichen Berechtigung für eine der Identitäten im Sicherheitskontext eines beliebigen Objekts im Berechtigungsbereichdirekt oder implizit eine GRANT-Berechtigung oder GRANT WITH GRANT-Berechtigung enthält.

Spezielle Aspekte für Berechtigungen auf Spaltenebene

Berechtigungen auf Spaltenebene werden mit der Syntax <Tabellenname>(<Spaltenname>) erteilt. Zum Beispiel:

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

Ein DENY auf der Tabelle wird mit einem GRANT auf einer Spalte überschrieben. Ein nachfolgendes DENY auf der Tabelle entfernt jedoch das GRANT auf der Spalte.

Beispiele

In den Beispielen dieses Abschnitts wird veranschaulicht, wie Berechtigungsinformationen abgerufen werden.

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

Die folgende Anweisung gibt mithilfe der fn_builtin_permissions-Funktion alle Datenbank-Engine-Berechtigungen zurück. Weitere Informationen finden Sie unter sys.fn_builtin_permissions.

SELECT * FROM fn_builtin_permissions(default);
GO

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

Im folgenden Beispiel wird fn_builtin_permissions verwendet, um alle Berechtigungen anzuzeigen, die für eine Kategorie des sicherungsfähigen Elements verfügbar sind. Im Beispiel werden Berechtigungen für Assemblys zurückgegeben.

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 mithilfe von fn_my_permissions eine Liste der effektiven Berechtigungen zurückgegeben, die vom aufrufenden Prinzipal für ein bestimmtes sicherungsfähiges Element gespeichert werden. Im Beispiel werden Berechtigungen für ein Objekt mit dem Namen Orders55 zurückgegeben. Weitere Informationen finden Sie unter sys.fn_my_permissions.

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

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

Im folgenden Beispiel werden Berechtigungen für ein Objekt namens Yttriumzurückgegeben. Die integrierte OBJECT_ID-Funktion zum Abrufen der ID des Yttrium-Objekts verwendet wird.

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

Zugehöriger Inhalt

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