Hace veinte años, casi al día, Amazon Web Services (AWS) lanzó Simple Storage Service (S3). Poco después, el servicio Elastic Compute Cloud (EC2) abrió su beta pública antes de lanzarse oficialmente en 2008. Estos eventos marcaron el inicio de la era moderna del almacenamiento y la computación bajo demanda en la nube, transformando la forma en que organizaciones de todos los tamaños conciben su infraestructura de TI. Sin embargo, dos décadas después, un problema persistente y silencioso amenaza la seguridad de estas mismas organizaciones: la falta de visibilidad total sobre sus propias máquinas virtuales. Según la Cloud Security Alliance, solo el 23% de las empresas reporta tener una visión completa de su huella en la nube, lo que significa que el 77% carece de visibilidad total sobre sus máquinas virtuales y otros activos cloud. Esta ceguera operativa no es un detalle menor; es la puerta de entrada a incidentes de seguridad que pueden costar millones.
El origen de la proliferación de máquinas virtuales: de la facilidad al caos
Los proveedores de servicios en la nube (CSPs) como AWS, Microsoft Azure y Google Cloud Platform (GCP) han diseñado sus plataformas para que el aprovisionamiento de nuevas máquinas virtuales (VMs) sea prácticamente instantáneo. Esta fricción cero es, en parte, lo que hace tan atractiva la nube. Un administrador puede levantar una instancia VM en cuestión de minutos. El problema es que el proceso inverso —desmantelar una VM cuando ya no se necesita— rara vez recibe la misma urgencia. En muchas empresas, especialmente aquellas con configuraciones multi-cloud que involucran AWS, Azure, GCP u otros CSPs, esta dinámica genera una acumulación creciente de cargas de trabajo que quedan fuera del alcance de las operaciones de seguridad.
Los CSPs ofrecen protecciones básicas, pero el trabajo continuo de seguridad recae en el cliente. Las máquinas virtuales abandonadas a menudo no reciben actualizaciones del sistema operativo; peor aún, no son monitoreadas y están sujetas a políticas de acceso que no han cambiado desde el día en que alguien creó la instancia. Esto incrementa el riesgo de que una máquina virtual se convierta en un vector de ataque silencioso, operando bajo el radar hasta que es demasiado tarde.
77% sin visibilidad: el dato que debería encender todas las alarmas
La visibilidad de la nube es un problema persistente. Los datos de la Cloud Security Alliance indican que solo el 23% de las organizaciones afirma tener una visión completa de su huella en la nube. El crecimiento descontrolado de activos, incluyendo flotas enteras de máquinas virtuales, es una gran parte del problema. Las rutas de ataque más comunes —como buckets de almacenamiento mal configurados y APIs expuestas— dominan las revelaciones de brechas, en parte porque generan señales públicas. Mientras tanto, el abuso de máquinas virtuales ocurre de forma más sutil y dentro del entorno interno; una identidad administrada que consulta almacenamiento en la nube no activa las mismas alarmas que una dirección IP externa intentando iniciar sesión.
El informe de 2024 de la Cloud Security Alliance clasificó la mala configuración y el control de cambios inadecuado como la principal amenaza para los recursos en la nube, seguida por las debilidades en la gestión de identidades y accesos (IAM). Esto coincide con la naturaleza impulsada por la identidad de las cargas de trabajo en la nube, donde tanto la máquina virtual en sí misma como lo que puede acceder merecen escrutinio. Según el informe 2024 State of Multicloud Security de Microsoft, las identidades de carga de trabajo asignadas a máquinas virtuales y otros recursos no humanos superan ampliamente a las identidades humanas, y la brecha no hace más que ampliarse a medida que las organizaciones despliegan más recursos de cómputo.
¿Qué es la proliferación de máquinas virtuales y por qué es un riesgo de seguridad?
La proliferación de máquinas virtuales, o VM sprawl, es el crecimiento descontrolado y no gestionado de instancias de máquinas virtuales dentro de un entorno de nube. Este fenómeno ocurre cuando los equipos crean VMs para proyectos temporales, pruebas o tareas específicas y luego se olvidan de eliminarlas. El riesgo radica en que estas VMs olvidadas conservan identidades y permisos que, con el tiempo, pueden ser explotados por atacantes para obtener acceso inicial a la red corporativa, moverse lateralmente entre sistemas y acceder a datos sensibles. Dado que a menudo no reciben parches de seguridad ni monitoreo, se convierten en puertas traseras ideales para los ciberdelincuentes.
Identidades de carga de trabajo: el nuevo perímetro de seguridad
La realidad es bastante mundana, pero peligrosa. Un ingeniero de machine learning aprovisiona una máquina virtual para tareas de procesamiento de datos. A la VM se le asigna una identidad, pero como definir sus permisos siguiendo el principio de mínimo privilegio llevaría demasiado tiempo, recibe acceso amplio de lectura/escritura al almacenamiento de datos y a otros recursos. Los proyectos terminan, pero las máquinas virtuales con permisos excesivos quedan «abandonadas a su suerte».
Una máquina virtual abandonada puede hacer más que simplemente «acumular polvo». Dado que cada VM está vinculada a alguna forma de identidad que determina a qué puede acceder la carga de trabajo en todo el entorno, las instancias olvidadas pueden ser explotadas por actores maliciosos para obtener un punto de apoyo inicial. Como las máquinas virtuales dentro de la misma nube privada virtual (VPC) o red virtual (VNet) a menudo pueden comunicarse entre sí en dirección este-oeste sin muchas restricciones, una VM comprometida puede sondear instancias adyacentes, alcanzar bases de datos internas o endpoints de almacenamiento, y explotar los permisos que se le concedieron. Con demasiada frecuencia, la microsegmentación de red resulta ser una tarea demasiado compleja de implementar.
En entornos híbridos que involucran identidades híbridas —por ejemplo, cuando Active Directory local se sincroniza con Entra ID— las cosas pueden complicarse aún más. Una máquina virtual comprometida en Azure que esté unida a un inquilino de Entra ID podría alcanzar archivos compartidos, bases de datos, aplicaciones u otros recursos que forman parte de la infraestructura local central de la organización.
Casos reales: cuando las máquinas virtuales se convierten en armas
Los ejemplos de ataques reales que involucran máquinas virtuales no son difíciles de encontrar. En una campaña documentada por Darktrace, los atacantes se movieron entre instancias EC2 de AWS a través de RDP interno, almacenaron cientos de gigabytes de datos exfiltrados en múltiples máquinas virtuales y desplegaron ransomware dentro de la red en la nube. El monitoreo detectó la actividad, pero la respuesta automatizada no estaba configurada correctamente para detenerla, y el ransomware se ejecutó.
Otros atacantes están explotando la misma facilidad con la que se pueden crear máquinas virtuales. Microsoft ha documentado una campaña en la que cuentas de Azure comprometidas fueron utilizadas para aprovisionar máquinas virtuales de corta duración como infraestructura de ataque desechable. Dado que el tráfico provenía de direcciones IP legítimas asociadas a Azure, las alertas fueron descartadas como falsos positivos.
El desafío de los equipos de seguridad: recursos limitados y herramientas complejas
Es probable que los equipos de TI y seguridad de muchas organizaciones sean pequeños y manejen la seguridad junto con otras responsabilidades de TI. Esto tiene mucho que ver con el tipo de herramientas que funcionan a esta escala. Los productos de seguridad que dependen de un conocimiento profundo específico de la plataforma, procedimientos de implementación complejos y múltiples herramientas para gestionar diversas partes de la infraestructura de TI pueden no ser adecuados. Incluso podrían pasar por alto la parte del problema de la proliferación que más importa.
Para complicar aún más las cosas, ¿qué sucede cuando un incidente involucra abuso de identidad? Un atacante en una máquina virtual rogue puede no estar haciendo nada que parezca sospechoso desde dentro de la propia VM cuando utiliza su identidad para acceder a recursos en la nube o locales. Detectar la anomalía requiere conectar lo que sucede en la máquina virtual con lo que la identidad de esa VM está haciendo en todo el entorno más amplio. Ese tipo de correlación depende de la integración con soluciones de identidad como Entra ID y Active Directory.
También está la cuestión de la velocidad. Cuando una carga de trabajo en la nube comprometida puede alcanzar recursos locales a través de una cadena de identidades federadas, la ventana entre el compromiso inicial y el daño grave puede ser corta. Aislar (auto) una máquina virtual antes de que comience el movimiento lateral debe ocurrir a cualquier hora. Es uno de los escenarios donde la correlación impulsada por IA y la detección en tiempo de ejecución demuestran su valor: nadie puede vigilar cada carga de trabajo las 24 horas del día y responder con la suficiente rapidez.
Costos, multas y cumplimiento normativo: el precio de la ceguera
Las incursiones exitosas cuestan caro a las empresas. Según una encuesta reciente de Hiscox, una de cada tres pymes reportó haber recibido multas sustanciales después de un ciberataque. Es también un recordatorio de que el incumplimiento normativo puede tener consecuencias financieras directas. Marcos regulatorios como NIST 800-53 y PCI DSS 4.0 son cada vez más específicos sobre la seguridad de las cargas de trabajo en la nube, y se espera que las empresas garanticen que las identidades asignadas a las cargas de trabajo en la nube estén correctamente definidas y monitoreadas de forma continua. Demostrar controles de acceso en los servidores que alojan datos sensibles ya no es suficiente cuando el riesgo reside en la capa de identidad.
El informe Cost of a Data Breach 2025 de IBM reveló que el 30% de las brechas afectaron datos dispersos en múltiples entornos, lo que demuestra los problemas que enfrentan las organizaciones para defender sus activos en diversos entornos. Una parte significativa del costo resultante se atribuye al tiempo transcurrido entre la infiltración y la detección, también conocido como dwell time. Las organizaciones que no pueden ver lo que sucede dentro de sus entornos tienden a descubrir las brechas a través de señales externas, como una queja de un cliente, momento en el que el atacante ya ha tenido semanas o meses de acceso.
Estrategias para recuperar el control: inventario, permisos y microsegmentación
Para empezar, toda organización necesita inventariar sus flotas de máquinas virtuales en todas las plataformas en la nube, revisar los permisos asociados a la identidad de cada máquina virtual y auditar su configuración en busca de aperturas innecesarias en las direcciones este-oeste y norte-sur. Como dice el refrán, las buenas cercas hacen buenos vecinos.
Para las organizaciones que ejecutan cargas de trabajo en entornos cloud y locales, la pregunta es si sus herramientas de seguridad pueden vigilar las máquinas virtuales con el mismo rigor que se aplica a los endpoints en los escritorios de los empleados y otras partes de su infraestructura. Solo entonces podrán ver el panorama completo y proteger sus datos en diversos entornos.
La lucha contra la proliferación de máquinas virtuales no es solo un problema técnico; es un imperativo estratégico. Las organizaciones que logren visibilidad total sobre sus máquinas virtuales, que implementen políticas de mínimo privilegio en las identidades de carga de trabajo y que automaticen la detección y respuesta ante comportamientos anómalos, estarán en una posición mucho más sólida para enfrentar las amenazas actuales. El 77% de las empresas que carece de esta visibilidad hoy tiene en sus manos la oportunidad de cerrar esa brecha antes de que un incidente se lo recuerde de la peor manera posible.
