En las siguientes secciones se explica cómo interactúa Cloud Armor con otras Google Cloud funciones y productos.
Reglas de cortafuegos de Cloud Armor y de VPC
Las políticas de seguridad de Cloud Armor y las reglas de cortafuegos de VPC tienen funciones diferentes:
- Las políticas de seguridad de Cloud Armor proporcionan seguridad perimetral y actúan sobre el tráfico de clientes a los front-ends de Google (GFEs).
- Las reglas de cortafuegos de VPC permiten o deniegan el tráfico hacia y desde tus back-ends. Debes crear reglas de firewall de entrada permitidas, cuyos destinos sean las VMs de backend con balanceo de carga y cuyas fuentes sean intervalos de IPs usados por balanceadores de carga de aplicación externos globales o balanceadores de carga de aplicación clásicos. Estas reglas permiten que los GFE y los sistemas de comprobación del estado se comuniquen con tus VMs de backend.
Por ejemplo, supongamos que quieres permitir que solo el tráfico de los intervalos CIDR 100.1.1.0/24 y 100.1.2.0/24 acceda a tu balanceador de carga de aplicación externo global o a tu balanceador de carga de aplicación clásico. Tu objetivo es bloquear el tráfico para que no llegue directamente a las instancias de backend balanceadas de carga. Es decir, solo el tráfico externo proxyizado a través del balanceador de carga de aplicación externo global o del balanceador de carga de aplicación clásico con una política de seguridad asociada puede llegar a las instancias.
En el diagrama anterior se muestra la siguiente configuración de implementación:
- Crea dos grupos de instancias, uno en la región
us-west1y otro en la regióneurope-west1. - Despliega instancias de la aplicación de backend en las VMs de los grupos de instancias.
- Crea un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico en el nivel Premium. Configura un mapa de URLs y un único servicio de backend cuyos backends sean los dos grupos de instancias que has creado en el paso anterior. La regla de reenvío del balanceador de carga debe usar la dirección IP externa
120.1.1.1. - Configura una política de seguridad de Cloud Armor que permita el tráfico de 100.1.1.0/24 y 100.1.2.0/24, y deniegue el resto del tráfico.
- Asocia esta política al servicio de backend del balanceador de carga. Para obtener instrucciones, consulta Configurar políticas de seguridad de Cloud Armor. Los balanceadores de carga HTTP(S) externos con mapas de URLs más complejos pueden hacer referencia a varios servicios de backend. Puedes asociar la política de seguridad a uno o varios de los servicios de backend según sea necesario.
- Configura reglas de cortafuegos de entrada para permitir el tráfico del balanceador de carga de aplicaciones externo global o del balanceador de carga de aplicaciones clásico. Para obtener más información, consulta Reglas de cortafuegos.
Cloud Armor con balanceadores de carga de aplicaciones externos e IAP
Identity-Aware Proxy (IAP) verifica la identidad de un usuario y, a continuación, determina si puede acceder a una aplicación. Para habilitar IAP en el balanceador de carga de aplicación externo global o en el balanceador de carga de aplicación clásico, usa los servicios de backend del balanceador de carga. Del mismo modo, las políticas de seguridad de Cloud Armor perimetrales se adjuntan a los servicios de backend de un balanceador de carga de aplicaciones externo global o de un balanceador de carga de aplicaciones clásico.
Si tanto las políticas de seguridad de Cloud Armor como IAP están habilitadas en un servicio de backend, el orden de su evaluación depende del tipo de balanceador de carga:
En el caso de un servicio de backend de un balanceador de carga de aplicación externo global, la evaluación de Cloud Armor se realiza primero. Si Cloud Armor bloquea una solicitud, IAP no la evalúa. Si Cloud Armor permite una solicitud, IAP la evalúa. La solicitud se bloquea si IAP no autentica la solicitud.
En el caso de un servicio de backend de un balanceador de carga de aplicaciones clásico, la evaluación de IAP se realiza primero. Si IAP autentica una solicitud, Cloud Armor la evalúa. Si una solicitud no supera la autenticación de IAP, Cloud Armor no la evalúa.
Para obtener más información sobre IAP y las configuraciones relacionadas, consulta la documentación de Identity-Aware Proxy.
Cloud Armor con despliegues híbridos
En una implementación híbrida, un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico necesita acceder a una aplicación o a una fuente de contenido que se ejecute fuera de Google Cloud, por ejemplo, en la infraestructura de otro proveedor de servicios en la nube. Puedes usar Cloud Armor para proteger estas implementaciones.
En el siguiente diagrama, el balanceador de carga tiene dos servicios de backend. Una tiene un grupo de instancias como backend. El otro servicio de backend tiene un NEG de Internet como backend, y el NEG de Internet está asociado a una aplicación que se ejecuta en el centro de datos de un proveedor externo.
Cuando asocias una política de seguridad de Cloud Armor al servicio de backend que tiene un NEG de Internet como backend, Cloud Armor inspecciona cada solicitud de capa 7 que llega al balanceador de carga de aplicaciones externo global o al balanceador de carga de aplicaciones clásico que esté destinado a ese servicio de backend.
La protección de Cloud Armor para los despliegues híbridos está sujeta a las mismas limitaciones que se aplican a los NEG de Internet.
Cloud Armor con Google Kubernetes Engine (GKE)
En las siguientes secciones se describe cómo funciona Cloud Armor con GKE.
Ingress de GKE
Después de configurar una política de seguridad de Cloud Armor, puedes usar Ingress de Kubernetes para habilitarla con GKE.
Puedes hacer referencia a tu política de seguridad con un recurso BackendConfig añadiendo el nombre de tu política de seguridad al BackendConfig. El siguiente manifiesto de
BackendConfig especifica una política de seguridad llamada
example-security-policy:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
namespace: cloud-armor-how-to
name: my-backendconfig
spec:
securityPolicy:
name: "example-security-policy"
Para obtener más información sobre las funciones de Ingress, consulta Configuración de Ingress.
GKE Gateway
Una vez que hayas configurado una política de seguridad de Cloud Armor, puedes usar la API Gateway de Kubernetes para habilitarla con GKE.
Puedes hacer referencia a tu política de seguridad añadiendo el nombre de tu política de seguridad a un recurso de política GCPBackendPolicy. El siguiente manifiesto de recursos de la política GCPBackendPolicy especifica una política de seguridad de backend llamada example-security-policy:
Servicio
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: ""
kind: Service
name: lb-service
Servicio de varios clústeres
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Para obtener más información sobre cómo configurar políticas de seguridad de backend de Cloud Armor, consulta el artículo Configurar una política de seguridad de backend de Cloud Armor para proteger tus servicios de backend.
Cloud Armor con Cloud CDN
Para proteger los servidores de origen de la CDN, puedes usar Cloud Armor con Cloud CDN. Cloud Armor protege el servidor de origen de tu CDN frente a ataques de aplicaciones, mitiga los riesgos de las 10 principales amenazas de OWASP y aplica políticas de filtrado de capa 7. Hay dos tipos de políticas de seguridad que afectan al modo en que Cloud Armor funciona con Cloud CDN: las políticas de seguridad perimetrales y las políticas de seguridad de backend.
Políticas de seguridad de Edge
Puedes usar políticas de seguridad perimetrales en los servicios de backend con Cloud CDN habilitado y en los segmentos de backend de Cloud Storage que estén detrás del balanceador de carga de aplicaciones externo global o del balanceador de carga de aplicaciones clásico. Usa políticas de seguridad perimetral para filtrar las solicitudes antes de que se sirva el contenido desde la caché.
Políticas de seguridad de backend
Cuando las políticas de seguridad de backend de Cloud Armor se aplican a servicios de backend con Cloud CDN habilitado, solo se aplican a las solicitudes dirigidas al servicio de backend. Estas solicitudes incluyen solicitudes de contenido dinámico y de datos que no están en caché, es decir, solicitudes que no se encuentran en la caché de Cloud CDN o que la omiten.
Cuando las políticas de seguridad perimetrales y las políticas de seguridad de backend se adjuntan al mismo servicio de backend, las políticas de seguridad de backend solo se aplican a las solicitudes de fallos de caché que hayan superado las políticas de seguridad perimetrales.
En el siguiente diagrama se muestra exclusivamente cómo funcionan las políticas de seguridad de backend con los orígenes de Cloud CDN después de que las políticas de seguridad de Edge hayan permitido las solicitudes.
Para obtener más información sobre Cloud CDN, consulta la documentación de Cloud CDN.
Cloud Armor con Cloud Run, App Engine o Cloud Run functions
Puede usar políticas de seguridad de Cloud Armor con un backend de NEG sin servidor que apunte a un servicio de Cloud Run, App Engine o Cloud Run functions.
Sin embargo, cuando usas Cloud Armor con NEGs sin servidor, Cloud Run o Cloud Run Functions, todo el acceso al endpoint sin servidor debe filtrarse a través de una política de seguridad de Cloud Armor.
Los usuarios que tengan la URL predeterminada de una aplicación sin servidor pueden saltarse el balanceador de carga e ir directamente a la URL del servicio. De esta forma, se omiten las políticas de seguridad de Cloud Armor. Para solucionar este problema, inhabilita la URL predeterminada que Google Cloud se asigna automáticamente a los servicios de Cloud Run o a las funciones de Cloud Run (2.ª gen.). Para proteger las aplicaciones de App Engine, puedes usar controles de acceso.
Si usas controles de entrada para aplicar tus controles de acceso a todo el tráfico entrante, puedes usar el ajuste de entrada internal-and-gclb al configurar funciones de Cloud Run o Cloud Run.
El ajuste de internal-and-gclb de Ingress solo permite el tráfico interno y el tráfico enviado a una dirección IP externa expuesta por el balanceador de carga de aplicaciones externo global o el balanceador de carga de aplicaciones clásico. El tráfico que se envía a estas URLs predeterminadas desde fuera de tu red privada se bloquea.
De esta forma, los usuarios no pueden eludir los controles de acceso (como las políticas de seguridad de Cloud Armor) configurados mediante el balanceador de carga de aplicación externo global o el balanceador de carga de aplicación clásico.
Para obtener más información sobre los NEGs sin servidor, consulta la descripción general de los grupos de puntos finales de red sin servidor y el artículo Configurar NEGs sin servidor.
Cloud Armor con Cloud Service Mesh
Puedes configurar políticas de seguridad de servicios internos para tu malla de servicios con el fin de aplicar límites de frecuencia globales del lado del servidor por cliente, lo que te ayudará a compartir de forma equitativa la capacidad disponible de tu servicio y a mitigar el riesgo de que los clientes maliciosos o que no se comporten correctamente sobrecarguen tus servicios. Puedes asociar una política de seguridad a una política de endpoints de Cloud Service Mesh para aplicar la limitación de frecuencia al tráfico entrante del lado del servidor. Sin embargo, no puedes configurar una política de seguridad de Google Cloud Armor si usas el enrutamiento de tráfico TCP. Para obtener más información sobre cómo usar Cloud Armor con Cloud Service Mesh, consulta el artículo Configurar la limitación de frecuencia con Cloud Armor.
Siguientes pasos
- Configurar políticas, reglas y expresiones de seguridad
- Información sobre las funciones de los niveles Enterprise de Cloud Armor
- Solucionar problemas