Hace veinte años, casi hoy, Amazon Web Services (AWS) lanzado Servicio de almacenamiento simple (S3). Unos meses más tarde, el servicio Elastic Compute Cloud (EC2) de la empresa abierto para pruebas beta públicas antes de su lanzamiento oficial en 2008. Estos eventos desencadenaron la era del almacenamiento y la computación en la nube bajo demanda modernos que cambiaron la forma en que las organizaciones de todos los tamaños piensan sobre su infraestructura de TI.
Si avanzamos hasta el presente, será difícil encontrar muchas organizaciones que no hayan «levantado y trasladado» al menos parte de sus cargas de trabajo a la nube, o que no estén planeando hacerlo pronto. De hecho, algunos ahora se ejecutan completamente en la nube, mientras que muchos otros han combinado cargas de trabajo en la nube, a menudo en configuraciones de múltiples nubes, con recursos locales que no se retirarán pronto.
De todas las cosas que estas organizaciones tienen en común, una merece una mirada más cercana: la expansión descontrolada de las máquinas virtuales (VM), o el crecimiento descontrolado de máquinas virtuales que a menudo se dejan valer por sí mismas.
Un problema en expansión
Los proveedores de servicios de nube pública (CSP) hacen que el aprovisionamiento de nuevas máquinas virtuales sea sencillo por diseño; después de todo, esto es en parte lo que hace que su oferta sea tan atractiva. Como pueden atestiguar muchos administradores, una nueva instancia de VM se puede poner en funcionamiento en unos momentos, pero desmantelarlo rara vez adquiere la misma urgencia.
En muchas empresas, especialmente aquellas con configuraciones de múltiples nubes que involucran a AWS, Azure, GCP y/u otros CSP, esta expansión da como resultado una creciente acumulación de cargas de trabajo que existen fuera de las operaciones de seguridad. Los CSP brindan protecciones básicas, pero el trabajo continuo recae en el cliente. Las máquinas a menudo ni siquiera reciben actualizaciones del sistema operativo; peor aún, generalmente no están monitoreados y sujetos a políticas de acceso que no han cambiado desde el día en que alguien creó la instancia. Esto aumenta el riesgo de que una máquina virtual «se vuelva deshonesta» y permanezca fuera del radar, hasta que sea demasiado tarde.
La visibilidad de la nube como tal es un problema persistente, ya que sólo unos 23% de las organizaciones informan que tienen una visión completa de su huella en la nube. El crecimiento desenfrenado de activos, incluidas flotas de máquinas virtuales, es una gran parte del problema. Las rutas de ataque básicas (cubos de almacenamiento mal configurados y API expuestas) dominan las revelaciones de violaciones, en parte porque producen señales de cara al público. Mientras tanto, el abuso de VM ocurre de manera más sutil y dentro de un entorno; una identidad administrada que consulta el almacenamiento en la nube no activará las mismas alarmas que una dirección IP externa que intenta iniciar sesión.
Un reciente informe por Cloud Security Alliance (CSA) clasificó la mala configuración y el control de cambios inadecuado como la principal amenaza para los recursos de la nube, seguidos por las debilidades de la gestión de identidades y accesos (IAM). Esto sigue la naturaleza basada en la identidad de las cargas de trabajo en la nube, donde tanto la propia máquina virtual como a qué puede acceder merecen un escrutinio. Según Microsoft Informe sobre el estado de la seguridad multinube 2024las 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 incrementan los recursos informáticos.
La realidad es bastante mundana: digamos, un ingeniero de aprendizaje automático proporciona una máquina virtual para tareas de procesamiento de datos. A la máquina virtual se le otorga una identidad, pero dado que determinar el alcance de sus permisos de acuerdo con el principio de privilegio mínimo llevaría demasiado tiempo, recibe un amplio acceso de lectura/escritura al almacenamiento de datos y otros recursos. Los proyectos concluyen, pero las máquinas virtuales con permisos excesivos se «dejan a su suerte».
Dejado para pudrirse
Sin embargo, una máquina virtual abandonada puede hacer más que «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, los malos actores pueden explotar las instancias olvidadas para ganar un punto de apoyo inicial. Como las máquinas virtuales en 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 máquina virtual puede sondear instancias adyacentes, llegar a bases de datos internas o puntos finales de almacenamiento y explotar cualquier permiso que se le haya otorgado. Con demasiada frecuencia, la microsegmentación de la red resulta ser una tarea demasiado desalentadora.
En entornos híbridos que involucran identidades híbridaslas cosas pueden complicarse aún más. Por ejemplo, cuando Active Directory local se sincroniza con Entra ID, un VM comprometida en Azure que está unido a un inquilino de Entra ID puede acceder a recursos compartidos de archivos, bases de datos, aplicaciones u otros recursos que forman parte de la infraestructura local central de la organización.
No es difícil encontrar ejemplos de ataques reales que involucren máquinas virtuales. En una campañalos atacantes se movieron entre instancias de AWS EC2 a través del Protocolo de escritorio remoto (RDP) interno, organizaron cientos de gigabytes de datos exfiltrados en múltiples máquinas virtuales y desataron ransomware dentro de la red de la nube. El monitoreo detectó la actividad, pero la respuesta automática no se configuró adecuadamente para detenerla y la implementación del ransomware continuó.
Otros atacantes están explotando la facilidad con la que se pueden activar las máquinas virtuales. Microsoft tiene documentado una campaña en la que las cuentas de Azure comprometidas se utilizaron indebidamente para aprovisionar máquinas virtuales de corta duración como infraestructura de ataque desechable. Dado que el tráfico procedía de direcciones IP legítimas asociadas a Azure, las alertas se descartaron como falsos positivos.
Luchando contra el despliegue y la decadencia.
Lo más probable es que sus equipos de seguridad y TI sean pequeños y manejen la seguridad junto con otras responsabilidades de TI, lo que tiene mucho que ver con el tipo de herramientas que funcionan a esta escala. Los productos de seguridad que se basan en una profunda experiencia específica de la plataforma, procedimientos de implementación complejos y una serie de herramientas para gestionar diversas partes de la infraestructura de TI pueden no ser la solución. Es posible que incluso pasen por alto la parte del problema de la expansión urbana que más importa.
Para enturbiar aún más las aguas, ¿qué sucede cuando un incidente involucra abuso de identidad? Es posible que un atacante en una máquina virtual no autorizada no esté haciendo nada que parezca sospechoso solo desde el interior de la máquina virtual cuando usa su identidad para acceder a recursos locales o en la nube. Detectar la anomalía requiere conectar lo que sucede en la propia máquina virtual con lo que hace la identidad de la máquina virtual en todo el entorno. 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 llegar a recursos locales a través de una cadena de identidad federada, la ventana entre el compromiso inicial y el daño grave puede ser corta. El (auto)aislamiento de una máquina virtual antes de que comience el movimiento lateral debe realizarse en cualquier hora. Es uno de los escenarios en los que la correlación impulsada por la IA y la detección del tiempo de ejecución se mantienen: nadie puede vigilar cada carga de trabajo las 24 horas del día y responder con la suficiente rapidez.
Las incursiones exitosas cuestan muy caras a las empresas. Según un encuesta recienteuna de cada tres pymes informó haber recibido multas importantes tras un ciberataque. También es un recordatorio de que el incumplimiento puede tener consecuencias financieras directas. Los 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 cada vez más que las empresas garanticen que las identidades asignadas a las cargas de trabajo en la nube tengan un alcance adecuado y se supervisen continuamente. Demostrar controles de acceso en los servidores que alojan datos confidenciales no es suficiente cuando el riesgo reside en la capa de identidad.
Mientras tanto, El coste de IBM por una filtración de datos en 2025 El informe encontró que el 30 por ciento de las infracciones afectaron a datos esparcidos en múltiples entornos, lo que muestra los problemas que enfrentan las organizaciones cuando se trata de defender sus activos en diversos entornos. 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 sucede dentro de sus entornos tienden a descubrir violaciones a través de señales «externas», como una queja de un cliente, momento en el cual el atacante ya ha tenido acceso durante semanas o meses.
Pensamientos de despedida
Las máquinas virtuales son uno de los recursos de nube modernos más antiguos y más frecuentemente implementados. La expansión descontrolada de las máquinas virtuales se acumula silenciosamente y, a menudo, se revela después de que algo sale mal. Las cargas de trabajo desprotegidas 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 empezar, cada organización necesita hacer un inventario de 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 sus configuraciones para detectar una apertura innecesaria «este-oeste» y «norte-sur». Las buenas vallas hacen buenos vecinos, como dice el refrán.
Para las organizaciones que ejecutan cargas de trabajo en entornos locales y en la nube, la pregunta es si sus herramientas de seguridad pueden vigilar las máquinas virtuales con el mismo rigor que se aplica a los puntos finales en los escritorios de los empleados y otras partes de su infraestructura. Sólo entonces podrán ver el panorama completo y proteger sus datos en diversos entornos.
Acerca del autor
