Como criar database roles no SQL Server: passo a passo

João Barros 16 de July de 2026 4 min de leitura

Criar database roles no SQL Server é a forma mais limpa e escalável de controlar acessos. Em vez de dares permissões diretamente a cada utilizador, agrupas as permissões num papel — o role — e adicionas as pessoas a esse papel. Quando alguém muda de função, basta trocar o membro, e a governança de dados fica muito mais simples de gerir e auditar.

Pré-requisitos

Uma instância de SQL Server (2012 ou superior) ou Azure SQL Database.
SQL Server Management Studio (SSMS) ou Azure Data Studio para correr as queries.
Permissão CREATE ROLE na base de dados, ou pertencer ao role db_securityadmin.
Uma base de dados de testes onde possas experimentar sem risco.

Passo 1: Criar o database role

Um database role é um contentor de permissões ao nível da base de dados. Cria um com o comando CREATE ROLE e dá-lhe um nome que descreva a função de negócio — por exemplo, quem só precisa de ler dados de vendas:

USE VendasDW;
GO

CREATE ROLE leitura_vendas;
GO

O SQL Server já traz roles fixos (como db_datareader ou db_owner), mas criar os teus próprios roles dá-te controlo fino sobre o que cada grupo pode fazer. O role fica criado, mas ainda vazio: sem permissões e sem membros. Isto é intencional — primeiro criamos o contentor, depois enchemo-lo de permissões.

Passo 2: Atribuir permissões ao role

Agora defines o que o role pode fazer com GRANT. Como o objetivo é governança, segue o princípio do menor privilégio: concede apenas o necessário. Neste exemplo damos permissão de leitura sobre um schema inteiro:

GRANT SELECT ON SCHEMA::vendas TO leitura_vendas;
GO

Repara que concedes a permissão ao role, e não a uma pessoa — é aí que está o ganho. Qualquer membro herda automaticamente tudo o que o role tiver, por isso não precisas de repetir o GRANT utilizador a utilizador. Se precisares de bloquear explicitamente uma ação, usa DENY, que tem sempre prioridade sobre GRANT.

Passo 3: Adicionar membros ao role

Para adicionar alguém, precisas de um utilizador na base de dados. Se ainda não existir, cria-o a partir de um login e depois junta-o ao role com ALTER ROLE ... ADD MEMBER:

-- cria um login e um utilizador (usa uma password forte)
CREATE LOGIN ana WITH PASSWORD = 'Muda_esta_Password_123!';
CREATE USER ana FOR LOGIN ana;
GO

-- adiciona o utilizador ao role
ALTER ROLE leitura_vendas ADD MEMBER ana;
GO

A partir daqui, a Ana consegue ler o schema vendas sem que lhe tenhas dado qualquer permissão direta. Podes adicionar tantos membros quantos precisares, sempre com o mesmo comando.

Boa prática: atribui permissões a roles, nunca diretamente a utilizadores. Assim, o acesso de cada pessoa resume-se aos roles a que pertence — fácil de ler e fácil de revogar.

Passo 4: Remover membros e gerir o role

Quando alguém muda de equipa, remove-se o membro sem mexer nas permissões do role:

ALTER ROLE leitura_vendas DROP MEMBER ana;
GO

Se precisares de mudar o nome do role, usa ALTER ROLE leitura_vendas WITH NAME = leitura_faturacao;. E para o eliminar, garante primeiro que não tem membros e corre DROP ROLE leitura_vendas;.

Verificar o resultado

Para confirmar quem pertence a cada role, consulta as vistas de sistema sys.database_role_members e sys.database_principals:

SELECT r.name AS role_name, m.name AS membro
FROM sys.database_role_members AS drm
JOIN sys.database_principals AS r ON drm.role_principal_id = r.principal_id
JOIN sys.database_principals AS m ON drm.member_principal_id = m.principal_id
ORDER BY r.name, m.name;

Deves ver a linha que liga leitura_vendas à Ana, enquanto ela ainda for membro. Para testares as permissões na prática, podes simular a sessão do utilizador e depois voltar ao teu contexto com REVERT:

EXECUTE AS USER = 'ana';
SELECT TOP (5) * FROM vendas.Faturas;   -- deve devolver dados
REVERT;

Conclusão

Com database roles, a gestão de acessos deixa de ser uma lista interminável de permissões individuais e passa a estar organizada por função: mais segura, mais fácil de auditar e alinhada com boas práticas de governança de dados. O próximo passo natural é mapear os perfis reais da tua organização — leitura, escrita, administração — e criar um role para cada um. Que funções de acesso existem hoje na tua base de dados que já podias transformar num role?