¿Virtualizar un servidor significará otra capa de sistema operativo para parchear y actualizar, más trabajo y mayor riesgo?

He realizado una búsqueda y no he encontrado nada que aborde problemas relacionados con parches y actualizaciones del sistema. Tengo pautas que dicen que los servidores deben tener los parches necesarios. Si tengo un host VM, ¿es esa una capa adicional para parchar y actualizar, incluso con hipervisores de metal desnudo? ¿A diferencia de tener un servidor de metal? (es decir, más trabajo, pruebas y documentación según mis directrices).

¿Con qué frecuencia se actualizan los hipervisores tipo 1 / bare-metal? ¿Eso importa? ¿El hecho de que sea una capa de software adicional introduce más complejidad y riesgo (seguridad y fiabilidad)? (por ejemplo, 99% de software sin errores x 99% de software sin errores = 98% de sistema sin errores)?

(Mi experiencia práctica es con VMWare Workstation and Server, y VirtualBox).

Sí, los productos como VMware deberían ser parcheados a veces ( las actualizaciones son acumulativas ), pero los parches son menos frecuentes que un sistema operativo de línea principal y el vector de ataque potencial es más pequeño: su hipervisor no debe ser de acceso público .

Usaré VMware ESXi versión 5.0 (no 5.1) como ejemplo ...

ESXi 5.0 ha tenido el siguiente programa de actualización:

Entre el 9/2011 y el presente, hubo diez actualizaciones para el producto ESXi 5.0. De esos, SIX fueron actualizaciones centradas en la seguridad incluidas en los paquetes de actualizaciones con descripciones como:

"Vulnerabilidad de análisis de tráfico ESXi NFS" - CVE-2012-2448 .

Estas vulnerabilidades de seguridad son reales, ya que a veces reflejan errores generales de seguridad de Linux, pero creo que la mayoría de las organizaciones no son muy susceptibles a los riesgos. Sin embargo, depende del ingeniero evaluar este riesgo. ¿Sus usuarios querrían un tiempo de inactividad masivo para corregir el siguiente exploit ?

"La macro encode_name en misc / mntent_r.c en la Biblioteca GNU C (también conocida como glibc o libc6) 2.11.1 y anteriores, tal como la usan ncpmount y mount.cifs, no maneja correctamente los caracteres de nueva línea en los nombres de los puntos de montaje, lo que permite a los usuarios locales para causar una denegación de servicio (corrupción mtab), o posiblemente modificar las opciones de montaje y obtener privilegios, a través de una solicitud de montaje diseñada ".

¿Tal vez? Tal vez no.

Corro Administrador de actualizaciones de VMware , pero sólo tiendo a la actualización si estoy impactado por un error o que requieren una mejora de funciones. Cuando se ejecuta en una configuración agrupada, la aplicación de parches es fácil sin tiempo de inactividad para las máquinas virtuales en ejecución. Si no existen otras razones urgentes, me esforzaré por actualizar trimestralmente. Los hosts individuales requerirán un reinicio completo, ya que los parches se entregan como imágenes monolíticas.

Como nota al margen, cada vez que heredo una configuración de VMware ESXi o trabajo en un sistema que normalmente no administro, a menudo veo hosts en ejecución que nunca han aplicado parches de VMware. ¡¡Eso está mal!! Pero puedo ver cómo los administradores pueden cometer ese error una vez que los sistemas están en funcionamiento.

Esta es una muy buena pregunta si eres nuevo en la virtualización con hosts 'bare metal'. Hacer las cosas de esta manera requiere una mentalidad diferente al enfoque que podría adoptar con los hipervisores que se ejecutan como un servicio / aplicación en la parte superior de un sistema operativo convencional.

En mi experiencia, probablemente sea justo decir que ESX e HyperV necesitan menos parches en general que los sistemas operativos convencionales. Esto no significa que no necesiten parches en absoluto, o que aplicar algunos parches no sería beneficioso independientemente de la "necesidad", pero esto significa que las interrupciones en sus servicios para parchar el host deberían ser menos frecuentes y más bajo tu control. Existe un riesgo potencial de seguridad para los sistemas operativos del hipervisor al igual que para cualquier otro, y si bien puede minimizar la exposición de este riesgo (por ejemplo, solo exponer la administración del hipervisor en una VLAN aislada que no se puede alcanzar lógicamente desde un servidor comprometido) Sería una tontería fingir que no hay ningún riesgo.

Entonces, si tiene 4 servidores no virtuales, por ejemplo, y los mueve a todos al mismo host virtualizado individual, entonces sí, está aumentando la cantidad de interrupciones que podrían ser causadas por la necesidad de parchear el sistema host (o lidiar con un problema de hardware, etc., para el caso).

Si bien sugeriría que la posibilidad de que ocurra este riesgo es relativamente baja (estoy hablando de la diferencia entre parchear un host virtual y el tipo de parche que requiere un reinicio que de todos modos tendría que hacer en un sistema independiente ), no hay forma de alejarse del hecho de que el impacto es alto.

Entonces, ¿por qué lo hacemos entonces?

El verdadero beneficio de la virtualización proviene de poder configurar más de un host y configurar los hosts para que trabajen juntos, lo que permite que los invitados se trasladen de un host a otro en caso de que un host falle o si desea programar parches en Los sistemas host.

Usando este enfoque, he logrado parchear 5 hosts ESX a su vez sin ninguna interrupción en los 40 servidores virtuales que se ejecutan sobre ellos. Esto es simplemente una cuestión de economías de escala: una vez que tenga suficientes máquinas virtuales invitados potenciales para que valga la pena construir este tipo de configuración compleja y administrarla con el tipo de herramientas que @ewwhite menciona en su respuesta, la recompensa por reducir los riesgos Te preocupa que llegue muy rápido.

Un servidor virtual requerirá el mismo mantenimiento y parches que un servidor físico, los hipervisores básicos requerirán actualizaciones, por seguridad, pero también para corregir errores y mejorar el rendimiento. Cuantos más servidores tenga, más trabajo tendrá que hacer para mantenerlos actualizados, no importa si son físicos o virtuales.

Parece que según las respuestas anteriores: la virtualización de un servidor ha introducido más complejidad y riesgo en seguridad y confiabilidad, pero estos deben compararse con los beneficios de poder reducir el tiempo de inactividad virtualizando un servidor.

Si su entorno requiere auditoría, pruebas y documentación, el costo-beneficio de la carga de trabajo adicional de un entorno virtualizado deberá tenerse en cuenta con la cantidad de servidores y personal de sistemas que tenga. En nuestro entorno no tenemos el tiempo del personal / personal para mantener la pista de auditoría para un entorno virtualizado. En nuestros procesos de negocios, podemos tomarnos un tiempo de inactividad, pero no podemos faltar un rastro de auditoría y documentación.