Nos últimos posts, aprendemos a criar tabelas, manipular dados, otimizar queries e até alterar estruturas em produção sem causar downtime. Mas à medida que seu ecossistema de tecnologia cresce, outra pergunta vital surge: quem tem permissão para fazer o quê no seu banco de dados?

Deixar a sua aplicação backend, seus analistas de dados e suas ferramentas de BI conectados ao banco usando o usuário postgres (o superusuário) é um dos maiores erros de segurança que você pode cometer. Um script malicioso, uma query de delete errada ou um vazamento de credenciais com esse nível de acesso pode destruir completamente a sua infraestrutura de dados.

Hoje, entramos no universo da DCL (Data Control Language). Vamos aprender como gerenciar usuários, criar papéis funcionais (Roles) e aplicar a política de privilégios mínimos no PostgreSQL usando os comandos GRANT e REVOKE.

O Conceito de Roles no PostgreSQL

Ao contrário de outros bancos de dados que diferenciam “usuários” de “grupos”, o PostgreSQL unificou tudo em um único conceito chamado Role (Papel).

• Uma Role pode agir como um usuário (se tiver permissão para fazer login).
• Uma Role pode agir como um grupo (servindo de contêiner para herança de permissões).

A boa prática de governança diz que nunca devemos dar permissões diretamente para o usuário de uma pessoa ou aplicação. Em vez disso, criamos um grupo (Role funcional), damos as permissões para esse grupo e depois associamos os usuários a ele.

Cenário Prático: Implementando o Privilégio Mínimo

Imagine que precisamos criar dois acessos no nosso banco: um para o time de Business Intelligence (que só pode ler dados) e outro para a nossa aplicação de microsserviço (que precisa ler e escrever, mas não pode apagar tabelas).

Passo 1: Criando as Roles de Grupo (Sem permissão de Login)

Primeiro, criamos os papéis que vão centralizar as permissões.

-- Grupo para leitura de relatórios
CREATE ROLE analista_bi_grupo;

-- Grupo para aplicações que manipulam dados
CREATE ROLE app_escrita_grupo;

Passo 2: Distribuindo Privilégios com o comando GRANT

O comando GRANT concede privilégios específicos (como SELECT, INSERT, UPDATE, DELETE) em objetos do banco (como tabelas e views) para uma determinada Role.

-- Liberando apenas leitura para o grupo de BI na tabela de servidores
GRANT SELECT ON TABLE servidores TO analista_bi_grupo;

-- Liberando leitura e escrita para o grupo da aplicação
GRANT SELECT, INSERT, UPDATE ON TABLE servidores TO app_escrita_grupo;

Passo 3: Criando os Usuários Finais (Com permissão de Login)

Agora sim, criamos as credenciais que a aplicação ou o analista vão usar para se conectar de verdade.

-- Usuário para o analista João
CREATE ROLE joao_analista WITH LOGIN PASSWORD 'SenhaForteAqui123';

-- Usuário para o microsserviço de deploy
CREATE ROLE api_deploy_user WITH LOGIN PASSWORD 'OutraSenhaSuperSegura';

Passo 4: Associando Usuários aos Grupos

Para que o João e a API herdem as permissões que configuramos no Passo 2, nós “colocamos” eles dentro de seus respectivos grupos:

GRANT analista_bi_grupo TO joao_analista;
GRANT app_escrita_grupo TO api_deploy_user;

A partir desse momento, se o João tentar rodar um DELETE FROM servidores;, o PostgreSQL vai rejeitar a query imediatamente com um erro de Permission Denied.

Removendo Permissões com o REVOKE

E se o escopo mudar e a aplicação de deploy não puder mais inserir novos dados, apenas atualizar os existentes? Usamos o comando REVOKE (Revogar/Retirar) para remover esse privilégio específico:

REVOKE INSERT ON TABLE servidores FROM app_escrita_grupo;

Boas Práticas de DCL na Cultura DevOps e Dados

1. Princípio do Privilégio Mínimo (PoLP): Cada usuário ou aplicação deve ter estritamente o acesso necessário para realizar sua função, e nada mais. Se a API só lê a tabela X, ela só ganha GRANT SELECT ON X.
2. Automação via Migrations: Assim como as tabelas (CREATE TABLE), a criação de Roles e a distribuição de privilégios devem ser versionadas em scripts de migração do seu pipeline de CI/CD ou gerenciadas via ferramentas de IaC como o Terraform (usando o provider do PostgreSQL). Evite dar GRANTs manuais direto no terminal de produção.
3. Cuidado com o GRANT ALL: Evite a preguiça de rodar GRANT ALL PRIVILEGES. Isso concede direitos de exclusão e modificações estruturais que raramente o usuário final deveria ter.

Conclusão

Entender a camada de DCL do PostgreSQL desmistifica a segurança de dados e aproxima o desenvolvimento da engenharia de confiabilidade (SRE). Garantir que os acessos sejam granulares e controlados via Roles protege a empresa contra vazamentos e mitiga drasticamente o impacto de falhas humanas ou bugs de código.

Com os conceitos de segurança de acesso consolidados, estamos prontos para avançar para o próximo nível de automação interna do banco de dados.

No próximo post da nossa seção de SQL, vamos falar sobre Triggers (Gatilhos). Vamos aprender como fazer o PostgreSQL reagir e executar ações de forma 100% automática sempre que um dado for inserido, atualizado ou deletado na sua infraestrutura. Até lá!

Como está a política de acessos no banco de dados da sua empresa hoje? Vocês usam o usuário root para tudo ou já aplicam a cultura de Roles e privilégios mínimos? Deixe seu comentário aqui embaixo!