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, utilice 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:
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.
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.
. Google CloudPrá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.