Seguridad

Cómo protege NeverWiped tus copias, dicho claro. No reivindicamos ninguna certificación: describimos lo que hace el sistema, y lo que no, límites conocidos incluidos.

Cifrado

• Las copias se cifran en tu servidor, antes de salir de él, con restic (código abierto), AES-256 y autenticación Poly1305.
• La clave del repositorio se genera en tu servidor, en /etc/neverwiped/repo.key (solo root), y nunca se nos envía. Una clave de recuperación, mostrada una vez al crear el repositorio, abre el mismo repositorio. No tenemos ninguna de las dos: solo guardamos un código de control corto, que indica a qué servidor pertenece una clave de recuperación y no abre nada.
• Tu servidor solo habla con la plataforma y con el almacenamiento por TLS (HTTPS). Los discos del almacenamiento también están cifrados en reposo; eso protege frente a un disco perdido o sustituido, no frente a alguien dentro del servidor de almacenamiento en marcha.
• No podemos leer ni descifrar tus copias: las restauraciones se descifran en tu servidor, nunca en los nuestros. Si pierdes a la vez el servidor (con su repo.key) y la clave de recuperación, nadie puede leerlas.

Almacenamiento solo-añadir

• Las copias se guardan en Francia, un repositorio por servidor, cada uno con su credencial limitada a ese repositorio.
• En el día a día, un servidor puede añadir copias y leerlas, no borrarlas ni sobrescribirlas.
• Las copias antiguas se purgan como mucho una vez por semana, justo después de una copia, con una credencial aparte válida una hora y limitada al repositorio de ese servidor. La plataforma emite esa credencial como mucho una vez por servidor y por semana.
• Puedes suspender la purga de un servidor (página del servidor › Conservación). Entonces no se emite para él ninguna credencial capaz de borrar, y su espacio solo crece. Detalles: almacenamiento, retención y purga.

Límites conocidos

• Root en tu servidor. Quien sea root en tu servidor puede leer sus copias (con repo.key), y puede usar las claves de ese servidor para obtener la credencial de purga semanal y borrar las copias de ese servidor. También puede añadir copias falsas: la purga siguiente las cuenta en la retención, y así se pueden borrar copias reales más antiguas. Suspender la purga cierra ambas cosas. Tus otros servidores no se ven afectados: cada uno tiene sus propias claves y su propio repositorio.
• Nuestra plataforma. La plataforma puede borrar el repositorio de un servidor: así funciona el borrado cuando eliminas un servidor o tu cuenta, o tras una baja o una suscripción impagada (cuándo se borran las copias). También envía la retención que usa cada purga. Quien tomara el control de nuestra plataforma podría por tanto borrar copias, pero seguiría sin poder leerlas.
• Una sola copia. Tus copias se guardan una sola vez, en un servidor de almacenamiento, en discos en RAID 6: eso resiste dos discos averiados, no la pérdida del servidor entero. Tu propio servidor conserva los datos originales.

Dónde están las claves y los datos

El agente y la instalación

• El script de instalación comprueba la huella SHA-256 del agente antes de instalarlo. La huella viene de nuestro sitio, como el agente: detecta una descarga dañada, no un compromiso de nuestro sitio.
• Las actualizaciones del agente están firmadas (Ed25519) y el agente rechaza una actualización cuya firma no sea válida. La clave de firma no está en la plataforma.
• El agente descarga restic (versión 0.18.1) de las publicaciones oficiales de restic y comprueba su huella SHA-256, incluida en el agente, antes de usarlo.
• El agente es un único binario estático y se ejecuta como root (tiene que leer lo que copia). Aparte de esa descarga de restic, solo habla con la plataforma y el almacenamiento.
• Nunca restaura encima de tus archivos sin una confirmación explícita (escribir la palabra pedida, o --yes).

En la plataforma

• Solo los administradores pueden abrir la administración, y necesitan un segundo factor. Cada página consultada y cada acción en la administración quedan en un registro de auditoría. La administración no da acceso al contenido de las copias.
• Puedes proteger tu propia cuenta con un segundo factor o una llave de acceso (passkey). Eliminar un servidor o quitar a un miembro del equipo vuelve a pedir tu contraseña.
• Límites de peticiones protegen los inicios de sesión y la API frente a intentos repetidos.
• La base de datos de la plataforma se copia, cifrada, en un segundo sitio en Finlandia.

Lo que no reivindicamos

No tenemos ninguna certificación de seguridad ni publicamos cifras de disponibilidad. Si eso cambia, esta página lo dirá, con el certificado.

Informar de una vulnerabilidad

Escribe a TODO_LEGAL(EMAIL_SECURITE), en español, inglés o francés. Contacto legible por máquinas: security.txt. Esta sección es nuestra política de divulgación.

Qué enviarnos

• Qué has encontrado y dónde: la página o la dirección, o el agente y el comando implicados.
• Los pasos para reproducirlo, y lo que un atacante podría hacer con ello.
• Si quieres que te lo agradezcamos públicamente, y con qué nombre.

No incluyas datos de otro cliente en tu informe. Si has visto alguno, dinos de qué se trataba, sin copiarlo.

Qué hacemos

• Acusamos recibo en 3 días hábiles, y te damos una primera evaluación en 10 días hábiles.
• Te mantenemos informado hasta la corrección, y te avisamos cuando esté en línea.
• Intentamos corregir los problemas graves en 30 días. Si tarda más, te decimos por qué y hasta cuándo.
• Si quieres, te damos las gracias con tu nombre en esta página una vez publicada la corrección. No pagamos recompensas: no hay programa de bug bounty.

Publicación

Danos un plazo razonable para corregir antes de publicar nada: proponemos 90 días desde tu informe, o menos una vez la corrección en línea y el agente actualizado por nuestros clientes. Acordamos la fecha contigo, y podemos publicar nuestro propio aviso de seguridad.

Alcance

• Incluido: este sitio y el área de cliente, el sitio de documentación, el script de instalación, el agente, y el servicio de almacenamiento al que tus servidores envían sus copias.
• Excluido: los servicios de otras empresas (nuestro proveedor de alojamiento, nuestro proveedor de pagos, nuestros proveedores de correo): infórmales directamente; restic en sí: infórmalo al proyecto restic; los informes que solo enumeran cabeceras o ajustes de correo ausentes, sin forma de explotarlos.

Reglas

• Prueba solo con tu propia cuenta y tus propios servidores.
• No accedas a datos o copias de otros clientes, ni los modifiques ni los borres. Si llegas a alguno, detente y avísanos.
• No degrades el servicio: nada de pruebas de carga o de denegación de servicio, nada de spam, nada de escaneos automáticos que saturen el sitio.
• Nada de ingeniería social con nuestro equipo o nuestros clientes, ni pruebas físicas.
• Guarda los detalles para ti hasta la fecha acordada.

Dentro de esos límites, la investigación de buena fe es bienvenida y no emprenderemos acciones contra ella. TODO_LEGAL(redacción de la cláusula de investigación de buena fe por validar)