El patrón en malla se basa en el establecimiento de una arquitectura de red híbrida. Esa arquitectura abarca varios entornos de procesamiento. En estos entornos, todos los sistemas pueden comunicarse entre sí y no se limitan a la comunicación unidireccional según los requisitos de seguridad de tus aplicaciones. Este patrón de redes se aplica principalmente a las arquitecturas híbridas en niveles, de múltiples nubes particionadas o con aumentos de actividad. También se aplica al diseño de continuidad empresarial para aprovisionar un entorno de recuperación ante desastres (DR) en Google Cloud. En todos los casos, se requiere que conectes los entornos de computación de manera tal que se cumplan los siguientes requisitos de comunicación:
- Las cargas de trabajo pueden comunicarse entre sí a través de los límites del entorno con direcciones IP RFC 1918 privadas.
- La comunicación se puede iniciar desde cualquier lado. Los detalles del modelo de comunicaciones pueden variar según las aplicaciones y los requisitos de seguridad, como los modelos de comunicaciones que se analizan en las siguientes opciones de diseño.
- Las reglas de firewall que uses deben permitir el tráfico entre direcciones IP de origen y destino específicas según los requisitos de la aplicación o las aplicaciones para las que se diseñó el patrón. Lo ideal es que puedas usar un enfoque de seguridad de varias capas para restringir los flujos de tráfico de manera detallada, tanto entre los entornos de computación como dentro de ellos.
Arquitectura
En el siguiente diagrama, se ilustra una arquitectura de referencia de alto nivel del patrón en malla.
- Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.
- Del lado de Google Cloud , puedes implementar cargas de trabajo en una o varias VPCs compartidas o no compartidas. Para conocer otras opciones de diseño posibles de este patrón, consulta las variaciones de diseño que se muestran a continuación. La estructura seleccionada de tus VPCs debe alinearse con los proyectos y el diseño de la jerarquía de recursos de tu organización.
- La red de VPC de Google Cloud se extiende a otros entornos de procesamiento. Esos entornos pueden ser locales o estar en otra nube. Usa una de las opciones de conectividad de redes híbridas y de múltiples nubes que cumplan con los requisitos de tu empresa y tu aplicación.
Limita las comunicaciones solo a las direcciones IP permitidas de tus fuentes y destinos. Usa cualquiera de las siguientes capacidades o una combinación de ellas:
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 sin cambiar el diseño de la red ni el enrutamiento.
Variantes
El patrón de arquitectura en malla se puede combinar con otros enfoques para cumplir con diferentes requisitos de diseño, sin dejar de tener en cuenta los requisitos de comunicación del patrón. Las opciones de patrones se describen en las siguientes secciones:
- Una VPC por entorno
- Usa un firewall de capa de aplicación centralizado
- Arquitectura distribuida de confianza cero de microservicios
Una VPC por entorno
Estos son los motivos comunes para considerar la opción de una VPC por entorno:
- El entorno de nube requiere la separación a nivel de red de las redes y los recursos de la VPC, en consonancia con el diseño de la jerarquía de recursos de tu organización.
Si se requiere la separación de dominios administrativos, también se puede combinar con un proyecto independiente por entorno.
- Para administrar de forma centralizada los recursos de red en una red común y proporcionar aislamiento de red entre los diferentes entornos, usa una VPC compartida para cada entorno que tengas en Google Cloud, como desarrollo, pruebas y producción.
- Requisitos de escalamiento que podrían superar las cuotas de VPC para una sola VPC o proyecto
Como se ilustra en el siguiente diagrama, el diseño de una VPC por entorno permite que cada VPC se integre directamente con el entorno local o con otros entornos de nube a través de VPNs o un Cloud Interconnect con varios adjuntos de VLAN.
El patrón que se muestra en el diagrama anterior se puede aplicar en una topología de red de concentrador y radio de zona de destino. En esa topología, se puede compartir una (o varias) conexiones híbridas con todas las VPCs radiales. Se comparte a través de una VPC de tránsito para finalizar la conectividad híbrida y las otras VPC de radio. También puedes expandir este diseño agregando un NVA con capacidades de inspección de firewall de nueva generación (NGFW) en la VPC de tránsito, como se describe en la siguiente sección, "Usa un firewall centralizado de capa de aplicación".
Usa un firewall de capa de aplicación centralizado
Si tus requisitos técnicos exigen considerar la capa de aplicación (capa 7) y la inspección profunda de paquetes con capacidades avanzadas de firewall que superen las capacidades de Cloud Next Generation Firewall, puedes usar un dispositivo NGFW alojado en un NVA. Sin embargo, esa NVA debe satisfacer las necesidades de seguridad de tu organización. Para implementar estos mecanismos, puedes extender la topología a fin de pasar todo el tráfico entre entornos a través de un firewall de NVA centralizado, como se muestra en el siguiente diagrama.
Puedes aplicar el patrón del siguiente diagrama al diseño de la zona de destino con una topología de concentrador y radio con dispositivos centralizados:
Como se muestra en el diagrama anterior, la VNA actúa como la capa de seguridad perimetral y sirve como base para habilitar la inspección de tráfico intercalada. También aplica políticas de control de acceso estrictas. Para inspeccionar los flujos de tráfico de este a oeste y de norte a sur, el diseño de una NVA centralizada podría incluir varios segmentos con diferentes niveles de controles de acceso de seguridad.
Arquitectura distribuida de confianza cero de microservicios
Cuando se usan aplicaciones alojadas en contenedores, la arquitectura distribuida de confianza cero de microservicios que se analizó en la sección del patrón duplicado también se aplica a este patrón de arquitectura.
La diferencia clave entre este patrón y el patrón reflejado es que el modelo de comunicación entre las cargas de trabajo en Google Cloud y otros entornos se puede iniciar desde cualquier lado. El tráfico debe controlarse y ser detallado, según los requisitos de la aplicación y los requisitos de seguridad con Service Mesh.
Prácticas recomendadas para el patrón de malla
- Antes de hacer cualquier otra cosa, decide el diseño de tu jerarquía de recursos y el diseño necesario para admitir cualquier proyecto y VPC. Esto puede ayudarte a seleccionar la arquitectura de redes óptima que se alinea con la estructura de tus proyectos de Google Cloud .
- Usa una arquitectura distribuida de confianza cero cuando uses Kubernetes en tu entorno de computación privado yGoogle Cloud.
- Cuando uses NVAs centralizadas en tu diseño, debes definir varios segmentos con diferentes niveles de controles de acceso de seguridad y políticas de inspección de tráfico. Basa estos controles y políticas en los requisitos de seguridad de tus aplicaciones.
- Cuando diseñes una solución que incluya AVN, es importante tener en cuenta la alta disponibilidad (AD) de las AVN para evitar un único punto de falla que pueda bloquear toda la comunicación. Sigue la guía de diseño y de implementación de HA y redundancia que proporciona el Google Cloud proveedor de seguridad que suministra tus NVA.
- Para proporcionar mayor privacidad, integridad de los datos y un modelo de comunicación controlado, expón las aplicaciones a través de las APIs con puertas de enlace de API, como Apigee y Apigee hybrid con mTLS de extremo a extremo. También puedes usar una VPC compartida con Apigee en el mismo recurso de organización.
- Si el diseño de tu solución requiere exponer una aplicación basada en Google Clouda la Internet pública, considera las recomendaciones de diseño que se analizan en Redes para la entrega de aplicaciones orientadas a Internet.
- 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. Además, puedes extender los perímetros de servicio a un entorno híbrido a través de una VPN autorizada o con 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.
- Revisa las prácticas recomendadas generales para los patrones de redes híbridas y de múltiples nubes.
Si pretendes aplicar un aislamiento más estricto y un acceso más detallado entre tus aplicaciones alojadas en Google Cloudy en otros entornos, considera usar uno de los patrones cerrados que se analizan en los otros documentos de esta serie.