Partilhar via

Permissões: CONCEDER, NEGAR, REVOGAR

  • Artigo

Aplica-se a:Azure Synapse AnalyticsAnalytics Platform System (PDW)ponto de extremidade de análise SQL no Microsoft FabricWarehouse no Microsoft Fabric

Use instruções GRANT e DENY para conceder ou negar uma permissão (como UPDATE) em um protegível (como um banco de dados, tabela, exibição, etc.) para uma entidade de segurança (um login, um usuário de banco de dados ou uma função de banco de dados). Use REVOKE para remover a concessão ou negação de uma permissão.

As permissões de nível de servidor são aplicadas aos logins. As permissões de nível de banco de dados são aplicadas a usuários e funções de banco de dados.

Para ver quais permissões foram concedidas e negadas, consulte as visualizações sys.server_permissions e sys.database_permissions. As permissões que não são explicitamente concedidas ou negadas a uma entidade de segurança podem ser herdadas por serem membros de 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 explicitamente nega que o principal tenha uma ou mais permissões.

  • REVOGAR remove existentes CONCEDER ou NEGAR permissões.

Transact-SQL convenções de sintaxe

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 para conceder, negar ou revogar.

ON [ <class_type> :: ] securable A cláusula ON descreve o parâmetro protegível no qual conceder, negar ou revogar permissões.

<class_type> O tipo de classe do protegível. Isso pode ser LOGIN, DE BANCO DE DADOS , OBJETO , ESQUEMA, FUNÇÃOou USUÁRIO. As permissões também podem ser concedidas ao SERVERclass_type, mas SERVER não é especificado para essas permissões. BANCO DE DADOS NÃO É ESPECIFICADO QUANDO A PERMISSÃO INCLUI A PALAVRA BANCO DE DADOS (por exemplo, ALTERAR QUALQUER BANCO DE DADOS). Quando nenhum class_type é especificado e o tipo de permissão não está restrito ao servidor ou classe de banco de dados, a classe é assumida como OBJECT.

securável
O nome do login, banco de dados, tabela, exibição, esquema, procedimento, função ou usuário no qual conceder, negar ou revogar permissões. O nome do objeto pode ser especificado com as regras de nomenclatura de três partes descritas em Transact-SQL convenções de sintaxe.

A principal [ ,...n ]
Uma ou mais entidades de segurança sendo concedidas, negadas ou revogadas permissões. Principal é o nome de um login, usuário de banco de dados ou função de banco de dados.

DE principal [ ,...n ]
Uma ou mais entidades de segurança das quais revogar permissões. Principal é o nome de um login, usuário de banco de dados ou função de banco de dados. FROM só pode ser usado com uma REVOGAR declaração. PARA pode ser usado com GRANT, DENYou REVOKE.

COM OPÇÃO DE SUBVENÇÃO
Indica que o beneficiário também terá a capacidade de conceder a permissão especificada a outros comitentes.

CASCATA
Indica que a permissão é negada ou revogada para a entidade de segurança especificada e para todas as outras entidades às quais a entidade de segurança concedeu a permissão. Obrigatório quando o responsável principal tem a permissão com GRANT OPTION.

OPÇÃO DE SUBVENÇÃO PARA
Indica que a capacidade de conceder a permissão especificada será revogada. Isso é necessário quando você estiver usando o argumento CASCADE.

Importante

Se a entidade de segurança tiver a permissão especificada sem a opção GRANT, a própria permissão será revogada.

Permissões

Para conceder uma permissão, o concedente deve ter a própria permissão com a COM OPÇÃO DE CONCESSÃO, ou deve ter uma permissão superior que implique que a permissão seja concedida. Os proprietários de objetos podem conceder permissões sobre os objetos que possuem. Entidades com permissão CONTROL em um protegível podem conceder permissão sobre esse protegível. Os membros do db_owner e db_securityadmin funções de banco de dados fixas podem conceder qualquer permissão no banco de dados.

Observações gerais

Negar ou revogar permissões a uma entidade de segurança não afetará as solicitações que passaram pela autorização e estão em execução no momento. Para restringir o acesso imediatamente, você deve cancelar solicitações ativas ou matar as sessões atuais.

Observação

A maioria das funções de servidor fixas não está disponível nesta versão. Em vez disso, use funções de banco de dados definidas pelo usuário. Os logins não podem ser adicionados à função de servidor fixa sysadmin . Conceder à permissão CONTROL SERVER aproxima a associação à função de servidor fixa sysadmin.

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

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

No Microsoft Fabric, atualmente o CREATE USER não pode ser executado explicitamente. Quando GRANT ou DENY é 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 de permissão explícita é uma CONCEDER ou NEGAR permissão dada a um principal por um GRANT ou DENY declaração.

Uma de permissão implícita é uma permissão GRANT ou DENY permissão que uma entidade de segurança (login, usuário ou função de banco de dados) herdou de outra função de banco de dados.

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

Encadeamento de propriedade

Quando vários objetos de banco de dados se acessam sequencialmente, a sequência é conhecida como cadeia de . Embora essas cadeias não existam de forma independente, quando o SQL Server atravessa os links em uma cadeia, o SQL Server avalia as permissões nos objetos constituintes de forma diferente do que faria se estivesse acessando os objetos separadamente. O encadeamento de propriedade tem implicações importantes para o gerenciamento da segurança. Para obter mais informações sobre cadeias de propriedade, consulte Ownership Chains e Tutorial: Ownership Chains and Context Switching.

Lista de permissões

Permissões de nível de servidor

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

Permissões que se aplicam a servidores

  • SERVIDOR DE CONTROLO

  • ADMINISTRAR OPERAÇÕES EM MASSA

  • ALTERAR QUALQUER LIGAÇÃO

  • ALTERAR QUALQUER BASE DE DADOS

  • CRIAR QUALQUER BASE DE DADOS

  • ALTERAR QUALQUER FONTE DE DADOS EXTERNA

  • ALTERAR QUALQUER FORMATO DE ARQUIVO EXTERNO

  • ALTERAR QUALQUER LOGIN

  • ESTADO DO SERVIDOR ALTER

  • CONECTAR SQL

  • VER QUALQUER DEFINIÇÃO

  • VER QUALQUER BASE DE DADOS

  • VER ESTADO DO SERVIDOR

Permissões que se aplicam a logins

  • CONTROLO NO INÍCIO DE SESSÃO

  • ALTER NO LOGIN

  • PERSONIFICAR NO LOGIN

  • VER DEFINIÇÃO

Permissões de nível de banco de dados

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

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

  • CONTROLO

  • ALTER

  • VER DEFINIÇÃO

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

  • APROPRIE-SE

Permissões que se aplicam apenas a bancos de dados

  • ALTERAR QUALQUER BASE DE DADOS

  • ALTER NA BASE DE DADOS

  • ALTERAR QUALQUER ESPAÇO DE DADOS

  • ALTERAR QUALQUER FUNÇÃO

  • ALTERAR QUALQUER ESQUEMA

  • ALTERAR QUALQUER UTILIZADOR

  • BANCO DE DADOS DE BACKUP

  • CONECTAR NO BANCO DE DADOS

  • CRIAR PROCEDIMENTO

  • CRIAR FUNÇÃO

  • CRIAR ESQUEMA

  • CRIAR TABELA

  • CRIAR VISTA

  • SHOWPLAN

Permissões que se aplicam apenas a usuários

  • PERSONIFICAR

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

  • ALTER

  • SUPRIMIR

  • EXECUTAR

  • INSERIR

  • SELECIONAR

  • ATUALIZAÇÃO

  • REFERÊNCIAS

Para obter uma definição de cada tipo de permissão, consulte Permissions (Mecanismo de Banco de Dados).

Permissões padrão

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

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

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

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

  • Todas as entidades de segurança, incluindo a função pública , não têm permissões explícitas ou implícitas por padrão.

  • Quando um login ou usuário se torna o proprietário de um banco de dados ou objeto, o login ou usuário sempre tem todas as permissões no banco de dados ou objeto. As permissões de propriedade não podem ser alteradas e não são visíveis como permissões explícitas. O GRANT, DENYe REVOKE declarações não têm efeito sobre os proprietários.

  • O sa login tem todas as permissões no aparelho. Semelhante às permissões de propriedade, as permissões sa não podem ser alteradas e não são visíveis como permissões explícitas. As GRANT, DENYe REVOKE declarações não têm efeito sobre sa login. O login 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 and Analytics Platform System (PDW)

Um. Concedendo uma permissão de nível de servidor para um login

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

GRANT CONTROL SERVER TO [Ted];  

GRANT ALTER ANY DATABASE TO Mary;

B. Concedendo uma permissão de nível de servidor para um login

O exemplo a seguir concede uma permissão de nível de servidor em um logon para uma entidade de servidor (outro login).

GRANT  VIEW DEFINITION ON LOGIN::Ted TO Mary;

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

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

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

D. Conceder, negar e revogar uma permissão de esquema

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

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

A seguinte instrução DENY impede Yuen de selecionar dados de qualquer tabela ou exibição no esquema dbo. Yuen não pode ler os dados, mesmo que ele tenha permissão de alguma outra forma, como através de uma associação de função.

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

A seguinte instrução REVOKE remove o DENY permissão. Agora, as permissões explícitas de Yuen são neutras. Yuen pode ser capaz de selecionar dados de qualquer tabela através de alguma outra permissão implícita, 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 as mesmas. A cláusula OBJECT:: é opcional.

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

GRANT UPDATE ON dbo.StatusTable TO [Ted];