Seguridad de redes para aplicaciones distribuidas en la red entre nubes

Last reviewed 2025-01-30 UTC

Este documento forma parte de una serie de guías de diseño de redes entre nubes. En esta parte se analiza la capa de seguridad de la red.

La serie consta de las siguientes partes:

Superficies de seguridad

Cuando diseñes la capa de seguridad de Cross-Cloud Network, debes tener en cuenta las siguientes superficies de seguridad:

  • Seguridad de las cargas de trabajo
  • Seguridad del perímetro de dominio

La seguridad de las cargas de trabajo controla la comunicación entre las cargas de trabajo en la nube privada virtual (VPC) y dentro de ella. La seguridad de las cargas de trabajo usa puntos de aplicación de la seguridad que están cerca de las cargas de trabajo en la arquitectura. Siempre que sea posible, Red Multinube proporciona seguridad a las cargas de trabajo mediante Cloud Next Generation Firewall de Google Cloud.

Es necesario aplicar medidas de seguridad perimetral en todos los límites de la red. Como el perímetro suele interconectar redes gestionadas por diferentes organizaciones, a menudo se requieren controles de seguridad más estrictos. Debes asegurarte de que las siguientes comunicaciones entre redes estén protegidas:

  • Comunicaciones entre VPCs
  • Comunicaciones a través de conexiones híbridas con otros proveedores de servicios en la nube o centros de datos on-premise
  • Comunicaciones a Internet

La posibilidad de insertar NVAs de redes de terceros en el entorno deGoogle Cloud es fundamental para cumplir los requisitos de seguridad perimetral en las conexiones híbridas.

Seguridad de las cargas de trabajo en la nube

Usa políticas de cortafuegos enGoogle Cloud para proteger las cargas de trabajo y proporcionar funciones de cortafuegos con reconocimiento del estado que se puedan escalar horizontalmente y que se apliquen a cada instancia de VM. La naturaleza distribuida de los cortafuegos te ayuda a implementar políticas de seguridad para la microsegmentación de la red sin que afecte negativamente al rendimiento de tus cargas de trabajo. Google Cloud

Usa políticas de cortafuegos jerárquicas para mejorar la gestión y aplicar el cumplimiento de la postura de tus políticas de cortafuegos. Las políticas de cortafuegos jerárquicas te permiten crear y aplicar una política de cortafuegos coherente en toda tu organización. Puedes asignar políticas de cortafuegos jerárquicas a la organización o a carpetas concretas. Además, las reglas de las políticas de cortafuegos jerárquicas pueden delegar la evaluación en políticas de nivel inferior (políticas de cortafuegos de red globales o regionales) con una acción goto_next.

Las reglas de nivel inferior no pueden anular una regla de un nivel superior en la jerarquía de recursos. Esta estructura de reglas permite a los administradores de toda la organización gestionar las reglas de cortafuegos obligatorias en un solo lugar. Entre los casos prácticos habituales de las políticas de cortafuegos jerárquicas se incluyen el acceso a hosts bastion de organizaciones o de varios proyectos, la autorización de sistemas de sondeo o de comprobación del estado centralizados y la aplicación de un límite de red virtual en una organización o un grupo de proyectos. Para ver más ejemplos de uso de políticas de cortafuegos jerárquicas, consulta Ejemplos de políticas de cortafuegos jerárquicas.

Usa políticas de cortafuegos de red globales y regionales para definir reglas en una red de VPC concreta, ya sea para todas las regiones de la red (global) o para una sola región (regional).

Para conseguir controles más granulares a nivel de máquina virtual (VM), te recomendamos que uses etiquetas gestionadas por Gestión de Identidades y Accesos (IAM) a nivel de organización o de proyecto. Las etiquetas controladas por IAM permiten aplicar reglas de cortafuegos basadas en la identidad del host de la carga de trabajo, en lugar de en la dirección IP del host, y funcionan en el peering de redes de VPC. Las reglas de firewall implementadas mediante etiquetas pueden proporcionar microsegmentación dentro de la subred con una cobertura de la política que se aplica automáticamente a las cargas de trabajo, independientemente de dónde se implementen y de la arquitectura de red.

Además de las funciones de inspección con estado y la compatibilidad con etiquetas, Cloud Next Generation Firewall también admite el filtrado por Threat Intelligence, FQDN y geolocalización.

Te recomendamos que migres de reglas de cortafuegos de VPC a políticas de cortafuegos. Para facilitar la migración, usa la herramienta de migración, que crea una política de cortafuegos de red global y convierte las reglas de cortafuegos de VPC en la nueva política.

Seguridad perimetral en la nube

En un entorno de red multinube, la seguridad perimetral se suele implementar en cada red. Por ejemplo, la red local tiene su propio conjunto de cortafuegos perimetrales, mientras que cada red en la nube implementa cortafuegos perimetrales independientes.

Como Cross-Cloud Network se ha diseñado para ser el centro de todas las comunicaciones, puedes unificar y centralizar los controles de seguridad perimetral, así como implementar un único conjunto de cortafuegos perimetrales en tu Cross-Cloud Network. Para ofrecer una pila de seguridad perimetral integrada, Cross-Cloud Network te proporciona opciones flexibles para insertar NVAs.

En los diseños que se muestran en los diagramas, puede implementar NVAs de terceros en la VPC de tránsito del proyecto de centro de conectividad.

Las NVAs se pueden implementar en una sola interfaz de red (modo de una sola NIC) o en varias interfaces de red de varias VPCs (modo de varias NICs). En el caso de las redes entre nubes, recomendamos una implementación de una sola NIC para las NVAs, ya que esta opción le permite hacer lo siguiente:

  • Inserta las NVAs con rutas basadas en políticas.
  • Evita crear topologías rígidas.
  • Despliega en una variedad de topologías entre VPCs.
  • Habilita el autoescalado para las NVAs.
  • Escala a muchas VPCs a lo largo del tiempo sin tener que cambiar la implementación de la interfaz de la NVA.

Si tu diseño requiere varias NICs, las recomendaciones se detallan en Seguridad perimetral de NVA con varias NICs.

Para llevar a cabo la dirección del tráfico necesaria para la implementación de la NVA, en esta guía se recomienda aplicar de forma selectiva rutas estáticas y basadas en políticas en las tablas de enrutamiento de la VPC. Las rutas basadas en políticas son más flexibles que las rutas estándar porque se basan en la información de origen y de destino. Estas rutas basadas en políticas también se aplican solo en lugares específicos de la topología de la red en la nube. Esta granularidad permite definir un comportamiento de redirección de tráfico muy específico para flujos de conectividad muy específicos.

Además, este diseño habilita los mecanismos de resiliencia que requieren los NVAs. Las NVAs están protegidas por un balanceador de carga TCP/UDP interno para habilitar la redundancia de las NVAs, el autoescalado para la capacidad elástica y la simetría de flujo para admitir el procesamiento de tráfico bidireccional con reconocimiento del estado.

Seguridad perimetral de NVA de una sola NIC

En el diseño descrito en Conectividad entre VPCs para servicios centralizados, la VPC de tránsito actúa como un centro para las VPCs de radio que están conectadas mediante el emparejamiento entre redes de VPC y la VPN de alta disponibilidad. La VPC de tránsito también permite la conectividad entre las redes externas y las VPC de spoke.

Para insertar una NVA con una sola NIC, este diseño combina los dos patrones siguientes:

  • Insertar NVAs en un hub de emparejamiento entre redes de VPC con conexiones híbridas externas
  • Insertar NVAs en un hub de VPC de VPN de alta disponibilidad con conexiones híbridas externas

En el siguiente diagrama se muestran las NVAs insertadas en los centros de conectividad para el emparejamiento entre redes de VPC y la VPN de alta disponibilidad:

NVAs insertadas en los centros de las redes de VPC emparejadas y las VPNs de alta disponibilidad

En el diagrama anterior se muestra un patrón combinado:

  • Una VPC de tránsito que aloja las conexiones VLAN de Cloud Interconnect que proporcionan conectividad híbrida o multinube. Esta VPC también contiene las NVAs de una sola NIC que monitorizan las conexiones híbridas.
  • VPCs de aplicaciones conectadas a la VPC de tránsito mediante el emparejamiento entre redes de VPC.
  • Una VPC de servicios central conectada a la VPC de tránsito mediante una VPN de alta disponibilidad.

En este diseño, los spokes que están conectados mediante una VPN de alta disponibilidad usan la VPC de tránsito para comunicarse con los spokes que están conectados mediante el emparejamiento entre redes de VPC. La comunicación se dirige a través de los cortafuegos de NVA de terceros mediante la siguiente combinación de balanceo de carga de transferencia, rutas estáticas y rutas basadas en políticas:

  1. Para dirigir el tráfico de la VPN de alta disponibilidad al balanceador de carga interno, aplica rutas basadas en políticas sin etiquetar a la VPC de tránsito. En estas rutas basadas en políticas, utiliza intervalos CIDR de origen y destino que permitan la simetría del tráfico.
  2. Para dirigir el tráfico entrante al balanceador de carga de red interno de tipo pasarela, aplica rutas basadas en políticas a las conexiones de Cloud Interconnect de la VPC de tránsito. Se trata de rutas regionales.
  3. Para que el tráfico que sale de la NVA no se enrute directamente de vuelta a la NVA, haz que todas las interfaces de la NVA sean el destino de una ruta basada en políticas de omisión para omitir otras rutas basadas en políticas. A continuación, el tráfico sigue la tabla de enrutamiento de la VPC una vez que las NVAs lo han procesado.
  4. Para dirigir el tráfico a los balanceadores de carga internos de la NVA en la VPC de tránsito, aplica rutas estáticas a las VPCs de la aplicación. Se pueden acotar por región mediante etiquetas de red.

Seguridad perimetral de NVA con varias NIC

En el modo de varias NICs, la topología es más estática porque las NVAs conectan las distintas VPCs en las que residen las diferentes interfaces de red.

Cuando se requieren zonas basadas en interfaces en un cortafuegos, el siguiente diseño de varias NICs permite la conectividad externa necesaria. Este diseño asigna diferentes interfaces de firewall a las redes externas. Los profesionales de la seguridad se refieren a las redes externas como redes no fiables y a las redes internas como redes fiables. En la implementación de NVA con varias NICs, este diseño se implementa mediante VPCs de confianza y no de confianza.

Para las comunicaciones internas, el cortafuegos se puede aplicar mediante un modelo de inserción de una sola NIC que corresponda a un modelo de zona basado en CIDR.

En este diseño, insertas las NVAs configurando lo siguiente:

  1. Para dirigir el tráfico de la VPN de alta disponibilidad al balanceador de carga interno, aplica rutas basadas en políticas sin etiquetar a la VPC de confianza. En estas rutas basadas en políticas, utiliza intervalos CIDR de origen y destino que permitan la simetría del tráfico.
  2. Para dirigir el tráfico entrante al balanceador de carga de red interno de tipo pases, aplica rutas basadas en políticas a las conexiones de Cloud Interconnect de la VPC no de confianza. Se trata de rutas regionales.
  3. Para que el tráfico que sale de la NVA no se enrute directamente de vuelta a la NVA, haz que todas las interfaces de la NVA sean el destino de una ruta basada en políticas de omisión para omitir otras rutas basadas en políticas. A continuación, el tráfico sigue la tabla de enrutamiento de la VPC una vez que las NVAs lo han procesado.
  4. Para dirigir el tráfico a los balanceadores de carga internos de la NVA en la VPC de confianza, aplica rutas estáticas a las VPCs de la aplicación. Se pueden acotar por región mediante etiquetas de red.

En el siguiente diagrama se muestran las NVAs con varias NICs insertadas entre las redes VPC no fiables y fiables del proyecto de concentrador:

NVAs para la comunicación interna

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: