Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Minimizar el tiempo de inactividad de la base de datos
21 de febrero de 2023 - Equipo de RRPP de TuxCare
Mantener las bases de datos parcheadas con las últimas actualizaciones de seguridad es esencial para que las organizaciones protejan sus datos. Los sistemas de bases de datos sin parches pueden dar lugar a ataques contra las operaciones básicas del sistema, incluidas las aplicaciones frontales. Los piratas informáticos suelen aprovechar los hosts, incluidas las bases de datos, como plataformas de lanzamiento de sus ataques.
Por este motivo, las organizaciones dan prioridad a la aplicación de parches de vulnerabilidad para protegerse. Sin embargo, mantener parcheadas estas vulnerabilidades de las bases de datos puede implicar programar tiempos de inactividad para aplicar las actualizaciones de seguridad, lo que puede provocar interrupciones en el negocio que nadie quiere afrontar.
Afortunadamente, es posible mantener las bases de datos parcheadas sin sacar los sistemas de producción ni tener que programar una ventana de mantenimiento. Se llama live patching, pero antes de entrar en materia, vamos a profundizar un poco más en el tiempo de inactividad de las bases de datos.
¿Por qué es tan importante el tiempo de actividad de las bases de datos?
Las aplicaciones corporativas, las plataformas orientadas al cliente y el análisis de datos dependen en gran medida del rendimiento, el tiempo de actividad y la seguridad de las bases de datos. Si los datos de los clientes quedan expuestos a vulnerabilidades de seguridad o la base de datos se bloquea durante un trabajo de replicación, esto tendrá consecuencias para la integridad de los datos.
Además, los problemas de integridad de las bases de datos podrían provocar el incumplimiento de las leyes de cumplimiento y privacidad, por no hablar de la pérdida de confianza de los consumidores. Si a esto se añaden las consecuencias financieras de limpiar el desastre que sigue a un incidente de seguridad de una base de datos, cualquier empresa podría llegar a un punto de no retorno. El coste de una sola violación de datos en Estados Unidos en 2022, por ejemplo, fue de 9,44 millones de dólares (IBM).
Los ingresos de las organizaciones dependen de sus servicios de aplicaciones y bases de datos de alto rendimiento y misión crítica. Por tanto, cualquier impacto en sus usuarios, asociaciones y ecosistema de la cadena de suministro debido a interrupciones de las bases de datos o fallos de seguridad hará que la empresa pierda algo más que ingresos.
¿Qué provoca la inactividad de la base de datos?
Varias circunstancias predecibles e impredecibles, entre ellas las vulnerabilidades comunes que explotan los ciberdelincuentes en las redes, bases de datos y aplicaciones frontales, podrían provocar la caída de cualquier sistema.
Las organizaciones suelen programar una ventana de control de cambios para realizar un mantenimiento crítico de sus bases de datos, los sistemas frontales correspondientes y las redes asociadas. En la mayoría de los casos, el tiempo de inactividad imprevisto de los datos puede deberse a un fallo en la actualización, a que los administradores de SecOps y de las bases de datos no dispongan de un plan de reversión en su plan de mantenimiento programado, o incluso a que se produzca un desastre natural, como cortes de electricidad o daños en las instalaciones.
Tiempos de inactividad por mantenimiento
Actualizar cualquier sistema informático es un proceso complejo. Incluso con los procedimientos más exhaustivos de control de cambios y ventanas de mantenimiento, el mantenimiento planificado podría convertirse en una interrupción inesperada. Durante una interrupción programada, si los distintos SecOps, DevOps y administradores de sistemas no pueden capturar todas las dependencias, podría producirse una interrupción inesperada de la producción.
¿En qué operaciones puede ocurrir esto?
- Actualizaciones de bases de datos y redes: La aplicación de parches a las bases de datos es importante para las organizaciones. La actualización de bases de datos y las rutinas de mantenimiento de la red son complicadas y están expuestas a interrupciones imprevistas y complicaciones técnicas.
- Mantenimiento rutinario: El mantenimiento del sistema de bases de datos incorpora varios pasos de parcheo y actualización:
- Aplicación de parches de seguridad para bases de datos de código abierto
- Actualización de tablas de datos y procedimientos almacenados
- Realizar la replicación de datos en un sistema de copia de seguridad antes de aplicar los parches.
Los sistemas de bases de datos también se encuentran en la base de la mayoría de las pilas de aplicaciones dentro de una organización, por lo que cualquier sistema, front-end o back-end, inevitablemente está trabajando con, añadiendo o modificando los datos contenidos en una base de datos, en algún lugar. Cuando esta dependencia es indirecta, es incluso posible que una interrupción de la base de datos cause interrupciones en sistemas que a primera vista podrían parecer desconectados de ella, a través de una API o una aplicación de pasarela de terceros.
La complejidad de la aplicación de parches a las bases de datos puede provocar tiempos de inactividad inesperados. En ocasiones, los parches de los proveedores provocan daños imprevistos en las tablas de la base de datos o en los procedimientos almacenados, lo que provoca interrupciones no planificadas. Los ingenieros de operaciones de seguridad y bases de datos SQL suelen probar los parches de los proveedores y actualizarlos en sus plataformas de desarrollo, control de calidad y puesta en escena para validar que el software de actualización funciona como se espera. A menudo, los problemas que no se detectan en el control de calidad aparecen en los sistemas de producción, provocando tiempos de inactividad inesperados.
Para evitarlo, los administradores de sistemas y los administradores de bases de datos SQL deben solicitar una ventana de control de cambios, incluso para las tareas de mantenimiento más pequeñas, a fin de evitar interrupciones de producción imprevistas.
De forma similar a las actualizaciones de bases de datos mencionadas anteriormente, la decisión de migrar a otra plataforma también podría provocar interrupciones inesperadas. La simple migración a la nube plantea varios riesgos para las operaciones de bases de datos, incluida la replicación incompleta de datos debido a la impredecible latencia de la red. No completar una replicación de datos de migración podría tener graves implicaciones para una organización que intenta volver a un estado estable positivo para las operaciones de aplicaciones y bases de datos.
¿Qué ocurre con otros tipos de paradas imprevistas?
En muchos casos, el tiempo de inactividad de la base de datos puede ocurrir como resultado de eventos que están aún más fuera del control de los equipos de TI/SecOps:
- Cortes de electricidad/catástrofes naturales: Aparte de los problemas imprevistos relacionados con la base de datos y otros sistemas informáticos durante una ventana de control de cambios, las catástrofes naturales, incluidos terremotos, inundaciones e incendios, pueden provocar cortes de electricidad y acceso a instalaciones críticas. El impacto y la duración de estas catástrofes naturales son difíciles de predecir.
- Fallo del servidor o del almacenamiento: Los sistemas de bases de datos dependen de la red para la conectividad, de los servidores que alojan la aplicación de base de datos y del nivel de almacenamiento para albergar los archivos de datos reales. Cualquier fallo en estas capas puede provocar una interrupción de la producción. Los clústeres de almacenamiento y los servidores admiten un diseño de HA y conmutación por error. Sin embargo, las organizaciones a menudo sólo prueban estas capacidades después de la configuración inicial si así lo exige un cliente o un mandato de seguridad.
- Error humano: Todos los sistemas críticos, incluyendo bases de datos, redes, aplicaciones y operaciones, son mantenidos por ingenieros humanos. El error humano es uno de los principales factores que hacen que una organización quede expuesta a ataques de ciberdelincuentes. Los errores en la aplicación de parches y en la configuración harán que se exploten las vulnerabilidades, lo que puede provocar la pérdida de datos y la indisponibilidad de los sistemas.
Medición del tiempo de actividad de bases de datos y sistemas
Las organizaciones del sector tecnológico suelen medirse a sí mismas según la escala de los "cinco nueves", basada en los niveles de tiempo de inactividad disponibles y aceptables. Una organización promocionará su disponibilidad de cinco nueves como ventaja competitiva en su respectivo mercado.
Además, las organizaciones se esforzarán por ofrecer una disponibilidad de cinco nueves mediante una gestión exhaustiva de los parches, las operaciones de seguridad y los procesos generales de gestión de TI.
AWS publicó en su sitio web un desglose gráfico que muestra los niveles aceptables de tiempo de interrupción:
Como factor adicional, no se trata sólo de que se produzca un 0,001% de tiempo de inactividad, también es relevante saber cuándo se produce una interrupción de este tipo. Es muy diferente que una interrupción se produzca fuera del horario comercial habitual o durante el pico de actividad de ventas en una temporada de vacaciones. Y, si hay algo que los profesionales de TI han aprendido a lo largo de los años, es que -según la Ley de Murphy- la interrupción siempre se produce cuando menos se espera y se desea.
Modernizar la gestión de parches para minimizar las interrupciones
Las organizaciones que desean reducir la complejidad de los parches de seguridad de las bases de datos y el riesgo de error humano han transformado digitalmente su enfoque de parcheado de vulnerabilidades adoptando el parcheado en vivo a través de TuxCare. La solución de live patching de TuxCare para bases de datos, denominada DBCare, permite a los equipos desplegar parches en los sistemas de bases de datos sin necesidad de reiniciar o programar tiempos de inactividad, lo que elimina por completo las interrupciones relacionadas con los parches.
Además, DBCare es compatible con MySQL, MariaDB y PostgreSQL, independientemente de si se encuentran en un centro de datos local o en las ofertas de AWS Aurora o Relational Database Services (RDS).
Otro componente fundamental de la aplicación de parches en directo de TuxCare es la completa automatización y la compatibilidad con una opción de despliegue de bucle cerrado. Nuestra tecnología de aplicación de parches en tiempo real ofrece las actualizaciones de seguridad más recientes con una interacción humana mínima, lo que reduce los errores y la exposición a vulnerabilidades.
TuxCare también ofrece parches en vivo para bibliotecas compartidas, entornos de máquinas virtuales, dispositivos IoT y todas las distribuciones Linux empresariales populares, a diferencia de muchas alternativas de parches en vivo que solo son funcionales para una única distribución o unas pocas.
Programe una conversación con uno de nuestros expertos para obtener una explicación personalizada de cómo funciona la automatización de parches en directo de TuxCare.
