Network Security, VPC and Perimeter Defense
Resumen
En la nube, la identidad se convierte en el control de acceso principal, pero la red sigue siendo el lugar donde se materializan la exposición y el movimiento lateral. Una cuenta comprometida con permiso para abrir un puerto, un firewall demasiado permisivo o un backend con IP pública pueden convertir un error de configuración en un incidente. La seguridad de red en Google Cloud no consiste en comprar un perímetro físico: consiste en diseñar una VPC con subredes y rutas intencionadas, aplicar reglas de firewall con mínimo privilegio, controlar la salida a internet, proteger las aplicaciones expuestas con balanceo y mitigación y mantener visibilidad de quién habla con quién.\n\nEste tema cubre los componentes que un Digital Leader debe poder situar en una conversación de riesgo: la VPC global y sus subredes regionales, las reglas de firewall distribuidas y las políticas jerárquicas, Private Google Access, Private Service Connect, Cloud NAT, Cloud VPN y Cloud Interconnect, Shared VPC y VPC Network Peering, Cloud Armor, los balanceadores de carga, Identity-Aware Proxy y VPC Service Controls. La meta no es memorizar productos, sino entender qué control responde a cada amenaza y qué trade-off de coste, complejidad y disponibilidad introduce.\n\nTambién se trata la diferencia entre segmentar y aislar. Segmentar reduce el alcance de un compromiso; aislar impide que el dato salga del perímetro. Una organización puede tener una VPC bien segmentada y aun así permitir que un usuario copie un dataset a un proyecto personal si no controla el egreso y el acceso a los servicios. La defensa perimetral combina red, identidad y política de servicios, y el examen suele evaluar esa combinación con escenarios de exposición accidental y ataques DDoS.\n\n## Objetivos de Aprendizaje\n\nAl terminar este contenido, serás capaz de:\n\n1. Explicar por qué la VPC de Google Cloud se describe como global y sus subredes como regionales, y qué implica para latencia, alta disponibilidad y diseño de direcciones.\n2. Diferenciar una red en modo automático de una red en modo personalizado y justificar por qué producción debe evitar la red default.\n3. Interpretar una regla de firewall de VPC: dirección, prioridad, acción, target, origen o destino, protocolo y puerto, y estado de la conexión.\n4. Explicar el papel de las políticas de firewall jerárquicas y de las políticas de seguridad de red en una organización con muchas VPC.\n5. Seleccionar el mecanismo adecuado para conectar redes o entornos: Shared VPC, VPC Network Peering, Cloud VPN o Cloud Interconnect, según el caso.\n6. Distinguir Private Google Access, Private Service Connect y Cloud NAT, y explicar qué problema de exposición resuelve cada uno.\n7. Describir cómo Cloud Armor y los balanceadores de carga protegen una aplicación expuesta frente a DDoS y tráfico malicioso de capa 7.\n8. Explicar qué aporta VPC Service Controls frente a IAM y por qué se considera un control de exfiltración, no un sustituto de la autenticación.\n9. Usar VPC Flow Logs, firewall rules logging y Network Intelligence Center para investigar conectividad y evidencia de tráfico.\n10. Diseñar una respuesta proporcionada ante un incidente de red: contener, segmentar, observar y restaurar sin romper el servicio.\n\n## Contenido Principal\n\n### Subtema 1: La VPC global y la organización de la red\n\nUna Virtual Private Cloud (VPC) en Google Cloud es una red lógica global compuesta por subredes regionales. A diferencia de una red tradicional atada a un centro de datos, la VPC de Google Cloud permite que recursos de distintas regiones compartan la misma red y se comuniquen por la red troncal de Google, con direccionamiento y políticas comunes. La subred es regional: define un rango CIDR, una región y la política de logs de flujo. Esa separación entre red global y subred regional es la base para diseñar alta disponibilidad sin construir túneles entre regiones.\n\n| Componente | Alcance | Función de negocio |\n|---|---|---|\n| VPC network | Global | Aísla lógicamente un conjunto de recursos y define la política de red |\n| Subnet | Regional | Asigna direcciones IP y ubicación a los recursos de una región |\n| Route | Global o regional según el tipo | Decide por dónde sale el tráfico |\n| Firewall rule | Asociada a una VPC | Permite o deniega tráfico hacia o desde instancias |\n| Peering | Entre dos VPC | Conecta redes con direcciones no solapadas |\n\nLa red default se crea automáticamente en un proyecto nuevo con subredes en cada región y reglas permisivas, como default-allow-internal. Es cómoda para aprender y peligrosa para producción: abre comunicación interna amplia y crea subredes que el equipo no diseñó. Una organización madura usa redes en modo personalizado, crea solo las subredes que necesita, planifica el direccionamiento para no solapar con on-premises y elimina la red default o la deja sin uso. La decisión de direccionamiento es difícil de revertir: cambiar el CIDR de una subred en uso obliga a recrear recursos, y un solapamiento con la red corporativa impide conectar por VPN o Interconnect.\n\nLa VPC también es el límite de muchas políticas. Las reglas de firewall no se comparten entre VPC, ni siquiera entre redes conectadas por peering o VPN. Si dos VPC se conectan, cada una mantiene su propio firewall y sus propias rutas. Esa característica es una ventaja de seguridad —cada dominio conserva su política— y una fuente de errores cuando un equipo asume que la conectividad implica permiso. Conectar no es autorizar; son decisiones distintas.\n\n### Subtema 2: Reglas de firewall y políticas jerárquicas\n\nCada VPC implementa un firewall virtual distribuido. Una regla de firewall se evalúa en la instancia y tiene varios componentes que conviene leer en orden: dirección (ingress o egress), prioridad (menor número, mayor prioridad), acción (allow o deny), target (a qué instancias o cuentas de servicio aplica), origen o destino (rangos CIDR, tags o cuentas de servicio) y protocolo y puerto. Las reglas son stateful: si una conexión se permite en un sentido, el tráfico de retorno de esa misma conexión se permite automáticamente. No se puede configurar una regla para denegar solo la respuesta de una conexión aceptada.\n\nLa red tiene dos reglas implícitas: denegar todo el ingreso y permitir todo el egreso. Esa asimetría explica por qué una instancia puede descargar software de internet pero no recibir una conexión entrante si no se abre el puerto. La regla implícita de egreso es un riesgo de exfiltración: si un atacante obtiene ejecución en la instancia, puede enviar datos hacia fuera salvo que se creen reglas de egreso restrictivas y se controle la salida con NAT, proxy o inspección.\n\n| Campo | Pregunta que responde | Error típico |\n|---|---|---|\n| Dirección | ¿Protege la entrada o la salida? | Crear solo reglas de entrada y dejar el egreso abierto |\n| Prioridad | ¿Qué regla gana si varias coinciden? | Asumir que una regla de denegación siempre gana |\n| Target | ¿A qué recursos aplica? | Aplicar una regla a toda la red por comodidad |\n| Origen o destino | ¿Quién puede conectarse? | Usar 0.0.0.0/0 en puertos administrativos |\n| Protocolo y puerto | ¿Qué servicio se expone? | Abrir un rango amplio en lugar del puerto necesario |\n| Logging | ¿Queda evidencia del tráfico? | Activar logs solo después de un incidente |\n\nPara organizaciones con muchas VPC, las reglas por red no bastan. Las políticas de firewall jerárquicas permiten definir reglas en la organización o en una carpeta y heredarlas hacia abajo, con la posibilidad de que una política superior prevalezca. Ese modelo centraliza controles obligatorios, como bloquear protocolos inseguros o impedir que un proyecto abra un puerto administrativo a internet, sin depender de que cada equipo repita la configuración. La política debe equilibrar control y autonomía: una regla global demasiado estricta puede impedir un caso de uso legítimo, y una excepción sin dueño ni fecha de revisión se convierte en deuda de seguridad.\n\nEl uso de tags o cuentas de servicio como target es una decisión de gobierno. Los tags son simples y visibles, pero cualquiera con permiso para modificar una instancia puede cambiar su tag y quedar cubierto por otra regla. Las cuentas de servicio son más difíciles de asignar por accidente y permiten una política basada en identidad de carga de trabajo. En cualquier caso, la regla debe tener un propósito documentado y un test de conectividad que demuestre que hace lo que se espera.\n\n### Subtema 3: Conectividad privada, salida a internet y conexión híbrida\n\nUna aplicación en la VPC a menudo necesita hablar con servicios de Google, con internet, con otra VPC o con el datacenter. Cada necesidad tiene un mecanismo distinto y una implicación de seguridad distinta.\n\nPrivate Google Access permite que instancias sin IP externa alcancen las APIs y servicios de Google usando direcciones internas. Es el control que evita exponer una VM a internet solo para que descargue paquetes o escriba en Cloud Storage. Se habilita por subred y no requiere NAT ni IP pública. Private Service Connect va más allá: publica un servicio de un productor (propio o de terceros) detrás de una dirección IP interna en la VPC del consumidor, de modo que el consumidor no necesita salir a internet ni conocer la topología del productor. Es la opción para consumir servicios gestionados o SaaS con direccionamiento privado y control de acceso.\n\nCloud NAT permite que instancias sin IP externa inicien conexiones salientes a internet. No permite conexiones entrantes: es una traducción de salida, no un firewall de entrada. Se usa para actualizaciones, APIs externas y dependencias, y debe combinarse con reglas de egreso y con registro para saber qué salió. Cloud VPN conecta la VPC con una red remota mediante túneles IPsec sobre internet; es rápida de desplegar y adecuada para sucursales o conexiones de menor volumen. Cloud Interconnect ofrece conexión dedicada o de socio con mayor ancho de banda y menor variabilidad, y se elige cuando la latencia, el volumen o el SLA justifican el coste y el tiempo de instalación.\n\n| Necesidad | Mecanismo | Qué evita | Consideración |\n|---|---|---|---|\n| VM sin IP pública debe usar APIs de Google | Private Google Access | Exponer la VM a internet | Se habilita por subred |\n| Consumir un servicio gestionado o de socio por IP privada | Private Service Connect | Salida a internet y exposición del productor | Requiere endpoint y política de aceptación |\n| Salida a internet para actualizaciones | Cloud NAT | Asignar IP pública a cada VM | No permite ingreso; registrar y limitar egreso |\n| Conectar sucursal o datacenter por internet | Cloud VPN | Enlaces dedicados costosos | Latencia variable y capacidad limitada |\n| Conectar datacenter con alto volumen y SLA | Cloud Interconnect | Cuellos de botella de VPN | Mayor coste y plazo de provisión |\n| Compartir una VPC entre proyectos | Shared VPC | Duplicar redes y políticas | El proyecto host administra la red |\n| Conectar dos VPC | VPC Network Peering | VPN innecesaria entre nubes | No es transitivo y requiere CIDR no solapado |\n\nShared VPC permite que un proyecto host comparta subredes con proyectos de servicio. El equipo de plataforma controla la red y las políticas, y los equipos de aplicación consumen subredes sin crear su propia VPC. Es el patrón para organizaciones grandes que quieren una red centralizada y autonomía de despliegue. VPC Network Peering conecta dos VPC con direcciones no solapadas y tráfico privado; no es transitivo, así que si A está conectada a B y B a C, A no alcanza C automáticamente. Esa limitación es una decisión de diseño, no un defecto: evita que una red se convierta en un camino lateral no gobernado.\n\n### Subtema 4: Defensa perimetral, DDoS y aplicaciones expuestas\n\nCuando una aplicación se publica en internet, el control principal deja de ser la regla de firewall de la instancia y pasa a ser la capa de entrada: el balanceador de carga y la política de seguridad que lo protege. Cloud Load Balancing distribuye el tráfico entre backends, termina TLS y ofrece una IP anycast global que absorbe tráfico en el borde de la red de Google. Un Application Load Balancer entiende HTTP y HTTPS y permite enrutar por host, ruta o encabezado; un Network Load Balancer trabaja en capas inferiores para tráfico TCP o UDP. La elección depende del protocolo y de la necesidad de inspección de capa 7.\n\nGoogle Cloud Armor se aplica delante del balanceador y evalúa reglas de seguridad de capa 3 a capa 7. Permite listas de permitidos y denegados por IP o rango, reglas basadas en geografía, encabezados, método o ruta, limitación de tasa, protección contra bots y mitigación de DDoS volumétrico y de aplicación. Su valor de negocio es que el filtrado ocurre en el borde, antes de que el tráfico llegue al backend, y que las reglas se reutilizan entre servicios. No es un firewall de VPC: no protege una VM que no está detrás de un balanceador, y no sustituye la segmentación interna.\n\n| Capa de defensa | Control | Amenaza principal |\n|---|---|---|\n| Borde global | Cloud Load Balancing y cualquiercast | Ataques volumétricos y picos de tráfico |\n| Aplicación | Cloud Armor con reglas L7, cuota y rate limiting | DDoS de aplicación, scraping, fuerza bruta, inyección |\n| Identidad de usuario | Identity-Aware Proxy (IAP) | Acceso no autorizado a aplicaciones internas |\n| Red interna | VPC firewall y políticas jerárquicas | Movimiento lateral y puertos expuestos |\n| Datos y servicios | VPC Service Controls | Exfiltración de datos entre perímetros |\n\nIdentity-Aware Proxy (IAP) protege aplicaciones internas sin exponerlas a internet: el usuario se autentica con su identidad corporativa y la política decide si puede acceder al recurso, en lugar de confiar en que está dentro de la red. Es el patrón de zero trust para aplicaciones web internas y para acceso administrativo a instancias, y reduce la necesidad de VPN para usuarios. La decisión de negocio es pasar de una confianza basada en la ubicación a una confianza basada en identidad y contexto.\n\nVPC Service Controls crea un perímetro alrededor de servicios gestionados, como Cloud Storage o BigQuery, y bloquea la salida de datos hacia recursos fuera del perímetro. No autentica usuarios ni reemplaza IAM: complementa IAM porque una identidad con permiso legítimo sobre un dataset puede seguir siendo bloqueada si intenta copiarlo a un proyecto fuera del perímetro. Es el control que responde a la pregunta de exfiltración, y su diseño exige planificar qué servicios y proyectos quedan dentro, qué reglas de ingreso y egreso se permiten y cómo se audita el tráfico entre perímetros.\n\nEn un ataque DDoS, la respuesta proporcionada combina absorción en el borde, reglas de Cloud Armor, limitación de tasa y un diseño elástico del backend. No se resuelve solo con un firewall de instancia ni con más CPU: el objetivo es que el tráfico malicioso no llegue al servicio y que el tráfico legítimo siga siendo atendido. La comunicación de negocio debe distinguir entre un pico legítimo y un ataque, porque la primera situación se maneja con capacidad y la segunda con mitigación activa.\n\n### Subtema 5: Visibilidad, operación y respuesta a incidentes\n\nSin visibilidad, la seguridad de red es una configuración que se cree correcta. VPC Flow Logs registra información sobre el tráfico de las interfaces de red, incluidas direcciones, puertos, protocolo y decisión; permite investigar conexiones, detectar patrones anómalos y demostrar qué tráfico se permitió. Firewall Rules Logging registra las conexiones que coinciden con una regla concreta y es útil para validar que una regla hace lo que se espera. Network Intelligence Center agrupa herramientas de topología, conectividad, rendimiento y monitorización para diagnosticar por qué un recurso no alcanza a otro.\n\nLa operación debe tener un runbook claro: ante una exposición, identificar el recurso, retirar la regla o la IP pública, revisar logs, rotar credenciales si corresponde, Notificar a los responsables y documentar la causa. La contención no es solo borrar la regla; es confirmar que no quedó otra ruta, que el tráfico no se desvió a otro backend y que el dato no salió. La evidencia de logs y la línea de tiempo son parte de la respuesta, no un extra para la auditoría.\n\n#### Ejemplo Práctico\n\nEl siguiente ejemplo crea una red personalizada, una subred regional, una regla de ingreso limitada a HTTPS y una política de seguridad para el balanceador. Los valores son ilustrativos.\n\nbash\n# Red personalizada y subred regional\ngcloud compute networks create cdl-vpc --subnet-mode=custom\ngcloud compute networks subnets create cdl-web-eu \\\n --network=cdl-vpc \\\n --region=europe-west1 \\\n --range=10.20.0.0/24 \\\n --enable-private-ip-google-access\n\n# Solo HTTPS desde el balanceador; no abrir SSH a internet\ngcloud compute firewall-rules create allow-https-lb \\\n --network=cdl-vpc \\\n --direction=INGRESS \\\n --action=ALLOW \\\n --rules=tcp:443 \\\n --source-ranges=130.211.0.0/22,35.191.0.0/16 \\\n --target-tags=web\n\n# Política de seguridad de Cloud Armor y regla de denegación por defecto\ngcloud compute security-policies create cdl-armor-policy \\\n --description='Proteccion perimetral del frontend'\ngcloud compute security-policies rules create 1000 \\\n --security-policy=cdl-armor-policy \\\n --expression='true' \\\n --action=deny-403\n\n# Prueba de conectividad entre dos recursos\ngcloud network-management connectivity-tests create web-a-db \\\n --source-instance=web-a \\\n --destination-instance=db-a \\\n --protocol=TCP \\\n --destination-port=5432\n\n\nLa lectura de negocio es que la aplicación solo acepta tráfico del balanceador, no tiene SSH abierto a internet y toda petición pasa por una política de borde. La prueba de conectividad documenta que el camino interno funciona y evita descubrir un bloqueo el día del despliegue.\n\nTemas relacionados: Security and Trust Principles in Google Cloud, Identity, Access Management and Compliance, Encryption, Key Management and Data Protection, Compliance, Data Sovereignty and Data Residency.\n\n## Errores Comunes\n\n1. Error: Usar la red default en producción porque ya existe y funciona. → Solución: Crear una VPC en modo personalizado con subredes planificadas, direccionamiento que no solape con on-premises y reglas explícitas; dejar la default fuera de uso.\n2. Error: Crear solo reglas de ingreso y asumir que el egreso está controlado. → Solución: Revisar la regla implícita de egreso, añadir reglas restrictivas para salidas sensibles y usar Cloud NAT o un proxy con registro cuando se necesite internet.\n3. Error: Conectar dos VPC con peering y creer que el firewall de una protege a la otra. → Solución: Recordar que cada VPC mantiene sus propias reglas y que el peering no es transitivo; diseñar la conectividad y el firewall por separado y probar el camino real.\n4. Error: Abrir SSH o bases de datos a 0.0.0.0/0 para resolver un problema de acceso. → Solución: Usar IAP para acceso administrativo, Private Service Connect o IP privada para bases de datos y una regla temporal documentada si se necesita una excepción.\n5. Error: Confiar solo en Cloud Armor para proteger una aplicación y dejar el backend accesible directamente. → Solución: Restringir el ingreso al rango del balanceador, aplicar IAP donde corresponda y segmentar el backend; Cloud Armor solo protege el tráfico que pasa por la capa que lo aplica.\n\n## Puntos para el Examen\n\n> 🎯 Punto clave 1: La VPC es global y las subredes son regionales. Esa es la base de la alta disponibilidad y de la conectividad entre regiones sin túneles adicionales.\n\n> 🎯 Punto clave 2: El firewall de VPC es distribuido, stateful y se evalúa por prioridad. La regla implícita deniega el ingreso y permite el egreso; controlar la salida es tan importante como cerrar la entrada.\n\n> 🎯 Punto clave 3: Private Google Access evita exponer VMs para usar APIs de Google; Cloud NAT permite salida sin IP pública; Private Service Connect consume servicios por IP privada; VPN e Interconnect conectan con on-premises.\n\n> 🎯 Punto clave 4: Cloud Armor protege aplicaciones detrás de un balanceador frente a DDoS y ataques de capa 7. IAP protege el acceso de usuarios con identidad; VPC Service Controls protege contra exfiltración entre perímetros.\n\n> 🎯 Punto clave 5: La evidencia se produce con logs y pruebas de conectividad. Una regla sin logging y sin test es una intención, no un control demostrado.\n\n## Recursos Externos\n\n- Virtual Private Cloud (VPC) overview — Red global, subredes regionales, rutas y firewall distribuido.\n- VPC firewall rules — Componentes, prioridad, estado de conexión y evaluación de reglas.\n- Cloud Armor security policy overview — Reglas de capa 3 a 7, mitigación de DDoS y protección de aplicaciones.\n- VPC Service Controls overview — Perímetros de servicios y prevención de exfiltración.\n- Cloud NAT overview — Salida a internet sin IP pública y sus límites.\n- Network Intelligence Center — Topología, conectividad y diagnóstico de red.\n\n## Autoevaluación Rápida\n\n1. Pregunta: Una VM sin IP pública necesita escribir en Cloud Storage y descargar actualizaciones de internet. ¿Qué combinación es la más segura?\n Respuesta: Private Google Access en la subred para las APIs de Google y Cloud NAT para la salida a internet, con reglas de egreso restrictivas y logs. Así no se asigna IP pública a la VM y se conserva visibilidad de la salida.\n\n2. Pregunta: ¿Por qué el peering entre dos VPC no garantiza que el firewall de una proteja a la otra?\n Respuesta: Porque las reglas de firewall pertenecen a cada VPC y no se comparten a través del peering. La conectividad permite el camino de red, pero cada red sigue aplicando sus propias reglas de ingreso y egreso; además, el peering no es transitivo.\n\n3. Pregunta: Un frontend recibe un ataque DDoS de capa 7. ¿Qué controles se combinan?\n Respuesta: Un balanceador global que absorbe el tráfico en el borde, Cloud Armor con reglas de rate limiting y filtrado de capa 7, y un backend elástico. El firewall de instancia no es suficiente porque el ataque llega como tráfico HTTP legítimo en apariencia.\n\n4. Pregunta: ¿Qué diferencia hay entre IAP y VPC Service Controls?\n Respuesta: IAP autentica y autoriza el acceso de usuarios a una aplicación o recurso según su identidad y contexto. VPC Service Controls define un perímetro alrededor de servicios gestionados para impedir que los datos salgan a recursos no autorizados. IAP controla quién entra; VPC Service Controls controla qué puede salir y desde dónde.\n\n5. Pregunta: ¿Qué evidencia usarías para demostrar que una regla de firewall funciona como se espera?\n Respuesta: Firewall Rules Logging para ver las conexiones que coinciden, VPC Flow Logs para el tráfico observado y una prueba de conectividad de Network Intelligence Center para verificar el camino. La combinación demuestra tanto la intención de la regla como el comportamiento real.\n\n