O mapa de hoje

• Bloco 1 — por que ninguém deveria usar o postgres no dia a dia
• Bloco 2 — CREATE ROLE, GRANT e REVOKE
• Bloco 3 — privilégio mínimo, views como proteção e LGPD
• Bloco 4 — mão na massa: criar uma role restrita e testar que ela é restrita

Retomando a Aula 15

• Quais funções do CRUD precisam de commit()?
• A view guarda os dados ou a consulta?
• Qual dos três usos de view tem a ver com segurança?

O que vocês vêm fazendo até agora

Desde a Aula 10, todo mundo conecta como postgres — o superusuário.

• Pode criar e apagar qualquer banco
• Pode apagar qualquer tabela
• Pode ler qualquer dado, de qualquer cliente
• Não existe nada que ele não possa fazer

O que dá errado

• O atendente apaga sem querer a tabela de clientes — e podia
• O estagiário vê o telefone e o CPF de todo mundo — e não precisava
• Um sistema invadido vira acesso total, não acesso parcial
• Ninguém sabe quem fez o quê: todo mundo é o mesmo usuário

Role — usuário e grupo na mesma palavra

Checagem do Bloco 1

Criar a role

CREATE ROLE atendente WITH LOGIN PASSWORD 'senha_atendente';

GRANT — conceder

GRANT CONNECT ON DATABASE locadora TO atendente;
GRANT USAGE   ON SCHEMA public     TO atendente;

GRANT SELECT          ON jogo, cliente, plataforma TO atendente;
GRANT SELECT, INSERT  ON emprestimo                TO atendente;

Os privilégios que existem

REVOKE — retirar

REVOKE INSERT ON emprestimo FROM atendente;

Role de grupo — concedendo para vários de uma vez

CREATE ROLE equipe_balcao;                    -- sem LOGIN: é um grupo
GRANT SELECT ON jogo, plataforma TO equipe_balcao;

CREATE ROLE ana   WITH LOGIN PASSWORD '...';
CREATE ROLE bruno WITH LOGIN PASSWORD '...';

GRANT equipe_balcao TO ana, bruno;            -- os dois herdam as permissões

Onde ver as permissões no pgAdmin

1. Clique com o botão direito na tabela → Properties…
2. Abra a aba Security
3. A lista mostra quem tem qual privilégio
4. Dá para conceder e revogar por aqui também, sem escrever SQL

Checagem do Bloco 2

O princípio do privilégio mínimo

Desenhando as permissões do negócio

Antes de escrever GRANT, responda: quem precisa fazer o quê em qual tabela?

View como proteção

CREATE VIEW catalogo_publico AS
SELECT titulo, genero, ano_lancamento FROM jogo;

GRANT SELECT ON catalogo_publico TO estagiario;
-- e NENHUM grant na tabela jogo

Dados pessoais — não é só boa prática

• Nome, telefone, CPF e e-mail de cliente são dados pessoais
• A LGPD (Lei 13.709/2018) exige que o acesso seja limitado ao necessário
• Vazamento gera multa para a empresa e dano para a pessoa

Erro comum — testar a permissão com o próprio postgres

No pgAdmin: crie uma segunda conexão de servidor, com o usuário da role e a senha dela. Assim dá para alternar entre as duas.

Checagem do Bloco 3