Behörigheter: BEVILJA, NEKA, ÅTERKALLA

Gäller för:Azure Synapse Analytics AnalyticsPlatform System (PDW)SQL-slutpunkt i Microsoft FabricWarehouse i Microsoft Fabric

Använd GRANT - och DENY-instruktioner för att bevilja eller neka en behörighet (till exempel UPDATE) för en skyddsbar (till exempel en databas, tabell, vy osv.) till ett säkerhetsobjekt (en inloggning, en databasanvändare eller en databasroll). Använd REVOKE för att ta bort beviljandet eller nekandet av en behörighet.

Behörigheter på servernivå tillämpas på inloggningar. Behörigheter på databasnivå tillämpas på databasanvändare och databasroller.

Om du vill se vilka behörigheter som har beviljats och nekats frågar du vyerna sys.server_permissions och sys.database_permissions. Behörigheter som inte uttryckligen beviljas eller nekas till ett säkerhetsobjekt kan ärvas genom att ha medlemskap i en roll som har behörigheter. Behörigheterna för de fasta databasrollerna kan inte ändras och visas inte i vyerna sys.server_permissions och sys.database_permissions.

  • GRANT beviljar uttryckligen en eller flera behörigheter.

  • NEKA nekar uttryckligen huvudkontot från att ha en eller flera behörigheter.

  • ÅTERKALLA tar bort befintliga GRANT- eller DENY-behörigheter .

Transact-SQL-syntaxkonventioner

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  
}  

Argument

<permission>[ ,... n ]
En eller flera behörigheter att bevilja, neka eller återkalla.

ON [ <class_type> :: ] securableOn-satsen beskriver den skyddsbara parameter som behörigheter ska beviljas, nekas eller återkallas på.

<> class_type Typ av skyddsbar klass. Detta kan vara LOGIN, DATABASE, OBJECT, SCHEMA, ROLE eller USER. Behörigheter kan också beviljas till SERVER-class_type, men SERVER har inte angetts för dessa behörigheter. DATABASE anges inte när behörigheten innehåller ordet DATABAS (till exempel ALTER ANY DATABASE). När ingen class_type har angetts och behörighetstypen inte är begränsad till server- eller databasklassen antas klassen vara OBJECT.

skyddsbar
Namnet på inloggningen, databasen, tabellen, vyn, schemat, proceduren, rollen eller användaren som behörigheter ska beviljas, nekas eller återkallas på. Objektnamnet kan anges med namngivningsreglerna i tre delar som beskrivs i Transact-SQL-syntaxkonventioner.

TO principal [ ,... n ]
Ett eller flera huvudkonton beviljas, nekas eller återkallas. Huvudkontot är namnet på en inloggnings-, databasanvändare eller databasroll.

FROM principal [ ,... n ]
Ett eller flera huvudkonton att återkalla behörigheter från. Huvudkontot är namnet på en inloggnings-, databasanvändare eller databasroll. FROM kan endast användas med en REVOKE-instruktion . TO kan användas med GRANT, DENY eller REVOKE.

MED ALTERNATIVET BEVILJA
Anger att den beviljande också kommer att ges möjlighet att bevilja den angivna behörigheten till andra huvudkonton.

CASCADE
Anger att behörigheten nekas eller återkallas till det angivna huvudkontot och till alla andra huvudkonton som huvudkontot har beviljat behörigheten till. Krävs när huvudkontot har behörighet med ALTERNATIVET BEVILJA.

BEVILJANDEALTERNATIV FÖR
Anger att möjligheten att bevilja den angivna behörigheten kommer att återkallas. Detta krävs när du använder argumentet CASCADE .

Viktigt

Om huvudkontot har den angivna behörigheten utan alternativet BEVILJA återkallas själva behörigheten.

Behörigheter

Om du vill bevilja en behörighet måste beviljaren antingen ha behörigheten själv med ALTERNATIVET MED BEVILJA, eller ha en högre behörighet som innebär att behörigheten beviljas. Objektägare kan bevilja behörigheter för de objekt som de äger. Huvudkonton med CONTROL-behörighet för en skyddsbar kan bevilja behörighet för den skyddsbara filen. Medlemmar i db_owner - och db_securityadmin fasta databasroller kan bevilja alla behörigheter i databasen.

Allmänna kommentarer

Om du nekar eller återkallar behörigheter till ett huvudkonto påverkas inte begäranden som har godkänts av auktoriseringen och som körs för närvarande. Om du vill begränsa åtkomsten omedelbart måste du avbryta aktiva begäranden eller avsluta aktuella sessioner.

Anteckning

De flesta fasta serverroller är inte tillgängliga i den här versionen. Använd användardefinierade databasroller i stället. Inloggningar kan inte läggas till i den fasta serverrollen sysadmin . Om du beviljar CONTROL SERVER-behörigheten ungefärligt medlemskap i den fasta sysadmin-serverrollen .

Vissa instruktioner kräver flera behörigheter. Om du till exempel vill skapa en tabell krävs behörigheterna CREATE TABLE i databasen och ALTER SCHEMA-behörigheten för den tabell som ska innehålla tabellen.

Analytics Platform System (PDW) kör ibland lagrade procedurer för att distribuera användaråtgärder till beräkningsnoderna. Därför kan inte körningsbehörigheten för en hel databas nekas. (Till exempel DENY EXECUTE ON DATABASE::<name> TO <user>; misslyckas.) Som en lösning kan du neka körningsbehörigheten till användarscheman eller specifika objekt (procedurer).

I Microsoft Fabric går det för närvarande inte att uttryckligen köra CREATE USER. När GRANT eller DENY körs skapas användaren automatiskt.

I Microsoft Fabric är behörigheter på servernivå inte hanterbara.

Implicita och explicita behörigheter

En explicit behörighet är en GRANT- eller DENY-behörighet som ges till ett huvudkonto av en GRANT - eller DENY-instruktion .

En implicit behörighet är en GRANT- eller DENY-behörighet som ett huvudkonto (inloggning, användare eller databasroll) har ärvt från en annan databasroll.

En implicit behörighet kan också ärvas från en överordnad eller överordnad behörighet. Till exempel kan UPDATE-behörighet för en tabell ärvas genom att ha UPDATE-behörighet för schemat som innehåller tabellen eller CONTROL-behörighet för tabellen.

Länkning av ägarskap

När flera databasobjekt kommer åt varandra sekventiellt kallas sekvensen för en kedja. Även om sådana kedjor inte finns oberoende av varandra, utvärderar SQL Server behörigheter för de ingående objekten annorlunda när SQL Server passerar länkarna i en kedja. Länkning av ägarskap har viktiga konsekvenser för att hantera säkerheten. Mer information om ägarskapskedjor finns i Ägarskapskedjor och Självstudie: Ägarskapskedjor och Kontextväxling.

Behörighetslista

Behörigheter på servernivå

Behörigheter på servernivå kan beviljas, nekas och återkallas från inloggningar.

Behörigheter som gäller för servrar

  • KONTROLLSERVER

  • ADMINISTRERA MASSÅTGÄRDER

  • ÄNDRA ALLA ANSLUTNINGAR

  • ÄNDRA EN DATABAS

  • SKAPA VALFRI DATABAS

  • ÄNDRA EN EXTERN DATAKÄLLA

  • ÄNDRA ETT EXTERNT FILFORMAT

  • ÄNDRA ALLA INLOGGNINGAR

  • ÄNDRA SERVERTILLSTÅND

  • ANSLUTA SQL

  • VISA ALLA DEFINITIONER

  • VISA VALFRI DATABAS

  • VISA SERVERTILLSTÅND

Behörigheter som gäller för inloggningar

  • KONTROLL VID INLOGGNING

  • ÄNDRA VID INLOGGNING

  • PERSONIFIERA VID INLOGGNING

  • VISA DEFINITION

Behörigheter på databasnivå

Behörigheter på databasnivå kan beviljas, nekas och återkallas från databasanvändare och användardefinierade databasroller.

Behörigheter som gäller för alla databasklasser

  • KONTROLL

  • ALTER

  • VISA DEFINITION

Behörigheter som gäller för alla databasklasser utom användare

  • BLI ÄGARE

Behörigheter som endast gäller för databaser

  • ÄNDRA EN DATABAS

  • ÄNDRA PÅ DATABAS

  • ÄNDRA ALLA DATAUTRYMMEN

  • ÄNDRA EN ROLL

  • ÄNDRA VALFRITT SCHEMA

  • ÄNDRA ALLA ANVÄNDARE

  • SÄKERHETSKOPIERA DATABAS

  • ANSLUT PÅ DATABAS

  • SKAPA PROCEDUR

  • SKAPA ROLL

  • SKAPA SCHEMA

  • CREATE TABLE

  • CREATE VIEW

  • SHOWPLAN

Behörigheter som endast gäller för användare

  • PERSONIFIERA

Behörigheter som gäller för databaser, scheman och objekt

  • ALTER

  • DELETE

  • UTFÖRA

  • INSERT

  • SELECT

  • UPDATE

  • REFERENSLISTA

En definition av varje typ av behörighet finns i Behörigheter (databasmotor).

Diagram över behörigheter

Alla behörigheter visas grafiskt på den här affischen. Det här är det enklaste sättet att se kapslad hierarki med behörigheter. Behörigheten ALTER ON LOGIN kan till exempel beviljas av sig själv, men den ingår också om en inloggning beviljas behörigheten CONTROL för den inloggningen, eller om en inloggning beviljas alter any login-behörigheten .

Aps säkerhetsbehörigheter affisch

Standardbehörigheter

I följande lista beskrivs standardbehörigheterna:

  • När en inloggning skapas med hjälp av instruktionen CREATE LOGIN får den nya inloggningen CONNECT SQL-behörigheten .

  • Alla inloggningar är medlemmar i den offentliga serverrollen och kan inte tas bort från offentlig.

  • När en databasanvändare skapas med hjälp av behörigheten SKAPA ANVÄNDARE får databasanvändaren CONNECT-behörigheten i databasen.

  • Alla huvudkonton, inklusive den offentliga rollen, har inga explicita eller implicita behörigheter som standard.

  • När en inloggning eller användare blir ägare till en databas eller ett objekt har inloggningen eller användaren alltid alla behörigheter för databasen eller objektet. Ägarskapsbehörigheterna kan inte ändras och visas inte som explicita behörigheter. Instruktionerna GRANT, DENY och REVOKE har ingen effekt på ägarna.

  • SA-inloggningen har alla behörigheter för installationen. På samma sätt som behörigheter för ägarskap kan sa-behörigheterna inte ändras och visas inte som explicita behörigheter. Instruktionerna GRANT, DENY och REVOKE har ingen effekt på SA-inloggningen . Det går inte att byta namn på SA-inloggningen.

  • USE-instruktionen kräver inte behörigheter. Alla huvudkonton kan köra USE-instruktionen på valfri databas.

Exempel: Azure Synapse Analytics and Analytics Platform System (PDW)

A. Bevilja en servernivå behörighet till en inloggning

Följande två instruktioner ger en behörighet på servernivå för en inloggning.

GRANT CONTROL SERVER TO [Ted];  
GRANT ALTER ANY DATABASE TO Mary;  

B. Bevilja en servernivå behörighet till en inloggning

I följande exempel ges en behörighet på servernivå för en inloggning till ett serverhuvudnamn (en annan inloggning).

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;  

C. Bevilja en användare behörighet på databasnivå

I följande exempel tilldelas en användare behörighet på databasnivå till ett databashuvudnamn (en annan användare).

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

D. Bevilja, neka och återkalla en schemabehörighet

Följande GRANT-instruktion ger Yuen möjlighet att välja data från valfri tabell eller vy i dbo-schemat.

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

Följande DENY-instruktion hindrar Yuen från att välja data från en tabell eller vy i dbo-schemat. Yuen kan inte läsa data även om han har behörighet på något annat sätt, till exempel genom ett rollmedlemskap.

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

Följande REVOKE-instruktion tar bort behörigheten NEKA . Nu är Yuens uttryckliga behörigheter neutrala. Yuen kanske kan välja data från valfri tabell via någon annan implicit behörighet, till exempel ett rollmedlemskap.

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

E. Demonstrerar den valfria OBJECT::-satsen

Eftersom OBJECT är standardklassen för en behörighetsinstruktion är följande två -instruktioner desamma. OBJECT:: -satsen är valfri.

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