Governança de dados: controlar acessos com GRANT em SQL

João Barros 05 de July de 2026 5 min de leitura

Controlar quem pode ler e alterar cada tabela é um dos pilares da governança de dados. O princípio do privilégio mínimo diz que cada pessoa deve ter apenas as permissões estritamente necessárias para o seu trabalho: nem mais, nem menos. Com os comandos GRANT, REVOKE e DENY do SQL Server, e usando papéis (roles) para organizar as permissões, este princípio fica simples de aplicar e fácil de auditar. Além de reduzir riscos de segurança, esta abordagem facilita auditorias e ajuda a cumprir regulamentos como o RGPD, que exigem saber quem acede a que dados.

Pré-requisitos

Uma instância de SQL Server ou uma base de dados no Azure SQL Database.
SQL Server Management Studio (SSMS) ou Azure Data Studio para correr as consultas.
Uma conta com permissões de administração (por exemplo, membro de db_owner) para criar papéis e conceder permissões.
Noções básicas de SQL: SELECT, tabelas e esquemas (schemas).

Passo 1: Criar um papel para agrupar utilizadores

Em vez de conceder permissões pessoa a pessoa, cria um papel (role) por função de negócio. Assim, quando alguém entra ou muda de equipa, só precisas de mexer no papel e não em dezenas de contas. Vamos criar um papel para os analistas de vendas.

CREATE ROLE analistas_vendas;

O papel começa sem qualquer permissão. É exatamente o que queremos: partir do zero e adicionar só o necessário.

Passo 2: Conceder apenas o necessário com GRANT

O comando GRANT atribui uma permissão. Para respeitar o privilégio mínimo, damos apenas leitura (SELECT) e só sobre os dados de vendas, e não sobre a base de dados inteira.

-- Ler todas as tabelas do esquema "vendas"
GRANT SELECT ON SCHEMA::vendas TO analistas_vendas;

-- Permissão mais fina: apenas uma tabela
GRANT SELECT ON OBJECT::vendas.encomendas TO analistas_vendas;

O operador SCHEMA:: aplica a permissão a todas as tabelas atuais e futuras do esquema, enquanto OBJECT:: atua numa única tabela. Escolhe o nível certo consoante a granularidade que precisas. Repara que não concedemos INSERT, UPDATE nem DELETE: um analista que só precisa de consultar dados não deve poder alterá-los.

Passo 3: Adicionar utilizadores ao papel

Agora ligamos as pessoas ao papel. Cada membro herda exatamente as permissões do papel, sem exceções.

ALTER ROLE analistas_vendas ADD MEMBER [maria];
ALTER ROLE analistas_vendas ADD MEMBER [joao];

Se amanhã entrar mais um analista, o processo é uma única linha. Podes ver a que papéis um utilizador pertence a qualquer momento nas propriedades da base de dados ou com consultas ao catálogo do sistema. Esta simplicidade é o que torna a governança sustentável ao longo do tempo.

Passo 4: Bloquear dados sensíveis com DENY

Às vezes queremos dar acesso a um esquema, mas proteger uma tabela específica com dados pessoais (PII). É aqui que entra o DENY, que tem prioridade sobre o GRANT.

-- Mesmo com SELECT no esquema, bloquear a tabela de dados pessoais
DENY SELECT ON OBJECT::vendas.clientes_pii TO analistas_vendas;

Regra de ouro: quando há um DENY e um GRANT para a mesma permissão, o DENY ganha. É a rede de segurança ideal para proteger dados sensíveis.

Passo 5: Remover permissões com REVOKE

As funções mudam. O REVOKE retira uma permissão concedida (ou anula um DENY), deixando o papel num estado neutro para essa permissão.

-- Retirar uma permissão de escrita concedida por engano
REVOKE INSERT ON SCHEMA::vendas FROM analistas_vendas;

-- Retirar um utilizador do papel
ALTER ROLE analistas_vendas DROP MEMBER [joao];

É importante não confundir REVOKE com DENY: o REVOKE remove a regra existente, enquanto o DENY bloqueia ativamente, mesmo que exista um GRANT.

Verificar o resultado

Há duas formas simples de confirmar que ficou tudo bem: consultar o catálogo de permissões e testar na pele do utilizador com EXECUTE AS.

-- Ver as permissões atribuídas ao papel
SELECT dp.permission_name, dp.state_desc, o.name AS objeto
FROM sys.database_permissions AS dp
LEFT JOIN sys.objects AS o ON o.object_id = dp.major_id
WHERE dp.grantee_principal_id = DATABASE_PRINCIPAL_ID('analistas_vendas');

-- Testar as permissões como se fosse a utilizadora
EXECUTE AS USER = 'maria';
SELECT TOP (1) * FROM vendas.encomendas;    -- deve funcionar
SELECT TOP (1) * FROM vendas.clientes_pii;  -- deve falhar (DENY)
REVERT;

Executa cada consulta e observa o resultado. Um erro de permissão numa das linhas não é uma falha do tutorial: é a governança a fazer o seu trabalho. Se a Maria conseguir ler vendas.encomendas mas for bloqueada em vendas.clientes_pii, o privilégio mínimo está a funcionar como esperado.

Conclusão

Com papéis, GRANT, DENY e REVOKE tens as peças essenciais para aplicar o privilégio mínimo e manter a governança de dados sob controlo. O próximo passo é rever estas permissões periodicamente e combiná-las com máscaras de dados (Dynamic Data Masking) e etiquetas de confidencialidade para uma proteção completa. Documenta também que papel dá acesso a quê; essa documentação vale ouro no dia de uma auditoria. Olhando para a tua base de dados, que tabela merecia um DENY ainda hoje?