Cifrado y clave de recuperación

Cómo funciona

• El agente usa restic (versión 0.18.1, de código abierto) para cifrarlo todo en tu servidor con AES-256 antes de enviarlo. Al almacenamiento solo llegan bloques cerrados.
• Al instalar, se genera en tu servidor una clave del repositorio aleatoria, escrita en /etc/neverwiped/repo.key (solo la lee root). Nunca se nos envía.
• Una segunda clave, la clave de recuperación, se añade al repositorio y se te muestra una vez. Abre el mismo repositorio, así que puedes leer tus copias aunque el servidor y su repo.key hayan desaparecido.
• Todo viaja por TLS (HTTPS). Los discos del almacenamiento también están cifrados en reposo; eso protege frente a un disco perdido, no frente a alguien dentro de un servidor encendido.
• Las restauraciones se descifran en tu servidor, nunca en el nuestro.

Dónde está cada clave

Varios servidores

Cada servidor que instalas recibe sus propias claves. No se comparte nada entre dos servidores de tu cuenta:

Así, una fuga en un servidor (acceso root, un config.json copiado) expone las copias de ese servidor, no las de los demás. Desinstalar o recuperar un servidor revoca solo sus claves.

• Una sola clave de API de cuenta para varias instalaciones está bien. Solo sirve para registrar servidores (y recuperar uno perdido). Después cada servidor tiene su propia clave de agente, así que puedes revocar la clave de cuenta. Tu plan fija cuántos servidores cuentan a la vez; una instalación por encima se rechaza, aunque varias empiecen al mismo tiempo.
• Etiqueta cada clave de recuperación. El recuadro de la instalación muestra el nombre del servidor, su identificador y un código de control como 4342-B317. Anota los tres junto a la clave. El mismo código aparece en la página del servidor en tu panel, apartado «Clés de ce serveur», y en neverwiped status. El código no abre nada; solo indica a qué servidor pertenece cada clave.
• **neverwiped recover comprueba la clave antes de revocar nada.** Si la clave que escribes es la de otro servidor, dice cuál y se detiene: el servidor elegido sigue funcionando. Los servidores instalados antes del código de control lo reciben en su próxima copia; hasta entonces la clave solo se comprueba después de reemitir los accesos.
• **Nunca clones un servidor con /etc/neverwiped dentro**, ni copies esa carpeta a otra máquina. Dos máquinas compartirían las claves de un servidor. El agente lo detecta (el identificador de máquina de /etc/machine-id es distinto) y se niega a hacer copias allí. En la copia, ejecuta neverwiped uninstall --yes: quita las claves copiadas solo de esa máquina y no avisa a la plataforma, así que el original conserva sus claves. Después vuelve a instalar: la copia pasa a ser un servidor nuevo con sus propias claves. Si es el mismo servidor y solo cambió su identificador de máquina (sistema reinstalado con /etc/neverwiped repuesto), ejecuta neverwiped install --same-server.

Guardar bien la clave de recuperación

• Guárdala en un gestor de contraseñas el día de la instalación, con el nombre del servidor en la entrada.
• No en el propio servidor: si lo pierdes, la clave se va con él.
• Ni en un repositorio Git, ni en un archivo del proyecto, ni en un chat con un agente de IA, ni en un ticket.
• Una copia impresa en un lugar seguro está bien.
• La clave solo se muestra al crear el repositorio. Reinstalar en el mismo servidor no la vuelve a mostrar.

¿Perdiste la clave de recuperación?

Lo que se puede hacer depende de una sola cosa: **¿el servidor sigue funcionando, con /etc/neverwiped/repo.key dentro?**

**Qué hace recovery-key new.** Usa el repo.key de este servidor para añadir una segunda clave de recuperación al repositorio, comprueba que la clave nueva abre las copias y la muestra una vez, con el nombre del servidor y un nuevo código de control. Solo se nos envía el código de control. Tu panel muestra entonces el código nuevo y el titular de la cuenta recibe un correo sobre el cambio. El código anterior también queda registrado, así que neverwiped recover sigue aceptando la clave anterior si la encuentras.

Qué no hace. No elimina la clave anterior. El almacenamiento solo acepta adiciones desde tu servidor y nosotros no tenemos ninguna clave, así que la clave anterior sigue abriendo estas copias. No pasa nada si solo la perdiste (un cajón, una entrada borrada del gestor de contraseñas). Si otra persona pudo verla, es una filtración, no una pérdida: ver Si crees que se ha filtrado una clave.

Después de una clave nueva:

1. Guárdala en tu gestor de contraseñas, con el nombre del servidor y el nuevo código de control.
2. Prueba la copia anotada: sudo neverwiped recovery-key check.
3. Tira las copias de la clave anterior solo después.

Lo que puede hacer soporte: ayudarte a saber a qué servidor pertenece un código de control, y registrar el código de una clave nueva si la plataforma lo rechazó (tras diez sustituciones). Soporte no puede abrir, descifrar ni restaurar tus copias, ni crear una clave de recuperación por ti. Las copias que ya no puedes leer siguen ocupando espacio: borra ese servidor en tu panel (página del servidor) para eliminarlas.

Lo que no podemos hacer

No podemos leer tus copias, ni descifrarlas, ni restaurarlas por ti. No tenemos la clave del repositorio ni la de recuperación, y no existe ninguna «clave maestra».

Lo que la consola de soporte muestra de tu cuenta: tu dirección, la facturación, los servidores (nombre, versión del agente, tamaño) y las ejecuciones de copia (fechas, tamaños, número de archivos, resultado). No muestra tu plan de copia, y las rutas de archivos en los mensajes de error están ocultas. No puede crear credenciales de almacenamiento. Cada intervención del soporte necesita un motivo escrito y aparece en tu registro de auditoría con ese motivo.

Por eso, si pierdes a la vez el servidor y la clave de recuperación, tus copias no se pueden leer, ni por ti ni por nosotros. Mientras el servidor funcione, no cambia nada: el agente sigue usando repo.key. Es el precio de un cifrado que no podemos abrir, y preferimos decirlo claro.

Acceso del equipo

Puedes dar acceso a tu cuenta a tus compañeros desde tu panel › Equipo. Cada persona entra con su propia dirección y su propia contraseña; tú eliges un rol:

Ningún rol da acceso al contenido de tus copias: la plataforma nunca tiene la clave de recuperación. Un enlace de invitación se envía a una sola dirección, sirve una vez, durante 7 días, y solo para una cuenta con esa dirección confirmada. El titular recibe un correo cada vez que alguien se une.

Retirar a alguien corta su acceso en su siguiente página y revoca las claves de API de cuenta y los tokens de API que creó. Los servidores ya instalados siguen haciendo copias: cada uno tiene su propia clave de agente. Si esa persona tenía root en tus servidores, cambia también ese acceso: no lo controlamos.

Inicio de sesión: dos pasos y claves de acceso

En tu panel › Mi cuenta › Seguridad puedes proteger el inicio de sesión en este sitio con un segundo paso:

• Clave de acceso (passkey) o llave de seguridad: usa el bloqueo de tu dispositivo (huella, cara o PIN) o una llave USB/NFC. Solo funciona en este sitio, así que un sitio falso no puede reutilizarla. También puedes iniciar sesión solo con la clave de acceso, sin contraseña.
• App de autenticación: un código de 6 cifras de una app como Aegis, Google Authenticator, 1Password o Bitwarden, pedido después de la contraseña. Cada código sirve una sola vez.
• 10 códigos de emergencia, mostrados una sola vez al activar el primer método. Cada uno sustituye el segundo paso una vez. Guárdalos lejos de tu teléfono.

Una vez activado, la contraseña sola ya no abre tu cuenta, ni siquiera tras restablecerla por correo. Al activarlo se cierran tus otras sesiones, y cada cambio se te avisa por correo. Cada miembro de un equipo activa el suyo. Las cuentas del back-office deben tener uno.

Esto protege solo el acceso al sitio web. No cambia nada del cifrado de tus copias: la clave de recuperación de cada servidor sigue siendo la única llave de sus datos.

¿Perdiste el teléfono, la llave y los códigos de emergencia? Escribe al soporte desde la dirección de la cuenta. Un correo solo no basta para quitar la protección, porque es justo lo que pediría alguien que tenga tu buzón: primero comprobamos tu identidad, lo que puede tardar unos días laborables. Tus copias siguen funcionando mientras tanto.

Tokens de API para tus scripts

En tu panel › Claves de API › Tokens de API puedes crear un token para un script de supervisión o un panel. Abre la API pública, que es de solo lectura:

GET /api/v1/token indica qué es un token (permisos, caducidad). Envíalo como Authorization: Bearer nw_tok_….

• Un token no puede cambiar ni borrar nada, no puede registrar un servidor y no sirve para el agente. Ningún token lee el contenido de tus copias: no tenemos las claves.
• Eliges sus permisos, dentro de lo que permite tu rol en el equipo (solo el titular y los administradores pueden dar invoices:read y audit:read). Si tu rol cambia después, el token pierde al momento lo que el nuevo rol no permite. Si dejas el equipo o te retiran, tus tokens se revocan.
• Cada token caduca a los 30, 90 o 365 días (90 por defecto). Se muestra una sola vez; solo guardamos una huella.
• La página de claves de API muestra, para cada token, cuándo y desde qué dirección se usó por última vez y cuántas llamadas hizo en los últimos 30 días. La creación, la revocación y cada llamada rechazada quedan en el registro de la cuenta.
• Límite: 60 llamadas por minuto y por token.

Registro de auditoría

El titular y los administradores tienen una página Registro de auditoría en el panel. Muestra quién hizo qué en la cuenta, cuándo y desde qué dirección:

• los inicios de sesión (contraseña, dos pasos, clave de acceso), cambios de contraseña y ajustes de doble autenticación del titular y de cada miembro, desde el día en que se unió al equipo;
• las invitaciones, llegadas, cambios de rol y retiradas del equipo;
• las claves y tokens de API creados o revocados, y las llamadas de API rechazadas por falta de permiso;
• los servidores eliminados y los cambios de conservación, con la persona que los hizo;
• los cambios de plan, cancelaciones y reanudaciones;
• cada intervención del soporte de NeverWiped en tu cuenta (consulta, cierre de sesiones, restablecimiento de la doble autenticación, revocación de las claves de agente de un servidor, reembolso), mostrada como «NeverWiped support» con el motivo indicado;
• cada descarga del propio registro.

Las copias de seguridad no están en él: están en la página Historial y en GET /api/v1/servers/{id}/runs.

Filtra por fechas y categoría y descarga en CSV (se abre en una hoja de cálculo, UTF-8) o en JSON. Un archivo cubre como máximo 366 días y 50 000 filas. Las horas de los archivos están en UTC. Las celdas que una hoja de cálculo podría ejecutar como fórmula empiezan por un apóstrofo.

Para una herramienta de seguridad (SIEM), crea un token de API con audit:read y lee GET /api/v1/audit?after=<id>&limit=500: los eventos llegan del más antiguo al más reciente; guarda next_after y envíalo como after la vez siguiente. Sin after, la lectura empieza 30 días atrás (o en since=<fecha ISO>).

El registro contiene las direcciones de correo e IP de tus miembros: por eso los técnicos y los miembros de solo lectura no lo ven.

Si crees que se ha filtrado una clave

• **Clave de recuperación o repo.key:** quien la tenga, junto con la credencial de almacenamiento, puede leer las copias de ese servidor. Cambiar la clave del repositorio aún no es posible desde el CLI: escribe a soporte y plantéate una instalación limpia en un repositorio nuevo (neverwiped uninstall --yes y después neverwiped install crea un repositorio nuevo).
• Clave de API de cuenta: revócala en tu panel › Claves de API. Los servidores instalados siguen funcionando.
• Token de API: revócalo en tu panel › Claves de API › Tokens de API. Solo podía leer, nunca cambiar nada.
• Credencial de almacenamiento (config.json): no puede borrar copias, pero escribe a soporte para que se emita una nueva.

Lo que un agente de IA puede hacer, o no, con estas credenciales: Para agentes de IA.