Patrones de arquitectura de redes seguras híbridas y multinube

Last reviewed 2025-01-23 UTC

En esta página se ofrece una vista de una sola página de todas las páginas de Crea arquitecturas híbridas y multinube con Google Cloud. Puedes imprimir esta página o guardarla en formato PDF mediante la función de impresión de tu navegador y seleccionando la opción Guardar como PDF. Esta página no proporciona un panel de índice en la parte derecha.

Este documento es el tercero de un conjunto de tres documentos. Se analizan los patrones de arquitectura de redes híbridas y multinube. En esta parte se analizan varios patrones de arquitectura de red segura habituales que puedes usar en arquitecturas híbridas y multinube. En él se describen los casos en los que estos patrones de redes son más adecuados y se ofrecen prácticas recomendadas para implementarlos con Google Cloud.

El conjunto de documentos sobre patrones de arquitectura híbridos y multinube consta de las siguientes partes:

• Crea arquitecturas híbridas y multinube: se explica cómo planificar una estrategia para diseñar una configuración híbrida y multinube con Google Cloud.
• Patrones de arquitectura híbridos y multinube: se analizan los patrones de arquitectura habituales que se pueden adoptar como parte de una estrategia híbrida y multinube.
• Patrones de arquitectura de redes seguras híbridas y multinube: se analizan los patrones de arquitectura de redes híbridas y multinube desde una perspectiva de redes (este documento).

Conectar entornos de computación privados de forma segura y fiable es esencial para cualquier arquitectura híbrida y multinube que quiera tener éxito. Google Cloud La conectividad de redes híbridas y el patrón de arquitectura de redes en la nube que elijas para una configuración híbrida y multinube deben cumplir los requisitos únicos de las cargas de trabajo de tu empresa. También debe adaptarse a los patrones de arquitectura que quieras aplicar. Aunque es posible que tengas que adaptar cada diseño, hay patrones comunes que puedes usar como modelo.

Los patrones de arquitectura de red de este documento no deben considerarse alternativas al diseño de la zona de aterrizaje 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, que abarca las siguientes áreas: Google Cloud

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

Las distintas aplicaciones pueden usar diferentes patrones de arquitectura de red, que se incorporan como parte de una arquitectura de zona de aterrizaje. En una configuración multicloud, debes mantener la coherencia del diseño de la zona de aterrizaje en todos los entornos.

Esta serie contiene las siguientes páginas:

• Consideraciones de diseño
• Patrones de arquitectura
  • Patrón reflejado
  • Patrón de malla
  • Patrones de acceso restringido
    • Salida controlada
    • Entrada controlada
    • Salida y entrada controladas
  • Transferencia
• Prácticas recomendadas generales

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de clientes de partners

Otros colaboradores:

• Saud Albazei | Ingeniero de clientes, Modernización de aplicaciones
• Anna Berenberg | Ingeniera
• Marco Ferrari | Arquitecto de soluciones en la nube
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Arquitecto de soluciones en la nube
• Mark Schlagenhauf | Redactor técnico 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 describen patrones de arquitectura de redes diseñados en función de los modelos de comunicación necesarios entre las aplicaciones que residen en Google Cloud y en otros entornos (on-premise, en otras nubes o en ambos).

Estos patrones deben incorporarse a la arquitectura general de la zona de aterrizaje de la organización, que puede incluir varios patrones de red para abordar los requisitos específicos de comunicación y seguridad de las diferentes aplicaciones.

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

• Patrón reflejado
• Patrón de malla
• Patrones de acceso restringido
  • Salida controlada
  • Entrada controlada
  • Salida y entrada controladas
• Patrón de transferencia

Patrón reflejado

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

El patrón reflejado presupone que las cargas de trabajo de prueba y de producción no deben comunicarse directamente entre sí. Sin embargo, debería ser posible gestionar e implementar ambos grupos de cargas de trabajo de forma coherente.

Si usas este patrón, conecta los dos entornos informáticos de forma que se ajusten a los siguientes requisitos:

• La integración y la implementación continuas (CI/CD) pueden desplegar y gestionar cargas de trabajo en todos los entornos informáticos o en entornos específicos.
• Los sistemas de monitorización, gestión de la configuración y otros sistemas administrativos deben funcionar en todos los entornos informáticos.
• Las cargas de trabajo no pueden comunicarse directamente entre entornos informáticos. Si es necesario, la comunicación debe ser precisa 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, monitorización, gestión de la configuración, 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, CI/CD y herramientas administrativas) en VPCs independientes en el lado de Google Cloud .
• VPC compartida se usa para cargas de trabajo de desarrollo y pruebas. Se usa una VPC adicional para las herramientas de CI/CD y de administración. Con VPCs compartidas:
  • Las aplicaciones las gestionan diferentes equipos por entorno y por proyecto de servicio.
  • El proyecto host administra y controla la comunicación de red y los controles de seguridad entre los entornos de desarrollo y de 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 cortafuegos solo permiten el tráfico autorizado.
  • También puedes usar Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para implementar la inspección profunda de paquetes con el fin de prevenir amenazas sin cambiar el diseño ni el enrutamiento. El cortafuegos empresarial de nueva generación de Cloud funciona creando endpoints de cortafuegos zonales gestionados por Google que usan tecnología de interceptación de paquetes para inspeccionar de forma transparente las cargas de trabajo en busca de las firmas de amenazas configuradas. También protege las cargas de trabajo frente a las amenazas.
• Permite la comunicación entre las VPCs emparejadas mediante direcciones IP internas.
  • El peering de este patrón permite que los sistemas de CI/CD y administrativos desplieguen y gestionen cargas de trabajo de desarrollo y pruebas.
• Consulta estas prácticas recomendadas generales.

Para establecer esta conexión de CI/CD, debes usar una de las opciones de conectividad de redes híbridas y multinube que se han descrito y que cumpla los requisitos de tu empresa y tus aplicaciones. Para que puedas implementar y gestionar 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 solapamientos.

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

• Puedes desplegar Cloud NAT en la misma red del proyecto del host de VPC compartida. Si implementas en la misma red del proyecto host de VPC compartida, evitarás que se pueda acceder directamente a estas instancias desde Internet.
• Para el tráfico web de salida, puedes usar Secure Web Proxy. El proxy ofrece varias ventajas.

Para obtener más información sobre las Google Cloud herramientas y las funciones que te ayudan a compilar, probar e implementar en Google Cloud y en entornos híbridos y multicloud, consulta la entrada de blog DevOps y CI/CD en Google Cloud : explicación.

Variantes

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

• VPC compartida por entorno
• Cortafuegos de capa de aplicación centralizado
• Topología de concentrador y radios
• 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 aplicación o de servicio entre entornos, incluidas las herramientas de CI/CD y las administrativas que puedan ser necesarias para cumplir determinados requisitos de seguridad de la organización. Estos requisitos limitan la comunicación, el dominio administrativo y el control de acceso de los diferentes servicios, que también deben gestionar distintos equipos.

Este diseño consigue la separación proporcionando aislamiento a nivel de red y de proyecto entre los distintos entornos, lo que permite una comunicación más precisa y un control de acceso de Gestión de Identidades y Accesos (IAM).

Desde el punto de vista de la gestión y las operaciones, este diseño ofrece la flexibilidad necesaria para gestionar las aplicaciones y las cargas de trabajo creadas por diferentes equipos por entorno y por proyecto de servicio. Los equipos de operaciones de redes pueden aprovisionar y gestionar las redes de VPC y sus funciones de seguridad en función de las siguientes estructuras posibles:

• Un equipo gestiona todos los proyectos host en todos los entornos.
• Diferentes equipos gestionan los proyectos host en sus respectivos entornos.

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

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

Cortafuegos de capa de aplicación centralizado

En algunos casos, los requisitos de seguridad pueden exigir que se tengan en cuenta la capa de aplicación (capa 7) y la inspección profunda de paquetes con mecanismos de cortafuegos avanzados que superen las funciones del cortafuegos de nueva generación de Cloud. Para cumplir los requisitos y estándares de seguridad de tu organización, puedes usar un dispositivo NGFW alojado en un dispositivo virtual de red (NVA). Varios Google Cloud partners de seguridad ofrecen opciones que se adaptan bien a esta tarea.

Como se muestra 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 VPCs compartidas, como se muestra en el siguiente diagrama.

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

Para disfrutar de una estrategia de seguridad multicapa sólida que incluya reglas de cortafuegos de VPC y funciones de servicio de prevención de intrusiones, añade más inspección de tráfico y control de seguridad a los flujos de tráfico este-oeste y norte-sur.

Nota: En las regiones de la nube admitidas, y cuando sea técnicamente posible para tu diseño, las NVAs se pueden implementar sin necesidad de varias redes de VPC ni interfaces de dispositivos. Esta implementación se basa en el uso del balanceo de carga y las funciones de rutas basadas en políticas. Estas funciones permiten integrar las NVAs en tu red de nube mediante un mecanismo independiente de la topología y basado en políticas. Para obtener más información, consulta el artículo Implementar dispositivos virtuales de red (NVAs) sin varias VPCs

.

Topología de concentrador y radios

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

• Las aplicaciones necesitan acceder a un conjunto común de servicios, como la monitorización, las herramientas de gestión de la configuración, la integración continua y la entrega continua o la autenticación.
• Es necesario aplicar un conjunto común de políticas de seguridad al tráfico entrante y saliente de forma centralizada a través del centro de control.

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

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

Como parte de la arquitectura de red en malla, estas son las principales opciones de conectividad (entre las VPCs de los radios y del centro) en Google Cloud:

• Emparejamiento entre redes VPC
• VPN
• Usar 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 tener en cuenta en tu diseño, consulta Arquitectura de red de concentrador y radios. Un factor clave que influye en la elección de una VPN en lugar del emparejamiento de VPC entre los radios y la VPC de concentrador es cuando se requiere la transitividad del tráfico. La transitividad del tráfico significa que el tráfico de un spoke puede llegar a otros spokes a través del centro de conectividad.

Arquitectura distribuida de confianza cero de microservicios

Las arquitecturas híbridas y multinube pueden requerir varios clústeres para alcanzar sus objetivos técnicos y empresariales, como separar el 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, sobre todo cuando se requieren para cumplir determinados requisitos de seguridad.

No basta con cumplir los requisitos de seguridad de las arquitecturas de microservicios distribuidas y basadas en la nube actuales, sino que también debes tener en cuenta 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 a nivel de microservicio, la autenticación y la identidad de la carga de trabajo. La confianza se basa en la identidad y se aplica a cada servicio.

Al usar una arquitectura de proxy distribuido, como una malla de servicios, los servicios pueden validar de forma eficaz a los llamantes e implementar políticas de control de acceso pormenorizado para cada solicitud, lo que permite crear un entorno de microservicios más seguro y escalable. Cloud Service Mesh te ofrece la flexibilidad de tener una malla común que puede abarcar tus despliegues deGoogle Cloud y on-premise. La malla usa políticas de autorización para proteger las comunicaciones entre servicios.

También puedes incorporar Apigee Adapter for Envoy, que es un despliegue ligero de la pasarela de APIs de Apigee en un clúster de Kubernetes, con esta arquitectura. Apigee Adapter for Envoy es un proxy de servicio y de edge de código abierto diseñado para aplicaciones 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 redGoogle Cloud .
• Configurar una malla multinube o híbrida
  • Despliega Cloud Service Mesh en entornos y clústeres.

Prácticas recomendadas para los patrones reflejados

• Los sistemas de integración y entrega continuas (CI/CD) necesarios para desplegar o reconfigurar las implementaciones de producción deben tener una alta disponibilidad, lo que significa que todos los componentes de la arquitectura deben diseñarse para proporcionar el nivel de disponibilidad del sistema esperado. Para obtener más información, consulta Google Cloud fiabilidad de la infraestructura.
• Para eliminar los errores de configuración en procesos repetidos, como las actualizaciones de código, es fundamental automatizar las compilaciones, las pruebas y los despliegues.
• La integración de NVAs centralizadas en este diseño puede requerir la incorporación de varios segmentos con diferentes niveles de controles de acceso de seguridad.
• Al diseñar una solución que incluya NVAs, es importante tener en cuenta la alta disponibilidad (HA) de las NVAs para evitar un único punto de fallo que pueda bloquear todas las comunicaciones. Sigue las directrices de diseño e implementación de alta disponibilidad y redundancia proporcionadas por tu proveedor de VNA.
• Si no exportas las rutas IP on-premise a través del emparejamiento de VPC o de 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 on-premise. Para obtener más información, consulta el artículo Intercambio de rutas personalizadas en el emparejamiento entre redes de VPC.
• En el caso de las cargas de trabajo con direcciones IP privadas que requieran acceso a las APIs de Google, puedes exponer las APIs de Google mediante un punto final de Private Service Connect en una red de VPC. Para obtener más información, consulta Acceso restringido en esta serie.
• Consulta las prácticas recomendadas generales para los patrones de arquitectura de redes híbridas y multinube.

Patrón de malla

El patrón en malla se basa en el establecimiento de una arquitectura de red híbrida. Esta arquitectura abarca varios entornos informáticos. En estos entornos, todos los sistemas pueden comunicarse entre sí y no se limitan a la comunicación unidireccional en función de los requisitos de seguridad de tus aplicaciones. Este patrón de red se aplica principalmente a las arquitecturas híbridas por niveles, multinube particionadas o de picos de carga. También se aplica al diseño de continuidad de la actividad empresarial para aprovisionar un entorno de recuperación tras desastres en Google Cloud. En todos los casos, debes conectar los entornos informáticos de forma que se ajusten a 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 puede iniciarse desde cualquiera de las dos partes. Los detalles del modelo de comunicaciones pueden variar en función de las aplicaciones y los requisitos de seguridad, como los modelos de comunicación que se describen en las opciones de diseño que se indican a continuación.
• Las reglas de firewall que utilice deben permitir el tráfico entre fuentes y destinos de direcciones IP específicas en función de los requisitos de la aplicación o las aplicaciones para las que se ha diseñado el patrón. Lo ideal es que uses un enfoque de seguridad multicapa para restringir los flujos de tráfico de forma granular, tanto entre entornos informáticos como dentro de ellos.

Arquitectura

En el siguiente diagrama se muestra 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 superposiciones.
• En el Google Cloud lado, puedes desplegar cargas de trabajo en una o varias VPCs compartidas o no compartidas. Para ver otras opciones de diseño posibles de este patrón, consulta las variaciones de diseño que se indican a continuación. La estructura seleccionada de tus VPCs debe alinearse con los proyectos y el diseño de la jerarquía de recursos de tu organización.
• La red de VPC de Google Cloud se extiende a otros entornos de computación. Estos entornos pueden ser on-premise o estar en otra nube. Usa una de las opciones de conectividad de redes híbridas y multinube que se adapte a los requisitos de tu empresa y tus aplicaciones.

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

  • Reglas de cortafuegos o políticas de cortafuegos.

  • Dispositivo virtual de red (NVA) con funciones de inspección de cortafuegos de nueva generación (NGFW) situado en la ruta de la red.

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

Variantes

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

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

Una VPC por entorno

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

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

Como se muestra en el siguiente diagrama, el diseño de una VPC por entorno permite que cada VPC se integre directamente con el entorno on-premise u otros entornos de nube mediante VPNs o Cloud Interconnect con varios adjuntos de VLAN.

El patrón que se muestra en el diagrama anterior se puede aplicar en una zona de aterrizaje con una topología de red de concentrador y radios. En esa topología, se puede compartir una o varias conexiones híbridas con todas las VPCs de radio. Se comparte mediante una VPC de tránsito para finalizar tanto la conectividad híbrida como las otras VPC de spoke. También puedes ampliar este diseño añadiendo una NVA con funciones de inspección de cortafuegos de última generación (NGFW) en la VPC de tránsito, tal como se describe en la siguiente sección, "Usar un cortafuegos de capa de aplicación centralizado".

Usar un cortafuegos de capa de aplicación centralizado

Si tus requisitos técnicos exigen que se tenga en cuenta la capa de aplicación (capa 7) y la inspección profunda de paquetes con funciones avanzadas de cortafuegos que superen las de Cloud Next Generation Firewall, puedes usar un dispositivo NGFW alojado en una NVA. Sin embargo, esa VNA debe cumplir los requisitos de seguridad de tu organización. Para implementar estos mecanismos, puedes ampliar la topología para que todo el tráfico entre entornos pase por un firewall de NVA centralizado, como se muestra en el siguiente diagrama.

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

Como se muestra en el diagrama anterior, la NVA actúa como capa de seguridad perimetral y sirve de base para habilitar la inspección del tráfico insertada. También aplica políticas estrictas de control de acceso. Para inspeccionar los flujos de tráfico este-oeste y norte-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 en contenedores, la arquitectura distribuida de confianza cero de microservicios que se describe en la sección sobre el patrón reflejado también se aplica a este patrón de arquitectura.

La diferencia principal entre este patrón y el patrón reflejado es que el modelo de comunicación entre las cargas de trabajo de Google Cloud y otros entornos se puede iniciar desde cualquier lado. El tráfico debe controlarse y granularse en función de los requisitos de la aplicación y de seguridad mediante malla de servicios.

Prácticas recomendadas para los patrones combinados

• Antes de hacer nada más, decide el diseño de la jerarquía de recursos y el diseño necesario para admitir cualquier proyecto y VPC. De esta forma, podrás seleccionar la arquitectura de red óptima que se ajuste a la estructura de tus Google Cloud proyectos.
• Usa una arquitectura distribuida de confianza cero cuando utilices Kubernetes en tu entorno de computación privado yGoogle Cloud.
• Cuando uses NVAs centralizadas en tu diseño, debes definir varios segmentos con diferentes niveles de controles de acceso de seguridad y políticas de inspección del tráfico. Basa estos controles y políticas en los requisitos de seguridad de tus aplicaciones.
• Al diseñar una solución que incluya NVAs, es importante tener en cuenta la alta disponibilidad (HA) de las NVAs para evitar un único punto de fallo que pueda bloquear todas las comunicaciones. Sigue las directrices de diseño e implementación de alta disponibilidad y redundancia proporcionadas por el Google Cloud proveedor de seguridad que suministra tus NVAs.
• Para aumentar la privacidad, la integridad de los datos y un modelo de comunicación controlado, expón las aplicaciones a través de APIs mediante pasarelas de APIs, como Apigee y Apigee hybrid, con mTLS de extremo a extremo. También puedes usar una VPC compartida con Apigee en el mismo recurso de organización.
• Si el diseño de tu solución requiere exponer una aplicación basada en Google Cloud a Internet, ten en cuenta las recomendaciones de diseño que se describen en el artículo Redes para la entrega de aplicaciones orientadas a Internet.
• Para proteger los Google Cloud servicios de tus proyectos y mitigar el riesgo de filtración externa de datos, usa Controles de Servicio de VPC para especificar perímetros de servicio a nivel de proyecto o de red de VPC. También puedes ampliar los perímetros de servicio a un entorno híbrido a través de una VPN o Cloud Interconnect autorizados. Para obtener más información sobre las ventajas de los perímetros de servicio, consulta la información general sobre Controles de Servicio de VPC.
• Consulta las prácticas recomendadas generales para los patrones de redes híbridas y multicloud.

Si quieres aplicar un aislamiento más estricto y un acceso más granular entre tus aplicaciones alojadas en Google Cloudy en otros entornos, considera la posibilidad de usar uno de los patrones cerrados que se describen en los demás documentos de esta serie.

Patrones de acceso

El patrón gated se basa en una arquitectura que expone aplicaciones y servicios seleccionados de forma precisa, en función de las APIs o los endpoints 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 controlada

• Entrada controlada

• Salida y entrada controladas (control bidireccional en ambas direcciones)

Como se ha mencionado anteriormente en esta guía, los patrones de arquitectura de redes que se describen aquí se pueden adaptar a varias aplicaciones con requisitos diversos. Para satisfacer las necesidades específicas de las diferentes aplicaciones, la arquitectura de tu zona de aterrizaje principal puede incorporar un patrón o una combinación de patrones simultáneamente. La implementación específica de la arquitectura seleccionada se determina en función de los requisitos de comunicación específicos de cada patrón protegido.

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

En esta serie se analiza cada patrón de acceso restringido y sus posibles opciones de diseño. Sin embargo, una opción de diseño habitual que se puede aplicar a todos los patrones protegidos es la arquitectura distribuida de confianza cero para aplicaciones en contenedores con arquitectura de microservicios. Esta opción se basa en Cloud Service Mesh, Apigee y Apigee Adapter for Envoy, un despliegue ligero de la pasarela de Apigee en un clúster de Kubernetes. Apigee Adapter for Envoy es un proxy de servicio y de edge popular de código abierto diseñado para aplicaciones basadas en la nube. Esta arquitectura controla las comunicaciones seguras permitidas entre servicios 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 en función del patrón seleccionado.

Los patrones de acceso controlado permiten implementar Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para realizar una inspección profunda de paquetes con el fin de prevenir amenazas sin tener que modificar el diseño ni el enrutamiento. Esta inspección está sujeta a las aplicaciones específicas a las que se accede, al modelo de comunicación y a los requisitos de seguridad. Si los requisitos de seguridad exigen la capa 7 y la inspección profunda de paquetes con mecanismos de cortafuegos avanzados que superen las funciones de Cloud Next Generation Firewall, puedes usar un cortafuegos de nueva generación (NGFW) centralizado alojado en un dispositivo virtual de red (NVA). Varios Google Cloud partners de seguridad ofrecen dispositivos NGFW que pueden cumplir tus requisitos de seguridad. Para integrar las AVNs con estos patrones protegidos, es posible que tengas que introducir varias zonas de seguridad en el diseño de la red, cada una con niveles de control de acceso distintos.

Salida cerrada

La arquitectura del patrón de redes de salida controlada se basa en exponer APIs concretas del entorno local u otro entorno de nube a las cargas de trabajo que se hayan implementado en Google Cloud. Lo hace sin exponerlos directamente a la red pública de Internet desde un entorno local o desde otros entornos de nube. Puedes facilitar esta exposición limitada mediante una pasarela o un proxy de APIs, o un balanceador de carga que actúe como fachada para las cargas de trabajo. Puedes implementar la funcionalidad de la pasarela de APIs en un segmento de red perimetral aislado, como una red perimetral.

El patrón de red salida controlada se aplica principalmente a los patrones de arquitectura de aplicaciones por niveles y a los patrones de arquitectura de aplicaciones particionadas (aunque no solo a estos). Al implementar cargas de trabajo de backend en una red interna, la red de salida controlada ayuda a mantener un nivel de seguridad más alto en tu entorno informático local. El patrón requiere que conectes los entornos de computación de forma que cumplan los siguientes requisitos de comunicación:

• Las cargas de trabajo que implementes en Google Cloud pueden comunicarse con la pasarela de API o el balanceador de carga (o un endpoint de Private Service Connect) que exponga la aplicación mediante direcciones IP internas.
• No se puede acceder directamente a otros sistemas del entorno de computación privada desde Google Cloud.
• No se permite la comunicación desde el entorno de computación privada a ninguna carga de trabajo implementada en Google Cloud .
• El tráfico a las APIs privadas de otros entornos solo se inicia desde el entorno Google Cloud .

Esta guía se centra en los entornos híbridos y multinube 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 a APIs de destino remotas con direcciones IP públicas a través de Internet. Sin embargo, debes tener en cuenta los siguientes mecanismos de seguridad:

• API OAuth 2.0 con Seguridad en la capa de transporte (TLS).
• Límite de frecuencia.
• Políticas de protección contra amenazas.
• TLS mutuo configurado en el backend de tu capa de API.
• Filtrado de lista de permitidas de direcciones IP configurado para permitir la comunicación únicamente con orígenes y destinos de APIs 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 cumple los requisitos de comunicación indicados en la sección anterior:

Los datos fluyen por el diagrama anterior de la siguiente manera:

• En el Google Cloud lado, puedes desplegar cargas de trabajo en nubes privadas virtuales (VPCs). Las VPCs pueden ser únicas o múltiples (compartidas o no compartidas). La implementación debe estar en consonancia 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 amplían a los demás entornos de computación. Los entornos pueden ser locales o estar en otra nube. Para facilitar la comunicación entre entornos mediante direcciones IP internas, utiliza una conectividad de red híbrida y multinube adecuada.

• Para limitar el tráfico que procede de direcciones IP de VPC específicas y que se dirige a balanceadores de carga o gateways remotos, use el filtrado de listas de permitidos de direcciones IP. El tráfico de retorno de estas conexiones se permite cuando se usan reglas de cortafuegos 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 cortafuegos o políticas de cortafuegos.

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

  • Cloud Next Generation Firewall Enterprise con servicio de prevención de intrusos (IPS) para implementar la inspección profunda de paquetes y prevenir amenazas.

• Todos los entornos comparten un espacio de direcciones IP RFC 1918 sin solapamientos.

Variantes

El patrón de arquitectura de salida controlada se puede combinar con otros enfoques para cumplir diferentes requisitos de diseño que sigan teniendo en cuenta los requisitos de comunicación de este patrón. El patrón ofrece las siguientes opciones:

• Usar Google Cloud la pasarela de APIs y el frontend global
• Exponer servicios remotos mediante Private Service Connect

Usar Google Cloud una pasarela de API y un frontend global

Con este enfoque de diseño, la exposición y la gestión de las APIs se encuentran enGoogle Cloud. Como se muestra en el diagrama anterior, puedes hacerlo implementando Apigee como plataforma de APIs. La decisión de desplegar una pasarela de API o un balanceador de carga en el entorno remoto depende de tus necesidades específicas y de la configuración actual. Apigee ofrece dos opciones para aprovisionar la conectividad:

• Con el emparejamiento de VPC
• Sin emparejamiento de VPC

Google Cloud Las funciones de frontend global, 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 aplicaciones cuyos backends están alojados en tus entornos on‐premise y en otros entornos de nube.

Para optimizar la velocidad de distribución de contenido, se distribuyen las aplicaciones desde Google Cloud puntos de presencia (PoPs) Google Cloud . Los PoPs están presentes en más de 180 centralitas de Internet y en más de 160 instalaciones de interconexión de todo el mundo.

Para ver cómo ayudan los PoPs a ofrecer APIs de alto rendimiento al usar Apigee con Cloud CDN para lograr lo siguiente, consulta el vídeo Delivering high-performing APIs with Apigee and Cloud CDN (Ofrecer APIs de alto rendimiento con Apigee y Cloud CDN) en YouTube:

• Reduce la latencia.
• Aloja APIs a nivel mundial.
• Aumentar la disponibilidad para los picos de tráfico.

El ejemplo de diseño que se muestra en el diagrama anterior se basa en Private Service Connect sin emparejamiento de VPC.

La red de salida de este diseño se establece mediante lo siguiente:

• Un balanceador de carga (LB en el diagrama), donde finalizan las solicitudes de cliente, procesa el tráfico y, a continuación, lo enruta a un backend de Private Service Connect.
• Un backend de Private Service Connect permite que un Google Cloud balanceador de carga envíe solicitudes de clientes a través de una conexión de Private Service Connect asociada a una vinculación de servicio de productor al servicio publicado (instancia de tiempo de ejecución de Apigee) mediante grupos de endpoints de red (NEGs) de Private Service Connect.

La red con límites se establece mediante lo siguiente:

• Un endpoint de Private Service Connect que hace referencia a una vinculación de servicio asociada a un balanceador de carga interno (ILB en el diagrama) en la VPC del cliente.

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

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

Para obtener más información, consulta los artículos Configurar un balanceador de carga de red de proxy interno regional con conectividad híbrida y Patrones de implementación de Private Service Connect.

Nota: En función de tus requisitos, las APIs de los back-ends locales se pueden exponer a través de Apigee Hybrid, una pasarela o un proxy de APIs de terceros, o un balanceador de carga.

Exponer servicios remotos mediante Private Service Connect

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

• No usas una plataforma de APIs o quieres evitar conectar toda tu red de VPC directamente a un entorno externo por los siguientes motivos:
  • Tienes restricciones de seguridad o requisitos de cumplimiento.
  • Tienes un solapamiento de intervalos de direcciones IP, como en una fusión o adquisición.
• Para habilitar comunicaciones unidireccionales seguras entre clientes, aplicaciones y servicios en los entornos, incluso cuando tienes poco tiempo.
• Es posible que tengas que proporcionar conectividad a varias VPCs de consumidor a través de una VPC de productor de servicios (VPC de tránsito) para ofrecer modelos de servicio con varios o un solo cliente altamente escalables, así como para acceder a servicios publicados en otros entornos.

Si usas Private Service Connect para aplicaciones que se consumen como APIs, se proporciona una dirección IP interna para las aplicaciones publicadas, lo que permite un acceso seguro dentro de la red privada en diferentes regiones y a través de la conectividad híbrida. Esta abstracción facilita la integración de recursos de diferentes nubes y entornos locales a través de un modelo de conectividad híbrido y multinube. Puedes acelerar la integración de aplicaciones y exponer de forma segura las aplicaciones que residen en un entorno on-premise u otro entorno de nube mediante Private Service Connect para publicar el servicio con un acceso detallado. En ese caso, puede usar la siguiente opción:

• Un adjunto de servicio que hace referencia a un balanceador de carga de red con proxy interno regional o a un balanceador de carga de aplicaciones interno.
  • El balanceador de carga usa un grupo de extremos de red híbrida (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 acceder a los servicios híbridos que se ejecutan en tu entorno local o en otros entornos de nube a través del endpoint de Private Service Connect, tal como se muestra en el siguiente diagrama. Esta opción de diseño para comunicaciones unidireccionales ofrece una alternativa al emparejamiento con una VPC de tránsito.

Como parte del diseño del diagrama anterior, se pueden conectar varios frontends, backends o endpoints a la misma vinculación de servicio, lo que permite que varias redes de VPC o varios consumidores accedan al mismo servicio. Como se muestra en el siguiente diagrama, puedes hacer que la aplicación sea accesible para varias VPCs. Esta accesibilidad puede ser útil en escenarios de servicios multiempresa en los que varios VPCs de consumidor utilizan tu servicio, aunque sus intervalos de direcciones IP se solapen.

La superposición de direcciones IP es uno de los problemas más habituales al integrar aplicaciones que residen en entornos diferentes. La conexión de Private Service Connect del siguiente diagrama ayuda a evitar el problema de superposición de direcciones IP. Para ello, no es necesario aprovisionar ni gestionar ningún componente de red adicional, como Cloud NAT o una NVA, para realizar la traducción de direcciones IP. Para ver un ejemplo de configuración, consulta Publicar un servicio híbrido mediante Private Service Connect.

El diseño tiene las siguientes ventajas:

• Evita posibles dependencias de escalado compartido y una gestión compleja a gran escala.
• Mejora la seguridad al proporcionar 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 ampliar en fases posteriores para integrar Apigee como plataforma de APIs mediante las opciones de diseño de redes que hemos comentado antes, incluida la opción Private Service Connect.

Puedes hacer que el punto final de Private Service Connect sea accesible desde otras regiones mediante el acceso global de Private Service Connect.

El cliente que se conecta al endpoint de Private Service Connect puede estar en la misma región que el endpoint o en otra región. 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 se accede a un endpoint de Private Service Connect desde recursos alojados en otras regiones, se aplican cargos de salida entre regiones al tráfico destinado a endpoints con acceso global.

Nota: Para realizar comprobaciones de estado distribuidas y facilitar la conexión de varias VPCs a entornos locales a través de varias conexiones híbridas, encadena un balanceador de carga de aplicaciones interno con un balanceador de carga de aplicaciones externo. Para obtener más información, consulta Encadenamiento explícito de balanceadores de carga de nivel 7 con PSC

. Google Cloud

Prácticas recomendadas

• Si eliges Apigee y Apigee Hybrid como solución de plataforma de APIs, disfrutarás de varias ventajas. Proporciona una capa de proxy y una abstracción o fachada para tus APIs de servicios de backend, combinadas con funciones de seguridad, limitación de frecuencia, cuotas y analíticas.
  • Usa Apigee Adapter for Envoy con una implementación de Apigee Hybrid con Kubernetes en la arquitectura que se adapte a tus requisitos.
• Las VPCs y el diseño de proyectos en Google Cloud deben basarse en tu jerarquía de recursos y en tus requisitos de modelo de comunicación segura.
• Cuando se usan APIs con pasarelas de APIs, también debes usar una lista de permitidas de direcciones IP. Una lista de permitidos limita las comunicaciones a las fuentes y los destinos de direcciones IP específicos de los consumidores de la API y las pasarelas de la API que pueden estar alojados en entornos diferentes.
• Usa reglas de cortafuegos de VPC u políticas de cortafuegos para controlar el acceso a los recursos de Private Service Connect a través del endpoint de Private Service Connect.
• Si una aplicación se expone externamente a través de un balanceador de carga de aplicaciones, te recomendamos que uses Google Cloud Armor como capa de seguridad adicional para protegerte frente a las amenazas de seguridad de la capa de aplicación y los ataques DDoS.

• 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 forma, puedes evitar asignar direcciones IP públicas externas a las instancias de VM en sistemas que se hayan desplegado detrás de una pasarela de API o un balanceador de carga.

  • Para el tráfico web de salida, puedes usar Google Cloud Secure Web Proxy. El proxy ofrece varias ventajas.

• Consulta las prácticas recomendadas generales para los patrones de redes híbridas y multicloud.

Entrada restringida

La arquitectura del patrón de entrada controlada se basa en exponer APIs seleccionadas de cargas de trabajo que se ejecutan en Google Cloud al entorno de computación privado sin exponerlas a Internet público. Este patrón es la contraparte del patrón de salida controlada y se adapta bien a los escenarios de híbrido de extremo, híbrido por niveles y multinube particionada.

Al igual que con el patrón de salida controlada, puedes facilitar esta exposición limitada a través de una pasarela de APIs o un balanceador de carga que sirva de fachada para las cargas de trabajo o los servicios. De esta forma, se puede acceder a él desde entornos de computación privados, entornos on-premise u otros entornos de nube, como se indica a continuación:

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

Arquitectura

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

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

• En el lado de la Google Cloud , despliega las cargas de trabajo en una VPC de aplicación (o en varias VPCs).
• La red del entorno Google Cloud se extiende a otros entornos informáticos (locales o en otra nube) mediante la conectividad de red híbrida o multicloud para facilitar la comunicación entre entornos.
• También puedes usar una VPC de tránsito para hacer lo siguiente:
  • Proporciona capas de seguridad de perímetro adicionales para permitir el acceso a APIs específicas fuera de tu VPC de aplicación.
  • Dirige el tráfico a las direcciones IP de las APIs. Puedes crear reglas de cortafuegos de VPC para impedir que algunas fuentes accedan a determinadas APIs a través de un endpoint.
  • Inspecciona el tráfico de la capa 7 en la VPC de tránsito integrando un dispositivo virtual de red (NVA).
• Accede a las APIs a través de una pasarela de APIs o un balanceador de carga (proxy o balanceador de carga 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 la API Gateway, puedes usar un balanceador de carga de red interno de tipo Pasarela.
• Proporcionar acceso limitado y detallado a un servicio publicado a través de un punto final de Private Service Connect mediante un balanceador de carga 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 superposiciones.

En el siguiente diagrama se muestra el diseño de este patrón con Apigee como plataforma de API.

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

• Funciones de pasarela o proxy
• Funciones de seguridad
• Límite de frecuencia
• Analytics

En el diseño:

• La conectividad de red de subida (para el tráfico procedente de otros entornos) pasa por un punto final de Private Service Connect en la VPC de tu aplicación que está asociada a la VPC de Apigee.
• En la VPC de la aplicación, se usa un balanceador de carga interno para exponer las APIs de la aplicación a través de un endpoint de Private Service Connect presentado en la VPC de Apigee. Para obtener más información, consulta Arquitectura con el emparejamiento de VPC inhabilitado.

• Configura reglas de cortafuegos y filtrado de tráfico en la VPC de la aplicación. De esta forma, se proporciona un acceso detallado y controlado. También ayuda a evitar que los sistemas accedan directamente a tus aplicaciones sin pasar por el punto final de Private Service Connect y la pasarela de APIs.

  Además, puedes restringir la publicidad de la subred de direcciones IP internas de la carga de trabajo de backend en la VPC de la aplicación a la red local para evitar que se pueda acceder directamente sin pasar por el endpoint de Private Service Connect y la API Gateway.

Es posible que se requieran determinadas medidas de seguridad perimetral fuera de la VPC de la aplicación, incluido el tráfico de conectividad híbrida. En estos casos, puedes incorporar una VPC de tránsito para implementar capas de seguridad adicionales. Estas capas, como los cortafuegos de última generación (NGFWs) de NVAs con varias interfaces de red o Cloud Next Generation Firewall Enterprise con servicio de prevención de intrusiones (IPS), realizan una inspección profunda de paquetes fuera de tu VPC de aplicación, tal como se muestra en el siguiente diagrama:

Como se muestra en el diagrama anterior:

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

Puede aprovisionar varios endpoints en la misma red de VPC, tal como se muestra en el siguiente diagrama. Para cubrir diferentes casos prácticos, puedes controlar las diferentes rutas de red posibles mediante Cloud Router y las reglas de cortafuegos de VPC. Por ejemplo, si conectas tu red local a Google Cloud mediante varias conexiones de red híbrida, 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. Google Cloud También 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 protegida se puede combinar con otros enfoques para cumplir diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación del patrón. El patrón ofrece las siguientes opciones:

• Acceder a las APIs de Google desde otros entornos

• Exponer back-ends de aplicaciones a otros entornos mediante Private Service Connect

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

Acceder a las APIs de Google desde otros entornos

Private Service Connect ofrece una solución para los casos en los que se requiere acceso a servicios de Google, como Cloud Storage o BigQuery, sin enviar tráfico a través de la red pública de Internet. Como se muestra en el siguiente diagrama, permite la accesibilidad a las APIs y servicios de Google compatibles (como Google Maps, Google Ads yGoogle Cloud) desde entornos locales u otras nubes a través de una conexión de red híbrida mediante la dirección IP del punto final de Private Service Connect. Para obtener más información sobre cómo acceder a las APIs de Google a través de los puntos finales de Private Service Connect, consulta el artículo Acerca del acceso a las APIs de Google a través de puntos finales.

En el diagrama anterior, tu red on-premise debe estar conectada a la red VPC de tránsito (consumidora) mediante túneles de Cloud VPN o una vinculación de VLAN de Cloud Interconnect.

Se puede acceder a las APIs de Google mediante endpoints o backends. Los endpoints te permiten orientar tus peticiones a un paquete de APIs de Google. Los back-ends te permiten orientar a una API de Google regional específica.

Nota: Los puntos finales de Private Service Connect se registran en el Directorio de servicios de las APIs de Google, donde puedes almacenar, gestionar y publicar servicios.

Exponer back-ends de aplicaciones a otros entornos mediante Private Service Connect

En casos concretos, como se destaca en el patrón híbrido por niveles, es posible que tengas que desplegar back-ends en Google Cloud y mantener los front-ends en entornos de computación privados. Aunque es menos habitual, este enfoque se puede aplicar cuando se trata de front-ends monolíticos y pesados que pueden depender de componentes antiguos. O, lo que es más habitual, cuando se gestionan aplicaciones distribuidas en varios entornos, incluidos los entornos on‐premise y otras nubes, que requieren conectividad con back‐ends alojados en Google Cloud a través de una red híbrida.

En este tipo de arquitectura, puedes usar una pasarela de API local o un balanceador de carga en el entorno local privado u otros entornos de nube para exponer directamente el frontend de la aplicación a Internet. Usar Private Service Connect en Google Cloud facilita la conectividad privada a los backends que se exponen a través de un punto final de Private Service Connect, preferiblemente mediante APIs predefinidas, como se muestra en el siguiente diagrama:

El diseño del diagrama anterior usa una implementación de Apigee Hybrid que consta de un plano de gestión en Google Cloud y un plano de entorno de ejecución alojado en tu otro entorno. Puedes instalar y gestionar el plano del entorno de ejecución en una pasarela de APIs distribuida en una de las plataformas de Kubernetes admitidas en tu entorno local o en otros entornos de nube. En función de tus requisitos de cargas de trabajo distribuidas en Google Cloud y otros entornos, puedes usar Apigee en Google Cloud con Apigee Hybrid. Para obtener más información, consulta Pasarelas de APIs distribuidas.

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

En algunos casos, puede que sea necesario exponer APIs de back-ends de aplicaciones alojados en Google Cloud en diferentes redes VPC. Como se muestra en el siguiente diagrama, una VPC de concentrador actúa como punto central de interconexión para las distintas VPCs (radios), lo que permite una comunicación segura a través de una conectividad híbrida privada. También puedes usar las funciones de la API Gateway local en otros entornos, como Apigee Hybrid, para finalizar las solicitudes de los clientes de forma local en el lugar donde se aloja el frontend de la aplicación.

Como se muestra en el diagrama anterior:

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

• Este diseño presupone que las VPCs de spoke no requieren comunicación directa entre VPCs.

  • Si se requiere la comunicación entre dispositivos, puedes usar el NVA para facilitar dicha comunicación.
  • Si tienes diferentes back-ends en diferentes VPCs, puedes usar Private Service Connect para exponerlos a la VPC de Apigee.
  • Si se usa el peering de VPC para la conectividad de norte a sur y de sur a norte entre las VPCs de radio y la VPC de concentrador, debes tener en cuenta la limitación de transitividad de las redes de VPC a través del peering de VPC. Para superar esta limitación, puedes usar cualquiera de las siguientes opciones:
    • Para interconectar las VPCs, usa una NVA.
    • Cuando corresponda, considera el modelo de Private Service Connect.
    • Para establecer la conectividad entre la VPC de Apigee y los back-ends que se encuentran en otrosGoogle Cloud proyectos de la misma organización sin componentes de red adicionales, utiliza la VPC compartida.

• Si se necesitan NVAs para inspeccionar el tráfico (incluido el tráfico de otros entornos), la conectividad híbrida con entornos on-premise u otros entornos de nube debe finalizar en la VPC de tránsito híbrida.

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

• Si necesitas determinadas funciones de balanceo de carga o funciones de seguridad, como añadir protección contra DDoS o un cortafuegos de aplicaciones web (WAF) de Google Cloud Armor, puedes desplegar un balanceador de carga de aplicaciones externo en el perímetro a través de una VPC externa antes de enrutar las solicitudes de clientes externos a los backends.

Prácticas recomendadas

• En los casos en los que las solicitudes de clientes de Internet deban recibirse localmente por un frontend alojado en un entorno privado local u otro entorno de nube, te recomendamos que uses Apigee Hybrid como solución de pasarela de API. Este enfoque también facilita la migración de la solución a un entorno completamente alojado en Google Cloud, al tiempo que se mantiene la coherencia de la plataforma de APIs (Apigee).
• Usa Apigee Adapter for Envoy con una implementación de Apigee Hybrid con Kubernetes en la arquitectura que se adapte a tus requisitos.
• El diseño de las VPCs y los proyectos en Google Cloud debe seguir los requisitos de la jerarquía de recursos y del modelo de comunicación segura, tal como se describe en esta guía.
• Incorporar una VPC de tránsito a este diseño ofrece la flexibilidad de aprovisionar medidas de seguridad perimetral adicionales 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 on-premise u otros entornos de nube mediante la dirección IP interna del endpoint a través de una red de conectividad híbrida. Para obtener más información, consulta Acceder al endpoint desde hosts locales.
• Para proteger los Google Cloud servicios de tus proyectos y mitigar el riesgo de filtración externa de datos, usa Controles de Servicio de VPC para especificar perímetros de servicio a nivel de proyecto o de red de VPC.
  • Cuando sea necesario, puedes ampliar 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 las ventajas de los perímetros de servicio, consulta la información general sobre Controles de Servicio de VPC.
• Usa reglas de cortafuegos de VPC u políticas de cortafuegos para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del endpoint de Private Service Connect. Por ejemplo, las reglas de cortafuegos salientes de la VPC de la aplicación (consumidor) pueden restringir el acceso de las instancias de VM a la dirección IP o la subred de tus endpoints. Para obtener más información sobre las reglas de cortafuegos de VPC en general, consulta Reglas de cortafuegos de VPC.
• Al diseñar una solución que incluya NVAs, es importante tener en cuenta la alta disponibilidad (HA) de las NVAs para evitar un único punto de fallo que pueda bloquear todas las comunicaciones. Sigue las directrices de diseño e implementación de alta disponibilidad y redundancia proporcionadas por tu proveedor de VNA.
• Para reforzar la seguridad perimetral y proteger tu pasarela de APIs desplegada en el entorno correspondiente, puedes implementar de forma opcional mecanismos de balanceo de carga y de firewall de aplicaciones web en tu otro entorno informático (híbrido u 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 forma, puedes evitar asignar direcciones IP públicas externas a las instancias de VM en sistemas que se hayan desplegado detrás de una pasarela de API o un balanceador de carga.
• Para el tráfico web de salida, usa proxy web seguro. El proxy ofrece varias ventajas.
• Consulta las prácticas recomendadas generales para los patrones de redes híbridas y multicloud.

Salida y entrada controladas

El patrón salida controlada y entrada controlada usa una combinación de salida controlada y entrada controlada en situaciones que requieren el uso bidireccional de APIs seleccionadas entre cargas de trabajo. Las cargas de trabajo se pueden ejecutar en Google Cloud, en entornos privados on-premise o en otros entornos de nube. En este patrón, puedes usar pasarelas de APIs, puntos finales de Private Service Connect o balanceadores de carga para exponer APIs específicas y, opcionalmente, proporcionar autenticación, autorización y auditorías de llamadas a APIs.

La diferencia clave entre este patrón y el patrón de malla radica en su aplicación a situaciones que solo requieren el uso bidireccional de APIs o la comunicación con fuentes y destinos de direcciones IP específicos, como una aplicación publicada a través de un punto final de Private Service Connect. Como la comunicación se limita a las APIs expuestas o a direcciones IP específicas, no es necesario que las redes de los entornos se alineen en tu diseño. Estos son algunos ejemplos de situaciones en las que se aplica esta política:

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

La comunicación funciona de la siguiente manera:

• Las cargas de trabajo que implementes en Google Cloud pueden comunicarse con la pasarela de APIs (o con 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 el contrario, las cargas de trabajo que implementes en otros entornos de computación pueden comunicarse con la pasarela de API del lado de Google Cloud(o con una dirección IP de endpoint 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 salida controlada y entrada controlada:

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

• En el lado de Google Cloud , despliega cargas de trabajo en una VPC (o una VPC compartida) sin exponerlas directamente a Internet.
• La red de Google Cloud entorno se amplía a otros entornos informáticos. Este entorno puede ser local o estar en otra nube. Para ampliar el entorno, usa un patrón de comunicación de conectividad híbrida y multinube adecuado para facilitar la comunicación entre los entornos de forma que puedan usar direcciones IP internas.
• De forma opcional, si habilitas el acceso a direcciones IP de destino específicas, puedes usar una VPC de tránsito para añadir una capa de seguridad perimetral fuera de la VPC de tu aplicación.
  • Puedes usar Cloud Next Generation Firewall o dispositivos virtuales de red (NVAs) con cortafuegos de nueva generación (NGFWs) en la VPC de tránsito para inspeccionar el tráfico y permitir o prohibir el acceso a determinadas APIs desde fuentes específicas antes de que lleguen a tu VPC de aplicación.
• Se debe acceder a las APIs a través de una pasarela de APIs o un balanceador de carga para proporcionar una capa de proxy, así como una abstracción o una fachada para las APIs de tu servicio.
• En el caso de las aplicaciones que se consumen como APIs, también puedes usar Private Service Connect para proporcionar una dirección IP interna a la aplicación publicada.
• Todos los entornos usan un espacio de direcciones IP RFC 1918 sin solapamientos.

Una aplicación habitual de este patrón consiste en desplegar back-ends de aplicaciones (o un subconjunto de back-ends de aplicaciones) en Google Cloud , mientras que otros componentes de back-end y de front-end se alojan en entornos on-premise o en otras nubes (patrón híbrido por niveles o patrón multinube particionado). A medida que las aplicaciones evolucionan y migran a la nube, suelen surgir dependencias y preferencias por servicios de nube específicos.

A veces, estas dependencias y preferencias llevan a la distribución de aplicaciones y back-ends entre diferentes proveedores de servicios en la nube. Además, algunas aplicaciones se pueden crear con una combinación de recursos y servicios distribuidos en entornos on-premise y en varios entornos de nube.

En el caso de las aplicaciones distribuidas, las funciones de conectividad híbrida y multinube de Cloud Load Balancing externo se pueden usar para finalizar las solicitudes de los usuarios y enrutarlas a frontends o backends de otros entornos. Este enrutamiento se produce a través de una conexión de red híbrida, como se muestra en el siguiente diagrama. Esta integración permite distribuir gradualmente 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, facilitada por un balanceador de carga interno (ILB en el diagrama).

El diseño Google Cloud del diagrama anterior te ayuda a hacer lo siguiente:

• Facilita la comunicación bidireccional entre Google Cloud, entornos locales y otros entornos de nube mediante APIs predefinidas en ambos lados que se ajustan al modelo de comunicación de este patrón.
• Para proporcionar front-ends globales para aplicaciones accesibles desde Internet con componentes de aplicación distribuidos (front-ends o back-ends) y para lograr los siguientes objetivos, puedes usar las funciones avanzadas de balanceo de carga y seguridad Google Cloud distribuidas en puntos de presencia (PoPs):
• Reduce los gastos de capital y simplifica las operaciones usando servicios gestionados sin servidor.
• Optimiza las conexiones a los back-ends de las aplicaciones en todo el mundo para mejorar la velocidad y la latencia.
  • Google Cloud Cross-Cloud Network permite la comunicación multinube entre componentes de aplicaciones 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 proporcionando acceso a Cloud CDN.
• Protege los frontends globales de las aplicaciones orientadas a Internet mediante las funciones de Google Cloud Armor, que proporcionan servicios de cortafuegos de aplicaciones web (WAF) y de mitigación de ataques DDoS distribuidos a nivel mundial.
• Si quieres, puedes incorporar Private Service Connect a tu diseño. De esta forma, se habilita un acceso privado y detallado a las APIs de servicios o a los servicios publicados desde otros entornos sin tener que atravesar la red pública de Internet. Google Cloud

Variantes

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

• Pasarelas de API distribuidas
• Comunicación bidireccional de APIs mediante Private Service Connect
• Comunicación bidireccional mediante puntos finales e interfaces de Private Service Connect

Pasarelas de APIs distribuidas

En situaciones como la basada en el patrón de multinube particionada, las aplicaciones (o los componentes de las aplicaciones) se pueden crear en diferentes entornos de nube, incluido un entorno privado local. El requisito habitual es enrutar las solicitudes de los clientes 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 carga local o una pasarela de API. Es posible que estas aplicaciones y sus componentes también requieran funciones específicas de la plataforma de APIs para la integración.

En el siguiente diagrama se muestra cómo se han diseñado Apigee y Apigee Hybrid para satisfacer estos requisitos con una pasarela de API localizada en cada entorno. La gestión de la plataforma de APIs se centraliza en Google Cloud. Este diseño ayuda a aplicar medidas de control de acceso estrictas, de forma que solo las direcciones IP aprobadas previamente (las APIs de destino y de origen, o las direcciones IP de los endpoints de Private Service Connect) puedan comunicarse entre sí Google Cloud y los demás entornos.

En la siguiente lista se describen las dos rutas de comunicación distintas del diagrama anterior que usan la pasarela de Apis de Apigee:

• Las solicitudes de los clientes llegan directamente al frontend de la aplicación en el entorno que aloja la aplicación (o el componente de frontend).
• Las pasarelas y los proxies de APIs de cada entorno gestionan las solicitudes de APIs de clientes y aplicaciones en diferentes direcciones en varios entornos.
  • La función de pasarela de APIs de Google Cloud (Apigee) expone los componentes de la aplicación (frontend o backend) alojados en Google Cloud.
  • La función de pasarela de APIs de otro entorno (híbrido) expone los componentes frontend (o backend) de la aplicación que están alojados en ese entorno.

También puedes usar una VPC de tránsito. Una VPC de tránsito puede proporcionar flexibilidad para separar las tareas y realizar inspecciones de seguridad y 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 (donde se adjunta la conectividad híbrida) facilita los siguientes requisitos para mantener la accesibilidad de extremo a extremo:

• Las direcciones IP de las APIs de destino deben anunciarse en los demás entornos en los que se alojan los clientes o los solicitantes.
• Las direcciones IP de los hosts que necesiten comunicarse con las APIs de destino deben anunciarse en el entorno en el que residan las APIs de destino. Por ejemplo, las direcciones IP del solicitante de la API (el cliente). La excepción se produce cuando la comunicación se realiza a través de un balanceador de carga, un proxy, un endpoint de Private Service Connect o una instancia NAT.

Para ampliar la conectividad al entorno remoto, este diseño usa el emparejamiento directo de VPC con la función de intercambio de rutas de clientes. El diseño permite que las solicitudes de API específicas que proceden de cargas de trabajo alojadas en la VPC de la aplicación se enruten a través de la VPC de tránsito. Google Cloud También puedes usar un endpoint de Private Service Connect en la VPC de la aplicación que esté asociado a un balanceador de carga con un backend de grupo de endpoints de red híbrida en la VPC de tránsito. Esta configuración se describe en la siguiente sección: comunicación bidireccional de APIs mediante Private Service Connect.

Comunicación bidireccional de APIs mediante Private Service Connect

A veces, las empresas no necesitan usar una pasarela de APIs (como Apigee) inmediatamente o quieren añadirla más adelante. Sin embargo, puede que haya requisitos empresariales para habilitar la comunicación y la integración entre determinadas aplicaciones en diferentes entornos. Por ejemplo, si tu empresa ha adquirido otra empresa, es posible que tengas que exponer determinadas aplicaciones a esa empresa. Es posible que tengan que exponer aplicaciones a tu empresa. Ambas empresas pueden tener sus propias cargas de trabajo alojadas en entornos diferentes (Google Cloud, locales u otras nubes) y deben evitar que se solapen las direcciones IP. En estos casos, puedes usar Private Service Connect para facilitar la comunicación.

En el caso de las aplicaciones que se consumen como APIs, también puedes usar Private Service Connect para proporcionar una dirección privada a las aplicaciones publicadas, lo que permite acceder de forma segura a la red privada en diferentes regiones y a través de la conectividad híbrida. Esta abstracción facilita la integración de recursos de diferentes nubes y entornos locales a través de un modelo de conectividad híbrido y multinube. También permite ensamblar aplicaciones en entornos multinube y on-premise. De esta forma, se pueden satisfacer diferentes requisitos de comunicación, como la integración de aplicaciones seguras en las que no se usa o no se tiene previsto usar una pasarela de APIs.

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

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

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 mediante endpoints e interfaces de Private Service Connect

Como se explica en el patrón de entrada controlada, una de las opciones para habilitar la comunicación entre el cliente y el servicio es usar un punto final de Private Service Connect para exponer un servicio en una VPC de productor a una VPC de consumidor. Esa conectividad se puede ampliar a un entorno local o incluso a otro entorno de proveedor de la nube mediante una conectividad híbrida. Sin embargo, en algunos casos, el servicio alojado también puede requerir una comunicación privada.

Para acceder a un servicio concreto, como recuperar datos de fuentes de datos que se pueden alojar dentro o fuera de la VPC del consumidor, esta comunicación privada puede producirse 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 un productor de servicios acceda a la red de un consumidor. Para ello, comparte una interfaz de red, pero mantiene la separación de los roles de productor y consumidor. Con esta interfaz de red en la VPC de consumidor, la VM de la aplicación puede acceder a los recursos de consumidor como si estuvieran ubicados de forma local en la VPC de productor.

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

Si la VPC del consumidor pertenece a una organización o entidad externa, como una organización de terceros, normalmente no podrás proteger la comunicación con la interfaz de Private Service Connect en la VPC del consumidor. En este 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 el artículo Configurar la seguridad de las interfaces de Private Service Connect. También puedes plantearte otra opción si no cumple los estándares o los requisitos de seguridad de tu organización.

Prácticas recomendadas

• En situaciones en las que las solicitudes de clientes de Internet deban recibirse localmente por un frontend alojado en un entorno privado on-premise u otro entorno de nube, te recomendamos que uses Hybrid como solución de pasarela de API.

  • Este enfoque también facilita la migración de la solución a un entorno totalmente Google Cloudalojado, al tiempo que se mantiene la coherencia de la plataforma de APIs (Apigee).

• Para minimizar la latencia y optimizar los costes de grandes volúmenes de transferencias de datos salientes a otros entornos cuando estos entornos se encuentren en configuraciones híbridas o multicloud a largo plazo o permanentes, ten en cuenta lo siguiente:

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

• Cuando sea aplicable a tus requisitos y a la arquitectura, usa Apigee Adapter for Envoy con un despliegue híbrido con Kubernetes.

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

• Usa Controles de Servicio de VPC para proteger los Google Cloud servicios de tus proyectos y mitigar el riesgo de filtración externa de datos. Para ello, especifica perímetros de servicio a nivel de proyecto o de red de VPC.

  • Puedes ampliar los perímetros de servicio a un entorno híbrido a través de una VPN o Cloud Interconnect autorizados. Para obtener más información sobre las ventajas de los perímetros de servicio, consulta Información general sobre Controles de Servicio de VPC.

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

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

• Si una carga de trabajo de 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 Internet público.

  • Para el tráfico web de salida, usa proxy web seguro. El proxy ofrece varias ventajas.

• Consulta las prácticas recomendadas generales para los patrones de redes híbridas y multicloud.

Patrones de transferencia

Con el patrón de transferencia, la arquitectura se basa en el uso de servicios de almacenamiento proporcionados porGoogle Cloudpara conectar un entorno de computación privado a proyectos en Google Cloud. Este patrón se aplica principalmente a las configuraciones que siguen el patrón de arquitectura multinube híbrida de analíticas, donde:

• Las cargas de trabajo que se ejecutan en un entorno informático privado o en otra nube suben datos a ubicaciones de almacenamiento compartido. En función de los casos de uso, las subidas pueden realizarse en bloque o en incrementos más pequeños.
• Las cargas de trabajo alojadas enGoogle Cloudu otros servicios de Google (como los servicios de analíticas de datos y de inteligencia artificial) consumen datos de las ubicaciones de almacenamiento compartido y los tratan en tiempo real o por lotes.

Arquitectura

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

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

• En el Google Cloud lado, despliega cargas de trabajo en una VPC de aplicación. Estas cargas de trabajo pueden incluir el procesamiento de datos, las analíticas y las aplicaciones frontend relacionadas con las analíticas.
• Para exponer de forma segura las aplicaciones frontend a los usuarios, puedes usar Cloud Load Balancing o API Gateway.
• Un conjunto de segmentos de Cloud Storage o colas de Pub/Sub sube datos del entorno de computación privado y los pone a disposición de las cargas de trabajo implementadas en Google Cloudpara que los procesen. Con las políticas de Gestión de Identidades y Accesos (IAM), puedes restringir el acceso a cargas de trabajo de confianza.
• Usa Controles de Servicio de VPC para restringir el acceso a los servicios y minimizar los riesgos de filtración externa de datos no autorizada de los servicios de Google Cloud .
• En esta arquitectura, la comunicación con los segmentos de Cloud Storage o Pub/Sub se lleva a cabo a través de redes públicas o mediante conectividad privada con VPN, Cloud Interconnect o Cross-Cloud Interconnect. Normalmente, la decisión sobre cómo conectarse depende de varios aspectos, como los siguientes:
  • Volumen de tráfico previsto
  • Si se trata de una configuración temporal o permanente
  • Requisitos de seguridad y cumplimiento

Variación

Las opciones de diseño descritas en el patrón de entrada controlada, que usa puntos finales de Private Service Connect para las APIs de Google, también se pueden aplicar a este patrón. En concreto, proporciona acceso a Cloud Storage, BigQuery y otras APIs de servicios de Google. Este enfoque requiere el uso de direcciones IP privadas a través de una conexión de red híbrida y multinube, como VPN, Cloud Interconnect y Cross-Cloud Interconnect.

Prácticas recomendadas

• Restringe el acceso a los segmentos de Cloud Storage y a los temas de Pub/Sub.
• Cuando sea posible, usa soluciones de transferencia de datos integradas y basadas en la nube, como la Google Cloud suite de soluciones. Para satisfacer tus necesidades, estas soluciones se han diseñado para mover, integrar y transformar datos de forma eficiente.

• Evalúa los distintos factores que influyen en las opciones de transferencia de datos, como el coste, el tiempo de transferencia previsto y la seguridad. Para obtener más información, consulta Evaluar las opciones de transferencia.

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

• Para proteger los Google Cloud servicios de tus proyectos y reducir el riesgo de filtración externa de datos, usa Controles de Servicio de VPC. Estos controles de servicio pueden especificar perímetros de servicio a nivel de proyecto o de red de VPC.

  • Puedes ampliar los perímetros de servicio a un entorno híbrido a través de una VPN o Cloud Interconnect autorizados. Para obtener más información sobre las ventajas de los perímetros de servicio, consulta Información general sobre Controles de Servicio de VPC.

• Comunícate con cargas de trabajo de analíticas de datos publicadas públicamente que estén alojadas en instancias de VM a través de una pasarela de API, un balanceador de carga o un dispositivo de red virtual. Usa uno de estos métodos de comunicación para aumentar la seguridad y evitar que se pueda acceder directamente a estas instancias desde Internet.

• Si se necesita acceso a Internet, se puede usar Cloud NAT en la misma VPC para gestionar el tráfico saliente de las instancias a Internet.

• Consulta las prácticas recomendadas generales para las topologías de redes híbridas y multicloud.

Prácticas recomendadas generales

Al diseñar e incorporar identidades en la nube, jerarquías de recursos y redes de zonas de destino, ten en cuenta las recomendaciones de diseño de Diseño de zonas de destino Google Cloud y las Google Cloud prácticas recomendadas de seguridad que se describen en la guía de aspectos básicos de seguridad para empresas. Valida el diseño seleccionado con los siguientes documentos:

• Prácticas recomendadas y arquitecturas de referencia para el diseño de VPCs
• Decide la jerarquía de recursos de tu Google Cloud zona de aterrizaje
• Google Cloud Framework Well-Architected: seguridad, privacidad y cumplimiento

Además, ten en cuenta las siguientes prácticas recomendadas generales:

• Cuando elijas una opción de conectividad de red híbrida o multicloud, ten en cuenta los requisitos empresariales y de las aplicaciones, como los acuerdos de nivel de servicio, el rendimiento, la seguridad, el coste, la fiabilidad y el ancho de banda. Para obtener más información, consulta Elegir 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 sea apropiado y se ajuste a los requisitos de tu diseño de jerarquía de recursos. Para obtener más información, consulta Decidir si crear varias redes de VPC.

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

• Cuando proceda, establece una identidad común entre los entornos para que los sistemas puedan autenticarse de forma segura entre los límites de los entornos.

• 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 tu sistema de gestión de identidades.

  • Consulta también Patrones para autenticar a los usuarios de la plantilla en un entorno híbrido.

• Al diseñar tus entornos on-premise y de nube, ten en cuenta las direcciones IPv6 desde el principio y determina qué servicios son compatibles con ellas. Para obtener más información, consulta Introducción a IPv6 en Google Cloud. Resume los servicios que se admitían cuando se escribió la entrada del blog.

• Al diseñar, implementar y gestionar tus reglas de cortafuegos de VPC, puedes hacer lo siguiente:

  • Usa el filtrado basado en cuentas de servicio en lugar del filtrado basado en etiquetas de red si necesitas controlar estrictamente cómo se aplican las reglas de cortafuegos a las VMs.
  • Usa políticas de cortafuegos cuando agrupes varias reglas de cortafuegos para poder actualizarlas todas a la vez. También puedes hacer que la política sea jerárquica. Para consultar las especificaciones y los detalles de las políticas de cortafuegos jerárquicas, consulta el artículo Políticas de cortafuegos jerárquicas.
  • Usa objetos de geolocalización en la política de cortafuegos cuando necesites filtrar el tráfico IPv4 externo e IPv6 externo en función de ubicaciones o regiones geográficas específicas.
  • Usa Inteligencia contra amenazas para las reglas de políticas de cortafuegos si necesitas proteger tu red permitiendo o bloqueando el tráfico en función de los datos de inteligencia contra amenazas, como las direcciones IP maliciosas conocidas o los intervalos de direcciones IP de nubes públicas. Por ejemplo, puedes permitir el tráfico de intervalos de direcciones IP de nubes públicas específicas 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 cortafuegos.

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

  • Google Cloud Armor
  • Sistema de Detección de Intrusos de Cloud
  • IPS de Cloud Next Generation Firewall
  • Inteligencia frente a amenazas para reglas de políticas de cortafuegos

  Estas capas adicionales pueden ayudarte a filtrar, inspeccionar y monitorizar una amplia variedad de amenazas en las capas de red y de aplicación para analizarlas y prevenirlas.

• 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 autoritativos para tu entorno privado y para tus recursos locales alojados en servidores DNS de tu entorno local.Google Cloud Para obtener más información, consulta Elegir dónde se realiza la resolución de DNS.

• Siempre que sea posible, exponga las aplicaciones a través de APIs mediante una pasarela de APIs o un balanceador de carga. Te recomendamos que te plantees usar una plataforma de APIs como Apigee. Apigee actúa como una abstracción o una fachada para tus APIs de servicios de backend, combinada con funciones de seguridad, limitación de frecuencia, cuotas y analíticas.

• Una plataforma de APIs (pasarela o proxy) y un balanceador de carga de aplicaciones no se excluyen mutuamente. A veces, usar tanto pasarelas de APIs como balanceadores de carga puede proporcionar una solución más sólida y segura para gestionar y distribuir el tráfico de APIs a gran escala. Con las pasarelas de API de Cloud Load Balancing, puedes hacer lo siguiente:

  • Ofrece APIs de alto rendimiento con Apigee y Cloud CDN para:

    • Reducir la latencia
    • Alojar APIs a nivel mundial

    • Aumentar la disponibilidad en las temporadas de mayor tráfico

      Para obtener más información, consulta el vídeo Delivering high-performing APIs with Apigee and Cloud CDN (Ofrecer APIs de alto rendimiento con Apigee y Cloud CDN) en YouTube.

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

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

  • Gestionar el balanceo de carga eficiente en las pasarelas de varias regiones. Para obtener más información, consulta el vídeo Securing APIs and Implementing multi-region failover with PSC and Apigee (Protección de APIs e implementación de conmutación por error multirregión con PSC y Apigee).

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

• Cuando se usa Cloud Load Balancing, debes usar sus funciones de optimización de la capacidad de las aplicaciones cuando sea posible. De esta forma, podrás hacer frente a algunos de los problemas de capacidad que pueden surgir en las aplicaciones distribuidas a nivel mundial.

  • Para obtener información detallada sobre la latencia, consulta el artículo Optimizar la latencia de las aplicaciones mediante el balanceo de carga.

• Aunque Cloud VPN cifra el tráfico entre entornos, con Cloud Interconnect debes usar MACsec o una VPN de alta disponibilidad a través de Cloud Interconnect para cifrar el tráfico en tránsito en la capa de conectividad. Para obtener más información, consulta ¿Cómo puedo cifrar mi tráfico a través de Cloud Interconnect?

  • También puedes usar el cifrado de la capa de servicio mediante TLS. Para obtener más información, consulta Decidir cómo cumplir los requisitos de cumplimiento para el cifrado en tránsito.

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

  • Para configuraciones híbridas o multinube a largo plazo con volúmenes de transferencia de datos salientes elevados, plantéate usar Cloud Interconnect o Cross-Cloud Interconnect. Estas opciones de conectividad ayudan a optimizar el rendimiento de la conectividad y pueden reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

• Cuando te conectes Google Cloud a recursos y tengas que elegir entre Cloud Interconnect, el emparejamiento directo o el emparejamiento mediante operador, te recomendamos que uses Cloud Interconnect, a menos que necesites acceder a aplicaciones de Google Workspace. Para obtener más información, puedes comparar las funciones de Emparejamiento directo con Cloud Interconnect y Emparejamiento mediante operador con Cloud Interconnect.

• Asigna suficiente espacio de direcciones IP de tu espacio de direcciones IP RFC 1918 para alojar tus sistemas en la nube.

• Si tienes restricciones técnicas que te obligan a mantener tu intervalo de direcciones IP, puedes hacer lo siguiente:

  • Usa las mismas direcciones IP internas para tus cargas de trabajo locales al migrarlas a Google Cloudmediante subredes híbridas.

  • Aprovisiona y usa tus propias direcciones IPv4 públicas para los Google Cloud recursos mediante la función Utiliza tu propia dirección IP (BYOIP) de Google.

• Si el diseño de tu solución requiere exponer una aplicación basada enGoogle Clouda Internet, consulta las recomendaciones de diseño que se describen en el artículo Redes para la entrega de aplicaciones orientadas a Internet.

• Cuando proceda, usa puntos finales de Private Service Connect para permitir que las cargas de trabajo de Google Cloud, on-premise o de otro entorno de nube con conectividad híbrida accedan de forma privada a las APIs de Google o a los servicios publicados mediante direcciones IP internas de forma granular.

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

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

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

• Para conseguir una configuración de nube sólida en el contexto de una arquitectura híbrida y multinube, sigue estos pasos:

  • Realizar una evaluación exhaustiva de los niveles de fiabilidad necesarios de las diferentes aplicaciones en los distintos entornos. De esta forma, puedes cumplir tus objetivos de disponibilidad y resiliencia.
  • Conoce las funciones de fiabilidad y los principios de diseño de tu proveedor de la nube. Para obtener más información, consulta Google Cloud fiabilidad de la infraestructura.

• La visibilidad y la monitorización de la red en la nube son fundamentales para mantener comunicaciones fiables. Network Intelligence Center ofrece una consola única para gestionar la visibilidad, la monitorización y la solución de problemas de la red.

Patrones de arquitectura de redes seguras híbridas y multinube: próximos pasos

• Consulta más información sobre los patrones de arquitectura comunes que puedes implementar usando los patrones de redes que se describen en este documento.
• Consulta cómo abordar la nube híbrida y la multinube, y cómo elegir las cargas de trabajo adecuadas.
• Consulta más información sobre Google Cloud Cross-Cloud Network una plataforma de red mundial abierta, segura y optimizada para aplicaciones y usuarios en entornos on‐premise y en otras nubes.
• Diseña una infraestructura fiable para tus cargas de trabajo en Google Cloud: guía de diseño para proteger tus aplicaciones frente a fallos a nivel de recurso, zona y región.
• Para obtener más información sobre cómo diseñar arquitecturas de alta disponibilidad enGoogle Cloud, consulta los patrones de aplicaciones resilientes y escalables.
• Consulta 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 Google Cloud red, así como sobre el impacto de una desconexión temporal Google Cloud.