Cómo cifra Restow sus datos
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.
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.
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, de modo que quien pueda cambiar la configuración de un equipo en Restow puede ejecutar comandos como root en esa máquina. Trate el acceso de administrador en consecuencia. El script de instalación y las actualizaciones del agente comprueban sumas SHA-256 que proceden de su propio Restow, lo que protege de descargas dañadas, no de una instancia comprometida; las actualizaciones del agente todavía no están firmadas.
Versiones firmadas
Cada imagen de versión 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. 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. 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.
El aviso al operador
El asistente de instalación empieza con 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. 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 rechaza los pasos posteriores de la instalación mientras no exista. 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).
¿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, y los hooks previos y posteriores también, por lo que quien pueda cambiar la configuración de un equipo en Restow puede ejecutar comandos como root en esa máquina.
¿Puedo comprobar que una versión procede realmente del proyecto Restow?
Sí. Cada imagen de versión se firma con cosign (modo keyless, mediante GitHub OIDC), incluye un SBOM y se construye 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. Las actualizaciones del agente, en cambio, se comprueban con una suma SHA-256 de su propio Restow, pero todavía no están firmadas.