Berechtigungen (Datenbank-Engine)

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-InstanzAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL-Analyseendpunkt in Microsoft FabricLagerhaus in Microsoft FabricSQL-Datenbank 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 der SQL-Datenbank in Microsoft Fabric ist die 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 die erforderlichen Berechtigungen verstanden haben, können Sie Berechtigungen auf Serverebene auf Anmeldungen oder Serverrollen und Berechtigungen auf Datenbankebene auf Benutzer oder Datenbankrollen anwenden, indem Sie die GRANTAnweisungen REVOKEDENYverwenden. 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. BEISPIELSWEISE ermöglicht ALTER ANY LOGIN das Erstellen, Ändern oder Ablegen von Anmeldungen 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. Beispielsweise ermöglicht ALTER ANY SCHEMA das Erstellen, Ändern oder Ablegen eines 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.

• 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 dieses 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:

• VIEW ANY SECURITY DEFINITION
• VIEW JEDE LEISTUNGSDEFINITION
• VIEW SICHERHEITSSTATUS DES SERVERS
• VIEW STATUS DER SERVERLEISTUNG
• VIEW JEDE KRYPTOGRAFISCH GESICHERTE DEFINITION

Datenbankebene:

• VIEW DATABASE SICHERHEITSSTATUS
• VIEW DATABASE LEISTUNGSSTATUS
• VIEW SICHERHEITSDEFINITION
• VIEW LEISTUNGSDEFINITION
• VIEW KRYPTOGRAFISCH GESICHERTE DEFINITION

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 DATABASEEVENT SESSION
• DROP ANY DATABASEEVENT SESSION
• Ändern Sie eine beliebige DATABASEEVENT SESSION Option
• ALTER ANY DATABASEEVENT SESSION ADD EVENT
• ALTER ANY DATABASEEVENT SESSION DROP EVENT
• ALTER ANY DATABASEEVENT SESSION ENABLE
• ALTER ANY DATABASEEVENT SESSION DISABLE
• ALTER ANY DATABASEEVENT SESSION ADD TARGET
• ALTER ANY DATABASEEVENT SESSION DROP TARGET

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

Sicherheitsbezogene Objektberechtigungen

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• VERWEISE (CREDENTIAL)
• ENTMASKIEREN (OBJEKT)
• DEMASKIEREN (SCHEMA)
• VIEW ANY ERROR LOG
• VIEW SERVER-SICHERHEITSAUDIT
• VIEW DATABASE SICHERHEITSÜBERWACHUNG

Ledger-Berechtigungen

• ALTER LEDGER
• ALTER LEDGER CONFIGURATION
• LEDGER AKTIVIEREN
• VIEW Inhalt des Ledgers

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

• Sicherheitskontext

  Dies ist die Gruppe von Prinzipalen, die Berechtigungen für die Zugriffsüberprüfung einbringen. 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 schließt die folgenden Prinzipale ein:

  • Die Anmeldung

  • Der Benutzer

  • Rollenzugehörigkeiten

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

• Berechtigungsraum

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

• Erforderliche Berechtigung

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

  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 INSERT auch die 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 MIT GRANT oder DENY angegeben werden; oder die Berechtigungen können eine stillschweigende oder übergreifende Berechtigung GRANT oder DENY sein. 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.

   Note

   Ein GRANT einer Berechtigung auf Spaltenebene setzt ein DENY auf Objektebene außer Kraft. 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 erfolgreich, wenn die erforderliche Berechtigung nicht verweigert wurde und die erforderliche Berechtigung für eine der Identitäten im Sicherheitskontext für ein beliebiges Objekt im Berechtigungsbereich entweder direkt oder implizit eine Berechtigung GRANT oder GRANT WITH GRANT enthält.

Spezielle Aspekte für Berechtigungen auf Spaltenebene

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

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

Ein DENY auf der Tabelle wird mit einem GRANT auf einer Spalte überschrieben. Eine nachfolgende DENY in der Tabelle entfernt jedoch die Spalte GRANT.

Examples

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

Verwandte Inhalte

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