Prefiero WannaSwitch a WannaCry

Los programas maliciosos como el ransomware, los virus y las fugas de datos involuntarias estaban antes reservados principalmente a los dispositivos finales. Recientemente, sin embargo, variantes de ransomware como WannaCry y Petya también han causado revuelo en el entorno de los servidores corporativos, porque los controles de acceso físico y lógico, así como la protección puramente estructural y de red, obviamente no son suficientes ni siquiera para las clases altas de los centros de datos.

La vulnerabilidad de WannaCry, Petya y sus colegas se basa obviamente en sistemas operativos sin parches. Ahora bien, hay muchos casos de uso en los que los parches en entornos productivos solo pueden aplicarse, por definición, a intervalos largos.

Ni siquiera hacen falta exploits de día cero muy sofisticados y energía maliciosa de reacción rápida para que el software correspondiente se apodere de estos sistemas.

Basta con explotar sin restricciones brechas razonablemente recientes (cuyos parches sólo están disponibles desde hace unas semanas o meses). Un centro de datos en funcionamiento 7-x-24 que prevea ventanas de mantenimiento regulares quizás dos veces al año y no considere que los parches de seguridad actuales sean lo suficientemente críticos como para interrumpir las operaciones está y sigue estando abierto a este tipo de ataques.

Los nombres de una gran variedad de empresas del sector financiero, de la industria química y de muchos otros sectores económicos, instituciones públicas y semipúblicas, se barajan en la prensa como víctimas sospechosas y confirmadas.

El hecho de que esto también incluya a los operadores de infraestructuras críticas da una idea profunda de la respuesta a los requisitos actuales como IT-SiG & Co. que se ha llevado a cabo hasta ahora. Esto plantea la cuestión de si las medidas de seguridad adoptadas hasta el momento son en absoluto adecuadas para hacer frente a las amenazas que plantea el ransomware. Es necesario resolver dos áreas de tensión:

• Operación informática 7-x-24 frente a parcheado permanente
• Defensa del ataque frente a una contrarreacción relajada

Existe un enfoque relativamente sencillo y, sobre todo, de aplicación más o menos universal: la duplicación independiente de la arquitectura y la infraestructura a nivel de base de datos y aplicación.

Este método, a menudo ridiculizado como anticuado en tiempos de máquinas virtuales, mirroring de almacenamiento y diversas variantes de clúster, también puede mostrar su fuerza en los ataques de ransomware: la independencia lógica de los entornos de sistemas subyacentes.

Los gángsters se van con las manos vacías pese al éxito de su ataque

Un usuario de Libelle no quería ser víctima de un ataque de ransomware. Por eso practicó la emergencia. (La empresa es un conocido fabricante de alimentos y, por desgracia, no debe ser nombrada porque esta industria está permanentemente expuesta a intentos de chantaje y otros ataques).

El éxito de esta empresa se basa en la calidad de sus productos y en la disponibilidad 7x24 de un gran número de bases de datos MS-SQL. Parchear permanentemente estas bases de datos e interrumpir constantemente las operaciones para ello no es factible en el día a día de la empresa.

Por lo tanto, se ha elegido un camino diferente: Los sistemas productivos funcionan "tal cual". Los datos actuales se transfieren permanentemente del entorno productivo a un denominado entorno espejo mediante la duplicación de datos y aplicaciones.

También se parchea regularmente y se actualiza, pero no en los entornos productivos, sino en los sistemas espejo. BusinessShadow funciona con total independencia del entorno productivo, sin servidores compartidos, sin almacenamiento compartido, en definitiva: sin compartir nada.

El mirroring significa que los datos actuales siempre están físicamente presentes en el lado espejo, pero los sistemas pueden ser mantenidos y actualizados con los últimos parches independientemente del funcionamiento productivo.

Si un ataque con ransomware tiene éxito en el entorno productivo y es exitoso debido al bajo nivel de parches, el sistema simplemente cambia al sistema espejo altamente parcheado y continúa trabajando allí en pocos minutos. El resultado: el ataque no fue repelido, sino que quedó en nada.

Precaución también contra la clásica corrupción de datos

La duplicación de datos descrita anteriormente es asíncrona. Esto tiene varias ventajas sobre el mirroring síncrono, que se utiliza a menudo en soluciones de almacenamiento y cluster: Por un lado, existe la posibilidad de utilizar ventanas de mantenimiento relajadas en la réplica en primer lugar, ya que, a diferencia de la réplica síncrona, no se requiere un commit en dos sitios; por otro lado, la empresa también sale de la trampa síncrona.

Si un error lógico ha corrompido el stock de datos productivos, el stock de datos en la réplica también se corrompe automáticamente. Cifrados o borrados ejecutados por ransomware, infestaciones de virus, actividades de aplicaciones defectuosas, importaciones de datos defectuosas, actividades manuales maliciosas de usuarios internos o externos o similares son errores lógicos que, en el mal de los casos, garantizan la paralización de la empresa.

En el caso aún peor, ese trabajo continúa con datos incorrectos, generando así un gasto económico adicional o incluso daños a la imagen pública.

Con la ayuda de esta duplicación asíncrona de datos y aplicaciones, se puede definir cualquier desfase temporal entre los sistemas productivo y espejo. Los datos productivos actuales ya están físicamente disponibles en el sistema espejo, pero se mantienen artificialmente en espera en un embudo temporal y sólo se activan lógicamente cuando expira el desfase temporal definido.

Desde un punto de vista lógico, el sistema espejo va permanentemente por detrás del sistema productivo exactamente en este desfase temporal, pero ya tiene el delta de los datos físicamente disponible en su propio almacenamiento y puede extraerlo ad hoc si lo desea.

Si se produce un error lógico de cualquier tipo en el entorno de producción, la instancia responsable desde el punto de vista organizativo decide sobre la conmutación, por ejemplo, el responsable de SAP, el propietario de la aplicación, el responsable de DR o el responsable de TI, en función de la estructura y los procesos de la empresa.

Desde un punto de vista técnico, se determina el mejor momento posible de la reserva de datos y se activa en el sistema espejo. De este modo, la base de datos o la aplicación en el sistema espejo está disponible de forma productiva en cualquier momento dentro del embudo temporal de forma precisa en cuanto a las transacciones y coherente en cuanto a los datos, los usuarios y otras aplicaciones que acceden se conectan de nuevo y pueden seguir trabajando con datos correctos.

Otra ventaja de este mirroring asíncrono de datos y aplicaciones es la importante reducción de los tiempos de latencia, ya que el sistema productivo no tiene que esperar al commit del sistema espejo.

Esto significa que también son posibles conceptos de RD (recuperación ante desastres) prácticos y económicamente interesantes a larga distancia y con bajos requisitos de volumen y QoS (calidad de servicio) en las líneas de red entre los sistemas.

Retos: lógicos, físicos, infraestructurales

Los sistemas de conmutación por error pueden funcionar no sólo en los centros de datos de la propia empresa, sino también, por ejemplo, como servicio en una "empresa amiga" o proveedor de servicios situado a cualquier distancia, lo que es especialmente frecuente en el sector de las PYME.

De este modo, la distancia entre el emplazamiento productivo y el de avería ya no está limitada por las posibilidades de las tecnologías DarkFibre, campus o metrocluster, que en el caso habitual sólo alcanzan unos pocos kilómetros.

La duplicación asíncrona puede ampliarse a voluntad en función de los requisitos empresariales y dependiendo de la estructura corporativa, incluso en diferentes placas tectónicas. Esto significa que son posibles conceptos de DR que también surten efecto en caso de catástrofes a gran escala y mantienen en funcionamiento las operaciones informáticas nacionales, regionales o incluso mundiales.

Además, la duplicación de datos y aplicaciones independiente de la arquitectura libera del dilema del "punto único de fallo": además de la ya recomendada arquitectura compartida-nada, también se admiten diferentes arquitecturas e infraestructuras de hardware en los entornos implicados.

Además de los intereses tecnológicos, también hay que tener en cuenta los económicos. Con arquitecturas homogéneas, el esfuerzo de mantenimiento es menor, pero el riesgo de controladores, parches de firmware o software de controlador defectuosos no solo afecta a entornos individuales, sino a todos ellos.

Además, las consideraciones comerciales también influyen en los requisitos de los entornos productivos y de emergencia: A menudo basta con que sólo el sistema productivo esté diseñado para un funcionamiento permanente de alto rendimiento.

El sistema de fallo también puede diseñarse más pequeño, sólo tiene que ser "lo suficientemente bueno" para que, con suerte, nunca se produzca, y si es así, que sea sólo de uso temporal.

En la práctica, estas consideraciones suelen dar lugar a que el "viejo" sistema productivo siga funcionando como un nuevo sistema de averías en el marco del ciclo habitual del hardware. Así, muchas empresas optan por la vía intermedia, entre la arquitectura homogénea y la heterogénea, en la que se definen al menos dos estándares de hardware, a menudo también con componentes de distintos fabricantes.