Permissões: GRANT, DENY, REVOKE

Aplica-se a: Azure Synapse AnalyticsPDW (Analytics Platform System)Ponto de extremidade de análise do SQL no Microsoft FabricWarehouse no Microsoft Fabric

Uso GRANT de instruções e DENY para conceder ou negar uma permissão (como UPDATE) em um seguro (como banco de dados, tabela, visualização, etc.) a um principal de segurança (um login, um usuário de banco de dados ou um papel de banco de dados). Use REVOKE para remover a concessão ou negar uma permissão.

As permissões no nível do servidor são aplicadas aos logons. As permissões no nível do banco de dados são aplicadas aos usuários de banco de dados e às funções de banco de dados.

Para ver quais permissões foram concedidas e negadas, consulte as exibições sys.server_permissions e sys.database_permissions. As permissões que não são concedidas ou negadas explicitamente a uma entidade de segurança podem ser herdadas por meio da associação a uma função que tenha permissões. As permissões das funções de banco de dados fixas não podem ser alteradas e não aparecem nas exibições sys.server_permissions e sys.database_permissions.

• GRANT concede explicitamente uma ou mais permissões.

• DENY nega explicitamente ao principal a posse de uma ou mais permissões.

• REVOKE remove permissões existentes GRANT ou DENY permissões.

Convenções de sintaxe de Transact-SQL

Sintaxe

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

Argumentos

<permissão>[ ,... n ]
Uma ou mais permissões a serem concedidas, negadas ou revogadas.

ON [ <class_type> :: ] securable A cláusula ON descreve o parâmetro protegível no qual as permissões grant, deny ou revoke serão concedidas.

<class_type> O tipo de classe do protegível. Isso pode ser LOGIN, DATABASE, OBJECTO, SCHEMA, ROLE, ou USER. As permissões também podem ser concedidas para o SERVERclass_type, mas SERVER não é especificado para essas permissões. DATABASE não é especificado quando a permissão inclui a palavra DATABASE (por exemplo, ALTERAR QUALQUER DATABASE). Quando nenhum class_type é especificado e o tipo de permissão não é restrito para o servidor ou a classe de banco de dados, a classe é considerada OBJECT.

securable
O nome do logon, do banco de dados, da tabela, da exibição, do esquema, do procedimento, da função ou do usuário em que as permissões serão concedidas, negadas ou revogadas. O nome do objeto pode ser especificado com as regras de nomenclatura de três partes descritas em Convenções da sintaxe Transact-SQL.

TO principal [ , ...n ]
Uma ou mais entidades de segurança às quais as permissões estão sendo concedidas, negadas ou revogadas. Entidade de segurança é o nome de um logon, um usuário de banco de dados ou uma função de banco de dados.

FROM principal [ , ...n ]
Uma ou mais entidades de segurança das quais as permissões serão revogadas. Entidade de segurança é o nome de um logon, um usuário de banco de dados ou uma função de banco de dados. FROM só pode ser usado com uma REVOKE instrução. TO pode ser usado com GRANT, DENY, ou REVOKE.

COM GRANT OPÇÃO
Indica que o usuário autorizado também poderá conceder a permissão especificada a outras entidades.

CASCADE
Indica que a permissão foi negada ou revogada para a entidade de segurança especificada e para todas as outras entidades de segurança às quais a entidade de segurança concedeu a permissão. É obrigatório quando o principal tem permissão com GRANT OPTION.

GRANT OPÇÃO PARA
Indica que a habilidade de conceder a permissão especificada será revogada. Será necessário quando você estiver usando o argumento CASCADE.

Permissões

Para conceder uma permissão, o doente deve ter ou a permissão em si com a opção WITH GRANTOPTION, ou uma permissão superior que implique que a permissão foi concedida. Os proprietários de objetos podem conceder permissões nos objetos de sua propriedade. As entidades de segurança com a permissão CONTROL em um protegível podem conceder a permissão nesse protegível. Os membros das funções de banco de dado fixas db_owner e db_securityadmin podem conceder qualquer permissão no banco de dados.

Comentários gerais

Negar ou revogar permissões a uma entidade de segurança não afetará as solicitações com autorização aprovada que estiverem em execução no momento. Para restringir o acesso imediatamente, você precisa cancelar as solicitações ativas ou encerrar as sessões atuais.

Algumas instruções exigem várias permissões. Por exemplo, para criar uma tabela são necessárias as CREATE TABLE permissões no banco de datos e a ALTER SCHEMA permissão para a tabela que conterá a tabela.

Às vezes, o PDW (Analytics Platform System) executa procedimentos armazenados para distribuir as ações do usuário para os nós de computação. Portanto, a permissão execute para um banco de dados inteiro não pode ser negada. (Por exemplo, DENY EXECUTE ON DATABASE::<name> TO <user>; falhará.) Como uma solução alternativa, negue a permissão execute para esquemas de usuário ou objetos específicos (procedimentos).

No Microsoft Fabric, atualmente não podem CREATE USER ser executados explicitamente. Quando GRANT ou DENY for executado, o usuário será criado automaticamente.

No Microsoft Fabric, as permissões no nível do servidor não são gerenciáveis.

Permissões implícitas e explícitas

Uma permissão explícita é uma permissão GRANT ou DENY concedida a um principal por uma declaração GRANT ou DENY.

Uma permissão implícita é uma GRANT ou DENY permissão que um principal (login, usuário ou papel de banco de dados) herdou de outro papel de banco de dados.

Uma permissão implícita também pode ser herdada de uma permissão de cobertura ou pai. Por exemplo, UPDATE permissão em uma tabela pode ser herdada ao ter UPDATE permissão sobre o esquema que contém a tabela, ou permissão CONTROL sobre a tabela.

Encadeamento de propriedade

Quando vários objetos de banco de dados acessam uns aos outros sequencialmente, essa sequência é conhecida como cadeia. Embora essas cadeias não existam independentemente, quando o SQL Server se desvia de links em uma cadeia, o SQL Server avalia as permissões nos objetos do cliente de forma diferente do que faria se estivesse acessando os objetos separadamente. O encadeamento de propriedade tem implicações importantes para o gerenciamento de segurança. Para obter mais informações sobre cadeias de propriedade, veja Cadeias de Propriedades e Tutorial: Cadeias de Propriedade e Comutação de Contexto.

Lista de permissões

Permissões no nível do servidor

As permissões no nível do servidor podem ser concedidas, negadas e revogadas dos logons.

Permissões que se aplicam a servidores

• SERVIDOR DE CONTROLE

• ADMINISTRAR OPERAÇÕES EM MASSA

• Alterar Qualquer Conexão

• ALTERAR QUALQUER DATABASE

• CRIAR QUALQUER DATABASE

• ALTERAR QUALQUER EXTERNAL DATA SOURCE

• ALTERAR QUALQUER EXTERNAL FILE FORMAT

• ALTERAR QUALQUER LOGIN

• ALTERAR ESTADO DO SERVIDOR

• CONECTAR SQL

• VIEW QUALQUER DEFINIÇÃO

• VIEW QUALQUER DATABASE

• VIEW ESTADO DO SERVIDOR

Permissões que se aplicam a logons

• CONTROLE LIGADO LOGIN

• ALTER ON LOGIN

• PERSONIFICAR ON LOGIN

• VIEW DEFINIÇÃO

Permissões no nível do banco de dados

As permissões no nível do banco de dados podem ser concedidas, revogadas e negadas dos usuários de banco de dados e das funções de banco de dados definidas pelo usuário.

Permissões que se aplicam a todas as classes de banco de dados

• CONTROL

• ALTER

• VIEW DEFINIÇÃO

Permissões que se aplicam a todas as classes de banco de dados, exceto a usuários

• ASSUMA A RESPONSABILIDADE

Permissões que se aplicam somente a bancos de dados

• ALTERAR QUALQUER DATABASE

• ALTER ON DATABASE

• ALTERAR QUALQUER ESPAÇO DE DADOS

• ALTERAR QUALQUER ROLE

• ALTERAR QUALQUER SCHEMA

• ALTERAR QUALQUER USER

• BACKUP DATABASE

• CONECTE DATABASE

• CREATE PROCEDURE

• CREATE ROLE

• CREATE SCHEMA

• CREATE TABLE

• CREATE VIEW

• SHOWPLAN

Permissões que se aplicam somente a usuários

• IMPERSONATE

Permissões que se aplicam a bancos de dados, esquemas e objetos

• ALTER

• DELETE

• Execute

• INSERT

• SELECT

• UPDATE

• REFERENCES

Para obter uma definição de cada tipo de permissão, confira Permissões (Mecanismo de Banco de Dados).

Permissões padrão

A lista a seguir descreve as permissões padrão:

• Quando um login é criado usando a CREATE LOGIN instrução, o novo login recebe a permissão CONNECT SQL .

• Todos os logons são membros da função de servidor pública e não podem ser removidos dessa função pública.

• Quando um usuário de banco de dados é criado usando a CREATE USER permissão, o usuário recebe a permissão CONNECT no banco de dados.

• As entidades de segurança, incluindo a função pública, não têm nenhuma permissão explícita ou implícita por padrão.

• Quando um logon ou um usuário se torna o proprietário de um banco de dados ou de um objeto, o logon ou o usuário passa a ter todas as permissões no banco de dados ou no objeto. As permissões de propriedade não podem ser alteradas e não são visíveis como as permissões explícitas. As GRANTinstruções , DENY, e REVOKE não têm efeito sobre os proprietários.

• O logon sa tem todas as permissões no dispositivo. Semelhante às permissões de propriedade, as permissões de sa não podem ser alteradas e não são visíveis como as permissões explícitas. As GRANTinstruções , DENY, e REVOKE não têm efeito no login SA . O logon sa não pode ser renomeado.

• A instrução USE não requer permissões. Todas as entidades de segurança podem executar a instrução USE em qualquer banco de dados.

Exemplos: Azure Synapse Analytics e PDW (Analytics Platform System)

a. Concedendo uma permissão no nível do servidor para um logon

As duas instruções a seguir concedem uma permissão no nível do servidor para um logon.

GRANT CONTROL SERVER TO [Ted];  

GRANT ALTER ANY DATABASE TO Mary;  

B. Concedendo uma permissão no nível do servidor para um logon

O exemplo a seguir concede uma permissão no nível do servidor em um logon a uma entidade de segurança do servidor (outro logon).

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;  

C. Concedendo uma permissão no nível do banco de dados para um usuário

O exemplo a seguir concede uma permissão no nível do banco de dados em um usuário a uma entidade de segurança do banco de dados (outro usuário).

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

D. Concedendo, negando e revogando uma permissão de esquema

A seguinte GRANT declaração concede a Yuen a capacidade de selecionar dados de qualquer tabela ou visualização no esquema dbo.

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

A seguinte DENY afirmação impede Yuen de selecionar dados de qualquer tabela ou visualização no esquema dbo. Yuen não poderá ler os dados mesmo que tenha recebido a permissão de alguma outra maneira, como por associação de função.

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

A seguinte REVOKE declaração remove a DENY permissão. Agora, as permissões explícitas do Yuen são neutras. Yuen poderá selecionar dados de qualquer tabela por meio de outras permissões implícitas, como uma associação de função.

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

E. Demonstrando a cláusula opcional OBJECT::

Como OBJECT é a classe padrão para uma instrução de permissão, as duas instruções a seguir são iguais. A cláusula OBJECT:: é opcional.

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

GRANT UPDATE ON dbo.StatusTable TO [Ted];