Berechtigungen: GRANT, DENY, REVOKE

Gilt für:Azure Synapse AnalyticsAnalytics Platform System (PDW)SQL Analytics-Endpunkt in Microsoft FabricWarehouse in Microsoft Fabric

Verwenden GRANT Sie und Anweisungen DENY , um eine Berechtigung (z. B. UPDATE) für eine sichere Datei (wie Datenbank, Tabelle, Ansicht usw.) an einen Sicherheitsprinzipal (einen Login, einen Datenbankbenutzer oder eine Datenbankrolle) zu erteilen oder zu verweigern. Verwenden REVOKE Sie es, um die Erteilung oder Ablehnung einer Genehmigung zu entfernen.

Berechtigungen auf Serverebene werden auf Anmeldenamen angewendet. Berechtigungen auf Datenbankebene werden auf Datenbankbenutzer und Datenbankrollen angewendet.

Fragen Sie die Sichten „sys.server_permissions“ und „sys.database_permissions“ ab, um festzustellen, welche Berechtigungen erteilt und verweigert wurden. Berechtigungen, die einem Sicherheitsprinzipal nicht explizit erteilt oder verweigert wurden, können geerbt werden, wenn eine Mitgliedschaft einer Rolle mit Berechtigung besteht. Die Berechtigungen der festen Datenbankrollen können nicht geändert werden und werden nicht in den Sichten „sys.server_permissions“ und „sys.database_permissions“ angezeigt.

• GRANT gewährt ausdrücklich eine oder mehrere Berechtigungen.

• DENY Verweigert dem Hauptprinzipal ausdrücklich eine oder mehrere Berechtigungen.

• REVOKE entfernt bestehende GRANT oder DENY Berechtigungen.

Transact-SQL-Syntaxkonventionen

Syntax

-- Azure Synapse Analytics and Parallel Data Warehouse and Microsoft Fabric
GRANT   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    TO principal [ ,...n ]  
    [ WITH GRANT OPTION ]  
[;]  
  
DENY   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    TO principal [ ,...n ]  
    [ CASCADE ]  
[;]  
  
REVOKE   
    <permission> [ ,...n ]  
    [ ON [ <class_type> :: ] securable ]   
    [ FROM | TO ] principal [ ,...n ]  
    [ CASCADE ]  
[;]  
  
<permission> ::=  
{ see the tables below }  
  
<class_type> ::=  
{  
      LOGIN  
    | DATABASE  
    | OBJECT  
    | ROLE  
    | SCHEMA  
    | USER  
}  

Argumente

<Berechtigungen>[ ,...n ]
Mindestens eine Berechtigung, die zu erteilen, verweigern oder widerrufen ist.

ON [ <class_type> :: ] securable Die ON-Klausel beschreibt den sicherungsfähigen Parameter, für den Berechtigungen zugewiesen, verweigert oder widerrufen werden sollen.

<class_type> Der Klassentyp des sicherungsfähigen Elements. Dies kann , DATABASE, OBJEKT,SCHEMA , , ROLEoder USERseinLOGIN. Berechtigungen können auch für SERVERKlassentyp erteilt werden, allerdings wird SERVER für diese Berechtigungen nicht angegeben. DATABASE wird nicht angegeben, wenn die Erlaubnis das Wort DATABASE enthält (zum Beispiel ALTER ANY DATABASE). Wenn class_type nicht angegeben ist und der Berechtigungstyp nicht auf die Server- oder Datenbankklassen beschränkt ist, wird von der Klasse OBJECT ausgegangen.

securable
Der Name für die Anmeldung, die Datenbank, die Tabelle, die Sicht, das Schema, die Prozedur, die Rolle oder den Benutzer, dem Berechtigungen erteilt, verweigert oder widerrufen werden sollen. Der Objektname kann mit den dreiteiligen Benennungsregeln angegeben werden, die unter Transact-SQL-Syntaxkonventionen beschrieben sind.

TO principal [ , ...n]
Mindestens ein Prinzipal, dem Berechtigungen erteilt, verweigert oder widerrufen werden sollen. Ein Prinzipal ist der Anmeldename, der Datenbankbenutzer oder die Datenbankrolle.

FROM principal [ , ...n]
Mindestens ein Prinzipal, für den Berechtigungen widerrufen werden sollen. Ein Prinzipal ist der Anmeldename, der Datenbankbenutzer oder die Datenbankrolle. FROM kann nur mit einer Anweisung REVOKE verwendet werden. TO kann mit GRANT, DENY, oder REVOKEverwendet werden.

MIT GRANT OPTION
Gibt an, dass der Empfänger die angegebene Berechtigung auch anderen Prinzipalen erteilen kann.

CASCADE
Gibt an, dass die Berechtigung für den angegebenen Prinzipal und für alle anderen Prinzipale verweigert oder widerrufen wird, denen diese Berechtigung von diesem Prinzipal erteilt wurde. Erforderlich, wenn der Schulleiter die Erlaubnis mit GRANT OPTION hat.

GRANT OPTION FÜR
Gibt an, dass die Fähigkeit, die angegebene Berechtigung zu erteilen, aufgehoben wird. Dies ist bei Verwendung des Arguments CASCADE erforderlich.

Berechtigungen

Um eine Genehmigung zu erteilen, muss der Erteiler entweder die Erlaubnis selbst mit der WITH-Option GRANThaben oder eine höhere Genehmigung besitzen, die die erteilte Genehmigung impliziert. Objektbesitzer können Berechtigungen für die Objekte erteilen, die sie besitzen. Prinzipale mit der Berechtigung CONTROL für ein sicherungsfähiges Element können die Berechtigung für dieses sicherungsfähige Element erteilen. Mitglieder der festen Datenbankrollen db_owner und db_securityadmin können jegliche Berechtigungen in der Datenbank erteilen.

Allgemeine Hinweise

Das Verweigern oder Widerrufen von Berechtigungen für ein Prinzipal hat keine Auswirkungen auf Anforderungen, die bereits autorisiert wurden und derzeit ausgeführt werden. Zum sofortigen Einschränken des Zugriffs müssen Sie aktive Anforderungen abbrechen oder aktuelle Sitzungen beenden.

Einige Anweisungen erfordern mehrere Berechtigungen. Zum Beispiel erfordert das Erstellen einer Tabelle die CREATE TABLE Berechtigungen in der Datenbank sowie die ALTER SCHEMA Berechtigung für die Tabelle, die die Tabelle enthalten wird.

Analytics Platform System (PDW) führt manchmal gespeicherte Prozeduren zum Verteilen von Benutzeraktionen auf Computeknoten aus. Aus diesem Grund kann die Berechtigung EXECUTE nicht für eine gesamte Datenbank verweigert werden. (Z.B. schlägt DENY EXECUTE ON DATABASE::<name> TO <user>; fehl.) Sie können dies umgehen, indem Sie die EXECUTE-Berechtigung für Benutzerschemas oder spezifische Objekte (Prozeduren) verweigern.

In Microsoft Fabric können derzeit nicht explizit CREATE USER ausgeführt werden. Wenn GRANT oder DENY ausgeführt wird, wird der Benutzer automatisch erstellt.

In Microsoft Fabric können Berechtigungen auf Serverebene nicht verwaltet werden.

Implizite und explizite Berechtigungen

Eine explizite Berechtigung ist eine GRANT- oder DENY-Berechtigung, die einem Prinzipal durch eine GRANT- oder DENY-Anweisung erteilt wird.

Eine implizite Berechtigung ist eine GRANT oder DENY eine Berechtigung, die ein Hauptverantwortlicher (Login, Benutzer oder Datenbankrolle) von einer anderen Datenbankrolle geerbt hat.

Eine implizite Berechtigung kann auch von einer abdeckenden oder übergeordneten Berechtigung geerbt werden. Zum Beispiel kann eine UPDATE Berechtigung für eine Tabelle vererbt werden, indem UPDATE man eine Berechtigung für das Schema hat, das die Tabelle enthält, oder die CONTROL-Berechtigung für die Tabelle.

Besitzverkettung

Wenn mehrere Datenbankobjekte aufeinander sequenziell zugreifen, wird diese Sequenz als Kette bezeichnet. Obwohl solche Ketten nicht unabhängig voneinander vorhanden sind, werden in SQL Server beim Traversieren der Links in einer Kette durch SQL Server die Berechtigungen für die einzelnen Objekte anders ausgewertet als beim getrennten Zugriff auf die Objekte. Besitzketten haben erhebliche Auswirkungen auf die Sicherheitsverwaltung. Weitere Informationen zu Besitzketten finden Sie im Artikel zu Besitzketten und im Tutorial: Besitzketten und Kontextwechsel.

Berechtigungsliste

Berechtigungen auf Serverebene

Berechtigungen auf Serverebene können von Anmeldenamen erteilt, verweigert und widerrufen werden.

Für Server geltende Berechtigungen

• Steuerungsserver

• VERWALTEN VON MASSENVORGÄNGEN

• ÄNDERN EINER BELIEBIGEN VERBINDUNG

• JEDES ÄNDERN DATABASE

• BELIEBIG ERSTELLEN DATABASE

• JEDES ÄNDERN EXTERNAL DATA SOURCE

• JEDES ÄNDERN EXTERNAL FILE FORMAT

• JEDES ÄNDERN LOGIN

• SERVERSTATUS ÄNDERN

• CONNECT SQL

• VIEW JEDE DEFINITION

• VIEW JEGLICHE DATABASE

• VIEW SERVERSTATUS

Berechtigungen,die für Anmeldenamen gelten

• STEUERUNG AN LOGIN

• ALTER ON LOGIN

• IMITIEREN AUF LOGIN

• VIEW DEFINITION

Berechtigungen auf Datenbankebene

Berechtigungen auf Datenbankebene können von Datenbankbenutzern und benutzerdefinierten Datenbankrollen erteilt, verweigert und widerrufen werden.

Für alle Datenbankklassen geltende Berechtigungen

• CONTROL

• ALTER

• VIEW DEFINITION

Für alle Datenbankklassen außer Benutzer geltende Berechtigungen

• EIGENTÜMERSCHAFT ÜBERNEHMEN

Nur für die Datenbank geltende Berechtigungen

• JEDES ÄNDERN DATABASE

• ALTER ON DATABASE

• ÄNDERN EINES BELIEBIGEN DATENBEREICHS

• JEDES ÄNDERN ROLE

• JEDES ÄNDERN SCHEMA

• JEDES ÄNDERN USER

• BACKUP DATABASE

• VERBINDEN UNS DATABASE

• CREATE PROCEDURE

• CREATE ROLE

• CREATE SCHEMA

• CREATE TABLE

• CREATE VIEW

• SHOWPLAN

Nur für Benutzer geltende Berechtigungen

• IMPERSONATE

Für Datenbanken, Schemas und Objekte geltende Berechtigungen

• ALTER

• DELETE

• Führen Sie

• INSERT

• SELECT

• UPDATE

• REFERENCES

Eine Definition für jede Art der Berechtigung finden Sie unter Berechtigungen (Datenbank-Engine).

Standardberechtigungen

In der folgenden Liste werden die Standardberechtigungen beschrieben:

• Wenn ein Login mit der Anweisung CREATE LOGIN erstellt wird, erhält der neue Login die SQL-Berechtigung CONNECT .

• Alle Anmeldenamen sind Mitglieder der Serverrolle public und können nicht aus public entfernt werden.

• Wenn ein Datenbankbenutzer mit der Berechtigung CREATE USER erstellt wird, erhält der Datenbankbenutzer die CONNECT-Berechtigung in der Datenbank.

• Standardmäßig verfügen alle Prinzipale, einschließlich der Rolle public, über keine expliziten oder impliziten Berechtigungen.

• Wenn ein Anmeldename oder ein Benutzer zum Besitzer einer Datenbank oder eines Objekts werden, erhalten diese alle Berechtigungen für die Datenbank bzw. das Objekt. Die Besitzerrechte können nicht geändert werden und sind nicht als explizite Berechtigungen sichtbar. Die , DENY, und REVOKE Aussagen GRANThaben keine Auswirkungen auf Eigentümer.

• Der sysadmin-Anmeldename verfügt über alle Berechtigungen auf dem Gerät. Ähnlich wie Besitzerrechte, können sa-Berechtigungen nicht geändert werden und sind nicht als explizite Berechtigungen sichtbar. Die GRANT, DENY, und Anweisungen REVOKE haben keinen Einfluss auf den SA-Login . Der sa-Anmeldename kann nicht umbenannt werden.

• Die Anweisung USE erfordert keine Berechtigungen. Auf allen Datenbanken können alle Prinzipale die Anweisung USE ausführen.

Beispiele: Azure Synapse Analytics und Analytics-Plattformsystem (PDW)

A. Erteilen einer Berechtigung auf Serverebene für einen Anmeldenamen

Die folgenden zwei Anweisungen erteilen einem Anmeldenamen eine Berechtigung auf Serverebene.

GRANT CONTROL SERVER TO [Ted];  

GRANT ALTER ANY DATABASE TO Mary;  

B. Erteilen einer Berechtigung auf Serverebene für einen Anmeldenamen

Im folgenden Beispiel wird einem Serverprinzipal (ein anderer Anmeldename) eine Berechtigung auf Serverebene für einen Anmeldenamen zugewiesen.

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;  

C. Erteilen einer Berechtigung auf Datenbankebene für einen Benutzer

Im folgenden Beispiel wird einem Datenbankprinzipal (ein anderer Benutzer) eine Berechtigung auf Datenbankebene für einen Benutzer zugewiesen.

GRANT VIEW DEFINITION ON USER::[Ted] TO Mary;  

D: Erteilen, Verweigern und Widerrufen einer Berechtigung für ein Schema

Die folgende GRANT Anweisung gewährt Yuen die Möglichkeit, Daten aus jeder Tabelle oder Ansicht im DBO-Schema auszuwählen.

GRANT SELECT ON SCHEMA::dbo TO [Yuen];  

Die folgende DENY Anweisung verhindert, dass Yuen Daten aus irgendeiner Tabelle oder Ansicht im DBO-Schema auswählt. Yuen kann die Daten nicht lesen, selbst wenn er auf eine andere Weise über die Berechtigung verfügt, z.B. über eine Rollenmitgliedschaft.

DENY SELECT ON SCHEMA::dbo TO [Yuen];  

Die folgende REVOKE Aussage entfernt die Berechtigung DENY . Jetzt sind die expliziten Berechtigungen von Yuen neutral. Yuen könnte über eine andere implizite Berechtigung, wie z.B. eine Rollenmitgliedschaft, über die Berechtigung verfügen, Daten aus einer beliebigen Tabelle auszuwählen.

REVOKE SELECT ON SCHEMA::dbo TO [Yuen];  

E. Veranschaulichung der optionalen Klausel OBJECT::

Da OBJECT die Standardklasse für eine Berechtigungsanweisung ist, sind die folgenden zwei Anweisungen identisch. Die Klausel OBJECT:: ist optional.

GRANT UPDATE ON OBJECT::dbo.StatusTable TO [Ted];  

GRANT UPDATE ON dbo.StatusTable TO [Ted];