Permissões (Mecanismo de Banco de Dados)

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure Azure Synapse Analytics PDW (Analytics Platform System)

Cada SQL Server protegível tem permissões associadas que podem ser concedidas a uma entidade de segurança. As permissões no mecanismo de banco de dados são gerenciadas no nível do servidor e atribuídas a funções de logon e de servidor, e no nível do banco de dados, são atribuídas a funções de usuários do banco de dados e funções de banco de dados. O modelo para o Banco de Dados SQL do Azure tem o mesmo sistema para as permissões de banco de dados, mas as permissões no nível do servidor não estão disponíveis. Este artigo contém a lista completa de permissões. Para obter uma implementação típica das permissões, veja Introdução às permissões do Mecanismo de Banco de Dados.

O número total de permissões para o SQL Server 2022 (16.x) é 292. O Banco de Dados SQL do Azure expõe 292 permissões. A maioria das permissões se aplica a todas as plataformas, mas algumas delas, não. Por exemplo, a maioria das permissões de nível de servidor não podem ser concedidas no banco de dados SQL do Azure, e algumas permissões só fazem sentido no Banco de Dados SQL do Azure. As novas permissões estão sendo introduzidas gradualmente nas novas versões. O SQL Server 2019 (15.x) expõe 248 permissões. O SQL Server 2017 (14.x) expôs 238 permissões. O SQL Server 2016 (13.x) expôs 230 permissões. O SQL Server 2014 (12.x) expôs 219 permissões. O SQL Server 2012 (11.x) expôs 214 permissões. SQL Server 2008 R2 (10.50.x) expôs 195 permissões. O artigo sys.fn_builtin_permissions especifica quais permissões são novas em versões recentes.

Assim que compreender os requisitos de permissões, você pode aplicar permissões no servidor para logons ou funções de servidor e permissões no banco de dados para usuários ou funções de banco de dados usando as instruções GRANT, REVOKE e DENY. Por exemplo:

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

Para obter dicas sobre como planejar um sistema de permissões, confira Introdução a permissões de mecanismo de banco de dados.

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 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>, em que 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.

• TAKE OWNERSHIP

  Habilita o usuário autorizado a assumir propriedade do protegível no qual é 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 <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.

• CREATE <Schema-contained Securable>

  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

A imagem a seguir mostra as permissões e as relações entre elas. Algumas das permissões de nível superior (como CONTROL SERVER) são listadas várias vezes. Neste artigo, o cartaz é pequeno demais para ser lido. Você pode baixar o Cartaz de permissões do mecanismo de banco de dados no formato 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

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

Novas permissões granulares adicionadas ao SQL Server 2022

As seguintes permissões são adicionadas ao SQL Server 2022:

• Foram adicionadas 10 novas permissões para permitir o acesso aos metadados do sistema.

• Foram adicionadas 18 novas permissões para eventos estendidos.

• Foram adicionadas 9 novas permissões quanto a objetos relacionados à segurança.

• Foram adicionadas 4 permissões para Razão.

• Mais 3 permissões de banco de dados adicionais.

Para obter mais informações, consulte Novas permissões granulares para SQL Server 2022 e SQL do Azure para melhorar a aderência com o PoLP.

Acesso a permissões de metadados do sistema

Nível de servidor:

• VIEW ANY SECURITY DEFINITION
• VIEW ANY PERFORMANCE DEFINITION
• VIEW SERVER SECURITY STATE
• VIEW SERVER PERFORMANCE STATE
• VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION

Nível de banco de dados:

• VIEW DATABASE SECURITY STATE
• VIEW DATABASE PERFORMANCE STATE
• VIEW SECURITY DEFINITION
• VIEW PERFORMANCE DEFINITION
• VIEW CRYPTOGRAPHICALLY SECURED DEFINITION

Permissões de Eventos Estendidos

Nível de servidor:

• CREATE ANY EVENT SESSION
• DROP ANY EVENT SESSION
• ALTER ANY EVENT SESSION OPTION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ALTER ANY EVENT SESSION ENABLE
• ALTER ANY EVENT SESSION DISABLE
• ALTER ANY EVENT SESSION ADD TARGET
• ALTER ANY EVENT SESSION DROP TARGET

Todas essas permissões estão sob a mesma permissão primária: ALTER ANY EVENT SESSION

Nível de banco de dados:

• CREATE ANY DATABASE EVENT SESSION
• DROP ANY DATABASE EVENT SESSION
• ALTER ANY DATABASE EVENT SESSION OPTION
• ALTER ANY DATABASE EVENT SESSION ADD EVENT
• ALTER ANY DATABASE EVENT SESSION DROP EVENT
• ALTER ANY DATABASE EVENT SESSION ENABLE
• ALTER ANY DATABASE EVENT SESSION DISABLE
• ALTER ANY DATABASE EVENT SESSION ADD TARGET
• ALTER ANY DATABASE EVENT SESSION DROP TARGET

Todas essas permissões estão sob a mesma permissão primária: ALTER ANY DATABASE EVENT SESSION

Permissões de objeto relacionadas à segurança

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• REFERENCES (CREDENTIAL)
• UNMASK (OBJECT)
• UNMASK (SCHEMA)
• VIEW ANY ERROR LOG
• VIEW SERVER SECURITY AUDIT
• VIEW DATABASE SECURITY AUDIT

Permissões do razão

• ALTER LEDGER
• ALTER LEDGER CONFIGURATION
• HABILITAR RAZÃO
• VIEW LEDGER CONTENT

Outras permissões do banco de dados

• ALTER ANY EXTERNAL JOB
• ALTER ANY EXTERNAL STREAM
• EXECUTE ANY EXTERNAL ENDPOINT

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, 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 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. Leia mais a respeito aqui: Permissões de objeto DENY (Transact-SQL).

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.

Considerações especiais para permissões no nível da coluna

Permissões em nível de coluna são concedidas com a sintaxe <table_name>(<column _name>). Por exemplo:

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

DENY na tabela é substituído por GRANT em uma coluna. No entanto, um DENY posterior na tabela removerá a coluna GRANT.

Exemplos

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

R. Retornar 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, veja sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);
GO

B. Retornar 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. Retornar 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, veja sys.fn_my_permissions (Transact-SQL).

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

D. Retornar 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 o ID do objeto Yttrium.

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

Conteúdo relacionado

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