MIMIX 11 y el punto ciego de la alta disponibilidad: por qué replicar en tiempo real no te protege de un ransomware
Precisely adelantó que Assure MIMIX 11 sumará continuous data protection para atacar un problema que la industria conocía hace años pero nadie había resuelto: la replicación por journaling remoto no distingue un cambio legítimo de uno cifrado por un atacante, y lo copia igual al servidor de respaldo.
Si administrás una partición IBM i con alta disponibilidad basada en journaling remoto, probablemente diste por sentado durante años que esa réplica en el sitio secundario era tu red de seguridad contra cualquier desastre. Un fallo de disco, un incendio en el centro de datos, un corte prolongado de energía: la réplica siempre estuvo ahí, sincronizada casi en tiempo real, lista para tomar el control. Pero hay un escenario contra el que ese mismo mecanismo no solo no ayuda, sino que activamente empeora las cosas: el ransomware. Precisely, el proveedor detrás de MIMIX, una de las soluciones de HA más usadas en el ecosistema IBM i, anunció que la próxima versión —Assure MIMIX 11, prevista para este año— incorpora por primera vez una capacidad de continuous data protection (CDP) pensada específicamente para cerrar ese punto ciego.
El problema no es nuevo, pero seguía sin resolverse
El software de alta disponibilidad tradicional en IBM i se apoya en el journaling remoto de IBM: cada cambio que se hace en un archivo de base de datos en el sistema origen se replica casi instantáneamente al sistema destino. Es una arquitectura extraordinariamente confiable para lo que fue diseñada —proteger contra fallas de hardware o desastres físicos— pero tiene una debilidad estructural frente al ransomware. Si un atacante logra cifrar archivos críticos en el sistema origen, el software de HA hace exactamente lo que se supone que debe hacer: replica ese cambio, fielmente y sin demora, al sistema destino. El resultado es que el ataque se propaga a la copia de respaldo casi tan rápido como al sistema productivo, dejando a la organización sin una copia limpia a la cual volver.
Esto no es un riesgo teórico. IBM i suele describirse como un sistema resistente al malware diseñado para Windows o Linux, y en gran medida es cierto: el modelo de objetos y la arquitectura del sistema operativo hacen que buena parte del malware genérico no funcione tal cual contra QSYS.LIB. Pero esa reputación generó una falsa sensación de inmunidad total. El Integrated File System (IFS), cuando queda expuesto a la red sin las protecciones adecuadas, se comporta como cualquier recurso compartido de Windows y hereda buena parte de sus vulnerabilidades. Y aunque la base de datos Db2 for i almacena sus archivos en la biblioteca tradicional QSYS.LIB, esos mismos archivos pueden verse comprometidos a través de conexiones ODBC o JDBC mal aseguradas, o de rutas de acceso al IFS que no deberían estar abiertas. En la última década se documentaron varios ataques de ransomware exitosos contra shops IBM i, y en cada uno la pregunta que definía la recuperación era la misma: ¿tenía la organización un backup reciente en un sitio verdaderamente aislado, o su única copia "de respaldo" había sido cifrada minutos después que la original?
Qué cambia con continuous data protection
La diferencia conceptual entre HA tradicional y CDP es la que explica por qué Precisely decidió construir algo nuevo en lugar de parchear lo existente. Heli Vyas, gerente de marketing de producto en Precisely, lo resumió en un blog reciente de la compañía: la CDP le da a los equipos de IBM i la capacidad de recuperarse a un punto en el tiempo aceptable anterior a que ocurriera la corrupción o la actividad maliciosa, no solamente al estado más reciente sincronizado. Esa es la clave: mientras que la réplica de HA solo conoce el "ahora" —el último cambio aplicado—, un mecanismo de CDP mantiene un historial de estados que permite retroceder el reloj a un momento anterior al ataque, sin depender de si ese momento coincide con el último backup completo disponible.
Según Vyas, esta primera fase de la funcionalidad "sienta las bases para opciones de recuperación más granulares" que llegarán después. Precisely todavía no detalló públicamente los mecanismos técnicos exactos —cómo se almacena ese historial, qué overhead agrega, si conserva múltiples puntos de recuperación o solo una ventana limitada—, así que conviene tratar el anuncio como una dirección de producto confirmada y no como una especificación cerrada. Es información que vale la pena volver a revisar cuando MIMIX 11 llegue a disponibilidad general.
MIMIX 11 no se limita a la pieza de ransomware. Precisely también anticipó dos cambios operativos concretos. El primero es una automatización mayor del "housekeeping" de journals: hoy, cada vez que se agregan o modifican archivos de base de datos, alguien tiene que ajustar la configuración de MIMIX para que los journals reflejen ese cambio, una tarea de mantenimiento recurrente que Precisely promete reducir. El segundo es un nuevo "modo migración", pensado para los períodos largos de sincronización inicial que implican mover un shop completo a un nuevo sistema o partición: durante esa ventana, MIMIX deshabilitará operaciones que solo tienen sentido cuando el grupo de datos ya está en estado estable, para evitar interferencias durante la sincronización.
La otra pieza: IA metida donde importa, no como demo
La tercera novedad conecta con algo que venimos señalando en este blog sobre cómo la IA se está integrando en herramientas de infraestructura IBM i: no como un chatbot separado al que hay que ir a consultar, sino incrustada en el flujo de trabajo. Precisely ya venía sumando asistencia generativa basada en su base de conocimiento de MIMIX, pero con la versión 11 promete algo más específico: guía generada por IA que aparece en el momento exacto en que ocurre un error, una excepción o un mensaje relevante, en lugar de quedar enterrada en una base de conocimiento que el administrador tiene que ir a buscar por su cuenta. Vyas lo planteó en términos de gobernanza operativa: llevar esa guía contextual al producto mismo reduce la dependencia del conocimiento tribal y hace la plataforma más accesible para un equipo más amplio, un problema real en shops IBM i pequeños donde la continuidad operativa depende de que una o dos personas tengan el conocimiento crítico en la cabeza.
Qué revisar en tu shop mientras tanto
MIMIX 11 todavía no está disponible de forma general, así que no hay un PTF ni una actualización concreta para aplicar hoy. Pero el anuncio es una buena excusa para hacer tres verificaciones que no dependen de esta versión. Primero, auditá qué tan aislado está realmente tu sitio de HA: si el sistema destino de tu réplica está en la misma red plana que el origen, con las mismas credenciales y el mismo nivel de exposición, tu "sitio secundario" no te protege de un ransomware aunque tengas journaling remoto funcionando perfectamente. Segundo, confirmá que exista al menos una copia de tus datos críticos verdaderamente fuera de la cadena de replicación en tiempo real —una cinta, un snapshot inmutable, algo que un atacante no pueda tocar simplemente porque comprometió el sistema origen. Tercero, si administrás el IFS expuesto a la red para integraciones con aplicaciones externas, revisá los permisos de recorrido de directorios y las conexiones ODBC/JDBC con la misma disciplina con la que auditarías un recurso compartido de Windows: en este punto específico, IBM i se comporta más parecido a esos sistemas de lo que a muchos administradores les gustaría admitir.