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

Last reviewed 2023-12-14 UTC

En esta página, se proporciona una vista de una sola página de todas las páginas en Crea arquitecturas híbridas y multinube con Google Cloud. Puedes imprimir esta página o guardarla en formato PDF con la función de impresión del navegador y elegir la opción Guardar como PDF. Esta página no proporciona un panel de índice (Índice) en el lado derecho.

Este documento es el tercero de tres documentos de un conjunto. En él, se analizan los patrones de arquitectura de redes híbridas y de múltiples nubes. En esta parte, se exploran varios patrones comunes de arquitectura de red segura 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 implementarlas con Google Cloud.

El conjunto de documentos para patrones de arquitectura híbrida y de múltiples nubes consta de estas 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 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 redes (este documento).

Conectar entornos de computación privados a Google Cloud de manera segura y confiable es esencial para cualquier arquitectura híbrida y multinube exitosa. El patrón de arquitectura de conectividad de redes híbridas y de redes en la nube que elijas para una configuración híbrida y de múltiples nubes debe 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 herramientas 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 aterrizaje de 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 varias nubes, debes mantener la coherencia del diseño de la zona de destino en todos los entornos.

Esta serie contiene las siguientes páginas:

• Consideraciones del diseño
• Patrones de arquitectura
  • Patrón duplicado
  • Patrón de malla
  • Patrones cerrados
    • Salida cerrada
    • Entrada cerrada
    • Entrada y salida cerradas
  • Traspaso
• Prácticas recomendadas generales

Colaboradores

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

Otros colaboradores:

• Saud Albazei | Ingeniero de Atención al Cliente, Modernización de aplicaciones
• Anna Berenberg | Socio de Ingeniería
• Marco Ferrari | Arquitecto de soluciones de nube
• Victor Moreno | Gerente de producto, Herramientas de redes de Cloud
• Johannes Passing | Arquitecto de Soluciones de Cloud
• Mark Schlagenhauf | Escritor técnico, Herramientas de redes
• Daniel Strebel | Líder de Soluciones de EMEA, Modernización de Aplicaciones
• Ammett Williams | Ingeniero de relaciones con desarrolladores

Patrones de arquitectura

En los documentos de esta serie, se analizan los patrones de arquitectura de redes que se diseñan 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 deben incorporarse a la arquitectura general de la zona de destino de la organización, que puede incluir varios patrones de red 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 red pueden ayudarte a cumplir con los requisitos de comunicación y seguridad de tus aplicaciones:

• Patrón duplicado
• Patrón de malla
• Patrones cerrados
  • Salida cerrada
  • Entrada cerrada
  • Salida cerrada y entrada cerrada
• Patrón de traspaso

Patrón duplicado

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

El patrón reflejado 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 alineen con los siguientes requisitos:

• La integración continua/implementación continua (CI/CD) puede implementar y administrar las cargas de trabajo en todos los entornos de computación o en entornos específicos.
• La supervisión, la administración de la configuración y otros sistemas administrativos deberían funcionar en todos los entornos de computación.
• Las cargas de trabajo no pueden comunicarse directamente entre 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 configuraciones, otros sistemas administrativos y comunicación de cargas de trabajo:

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

• Las cargas de trabajo se distribuyen en función de los entornos funcionales (desarrollo, pruebas, herramientas de CI/CD y administrativas) en VPC separadas en el lado de Google Cloud .
• La VPC compartida se usa para 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:
  • Diferentes equipos administran las aplicaciones 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 permitido.
  • También puedes usar Cloud Next Generation Firewall Enterprise con el 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 ni el enrutamiento. Cloud Next Generation Firewall Enterprise funciona mediante la creación de 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 vinculadas con 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.

Para establecer esta conexión de CI/CD, usa una de las opciones de conectividad de redes híbridas y múltiples que se mencionaron antes y que cumplan 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 de 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 directamente a estas instancias 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 funciones de Google Cloud que te ayudan a compilar, probar e implementar en Google Cloud y en entornos híbridos y multinube, consulta el blog DevOps y CI/CD en Google Cloud explicado.

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 reflejo ofrece estas opciones, que se describen en las siguientes secciones:

• VPC compartida por entorno
• Firewall centralizado de capa de aplicación
• Topología de concentrador y radio
• Arquitectura distribuida de confianza cero de microservicios

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 de CI/CD y administrativas 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 de 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 para administrar las aplicaciones y las cargas de trabajo que crean diferentes equipos por entorno y por proyecto de servicio. Los equipos de operaciones de red 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 de host en todos los entornos.
• Diferentes equipos administran los proyectos host en sus respectivos entornos.

Las decisiones sobre la administración de proyectos de 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é tipo de 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:

Firewall centralizado de la capa de aplicación

En algunos casos, 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 superan 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 socios de seguridad de Google Cloudofrecen 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 mediante varias interfaces de red.

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

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 intercalado y aplicar políticas de control de acceso estrictas.

Para obtener 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 más inspecciones de tráfico y control de seguridad en los flujos de tráfico este-oeste y norte-sur.

Nota: En las regiones de nube compatibles y cuando sea técnicamente factible para tu diseño, los NVA se pueden implementar sin requerir varias redes de VPC ni interfaces de dispositivos. Esta implementación se basa en el uso del balanceo de cargas y las capacidades de enrutamiento basado en políticas. Estas funciones habilitan un mecanismo independiente de la topología y basado en políticas para integrar NVA en tu red de nube. Para obtener más información, consulta Cómo implementar dispositivos virtuales de red (NVA) sin varias VPC.

Topología de concentrador y radio

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

• Las aplicaciones deben acceder a un conjunto común de servicios, como la supervisión, las herramientas de administración de parámetros de configuración, CI/CD o la 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.

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 alinearla con tus requisitos de conectividad.

Como parte de la arquitectura de red de maraña, las siguientes son las opciones de conectividad principales (entre las VPC de maraña y las de centro) en Google Cloud:

• Intercambio de tráfico entre redes de VPC
• VPN
• Con un dispositivo virtual de red (NVA)
  • Con varias interfaces de red
  • Con Network Connectivity Center (NCC)

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 la VPN sobre el intercambio de tráfico entre VPC entre los radios y el VPC del concentrador 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 requiere cumplir con ciertos requisitos de seguridad.

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

Cuando se usa una arquitectura de proxy distribuida, como una malla de servicios, los servicios pueden validar de manera eficaz a los llamadores y, además, implementar políticas de control de acceso detallado 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 implementaciones locales y deGoogle Cloud . 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 liviana de la puerta de enlace de API de Apigee en 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.

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

• Arquitectura distribuida de confianza cero
• Entorno híbrido de GKE Enterprise
• Conectar con Google
  • Conecta un clúster de GKE Enterprise local a una red deGoogle Cloud .
• Configura una malla híbrida o de múltiples nubes
  • Implementa Cloud Service Mesh en entornos y clústeres.

Prácticas recomendadas para patrones simétricos

• 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 la confiabilidad de la infraestructura deGoogle Cloud .
• Para eliminar los errores de configuración de los procesos repetidos, como las actualizaciones de código, la automatización es esencial para estandarizar tus compilaciones, pruebas e implementaciones.
• La integración de NVA centralizados 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 NVA, es importante tener en cuenta la alta disponibilidad (HA) de las NVA para evitar un punto único de fallo que podría bloquear toda la comunicación. Sigue las instrucciones de diseño y de implementación de la HA y la redundancia que proporciona tu proveedor de NVA.
• Si no exportas las rutas de IP locales a través del intercambio de tráfico entre VPC o la VPN a la VPC de desarrollo y pruebas, puedes restringir la accesibilidad de la red desde los entornos de desarrollo y pruebas al entorno local. Para obtener más información, consulta Intercambio de rutas personalizado del intercambio de tráfico entre redes de VPC.
• En el caso de 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 Ingresos con control de acceso 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 establecer una arquitectura de red híbrida. Esa arquitectura abarca varios entornos de computación. 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 red se aplica principalmente a las arquitecturas híbridas por niveles, de múltiples nubes particionadas o con aumentos de actividad. También se aplica al diseño de continuidad del negocio para aprovisionar un entorno de recuperación ante desastres (DR) en Google Cloud. En todos los casos, requiere que conectes los entornos de computación de manera tal que se alineen con los siguientes requisitos de comunicación:

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

Arquitectura

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

• Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.
• En el lado de Google Cloud , puedes implementar cargas de trabajo en una sola VPC compartida o en varias VPC compartidas o no compartidas. Para conocer otras posibles opciones de diseño de este patrón, consulta las variaciones de diseño que se indican a continuación. La estructura seleccionada de tus VPC 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 aplicación.

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

  • Reglas de firewall o políticas de firewall

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

  • Cloud Next Generation Firewall Enterprise con el 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 ni el enrutamiento de la red

Variantes

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

• Una VPC por entorno
• Usa un firewall de capa de aplicación centralizado
• Arquitectura distribuida de confianza cero de microservicios

Una VPC por entorno

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

• El entorno de nube requiere la separación a nivel de la red de las redes y los recursos de la VPC, en alineación 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 de una sola VPC o un solo 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 mediante VPN o Cloud Interconnect con varios adjuntos de VLAN.

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 aterrizaje. En esa topología, se puede compartir una sola (o varias) conexiones híbridas con todas las VPC de radio. Se comparte mediante 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: "Cómo usar un firewall de capa de aplicación centralizado".

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 superan 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 para pasar todo el tráfico entre entornos a través de un firewall NVA centralizado, como se muestra en el siguiente diagrama.

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

Como se muestra en el diagrama anterior, la NVA actúa como la capa de seguridad del perímetro y sirve como base para habilitar la inspección de tráfico intercalado. 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 puede 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 los microservicios que se analiza en la sección patrón reflejado 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 definirse con precisión, 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 tu diseño de jerarquía de recursos y el diseño necesario para admitir cualquier proyecto y VPC. De esta manera, puedes seleccionar la arquitectura de red óptima que se alinee 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 usas NVAs centralizados 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. Basar estos controles y políticas en los requisitos de seguridad de tus aplicaciones
• Cuando diseñes una solución que incluya NVA, es importante tener en cuenta la alta disponibilidad (HA) de las NVA para evitar un punto único de fallo que podría bloquear toda la comunicación. Sigue las instrucciones de diseño y de implementación de HA y redundancia que proporciona el proveedor de seguridad deGoogle Cloud que suministra tus NVA.
• Para proporcionar mayor privacidad, integridad de los datos y un modelo de comunicación controlado, expone las aplicaciones a través de APIs con puertas de enlace de API, como Apigee y Apigee híbrido con mTLS de extremo a extremo. También puedes usar una VPC compartida con Apigee en el mismo recurso de la organización.
• Si el diseño de tu solución requiere exponer una aplicación basada en Google Cloud a la Internet pública, considera las recomendaciones de diseño que se analizan en Redes para la entrega de aplicaciones orientadas a Internet.
• Para ayudar a 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 deseas 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 con control de acceso 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:

• Salida cerrada

• Entrada cerrada

• Entrada y salida cerradas (cerradas bidireccionales en ambas direcciones)

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.

Nota: En general, el patrón cerrado se puede aplicar o incorporar con la opción de diseño de la zona de destino que expone los servicios en un modelo de productor y consumidor.

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 socios de seguridad de Google Cloudofrecen 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 red 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 que se implementan 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 o un proxy de API, o un balanceador de cargas que actúe como 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 se implementan cargas de trabajo de backend dentro de una red interna, las redes de salida con control de acceso ayudan a mantener un nivel más alto de seguridad en 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 mediante 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 tu capa de API
• Filtrado de lista de entidades IP permitidas configurado para permitir solo la comunicación con fuentes y destinos de API predefinidos desde ambos lados

Para proteger un proxy de API, ten en cuenta estos otros aspectos de seguridad. Para obtener más información, consulta Prácticas recomendadas para proteger tus aplicaciones y APIs con Apigee.

Arquitectura

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

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

• En el 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 estar alineada 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 otros entornos de procesamiento. Los entornos pueden ser locales o de 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. Se permite el tráfico de retorno de estas conexiones cuando se usan reglas de firewall con estado. Puedes usar cualquier combinación de las siguientes funciones para proteger y limitar las comunicaciones solo a las direcciones IP de origen y destino permitidas:

  • 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 el servicio de prevención de intrusiones (IPS) para implementar una inspección profunda de paquetes para la prevención de amenazas

• 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 cumplir con 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 Google Cloud la puerta de enlace de API y el frontend global
• Expón servicios remotos con Private Service Connect

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

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 a través de la implementación de 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 de aprovisionamiento de conectividad:

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

Las capacidades de frontend global deGoogle 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.

Para optimizar las velocidades de entrega de contenido, se deben entregar esas aplicaciones desde los puntos de presencia (PoP) de Google Cloud . Los PoP de Google Cloud 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 el intercambio de tráfico entre VPC.

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

• Un balanceador de cargas (LB en el diagrama), donde 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 de Google Cloud envíe solicitudes de clientes a través de una conexión de Private Service Connect asociada con un adjunto de servicio de productor al servicio publicado (instancia del entorno de ejecución de Apigee) con grupos de extremos de red (NEG) de Private Service Connect.

La red descendente se establece 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.

Nota: Según tus requisitos, las APIs de los backends locales se pueden exponer a través de Apigee Hybrid, una puerta de enlace o un proxy de API de terceros, o un balanceador de cargas.

Expone servicios remotos con Private Service Connect

Usa la opción Private Service Connect para exponer servicios remotos en las siguientes situaciones:

• 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.
  • Hay una superposición de rangos de direcciones IP, como en una fusión o una adquisición.
• Para habilitar comunicaciones unidireccionales seguras entre clientes, aplicaciones y servicios en todos los entornos, incluso cuando tienes una fecha límite corta.
• 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 entre 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:

• Un adjunto de servicio que hace referencia a un balanceador de cargas de red de proxy interno regional o un balanceador de cargas de aplicaciones interno.
  • El balanceador de cargas usa un grupo de extremos de red híbrido (NEG de conectividad híbrida) en una VPC de productor que actúa en este diseño como una VPC de tránsito.

En el diagrama anterior, las cargas de trabajo de la red de VPC de tu aplicación pueden llegar 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 opción alternativa para el intercambio de tráfico con una VPC de tránsito.

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 administración compleja a gran escala.
• Mejora la seguridad, ya que proporciona un control de conectividad detallado.
• 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 la API mediante las opciones de diseño de redes que se analizaron anteriormente, incluida la opción de Private Service Connect.

Puedes hacer que se pueda acceder al extremo de Private Service Connect 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 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 interregionales al tráfico destinado a extremos con acceso global.

Nota: Para lograr verificaciones de estado distribuidas y facilitar la conexión de varias VPC a entornos locales a través de varias conexiones híbridas, encadena un balanceador de cargas de aplicaciones interno con un balanceador de cargas de aplicaciones externo. Para obtener más información, consulta Encadenado explícito de balanceadores de cargas de L7 de Google Cloud con PSC.

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.
  • 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.
• 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 entidades permitidas de direcciones IP. Una lista de entidades permitidas limita las comunicaciones a las fuentes y los destinos de direcciones IP específicas de los consumidores y las puertas de enlace de la 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, evitas asignar instancias de VM con direcciones IP públicas externas 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, puedes usar el proxy web seguro de Google Cloud. El proxy ofrece varios beneficios.

• 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 exponer las APIs seleccionadas de las 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 híbridas perimetrales, híbridas por niveles y particionadas de múltiples nubes.

Al igual que con el patrón de salida controlada, 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 entornos de computación privados, entornos locales o a otros entornos de nube, como se indica a continuación:

• 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 equilibrador de cargas mediante direcciones IP internas. No se puede acceder a otros sistemas implementados en Google Cloud .
• No se permite la comunicación de Google Cloud al entorno de computación privado ni a otros entornos de nube. El tráfico solo se inicia desde el entorno privado o desde otros entornos de nube hacia las APIs de Google Cloud.

Arquitectura

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

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

• En el lado de Google Cloud , implementa cargas de trabajo en una VPC de aplicación (o varias VPC).
• La red del entorno de Google Cloud se extiende a otros entornos de procesamiento (locales o en otra nube) mediante conectividad de red híbrida o multinube para facilitar la comunicación entre los entornos.
• De forma opcional, puedes usar una VPC de tránsito para lograr lo siguiente:
  • Proporciona capas adicionales de seguridad del perímetro 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.
  • Integra un dispositivo virtual de red (NVA) para inspeccionar el tráfico de la capa 7 en la VPC de tránsito.
• 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 la plataforma de API.

En el diagrama anterior, usar Apigee como la plataforma de API proporciona las siguientes funciones y capacidades para habilitar el patrón de entrada controlada:

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

En el diseño:

• La conectividad de red orientada al norte (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á asociada 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 la API.

  Además, puedes restringir la publicación de la subred de dirección IP interna de la carga de trabajo del 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 la API.

Es posible que ciertos requisitos de seguridad requieran una inspección de seguridad del perímetro 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 NVA de firewall de nueva generación (NGFW) con múltiples 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:

Como se ilustra en el diagrama anterior:

• La conectividad de red orientada al norte (para el tráfico proveniente de otros entornos) pasa a través de 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 mediante varias conexiones de red híbridas, puedes enviar parte del tráfico de 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. Además, puedes usar el acceso global de Private Service Connect para proporcionar opciones de conmutación por error.

Variantes

El patrón de arquitectura de entrada controlada se puede combinar con otros enfoques para cumplir con diferentes requisitos de diseño, sin dejar de considerar los requisitos de comunicación del patrón. El patrón ofrece las siguientes opciones:

• Cómo acceder a las APIs de Google desde otros entornos

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

• Usa una arquitectura de concentrador y radios para exponer los backends de la aplicación a otros entornos

Accede a las APIs de Google desde otros entornos

En situaciones que requieren acceso a los servicios de Google, como Cloud Storage o BigQuery, sin enviar tráfico a través de Internet público, Private Service Connect ofrece una solución. 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 otro tipo de nube a través de una conexión de red híbrida con la dirección IP del extremo de Private Service Connect. Si deseas obtener más información para acceder 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.

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

Se puede acceder a las APIs de Google mediante extremos o backends. Los extremos 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.

Nota: Los extremos de Private Service Connect se registran en el Directorio de servicios para las APIs de Google, donde puedes almacenar, administrar y publicar servicios.

Expone 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 necesites implementar backends en Google Cloud mientras mantienes frontends en entornos de computación privados. Si bien es menos común, este enfoque se aplica cuando se trata de frontends monolíticos pesados que pueden depender de componentes heredados. O, más comúnmente, cuando se administran aplicaciones distribuidas en varios entornos, incluidos los locales y otras nubes, que requieren conectividad a backends alojados en Google Cloud a través de una red híbrida.

En una arquitectura de este tipo, puedes usar una puerta de enlace de API local o un balanceador de cargas 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:

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 tiempo de ejecución alojado en tu otro entorno. Puedes instalar y administrar el plano 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 requirements para cargas de trabajo distribuidas en Google Cloud y otros ambientes, 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 backends de la aplicación a otros entornos

En algunos casos, es posible que se requiera exponer APIs de 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 diversas VPC (radios), lo que permite una comunicación segura a través de la conectividad híbrida privada. De manera opcional, las funciones de API Gateway locales en otros entornos, como Apigee Hybrid, se pueden usar para finalizar las solicitudes del cliente de forma local donde se aloja el frontend de la aplicación.

Como se ilustra en el diagrama anterior:

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

• En este diseño, se supone que las VPC de radio no requieren comunicación directa de VPC a VPC.

  • Si se requiere la comunicación de nodo a nodo, puedes usar la NVA para facilitarla.
  • Si tienes diferentes backends en diferentes VPC, 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 norte-sur y sur-norte entre las VPC de radio y la VPC del 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 herramientas de redes adicionales, usa VPC compartida.

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

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

• Si se requieren ciertas funciones de balanceo de cargas o de seguridad, como agregar la protección contra DDoS o el 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 un VPC externo 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 fluida de la solución a un entorno completamente alojado en Google Cloudy, al mismo tiempo, mantiene la coherencia de la plataforma de la API (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 VPC 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 para aprovisionar medidas de seguridad adicionales del perímetro y conectividad híbrida fuera de la VPC de la carga de trabajo.
• Usa Private Service Connect para acceder a las APIs y los servicios de Google desde entornos locales o de otro tipo 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.
  • Cuando sea necesario, puedes extender los perímetros de servicio a un entorno híbrido a través de una VPN o 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.
• 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 a 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 NVA, es importante tener en cuenta la alta disponibilidad (HA) de las NVA para evitar un punto único de fallo que podría bloquear toda la comunicación. Sigue la guía de diseño y de implementación de la HA y la redundancia que te proporciona tu proveedor de NVA.
• Para fortalecer la seguridad del perímetro y proteger la puerta de enlace de la API que se implementa en el entorno respectivo, puedes implementar de manera opcional mecanismos de balanceo de cargas y 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, evitarás asignar instancias de VM con direcciones IP públicas externas 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 se pueden ejecutar en Google Cloud, en entornos privados locales 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 está restringida a las APIs expuestas o a direcciones IP específicas, las redes de los entornos no necesitan alinearse en tu diseño. Entre las situaciones comunes aplicables, se incluyen las siguientes:

• 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 implementes en Google Cloud pueden comunicarse con la puerta de enlace de API (o direcciones IP de destino específicas) mediante 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 procesamiento pueden comunicarse con la puerta de enlace de API de Google Cloud(o una dirección IP de extremo publicada específica) mediante 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:

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

• En el lado de Google Cloud , implementas cargas de trabajo en una VPC (o VPC compartida) sin exponerlas directamente a Internet.
• La red del entorno de 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 multinube adecuado para facilitar la comunicación entre 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 híbrido por niveles o patrón de múltiples nubes particionadas). A medida que las aplicaciones evolucionan y migran a la nube, a menudo surgen dependencias y preferencias para servicios específicos de la nube.

A veces, estas dependencias y preferencias llevan a la distribución de aplicaciones y backends entre diferentes proveedores de servicios en la nube. Además, algunas aplicaciones se pueden compilar 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 realiza 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).

El uso del diseño de Google Cloud en el 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 capacidades avanzadas de carga de balanceo y seguridad de Google Cloud distribuidas en puntos de presencia (PoP):
• Usa servicios administrados sin servidores para reducir los gastos de capital y simplificar las operaciones.
• Optimiza las conexiones a los backends de la aplicación de forma global para mejorar la velocidad y la latencia.
  • La red multinube deGoogle Cloudhabilita la comunicación multinube entre los componentes de la aplicación 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 cumplir con diferentes requisitos de diseño, sin dejar de considerar los requisitos de comunicación de este patrón. Los patrones ofrecen las siguientes opciones:

• Puertas de enlace de API distribuidas
• Comunicación bidireccional de la API con Private Service Connect
• Comunicación bidireccional con extremos e interfaces de Private Service Connect

Puertas de enlace de API distribuidas

En situaciones como la que se basa en el patrón de múltiples nubes particionadas, las aplicaciones (o los componentes de la aplicación) 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 API 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 API está centralizada 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.

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

• Las solicitudes del cliente llegan al frontend de la aplicación directamente en el entorno que aloja la aplicación (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 forma opcional, puedes considerar usar una VPC de tránsito. Una VPC de tránsito puede proporcionar flexibilidad para separar las inquietudes 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 de las direcciones IP, una VPC de tránsito (en la que se conecta 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 es 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 función de intercambio de rutas del cliente. El diseño permite que las solicitudes de API específicas que se originan en cargas de trabajo alojadas en 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á asociado con 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 APIs con Private Service Connect.

Comunicación de API bidireccional 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 empresariales para permitir la comunicación y la integración entre ciertas aplicaciones en diferentes entornos. Por ejemplo, si tu empresa adquirió otra, es posible que necesites 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, de forma local o en otras nubes) y deben evitar la superposición de direcciones IP. En esos casos, puedes usar Private Service Connect para facilitar una comunicación eficaz.

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 ensamblado de aplicaciones en entornos de múltiples nubes y locales. Esto puede satisfacer diferentes requisitos de comunicación, como la integración de aplicaciones seguras en las que no se usa una puerta de enlace de API o no se planea usarla.

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.

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 o fuera de la VPC del consumidor, 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 adjunta a la VPC de tránsito (consumidor). Es posible llegar a destinos externos a los que se puede acceder desde la VPC del consumidor (de tránsito) a la que está conectada 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:

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 caso, 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. También puedes considerar un enfoque alternativo si no cumple con el cumplimiento o los estándares de seguridad de tu organización.

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 Hybrid como una solución de puerta de enlace de API.

  • Este enfoque también facilita la migración de la solución a un entorno alojado por completo en Google Cloudy, al mismo tiempo, mantiene la coherencia de la plataforma de la 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 de destino 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 de Google Cloud en tus proyectos y mitigar el riesgo de robo de datos especificando perímetros de servicio a nivel del proyecto o de la red de VPC.

  • 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.

• 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 a 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.

  • 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.

Patrones de traspaso

Con el patrón de traspaso, la arquitectura se basa en el uso de los servicios de almacenamiento que proporcionaGoogle 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 Cloud, o bien otros servicios de Google (por ejemplo, servicios de análisis de datos y de inteligencia artificial) consumen datos de las ubicaciones de almacenamiento compartidas y los procesan de forma continua o por lotes.

Arquitectura

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

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

• En Google Cloud , implementa 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 de robo de datos no autorizados 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 conectarse depende de varios aspectos, como los siguientes:
  • Volumen de tráfico esperado
  • Si se trata de 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 de movimiento de datos integradas y centradas en la nube, como el paquete de soluciones de Google Cloud. 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 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 servicios de Google Cloud 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.

  • 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.

• Comunicarse con cargas de trabajo de análisis de datos publicadas públicamente que se alojan 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 evitar que se pueda acceder directamente a estas instancias 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 para las topologías de red para nube híbrida y múltiples nubes.

Prácticas recomendadas generales

Cuando diseñes y realices la integración de identidades en la nube, jerarquía de recursos y redes de zonas de destino, ten en cuenta las recomendaciones de diseño en el diseño de la zona de destino en Google Cloud y las prácticas recomendadas de seguridad de Google Cloud que se describen en el plano de las bases empresariales. Valida el diseño seleccionado en función de los siguientes documentos:

• Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC
• Decide una jerarquía de recursos para la zona de destino de Google Cloud
• Google Cloud Framework de la arquitectura: Seguridad, privacidad y cumplimiento

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

• Cuando elijas una opción de conectividad de red híbrida o de múltiples nubes, ten en cuenta los requisitos empresariales y de aplicación, como los ANSs, el rendimiento, la seguridad, el costo, la confiabilidad y el ancho de banda. Para obtener más información, consulta Elige un producto de conectividad de red y Patrones para conectar otros proveedores de servicios en la nube con Google Cloud.

• Usa VPCs compartidas en Google Cloud en lugar de varias VPCs cuando sean apropiadas y estén alineadas con los requisitos de diseño de la jerarquía de recursos. Para obtener más información, consulta Decide si crear o no varias redes de VPC.

• Sigue las prácticas recomendadas para planificar cuentas y organizaciones.

• Cuando corresponda, establece una identidad común entre los entornos para que los sistemas puedan autenticarse de manera segura a través de los límites del entorno.

• Para exponer aplicaciones de forma segura a los usuarios corporativos en una configuración híbrida y elegir el enfoque que mejor se adapte a tus requisitos, debes seguir las formas recomendadas de integrar Google Cloud con tu sistema de administración de identidades.

  • Consulta también Patrones para autenticar a los usuarios del personal en un entorno híbrido.

• Cuando diseñes tus entornos locales y de nube, ten en cuenta la dirección IPv6 desde el principio y ten en cuenta qué servicios la admiten. Para obtener más información, consulta Introducción a IPv6 en Google Cloud. En él, se resumen los servicios que se admitían cuando se escribió el blog.

• Cuando diseñes, implementes y administres las reglas de firewall de tu VPC, podrás hacer lo siguiente:

  • Usa el filtrado basado en cuentas de servicio en lugar del filtrado basado en etiquetas de red si necesitas un control estricto sobre cómo se aplican las reglas de firewall a las VMs.
  • Usa políticas de firewall cuando agrupes varias reglas de firewall para que puedas actualizarlas todas a la vez. También puedes hacer que la política sea jerárquica. Para obtener más información sobre las especificaciones y las políticas de los firewalls jerárquicos, consulta Políticas de firewall jerárquicas.
  • Usa objetos de ubicación geográfica en la política de firewall cuando necesites filtrar el tráfico IPv4 y IPv6 externo según ubicaciones o regiones geográficas específicas.
  • Usa Threat Intelligence para reglas de políticas de firewall si necesitas proteger tu red mediante el permiso o el bloqueo de tráfico según los datos de Threat Intelligence, como las direcciones IP maliciosas conocidas o los rangos de direcciones IP de la nube pública. Por ejemplo, puedes permitir el tráfico desde rangos específicos de direcciones IP de la nube pública si tus servicios solo necesitan comunicarse con esa nube pública. Para obtener más información, consulta las Prácticas recomendadas para las reglas de firewall.

• Siempre debes diseñar tu seguridad en la nube y en la red con un enfoque de seguridad de varias capas, teniendo en cuenta capas de seguridad adicionales, como las siguientes:

  • Google Cloud Armor
  • Sistema de detección de intrusiones de Cloud
  • IPS de Cloud Next Generation Firewall
  • Threat Intelligence para reglas de políticas de firewall

  Estas capas adicionales pueden ayudarte a filtrar, inspeccionar y supervisar una amplia variedad de amenazas en las capas de red y de aplicación para su análisis y prevención.

• Cuando decidas dónde se debe realizar la resolución de DNS en una configuración híbrida, te recomendamos que uses dos sistemas de DNS autorizados para tu entorno privado deGoogle Cloud y para tus recursos locales que se alojan en servidores DNS existentes en tu entorno local. Para obtener más información, consulta Elige dónde realizar la resolución de DNS.

• Cuando sea posible, siempre expone aplicaciones a través de APIs mediante una puerta de enlace de API o un balanceador de cargas. Te recomendamos que consideres una plataforma de API como Apigee. Apigee actúa como una abstracción o fachada para tus APIs de servicio de backend, combinada con capacidades de seguridad, límites de frecuencia, cuotas y estadísticas.

• Una plataforma de API (puerta de enlace o proxy) y el balanceador de cargas de aplicaciones no son mutuamente excluyentes. A veces, el uso de las puertas de enlace de API y los balanceadores de cargas en conjunto pueden proporcionar una solución más sólida y segura para administrar y distribuir el tráfico de API a gran escala. El uso de las puertas de enlace de la API de Cloud Load Balancing te permite lograr lo siguiente:

  • Entrega APIs de alto rendimiento con Apigee y Cloud CDN para hacer lo siguiente:

    • Reducir la latencia
    • Aloja las APIs en todo el mundo

    • Aumenta la disponibilidad para las temporadas de mayor tráfico

      Para obtener más información, mira Delivering high-performanceAPIs with Apigee and Cloud CDN (Entrega APIs de alto rendimiento con Apigee y Cloud CDN) en YouTube.

  • Implementa la administración avanzada del tráfico.

  • Usa Google Cloud Armor como protección contra DSD, WAF y servicio de seguridad de red para proteger tus APIs.

  • Administra un balanceo de cargas eficiente en varias puertas de enlace en varias regiones. Para obtener más información, consulta Protege las APIs e implementa la conmutación por error multirregional con PSC y Apigee.

• Para determinar qué producto de Cloud Load Balancing usar, primero debes determinar qué tipo de tráfico deben manejar tus balanceadores de cargas. Para obtener más información, consulta Elige un balanceador de cargas.

• Cuando se usa Cloud Load Balancing, debes usar sus capacidades de optimización de la capacidad de la aplicación cuando corresponda. Esto puede ayudarte a abordar algunos de los desafíos de capacidad que pueden ocurrir en aplicaciones distribuidas a nivel mundial.

  • Para obtener un análisis detallado sobre la latencia, consulta Optimiza la latencia de la aplicación con el balanceo de cargas.

• Si bien Cloud VPN encripta el tráfico entre entornos, con Cloud Interconnect debes usar MACsec o VPN con alta disponibilidad en Cloud Interconnect para encriptar el tráfico en tránsito en la conectividad capa. Para obtener más información, consulta Cómo puedo encriptar mi tráfico en Cloud Interconnect

  • También puedes considerar la encriptación de la capa de servicio con TLS. Para obtener más información, consulta Decide cómo cumplir con los requisitos de cumplimiento para la encriptación en tránsito.

• Si necesitas más volumen de tráfico a través de una conectividad híbrida de VPN que un solo túnel de VPN puede admitir, puedes considerar usar la opción de enrutamiento de VPN con alta disponibilidad activo/activo.

  • Para configuraciones híbridas o de múltiples nubes a largo plazo con grandes volúmenes de transferencia de datos salientes, considera Cloud Interconnect o Cross-Cloud Interconnect. Esas opciones de conectividad ayudan a optimizar el rendimiento de la conectividad y pueden reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Cuando te conectes a los recursos de Google Cloud y trates de elegir entre Cloud Interconnect, el intercambio de tráfico directo o el intercambio de tráfico por proveedores, te recomendamos usar Cloud Interconnect, a menos que necesites acceder a las aplicaciones de Google Workspace. Para obtener más información, puedes comparar las características del intercambio de tráfico directo con Cloud Interconnect y el intercambio de tráfico por proveedores con Cloud Interconnect.

• Deja espacio de dirección IP suficiente en la dirección IP RFC 1918 existente para todos los sistemas alojados en la nube.

• Si tienes restricciones técnicas que requieren que conserves tu rango de direcciones IP, puedes hacer lo siguiente:

  • Usa las mismas direcciones IP internas para tus cargas de trabajo locales mientras las migras a Google Cloud, con subredes híbridas.

  • Aprovisiona y usa tus propias direcciones IPv4 públicas para los recursos deGoogle Cloud con usa tu propia IP (BYOIP) en Google.

• Si el diseño de tu solución requiere exponer una aplicación basada enGoogle Clouda la Internet pública, considera las recomendaciones de diseño que se analizan en Redes para la entrega de aplicaciones orientadas a Internet.

• Cuando corresponda, usa extremos de Private Service Connect para permitir que las cargas de trabajo en Google Cloud, de forma local o en otro entorno de nube con conectividad híbrida, accedan a las APIs de Google de forma privada o a servicios publicados, mediante direcciones IP internas de manera detallada.

• Cuando uses Private Service Connect, debes controlar lo siguiente:

  • Quién puede implementar recursos de Private Service Connect
  • Si se pueden establecer conexiones entre consumidores y productores
  • Qué tráfico de red puede acceder a esas conexiones

  Para obtener más información, consulta Seguridad de Private Service Connect.

• Para lograr una configuración de nube sólida en el contexto de la arquitectura de nube híbrida y de múltiples nubes:

  • Realiza una evaluación integral de los niveles requeridos de confiabilidad de las diferentes aplicaciones en todos los entornos. Esto puede ayudarte a cumplir con tus objetivos de disponibilidad y resiliencia.
  • Comprende las capacidades de confiabilidad y los principios de diseño de tu proveedor de servicios en la nube. Para obtener más información, consulta la confiabilidad de la infraestructura deGoogle Cloud .

• La visibilidad y la supervisión de la red de la nube son esenciales para mantener comunicaciones confiables. Network Intelligence Center proporciona una sola consola para administrar la visibilidad, la supervisión y la solución de problemas de la red.

Patrones de arquitectura de herramientas de redes seguras de nubes híbridas y múltiples: ¿Qué sigue?

• Obtén más información sobre los patrones de arquitectura comunes que puedes utilizar mediante el uso de los patrones de red que se analizan en este documento.
• Aprende cómo abordar la nube híbrida y las múltiples nubes y cómo elegir cargas de trabajo adecuadas.
• Obtén más información sobre Google Cloud Cross-Cloud Network, una plataforma de red global abierta, segura y optimizada para aplicaciones y usuarios locales y en otras nubes.
• Diseña una infraestructura confiable para tus cargas de trabajo en Google Cloud: orientación de diseño para ayudar a proteger tus aplicaciones de fallas a nivel de recurso, zona y región.
• Para obtener más información sobre el diseño de arquitecturas de alta disponibilidad enGoogle Cloud, consulta los patrones para apps resilientes y escalables.
• Obtén más información sobre las posibles opciones de conectividad para conectar el clúster de GKE Enterprise que se ejecuta en tu entorno local o perimetral a la red de Google Cloud junto con el Impacto de la desconexión temporal de Google Cloud.