Hace casi veinte años, casi exactamente, Amazon Web Services (AWS) lanzó Simple Storage Service (S3). Unos meses más tarde, el servicio Elastic Compute Cloud (EC2) se abrió a pruebas beta públicas antes de su lanzamiento oficial en 2008. Estos acontecimientos impulsaron la era moderna del almacenamiento y la computación en la nube on‑demand, que cambió la forma en que organizaciones de todos los tamaños piensan sobre su infraestructura de TI.
Si avanzamos al presente, es difícil encontrar organizaciones que no hayan hecho rehosting de al menos parte de sus cargas de trabajo hacia la nube, o que no estén planeando hacerlo pronto. De hecho, algunas ya operan completamente en la nube, mientras que muchas otras han combinado cargas de trabajo en la nube —a menudo en configuraciones multicloud— con recursos on premise que no se retirarán pronto.
De todas las cosas que estas organizaciones tienen en común, una merece una mirada más detallada: la proliferación de máquinas virtuales descontrolada que a menudo quedan “a su suerte”.
Un problema en expansión
Los proveedores de Cloud Services (CSP) hacen que el aprovisionamiento de nuevas máquinas virtuales sea extremadamente simple por diseño; al fin y al cabo, eso es parte de lo que hace atractiva su oferta. Como pueden confirmar muchos administradores, una nueva máquina virtual puede levantarse en cuestión de momentos, pero su desmantelamiento rara vez recibe la misma urgencia.
En muchas empresas —especialmente aquellas con configuraciones multi-cloud que involucran AWS, Azure, GCP y/u otros CSP— esta proliferación genera un creciente inventario de cargas de trabajo que existen fuera de las operaciones de seguridad. Los CSP brindan protecciones base, pero el trabajo continuo recae en el cliente. A menudo las máquinas ni siquiera reciben actualizaciones del sistema operativo; peor aún, generalmente no se monitorean 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 vuelva rebelde” sin ser detectada, hasta que sea demasiado tarde.
La visibilidad en la nube sigue siendo un problema persistente: solo alrededor del 23% de las organizaciones afirman tener una visión completa de su huella cloud. El crecimiento descontrolado de activos es una parte importante del problema. Los vectores clásicos —buckets de almacenamiento mal configurados y APIs expuestas— dominan los reportes de brechas, en parte porque generan señales públicas. Mientras tanto, el abuso de máquinas virtuales ocurre de forma más sutil, dentro del entorno; una identidad administrada consultando un bucket de almacenamiento la nube no disparará las mismas alarmas que una IP externa intentando autenticarse.
Un reporte reciente de la Cloud Security Alliance (CSA) clasificó la mala configuración y el control inadecuado de cambios como la principal amenaza para los recursos en la nube, seguidos por las debilidades en Identity and Access Management (IAM). Esto coincide con la naturaleza identity‑driven de las cargas de trabajo en la nube, donde tanto la propia virtual machine (VM) como los recursos a los que puede acceder requieren un escrutinio detallado. Según el reporte Microsoft 2024 State of Multicloud Security, las workload identities asignadas a VMs y otros recursos no humanos superan ampliamente a las identidades humanas, y la brecha continúa ampliándose a medida que las organizaciones levantan más recursos de cómputo.
Un informe reciente de la Cloud Security Alliance (CSA) clasificó la mala configuración y el control inadecuado de cambios como la principal amenaza para los recursos en la nube, seguido por las debilidades en la gestión de identidades y accesos. Esto es coherente con la naturaleza basada en identidad de las cargas de trabajo en la nube, donde tanto la propia máquina virtual como aquello a lo que puede acceder requieren un escrutinio detallado. Según el informe Microsoft 2024 State of Multicloud Security, las identidades de cargas de trabajo asignadas a máquinas virtuales y otros recursos no humanos superan ampliamente a las identidades humanas, y la brecha continúa ampliándose a medida que las organizaciones ponen en marcha más recursos de cómputo.
La realidad es bastante mundana: por ejemplo, un ingeniero de machine learning aprovisiona una máquina virtual para tareas de procesamiento de datos. A la máquina virtual se le asigna una identidad, pero como definir sus permisos siguiendo el principio de mínimo privilegio llevaría demasiado tiempo, recibe un acceso amplio de lectura y 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”.
Abandonadas a su suerte
Una máquina virtual abandonada puede hacer algo más que simplemente acumular polvo. Dado que cada máquina virtual está asociada a algún tipo de identidad que determina a qué puede acceder la carga de trabajo dentro del 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 o red virtual suelen poder comunicarse entre sí en la dirección este‑oeste sin demasiadas restricciones, una máquina virtual puede explorar instancias vecinas, llegar a bases de datos internas o a puntos finales de almacenamiento y aprovechar los permisos que se le hayan otorgado. Con demasiada frecuencia, la microsegmentación de la red resulta ser una tarea demasiado compleja.
En entornos híbridos que involucran identidades híbridas, las cosas pueden volverse aún más complicadas. Por ejemplo, cuando Active Directory local se sincroniza con Entra ID, una máquina virtual comprometida en Azure que está unida a una entidad de Entra ID puede llegar a recursos compartidos de archivos, bases de datos, aplicaciones u otros recursos que forman parte de la infraestructura central local de la organización.
Los ejemplos de ataques reales que involucran máquinas virtuales no son difíciles de encontrar. En una campaña, los atacantes se desplazaron entre instancias EC2 de AWS mediante el Protocolo de Escritorio Remoto (RDP) interno, organizaron cientos de gigabytes de datos exfiltrados distribuidos en varias máquinas virtuales y liberaron ransomware dentro de la red en la nube. El monitoreo detectó la actividad, pero la respuesta automatizada no estaba configurada adecuadamente para detenerla y el despliegue del ransomware avanzó de todos modos.
Otros atacantes están aprovechando la facilidad con la que se pueden poner en marcha las máquinas virtuales. Microsoft ha documentado una campaña en la que cuentas de Azure comprometidas se utilizaron indebidamente para aprovisionar máquinas virtuales de corta duración como infraestructura desechable para ataques. Como el tráfico provenía de direcciones IP legítimas asociadas a Azure, las alertas fueron descartadas como falsos positivos.
Luchando contra el deploy and decay
Lo más probable es que sus equipos de TI y de seguridad sean pequeños y gestionen la seguridad junto con otras responsabilidades de TI, lo que influye directamente en qué tipo de herramientas funcionan a esta escala. Los productos de seguridad que dependen de conocimientos profundos específicos de cada plataforma, procedimientos de despliegue complejos y múltiples herramientas para administrar distintas partes de la infraestructura de TI pueden no ser adecuados. Incluso pueden pasar por alto la parte del problema de proliferación que más importa.
Para complicar aún más las cosas, ¿qué ocurre cuando un incidente implica abuso de identidad? Un atacante en una máquina virtual fraudulenta puede no estar haciendo nada que parezca sospechoso desde la propia máquina virtual cuando utiliza su identidad para acceder a recursos en la nube o locales. Detectar la anomalía requiere conectar lo que está ocurriendo dentro de la máquina virtual con lo que la identidad de esa máquina virtual está haciendo en 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 federated identity chain, la ventana entre el compromiso inicial y un daño serio puede ser muy corta. Aislar una máquina virtual de forma automática antes de que comience el movimiento lateral debe poder ocurrir en cualquier momento. Es uno de los escenarios en los que la correlación basada en inteligencia artificial y la detección en tiempo de ejecución demuestran su utilidad: nadie puede vigilar cada carga de trabajo las 24 horas del día ni responder con suficiente rapidez.
Las intrusiones exitosas resultan muy costosas para las empresas. Según una encuesta reciente, una de cada tres pequeñas y medianas empresas informó haber recibido multas significativas después de un ciberataque. Esto también recuerda que el incumplimiento puede tener consecuencias financieras directas. Marcos regulatorios como NIST 800-53 y PCI DSS 4.0 son cada vez más específicos en cuanto a la seguridad de las cargas de trabajo en la nube, y se espera cada vez más que las compañías garanticen que las identidades asignadas a las cargas de trabajo en la nube estén correctamente definidas y sean supervisadas de forma continua. Demostrar controles de acceso en los servidores que alojan datos sensibles no es suficiente cuando el riesgo se encuentra en la capa de identidad.
Mientras tanto, el informe IBM Cost of a Data Breach 2025 reveló que el 30 por ciento de las brechas afectó datos dispersos en múltiples entornos, lo que evidencia los problemas que enfrentan las organizaciones al defender sus activos en distintos escenarios. Una parte significativa del costo resultante se debe al tiempo transcurrido entre la infiltración y la detección, también conocido como tiempo de permanencia. Las organizaciones que no pueden ver lo que ocurre dentro de sus entornos suelen descubrir las brechas a través de señales “externas”, como una queja de un cliente, momento en el cual el atacante ya ha tenido semanas o incluso meses de acceso.
Reflexiones finales
Las máquinas virtuales son uno de los recursos más antiguos y más frecuentemente desplegados en la nube moderna. La proliferación de máquinas virtuales se acumula silenciosamente y a menudo se manifiesta cuando algo ya ha salido mal. Las cargas de trabajo no protegidas transportan identidades y se comunican entre sí y con recursos locales en patrones de tráfico que no todos los controles de seguridad pueden observar y detectar.
Para comenzar, toda organización necesita inventariar sus flotas de máquinas virtuales en todas las plataformas de nube, revisar los permisos asociados a la identidad de cada máquina virtual y auditar su configuración para identificar aperturas innecesarias en el tráfico “este‑oeste” y “norte‑sur”. “Buenas cercas hacen buenos vecinos”, como dice el refrán.
Para las organizaciones que ejecutan cargas de trabajo tanto en la nube como en entornos locales, la pregunta es si sus herramientas de seguridad pueden vigilar las máquinas virtuales con el mismo rigor que aplican a los equipos de los empleados y a otras partes de su infraestructura. Solo así podrán tener una visión completa y proteger sus datos a través de los distintos entornos.
