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 funcione como una 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 implementas cargas de trabajo de backend dentro de una red interna, las herramientas de redes de salida cerradas ayudan a mantener un nivel de seguridad más alto dentro de tu entorno de computación local. El patrón requiere que conectes los entornos de computación de manera tal que se cumplan los requisitos de comunicación que se mencionan a continuación:
- Las cargas de trabajo que implementas en Google Cloud pueden comunicarse con la puerta de enlace de API o el balanceador de cargas (o con 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.
Esta guía se enfoca 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 la API.
- Filtrado de lista de entidades permitidas de direcciones IP configurado para permitir solo la comunicación con fuentes y destinos de API predefinidos de ambos lados.
Para proteger un proxy de API, considera estos otros aspectos de seguridad. Si deseas obtener más información, consulta Prácticas recomendadas para proteger tus aplicaciones y APIs mediante Apigee.
Arquitectura
En el siguiente diagrama, se muestra una arquitectura de referencia que admite los requisitos de comunicación enumerados en la sección anterior:
Los datos fluyen por el diagrama anterior de la siguiente manera:
- En 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 de Google Cloud se extienden a los otros 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, usa una conectividad de red híbrida 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 capacidades 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 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 dirección IP RFC 1918 sin superposición.
Variantes
El patrón de arquitectura de salida cerrada 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 la puerta de enlace de API de Google Cloud y el frontend global
- Expón servicios remotos con Private Service Connect
Usa la puerta de enlace de API de Google Cloud y el frontend global
Con este enfoque de diseño, la exposición y la administración de las API residen dentro de Google Cloud. Como se muestra en el diagrama anterior, puedes lograr esto mediante 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 la configuración actual. Apigee ofrece dos opciones para el aprovisionamiento de conectividad:
- Con intercambio de tráfico entre VPC
- Sin intercambio de tráfico de VPC
Las capacidades de frontend global de Google 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.
La optimización de las velocidades de entrega de contenido se logra mediante la entrega de esas aplicaciones desde puntos de presencia (PoP) de Google Cloud. Los PoP de Google Cloud están presentes en más de 180 intercambios de Internet y en más de 160 instalaciones de interconexión de 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 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), en el que finalizan las solicitudes de clientes, 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 de Google Cloud envíe solicitudes a los 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) mediante grupos de extremos de red (NEG) de Private Service Connect.
Las redes descendentes se establecen a través de las siguientes opciones:
- 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.
Expón 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.
- Tienes una superposición de rango de direcciones IP, por ejemplo, en una situación de combinación y adquisición.
- Para habilitar comunicaciones unidireccionales seguras entre clientes, aplicaciones y servicios en todos los entornos, incluso cuando tienes un plazo corto.
- 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 nubes diversas y entornos locales en 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í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 en 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 extremo de Private Service Connect, como se ilustra en el siguiente diagrama. Esta opción de diseño para las comunicaciones unidireccionales proporciona una alternativa al intercambio de tráfico a 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 el 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 una configuración de ejemplo, consulta Publica un servicio híbrido mediante Private Service Connect.
El diseño tiene las siguientes ventajas:
- Evita las posibles dependencias de escalamiento compartidas y la 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 puede expandirse en etapas posteriores para integrar Apigee como la plataforma de API mediante las opciones de diseño de red que se analizaron antes, incluida la opción Private Service Connect.
Puedes hacer que el extremo de Private Service Connect sea accesible desde otras regiones mediante 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 región 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 se accede a un extremo de Private Service Connect mediante recursos alojados en otras regiones, 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 las APIs con puertas de enlace de API, también debes usar una lista de direcciones IP permitidas. Una lista de anunciantes permitidos limita las comunicaciones a las fuentes y los destinos de direcciones IP específicas de los consumidores de API y las puertas de enlace de API que podrían alojarse en entornos diferentes.
- Usa las reglas de firewall de VPC o las 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. Esto te permite evitar 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, puedes usar el proxy web seguro de Google Cloud. El proxy ofrece varios beneficios.
Revisa las prácticas recomendadas generales sobre los patrones de red híbridas y de múltiples nubes.