Arkhivio Backup Framework — Relatório de Conformidade LGPD

O MongoDB armazena exclusivamente metadados dos arquivos (caminho, tamanho, data de modificação, CRC32) — nenhum conteúdo de arquivo é persistido no catálogo. A seleção de diretórios é configurável por job, com suporte a exclude_dirs validado em job_manager.py. Credenciais de acesso ao S3 são mascaradas em todas as respostas da API pela função _serialize_bucket() em main.py, que remove access_key e secret_key antes de retornar ao cliente.

Checksum CRC32 calculado para cada arquivo no momento do scan (scanner.py), armazenado no MongoDB e gravado nos metadados do objeto S3 durante o upload (uploader.py). O módulo audit.py oferece três verificações independentes sob demanda: (1) existência do catálogo mais recente, (2) confronto do CRC32 no MongoDB versus metadado S3 sem baixar o arquivo, e (3) download aleatório com recomputação completa do CRC32. O reconciler.py detecta e corrige divergências entre MongoDB e S3.

O framework implementa múltiplas camadas de segurança técnica: controle de acesso baseado em função (auth.py), criptografia simétrica Fernet para credenciais em repouso (crypto_utils.py), TLS 1.2+ com ECDHE para tráfego em trânsito (nginx), cookies de sessão assinados com HMAC-SHA256 (itsdangerous), execução em contêiner como usuário sem privilégios (appuser) e cabeçalhos HTTP de segurança (HSTS, X-Frame-Options, X-Content-Type-Options).

Todos os acessos e operações de escrita geram eventos de log estruturado com identificação do usuário autenticado (session["username"]), nome do recurso e timestamp UTC ISO-8601. O inventário files.json.gz publicado no S3 após cada execução lista todos os arquivos processados em formato JSON aberto, sem formato proprietário, possibilitando auditorias e análises externas.

Cada arquivo copiado é um objeto bruto no S3 em caminho legível ({host}/{caminho/absoluto}), acessível com qualquer ferramenta S3-compatível sem necessidade do framework. O inventário files.json.gz lista todos os arquivos com caminho, tamanho, data de modificação e CRC32 em esquema JSON aberto. O módulo restore.py restaura arquivos com preservação de estrutura de diretórios ou em formato plano (--flat), atendendo ao requisito de portabilidade.

A infraestrutura de eliminação existe e está testada: delete.py remove objetos do S3 e marca registros como excluídos no MongoDB com deleted_in_s3=True e timestamp de exclusão. A lacuna é procedimental, não técnica — o framework não possui mecanismo para localizar automaticamente todos os objetos pertencentes a um titular específico. A organização deve manter um mapeamento titular → caminhos de arquivo na camada de aplicação.

O framework opera como espelho do sistema de origem: quando dados são corrigidos na fonte e o próximo backup é executado, o scanner detecta a alteração via mtime/tamanho e atualiza o registro no MongoDB, fazendo novo upload para o S3. O reconciler.py garante a consistência entre catálogo e armazenamento após qualquer ciclo de atualização.

O framework registra o destino S3 configurado por job (bucket, região, endpoint). Não há, porém, um relatório estruturado de compartilhamento de dados por titular gerado automaticamente — isso é um artefato de governança organizacional.

Todo tráfego S3 utiliza HTTPS via boto3 (TLS 1.2+ imposto pelos endpoints AWS/Cloudflare). O dashboard web é servido via nginx com TLS 1.2+, cipher suites ECDHE, HSTS com max-age=63072000 (2 anos, preload), redirecionamento HTTP→HTTPS. A porta 8000 do uvicorn não é exposta ao host. Conexões MongoDB suportam TLS via MONGO_OPTIONS; o config.py emite aviso de startup se TLS estiver desabilitado em host não-local.

Credenciais S3 armazenadas no MongoDB são criptografadas com Fernet AES-128-CBC + HMAC via crypto_utils.py — um comprometimento do banco de dados isoladamente não expõe o acesso ao armazenamento. A criptografia dos dados de backup em repouso é delegada ao bucket S3: SSE-KMS com chave gerenciada pelo cliente deve ser habilitado no bucket. Não é necessária nenhuma alteração no código do framework.

O dashboard web implementa controle de acesso baseado em função: admin — CRUD completo em jobs e buckets; operador — leitura somente. Dois backends de autenticação: local com comparação temporalmente segura via secrets.compare_digest() (auth.py:121–130) e Active Directory com bind LDAP + consulta de grupo memberOf. A validação de startup em _validate_config() falha imediatamente se SESSION_SECRET, credenciais ou variáveis AD estiverem ausentes — o servidor não inicia em estado de segurança degradada.

O framework emite eventos de log estruturado para todas as anomalias detectáveis: divergência CRC32, inconsistência MongoDB/S3 (reconciler_mismatch), falhas de upload (upload_error), credenciais não encontradas (secret_fetch_failed), TLS desabilitado (mongo_tls_disabled). A lacuna é que nenhum pipeline de alerta está ativado por padrão — conectar o fluxo de logs a uma plataforma de monitoramento e definir runbooks de resposta a incidentes é uma etapa operacional.

Todos os 6 endpoints de escrita (criar/atualizar/excluir jobs e buckets) emitem um evento de log nomeado audit_* com o usuário autenticado e o recurso afetado. O fluxo de logs cobre o ciclo completo das operações. Exemplo:

Todos os timestamps são UTC ISO-8601. Nenhuma credencial ou chave é registrada nos logs. Logs podem ser encaminhados para armazenamento imutável (CloudWatch Logs, Splunk, S3) conforme documentado em LOG_INTEGRATION.md.

O design minimiza a superfície de exposição de dados pessoais por padrão: MongoDB armazena apenas metadados (sem conteúdo de arquivo); credenciais S3 são criptografadas em repouso antes de persistência; chave de criptografia pode ser mantida inteiramente fora do disco em 6 provedores de secrets (AWS SM, Azure KV, GCP, IBM, HashiCorp Vault, OpenBao); sessão expira automaticamente; servidores não iniciam em estado de segurança degradada. O timeout de sessão de 3.600 s é configurável via SESSION_TIMEOUT_SECONDS.

A nomeação do Encarregado (DPO) e a elaboração do Relatório de Impacto à Proteção de Dados Pessoais (RIPD) são obrigações organizacionais fora do escopo do framework. O sistema suporta o processo de elaboração do RIPD: audit.py --json gera evidências técnicas de integridade em formato estruturado, todos os avisos de configuração são eventos de log mensuráveis, e a documentação (SETUP.md, USER_MANUAL.md) descreve com precisão os controles implementados.

O framework é Python auto-hospedado — nenhum contrato de operador é necessário com o software em si. Contratos de tratamento de dados devem ser celebrados com cada provedor de nuvem utilizado para armazenar dados pessoais: AWS (Data Processing Addendum), Cloudflare (DPA R2), MongoDB Atlas (DPA Atlas). Provedores brasileiros ou com sede no Brasil devem seguir a legislação nacional; provedores estrangeiros requerem cláusulas contratuais padrão conforme Art. 33, II da LGPD.