SQL Academy · Aula

Permissões em nível de coluna

Oculte colunas confidenciais.

Permissões em nível de coluna é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.

Por que as permissões no nível de coluna são importantes

Nem todo usuário deve ver todas as colunas de uma tabela. Uma coluna de salário, um hash da senha ou um número do cartão de crédito pode estar na mesma tabela que dados perfeitamente públicos, como um nome de usuário ou e-mail.

As permissões no nível de coluna permitem conceder acesso a colunas específicas em vez da tabela inteira, mantendo os dados confidenciais ocultos de usuários que não têm motivo profissional para vê-los.

GRANT em uma tabela inteira

Por padrão, GRANT SELECT ON table dá a um papel a capacidade de ler todas as colunas. Isso é adequado para dados públicos, mas é problemático quando a tabela mistura colunas confidenciais e não confidenciais.

A consulta abaixo dá ao papel analyst acesso completo de leitura à tabela employees — incluindo salário e SSN.

GRANT SELECT ON employees TO analyst;

Sintaxe de GRANT no nível de coluna

O PostgreSQL (e o SQL padrão) permite listar nomes de colunas específicos dentro de uma instrução GRANT. A sintaxe é:

GRANT privilege (col1, col2) ON table TO role;

O exemplo abaixo concede ao papel analyst permissão para ler somente id, name e department — mas NOT salary ou ssn.

GRANT SELECT (id, name, department) ON employees TO analyst;

Verificando permissões de coluna

Você pode inspecionar os privilégios no nível de coluna no PostgreSQL consultando a visualização information_schema.column_privileges. Ela lista qual beneficiário tem qual privilégio em qual coluna.

SELECT grantee, table_name, column_name, privilege_type
FROM information_schema.column_privileges
WHERE table_name = 'employees'
ORDER BY grantee, column_name;

O que acontece sem as colunas corretas

Se um papel tentar ler uma coluna à qual não recebeu acesso, o banco de dados retornará um erro de permissão negada. Somente referências a colunas permitidas serão bem-sucedidas.

Supondo que analyst tenha recebido acesso somente a id, name e department, a primeira consulta abaixo falhará; a segunda será bem-sucedida.

-- This will fail for analyst (no permission on salary):
-- SELECT id, name, salary FROM employees;

-- This succeeds:
SELECT id, name, department FROM employees;

Permissão de UPDATE no nível de coluna

As restrições no nível de coluna também se aplicam a UPDATE. Você pode permitir que um papel atualize somente colunas específicas — por exemplo, permitindo que um papel de suporte atualize o status de um usuário sem poder alterar seu email ou password_hash.

GRANT UPDATE (status) ON users TO helpdesk;

-- helpdesk can now run:
UPDATE users SET status = 'suspended' WHERE id = 42;

Ocultando colunas com visualizações

Outra abordagem comum é criar uma visualização que exponha somente as colunas seguras e, em seguida, conceder acesso à visualização em vez da tabela base. Isso funciona em todos os bancos de dados, não apenas naqueles que oferecem suporte a GRANT no nível de coluna.

CREATE VIEW public_employees AS
SELECT id, name, department, hire_date
FROM employees;

GRANT SELECT ON public_employees TO analyst;

Revogando acesso no nível de coluna

Assim como GRANT, você pode usar REVOKE com uma lista de colunas para remover o acesso a colunas específicas. Se um papel tiver acesso amplo no nível da tabela, talvez seja necessário revogá-lo completamente antes de conceder acesso restrito no nível de coluna.

-- Remove all SELECT on the table first
REVOKE SELECT ON employees FROM analyst;

-- Then grant only safe columns
GRANT SELECT (id, name, department) ON employees TO analyst;

Permissões de coluna e RLS juntas

As permissões no nível de coluna e a Segurança no nível de linha (RLS) são complementares. O RLS controla quais linhas um usuário pode ver; as permissões no nível de coluna controlam quais colunas dessas linhas ficam visíveis.

Juntos, eles formam um poderoso controle de acesso bidimensional: restrinja o conjunto de linhas e oculte campos confidenciais em cada linha.

-- RLS policy: employees can see only their own row
CREATE POLICY own_row ON employees
  FOR SELECT
  USING (user_id = current_user_id());

-- Column grant: hide salary even for own row
GRANT SELECT (id, name, department) ON employees TO employee_role;

Usando funções SECURITY DEFINER

Quando você precisa de uma lógica granular além de simples listas de colunas, uma função SECURITY DEFINER pode servir como uma ponte. A função é executada com os privilégios do proprietário (que tem acesso completo às colunas) e retorna somente o que escolher expor, independentemente de quem a chame.

CREATE OR REPLACE FUNCTION get_employee_summary(emp_id INT)
RETURNS TABLE(id INT, name TEXT, department TEXT)
SECURITY DEFINER
LANGUAGE sql AS
$$
  SELECT id, name, department
  FROM employees
  WHERE id = emp_id;
$$;

GRANT EXECUTE ON FUNCTION get_employee_summary(INT) TO analyst;

Projeto prático: segurança de colunas em camadas

Um padrão sólido para produção combina três camadas:

Propriedade da tabela — somente a conta de serviço do aplicativo é proprietária da tabela base.
Visualizações ou GRANT de coluna — os papéis de leitura têm acesso somente a colunas não confidenciais.
Colunas de auditoria — registre qual usuário e qual horário tocaram nos dados confidenciais por meio de gatilhos.

Isso garante que, mesmo que um papel receba privilégios excessivos acidentalmente em uma camada, as outras camadas ainda protejam os dados.

-- Layer 1: revoke public access
REVOKE ALL ON employees FROM PUBLIC;

-- Layer 2: expose safe columns via view
CREATE VIEW employee_public AS
SELECT id, name, department, hire_date FROM employees;

GRANT SELECT ON employee_public TO reporting_role;

-- Layer 3: audit trigger logs sensitive field reads (pseudocode)
-- CREATE TRIGGER audit_salary AFTER SELECT ON employees ...

Verificação rápida

Qual instrução SQL concede corretamente ao papel hr_viewer a capacidade de ler somente as colunas name e department da tabela employees?

Recapitulação: permissões no nível de coluna

As permissões no nível de coluna permitem restringir o acesso a campos individuais em vez de tabelas inteiras, mantendo dados confidenciais, como salários, SSNs e hashes de senhas, ocultos de papéis sem os privilégios necessários.

Principais conclusões:

Use GRANT SELECT (col1, col2) ON table TO role para restringir as colunas que podem ser lidas.
Use REVOKE com uma lista de colunas para remover o acesso a colunas específicas.
As visualizações são uma alternativa portátil que funciona em todos os bancos de dados.
Combine permissões no nível de coluna com RLS para obter um controle de acesso bidimensional.
As funções SECURITY DEFINER fornecem filtragem programática no nível de coluna com lógica adicional.

Quando aplicada de forma consistente, a segurança no nível de coluna é uma das maneiras mais simples e eficazes de impor o princípio do privilégio mínimo na camada de dados.

Perguntas Frequentes

A aula “Permissões em nível de coluna” é grátis?

Sim — o texto completo de “Permissões em nível de coluna” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.

O que vou aprender em “Permissões em nível de coluna”?

Oculte colunas confidenciais. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar SQL Academy?

Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.

Quanto tempo leva a aula “Permissões em nível de coluna”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de SQL Academy?

Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

Funções e privilégios
Políticas de segurança em nível de linha
Permissões em nível de coluna
Auditando o acesso

← Voltar para SQL Academy