En esta página se muestran casos prácticos habituales de las políticas de seguridad de Google Cloud Armor. Las políticas de seguridad de Cloud Armor pueden proteger tu aplicación con funciones como listas de permitidos y de denegación de direcciones IP, así como reglas preconfiguradas para evitar ataques web habituales.
Controlar el acceso a tus aplicaciones y servicios web
En esta sección se describen varias formas de usar las políticas de seguridad de Cloud Armor para controlar el acceso a tus aplicaciones o servicios.
Habilitar el acceso para usuarios con direcciones IP específicas mediante listas de permitidos
Un caso de uso habitual para incluir direcciones IP de usuarios en una lista de permitidas es cuando solo un conjunto específico de usuarios accede a tu balanceador de carga de aplicación externo global o a tu balanceador de carga de aplicación clásico. En el siguiente ejemplo, solo los usuarios de tu organización pueden acceder a los servicios que hay detrás de tu balanceador de carga. Estos usuarios tienen direcciones IP o bloques de direcciones asignados por tu organización. Puede colocar estas direcciones IP o intervalos CIDR en una lista de permitidas para que solo estos usuarios tengan acceso al balanceador de carga.
Puedes controlar el acceso al balanceador de carga de aplicación externo global o al balanceador de carga de aplicación clásico configurando una lista de elementos permitidos con direcciones IP de origen o intervalos CIDR de origen desde los que se permite el acceso a tu balanceador de carga. En la siguiente sección se describe esta configuración con más detalle.
En esta configuración, solo quieres permitir que los usuarios de tu organización con direcciones IP de un intervalo de IPs accedan al balanceador de carga de aplicación externo global o al balanceador de carga de aplicación clásico. Quieres que se deniegue el resto del tráfico.
Para crear esta configuración, sigue estos pasos:
- Crea una política de seguridad de Cloud Armor.
- En la política de seguridad, añade una regla que añada el intervalo a la lista de permitidas
como primera regla. Esta regla tiene la descripción
allow [RANGE], donde[RANGE]es el intervalo de IP deseado. - Modifica la regla predeterminada de la política para que sea una regla de denegación en lugar de una de permiso. La regla predeterminada rige el tráfico que no coincide con ninguna de las reglas anteriores. Es la última regla de la política. Si cambia la regla de
allowadeny, se bloqueará todo el tráfico que no proceda del intervalo de la lista de permitidos. - Asocia esta política al balanceador de carga de aplicaciones externo global o al servicio de backend del balanceador de carga de aplicaciones clásico.
Si tu organización utiliza un proveedor de seguridad externo para depurar el tráfico, puedes añadir la dirección IP del proveedor de seguridad a una lista de permitidos para asegurarte de que solo el tráfico depurado pueda acceder al balanceador de carga de aplicaciones externo global o al balanceador de carga de aplicaciones clásico y a los backends.
En la siguiente ilustración, el proveedor externo se identifica mediante el intervalo CIDR 192.0.2.0/24, que está en una lista de permitidas.
Bloquear el acceso de los usuarios en direcciones IP específicas con listas de denegación
Usa listas de denegación para crear políticas de seguridad de Cloud Armor que rechacen el tráfico de una dirección IP o un intervalo CIDR. En la siguiente ilustración, la política de seguridad de Cloud Armor tiene una regla deny que bloquea el tráfico de la dirección IP 198.51.100.1, donde se ha identificado a un usuario malintencionado.
Reglas personalizadas para filtrar en función de los parámetros de las capas 3 a 7
Usa el lenguaje de reglas personalizadas de Cloud Armor para definir una o varias expresiones en la condición de coincidencia de una regla. Cuando Cloud Armor recibe una solicitud, la evalúa en función de estas expresiones. Si hay una coincidencia, se aplica la acción de la regla, que puede ser denegar o permitir el tráfico entrante.
Los siguientes ejemplos son expresiones escritas en la extensión de Cloud Armor del lenguaje de expresión común (CEL). Para obtener más información, consulte la referencia de lenguaje de reglas personalizadas.
Para definir expresiones en una regla, usa la marca --expression de gcloud o la consolaTrusted Cloud . Para obtener más información, consulta el artículo sobre cómo crear políticas, reglas y expresiones de seguridad de Cloud Armor.
En el siguiente ejemplo, las solicitudes de 2001:db8::/32 (como las de tus testers alfa) de la región AU coinciden con la siguiente expresión:
origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')
En el siguiente ejemplo, se buscan coincidencias con solicitudes de 192.0.2.0/24 y con un user-agent que contenga la cadena WordPress:
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
Para ver más ejemplos, consulta Expresiones de ejemplo en la referencia del lenguaje de reglas personalizadas.
Protege tu implementación frente a ataques de capa de aplicación y reduce los riesgos de los 10 principales de OWASP
Puedes usar Cloud Armor para proteger un servidor de origen de Cloud CDN frente a ataques de capa de aplicación (L7), como los de inyección de SQL (SQLi) y de cross-site scripting (XSS). El contenido de una caché es estático y, presumiblemente, no supone un riesgo de ataque dirigido desde la Web. Sin embargo, el servidor de origen del contenido subyacente puede ser una aplicación dinámica con vulnerabilidades conocidas o potenciales de aplicaciones web. Es posible que tus requisitos de seguridad o cumplimiento te obliguen a mitigar estos riesgos para evitar que se aprovechen vulnerabilidades de Internet para atacar correctamente el servidor de origen.
Para mitigar los riesgos, sigue estos pasos:
- Crea o identifica un servicio de backend con la CDN habilitada.
- Crea una política de seguridad de Cloud Armor.
- Crea una o varias reglas en la política de seguridad para denegar ataques de capa 7.
- Configure uno de los destinos de la política de seguridad para que sea el servicio de backend que ha creado o identificado en el paso 1.
También puedes usar reglas preconfiguradas para detectar y bloquear ataques comunes de la capa de aplicación. Las reglas preconfiguradas son conjuntos de expresiones predefinidos que puedes añadir a una política de seguridad de Cloud Armor. Para añadir estos conjuntos de expresiones a una regla, usa la marca --expression de gcloud o la consola Trusted Cloud .
Para obtener más información, consulta el artículo Crear políticas, reglas y expresiones de seguridad.
Una regla preconfigurada inspecciona de forma predeterminada los primeros 8 kB del cuerpo de una solicitud. Sin embargo, puedes configurar este límite por política. Para obtener más información sobre cómo configurar este límite de inspección para el cuerpo de una solicitud al usar reglas de WAF preconfiguradas, consulta Limitación de la inspección del cuerpo de las solicitudes POST y PATCH.
Para obtener más información sobre las reglas preconfiguradas, consulta Reglas preconfiguradas en la referencia del lenguaje de reglas personalizadas.
En el siguiente ejemplo, se usa una regla preconfigurada para mitigar los ataques de cross-site scripting (XSS):
evaluatePreconfiguredWaf('xss-stable')
En el siguiente ejemplo, se usa una regla preconfigurada para mitigar los ataques de inyección de SQL (SQLi):
evaluatePreconfiguredWaf('sqli-stable')
También puedes combinar reglas preconfiguradas con otras expresiones. En el siguiente ejemplo se usa una regla preconfigurada para mitigar los ataques SQLi del intervalo de direcciones IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')
Mitigación de los 10 principales riesgos de OWASP en cargas de trabajo híbridas
Cloud Armor ofrece mitigaciones para los siguientes ataques, tanto si se han desplegado en Trusted Cloud, en instalaciones locales o en un proveedor externo:
- Inyección de SQL (SQLi)
- Cross‑site scripting (XSS)
- Inclusión de archivos locales (LFI)
- Inclusión de archivos remotos (RFI)
- Ejecución remota de código (RCE)
Puede usar estas funciones para abordar algunos de los riesgos de seguridad de aplicaciones web más habituales, incluidos los que se identifican en la lista OWASP Top 10.
Las reglas de cortafuegos de aplicaciones web (WAF) preconfiguradas de Cloud Armor se pueden añadir a una política de seguridad para detectar y denegar solicitudes de capa 7 no deseadas que contengan intentos de inyección de SQL o de XSS. Cloud Armor detecta las solicitudes maliciosas y las rechaza en el perímetro de la infraestructura de Google. Las solicitudes no se envían al servicio de backend a través de un proxy, independientemente de dónde se haya implementado el servicio de backend.
Para proteger una carga de trabajo no alojada enTrusted Cloudfrente a estos ataques en el perímetro de la red de Google, sigue estos pasos:
- Configura un balanceador de carga de aplicaciones externo global o un balanceador de carga de aplicaciones clásico con un servicio de backend que tenga un NEG de Internet como backend.
- Crea una política de seguridad de Cloud Armor.
- Añade reglas de SQLi y XSS preconfiguradas a la política.
- Adjunta la política de seguridad al servicio de backend que has creado en el paso 1.
- Monitoriza la actividad de Cloud Armor mediante Cloud Logging, Cloud Monitoring y los resultados enviados a Security Command Center.
Controles de acceso de la capa 7 y ataques de invalidación de caché
En función de la arquitectura de la aplicación, puede configurar un servicio de backend para que responda a solicitudes de varias URLs, incluido contenido que se puede almacenar en caché y contenido que no. En estos casos, crea políticas de seguridad de Cloud Armor que denieguen el tráfico no deseado en determinadas rutas de solicitud, pero que permitan que todos los clientes accedan al contenido estático en otra ruta de solicitud.
En otras situaciones, aunque el contenido se sirva de forma eficiente desde la caché, un cliente malicioso o defectuoso puede generar un gran volumen de solicitudes que provoquen un fallo de caché y requieran que el servidor de origen subyacente obtenga o genere el contenido solicitado. Esto puede agotar los recursos limitados y tener un impacto negativo en la disponibilidad de la aplicación para todos los usuarios. Puedes crear una política de seguridad de Cloud Armor que coincida con la firma de los clientes que estén causando el problema y rechazar las solicitudes antes de que lleguen al servidor de origen y afecten al rendimiento.
Para ello, sigue estos pasos:
- Crea una política de seguridad de Cloud Armor.
Configura una regla. Por ejemplo, la siguiente regla deniega el acceso a
"/admin":request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')Adjunta la política de seguridad del paso 1 al servicio de backend que tenga Cloud CDN habilitado.
Siguientes pasos
- Configurar políticas de seguridad
- Información sobre el lenguaje de las reglas personalizadas
- Ajustar reglas de WAF