Logo

Documento técnico sobre seguridad y privacidad (resumen)Capítulo 4

Capítulo 4 Autenticación, autorización y control de acceso

Este capítulo define el modelo de identidad de FileBolt, las capas de tokens y los límites del control de acceso. La subida y la descarga usan tokens de acceso de corta duración (sesiones en el servidor, basadas en consulta, con caducidad y alcance limitado) para controlar el acceso al texto cifrado y al manifiesto. Las acciones de gestión del remitente usan tokens de inicio de sesión de larga duración almacenados en el cliente. El sistema DEBE admitir la revocación, y los datos de auditoría DEBEN ser visibles solo para el remitente.

4.0 Resumen

  • Token de acceso de corta duración: controla el acceso al texto cifrado y al manifiesto; sesión en el servidor (consulta); DEBE vincularse a transferId; DEBE tener alcance limitado; DEBE caducar.
  • Token de inicio de sesión de larga duración: se usa para la gestión del remitente (eliminar, revocar, auditar); se almacena en el cliente; los destinatarios NO DEBEN usarlo para acceder al texto cifrado.
  • Separación entre claves y autorización: los tokens controlan únicamente el acceso al texto cifrado; la capacidad de descifrado proviene de la CEK en el fragmento de la URL (consulta el capítulo 5).

4.1 Modelo de identidad

  • El sistema admite un modelo de identidad de usuario de pago para la gestión del remitente.
  • El inicio de sesión del remitente PUEDE usar un enlace mágico de un solo uso; el cliente almacena un token de inicio de sesión de larga duración tras una autenticación correcta.
  • Los destinatarios no necesitan una cuenta para las descargas predeterminadas (consulta la documentación de UX); el acceso se controla mediante enlace o token.

4.2 Modelo de autorización y capas de tokens

Se usan dos tipos de token con una separación estricta de responsabilidades:

  1. Token de acceso de corta duración (sesión / consulta): para subir y descargar texto cifrado y leer el manifiesto; DEBE vincularse a transferId; DEBE caducar; DEBE tener alcance limitado por operación.
  2. Token de inicio de sesión de larga duración: para las acciones de gestión del remitente; NO DEBE conceder capacidad de descifrado.

4.2.2 Ejemplos de alcance

  • upload_chunk: subir fragmentos de texto cifrado de un transferId concreto.
  • read_manifest: leer el manifiesto de un transferId concreto.
  • download_chunk: descargar fragmentos de texto cifrado de un transferId concreto.

4.3 Autorización de subida

  • Las API de subida DEBEN validar el alcance del token y la vinculación con transferId antes de aceptar texto cifrado.
  • Las subidas de fragmentos DEBERÍAN ser idempotentes por (transferId, fileId, chunkIndex).
  • Ante un token no válido o una discrepancia, el sistema DEBE fallar en cerrado.

4.4 Autorización de descarga

  • El acceso al manifiesto y al texto cifrado DEBE exigir un token válido y con alcance limitado; los tokens DEBEN tener un límite de tiempo.
  • Los destinatarios NO DEBEN poder enumerar otras transferencias ni acceder a fragmentos fuera del transferId vinculado.
  • PUEDE aplicarse limitación de frecuencia para prevenir abusos (consulta el capítulo 7) sin romper la capacidad de reanudar.

4.5 Revocación e invalidación anticipada

  • Los remitentes DEBEN poder revocar una transferencia; la revocación DEBE inutilizar los tokens para accesos posteriores.
  • La revocación DEBERÍA activar la limpieza o la aceleración del TTL del texto cifrado siempre que sea viable.
  • La UX del destinatario DEBE indicar claramente el estado revocado o caducado y el siguiente paso (contactar con el remitente).

4.6 Auditoría y aislamiento de permisos

  • La evidencia de entrega (descargas, recuentos) DEBE ser visible solo para el remitente de forma predeterminada.
  • Las API de auditoría DEBEN exigir la autenticación del remitente y DEBEN estar aisladas de los tokens de acceso de los destinatarios.

4.7 Registros y minimización de datos sensibles

  • Los registros NO DEBEN contener fragmentos de URL, CEK ni material de claves derivable.
  • Los registros DEBERÍAN minimizar los datos personales y centrarse en eventos relevantes para la seguridad (fallos de token, revocaciones, límites de frecuencia).
  • Los mensajes de error DEBEN ser accionables, pero no deben filtrar secretos.

4.8 ID de afirmaciones relacionados