La arquitectura del patrón de red de salida cerrada se basa en la exposición de APIs seleccionadas del entorno local o de otro entorno de nube a las cargas de trabajo implementadas en Google Cloud. Lo hace sin exponerlos directamente a la Internet pública desde un entorno local o desde otros entornos de nube. Puedes facilitar esta exposición limitada a través de una puerta de enlace o un proxy de API, o un balanceador de cargas que actúe como fachada para las cargas de trabajo existentes. Puedes implementar la funcionalidad de la puerta de enlace de API en un segmento de red perimetral aislado, como una red perimetral.
El patrón de red de salida cerrada se aplica principalmente, entre otros, a patrones de arquitectura de aplicaciones en niveles y a patrones de arquitectura de aplicación particionada. Cuando se implementan cargas de trabajo de backend dentro de una red interna, las redes de salida con control de acceso ayudan a mantener un nivel más alto de seguridad en tu entorno de computación local. El patrón requiere que conectes los entornos de computación de manera tal que se cumplan los siguientes requisitos de comunicación:
- Las cargas de trabajo que implementes en Google Cloud pueden comunicarse con la puerta de enlace de API o el balanceador de cargas (o un extremo de Private Service Connect) que expone la aplicación mediante direcciones IP internas.
- No se puede acceder a otros sistemas en el entorno de computación privado directamente desde Google Cloud.
- No se permite la comunicación del entorno de computación privado a ninguna carga de trabajo implementada en Google Cloud .
- El tráfico a las APIs privadas en otros entornos solo se inicia desde el entorno de Google Cloud .
El enfoque de esta guía está en los entornos híbridos y de múltiples nubes 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 de API a la API de destino remoto con direcciones IP públicas a través de Internet. Sin embargo, debes tener en cuenta los siguientes mecanismos de seguridad:
- API de OAuth 2.0 con seguridad de la capa de transporte (TLS)
- Límite de frecuencia.
- Políticas de protección contra las amenazas.
- TLS mutua configurada en el backend de tu capa de API
- Filtrado de lista de entidades IP permitidas configurado para permitir solo la comunicación con fuentes y destinos de API 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 admite los requisitos de comunicación que se enumeran en la sección anterior:
Los datos fluyen a través del diagrama anterior de la siguiente manera:
- En el lado de Google Cloud , puedes implementar cargas de trabajo en nubes privadas virtuales (VPC). Las VPCs pueden ser una o varias (compartidas o no compartidas). La implementación debe estar alineada 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 extienden a los otros entornos de procesamiento. Los entornos pueden ser locales o estar en otra nube. Para facilitar la comunicación entre entornos con direcciones IP internas, usa una conectividad de redes híbridas y de múltiples nubes adecuada.
Para limitar el tráfico que se origina en direcciones IP de VPCs específicas y que está destinado a puertas de enlace o balanceadores de cargas remotos, usa el filtrado de listas de direcciones IP permitidas. Se permite el tráfico de retorno de estas conexiones cuando se usan reglas de firewall 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 firewall de nueva generación (NGFW) que se colocan en la ruta de red.
Cloud Next Generation Firewall Enterprise con el servicio de prevención de intrusiones (IPS) para implementar una inspección profunda de paquetes para la prevención de amenazas
Todos los entornos comparten un espacio de direcciones IP RFC 1918 sin superposición.
Variantes
El patrón de arquitectura de salida controlada se puede combinar con otros enfoques para cumplir con diferentes requisitos de diseño que aún consideran los requisitos de comunicación de este patrón. El patrón ofrece las siguientes opciones:
Usa Google Cloud API Gateway y frontend global
Con este enfoque de diseño, la exposición y la administración de la API residen enGoogle Cloud. Como se muestra en el diagrama anterior, puedes lograr esto a través de la implementación de Apigee como la plataforma de API. La decisión de implementar una puerta de enlace de API o un balanceador de cargas en el entorno remoto depende de tus necesidades específicas y de la configuración actual. Apigee proporciona dos opciones de aprovisionamiento de conectividad:
- Con intercambio de tráfico entre VPC
- Sin intercambio de tráfico de VPC
Las capacidades de frontend global deGoogle Cloud , 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 las aplicaciones que tienen backends alojados en tu entorno en entornos locales y en otros entornos de nube.
Para optimizar las velocidades de entrega de contenido, se entregan esas aplicaciones desde Google Cloud puntos de presencia (PoP). Google Cloud Los PoP están presentes en más de180 intercambios de Internet y en más de 160 instalaciones de interconexión en todo el mundo.
Si deseas ver cómo los PoP ayudan a entregar APIs de alto rendimiento cuando se usa Apigee con Cloud CDN para lograr lo siguiente, mira Entrega API de alto rendimiento con Apigee y Cloud CDN en YouTube:
- Reduce la latencia.
- Aloja las APIs en todo el mundo.
- Aumenta la disponibilidad para el tráfico máximo.
El ejemplo de diseño que se ilustra en el diagrama anterior se basa en Private Service Connect sin el intercambio de tráfico entre VPC.
La red ascendente en este diseño se establece a través de lo siguiente:
- Un balanceador de cargas (LB en el diagrama), donde finalizan las solicitudes del cliente, procesa el tráfico y, luego, lo enruta a un backend de Private Service Connect.
- Un backend de Private Service Connect permite que un balanceador de cargas Google Cloud envíe solicitudes de clientes a través de una conexión de Private Service Connect asociada con un adjunto de servicio de productor al servicio publicado (instancia del entorno de ejecución de Apigee) con grupos de extremos de red (NEG) de Private Service Connect.
La red descendente se establece a través de lo siguiente:
- Un extremo de Private Service Connect que hace referencia a un adjunto de servicio asociado con un balanceador de cargas interno (ILB en el diagrama) en la VPC del cliente
El ILB se implementa con grupos de extremos de red de conectividad híbrida (NEG de conectividad híbrida).
Se accede a los servicios híbridos a través del NEG de conectividad híbrida a través de una conectividad de red híbrida, como VPN o Cloud Interconnect.
Para obtener más información, consulta Configura un balanceador de cargas de red del proxy interno regional con conectividad híbrida y Patrones de implementación de Private Service Connect.
Expone servicios remotos con Private Service Connect
Usa la opción Private Service Connect para exponer servicios remotos en las siguientes situaciones:
- No usas una plataforma de API o deseas evitar conectar tu red de VPC completa directamente a un entorno externo por los siguientes motivos:
- Tienes restricciones de seguridad o requisitos de cumplimiento.
- Hay una superposición de rangos de direcciones IP, como en una fusión o una adquisición.
- Para habilitar comunicaciones unidireccionales seguras entre clientes, aplicaciones y servicios en todos los entornos, incluso cuando tienes una fecha límite corta.
- Es posible que debas proporcionar conectividad a varias VPC de consumidor a través de una VPC de productor de servicios (VPC de tránsito) para ofrecer modelos de servicio multiusuario o de usuario único con alta escalabilidad para alcanzar los servicios publicados en otros entornos.
El uso de Private Service Connect para aplicaciones que se consumen como APIs proporciona una dirección IP interna para las aplicaciones publicadas, lo que permite el acceso seguro dentro de la red privada entre regiones y a través de la conectividad híbrida. Esta abstracción facilita la integración de recursos de diversas nubes y entornos locales a través de un modelo de conectividad híbrida y de múltiples nubes. Puedes acelerar la integración de aplicaciones y exponer de forma segura las aplicaciones que residen en un entorno local o en otro entorno de nube mediante Private Service Connect en publica el servicio con acceso detallado. En este caso, puedes usar la siguiente opción:
- Un adjunto de servicio que hace referencia a un balanceador de cargas de red de proxy interno regional o un balanceador de cargas de aplicaciones interno.
- El balanceador de cargas usa un grupo de extremos de red híbrido (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 llegar a los servicios híbridos que se ejecutan en tu entorno local o en otros entornos de nube a través del extremo de Private Service Connect, como se ilustra en el siguiente diagrama. Esta opción de diseño para comunicaciones unidireccionales proporciona una opción alternativa para el intercambio de tráfico con una VPC de tránsito.
Como parte del diseño del diagrama anterior, varios frontends, backends o extremos pueden conectarse al mismo adjunto de servicio, lo que permite que varias redes de VPC o varios consumidores accedan al mismo servicio. Como se ilustra en el siguiente diagrama, puedes hacer que varias VPCs sean accesibles para la aplicación. Esta accesibilidad puede ayudar en situaciones de servicios multiusuario en las que varias VPCs de consumidores consumen tu servicio, incluso si sus rangos de direcciones IP se superponen.
La superposición de direcciones IP es uno de los problemas más habituales cuando se integran aplicaciones que residen en diferentes entornos. La conexión de Private Service Connect en el siguiente diagrama ayuda a evitar el problema de superposición de direcciones IP. Lo hace sin necesidad de aprovisionar ni administrar ningún componente de red adicional, como Cloud NAT o un NVA, para realizar la traducción de la dirección IP. Para ver un ejemplo de configuración, consulta Publica un servicio híbrido con Private Service Connect.
El diseño tiene las siguientes ventajas:
- Evita posibles dependencias de escalamiento compartidas y una administración compleja a gran escala.
- Mejora la seguridad, ya que proporciona 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 expandir en etapas posteriores para integrar Apigee como la plataforma de la API mediante las opciones de diseño de redes que se analizaron anteriormente, incluida la opción de Private Service Connect.
Puedes hacer que se pueda acceder al extremo de Private Service Connect desde otras regiones con el acceso global de Private Service Connect.
El cliente que se conecta al extremo de Private Service Connect puede estar en la misma región que el extremo o en una diferente. 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 los recursos alojados en otras regiones acceden a un extremo de Private Service Connect, se aplican cargos de salida interregionales al tráfico destinado a extremos con acceso global.
Prácticas recomendadas
- Considerar a Apigee y Apigee Hybrid como tu solución de plataforma de API ofrece varios beneficios. Proporciona una capa de proxy y una abstracción o fachada para tus APIs de servicio de backend combinadas con capacidades de seguridad, límites de frecuencia, cuotas y estadísticas.
- 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.
- Las VPCs y el diseño de proyectos en Google Cloud deben estar impulsados por tu jerarquía de recursos y los requisitos del modelo de comunicación segura.
- Cuando se usan APIs con puertas de enlace de API, también debes usar una lista de entidades permitidas de direcciones IP. Una lista de entidades permitidas limita las comunicaciones a las fuentes y los destinos de direcciones IP específicas de los consumidores y las puertas de enlace de la API que podrían alojarse en diferentes entornos.
- Usa reglas de firewall de VPC o políticas de firewall para controlar el acceso a los recursos de Private Service Connect a través del extremo de Private Service Connect.
- Si una aplicación se expone de forma externa a través de un balanceador de cargas de aplicaciones, considera usar Google Cloud Armor como una capa de seguridad adicional para protegerte contra DSD y las amenazas de seguridad de la capa de la aplicación.
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 manera, evitas 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 equilibrador de cargas.
- Para el tráfico web saliente, puedes usar Google Cloud 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.