Logo

Artigo sobre 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, camadas de token e limites de controle de acesso do FileBolt. O upload e o download usam tokens de acesso de curta duração (sessões do lado do servidor, baseadas em pesquisa, expiradas, com escopo definido) para bloquear o texto cifrado e o acesso ao manifesto. As ações de gerenciamento de remetentes usam tokens de login de longa duração armazenados no cliente. O sistema DEVE suportar a revogação e os dados de auditoria DEVEM ser visíveis apenas para o remetente.

4.0 Resumo

  • Token de acesso de curta duração: bloqueia o acesso ao texto cifrado/manifesto; sessão do lado do servidor (pesquisa); DEVE vincular-se a transferId; DEVE ter escopo definido; DEVE expirar.
  • Token de login de longa duração: usado para gerenciamento de remetentes (excluir/revogar/auditar); armazenado no cliente; NÃO DEVE ser usado por destinatários para acessar texto cifrado.
  • Separação de chaves e autorização: os tokens controlam apenas o acesso ao texto cifrado; a capacidade de descriptografia vem de CEK no fragmento de URL (consulte o Capítulo 5).

4.1 Modelo de identidade

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

4.2 Modelo de autorização e camadas de token

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

  1. Token de acesso de curta duração (sessão/pesquisa): para upload/download de texto cifrado e leitura de manifesto; DEVE vincular-se a transferId; DEVE expirar; DEVE ter escopo definido por operação.
  2. Token de login de longa duração: para ações de gerenciamento de remetentes; NÃO DEVE conceder capacidade de descriptografia.

4.2.2 Exemplos de escopo

  • upload_chunk: carrega pedaços de texto cifrado para um transferId específico.
  • read_manifest: leia o manifesto para um transferId específico.
  • download_chunk: baixe pedaços de texto cifrado para um transferId específico.

4.3 Autorização de upload

  • As APIs de upload DEVEM validar o escopo do token e a ligação transferId antes de aceitar o texto cifrado.
  • Os uploads de pedaços DEVEM ser idempotentes por (transferId, fileId, chunkIndex).
  • Em caso de token inválido ou incompatibilidade, o sistema DEVE falhar ao fechar.

4.4 Autorização de download

  • O acesso ao manifesto e ao texto cifrado DEVE exigir um token válido com escopo definido; os tokens DEVEM ser limitados no tempo.
  • Os destinatários NÃO DEVEM ser capazes de enumerar outras transferências ou acessar partes fora do transferId vinculado.
  • A limitação de taxa PODE ser aplicada para prevenção de abusos (ver Capítulo 7) sem quebrar a capacidade de retomada.

4.5 Revogação e invalidação antecipada

  • Os remetentes DEVEM ser capazes de revogar uma transferência; a revogação DEVE tornar os tokens inutilizáveis ​​para acesso subsequente.
  • A revogação DEVE acionar a limpeza/aceleração TTL para texto cifrado sempre que possível.
  • A UX do destinatário DEVE indicar claramente o status revogado/expirado e a próxima etapa (contatar o remetente).

4.6 Auditoria e isolamento de permissão

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

4.7 Registro e minimização de dados confidenciais

  • Os logs NÃO DEVEM conter fragmentos de URL, CEK ou material de chave derivável.
  • Os logs DEVEM minimizar os dados pessoais e focar em eventos relevantes para a segurança (falhas de token, revogação, limites de taxa).
  • As mensagens de erro DEVEM ser acionáveis, mas não devem vazar segredos.

4.8 IDs de reivindicações relacionadas