Logo

Capítulo 3 Arquitetura do Sistema e Fluxo de Dados

Este capítulo descreve os componentes de alto nível do sistema e o fluxo de dados ponta a ponta para upload, download e gerenciamento de remetentes. O foco está no que é criptografado, quais metadados são necessários e como o controle de acesso e a revogação são aplicados.

Metadados do documento

Versão do artigo técnico
v1.0
Última atualização
2026-01-14

3.1 Componentes

  • Client: fragmenta arquivos, criptografa/descriptografa e gerencia CEK no fragmento de URL.
  • API/Edge: emite e valida tokens com escopo definido; serve pedaços de manifesto e texto cifrado.
  • Armazenamento de objetos: armazena pedaços e manifestos criptografados; tratado como não confiável para confidencialidade de texto simples.
  • Loja estadual: rastreia o estado da transferência (progresso do upload, expiração, revogação) com metadados mínimos.

3.2 Objetos de dados

  • Manifest: parâmetros públicos necessários para buscar e montar pedaços (cryptoVersion, tamanho/contagem de pedaços, mapeamento); NÃO DEVE conter CEK.
  • Chunk: parte do arquivo criptografado (texto cifrado) mais metadados mínimos (comprimento/etag), endereçados por (transferId, fileId, chunkIndex).
  • State: registro do lado do servidor para autorização, TTL, revogação e capacidade de retomada.

3.3 Fluxo de upload

  1. O cliente cria uma transferência e recebe um token de upload com escopo de curta duração vinculado a transferId.
  2. O cliente gera CEK por arquivo localmente, divide os arquivos em partes de tamanho fixo e criptografa cada parte com AEAD.
  3. O cliente carrega pedaços de texto cifrado em paralelo; as novas tentativas são idempotentes por pedaço.
  4. O cliente carrega o manifesto (somente parâmetros públicos). O servidor marca a transferência como PRONTA quando as peças necessárias estão presentes.

3.4 Fluxo de download

  1. O destinatário abre o link de compartilhamento. O fragmento de URL (material CEK) permanece no navegador e não é enviado ao servidor.
  2. O cliente busca o manifesto usando um token de download com escopo definido e determina o plano de blocos.
  3. O cliente baixa pedaços de texto cifrado (opcionalmente em paralelo), verifica a autenticação AEAD e depois monta o arquivo de texto simples.
  4. Em caso de falhas, o cliente retoma solicitando apenas os pedaços ausentes; falhas de integridade DEVEM falhar fechadas.

3.5 Gerenciamento de remetentes e fluxo de auditoria

  • Os remetentes são autenticados usando um token de login de longa duração (armazenado no cliente) para operações de gerenciamento.
  • As APIs de gerenciamento permitem listar transferências, verificar evidências de entrega e revogar/excluir transferências.
  • Os dados de auditoria foram projetados para serem visíveis apenas para o remetente; ele não é exposto aos destinatários por padrão.

3.6 Visibilidade e minimização

  • O servidor e o armazenamento lidam apenas com texto cifrado e parâmetros públicos necessários; eles não podem descriptografar o conteúdo sem CEK.
  • Logs e análises DEVEM ser minimizados e NÃO DEVEM incluir fragmentos de URL ou material CEK.
  • A coleta de metadados DEVE ser limitada por finalidade (evidência de entrega, prevenção de abuso e confiabilidade operacional).