Herramientas de redes para el acceso seguro dentro de la nube: 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 las empresas que migran cargas de trabajo de centros de datos aGoogle Cloud.

La serie consiste en los siguientes documentos:

Las cargas de trabajo para casos de uso dentro de la nube residen en redes de VPC y necesitan conectarse a otros recursos en Google Cloud. Pueden consumir servicios que se proporcionan de forma nativa en la nube, como BigQuery. El perímetro de seguridad se proporciona mediante una variedad de capacidades propias (1P) y de terceros (3P), como firewalls, Controles del servicio de VPC y dispositivos virtuales de red.

En muchos casos, estas cargas de trabajo abarcan varias redes de VPC de Google Cloud, y los límites entre las redes de VPC deben protegerse. En este documento, se abordan estas arquitecturas de seguridad y conectividad en profundidad.

Arquitectura lift-and-shift

La primera situación para un caso de uso dentro de la nube es una arquitectura lift-and-shift en la que se mueven las cargas de trabajo establecidas a la nube tal como están.

Cloud NGFW

Puedes ayudar a establecer un perímetro seguro mediante la configuración de Cloud Next Generation Firewall. Puedes usar etiquetas, cuentas de servicio y etiquetas de red para aplicar reglas de firewall detalladas a las VMs. Para obtener lineamientos de implementación sobre cómo administrar el tráfico con Google Cloud reglas de firewall, consulta Políticas de firewall de red en el plano de bases empresariales.

También puedes usar el registro de reglas de firewall para auditar y verificar los efectos de la configuración de la regla de firewall.

Puedes usar los registros de flujo de VPC para detectar intrusiones en la red y también transmitir los registros para integrarlos a SIEM. Este sistema general puede proporcionar supervisió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 firewall pueden usar etiquetas de red para restringir el tráfico entre las VMs de una red de VPC.

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

Figura 1. Configuración de firewall 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 firewalls de aplicaciones web (WAF) o firewalls de seguridad a nivel de la aplicación. Las NVA con varias interfaces de red se pueden usar para crear un puente entre redes de VPC. Puedes usar los NVA para implementar funciones de seguridad de tráfico entre redes de VPC, en especial cuando usas una configuración de radio y concentrador, como se muestra en la figura 2.

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

Figura 2. Configuración de dispositivos de red centralizados en una red de VPC compartida.

IDS de Cloud

El Sistema de detección de intrusiones de Cloud (IDS de Cloud) te permite implementar la inspección y el registro de seguridad nativos mediante la duplicación del tráfico desde una subred en tu red de VPC. Con el IDS de Cloud, puedes inspeccionar y supervisar una amplia variedad de amenazas a nivel de red y de aplicación para su análisis. Debes crear extremos del IDS de Cloud en tu red de Google Cloud VPC. Estos extremos supervisan el tráfico de entrada y salida desde y hacia esa red, así como el tráfico de red dentro de la VPC, mediante la funcionalidad de duplicación de paquetes que está incorporada en la pila de herramientas de redes de Google Cloud . Debes habilitar el acceso privado a servicios para conectarte al proyecto del productor de servicios (el proyecto administrado por Google) que aloja los procesos del IDS de Cloud.

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

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

Figura 3. Configuración del IDS de Cloud para duplicar el tráfico de VPC que usa el acceso de servicios privados.

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

Network Connectivity Center

Network Connectivity Center es un framework de orquestación que simplifica la conectividad de red entre los recursos que están conectados a un recurso de administración central llamado concentrador. Network Connectivity Center admite los siguientes tipos de redes:

  • Google Cloud Redes de VPC
  • Redes locales y otras redes de la nube que usan Cloud Interconnect o VPN con HA
  • Conexiones encriptadas ancladas por VMs

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 en una topología de malla completa o de concentrador y radio.

Intercambio de tráfico entre redes de VPC

En el caso de las aplicaciones que abarcan varias redes de VPC, ya sea que pertenezcan al mismo Google Cloud proyecto o al mismo recurso de la organización, el intercambio de tráfico entre redes de VPC permite la conectividad entre redes de VPC. Esta conectividad permite que el tráfico permanezca dentro de la red de Google para que no se desvíe a la Internet pública.

Una arquitectura de concentrador y radio es un modelo popular para la conectividad de VPC. Este modelo es útil cuando una empresa tiene varias aplicaciones que necesitan acceder a un conjunto común de servicios, como registros o autenticación. El 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 concentrador. Para obtener orientación sobre cómo configurar una arquitectura de concentrador y radio con el intercambio de tráfico entre redes de VPC, consulta Conectividad entre VPC de redes multinube con el intercambio de tráfico entre redes de VPC.

VPC compartida

Puedes usar la VPC compartida para mantener un control centralizado sobre los recursos de red, como las subredes, las rutas y los firewalls en los proyectos host. Este nivel de control te permite implementar la práctica recomendada de seguridad de privilegio mínimo para la administración de la red, la auditoría y el control de acceso, ya que puedes delegar tareas de administración de red a administradores de red y seguridad. Puedes asignar la capacidad de crear y administrar VMs a los administradores de instancias mediante proyectos de servicio. El uso de un proyecto de servicio garantiza que los administradores de VM solo tengan la capacidad de crear y administrar instancias y que no se les permita realizar cambios en la red compartida que afecten a la red de VPC compartida.

Por ejemplo, puedes proporcionar más aislamiento si defines dos redes de VPC que se encuentran en dos proyectos host y adjuntas varios proyectos de servicio a cada red, uno para la producción y otro para las 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 de compilación de 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 proyectos de servicio y hosts aislados (entornos de prueba y producción).

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

Arquitectura de servicios híbridos

La arquitectura de servicios híbridos proporciona servicios adicionales nativos de la nube que están diseñados para permitirte conectar y proteger servicios en un entorno de varias VPC. Estos servicios nativos de la nube complementan lo que está disponible en la arquitectura lift-and-shift y pueden facilitar la administració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 aparezca en otra red de VPC. No es necesario que los servicios se alojen en el mismo recurso de la organización, por lo que se puede usar Private Service Connect para consumir de forma privada servicios de otra red de VPC, incluso si esta está conectada a otro recurso de la organización.

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

Configura Private Service Connect para acceder a las APIs de Google

Cuando usas Private Service Connect, puedes exponer las APIs de Google mediante un extremo de Private Service Connect que forma parte de la red de VPC, como se muestra en la figura 7.

Configuración de Private Service Connect para enviar tráfico a las APIs de Google con un extremo de Private Service Connect que es privado para tu red de VPC.

Figura 7. Configuración de Private Service Connect para enviar tráfico a las APIs de Google con un extremo de Private Service Connect que es privado para tu red de VPC.

Las cargas de trabajo pueden enviar tráfico a un paquete de APIs de Google globales mediante un extremo de Private Service Connect. Además, puedes usar un backend de Private Service Connect para acceder a una sola API de Google, lo que extiende las funciones de seguridad de los balanceadores de cargas 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 API de Google con un backend de Private Service Connect.

Figura 8. Configuración de Private Service Connect para enviar tráfico a las API de Google con un backend de Private Service Connect.

Usa 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 uno diferente. Una red de VPC de productor de servicios puede admitir varios consumidores de servicios. El consumidor puede conectarse al servicio del productor mediante el envío de tráfico a un extremo de Private Service Connect ubicado en la red de VPC del consumidor. El extremo 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 administrados a través de un extremo.

Figura 9. Configuración de Private Service Connect para publicar un servicio administrado a través de un adjunto de servicio y consumir el servicio a través de un extremo.

Acceso privado a servicios

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 admite todos los servicios. Puedes usar el acceso privado a los servicios para acceder a estos servicios enumerados.

Conector de acceso a VPC sin servidores

Un conector de acceso a VPC sin servidores controla el tráfico entre el entorno sin servidores y la red de VPC. Cuando creas un conector en un proyecto de Google Cloud, debes conectarlo a una red de VPC y a una región específicas. Luego, puedes configurar tus servicios sin servidores para usar el conector en el tráfico de red saliente. Puedes especificar un conector con una subred o un rango de CIDR. El tráfico que se envió a través del conector a la red de VPC se origina desde la subred o el rango de CIDR que especificaste, como se muestra en la figura 10.

Configuración del conector de acceso a VPC sin servidores para acceder a entornos sin servidores de Google Cloud mediante direcciones IP internas dentro de la red de VPC.

Figura 10. Configuración del conector de acceso a VPC sin servidores para acceder a entornos sin servidores de Google Cloud mediante direcciones IP internas dentro de tu red de VPC.

Los conectores de acceso a VPC sin servidores son compatibles con todas las regiones que admiten Cloud Run, las funciones de Cloud Run o el entorno estándar de App Engine. Si deseas obtener más información, consulta la lista de servicios compatibles y protocolos de red compatibles para usar el conector de acceso a VPC sin servidores.

Salida de VPC directa

La 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 servidores.

Controles del servicio de VPC

Los Controles del servicio de VPC te ayudan a evitar el robo de datos de servicios como Cloud Storage o BigQuery, ya que evitan los accesos autorizados 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 hacen que las políticas de IAM se establezcan de forma incorrecta en un servicio como Cloud Storage o BigQuery. Como resultado, los recursos de estos servicios se vuelven de acceso público. En ese caso, existe el riesgo de exposición de datos. Si tienes estos servicios configurados como parte del perímetro de los Controles del servicio de VPC, se bloquea el acceso de entrada a los recursos, incluso si las políticas de IAM permiten el acceso.

Los Controles del servicio de VPC pueden crear perímetros en función de los atributos del cliente, como el tipo de identidad (cuenta de servicio o usuario) y el origen de la red (dirección IP o red de VPC).

Los Controles del servicio de VPC ayudan a mitigar los siguientes riesgos de seguridad:

  • Acceso desde redes no autorizadas que usan credenciales robadas.
  • Robo de datos debido a usuarios maliciosos con información privilegiada o un código vulnerado.
  • Exposición pública de datos privados debido a políticas de IAM mal configuradas

En la Figura 11, se muestra cómo los Controles del servicio de VPC te permiten establecer un perímetro de servicio para mitigar estos riesgos.

Perímetro de servicio de VPC extendido a entornos híbridos mediante servicios de acceso privado.

Figura 11. Perímetro de servicio de VPC extendido a entornos híbridos mediante servicios de acceso privado.

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

Configuración de las reglas de entrada y salida para comunicarse entre perímetros de servicio

Figura 12. Configuración de las reglas de entrada y salida para comunicarse entre perímetros de servicio

Para obtener recomendaciones detalladas sobre las arquitecturas de implementación de Controles del servicio de VPC, consulta Diseña perímetros de servicio. Para obtener más información sobre la lista de servicios admitidos por los Controles del servicio de VPC, consulta Productos admitidos y limitaciones.

Arquitectura distribuida de confianza cero

Los controles de seguridad perimetral de la red son necesarios, pero no suficientes para admitir los principios de seguridad de privilegio mínimo y la defensa en profundidad. Las arquitecturas distribuidas de confianza cero se basan en el perímetro de la red para la aplicación de la seguridad, pero no solo dependen de él. Como arquitecturas distribuidas, están compuestas por microservicios con aplicación de la política de seguridad por servicio, autenticación sólida e identidad de la carga de trabajo.

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

Cloud Service Mesh

Cloud Service Mesh proporciona una malla de microservicios de arquitectura distribuida de confianza cero mTLS lista para usar que se basa en las bases de Istio. Configuras la malla con un flujo integrado. Cloud Service Mesh administrado, con datos administrados por Google y planos de control, se admite en GKE. También hay un plano de control en el clúster disponible, que es adecuado para otros entornos como Google Distributed Cloudises o GKE Multi-Cloud. Cloud Service Mesh administra la identidad y los certificados, lo que proporciona un modelo de política de autorización basado en Istio.

Cloud Service Mesh se basa en flotas para administrar la identidad y la configuración de implementación del servicio 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 de conectividad de red especiales más allá de la configuración de firewall. Cuando la arquitectura incluye varios clústeres de Cloud Service Mesh en redes de VPC o entornos de red independientes, como en una conexión de Cloud Interconnect, también necesitas una puerta de enlace este-oeste. Las prácticas recomendadas de las herramientas de redes de Cloud Service Mesh son las mismas que se describen en Prácticas recomendadas para las herramientas de redes de GKE.

Cloud Service Mesh también se integra en Identity-Aware Proxy (IAP). IAP te permite configurar políticas de acceso detalladas para que puedas 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 habilita un entorno de extremo a extremo de confianza cero.

Debes considerar los requisitos del clúster de GKE cuando usas Cloud Service Mesh. Para obtener más información, consulta la sección Requisitos en la documentación “Instalación de un solo proyecto en GKE”.

¿Qué sigue?