Google PCNE: Política de firewall, Cloud Armor y seguridad de red — Guía de estudio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Información general

La política de firewall, Cloud Armor y la seguridad de red en Google Cloud proporcionan en conjunto controles por capas para la segmentación, la reducción de la superficie de ataque, la resiliencia ante DDoS y la observabilidad. Los diseños eficaces combinan la segmentación basada en identidad, la aplicación jerárquica de políticas, el principio de privilegio mínimo para la entrada y salida, y protecciones en el borde de la red vinculadas a los balanceadores de cargas globales de Google. El éxito operativo depende de comprender la evaluación de reglas, los comportamientos implícitos, el alcance del registro de logs y de dónde se origina realmente el tráfico para los diferentes modos de balanceo de cargas.

Reglas de firewall de VPC y segmentación basada en identidad

Las reglas de firewall de VPC son con estado (stateful) y se evalúan por red, dirección y prioridad.

• Dirección y reglas implícitas:
  • La entrada (ingress) se evalúa para el tráfico que ingresa a una NIC de VM; la salida (egress) para el tráfico que la abandona.
  • Existen dos reglas implícitas en cada VPC: una regla implícita de denegación total de entrada y una regla implícita de permiso total de salida. Estas no se pueden modificar y no producen logs. La red predeterminada también crea varias reglas permisivas; las VPC personalizadas no lo hacen.
• Prioridad y evaluación:
  • Las prioridades van de 0 a 65535, donde los números más bajos se evalúan primero. La primera regla que coincide determina completamente la acción.
  • Si coinciden varias reglas con la misma prioridad, gana el rango de IP más específico; si la especificidad es igual y las acciones entran en conflicto, gana la denegación. Evite las superposiciones con la misma prioridad.
• Destinos (targets) y orígenes (sources):
  • Los destinos (targets) definen a qué VMs se aplica la regla: etiquetas de red, cuentas de servicio de VM o etiquetas seguras. Los orígenes/destinos son CIDR de IP; para la entrada, también puede especificar cuentas de servicio o etiquetas de origen para orígenes dentro de la misma VPC.
  • Las etiquetas de red son metadatos de VM que pueden establecer los usuarios del proyecto; son simples pero menos controladas. Las cuentas de servicio proporcionan una segmentación basada en identidad vinculada a la identidad de la carga de trabajo y a IAM, lo que dificulta su uso indebido. Las etiquetas seguras (etiquetas del administrador de recursos a nivel de organización vinculadas a través de IAM) permiten a los equipos de seguridad controlar a qué VMs puede apuntar una regla sin permitir que los desarrolladores se autoasignen etiquetas que eludan la protección; úselas para una gobernanza más sólida.
• Registro de logs:
  • Habilite el registro de logs de reglas de firewall por regla para capturar las conexiones permitidas o denegadas que coincidan con esa regla. Las denegaciones implícitas no se registran; si necesita logs de denegación, agregue una regla explícita de denegación de alta prioridad con el registro habilitado.
  • Los logs incluyen la referencia de la regla, la acción, la 5-tupla, los bytes y se pueden exportar para análisis forense.

Diseño y operaciones:

• Entrada con privilegio mínimo: Prefiera la denegación por defecto utilizando denegaciones explícitas de alta prioridad, y luego agregue permisos acotados por cuenta de servicio o etiqueta segura. Para los grupos de instancias detrás de un balanceador de cargas, permita el tráfico solo desde el balanceador de cargas o los rangos de las verificaciones de estado que realmente originan el tráfico.
• Salida con privilegio mínimo: Reemplace el permiso implícito con una denegación explícita de salida total de alta prioridad más permisos específicos (para rangos de NAT, IP de socios o API de Google a través de Private Google Access). Tenga cuidado de no interrumpir los flujos de retorno; la naturaleza con estado (statefulness) permite respuestas a conexiones permitidas sin reglas adicionales.
• Segmentación basada en identidad:
  • Use cuentas de servicio para una política de “quién puede hablar con quién”, independientemente de la movilidad de la IP.
  • Use etiquetas seguras para evitar que los desarrolladores se autoapliquen etiquetas de red permisivas.
• Errores comunes y modos de fallo:
  • Identidad de origen del balanceador de cargas: Para los balanceadores de cargas de HTTP(S) externos, los backends ven conexiones desde los proxies de Google Front End, no desde las IP de los clientes. Use Cloud Armor para permitir/denegar IP de clientes; use el firewall de VPC para permitir los rangos de salida de GFE y de las verificaciones de estado. Para los balanceadores de cargas de red TCP/UDP, los backends ven la IP del cliente; las listas de permisos de IP de clientes en el firewall se aplican directamente.
  • Falta de logs de denegación: Las denegaciones de las reglas implícitas no se registran. Agregue una regla de denegación explícita con el registro habilitado para observar el tráfico bloqueado.
  • Omisión de NAT: Si una VM tiene una IP externa, la usará para el tráfico de salida y omitirá Cloud NAT. Elimine la IP externa para forzar el uso de NAT.
  • Diagnóstico de no coincidencia de reglas: Confirme la dirección, la identidad del destino (etiqueta/cuenta de servicio/etiqueta segura), la prioridad y los filtros de origen. Si los logs no muestran ninguna coincidencia, el tráfico no está llegando a la regla que usted espera.

Ejemplo corto, permiso de entrada basado en identidad con registro de logs:

• Destino (target): cuenta de servicio sa: web-backend@project.iam.gserviceaccount.com
• Rangos de origen: rangos de proxy de GFE + verificaciones de estado de Google
• Prioridad: 100
• Acción: permitir tcp:80,443
• Registro de logs: activado

Política de firewall jerárquica, segmentación y perímetros de servicio

Las políticas de firewall jerárquicas aplican reglas a nivel de organización o de carpeta antes que cualquier regla a nivel de VPC. Úsalas para garantizar barreras de protección (por ejemplo, “denegar toda la entrada desde internet a las VM sin balanceador de carga” o “denegar RDP/SSH desde 0.0.0.0/0”). Las reglas de VPC de nivel inferior no pueden anular una denegación de organización/carpeta que ya haya coincidido.

Estrategia de segmentación:

• Segmentación de entrada:
  • Política de organización/carpeta: denegaciones de alta prioridad para puertos de riesgo y una denegación predeterminada, excepto para los puntos de entrada autorizados. Permite los rangos de comprobación de estado de Google donde sea necesario.
  • Reglas de VPC: permisos específicos para la carga de trabajo, dirigidos por cuenta de servicio o etiqueta segura. Para servicios internos, usa Private Service Connect o el balanceo de carga interno para el acceso este-oeste con reglas restringidas.
• Segmentación de salida:
  • Reemplaza la regla implícita de permitir toda la salida por una denegación de toda la salida de alta prioridad a nivel de organización/carpeta o VPC, y luego abre solo lo que sea necesario:
    • Salida a internet a través de Cloud NAT o firewalls de salida aprobados.
    • APIs de Google a través de Private Google Access y los puntos de conexión private.googleapis.com o restricted.googleapis.com. El punto de conexión restringido se combina con VPC Service Controls para evitar la exfiltración de datos a identidades o proyectos no autorizados.
    • Para diseños que dirigen 0.0.0.0/0 a través de un firewall de terceros pero que aún requieren acceso directo a las APIs de Google sin hacer hairpinning, agrega rutas estáticas para los bloques VIP de las APIs de Google a la puerta de enlace de internet predeterminada y habilita Private Google Access en las subredes. Esto preserva los controles de seguridad al tiempo que reduce la latencia y la dependencia del dispositivo de terceros para los servicios propios.

Interacciones con el perímetro de servicio:

• VPC Service Controls define perímetros alrededor de los proyectos y las APIs de Google compatibles para mitigar la exfiltración de datos. Cuando los perímetros están habilitados:
  • Prefiere restricted.googleapis.com para que las llamadas a la API deban permanecer dentro del contexto del perímetro.
  • Asegúrate de que el DNS apunte los dominios relevantes a los puntos de conexión restringidos o privados y que las rutas no redirijan el tráfico hacia dispositivos de salida no confiables.
  • Combina la política de perímetro con listas de permisos del firewall de salida para evitar fugas accidentales a puntos de conexión fuera del perímetro.

Compensaciones:

• Las denegaciones a nivel de organización simplifican la gestión de riesgos, pero pueden bloquear experimentos legítimos si el control de cambios es lento; delega excepciones usando etiquetas seguras y flujos de trabajo de solicitud documentados.
• Las denegaciones de salida agresivas reducen el radio de impacto, pero requieren un descubrimiento de servicios y un control de cambios robustos para evitar interrupciones.

Cloud Armor, WAF y protecciones de borde globales

Cloud Armor vincula políticas de seguridad a los balanceadores de carga de proxy TCP/SSL externos y HTTP(S) externos para proteger en el borde.

• Reglas de WAF:
  • Usa reglas preconfiguradas para el Top 10 de OWASP y CVEs comunes, y reglas personalizadas usando un lenguaje de expresión para coincidencias basadas en encabezados, IPs, países, URIs y más.
  • Asocia por cada servicio de backend y ordena las reglas por prioridad. Las acciones incluyen permitir, denegar con respuestas específicas o redirigir para HTTP(S).
• Limitación de velocidad:
  • Aplica cuotas por clave (por ejemplo, por IP de cliente, encabezado o cookie) con ventanas deslizantes y controles de ráfagas. Las prohibiciones basadas en la tasa añaden automáticamente denegaciones temporales para las fuentes abusivas.
• Adaptive Protection:
  • La detección de anomalías basada en ML aprende los patrones de solicitud normales y detecta DDoS de L7 o abusos. Puede sugerir o generar automáticamente reglas candidatas; impleméntalas primero en modo de vista previa.
• Modo de vista previa:
  • Evalúa nuevas reglas sin afectar el tráfico. Los resultados de la vista previa se registran en logs, lo que permite un ajuste de bajo riesgo. Pasa al modo de aplicación forzosa después de la verificación.

Defensa contra DDoS y controles del balanceador de carga global:

• El borde global anycast de Google absorbe ataques volumétricos de L3/L4; la validación SYN/ACK, el manejo de paquetes malformados y la capacidad de autoescalado del borde están integrados en la plataforma para los balanceadores de carga de proxy TCP/SSL y HTTP(S) externos.
• Combínalo con Cloud Armor para mitigar inundaciones de L7, credential stuffing y abuso de aplicaciones.
• Aplica políticas de TLS, cifrados modernos y, cuando sea necesario, mTLS de cliente en el balanceador de carga. Para requisitos de IPv6, usa un balanceador de carga de proxy TCP/SSL o HTTP(S) externo global con VIPs de IPv6.
• Para incluir en una lista de permisos IPs de clientes específicas para una aplicación con balanceo de carga:
  • Si usas HTTP(S), prefiere las listas de permisos de Cloud Armor basadas en la IP del cliente y mantén las reglas de firewall del backend limitadas a las fuentes de GFE y de comprobación de estado.
  • Si usas un balanceador de carga de red TCP/UDP, los backends ven la IP real del cliente; aplica las listas de permisos del firewall de VPC directamente a las instancias de destino (por etiqueta segura o cuenta de servicio) e incluye las IPs de comprobación de estado de Google.

Precauciones operativas:

• Las reglas se evalúan en el borde; las listas de permisos incorrectas pueden causar interrupciones globales al instante. Usa el modo de vista previa y los despliegues por etapas, y monitorea los logs de Cloud Armor y las métricas del balanceador de carga.
• Las necesidades de afinidad de sesión varían: para protocolos mixtos (por ejemplo, HTTP y TFTP del mismo cliente al mismo grupo de backend), la afinidad por IP de cliente en el balanceador de carga preserva la persistencia de sesión entre puertos.

Visibilidad, inspección y respuesta a incidentes

Observabilidad:

• Los VPC Flow Logs proporcionan registros de flujo de 5 tuplas muestreados por subred con muestreo, enriquecimiento con metadatos e intervalos de agregación configurables. Úselos para establecer bases de referencia de rendimiento y para la detección de anomalías.
• El registro de reglas de firewall captura los permisos y denegaciones por conexión para las reglas específicas que tienen el registro habilitado; cree reglas de denegación explícitas para registrar los bloqueos que de otro modo coincidirían con las denegaciones implícitas.
• Los registros de solicitudes y los resultados de la vista previa de Cloud Armor muestran las coincidencias de reglas, las decisiones de acción y los resultados de la limitación de velocidad en el borde de la red.

Inspección y detección:

• Packet Mirroring copia el tráfico a un colector en la misma región para una inspección profunda de paquetes o para un IDS. Limite el alcance de la replicación por subred, etiqueta o cuenta de servicio para reducir la sobrecarga. Packet Mirroring opera fuera de banda y no bloquea el tráfico; úselo con Cloud IDS o sensores de terceros.
• La inspección L7 en línea requiere un patrón de dispositivo con 2 NIC y el enrutamiento del tráfico a través de él. Diseñe para un enrutamiento simétrico y alta disponibilidad (HA); considere los dominios de fallo regionales y los posibles cuellos de botella de rendimiento. Los dispositivos en línea aumentan el radio de impacto si fallan; despliegue grupos de instancias administrados y patrones de conmutación por error de rutas con comprobaciones de estado donde sea aplicable.

Prácticas de respuesta a incidentes:

• Centralice los registros en un proyecto de seguridad, cree detecciones para picos repentinos de denegaciones, creaciones de nuevas reglas de alta prioridad o activadores de límite de velocidad de Cloud Armor. Use BigQuery o integraciones con SIEM para la investigación.
• Asegure el mínimo privilegio en IAM: el rol de Network Admin es insuficiente para modificar las políticas de firewall en una VPC compartida, donde se requiere el rol de Security Admin; segregue las funciones entre los equipos de red y de seguridad.
• Cuando necesite acceso de emergencia SSH (break-glass) y las claves no estén preaprovisionadas, use

undefined

desde Cloud Shell para insertar una clave efímera a través de los metadatos de la instancia, si los permisos de IAM y la configuración de los metadatos de la instancia lo permiten.

• Para solucionar escenarios de “sin registros”: verifique la regla y la dirección del tráfico, recuerde que las denegaciones implícitas no generan registros y compruebe las políticas jerárquicas que podrían haber coincidido antes.

Escenario de un problema práctico

Contoso Retail opera una plataforma web de varias capas en Google Cloud. El tráfico del frontend es atendido por un balanceador de cargas HTTP(S) externo y global; las VM de la aplicación se ejecutan en múltiples regiones sin IP externas. El tráfico de egreso debe hacer hairpinning a través de un NGFW de terceros, excepto para las API de Google (BigQuery y Pub/Sub). El equipo de seguridad desea barreras de protección (guardrails) a nivel de organización, listas de permisos de IP de clientes para un piloto con un socio y un riesgo mínimo al probar un cliente sospechoso de ser malicioso.

Enfoque:

1. Establecer barreras de protección jerárquicas
   • Cree una política de firewall jerárquica a nivel de organización que deniegue todo el tráfico de ingreso desde 0.0.0.0/0 a los destinos de VM que carecen de la etiqueta segura

undefined

, y que deniegue los puertos administrativos (SSH, RDP) desde internet.

• Justificación: Detiene la exposición insegura a nivel global; los desarrolladores no pueden autoasignarse la etiqueta segura debido a los permisos de IAM sobre las etiquetas.

2. Segmentación de cargas de trabajo basada en identidad
   • Asigne cuentas de servicio distintas a las capas de frontend, aplicación y base de datos. Haga referencia a estas cuentas de servicio en las reglas de firewall a nivel de VPC para permitir solo los flujos este-oeste requeridos (por ejemplo,

undefined

,

undefined

).

• Justificación: Vincula la política a la identidad de la carga de trabajo y resiste el uso indebido accidental de etiquetas.

3. Permisos de ingreso para backends con balanceo de carga

   • En las VM de la aplicación, cree una regla de permiso de ingreso de alta prioridad dirigida por la cuenta de servicio de la aplicación, con rangos de origen iguales a los de los proxies de Google Front End y los rangos de comprobación de estado de Google; habilite el registro.
   • Justificación: Para HTTP(S) L7, los backends solo deben aceptar conexiones desde las IP de GFE y de las comprobaciones de estado; las listas de permisos de IP de clientes se aplican en el borde de la red.

4. Política de borde con Cloud Armor

   • Asocie una política de Cloud Armor al servicio de backend del balanceador de cargas HTTP(S) externo:
     • Agregue una regla de lista de permisos para la IP del cliente socio.
     • Habilite las reglas WAF preconfiguradas para el Top 10 de OWASP.
     • Configure un límite de velocidad basado en la IP del cliente con umbrales conservadores.
   • Justificación: Aplica restricciones de origen del cliente y protecciones de la capa de aplicación donde la IP del cliente es visible y antes de que el tráfico llegue a la VPC.

5. Protección adaptativa y pruebas seguras

   • Habilite Adaptive Protection y cree una regla de denegación para la IP del cliente sospechoso en modo de vista previa.
   • Justificación: La vista previa permite verificar el comportamiento sin afectar a los usuarios reales; los registros confirman si el cliente es malicioso antes de aplicar la regla.

6. Segmentación de egreso con Private Google Access

   • Mantenga una ruta 0.0.0.0/0 hacia el NGFW de terceros. Agregue rutas estáticas personalizadas para las VIP de las API de Google hacia la puerta de enlace de internet predeterminada y habilite Private Google Access en las subredes. Agregue una regla explícita de alta prioridad para denegar todo el egreso, y luego permisos específicos para el siguiente salto del NGFW y las API de Google; habilite el registro.
   • Justificación: Fuerza el egreso general de internet a través del NGFW, mientras permite que se acceda a BigQuery y Pub/Sub de forma privada sin hairpinning innecesario.

7. Controles de NAT y de IP externas

   • Use Cloud NAT para las instancias que necesitan egreso a internet pero no tienen IP externas. Audite y elimine cualquier IP externa en las instancias de cómputo que deban usar NAT.
   • Justificación: Evita el desvío de NAT (NAT bypass) y preserva una postura de egreso única.

8. Inspección y monitorización

   • Habilite Packet Mirroring en cada región para la capa de aplicación, apuntando a la cuenta de servicio de la aplicación, y envíe el tráfico replicado a un colector de IDS regional. Habilite los VPC Flow Logs y el registro de reglas de firewall para las reglas clave; exporte los registros de Cloud Armor y de la VPC a un proyecto de seguridad central y a BigQuery.
   • Justificación: Proporciona una visibilidad profunda para la búsqueda de amenazas (threat hunting) y para establecer bases de referencia de rendimiento sin introducir latencia en la ruta del tráfico.

9. Operaciones preparadas para incidentes

   • Cree alertas sobre picos de denegaciones en Cloud Armor, registros de denegación del firewall o cambios en las políticas jerárquicas. Documente un procedimiento de SSH de emergencia (break-glass) usando

undefined

de Cloud Shell para un acceso de emergencia controlado.

• Justificación: Detecta abusos activos rápidamente y preserva una ruta operativa segura para la remediación.

10. Seguridad en los cambios y reversión (rollback)

• Implemente los cambios de Cloud Armor en modo de vista previa y luego aplíquelos. Para los cambios de firewall, use prioridades de menor riesgo y proyectos canario antes de propagarlos a la política a nivel de organización.
• Justificación: Minimiza la posibilidad de interrupciones globales por errores en las políticas, manteniendo al mismo tiempo una postura de seguridad sólida.

← Arquitectura de VPC · Todos los dominios · Conectividad híbrida →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →