Logo

Informe técnico sobre seguridad y privacidad (descripción general)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 de control de acceso. La carga y descarga utilizan tokens de acceso de corta duración (sesiones del lado del servidor, basadas en búsquedas, con vencimiento, con alcance) para controlar el texto cifrado y el acceso al manifiesto. Las acciones de gestión del remitente utilizan 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 sólo para el remitente.

4.0 Resumen

  • Token de acceso de corta duración: puertas de acceso a texto cifrado/manifiesto; sesión del lado del servidor (búsqueda); DEBE vincularse a transferId; DEBE tener alcance; DEBE caducar.
  • Token de inicio de sesión de larga duración: utilizado para la gestión de remitentes (eliminar/revocar/auditar); almacenado en el cliente; Los destinatarios NO DEBEN utilizarlo para acceder al texto cifrado.
  • Separación de claves y autorización: los tokens controlan únicamente el acceso al texto cifrado; La capacidad de descifrado proviene de CEK en el fragmento de URL (consulte el Capítulo 5).

4.1 Modelo de identidad

  • El sistema admite un modelo de identidad de usuario pago para la gestión de remitentes.
  • El inicio de sesión del remitente PUEDE utilizar un enlace mágico de una sola vez; el cliente almacena un token de inicio de sesión de larga duración después de una autenticación exitosa.
  • No es necesario que los destinatarios tengan una cuenta para las descargas predeterminadas (consulte los documentos de UX); el acceso está controlado por enlace/token.

4.2 Modelo de autorización y capas de tokens

Se utilizan dos tipos de tokens con estricta separación de responsabilidades:

  1. Token de acceso de corta duración (sesión/búsqueda): para carga/descarga de texto cifrado y lectura de manifiesto; DEBE vincularse a transferId; DEBE caducar; DEBE tener un alcance por operación.
  2. Token de inicio de sesión de larga duración: para acciones de gestión de remitentes; NO DEBE otorgar capacidad de descifrado.

4.2.2 Ejemplos de alcance

  • upload_chunk: carga fragmentos de texto cifrado para un transferId específico.
  • read_manifest: lee el manifiesto para un transferId específico.
  • download_chunk: descargue fragmentos de texto cifrado para un transferId específico.

4.3 Autorización de carga

  • Las API de carga DEBEN validar el alcance del token y el enlace transferId antes de aceptar texto cifrado.
  • Las cargas de fragmentos DEBEN ser idempotentes por (transferId, fileId, chunkIndex).
  • En caso de token no válido o no coincide, el sistema DEBE cerrarse por error.

4.4 Autorización de descarga

  • El acceso al manifiesto y al texto cifrado DEBE requerir un token válido con alcance; 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.
  • La limitación de la tasa PUEDE aplicarse para la prevención del abuso (consulte el Capítulo 7) sin interrumpir la reanudación.

4.5 Revocación e invalidación anticipada

  • Los remitentes DEBEN poder revocar una transferencia; la revocación DEBE inutilizar los tokens para el acceso posterior.
  • La revocación DEBE activar la limpieza/aceleración TTL para texto cifrado cuando sea posible.
  • La UX del destinatario DEBE indicar claramente el estado revocado/caducado y el siguiente paso (contactar al remitente).

4.6 Auditoría y aislamiento de permisos

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

4.7 Registro y minimización de datos confidenciales

  • Los registros NO DEBEN contener fragmentos de URL, CEK ni material de clave derivable.
  • Los registros DEBEN minimizar los datos personales y centrarse en eventos relevantes para la seguridad (fallos de tokens, revocación, límites de velocidad).
  • Los mensajes de error DEBEN ser procesables pero no deben filtrar secretos.

4.8 ID de reclamaciones relacionadas