Se usó la API de Cloud Translation para traducir esta página.

Integra Google Cloud Armor con otros productos de Google

En las siguientes secciones, se analiza cómo interactúa Google Cloud Armor con otras funciones y productos de Google Cloud.

Reglas de firewall de VPC y Google Cloud Armor

Las políticas de seguridad de Google Cloud Armor y las reglas de firewall de VPC tienen funciones diferentes.

Las políticas de seguridad de Google Cloud Armor brindan seguridad perimetral y actúan sobre el tráfico de clientes en Google Front Ends (GFE).
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 objetivos sean las VM de backend con balanceo de cargas y cuyas fuentes sean rangos de IP que usan los balanceadores de cargas de aplicaciones externos globales o los 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 que solo el tráfico del rango CIDR 100.1.1.0/24 y el rango CIDR 100.1.2.0/24 acceda a tu balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico. Tu objetivo es garantizar que el tráfico no pueda alcanzar directamente a las instancias de balanceo de cargas de backend. En otras palabras, solo el tráfico externo dirigido por proxy a través del balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico con una política de seguridad asociada debe llegar a las instancias.

Uso de la política de seguridad de Google Cloud Armor con firewalls de entrada a fin de restringir el acceso — Uso de la política de seguridad de Google Cloud Armor con firewalls de entrada para restringir el acceso (haz clic para ampliar).

En la ilustración anterior, puedes lograr tus objetivos de seguridad mediante la configuración de la implementación de Google Cloud de la siguiente manera:

Crea dos grupos de instancias, uno en la región us-west1 y otro en la región europe-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 uno clásico en el nivel Premium. Configura un mapa de URL simple y un servicio de backend único cuyos backends sean los dos grupos de instancias que creaste en el paso anterior. Asegúrate de que la regla de reenvío del balanceador de cargas use la dirección IP externa 120.1.1.1.
Configura una política de seguridad de Google Cloud Armor que permita el tráfico desde 100.1.1.0/24 y 100.1.2.0/24 y deniegue 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. 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.

Google Cloud Armor con IAP y balanceadores de cargas de aplicaciones externos

Identity-Aware Proxy (IAP) verifica la identidad de un usuario y, luego, determina si se le debe permitir el acceso a una aplicación. Si quieres habilitar IAP para el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, debes habilitarlo en los servicios de backend del balanceador de cargas. Del mismo modo, las políticas de seguridad perimetral de Google 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 Google Cloud Armor están habilitados para un servicio de backend, el orden de la evaluación dependerá del tipo de balanceador de cargas:

Para un servicio de backend de un balanceador de cargas de aplicaciones externo global, primero se realiza la evaluación de Google Cloud Armor. Si Google Cloud Armor bloquea una solicitud, IAP no la evalúa. Si Google 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, Google Cloud Armor la evalúa. Si una solicitud falla en la autenticación de IAP, Google Cloud Armor no la evalúa.

Usa las listas de bloqueo de direcciones IP y las lista de anunciantes permitidos con IAP. — Usa listas de bloqueo de direcciones IP y listas de entidades permitidas con IAP (haz clic para ampliar).

Para obtener más información sobre IAP y las opciones de configuración relacionadas, consulta la documentación de Identity-Aware Proxy.

Google 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 Google 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 Google Cloud Armor al servicio de backend que tiene un NEG de Internet como backend, Google Cloud Armor inspecciona cada solicitud de L7 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 Google Cloud Armor para implementaciones híbridas está sujeta a las mismas limitaciones que se aplican a los NEG de Internet.

Entrada de Google Cloud Armor con Google Kubernetes Engine (GKE)

Después de configurar una política de seguridad de Google 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 características de Ingress, consulta Configura características de Ingress.

Google Cloud Armor con Cloud CDN

Para proteger los servidores de origen de CDN, puedes usar Google Cloud Armor con Cloud CDN. Google 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 Google 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 para Cloud CDN y los buckets de backend de Cloud Storage detrás del balanceador de cargas de aplicaciones externo global o el 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 Google 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.

Las solicitudes siempre se evalúan primero en función de las políticas de seguridad perimetral. En el caso de las solicitudes que las políticas de seguridad perimetral admiten, la solicitud se entrega al usuario y no se evalúa en función de la política de seguridad de backend. De lo contrario, la solicitud se vuelve a evaluar, esta vez con la política de seguridad de backend.

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.

Uso de las políticas de seguridad de backend de Google Cloud Armor con Cloud CDN. — Usa las políticas de seguridad de backend de Google Cloud Armor con Cloud CDN (haz clic para ampliar).

Para obtener más información sobre Cloud CDN, consulta la documentación de Cloud CDN.

Google Cloud Armor con Cloud Run, App Engine o Cloud Functions

Puedes usar las políticas de seguridad de Google Cloud Armor con un backend de NEG sin servidores que apunte a un servicio Cloud Run , App Engine o Cloud Functions.

Sin embargo, cuando usas Google Cloud Armor con NEG sin servidores, Cloud Run o Cloud Functions, debes seguir pasos especiales para asegurarte de que todo el acceso al extremo sin servidores se filtre por una política de seguridad de Google 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. Así se omiten las políticas de seguridad de Google Cloud Armor. Además, no puedes inhabilitar las URLs que Google Cloud asigna de forma automática a los servicios de Cloud Run o Cloud Functions. Para proteger estas aplicaciones, puedes usar los controles de entrada de App Engine o los controles de entrada de Cloud Run.

Para asegurarte de que los controles de acceso se apliquen a todo el tráfico entrante, puedes usar internal-and-gclb cuando configures Cloud Functions o Cloud Run. Esto 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. El tráfico enviado a cloudfunctions.net o a cualquier otro dominio personalizado configurado a través de Cloud Functions se bloquea. Esto evita que los usuarios eludan los controles de acceso (como las políticas de seguridad de Google 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.