Cambio de paradigma en la aplicación de parches

Cualquier tiempo de inactividad -planificado o no- supone siempre una circunstancia desafortunada para los equipos del centro de datos SAP y también para los departamentos especializados o los usuarios de las empresas.

En cuanto a los tiempos de inactividad previstos, seguimos teniendo una media estimada de cinco días al año, una cifra nada desdeñable. A lo largo de los años, los procesos de aplicación de parches se han vuelto más o menos rituales y se siguen guiones estándar: los intervalos de aplicación de parches son relativamente fijos, y los parches suelen tener lugar los fines de semana.

Prácticamente todos los departamentos de operaciones informáticas están implicados y los periodos de inactividad planificados se coordinan con los departamentos especializados.

No hay fechas fijas para las paradas imprevistas en los centros de datos SAP y no es posible cambiar a los fines de semana. La coordinación con los departamentos no es posible.

Por regla general, durante una parada imprevista sólo puede solucionarse un problema concreto. Para minimizar los tiempos de inactividad imprevistos, existen varios conceptos y soluciones, por separado o combinados: RAS (Fiabilidad, Disponibilidad, Capacidad de Servicio), virtualización, clusters HA/GEO, reversión del sistema o parcheado en vivo/online.

En tiempos de negocios en tiempo real, se nos exige que nos esforcemos por conseguir un verdadero funcionamiento 7X24 o "Hacia un tiempo de inactividad cero". La naturaleza de las cosas exige que las actualizaciones de software (y de vez en cuando las de hardware) se lleven a cabo en un centro de datos SAP.

Más que en el pasado, la atención se centra en la seguridad. Los llamados CVE (Common Vulnerabilities and Exposures) también afectan a los sistemas operativos.

Los CVE describen agujeros de seguridad y otras vulnerabilidades sobre la base de convenciones uniformes; en este caso: la vulnerabilidad de las plataformas de sistemas operativos, incluido el núcleo. Linux no está exento de esto.

Por ejemplo, en 2014 se identificaron 24 CVE clasificadas como graves para Linux. Hubo más para otros sistemas operativos. Es de suponer que las CVE en su conjunto seguirán aumentando.

La aplicación de parches de seguridad repercute en los tiempos de inactividad planificados y no planificados. No debe darse el caso de que, por ejemplo, las actualizaciones de seguridad o un tipo de terapia CVE provoquen un freno total de TI o SAP.

El objetivo debe ser: La aplicación de parches sin reiniciar el sistema, incluidos los acuerdos con los departamentos sobre los tiempos de inactividad, por ejemplo, con SAP no se utiliza durante un determinado período de tiempo.

Tiene que entrar en juego el parcheado en vivo, que da la puntilla a los conceptos convencionales y, en el fondo, aumenta de forma sostenible la disponibilidad de los servicios informáticos de las aplicaciones SAP críticas. Suse lleva años trabajando en la aplicación de parches en vivo o en línea del núcleo Linux en el entorno empresarial, sin las típicas paradas del sistema.

En el proyecto de desarrollo kGraft, se amplió la clásica actualización dinámica de software (DSU), utilizada principalmente para parches de seguridad y parches de tamaño limitado, con el objetivo de proporcionar una solución estándar de parcheado en vivo para la implantación de Linux Enterprise.

kGraft se basa en las tecnologías más avanzadas de Linux, incluido el código auto-modificable INT3/IPI-NMI, un mecanismo de actualización tipo RCU, asignación de espacio NOP basada en mount y mecanismos estándar de carga/enlace de módulos del kernel.

Como parte de la edición de Sapphire de este año, Suse presentó su solución Suse Linux Enterprise Live Patching certificada por SAP, que desde entonces está disponible para servidores x86-64. Además, se entrega con SLES 12 Service Pack 1 para aplicaciones SAP (Hana, NetWeaver y otras plataformas SAP).

Con Suse Linux Enterprise Live Patching, Suse ofrece a las empresas una palanca para dar la espalda a conceptos de parcheado obsoletos. Para implementar conceptos de operaciones de seguridad sin tiempos de inactividad planificados y minimizando los tiempos de inactividad no planificados (mediante CVE).

Al mismo tiempo, se puede mejorar la gestión de riesgos, minimizar proactivamente el potencial de ataque de programas maliciosos y, sobre todo, aumentar la calidad de los servicios informáticos.