Logo

Whitepaper de segurança e privacidade (visão geral)Capítulo 4

Capítulo 4 Autenticação, autorização e controle de acesso

Este capítulo define o modelo de identidade do FileBolt, as camadas de tokens e os limites do controle de acesso. O upload e o download usam tokens de acesso de curta duração (sessões no servidor, baseadas em consulta, com expiração e escopo) para controlar o acesso ao texto cifrado e ao manifest. As ações de gerenciamento do remetente usam tokens de login de longa duração armazenados no cliente. O sistema DEVE oferecer suporte à revogação, e os dados de auditoria DEVEM ser visíveis somente ao remetente.

4.0 Resumo

  • Token de acesso de curta duração: controla o acesso ao texto cifrado/manifest; sessão no servidor (consulta); DEVE ser vinculado ao transferId; DEVE ter escopo; DEVE expirar.
  • Token de login de longa duração: usado para o gerenciamento do remetente (excluir/revogar/auditar); armazenado no cliente; NÃO DEVE ser usado por destinatários para acessar o texto cifrado.
  • Separação entre chaves e autorização: os tokens controlam apenas o acesso ao texto cifrado; a capacidade de descriptografar vem da CEK no fragmento da URL (veja o Capítulo 5).

4.1 Modelo de identidade

  • O sistema oferece suporte a um modelo de identidade de usuário pago para o gerenciamento do remetente.
  • O login do remetente PODE usar um magic link de uso único; o cliente armazena um token de login de longa duração após a autenticação bem-sucedida.
  • Os destinatários não precisam ter uma conta para fazer downloads por padrão (veja a documentação de UX); o acesso é controlado por link/token.

4.2 Modelo de autorização e camadas de tokens

Dois tipos de token são usados, com separação estrita de responsabilidades:

  1. Token de acesso de curta duração (sessão / consulta): para upload/download do texto cifrado e leitura do manifest; DEVE ser vinculado ao transferId; DEVE expirar; DEVE ter escopo por operação.
  2. Token de login de longa duração: para as ações de gerenciamento do remetente; NÃO DEVE conceder capacidade de descriptografia.

4.2.2 Exemplos de escopo

  • upload_chunk: enviar blocos de texto cifrado de um transferId específico.
  • read_manifest: ler o manifest de um transferId específico.
  • download_chunk: baixar blocos de texto cifrado de um transferId específico.

4.3 Autorização de upload

  • As APIs de upload DEVEM validar o escopo do token e a vinculação ao transferId antes de aceitar o texto cifrado.
  • Os uploads de blocos DEVERIAM ser idempotentes por (transferId, fileId, chunkIndex).
  • Diante de um token inválido ou de uma divergência, o sistema DEVE falhar de forma fechada.

4.4 Autorização de download

  • O acesso ao manifest e ao texto cifrado DEVE exigir um token válido e com escopo; os tokens DEVEM ter validade limitada.
  • Os destinatários NÃO DEVEM conseguir enumerar outras transferências nem acessar blocos fora do transferId vinculado.
  • A limitação de taxa PODE ser aplicada para prevenir abusos (veja o Capítulo 7) sem prejudicar a possibilidade de retomada.

4.5 Revogação e invalidação antecipada

  • Os remetentes DEVEM poder revogar uma transferência; a revogação DEVE tornar os tokens inutilizáveis para acessos posteriores.
  • A revogação DEVERIA acionar a limpeza ou a aceleração do TTL do texto cifrado sempre que viável.
  • A experiência do destinatário DEVE indicar claramente o status de revogado/expirado e o próximo passo (entrar em contato com o remetente).

4.6 Auditoria e isolamento de permissões

  • As evidências de entrega (downloads, contagens) DEVEM ser visíveis somente ao remetente por padrão.
  • As APIs de auditoria DEVEM exigir a autenticação do remetente e DEVEM ser isoladas dos tokens de acesso dos destinatários.

4.7 Registro em logs e minimização de dados sensíveis

  • Os logs NÃO DEVEM conter fragmentos de URL, CEK nem material derivável de chaves.
  • Os logs DEVERIAM minimizar os dados pessoais e se concentrar em eventos relevantes para a segurança (falhas de token, revogação, limites de taxa).
  • As mensagens de erro DEVEM indicar o que fazer, mas não podem vazar segredos.

4.8 IDs de afirmação relacionados