Função Pública no SQL Server

As funções de banco de dados são semelhantes aos grupos do Windows — em vez de revogar ou conceder acesso a cada usuário separadamente, os administradores gerenciam o acesso concedendo ou revogando permissões das funções e alterando a associação das funções. Usar funções facilita a concessão e revogação precisa de privilégios para os usuários do banco de dados. E como vários usuários podem ser membros de uma função de banco de dados SQL, você pode gerenciar facilmente os direitos para um grupo inteiro de usuários de uma só vez.

In this post, we explain the public role in Microsoft SQL Server and some of the best practices related to it. (We are deliberately using lowercase letters here, since that is how the public role is spelled in the SQL Server world, unlike in the Oracle world.)

Tipos de Funções no SQL Server

O Microsoft SQL Server oferece vários tipos de funções pré-construídas:

• Funções de servidor fixas — São chamadas de “fixas” porque, exceto pela função pública, não podem ser modificadas ou excluídas
• Funções de banco de dados fixas
• Aplicação role — Um principal de banco de dados que pode ser usado por uma aplicação para executar com seu próprio conjunto de permissões (desativado por padrão)
• Funções definidas pelo usuário (a partir do SQL Server 2012) — Apenas permissões de nível de servidor podem ser adicionadas às funções definidas pelo

Onde o Papel Público se Encaixa

Todas as plataformas de banco de dados vêm com uma função predefinida chamada public, mas a implementação dessa função varia de acordo com a plataforma. No SQL Server, a função public faz parte da função fixa do servidor, e as permissões podem ser concedidas, negadas ou revogadas das permissões da função public do SQL Server.

Quando um login do SQL Server é criado, a função pública é atribuída ao login e não pode ser revogada. Se o principal do servidor não receber ou negar permissões específicas em um objeto protegível, o login herdará automaticamente as permissões para esse objeto que são concedidas à função pública.

Permissões Atribuídas à Função Pública

Para manter a segurança do SQL Server e cumprir com diversas regulamentações, incluindo PCI DSS e HIPAA, você precisa conhecer todos os papéis no nível do servidor e do banco de dados atribuídos a cada usuário. Vamos revisar as permissões no nível do servidor atribuídas ao papel público utilizando uma consulta transact-SQL no Management Studio:

      SELECT sp.state_desc as "Permission State", sp.permission_name as "Permission",
sl.name "Principal Name",sp.class_desc AS "Object Class", ep.name "End Point"
FROM sys.server_permissions AS sp
  JOIN sys.server_principals AS sl
    ON sp.grantee_principal_id = sl.principal_id
  LEFT JOIN sys.endpoints AS ep
    ON sp.major_id = ep.endpoint_id
WHERE sl.name = 'public';
      

Como a tabela acima mostra, apenas cinco permissões de nível de servidor são atribuídas à função pública. Observe que a permissão VIEW ANY DATABASE não concede aos usuários acesso a quaisquer objetos do banco de dados; ela apenas permite que eles listem todos os bancos de dados em uma instância do SQL Server. Portanto, se você criar um novo login e não atribuir outras funções ou permissões, o usuário só poderá fazer login na instância e não poderá fazer mais nada.

Permissões quando um Login do SQL Server é Atribuído a um Banco de Dados Padrão

Agora, vamos criar um login no SQL Server que utiliza a Autenticação SQL atribuindo um banco de dados padrão a esse usuário.

      USE [master]
GO
CREATE LOGIN [SQTest] WITH PASSWORD=N'nhggLboBn6SHolSWfipjzO/7GYw8M2RMbCt1LsCTK5M=', DEFAULT_DATABASE=[SBITS], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
      

Se fizermos login como esse usuário e listarmos todas as permissões no nível do banco de dados para o banco de dados padrão do usuário SBITS, podemos ver quais permissões eles têm. Como mostrado abaixo, o usuário Stealth não tem nenhuma permissão no banco de dados SBITS, embora esse seja o banco de dados padrão do usuário. Em outras palavras, só porque um banco de dados padrão de usuário é atribuído a um login de usuário, isso não significa que o usuário será capaz de ver os objetos do banco de dados ou os dados.

Para verificar isso, podemos usar o seguinte script:

      EXECUTE AS LOGIN= 'SQTest';
GO
USE SBITS
GO
SELECT dp.state_desc AS "Class Description", dp.permission_name AS "Permission Name",
SCHEMA_NAME(ao.schema_id) AS "Schema Name", ao.name AS "Object Name"
FROM sys.database_permissions dp
 LEFT JOIN sys.all_objects ao
  ON dp.major_id = ao.object_id
 JOIN sys.database_principals du
  ON dp.grantee_principal_id = du.principal_id
WHERE du.name = 'TestLoginPerms'
 AND ao.name IS NOT NULL
ORDER BY ao.name;
REVERT
      

Permissões herdadas pela função Pública no banco de dados Master

Uma vez que o login do usuário Stealth faz parte da public role por padrão, vamos ver as permissões herdadas pela public role no banco de dados master.

      USE master;
GO
 SELECT sp.state_desc AS "Permission State", sp.permission_name AS "Permission",
 SCHEMA_NAME(ao.schema_id) AS 'Schema', ao.name AS "Object Name"
 FROM sys.database_permissions sp
  LEFT JOIN sys.all_objects ao
     ON sp.major_id = ao.object_id
   JOIN sys.database_principals dp
     ON sp.grantee_principal_id = dp.principal_id
 WHERE dp.name = 'public'
 AND ao.name IS NOT NULL
 ORDER BY ao.name
      

In SQL Server 2016, there are 2,089 permissions stored in the master database granted to the public role. While it might seem daunting, they are all SELECT permissions and do not allow the user Stealth to make any changes in the master database. However, it is good practice to revoke some of the permissions based on the security policies in your organization. However, exercise caution while revoking them because some are required by users for normal operations in certain circumstances.

Simplificando a Revisão e Gestão de Funções

Em vez de recorrer a scripts personalizados complexos para descobrir os problemas relacionados ao papel público em uma instância de cada vez, considere usar Netwrix Access Analyzer. Esta plataforma de governança de acesso a dados pode enumerar todas as funções e privilégios do SQL Server, incluindo as funções públicas do SQL Server e as funções de banco de dados públicas do SQL Server, e produzir relatórios detalhados de direitos de forma imediata. Ela oferece uma visão unificada do papel público em todos os SQL Servers da sua empresa e ajuda a remediar quaisquer problemas com um clique de um botão.

Melhores práticas para a função Public no SQL Server

Recomendamos as seguintes melhores práticas quando se trata de papel público no SQL Server:

• Não conceda privilégios adicionais à função pública fora dos privilégios padrão, sob nenhuma circunstância. Se necessário, utilize uma função definida pelo usuário.
• Não modifique as permissões de nível de servidor para a função pública, pois isso pode impedir que os usuários se conectem ao banco de dados.
• Revise as permissões públicas toda vez que você atualizar seu SQL Server, pois a Microsoft frequentemente faz alterações na função pública.

FAQ

O que é a função de banco de dados público?

As permissões concedidas à função de banco de dados público são herdadas por cada usuário do banco de dados.

Quais permissões o papel público tem no SQL Server?

Todo login do SQL Server pertence à função de servidor público. Quando um principal de servidor não recebeu permissões específicas concedidas ou negadas em um objeto protegível, o usuário herda as permissões concedidas a esse objeto para a função pública.