Permissões (Mecanismo de Banco de Dados)

Todo protegível do SQL Server 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 do SQL Server

• Algoritmo de verificação de permissão

• Exemplos

Convenções de nomenclatura de permissões

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

• CONTROL

  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>, em que o Protegível do Servidor pode ser qualquer servidor protegível.

  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>, em que o Protegível de Banco de Dados pode ser qualquer protegível no nível do 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.

• TAKE OWNERSHIP

  Habilita o usuário autorizado a assumir propriedade do protegível no qual é concedido.

• REPRESENTAR Logon<>

  Permite que o usuário autorizado represente o logon.

• IMPERSONATE <User>

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

• CREATE <Server Securable>

  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.

• Protegível contido no esquema CREATE <>

  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 DEFINITION

  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 uma FUNCTION ou VIEW com a cláusula WITH SCHEMABINDING que faz referência àquele 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 classes principais de permissões e os tipos de protegíveis aos quais elas podem ser aplicadas.

Permissões do SQL Server e do Banco de Dados SQL

A tabela a seguir fornece uma lista completa de permissões do SQL Server . Banco de Dados SQL permissões só estão disponíveis para protegíveis de base com suporte. As permissões no nível do servidor não podem ser concedidas em 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 localizado, o algoritmo irá procurar uma permissão GRANT que fornece 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 as permissões relacionadas com o logon ou usuário atual, a menos que o contexto de segurança tenha sido alterado para outro logon ou usuário por meio da instrução EXECUTE AS. 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, consulte 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 a permissão EXECUTE no procedimento armazenado e a permissão INSERT em várias tabelas que são referenciadas pelo procedimento armazenado.

  • Uma exibição de gerenciamento dinâmico pode exibir as permissões VIEW SERVER STATE e 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 declarada explicitamente como GRANT, GRANT WITH GRANT ou DENY; ou as permissões podem ser implícitas ou de cobertura 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.

   Observação

   Uma permissão GRANT no nível de coluna substitui DENY no nível de 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. Executa a verificação de permissão se a permissão necessária não tiver sido negada e a permissão necessária contiver uma permissão GRANT ou GRANT WITH GRANT direta ou implicitamente para quaisquer das identidades contidas no contexto de segurança para qualquer objeto do 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 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 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 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 interna OBJECT_ID é 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)