Sobre la impostergable necesidad de repensar la seguridad en VDI

Días atrás me consultaron lo siguiente: “Estamos por implementar 300 escritorios virtuales Windows 7 con Vmware View y no sabemos que hacer con el asunto antivirus. Un técnico amigo nos recomendó prudencia, porque existen ciertos factores a considerar (…)”

La problemática a discutir será el antivirus en ambientes VDI (Virtual Desktop Infraestructure), no en servidores: servidores es otro paradigma de merecida extensión que en todo caso mencionaremos en otra oportunidad.
Nuestra tríada de argumentos pro antivirus-para-ambientes-virtuales es la siguiente: más recursos, más disponibilidad, y más seguridad. Y los planteo en tal orden pues se trata del nivel de impacto que se percibe al cambiar de antivirus clásico a antivirus de hipervisor.

¿Y qué es esto de antivirus clásico y antivirus de hipervisor?

Antivirus clásico

Antivirus de hipervisor

Como habrán notado en las para nada complejas descripciones gráficas, un antivirus de hipervisor, básicamente, nos evita la necesidad de instalar agentes en cada escritorio virtual.

¿Cómo es esto?

Simple: En un modelo de antivirus clásico, el cliente de antivirus instala en el sistema operativo un driver a nivel de kernel que intercepta las operaciones de IO, las analiza y compara contra su patrón de firmas cargado en memoria, y devuelve un veredicto sobre la validez de dicha operación de IO.
En un antivirus de hipervisor el driver de kernel responsable de la intromisión está instalado justamente en el hipervisor del host ESXI, y no en el sistema operativo guest. En un ambiente de antivirus de hipervisor, además, cada Host ESXI dispone de un appliance virtual de seguridad ejecutándose como maquina virtual. Dicho appliance tiene las firmas de virus en memoria, y se encarga de responder a todas las solicitudes de análisis de IO que recibe por parte del kernel del hipervisor, y dado que el kernel tiene visibilidad e injerencia sobre toda operación de IO de los escritorios virtuales, podemos decir que no se les escapa una.
En pocas palabras, el enfoque de antivirus clásico requiere de un agente AV en cada desktop, con su footprint en memoria, su patrón de virus en memoria, y su consumo de recursos acorde. En un enfoque de hipervisor, el agente es un único virtual appliance por Host que analiza las operaciones de IO de todos los escritorios virtuales de dicho Host.

¿Y qué es eso de recursos-disponibilidad-seguridad?

Buen punto. Primero la memoria RAM. Un cliente antivirus puede requerir de unos 300-400 Mb promedio solamente para existir. Supongamos un host ESXI que soporta 40 escritorios virtuales, 40 por 350 son 14Gb de memoria solamente de Antivirus. Esos 14Gb se transforman en 3 o 4 si decidimos implementar un antivirus de hipervisor, no se a ustedes, pero a mi me gusta cuidar la RAM.

¿Y nada más?

Mucho más. Imaginemos una implementación de Linked Clones. Uno de los puntos más interesantes de los clones es el ahorro de storage, si tenemos 80 desktops en base a una imagen de 40GB, necesitaríamos de 3.12 TB aproximados de Storage. Pero, en cambio, si utilizaramos clones, nos bastaría con unos +-500Gb totales (entre imagen master y deltas).
Supongamos que implementamos clones porque nuestros usuarios solo se dedican a trabajar con documentos de texto y plantillas. Cuanta información nueva, por día, escribirán los usuarios en el disco?
Y depende, porque si el usuario tiene un antivirus clásico de esos que descargan 4 firmas de 100mb por día, posiblemente mucho. Adicionalmente, con cada operación de Refresh que ejecuten los clones, sería absolutamente necesaria una descarga de firmas que posiblemente no fueran solo las firmas del día, sino todas las firmas que se liberaron desde la última vez que se actualizó la imagen Master. Y es este otro asunto resuelto con el antivirus de hipervisor, ya que siendo que el appliance es el único que necesita tener las firmas, están se descargan e implementan una sola vez.

Siguiendo la linea de firmas y storage: ¿Qué pása cuando se libera una nueva firma de virus y mis 80 VDI se ponen a descargarla en simultáneo? ¿Cómo se comporta esa única LUN que aloja todos mis discos de desktop?
Esa LUN muy posiblemente explote, y si no explota, será tan alta su latencia, que más de un usuario ofendido gritará que así no se puede trabajar, que a quien se le ocurre implementar escritorios virtuales y que todo tiempo por pasado fue mejor.
Esto sucede porque cuando se dimensiona una infraestructura de VDI, si bien se consideran IOPs promedio + ciertos picos, el proyecto sería inviable si se contemplaran también los casos en los cuáles TODOS los desktops tuvieran una actividad intensiva de escritura y/o lectura en el mismo preciso momento.
Este síndrome, conocido como AV Storm, también aplica cuando todos los agentes de AV inician escaneos en simultáneo (es decir, lecturas masivas de disco).
Si bien existen las llamadas Ventanas de randomización, para actualizar firmas o programar escaneos, no son del todo seguras ya que consisten, básicamente,  en dispersar el update de firmas en un amplio umbral de tiempo para evitar colapsar el storage. Esto es lo mismo que vacunarse una semana tarde contra una epidemia de gripe aviar.

Una más sobre seguridad: Permítanme recordarles a todos ustedes lo cómodo que es trabajar con templates de sistemas operativos de esos que tenemos guardados en la carpeta “Imágenes”. Eventualmente, el administrador vmware responsable y consciente de los riegos informáticos, instancia esos templates, los actualiza según corresponde y los vuelve a cerrar porque entiende que es una tarea necesaria reductora de riesgos.
De todas formas, “eventualmente” dista muchísimo de la frecuencia ideal. Eventualmente no es todos los días, siquiera una vez por semana. Eventualmente puede ser una vez cada dos meses, eventualmente es entonces inadmisible.
¿Pero qué tal si les dijera que todos esos templates, si se usara antivirus de hipervisor, ahora estarían protegidos, independientemente de cuanto tiempo lleven sin actualizaciones?
Ya que las firmas de AV son asunto del security appliance, ni bien se instancia un template este ya está siendo monitoreado y protegido. Esto para nada hace de “eventualmente” un plazo ideal, pero sí lo vuelve un poco más tolerable, de eso no hay duda.
Espero haber logrado transmitir de forma clara, las principales razones por las cuáles es absolutamente necesario pensar al antivirus desde otro lugar: tomarnos un momento para decidir cómo vamos a encarar el asunto. Y esto no supone decir: “Me convencieron, voy a migrar a antivirus de hipervisor”, porque no siempre es posible. Sino más bien, tomar consciencia de cuáles son los riesgos y desventajas del camino clásico, y a partir de ello definir si nos interesa hacer algo o no al respecto.

Posiblemente más adelante escriba algo similar respecto al paradigma de AV en servidores virtuales.

Por el momento, los invito a investigar sobre la solución de antivirus de hipervisor Deep Security de Trend Micro, que cumple con creces las necesidades del mercado, y a comunicarme cualquier duda, consulta o sugerencia.

Luciano Zeppa