Máquinas virtuales, prácticamente en todas partes, pero no todas protegidas

Hace casi exactamente veinte años, Amazon Web Services (AWS) fue comenzó Servicio de almacenamiento sencillo (S3). El servicio Elastic Compute Cloud (EC2) de la empresa siguió unos meses más tarde. abierto para pruebas beta públicas antes de su lanzamiento oficial en 2008. Estos eventos marcaron el comienzo de la era de la informática y el almacenamiento en la nube bajo demanda modernos, cambiando la forma en que las empresas de todos los tamaños piensan sobre su infraestructura de TI.

Si miramos hacia el presente, será difícil encontrar muchas empresas que no hayan trasladado al menos algunas de sus cargas de trabajo a la nube o que no planeen hacerlo pronto. De hecho, algunos ahora se ejecutan completamente en la nube, mientras que muchos otros tienen cargas de trabajo en la nube, a menudo en configuraciones de múltiples nubes, junto con recursos locales que no serán retirados de servicio en el corto plazo.

Entre todas las similitudes entre estas organizaciones, vale la pena observar más de cerca una cosa: la proliferación de máquinas virtuales (VM), o el crecimiento descontrolado de máquinas virtuales que a menudo se dejan valer por sí mismas.

Un problema de gran alcance

Los proveedores de servicios de nube pública (CSP) permiten una implementación perfecta de nuevas máquinas virtuales. Después de todo, eso es exactamente lo que hace que su oferta sea tan atractiva. Muchos administradores pueden dar fe de que se puede poner en funcionamiento una nueva instancia de VM en cuestión de momentos, pero su desmantelamiento rara vez se lleva a cabo con la misma urgencia.

En muchas organizaciones, particularmente aquellas con configuraciones de múltiples nubes que utilizan AWS, Azure, GCP y/u otros CSP, esta proliferación da como resultado un conjunto creciente de cargas de trabajo que existen fuera de las operaciones de seguridad. Si bien los CSP brindan protección básica, 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 están 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 siga pasando desapercibida, hasta que sea demasiado tarde.

La visibilidad de la nube como tal es un problema constante, ya que sólo unos 23% de las organizaciones informan que tienen una visión completa de su huella en la nube. Una gran parte del problema es el crecimiento descontrolado de los activos, incluidas las flotas de máquinas virtuales. Las rutas de ataque más comunes (cubos de almacenamiento mal configurados y API expuestas) dominan las revelaciones de infracciones, en parte porque generan señales disponibles públicamente. Ahora, 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 generará las mismas alarmas que una dirección IP externa que intente iniciar sesión.

uno actual informe La Cloud Security Alliance (CSA) clasificó la configuración incorrecta y el control de cambios inadecuado como las principales amenazas a los recursos de la nube, seguidas de las vulnerabilidades de gestión de identidad y acceso (IAM). Esto es coherente con 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 requieren 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 con creces a las identidades humanas, y la brecha se amplía a medida que las empresas implementan más recursos informáticos.

La realidad es bastante mundana: digamos que un ingeniero de aprendizaje automático implementa una máquina virtual para tareas de procesamiento de datos. A la máquina virtual se le otorga una identidad, pero debido a que establecer sus permisos utilizando el principio de privilegio mínimo llevaría demasiado tiempo, se le otorga un amplio acceso de lectura/escritura al almacenamiento de datos y otros recursos. Los proyectos se completarán, pero las máquinas virtuales con privilegios demasiado altos quedarán “dejadas a su suerte”.

Dejado para descomponerse

Sin embargo, una máquina virtual abandonada puede hacer más que simplemente «acumular polvo». Debido a que cada VM está vinculada a algún tipo de identidad que determina a qué puede acceder la carga de trabajo en todo el entorno, actores maliciosos pueden explotar las instancias olvidadas para ganar un punto de apoyo inicial. Debido a que 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 explorar instancias vecinas, 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 con Identidades híbridaspuede volverse aún más complicado. Por ejemplo, si el Active Directory local está sincronizado con el Entra ID, un VM comprometida en Azure conectado 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 utilizan máquinas virtuales. En una campañaLos atacantes se movieron entre instancias de AWS EC2 utilizando el protocolo de escritorio remoto (RDP) interno, implementando cientos de gigabytes de datos extraídos en múltiples máquinas virtuales y liberando ransomware dentro de la red de la nube. Aunque el monitoreo detectó la actividad, la respuesta automatizada no se configuró adecuadamente para detenerla y la implementación del ransomware continuó.

Otros atacantes aprovechan la sencilla capacidad de activar máquinas virtuales. Microsoft tiene documentado una campaña que aprovechó las cuentas de Azure comprometidas para implementar máquinas virtuales de corta duración como infraestructura de ataque desechable. Debido a que el tráfico provenía de direcciones IP legítimas vinculadas a Azure, las alertas se descartaron como falsos positivos.

Luchando contra el desarrollo y la decadencia

Lo más probable es que sus equipos de TI y seguridad sean pequeños y manejen la seguridad junto con otras tareas 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 amplia experiencia en plataformas específicas, procedimientos de implementación complejos y un conjunto de herramientas para administrar diferentes partes de la infraestructura de TI pueden no ser la solución adecuada. Es posible que incluso estén pasando por alto la parte del problema de expansión que más importa.

¿Qué sucede si un incidente involucra suplantación de identidad? Un atacante en una máquina virtual fraudulenta no puede hacer nada que parezca sospechoso desde el interior de la máquina virtual si usa su identidad para acceder a recursos locales o en la nube. Para detectar la anomalía, las operaciones en la propia VM deben estar relacionadas con las acciones de la identidad de la VM en todo el entorno. Este 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. Si una carga de trabajo en la nube comprometida puede llegar a los recursos locales a través de una cadena de identidad federada, el tiempo entre el compromiso inicial y el daño grave puede ser corto. El aislamiento (automático) de una VM antes del inicio del movimiento lateral debe realizarse cada 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 ganan la vida: nadie puede monitorear cada carga de trabajo las 24 horas del día, los 7 días de la semana y responder con la suficiente rapidez.

Los ataques exitosos cuestan caro a las empresas. Según un encuesta actualUna de cada tres pymes afirmó haber recibido multas elevadas 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 se están volviendo más específicos con respecto a la seguridad de las cargas de trabajo en la nube, y se espera cada vez más que las organizaciones garanticen que las identidades asignadas a las cargas de trabajo en la nube tengan el alcance adecuado y se supervisen continuamente. Probar controles de acceso a los servidores que alojan datos confidenciales no es suficiente cuando el riesgo está en el nivel de identidad.

Mientras tanto, El coste para IBM de una filtración de datos en 2025 El informe encontró que el 30 por ciento de las filtraciones involucraron datos dispersos en múltiples entornos, lo que muestra los problemas que enfrentan las organizaciones cuando se trata de proteger sus activos en diferentes entornos. Una parte importante de los costes resultantes 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 en sus entornos tienden a descubrir violaciones a través de señales «externas», como una queja de un cliente, a la que el atacante ya ha tenido acceso durante semanas o meses.

Pensamientos de despedida

Las máquinas virtuales se encuentran entre los recursos de nube modernos más antiguos y más ampliamente implementados. La proliferación de VM se acumula sigilosamente y, a menudo, se hace evidente después de que algo sale mal. Las cargas de trabajo desprotegidas portan 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, todos La organización necesita hacer un balance distribuye sus flotas de VM en todas las plataformas en la nube, verifica los permisos asociados con la identidad de cada VM y verifica su configuración para detectar una apertura innecesaria «este-oeste» y «norte-sur». Como dice el refrán, buenas vallas hacen buenos vecinos.

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 nivel de precisión que lo hacen en los puntos finales de los escritorios de los empleados y otras partes de su infraestructura. Sólo entonces podrán ver el panorama más amplio y proteger sus datos en diferentes entornos.