Patrón de malla

Last reviewed 2023-12-14 UTC

El patrón en malla se basa en establecer una arquitectura de red híbrida. Esa arquitectura abarca varios entornos de computación. 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 red se aplica principalmente a las arquitecturas híbridas por niveles, de múltiples nubes particionadas o con aumentos de actividad. También se aplica al diseño de continuidad del negocio para aprovisionar un entorno de recuperación ante desastres (DR) en Google Cloud. En todos los casos, requiere que conectes los entornos de computación de manera tal que se alineen con los siguientes requisitos de comunicación:

  • Las cargas de trabajo pueden comunicarse entre sí a través de los límites del entorno mediante direcciones IP RFC 1918 privadas.
  • La comunicación se puede iniciar desde cualquier lado. Los detalles del modelo de comunicación pueden variar según las aplicaciones y los requisitos de seguridad, como los modelos de comunicación que se analizan en las opciones de diseño que se presentan a continuación.
  • Las reglas de firewall que uses deben permitir el tráfico entre fuentes y destinos de direcciones IP específicas según los requisitos de la aplicación o las aplicaciones para las que se diseñó el patrón. Idealmente, puedes usar un enfoque de seguridad de varias capas para restringir los flujos de tráfico de manera detallada, entre los entornos de computación y dentro de ellos.

Arquitectura

En el siguiente diagrama, se ilustra una arquitectura de referencia de alto nivel del patrón enmallado.

Los datos de una arquitectura de red híbrida fluyen desde dos subredes en Google Cloud a una carga de trabajo en un entorno local.

  • Todos los entornos deben usar un espacio de direcciones IP RFC 1918 sin superposición.
  • En el lado de Google Cloud , puedes implementar cargas de trabajo en una sola VPC compartida o en varias VPC compartidas o no compartidas. Para conocer otras posibles opciones de diseño de este patrón, consulta las variaciones de diseño que se indican a continuación. La estructura seleccionada de tus VPC 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 ambientes 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 aplicación.
  • Limita las comunicaciones solo a las direcciones IP permitidas de tus fuentes y destinos. Usa cualquiera de las siguientes funciones o una combinación de ellas:

    • Reglas de firewall o políticas de firewall

    • Dispositivo virtual de red (NVA) con capacidades de inspección de firewall de nueva generación (NGFW) que se coloca 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 sin cambiar el diseño ni el enrutamiento de la red

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 considerar los requisitos de comunicación del patrón. Las opciones de patrones se describen en las siguientes secciones:

Una VPC por entorno

Los motivos comunes para considerar la opción de una VPC por entorno son los siguientes:

  • El entorno de nube requiere la separación a nivel de la red de las redes y los recursos de la VPC, en alineación 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 de una sola VPC o un solo 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 mediante VPN o Cloud Interconnect con varios adjuntos de VLAN.

Los datos de una arquitectura de red híbrida con una VPC en cada entorno fluyen desde dos subredes en Google Cloud a una carga de trabajo en un entorno local.

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 aterrizaje. En esa topología, se puede compartir una sola (o varias) conexiones híbridas con todas las VPC de radio. Se comparte mediante 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: "Cómo usar un firewall de capa de aplicación centralizado".

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 superan 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 para pasar todo el tráfico entre entornos a través de un firewall NVA centralizado, como se muestra en el siguiente diagrama.

Puedes aplicar el patrón del siguiente diagrama en el diseño de la zona de destino con una topología de concentrador y radio con dispositivos centralizados:

Los datos de dos VPC compartidas en Google Cloud fluyen a través de un NVA a una red de VPC de tránsito a una carga de trabajo en un entorno local.

Como se muestra en el diagrama anterior, la NVA actúa como la capa de seguridad del perímetro y sirve como base para habilitar la inspección de tráfico intercalado. 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 puede 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 los microservicios que se analiza en la sección patrón reflejado 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 definirse con precisión, 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 tu diseño de jerarquía de recursos y el diseño necesario para admitir cualquier proyecto y VPC. De esta manera, puedes seleccionar la arquitectura de red óptima que se alinee 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 usas NVAs centralizados 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. Basar estos controles y políticas en los requisitos de seguridad de tus aplicaciones
  • Cuando diseñes una solución que incluya NVA, es importante tener en cuenta la alta disponibilidad (HA) de las NVA para evitar un punto único de fallo que podría bloquear toda la comunicación. Sigue las instrucciones de diseño y de implementación de HA y redundancia que proporciona el proveedor de seguridad deGoogle Cloud que suministra tus NVA.
  • Para proporcionar mayor privacidad, integridad de los datos y un modelo de comunicación controlado, expone las aplicaciones a través de APIs con puertas de enlace de API, como Apigee y Apigee híbrido con mTLS de extremo a extremo. También puedes usar una VPC compartida con Apigee en el mismo recurso de la 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 ayudar a 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 deseas 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 con control de acceso que se analizan en los otros documentos de esta serie.