Patrones de arquitectura de herramientas de redes seguras de nubes híbridas y múltiples

Last reviewed 2025-01-23 UTC

Este documento es el tercero de un conjunto de tres. Se analizan los patrones de arquitectura de redes híbridas y de múltiples nubes. En esta parte, se exploran varios patrones de arquitectura de red segura comunes que puedes usar para arquitecturas híbridas y de múltiples nubes. Se describen las situaciones para las que estos patrones de herramientas de redes son más adecuados y se proporcionan prácticas recomendadas para implementarlos con Google Cloud.

El conjunto de documentos sobre patrones de arquitectura híbrida y de múltiples nubes consta de las siguientes partes:

  • Compila arquitecturas híbridas y de múltiples nubes: Se analiza la planificación de una estrategia para diseñar una configuración de nube híbrida y múltiples nubes con Google Cloud.
  • Patrones de arquitectura híbrida y de múltiples nubes: se analizan patrones de arquitectura comunes para adoptar como parte de una estrategia de nube híbrida y multinube.
  • Patrones de arquitectura de herramientas de redes seguras de nubes híbridas y múltiples: Se analizan los patrones de arquitectura de redes híbridas y de múltiples nubes desde la perspectiva de las herramientas de redes (este documento).

Conectar entornos de computación privados a Google Cloud de forma segura y confiable es fundamental para cualquier arquitectura híbrida y de múltiples nubes exitosa. La conectividad de redes híbridas y el patrón de arquitectura de redes en la nube que elijas para una configuración híbrida y de múltiples nubes deben cumplir con los requisitos únicos de tus cargas de trabajo empresariales. También debe adaptarse a los patrones de arquitectura que pretendes aplicar. Aunque es posible que debas adaptar cada diseño, existen patrones comunes que puedes usar como modelo.

Los patrones de arquitectura de redes de este documento no deben considerarse alternativas al diseño de la zona de destino en Google Cloud. En su lugar, debes diseñar e implementar los patrones de arquitectura que selecciones como parte del diseño general de la zona de destino Google Cloud , que abarca las siguientes áreas:

  • Identidades
  • Administración de recursos
  • Seguridad
  • Redes
  • Supervisión

Las diferentes aplicaciones pueden usar diferentes patrones de arquitectura de redes, que se incorporan como parte de una arquitectura de zona de destino. En una configuración de múltiples nubes, debes mantener la coherencia del diseño de la zona de destino en todos los entornos.

Esta serie contiene las siguientes páginas:

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de Atención al Cliente para Socios

Otros colaboradores:

Patrones de arquitectura

En los documentos de esta serie, se analizan los patrones de arquitectura de redes diseñados en función de los modelos de comunicación requeridos entre las aplicaciones que residen en Google Cloud y en otros entornos (locales, en otras nubes o ambos).

Estos patrones se deben incorporar a la arquitectura general de la zona de destino de la organización, que puede incluir varios patrones de redes para abordar los requisitos específicos de comunicación y seguridad de diferentes aplicaciones.

En los documentos de esta serie, también se analizan las diferentes variaciones de diseño que se pueden usar con cada patrón de arquitectura. Los siguientes patrones de redes pueden ayudarte a cumplir con los requisitos de comunicación y seguridad de tus aplicaciones:

Patrón duplicado

El patrón duplicado se basa en replicar el diseño de un entorno o entornos existentes determinados en un entorno o entornos nuevos. Por lo tanto, este patrón se aplica principalmente a las arquitecturas que siguen el patrón de híbrido de entorno. En ese patrón, ejecutas tus cargas de trabajo de desarrollo y prueba en un entorno, mientras que ejecutas tus cargas de trabajo de producción y de etapa de prueba en otro.

El patrón duplicado supone que las cargas de trabajo de prueba y de producción no deben comunicarse directamente entre sí. Sin embargo, debería ser posible implementar y administrar ambos grupos de cargas de trabajo de manera coherente.

Si usas este patrón, conecta los dos entornos de computación de manera tal que se cumplan los siguientes requisitos:

  • La integración continua/implementación continua (CI/CD) puede implementar y administrar cargas de trabajo en todos los entornos de computación o en entornos específicos.
  • Los sistemas de supervisión, administración de la configuración y otros sistemas administrativos deben funcionar en todos los entornos de computación.
  • Las cargas de trabajo no pueden comunicarse directamente entre los entornos de computación. Si es necesario, la comunicación debe ser detallada y controlada.

Arquitectura

En el siguiente diagrama de arquitectura, se muestra una arquitectura de referencia de alto nivel de este patrón que admite CI/CD, supervisión, administración de la configuración, otros sistemas administrativos y comunicación de cargas de trabajo:

Los datos fluyen entre una VPC de CI/CD y una de administrador en Google Cloud , y un entorno de producción local. Los datos también fluyen entre la VPC de CI/CD y los entornos de desarrollo y prueba dentro de Google Cloud.

La descripción de la arquitectura en el diagrama anterior es la siguiente:

  • Las cargas de trabajo se distribuyen según los entornos funcionales (desarrollo, pruebas, herramientas administrativas y de CI/CD) en diferentes VPCs del lado de Google Cloud .
  • La VPC compartida se usa para las cargas de trabajo de desarrollo y prueba. Se usa una VPC adicional para las herramientas administrativas y de CI/CD. Con las VPC compartidas, puedes hacer lo siguiente:
    • Las aplicaciones son administradas por diferentes equipos por entorno y por proyecto de servicio.
    • El proyecto host administra y controla la comunicación de red y los controles de seguridad entre los entornos de desarrollo y prueba, así como fuera de la VPC.
  • La VPC de CI/CD está conectada a la red que ejecuta las cargas de trabajo de producción en tu entorno de computación privado.
  • Las reglas de firewall solo permiten el tráfico autorizado.
    • También puedes usar Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para implementar la inspección profunda de paquetes para la prevención de amenazas sin cambiar el diseño ni el enrutamiento. Cloud Next Generation Firewall Enterprise funciona creando extremos de firewall zonales administrados por Google que usan tecnología de interceptación de paquetes para inspeccionar con transparencia las cargas de trabajo en busca de las firmas de amenazas configuradas. También protege las cargas de trabajo contra amenazas.
  • Permite la comunicación entre las VPC con intercambio de tráfico a través de direcciones IP internas.
    • El intercambio de tráfico en este patrón permite que los sistemas administrativos y de CI/CD implementen y administren las cargas de trabajo de desarrollo y de prueba.
  • Considera estas prácticas recomendadas generales.

Establece esta conexión de CI/CD con una de las opciones de conectividad de redes híbridas y de múltiples nubes que se analizaron y que cumplen con los requisitos de tu empresa y tus aplicaciones. Para permitirte implementar y administrar cargas de trabajo de producción, esta conexión proporciona accesibilidad a la red privada entre los diferentes entornos de computación. Todos los entornos deben tener un espacio de direcciones IP RFC 1918 sin superposición.

Si las instancias en los entornos de desarrollo y pruebas requieren acceso a Internet, considera las siguientes opciones:

  • Puedes implementar Cloud NAT en la misma red del proyecto host de la VPC compartida. La implementación en la misma red del proyecto host de VPC compartida ayuda a evitar que se pueda acceder a estas instancias directamente desde Internet.
  • Para el tráfico web saliente, puedes usar el proxy web seguro. El proxy ofrece varios beneficios.

Para obtener más información sobre las herramientas y capacidades de Google Cloud que te ayudan a compilar, probar y realizar implementaciones en Google Cloud y en entornos híbridos y de múltiples nubes, consulta el blog DevOps y CI/CD en Google Cloud explicados.

Variantes

Para cumplir con diferentes requisitos de diseño y, al mismo tiempo, tener en cuenta todos los requisitos de comunicación, el patrón de arquitectura duplicada ofrece las siguientes opciones, que se describen en las secciones a continuación:

VPC compartida por entorno

La opción de diseño de VPC compartida por entorno permite la separación a nivel de la aplicación o del servicio en todos los entornos, incluidas las herramientas administrativas y de CI/CD que podrían ser necesarias para cumplir con ciertos requisitos de seguridad de la organización. Estos requisitos limitan la comunicación, el dominio administrativo y el control de acceso para los diferentes servicios que también deben administrar diferentes equipos.

Este diseño logra la separación proporcionando aislamiento a nivel de la red y del proyecto entre los diferentes entornos, lo que permite una comunicación más detallada y un control de acceso de Identity and Access Management (IAM).

Desde una perspectiva de administración y operaciones, este diseño proporciona la flexibilidad necesaria para administrar las aplicaciones y las cargas de trabajo creadas por diferentes equipos por entorno y por proyecto de servicio. Los equipos de operaciones de redes pueden aprovisionar y administrar las redes de VPC y sus funciones de seguridad según las siguientes estructuras posibles:

  • Un equipo administra todos los proyectos host en todos los entornos.
  • Diferentes equipos administran los proyectos host en sus respectivos entornos.

Las decisiones sobre la administración de proyectos host deben basarse en la estructura del equipo, las operaciones de seguridad y los requisitos de acceso de cada equipo. Puedes aplicar esta variación de diseño a la opción de diseño de zona de destino de red de VPC compartida para cada entorno. Sin embargo, debes tener en cuenta los requisitos de comunicación del patrón duplicado para definir qué comunicación se permite entre los diferentes entornos, incluida la comunicación a través de la red híbrida.

También puedes aprovisionar una red de VPC compartida para cada entorno principal, como se ilustra en el siguiente diagrama:

El intercambio de tráfico entre VPC en Google Cloud comparte datos entre los entornos de desarrollo y pruebas, y las subredes administrativas y de CI/CD. Las subredes comparten datos entre Google Cloud y un entorno local.

Firewall centralizado de la capa de aplicación

En algunas situaciones, los requisitos de seguridad pueden exigir la consideración de la capa de aplicación (capa 7) y la inspección profunda de paquetes con mecanismos avanzados de firewall que superen las capacidades de Cloud Next Generation Firewall. Para cumplir con los requisitos y estándares de seguridad de tu organización, puedes usar un dispositivo NGFW alojado en un dispositivo virtual de red (NVA). Varios Google Cloud socios de seguridad ofrecen opciones adecuadas para esta tarea.

Como se ilustra en el siguiente diagrama, puedes colocar la NVA en la ruta de red entre la nube privada virtual y el entorno de computación privado con varias interfaces de red.

El intercambio de tráfico entre VPC en Google Cloud comparte datos entre los entornos de desarrollo y prueba, y las subredes administrativas y de CI/CD. Las subredes comparten datos entre Google Cloud y un entorno local a través de una red de VPC de tránsito.

Este diseño también se puede usar con varias VPC compartidas, como se ilustra en el siguiente diagrama.

El intercambio de tráfico entre VPC en Google Cloud comparte datos entre los entornos de desarrollo y pruebas, y las subredes administrativas y de CI/CD. Las subredes usan una NVA para compartir datos entre Google Cloud y un entorno local a través de una red de VPC de tránsito.

La NVA en este diseño actúa como la capa de seguridad perimetral. También sirve como base para habilitar la inspección de tráfico intercalada y aplicar políticas estrictas de control de acceso.

Para una estrategia de seguridad sólida de varias capas que incluya reglas de firewall de VPC y capacidades de servicio de prevención de intrusiones, incluye una mayor inspección del tráfico y control de seguridad para los flujos de tráfico este-oeste y norte-sur.

Topología de concentrador y radio

Otra posible variación de diseño es usar VPCs independientes (incluidas las VPCs compartidas) para el desarrollo y las diferentes etapas de prueba. En esta variación, como se muestra en el siguiente diagrama, todos los entornos de etapa de desarrollo se conectan con la VPC administrativa y de CI/CD en una arquitectura de concentrador y radio. Usa esta opción si debes separar los dominios administrativos y las funciones en cada entorno. El modelo de comunicación de concentrador y radio puede ayudar con los siguientes requisitos:

  • Las aplicaciones deben acceder a un conjunto común de servicios, como supervisión, herramientas de administración de configuración, CI/CD o autenticación.
  • Se debe aplicar un conjunto común de políticas de seguridad al tráfico entrante y saliente de forma centralizada a través del concentrador.

Para obtener más información sobre las opciones de diseño de concentrador y radio, consulta Topología de concentrador y radio con dispositivos centralizados y Topología de concentrador y radio sin dispositivos centralizados.

Los entornos de desarrollo y pruebas comparten datos con una VPC de CI/CD central y una VPC de administrador en un entorno local.

Como se muestra en el diagrama anterior, la comunicación entre VPC y la conectividad híbrida pasan por la VPC central. Como parte de este patrón, puedes controlar y restringir la comunicación en la VPC del concentrador para que se alinee con tus requisitos de conectividad.

Como parte de la arquitectura de red de concentrador y radio, las siguientes son las principales opciones de conectividad (entre las VPC de radio y de concentrador) en Google Cloud:

  • Intercambio de tráfico entre redes de VPC
  • VPN
  • Uso de un dispositivo virtual de red (NVA)

Para obtener más información sobre qué opción debes considerar en tu diseño, consulta Arquitectura de red de concentrador y radio. Un factor clave que influye en la selección de VPN en lugar del intercambio de tráfico entre VPCs entre las VPCs radiales y la VPC central es cuando se requiere la transitividad del tráfico. La transitividad del tráfico significa que el tráfico de un radio puede llegar a otros radios a través del concentrador.

Arquitectura distribuida de confianza cero de microservicios

Las arquitecturas híbridas y de múltiples nubes pueden requerir varios clústeres para lograr sus objetivos técnicos y comerciales, incluida la separación del entorno de producción de los entornos de desarrollo y pruebas. Por lo tanto, los controles de seguridad del perímetro de la red son importantes, en especial cuando se requieren para cumplir con ciertos requisitos de seguridad.

No basta con admitir los requisitos de seguridad de las arquitecturas de microservicios distribuidas actuales que priorizan la nube, sino que también debes considerar las arquitecturas distribuidas de confianza cero. La arquitectura distribuida de confianza cero de microservicios admite tu arquitectura de microservicios con aplicación de la política de seguridad a nivel del microservicio, autenticación e identidad de la carga de trabajo. La confianza se basa en la identidad y se aplica para cada servicio.

Con una arquitectura de proxy distribuido, como una malla de servicios, los servicios pueden validar de manera eficaz a los llamadores y aplicar políticas de control de acceso detalladas para cada solicitud, lo que permite un entorno de microservicios más seguro y escalable. Cloud Service Mesh te brinda la flexibilidad de tener una malla común que puede abarcar tus implementacionesGoogle Cloud y locales. La malla usa políticas de autorización para ayudar a proteger las comunicaciones de servicio a servicio.

También puedes incorporar Apigee Adapter for Envoy, que es una implementación de puerta de enlace de API de Apigee liviana dentro de un clúster de Kubernetes, con esta arquitectura. El adaptador de Apigee para Envoy es un proxy de servicio y de código abierto diseñado para las aplicaciones centradas en la nube.

Los datos fluyen entre los servicios en Google Cloud y un entorno local a través de una arquitectura de proxy distribuida.

Para obtener más información sobre este tema, consulta los siguientes artículos:

Prácticas recomendadas para patrones duplicados

  • Los sistemas de CI/CD necesarios para implementar o reconfigurar implementaciones de producción deben tener alta disponibilidad, lo que significa que todos los componentes de la arquitectura deben diseñarse para proporcionar el nivel esperado de disponibilidad del sistema. Para obtener más información, consulta Google Cloud confiabilidad de la infraestructura.
  • Para eliminar los errores de configuración en procesos repetidos, como las actualizaciones de código, la automatización es fundamental para estandarizar tus compilaciones, pruebas e implementaciones.
  • La integración de NVAs centralizadas en este diseño puede requerir la incorporación de varios segmentos con diferentes niveles de controles de acceso de seguridad.
  • Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño e implementación de alta disponibilidad y redundancia que te proporciona tu proveedor de NVA.
  • Si no exportas las rutas IP locales a través del intercambio de tráfico entre VPCs o la VPN a la VPC de desarrollo y pruebas, puedes restringir la accesibilidad a la red desde los entornos de desarrollo y pruebas al entorno local. Para obtener más información, consulta Intercambio de rutas personalizadas del intercambio de tráfico entre redes de VPC.
  • Para las cargas de trabajo con direcciones IP privadas que pueden requerir acceso a las APIs de Google, puedes exponer las APIs de Google con un extremo de Private Service Connect dentro de una red de VPC. Para obtener más información, consulta Ingreso controlado en esta serie.
  • Revisa las prácticas recomendadas generales para los patrones de arquitectura de redes híbridas y de múltiples nubes.

Patrón de malla

El patrón en malla se basa en el establecimiento de una arquitectura de red híbrida. Esa arquitectura abarca varios entornos de procesamiento. En estos entornos, todos los sistemas pueden comunicarse entre sí y no se limitan a la comunicación unidireccional según los requisitos de seguridad de tus aplicaciones. Este patrón de redes se aplica principalmente a las arquitecturas híbridas en niveles, de múltiples nubes particionadas o con aumentos de actividad. También se aplica al diseño de continuidad empresarial para aprovisionar un entorno de recuperación ante desastres (DR) en Google Cloud. En todos los casos, se requiere que conectes los entornos de computación de manera tal que se cumplan los siguientes requisitos de comunicación:

  • Las cargas de trabajo pueden comunicarse entre sí a través de los límites del entorno con direcciones IP RFC 1918 privadas.
  • La comunicación se puede iniciar desde cualquier lado. Los detalles del modelo de comunicaciones pueden variar según las aplicaciones y los requisitos de seguridad, como los modelos de comunicaciones que se analizan en las siguientes opciones de diseño.
  • Las reglas de firewall que uses deben permitir el tráfico entre direcciones IP de origen y destino específicas según los requisitos de la aplicación o las aplicaciones para las que se diseñó el patrón. Lo ideal es que puedas usar un enfoque de seguridad de varias capas para restringir los flujos de tráfico de manera detallada, tanto entre los entornos de computación como dentro de ellos.

Arquitectura

En el siguiente diagrama, se ilustra una arquitectura de referencia de alto nivel del patrón en malla.

Los datos de una arquitectura de red híbrida fluyen desde dos subredes en Google Cloud a una carga de trabajo en un entorno local.

  • Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.
  • Del lado de Google Cloud , puedes implementar cargas de trabajo en una o varias VPCs compartidas o no compartidas. Para conocer otras opciones de diseño posibles de este patrón, consulta las variaciones de diseño que se muestran a continuación. La estructura seleccionada de tus VPCs debe alinearse con los proyectos y el diseño de la jerarquía de recursos de tu organización.
  • La red de VPC de Google Cloud se extiende a otros entornos de procesamiento. Esos entornos pueden ser locales o estar en otra nube. Usa una de las opciones de conectividad de redes híbridas y de múltiples nubes que cumplan con los requisitos de tu empresa y tu aplicación.

  • Limita las comunicaciones solo a las direcciones IP permitidas de tus fuentes y destinos. Usa cualquiera de las siguientes capacidades o una combinación de ellas:

    • Reglas de firewall o políticas de firewall.

    • Dispositivo virtual de red (NVA) con funciones de inspección de firewall de nueva generación (NGFW) que se colocan en la ruta de red.

    • Cloud Next Generation Firewall Enterprise con servicio de prevención de intrusiones (IPS) para implementar una inspección profunda de paquetes para la prevención de amenazas sin cambiar el diseño de la red ni el enrutamiento.

Variantes

El patrón de arquitectura en malla se puede combinar con otros enfoques para satisfacer diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación del patrón. Las opciones de patrones se describen en las siguientes secciones:

Una VPC por entorno

Estos son los motivos comunes para considerar la opción de una VPC por entorno:

  • El entorno de nube requiere la separación a nivel de red de las redes y los recursos de la VPC, en consonancia con el diseño de la jerarquía de recursos de tu organización. Si se requiere la separación de dominios administrativos, también se puede combinar con un proyecto independiente por entorno.
    • Para administrar de forma centralizada los recursos de red en una red común y proporcionar aislamiento de red entre los diferentes entornos, usa una VPC compartida para cada entorno que tengas en Google Cloud, como desarrollo, pruebas y producción.
  • Requisitos de escalamiento que podrían superar las cuotas de VPC para una sola VPC o proyecto

Como se ilustra en el siguiente diagrama, el diseño de una VPC por entorno permite que cada VPC se integre directamente con el entorno local o con otros entornos de nube a través de VPNs o un Cloud Interconnect con varios adjuntos de VLAN.

Los datos de una arquitectura de red híbrida con una VPC en cada entorno fluyen desde dos subredes en Google Cloud a una carga de trabajo en un entorno local.

El patrón que se muestra en el diagrama anterior se puede aplicar en una topología de red de concentrador y radio de zona de destino. En esa topología, se puede compartir una (o varias) conexiones híbridas con todas las VPCs radiales. Se comparte a través de una VPC de tránsito para finalizar la conectividad híbrida y las otras VPC de radio. También puedes expandir este diseño agregando un NVA con capacidades de inspección de firewall de nueva generación (NGFW) en la VPC de tránsito, como se describe en la siguiente sección, "Usa un firewall centralizado de capa de aplicación".

Usa un firewall de capa de aplicación centralizado

Si tus requisitos técnicos exigen considerar la capa de aplicación (capa 7) y la inspección profunda de paquetes con capacidades avanzadas de firewall que superen las capacidades de Cloud Next Generation Firewall, puedes usar un dispositivo NGFW alojado en un NVA. Sin embargo, esa NVA debe satisfacer las necesidades de seguridad de tu organización. Para implementar estos mecanismos, puedes extender la topología a fin de pasar todo el tráfico entre entornos a través de un firewall de NVA centralizado, como se muestra en el siguiente diagrama.

Puedes aplicar el patrón del siguiente diagrama al diseño de la zona de destino con una topología de concentrador y radio con dispositivos centralizados:

Los datos de dos VPC compartidas en Google Cloud fluyen a través de una NVA a una red de VPC de tránsito y a una carga de trabajo en un entorno local.

Como se muestra en el diagrama anterior, la VNA actúa como la capa de seguridad perimetral y sirve como base para habilitar la inspección de tráfico intercalada. También aplica políticas de control de acceso estrictas. Para inspeccionar los flujos de tráfico de este a oeste y de norte a sur, el diseño de una NVA centralizada podría incluir varios segmentos con diferentes niveles de controles de acceso de seguridad.

Arquitectura distribuida de confianza cero de microservicios

Cuando se usan aplicaciones alojadas en contenedores, la arquitectura distribuida de confianza cero de microservicios que se analizó en la sección del patrón duplicado también se aplica a este patrón de arquitectura.

La diferencia clave entre este patrón y el patrón reflejado es que el modelo de comunicación entre las cargas de trabajo en Google Cloud y otros entornos se puede iniciar desde cualquier lado. El tráfico debe controlarse y ser detallado, según los requisitos de la aplicación y los requisitos de seguridad con Service Mesh.

Prácticas recomendadas para el patrón de malla

  • Antes de hacer cualquier otra cosa, decide el diseño de tu jerarquía de recursos y el diseño necesario para admitir cualquier proyecto y VPC. Esto puede ayudarte a seleccionar la arquitectura de redes óptima que se alinea con la estructura de tus proyectos de Google Cloud .
  • Usa una arquitectura distribuida de confianza cero cuando uses Kubernetes en tu entorno de computación privado yGoogle Cloud.
  • Cuando uses NVAs centralizadas en tu diseño, debes definir varios segmentos con diferentes niveles de controles de acceso de seguridad y políticas de inspección de tráfico. Basa estos controles y políticas en los requisitos de seguridad de tus aplicaciones.
  • Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño y de implementación de HA y redundancia que proporciona el Google Cloud proveedor de seguridad que suministra tus NVA.
  • Para proporcionar mayor privacidad, integridad de los datos y un modelo de comunicación controlado, expón las aplicaciones a través de las APIs con puertas de enlace de API, como Apigee y Apigee hybrid con mTLS de extremo a extremo. También puedes usar una VPC compartida con Apigee en el mismo recurso de organización.
  • Si el diseño de tu solución requiere exponer una aplicación basada en Google Clouda la Internet pública, considera las recomendaciones de diseño que se analizan en Redes para la entrega de aplicaciones orientadas a Internet.
  • Para proteger los servicios de Google Cloud en tus proyectos y mitigar el riesgo de robo de datos, usa los Controles del servicio de VPC para especificar perímetros de servicio a nivel del proyecto o de la red de VPC. Además, puedes extender los perímetros de servicio a un entorno híbrido a través de una VPN autorizada o con Cloud Interconnect. Para obtener más información sobre los beneficios de los perímetros de servicio, consulta la Descripción general de los Controles del servicio de VPC.
  • Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.

Si pretendes aplicar un aislamiento más estricto y un acceso más detallado entre tus aplicaciones alojadas en Google Cloudy en otros entornos, considera usar uno de los patrones cerrados que se analizan en los otros documentos de esta serie.

Patrones cerrados

El patrón cerrado se basa en una arquitectura que expone aplicaciones y servicios seleccionados de manera detallada, según las APIs o los extremos expuestos específicos entre los diferentes entornos. En esta guía, se clasifica este patrón en tres opciones posibles, cada una determinada por el modelo de comunicación específico:

Como se mencionó antes en esta guía, los patrones de arquitectura de red que se describen aquí se pueden adaptar a varias aplicaciones con requisitos diversos. Para abordar las necesidades específicas de las diferentes aplicaciones, la arquitectura de la zona de destino principal puede incorporar un patrón o una combinación de patrones de forma simultánea. La implementación específica de la arquitectura seleccionada se determina según los requisitos de comunicación específicos de cada patrón cerrado.

En esta serie, se analiza cada patrón cerrado y sus posibles opciones de diseño. Sin embargo, una opción de diseño común aplicable a todos los patrones cerrados es la arquitectura distribuida de confianza cero para aplicaciones alojadas en contenedores con arquitectura de microservicios. Esta opción cuenta con la tecnología de Cloud Service Mesh, Apigee y Apigee Adapter for Envoy, una implementación de puerta de enlace básica de Apigee en un clúster de Kubernetes. El adaptador de Apigee para Envoy es un proxy de servicio y de código abierto popular diseñado para las aplicaciones centradas en la nube. Este control de arquitectura permitió las comunicaciones seguras de servicio a servicio y la dirección de la comunicación a nivel de servicio. Las políticas de comunicación de tráfico se pueden diseñar, ajustar y aplicar a nivel de servicio según el patrón seleccionado.

Los patrones cerrados permiten la implementación de Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para realizar una inspección profunda de paquetes para la prevención de amenazas sin ningún diseño ni modificaciones de enrutamiento. Esa inspección está sujeta a las aplicaciones específicas a las que se accede, el modelo de comunicación y los requisitos de seguridad. Si los requisitos de seguridad exigen una inspección profunda de paquetes y una capa 7 con mecanismos avanzados de firewall que superan las capacidades de Cloud Next Generation Firewall, puedes usar un firewall centralizado de última generación (NGFW) alojado en un dispositivo virtual de red (NVA) Varios Google Cloud socios de seguridad ofrecen dispositivos NGFW que pueden cumplir con tus requisitos de seguridad. La integración de NVAs con estos patrones cerrados puede requerir la introducción de varias zonas de seguridad dentro del diseño de red, cada una con niveles de control de acceso distintos.

Salida cerrada

La arquitectura del patrón de redes de salida cerrada se basa en la exposición de APIs seleccionadas del entorno local o de otro entorno de nube a las cargas de trabajo implementadas en Google Cloud. Lo hace sin exponerlos directamente a la Internet pública desde un entorno local o desde otros entornos de nube. Puedes facilitar esta exposición limitada a través de una puerta de enlace de API o un proxy, o un balanceador de cargas que actúe como una fachada para las cargas de trabajo existentes. Puedes implementar la funcionalidad de la puerta de enlace de API en un segmento de red perimetral aislado, como una red perimetral.

El patrón de red de salida cerrada se aplica principalmente, entre otros, a patrones de arquitectura de aplicaciones en niveles y a patrones de arquitectura de aplicación particionada. Cuando implementas cargas de trabajo de backend dentro de una red interna, las redes de salida controlada ayudan a mantener un mayor nivel de seguridad dentro de tu entorno de computación local. El patrón requiere que conectes los entornos de computación de manera tal que se cumplan los siguientes requisitos de comunicación:

  • Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API o el balanceador de cargas (o un extremo de Private Service Connect) que expone la aplicación a través de direcciones IP internas.
  • No se puede acceder a otros sistemas en el entorno de computación privado directamente desde Google Cloud.
  • No se permite la comunicación del entorno de computación privado a ninguna carga de trabajo implementada en Google Cloud .
  • El tráfico a las APIs privadas en otros entornos solo se inicia desde el entorno de Google Cloud .

El enfoque de esta guía está en los entornos híbridos y de múltiples nubes conectados a través de una red híbrida privada. Si los requisitos de seguridad de tu organización lo permiten, se puede acceder directamente a las llamadas de API a la API de destino remoto con direcciones IP públicas a través de Internet. Sin embargo, debes tener en cuenta los siguientes mecanismos de seguridad:

  • API de OAuth 2.0 con seguridad de la capa de transporte (TLS).
  • Límite de frecuencia.
  • Políticas de protección contra las amenazas.
  • TLS mutua configurada en el backend de la capa de la API
  • El filtrado de la lista de entidades permitidas de direcciones IP está configurado para permitir solo la comunicación con fuentes y destinos de API predefinidos desde ambos lados.

Para proteger un proxy de API, considera estos otros aspectos de seguridad. Para obtener más información, consulta Prácticas recomendadas para proteger tus aplicaciones y APIs a través de Apigee.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de referencia que admite los requisitos de comunicación que se mencionaron en la sección anterior:

Los datos fluyen en una sola dirección, desde un proyecto host en Google Cloud hasta una carga de trabajo en un entorno local.

Los datos fluyen a través del diagrama anterior de la siguiente manera:

  • Del lado de Google Cloud , puedes implementar cargas de trabajo en nubes privadas virtuales (VPC). Las VPCs pueden ser una o varias (compartidas o no compartidas). La implementación debe alinearse con los proyectos y el diseño de la jerarquía de recursos de tu organización.
  • Las redes de VPC del entorno Google Cloud se extienden a los demás entornos de procesamiento. Los entornos pueden ser locales o estar en otra nube. Para facilitar la comunicación entre entornos con direcciones IP internas, usa una conectividad de redes híbridas y de múltiples nubes adecuada.

  • Para limitar el tráfico que se origina en direcciones IP de VPCs específicas y que está destinado a puertas de enlace o balanceadores de cargas remotos, usa el filtrado de listas de direcciones IP permitidas. El tráfico de retorno de estas conexiones se permite cuando se usan reglas de firewall con estado. Puedes usar cualquier combinación de las siguientes capacidades para proteger y limitar las comunicaciones solo a las direcciones IP de origen y destino permitidas:

  • Todos los entornos comparten un espacio de direcciones IP RFC 1918 sin superposición.

Variantes

El patrón de arquitectura de salida controlada se puede combinar con otros enfoques para satisfacer diferentes requisitos de diseño que aún consideran los requisitos de comunicación de este patrón. El patrón ofrece las siguientes opciones:

Usa la puerta de enlace de la API de Google Cloud y el frontend global

Datos que fluyen en Google Cloud desde Apigee a la VPC de un proyecto del cliente y, luego, fuera de Cloud a un entorno local o a otra instancia de nube.

Con este enfoque de diseño, la exposición y la administración de la API residen enGoogle Cloud. Como se muestra en el diagrama anterior, puedes lograr esto implementando Apigee como la plataforma de API. La decisión de implementar una puerta de enlace de API o un balanceador de cargas en el entorno remoto depende de tus necesidades específicas y de la configuración actual. Apigee proporciona dos opciones para aprovisionar la conectividad:

  • Con intercambio de tráfico entre VPC
  • Sin intercambio de tráfico de VPC

Google Cloud Las capacidades de frontend global de Google Cloud, como Cloud Load Balancing, Cloud CDN (cuando se accede a través de Cloud Interconnect) y Cross‑Cloud Interconnect, mejoran la velocidad con la que los usuarios pueden acceder a las aplicaciones que tienen backends alojados en tu entorno en entornos locales y en otros entornos de nube.

La optimización de las velocidades de entrega de contenido se logra entregando esas aplicaciones desde Google Cloud puntos de presencia (PoP). Google Cloud Los PoP están presentes en más de180 intercambios de Internet y en más de 160 instalaciones de interconexión en todo el mundo.

Si deseas ver cómo los PoP ayudan a entregar APIs de alto rendimiento cuando se usa Apigee con Cloud CDN para lograr lo siguiente, mira Entrega API de alto rendimiento con Apigee y Cloud CDN en YouTube:

  • Reduce la latencia.
  • Aloja las APIs en todo el mundo.
  • Aumenta la disponibilidad para el tráfico máximo.

El ejemplo de diseño que se ilustra en el diagrama anterior se basa en Private Service Connect sin intercambio de tráfico entre VPCs.

La red ascendente de este diseño se establece a través de lo siguiente:

  • Un balanceador de cargas (LB en el diagrama), en el que finalizan las solicitudes del cliente, procesa el tráfico y, luego, lo enruta a un backend de Private Service Connect.
  • Un backend de Private Service Connect permite que un balanceador de cargas Google Cloud envíe solicitudes de clientes a través de una conexión de Private Service Connect asociada a un adjunto de servicio del productor al servicio publicado (instancia de tiempo de ejecución de Apigee) con grupos de extremos de red (NEG) de Private Service Connect.

Las redes descendentes se establecen a través de lo siguiente:

  • Un extremo de Private Service Connect que hace referencia a un adjunto de servicio asociado con un balanceador de cargas interno (ILB en el diagrama) en la VPC del cliente.

  • El ILB se implementa con grupos de extremos de red de conectividad híbrida (NEG de conectividad híbrida).

  • Se accede a los servicios híbridos a través del NEG de conectividad híbrida a través de una conectividad de red híbrida, como VPN o Cloud Interconnect.

Para obtener más información, consulta Configura un balanceador de cargas de red del proxy interno regional con conectividad híbrida y Patrones de implementación de Private Service Connect.

Expón servicios remotos con Private Service Connect

Datos que fluyen desde Google Cloud a un entorno local o a otra nube, después de originarse en una carga de trabajo en una VPC y pasar a través de Cloud Load Balancing, un NEG de conectividad híbrida y una Cloud VPN o interconexión.

Usa la opción Private Service Connect para exponer servicios remotos en los siguientes casos:

  • No usas una plataforma de API o deseas evitar conectar tu red de VPC completa directamente a un entorno externo por los siguientes motivos:
    • Tienes restricciones de seguridad o requisitos de cumplimiento.
    • Tienes una superposición de rangos de direcciones IP, como en una situación de fusión y adquisición.
  • Para habilitar comunicaciones unidireccionales seguras entre clientes, aplicaciones y servicios en los diferentes entornos, incluso cuando tienes un plazo corto.
  • Es posible que debas proporcionar conectividad a varias VPC de consumidor a través de una VPC de productor de servicios (VPC de tránsito) para ofrecer modelos de servicio multiusuario o de usuario único con alta escalabilidad para alcanzar los servicios publicados en otros entornos.

El uso de Private Service Connect para aplicaciones que se consumen como APIs proporciona una dirección IP interna para las aplicaciones publicadas, lo que permite el acceso seguro dentro de la red privada en todas las regiones y a través de la conectividad híbrida. Esta abstracción facilita la integración de recursos de diversas nubes y entornos locales a través de un modelo de conectividad híbrida y de múltiples nubes. Puedes acelerar la integración de aplicaciones y exponer de forma segura las aplicaciones que residen en un entorno local o en otro entorno de nube mediante Private Service Connect en publica el servicio con acceso detallado. En este caso, puedes usar la siguiente opción:

En el diagrama anterior, las cargas de trabajo de la red de VPC de tu aplicación pueden acceder a los servicios híbridos que se ejecutan en tu entorno local o en otros entornos de nube a través del extremo de Private Service Connect, como se ilustra en el siguiente diagrama. Esta opción de diseño para comunicaciones unidireccionales proporciona una alternativa al intercambio de tráfico con una VPC de tránsito.

Datos que fluyen a través de varias VPC dentro de Google Cloud y entre ellas antes de salir a través de Cloud VPN o Cloud Interconnect hacia un entorno local o a otra nube

Como parte del diseño del diagrama anterior, varios frontends, backends o extremos pueden conectarse al mismo adjunto de servicio, lo que permite que varias redes de VPC o varios consumidores accedan al mismo servicio. Como se ilustra en el siguiente diagrama, puedes hacer que varias VPCs sean accesibles para la aplicación. Esta accesibilidad puede ayudar en situaciones de servicios multiusuario en las que varias VPCs de consumidores consumen tu servicio, incluso si sus rangos de direcciones IP se superponen.

La superposición de direcciones IP es uno de los problemas más habituales cuando se integran aplicaciones que residen en diferentes entornos. La conexión de Private Service Connect en el siguiente diagrama ayuda a evitar el problema de superposición de direcciones IP. Lo hace sin necesidad de aprovisionar ni administrar ningún componente de red adicional, como Cloud NAT o un NVA, para realizar la traducción de la dirección IP. Para ver un ejemplo de configuración, consulta Publica un servicio híbrido con Private Service Connect.

El diseño tiene las siguientes ventajas:

  • Evita posibles dependencias de escalamiento compartidas y una capacidad de administración compleja a gran escala.
  • Mejora la seguridad, ya que proporciona un control detallado de la conectividad.
  • Reduce la coordinación de direcciones IP entre el productor y el consumidor del servicio y el entorno externo remoto.

El enfoque de diseño del diagrama anterior se puede expandir en etapas posteriores para integrar Apigee como la plataforma de APIs con las opciones de diseño de redes que se analizaron anteriormente, incluida la opción de Private Service Connect.

Puedes hacer que el extremo de Private Service Connect sea accesible desde otras regiones con el acceso global de Private Service Connect.

El cliente que se conecta al extremo de Private Service Connect puede estar en la misma región que el extremo o en una región diferente. Este enfoque se puede usar para proporcionar alta disponibilidad en los servicios alojados en varias regiones o para acceder a los servicios disponibles en una sola región desde otras regiones. Cuando los recursos alojados en otras regiones acceden a un extremo de Private Service Connect, se aplican cargos de salida interregional al tráfico destinado a los extremos con acceso global.

Google Cloud

Prácticas recomendadas

  • Considerar a Apigee y Apigee Hybrid como tu solución de plataforma de API ofrece varios beneficios. Proporciona una capa de proxy y una abstracción o fachada para tus APIs de servicio de backend combinadas con capacidades de seguridad, límites de frecuencia, cuotas y estadísticas.
  • Las VPCs y el diseño de proyectos en Google Cloud deben estar impulsados por tu jerarquía de recursos y los requisitos del modelo de comunicación segura.
  • Cuando se usan APIs con puertas de enlace de API, también debes usar una lista de direcciones IP permitidas. Una lista de entidades permitidas limita las comunicaciones a las direcciones IP específicas de origen y destino de los consumidores de la API y las puertas de enlace de API que podrían alojarse en diferentes entornos.
  • Usa reglas de firewall de VPC o políticas de firewall para controlar el acceso a los recursos de Private Service Connect a través del extremo de Private Service Connect.
  • Si una aplicación se expone de forma externa a través de un balanceador de cargas de aplicaciones, considera usar Google Cloud Armor como una capa de seguridad adicional para protegerte contra DSD y las amenazas de seguridad de la capa de la aplicación.

  • Si las instancias requieren acceso a Internet, usa Cloud NAT en la VPC de la aplicación (consumidor) para permitir que las cargas de trabajo accedan a Internet. De esta manera, puedes evitar asignar direcciones IP públicas externas a las instancias de VM en los sistemas que se implementan detrás de una puerta de enlace de API o un balanceador de cargas.

  • Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.

Entrada cerrada

La arquitectura del patrón de entrada cerrada se basa en la exposición de APIs seleccionadas de cargas de trabajo que se ejecutan en Google Cloud al entorno de computación privado sin exponerlas a la Internet pública. Este patrón es la contraparte del patrón de salida cerrada y es adecuado para las situaciones de híbrido perimetral, híbrido por niveles y multicloud particionado.

Al igual que con el patrón de salida cerrada, puedes facilitar esta exposición limitada a través de una puerta de enlace de API o un balanceador de cargas que actúe como fachada para las cargas de trabajo o los servicios existentes. De esta manera, se puede acceder a él desde entornos de computación privados, entornos locales o cualquier otro entorno de nube, de la siguiente manera:

  • Las cargas de trabajo que implementas en el entorno de computación privado o en otros entornos de nube pueden comunicarse con la puerta de enlace de API o el balanceador de cargas mediante direcciones IP internas. No se puede acceder a otros sistemas implementados enGoogle Cloud .
  • No se permite la comunicación desde Google Cloud hacia el entorno de computación privado ni hacia otros entornos de nube. El tráfico solo se inicia desde el entorno privado o desde otros entornos de nube hacia las APIs en Google Cloud.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con los requisitos del patrón de entrada cerrada.

Datos que fluyen en una dirección desde un entorno local o una nube a través de Cloud VPN o Cloud Interconnect hacia un entorno de Google Cloud y terminan en una carga de trabajo

La descripción de la arquitectura en el diagrama anterior es la siguiente:

  • En el lado de Google Cloud , implementas cargas de trabajo en una VPC de aplicación (o varias VPCs).
  • La red del entorno Google Cloud se extiende a otros entornos de procesamiento (locales o en otra nube) a través de la conectividad de red híbrida o multinube para facilitar la comunicación entre los entornos.
  • De manera opcional, puedes usar una VPC de tránsito para lograr lo siguiente:
    • Proporciona capas de seguridad perimetral adicionales para permitir el acceso a APIs específicas fuera de la VPC de tu aplicación.
    • Enruta el tráfico a las direcciones IP de las APIs. Puedes crear reglas de firewall de VPC para evitar que algunas fuentes accedan a ciertas APIs a través de un extremo.
    • Inspecciona el tráfico de capa 7 en la VPC de tránsito integrando un dispositivo virtual de red (NVA).
  • Accede a las APIs a través de una puerta de enlace de API o un balanceador de cargas (proxy o balanceador de cargas de aplicaciones) para proporcionar una capa de proxy y una capa de abstracción o fachada para tus APIs de servicio. Si necesitas distribuir el tráfico entre varias instancias de puerta de enlace de API, puedes usar un balanceador de cargas de red de transferencia interno.
  • Proporciona acceso limitado y detallado a un servicio publicado a través de un extremo de Private Service Connect con un balanceador de cargas a través de Private Service Connect para exponer una aplicación o un servicio.
  • Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.

En el siguiente diagrama, se ilustra el diseño de este patrón con Apigee como plataforma de APIs.

Los datos fluyen hacia un entorno de Google Cloud y se entregan en un proyecto en una instancia de Apigee desde un entorno local o de nube a través de Cloud VPN o Cloud Interconnect.

En el diagrama anterior, el uso de Apigee como plataforma de API proporciona las siguientes características y capacidades para habilitar el patrón de ingreso controlado:

  • Funcionalidad de puerta de enlace o proxy
  • Capacidades de seguridad
  • Límite de frecuencia
  • Analytics

En el diseño:

  • La conectividad de red de salida (para el tráfico proveniente de otros entornos) pasa por un extremo de Private Service Connect en la VPC de tu aplicación que está asociado con la VPC de Apigee.
  • En la VPC de la aplicación, se usa un balanceador de cargas interno para exponer las APIs de la aplicación a través de un extremo de Private Service Connect que se presenta en la VPC de Apigee. Para obtener más información, consulta Arquitectura con intercambio de tráfico entre VPC inhabilitado.

  • Configura reglas de firewall y filtrado de tráfico en la VPC de la aplicación. De esta manera, se proporciona un acceso detallado y controlado. También ayuda a evitar que los sistemas lleguen directamente a tus aplicaciones sin pasar por el extremo de Private Service Connect y la puerta de enlace de API.

    Además, puedes restringir el anuncio de la subred de direcciones IP internas de la carga de trabajo de backend en la VPC de la aplicación a la red local para evitar la accesibilidad directa sin pasar por el extremo de Private Service Connect y la puerta de enlace de API.

Es posible que ciertos requisitos de seguridad exijan una inspección de seguridad perimetral fuera de la VPC de la aplicación, incluido el tráfico de conectividad híbrida. En esos casos, puedes incorporar una VPC de tránsito para implementar capas de seguridad adicionales. Estas capas, como los dispositivos virtuales de red (NVA) de firewalls de nueva generación (NGFW) con varias interfaces de red o Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS), realizan una inspección profunda de paquetes fuera de la VPC de tu aplicación, como se ilustra en el siguiente diagrama:

Los datos fluyen hacia un entorno de Google Cloud y se entregan en una aplicación desde un entorno local o de nube a través de una Cloud VPN o Cloud Interconnect.

Como se ilustra en el diagrama anterior:

  • La conectividad de red de salida (para el tráfico proveniente de otros entornos) pasa por una VPC de tránsito independiente hacia el extremo de Private Service Connect en la VPC de tránsito asociada con la VPC de Apigee.
  • En la VPC de la aplicación, se usa un balanceador de cargas interno (ILB en el diagrama) para exponer la aplicación a través de un extremo de Private Service Connect en la VPC de Apigee.

Puedes aprovisionar varios extremos en la misma red de VPC, como se muestra en el siguiente diagrama. Para abarcar diferentes casos de uso, puedes controlar las diferentes rutas de acceso a la red posibles con Cloud Router y las reglas de firewall de VPC. Por ejemplo, si conectas tu red local a Google Cloud con varias conexiones de redes híbridas, puedes enviar parte del tráfico desde la red local a APIs de Google o servicios publicados específicos a través de una conexión y el resto a través de otra. También puedes usar el acceso global de Private Service Connect para proporcionar opciones de conmutación por error.

Los datos fluyen hacia un entorno de Google Cloud y se entregan a través de varios extremos de Private Service Connect a varias VPCs del productor desde un entorno local o de nube a través de Cloud VPN o Cloud Interconnect.

Variantes

El patrón de arquitectura de ingreso controlado se puede combinar con otros enfoques para satisfacer diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación del patrón. El patrón ofrece las siguientes opciones:

Accede a las APIs de Google desde otros entornos

Private Service Connect ofrece una solución para las situaciones en las que se requiere acceso a los servicios de Google, como Cloud Storage o BigQuery, sin enviar tráfico a través de Internet pública. Como se muestra en el siguiente diagrama, permite la accesibilidad a los servicios y las APIs de Google compatibles (incluidos Google Maps, Google Ads yGoogle Cloud) desde entornos locales o de otras nubes a través de una conexión de red híbrida que usa la dirección IP del extremo de Private Service Connect. Para obtener más información sobre el acceso a las APIs de Google a través de extremos de Private Service Connect, consulta Información sobre el acceso a las APIs de Google a través de extremos.

Los datos fluyen desde un entorno local a los servicios de Google en un entorno Google Cloud .

En el diagrama anterior, tu red local debe estar conectada a la red de VPC de tránsito (consumidor) a través de túneles de Cloud VPN o un adjunto de VLAN de Cloud Interconnect.

Se puede acceder a las APIs de Google a través de endpoints o backends. Los endpoints te permiten segmentar tus anuncios para un paquete de APIs de Google. Los backends te permiten segmentar tus anuncios para una API de Google regional específica.

Expón backends de aplicaciones a otros entornos con Private Service Connect

En situaciones específicas, como se destaca en el patrón híbrido en niveles, es posible que debas implementar backends en Google Cloud y mantener los frontends en entornos de computación privados. Si bien es menos común, este enfoque se aplica cuando se trata de frontends monolíticos y pesados que pueden depender de componentes heredados. O, más comúnmente, cuando se administran aplicaciones distribuidas en varios entornos, incluidas las instalaciones locales y otras nubes, que requieren conectividad a los backends alojados en Google Cloud a través de una red híbrida.

En una arquitectura de este tipo, puedes usar un balanceador de cargas o una puerta de enlace de API local en el entorno local privado, o en otros entornos de nube, para exponer directamente el frontend de la aplicación a la Internet pública. El uso de Private Service Connect en Google Cloud facilita la conectividad privada a los backends que se exponen a través de un extremo de Private Service Connect, idealmente con APIs predefinidas, como se ilustra en el siguiente diagrama:

Los datos fluyen hacia un entorno de Google Cloud desde un entorno local o desde otro entorno de nube. Los datos fluyen a través de una instancia de Apigee y un servicio de frontend en el entorno non-Google Cloud y terminan en una VPC de la aplicación del proyecto del cliente.

El diseño del diagrama anterior usa una implementación de Apigee Hybrid que consta de un plano de administración en Google Cloud y un plano de entorno de ejecución alojado en tu otro entorno. Puedes instalar y administrar el plano del entorno de ejecución en una puerta de enlace de API distribuida en una de las plataformas de Kubernetes compatibles en tu entorno local o en otros entornos de nube. Según tus requisitos para las cargas de trabajo distribuidas en Google Cloud y otros entornos, puedes usar Apigee en Google Cloud con Apigee Hybrid. Para obtener más información, consulta Puertas de enlace de API distribuidas.

Usa una arquitectura de concentrador y radio para exponer los back-ends de las aplicaciones a otros entornos

En ciertos casos, es posible que debas exponer APIs desde backends de aplicaciones alojados en Google Cloud en diferentes redes de VPC. Como se ilustra en el siguiente diagrama, una VPC de concentrador funciona como un punto central de interconexión para las distintas VPC (radios), lo que permite una comunicación segura a través de la conectividad híbrida privada. De manera opcional, se pueden usar capacidades de puerta de enlace de API local en otros entornos, como Apigee Hybrid, para finalizar las solicitudes de los clientes de forma local donde se aloja el frontend de la aplicación.

Los datos fluyen entre un entorno de Google Cloud y un entorno local o de otra nube, y exponen APIs de los back-ends de aplicaciones alojados en Google Cloud en diferentes redes de VPC.

Como se ilustra en el diagrama anterior:

  • Para proporcionar capacidades adicionales de inspección de capa 7 del NGFW, el NVA con capacidades de NGFW se integra de forma opcional en el diseño. Es posible que necesites estas capacidades para cumplir con requisitos de seguridad específicos y los estándares de la política de seguridad de tu organización.

  • Este diseño supone que las VPC de radio no requieren comunicación directa entre VPC.

    • Si se requiere comunicación entre radios, puedes usar la NVA para facilitar dicha comunicación.
    • Si tienes diferentes backends en diferentes VPCs, puedes usar Private Service Connect para exponer estos backends a la VPC de Apigee.
    • Si se usa el intercambio de tráfico entre VPC para la conectividad de norte a sur y de sur a norte entre las VPC de radio y la VPC de concentrador, debes tener en cuenta la limitación de transitividad de las redes de VPC a través del intercambio de tráfico entre VPC. Para superar esta limitación, puedes usar cualquiera de las siguientes opciones:
      • Para interconectar las VPC, usa una NVA.
      • Cuando corresponda, considera el modelo de Private Service Connect.
      • Para establecer la conectividad entre la VPC de Apigee y los backends que se encuentran en otros proyectos deGoogle Cloud en la misma organización sin componentes de redes adicionales, usa la VPC compartida.

  • Si se requieren AVN para la inspección del tráfico, incluido el tráfico de tus otros entornos, la conectividad híbrida a entornos locales o de otras nubes debe finalizar en la VPC de tránsito híbrido.

  • Si el diseño no incluye la NVA, puedes finalizar la conectividad híbrida en la VPC del concentrador.

  • Si se requieren ciertas funcionalidades de balanceo de cargas o capacidades de seguridad, como agregar protección contra DDoS o WAF de Google Cloud Armor, puedes implementar de forma opcional un balanceador de cargas de aplicaciones externo en el perímetro a través de una VPC externa antes de enrutar las solicitudes de clientes externos a los backends.

Prácticas recomendadas

  • En situaciones en las que un frontend alojado en un entorno privado local o en otro entorno de nube debe recibir solicitudes de clientes de Internet de forma local, considera usar Apigee Hybrid como solución de puerta de enlace de API. Este enfoque también facilita una migración sin problemas de la solución a un entorno completamente alojado en Google Cloud, al tiempo que mantiene la coherencia de la plataforma de APIs (Apigee).
  • Usa el adaptador de Apigee para Envoy con una arquitectura de implementación de Apigee Hybrid con Kubernetes cuando corresponda para tus requisitos y la arquitectura.
  • El diseño de las VPCs y los proyectos en Google Cloud debe seguir la jerarquía de recursos y los requisitos del modelo de comunicación segura, como se describe en esta guía.
  • Incorporar una VPC de tránsito en este diseño proporciona la flexibilidad necesaria para aprovisionar medidas de seguridad perimetral adicionales y conectividad híbrida fuera de la VPC de carga de trabajo.
  • Usa Private Service Connect para acceder a las APIs y los servicios de Google desde entornos locales o desde otros entornos de nube con la dirección IP interna del extremo a través de una red de conectividad híbrida. Para obtener más información, consulta Accede al extremo desde hosts locales.
  • Para proteger los servicios de Google Cloud en tus proyectos y mitigar el riesgo de robo de datos, usa los Controles del servicio de VPC para especificar perímetros de servicio a nivel del proyecto o de la red de VPC.
  • Usa reglas de firewall de VPC o políticas de firewall para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del extremo de Private Service Connect. Por ejemplo, las reglas de firewall de salida en la VPC de la aplicación (consumidor) pueden restringir el acceso desde las instancias de VM a la dirección IP o la subred de tus extremos. Para obtener más información sobre las reglas de firewall de VPC en general, consulta Reglas de firewall de VPC.
  • Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño e implementación de alta disponibilidad y redundancia que te proporciona tu proveedor de NVA.
  • Para fortalecer la seguridad perimetral y proteger tu puerta de enlace de API implementada en el entorno respectivo, puedes implementar de forma opcional mecanismos de balanceo de cargas y de firewall de aplicación web en tu otro entorno de procesamiento (híbrido o de otra nube). Implementa estas opciones en la red perimetral que está conectada directamente a Internet.
  • Si las instancias requieren acceso a Internet, usa Cloud NAT en la VPC de la aplicación para permitir que las cargas de trabajo accedan a Internet. De esta manera, puedes evitar asignar direcciones IP públicas externas a las instancias de VM en sistemas que se implementan detrás de una puerta de enlace de API o un balanceador de cargas.
  • Para el tráfico web saliente, usa el proxy web seguro. El proxy ofrece varios beneficios.
  • Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.

Salida cerrada y entrada cerrada

El patrón de entrada y salida cerradas usa una combinación de entrada y salida cerradas para situaciones que exigen el uso bidireccional de las APIs seleccionadas entre las cargas de trabajo. Las cargas de trabajo pueden ejecutarse en Google Cloud, en entornos locales privados o en otros entornos de nube. En este patrón, puedes usar puertas de enlace de API, extremos de Private Service Connect o balanceadores de cargas para exponer APIs específicas y, de forma opcional, proporcionar autenticación, autorización y auditorías de llamadas a la API.

La distinción clave entre este patrón y el patrón de malla se encuentra en la aplicación para situaciones que solo requieren el uso bidireccional de la API o la comunicación con fuentes y destinos de direcciones IP específicas, por ejemplo, una aplicación publicada a través de un extremo de Private Service Connect. Debido a que la comunicación se restringe a las APIs expuestas o a direcciones IP específicas, las redes de los diferentes entornos no necesitan alinearse en tu diseño. Estos son algunos casos comunes en los que se aplica esta política:

  • Fusiones y adquisiciones
  • Integraciones de aplicaciones con socios
  • Integraciones entre aplicaciones y servicios de una organización con diferentes unidades organizativas que administran sus propias aplicaciones y las alojan en diferentes entornos.

La comunicación funciona de la siguiente manera:

  • Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API (o con direcciones IP de destino específicas) a través de direcciones IP internas. No se puede acceder a otros sistemas implementados en el entorno de computación privado.
  • Por otro lado, las cargas de trabajo que implementes en otros entornos de computación pueden comunicarse con la puerta de enlace de API del lado de Google Cloud(o una dirección IP de extremo publicada específica) mediante el uso de direcciones IP internas. No se puede acceder a otros sistemas implementados en Google Cloud .

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de referencia para el patrón de entrada y salida cerradas:

Los datos ingresan y egresan entre Google Cloud y una red local o de otra nube.

El enfoque de diseño del diagrama anterior tiene los siguientes elementos:

  • Del lado de Google Cloud , implementas cargas de trabajo en una VPC (o VPC compartida) sin exponerlas directamente a Internet.
  • La red del entorno Google Cloud se extiende a otros entornos de procesamiento. Ese entorno puede ser local o estar en otra nube. Para extender el entorno, usa un patrón de comunicación de conectividad híbrida y de varias nubes adecuado para facilitar la comunicación entre los entornos, de modo que puedan usar direcciones IP internas.
  • De manera opcional, si habilitas el acceso a direcciones IP de destino específicas, puedes usar una VPC de tránsito para agregar una capa de seguridad perimetral fuera de la VPC de tu aplicación.
    • Puedes usar el firewall de nueva generación de Cloud o dispositivos virtuales de red (NVA) con firewalls de última generación (NGFW) en la VPC de tránsito para inspeccionar el tráfico y permitir o prohibir el acceso a ciertas APIs desde fuentes específicas antes de llegar a la VPC de tu aplicación.
  • Se debe acceder a las APIs a través de una puerta de enlace de API o un balanceador de cargas para proporcionar una capa de proxy y una abstracción o fachada para tus API de servicio.
  • En las aplicaciones consumidas como APIs, también puedes usar Private Service Connect para proporcionar una dirección IP interna para la aplicación publicada.
  • Todos los entornos usan un espacio de direcciones IP RFC 1918 sin superposición.

Una aplicación común de este patrón implica implementar backends de aplicaciones (o un subconjunto de backends de aplicaciones) en Google Cloud mientras se alojan otros componentes de backend y frontend en entornos locales o en otras nubes (patrón de híbrido en niveles o patrón de multicloud particionado). A medida que las aplicaciones evolucionan y migran a la nube, suelen surgir dependencias y preferencias por servicios en la nube específicos.

A veces, estas dependencias y preferencias llevan a la distribución de aplicaciones y backends en diferentes proveedores de servicios en la nube. Además, algunas aplicaciones pueden compilarse con una combinación de recursos y servicios distribuidos en entornos locales y múltiples entornos de nube.

En el caso de las aplicaciones distribuidas, las capacidades de la conectividad externa y de nubes híbridas de Cloud Load Balancing se pueden usar para finalizar las solicitudes de los usuarios y enrutarlas a frontends o backends en otros entornos. Este enrutamiento se produce a través de una conexión de red híbrida, como se ilustra en el siguiente diagrama. Esta integración permite la distribución gradual de los componentes de la aplicación en diferentes entornos. Las solicitudes del frontend a los servicios de backend alojados en Google Cloud se comunican de forma segura a través de la conexión de red híbrida establecida que facilita un balanceador de cargas interno (ILB en el diagrama).

Los datos ingresan y egresan entre un frontend de la aplicación en un entorno local o en otra nube y un backend de la aplicación en un entorno de Google Cloud . Los datos fluyen a través de un balanceador de cargas interno (ILB) en Google Cloud.

Usar el diseño Google Cloud del diagrama anterior ayuda con lo siguiente:

  • Facilita la comunicación bidireccional entre Google Cloud, de forma local y en otros entornos de nube mediante el uso de APIs predefinidas en ambos lados que se alinean con el modelo de comunicación de este patrón.
  • Para proporcionar frontends globales para aplicaciones orientadas a Internet con componentes de aplicaciones distribuidos (frontends o backends) y lograr los siguientes objetivos, puedes usar las capacidades avanzadas de balanceo de cargas y seguridad de Google Cloud distribuidas en puntos de presencia (PoP):
  • Reduce los gastos de capital y simplifica las operaciones con servicios administrados sin servidores.
  • Optimiza las conexiones a los servidores de aplicaciones a nivel global para mejorar la velocidad y reducir la latencia.
    • Google Cloud Cross-Cloud Network permite la comunicación entre varios componentes de aplicaciones en varias nubes a través de conexiones privadas óptimas.
  • Almacena en caché el contenido estático de alta demanda y mejora el rendimiento de las aplicaciones que usan Cloud Load Balancing global mediante el acceso a Cloud CDN.
  • Protege los frontends globales de las aplicaciones orientadas a Internet con las capacidades de Google Cloud Armor que proporcionan servicios de firewall de aplicación web (WAF) y mitigación de DSD distribuidos en todo el mundo.
  • De manera opcional, puedes incorporar Private Service Connect en tu diseño. Esto permite el acceso privado y detallado a las APIs de servicio de Google Cloud o a los servicios publicados desde otros entornos sin atravesar la Internet pública.

Variantes

Los patrones de arquitectura de entrada y salida cerradas se pueden combinar con otros enfoques para satisfacer diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación de este patrón. Los patrones ofrecen las siguientes opciones:

Puertas de enlace de API distribuidas

En situaciones como la basada en el patrón de múltiples nubes particionadas, las aplicaciones (o los componentes de las aplicaciones) se pueden compilar en diferentes entornos de nube, incluido un entorno local privado. El requisito común es enrutar las solicitudes del cliente al frontend de la aplicación directamente al entorno en el que se aloja la aplicación (o el componente de frontend). Este tipo de comunicación requiere un balanceador de cargas local o una puerta de enlace de API. Es posible que estas aplicaciones y sus componentes también requieran capacidades específicas de la plataforma de APIs para la integración.

En el siguiente diagrama, se ilustra cómo Apigee y Apigee Hybrid están diseñados para abordar estos requisitos con una puerta de enlace de API localizada en cada entorno. La administración de la plataforma de APIs se centraliza en Google Cloud. Este diseño ayuda a aplicar medidas estrictas de control de acceso en las que solo las direcciones IP aprobadas con anterioridad (APIs de destino y destino o direcciones IP de extremo de Private Service Connect) pueden comunicarse entre Google Cloud y los otros entornos.

Los datos ingresan y egresan entre un entorno local o de otra nube y un entorno de Google Cloud . Las solicitudes del cliente al frontend de la aplicación van directamente al entorno en el que se aloja la aplicación (o el componente de frontend).

En la siguiente lista, se describen las dos rutas de comunicación distintas del diagrama anterior que usan la puerta de enlace de API de Apigee:

  • Las solicitudes del cliente llegan directamente al frontend de la aplicación en el entorno que la aloja (o el componente de frontend).
  • Las puertas de enlace y los proxies de API dentro de cada entorno controlan las solicitudes a la API del cliente y de la aplicación en diferentes direcciones en varios entornos.
    • La funcionalidad de la puerta de enlace de API en Google Cloud(Apigee) expone los componentes de la aplicación (frontend o backend) que se alojan en Google Cloud.
    • La funcionalidad de la puerta de enlace de API en otro entorno (híbrido) expone los componentes de frontend (o backend) de la aplicación que se alojan en ese entorno.

De manera opcional, puedes considerar usar una VPC de tránsito. Una VPC de tránsito puede proporcionar flexibilidad para separar las responsabilidades y realizar la inspección de seguridad y la conectividad híbrida en una red de VPC independiente. Desde el punto de vista de la accesibilidad a la dirección IP, una VPC de tránsito (en la que se adjunta la conectividad híbrida) facilita los siguientes requisitos para mantener la accesibilidad de extremo a extremo:

  • Las direcciones IP de las APIs de destino deben anunciarse a los otros entornos en los que se alojan los clientes o solicitantes.
  • Las direcciones IP para los hosts que necesitan comunicarse con las APIs de destino deben anunciarse al entorno en el que reside la API de destino, por ejemplo, las direcciones IP del solicitante de la API (el cliente). La excepción se da cuando la comunicación se produce a través de un balanceador de cargas, un proxy, un extremo de Private Service Connect o una instancia de NAT.

Para extender la conectividad al entorno remoto, este diseño usa el intercambio de tráfico de VPC directo con la capacidad de intercambio de rutas del cliente. El diseño permite que las solicitudes de API específicas que se originan en las cargas de trabajo alojadas dentro de la VPC de la aplicación Google Cloud se enruten a través de la VPC de tránsito. Como alternativa, puedes usar un extremo de Private Service Connect en la VPC de la aplicación que está asociada a un balanceador de cargas con un backend de grupo de extremos de red híbrido en la VPC de tránsito. Esa configuración se describe en la siguiente sección: Comunicación bidireccional de la API con Private Service Connect.

Comunicación bidireccional de la API con Private Service Connect

A veces, es posible que las empresas no necesiten usar una puerta de enlace de API (como Apigee) de inmediato o que quieran agregarla más adelante. Sin embargo, es posible que haya requisitos comerciales para habilitar la comunicación y la integración entre ciertas aplicaciones en diferentes entornos. Por ejemplo, si tu empresa adquirió otra, es posible que debas exponer ciertas aplicaciones a esa empresa. Es posible que deban exponer aplicaciones a tu empresa. Ambas empresas pueden tener sus propias cargas de trabajo alojadas en diferentes entornos (Google Cloud, locales o en otras nubes) y deben evitar la superposición de direcciones IP. En esos casos, puedes usar Private Service Connect para facilitar la comunicación efectiva.

En las aplicaciones consumidas como APIs, también puedes usar Private Service Connect para proporcionar una dirección privada a las aplicaciones publicadas, lo que permite el acceso seguro dentro de la red privada entre regiones y a través de una conectividad híbrida. Esta abstracción facilita la integración de recursos de diversas nubes y entornos locales a través de un modelo de conectividad híbrida y de múltiples nubes. También permite el ensamblaje de aplicaciones en entornos locales y de múltiples nubes. Esto puede satisfacer diferentes requisitos de comunicación, como la integración de aplicaciones seguras en las que no se usa o no se planea usar una puerta de enlace de API.

Si usas Private Service Connect con Cloud Load Balancing, como se muestra en el siguiente diagrama, puedes lograr dos rutas de comunicación distintas. Cada ruta se inicia desde una dirección diferente para un propósito de conectividad independiente, idealmente a través de llamadas a la API.

  • Todas las consideraciones y recomendaciones de diseño de Private Service Connect que se analizan en esta guía se aplican a este diseño.
  • Si se requiere una inspección adicional de la capa 7, puedes integrar los NVA en este diseño (en la VPC de tránsito).
  • Este diseño se puede usar con o sin puertas de enlace de API.

Los entornos locales o de otras nubes y un entorno de Google Cloud comunican datos a través de diferentes rutas y a través de varios balanceadores de cargas, extremos de VPC y subredes.

Las dos rutas de conectividad que se muestran en el diagrama anterior representan conexiones independientes y no ilustran la comunicación bidireccional de una sola conexión o flujo.

Comunicación bidireccional con extremos e interfaces de Private Service Connect

Como se explica en el patrón de entrada cerrada, una de las opciones para habilitar la comunicación cliente-servicio es mediante un extremo de Private Service Connect para exponer un servicio en una VPC de productor a una VPC de consumidor. Esa conectividad se puede extender a un entorno local o incluso a otro entorno de proveedor de servicios en la nube a través de una conectividad híbrida. Sin embargo, en algunos casos, el servicio alojado también puede requerir comunicación privada.

Para acceder a un servicio determinado, como recuperar datos de fuentes de datos que se pueden alojar dentro de la VPC del consumidor o fuera de ella, esta comunicación privada puede ser entre la VPC de la aplicación (productor) y un entorno remoto, como un entorno local.

En este caso, las interfaces de Private Service Connect permiten que una instancia de VM de productor de servicios acceda a la red de un consumidor. Para ello, comparte una interfaz de red, a la vez que mantiene la separación de los roles de productor y consumidor. Con esta interfaz de red en la VPC del consumidor, la VM de la aplicación puede acceder a los recursos del consumidor como si residieran de forma local en la VPC del productor.

Una interfaz de Private Service Connect es una interfaz de red conectada a la VPC del consumidor (tránsito). Es posible llegar a destinos externos a los que se puede acceder desde la VPC del consumidor (de tránsito) en la que se adjunta la interfaz de Private Service Connect. Por lo tanto, esta conexión se puede extender a un entorno externo a través de una conectividad híbrida, como un entorno local, como se ilustra en el siguiente diagrama:

Los datos ingresan y egresan entre una aplicación en Google Cloud y una carga de trabajo en una red local o de otra nube.

Si la VPC del consumidor es una organización o entidad externa, como una organización de terceros, por lo general, no tendrás la capacidad de proteger la comunicación con la interfaz de Private Service Connect en la VPC del consumidor. En tal situación, puedes definir políticas de seguridad en el SO invitado de la VM de la interfaz de Private Service Connect. Para obtener más información, consulta Configura la seguridad para interfaces de Private Service Connect. O bien, puedes considerar un enfoque alternativo si no cumple con los estándares o el cumplimiento de seguridad de tu organización.

Prácticas recomendadas

  • Para situaciones en las que un frontend alojado en un entorno privado local o en otro entorno de nube debe recibir solicitudes de clientes desde Internet de forma local, considera usar Hybrid como solución de puerta de enlace de API.

    • Este enfoque también facilita la migración de la solución a un entorno completamente Google Cloudalojado y, al mismo tiempo, mantiene la coherencia de la plataforma de API (Apigee).

  • Para minimizar la latencia y optimizar los costos de grandes volúmenes de transferencias de datos salientes a tus otros entornos cuando estos se encuentran en configuraciones híbridas o de múltiples nubes a largo plazo o permanentes, considera lo siguiente:

    • Usa Cloud Interconnect o Cross-Cloud Interconnect.
    • Para finalizar las conexiones de los usuarios en el frontend objetivo en el entorno adecuado, usa Híbrido.

  • Cuando corresponda para tus requisitos y la arquitectura, usa el adaptador de Apigee para Envoy con una implementación híbrida con Kubernetes.

  • Antes de diseñar las rutas de conectividad y enrutamiento, primero debes identificar qué tráfico o solicitudes de API deben dirigirse a una puerta de enlace de API local o remota, junto con los entornos de origen y destino.

  • Usa los Controles del servicio de VPC para proteger los servicios Google Cloud en tus proyectos y mitigar el riesgo de robo de datos. Para ello, especifica perímetros de servicio a nivel del proyecto o de la red de VPC.

  • Usa Reglas de firewall de la nube privada virtual (VPC) o políticas de firewall para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del extremo de Private Service Connect. Por ejemplo, las reglas de firewall de salida en la VPC de la aplicación (consumidor) pueden restringir el acceso desde las instancias de VM a la dirección IP o la subred de tus extremos.

  • Cuando usas una interfaz de Private Service Connect, debes proteger la comunicación con la interfaz configurando la seguridad para la interfaz de Private Service Connect.

  • Si una carga de trabajo en una subred privada requiere acceso a Internet, usa Cloud NAT para evitar asignar una dirección IP externa a la carga de trabajo y exponerla a la Internet pública.

  • Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.

Patrones de traspaso

Con el patrón de traspaso, la arquitectura se basa en el uso de servicios de almacenamiento proporcionados porGoogle Cloudpara conectar un entorno de computación privado a proyectos en Google Cloud. Este patrón se aplica en especial en la configuración que sigue el patrón de arquitectura de múltiples nubes híbridas de estadísticas, donde:

  • Las cargas de trabajo que se ejecutan en un entorno de computación privado o en otra nube suben datos a ubicaciones de almacenamiento compartidas. Según los casos de uso, las cargas pueden realizarse de forma masiva o en incrementos más pequeños.
  • Las cargas de trabajo alojadas enGoogle Cloudo en otros servicios de Google (por ejemplo, servicios de análisis de datos y de inteligencia artificial) consumen datos de las ubicaciones de almacenamiento compartido y los procesan en forma de transmisión o por lotes.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de referencia para el patrón de traspaso.

Los datos fluyen desde un entorno local a una carga de trabajo alojada en una VPC y a un servicio de análisis de datos alojado en un entorno de Google Cloud .

En el diagrama de arquitectura anterior, se muestran los siguientes flujos de trabajo:

  • En el lado de Google Cloud , implementas cargas de trabajo en una VPC de aplicación. Estas cargas de trabajo pueden incluir procesamiento de datos, estadísticas y aplicaciones de frontend relacionadas con las estadísticas.
  • Para exponer las aplicaciones de frontend de forma segura a los usuarios, puedes usar Cloud Load Balancing o API Gateway.
  • Un conjunto de buckets de Cloud Storage o colas de Pub/Sub sube los datos del entorno de computación privado y los pone a disposición para su procesamiento posterior mediante cargas de trabajo implementadas en Google Cloud. Con las políticas de Identity and Access Management (IAM), puedes restringir el acceso a las cargas de trabajo de confianza.
  • Usa los Controles del servicio de VPC para restringir el acceso a los servicios y minimizar los riesgos injustificados de robo de datos de los servicios de Google Cloud .
  • En esta arquitectura, la comunicación con los buckets de Cloud Storage, o Pub/Sub, se realiza a través de redes públicas o a través de la conectividad privada mediante VPN, Cloud Interconnect o Cross-Cloud Interconnect. Por lo general, la decisión sobre cómo conectar depende de varios aspectos, como los siguientes:
    • Volumen de tráfico esperado
    • Si es una configuración temporal o permanente
    • Requisitos de seguridad y cumplimiento

Variante

Las opciones de diseño que se describen en el patrón de entrada cerrada, que usa extremos de Private Service Connect para las APIs de Google, también se pueden aplicar a este patrón. Específicamente, proporciona acceso a Cloud Storage, BigQuery y otras APIs de servicio de Google. Este enfoque requiere un direccionamiento IP privado a través de una conexión de red híbrida y de múltiples nubes, como VPN, Cloud Interconnect y Cross-Cloud Interconnect.

Prácticas recomendadas

  • Bloquea el acceso a los buckets de Cloud Storage y los temas de Pub/Sub.
  • Cuando corresponda, usa soluciones integradas de transferencia de datos que prioricen la nube, como el Google Cloud paquete de soluciones. Para satisfacer las necesidades de tu caso de uso, estas soluciones están diseñadas para mover, integrar y transformar datos de manera eficiente.

  • Evalúa los diferentes factores que influyen en las opciones de transferencia de datos, como el costo, el tiempo de transferencia esperado y la seguridad. Para obtener más información, consulta Cómo evaluar tus opciones de transferencia.

  • Para minimizar la latencia y evitar la transferencia y el movimiento de datos de gran volumen a través de la Internet pública, considera usar Cloud Interconnect o Cross-Cloud Interconnect, incluido el acceso a extremos de Private Service Connect en tu nube privada virtual para las APIs de Google.

  • Para proteger los Google Cloud servicios en tus proyectos y mitigar el riesgo de robo de datos, usa los Controles del servicio de VPC. Estos controles de servicio pueden especificar perímetros de servicio a nivel del proyecto o de la red de VPC.

  • Comunícate con cargas de trabajo de análisis de datos publicadas de forma pública y alojadas en instancias de VM a través de una puerta de enlace de API, un balanceador de cargas o un dispositivo de red virtual. Usa uno de estos métodos de comunicación para mayor seguridad y para evitar que se pueda acceder a estas instancias directamente desde Internet.

  • Si se requiere acceso a Internet, se puede usar Cloud NAT en la misma VPC para controlar el tráfico saliente de las instancias a la Internet pública.

  • Revisa las prácticas recomendadas generales sobre las topologías de red para nube híbrida y múltiples nubes.

Prácticas recomendadas generales

Cuando diseñes e incorpores identidades de Cloud, jerarquías de recursos y redes de zonas de destino, ten en cuenta las recomendaciones de diseño que se incluyen en Diseño de la zona de destino en Google Cloud y las prácticas recomendadas de seguridad de Google Cloud que se abordan en el plano sobre las bases de la empresa. Valida el diseño seleccionado con los siguientes documentos:

Además, considera las siguientes prácticas recomendadas generales:

Patrones de arquitectura de herramientas de redes seguras de nubes híbridas y múltiples: Próximos pasos