DOCKER - MINIO ANTIRANSOMWARE

 

🔒 COPIAS DE SEGURIDAD INMUTABLES con MINIO y KOPIA | ALMACENAMIENTO S3 PROPIO y PROTECCIÓN ANTI-RANSOMWARE

Una copia de seguridad solo vale lo que vale su capacidad de sobrevivir al incidente que pretende cubrir. El ransomware moderno lo sabe perfectamente: antes de cifrar los datos busca los respaldos, y si el agente de copia tiene permiso para borrar en el destino, ese permiso es exactamente el que se utiliza para destruirlos. De poco sirve una copia diaria impecable si el atacante puede eliminarla con las mismas credenciales que la crearon.

En esta práctica partimos de ese problema y lo resolvemos con la única defensa que no depende de la buena fe del cliente: la inmutabilidad. Levantaremos nuestro propio almacenamiento de objetos compatible con S3 mediante MinIO y Docker Compose, lo serviremos por HTTPS a través de un proxy inverso con certificado propio, y crearemos un depósito con Object Lock en modo Compliance, donde un objeto escrito no puede ser modificado ni borrado hasta que expire su plazo de retención, ni siquiera por la cuenta administradora del propio servidor. Contra ese almacenamiento respaldaremos dos equipos reales con Kopia —un Ubuntu Server y un Windows 11—, programaremos las copias en ambos, simularemos un ataque de ransomware completo y restauraremos los datos para demostrar que la protección funciona de extremo a extremo.

🧰 Tecnologías empleadas

• MinIO como servidor de almacenamiento de objetos compatible con la API de Amazon S3, autoalojado en contenedores.
• Docker y Docker Compose para el despliegue del stack, con credenciales separadas en un archivo de variables de entorno.
• Nginx como proxy inverso, sirviendo tanto la API de S3 como la consola web por HTTPS.
• OpenSSL para la generación del certificado autofirmado, válido para las dos interfaces de red del servidor.
• MinIO Client (mc) para toda la administración: creación del depósito con bloqueo, retención, usuarios y políticas.
• Kopia como motor de copia en los endpoints, con cifrado en el cliente, deduplicación y soporte nativo de Object Lock.
• systemd en Linux y el Programador de tareas en Windows para la automatización de las copias diarias.

🎯 Objetivos de la práctica

• Desplegar un almacenamiento de objetos propio, compatible con S3, sin depender de ningún proveedor externo.
• Comprender la diferencia entre versionado e inmutabilidad, y por qué el primero por sí solo no protege frente a un borrado deliberado.
• Distinguir los modos de retención Governance y Compliance, y entender las implicaciones de elegir el segundo.
• Configurar credenciales dedicadas para los agentes de copia con el mínimo privilegio necesario.
• Desplegar el agente de copia en dos sistemas operativos distintos contra un mismo repositorio compartido.
• Automatizar las copias diarias en Linux y en Windows con las herramientas nativas de cada sistema.
• Verificar la protección mediante un simulacro de ransomware completo, incluyendo el escenario de credenciales de administrador comprometidas.
• Restaurar los datos y comprobar que la recuperación es real, que es lo único que convierte un respaldo en una copia de seguridad.

🧩 Desarrollo de la práctica

Comenzaremos levantando el stack en el servidor: un contenedor de MinIO con su volumen persistente y un Nginx por delante que publica la API de S3 y la consola web en puertos separados. Generaremos un certificado autofirmado con clave de curva elíptica válido para las dos direcciones del servidor, ya que los agentes llegarán por la red interna mientras la administración se realiza desde la red de gestión, y veremos por qué esa decisión debe tomarse antes de desplegar ningún agente.

En la configuración del proxy prestaremos especial atención a dos detalles que condicionan todo lo demás: la cabecera Host debe llegar intacta al servidor, porque forma parte de la firma criptográfica de cada petición S3, y el límite de tamaño de subida debe eliminarse, porque los bloques que envía el agente superan holgadamente el valor por defecto. Ambos fallos producen errores que apuntan en direcciones equivocadas.

Con el servidor en marcha, crearemos el depósito con bloqueo de objetos y le fijaremos una retención por defecto en modo Compliance. Veremos que este paso solo puede hacerse desde la línea de comandos, y por qué crear el depósito desde la interfaz web deja un almacenamiento inservible para este propósito. Crearemos después un usuario dedicado para los agentes, con una política restringida al depósito de copias y sin capacidad para saltarse retenciones ni destruir el contenedor.

A continuación desplegaremos Kopia en el Ubuntu Server, añadiendo el certificado del servidor al almacén de confianza del sistema y creando el repositorio con la retención asociada, de modo que cada bloque nazca ya protegido. Validaremos la compatibilidad del almacenamiento con una comprobación que escribe datos reales y verifica escrituras condicionales, listados, lecturas parciales y acceso concurrente. Repetiremos el despliegue en el Windows 11, trayendo el certificado por SCP y conectando el equipo al mismo repositorio ya existente, y programaremos las copias diarias en ambos sistemas.

La parte central de la práctica es el simulacro. Cifraremos y destruiremos los ficheros originales en el endpoint, y desde ese mismo equipo comprometido intentaremos borrar las copias con las credenciales del agente. Descubriremos que el primer borrado parece funcionar y deja el depósito aparentemente vacío, y comprobaremos que en realidad no ha destruido nada. Iremos después a por las versiones, que es donde el bloqueo dice que no, y terminaremos con el peor escenario posible: un atacante que ha conseguido las credenciales de administrador del almacenamiento. Analizaremos con detalle qué puede y qué no puede hacer en ese caso, incluida una distinción sutil entre la retención del depósito y la de cada objeto que casi todas las guías pasan por alto.

Cerraremos restaurando los datos, verificando que el contenido recuperado es idéntico al original, y revisando el mecanismo que mantiene viva la protección con el paso del tiempo: la renovación periódica de los bloqueos, que es el punto donde más instalaciones fallan en silencio.

🔍 ¿Por qué es importante esta práctica?

Porque el respaldo es el último recurso cuando todo lo demás ha fallado, y precisamente por eso es el primer objetivo de un atacante que sabe lo que hace. Las estrategias de copia tradicionales asumen un fallo accidental —un disco que muere, un borrado por error, un incendio— y frente a eso funcionan bien. Frente a un adversario deliberado que ya está dentro de la red y tiene las credenciales del agente, no funcionan en absoluto.

La inmutabilidad cambia el modelo de confianza. Deja de importar si el cliente está comprometido, porque la regla la impone el almacenamiento y no la aplicación que escribe. Es la diferencia entre pedirle al sistema que no borre y hacer que no pueda hacerlo.

Esta práctica también aporta claridad sobre conceptos que se confunden a menudo: versionado no es inmutabilidad, un marcador de borrado no es un borrado, la retención por defecto de un depósito no es la retención de sus objetos, y un plazo de bloqueo no es una política de conservación. Entender esas distinciones es la diferencia entre creer que se tiene una copia protegida y tenerla de verdad.

Y hay un componente normativo creciente. La regla clásica del 3-2-1 ha evolucionado hacia el 3-2-1-1-0: tres copias, en dos soportes, una fuera del emplazamiento, una inmutable y cero errores en las pruebas de restauración. Esa segunda "uno" es exactamente lo que se construye aquí, y en varios sectores ha pasado de recomendación a requisito.

✅ Resultados esperados

Al finalizar dispondremos de un almacenamiento de objetos propio, servido por HTTPS, con un depósito cuyos contenidos no pueden ser borrados ni alterados durante su periodo de retención por ningún usuario del sistema. Dos equipos con sistemas operativos distintos estarán respaldándose contra él de forma automática y desatendida, con sus datos cifrados antes de salir del origen, de modo que el servidor de almacenamiento nunca ve el contenido en claro.

Habremos demostrado, con un ataque real y no con una explicación teórica, que las copias resisten tanto al compromiso del endpoint como al de las credenciales administrativas del almacenamiento. Y habremos completado el ciclo restaurando los datos y verificando su integridad, incluida una restauración cruzada desde un equipo distinto al de origen, que es lo que ocurre cuando la máquina original ya no existe.

🏢 Propuesta empresarial

📌 Escenario propuesto

Una organización con varias sedes ha sufrido un intento de cifrado masivo que, aunque contenido a tiempo, ha dejado en evidencia su estrategia de respaldo: las copias se almacenaban en un recurso de red accesible desde los propios equipos respaldados, con credenciales guardadas en cada endpoint. La auditoría posterior concluye que, de haber progresado el incidente unas horas más, los respaldos habrían sido eliminados con esas mismas credenciales y la recuperación habría sido imposible.

La dirección solicita rediseñar el sistema de copias partiendo de una premisa distinta: asumir que los equipos serán comprometidos y que las credenciales que contienen caerán en manos del atacante, y diseñar el respaldo para que aun así sobreviva.

🎯 Requisitos técnicos solicitados por la empresa

• El almacenamiento de copias debe ser propio, sin dependencia de servicios en la nube de terceros, por requisitos de soberanía del dato.
• Las copias deben ser inmutables durante un plazo definido, sin excepciones para ninguna cuenta, incluida la administrativa.
• Los datos deben viajar y almacenarse cifrados, de forma que ni el administrador del almacenamiento pueda leer su contenido.
• Los agentes deben operar con credenciales propias y de mínimo privilegio, distintas de las administrativas y limitadas al depósito de copias.
• La solución debe cubrir estaciones Windows y servidores Linux con un único repositorio común.
• Las copias deben ejecutarse de forma automática y desatendida, con registro verificable de cada ejecución.
• Debe existir un procedimiento de restauración probado, no solo documentado.

🔐 Justificación técnica y de seguridad

El diseño desplaza el punto de control desde el cliente hacia el almacenamiento. Al fijar la retención en modo Compliance, la imposibilidad de borrar deja de ser una cuestión de permisos —que se pueden robar o escalar— y pasa a ser una propiedad del sistema, que ninguna credencial puede eludir. El agente conserva el permiso de escritura que necesita para trabajar, pero ese permiso ya no es un vector de destrucción.

El cifrado en el cliente resuelve simultáneamente dos riesgos: protege la confidencialidad frente a un compromiso del servidor de almacenamiento, y permite ubicar ese servidor en una red distinta o incluso delegar su operación sin exponer el contenido de las copias.

La separación de credenciales limita el alcance de un compromiso: la cuenta del agente solo alcanza el depósito de copias y no puede destruirlo ni saltarse retenciones, mientras que la cuenta administrativa queda reservada a la gestión del servicio y fuera de los equipos respaldados.

Conviene señalar con honestidad el límite del diseño: esta protección cubre el acceso a través de la API de almacenamiento, que es el vector real del ransomware y del robo de credenciales, pero no sustituye al endurecimiento del sistema anfitrión donde reside el almacenamiento. Por ese motivo, en un despliegue real ese servidor debe vivir en una máquina independiente, con acceso administrativo restringido y, preferiblemente, replicado hacia una segunda ubicación.

🧪 Validación esperada

La validación no consiste en comprobar que las copias se crean, sino en comprobar que no se pueden destruir. Se verificará que un intento de borrado con las credenciales del agente no elimina ningún dato, que un intento dirigido contra las versiones almacenadas es rechazado por el sistema, y que el mismo intento realizado con la cuenta administradora obtiene idéntico resultado. Se comprobará igualmente que la modificación del plazo de retención del depósito no afecta a los objetos ya almacenados.

Se validará finalmente la restauración completa de un conjunto de datos previamente cifrados por el simulacro de ataque, verificando la integridad del contenido recuperado, y se revisará el registro de mantenimiento para confirmar que la renovación automática de los bloqueos está operando.

✅ Resultado empresarial esperado

La organización dispone de un sistema de respaldo que sigue siendo válido bajo la hipótesis de compromiso total de sus endpoints. El coste de recuperación ante un incidente de ransomware pasa de ser una negociación con el atacante a ser un procedimiento técnico con tiempos conocidos y probados.

Además, la solución cubre la componente de inmutabilidad exigida por los marcos de cumplimiento que se están volviendo obligatorios en sectores regulados, y lo hace sobre infraestructura propia, con costes predecibles y sin dependencia de licenciamiento por volumen ni de la disponibilidad de un proveedor externo.

🎬 Actividad práctica

En esta práctica configuraremos MinIO en Docker para desplegar un almacenamiento de objetos propio compatible con S3, y lo utilizaremos como destino de copias de seguridad inmutables a prueba de ransomware con Kopia. Para ello, generaremos un certificado autofirmado válido para las dos interfaces del servidor y configuraremos Nginx como proxy inverso para publicar por HTTPS tanto la API de almacenamiento como la consola de administración. Crearemos después un depósito con Object Lock en modo Compliance, de forma que ningún objeto pueda ser borrado ni alterado durante su periodo de retención, ni siquiera por la cuenta administradora del servidor, y daremos de alta unas credenciales dedicadas para los agentes con acceso limitado exclusivamente a ese depósito. También instalaremos el agente de copia en un servidor Ubuntu y en un equipo Windows 11, conectando ambos a un mismo repositorio cifrado en origen y programando copias diarias automáticas con systemd y con el Programador de tareas. Posteriormente simularemos un ataque de ransomware completo, cifrando los ficheros del equipo e intentando destruir las copias primero con las credenciales del agente y después con las del administrador, y veremos por qué el primer borrado parece funcionar sin haber destruido nada. Finalmente restauraremos los datos comprobando su integridad y revisaremos el mecanismo que mantiene viva la protección con el paso del tiempo, que es el punto donde más instalaciones fallan sin que nadie se dé cuenta.

🔗 Enlaces de interés

DOCUMENTACIÓN

⚙️ Estructura de red