Este documento forma parte de una serie en la que se describen las arquitecturas de redes y seguridad para las empresas que migran cargas de trabajo de centros de datos a Google Cloud.
La serie consiste en los siguientes documentos:
- Diseña redes para migrar cargas de trabajo empresariales: enfoques arquitectónicos
- Herramientas de redes para el acceso seguro dentro de la nube: Arquitecturas de referencia (este documento)
- Herramientas de redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia
- Herramientas de redes para cargas de trabajo de nubes híbridas y múltiples: arquitecturas de referencia
Las cargas de trabajo para casos de uso dentro de la nube residen en redes de VPC y necesitan conectarse a otros recursos en Google Cloud. Pueden consumir servicios que se proporcionan de forma nativa en la nube, como BigQuery. El perímetro de seguridad se proporciona mediante una variedad de capacidades propias (1P) y de terceros (3P), como firewalls, Controles del servicio de VPC y dispositivos virtuales de red.
En muchos casos, estas cargas de trabajo abarcan varias redes de VPC de Google Cloud, y los límites entre las redes de VPC deben protegerse. En este documento, se abordan estas arquitecturas de seguridad y conectividad en profundidad.
Arquitectura lift-and-shift
La primera situación para un caso de uso dentro de la nube es una arquitectura lift-and-shift en la que se mueven las cargas de trabajo establecidas a la nube tal como están.
Firewall
Puedes ayudar a establecer un perímetro seguro mediante la configuración de reglas de firewall.
Puedes usar etiquetas de red para aplicar reglas de firewall detalladas a una colección de VMs. Una etiqueta es un atributo arbitrario que se compone de una string de caracteres agregada al campo tags de la VM en el momento de la creación de la VM.
La VM también se puede asignar más adelante mediante la edición de la etiqueta. Para obtener pautas de implementación sobre cómo administrar el tráfico con reglas de firewall de Google Cloud, consulta Políticas de firewall de red en el plano de bases empresariales.
También puedes usar el registro de firewall para auditar y verificar los efectos de la configuración de la regla de firewall.
Puedes usar los registros de flujo de VPC para detectar intrusiones en la red y transmitir los registros a fin de integrarlos a SIEM. Este sistema general puede proporcionar supervisión en tiempo real, correlación de eventos, análisis y alertas de seguridad.
En la Figura 1, se muestra cómo las reglas de firewall pueden usar etiquetas de VM para restringir el tráfico entre las VMs de una red de VPC.
Figura 1. Configuración de firewall de red que usa etiquetas de red para aplicar un control de salida detallado.
Dispositivo virtual de red
Un dispositivo virtual de red (NVA) es una VM que tiene interfaces de red múltiples. El NVA te permite conectarte directamente a varias redes de VPC. Las funciones de seguridad como los firewalls de aplicaciones web (WAF) y los firewalls de nivel de aplicación de seguridad se pueden implementar en las VMs. Puedes usar los NVA a fin de implementar funciones de seguridad para el tráfico este-oeste, en especial cuando usas una configuración de radio y concentrador, como se muestra en la figura 2.
Para obtener lineamientos de implementación sobre cómo usar los NVA en Google Cloud, consulta Dispositivos de red centralizados en Google Cloud.
Figura 2. Configuración de dispositivos de red centralizados en una red de VPC compartida.
IDS de Cloud
El Sistema de detección de intrusiones de Cloud (IDS de Cloud) te permite implementar la inspección y el registro de seguridad nativos mediante la duplicación del tráfico desde una subred en tu red de VPC. Con el IDS de Cloud, puedes inspeccionar y supervisar una amplia variedad de amenazas a nivel de red y de aplicación para su análisis. Debes crear extremos del IDS de Cloud en tu red de VPC que está asociada con tu proyecto de Google Cloud. Estos extremos supervisan el tráfico de entrada y salida desde y hacia esa red, así como el tráfico de red dentro de la VPC, mediante la funcionalidad de duplicación de paquetes que está incorporada en la pila de herramientas de redes de Google Cloud. Debes habilitar el acceso privado a servicios para conectarte al proyecto del productor de servicios (el proyecto administrado por Google) que aloja los procesos del IDS de Cloud.
Si tienes una arquitectura de concentrador y radio, el tráfico de cada uno de los radios se puede duplicar en las instancias del IDS de Cloud, como se muestra en la figura 3.
Figura 3. Configuración del IDS de Cloud para duplicar el tráfico de VPC que usa el acceso de servicios privados.
El IDS de Cloud se puede proteger en el perímetro de servicio de los Controles del servicio de VPC mediante un paso adicional. Puedes obtener más información sobre la compatibilidad con los Controles del servicio de VPC en Productos compatibles.
Intercambio de tráfico entre redes de VPC
En el caso de las aplicaciones que abarcan varias redes de VPC, ya sea que pertenezcan al mismo proyecto de Google Cloud o al mismo recurso de la organización, el intercambio de tráfico entre redes de VPC permite la conectividad entre redes de VPC. Esta conectividad permite que el tráfico permanezca dentro de la red de Google para que no se desvíe a la Internet pública.
Hay dos modelos para usar el intercambio de tráfico entre redes de VPC en una arquitectura lift-and-shift. Uno es con una arquitectura de concentrador y radio “pura”, y el otro es en una arquitectura de concentrador y radio con transitividad, en la que el tráfico de un radio puede llegar a otro. En las siguientes secciones, se proporcionan detalles para usar el intercambio de tráfico entre redes de VPC con estas arquitecturas diferentes.
Arquitectura de concentrador y radio
Una arquitectura de concentrador y radio es un modelo popular para la conectividad de VPC que usa el intercambio de tráfico entre redes de VPC. Este modelo es útil cuando una empresa tiene varias aplicaciones que necesitan acceder a un conjunto común de servicios, como registros o autenticación. El modelo también es útil si la empresa necesita implementar un conjunto común de políticas de seguridad para el tráfico que sale de la red a través del concentrador. En un modelo de concentrador y radio puro, no se permite el intercambio de tráfico entre los radios (conocido como tráfico transitivo). En la Figura 4, se muestra una arquitectura de concentrador y radio pura que usa el intercambio de tráfico entre redes de VPC para conectar los radios al concentrador. Para conocer los lineamientos de implementación a fin de compilar redes de concentrador y radio, consulta Topología de red de concentradores y radios en el plano de bases empresariales.
Sin embargo, si no necesitas una separación a nivel de la VPC, puedes usar una arquitectura de VPC compartida, que puede proporcionar un modelo más simple para algunas empresas que recién comienzan en Google Cloud
Figura 4. Arquitectura de red de concentrador y radio que usa el intercambio de tráfico entre redes de VPC para el aislamiento de red y la conectividad no transitiva.
Concentrador y radio con transitividad
Para habilitar el concentrador y el radio con transitividad (el tráfico de un radio puede llegar a otros radios a través del concentrador), hay varios enfoques que usan el intercambio de tráfico entre redes de VPC. Puedes usar el intercambio de tráfico entre redes de VPC en una topología de malla completa, en la que cada red de VPC intercambia tráfico directamente con todas las demás redes de VPC a las que necesita llegar.
Como alternativa, puedes usar un NVA para conectar el concentrador y el radio. Luego, el NVA reside en balanceadores de cargas internos que se usan como el siguiente salto para el tráfico de los radios de VPC. En la Figura 5, se muestran ambas opciones.
Además, puedes usar VPN para conectarte entre el concentrador y las redes de VPC de radio. Esta disposición permite la accesibilidad entre conexiones de radios, lo que proporciona transitividad a través de la red de VPC del concentrador.
Figura 5. Configuración de red de concentrador y radio que usa Cloud VPN para el aislamiento de red y la conectividad transitiva.
VPC compartida
Puedes usar la VPC compartida para mantener un control centralizado sobre los recursos de red, como las subredes, las rutas y los firewalls en los proyectos host. Este nivel de control te permite implementar la práctica recomendada de seguridad de privilegio mínimo para la administración de la red, la auditoría y el control de acceso, ya que puedes delegar tareas de administración de red a administradores de red y seguridad. Puedes asignar la capacidad de crear y administrar VMs a los administradores de instancias mediante proyectos de servicio. El uso de un proyecto de servicio garantiza que los administradores de VM solo tengan la capacidad de crear y administrar instancias y que no se les permita realizar cambios en la red compartida que afecten a la red de VPC compartida.
Por ejemplo, puedes proporcionar más aislamiento si defines dos redes de VPC que se encuentran en dos proyectos host y adjuntas varios proyectos de servicio a cada red, uno para la producción y otro para las pruebas. En la Figura 6, se muestra una arquitectura que aísla un entorno de producción de un entorno de pruebas mediante proyectos independientes.
Para obtener más información sobre las prácticas recomendadas de compilación de redes de VPC, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.
Figura 6. Configuración de red de VPC compartida que usa varios proyectos de servicio y hosts aislados (entornos de prueba y producción).
Arquitectura de servicios híbridos
La arquitectura de servicios híbridos proporciona servicios adicionales nativos de la nube que están diseñados para permitirte conectar y proteger servicios en un entorno de varias VPC. Estos servicios nativos de la nube complementan lo que está disponible en la arquitectura lift-and-shift y pueden facilitar la administración de un entorno segmentado por VPC a gran escala.
Private Service Connect
Private Service Connect permite que un servicio alojado en una red de VPC aparezca en otra red de VPC. No es necesario que los servicios se alojen en el mismo recurso de la organización, por lo que se puede usar Private Service Connect para consumir de forma privada servicios de otra red de VPC, incluso si esta está conectada a otro recurso de la organización.
Puedes usar Private Service Connect de dos maneras: para acceder a las APIs de Google o para acceder a los servicios alojados en otras redes de VPC.
Configura Private Service Connect para acceder a las APIs de Google
Cuando usas Private Service Connect, puedes exponer las API de Google mediante un extremo de Private Service Connect que forma parte de la red de VPC, como se muestra en la figura 7.
Figura 7. Configuración de Private Service Connect para enviar tráfico a las APIs de Google con un extremo de Private Service Connect que es privado para tu red de VPC.
Las cargas de trabajo pueden enviar tráfico a un paquete de APIs de Google globales mediante un extremo de Private Service Connect. Además, puedes usar un backend de Private Service Connect para acceder a una sola API de Google, lo que extiende las funciones de seguridad de los balanceadores de cargas a los servicios de API. En la Figura 8, se muestra esta configuración.
Figura 8. Configuración de Private Service Connect para enviar tráfico a las API de Google con un backend de Private Service Connect.
Usa Private Service Connect entre redes de VPC o entidades
Private Service Connect también permite que un productor de servicios ofrezca servicios a un consumidor de servicios en otra red de VPC, ya sea en el mismo recurso de organización o en uno diferente. Una red de VPC de productor de servicios puede admitir varios consumidores de servicios. El consumidor puede conectarse al servicio del productor mediante el envío de tráfico a un extremo de Private Service Connect ubicado en la red de VPC del consumidor. El extremo reenvía el tráfico a la red de VPC que contiene el servicio publicado.
Figura 9. Configuración de Private Service Connect para publicar un servicio administrado a través de un adjunto de servicio y consumir el servicio a través de un extremo.
Conector de acceso a VPC sin servidores
Un conector de acceso a VPC sin servidores controla el tráfico entre el entorno sin servidores y la red de VPC. Cuando creas un conector en un proyecto de Google Cloud, debes conectarlo a una red de VPC y a una región específicas. Luego, puedes configurar tus servicios sin servidores para usar el conector en el tráfico de red saliente. Puedes especificar un conector con una subred o un rango de CIDR. El tráfico que se envió a través del conector a la red de VPC se origina desde la subred o el rango de CIDR que especificaste, como se muestra en la figura 10.
Figura 10. Configuración del conector de acceso a VPC sin servidores para acceder a entornos sin servidores de Google Cloud mediante direcciones IP internas dentro de la red de VPC.
Los conectores de acceso a VPC sin servidores son compatibles con todas las regiones que admiten Cloud Run, Cloud Functions o el entorno estándar de App Engine. Si deseas obtener más información, consulta la lista de servicios compatibles y protocolos de red compatibles para usar el conector de acceso a VPC sin servidores.
Controles del servicio de VPC
Los Controles del servicio de VPC te ayudan a evitar el robo de datos de servicios como Cloud Storage o BigQuery, ya que evitan los accesos autorizados desde Internet o desde proyectos que no forman parte de un perímetro de seguridad. Por ejemplo, imagina una situación en la que un error humano o una automatización incorrecta hacen que las políticas de IAM se establezcan de forma incorrecta en un servicio como Cloud Storage o BigQuery. Como resultado, los recursos de estos servicios se vuelven de acceso público. En ese caso, existe el riesgo de exposición de datos. Si tienes estos servicios configurados como parte del perímetro de los Controles del servicio de VPC, se bloquea el acceso de entrada a los recursos, incluso si las políticas de IAM permiten el acceso.
Los Controles del servicio de VPC pueden crear perímetros en función de los atributos del cliente, como el tipo de identidad (cuenta de servicio o usuario) y el origen de la red (dirección IP o red de VPC).
Los Controles del servicio de VPC ayudan a mitigar los siguientes riesgos de seguridad:
- Acceso desde redes no autorizadas que usan credenciales robadas.
- Robo de datos debido a usuarios maliciosos con información privilegiada o un código vulnerado.
- Exposición pública de datos privados debido a políticas de IAM mal configuradas
En la Figura 11, se muestra cómo los Controles del servicio de VPC te permiten establecer un perímetro de servicio para mitigar estos riesgos.
Figura 11. Perímetro de servicio de VPC extendido a entornos híbridos mediante servicios de acceso privado.
Mediante las reglas de entrada y salida, puedes habilitar la comunicación entre dos perímetros de servicio, como se muestra en la figura 12.
Figura 12. Configuración de las reglas de entrada y salida para comunicarse entre perímetros de servicio
Para obtener recomendaciones detalladas sobre las arquitecturas de implementación de Controles del servicio de VPC, consulta Diseña perímetros de servicio. Para obtener más información sobre la lista de servicios admitidos por los Controles del servicio de VPC, consulta Productos admitidos y limitaciones.
Arquitectura distribuida de confianza cero
Los controles de seguridad perimetral de la red son necesarios, pero no suficientes para admitir los principios de seguridad de privilegio mínimo y la defensa en profundidad. Las arquitecturas distribuidas de confianza cero se basan en el perímetro de la red para la aplicación de la seguridad, pero no solo dependen de él. Como arquitecturas distribuidas, están compuestas por microservicios con aplicación de la política de seguridad por servicio, autenticación sólida e identidad de la carga de trabajo.
Puedes implementar arquitecturas distribuidas de confianza cero como servicios administrados por Traffic Director y Anthos Service Mesh.
Traffic Director
Traffic Director se puede configurar para proporcionar una malla de microservicios de arquitectura distribuida de confianza cero dentro de un clúster de GKE mediante la seguridad de servicios. En este modelo, en los servicios de GKE que tienen archivos adicionales de Envoy o gRPC sin proxy, la identidad, los certificados y la política de autorización están administrados por Traffic Director, Workload Identity, Certificate Authority Service y también IAM. La plataforma proporciona la administración de certificados y la asignación de nombres seguros, y todas las comunicaciones de servicio están sujetas a la seguridad del transporte de mTLS. En la Figura 13, se muestra un clúster con esta configuración.
Figura 13. Malla de arquitectura distribuida de confianza cero de un solo clúster que usa Traffic Director.
Una política de autorización especifica cómo un servidor autoriza RPC o solicitudes entrantes. La política de autorización se puede configurar para permitir o rechazar una RPC o solicitud entrante según varios parámetros, como la identidad del cliente que envió la solicitud, el host, los encabezados y otros atributos HTTP. Hay lineamientos de implementación disponibles para configurar las políticas de autorización en mallas basadas en gRPC y Envoy.
En la Figura 13, la arquitectura tiene un solo clúster y redes planas (espacio de direcciones IP compartidas). Por lo general, se usan varios clústeres en la arquitectura distribuida de confianza cero para el aislamiento, la ubicación y el escalamiento.
En entornos más complejos, varios clústeres pueden compartir la identidad administrada cuando los clústeres se agrupan por flotas. En ese caso, puedes configurar la conectividad de red en redes de VPC independientes mediante Private Service Connect. Este enfoque es similar al enfoque de conectividad de redes de acceso de carga de trabajo de varios clústeres, como se describe más adelante en este documento.
Para obtener información sobre el control detallado de cómo se maneja el tráfico con Traffic Director, consulta Descripción general de la administración avanzada del tráfico.
Anthos Service Mesh
Anthos Service Mesh proporciona una malla de microservicios de arquitectura distribuida de confianza cero mTLS lista para usar que se basa en las bases de Istio. Configuras la malla con un flujo integrado. Anthos Service Mesh administrado, con datos administrados por Google y planos de control, se admite en GKE. También hay un plano de control en el clúster disponible, que es adecuado para otros entornos, como Google Distributed Cloud Virtualises o GKE Multi-Cloud. Anthos Service Mesh administra la identidad y los certificados, lo que proporciona un modelo de política de autorización basado en Istio.
Anthos Service Mesh se basa en flotas para administrar la identidad y la configuración de implementación del servicio de varios clústeres. Al igual que con Traffic Director, cuando tus cargas de trabajo operan en un entorno de conectividad de red de VPC plana (o compartida), no hay requisitos de conectividad de red especiales más allá de la configuración de firewall. Cuando la arquitectura incluye varios clústeres de Anthos Service Mesh en redes de VPC o entornos de red independientes, como en una conexión de Cloud Interconnect, también necesitas una puerta de enlace este-oeste. Las prácticas recomendadas de las herramientas de redes de Anthos Service Mesh son las mismas que se describen en Prácticas recomendadas para las herramientas de redes de GKE.
Anthos Service Mesh también se integra en Identity-Aware Proxy (IAP). IAP te permite configurar políticas de acceso detalladas para que puedas controlar el acceso de los usuarios a una carga de trabajo en función de los atributos de la solicitud de origen, como la identidad del usuario, la dirección IP y el tipo de dispositivo. Este nivel de control habilita un entorno de extremo a extremo de confianza cero.
Debes considerar los requisitos del clúster de GKE cuando usas Anthos Service Mesh. Para obtener más información, consulta la sección Requisitos en la documentación “Instalación de un solo proyecto en GKE”.
¿Qué sigue?
- Herramientas de redes para la entrega de aplicaciones orientadas a Internet: arquitecturas de referencia.
- Herramientas de redes para cargas de trabajo de nubes híbridas y múltiples: arquitecturas de referencia.
- La migración a Google Cloud puede ayudarte a planificar, diseñar y, luego, implementar el proceso de migración de tus cargas de trabajo en Google Cloud.
- El documento Diseño de zonas de destino en Google Cloud tiene orientación para crear una red de zona de destino.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.