La arquitectura del patrón de entrada cerrada se basa en la exposición de APIs seleccionadas de cargas de trabajo que se ejecutan en Google Cloud al entorno de computación privado sin exponerlas a la Internet pública. Este patrón es la contraparte del patrón de salida cerrada y es adecuado para las situaciones de híbrido perimetral, híbrido en niveles y multicloud particionado.
Al igual que con el patrón de salida cerrada, puedes facilitar esta exposición limitada a través de una puerta de enlace de API o un balanceador de cargas que actúe como fachada para las cargas de trabajo o los servicios existentes. De esta manera, se puede acceder a él desde entornos de computación privados, entornos locales o cualquier otro entorno de nube, de la siguiente manera:
- Las cargas de trabajo que implementas en el entorno de computación privado o en otros entornos de nube pueden comunicarse con la puerta de enlace de API o el balanceador de cargas mediante direcciones IP internas. No se puede acceder a otros sistemas implementados enGoogle Cloud .
- No se permite la comunicación desde Google Cloud hacia el entorno de computación privado ni hacia otros entornos de nube. El tráfico solo se inicia desde el entorno privado o desde otros entornos de nube hacia las APIs en Google Cloud.
Arquitectura
En el siguiente diagrama, se muestra una arquitectura de referencia que cumple con los requisitos del patrón de entrada cerrada.
La descripción de la arquitectura en el diagrama anterior es la siguiente:
- En el lado de Google Cloud , implementas cargas de trabajo en una VPC de aplicación (o varias VPCs).
- La red del entorno Google Cloud se extiende a otros entornos de procesamiento (locales o en otra nube) a través de la conectividad de red híbrida o multinube para facilitar la comunicación entre los entornos.
- De manera opcional, puedes usar una VPC de tránsito para lograr lo siguiente:
- Proporciona capas de seguridad perimetral adicionales para permitir el acceso a APIs específicas fuera de la VPC de tu aplicación.
- Enruta el tráfico a las direcciones IP de las APIs. Puedes crear reglas de firewall de VPC para evitar que algunas fuentes accedan a ciertas APIs a través de un extremo.
- Inspecciona el tráfico de capa 7 en la VPC de tránsito integrando un dispositivo virtual de red (NVA).
- Accede a las APIs a través de una puerta de enlace de API o un balanceador de cargas (proxy o balanceador de cargas de aplicaciones) para proporcionar una capa de proxy y una capa de abstracción o fachada para tus APIs de servicio. Si necesitas distribuir el tráfico entre varias instancias de puerta de enlace de API, puedes usar un balanceador de cargas de red de transferencia interno.
- Proporciona acceso limitado y detallado a un servicio publicado a través de un extremo de Private Service Connect con un balanceador de cargas a través de Private Service Connect para exponer una aplicación o un servicio.
- Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.
En el siguiente diagrama, se ilustra el diseño de este patrón con Apigee como plataforma de APIs.
En el diagrama anterior, el uso de Apigee como plataforma de API proporciona las siguientes características y capacidades para habilitar el patrón de ingreso controlado:
- Funcionalidad de puerta de enlace o proxy
- Capacidades de seguridad
- Límite de frecuencia
- Analytics
En el diseño:
- La conectividad de red de salida (para el tráfico proveniente de otros entornos) pasa por un extremo de Private Service Connect en la VPC de tu aplicación que está asociado con la VPC de Apigee.
- En la VPC de la aplicación, se usa un balanceador de cargas interno para exponer las APIs de la aplicación a través de un extremo de Private Service Connect que se presenta en la VPC de Apigee. Para obtener más información, consulta Arquitectura con intercambio de tráfico entre VPC inhabilitado.
Configura reglas de firewall y filtrado de tráfico en la VPC de la aplicación. De esta manera, se proporciona un acceso detallado y controlado. También ayuda a evitar que los sistemas lleguen directamente a tus aplicaciones sin pasar por el extremo de Private Service Connect y la puerta de enlace de API.
Además, puedes restringir el anuncio de la subred de direcciones IP internas de la carga de trabajo de backend en la VPC de la aplicación a la red local para evitar la accesibilidad directa sin pasar por el extremo de Private Service Connect y la puerta de enlace de API.
Es posible que ciertos requisitos de seguridad exijan una inspección de seguridad perimetral fuera de la VPC de la aplicación, incluido el tráfico de conectividad híbrida. En esos casos, puedes incorporar una VPC de tránsito para implementar capas de seguridad adicionales. Estas capas, como los dispositivos virtuales de red (NVA) de firewalls de nueva generación (NGFW) con varias interfaces de red o Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS), realizan una inspección profunda de paquetes fuera de la VPC de tu aplicación, como se ilustra en el siguiente diagrama:
Como se ilustra en el diagrama anterior:
- La conectividad de red de salida (para el tráfico proveniente de otros entornos) pasa por una VPC de tránsito independiente hacia el extremo de Private Service Connect en la VPC de tránsito asociada con la VPC de Apigee.
- En la VPC de la aplicación, se usa un balanceador de cargas interno (ILB en el diagrama) para exponer la aplicación a través de un extremo de Private Service Connect en la VPC de Apigee.
Puedes aprovisionar varios extremos en la misma red de VPC, como se muestra en el siguiente diagrama. Para abarcar diferentes casos de uso, puedes controlar las diferentes rutas de acceso a la red posibles con Cloud Router y las reglas de firewall de VPC. Por ejemplo, si conectas tu red local a Google Cloud con varias conexiones de redes híbridas, puedes enviar parte del tráfico desde la red local a APIs de Google o servicios publicados específicos a través de una conexión y el resto a través de otra. También puedes usar el acceso global de Private Service Connect para proporcionar opciones de conmutación por error.
Variantes
El patrón de arquitectura de ingreso controlado se puede combinar con otros enfoques para satisfacer diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación del patrón. El patrón ofrece las siguientes opciones:
Accede a las APIs de Google desde otros entornos
Private Service Connect ofrece una solución para las situaciones en las que se requiere acceso a los servicios de Google, como Cloud Storage o BigQuery, sin enviar tráfico a través de Internet pública. Como se muestra en el siguiente diagrama, permite la accesibilidad a los servicios y las APIs de Google compatibles (incluidos Google Maps, Google Ads yGoogle Cloud) desde entornos locales o de otras nubes a través de una conexión de red híbrida que usa la dirección IP del extremo de Private Service Connect. Para obtener más información sobre el acceso a las APIs de Google a través de extremos de Private Service Connect, consulta Información sobre el acceso a las APIs de Google a través de extremos.
En el diagrama anterior, tu red local debe estar conectada a la red de VPC de tránsito (consumidor) a través de túneles de Cloud VPN o un adjunto de VLAN de Cloud Interconnect.
Se puede acceder a las APIs de Google a través de endpoints o backends. Los endpoints te permiten segmentar tus anuncios para un paquete de APIs de Google. Los backends te permiten segmentar tus anuncios para una API de Google regional específica.
Expón backends de aplicaciones a otros entornos con Private Service Connect
En situaciones específicas, como se destaca en el patrón híbrido en niveles, es posible que debas implementar backends en Google Cloud y mantener los frontends en entornos de computación privados. Si bien es menos común, este enfoque se aplica cuando se trata de frontends monolíticos y pesados que pueden depender de componentes heredados. O, más comúnmente, cuando se administran aplicaciones distribuidas en varios entornos, incluidas las instalaciones locales y otras nubes, que requieren conectividad a los backends alojados en Google Cloud a través de una red híbrida.
En una arquitectura de este tipo, puedes usar un balanceador de cargas o una puerta de enlace de API local en el entorno local privado, o en otros entornos de nube, para exponer directamente el frontend de la aplicación a la Internet pública. El uso de Private Service Connect en Google Cloud facilita la conectividad privada a los backends que se exponen a través de un extremo de Private Service Connect, idealmente con APIs predefinidas, como se ilustra en el siguiente diagrama:
El diseño del diagrama anterior usa una implementación de Apigee Hybrid que consta de un plano de administración en Google Cloud y un plano de entorno de ejecución alojado en tu otro entorno. Puedes instalar y administrar el plano del entorno de ejecución en una puerta de enlace de API distribuida en una de las plataformas de Kubernetes compatibles en tu entorno local o en otros entornos de nube. Según tus requisitos para las cargas de trabajo distribuidas en Google Cloud y otros entornos, puedes usar Apigee en Google Cloud con Apigee Hybrid. Para obtener más información, consulta Puertas de enlace de API distribuidas.
Usa una arquitectura de concentrador y radio para exponer los back-ends de las aplicaciones a otros entornos
En ciertos casos, es posible que debas exponer APIs desde backends de aplicaciones alojados en Google Cloud en diferentes redes de VPC. Como se ilustra en el siguiente diagrama, una VPC de concentrador funciona como un punto central de interconexión para las distintas VPC (radios), lo que permite una comunicación segura a través de la conectividad híbrida privada. De manera opcional, se pueden usar capacidades de puerta de enlace de API local en otros entornos, como Apigee Hybrid, para finalizar las solicitudes de los clientes de forma local donde se aloja el frontend de la aplicación.
Como se ilustra en el diagrama anterior:
- Para proporcionar capacidades adicionales de inspección de capa 7 del NGFW, el NVA con capacidades de NGFW se integra de forma opcional en el diseño. Es posible que necesites estas capacidades para cumplir con requisitos de seguridad específicos y los estándares de la política de seguridad de tu organización.
Este diseño supone que las VPC de radio no requieren comunicación directa entre VPC.
- Si se requiere comunicación entre radios, puedes usar la NVA para facilitar dicha comunicación.
- Si tienes diferentes backends en diferentes VPCs, puedes usar Private Service Connect para exponer estos backends a la VPC de Apigee.
- Si se usa el intercambio de tráfico entre VPC para la conectividad de norte a sur y de sur a norte entre las VPC de radio y la VPC de concentrador, debes tener en cuenta la limitación de transitividad de las redes de VPC a través del intercambio de tráfico entre VPC. Para superar esta limitación, puedes usar cualquiera de las siguientes opciones:
- Para interconectar las VPC, usa una NVA.
- Cuando corresponda, considera el modelo de Private Service Connect.
- Para establecer la conectividad entre la VPC de Apigee y los backends que se encuentran en otros proyectos deGoogle Cloud en la misma organización sin componentes de redes adicionales, usa la VPC compartida.
Si se requieren AVN para la inspección del tráfico, incluido el tráfico de tus otros entornos, la conectividad híbrida a entornos locales o de otras nubes debe finalizar en la VPC de tránsito híbrido.
Si el diseño no incluye la NVA, puedes finalizar la conectividad híbrida en la VPC del concentrador.
Si se requieren ciertas funcionalidades de balanceo de cargas o capacidades de seguridad, como agregar protección contra DDoS o WAF de Google Cloud Armor, puedes implementar de forma opcional un balanceador de cargas de aplicaciones externo en el perímetro a través de una VPC externa antes de enrutar las solicitudes de clientes externos a los backends.
Prácticas recomendadas
- En situaciones en las que un frontend alojado en un entorno privado local o en otro entorno de nube debe recibir solicitudes de clientes de Internet de forma local, considera usar Apigee Hybrid como solución de puerta de enlace de API. Este enfoque también facilita una migración sin problemas de la solución a un entorno completamente Google Cloudalojado, al mismo tiempo que se mantiene la coherencia de la plataforma de APIs (Apigee).
- Usa el adaptador de Apigee para Envoy con una arquitectura de implementación de Apigee Hybrid con Kubernetes cuando corresponda para tus requisitos y la arquitectura.
- El diseño de las VPCs y los proyectos en Google Cloud debe seguir la jerarquía de recursos y los requisitos del modelo de comunicación segura, como se describe en esta guía.
- Incorporar una VPC de tránsito en este diseño proporciona la flexibilidad necesaria para aprovisionar medidas de seguridad perimetral adicionales y conectividad híbrida fuera de la VPC de carga de trabajo.
- Usa Private Service Connect para acceder a las APIs y los servicios de Google desde entornos locales o desde otros entornos de nube con la dirección IP interna del extremo a través de una red de conectividad híbrida. Para obtener más información, consulta Accede al extremo desde hosts locales.
- Para proteger los servicios de Google Cloud en tus proyectos y mitigar el riesgo de robo de datos, usa los Controles del servicio de VPC para especificar perímetros de servicio a nivel del proyecto o de la red de VPC.
- Cuando sea necesario, puedes extender los perímetros de servicio a un entorno híbrido a través de una VPN o Cloud Interconnect. Para obtener más información sobre los beneficios de los perímetros de servicio, consulta la Descripción general de los Controles del servicio de VPC.
- Usa reglas de firewall de VPC o políticas de firewall para controlar el acceso a nivel de red a los recursos de Private Service Connect a través del extremo de Private Service Connect. Por ejemplo, las reglas de firewall de salida en la VPC de la aplicación (consumidor) pueden restringir el acceso desde las instancias de VM a la dirección IP o la subred de tus extremos. Para obtener más información sobre las reglas de firewall de VPC en general, consulta Reglas de firewall de VPC.
- Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño e implementación de alta disponibilidad y redundancia que te proporciona tu proveedor de NVA.
- Para fortalecer la seguridad perimetral y proteger tu puerta de enlace de API implementada en el entorno respectivo, puedes implementar de forma opcional mecanismos de balanceo de cargas y de firewall de aplicación web en tu otro entorno de procesamiento (híbrido o de otra nube). Implementa estas opciones en la red perimetral que está conectada directamente a Internet.
- Si las instancias requieren acceso a Internet, usa Cloud NAT en la VPC de la aplicación para permitir que las cargas de trabajo accedan a Internet. De esta manera, puedes evitar asignar direcciones IP públicas externas a las instancias de VM en sistemas que se implementan detrás de una puerta de enlace de API o un balanceador de cargas.
- Para el tráfico web saliente, usa el proxy web seguro. El proxy ofrece varios beneficios.
- Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.