Hardened Repository de Veeam: bare-metal, credenciales de un solo uso y por qué no va virtualizado

Pones un repositorio inmutable. Marcas la casilla, defines catorce días de retención bloqueada, y el reporte sale en verde. Sobre el papel, el ransomware ya no puede borrar tus respaldos.

Y luego resulta que sí puede, porque montaste ese repositorio como máquina virtual en el mismo clúster que estás protegiendo.

La inmutabilidad de un Hardened Repository es real y funciona. Pero funciona dentro de un modelo de amenaza muy concreto, y casi todas las implementaciones que revisamos lo rompen por fuera sin darse cuenta. Este artículo es el detalle que esa casilla no te cuenta.

1. Contra quién se está defendiendo, exactamente

Empecemos por lo que casi nunca se dice en voz alta, porque de ahí sale todo lo demás.

El Hardened Repository no está diseñado para defenderte de un atacante externo. Está diseñado para defenderte de tu propio servidor de respaldos comprometido.

Piénsalo desde el lado del atacante. Un ataque moderno es una operación conducida por personas que se toman su tiempo. ¿Cuál es la máquina más valiosa de tu red para esa operación? No el controlador de dominio: el servidor de backup. Porque tiene credenciales hacia todo lo que respalda, y porque es lo único que se interpone entre la extorsión y el pago.

Un servidor de respaldos tradicional guarda las credenciales del repositorio en su base de datos de configuración. Es lo que le permite escribir ahí cada noche sin que nadie teclee nada. Y es también lo que convierte al repositorio en una extensión del servidor: quien toma uno, toma el otro.

Todo el diseño del Hardened Repository existe para cortar ese hilo.

2. Credenciales de un solo uso: el mecanismo, no el eslogan

Aquí es donde la mayoría de las explicaciones se quedan cortas, así que vale la pena verlo por dentro.

Cuando das de alta el repositorio, capturas credenciales SSH del servidor Linux. Se usan una sola vez: para copiar el servicio de transporte, instalarlo y dejarlo corriendo. Terminado eso, esas credenciales no se guardan en la base de configuración del servidor de respaldos.

De ahí en adelante la comunicación ocurre entre el servidor y ese servicio de transporte ya instalado. Nadie vuelve a autenticarse contra el sistema operativo del repositorio.

La consecuencia práctica es la que importa:

1. Un atacante que tome el servidor de respaldos no encuentra ahí con qué entrar al repositorio. No hay credencial que robar, porque no está.
2. Puede pedirle al servicio de transporte que escriba respaldos nuevos. Lo que no puede es pedirle que borre los que ya están bloqueados: esa operación no existe en el protocolo.

Y el complemento obligatorio, que es donde muchas implementaciones aflojan: después del despliegue, SSH se apaga. Si dejas el acceso remoto abierto "por si acaso", reconstruiste el hilo que acabas de cortar — solo que ahora la credencial vive en la cabeza de alguien o, peor, en un gestor compartido.

El acceso al repositorio pasa a ser presencial, por consola. Es incómodo a propósito.

Con eso queda cerrada la puerta de entrada. Falta la de salida, que es un control distinto y se resuelve en el firewall: una lista blanca con los destinos que el repositorio de verdad necesita y un deny explícito debajo. Un repositorio sin SSH pero con salida libre a internet sigue teniendo por dónde conversar con quien lo tomó.

Cómo se sostiene la inmutabilidad por debajo

El bloqueo no es una propiedad de Veeam: es del sistema de archivos. Los archivos de respaldo reciben el atributo de inmutabilidad de Linux, y mientras esté puesto, ni root puede borrarlos ni modificarlos. Se levanta solo cuando vence el periodo.

Dos detalles que se pasan por alto:

1. El reloj es parte del control. El vencimiento se evalúa contra la hora del sistema. Un servidor cuya hora se puede mover es un servidor cuya inmutabilidad se puede vencer antes de tiempo. La sincronización de tiempo deja de ser higiene y pasa a ser control de seguridad.
2. El sistema de archivos importa. Se usa XFS con reflink habilitado, no por gusto: es lo que permite el clonado por bloques, y con eso los synthetic fulls dejan de copiar datos y pasan a referenciarlos. La diferencia en espacio y en ventana de respaldo es enorme. Y no se puede activar después: se define al formatear.

3. Bare-metal no es purismo

Aquí está la recomendación que más se ignora y la que más caro sale. Bare-metal se refiere a un equipo de cómputo o servidor que ejecuta un sistema operativo directamente sobre el hardware físico, sin usar una capa de hipervisor intermedia. El repositorio endurecido va sobre hardware dedicado, con discos conectados directamente. No sobre una máquina virtual. No sobre un LUN de la SAN. No sobre un recurso compartido de un NAS.

La razón cabe en una frase:

El atributo de inmutabilidad protege los archivos desde dentro del sistema operativo. No protege el volumen desde fuera.

Recorre lo que puede hacer alguien con acceso al hipervisor sin tocar nunca el Linux del repositorio:

1. Borrar la máquina virtual completa. Los archivos siguen inmutables hasta el último instante, y desaparecen con el disco que los contiene.
2. Desconectar o borrar los discos virtuales.
3. Revertir un snapshot y devolver el repositorio a un estado anterior. Y ojo: un snapshot no es un respaldo, pero sí es una máquina del tiempo para deshacer tu protección.
4. Montar los discos desde otra máquina virtual y leerlos o sobrescribirlos, con el sistema de archivos del repositorio apagado y su atributo de inmutabilidad sin nadie que lo aplique.

Ninguna de esas cuatro cosas requiere una sola credencial del repositorio. Solo requieren el hipervisor.

Lo mismo aplica al almacenamiento de red: si el volumen vive en una cabina, quien administre esa cabina puede borrarlo, y el Linux se entera cuando ya no está.

El argumento que no es técnico sino de dominio de falla

Hay una segunda razón, y es más de fondo: si el clúster de virtualización es lo que estás protegiendo, meter la copia de último recurso dentro de ese mismo clúster contradice el propósito del ejercicio. Un evento que se lleve al clúster —ransomware, error de operación, falla del almacenamiento compartido— se lleva también la salida.

Es el mismo criterio de la regla 3-2-1-1-0: la copia inmutable y la copia fuera de sitio existen porque los dominios de falla tienen que ser distintos. Un repositorio virtualizado sobre la infraestructura protegida comparte dominio de falla con lo que respalda, aunque el reporte diga que es inmutable.

¿Significa que un repositorio virtual no sirve para nada? No. Sirve como repositorio, y puede estar perfectamente bien para copias operativas de restauración rápida. Lo que no es, es la copia de último recurso. Y llamarle inmutable sin la letra chica es lo que convierte una decisión de arquitectura en una sorpresa.

4. El appliance virtual: por qué no me convenció

Veeam distribuye una imagen instalable ya endurecida, para no tener que construir el Linux a mano. La idea es buena: quita la parte del trabajo donde más se equivoca uno, que es el hardening del sistema operativo, y garantiza que todas las instalaciones salgan iguales.

La probé y me quedé con sensaciones encontradas. Lo digo como opinión, no como recomendación general:

1. Es una caja cerrada, y eso corta en los dos sentidos. Lo que te protege de configurarlo mal también te impide diagnosticar. El día que algo no cuadra —un disco, una interfaz, un servicio que no levanta— no tienes las herramientas que usarías en cualquier otro Linux tuyo.
2. No entra en tu estándar de plataforma. Si tienes una distribución de casa, un esquema de parcheo, un agente de monitoreo y una convención de nombres, el appliance no se acomoda a nada de eso. Queda como un huérfano operativo: el único servidor que se administra distinto.
3. Se distribuye como imagen desplegable, y ahí está la trampa. Que se pueda desplegar como máquina virtual no significa que deba. Es la facilidad la que empuja a la decisión equivocada de la §3 — y en pantalla se ve exactamente igual de verde que la correcta.

Contra eso, lo que sí le reconozco: si no hay quien construya y sostenga un Linux endurecido con criterio, el appliance es mucho mejor que un Ubuntu improvisado con SSH abierto. La pregunta no es si el appliance es bueno en abstracto, sino contra qué alternativa real lo estás comparando.

Mi criterio, resumido: appliance sobre hardware dedicado es una buena combinación. Appliance sobre máquina virtual es cambiar un problema de operación por uno de arquitectura, y el segundo es peor.

5. Lo que hay que decidir antes de formatear

Cosas que después del despliegue son caras o imposibles:

1. XFS con reflink. Se define al formatear. Si el volumen ya está formateado sin él, se rehace.
2. Discos directos, DAS. No SAN ni NAS. Cambiar esto después es migrar todo el repositorio. Y en esta parte también tengo una preferencia, y viene de la práctica: discos mecánicos, nada de SSD.
3. El razonamiento empieza por el equipo. Es raro que se dedique un servidor de gama media o alta a un hardened repo; esto es terreno de máquinas bastante más sencillas. Y esas máquinas muchas veces no ofrecen SSD de grado enterprise entre sus opciones de configuración — ni mixed use, ni read intensive, ni nada parecido.
4. Ahí aparece el problema. Muchos integradores, anteponiendo el performance, terminan metiendo SSD de grado consumer. Y un repositorio de respaldo es escritura intensiva y constante, que es exactamente el uso para el que ese disco no está hecho: fallan en poco tiempo.
5. Mi recomendación en esos casos son discos SATA de gama enterprise — HGST Ultrastar o WD Gold. El performance se cae, sí. La confiabilidad se dispara. He visto discos de esos operar sin una sola falla durante ocho años o más.
6. El periodo de inmutabilidad. Tiene que sobrevivir al tiempo que tarda un ataque en detectarse, que rara vez es un día. Si el bloqueo dura menos que el dwell time del atacante, no protege nada.
7. Sincronización de tiempo confiable, tratada como control y no como detalle.
8. Cómo se accede el día del incidente. Sin SSH, el acceso es por consola: hay que saber quién tiene llave del sitio y del rack, y que eso esté escrito antes de necesitarlo.

6. Lo que la inmutabilidad no resuelve

Conviene decirlo porque el reporte en verde invita a creer lo contrario.

Un repositorio inmutable garantiza que los puntos de restauración existan. No garantiza que sirvan. El respaldo que nunca se probó sigue sin ser un respaldo, aunque nadie pueda borrarlo — y restaurar es un procedimiento que se ensaya en laboratorio, no en el incidente.

Tampoco cubre la salida a internet del repositorio: el canal por donde un atacante conversa con lo que ya tomó es un control aparte, y complementario.

Y no te salva de depender de un solo sistema: a Veeam también hay que respaldarlo. Si pierdes la base de configuración, tienes los datos y no tienes el índice para encontrarlos.

Entonces, ¿cómo se ve uno bien hecho?

Un servidor físico, con sus discos conectados directamente, formateado en XFS con reflink. Desplegado con credenciales que se usaron una vez y no quedaron guardadas en ningún lado. Con SSH apagado y acceso por consola. Con la hora sincronizada y protegida. Con la salida a internet acotada a los destinos que necesita y todo lo demás negado. Con un periodo de bloqueo más largo que el tiempo que tardarías en darte cuenta de que te entraron. Y con una copia más, fuera de sitio, en otro dominio de falla.

Nada de eso es exótico ni caro. Casi todo se decide en la hora en que se formatea el volumen, y esa hora nunca vuelve.

Si ya tienes uno montado y acabas de leer que está en una máquina virtual: no lo tires. Úsalo como lo que sí es —una copia operativa rápida— y planea la de último recurso aparte. Lo que no conviene es seguir contándolo en el comité como si fuera lo que no es.