Permissões (Mecanismo de Banco de Dados)

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsAnalytics Platform System (PDW)Ponto de extremidade de análise de SQL no Microsoft FabricDepósito no Microsoft FabricBanco de dados SQL no Microsoft Fabric

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, consulte 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.

No banco de dados SQL no Microsoft Fabric, há suporte apenas para usuários e funções no nível do banco de dados. Logins, funções no nível do servidor e a conta sa não estão disponíveis. No banco de dados SQL no Microsoft Fabric, a ID do Microsoft Entra para usuários do banco de dados é o único método de autenticação com suporte. Para obter mais informações, consulte Autorização no banco de dados SQL no Microsoft Fabric.

Depois de entender as permissões necessárias, você pode aplicar permissões no nível do servidor a logins ou funções de servidor, e permissões no nível do banco de dados a 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, consulte Introdução às permissões do 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>, 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

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

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 Pôster de Permissões do Mecanismo de Banco de Dados em tamanho completo 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 do servidor:

• VIEW QUALQUER DEFINIÇÃO DE SEGURANÇA
• VIEW QUALQUER DEFINIÇÃO DE DESEMPENHO
• VIEW ESTADO DE SEGURANÇA DO SERVIDOR
• VIEW ESTADO DE DESEMPENHO DO SERVIDOR
• VIEW QUALQUER DEFINIÇÃO PROTEGIDA CRIPTOGRAFICAMENTE

Nível do banco de dados:

• VIEW DATABASE ESTADO DE SEGURANÇA
• VIEW DATABASE ESTADO DE DESEMPENHO
• VIEW DEFINIÇÃO DE SEGURANÇA
• VIEW DEFINIÇÃO DE DESEMPENHO
• VIEW DEFINIÇÃO PROTEGIDA CRIPTOGRAFICAMENTE

Permissões de Eventos Estendidos

Nível do servidor:

• CRIAR QUALQUER EVENT SESSION
• Solte qualquer EVENT SESSION
• ALTER ANY EVENT SESSION OPTION
• ALTERAR QUALQUER EVENT SESSION ADICIONAR EVENTO
• ALTER ANY EVENT SESSION DROP EVENT
• ALTERAR QUALQUER EVENT SESSION HABILITAÇÃO
• ALTER ANY EVENT SESSION DISABLE
• ALTERAR QUALQUER EVENT SESSION ADICIONAR DESTINO
• ALTERAR QUALQUER EVENT SESSION DESTINO DE DESCARTE

Todas essas permissões pertencem à mesma permissão pai: ALTER ANY EVENT SESSION

Nível do banco de dados:

• CRIE QUALQUER DATABASEEVENT SESSION
• Solte qualquer DATABASEEVENT SESSION
• ALTERAR QUALQUER DATABASEEVENT SESSION OPÇÃO
• ALTERAR QUALQUER DATABASEEVENT SESSION ADICIONAR EVENTO
• ALTER ANY DATABASEEVENT SESSION DROP EVENT
• ALTERAR QUALQUER DATABASEEVENT SESSION ATIVAR
• ALTERAR QUALQUER DATABASEEVENT SESSION DESATIVAR
• ALTERAR QUALQUER DATABASEEVENT SESSION ADICIONAR DESTINO
• ALTERAR QUALQUER DATABASEEVENT SESSION DESTINO DE EXCLUSÃO

Todas essas permissões estão sob a mesma permissão principal: ALTER ANY DATABASEEVENT SESSION

Permissões de objeto relacionadas à segurança

• CONTROLE (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• REFERÊNCIAS (CREDENTIAL)
• REVELAR (OBJETO)
• Desmascarar (SCHEMA)
• VIEW QUALQUER LOG DE ERROS
• VIEW AUDITORIA DE SEGURANÇA DO SERVIDOR
• VIEW DATABASE AUDITORIA DE SEGURANÇA

Permissões do livro-razão

• ALTER LEDGER
• ALTERAR CONFIGURAÇÃO DO REGISTRO
• ATIVAR LIVRO-RAZÃO
• VIEW CONTEÚDO DO LIVRO-RAZÃO

Outras permissões do banco de dados

• ALTERAR QUALQUER TRABALHO EXTERNO
• ALTERAR QUALQUER STREAM EXTERNO
• EXECUTAR QUALQUER COMANDO EXTERNO 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 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. Para obter mais informações, consulte DENY Permissões 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. 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.

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;

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

Examples

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

A. 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, consulte sys.fn_builtin_permissions.

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, consulte sys.fn_my_permissions.

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)