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