Introdução às permissões do Mecanismo de Banco de Dados

Aplica-se a:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Sistema de Plataforma de Análise (PDW)Base de dados SQL no Microsoft Fabric

Este artigo analisa alguns conceitos básicos de segurança e, em seguida, descreve uma implementação típica de permissões. As permissões no Mecanismo de Banco de Dados são gerenciadas no nível do servidor por meio de logons e funções de servidor, e no nível do banco de dados por meio de usuários e funções de banco de dados.

A base de dados SQL e a base de dados SQL no Microsoft Fabric oferecem as mesmas opções dentro de cada base de dados, mas as permissões ao nível do servidor não estão disponíveis.

No Banco de Dados SQL, consulte Tutorial: Proteger um banco de dados no Banco de Dados SQL do Azure. A autenticação do Microsoft Entra ID é recomendada. Para obter mais informações, consulte Tutorial: Criar usuários do Microsoft Entra usando aplicativos do Microsoft Entra.
Na base de dados SQL no Microsoft Fabric, o único método de autenticação suportado para utilizadores de base de dados é o Microsoft Entra ID. As funções e permissões no nível do servidor não estão disponíveis. Para obter mais informações, consulte Autorização no banco de dados SQL no Microsoft Fabric.

Note

O Microsoft Entra ID era conhecido anteriormente como Azure Ative Directory (Azure AD).

Agentes de segurança

Uma entidade de segurança é a identidade utilizada pelo SQL Server, à qual podem ser atribuídas permissões para executar ações. Os princípios de segurança geralmente são pessoas, ou grupos de pessoas, mas podem ser outras entidades que fingem ser pessoas. As entidades de segurança podem ser criadas e gerenciadas usando os exemplos Transact-SQL mostrados neste artigo ou usando o SQL Server Management Studio.

Logins

Logons são contas de usuário individuais para entrar no Mecanismo de Banco de Dados do SQL Server. O SQL Server e o Banco de dados SQL oferecem suporte a logons baseados na autenticação do Windows e logons baseados na autenticação do SQL Server. Para obter informações sobre os dois tipos de logins, consulte Escolher um modo de autenticação.

Funções de servidor fixas

No SQL Server, as funções de servidor fixas são um conjunto de funções pré-configuradas que fornecem um grupo conveniente de permissões no nível do servidor. Os logins podem ser adicionados às funções usando a ALTER SERVER ROLE ... ADD MEMBER instrução. Para obter mais informações, consulte ALTER SERVER ROLE. O Banco de dados SQL não oferece suporte às funções de servidor fixas, mas tem duas funções no master banco de dados (dbmanager e loginmanager) que funcionam como funções de servidor.

Funções de servidor definidas pelo usuário

No SQL Server, você pode criar suas próprias funções de servidor e atribuir permissões de nível de servidor a elas. Os logins podem ser adicionados às funções de servidor usando a ALTER SERVER ROLE ... ADD MEMBER instrução. Para obter mais informações, consulte ALTER SERVER ROLE. O Banco de dados SQL não oferece suporte às funções de servidor definidas pelo usuário.

Utilizadores de bases de dados

Para conceder acesso a um logon em um banco de dados, crie um usuário de banco de dados nesse banco de dados e mapeie o usuário do banco de dados para um logon. O nome de usuário do banco de dados geralmente é o mesmo que o nome de login por convenção, embora não precise ser o mesmo. Cada utilizador da base de dados mapeia para um único login. Um login pode ser mapeado para apenas um usuário em um banco de dados, mas pode ser mapeado como um usuário de banco de dados em vários bancos de dados diferentes.

Também podem ser criados usuários do banco de dados que não tenham um login correspondente. Esses usuários são chamados de usuários de banco de dados contidos. A Microsoft incentiva o uso de usuários de banco de dados contidos, porque facilita a movimentação do banco de dados para um servidor diferente. Como um logon, um usuário de banco de dados contido pode usar a autenticação do Windows ou a autenticação do SQL Server. Para obter mais informações, consulte Tornar seu banco de dados portátil usando bancos de dados contidos.

Existem 12 tipos de utilizadores com ligeiras diferenças na forma como se autenticam e quem representam. Para ver uma lista de usuários, consulte CREATE USER.

Funções de banco de dados fixas

As funções de banco de dados fixas são um conjunto de funções pré-configuradas que fornecem um grupo conveniente de permissões no nível do banco de dados. Usuários de banco de dados e funções de banco de dados definidas pelo usuário podem ser adicionados às funções de banco de dados fixas usando a ALTER ROLE ... ADD MEMBER instrução. Para obter mais informações, consulte ALTER ROLE.

Funções de banco de dados definidas pelo usuário

Os usuários com a CREATE ROLE permissão podem criar novas funções de banco de dados definidas pelo usuário para representar grupos de usuários com permissões comuns. Normalmente, as permissões são concedidas ou negadas a toda a função, simplificando o gerenciamento e o monitoramento de permissões. Os usuários do banco de dados podem ser adicionados às funções do banco de dados usando a ALTER ROLE ... ADD MEMBER instrução. Para obter mais informações, consulte ALTER ROLE.

Outros princípios

Outras entidades de segurança não discutidas aqui incluem funções de aplicativo e logins e usuários baseados em certificados ou chaves assimétricas.

Para obter um gráfico mostrando as relações entre usuários do Windows, grupos do Windows, logons e usuários de banco de dados, consulte Criar um usuário de banco de dados.

Cenário típico

O exemplo a seguir representa um método comum e recomendado de configuração de permissões.

No Windows Ative Directory ou Microsoft Entra ID

Crie um usuário para cada pessoa.
Crie grupos do Windows que representem as unidades de trabalho e as funções de trabalho.
Adicione os usuários do Windows aos grupos do Windows.

Se o usuário estará se conectando a muitos bancos de dados

Crie um login para os grupos do Windows. (Se você usar a autenticação do SQL Server, ignore as etapas do Ative Directory e crie logons de autenticação do SQL Server aqui.)
No banco de dados de usuários, crie um usuário de banco de dados para o logon que representa os grupos do Windows.
No banco de dados do usuário, crie uma ou mais funções de banco de dados definidas pelo usuário, cada uma representando uma função semelhante. Por exemplo, você pode ter uma função de analista financeiro e uma função de analista de vendas.
Adicione os usuários do banco de dados a uma ou mais funções de banco de dados definidas pelo usuário.
Conceda permissões às funções de banco de dados definidas pelo usuário.

Se o usuário estiver se conectando a apenas um banco de dados

No banco de dados de usuário, crie um usuário de banco de dados contido para o grupo Windows. (Se você usar a autenticação do SQL Server, ignore as etapas do Ative Directory e crie a autenticação do SQL Server do usuário de banco de dados contido aqui.)
No banco de dados do usuário, crie uma ou mais funções de banco de dados definidas pelo usuário, cada uma representando uma função semelhante. Por exemplo, você pode ter uma função de analista financeiro e uma função de analista de vendas.
Adicione os usuários do banco de dados a uma ou mais funções de banco de dados definidas pelo usuário.
Conceda permissões às funções de banco de dados definidas pelo usuário.

O resultado típico neste ponto é que um usuário do Windows é membro de um grupo do Windows. O grupo do Windows tem um logon no SQL Server ou no Banco de dados SQL. O login é mapeado para uma identidade de usuário no banco de dados de usuários. O usuário é membro de uma função de banco de dados. Agora você precisa adicionar permissões à função.

Atribuir permissões

A maioria das instruções de permissão tem o seguinte formato:

<authorization> <permission> ON <securable>::<name> TO <principal>;

<authorization> deve ser GRANT, REVOKEou DENY.
O <permission> estabelece a ação que você permite ou proíbe. O número exato de permissões difere entre o SQL Server e o Banco de Dados SQL do Azure. Para obter informações sobre permissões, consulte Permissões (Mecanismo de Banco de Dados) e consulte o gráfico mais adiante neste artigo.
ON <securable>::<name> é o tipo de protegível (servidor, objeto de servidor, banco de dados ou objeto de banco de dados) e o seu nome. Algumas permissões não são necessárias <securable>::<name> porque são inequívocas ou inadequadas no contexto. Por exemplo, a CREATE TABLE permissão não requer a <securable>::<name> cláusula (GRANT CREATE TABLE TO Mary; permite que Mary crie tabelas).
<principal> é a entidade de segurança (login, utilizador ou função) que recebe ou perde a permissão. Conceda permissões a funções sempre que possível.

A instrução de exemplo a seguir concede a UPDATE permissão, na Parts tabela ou exibição contida no Production esquema, para a função chamada PartsTeam:

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;

A instrução de exemplo a seguir concede a UPDATE permissão, no Production esquema e, por extensão, em qualquer tabela ou exibição contida nesse esquema, para a função chamada ProductionTeam, que é uma abordagem mais eficaz e vendável para atribuir permissões do que no nível de objeto individual:

GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;

As permissões são concedidas às entidades de segurança (logons, usuários e funções) usando a GRANT instrução. As permissões são explicitamente negadas usando o DENY comando. Uma permissão concedida ou negada anteriormente é removida usando a REVOKE instrução. As permissões são cumulativas, com o usuário recebendo todas as permissões concedidas ao usuário, login e quaisquer associações de grupo; no entanto, qualquer recusa de permissão substitui todas as concessões.

Caution

Um erro comum é tentar remover um GRANT usando DENY em vez de REVOKE. Isso pode causar problemas quando um usuário recebe permissões de várias fontes, o que pode ser um cenário comum. O exemplo a seguir demonstra o princípio.

O grupo de Vendas recebe permissões na tabela SELECT através da instrução OrderStatusGRANT SELECT ON OBJECT::OrderStatus TO Sales;. O usuário Jae é um membro da Sales função. Jae também recebeu SELECT permissão para a OrderStatus tabela sob seu próprio nome de usuário através da declaração GRANT SELECT ON OBJECT::OrderStatus TO Jae;. Suponha que o administrador deseja remover o GRANT para a Sales função.

Se o administrador executar corretamente REVOKE SELECT ON OBJECT::OrderStatus TO Sales;, Jae manterá o acesso SELECT à tabela OrderStatus por meio de sua instrução individual GRANT.
Se o administrador executar incorretamente DENY SELECT ON OBJECT::OrderStatus TO Sales;, então Jae, como membro da função Sales, terá a permissão SELECT negada porque o DENY para Sales substitui seu GRANT individual.

Note

As permissões podem ser configuradas usando o Management Studio. Encontre o elemento securizável no Explorador de Objetos, clique direito sobre o elemento securizável e selecione Propriedades. Selecione a página Permissões . Para obter ajuda sobre como usar a página de permissões, consulte Página de permissões ou elementos protegidos.

Hierarquia de permissões

As permissões têm uma hierarquia pai/filho. Ou seja, se você conceder SELECT permissão em um banco de dados, essa permissão incluirá SELECT permissão em todos os esquemas (filho) no banco de dados. Se você conceder SELECT permissão num esquema, ela incluirá SELECT permissão em todas as tabelas e visões no esquema. As permissões são transitivas: se você conceder SELECT permissão em um banco de dados, ele incluirá SELECT permissão em todos os esquemas (filho) e todas as tabelas e exibições (neto).

As permissões também têm permissões abrangentes. A CONTROL permissão em um objeto normalmente lhe dá todas as outras permissões no objeto.

Como a hierarquia pai/filho e a hierarquia de cobertura podem agir com a mesma permissão, o sistema de permissão pode ficar complicado. Por exemplo, vamos pegar uma tabela (Region), em um esquema (Customers), em um banco de dados (SalesDB).

CONTROL permissão na tabela Region inclui todas as outras permissões na tabela Region, incluindo ALTER, SELECT, INSERT, UPDATE, DELETE, e algumas outras permissões.
SELECT Customers do esquema que possui a tabela Region inclui a permissão SELECT sobre a tabela Region.

Assim, SELECT a permissão na tabela pode ser alcançada através de qualquer uma destas seis instruções:

GRANT SELECT ON OBJECT::Region TO Jae;

GRANT CONTROL ON OBJECT::Region TO Jae;

GRANT SELECT ON SCHEMA::Customers TO Jae;

GRANT CONTROL ON SCHEMA::Customers TO Jae;

GRANT SELECT ON DATABASE::SalesDB TO Jae;

GRANT CONTROL ON DATABASE::SalesDB TO Jae;

Conceder o mínimo de permissão

A primeira permissão listada anteriormente (GRANT SELECT ON OBJECT::Region TO Jae;) é a mais granular. Essa declaração é a permissão mínima possível que proporciona o SELECT. Nenhuma permissão para objetos subordinados está associada a ele. É um bom princípio sempre conceder o mínimo de permissão possível, mas você deve considerar conceder em níveis mais altos, a fim de simplificar o sistema de concessão.

Portanto, se Jae precisar de permissão para todo o esquema, conceda SELECT uma vez no nível do esquema, em vez de conceder SELECT no nível de tabela ou exibição muitas vezes. O design do banco de dados pode afetar drasticamente o sucesso dessa estratégia. Essa estratégia funciona melhor quando o banco de dados é projetado para que objetos que precisam de permissões idênticas sejam incluídos em um único esquema.

Tip

Ao projetar um banco de dados e seus objetos, planeje desde o início como os aplicativos e usuários acessam esses objetos. Use essas informações para controlar o acesso a tabelas, exibições, funções e procedimentos armazenados usando esquemas. Os esquemas permitem agrupar tipos de acesso mais facilmente.

Diagrama de permissões

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.

Captura de tela do PDF de permissões do Mecanismo de Banco de Dados.

Para obter um gráfico mostrando as relações entre as entidades de banco de dados e os objetos de servidor e banco de dados, consulte Hierarquia de permissões (Mecanismo de Banco de Dados).

Permissões versus funções fixas de servidor e banco de dados fixas

As permissões das funções de servidor fixas e das funções de banco de dados fixas são semelhantes, mas não exatamente iguais, às permissões granulares. Por exemplo, os membros da função de servidor fixa sysadmin têm todas as permissões na instância do SQL Server, assim como os logons com a CONTROL SERVER permissão.

Mas, conceder a CONTROL SERVER permissão não torna um logon um membro da função de servidor fixa sysadmin , e adicionar um login à função de servidor fixa sysadmin não concede explicitamente a permissão ao CONTROL SERVER login. Às vezes, um procedimento armazenado verifica as permissões verificando a função fixa e não verificando a permissão granular.

Por exemplo, desanexar um banco de dados requer associação à função fixa de banco de dados db_owner. A permissão equivalente CONTROL DATABASE não é suficiente. Estes dois sistemas operam em paralelo, mas raramente interagem um com o outro. A Microsoft recomenda o uso do sistema de permissões granular mais recente em vez de funções fixas sempre que possível.

Permissões de monitorização

As exibições a seguir retornam informações de segurança. Para todas as vistas relacionadas com segurança, consulte Vistas do catálogo de segurança (Transact-SQL).

View	Description
`sys.server_principals` ¹	Logons e funções de servidor definidas pelo usuário em um servidor
`sys.database_principals`	Usuários e funções definidas pelo usuário em um banco de dados
`sys.server_permissions` ¹	Permissões concedidas a logins e funções de servidor fixas definidas pelo usuário
`sys.database_permissions`	Permissões concedidas a usuários e funções de banco de dados fixas definidas pelo usuário
`sys.database_role_members`	Associação de funções de banco de dados
`sys.server_role_members` ¹	Subscrição de função de servidor

¹ Esta vista não está disponível na Base de Dados SQL.

Examples

As declarações a seguir retornam informações úteis sobre permissões.

A. Lista de permissões de banco de dados para cada usuário

Para retornar as permissões explícitas concedidas ou negadas em um banco de dados (SQL Server e Banco de dados SQL), execute a seguinte instrução Transact-SQL no banco de dados.

SELECT perms.state_desc AS State,
       permission_name AS [Permission],
       obj.name AS [on Object],
       dp.name AS [to User Name]
FROM sys.database_permissions AS perms
     INNER JOIN sys.database_principals AS dp
         ON perms.grantee_principal_id = dp.principal_id
     INNER JOIN sys.objects AS obj
         ON perms.major_id = obj.object_id;

B. Listar membros da função de servidor

Para retornar os membros das funções de servidor (somente SQL Server), execute a instrução a seguir.

SELECT roles.principal_id AS RolePrincipalID,
       roles.name AS RolePrincipalName,
       server_role_members.member_principal_id AS MemberPrincipalID,
       members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
     INNER JOIN sys.server_principals AS roles
         ON server_role_members.role_principal_id = roles.principal_id
     LEFT OUTER JOIN sys.server_principals AS members
         ON server_role_members.member_principal_id = members.principal_id;

C. Listar todos os principais de banco de dados que são membros de uma função a nível de banco de dados

Para retornar os membros das funções de banco de dados (SQL Server e Banco de dados SQL), execute a seguinte instrução no banco de dados.

SELECT dRole.name AS [Database Role Name],
       dp.name AS [Members]
FROM sys.database_role_members AS dRo
     INNER JOIN sys.database_principals AS dp
         ON dRo.member_principal_id = dp.principal_id
     INNER JOIN sys.database_principals AS dRole
         ON dRo.role_principal_id = dRole.principal_id;

Comentários

Esta página foi útil?

Last updated on 2025-11-18