En este documento, se describen los casos de uso comunes de las políticas de seguridad de Google Cloud Armor. Las políticas de seguridad de Cloud Armor ayudan a proteger tu aplicación con listas de anunciantes permitidos y de bloqueo de direcciones IP, y reglas preconfiguradas que disuaden los ataques web comunes.
Disponibilidad de las características
En la siguiente tabla, se resume la disponibilidad de las funciones de Cloud Armor según tu nivel de suscripción y el tipo de balanceador de cargas o extremo que proteges.
| Función | Cloud Armor Standard | Cloud Armor Enterprise | Extremos compatibles |
|---|---|---|---|
| Protección contra DDoS volumétricos | Incluido | Incluido | Todos los balanceadores de cargas externos, Cloud CDN y Media CDN |
| Reglas de IP permitidas o bloqueadas | Incluido | Incluido | Balanceador de cargas de aplicaciones externo, balanceador de cargas de red de proxy externo |
| Reglas de WAF preconfiguradas | Incluido | Incluido | Balanceador de cargas de aplicaciones externo, balanceador de cargas de red de proxy externo |
| Reglas de CEL personalizadas | Incluido | Incluido | Balanceador de cargas de aplicaciones externo, balanceador de cargas de red de proxy externo |
| Protección Adaptativa | Solo alertas | Protección completa | Balanceador de cargas de aplicaciones externo |
| Administración de bots | No disponible | Incluido | Balanceador de cargas de aplicaciones externo |
| Protección avanzada contra DSD de red | No disponible | Incluido | Balanceador de cargas de red de transferencia externo, reenvío de protocolos y VM con IP pública |
| Políticas de seguridad perimetral de red | No disponible | Incluido | Balanceador de cargas de red de transferencia externo, reenvío de protocolos y VM con IP pública |
| Inteligencia contra amenazas | No disponible | Incluido | Balanceador de cargas de aplicaciones externo, balanceador de cargas de red de proxy externo |
Ejemplos de políticas de seguridad
En esta sección, se describe cómo usar las políticas de seguridad de Cloud Armor para controlar el acceso a tus aplicaciones o servicios.
Habilita el acceso para los usuarios en direcciones IP específicas con listas de anunciantes permitidos
Usa una lista de direcciones IP permitidas para limitar las solicitudes a direcciones IP o rangos de CIDR específicos, como las IPs públicas de tus sucursales. Solo puedes permitir el tráfico que se origina en esos rangos especificados.
Controla el acceso al balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico configurando una lista de direcciones IP o rangos de CIDR de clientes permitidos. En la siguiente sección, se describe esta configuración.
En esta configuración, solo permites que las solicitudes de direcciones IP de clientes en un rango específico accedan al balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico. Deseas rechazar todo 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, agrega una regla que incluya el rango a la lista de entidades permitidas.
Esta regla tiene la descripción
allow [RANGE], en la que[RANGE]es el rango de IP deseado. - Cambia la regla predeterminada en la política de una regla de permiso a una regla de denegación. La regla predeterminada es la última regla de la política y rige el tráfico que no coincide con ninguna de las reglas anteriores. Si cambias esta regla a
deny, se bloqueará todo el tráfico que no esté en el rango de la lista de anunciantes permitidos. - Asocia esta política con el balanceador de cargas de aplicaciones externo global o el servicio de backend del balanceador de cargas de aplicaciones clásico.
Si tu organización usa un proveedor de seguridad externo para depurar el tráfico, puedes agregar la dirección IP del proveedor de seguridad a una lista de anunciantes permitidos a fin de garantizar que solo el tráfico que se depuró pueda acceder al balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico y a los backends.
En la siguiente ilustración, el proveedor externo se identifica con el rango de CIDR 192.0.2.0/24, y este rango está en una lista de anunciantes permitidos.
Bloquea el acceso de los usuarios en direcciones IP específicas con listas de bloqueo
Usa listas de denegación para rechazar el tráfico de direcciones IP o rangos CIDR específicos.
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, en la que se identificó a un usuario malicioso.
Reglas personalizadas para filtrar en función de los parámetros de la capa 3 a la capa 7
Define expresiones en la condición de coincidencia de una regla con el lenguaje de reglas personalizadas de Cloud Armor. Cloud Armor evalúa las solicitudes entrantes en función de estas expresiones. Si una solicitud coincide, se aplica la acción de la regla, ya sea que se deniegue o se permita el tráfico.
Los siguientes ejemplos son expresiones escritas en la extensión de Cloud Armor del Common Expression Language (CEL). Para obtener más información, consulta la referencia del lenguaje de reglas personalizadas.
Define expresiones con la marca --expression de Google Cloud CLI o la consola deGoogle Cloud . Para obtener más información, consulta Crea reglas, expresiones y políticas de seguridad.
En el siguiente ejemplo, las solicitudes de 2001:db8::/32 (como tus verificadores Alfa) en la región AU coinciden con la siguiente expresión:
origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')
El siguiente ejemplo coincide con las solicitudes de 192.0.2.0/24 y con un usuario-agente que contiene la string WordPress:
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
Para obtener ejemplos adicionales, consulta Expresiones de ejemplo en la referencia del lenguaje de reglas personalizadas.
Protege tu implementación contra ataques de la capa de la aplicación y ayuda a mitigar los 10 riesgos principales de OWASP
Cloud Armor ayuda a proteger los servidores de origen de Cloud CDN de los ataques de la capa de la aplicación (L7), como la inyección de SQL (SQLi) y las secuencia de comandos entre sitios (XSS). El contenido de la caché es estático y, por lo general, no implica un riesgo de un ataque orientado. Sin embargo, el servidor de origen puede ser una aplicación dinámica con vulnerabilidades. Es posible que tus requisitos de seguridad exijan que mitigues estos riesgos para evitar que los exploits ataquen el servidor de origen.
Para mitigar los riesgos, sigue estos pasos:
- Crea o identifica un servicio de backend con CDN habilitado.
- Crea una política de seguridad de Cloud Armor.
- Crea una o más reglas en la política de seguridad para denegar los ataques de L7.
- Configura uno de los objetivos de la política de seguridad para que sea el servicio de backend que creaste o identificaste en el paso 1.
Usa reglas preconfiguradas para detectar y bloquear ataques comunes de la capa de la aplicación.
Las reglas preconfiguradas son conjuntos de expresiones predefinidas que puedes agregar a una política de seguridad. Para agregar estos conjuntos de expresiones a una regla, usa la marca --expression o la Google Cloud consola de gcloud CLI.
Para obtener más información, consulta Crea reglas, expresiones y políticas de seguridad.
De forma predeterminada, una regla preconfigurada inspecciona hasta los primeros 8 KB de un cuerpo de 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 cuando se usan reglas de WAF preconfiguradas, consulta Limitación de inspección del cuerpo de la solicitud.
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 secuencias de comandos entre sitios (XSS):
evaluatePreconfiguredWaf('xss-v422-stable')
En el siguiente ejemplo, se usa una regla preconfigurada para mitigar los ataques de inserción de SQL (SQLi):
evaluatePreconfiguredWaf('sqli-v422-stable')
También puedes combinar reglas preconfiguradas con otras expresiones. En el siguiente ejemplo, se usa una regla preconfigurada para mitigar los ataques de SQLi del rango de direcciones IP 192.0.2.1/24:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-v422-stable')
Las 10 mejores mitigaciones de OWASP para cargas de trabajo híbridas
Cloud Armor ofrece mitigaciones para los siguientes ataques, ya sea que se implementen en Google Cloud, de manera local o en un proveedor externo:
- Inserción de SQL (SQLi)
- Secuencia de comandos entre sitios (XSS)
- Inclusión de archivos locales (LFI)
- Inclusión de archivos remotos (RFI)
- Ejecución de código remoto (RCE)
Puedes usar estas capacidades para abordar algunos de los riesgos de seguridad de aplicaciones web más comunes, incluidos los riesgos identificados en la lista Los 10 riesgos principales de OWASP.
Agrega reglas de WAF preconfiguradas a una política de seguridad para detectar y rechazar solicitudes no deseadas de capa 7, como intentos de SQLi o XSS. Cloud Armor detecta y descarta las solicitudes maliciosas en el perímetro de la infraestructura de Google. Las solicitudes no se envían mediante proxy al servicio de backend, sin importar dónde se implemente.
Para proteger una carga de trabajo que no está alojada enGoogle Cloudde estos ataques en el perímetro de la red de Google, sigue estos pasos:
- Configura un balanceador de cargas de aplicaciones externo global o un balanceador de cargas 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.
- Agrega reglas de SQLi y XSS a la política.
- Vincula la política de seguridad al servicio de backend que creaste en el paso 1.
- Supervisa la actividad de Cloud Armor con Cloud Logging, Cloud Monitoring y los hallazgos enviados a Security Command Center.
Protección contra DSD de servidores de origen externo y supervisión de la capa 7 en Cloud CDN
Las implementaciones de Cloud CDN con un servidor de origen externo pueden tener la infraestructura perimetral de Google como frontend para el envío mediante proxy, el almacenamiento en caché y el filtrado de capa 7 de Cloud Armor. Con los NEG de Internet, el servidor de origen se puede ubicar de forma local o con un proveedor de infraestructura externo.
Cloud Armor y la infraestructura perimetral de Google mitigan los ataques de L3 y L4, te alertan sobre la actividad sospechosa de la capa 7 y rechazan las solicitudes no deseadas de la capa 7 con reglas personalizadas. La telemetría y el registro de Cloud Armor en Cloud Logging, Cloud Monitoring y Security Command Center proporcionan estadísticas prácticas para las aplicaciones protegidas independientemente de dónde se implementen.
Si quieres habilitar la protección de Cloud Armor para los servidores de orígenes externos de CDN, sigue estos pasos:
- Configura un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico con un servicio de backend que tenga un NEG de Internet como backend.
- Habilita Cloud CDN para este servicio de backend.
- Crea una política de seguridad de Cloud Armor.
- Vincula la política de seguridad al servicio de backend que creaste en el paso 1.
- Accede a las alertas, los registros y la telemetría de Cloud Armor en Security Command Center, Cloud Logging y Cloud Monitoring.
Además, puedes usar políticas de seguridad perimetral para proteger el contenido almacenado en la caché. Para obtener más información sobre las políticas de seguridad perimetral, consulta la Descripción general de la política de seguridad.
Controles de acceso a la capa 7 y ataques de eliminación de caché
Según la arquitectura de la aplicación, puedes configurar un servicio de backend con el fin de que entregue solicitudes para diversas URL, incluido el contenido que puede almacenarse en caché y el que no. En esas situaciones de implementación, crea políticas de seguridad de Cloud Armor que rechacen el tráfico no deseado en ciertas rutas de solicitud, pero que permitan que todos los clientes accedan al contenido estático en una ruta de solicitud diferente.
En otras situaciones, a pesar de que el contenido se entrega desde la caché, un cliente malicioso puede generar muchas solicitudes que dan como resultado un error de caché. Un error de caché requiere que el servidor de origen recupere o genere el contenido, lo que puede sobrecargar los recursos y afectar la disponibilidad. Crea una política de seguridad para que coincida con las firmas de los clientes que causan el problema y rechaza las solicitudes antes de que lleguen al servidor de origen.
Para lograrlo, 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>')Vincula la política de seguridad del paso 1 al servicio de backend que tiene habilitado Cloud CDN.
Protección del balanceador de cargas de red de transferencia externo
Si tienes una suscripción a Cloud Armor Enterprise, puedes usar la protección contra DDoS de red avanzada para proteger tus balanceadores de cargas de red externos de transferencia, el reenvío de protocolos y las VMs con direcciones IP públicas. Esta función proporciona mitigación en línea y siempre activa de ataques DSD L3 y L4.
Para obtener más información, consulta Descripción general de la protección avanzada contra DDoS de red.
¿Qué sigue?
- Configura políticas de seguridad
- Obtén información sobre el lenguaje de las reglas personalizadas
- Ajusta las reglas de WAF