Redes para un acceso seguro entre nubes: arquitecturas de referencia

Last reviewed 2025-01-13 UTC

Este documento forma parte de una serie en la que se describen las arquitecturas de redes y seguridad para empresas que están migrando cargas de trabajo de centros de datos aGoogle Cloud.

La serie consta de los siguientes documentos:

Las cargas de trabajo de los casos prácticos en la nube residen en redes de VPC y necesitan conectarse a otros recursos de Google Cloud. Pueden consumir servicios que se proporcionan de forma nativa en la nube, como BigQuery. El perímetro de seguridad se proporciona mediante diversas funciones propias y de terceros, como firewalls, Controles de Servicio de VPC y dispositivos virtuales de red.

En muchos casos, estas cargas de trabajo abarcan varias redes de VPC Google Cloud y es necesario proteger los límites entre las redes de VPC. En este documento se describen en detalle estas arquitecturas de seguridad y conectividad.

Arquitectura de lift-and-shift

El primer escenario de un caso práctico en la misma nube es una arquitectura de migración tal cual, en la que se trasladan cargas de trabajo establecidas a la nube sin hacer cambios.

Cloud NGFW

Puedes ayudar a establecer un perímetro seguro configurando Cloud Next Generation Firewall. Puedes usar etiquetas, cuentas de servicio y etiquetas de red para aplicar reglas de cortafuegos detalladas a las VMs. Para obtener directrices de implementación sobre cómo gestionar el tráfico con Google Cloud reglas de cortafuegos, consulta Políticas de cortafuegos de red en el plan técnico de las bases de la empresa.

También puedes usar Almacenamiento de registros de reglas de cortafuegos para auditar y verificar los efectos de la configuración de las reglas de cortafuegos.

Puedes usar registros de flujo de VPC para realizar análisis forenses de la red y también transmitir los registros para integrarlos con SIEM. Este sistema general puede proporcionar monitorización en tiempo real, correlación de eventos, análisis y alertas de seguridad.

En la figura 1 se muestra cómo las reglas de cortafuegos pueden usar etiquetas de red para restringir el tráfico entre las VMs de una red de VPC.

Configuración de cortafuegos de red que usa etiquetas de red para aplicar un control de salida detallado.

Imagen 1. Configuración de cortafuegos de red que usa etiquetas de red para aplicar un control de salida detallado.

Dispositivo virtual de red

Un dispositivo virtual de red (NVA) es una VM que tiene funciones de seguridad, como cortafuegos de aplicaciones web (WAF) o cortafuegos de nivel de aplicación de seguridad. Las NVAs con varias interfaces de red se pueden usar para crear un puente entre redes de VPC. Puedes usar las AVNs para implementar funciones de seguridad en el tráfico entre redes de VPC, especialmente cuando usas una configuración de concentrador y radios, como se muestra en la figura 2.

Configuración centralizada de dispositivos de red en una red de VPC compartida.

Imagen 2. Configuración centralizada de dispositivos de red en una red de VPC compartida.

Cloud IDS

Cloud Intrusion Detection System (Cloud IDS) te permite implementar la inspección de seguridad nativa y el registro reflejando el tráfico de una subred de tu red de VPC. Con Cloud IDS, puedes inspeccionar y monitorizar una gran variedad de amenazas en la capa de red y en la capa de aplicación para analizarlas. Crea endpoints de Cloud IDS en tu red de Google Cloud VPC. Estos endpoints monitorizan el tráfico de entrada y salida hacia y desde esa red, así como el tráfico de la red de VPC interna, mediante la función de duplicación de paquetes integrada en la Google Cloud pila de redes. Debes habilitar el acceso a servicios privados para conectarte al proyecto del productor de servicios (el proyecto gestionado por Google) que aloja los procesos de Cloud IDS.

Si tienes una arquitectura de concentrador y radios, el tráfico de cada uno de los radios se puede replicar en las instancias de Cloud IDS, tal como se muestra en la figura 3.

Configuración de Cloud IDS para replicar el tráfico de VPC que usa el acceso a servicios privados.

Imagen 3. Configuración de Cloud IDS para replicar el tráfico de VPC que usa el acceso a servicios privados.

Cloud IDS se puede proteger en el perímetro de servicio de Controles de Servicio de VPC mediante un paso adicional. Puedes consultar más información sobre la compatibilidad con Controles de Servicio de VPC en los productos compatibles.

Network Connectivity Center

Network Connectivity Center es un marco de orquestación que simplifica la conectividad de red entre recursos conectados a un recurso de gestión central llamado "hub". Network Connectivity Center admite los siguientes tipos de redes:

  • Google Cloud Redes de VPC
  • Redes on-premise y otras redes en la nube que usan Cloud Interconnect o VPN de alta disponibilidad
  • Conexiones cifradas ancladas por máquinas virtuales

Network Connectivity Center es el plano de control de la arquitectura. Las conexiones a las redes se denominan radios. Puedes usar Network Connectivity Center para conectar redes entre sí con una topología de malla completa o de eje y radio.

Emparejamiento entre redes VPC

En el caso de las aplicaciones que abarcan varias redes de VPC, ya pertenezcan al mismo proyecto o al mismo recurso de organización, el emparejamiento de redes de VPC permite la conectividad entre redes de VPC. Google Cloud Esta conectividad permite que el tráfico permanezca en la red de Google para que no atraviese la red pública de Internet.

Una arquitectura de eje y radio es un modelo popular para la conectividad de VPCs. Este modelo es útil cuando una empresa tiene varias aplicaciones que necesitan acceder a un conjunto común de servicios, como el registro o la autenticación. Este modelo también es útil si la empresa necesita implementar un conjunto común de políticas de seguridad para el tráfico que sale de la red a través del centro. Para obtener instrucciones sobre cómo configurar una arquitectura de concentrador y radios mediante el emparejamiento entre redes de VPC, consulta Conectividad entre VPCs de Red Multinube mediante el emparejamiento entre redes de VPC.

VPC compartida

Puedes usar la VPC compartida para mantener el control centralizado de los recursos de red, como las subredes, las rutas y los cortafuegos, en los proyectos host. Este nivel de control te permite implementar la práctica recomendada de seguridad de mínimo privilegio para la administración de redes, la auditoría y el control de acceso, ya que puedes delegar tareas de administración de redes en administradores de redes y de seguridad. Puedes asignar la capacidad de crear y gestionar máquinas virtuales a administradores de instancias mediante proyectos de servicio. Al usar un proyecto de servicio, se asegura de que los administradores de la VM solo tengan la capacidad de crear y gestionar instancias, y de que no puedan hacer ningún cambio que afecte a la red de VPC compartida.

Por ejemplo, puedes proporcionar más aislamiento definiendo dos redes de VPC en dos proyectos del host y vinculando varios proyectos de servicio a cada red, uno para producción y otro para pruebas. En la figura 6 se muestra una arquitectura que aísla un entorno de producción de un entorno de pruebas mediante proyectos independientes.

Para obtener más información sobre las prácticas recomendadas para crear redes de VPC, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.

Configuración de red de VPC compartida que usa varios hosts y proyectos de servicio aislados (entornos de prueba y de producción).

Imagen 6. Configuración de red de VPC compartida que usa varios hosts y proyectos de servicio aislados (entornos de prueba y de producción).

Arquitectura de servicios híbridos

La arquitectura de servicios híbridos proporciona servicios nativos de la nube adicionales diseñados para permitirte conectar y proteger servicios en un entorno de varias VPCs. Estos servicios nativos de la nube complementan lo que está disponible en la arquitectura de migración tal cual y pueden facilitar la gestión de un entorno segmentado por VPC a gran escala.

Private Service Connect

Private Service Connect permite que un servicio alojado en una red de VPC se muestre en otra. No es necesario que los servicios estén alojados en el mismo recurso de organización, por lo que Private Service Connect se puede usar para consumir servicios de forma privada desde otra red de VPC, aunque esté conectada a otro recurso de organización.

Puedes usar Private Service Connect de dos formas: para acceder a las APIs de Google o para acceder a servicios alojados en otras redes de VPC.

Usar Private Service Connect para acceder a las APIs de Google

Cuando usas Private Service Connect, puedes exponer APIs de Google mediante un punto final de Private Service Connect que forme parte de tu red de VPC, tal como se muestra en la figura 7.

Configuración de Private Service Connect para enviar tráfico a las APIs de Google mediante un punto final de Private Service Connect privado para tu red de VPC.

Imagen 7. Configuración de Private Service Connect para enviar tráfico a las APIs de Google mediante un punto final de Private Service Connect privado para tu red de VPC.

Las cargas de trabajo pueden enviar tráfico a un paquete de APIs de Google globales mediante un punto final de Private Service Connect. Además, puedes usar un backend de Private Service Connect para acceder a una sola API de Google, lo que amplía las funciones de seguridad de los balanceadores de carga a los servicios de API. En la figura 8 se muestra esta configuración.

Configuración de Private Service Connect para enviar tráfico a las APIs de Google mediante un backend de Private Service Connect.

Imagen 8. Configuración de Private Service Connect para enviar tráfico a las APIs de Google mediante un backend de Private Service Connect.

Usar Private Service Connect entre redes de VPC o entidades

Private Service Connect también permite que un productor de servicios ofrezca servicios a un consumidor de servicios en otra red de VPC, ya sea en el mismo recurso de organización o en otro. Una red VPC de un productor de servicios puede admitir varios consumidores de servicios. El consumidor puede conectarse al servicio del productor enviando tráfico a un endpoint de Private Service Connect situado en la red de VPC del consumidor. El punto final reenvía el tráfico a la red de VPC que contiene el servicio publicado.

Configuración de Private Service Connect para publicar y consumir servicios gestionados a través de un endpoint.

Imagen 9. Configuración de Private Service Connect para publicar un servicio gestionado mediante una vinculación de servicio y consumir el servicio mediante un punto final.

Acceso a servicios privados

Private Service Connect es la forma recomendada para que un productor de servicios proporcione un servicio a un consumidor de servicios. Sin embargo, Private Service Connect no es compatible con todos los servicios. Puedes usar el acceso a servicios privados para acceder a estos servicios de la lista.

Conector de acceso a VPC sin servidor

Un conector de acceso sin servidor de VPC gestiona el tráfico entre tu entorno sin servidor y tu red de VPC. Cuando creas un conector en tu Google Cloud proyecto, lo asocias a una red de VPC y a una región específicas. A continuación, puede configurar sus servicios sin servidor para que usen el conector en el tráfico de red saliente. Puedes especificar un conector mediante una subred o un intervalo CIDR. El tráfico enviado a través del conector a la red de VPC procede de la subred o del intervalo CIDR que hayas especificado, tal como se muestra en la figura 10.

Configuración del conector de acceso a VPC sin servidor para acceder a entornos sin servidor de Google Cloud mediante direcciones IP internas en tu red VPC.

Imagen 10. Configuración del conector de acceso a VPC sin servidor para acceder a entornos sin servidor mediante direcciones IP internas en tu red de VPC. Google Cloud

Los conectores de acceso a VPC sin servidor se admiten en todas las regiones que admiten Cloud Run, Cloud Run functions o el entorno estándar de App Engine. Para obtener más información, consulta la lista de servicios admitidos y protocolos de red admitidos para usar el conector de acceso a VPC sin servidor.

Salida de VPC directa

Salida de VPC directa permite que tu servicio de Cloud Run envíe tráfico a una red de VPC sin configurar un conector de acceso a VPC sin servidor.

Controles de Servicio de VPC

Controles de Servicio de VPC te ayuda a evitar la filtración de datos de servicios como Cloud Storage o BigQuery impidiendo el acceso autorizado desde Internet o desde proyectos que no forman parte de un perímetro de seguridad. Por ejemplo, imagina una situación en la que un error humano o una automatización incorrecta provoca que las políticas de gestión de identidades y accesos se definan de forma incorrecta en un servicio como Cloud Storage o BigQuery. Como resultado, los recursos de estos servicios se vuelven accesibles públicamente. En ese caso, existe el riesgo de que se expongan los datos. Si tienes estos servicios configurados como parte del perímetro de Controles de Servicio de VPC, se bloqueará el acceso de entrada a los recursos, aunque las políticas de IAM permitan el acceso.

Controles de Servicio de VPC puede crear perímetros basados en atributos de cliente, como el tipo de identidad (cuenta de servicio o usuario) y el origen de la red (dirección IP o red de VPC).

Controles de Servicio de VPC ayuda a mitigar los siguientes riesgos de seguridad:

  • Acceso desde redes no autorizadas que usan credenciales robadas.
  • Filtración externa de datos por parte de usuarios internos malintencionados o código vulnerado.
  • Exposición pública de datos privados debido a políticas de gestión de identidades y accesos mal configuradas.

En la figura 11 se muestra cómo Controles de Servicio de VPC te permite establecer un perímetro de servicio para mitigar estos riesgos.

El perímetro de servicio de VPC se amplía a entornos híbridos mediante servicios de acceso privado.

Imagen 11. El perímetro de servicio de VPC se amplía a entornos híbridos mediante servicios de acceso privado.

Si usas reglas de entrada y salida, puedes habilitar la comunicación entre dos perímetros de servicio, tal como se muestra en la figura 12.

Configurar reglas de entrada y salida para comunicarse entre perímetros de servicio.

Imagen 12. Configurar reglas de entrada y salida para comunicarse entre perímetros de servicio.

Para obtener recomendaciones detalladas sobre las arquitecturas de implementación de Controles de Servicio de VPC, consulta Diseñar y crear arquitecturas de perímetros de servicio. Para obtener más información sobre la lista de servicios compatibles con Controles de Servicio de VPC, consulte Productos admitidos y limitaciones.

Arquitectura distribuida de confianza cero

Los controles de seguridad del perímetro de red son necesarios, pero no suficientes para admitir los principios de seguridad de mínimos accesos y defensa en profundidad. Las arquitecturas distribuidas de confianza cero se basan en el perímetro de la red para aplicar la seguridad, pero no dependen únicamente de él. Como arquitecturas distribuidas, se componen de microservicios con la aplicación de la política de seguridad por servicio, una autenticación sólida y una identidad de carga de trabajo.

Puedes implementar arquitecturas distribuidas de confianza cero como servicios gestionados por Cloud Service Mesh y Anthos Service Mesh.

Cloud Service Mesh

Cloud Service Mesh proporciona una malla de microservicios de arquitectura distribuida de confianza cero mTLS lista para usar, basada en los fundamentos de Istio. Para configurar la malla, debes usar un flujo integrado. Managed Cloud Service Mesh, con planos de datos y de control gestionados por Google, se admite en GKE. También está disponible un plano de control en el clúster, que es adecuado para otros entornos, como Google Distributed Cloud o GKE Multi-Cloud. Cloud Service Mesh gestiona las identidades y los certificados, y proporciona un modelo de política de autorización basado en Istio.

Cloud Service Mesh utiliza flotas para gestionar la configuración de implementación y la identidad de servicios de varios clústeres. Al igual que con Cloud Service Mesh, cuando tus cargas de trabajo operan en un entorno de conectividad de red de VPC plana (o compartida), no hay requisitos especiales de conectividad de red más allá de la configuración del cortafuegos. Si tu arquitectura incluye varios clústeres de Cloud Service Mesh en redes de VPC o entornos de red independientes, como una conexión de Cloud Interconnect, también necesitas una pasarela este-oeste. Las prácticas recomendadas para las redes de Cloud Service Mesh son las mismas que se describen en las prácticas recomendadas para las redes de GKE.

Cloud Service Mesh también se integra con Identity-Aware Proxy (IAP). IAP te permite definir políticas de acceso detalladas para controlar el acceso de los usuarios a una carga de trabajo en función de los atributos de la solicitud de origen, como la identidad del usuario, la dirección IP y el tipo de dispositivo. Este nivel de control permite crear un entorno de confianza cero de extremo a extremo.

Debes tener en cuenta los requisitos de los clústeres de GKE cuando uses Cloud Service Mesh. Para obtener más información, consulta la sección Requisitos del artículo "Instalación de un solo proyecto en GKE".

Siguientes pasos