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 perimetral 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 VPCs 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
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.
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 tus 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.