La segmentación en cloud no se rompe porque alguien “abra un puerto” sin más. Se rompe cuando se encadenan decisiones razonables bajo presión (entrega rápida, interconexión entre equipos, reducción de costes) y el resultado final permite movimiento lateral entre sistemas que, en teoría, estaban aislados. En incidentes reales, el atacante rara vez entra por donde esperas; entra por un punto expuesto y se desplaza por rutas internas que nadie revisa de forma holística.
Cuando hablamos de VPC/VNet, security groups/NSG, tablas de rutas, peering y separación entre entornos, el problema típico no es desconocimiento: es falta de validación cruzada. Una regla de SG puede ser “correcta” en aislamiento, pero combinada con una ruta 0.0.0.0/0, un peering amplio o un firewall sin inspección, termina habilitando tráfico que nunca se pretendió.
Qué salió mal: el atacante no necesitó romper la segmentación, solo aprovecharla
Un patrón que se repite: un servicio “de apoyo” en un entorno menos crítico (por ejemplo, una VM de utilidades, un runner de CI, una instancia para pruebas) queda accesible desde Internet por comodidad. El acceso inicial puede ser una credencial filtrada o un panel expuesto. A partir de ahí, el atacante busca conectividad interna: no necesita explotar 0-days si encuentra caminos de red que ya existen.
En cloud, la segmentación efectiva depende de tres capas alineadas: rutas (qué es alcanzable), filtros (SG/NSG/NACL) y topología (peering/transit/hubs). Cuando una de esas capas es demasiado amplia, el atacante convierte un acceso “local” en un pivote. En empresa se ve como “ruido” al principio: conexiones fallidas, escaneos internos, y luego accesos exitosos a servicios que estaban pensados solo para consumo interno.
La consecuencia operativa no suele ser inmediata. Lo crítico es que, una vez dentro, el atacante se mueve hacia donde hay datos o control: bases de datos internas, APIs de administración, saltos hacia entornos de preproducción que comparten credenciales, o incluso hacia producción si existe conectividad “por conveniencia”. La segmentación mal diseñada no solo amplía el blast radius: reduce drásticamente el tiempo que tiene el equipo para detectar el movimiento lateral.
Rutas y peering: el atajo corporativo que crea autopistas laterales
El error más caro que he visto: tratar el peering (VPC Peering/VNet Peering) como si fuese “solo una conexión” y no una ampliación del dominio de alcance. Si dos redes se emparejan y sus tablas de rutas permiten prefijos amplios (por ejemplo, toda la red corporativa o todo el rango de otro entorno), la segmentación queda subordinada a “que los SG/NSG lo paren”. En incidentes, eso se traduce en que cualquier fallo puntual de reglas se convierte en conectividad transversal.
Otro clásico: la red tipo hub-and-spoke (con Transit Gateway/Virtual WAN o appliances) se despliega para centralizar, pero se activa el tránsito entre spokes sin un diseño explícito de “quién puede hablar con quién”. El resultado es un efecto secundario: un entorno de desarrollo termina pudiendo iniciar conexiones hacia servicios de producción a través del hub, aunque nadie lo haya pedido formalmente.
- Peering entre entornos por “integración rápida”: se habilita para que una app en dev consuma un servicio en shared-services, y meses después ese mismo peering permite explorar rangos internos y llegar a pre/producción si hay rutas heredadas.
- Tablas de rutas con prefijos demasiado grandes: se anuncia 10.0.0.0/8 “para no estar actualizando rutas”, lo que rompe cualquier intento de microsegmentación y complica auditorías (“todo llega a todo, salvo excepciones”).
- Transitividades implícitas: en topologías con hubs, el equipo asume que el tráfico no atraviesa spokes; en la práctica, una configuración de propagación de rutas o una regla en el appliance habilita tránsito no deseado.
Cada uno de estos puntos suele nacer de una presión real: reducir time-to-market, evitar cambios recurrentes, simplificar operación. Pero la consecuencia es predecible: cuando el atacante aterriza en el spoke “más débil”, hereda el mapa de carreteras hacia activos críticos.
Security Groups/NSG: reglas “temporales”, referencias cruzadas y el espejismo del perímetro
SG y NSG son potentes, pero también fáciles de degradar con el tiempo. La degradación típica no es una regla abiertamente mala, sino un conjunto de excepciones acumuladas: “abrimos esto para una prueba”, “permitimos desde cualquier lugar porque el origen cambia”, “referenciamos el SG de otro equipo para que funcione”. Tras varias iteraciones, el grafo de permisos deja de representar intención y pasa a representar historia.
Un punto especialmente peligroso son las referencias cruzadas (por ejemplo, SG-to-SG) que atraviesan límites organizativos o de entorno. En teoría se usan para acotar (“solo este grupo puede hablar con este servicio”), pero en empresas con equipos autónomos se convierten en dependencias opacas: alguien amplía el SG origen para resolver un problema y, sin darse cuenta, amplía el acceso a varios servicios aguas abajo.
- Reglas de entrada amplias para administración: permitir RDP/SSH desde rangos genéricos (o peores, 0.0.0.0/0) “porque la VPN falla” crea un punto de acceso directo a la red interna. Aunque el host esté “en una subnet privada”, el camino puede existir vía NAT, bastion mal controlado o IP pública accidental.
- Salida sin restricciones: egress abierto total en workloads de baja criticidad facilita exfiltración y C2. Además, permite que un atacante alcance servicios internos por rutas existentes aunque el inbound esté más cuidado.
- Reglas duplicadas entre SG/NSG y NACL/UDR: cuando se intenta “compensar” con otra capa sin un modelo claro, se pierde trazabilidad. En incidentes, esto se traduce en horas perdidas: nadie sabe qué capa está permitiendo el paso.
El impacto real: un atacante con un pie dentro puede usar herramientas comunes de reconocimiento (escaneo de puertos, enumeración de servicios, probes a metadata endpoints) y, si la conectividad lo permite, encontrar superficies internas que no estaban monitorizadas como si fueran “externas”. La segmentación fallida convierte lo “interno” en un perímetro inexistente.
Exposición accidental entre entornos: cuando dev y prod comparten más de lo que crees
La separación entre entornos suele romperse por caminos no obvios: un peering “temporal”, una excepción de ruta para un proveedor, una subnet compartida para herramientas, o un servicio común (logging, artefactos, CI/CD) desplegado sin límites estrictos. En cloud, el aislamiento no es una propiedad emergente: hay que diseñarlo explícitamente y validarlo continuamente.
Un caso típico en corporaciones: shared-services se convierte en “tierra de nadie”. Por querer centralizar (DNS interno, repositorios, scanners, proxies, AD/LDAP), se conecta a todo. Si shared-services queda comprometido (por ejemplo, una VM de utilidades con parcheo irregular), el atacante tiene un trampolín privilegiado: credenciales en memoria, tokens de acceso, y conectividad hacia muchos spokes.
Hay también un error de diseño recurrente: asumir que “dev no importa” porque no contiene datos sensibles. En la práctica, dev suele contener secretos (tokens, claves, pipelines con permisos), y además tiene acceso a repositorios, imágenes y despliegues. Si dev puede iniciar conexiones hacia prod (aunque sea a “un puerto concreto”), el atacante convierte una intrusión barata en un incidente mayor.
Cómo hacerlo en la práctica: valida el aislamiento con pruebas de conectividad y revisión de rutas, no solo leyendo reglas sueltas.
- Mapea alcance real por rutas: revisa tablas de rutas/UDR de cada subnet y verifica qué prefijos se anuncian por peering/hub. En AWS, comprueba rutas efectivas por subnet y la propagación en Transit Gateway si aplica. En Azure, revisa “Effective routes” por NIC/subnet para detectar UDR heredadas o propagación de BGP.
- Revisa reglas efectivas, no declarativas: identifica SG/NSG que se referencian entre sí y documenta el grafo. La pregunta operativa no es “¿qué permite este SG?”, sino “¿qué fuentes reales pueden alcanzar este servicio a través de rutas existentes?”.
- Ejecuta pruebas desde dentro: desde un host controlado en dev, intenta alcanzar endpoints internos de pre/prod (puertos de administración, bases de datos, APIs internas). Si hay conectividad, registra el camino (ruta + regla) que lo habilita y decide si es intencional o residual.
Estas validaciones suelen destapar “conectividad fantasma”: accesos que nadie recuerda haber pedido. Corregirlos reduce significativamente el riesgo, incluso sin cambiar nada en la capa de aplicación.
Recomendaciones para entornos corporativos
Los fallos de segmentación en cloud que dejan pasar a un atacante suelen ser combinaciones: rutas amplias más peering sin límites, más reglas SG/NSG degradadas con el tiempo. El atacante se beneficia de la conectividad ya existente y del hecho de que muchas organizaciones revisan componentes aislados, no el sistema completo.
Si quieres reducir movimiento lateral, céntrate en validar alcance real: qué redes son alcanzables, por qué camino (rutas/peering/hubs) y qué reglas efectivas lo permiten. Mantener aislamiento entre entornos no es solo “tener VPC/VNet distintas”: es evitar que la topología y las rutas conviertan esa separación en una etiqueta.
Por último, disciplina operativa: cada excepción “temporal” en SG/NSG o rutas debe tener caducidad y dueño. Sin esa higiene, la segmentación se convierte en deuda técnica de seguridad, y esa deuda es exactamente lo que un atacante explota para moverse sin necesidad de técnicas sofisticadas.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.