Prácticas recomendadas para la gestión de parches

Como arquitecto de soluciones, a menudo me preguntan cuáles son las prácticas recomendadas de Red Hat para la gestión de parches. En este artículo, proporcionaré información importante y la relacionaré con trabajos y materiales relevantes, cuando sea necesario, para explicar de manera concisa el concepto de estas prácticas y las herramientas que puede aprovechar como parte de su kit de gestión de parches.

Después de leerlo, tendrá una mejor comprensión sobre estos recursos, los enfoques que puede aprovechar para distribuir parches para su empresa y los métodos más eficaces para definir ese proceso.

Es cierto que es un poco presuntuoso decir que un método en particular es una "práctica recomendada", en el sentido de nombrarla como la "mejor". Lo más conveniente para una empresa puede no serlo para otra. Por lo tanto, en lugar de denominar a un enfoque como "el recomendado" o "el mejor", considero que es más apropiado analizar el proceso según lo que sea más adecuado para cierto nivel de riesgo. Cuando se habla de gestión de parches, básicamente se hace referencia a la gestión de riesgos o de cambios.

Todas las empresas necesitan un enfoque para abordar los riesgos. Sin embargo, este es único y cada empresa debe determinar en qué se centra y de qué manera evalúa las diversas limitaciones, las áreas afectadas y los resultados empresariales.

Considero que "buenas prácticas" es un término más apropiado. Por ejemplo, la comunidad de prácticas de automatización publica un documento sobre las buenas prácticas de automatización que se basa en la información que obtiene de ayudar a los clientes que pertenecen a este campo.

¿Qué podemos aprovechar de nuestro kit de herramientas y enfoque para la gestión de parches?

Existen recursos y metodologías para definir la manera de administrar los parches en su infraestructura.

1. Definiciones de erratas

Red Hat desglosa los cambios en el código o el contenido (erratas) en tres categorías. Cada una tiene un propósito y una velocidad de modificación diferentes. Una opción puede ser mejor que otra para cierto objetivo y velocidad según las metas y la tolerancia al cambio de su empresa.

• Aviso de seguridad de Red Hat (RHSA): se implementan cambios urgentes para proteger los sistemas
• Aviso de errores de Red Hat (RHBA): corrección de errores que pueden haber afectado a los sistemas
• Aviso de mejora de Red Hat (RHEA) : se agregan nuevas funciones

Para obtener más información, consulte las páginas security backporting practice y what is backporting, and how does it apply to RHEL and other Red Hat products?

Con este principio, puede separar las erratas según el tipo y el riesgo, y luego elegir los parches que considera necesarios y los que considera opcionales. 

Por ejemplo, si se trata de una infraestructura con acceso a Internet o una zona desmilitarizada (DMZ) con un perfil de seguridad alto, puede optar por aplicar solo la errata del aviso de seguridad de Red Hat con la frecuencia que se publique en ese entorno. De ese modo, puede abordar las necesidades de las infraestructuras de alto riesgo y, al mismo tiempo, dividir los cambios en lotes pequeños y manejables. 

En estos enlaces, verá ejemplos sobre la forma de aplicar solo las erratas de seguridad en un proceso de parches:

• Is it possible to limit yum so that it lists or installs only security updates?
• How to apply security errata from Red Hat Satellite?

Otro enfoque que se debe tener en cuenta es la aplicación de parches en subconjuntos de paquetes para reducir aún más el riesgo que conlleva el cambio. Esto también le brinda la flexibilidad de poder restaurar el sistema, en caso de que el parche interactúe con él de maneras inesperadas. Al igual que con cualquier enfoque, existen ventajas y desventajas que deben considerarse y gestionarse. Esto puede ser un proceso demasiado detallado para algunos, mientras que para otros puede ajustarse mejor a la tolerancia al cambio.

2. 10 Steps to Build a Standard Operating Environment (SOE)

En este artículo, se proporciona una guía completa sobre el uso de Red Hat Satellite para habilitar y gestionar un entorno operativo estándar. Se tratan todos los temas con gran detalle, y se creó con el objetivo de ser un punto de referencia para responder las preguntas más comunes sobre las prácticas recomendadas. Si bien se redactó hace varios años, cuando se presentó por primera vez Red Hat Satellite 6, en la actualidad, aún se aplican los conceptos básicos.

La gestión y la preparación del contenido son de suma importancia en el proceso de aplicación de parches, ya que establecen la base para que se incluya en la infraestructura y desempeñan un papel importante en el proceso en términos de gestión y reducción de los riesgos.

Concéntrese especialmente en los entornos de ciclo de vida y las vistas de contenido de Satellite. Estos son conceptos fundamentales para la preparación del contenido y su traslado (o restauración) a la infraestructura.

Luego, enfóquese en las secciones Organizations, Locations y Host Groups para clasificar la infraestructura y el inventario. Con demasiada frecuencia, me encuentro con que los usuarios se vuelven demasiado detallistas con los entornos de ciclo de vida o las vistas de contenido e intentan usar estas estructuras para resolver los temas de clasificación de ubicaciones geográficas, entornos de nube, infraestructuras similares o diferentes equipos dentro de una empresa.

3. Ejecución activa de parches en el kernel

La ejecución activa de parches en el kernel está disponible desde hace varios años y forma parte de varias versiones importantes de Red Hat Enterprise Linux. Puede aplicar este proceso sin reiniciar el sistema para corregir un punto vulnerable rápidamente. De ese modo, los administradores pueden abordar el riesgo de inmediato y programar un período de mantenimiento más adecuado cuando se pueda reiniciar el sistema. 

Esto también se puede organizar con Red Hat Satellite.

4. Identificación de paquetes que requieren un reinicio del sistema después de una actualización

Según la actualización y el contenido de las erratas, puede que no sea necesario reiniciar el sistema después de aplicar un parche. A veces, todo lo que se necesita para usar un archivo binario actualizado después de una actualización es volver a iniciar el servicio. 

A partir de Red Hat Enterprise Linux 7, yum-utils incluye un plug-in denominado needs-restarting. Este complemento le informa si es necesario reiniciar el sistema después de aplicar los parches. Con esa información, podrá saber si se deben realizar cambios en un sistema, y se disminuye la necesidad de implementar reinicios al ejecutar un parche.

Satellite también cuenta con una función denominada Tracer, la cual logra lo mismo desde la perspectiva de la herramienta, ya que ayuda a los administradores a identificar las aplicaciones que deben reiniciarse después de ejecutar un parche en un sistema.

5. Considere solicitar soporte preventivo de Red Hat

Si se cuenta con conocimiento avanzado sobre una actividad de mantenimiento determinada y tiene la oportunidad de recopilar información y datos por adelantado, se puede reducir el tiempo de inactividad y algunos de los riesgos asociados con la aplicación de parches.

Una solicitud de soporte preventivo puede reducir considerablemente el tiempo de resolución de problemas que se necesita para la recuperación de un servicio, así como brindar la oportunidad de revisar los procedimientos o enfoques con anticipación. Esto puede tener un impacto medible en la reducción de las interrupciones y los indicadores de tiempo medio de resolución (MTTR).

6. Implemente la automatización

No es ningún secreto que remplazar las tareas manuales con un enfoque automatizado reduce los errores humanos, aumenta la confiabilidad y acelera el proceso de aplicación de parches. La automatización marca una diferencia importante a la hora de adoptar las prácticas recomendadas adecuadas para su empresa.

Red Hat Satellite cuenta con una función para usar la ejecución remota con Ansible. Además, puede ejecutar los playbooks y las funciones de Ansible en su inventario de Red Hat Enterprise Linux y automatizar y programar de manera sencilla la aplicación de parches.

De hecho, con el conjunto de contenido oficial de Ansible redhat.satellite, que se incluye en Red Hat Ansible Automation Platform, puede automatizar y organizar toda la gestión de contenido de Satellite y aplicar el contenido de parches después de su organización.

Incluso hay módulos de Ansible que puede usar para realizar pruebas funcionales para servicios web o verificación de servicios después de haber aplicado un parche.

Resumen

Red Hat publicó An Open Approach to Vulnerability Management, una publicación de blog en la que se ofrece una metodología concisa y completa sobre la forma en que las empresas abordan la gestión de los puntos vulnerables. Las decisiones sobre la gestión de riesgos se pueden tomar después de considerar y sopesar las limitaciones, las consecuencias y los resultados empresariales.

La pregunta es: ¿todos los puntos vulnerables son importantes? En este artículo, se destacan algunas de las realidades, las ventajas y las desventajas relacionadas con la evaluación de las limitaciones, las consecuencias y los resultados. Este es un buen ejemplo de cómo sopesar el deseo de obtener resultados con el costo y el beneficio de lograrlos. Si bien se deben tener en cuenta los riesgos, no todos deben considerarse de la misma manera, y nadie tiene recursos ilimitados para abordarlos. En este ejemplo, se trata de priorizar lo más importante y tener una estrategia para clasificar el riesgo que vale la pena reducir y el que no representa un verdadero problema.

En pocas palabras, se necesita repetición y compromiso. Ninguno de los ejemplos de este artículo constituye un esbozo de estrategia. Cada uno de ellos se revisó y perfeccionó una y otra vez hasta que encontramos un equilibrio de gestión de riesgos adecuado para Red Hat. Estos métodos se siguen perfeccionando a medida que aprendemos cosas nuevas y que cambia el panorama del sector. Es tan importante seguir evaluando la tolerancia al riesgo y la postura sobre el tema como tener un enfoque definido desde el principio. La personalización y el refinamiento permanentes son lo que hace que las prácticas puedan ser "recomendadas".