Permissões (Motor de Base de Dados)

Aplica-se a:SQL ServerBase de Dados SQL do AzureInstância Gerida do Azure SQLAzure Synapse AnalyticsSistema de Plataforma de Análise (PDW)Ponto de Extremidade de Análise SQL no Microsoft FabricArmazém no Microsoft FabricBase de Dados SQL no Microsoft Fabric

Cada elemento securizável do SQL Server tem permissões associadas que podem ser concedidas a uma entidade. As permissões no Mecanismo de Banco de Dados são gerenciadas no nível de servidor atribuído a logons e funções de servidor e no nível de banco de dados atribuído a usuários de banco de dados e funções de banco de dados. O modelo do 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 não. Por exemplo, a maioria das permissões de nível de servidor não pode ser concedida no Banco de Dados SQL do Azure e algumas permissões só fazem sentido no Banco de Dados SQL do Azure. Novas permissões estão sendo introduzidas gradualmente com 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. O 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.

Numa base de dados SQL no Microsoft Fabric, apenas são suportados utilizadores e funções de nível de base de dados. Logins ao nível de servidor, funções e a conta sa não estão disponíveis. Na base de dados SQL no Microsoft Fabric, o Microsoft Entra ID para utilizadores de base de dados é o único método de autenticação suportado. Para obter mais informações, consulte Autorização no banco de dados SQL no Microsoft Fabric.

Depois de compreender as permissões necessárias, pode aplicar permissões ao nível do servidor a inícios de sessão ou funções de servidor, e permissões ao nível da base de dados a utilizadores ou funções de base de dados, utilizando 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 são descritas as convenções gerais que são seguidas para nomear permissões:

• CONTROL

  Confere capacidades de propriedade ao beneficiário. O beneficiário efetivamente tem todas as permissões definidas no securable. Um principal que recebeu CONTROL também pode conceder permissões sobre o securável. Como o modelo de segurança do SQL Server é hierárquico, CONTROL em um escopo específico inclui implicitamente CONTROL em todos os protegíveis sob esse escopo. Por exemplo, CONTROL em um banco de dados implica todas as permissões no 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 dentro de todos os esquemas dentro do banco de dados.

• ALTER

  Confere a capacidade de alterar as propriedades, exceto a titularidade, de um determinado objeto seguro. Quando concedido em um escopo, o ALTER também concede a capacidade de alterar, criar ou descartar qualquer protegível que esteja contido nesse escopo. Por exemplo, a permissão ALTER em um esquema inclui a capacidade de criar, alterar e soltar objetos do esquema.

• ALTER ANY <Server Securable>, onde Server Securable pode ser qualquer servidor securable.

  Confere a capacidade de criar, alterar ou descartar instâncias individuais do Server Securable. Por exemplo, ALTER ANY LOGIN confere a capacidade de criar, alterar ou eliminar qualquer login na instância.

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

  Confere a capacidade de CRIAR, ALTERAR ou SOLTAR instâncias individuais do Database Securable. Por exemplo, ALTER ANY SCHEMA confere a capacidade de criar, alterar ou eliminar qualquer esquema na base de dados.

• ASSUMIR A RESPONSABILIDADE

  Permite que o beneficiário se aproprie do valor mobiliário sobre o qual é concedido.

• Personificar <Login>

  Permite que o beneficiário represente o login.

• PERSONIFICAR <UTILIZADOR>

  Permite que o beneficiário se faça passar pelo usuário.

• CRIAR <Servidor Protegível>

  Confere ao beneficiário a capacidade de criar o Server Securable.

• CREATE <Banco de Dados Protegível>

  Confere ao beneficiário a capacidade de criar o Banco de Dados Protegível.

• CREATE <Schema-contido Securable>

  Confere a capacidade de criar objetos de segurança contidos no esquema. No entanto, a permissão ALTER no esquema é necessária para criar o protegível em um esquema específico.

• VIEW DEFINIÇÃO

  Permite que o beneficiário acesse metadados.

• REFERENCES

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

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

Gráfico de permissões do SQL Server

A imagem a seguir mostra as permissões e suas relações entre si. Algumas das permissões de nível superior (como CONTROL SERVER) são listadas muitas vezes. Neste artigo, o cartaz é demasiado pequeno para ser lido. Você pode baixar o poster de Permissões do Mecanismo de Banco de Dados em tamanho real em formato PDF.

Permissões aplicáveis a valores mobiliários específicos

A tabela a seguir lista as principais classes de permissões e os tipos de objetos de segurança 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 da Base de Dados SQL do Azure só estão disponíveis para objetos básicos com suporte. As permissões de nível de servidor não podem ser concedidas no Banco de Dados SQL do Azure, no entanto, em alguns casos, as permissões de banco de dados estão disponíveis.

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.

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

• 9 novas permissões foram adicionadas em relação a objetos relacionados à segurança.

• Foram adicionadas 4 permissões para o Ledger.

• 3 permissões adicionais de banco de dados.

Para obter mais informações, consulte Novas permissões granulares para SQL Server 2022 e SQL do Azure para melhorar a aderência com 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 CRIPTOGRAFICAMENTE SEGURA

Nível da base 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 CRIPTOGRAFICAMENTE SEGURA

Permissões estendidas para eventos

Nível do servidor:

• CRIAR QUALQUER EVENT SESSION
• LARGUE QUALQUER EVENT SESSION
• ALTERAR QUALQUER EVENT SESSION OPÇÃO
• ALTERAR QUALQUER EVENT SESSION ADICIONAR EVENTO
• ALTERAR QUALQUER EVENT SESSION ELIMINAÇÃO DE EVENTO
• ALTERAR QUALQUER EVENT SESSION ATIVAR
• ALTERAR QUALQUER EVENT SESSION DESATIVAÇÃO
• ALTERAR QUALQUER EVENT SESSION ALVO DE ADIÇÃO
• ALTERAR QUALQUER EVENT SESSION DESTINO DE DROP

Todas estas permissões estão sob a mesma permissão principal: ALTER ANY EVENT SESSION

Nível da base de dados:

• CRIAR QUALQUER DATABASEEVENT SESSION
• LARGUE TODOS OS DATABASEEVENT SESSION
• ALTERAR QUALQUER DATABASEEVENT SESSION OPÇÃO
• ALTERAR QUALQUER DATABASEEVENT SESSION ADICIONAR EVENTO
• ALTERAR QUALQUER DATABASEEVENT SESSION DROP EVENT
• ALTERAR QUALQUER DATABASEEVENT SESSION ATIVAR
• ALTERAR QUALQUER DATABASEEVENT SESSION DESATIVAR
• ALTERAR QUALQUER DATABASEEVENT SESSION ALVO DE ADIÇÃO
• ALTERAR QUALQUER DATABASEEVENT SESSION DESTINO DE LARGADA

Todas estas permissões estão sob a mesma permissão parental: ALTERAR QUALQUER DATABASEEVENT SESSION

Permissões de objeto relacionadas à segurança

• CONTROLO (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• REFERÊNCIAS (CREDENTIAL)
• DESMASCARAR (OBJETO)
• DESMASCARAR (SCHEMA)
• VIEW QUALQUER REGISTO DE ERROS
• VIEW AUDITORIA DE SEGURANÇA DE SERVIDORES
• VIEW DATABASE AUDITORIA DE SEGURANÇA

Permissões do registro

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

Outras permissões de banco de dados

• ALTERAR QUALQUER TRABALHO EXTERNO
• ALTERAR QUALQUER FLUXO EXTERNO
• EXECUTAR QUALQUER ELEMENTO EXTERNO ENDPOINT

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

A verificação de permissões pode ser complexa. O algoritmo de verificação de permissão inclui associações de grupo sobrepostas e encadeamento de propriedade, permissões explícitas e implícitas, e pode ser afetado pelas permissões em classes protegíveis que contêm a entidade protegível. O processo geral do algoritmo é coletar todas as permissões relevantes. Se não for encontrado bloqueio DENY , o algoritmo procura 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ão e a permissão necessária.

• Contexto de segurança

  Este é o grupo de entidades que contribuem com permissões para a verificação de acesso. Estas são permissões relacionadas com o login ou utilizador atual, a menos que o contexto de segurança tenha sido alterado para outro login ou utilizador ao usar a EXECUTE AS instrução. O contexto de segurança inclui os seguintes princípios:

  • O login

  • O utilizador

  • Pertença a funções

  • Associações de grupo do Windows

  • Se a assinatura do módulo estiver a ser utilizada, qualquer login ou conta de utilizador para o certificado usado para assinar o módulo que o utilizador está a executar no momento, e as associações de funções relacionadas com essa entidade.

• Espaço de permissões

  Esta é a entidade segurável e quaisquer classes seguráveis que contenham o segurável. Por exemplo, uma tabela (uma entidade protegível) é contida pela classe protegível do esquema e pela classe protegível do banco de dados. O acesso pode ser afetado por permissões de tabela, esquema, banco de dados e nível de 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 que é necessária. Por exemplo, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL, e assim por diante.

  O acesso pode exigir várias permissões, como nos exemplos a seguir:

  • Um procedimento armazenado pode exigir tanto a permissão EXECUTE sobre o procedimento armazenado, bem como a permissão INSERT sobre várias tabelas referenciadas pelo procedimento armazenado.

  • Uma vista de gestão dinâmica pode exigir tanto a permissão VIEW SERVER STATE como a permissão SELECT na vista.

Etapas gerais do algoritmo

Quando o algoritmo está a determinar se deve permitir o acesso a um elemento de segurança, as etapas precisas que utiliza podem variar, dependendo das entidades principais e dos elementos de segurança envolvidos. No entanto, o algoritmo executa as seguintes etapas gerais:

1. Ignore 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. Permitir acesso se o encadeamento de propriedade for aplicável e se a verificação de acesso no objeto previamente na cadeia passar na verificação de segurança.

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

4. Para esse contexto de segurança, colete todas as permissões concedidas ou negadas para o espaço de permissão. A permissão pode ser explicitamente indicada como GRANT, GRANT COM 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 no esquema foi concedido, SELECT na tabela é concedido. Se o CONTROL for negado na tabela, o SELECT também será negado na tabela.

   Note

   A GRANT de uma permissão ao nível da coluna sobrepõe a DENY ao nível do objeto. Para mais informações, consulte DENY Permissões de Objetos.

5. Identifique a permissão necessária.

6. Falha na verificação de permissão se a permissão necessária for direta ou implicitamente negada a qualquer uma das identidades no contexto de segurança para os objetos no espaço de permissão.

7. A verificação de permissões é aprovada se a permissão necessária não tiver sido negada e a permissão necessária contiver uma GRANT ou uma GRANT com permissão GRANT, direta ou implicitamente, para qualquer uma das identidades no contexto de segurança relativamente a qualquer objeto no espaço de permissões.

Considerações especiais para permissões ao nível de coluna

As permissões de nível de coluna são concedidas com a sintaxe< table_name>(<nome_da_coluna>). Por exemplo:

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

Uma DENY na tabela é substituída por uma GRANT numa coluna. No entanto, uma DENY subsequente na tabela remove a coluna GRANT.

Examples

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

A. Retornar a lista completa de permissões concedidas

A instrução a seguir retorna todas as permissões do Mecanismo de Banco de Dados usando a fn_builtin_permissions função. Para obter mais informações, consulte sys.fn_builtin_permissions.

SELECT * FROM fn_builtin_permissions(default);
GO

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

O exemplo a seguir usa fn_builtin_permissions para exibir todas as permissões disponíveis para uma categoria de objeto seguro. O exemplo retorna permissões em assemblagens.

SELECT * FROM fn_builtin_permissions('assembly');
GO

C. Devolver as permissões concedidas à entidade de execução num objeto

O exemplo a seguir usa fn_my_permissions para retornar uma lista das permissões efetivas que são mantidas pelo principal chamador num elemento de segurança especificado. O exemplo retorna permissões em um objeto chamado Orders55. Para obter mais informações, consulte sys.fn_my_permissions.

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

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

O exemplo a seguir retorna permissões aplicáveis a um objeto chamado Yttrium. 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

Conteúdo relacionado

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