sqlpostgresqlgrantprivileges

GRANT no SQL: privilegios em tabelas, esquemas e colunas com menor privilegio

Como conceder privilegios em tabelas, esquemas e colunas com GRANT, a diferenca entre privilegios de objeto e participacao em papel, e como projetar acesso com menor privilegio.

3 min de leituraReferencesql · postgresql · grant · privileges · roles · security

GRANT entrega o direito de fazer algo: ler uma tabela, inserir linhas, usar um esquema. No PostgreSQL um papel comum nao enxerga nada alem do que lhe foi permitido de forma explicita, entao um bom conjunto de comandos GRANT e o seu modelo de acesso. Deixe-o amplo demais e um analista reescreve sem querer os dados de producao.

Privilegios de tabela

A forma basica lista as acoes e o objeto, e depois o papel que recebe. Pegue as conhecidas users, orders e employees.

CREATE ROLE analyst NOLOGIN;

GRANT SELECT, INSERT ON orders TO analyst;
GRANT SELECT ON users TO analyst;

Os privilegios de tabela sao SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES e TRIGGER. A palavra ALL concede todos de uma vez:

GRANT ALL PRIVILEGES ON employees TO analyst;

Pegadinha: conceder SELECT em uma tabela nao basta se o analista nao consegue entrar no esquema. Para alcancar um objeto voce tambem precisa de USAGE no esquema que o contem:

GRANT USAGE ON SCHEMA public TO analyst;

Sem USAGE a consulta falha com permission denied for schema, mesmo que o privilegio de tabela exista tecnicamente.

Colunas e esquemas inteiros

Os privilegios podem ser estreitados ate colunas individuais. Isso ajuda quando employees.salary e sensivel mas o nome e o departamento podem ser lidos por todos.

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

Agora SELECT id, name FROM employees funciona, mas SELECT salary FROM employees e recusado. UPDATE tambem aceita colunas: GRANT UPDATE (status) ON orders TO analyst permite alterar apenas o status do pedido.

No sentido inverso, voce pode conceder em todas as tabelas de um esquema com um unico comando:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst;

Pegadinha importante: ALL TABLES IN SCHEMA so afeta as tabelas que existem no momento em que ele roda. Uma tabela criada amanha nao recebe o privilegio. Para conceder automaticamente daqui pra frente, configure ALTER DEFAULT PRIVILEGES:

ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO analyst;

WITH GRANT OPTION e a passagem de direitos

Por padrao, quem recebe um privilegio nao pode repassa-lo. WITH GRANT OPTION muda isso:

GRANT SELECT ON orders TO team_lead WITH GRANT OPTION;

Agora team_lead pode rodar o GRANT SELECT ON orders TO ... por conta propria. E comodo para delegar, mas arriscado: voce perde o controle de quem acaba tendo acesso. Outra pegadinha e que o REVOKE passa a precisar de CASCADE, senao a revogacao fica bloqueada por privilegios dependentes:

REVOKE SELECT ON orders FROM team_lead CASCADE;

CASCADE tambem revoga cada privilegio que team_lead distribuiu com base nessa grant option.

Privilegios de objeto versus participacao em papel

Sao dois mecanismos distintos que e facil confundir.

  • Um privilegio de objeto e um direito como SELECT ON orders, ligado a um objeto especifico.
  • A participacao em papel e GRANT role_a TO role_b, que torna role_b membro de role_a e lhe da todos os privilegios de role_a de uma vez.

Papeis de agrupamento sao a espinha dorsal de um controle de acesso gerenciavel:

CREATE ROLE readonly NOLOGIN;
GRANT USAGE ON SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

CREATE ROLE alice LOGIN PASSWORD 'secret';
GRANT readonly TO alice;

Agora alice le tudo por meio da participacao em readonly. Mude os privilegios de readonly e eles se aplicam a todos os membros de uma vez, sem nomear ninguem individualmente.

Projetar com menor privilegio

O principio do menor privilegio e simples: um papel recebe exatamente o que precisa para o seu trabalho e nem um byte a mais.

  • Nao conceda direitos diretamente aos usuarios; reuna-os em papeis de agrupamento (readonly, app_write, reporting).
  • Proteja colunas sensiveis com grants em nivel de coluna em vez de SELECT na tabela inteira.
  • Lembre que o dono da tabela e o superusuario tem acesso total que ignora o GRANT por completo; REVOKE nao os afeta.

Diferencas entre os bancos:

  • MySQL nao tem ALL TABLES IN SCHEMA; use GRANT SELECT ON mydb.* para um banco inteiro. Os grants por coluna existem: GRANT SELECT (name) ON employees TO 'analyst'@'%'.
  • ClickHouse suporta GRANT, papeis e WITH GRANT OPTION, mas nao tem o conceito de USAGE de esquema; os direitos sao concedidos no banco e na tabela diretamente.

A regra base: de USAGE no esquema, os privilegios minimos nos objetos, agrupe por papeis e mantenha WITH GRANT OPTION sob controle rigoroso.

Pratique com exercícios reais

Resolva exercícios no treinador de SQL com correção instantânea e dicas.

Abrir o treinador