Permissões: GRANT, DENY, REVOKE

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

Utilização GRANT de instruções e DENY para conceder ou negar uma permissão (como UPDATE) sobre um seguro (como uma base de dados, tabela, vista, etc.) a um principal de segurança (um login, um utilizador de base de dados ou um papel de base de dados). Use REVOKE para remover a concessão ou negar uma autorizaçã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 nega explicitamente ao principal a possibilidade de ter uma ou mais permissões.

• REVOKE remove permissões existentes GRANT ou DENY 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. Isto pode ser LOGIN, DATABASE, OBJECTO, SCHEMA, ROLE, ou USER. As permissões também podem ser concedidas ao 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 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. O 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 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 diretor tem autorização com GRANT a OPTION.

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

Permissões

Para conceder uma permissão, o concedente deve ter ou a própria permissão com a opção WITHGRANT, ou deve ter uma permissão superior que implique que a permissão está a ser 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.

Algumas instruções requerem várias permissões. Por exemplo, para criar uma tabela são necessárias as CREATE TABLE permissões na base de dados e a ALTER SCHEMA permissão para a tabela que irá conter.

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 não pode CREATE USER ser executado explicitamente. Quando GRANT ou DENY for executado, o utilizador 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, utilizador ou papel de base de dados) herdou de outro papel de base de dados.

Uma permissão implícita também pode ser herdada de uma permissão de cobertura ou pai. Por exemplo, UPDATE a permissão numa 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 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

• ALTER QUALQUER DATABASE

• CRIAR QUALQUER DATABASE

• ALTER QUALQUER EXTERNAL DATA SOURCE

• ALTER QUALQUER EXTERNAL FILE FORMAT

• ALTER QUALQUER LOGIN

• ESTADO DO SERVIDOR ALTER

• CONECTAR SQL

• VIEW QUALQUER DEFINIÇÃO

• VIEW QUALQUER DATABASE

• VIEW ESTADO DO SERVIDOR

Permissões que se aplicam a logins

• CONTROLO LIGADO LOGIN

• ALTER ON LOGIN

• IMITAR ON LOGIN

• VIEW 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

• VIEW 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

• ALTER QUALQUER DATABASE

• ALTER ON DATABASE

• ALTERAR QUALQUER ESPAÇO DE DADOS

• ALTER QUALQUER ROLE

• ALTER QUALQUER SCHEMA

• ALTER QUALQUER USER

• BACKUP DATABASE

• LIGAR-SE DATABASE

• CREATE PROCEDURE

• CREATE ROLE

• CREATE SCHEMA

• CREATE TABLE

• CREATE VIEW

• SHOWPLAN

Permissões que se aplicam apenas a usuários

• PERSONIFICAR

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

• ALTER

• DELETE

• EXECUTAR

• INSERT

• SELECT

• UPDATE

• 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 login é criado usando a CREATE LOGIN instrução, o novo login 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 utilizador de base de dados é criado usando a CREATE USER permissão, o utilizador da base de dados recebe a permissão CONNECT na base 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. As declarações GRANT, DENY, e REVOKE não têm efeito nos 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 GRANTinstruções , DENY, e REVOKE não têm efeito no login sa . 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 GRANT afirmação concede a Yuen a capacidade de selecionar dados de qualquer tabela ou vista no esquema dbo.

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

A seguinte DENY afirmação impede a Yuen de selecionar dados de qualquer tabela ou vista 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 REVOKE afirmação remove a 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];