Gerenciamento de acesso e segurança

Imagina um pesadelo: você é o admin do banco de dados e, do nada, uma tabela importante com dados dos clientes simplesmente... some. Quem fez isso? Por quê? Talvez tenha sido um estagiário sem experiência que acidentalmente mandou um DROP TABLE. Ou talvez foi um usuário mal-intencionado que tinha acesso ao banco... Seja lá o que for, já era! Só resta acordar, respirar fundo e começar a estudar como proteger bancos de dados. Porque banco sem segurança é tipo casa sem fundação.

Pra bancos de dados, a segurança tem que ser top pra evitar ameaças como:

• Acesso não autorizado: alguém consegue acessar dados que não deveria ver.
• Vazamento de dados: senhas, cartões de crédito ou informações confidenciais caem nas mãos erradas.
• SQL injection: aquele truque malandro que permite ao atacante manipular seu banco usando queries mal protegidas.
• Erros humanos: deletar dados sem querer ou fazer uma alteração que não dá pra desfazer.

No PostgreSQL, a segurança é feita em vários níveis: desde a criação de roles e controle de permissões até restrições de acesso pela rede. Isso permite configurar direitinho quem pode fazer o quê com seus dados.

Níveis principais de segurança no PostgreSQL

No PostgreSQL, existem três níveis principais onde você pode controlar o acesso:

1. Gerenciamento de acesso no nível do banco de dados. Nesse nível, você decide quem pode se conectar ao seu banco e o que o usuário pode fazer depois de conectado. Por exemplo, dá pra bloquear alguns usuários de entrar no banco. Outros podem só ler os dados. O principal instrumento aqui são as roles.

2. Controle de acesso no nível de tabelas, linhas e colunas.

No PostgreSQL, o acesso aos dados pode ser bem detalhado. Você pode:

• Permitir que o usuário leia só certas colunas.
• Permitir leitura na tabela só se o usuário for o dono da linha. Isso se chama ROW LEVEL SECURITY (RLS), e a gente vai ver isso em detalhes nas próximas aulas.
• Restringir o acesso só pra partes do banco (schemas) onde estão os dados importantes.

3. Configuração de acesso pela rede. O banco pode ser configurado pra aceitar conexões só de clientes confiáveis. Isso é feito no arquivo de configuração do PostgreSQL chamado pg_hba.conf. Com esse arquivo, dá pra liberar acesso só da máquina local ou de certos IPs.

Ferramentas de segurança do PostgreSQL

Bora ver quais ferramentas de segurança o PostgreSQL oferece e como elas funcionam na prática.

Vamos começar com roles e privilégios — a base do sistema de controle de acesso. No PostgreSQL, uma role não é só um usuário, é algo mais flexível. Pode representar uma pessoa ou um grupo inteiro. Por exemplo, você pode criar uma role chamada manager que tem acesso total à tabela de pedidos, e pro estagiário serve uma role intern, que só pode ler — assim ele não faz besteira sem querer.

As roles podem ser configuradas de várias formas: dar mais ou menos permissões pra cada uma, ou até permitir que uma role herde permissões de outra. É por elas que você define quem pode se conectar, quais schemas e tabelas estão disponíveis, e até quais linhas podem ser vistas ou alteradas.

Depois vêm os arquivos de configuração. No PostgreSQL, tem dois arquivos principais que são super importantes pra segurança.

O primeiro é o pg_hba.conf. Ele controla o acesso pela rede ao banco. É aqui que você define quem pode se conectar ao servidor, de qual IP e como vai ser feita a autenticação. Se quiser liberar acesso só pra certas máquinas ou usuários — é aqui que faz.

O segundo arquivo é o postgresql.conf. Ele cuida das configurações gerais do servidor, e entre outras coisas, define parâmetros de logging e auditoria. Isso permite monitorar quem faz o quê, perceber atividades suspeitas e investigar quando precisar.

Por fim, logging e auditoria. "Logs são seus melhores amigos". Parece estranho, mas pra quem administra banco de dados, essa é a regra número um. No PostgreSQL, dá pra configurar o logging de todas as queries e ações dos usuários. Isso ajuda a descobrir quem fez o quê se algo der ruim.

Exemplo: protegendo dados de SQL injection

SQL injection é um dos ataques mais comuns contra bancos de dados. E é muito importante saber se proteger disso. Imagina que você tem um app onde o usuário digita o ID da conta pra ver o perfil. E o app faz uma query assim:

SELECT * FROM users WHERE id = 123;

Mas e se o usuário digitar 123 OR 1=1 em vez de um número? A query vira algo assim:

SELECT * FROM users WHERE id = 123 OR 1=1;

E em vez de um registro, a tabela inteira users fica exposta.

Como se proteger? O PostgreSQL permite usar queries parametrizadas ou comandos preparados (PREPARE e EXECUTE), assim os dados do usuário nunca se misturam com o código SQL. Olha só como fica:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

Mais exemplos de ameaças reais

Pra você entender bem por que segurança é importante, aqui vão dois cenários reais:

Exemplo 1: "Funcionário deletou a tabela inteira"

Uma vez, numa empresa (na real, isso já rolou em várias...), um estagiário digitou sem querer no console:

DROP TABLE employees;

E 10 anos de dados de funcionários sumiram pra sempre. Como evitar isso?

• Controle as permissões! Por exemplo, a role intern só pode ler.
• Configure auditoria! Os logs mostram quem mandou a query fatal.

Exemplo 2: "Vazamento de dados por conexão sem criptografia"

Se o usuário conecta no PostgreSQL sem criptografia, login e senha podem ser interceptados por um atacante. Configure SSL e garanta que as conexões sejam seguras.

Tarefas principais pra administradores

Pra fechar essa introdução, se liga nas três tarefas principais de qualquer admin de PostgreSQL:

• Controle de acesso. Garanta que só usuários autorizados possam fazer certas ações.
• Criptografia. Dados confidenciais sempre devem ser armazenados e transmitidos de forma criptografada.
• Monitoramento. Configure auditoria e fique de olho em atividades suspeitas nos logs.

Nas próximas aulas, você vai aprender como criar roles, controlar acesso com GRANT e REVOKE, implementar controle de acesso por linha e usar criptografia pra proteger seus dados.