Backup seguro e plano de recuperação

1. Por que Segurança em Backup é Responsabilidade do Dev

Muitos desenvolvedores acreditam que backup é problema exclusivo da infraestrutura. Essa visão é perigosa. Um backup operacional — aquele que simplesmente copia dados para outro local — não protege contra ransomware, adulteração ou vazamento. O backup seguro exige criptografia, imutabilidade e validação de integridade, decisões que impactam diretamente a arquitetura do software.

Os riscos de backups não protegidos são concretos:
- Ransomware: atacantes criptografam backups acessíveis com as mesmas credenciais do sistema produtivo
- Vazamento de dados: backups armazenados sem criptografia em buckets S3 mal configurados
- Perda de integridade: backups corrompidos que passam despercebidos até a hora da restauração

O desenvolvedor define como os dados são exportados, quais chaves são usadas e como o pipeline de backup se integra ao ciclo de vida da aplicação. Ignorar isso é criar uma vulnerabilidade sistêmica.

2. Estratégia de Criptografia para Backups

A criptografia deve ocorrer em duas camadas:

Em trânsito: TLS 1.2+ para transferências HTTP/HTTPS, SSH para rsync/scp. Nunca enviar backups por protocolos não criptografados como FTP ou HTTP simples.

Em repouso: AES-256-GCM é o padrão atual. O gerenciamento de chaves é o ponto crítico — jamais armazenar chaves de criptografia no código-fonte ou em variáveis de ambiente não seguras. Use cofres como HashiCorp Vault, AWS KMS ou Azure Key Vault.

Exemplo prático: backup criptografado de banco PostgreSQL antes do upload para S3.

# 1. Exportar banco e criptografar com GPG (chave simétrica)
pg_dump -h localhost -U app_user my_database | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/backup_key.pgp -o backup_$(date +%Y%m%d).sql.gpg

# 2. Verificar integridade do arquivo criptografado
gpg --verify backup_$(date +%Y%m%d).sql.gpg 2>&1 || { echo "Falha na verificação"; exit 1; }

# 3. Upload para bucket com criptografia do lado do servidor
aws s3 cp backup_$(date +%Y%m%d).sql.gpg s3://my-backup-bucket/db/ --sse AES256

A chave backup_key.pgp deve ser armazenada no Vault e rotacionada a cada 90 dias.

3. Imutabilidade e Proteção Contra Ransomware

Backup imutável significa que, uma vez escrito, o dado não pode ser modificado ou excluído por um período definido. Isso frustra ataques de ransomware que tentam deletar ou criptografar backups.

Implementações práticas:
- S3 Object Lock: modo "Governance" ou "Compliance" com retenção por período
- Azure Blob Storage: política de WORM (Write Once, Read Many) com "Time-based retention"
- Snapshots de disco: AWS EBS Snapshots com proteção contra exclusão acidental

Princípio fundamental: a conta que escreve o backup não pode ter permissão para deletá-lo. Separe roles: backup-writer (apenas PutObject) e backup-admin (exclusão com aprovação manual).

Exemplo de política S3 para bucket imutável:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::meu-bucket-imutavel/*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::meu-bucket-imutavel/*"
    }
  ]
}

4. Plano de Recuperação com Foco em Segurança

De nada adianta ter backups seguros se a recuperação for caótica. O plano deve ser testado regularmente — não apenas "simular" restauração, mas executar o processo completo em ambiente isolado.

Procedimento seguro de validação pós-restauração:

# 1. Restaurar backup em ambiente sandbox (nunca direto em produção)
gpg --decrypt backup_20250101.sql.gpg > /tmp/restore_test.sql

# 2. Calcular checksum do arquivo original vs. restaurado
sha256sum backup_20250101.sql.gpg > /tmp/checksum_original.txt
sha256sum /tmp/restore_test.sql > /tmp/checksum_restaurado.txt

# 3. Comparar hashes
diff /tmp/checksum_original.txt /tmp/checksum_restaurado.txt || { echo "Integridade comprometida"; exit 1; }

# 4. Executar validação de dados (exemplo: contar registros)
psql -h sandbox-db -U test_user -d restored_db -c "SELECT count(*) FROM usuarios;"

# 5. Se tudo ok, promover para produção

Métricas críticas: RTO (Recovery Time Objective) deve ser documentado e testado. Um backup de 500GB que leva 8 horas para restaurar pode ser inaceitável para o negócio.

5. Logging e Auditoria de Operações de Backup

Cada operação de backup e restauração deve gerar logs imutáveis, sem expor dados sensíveis. O que registrar:

  • Timestamp da operação (UTC)
  • Hash SHA-256 do arquivo de backup
  • Tamanho em bytes
  • Status: sucesso, falha, parcial
  • Identificador do bucket/repositório
  • Chave da criptografia usada (apenas referência, não a chave em si)

Exemplo de log seguro:

{"timestamp":"2025-01-01T03:00:00Z","operation":"backup","source":"prod-db","target":"s3://backup-bucket/db/","checksum":"a1b2c3d4...","size_bytes":2147483648,"status":"success","encryption_key_id":"arn:aws:kms:us-east-1:123456789012:key/abc123"}

Configure alertas para:
- Falhas de backup consecutivas (ex: 3 falhas em 1 hora)
- Tentativas de exclusão de objetos imutáveis
- Chaves de criptografia próximas ao vencimento
- Acessos de IPs não autorizados ao bucket de backup

AWS CloudTrail ou syslog centralizado (ex: ELK Stack) são ferramentas adequadas para auditoria imutável.

6. Automatização Segura e Pipeline de Backup

Scripts de backup devem ser robustos e notificar falhas imediatamente. Todo pipeline de CI/CD que faz backup precisa usar secrets management.

Exemplo de workflow GitHub Actions para backup de staging antes de deploy destrutivo:

name: Backup Staging DB

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Backup and encrypt database
        env:
          DB_URL: ${{ secrets.STAGING_DB_URL }}
          BACKUP_PASSPHRASE: ${{ secrets.BACKUP_PASSPHRASE }}
        run: |
          pg_dump "$DB_URL" | gpg --symmetric --cipher-algo AES256 --batch --passphrase "$BACKUP_PASSPHRASE" -o backup_staging_$(date +%Y%m%d_%H%M%S).sql.gpg

      - name: Upload to S3 with immutability
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_BACKUP_ACCESS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_BACKUP_SECRET_KEY }}
        run: |
          aws s3 cp *.sql.gpg s3://staging-backup-bucket/ --sse AES256

Nunca expor credenciais no código. Use secrets do repositório ou um cofre externo.

7. Plano de Resposta a Incidentes com Backup

Quando um incidente acontece (ransomware, falha catastrófica, corrupção de dados), os passos imediatos são:

  1. Isolar o sistema comprometido: desligar servidores afetados, revogar chaves de acesso
  2. Verificar integridade do backup mais recente: calcular checksum e comparar com o registrado no log de auditoria
  3. Decidir tipo de recuperação:
  4. Recuperação seletiva: apenas tabelas/arquivos críticos (menor tempo, menor risco)
  5. Recuperação total: restaurar todo o ambiente (maior garantia de consistência)

Exemplo de script de verificação de integridade pré-restauração:

# Verificar integridade de todos os backups disponíveis
for backup in s3://meu-bucket/backups/*.sql.gpg; do
    aws s3 cp "$backup" /tmp/
    filename=$(basename "$backup")
    # Comparar checksum do log com o arquivo baixado
    expected_hash=$(grep "$filename" /var/log/backup_audit.log | jq -r '.checksum')
    actual_hash=$(sha256sum "/tmp/$filename" | awk '{print $1}')
    if [ "$expected_hash" != "$actual_hash" ]; then
        echo "ALERTA: Backup $filename pode estar comprometido"
    fi
done

Pós-incidente: revisar políticas, rotacionar todas as chaves de criptografia, atualizar o plano de backup com as lições aprendidas.

Backup seguro não é um produto que se compra, é uma prática que se incorpora ao desenvolvimento. Cada linha de código que exporta dados, cada pipeline que move backups, cada chave armazenada — tudo isso define o quão resiliente sua aplicação será contra perda de dados.

Referências