Dossira Arquitectura de seguridad actual
Arquitectura actual de la vista previa privada de Dossira
Este documento describe el comportamiento que actualmente podemos verificar en el código fuente de la aplicación. No es una lista de controles planificados.
1. Alcance de la aplicación
Dossira se basa actualmente en un espacio de trabajo de archivos vinculado a una organización con:
- navegación por carpetas y archivos;
- carga, previsualización y descarga;
- operaciones comunes de archivos;
- membresía interna del espacio de trabajo;
- comparticiones externas creadas por el propietario;
- E2EE opcional para operaciones admitidas sobre contenido de archivos.
Los comentarios, las decisiones, un registro de actividad de room, el sellado, la exportación de auditoría, la facturación y la aplicación de cuotas no forman actualmente parte de la superficie del producto en la vista previa privada.
2. Autenticación y acceso de destinatarios
Miembros internos
Los miembros internos registrados pueden elegir una passkey en dispositivos compatibles mediante el sistema de identidad host. El mismo selector de inicio de sesión también ofrece correo y contraseña y enlace mágico, por lo que las passkeys son preferidas en lugar de obligatorias o exclusivas.
La disponibilidad de passkeys depende del soporte WebAuthn y de un autenticador disponible. Dossira no publica una garantía universal de navegador, sincronización de dispositivos o recuperación. Las passkeys de inicio de sesión también son distintas de las claves personales y de espacio de trabajo usadas por el E2EE opcional.
Destinatarios externos
Los destinatarios externos usan actualmente:
- compartición con correo confirmado y verificación por PIN; o
- un enlace público creado explícitamente.
Los destinatarios externos no reciben actualmente el mismo flujo de passkey que los miembros. La caducidad, revocación, extensión y reemisión de comparticiones están implementadas.
La revocación detiene el acceso posterior a través de la compartición de Dossira. No puede borrar archivos ya descargados o copiados fuera del servicio.
3. Cifrado de transporte e infraestructura
Los endpoints web y API de producción revisados usan HTTPS. La configuración de service mesh revisada usa mTLS estricto entre servicios de la malla, y la documentación actual de infraestructura registra discos cifrados para servidores de aplicación, base de datos, almacenamiento de objetos, failover y copias de seguridad.
Estos controles protegen los datos en tránsito y en los discos de servidor subyacentes. Son independientes del E2EE opcional del lado del cliente para cargas útiles de archivos y no significan que cada objeto almacenado use una clave de aplicación controlada por el cliente.
4. Límite E2EE opcional
La aplicación admite E2EE opcional de espacio de trabajo en la ruta de archivos con almacenamiento previo para carga, previsualización y descarga de cargas útiles de archivos.
Límites importantes:
- E2EE es opcional, no el comportamiento predeterminado de todos los espacios de trabajo;
- protege operaciones admitidas sobre cargas útiles de archivos, no todos los datos del espacio de trabajo;
- los nombres de archivo y los metadatos de carpetas permanecen fuera del límite E2EE;
- los flujos de compartición con invitados aún no proporcionan soporte E2EE equivalente;
- las operaciones de archivos respaldadas por espejo no usan la misma ruta E2EE.
Por tanto, el sitio web no afirma que Dossira sea ciego a nombres de archivo, todos los metadatos o contenido compartido con invitados.
El acceso a claves de espacio de trabajo cifrado y la recuperación dependen del flujo configurado de miembros y claves de espacio de trabajo, y deben probarse para la implementación. Dossira no publica una garantía universal de recuperación por el proveedor, ceguera del proveedor o acceso entre dispositivos.
5. Límite de alojamiento
Dossira es ofrecido por una empresa noruega. Los datos de clientes y las identidades de usuarios se alojan en infraestructura de Hetzner en Alemania y Finlandia. Dossira no utiliza AWS, Microsoft Azure ni Google Cloud para este alojamiento.
Para roles de responsable/encargado, proveedores de servicios e información sobre transferencias, consulte la Política de privacidad y el Acuerdo de procesamiento de datos.
6. Registros de actividad y afirmaciones de auditoría
El sistema subyacente conserva registros operativos estrechos:
- los recursos y versiones subidas conservan campos de creador y marca de tiempo;
- los tickets de compartición conservan detalles de creación, actualización, caducidad y revocación;
- los desafíos con correo confirmado conservan estado de envío, intento, consumo e invalidación.
El producto actual no expone un registro completo de eventos visible para el cliente ni una exportación de auditoría. En particular, esta auditoría no verificó eventos duraderos visibles para el cliente para cada entrada de room, entrada fallida, previsualización de archivo, descarga de archivo, cambio de membresía, acción de sellado/cierre o exportación.
Por tanto, actualmente no afirmamos que:
- cada acceso se registre en un libro visible para el cliente;
- cada acción clave esté disponible para auditoría;
- pueda exportarse un registro completo de actividad.
7. Ciclo de vida de room y sellado
Un ciclo de sellado de room o de cierre y exportación no está implementado. Actualmente no existe una transición de solo lectura a nivel de room, bloqueo de versión activado por sellado, manifiesto de cierre o exportación, acción de reapertura, regla de facturación, ni actor/marca de tiempo de sellado. El acceso externo de invitado en solo lectura es una capacidad de compartición, no sellado de room.
Los espacios de trabajo actuales no deben describirse como sellados, inmutables, a prueba de manipulaciones, permanentes o jurídicamente concluyentes.
8. Informar de una vulnerabilidad
Si cree que ha encontrado una vulnerabilidad, use la página de contacto e identifique el informe como relacionado con seguridad. No incluya contenido confidencial de clientes en un informe inicial.