Diseña redes para migrar cargas de trabajo empresariales: enfoques arquitectónicos

Last reviewed 2023-11-13 UTC

En este documento, se presenta una serie en la que se describen las arquitecturas de seguridad y las herramientas de redes para las empresas que migran cargas de trabajo de centros de datos a Google Cloud. Estas arquitecturas se enfocan en la conectividad avanzada, los principios de seguridad de confianza cero y la administración en un entorno híbrido.

Como se describe en el documento adjunto, Arquitecturas para proteger los planos de datos en la nube, las empresas implementan un espectro de arquitecturas que tienen en cuenta las necesidades de conectividad y seguridad en la nube. Clasificamos estas arquitecturas en tres patrones arquitectónicos distintos: lift-and-shift, servicios híbridos y distribución de confianza cero. En el documento actual, se consideran diferentes enfoques de seguridad, según la arquitectura que haya elegido una empresa. También se describe cómo crear esos enfoques mediante los componentes básicos que proporciona Google Cloud. Debes usar estos lineamientos de seguridad junto con otros lineamientos de arquitectura para abarcar la confiabilidad, la disponibilidad, el escalamiento, el rendimiento y la administración.

Este documento está diseñado para ayudar a los arquitectos de sistemas, los administradores de redes y los administradores de seguridad que planean migrar cargas de trabajo locales a la nube. Se da por sentado que:

  • Estás familiarizado con los conceptos de herramientas de redes y seguridad de los centros de datos.
  • Tienes cargas de trabajo existentes en tu centro de datos local y estás familiarizado con lo que hacen y quiénes son sus usuarios.
  • Tienes al menos algunas cargas de trabajo que planeas migrar.
  • Por lo general, estás familiarizado con los conceptos descritos en Arquitecturas para proteger los planos de datos en la nube.

La serie consiste en los siguientes documentos:

En este documento, se resumen los tres patrones arquitectónicos principales y se presentan los componentes básicos que puedes usar para crear tu infraestructura. Por último, se describe cómo ensamblar los componentes básicos en una serie de arquitecturas de referencia que coinciden con los patrones. Puedes usar estas arquitecturas de referencia para guiar tu propia arquitectura.

En este documento, se mencionan máquinas virtuales (VMs) como ejemplos de recursos de carga de trabajo. La información se aplica a otros recursos que usan redes de VPC, como las instancias de Cloud SQL y los nodos de Google Kubernetes Engine.

Descripción general de los patrones de arquitectura

Por lo general, los ingenieros de redes se enfocan en crear la infraestructura de red física y la infraestructura de seguridad en los centros de datos locales.

El recorrido hacia la nube cambió este enfoque porque las construcciones de herramientas de redes en la nube están definidas por software. En la nube, los propietarios de las aplicaciones tienen un control limitado de la pila de infraestructura subyacente. También necesitan un modelo que tenga un perímetro seguro y proporcione aislamiento para sus cargas de trabajo.

En esta serie, consideramos tres patrones arquitectónicos comunes. Estos patrones se compilan uno sobre otro y se pueden ver como un espectro en lugar de una opción estricta.

Patrón de lift-and-shift

En el patrón arquitectónico de lift-and-shift, los propietarios de aplicaciones empresariales migran sus cargas de trabajo a la nube sin refactorizar esas cargas de trabajo. Los ingenieros de red y seguridad usan los controles de capa 3 y capa 4 para proporcionar protección mediante una combinación de dispositivos virtuales de red que imitan dispositivos físicos locales y reglas de firewall en la nube en la red de VPC. Los propietarios de la carga de trabajo implementan sus servicios en las redes de VPC.

Patrón de servicios híbridos

Las cargas de trabajo que se compilan mediante lift-and-shift pueden necesitar acceso a los servicios en la nube, como BigQuery o Cloud SQL. Por lo general, el acceso a esos servicios en la nube está en la capa 4 y la capa 7. En este contexto, el aislamiento y la seguridad no se pueden realizar estrictamente en la capa 3. Por lo tanto, las herramientas de redes de servicios y los Controles del servicio de VPC se usan para proporcionar conectividad y seguridad, según las identidades del servicio al que se accede y el servicio que solicita acceso. En este modelo, es posible expresar políticas de control de acceso enriquecidas.

Patrón distribuido de confianza cero

En una arquitectura de confianza cero, las aplicaciones empresariales extienden la aplicación de la seguridad más allá de los controles perimetrales. Dentro del perímetro, las cargas de trabajo pueden comunicarse con otras cargas de trabajo solo si su identidad de IAM tiene un permiso específico, que se rechaza de forma predeterminada. En una arquitectura distribuida de confianza cero, la confianza se basa en la identidad y se aplica para cada aplicación. Las cargas de trabajo se compilan como microservicios que tienen identidades emitidas de forma central. De esta manera, los servicios pueden validar a sus emisores y tomar decisiones basadas en políticas para cada solicitud sobre si ese acceso es aceptable. A menudo, esta arquitectura se implementa mediante proxies distribuidos (una malla de servicios) en lugar de usar puertas de enlace centralizadas.

Las empresas pueden aplicar el acceso de confianza cero de los usuarios y dispositivos a las aplicaciones empresariales mediante la configuración de Identity-Aware Proxy (IAP). IAP proporciona controles basados en la identidad y en el contexto para el tráfico de usuarios desde Internet o la intranet.

Combina patrones

Las empresas que compilan o migran sus aplicaciones empresariales a la nube suelen usar una combinación de los tres patrones arquitectónicos.

Google Cloud ofrece una cartera de productos y servicios que funcionan como componentes básicos para implementar el plano de datos en la nube que impulsa los patrones arquitectónicos. Estos componentes básicos se analizarán más adelante en este documento. La combinación de controles que se proporcionan en el plano de datos en la nube, junto con los controles administrativos para administrar los recursos en la nube, forma la base de un perímetro de seguridad de extremo a extremo. El perímetro que crea esta combinación te permite controlar, implementar y operar tus cargas de trabajo en la nube.

Controles administrativos y jerarquía de recursos

En esta sección, se presenta un resumen de los controles administrativos que Google Cloud proporciona como contenedores de recursos. Los controles incluyen proyectos, carpetas y recursos de la organización de Google Cloud que te permiten agrupar y organizar de forma jerárquica los recursos en la nube. Esta organización jerárquica te proporciona una estructura de propiedad y puntos de ancla para aplicar políticas y controles.

Un recurso de organización de Google es el nodo raíz en la jerarquía y es la base para crear implementaciones en la nube. Un recurso de organización puede tener carpetas y proyectos como elementos secundarios. Una carpeta tiene proyectos u otras carpetas como secundarias. Todos los demás recursos de nube son elementos secundarios de los proyectos.

Usas las carpetas como un método para agrupar proyectos. Los proyectos constituyen la base para la creación, la habilitación y el uso de todos los servicios de Google Cloud. Los proyectos te permiten administrar las APIs, habilitar la facturación, agregar y quitar colaboradores, y administrar permisos.

Mediante la Identity and Access Management (IAM) de Google, puedes asignar roles, y definir políticas y permisos de acceso en todos los niveles de la jerarquía de recursos. Los recursos en la jerarquía heredan las políticas de IAM. Los propietarios de recursos que se encuentran más abajo en la jerarquía no pueden alterar estas políticas. En algunos casos, la administración de identidades y accesos se proporciona a un nivel más detallado, por ejemplo, en el alcance de los objetos en un espacio de nombres o clúster en Google Kubernetes Engine.

Consideraciones de diseño para las redes de nube privada virtual de Google

Cuando diseñas una estrategia de migración a la nube, es importante desarrollar una estrategia para cómo tu empresa usará redes de VPC. Una red de VPC es una versión virtual de tu red física tradicional. Es una partición de red privada completamente aislada. De forma predeterminada, las cargas de trabajo o los servicios que se implementan en una red de VPC no pueden comunicarse con trabajos en otra red de VPC. Por lo tanto, las redes de VPC habilitan el aislamiento de la carga de trabajo mediante la formación de un límite de seguridad.

Debido a que cada red de VPC en la nube es una red completamente virtual, cada una tiene su propio espacio de direcciones IP privado. Por lo tanto, puedes usar la misma dirección IP en varias redes de VPC sin conflictos. Una implementación local típica puede consumir una gran parte del espacio de direcciones IP privadas de RFC 1918. Por otro lado, si tienes cargas de trabajo locales y en redes de VPC, puedes volver a usar los mismos rangos de direcciones en diferentes redes de VPC, siempre que esas redes no estén conectadas o intercambien de tráfico, y por tanto usen un espacio de direcciones IP con menor velocidad.

Las redes de VPC son globales

Las redes de VPC en Google Cloud son globales, lo que significa que los recursos implementados en un proyecto que tiene una red de VPC pueden comunicarse entre sí directamente con la red troncal privada de Google.

Como se muestra en la Figura 1, puedes tener una red de VPC en tu proyecto que contenga subredes en diferentes regiones que abarquen varias zonas. Las VMs de cualquier región pueden comunicarse de forma privada entre sí mediante las rutas de VPC locales.

Implementación global de la red de VPC de Google Cloud con subredes configuradas en diferentes regiones.

Figura 1. Implementación global de la red de VPC de Google Cloud con subredes configuradas en diferentes regiones.

Comparte una red mediante VPC compartida

La VPC compartida permite que un recurso de organización conecte varios proyectos a una red de VPC común para que se puedan comunicar entre sí de manera segura mediante direcciones IP internas de la red compartida. Los administradores de red para esa red compartida aplican el control centralizado de los recursos de red.

Cuando usas una VPC compartida, debes designar un proyecto como proyecto host y conectarle uno o más proyectos de servicio. Las redes de VPC en el proyecto host se conocen como redes de VPC compartida. Los recursos aptos de proyectos de servicio pueden usar subredes en la red de VPC compartida.

Las empresas suelen usar redes de VPC compartidas cuando necesitan administradores de red y seguridad para centralizar la administración de recursos de red, como subredes y rutas. Al mismo tiempo, las redes de VPC compartida permiten que los equipos de aplicaciones y desarrollo creen y borren instancias de VM y, además, implementen cargas de trabajo en subredes designadas mediante los proyectos de servicio.

Aísla entornos mediante redes de VPC

Usar redes de VPC para aislar entornos tiene varias ventajas, pero también debes considerar algunas desventajas. En esta sección, se abordan estas desventajas y se describen patrones comunes para implementar el aislamiento.

Motivos para aislar entornos

Debido a que las redes de VPC representan un dominio de aislamiento, muchas empresas las usan para mantener entornos o unidades de negocios en dominios independientes. Los motivos comunes para crear un aislamiento a nivel de la VPC son los siguientes:

  • Una empresa desea establecer comunicaciones de denegación predeterminadas entre una red de VPC y otra, porque estas redes representan una distinción significativa de la organización. Para obtener más información, consulta Patrones de aislamiento de red de VPC comunes más adelante en este documento.
  • Una empresa debe tener rangos de direcciones IP superpuestos debido a entornos locales preexistentes, debido a adquisiciones o a implementaciones en otros entornos de nube.
  • Una empresa desea delegar el control administrativo total de una red a una parte de la empresa.

Desventajas de los entornos aislados

Crear entornos aislados con redes de VPC puede tener algunas desventajas. Tener varias redes de VPC puede aumentar la sobrecarga administrativa de administrar los servicios que abarcan varias redes. En este documento, se analizan técnicas que puedes usar para administrar esta complejidad.

Patrones de aislamiento de red de VPC comunes

Existen algunos patrones comunes para aislar redes de VPC:

  • Aísla los entornos de desarrollo, etapa de pruebas y producción. Este patrón permite que las empresas segreguen por completo los entornos de desarrollo, etapa de pruebas y producción. En efecto, esta estructura mantiene varias copias completas de las aplicaciones, con un lanzamiento progresivo entre cada entorno. En este patrón, las redes de VPC se usan como límites de seguridad. Los desarrolladores tienen un alto grado de acceso a las redes de VPC de desarrollo para realizar su trabajo diario. Cuando finaliza el desarrollo, un equipo de producción de ingeniería o un equipo de control de calidad puede migrar los cambios a un entorno de etapa de pruebas, en el que los cambios se pueden probar de forma integrada. Cuando los cambios están listos para implementarse, se envían a un entorno de producción.
  • Aísla las unidades de negocios. Algunas empresas desean imponer un alto grado de aislamiento entre las unidades de negocios, en especial en el caso de las unidades que se adquirieron o las que exigen un alto grado de autonomía y aislamiento. En este patrón, las empresas suelen crear una red de VPC para cada unidad de negocios y delegar el control de esa VPC a los administradores de la unidad de negocios. La empresa usa técnicas que se describen más adelante en este documento para exponer los servicios que abarcan la empresa o alojar aplicaciones orientadas al usuario que abarcan varias unidades de negocios.

Recomendación para crear entornos aislados

Te recomendamos que diseñes tus redes de VPC para que tengan el dominio más amplio que se alinee con los límites administrativos y de seguridad de tu empresa. Puedes lograr un aislamiento adicional entre las cargas de trabajo que se ejecutan en la misma red de VPC a través de controles de seguridad como los firewalls.

Si quieres obtener más información para diseñar y crear una estrategia de aislamiento para tu organización, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC y Herramientas de redes en el plano de bases empresarial de Google Cloud.

Componentes básicos para las herramientas de redes en la nube

En esta sección, se analizan los componentes básicos para la conectividad de red, la seguridad de la red, la red de servicio y la seguridad de servicio. La Figura 2 muestra cómo se relacionan estos componentes básicos. Puedes usar uno o más de los productos que se enumeran en una fila determinada.

Componentes básicos en el dominio de la conectividad y la seguridad de la red de la nube.

Figura 2. Componentes básicos en el dominio de la conectividad y la seguridad de la red de la nube.

En las siguientes secciones, se analiza cada uno de los componentes básicos y qué servicios de Google Cloud puedes usar para cada uno de ellos.

Conectividad de red

El bloque de la conectividad de red está en la base de la jerarquía. Es responsable de conectar los recursos de Google Cloud a los centros de datos locales o a otras nubes. En función de tus necesidades, es posible que necesites solo uno de estos productos o que los uses para manejar diferentes casos de uso.

Cloud VPN

Cloud VPN te permite conectar tus oficinas de sucursales remotas o cualquier otro proveedor de servicios en la nube a redes de VPC de Google a través de una conexión de VPN IPsec. Una puerta de enlace de VPN encripta el tráfico que se traslada entre las dos redes; luego, la otra puerta de enlace de VPN lo desencripta, lo que ayuda a proteger los datos mientras atraviesan Internet.

Cloud VPN te permite habilitar la conectividad entre tu entorno local y Google Cloud sin la sobrecarga de aprovisionar las conexiones cruzadas físicas que se requieren para Cloud Interconnect (descritos en la siguiente sección). Puedes aprovisionar una VPN con alta disponibilidad para cumplir con un requisito de ANS de hasta un 99.99% de disponibilidad si tienes la arquitectura que cumple. Puedes considerar usar Cloud VPN si tus cargas de trabajo no requieren una latencia baja o un ancho de banda alto. Por ejemplo, Cloud VPN es una buena opción para casos de uso que no son esenciales o para extender la conectividad a otros proveedores de servicios en la nube.

Cloud Interconnect

Cloud Interconnect proporciona conectividad dedicada de nivel empresarial a Google Cloud que tiene una capacidad de procesamiento mayor y un rendimiento de red más confiable en comparación con el uso de VPN o entrada de Internet. La interconexión dedicada proporciona conectividad física directa a la red de Google desde tus routers. La interconexión de socio proporciona conectividad dedicada a través de una red extensa de socios, que podrían ofrecer opciones de alcance más amplios u otras opciones de ancho de banda que la interconexión dedicada. Cross-Cloud Interconnect proporciona conectividad directa dedicada desde tus redes de VPC hacia otros proveedores de servicios en la nube. La interconexión dedicada requiere que te conectes a una instalación de colocación en la que Google tenga presencia, pero la interconexión de socio no. Cross-Cloud Interconnect te permite seleccionar ubicaciones que cumplan con tus requisitos para establecer las conexiones. Cloud Interconnect garantiza que el tráfico entre tu red local o cualquier otra red de nube y tu red de VPC no pase por la Internet pública.

Puedes aprovisionar estas conexiones de Cloud Interconnect para cumplir con un requisito de ANS de hasta el 99.99% de disponibilidad si aprovisionas la arquitectura adecuada. Puedes usar Cloud Interconnect para admitir cargas de trabajo que requieran baja latencia, ancho de banda alto y rendimiento predecible, a la vez que garantizas que todo tu tráfico sea privado.

Network Connectivity Center para entornos híbridos

Network Connectivity Center proporciona conectividad de sitio a sitio entre las redes locales y otras de la nube. Lo hace mediante la red troncal de Google para brindar conectividad confiable entre tus sitios.

Además, puedes extender tu red de superposición SD-WAN existente a Google Cloud mediante la configuración de una VM o un router de proveedor externo como un adjunto de radio lógico.

Puedes acceder a los recursos dentro de las redes de VPC mediante el router, la VPN o la red de Cloud Interconnect como adjuntos de radio. Puedes usar Network Connectivity Center para consolidar la conectividad entre tus sitios locales, tus presencias en otras nubes y Google Cloud, y administrar todo con una sola vista.

Network Connectivity Center para redes de VPC

Network Connectivity Center también te permite crear una malla entre muchas redes de VPC. Puedes conectar esta malla a las instalaciones locales o a otras nubes mediante Cloud VPN o Cloud Interconnect.

Intercambio de tráfico entre redes de VPC

El intercambio de tráfico entre redes de VPC te permite conectar redes de VPC de Google para que las cargas de trabajo que se encuentran en redes de VPC diferentes puedan comunicarse de forma interna, sin importar si pertenecen al mismo proyecto o al mismo recurso de organización. El tráfico permanece dentro de la red de Google y no se desvía a la Internet pública.

El intercambio de tráfico entre redes de VPC requiere que las redes que intercambian tráfico no tengan direcciones IP superpuestas.

Seguridad de red

El bloque de seguridad de red se sitúa sobre el bloque de conectividad de red. Es responsable de permitir o denegar el acceso a los recursos según las características de los paquetes de IP.

Reglas de firewall de VPC

Las reglas de firewall de VPC se aplican a una red determinada. Las reglas de firewall de VPC permiten o rechazan las conexiones hacia o desde las instancias de VM según la configuración que especifiques. Las reglas de firewall de VPC habilitadas siempre se aplican, ya que protegen las instancias sin importar la configuración, el sistema operativo o si las VMs se iniciaron por completo.

Cada red de VPC funciona como un firewall distribuido. Aunque que las reglas de firewall se definen a nivel de red, las conexiones se permiten o deniegan por instancia. Se puede considerar que las reglas de firewall de VPC existen entre las instancias y otras redes y, también, entre instancias individuales dentro de la misma red.

Políticas jerárquicas de firewall

Las políticas de firewall jerárquicas te permiten crear y aplicar una política de firewall coherente en toda la empresa. Estas políticas contienen reglas que pueden rechazar o permitir las conexiones de forma explícita. Puedes asignar políticas de firewall jerárquicas a toda la organización o a carpetas individuales.

Duplicación de paquetes

La duplicación de paquetes clona el tráfico de instancias específicas en tu red de VPC y lo reenvía a colectores para su análisis. La duplicación de paquetes capta todo el tráfico y los datos de paquetes, incluidas las cargas útiles y los encabezados. Puedes configurar la duplicación para el tráfico de entrada y el de salida, solo el de entrada o solo el de salida. La duplicación ocurre en las instancias de VM, no en la red.

Dispositivo virtual de red

Los dispositivos virtuales de red te permiten aplicar controles de seguridad y cumplimiento a la red virtual que son coherentes con los controles del entorno local. Puedes hacerlo mediante la implementación de imágenes de VM disponibles en Google Cloud Marketplace en VMs que tengan varias interfaces de red, cada una conectada a una red de VPC diferente, para realizar una variedad de funciones virtuales de red.

Los casos de uso típicos para los dispositivos virtuales son los siguientes:

  • Firewalls de última generación (NGFW) Los NGFW consisten en un conjunto centralizado de firewalls que se ejecutan como VMs que entregan funciones que no están disponibles en las reglas de firewall de VPC. Las características típicas de los productos NGFW son la inspección profunda de paquetes (DPI) y la protección de firewall en la capa de la aplicación. Algunos NGFW también proporcionan una inspección de tráfico de TLS/SSL y otras funciones de red, como se describe más adelante en esta lista.
  • Sistema de detección de intrusiones/sistema de prevención de intrusiones (IDS/IPS). Un IDS basado en la red proporciona visibilidad del tráfico potencialmente malicioso. Para evitar intrusiones, los dispositivos IPS pueden bloquear el tráfico malicioso para que llegue a su destino.
  • Puerta de enlace web segura (SWG). Un SWG bloquea las amenazas de Internet, ya que permite que las empresas apliquen políticas corporativas en el tráfico que viaja hacia y desde Internet. Para ello, se usa el filtrado de URL, la detección de código malicioso y el control de acceso.
  • Puerta de enlace de traducción de dirección de red (NAT). Una puerta de enlace NAT traduce direcciones IP y puertos. Por ejemplo, esta traducción ayuda a evitar la superposición de direcciones IP. Google Cloud ofrece Cloud NAT como un servicio administrado, pero este servicio solo está disponible para el tráfico que va a Internet, no el tráfico que va a la ubicación local o a otras redes de VPC.
  • Firewall de aplicación web (WAF) Un WAF está diseñado para bloquear el tráfico HTTP(S) malicioso que se dirige a una aplicación web. Google Cloud ofrece la funcionalidad de WAF a través de las políticas de seguridad de Google Cloud Armor. La funcionalidad exacta difiere entre los proveedores de WAF, por lo que es importante determinar lo que necesitas.

IDS de Cloud

IDS de Cloud es un servicio de detección de intrusiones que proporciona detección de amenazas para intrusiones, software malicioso, software espía y ataques de comando y control en tu red. Cloud IDS funciona mediante la creación de una red de intercambio de tráfico administrada por Google que contiene VMs que recibirán tráfico duplicado. Luego, el tráfico duplicado se inspecciona mediante tecnologías de protección contra amenazas de Palo Alto Networks para proporcionar detección avanzada de amenazas.

IDS de Cloud proporciona visibilidad completa del tráfico dentro de las subredes, lo que te permite supervisar la comunicación de VM a VM y detectar movimientos laterales.

Cloud NAT

Cloud NAT proporciona compatibilidad con la traducción de direcciones de red definida por software completamente administrada para las aplicaciones. Habilita la traducción de direcciones de red de origen (NAT de origen o SNAT) para el tráfico orientado a Internet desde las VMs que no tienen direcciones IP externas.

Estadísticas de firewall

Estadísticas de firewall te ayuda a comprender y optimizar las reglas de firewall. Proporciona datos sobre cómo se usan las reglas de firewall, expone una configuración incorrecta y, además, identifica reglas que se pueden hacer más estrictas. También usa el aprendizaje automático para predecir el uso futuro de tus reglas de firewall a fin de que puedas tomar decisiones fundamentadas sobre si quitar o ajustar reglas que parecen ser demasiado permisivas.

Registro de red

Puedes usar varios productos de Google Cloud para registrar y analizar el tráfico de red.

El Registro de reglas de firewall te permite inspeccionar, verificar y analizar los efectos de tus reglas de firewall. Por ejemplo, puedes determinar si una regla de firewall diseñada para rechazar el tráfico funciona según lo previsto. El registro de reglas de firewall también es útil si necesitas determinar cuántas conexiones se ven afectadas por una regla de firewall determinada.

Habilita el registro de las reglas de firewall de forma individual para las reglas cuyas conexiones debas registrar. El registro de las reglas de firewall es una opción que se puede aplicar a cualquier regla de firewall, independientemente de la acción (permitir o denegar) o la dirección (entrada o salida) de la regla.

Los registros de flujo de VPC registran una muestra de flujos de red que envían y reciben las instancias de VM, incluidas las instancias que se usan como nodos de Google Kubernetes Engine (GKE). Estos registros se pueden usar para supervisar redes, detectar intrusiones, realizar análisis de seguridad en tiempo real y optimizar gastos.

Herramientas de redes de servicio

Los bloques de herramientas de redes de servicio son responsables de proporcionar servicios de búsqueda que indiquen a qué servicios debe dirigirse una solicitud (DNS, Directorio de servicios) y de enviar las solicitudes al lugar correcto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Se accede a las cargas de trabajo mediante nombres de dominio. Cloud DNS ofrece una traducción confiable y de baja latencia de los nombres de dominio a las direcciones IP que se encuentran en cualquier parte del mundo. En Cloud DNS, se ofrecen zonas públicas y zonas de DNS administradas privadas. Una zona pública es visible para la Internet pública, mientras que una zona privada solo es visible desde una o más redes de VPC especificadas.

Cloud Load Balancing

Dentro de Google Cloud, los Balanceadores de cargas son un componente crucial: enrutan el tráfico a varios servicios para garantizar velocidad y eficiencia, y ayudan a garantizar la seguridad global del tráfico interno y externo.

Nuestros balanceadores de cargas también permiten enrutar y escalar el tráfico entre varias nubes o entornos híbridos. Esto hace que Cloud Load Balancing sea la "puerta principal" mediante la cual se puede escalar cualquier aplicación sin importar dónde se encuentre o en cuántos lugares esté alojada. Google ofrece varios tipos de balanceo de cargas: global y regional, interno y externo, y de capa 4 y de capa 7.

Directorio de servicios

El Directorio de servicios te permite administrar tu inventario de servicios, lo que proporciona un único lugar seguro para publicar, descubrir y conectar servicios, todas las operaciones respaldadas por el control de acceso basado en la identidad. Te permite registrar servicios con nombre y sus extremos. El registro puede ser manual o mediante integraciones con Private Service Connect, GKE y Cloud Load Balancing. El descubrimiento de servicios es posible mediante las APIs de HTTP y gRPC explícitas, y con Cloud DNS.

Mallas de servicios: Anthos Service Mesh y Traffic Director

Anthos Service Mesh y Traffic Director están diseñados para facilitar la ejecución de aplicaciones distribuidas complejas mediante la habilitación de un amplio conjunto de políticas de administración y seguridad de tráfico en las arquitecturas de la malla de servicios. Las diferencias principales entre estos productos están en los entornos que admiten, en las APIs de Istio y en las capacidades de balanceo de cargas global.

Anthos Service Mesh es ideal para implementaciones regionales y globales basadas en Kubernetes, tanto en Google Cloud como en entornos locales, que se benefician de un producto administrado de Istio.

Traffic Director es ideal para casos de uso de herramientas de redes con servicios implementados a nivel global que reconocen el estado y la carga en Google Cloud. Traffic Director administra las cargas de trabajo mediante proxies de Envoy que actúan como sidecars o puertas de enlace, o mediante cargas de trabajo de gRPC sin proxy.

En la siguiente tabla, se resumen las funciones del Directorio de tráfico y Anthos Service Mesh.

Anthos Service Mesh Traffic Director
Tipo de implementación Kubernetes VM, Kubernetes
Entornos Google Cloud, entornos locales y múltiples nubes Google Cloud, entornos locales y múltiples nubes
Permiso de la implementación Regional y regional federada Global
Superficie de la API Istio Enrutamiento de servicio (modelo de puerta de enlace de Kubernetes)
Conectividad de red Sidecar de Envoy Sidecar de Envoy, gRPC sin proxy
Distribución de cargas global según el estado del backend Sí (basado en Kubernetes) Sí
Distribución de cargas global según la carga de backend No Sí
Identidad administrada para la carga de trabajo mTLS (confianza cero) Sí Sí (solo GKE)

Google explicó aún más sobre cómo compilar un entorno de arquitectura distribuida de confianza cero de extremo a extremo mediante la arquitectura BeyondProd. Además del perímetro de red y la autenticación y autorización del servicio, BeyondProd detalla cómo los entornos de procesamiento confiables, el origen del código y los lanzamientos de implementación cumplen una función en cuanto a lograr una arquitectura de servicio de confianza cero distribuida y segura. Debes considerar estos problemas que se extienden más allá de las herramientas de redes cuando adoptas un enfoque de confianza cero.

Private Service Connect

Private Service Connect crea abstracciones de servicios mediante la disponibilidad de cargas de trabajo en redes de VPC a través de un solo extremo. Esto permite que dos redes se comuniquen en un modelo cliente-servidor que exponga solo el servicio al consumidor en lugar de toda la red o la carga de trabajo. Un modelo de red orientado al servicio permite que los administradores de redes razonen sobre los servicios que exponen entre redes en lugar de subredes o VPC, lo que permite el consumo de los servicios en un modelo de productor y consumidor, ya sea para servicios de primera parte o de terceros (SaaS).

Con Private Service Connect, una VPC de consumidor puede usar una dirección IP privada para conectarse a una API de Google o a un servicio en otra VPC.

Puedes extender Private Service Connect a tu red local para acceder a los extremos que se conectan a las APIs de Google o a servicios administrados en otra red de VPC. Private Service Connect permite el consumo de servicios en la capa 4 o la capa 7.

En la capa 4, Private Service Connect requiere que el productor cree una o más subredes específicas de Private Service Connect. Estas subredes también se denominan subredes NAT. Private Service Connect realiza NAT de origen mediante una dirección IP que se selecciona de una de las subredes de Private Service Connect para enrutar las solicitudes a un productor de servicios. Este enfoque te permite usar direcciones IP superpuestas entre consumidores y productores.

En la capa 7, puedes crear un backend de Private Service Connect mediante un balanceador de cargas de aplicaciones interno. El balanceador de cargas de aplicaciones interno te permite elegir qué servicios están disponibles mediante un mapa de URL. Para obtener más información, consulta Acerca de los backends de Private Service Connect.

Acceso privado a servicios

El acceso privado a servicios es una conexión privada entre tu red de VPC y una red de Google o de terceros. Los socios que ofrecen servicios se conocen como productores de servicios. El acceso privado a los servicios usa el intercambio de tráfico entre redes de VPC para establecer la conectividad, y requiere que las redes de VPC del consumidor y del productor intercambian tráfico entre sí. Esto es diferente de Private Service Connect, que te permite proyectar una sola dirección IP privada en la subred.

La conexión privada permite que las instancias de VM en la red de VPC y los servicios a los que accedes se comuniquen de forma exclusiva mediante direcciones IP internas. Las instancias de VM no necesitan acceso a Internet o direcciones IP externas para alcanzar los servicios que están disponibles a través del acceso privado a los servicios. El acceso privado a los servicios también se puede extender a la red local mediante Cloud VPN o Cloud Interconnect para proporcionar un método para que los hosts locales alcancen la red del productor de servicios Para obtener una lista de los servicios administrados por Google que son compatibles con el acceso privado a los servicios, consulta Servicios compatibles en la documentación de la nube privada virtual.

Acceso a VPC sin servidores

El Acceso a VPC sin servidores te permite conectarte directamente a la red de VPC desde servicios alojados en entornos sin servidores, como Cloud Run, App Engine o Cloud Functions. La configuración del Acceso a VPC sin servidores permite que el entorno sin servidores envíe solicitudes a la red de VPC mediante DNS internos y direcciones IP internas. Las respuestas a estas solicitudes también usan tu red virtual.

El Acceso a VPC sin servidores envía tráfico interno desde tu red de VPC al entorno sin servidores solo cuando ese tráfico es una respuesta a una solicitud que se envió desde el entorno sin servidores a través del conector de acceso a VPC sin servidores.

El Acceso a VPC sin servidores tiene los siguientes beneficios:

  • Las solicitudes enviadas a tu red de VPC nunca se exponen a Internet.
  • La comunicación a través del Acceso a VPC sin servidores puede tener menos latencia en comparación con la comunicación a través de Internet.

Seguridad del servicio

Los bloques de seguridad del servicio controlan el acceso a los recursos según la identidad del solicitante o la comprensión de nivel superior de los patrones de paquetes en lugar de solo las características de un paquete individual.

Google Cloud Armor para DDoS/WAF

Google Cloud Armor es un servicio de mitigación de firewall de aplicación web (WAF) y denegación de servicio distribuido (DDoS) que te ayuda a defender tus aplicaciones y servicios web de varios tipos de amenazas. Estas amenazas incluyen ataques de DSD, ataques basados en la Web, como secuencias de comandos entre sitios (XSS) y la inyección de SQL (SQLi), y ataques basados en fraudes y automatizaciones.

Google Cloud Armor inspecciona las solicitudes entrantes en el extremo global de Google. Tiene un conjunto integrado de reglas de firewall de aplicaciones web para analizar.ataques web comunes y un avanzado Sistema de detección de ataques basado en el AA que compila un modelo de tráfico adecuado y, luego, detecta el tráfico incorrecto. Por último, Google Cloud Armor se integra en Google reCAPTCHA Enterprise para ayudar a detectar y detener ataques sofisticados de fraude y basados en la automatización mediante la telemetría de extremo y la telemetría de nube.

Identity Aware Proxy (IAP)

Identity-Aware Proxy (IAP) proporciona controles de acceso adaptado al contexto a las aplicaciones y VMs basadas en la nube que se ejecutan en Google Cloud o que se conectan a Google Cloud mediante el uso de cualquiera de las tecnologías de redes híbridas IAP verifica la identidad del usuario y determina si la solicitud del usuario se origina en fuentes confiables, según varios atributos contextuales. IAP también admite el uso de túneles TCP para el acceso SSH/RDP desde usuarios empresariales.

Controles del servicio de VPC

Los Controles del servicio de VPC te ayudan a mitigar el riesgo de robo de datos de los servicios de Google Cloud, como Cloud Storage y BigQuery. Usar los Controles del servicio de VPC ayuda a garantizar que el uso de los servicios de Google Cloud solo se realice desde entornos aprobados.

Puedes usar los Controles del servicio de VPC para crear perímetros que protejan los recursos y datos de los servicios que especifiques, ya que limitan el acceso a construcciones de identidad nativas de la nube, como las cuentas de servicio y las redes de VPC. Después de crear un perímetro, se rechaza el acceso a los servicios de Google especificados, a menos que la solicitud provenga del perímetro.

Publicación de contenido

Los bloques de entrega de contenido controlan la optimización de la entrega de aplicaciones y contenido.

Cloud CDN

Cloud CDN proporciona aceleración de contenido estático mediante la red perimetral global de Google para entregar contenido desde el punto más cercano al usuario. Esto ayuda a reducir la latencia de tus sitios web y aplicaciones.

Media CDN

Media CDN es la solución de entrega de contenido multimedia de Google y está diseñada para cargas de trabajo de salida de alta capacidad de procesamiento.

Observabilidad

Los bloques de observabilidad te brindan visibilidad de tu red y proporcionan estadísticas que se pueden usar para solucionar problemas, documentar, investigar.

Network Intelligence Center

Network Intelligence Center consta de varios productos que abordan varios aspectos de la observabilidad de la red. Cada producto tiene un enfoque diferente y proporciona estadísticas detalladas para informar a los administradores, arquitectos y profesionales sobre el estado y los problemas de red.

Arquitecturas de referencia

En los siguientes documentos, se presentan arquitecturas de referencia para diferentes tipos de cargas de trabajo: dentro de la nube, orientada a Internet e híbrida. Estas arquitecturas de cargas de trabajo se compilan en un plano de datos en la nube que se realiza mediante los componentes básicos y los patrones arquitectónicos que se describieron en las secciones anteriores de este documento.

Puedes usar las arquitecturas de referencia para diseñar formas de migrar o compilar cargas de trabajo en la nube. Luego, el plano de datos en la nube respalda las cargas de trabajo y usa las arquitecturas. Aunque estos documentos no proporcionan un conjunto exhaustivo de arquitecturas de referencia, sí abarcan las situaciones más comunes.

Al igual que con los patrones de arquitectura de seguridad que se describen en Arquitecturas para proteger los planos de datos en la nube, los servicios del mundo real pueden usar una combinación de estos diseños. En estos documentos, se analiza cada tipo de carga de trabajo y las consideraciones para cada arquitectura de seguridad.

¿Qué sigue?