Segurança de Bancos de Dados

A segurança de bancos de dados é um pilar crítico da segurança da informação, pois os bancos de dados armazenam os ativos mais valiosos de uma organização: dados de clientes, propriedade intelectual, informações financeiras e muito mais. Uma violação de dados pode resultar em perdas financeiras, danos à reputação e consequências legais. Nesta aula, vamos explorar quatro áreas essenciais para proteger bancos de dados: criptografia, controle de acesso baseado em papéis (roles), gerenciamento de segredos e políticas de backup.

Esses tópicos não são independentes; eles se complementam para criar uma defesa em profundidade. A criptografia protege os dados em repouso e em trânsito, os roles garantem que apenas usuários autorizados acessem dados específicos, o gerenciamento de segredos protege credenciais e chaves, e as políticas de backup garantem a disponibilidade e a recuperação em caso de incidentes. Vamos mergulhar em cada um deles com detalhes práticos e exemplos.

Encryption

A criptografia é o processo de transformar dados legíveis (texto claro) em um formato ilegível (texto cifrado) usando algoritmos e chaves. No contexto de bancos de dados, a criptografia é aplicada em duas áreas principais: dados em repouso (armazenados em disco, backups, etc.) e dados em trânsito (transferidos entre o cliente e o servidor de banco de dados).

Para dados em repouso, os bancos de dados modernos oferecem criptografia transparente (TDE - Transparent Data Encryption), que criptografa automaticamente os arquivos de dados e logs. Isso protege os dados mesmo se os arquivos forem copiados ou roubados. Além disso, pode-se criptografar colunas específicas (dados sensíveis como CPF, cartões de crédito) usando criptografia em nível de aplicação ou funções nativas do banco.

Para dados em trânsito, é essencial usar conexões criptografadas, como TLS/SSL, para evitar que dados sejam interceptados em redes não confiáveis. A maioria dos bancos de dados suporta configuração de TLS, como o PostgreSQL com SSL ou o MySQL com SSL.

Exemplo de configuração de criptografia em PostgreSQL (transparente):

-- Habilitar criptografia em repouso (TDE) no PostgreSQL
-- (Requer extensão pgcrypto ou uso de tablespace criptografado)
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Criar tabela com dados sensíveis
CREATE TABLE usuarios (
    id SERIAL PRIMARY KEY,
    nome TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL,
    cpf BYTEA NOT NULL
);

-- Inserir dados criptografados usando pgp_sym_encrypt
INSERT INTO usuarios (nome, email, cpf)
VALUES ('João Silva', 'joao@example.com', pgp_sym_encrypt('12345678900', 'chave-secreta'));

-- Consultar e descriptografar
SELECT nome, pgp_sym_decrypt(cpf, 'chave-secreta') AS cpf
FROM usuarios;

É importante gerenciar as chaves de criptografia com cuidado, usando cofres de chaves (HSM) ou serviços de gerenciamento de chaves (KMS).

Roles

O controle de acesso baseado em papéis (RBAC) é uma prática fundamental para garantir que cada usuário ou aplicação tenha apenas as permissões necessárias para realizar suas tarefas. Em bancos de dados, os roles (papéis) agrupam permissões e podem ser atribuídos a usuários ou outros roles, facilitando a administração.

Em vez de conceder permissões diretamente a cada usuário, criamos roles como 'admin', 'leitor', 'escritor' e atribuímos privilégios a esses roles. Depois, associamos usuários a esses roles. Isso simplifica a gestão, pois mudanças de permissão são feitas nos roles, não em cada usuário.

Exemplo de criação de roles e atribuição de permissões em PostgreSQL:

-- Criar roles
CREATE ROLE leitor;
CREATE ROLE escritor;
CREATE ROLE admin;

-- Conceder permissões
GRANT SELECT ON TABLE usuarios TO leitor;
GRANT INSERT, UPDATE ON TABLE usuarios TO escritor;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO admin;

-- Criar usuários e atribuir roles
CREATE USER ana WITH PASSWORD 'senha-forte';
CREATE USER carlos WITH PASSWORD 'outra-senha';
GRANT leitor TO ana;
GRANT escritor TO carlos;

Além de permissões, roles podem ser usados para aplicar políticas de senha, limites de conexão e até mesmo para separar ambientes (desenvolvimento, teste, produção).

Secrets

Segredos são informações sensíveis como senhas, chaves de API, tokens de autenticação e strings de conexão. Em um ambiente de banco de dados, os segredos incluem as credenciais de acesso ao banco e as chaves de criptografia. Armazenar segredos em código-fonte ou arquivos de configuração não criptografados é um risco grave de segurança.

Práticas recomendadas para gerenciamento de segredos incluem: usar um cofre de segredos (como HashiCorp Vault, AWS Secrets Manager, ou Kubernetes Secrets), rotacionar segredos regularmente, e nunca expor segredos em logs ou mensagens de erro. No código, podemos usar variáveis de ambiente ou bibliotecas de gerenciamento de segredos para acessar credenciais dinamicamente.

Exemplo de uso de variáveis de ambiente para conectar a um banco (em Python, mas o conceito é geral):

import os
import psycopg2

# Obter segredos de variáveis de ambiente (não hardcoded)
db_host = os.environ.get('DB_HOST')
db_port = os.environ.get('DB_PORT')
db_user = os.environ.get('DB_USER')
db_password = os.environ.get('DB_PASSWORD')
db_name = os.environ.get('DB_NAME')

conn = psycopg2.connect(
    host=db_host,
    port=db_port,
    user=db_user,
    password=db_password,
    dbname=db_name
)

No ambiente de produção, é comum usar um serviço de gerenciamento de segredos que injeta os segredos no ambiente da aplicação, evitando que fiquem em arquivos versionados.

Backup policies

As políticas de backup são essenciais para garantir a disponibilidade e a recuperação de dados em caso de falhas, desastres ou ataques (como ransomware). Uma política de backup define o que, quando, como e por quanto tempo os dados são copiados e armazenados.

Os tipos de backup incluem: completo, incremental e diferencial. Backups completos copiam todos os dados, mas são demorados e consomem espaço. Backups incrementais copiam apenas as mudanças desde o último backup (completo ou incremental), e os diferenciais copiam as mudanças desde o último backup completo. A escolha depende do RPO (Recovery Point Objective) e RTO (Recovery Time Objective) da organização.

Além de backups regulares, é crucial testar a restauração periodicamente e armazenar backups em locais seguros, preferencialmente fora do ambiente principal (por exemplo, em armazenamento na nuvem ou em outro datacenter).

Exemplo de script de backup do PostgreSQL usando pg_dump:

#!/bin/bash
# Backup completo do banco 'meubanco' para um arquivo com timestamp
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
BACKUP_DIR="/backups"
DB_NAME="meubanco"

pg_dump -U postgres -h localhost $DB_NAME > $BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.sql

# Compactar e remover backups antigos (exemplo: manter 7 dias)
gzip $BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.sql
find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

Para bancos de dados gerenciados na nuvem, como RDS, existem recursos de backup automático e point-in-time recovery, que facilitam a implementação de políticas robustas.

Boas Práticas e Observações Finais

Além dos tópicos principais, algumas boas práticas gerais incluem: manter o software do banco de dados atualizado com patches de segurança, aplicar o princípio do menor privilégio, monitorar logs de acesso e atividades, e usar autenticação multifator (MFA) para acesso administrativo. A segurança de bancos de dados é um processo contínuo, não uma configuração única. Avalie regularmente sua postura de segurança e adapte-se a novas ameaças.

Referências

• PostgreSQL: Encryption Options
• MySQL: Encrypted Connections
• PostgreSQL: User Management
• Oracle Database Security Guide
• HashiCorp Vault Documentation
• AWS Secrets Manager
• PostgreSQL: Backup and Restore
• MySQL: Backup and Recovery

Exercícios

1. Explique a diferença entre criptografia em repouso e criptografia em trânsito. Dê um exemplo de cada.
2. Em um banco de dados PostgreSQL, como você criaria um role chamado 'aplicacao' que pode apenas consultar (SELECT) as tabelas do schema 'public'? Escreva os comandos SQL.
3. Por que é importante usar um gerenciador de segredos em vez de armazenar credenciais em arquivos de configuração? Liste pelo menos três benefícios.
4. Descreva a diferença entre backup completo, incremental e diferencial. Em qual cenário você usaria cada um?
5. Você é responsável por um banco de dados que contém dados de cartão de crédito. Quais medidas de segurança você implementaria para proteger esses dados? Justifique.

Ver resposta

Ver resposta

CREATE ROLE aplicacao;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO aplicacao;

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

Ver resposta

Ver resposta

Ver resposta