Los parches realmente importan: parchear es lo que evita que las soluciones tecnológicas se conviertan en grandes bloques de queso suizo con infinitas vulnerabilidades de seguridad que perforan agujeros tras agujeros en soluciones críticas.

Pero cualquiera que haya pasado algún tiempo manteniendo los sistemas sabe que la aplicación de parches suele ser más fácil de decir que de hacer.

Sí, en algunos casos basta con ejecutar la línea de comandos para instalar el parche y listo. Sin embargo, estos casos son cada vez más raros: debido a la complejidad del entorno tecnológico, es más probable que enfrente el complejo proceso de lograr las mejores prácticas de aplicación de parches.

En este artículo, describimos por qué la aplicación de parches a la base de datos es importante (¡sí, las bases de datos son vulnerables!), explicamos el problema con la aplicación de parches a la base de datos y señalamos una nueva solución que alivia la aplicación de parches a la base de datos.

Precaución: los servicios de su base de datos también son vulnerables

Sabemos que los servicios de base de datos son fundamentales: las bases de datos respaldan las operaciones de TI de innumerables formas y se ejecutan en segundo plano. Sin embargo, las bases de datos simplemente no son la parte más interesante de la pila de tecnología, que es una de las razones por las que se puede descuidar la aplicación de parches a las bases de datos. En una encuesta reciente de Imperva, la empresa descubrió que casi el 50 % de las bases de datos locales eran vulnerables a abusos conocidos.

Sin embargo, los ciberdelincuentes no ignoran las bases de datos. Como cualquier otro elemento de la pila de tecnología, las bases de datos están llenas de vulnerabilidades. Solo un servicio de base de datos tiene más de mil vulnerabilidades relacionadas.

Considere algunos ejemplos. La vulnerabilidad en CVE-2016-6662 se informó en septiembre de 2016, lo que permite a los atacantes insertar ajustes de configuración MySQL maliciosos en el servicio de base de datos de la víctima. También afectó a los clones de MySQL, incluido MariaDB, que se vio obligado a publicar medidas de mitigación detalladas aquí.

Otro ejemplo: en 2020, se identificó una vulnerabilidad de base de datos en la que los atacantes podían lanzar un ataque de escalada de privilegios debido a la forma en que algunas versiones de MariaDB trataban «setuid» durante la fase de instalación.

En nuestros dos ejemplos, corregir o actualizar a una versión más nueva del servicio de la base de datos solucionaría esta vulnerabilidad. Pero aquí está el problema: la aplicación de parches no es tan consistente como debería ser, sobre todo porque los equipos técnicos son perezosos o porque se olvidan los servicios de base de datos.

Simplemente vaya a la administración de parches, ¿verdad?

No exactamente. Hay otra razón por la que se descuida la aplicación de parches a la base de datos: la aplicación de parches a la base de datos puede ser increíblemente difícil, con instrucciones contradictorias y ambiguas. Este problema ocurre especialmente cuando las implementaciones de bases de datos son relativamente complejas.

Tome los clústeres de MySQL, por ejemplo. La base de datos MySQL de código abierto tiene un artículo oficial que describe cómo los usuarios deben reparar un clúster de MySQL, pero las instrucciones son complejas y tienen en cuenta solo una configuración de clúster de MySQL específica, InnoDB, si hay otras estrategias de clúster de MySQL.

Las instrucciones anteriores para MySQL también omiten varios aspectos importantes de la aplicación de parches. No cubre cómo el proceso de parche puede afectar a otras aplicaciones, o cómo puede afectar a otros sistemas en su solución tecnológica. Por supuesto, no puede ofrecer este consejo porque cada entorno es diferente y los autores no saben cómo es su entorno.

Y ahí radica el problema principal con las mejores prácticas de parches y las mejores prácticas generales para las bases de datos: es casi imposible tener en cuenta las infinitas variaciones prácticas, desde diferencias en la configuración de la base de datos hasta diferentes niveles de conocimiento técnico.

Las mejores prácticas de aplicación de parches son adecuadas para usted

El resultado neto puede ser que la implementación de las mejores prácticas de reparación publicadas sea muy ambigua e incierta. Los administradores de sistemas pueden decidir fácilmente que los riesgos y las consecuencias de la aplicación incorrecta de parches son mucho más importantes que el riesgo de un ataque cibernético en una base de datos. Entonces, si bien es teóricamente fácil «continuar parcheando», la realidad es muy diferente.

Incluso cuando los equipos tienen el conocimiento técnico y la confianza práctica para tener éxito en la reparación de una base de datos, todavía existe la realidad de que el servicio de la base de datos debe estar fuera de línea durante algún tiempo para realizar la reparación.

Sin alta disponibilidad, el tiempo de inactividad es el efecto secundario más perturbador, ya que los servicios técnicos se desconectan e interrumpen el trabajo.

Las configuraciones de alta disponibilidad pueden garantizar que no haya tiempo de inactividad, pero también es probable que experimenten una degradación del servicio porque algunos servidores en el clúster están fuera de línea y no pueden satisfacer la demanda o proporcionar la protección adecuada, mientras que algunos nodos están fuera de servicio por mantenimiento.

Los procedimientos de aplicación de parches complejos también consumen una cantidad significativa de tiempo, lo que quita recursos de otras tareas importantes y, en algunos casos, es posible que los recursos simplemente no estén disponibles para garantizar una aplicación de parches consistente.

Finalmente, desconectar bases de datos para reparar y administrar procesos de migración complejos siempre conlleva el riesgo de que algo salga mal. La corrupción de datos puede avanzar progresivamente durante la migración o es posible que algunos servidores no vuelvan a funcionar después de la reparación. Estos riesgos no se pueden ignorar y son una parte integral de las prácticas actuales de parcheo de bases de datos que requieren un reinicio.

Una alternativa es parchear la base de datos en vivo

Hasta hace poco, parchear un servicio de tecnología casi siempre requería un reinicio, pero el parcheo en tiempo real aún prevalece. Con el parcheo en vivo, las herramientas de parcheo intercambian el código parcheado en el acto: el servicio que se está reparando se ejecuta mientras el parcheo está en curso, sin necesidad de reiniciar.

Este es exactamente el papel de DatabaseCare, una nueva solución de TuxCare. Con DatabaseCare, puede realizar reparaciones integrales con la frecuencia que desee, ya que DatabaseCare repara su base de datos mientras ejecuta y da servicio a los datos de forma activa.

¿Como funciona esto? En la práctica, es simple. Su servidor se conecta al ePortal DatabaseCare local, donde los parches se almacenan de forma segura. Tan pronto como se detecta una nueva vulnerabilidad, el agente se comunica con el ePortal, que luego descarga la actualización de DatabaseCare. Luego, el agente congela su servicio de base de datos en modo seguro por un tiempo y aplica la solución de manera transparente en la memoria. Este «congelamiento» es tan rápido que ni siquiera interrumpe las conexiones de red al servicio o la consulta de la base de datos.

El resultado: sus bases de datos se actualizan automáticamente con los últimos parches de seguridad, sin tiempo de inactividad, con interrupciones y riesgos mínimos, y sin ningún esfuerzo continuo por parte de sus equipos técnicos.

¿Cómo le beneficia DatabaseCare?

Echemos un vistazo más de cerca a los beneficios de los parches en vivo, en comparación con las mejores prácticas de parches en su forma actual.

Ya hemos señalado la complejidad de parchear bases de datos, especialmente para bases de datos distribuidas con alta disponibilidad. DatabaseCare reemplaza un conjunto complejo de pasos que involucran procedimientos de migración complejos con un solo paso simple, único, que también se puede automatizar fácilmente.

Elimina la ambigüedad al parchear sus bases de datos. ¿Estás siguiendo las instrucciones correctas? ¿Funcionará incluso si lo haces perfectamente? Todos estos problemas ya no existen: la aplicación de parches se realiza automáticamente y en segundo plano. Entonces, sí, el riesgo asociado con la reparación de bases de datos ahora se reduce significativamente, lo que reduce la vacilación para reparar.

Al mismo tiempo, la aplicación automática de parches también significa que no tiene que tratar de incluir los parches como otra larga lista de tareas de TI agotadoras. Y cuando la aplicación de parches no compite por los recursos, ocurre con mayor frecuencia. Otras unidades de negocios dentro de la organización apreciarán que ya no necesita largas ventanas de mantenimiento para sus operaciones de aplicación de parches.

Todos sabemos lo que significa la aplicación regular de parches: mayor seguridad. Reduzca el tiempo entre la fecha de lanzamiento del parche y la aplicación de este, y reduzca el tiempo para los atacantes que pueden aprovechar la vulnerabilidad.

Las mejores prácticas son importantes, pero DatabaseCare desbloquea una seguridad consistente

La aplicación de parches a los servicios de la base de datos no es nada nuevo: las pautas de mejores prácticas existen desde hace algún tiempo. Sin embargo, existen dificultades prácticas para corregir las mejores prácticas en el estado actual, y estas dificultades prácticas abren una ventana para los atacantes cibernéticos.

DatabaseCare llena un vacío: no interrumpe sus operaciones, no representa un riesgo de falla y no necesita recursos para trabajar. Tu seguridad volverá a ser mucho más fuerte. Instalar DatabaseCare también es fácil. Para obtener más información, consulte la página de DatabaseCare en el sitio web de TuxCare.