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

• ÜBERNEHMEN EIGENTUM

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

• < Nachahmen>

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

• Benutzer imitieren <>

  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 Klausel zu erstellen, die WITH SCHEMABINDING 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 JEDE SICHERHEITSDEFINITION
• VIEW JEDE LEISTUNGSDEFINITION
• VIEW SERVERSICHERHEITSSTATUS
• VIEW SERVERLEISTUNGSSTATUS
• 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:

• BELIEBIG ERSTELLEN EVENT SESSION
• DROP ANY EVENT SESSION
• ÄNDERN EINER BELIEBIGEN 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
• ÄNDERN EINES BELIEBIGEN ADD-ZIELS EVENT SESSION
• ÄNDERN EINES EVENT SESSION BELIEBIGEN DROP-ZIELS

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

Datenbankebene:

• BELIEBIG ERSTELLEN DATABASEEVENT SESSION
• DROP ANY DATABASEEVENT SESSION
• ÄNDERN EINER BELIEBIGEN 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
• ÄNDERN EINES BELIEBIGEN ADD-ZIELS DATABASEEVENT SESSION
• ÄNDERN EINES DATABASEEVENT SESSION BELIEBIGEN DROP-ZIELS

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

Sicherheitsbezogene Objektberechtigungen

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• VERWEISE (CREDENTIAL)
• ENTMASKIEREN (OBJEKT)
• UNMASK (SCHEMA)
• VIEW FEHLERPROTOKOLL
• VIEW SERVERSICHERHEITSÜBERWACHUNG
• VIEW DATABASE SICHERHEITSÜBERWACHUNG

Ledger-Berechtigungen

• ALTER LEDGER
• ALTER LEDGER-KONFIGURATION
• LEDGER AKTIVIEREN
• VIEW LEDGER-INHALT

Andere Berechtigungen für Datenbank

• ÄNDERN EINES EXTERNEN AUFTRAGS
• ÄNDERN EINES EXTERNEN DATENSTROMS
• AUSFÜHREN BELIEBIGER EXTERNER ELEMENTE 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 Blockierung DENY gefunden wird, sucht der Algorithmus nach einem GRANT , der ausreichendEn Zugriff bietet. 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

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

• 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. Beispiel: INSERT, , , UPDATE, DELETESELECT, 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 INSERT auch die Berechtigung für mehrere Tabellen erfordern, auf die von der gespeicherten Prozedur verwiesen wird.

  • Eine dynamische Verwaltungsansicht kann sowohl SERVER STATE als auch VIEW SELECT-Berechtigung für die Ansicht 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 ein GRANT, GRANT WITH GRANToder DENY; angegeben werden, oder die Berechtigungen können impliziert oder abgedeckt werden.GRANTDENY 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

   A GRANT of a column-level permission overrides a DENY at the object level. 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. Ü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.

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;

A DENY in der Tabelle wird durch eine GRANT Spalte überschrieben. Eine nachfolgende DENY 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)