Docker Compose em Produção: Hardening de Segurança, Caddy e Backups Automáticos

Introdução à Orquestração Robusta em Produção com Docker Compose

O ecossistema Docker transformou a forma como empacotamos e distribuímos aplicações, mas a transição de ambientes de desenvolvimento locais para servidores de produção exige um rigor arquitetural severo. Historicamente relegado a ambientes de testes e homologação devido a equívocos sobre sua escalabilidade, o Docker Compose evoluiu e tornou-se uma ferramenta perfeitamente viável para cargas de trabalho monolíticas ou baseadas em microsserviços de porte pequeno e médio, desde que acompanhado por padrões estritos de engenharia de confiabilidade e segurança de infraestrutura.

Em cenários produtivos, a conveniência de iniciar múltiplos containers com um único arquivo YAML não pode vir acompanhada de concessões de segurança. Deixar portas de bancos de dados expostas diretamente na interface pública, rodar processos internos com privilégios de root dentro do container ou negligenciar a rotação e encriptação de snapshots de dados são falhas críticas que comprometem a integridade operacional de toda a arquitetura de software moderna.

Este artigo explora detalhadamente as diretrizes fundamentais para endurecer (hardnening) a sua infraestrutura baseada em Docker Compose, implementando o princípio de privilégios mínimos, isolamento estrito de redes overlay e bridge, a adoção de um proxy reverso elegante com Caddy Server e TLS automatizado, além de uma rotina automatizada e resiliente de backups em nuvem.

Princípios de Hardening de Segurança e Usuários Não-Root

O primeiro vetor de ataque em ambientes conteinerizados explora a configuração padrão onde os processos da aplicação rodam sob o usuário root dentro do namespace do container. Caso ocorra uma vulnerabilidade de execução remota de código (RCE) na stack tecnológica, o invasor adquire imediatamente privilégios administrativos sobre o sistema de arquivos do container e, dependendo de falhas de isolamento do kernel do host, pode escalar privilégios para a máquina hospedeira. Mitigar este risco exige a especificação explícita de UID e GID não-privilegiados nos Dockerfiles e nos manifestos do Compose.

Além da restrição de usuários, o hardening exige a remoção de capacidades desnecessárias do kernel Linux (Linux Capabilities) e a montagem de sistemas de arquivos raiz como somente leitura (read_only: true), com volumes persistentes pontuais para diretórios de dados temporários e logs. Essas diretrizes bloqueiam tentativas de modificação maliciosa de binários do sistema operacional interno e reduzem drasticamente a superfície de ataque da aplicação exposta ao tráfego externo.

version: '3.8'
services:
  app:
    image: registry.internal/app:v1.2.0
    user: "10001:10001"
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    volumes:
- tmp-data:/tmp
    networks:
      - internal
volumes:
  tmp-data:
networks:
  internal:
    internal: true

Topologia de Rede Avançada e Isolamento de Bancos de Dados

A arquitetura de redes no Docker Compose é frequentemente negligenciada, resultando em cenários onde bancos de dados como PostgreSQL, Redis ou MySQL ficam acessíveis por interfaces de rede desnecessárias. O isolamento rigoroso determina que nenhum serviço de armazenamento persistente deve possuir portas mapeadas diretamente para o host (diretiva ports), devendo comunicar-se exclusivamente através de redes Docker internas e privadas, onde a resolução de nomes via DNS interno gerencia o tráfego inter-serviços.

Para alcançar este nível de isolamento, separamos a infraestrutura em redes distintas: uma rede externa (geralmente gerenciada pelo proxy reverso para entrada de tráfego HTTP/HTTPS) e redes internas isoladas para persistência de dados. A diretiva internal: true na definição da rede garante que os containers conectados a ela não tenham absolutamente nenhuma rota de saída para a internet pública, eliminando vetores de exfiltração de dados caso ocorra um comprometimento lateral na rede interna.

networks:
  public_net:
    driver: bridge
  database_net:
    driver: bridge
    internal: true
services:
  database:
    image: postgres:15-alpine
    networks:
      - database_net
    environment:
      POSTGRES_DB: production
    volumes:
      - pgdata:/var/lib/postgresql/data
  backend:
    image: my-backend:latest
    networks:
      - database_net
      - public_net

Proxy Reverso Elegante com Caddy e SSL Automático

A gestão de certificados TLS e o roteamento de tráfego HTTP em ambientes tradicionais exigia configurações complexas e extensas no Nginx ou Apache, acompanhadas de scripts de renovação via Certbot. O Caddy Server redefine essa experiência ao automatizar nativamente o provisionamento, monitoramento e renovação de certificados SSL/TLS via Let's Encrypt ou ZeroSSL, exigindo pouquíssimas linhas em seu arquivo de configuração Caddyfile e integrando-se de forma fluida ao ecossistema Docker Compose.

No arquivo Compose, o Caddy atua como a única porta de entrada exposta para o mundo exterior (portas 80 e 443), interceptando as requisições HTTPS e fazendo o encaminhamento reverso (reverse proxy) para os containers de aplicação internos através do DNS interno do Docker. Esta abordagem simplifica o gerenciamento de cabeçalhos de segurança HTTP, redirecionamentos automáticos de HTTP para HTTPS e o balanceamento de carga básico entre instâncias de microsserviços.

api.marciocunha.net {
    reverse_proxy backend:8080 {
        header_up Host {http.reverse_proxy.upstream.host}
        header_up X-Real-IP {http.remote_host}
        header_up X-Forwarded-For {http.remote_host}
        header_up X-Forwarded-Proto {http.scheme}
    }
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
    encode gzip zstd
}

Rotinas Automatizadas de Snapshot, Compactação e Backups na Nuvem

Nenhuma arquitetura de produção pode ser considerada completa sem uma estratégia rigorosa e testada de recuperação de desastres (Disaster Recovery). Depender de snapshots manuais ou cópias esporádicas de volumes Docker é um convite ao colapso operacional. A engenharia de confiabilidade exige a automação de rotinas de dump de bancos de dados, compactação criptografada dos arquivos resultantes e sincronização imediata com um storage de longo prazo na nuvem, como o AWS S3 ou buckets compatíveis com S3.

Podemos implementar esta rotina encapsulando o processo em um container dedicado executando scripts shell acionados via cron jobs internos ou gerenciados por orchestradores externos, montando os volumes persistentes dos bancos de dados em modo somente leitura para extração segura dos dumps. A rotação dos backups segue políticas de retenção estritas (estratégia GFS - Grandfather-Father-Son), garantindo que snapshots diários, semanais e mensais sejam gerados sem consumir espaço infinito de armazenamento.

#!/usr/bin/env bash
set -euo pipefail
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
BACKUP_DIR="/backups"
DB_CONTAINER="production_db_1"
DB_NAME="production"
DB_USER="postgres"

echo "[+] Iniciando dump do banco de dados..."
docker exec -t ${DB_CONTAINER} pg_dump -U ${DB_USER} ${DB_NAME} | gzip > "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz"

echo "[+] Criptografando arquivo compactado..."
openssl enc -aes-256-cbc -salt -in "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz" -out "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz.enc" -k "${BACKUP_ENCRYPTION_KEY}"
rm "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz"

echo "[+] Enviando para o storage em nuvem..."
aws s3 cp "${BACKUP_DIR}/db_${TIMESTAMP}.sql.gz.enc" "s3://${S3_BUCKET_NAME}/backups/db_${TIMESTAMP}.sql.gz.enc"

echo "[+] Removendo backups locais antigos com mais de 7 dias..."
find ${BACKUP_DIR} -type f -name "*.enc" -mtime +7 -delete
echo "[+] Processo de backup concluído com sucesso."

Conclusão e Práticas Acionáveis para Infraestruturas Resilientes

A gestão de ambientes produtivos com Docker Compose não precisa abdicar dos padrões avançados de segurança, observabilidade e resiliência encontrados em ecossistemas de orquestração mais complexos, como o Kubernetes. Ao aplicar rigorosamente o isolamento de redes internas, a execução de containers com usuários não-privilegiados, o roteamento elegante provido pelo Caddy Server e pipelines automatizados de backup criptografado, construímos uma infraestrutura leve, auditável e altamente estável.

Como recomendação final para arquitetos e engenheiros de software, estabeleça rotinas periódicas de testes de restauração (Restore Drills). Um backup que nunca foi testado para restauração é, essencialmente, um backup inexistente. Valide sua documentação de disaster recovery trimestralmente e mantenha seus arquivos de configuração versionados e submetidos a revisões de código rigorosas, garantindo a longevidade e a segurança dos seus sistemas em produção.