Cómo cifra Restow sus datos
Por Lucas Flores, IT Systeme Flores UG. Última actualización:
Cada bloque que Restow escribe en el almacenamiento se cifra con AES-256-GCM antes de salir del servidor, con una clave de cifrado independiente por organización. Eso es una propiedad estructural del almacén de bloques, no un ajuste que haya que recordar activar, y se aplica igual en todas las ediciones.
Quién puede leer realmente sus datos
En una instalación autoalojada (la forma habitual de ejecutar Community o Business), la clave de su organización nunca sale de su propia infraestructura, y nadie fuera de ella tiene la clave. En una instancia que un proveedor de servicios opera para usted bajo la edición Service Provider, ese proveedor tiene la clave maestra de la instalación para operar el servicio (algo inevitable para un servicio que opera otra persona), y con ella puede descifrar técnicamente los datos de cualquier cliente, incluso completamente fuera de Restow (por ejemplo con la herramienta independiente de restauración sin conexión y el almacén de bloques directamente, sin pasar por la aplicación en ejecución). Las lecturas y restauraciones dentro de Restow pasan por vías auditadas y quedan registradas en un registro con detección de manipulaciones y con cadena de hashes: quién, cuándo, para quién y desde qué IP. Pero ese registro no ve un acceso realizado fuera de Restow con la clave maestra directamente. Elija un proveedor en el que confíe por la misma razón por la que confiaría en cualquiera que tenga una clave maestra de sus datos, y haga que su contrato de encargo del tratamiento (art. 28 RGPD) lo regule explícitamente.
Roles de base de datos
Desde la 0.3.5, el inicio de sesión (sesiones, contraseñas, llaves de
acceso y secretos de doble factor) funciona con un rol de base de
datos propio. El rol de la aplicación se limita a los datos de los
clientes bajo la seguridad a nivel de fila de PostgreSQL y solo puede
añadir trabajos a la cola. La migración de la base de datos crea el
rol de inicio de sesión y lo mantiene al día; no hace falta cambiar el
archivo .env, y DATABASE_AUTH_URL es
opcional para las instalaciones que gestionan ellas mismas sus roles
de base de datos.
Es un refuerzo, y no se conoce ninguna explotación. Hasta la 0.3.4, el rol de la aplicación también podía leer y escribir las tablas fuera de la seguridad a nivel de fila, entre ellas las tablas de inicio de sesión, los ajustes de la instalación, la licencia y la cola de trabajos, de modo que un fallo en el código de consultas por cliente podría haber alcanzado datos más allá de su cliente. El cambio limita lo que puede alcanzar un fallo así; no significa que no exista ninguno.
Sin llamadas a casa
Restow no llama a casa: sin telemetría, sin servidor de licencias contactado en tiempo de ejecución, sin conexión de vuelta a IT Systeme Flores UG. Solo se conecta con lo que usted configure: Microsoft 365, sus servidores IMAP, el almacenamiento que elija y su transporte de correo. Además, solo cuando se ejecuta en modo público, Let's Encrypt para su propio certificado TLS; solo si usted activa la comprobación de actualizaciones, la fuente de actualizaciones que haya elegido; y solo si activa el actualizador opcional, el registro del que este descarga las imágenes (ghcr.io por defecto). Los agentes de equipos solo hablan con su propio Restow. Una clave de licencia se verifica sin conexión frente a una firma Ed25519, sin contactar en absoluto con ningún servidor. Desde la 0.4.5 una clave también puede llevar un periodo de actualizaciones: si una versión está cubierta se decide con la clave y con la fecha de publicación que lleva la imagen de la versión, no con una llamada a un servidor, y la versión instalada sigue funcionando con todos sus módulos.
El agente de equipos
El agente que respalda servidores y equipos (véase copia de servidores y equipos) se conecta solo con conexiones salientes por HTTPS y no abre ningún puerto. Solo anexa: puede añadir copias, pero nunca borrarlas ni sobrescribirlas, y la retención y la limpieza se ejecutan únicamente en el servidor de Restow. Nunca tiene las credenciales del destino de almacenamiento, solo su propio secreto de agente y la contraseña de su propio repositorio. Dos límites se indican con claridad. Todavía no hay mTLS: cada agente se autentica con un secreto propio por HTTPS, de modo que un secreto robado (root en la máquina) permitiría escribir copias nuevas en el repositorio de esa máquina y leerlo, pero no borrar nada. Y el agente se ejecuta como root, porque tiene que leer cada archivo que respalda. Los hooks previos y posteriores también se ejecutan como root, así que el equipo decide si los ejecuta: en un equipo nuevo están desactivados, solo root en el equipo puede permitirlos (solo scripts con nombre o cualquier comando), y Restow no puede ni cambiar ese ajuste ni configurar un hook que el equipo no ejecutaría. Donde se permite cualquier comando, quien pueda cambiar la configuración de ese equipo en Restow puede ejecutar comandos como root en él; trate el acceso de administrador en consecuencia.
El agente se instala en una carpeta que solo root puede modificar, y
cada versión del agente la firma el mantenedor con una clave Ed25519
que está compilada en el agente y escrita en el script de
instalación. El instalador y la actualización automática del agente
comprueban esa firma y el SHA-256 de cada archivo antes de ejecutar
nada, de modo que una instancia comprometida no puede hacer que un
agente instalado ejecute un binario propio. Queda un límite: la
primera instalación confía en el script de instalación que sirve la
instancia, como cualquier curl | sh. Compare la huella
de la clave de versión que muestra el script con la publicada,
SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (Ed25519, también en las notas de la versión).
Versiones firmadas
Cada versión sale en dos compilaciones: las imágenes completas
restow y restow-web, y las imágenes
Community restow-community y
restow-web-community. Cada una de las cuatro imágenes se
construye para amd64 y arm64, se firma con cosign (modo keyless,
mediante GitHub OIDC) e incluye un SBOM en formato SPDX, adjunto
también como atestación de cosign. Los archivos de la versión constan
en un archivo de sumas de comprobación que también está firmado, y
las versiones del agente llevan la firma propia del mantenedor (véase
arriba). Cómo comprobar todo esto se
describe en la documentación (en inglés):
verify releases.
Actualizaciones y actualizador
La comprobación de actualizaciones está desactivada hasta que un administrador la activa. Una vez activa, solo lee la lista de versiones de la fuente que eligió el operador (por defecto las versiones públicas de GitHub, o su propio repositorio de GitHub, Forgejo o Gitea), una vez al día o a petición, y ninguna solicitud lleva datos sobre su instalación. El actualizador opcional es de activación voluntaria y un perfil de Compose aparte que no hace nada hasta que usted lo inicia. Antes de descargar una imagen, comprueba su firma de cosign frente a la identidad del flujo de publicación y rechaza una imagen que no puede verificar. Cambiar la fuente de actualizaciones y anunciar una actualización piden un inicio de sesión reciente. El actualizador necesita el socket de Docker, que equivale a acceso root al anfitrión: un compromiso documentado, descrito en la documentación (en inglés) bajo updates, que conviene leer antes de activarlo.
Desde la 0.3.6, un cambio que solo surte efecto tras un reinicio muestra en Instalación, Actualizaciones un aviso «Reinicio necesario» con el motivo y el comando para copiar, y los administradores del proveedor ven un aviso sobre cada página. Si el actualizador está en marcha, el propietario del equipo del proveedor tiene además un botón «Reiniciar ahora». Pasa por el actualizador y reinicia solo la API, el worker o el scheduler, ningún otro servicio. Nunca se ejecuta mientras una actualización está anunciada o en curso, pide antes una confirmación y el registro de auditoría anota quién lo pidió. Nada se reinicia sin un clic. El botón necesita el actualizador de la 0.3.6; uno anterior muestra el comando. Todavía nada registra una solicitud de reinicio: el aviso y el botón están listos para las actualizaciones que los necesiten.
Desde la 0.4.2, una actualización también se puede planificar para una fecha y
hora elegidas, hasta con 30 días de antelación, en la zona horaria de la
instalación. Antes no se pausa nada: el servidor confirma el plan la cuenta atrás
antes de la hora elegida exactamente como si un administrador lo hubiera confirmado
entonces, con las mismas comprobaciones, y todos los usuarios conectados ven un
aviso desde un día antes. Cuando el servidor ejecuta la versión nueva, la instalan
también los nodos de Proxmox VE y los agentes, solo cuando están libres, con la misma
descarga firmada que su propia autoactualización (el agente comprueba el
SHA256SUMS firmado con la clave incorporada, y después cada archivo
con su hash firmado), y las ejecuciones nuevas esperan a que lo hayan hecho, 15
minutos como máximo. restow-agent update lo hace a mano en un equipo,
como restow-pve update en un nodo; mientras se ejecuta una copia, se
niega.
Desde la 0.3.6, volver a ejecutar el instalador
(install.sh) en una instalación existente actualiza
además un docker-compose.yml antiguo a la versión que
indica .env. El instalador comprueba el archivo con el
SHA256SUMS firmado de la versión, conserva el archivo
antiguo como docker-compose.yml.bak-<timestamp> y
deja .env como está.
Copias inmutables y detección de ransomware
El cifrado protege lo que un atacante puede leer; no impide el borrado. Desde la 0.4.0 lo hacen dos capas más. Cada repositorio se puede hacer inmutable: en S3 con Object Lock, el propio almacenamiento se niega a borrar o sobrescribir los datos de copia bloqueados antes de su fecha, lo pida quien lo pida; un directorio recibe solo un retraso de borrado que Restow cumple por sí mismo y que no es inmutabilidad. Está desactivado hasta que un administrador lo activa, y reducirlo exige al propietario del proveedor con un inicio de sesión reciente. Qué se bloquea y qué no, y contra qué no protege, está en la página de almacenamiento. La detección de ransomware juzga cada punto de restauración nuevo, marca los sospechosos, avisa una vez por ataque y pausa la retención del objeto hasta que un administrador resuelva el hallazgo. Es un sistema de aviso temprano, no un antivirus, y solo se probó con ataques simulados; véase detección de ransomware.
Endpoints S3 por HTTPS
Desde la 0.4.0 se rechaza un endpoint S3 nuevo o modificado por
http:// sin cifrar, también para los administradores del
proveedor y el valor predeterminado de la instalación, salvo hacia la propia
máquina. Los endpoints guardados antes siguen funcionando y dicen en rojo que
deberían pasar a HTTPS.
El mounter y los recursos compartidos
La copia de recursos compartidos (véase
recursos compartidos) se
ejecuta en contenedores runner de vida corta que arranca el mounter, y el
mounter tiene el socket de Docker, es decir, acceso equivalente a root en el
host. Las instalaciones nuevas lo arrancan por defecto;
install.sh --no-mounter lo deja apagado, y conviene leer antes
las notas de seguridad del mounter
(en inglés). Un runner no tiene más red que una interna hacia la API, monta
el recurso solo de lectura y escribe con una credencial que vale para una
ejecución y es de solo anexado. Los administradores del inquilino pueden
añadir recursos compartidos por sí mismos; un recurso en una dirección privada
o de bucle local necesita la aprobación de un administrador del proveedor o el
interruptor de la instalación «Los inquilinos pueden añadir recursos en redes
privadas».
Volcados de la base de datos, actualizaciones y restauración de archivos
Antes de una actualización, el actualizador guarda un volcado de la base de datos. La pestaña Actualizaciones enumera esos volcados, y el propietario del proveedor puede descargar uno, mediante un enlace de un solo uso, tras un inicio de sesión reciente y con una entrada de auditoría, o eliminarlo. Un volcado contiene toda la base de datos, secretos cifrados incluidos: guarde un volcado descargado con tanto cuidado como la clave maestra. Cuando se confirma una actualización, su diálogo cuenta lo que sigue en ejecución en cada inquilino y pregunta si detener las ejecuciones limpiamente, esperarlas o no esperar; desde la confirmación hasta el final de la actualización no arranca ninguna ejecución nueva. Desde la 0.4.2 un administrador también puede detener una copia en curso desde la aplicación web (invitados de Proxmox VE, equipos y ejecuciones de recursos compartidos); cada parada pregunta antes y queda en el registro de auditoría, y la ejecución termina como cancelada.
Los operadores de restauración, que ven y restauran copias sin administrarlas, pueden ahora abrir también Servidores y equipos, Restauración de archivos: exploran puntos de restauración, descargan archivos como ZIP y restauran archivos en un equipo, y en Proxmox VE exploran y descargan archivos de puntos de restauración de contenedores y VM. Los ajustes, los tokens, los trabajos, copiar, restaurar un invitado entero y la contraseña del repositorio siguen con los administradores. Cada lectura, descarga y restauración queda en el registro de auditoría con el operador como actor. Una descarga preparada de archivos de Proxmox VE se puede iniciar una vez, en diez minutos, por el administrador que la preparó, y los archivos de una VM los lee el servidor en un proceso hijo restringido, sin montar nada.
El aviso al operador
El asistente de instalación pide primero un token de instalación de un solo uso, que solo puede leer quien tiene acceso al registro (o a la configuración) del servidor. Después muestra un aviso al operador que hay que aceptar antes que cualquier otra cosa: el hardware y el almacenamiento (redundancia, inmutabilidad o WORM), la custodia de las claves de cifrado, la seguridad de red y de acceso y las pruebas de restauración son responsabilidad del operador, y el archivo está diseñado para un uso conforme a GoBD. Los datos solo son inmutables si el almacenamiento los hace inmutables: sin Object Lock en la ubicación de almacenamiento, cualquiera que pueda llegar a ella puede cambiar o borrar las copias. Desde la 0.4.0 Restow puede bloquear datos de copia en S3 con Object Lock, y un directorio recibe solo un retraso de borrado (véase arriba). La aceptación (versión del texto, hora, dirección del cliente) se guarda y se escribe en el registro de auditoría, y el servidor no completa la instalación sin ella. Véase la documentación (en inglés): operator notice.
El resto del panorama
El cifrado es una pieza de la historia de la soberanía; dónde viven físicamente los bytes cifrados es la otra. Véase almacenamiento y, en inglés, Your data is your data para el panorama completo.
Preguntas frecuentes
¿Cómo se cifran mis datos en Restow?
Cada bloque se cifra con AES-256-GCM antes de salir del servidor, con una clave independiente por organización (cliente). El cifrado no es opcional ni depende de la edición: se aplica igual en Community, Business y Service Provider.
¿Puede el operador de mi instancia de Restow leer mis datos?
En una instalación autoalojada (la forma habitual de ejecutar Community o Business), nadie fuera de su organización tiene la clave. En una instancia operada por un proveedor de servicios, el proveedor tiene la clave maestra de la instalación y puede, con ella, descifrar técnicamente los datos del cliente, incluso fuera de la aplicación Restow en ejecución, por ejemplo con la herramienta independiente de restauración sin conexión. Las lecturas y restauraciones dentro de Restow pasan por vías registradas y auditadas (quién, cuándo, para quién, desde qué IP) en un registro con detección de manipulaciones y con cadena de hashes; un acceso fuera de Restow con la clave maestra directamente no aparece ahí. Elija un proveedor de confianza y recoja esto explícitamente en su contrato de encargo del tratamiento (art. 28 RGPD).
¿Qué permisos de base de datos tiene la aplicación Restow?
Desde la 0.3.5, el inicio de sesión (sesiones, contraseñas, llaves de acceso, secretos de doble factor) funciona con un rol de base de datos propio, y el rol de la aplicación se limita a los datos de los clientes bajo la seguridad a nivel de fila y solo puede añadir trabajos a la cola. Hasta la 0.3.4, el rol de la aplicación también podía leer y escribir las tablas fuera de la seguridad a nivel de fila, como las tablas de inicio de sesión, los ajustes de la instalación, la licencia y la cola de trabajos. Fue un refuerzo, no la corrección de una explotación conocida.
¿Reinicia Restow sus servicios por sí solo?
No. Cuando un cambio solo surte efecto tras un reinicio, Restow muestra un aviso «Reinicio necesario» con el motivo y el comando que se ejecuta en el servidor y, si el actualizador está en marcha, un botón «Reiniciar ahora» para el propietario del equipo del proveedor. El botón pasa por el actualizador, reinicia solo la API, el worker o el scheduler, nunca se ejecuta mientras una actualización está anunciada o en curso y pide antes una confirmación. Nada se reinicia sin un clic. Todavía nada registra una solicitud de reinicio; el aviso y el botón están listos para las actualizaciones que los necesiten.
¿Se pueden bloquear las copias para que nadie las borre?
Por repositorio, desde la 0.4.0. En un bucket S3 creado con Object Lock, Restow bloquea los datos de copia en modo compliance o governance durante 1 a 3650 días, y el propio almacenamiento se niega a borrarlos o sobrescribirlos antes de la fecha. Un directorio recibe solo un retraso de borrado que Restow impone por sí mismo y que no es inmutabilidad. La inmutabilidad está desactivada hasta que un administrador la activa, y no ayuda si alguien que controla Restow detiene los bloqueos; lo que está bloqueado sigue bloqueado hasta su fecha. Se probó con un S3 simulado, todavía no con un servicio S3 real con Object Lock.
¿Detecta Restow el ransomware?
Juzga cada punto de restauración nuevo en busca de señales (la cantidad de cambios, los borrados, las extensiones renombradas, los nombres conocidos, los archivos de muestra que parecen cifrados, los datos que no se comprimen ni se deduplican), marca los sospechosos, avisa una vez por ataque y pausa la retención de ese objeto hasta que un administrador resuelva el hallazgo. Es un sistema de aviso temprano, no un antivirus, nunca bloquea una copia y se probó con ataques simulados, no con ransomware real.
¿Envía Restow telemetría o llama a casa?
No. Sin telemetría, sin servidor de licencias contactado en tiempo de ejecución, sin conexión con IT Systeme Flores UG. Solo se conecta con lo que usted configure: Microsoft 365, sus servidores IMAP, su almacenamiento y su transporte de correo. Además, solo en modo público, Let's Encrypt para su propio certificado TLS; solo si usted activa la comprobación de actualizaciones, la fuente de actualizaciones que haya elegido; y solo si activa el actualizador opcional, el registro del que este descarga las imágenes (ghcr.io por defecto). Los agentes de equipos solo hablan con su propio Restow.
¿Qué puede hacer el agente en un equipo, y qué no?
El agente se conecta solo con conexiones salientes por HTTPS y no abre ningún puerto. Solo anexa: puede añadir copias, pero nunca borrarlas ni sobrescribirlas, y nunca tiene las credenciales del almacenamiento. Todavía no hay mTLS, así que cada agente se autentica con un secreto propio por HTTPS. El agente se ejecuta como root. Los hooks previos y posteriores también, así que decide el equipo: están desactivados hasta que root en el equipo los permite (solo scripts con nombre o cualquier comando), y Restow no puede cambiar ese ajuste.
¿Puedo comprobar que una versión procede realmente del proyecto Restow?
Sí. Cada versión sale en dos compilaciones con cuatro imágenes (restow y restow-web, la compilación completa; restow-community y restow-web-community, la compilación Community), cada una firmada con cosign (modo keyless, mediante GitHub OIDC), con un SBOM y construida para amd64 y arm64. Los archivos de la versión están cubiertos por una lista de sumas de comprobación firmada. La documentación muestra el comando de verificación. Cada versión del agente la firma el mantenedor con una clave Ed25519; el instalador y el agente comprueban esa firma antes de ejecutar nada. La primera instalación confía en el script de instalación que sirve su instancia: compare la huella de la clave de versión que muestra con la publicada, SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (también en las notas de la versión).
Cómo funciona el aislamiento entre clientes →
Detección de ransomware: cómo se juzga cada punto de restauración →
Más en Aprender: copias inmutables, WORM, air gap y ransomware →
Más en Aprender: RGPD y copias de seguridad (supresión, cifrado, encargados del tratamiento) →