Tema 5
La red cloud define qué recursos pueden comunicarse, qué servicios quedan expuestos y cómo se conectan aplicaciones, usuarios, sedes y servicios administrados. Diseñarla bien reduce superficie de ataque y facilita contención.
Las redes cloud se crean por software, pero siguen cumpliendo una función crítica: controlar el flujo de comunicación entre recursos. Una mala regla de red puede exponer bases de datos, consolas administrativas, APIs internas o servicios que nunca debieron estar disponibles desde internet.
En cloud, los conceptos clásicos de red se combinan con componentes propios de cada proveedor: VPC o VNet, subredes, tablas de rutas, gateways, security groups, firewalls administrados, endpoints privados, balanceadores y servicios de conectividad híbrida.
El objetivo no es construir redes complejas, sino redes entendibles, segmentadas y verificables, donde cada ruta y exposición tenga una razón clara.
Una VPC, VNet o red virtual es un espacio lógico aislado donde se despliegan recursos cloud. Define rangos IP, subredes, rutas, conectividad y controles de tráfico. Es la base de la segmentación de red en cloud.
Una red virtual bien diseñada debe considerar:
Las subredes separan recursos según exposición y función. La distinción más común es entre subred pública y privada, pero en arquitecturas maduras también aparecen subredes de datos, integración, administración, seguridad y egreso.
| Tipo de subred | Uso típico | Control clave |
|---|---|---|
| Pública | Balanceadores, gateways o servicios que reciben tráfico externo | Exponer solo componentes necesarios y usar filtrado adicional |
| Privada | Aplicaciones internas, servicios backend y procesamiento | Sin ruta directa entrante desde internet |
| Datos | Bases de datos, colas, caches y almacenamiento interno | Acceso solo desde aplicaciones autorizadas |
| Administración | Bastion, herramientas de operación, jump hosts o endpoints de gestión | Acceso restringido, MFA, logging y sesiones auditadas |
| Egreso | Salida controlada hacia internet o terceros | NAT, proxy, firewall e inspección de tráfico saliente |
Las tablas de rutas determinan por dónde viaja el tráfico. Una subred puede tener una ruta hacia internet, hacia otra red, hacia un gateway NAT, hacia un firewall central o hacia un enlace privado.
Riesgos habituales:
Las rutas deben documentarse y revisarse igual que las reglas de firewall, porque una ruta incorrecta puede convertir un recurso interno en alcanzable desde lugares no deseados.
Los security groups, network security groups o listas de control permiten filtrar tráfico hacia recursos o subredes. Su granularidad varía según el proveedor, pero el principio es el mismo: permitir solo comunicaciones necesarias.
| Regla | Riesgo | Mejor enfoque |
|---|---|---|
SSH/RDP desde 0.0.0.0/0 |
Fuerza bruta y acceso administrativo expuesto | VPN, bastion, SSO, JIT y origen restringido |
| Base de datos abierta a toda la VPC | Movimiento lateral desde cualquier workload | Permitir solo subredes o identidades de aplicación autorizadas |
| Salida irrestricta a internet | Exfiltración o descarga de payloads | Egreso por proxy, firewall o destinos permitidos |
| Reglas sin descripción | Dificultad para auditar y limpiar permisos | Documentar propósito, dueño, ticket y fecha de revisión |
Los firewalls cloud permiten aplicar políticas de tráfico más avanzadas que una simple regla de puerto. Pueden inspeccionar tráfico, filtrar por dominio, aplicar listas de amenazas, registrar eventos y controlar egreso.
Se usan especialmente para:
Muchos proveedores permiten consumir servicios administrados mediante endpoints privados. Esto evita que el tráfico hacia almacenamiento, bases de datos, colas o APIs administradas salga por internet público.
Beneficios:
Los endpoints privados también deben gobernarse: pueden ampliar conectividad hacia servicios sensibles si no se controlan por cuenta, red, identidad y recurso.
A medida que crece el uso de cloud, aparecen muchas redes virtuales. Conectarlas sin criterio puede crear una malla difícil de entender y controlar. Para evitarlo se usan patrones como hub-and-spoke, transit gateways o redes compartidas.
| Patrón | Ventaja | Riesgo |
|---|---|---|
| Peering directo | Simple para pocas redes | Difícil de gobernar cuando crece |
| Hub-and-spoke | Centraliza conectividad y control | El hub requiere alta disponibilidad y cambios controlados |
| Transit gateway | Escala interconexión entre muchas redes | Rutas amplias pueden permitir movimiento lateral |
| Red compartida | Reduce duplicación y estandariza conectividad | Errores centrales impactan a múltiples equipos |
Muchas organizaciones conectan cloud con datacenters, oficinas o redes de terceros mediante VPN, enlaces dedicados o SD-WAN. Esta conectividad amplía la superficie de ataque: un incidente local puede alcanzar cloud y un incidente cloud puede impactar sistemas internos.
Controles recomendados:
Administrar recursos cloud no debería requerir exponer SSH, RDP o consolas internas directamente a internet. Existen alternativas más seguras y auditables.
El acceso administrativo debe ser excepcional, trazable y revisable. Si una regla administrativa queda abierta de forma permanente, se convierte en una puerta de entrada.
La segmentación limita el movimiento lateral. Si un workload se compromete, no debería poder alcanzar bases de datos, servicios internos, redes administrativas o ambientes productivos sin restricciones.
Se puede segmentar por:
Sin visibilidad, las reglas de red se vuelven difíciles de validar. Los logs de flujo, registros de firewall, eventos de DNS, métricas de balanceadores y alertas de exposición ayudan a detectar errores y actividad anómala.
Se recomienda monitorear:
La seguridad de redes cloud consiste en controlar rutas, exposición, segmentación y conectividad. Una red bien diseñada permite que las aplicaciones funcionen sin abrir caminos innecesarios hacia datos, administración o servicios internos.
En el próximo tema estudiaremos la protección de datos en cloud: cifrado, KMS, clasificación, backups y retención.