Veeam Backup & Replication ofrece dos formas consolidadas de hacer inmutables los datos de backup: un repositorio Linux reforzado (hardened repository), en el que el sistema operativo protege los archivos de backup, y un repositorio de almacenamiento de objetos compatible con S3 con object lock, en el que la plataforma de almacenamiento rechaza la eliminación hasta que expira un periodo de retención. Ambos impiden que un operador de ransomware o un administrador malintencionado borren los puntos de restauración. Difieren en quién aplica la protección, en cuánta infraestructura opera el equipo de backup y en cómo se comporta cada uno a medida que crecen los volúmenes y las ventanas de retención.
La elección importa más que antes. Los atacantes apuntan pronto a la infraestructura de backup, y la inmutabilidad ha pasado de ser un paso de refuerzo opcional a una expectativa básica en las revisiones de seguridad y en los cuestionarios de ciberseguros. Este artículo compara los dos modelos en cuanto a dónde se aplica la inmutabilidad, carga operativa, ruta de escalado, opciones multisitio, comportamiento en la restauración, coste y qué puede seguir haciendo un servidor de backup comprometido, y después analiza la ejecución conjunta de ambos.
En términos de Veeam, inmutabilidad significa que un punto de restauración no puede modificarse ni eliminarse durante un periodo definido, ni siquiera por una cuenta con todos los derechos en la consola de Veeam. Confiar únicamente en el control de acceso es la respuesta ingenua: falla en cuanto un atacante obtiene esas credenciales, que es exactamente lo que persiguen las campañas de ransomware.
La inmutabilidad, por tanto, debe aplicarse en un lugar que el servidor de backup no pueda anular. El repositorio Linux reforzado sitúa ese punto de aplicación en el sistema de archivos de un host Linux que controla el equipo de backup. Un repositorio con S3 Object Lock lo sitúa en la plataforma de almacenamiento, que aplica una regla de retención a cada objeto y rechaza las solicitudes de eliminación o sobrescritura hasta que la regla expira.
Un repositorio reforzado es un servidor Linux con almacenamiento de bloques conectado directamente y formateado con XFS. Veeam escribe en él los archivos de backup y establece el atributo de inmutabilidad del sistema de archivos en cada archivo durante el periodo de retención configurado. Mientras el atributo está activo, el archivo no puede eliminarse, renombrarse ni modificarse, ni siquiera por root, hasta que un proceso programado en el repositorio lo retira.
Dos decisiones de diseño lo hacen creíble. El repositorio se registra en Veeam con credenciales de un solo uso, de modo que el servidor de backup no conserva ningún inicio de sesión privilegiado persistente en el host. Y el host está concebido para estar aislado: sin inicio de sesión remoto por contraseña, sin pertenencia a un dominio de directorio, con SSH restringido y tratado como un appliance en lugar de como un servidor de uso general.
El equipo de backup se convierte en propietario de un pequeño parque Linux sensible desde el punto de vista de la seguridad. Alguien tiene que reforzar la imagen del sistema operativo, aplicar actualizaciones del kernel y de paquetes, vigilar las desviaciones de configuración, sustituir discos y controlar el acceso físico. Nada de esto es difícil, pero todo es recurrente, y la garantía de inmutabilidad depende de que se haga de forma consistente.
El escalado es vertical (scale-up): añadir discos o sustituir el host por uno mayor. Varios repositorios reforzados pueden agruparse como extensiones de rendimiento en un repositorio de backup scale-out, pero cada uno sigue siendo un host independiente con su propio parcheado, su propio dominio de fallo y su propio techo de capacidad.
Con almacenamiento de objetos, Veeam escribe los datos de backup como objetos en un bucket con versionado y object lock habilitados y establece una fecha de retención (retain-until) en cada objeto. La plataforma aplica esa fecha: las solicitudes de eliminación o sobrescritura anteriores a su vencimiento se rechazan con independencia de las credenciales presentadas. Veeam amplía las fechas de retención de los objetos que aún necesitan los puntos de restauración activos, de modo que los administradores nunca tocan objetos individuales.
El almacenamiento de objetos sirve a Veeam en dos funciones. Como nivel de capacidad en un repositorio de backup scale-out, recibe copias o puntos de restauración descargados desde un nivel de rendimiento, normalmente para retención más larga o protección fuera de las instalaciones. Como nivel de rendimiento directo a objeto, recibe los backups primarios directamente desde los trabajos. El mecanismo de inmutabilidad es idéntico en ambas funciones.
El equipo de backup ya no parchea un host Linux para preservar la inmutabilidad. El esfuerzo de refuerzo se desplaza al modelo de acceso de la plataforma de almacenamiento: un usuario dedicado para Veeam, políticas de bucket de mínimo privilegio, MFA para el acceso administrativo y separación entre la administración de backup y la de almacenamiento. Un almacén de objetos on-premises sigue teniendo hosts que actualizar, pero ese trabajo pertenece a la capa de almacenamiento y no debilita el bloqueo si se retrasa.
El escalado es horizontal. El almacenamiento de objetos crece añadiendo nodos o unidades a un único espacio de nombres, de modo que un bucket puede pasar de decenas de terabytes a petabytes sin rediseñar repositorios ni migrar datos entre hosts.
En el modelo de repositorio reforzado, un servidor Veeam comprometido puede eliminar trabajos de backup, cambiar políticas de retención y detener futuros backups. No puede eliminar ni modificar los archivos que llevan el atributo de inmutabilidad. Pero si el atacante también obtiene root en el host Linux, mediante una vulnerabilidad independiente, una configuración SSH débil o acceso físico, el atributo puede retirarse y los datos destruirse. El repositorio reforzado es tan sólido como el refuerzo de Linux que lo rodea.
En el modelo de object lock, un servidor Veeam comprometido puede interrumpir los backups futuros de la misma manera, pero no puede acortar la retención de los objetos ya bloqueados. Con un bloqueo de tipo compliance, ni siquiera el administrador del almacenamiento puede retirar un bloqueo antes de que expire. El atacante tendría que comprometer la propia plataforma de almacenamiento: un sistema separado con credenciales separadas y, idealmente, un equipo separado. Esa separación de funciones es el argumento de seguridad central de object lock.
Las restauraciones desde un repositorio reforzado se comportan como las de cualquier repositorio basado en bloques: acceso aleatorio rápido y compatibilidad con la recuperación instantánea. Las restauraciones desde almacenamiento de objetos dependen de la plataforma. Un almacén de objetos on-premises bien dimensionado ofrece un alto rendimiento sobre una red local y admite directamente la recuperación instantánea y las restauraciones a nivel de archivo. El almacenamiento de objetos en una nube de hiperescala puede añadir cargos de egreso y límites de ancho de banda a las restauraciones grandes, algo que conviene modelar antes de comprometer allí una retención larga.
Un repositorio reforzado es una máquina en una ubicación; la protección fuera de las instalaciones supone un segundo host reforzado en otro lugar más un trabajo de copia de backup. Las plataformas de almacenamiento de objetos suelen replicar entre sitios o buckets, y algunas extienden un único espacio de nombres entre ubicaciones, de modo que la capa de almacenamiento puede producir la segunda copia inmutable en lugar de requerir trabajos y hosts adicionales de Veeam.
Un repositorio reforzado es económico al principio: un servidor, unidades y una distribución Linux. Su curva de coste se inclina hacia arriba con la escala, porque cada host añade hardware, espacio en rack y tiempo de administración. El almacenamiento de objetos tiene un punto de entrada más alto para un despliegue pequeño, pero se aplana a medida que crece la capacidad, en particular cuando la codificación de borrado (erasure coding) sustituye al mirroring y una sola plataforma absorbe una retención que de otro modo requeriría varios hosts. Supongamos que una organización debe conservar 90 días de puntos de restauración inmutables para 400 TB de datos de origen; una plataforma de almacenamiento frente a una flota de servidores reforzados se convierte en una cuestión de coste operativo tanto como de hardware.
| Dimensión | Repositorio Linux reforzado | Repositorio con S3 Object Lock |
|---|---|---|
| Dónde se aplica la inmutabilidad | Atributo de inmutabilidad de XFS en un host Linux operado por el equipo de backup | Regla de retención aplicada por la plataforma de almacenamiento de objetos |
| Carga operativa | Refuerzo del SO, parcheado y seguridad física por cada host | Políticas de acceso en la capa de almacenamiento; mantenimiento de hosts a cargo del equipo de almacenamiento |
| Ruta de escalado | Escalado vertical por host; más hosts como extensiones de SOBR | Añadir nodos o unidades a un único espacio de nombres |
| Opciones multisitio | Segundo host más trabajos de copia de backup | Replicación de la plataforma o buckets extendidos |
| Comportamiento en la restauración | Restauraciones locales a velocidad de bloque, recuperación instantánea | Rápido en almacenamiento de objetos local; consideraciones de egreso y ancho de banda en la nube pública |
| Perfil de coste | Bajo coste de entrada, aumenta con el número de hosts | Punto de entrada más alto, se aplana a escala |
| Servidor de backup comprometido | No puede eliminar los archivos bloqueados; root en el host sí podría | No puede acortar los bloqueos; requiere comprometer por separado la plataforma de almacenamiento |
| Mejor encaje | Retención local a corto plazo, sitios pequeños, restauraciones operativas rápidas | Retención larga, copias fuera de las instalaciones, entornos grandes o en crecimiento |
Los dos modelos no son mutuamente excluyentes, y el repositorio de backup scale-out está construido para combinarlos. Un patrón habitual utiliza un repositorio reforzado como nivel de rendimiento para los puntos de restauración recientes, donde más importan las restauraciones locales rápidas, y un bucket con object lock como nivel de capacidad para la retención más larga y la copia fuera de las instalaciones. La inmutabilidad se aplica en ambos niveles, de modo que una ventana corta en el host reforzado no deja expuestos los datos más antiguos.
Preguntas que ayudan a decidir el reparto:
Scality ARTESCA es almacenamiento de objetos S3 diseñado para backup, validado con Veeam como repositorio con object lock tanto para uso directo a objeto como para el nivel de capacidad. La inmutabilidad la aplica la plataforma, de modo que un servidor Veeam comprometido no puede acortar ni eliminar la retención de los objetos bloqueados. El modelo de seguridad se describe en la página de seguridad y ciberresiliencia de ARTESCA.
ARTESCA está disponible como software o como appliance hardware y escala desde decenas de terabytes hasta petabytes en un único espacio de nombres, lo que se ajusta a las funciones de retención larga y de copia fuera de las instalaciones en las que una flota de repositorios reforzados resulta difícil de gestionar. La orientación para dimensionar un nivel con object lock está en el artículo sobre dimensionamiento del repositorio de backup, y la lista de aplicaciones de backup validadas está en la página de compatibilidad con soluciones de backup.
Sea cual sea el modelo elegido, el paso práctico es el mismo: decidir quién es responsable del punto de aplicación, documentarlo y probar una restauración desde datos inmutables antes de que un incidente obligue a plantear la pregunta.