Permessi: GRANT, DENY, REVOKE

Si applica a:Azure Synapse AnalyticsAnalyticsPlatform System (PDW)ENDPOINT di analisi SQL in Microsoft FabricWarehouse in Microsoft Fabric

Uso GRANT delle istruzioni e DENY per concedere o negare un permesso (come UPDATE) su un oggetto di sicurezza (come un database, una tabella, una vista, ecc.) a un security principal (un login, un utente di database o un ruolo di database). Usare REVOKE per rimuovere la concessione o negare un permesso.

Le autorizzazioni a livello server vengono applicate agli account di accesso. Le autorizzazioni a livello di database vengono applicate agli utenti database e ai ruoli del database.

Per visualizzare le autorizzazioni concesse e negate, eseguire una query nelle visualizzazioni sys.server_permissions e sys.database_permissions. Le autorizzazioni che non sono concesse o negate in modo esplicito per un'entità di sicurezza possono essere ereditate attraverso l'appartenenza a un ruolo con autorizzazioni. Le autorizzazioni dei ruoli predefiniti del database non possono essere modificate e non sono incluse nelle visualizzazioni sys.server_permissions e sys.database_permissions.

• GRANT concede esplicitamente uno o più permessi.

• DENY nega esplicitamente al titolare di avere uno o più permessi.

• REVOKE Rimuove permessi esistenti GRANT o DENY autorizzati.

Convenzioni relative alla sintassi Transact-SQL

Sintassi

-- 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  
}  

Argomenti

<permesso>[ ,... n ]
Una o più autorizzazioni da concedere, negare o revocare.

ON [ <class_type> :: ] securable La clausola ON descrive il parametro dell'entità a protezione diretta in cui concedere, negare o revocare le autorizzazioni.

<class_type> Tipo di classe dell'entità a protezione diretta. Questo può essere LOGIN, DATABASE, OGGETTO, SCHEMA, ROLE, o USER. Sebbene sia anche possibile concedere le autorizzazioni a SERVERclass_type, SERVER non è specificato per tali autorizzazioni. DATABASE non è specificato quando il permesso include la parola DATABASE (ad esempio ALTER ANY DATABASE). Se class_type non è specificato e il tipo di autorizzazione non è limitato al server o alla classe del database, viene usata la classe OBJECT.

securable
Nome di account di accesso, database, tabella, visualizzazione, schema, procedura, ruolo o utente in cui concedere, negare o revocare le autorizzazioni. Il nome dell'oggetto può essere specificato con le regole di denominazione in tre parti descritte nelle convenzioni di sintassi Transact-SQL.

AL preside [ ,...n ]
Una o più entità di sicurezza a cui vengono concesse, negate o revocate le autorizzazioni. L'entità di sicurezza corrisponde al nome di un account di accesso, di un utente database o di un ruolo del database.

DAL preside [ ,... n ]
Una o più entità di sicurezza a cui revocare le autorizzazioni. L'entità di sicurezza corrisponde al nome di un account di accesso, di un utente database o di un ruolo del database. FROM può essere usato solo con un'istruzione REVOKE . TO può essere usato con GRANT, DENY, oppure REVOKE.

CON GRANT OPZIONE
Indica che l'utente autorizzato potrà inoltre concedere l'autorizzazione specificata ad altre entità.

CASCADE
Indica che l'autorizzazione viene negata o revocata all'entità specificata e a tutte le entità a cui l'entità di sicurezza ha concesso l'autorizzazione. Richiesto quando il titolare ha il permesso con GRANT OPTION.

GRANT OPZIONE PER
Indica che verrà revocata la capacità di concedere l'autorizzazione specificata. Obbligatorio quando viene usato l'argomento CASCADE.

Autorizzazioni

Per concedere un permesso, il concedente deve avere o il permesso stesso con l'opzione WITHGRANT, oppure un permesso superiore che implichi che il permesso sia stato concesso. I proprietari degli oggetti possono concedere autorizzazioni per gli oggetti di cui sono proprietari. Le entità con l'autorizzazione CONTROL per un'entità a sicurezza diretta possono concedere l'autorizzazione per l'entità. I membri dei ruoli del database predefiniti db_owner e db_securityadmin possono concedere qualsiasi autorizzazione nel database.

Osservazioni generali

La negazione o la revoca delle autorizzazioni a un'entità di sicurezza non ha effetto sulle richieste che hanno passato l'autorizzazione e sono attualmente in esecuzione. Per limitare immediatamente l'accesso, è necessario annullare le richieste attive o terminare le sessioni correnti.

Alcune istruzioni richiedono più autorizzazioni. Ad esempio, per creare una tabella sono necessari i CREATE TABLE permessi nel database e i ALTER SCHEMA permessi per la tabella che conterrà la tabella.

Il sistema PDW (Analytics Platform System) a volte esegue stored procedure per distribuire le azioni utente ai nodi di calcolo. Pertanto, non è possibile negare l'autorizzazione di esecuzione per un intero database. Ad esempio DENY EXECUTE ON DATABASE::<name> TO <user>; , avrà esito negativo. Come soluzione alternativa, negare l'autorizzazione di esecuzione per schemi utente o oggetti specifici (routine).

In Microsoft Fabric, attualmente non può CREATE USER essere eseguito esplicitamente. Quando GRANT viene eseguito o DENY viene eseguito, l'utente verrà creato automaticamente.

In Microsoft Fabric le autorizzazioni a livello di server non sono gestibili.

Autorizzazioni implicite ed esplicite

Un'autorizzazione esplicita è un'autorizzazioneGRANT o DENY assegnata a un'entità da un'istruzione GRANT o DENY .

Un permesso implicito è un GRANT permesso o DENY che un principale (login, utente o ruolo di database) ha ereditato da un altro ruolo nel database.

Un'autorizzazione implicita può anche essere ereditata da un'autorizzazione di copertura o da un'autorizzazione padre. Ad esempio, il UPDATE permesso su una tabella può essere ereditato ottenendo UPDATE il permesso sullo schema che contiene la tabella, oppure il permesso CONTROL sulla tabella.

Concatenamento della proprietà

Quando più oggetti di database accedono l'uno all'altro in sequenza, questa sequenza è nota come catena. Sebbene queste catene non esistono in modo indipendente, quando in SQL Server vengono attraversati i collegamenti contenuti in una catena, SQL Server valuta le autorizzazioni per gli oggetti che compongono la catena diversamente da quanto farebbe se accedesse agli oggetti separatamente. Il concatenamento della proprietà ha implicazioni importanti per la gestione della sicurezza. Per altre informazioni sulle catene di proprietà, vedere Catene di proprietà e Esercitazione: Catene di proprietà e cambio di contesto.

Elenco delle autorizzazioni

Autorizzazioni a livello di server

Le autorizzazioni a livello di server possono essere concesse, negate e revocate dagli account di accesso.

Autorizzazioni valide per i server

• SERVER DI CONTROLLO

• AMMINISTRARE LE OPERAZIONI MASSIVE

• ALTERARE QUALSIASI CONNESSIONE

• MODIFICA QUALSIASI DATABASE

• CREA QUALSIASI DATABASE

• MODIFICA QUALSIASI EXTERNAL DATA SOURCE

• MODIFICA QUALSIASI EXTERNAL FILE FORMAT

• MODIFICA QUALSIASI LOGIN

• MODIFICA STATO DEL SERVER

• CONNECT SQL

• VIEW QUALSIASI DEFINIZIONE

• VIEW QUALSIASI DATABASE

• VIEW STATO SERVER

Autorizzazioni valide per gli account di accesso

• CONTROLLO ACCESO LOGIN

• ALTER ON LOGIN

• IMPERSONARE ON LOGIN

• VIEW DEFINIZIONE

Autorizzazioni a livello di database

Le autorizzazioni a livello di database possono essere concesse, negate e revocate dagli utenti database e dai ruoli del database definiti dall'utente.

Autorizzazioni valide per tutte le classi di database

• CONTROL

• ALTER

• VIEW DEFINIZIONE

Autorizzazioni valide per tutte le classi di database esclusi gli utenti

• ASSUMI LA PROPRIETÀ

Autorizzazioni valide solo per i database

• MODIFICA QUALSIASI DATABASE

• ALTER ON DATABASE

• MODIFICARE QUALSIASI SPAZIO DATI

• MODIFICA QUALSIASI ROLE

• MODIFICA QUALSIASI SCHEMA

• MODIFICA QUALSIASI USER

• BACKUP DATABASE

• COLLEGATI DATABASE

• CREATE PROCEDURE

• CREATE ROLE

• CREATE SCHEMA

• CREATE TABLE

• CREATE VIEW

• SHOWPLAN

Autorizzazioni valide solo per gli utenti

• IMPERSONATE

Autorizzazioni valide per i database, gli schemi e gli oggetti

• ALTER

• DELETE

• EXECUTE

• INSERT

• SELECT

• UPDATE

• REFERENCES

Per una definizione di ogni tipo di autorizzazione, vedere Autorizzazioni (motore di database).

Autorizzazioni predefinite

L'elenco seguente descrive le autorizzazioni predefinite:

• Quando un login viene creato utilizzando l'istruzione CREATE LOGIN , il nuovo login riceve il permesso CONNECT SQL .

• Tutti gli account di accesso sono membri del ruolo del server public e non possono essere rimossi da public.

• Quando un utente del database viene creato utilizzando il CREATE USER permesso, l'utente riceve il permesso CONNECT nel database.

• Tutte le entità di sicurezza, incluso il ruolo public, non hanno alcuna autorizzazione esplicita o implicita per impostazione predefinita.

• Quando un account di accesso o un utente diventa il proprietario di un database o un oggetto, l'account o l'utente ha sempre tutte le autorizzazioni per il database o l'oggetto. Le autorizzazioni di proprietà non possono essere modificate e non sono visibili come autorizzazioni esplicite. Le GRANTistruzioni , DENY, e REVOKE non hanno alcun effetto sui proprietari.

• L'account di accesso sa ha tutte le autorizzazioni nell'appliance. Analogamente alle autorizzazioni di proprietà, le autorizzazioni sa non possono essere modificate e non sono visibili come autorizzazioni esplicite. Le GRANTistruzioni , DENY, e REVOKE non hanno alcun effetto sull'accesso SA . L'account di accesso sa non può essere rinominato.

• L'istruzione USE non richiede autorizzazioni. Tutte le entità di sicurezza possono eseguire l'istruzione USE in qualsiasi database.

Esempi: Azure Synapse Analytics e Piattaforma di strumenti analitici (PDW)

R. Concessione di un'autorizzazione a livello di server a un account di accesso

Le due istruzioni seguenti concedono un'autorizzazione a livello di server a un account di accesso.

GRANT CONTROL SERVER TO [Ted];  

GRANT ALTER ANY DATABASE TO Mary;  

B. Concessione di un'autorizzazione a livello di server a un account di accesso

L'esempio seguente concede un'autorizzazione a livello di server in un account di accesso a un'entità di sicurezza del server (un altro account di accesso).

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;  

C. Concessione di un'autorizzazione a livello di database a un utente

L'esempio seguente concede un'autorizzazione a livello di database in un utente a un'entità di sicurezza del database (un altro utente).

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

D. Concessione, negazione e revoca di un'autorizzazione dello schema

La seguente GRANT affermazione concede a Yuen la possibilità di selezionare dati da qualsiasi tabella o vista nello schema dbo.

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

La seguente DENY affermazione impedisce a Yuen di selezionare dati da qualsiasi tabella o vista nello schema dbo. Yuen non può leggere i dati anche se dispone dell'autorizzazione in modo diverso, ad esempio tramite l'appartenenza a un ruolo.

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

La seguente REVOKE affermazione rimuove il DENY permesso. Le autorizzazioni esplicite di Yuen sono ora neutre. Yuen può selezionare dati da qualsiasi tabella attraverso un'altra autorizzazione implicita, ad esempio l'appartenenza a un ruolo.

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

E. Dimostrazione della clausola OBJECT:: facoltativa

Poiché OBJECT è la classe predefinita di un'istruzione di autorizzazione, le due istruzioni seguenti corrispondono. La clausola OBJECT:: è facoltativa.

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

GRANT UPDATE ON dbo.StatusTable TO [Ted];