Como implementar Column-Level Security no SQL Server

Proteger colunas sensíveis — como salários, números de contribuinte ou contactos — é uma necessidade comum em qualquer base de dados. A Column-Level Security no SQL Server permite decidir, coluna a coluna, quem pode ver o quê, sem duplicar tabelas nem manter vistas complicadas. Com as permissões GRANT e DENY aplicadas diretamente às colunas, controlas o acesso com poucas linhas de T-SQL e mantens uma única fonte de dados.

Pré-requisitos

• Uma instância de SQL Server (2016 ou superior) ou Azure SQL Database.
• SQL Server Management Studio (SSMS) ou Azure Data Studio.
• Permissões de administrador na base de dados para criar utilizadores e conceder permissões.
• Conhecimentos básicos de T-SQL (SELECT e CREATE TABLE).

Passo 1: Criar uma tabela de exemplo

Para este exemplo, criamos uma tabela de funcionários com uma coluna sensível — o Salario — que queremos esconder da equipa de suporte, mantendo visíveis o nome e o departamento.

CREATE TABLE dbo.Funcionarios
(
    FuncionarioID INT PRIMARY KEY,
    Nome          NVARCHAR(100),
    Departamento  NVARCHAR(50),
    Salario       DECIMAL(10,2)
);

INSERT INTO dbo.Funcionarios VALUES
(1, N'Ana Silva',   N'Financeiro', 3200.00),
(2, N'Bruno Costa', N'Suporte',    1800.00);

Passo 2: Criar um utilizador e uma role

De seguida, criamos um utilizador de base de dados e uma role. Atribuir permissões a uma role, e não a cada pessoa, é uma boa prática de governança: quando alguém entra ou sai da equipa, basta adicionar ou remover o membro da role.

-- Database user without login (simple for testing)
CREATE USER SuporteUser WITHOUT LOGIN;

-- Role for the support team
CREATE ROLE SuporteRole;
ALTER ROLE SuporteRole ADD MEMBER SuporteUser;

Passo 3: Conceder acesso apenas às colunas permitidas

Aqui está o coração da Column-Level Security. Em vez de dar SELECT na tabela inteira, concedemos SELECT apenas nas colunas que a equipa pode consultar. A coluna Salario fica simplesmente de fora da lista.

GRANT SELECT ON dbo.Funcionarios(FuncionarioID, Nome, Departamento) TO SuporteRole;

Esta abordagem é mais segura e mais fácil de manter do que criar uma vista só com as colunas permitidas, porque as regras ficam guardadas no próprio motor de permissões do SQL Server. As permissões ao nível da coluna funcionam com SELECT, UPDATE e REFERENCES.

Passo 4: Bloquear uma coluna com DENY (padrão alternativo)

Às vezes é mais prático dar acesso a quase tudo e bloquear apenas uma ou duas colunas. Nesse caso, concede SELECT na tabela e usa DENY na coluna sensível. É importante saber que o DENY tem sempre prioridade sobre o GRANT: mesmo com permissão na tabela, a coluna negada continua inacessível.

GRANT SELECT ON dbo.Funcionarios TO SuporteRole;
DENY SELECT ON dbo.Funcionarios(Salario) TO SuporteRole;

Escolhe apenas um dos padrões — o do Passo 3 (lista de permitidos) ou o do Passo 4 (lista de proibidos) — consoante seja mais curto enumerar o que é permitido ou o que é proibido.

Verificar o resultado

Não precisas de iniciar sessão com outro utilizador para testar. Usa EXECUTE AS para assumir a identidade do SuporteUser na mesma janela e REVERT para voltar ao teu utilizador. Repara que um SELECT com asterisco falha, porque inclui a coluna protegida.

EXECUTE AS USER = 'SuporteUser';

-- This WORKS (only permitted columns)
SELECT FuncionarioID, Nome, Departamento FROM dbo.Funcionarios;

-- This FAILS: "The SELECT permission was denied on the column 'Salario'"
SELECT * FROM dbo.Funcionarios;

REVERT;

Se a primeira consulta devolve as linhas e a segunda termina com um erro de permissão na coluna Salario, então a Column-Level Security está configurada corretamente.

Conclusão

Em poucos minutos restringiste o acesso a uma coluna sensível sem duplicar dados nem criar objetos extra. O próximo passo natural é combinar esta técnica com Row-Level Security, para controlar linhas e colunas em simultâneo, ou organizar as permissões em roles por departamento para simplificar a gestão. Qual é a primeira coluna da tua base de dados que devia ficar protegida já hoje?