En las siguientes secciones, se analiza cómo interactúa Cloud Armor con otras Google Cloud funciones y productos.
Reglas de firewall de Cloud Armor y de VPC
Las políticas de seguridad de Cloud Armor y las reglas de firewall de VPC tienen funciones diferentes:
- Las políticas de seguridad de Cloud Armor brindan seguridad perimetral y actúan sobre el tráfico de clientes en Google Front Ends (GFEs).
- Las reglas de firewall de VPC permiten o deniegan el tráfico hacia y desde tus backends. Debes crear reglas de firewall de permiso de entrada, cuyos destinos sean las VMs de backend con balanceo de cargas y cuyas fuentes sean rangos de IP usados por balanceadores de cargas de aplicaciones externos globales o balanceadores de cargas de aplicaciones clásicos. Estas reglas permiten que los GFE y los sistemas de verificación de estado se comuniquen con tus VM de backend.
Por ejemplo, considera una situación en la que deseas permitir el tráfico solo del rango de CIDR 100.1.1.0/24 y el rango de 100.1.2.0/24 para acceder a tu balanceador de cargas de aplicaciones externo global o tu balanceador de cargas de aplicaciones clásico. Tu objetivo es bloquear el tráfico para que no llegue directamente a las instancias de balanceo de cargas de backend. En otras palabras, solo el tráfico externo que se procesa a través del balanceador de cargas de aplicaciones externo global o del balanceador de cargas de aplicaciones 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. - Implementa instancias de aplicaciones de backend en las VM de los grupos de instancias.
- Crea un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico en el nivel Premium. Configura un mapa de URL y un servicio de backend único cuyos backends sean los dos grupos de instancias que creaste en el paso anterior. La regla de reenvío del balanceador de cargas 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 desde 100.1.1.0/24 y 100.1.2.0/24, y rechace todo el resto del tráfico.
- Asocia esta política con el servicio de backend del balanceador de cargas. Para obtener instrucciones, consulta Configura políticas de seguridad de Cloud Armor. Los balanceadores de cargas de HTTP(S) externos con mapas de URL más complejos pueden hacer referencia a varios servicios de backend. Puedes asociar la política de seguridad con uno o más de los servicios de backend, según sea necesario.
- Configura las reglas de firewall de permiso de entrada para permitir el tráfico desde el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico. Para obtener más información, consulta las Reglas de firewall.
Cloud Armor con balanceadores de cargas de aplicaciones externos y IAP
Identity-Aware Proxy (IAP) verifica la identidad de un usuario y, luego, determina si puede acceder a una aplicación. Para habilitar IAP para el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, usa los servicios de backend del balanceador de cargas. Del mismo modo, las políticas de seguridad perimetral de Cloud Armor se vinculan a los servicios de backend de un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico.
Si IAP y las políticas de seguridad de Cloud Armor están habilitadas para un servicio de backend, el orden de su evaluación depende del tipo de balanceador de cargas:
En el caso de un servicio de backend de un balanceador de cargas de aplicaciones externo global, primero se realiza la evaluación de Cloud Armor. 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 la autentica.
Para un servicio de backend de un balanceador de cargas de aplicaciones clásico, primero se realiza la evaluación de IAP. 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 opciones de configuración relacionadas, consulta la documentación de Identity-Aware Proxy.
Cloud Armor con implementaciones híbridas
En una implementación híbrida, un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico necesita acceso a una aplicación o fuente de contenido que se ejecuta fuera de Google Cloud, por ejemplo, en la infraestructura de otro proveedor de servicios en la nube. Puedes usar Cloud Armor para proteger esas implementaciones.
En el siguiente diagrama, el balanceador de cargas tiene dos servicios de backend. Uno 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 con una aplicación que se ejecuta en el centro de datos de un proveedor externo.
Cuando adjuntas 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 cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico que está destinado a ese servicio de backend.
La protección de Cloud Armor para implementaciones híbridas 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.
Para hacer referencia a tu política de seguridad con un recurso BackendConfig, agrega el nombre de tu política de seguridad a BackendConfig. En el siguiente manifiesto de BackendConfig, se 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.
Puerta de enlace de GKE
Después de configurar una política de seguridad de Cloud Armor, puedes usar la API de Gateway de Kubernetes para habilitarla con GKE.
Para hacer referencia a tu política de seguridad, agrega el nombre de tu política de seguridad a un recurso de política GCPBackendPolicy. En el siguiente manifiesto del recurso de política GCPBackendPolicy, se 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 la configuración de las políticas de seguridad de backend de Cloud Armor, consulta Configura la 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 CDN, puedes usar Cloud Armor con Cloud CDN. Cloud Armor protege tu servidor de origen de CDN de los ataques de las aplicaciones, mitiga los 10 riesgos principales de OWASP y aplica las políticas de filtrado de la capa 7. Existen dos tipos de políticas de seguridad que afectan cómo funciona Cloud Armor con Cloud CDN: las políticas de seguridad perimetral y las políticas de seguridad de backend.
Políticas de seguridad perimetral
Puedes usar políticas de seguridad perimetral para los servicios de backend habilitados de Cloud CDN y los buckets de backend de Cloud Storage detrás del balanceador de cargas de aplicaciones externo global o del balanceador de cargas de aplicaciones clásico. Usa las políticas de seguridad perimetral para filtrar las solicitudes antes de que el contenido se entregue desde la caché.
Políticas de seguridad de backend
Cuando las políticas de seguridad de backend de Cloud Armor se aplican a los servicios de backend con Cloud CDN habilitado, solo se aplican a las solicitudes enrutadas al servicio de backend. Estas solicitudes incluyen solicitudes de contenido dinámico y errores de caché, es decir, solicitudes que omiten la caché de Cloud CDN.
Cuando las políticas de seguridad perimetral y de backend se vinculan al mismo servicio de backend, las políticas de seguridad de backend solo se aplican a las solicitudes de error de caché que pasaron las políticas de seguridad perimetral.
En el siguiente diagrama, se muestra de forma exclusiva 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 perimetral permiten 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
Puedes usar las políticas de seguridad de Cloud Armor con un backend de NEG sin servidores que apunte a un servicio de Cloud Run, App Engine o Cloud Run Functions.
Sin embargo, cuando usas Cloud Armor con NEG sin servidores, Cloud Run o Cloud Run Functions, todo el acceso al extremo sin servidores debe filtrarse a través de una política de seguridad de Cloud Armor.
Los usuarios que tienen la URL predeterminada para una aplicación sin servidores pueden omitir el balanceador de cargas y dirigirse directamente a la URL del servicio. Con esta acción, se omiten las políticas de seguridad de Cloud Armor. Para solucionar este problema, inhabilita la URL predeterminada que Google Cloud asigna automáticamente a los servicios de Cloud Run o a las funciones de Cloud Run Functions (2ª gen.). Para proteger las aplicaciones de App Engine, puedes usar los controles de entrada.
Si usas controles de entrada para aplicar tus controles de acceso a todo el tráfico entrante, puedes usar el parámetro de configuración de entrada internal-and-gclb cuando configures Cloud Run Functions o Cloud Run.
El parámetro de configuración de entrada internal-and-gclb solo permite el tráfico interno y el tráfico enviado a una dirección IP externa expuesta por el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico. Se bloquea el tráfico que se envía a estas URLs predeterminadas desde fuera de tu red privada.
Esto evita que los usuarios eludan los controles de acceso (como las políticas de seguridad de Cloud Armor) configurados a través del balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico.
Para obtener más información sobre los NEG sin servidores, consulta Descripción general de los grupos de extremos de redes sin servidores y Configura NEG sin servidores.
Cloud Armor con Cloud Service Mesh
Puedes configurar políticas de seguridad de servicios internos para tu malla de servicios y aplicar límite de frecuencia globales del servidor por cliente, lo que te ayudará a compartir de manera equitativa la capacidad disponible de tu servicio y mitigar el riesgo de que los clientes maliciosos o con comportamiento inadecuado sobrecarguen tus servicios. Adjuntas una política de seguridad a una política de extremo de Cloud Service Mesh para aplicar límite de frecuencia al tráfico entrante en el 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 el uso de Cloud Armor con Cloud Service Mesh, consulta Configura el límite de frecuencia con Cloud Armor.
¿Qué sigue?
- Configura, reglas, expresiones y políticas de seguridad
- Más información sobre las funciones de los niveles de Cloud Armor Enterprise
- Soluciona problemas