¿Qué capa de respaldo debería gestionar las claves de cifrado: el cliente, el repositorio o el destino externo?
Para la mayoría de las copias de seguridad de servidores domésticos, la aplicación o el cliente de copia de seguridad debería controlar el cifrado necesario para leer la copia de seguridad, mientras que el cifrado del proveedor de almacenamiento externo debería tratarse como una capa adicional. Esto evita que un compromiso de la nube o del almacenamiento remoto exponga automáticamente el contenido de las copias de seguridad y, al mismo tiempo, conserva un formato de copia de seguridad que puede seguir deduplicando, verificando y restaurando los datos de forma eficiente.
La distinción importante no es simplemente «cifrado del lado del cliente frente a cifrado del lado del servidor». Debes decidir qué dominio de fallo es el propietario del secreto de descifrado. Si la única clave existe en el servidor de origen, un origen averiado o cifrado por ransomware puede destruir la capacidad de recuperación. Si el destino externo posee la única clave relevante, el operador del destino o una cuenta de destino comprometida pueden seguir dentro del límite de confianza. El mejor diseño separa los datos de copia de seguridad, las credenciales del repositorio y las claves de recuperación.
Hay tres lugares diferentes donde puede residir el cifrado
La expresión «copia de seguridad cifrada» oculta varias arquitecturas. Los archivos de origen pueden cifrarse antes de que la herramienta de copia de seguridad los procese. La herramienta de copia de seguridad puede cifrar el formato de su repositorio antes de enviar los objetos al almacenamiento local o remoto. O bien, el sistema de almacenamiento de destino puede recibir los datos y cifrarlos en reposo mediante su propia capa de gestión de claves.
| Capa | ¿Quién realiza el cifrado? | ¿Quién debe conservar un secreto de recuperación? | Principal ventaja | Principal desventaja |
|---|---|---|---|---|
| Cifrado previo en el cliente | Aplicación de origen o herramienta de cifrado | Propietario de la clave del cliente/usuario | Fuerte separación respecto al repositorio de copias de seguridad y al proveedor | Puede reducir la deduplicación optimizada para copias de seguridad, la visibilidad de los metadatos y la comodidad de las restauraciones granulares |
| Cifrado del repositorio de copias de seguridad | Software de copia de seguridad antes del almacenamiento | Titular de la clave/frase de contraseña del repositorio | El mejor equilibrio entre confidencialidad y funciones de copia de seguridad | Perder la clave o la frase de contraseña puede hacer que todo el repositorio sea ilegible |
| Cifrado del destino externo | Servicio de nube/NAS/almacenamiento | Clave del destino administrada por el proveedor, KMS o el cliente | Protección sencilla para los datos en reposo | El destino sigue formando parte del límite de confianza del descifrado |
El cifrado a nivel de repositorio suele ser la mejor opción predeterminada
Las herramientas modernas de copias de seguridad están diseñadas para cifrar los datos como parte del formato del repositorio. La documentación de cifrado de Restic trata el cifrado como una función esencial del repositorio y admite varias claves de acceso o contraseñas. Kopia describe de forma similar sus repositorios como una capa que añade cifrado y deduplicación sobre backends de almacenamiento como sistemas de archivos, S3 y almacenes de objetos en la nube.
Borg hace que el modelo de confianza sea especialmente explícito. Su documentación de seguridad presupone que el entorno del cliente es de confianza y que el repositorio puede ser hostil. Borg cifra los datos localmente para que un repositorio remoto no reciba los archivos en texto plano ni la clave de copia de seguridad sin cifrar.
Este patrón resulta atractivo para un NAS doméstico porque la aplicación de copias de seguridad aún puede ver los archivos originales mientras crea la copia. Puede realizar fragmentación, deduplicación, compresión, gestión de metadatos de instantáneas, verificación y restauraciones selectivas antes del cifrado o al mismo tiempo. El destino de almacenamiento recibe objetos cifrados del repositorio en lugar de archivos legibles normales.
No confundas la clave del repositorio con la credencial de almacenamiento
Una clave de acceso a un bucket en la nube, una clave privada de SFTP, una contraseña de un NAS remoto y una clave de descifrado de copias de seguridad son secretos diferentes, aunque un script de automatización necesite todos. La credencial de almacenamiento responde a «¿puede este cliente leer o escribir objetos del repositorio?». La clave del repositorio responde a «¿se pueden descifrar estos objetos para convertirlos en datos de la copia de seguridad?».
Separar ambos aspectos es importante durante un incidente. Un atacante que robe una credencial de un bucket con permisos de escritura no debería obtener automáticamente el secreto de descifrado del repositorio. Del mismo modo, tener la frase de contraseña de la copia de seguridad no debería conceder necesariamente acceso administrativo a la cuenta de almacenamiento externa.
La guía de ZimaSpace sobre verificar todas las claves necesarias para una restauración cifrada es un complemento útil porque identifica el acceso al repositorio, el cifrado de las copias de seguridad, el almacenamiento de destino, los secretos de los contenedores y los secretos a nivel de aplicación como dependencias de recuperación independientes.
El cifrado en el cliente es mejor para datos limitados de alta sensibilidad
Cifrar los archivos antes de que la aplicación de copias de seguridad los lea puede tener sentido cuando un conjunto de datos específico debe permanecer opaco incluso para las herramientas de copia de seguridad habituales o los administradores. Algunos ejemplos son un pequeño archivo legal, una base de datos de contraseñas exportada, un paquete de claves privadas o un contenedor cifrado controlado por el cliente.
La contrapartida es que un cifrado realizado demasiado pronto puede ocultar estructuras que el sistema de copias de seguridad aprovecharía de otro modo. Si cada archivo modificado se convierte en una salida cifrada completamente distinta, la compresión y la deduplicación pueden resultar menos eficaces. La exploración granular de archivos también puede convertirse en una restauración en dos pasos: recuperar primero el objeto cifrado y después desbloquearlo con otra herramienta.
Por ese motivo, el cifrado previo del conjunto de datos completo suele ser una arquitectura de copias de seguridad domésticas predeterminada más débil que usar una herramienta de copias de seguridad con cifrado nativo y autenticado del repositorio. Úselo cuando necesite deliberadamente un segundo límite de confianza alrededor de un subconjunto de datos.
El cifrado del lado del servidor externo protege el almacenamiento, no todo el modelo de confianza de las copias de seguridad
Los almacenes de objetos en la nube suelen cifrar los datos en reposo. Amazon S3, por ejemplo, aplica el cifrado del lado del servidor de forma predeterminada y admite claves de KMS administradas por AWS o por el cliente. Su documentación sobre SSE-KMS describe cómo S3 realiza el cifrado en el destino, mientras AWS KMS controla las claves y los permisos.
Backblaze B2 también admite SSE-B2 administrado por el proveedor y SSE-C administrado por el cliente. Su documentación sobre el cifrado del lado del servidor señala que SSE protege los datos de los archivos en reposo y que perder una clave SSE-C administrada por el cliente hace que los datos sean irrecuperables.
El cifrado del lado del servidor es valioso. Ayuda a proteger los medios físicos y la infraestructura de almacenamiento, y las políticas de KMS administradas por el cliente pueden crear controles organizativos sólidos. Pero si el servicio de destino puede descifrar los datos cada vez que llega una solicitud de almacenamiento autorizada, el destino sigue estando dentro del límite de confidencialidad. Esto es distinto de cargar un repositorio de Borg, restic o Kopia que ya estaba cifrado antes de llegar al proveedor.
Usa el cifrado externo como defensa en profundidad
La respuesta práctica suele ser «ambos». Deja que la aplicación de copias de seguridad cifre el contenido del repositorio antes de cargarlo y, después, mantén activado el cifrado normal en reposo del destino como otro control. Las dos capas protegen frente a eventos distintos.
| Fallo o amenaza | Cifrado del repositorio | Cifrado del lado del servidor del destino |
|---|---|---|
| Exposición del disco o medio en la nube | Protege el contenido | Protege el contenido |
| El proveedor de almacenamiento puede leer los objetos autorizados | Puede mantener al proveedor fuera del límite de confianza del texto plano | Normalmente, no por sí sola |
| Credencial del bucket robada | Es posible que los datos sigan siendo ilegibles sin la clave del repositorio | Las lecturas autorizadas aún pueden activar el descifrado |
| Pérdida de la frase de contraseña o clave de la copia de seguridad | Puede hacer que el repositorio sea irrecuperable | No recupera la clave del repositorio |
| Pérdida de la clave de almacenamiento gestionada por el proveedor | La capa del repositorio no puede solucionar la indisponibilidad de los datos de destino | Se aplica la política de recuperación del proveedor/KMS |
La clave debe sobrevivir a la máquina que protege
La regla más importante sobre la ubicación de las claves es sencilla: no guardes la única copia de recuperación del secreto de cifrado en el servidor del que estás haciendo copias de seguridad. La guía actual de inicialización del repositorio de Borg recomienda explícitamente conservar una copia de seguridad de la clave de Borg fuera tanto del repositorio como del sistema que crea las copias de seguridad.
La misma lógica se aplica a las contraseñas de restic, las contraseñas de repositorio de Kopia, las claves de age, el material de recuperación de LUKS, la administración de KMS en la nube y las claves maestras de las aplicaciones. Un repositorio cifrado perfectamente es inútil si el único secreto de descifrado desaparece junto con la unidad de arranque averiada.
Para un hogar o un laboratorio pequeño, conserva al menos una copia de recuperación sin conexión o en un sistema de credenciales independiente que no dependa de que el NAS esté operativo. Después, prueba una restauración desde una máquina limpia. Una contraseña escrita que nunca se haya usado para abrir el repositorio demuestra que existe documentación, no que la recuperación sea posible.
¿Qué capa debería gestionar la clave en los diseños habituales de servidores domésticos?
NAS doméstico realizando copias de seguridad en almacenamiento de objetos
Usa el cifrado nativo del repositorio en restic, Borg, Kopia o una herramienta de copia de seguridad comparable antes de que los datos salgan del NAS. Mantén la clave o frase de contraseña del repositorio fuera del NAS. Deja activado el cifrado del bucket como defensa en profundidad. Así, el destino en la nube no será el único control de confidencialidad.
NAS doméstico realizando copias de seguridad en el servidor remoto de un amigo
Prefiere un cifrado del cliente o del repositorio cuya clave de texto plano no se encuentre en el servidor de tu amigo. El host remoto puede almacenar objetos opacos del repositorio y aplicar permisos de escritura limitados. Esto es especialmente valioso porque el control físico y administrativo de la máquina remota pertenece a otro dominio de fallo.
Disco local de copias de seguridad almacenado en la misma casa
El cifrado del repositorio sigue protegiendo la confidencialidad si el disco se pierde o es robado. El cifrado de disco completo en el disco de copia de seguridad puede ser una segunda capa útil, pero no permitas que la clave de desbloqueo del disco se convierta en la única vía de acceso al repositorio de copias de seguridad.
Copias de seguridad en la nube administradas con funciones de recuperación del proveedor
El cifrado administrado por el proveedor puede ser razonable cuando la simplicidad y la recuperación asistida por el proveedor son más importantes que mantener al proveedor fuera del límite de confianza del texto plano. Ten en cuenta que esta es una decisión de seguridad distinta del cifrado del cliente con un modelo de conocimiento cero.
No guardes todos los secretos de las copias de seguridad en un único archivo de automatización
Un trabajo de copia de seguridad desatendido necesita credenciales, pero la comodidad puede desdibujar tus límites de seguridad. La guía de automatización de restic advierte que la forma de proporcionar las contraseñas puede exponer las credenciales y recomienda proteger cuidadosamente los archivos de contraseñas.
En un servidor doméstico, separa al menos estos roles cuando sea práctico:
- Una credencial con permisos limitados que pueda acceder al destino de la copia de seguridad.
- La contraseña o clave de descifrado del repositorio.
- Una copia de recuperación sin conexión de esa contraseña o clave.
- Credenciales administrativas que pueden eliminar políticas de retención, buckets o cuentas remotas.
Esta separación es más importante que decidir si un secreto específico se almacena en un archivo, una variable de entorno, un gestor de contraseñas, un token de hardware o un KMS. La arquitectura debe impedir que una única credencial de automatización robada pueda leer simultáneamente los datos en texto plano, eliminar el repositorio y destruir la única clave de recuperación.
El cifrado no sustituye a la inmutabilidad ni a las pruebas de restauración
La confidencialidad, la integridad, la resistencia al borrado y la capacidad de recuperación son objetivos distintos. Un repositorio cifrado aún puede borrarse. Un bucket inmutable aún puede contener copias de seguridad cuya clave de descifrado se haya perdido. Un trabajo de copia de seguridad completado correctamente aún puede fallar durante la restauración.
La comparación de ZimaSpace entre un servidor de copia de seguridad remoto y el almacenamiento de objetos en la nube para copias de seguridad de máquinas virtuales llega a la misma conclusión operativa: la etiqueta del destino importa menos que haber probado una recuperación real.
Matriz de decisiones
| Prioridad | Propiedad de clave preferida |
|---|---|
| Mantener al administrador de la nube o remoto alejado del texto sin formato | Cliente o repositorio de copias de seguridad cifrado |
| Conservar la deduplicación y las restauraciones adaptadas a copias de seguridad | Cifrado nativo del repositorio |
| Menor complejidad operativa | Cifrado del destino gestionado por el proveedor, aceptando una confianza más amplia |
| Defensa en profundidad sólida | Cifrado del repositorio + cifrado del servidor de destino |
| Proteger por separado un subconjunto muy pequeño y extremadamente sensible | Cifrado previo en el cliente + copia de seguridad normal en el repositorio |
| Recuperación ante desastres tras la pérdida del origen | Cualquier modelo con una copia de recuperación independiente y probada de la clave |
Veredicto final
En la mayoría de los sistemas de copia de seguridad autoalojados, deja que el cliente de copia de seguridad o el formato del repositorio controle el límite de cifrado del contenido, y deja que el destino externo vuelva a cifrar los datos en reposo. Esto conserva funciones de copia de seguridad como la deduplicación y la verificación, al tiempo que reduce cuánto debes confiar en que el sistema de almacenamiento remoto maneje datos en texto sin formato.
El plan de gestión de claves solo está completo cuando el secreto de descifrado sobrevive a la pérdida del servidor de origen, el destino de almacenamiento y la estación de trabajo habitual del administrador. Prueba esa suposición desde una máquina limpia antes de considerar recuperable la copia de seguridad.
Preguntas frecuentes
¿Es suficiente el cifrado del servidor en la nube para las copias de seguridad domésticas?
Protege los datos en reposo, pero normalmente mantiene el servicio de almacenamiento dentro del límite de confianza de descifrado. Usa también el cifrado nativo de la copia de seguridad cuando no quieras que el proveedor o una credencial de almacenamiento robada sean suficientes para acceder al texto sin formato.
¿Debe almacenarse la clave del repositorio dentro del repositorio?
Algunos formatos de copia de seguridad almacenan un objeto de clave cifrado en el repositorio, pero la recuperación aún depende de otro secreto, como una frase de contraseña segura. Conserva el material de recuperación independiente fuera del repositorio y del sistema de origen.
¿Cifrar los archivos antes de hacer la copia de seguridad mejora la seguridad?
Puede crear un límite de confianza adicional para subconjuntos sensibles, pero cifrarlo todo antes de que la herramienta de copia de seguridad lo vea puede reducir la deduplicación, la compresión, la visibilidad de los metadatos y la comodidad de restauración.
¿Cuál es la prueba más importante de gestión de claves?
Restaurar desde una máquina limpia después de asumir que el NAS original no está disponible en absoluto. Si no puedes localizar todas las credenciales ni descifrar datos representativos, el plan de claves está incompleto.
Productos recomendados
Comparaciones de productos
Más para leer
¿Puede Home Assistant reemplazar a openHAB para controlar todos los dispositivos del hogar?
Home Assistant puede reemplazar a openHAB solo cuando cada dispositivo y automatización esenciales superen una prueba paralela de migración y reversión.
Mini PC vs. servidor de placa única vs. NAS para Home Assistant
Elige una SBC para un dispositivo pequeño y eficiente, un mini PC para disponer de más margen de capacidad y una NAS solo cuando...
Cómo elegir entre un servidor dedicado para Home Assistant y un host compartido de aplicaciones
Elige un alojamiento dedicado para aislar las fallas de forma más sencilla; elige un alojamiento compartido cuando el aislamiento, las ventanas de mantenimiento y...
