Permissões (Mecanismo de Banco de Dados)

Cada SQL Server protegível tem permissões associadas que podem ser concedidas a uma entidade de segurança. Este tópico fornece as seguintes informações:

• Convenções de nomenclatura de permissões

• Permissões relacionadas a protegíveis específicos

• permissões de SQL Server

• Algoritmo de verificação de permissão

• Examples

Convenções de nomenclatura de permissões

A seguir, encontram-se as convenções gerais a serem adotadas ao se nomear permissões:

• CONTROLE

  Confere capacidades de propriedade ao usuário autorizado. O usuário autorizado efetivamente tem todas as permissões definidas no protegível. Uma entidade à qual foi concedido CONTROL também pode conceder permissões no protegível. Como o modelo de segurança do SQL Server é hierárquico, CONTROL em um escopo específico inclui implicitamente CONTROL sobre todos os protegíveis naquele escopo. Por exemplo, CONTROL em um banco de dados implica todas as permissões do banco de dados, todas as permissões em todos os assemblies no banco de dados, todas as permissões em todos os esquemas no banco de dados e todas as permissões em objetos de todos os esquemas no banco de dados.

• ALTER

  Confere a capacidade de alterar as propriedades, menos a propriedade de um protegível específico. Quando concedido em um escopo, ALTER também concede a capacidade de alterar, criar ou descartar qualquer protegível contido naquele escopo. Por exemplo, a permissão ALTER em um esquema inclui a capacidade de criar, alterar e descartar objetos do esquema.

• ALTER ANY <Server Securable>, onde Server Securable pode ser qualquer protegível do servidor.

  Confere a capacidade de criar, alterar ou remover instâncias individuais do Protegível de Servidor. Por exemplo, ALTER ANY LOGIN confere a capacidade de criar, alterar ou descartar qualquer logon na instância.

• ALTER ANY <Database Securable>, onde Database Securable pode ser qualquer protegível no nível de banco de dados.

  Confere a capacidade de criar, alterar ou remover instâncias individuais do Protegível do Banco de Dados. Por exemplo, ALTER ANY SCHEMA confere a capacidade de criar, alterar ou descartar qualquer esquema no banco de dados.

• ASSUMA A RESPONSABILIDADE

  Permite que o usuário autorizado assuma a propriedade do protegível no qual ele é concedido.

• IMPERSONATE <Logon>

  Permite que o usuário autorizado represente o logon.

• IMPERSONATE <Usuário>

  Permite que o usuário autorizado represente o usuário.

• CREATE <Servidor Protegível>

  Confere ao usuário autorizado a habilidade para criar o Protegível de Servidor.

• CREATE <Database Securable>

  Confere ao usuário autorizado a habilidade de criar o Protegível de Banco de Dados.

• CREATE <Protegível contido em esquema>

  Confere a capacidade para criar o protegível contido em esquema. Porém, a permissão ALTER no esquema é necessária para criar o protegível em um esquema específico.

• VIEW DEFINIÇÃO

  Permite que o usuário autorizado acesse os metadados.

• REFERENCES

  A permissão REFERENCES em uma tabela é necessária para criar uma restrição FOREIGN KEY que faça referência àquela tabela.

  A permissão REFERENCES é necessária em um objeto para criar um FUNCTION ou VIEW com a cláusula WITH SCHEMABINDING, que faz referência a esse objeto.

Gráfico de permissões do SQL Server

Para obter um gráfico com tamanho de um cartaz de todas as permissões do Mecanismo de Banco de Dados em formato pdf, consulte https://github.com/microsoft/sql-server-samples/blob/master/samples/features/security/permissions-posters/Microsoft_SQL_Server_2017_and_Azure_SQL_Database_permissions_infographic.pdf.

Permissões aplicáveis a protegíveis específicos

A tabela a seguir lista as classes principais de permissões e os tipos de protegíveis aos quais elas podem ser aplicadas.

Permissões de banco de dados SQL e SQL Server

A tabela a seguir fornece uma lista completa de permissões do SQL Server. As permissões do Banco de Dados SQL só estão disponíveis para protegíveis de base com suporte. Não é possível conceder permissões no nível do servidor no Banco de Dados SQL, no entanto, em alguns casos, as permissões de banco de dados estão disponíveis.

Resumo do algoritmo de verificação de permissão

A verificação de permissões pode ser uma tarefa complexa. O algoritmo de verificação de permissão inclui a sobreposição de associações de grupo e o encadeamento de propriedades, as permissões explícita e implícita, e pode ser afetado pelas permissões em classes de protegíveis que contêm a entidade protegível. O processo geral do algoritmo é coletar todas as permissões pertinentes. Se nenhum bloqueio DENY for encontrado, o algoritmo procurará um GRANT que forneça acesso suficiente. O algoritmo contém três elementos essenciais, o contexto de segurança, o espaço de permissãoe a permissão necessária.

• Contexto de segurança

  Este é o grupo de entidades que fornece permissões à verificação de acesso. Essas são permissões relacionadas ao logon ou ao usuário atual, a menos que o contexto de segurança tenha sido alterado para outro logon ou usuário usando a EXECUTE AS instrução. O contexto de segurança inclui as seguintes entidades:

  • O logon

  • O usuário

  • Associações de função

  • Associações de grupo do Windows

  • Se a assinatura de módulo estiver sendo usada, qualquer logon ou conta de usuário do certificado usado para assinar o módulo que está em execução no momento e as associações de função associadas a essa entidade.

• Espaço de permissão

  É a entidade protegível e qualquer classe protegível que contém o protegível. Por exemplo, uma tabela (uma entidade protegível) é contida pela classe protegível de esquema e pela classe protegível de banco de dados. O acesso pode ser afetado por permissões em nível de tabela, esquema, banco de dados e servidor. Para obter mais informações, veja Hierarquia de permissões (Mecanismo de Banco de Dados).

• Permissão necessária

  O tipo de permissão exigido. Por exemplo, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, e assim por diante.

  O acesso pode exigir várias permissões, como as dos exemplos a seguir.

  • Um procedimento armazenado pode exigir tanto a permissão EXECUTE no procedimento armazenado quanto a permissão INSERT em diversas tabelas referenciadas pelo procedimento armazenado.

  • Uma exibição de gerenciamento dinâmico pode exigir tanto a permissão VIEW SERVER STATE quanto a permissão SELECT na exibição.

Etapas gerais do algoritmo

Quando o algoritmo estiver determinando a permissão do acesso a um protegível, as etapas que ele utiliza podem variar, dependendo das entidades e dos protegíveis que estão envolvidos. No entanto, o algoritmo executa as seguintes etapas gerais:

1. Ignorar a verificação de permissão se o logon for um membro da função de servidor fixa sysadmin ou se o usuário for o usuário dbo no banco de dados atual.

2. Permite o acesso se o encadeamento de propriedades for aplicável e se a verificação de acesso no objeto anterior da cadeia tiver passado pela verificação de segurança.

3. Agrega as identidades em nível de servidor e de banco de dados e as identidades do módulo assinado associadas ao chamador para criar o contexto de segurança.

4. Para esse contexto de segurança, reúna todas as permissões concedidas ou negadas ao espaço de permissão. A permissão pode ser explicitamente declarada como GRANT, GRANT WITH GRANT ou DENY; ou as permissões podem ser uma permissão implícita ou abrangente GRANT ou DENY. Por exemplo, a permissão CONTROL em um esquema implica CONTROL em uma tabela. E CONTROL em uma tabela implica SELECT. Portanto, se CONTROL foi concedida no esquema, SELECT será concedida na tabela. Se CONTROL foi negada na tabela, SELECT será negada na tabela.

   Note

   GRANT Uma permissão no nível da coluna substitui uma DENY no nível do objeto.

5. Identifica a permissão necessária.

6. Falha ao executar a verificação de permissão se a permissão necessária for direta ou implicitamente negada a quaisquer das identidades contidas no contexto de segurança para os objetos do espaço de permissão.

7. Passe a verificação de permissão se a permissão necessária não foi negada e se a permissão necessária contém uma GRANT ou uma GRANT permissão WITH GRANT direta ou implicitamente para qualquer uma das identidades no contexto de segurança de qualquer objeto no espaço de permissão.

Exemplos

Os exemplos nesta seção mostram como recuperar informações sobre permissões.

A. Retornando a lista completa de permissões que podem ser concedidas

A instrução a seguir retorna todas as permissões de mecanismo de banco de dados usando a função fn_builtin_permissions. Para obter mais informações, consulte sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);  
GO  

B. Retornando as permissões em uma classe específica de objetos

O exemplo a seguir usa fn_builtin_permissions para exibir todas as permissões que estão disponíveis para uma categoria de protegível. O exemplo retorna permissões em assemblies.

SELECT * FROM fn_builtin_permissions('assembly');  
GO    

C. Retornando as permissões concedidas à entidade de segurança em execução em um objeto

O exemplo a seguir usa fn_my_permissions para retornar uma lista das permissões efetivas mantidas pela entidade de chamada em um protegível especificado. O exemplo retorna permissões em um objeto denominado Orders55. Para obter mais informações, consulte sys.fn_my_permissions (Transact-SQL).

SELECT * FROM fn_my_permissions('Orders55', 'object');  
GO  

D. Retornando as permissões aplicáveis a um objeto especificado

O exemplo a seguir retorna permissões aplicáveis a um objeto denominado Yttrium. Observe que a função OBJECT_ID interna é usada para recuperar a ID do objeto Yttrium.

SELECT * FROM sys.database_permissions   
    WHERE major_id = OBJECT_ID('Yttrium');  
GO  

Consulte Também

Hierarquia de permissões (Mecanismo de Banco de Dados)
sys.database_permissions (Transact-SQL)