En esta página, se detallan los casos de uso comunes para las políticas de seguridad de Google Cloud Armor. Las políticas de seguridad de Google Cloud Armor pueden proteger tu aplicación con características como las listas de anunciantes permitidos y de bloqueo de direcciones IP, y las reglas preconfiguradas para disuadir los ataques web comunes.
Controla el acceso a tus aplicaciones y servicios web
En esta sección, se presentan varias formas de usar las políticas de seguridad de Google 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
Un caso de uso típico para ubicar direcciones IP de usuarios en una lista de entidades permitidas es cuando tus al balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico a un conjunto específico de usuarios. En el siguiente ejemplo, solo los usuarios de tu organización tienen acceso a los servicios detrás del balanceador de cargas. Estos usuarios tienen direcciones IP o bloques de direcciones asignados por la organización. Puedes ubicar estos rangos de CIDR o direcciones IP en una lista de admisión para que solo estos usuarios tengan acceso al balanceador de cargas.
Para controlar el acceso al balanceador de cargas de aplicaciones externo global o al balanceador de cargas de aplicaciones clásico, configura una lista de direcciones IP o rangos de CIDR de origen permitidos desde los que se permita el acceso a tu balanceador de cargas. En la siguiente sección, se describe con más detalle esta configuración.
En esta configuración, solo quieres permitir que los usuarios de tu organización tengan direcciones IP de un rango de IP para acceder al balanceador de cargas de aplicaciones externo global 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 Google Cloud Armor.
- En la política de seguridad, agrega una regla que incluya el rango a la lista de permisos como la primera regla. Esta regla tiene la descripción
allow [RANGE], en la que[RANGE]es el rango de IP deseado. - Modifica la regla predeterminada en la política de una regla de permiso a una regla de denegación. La regla predeterminada rige el tráfico que no coincide con ninguna de las reglas anteriores. Es la última regla de la política. Cambiar la regla de
allowadenybloquea todo el tráfico que no se origina en el rango en la lista de anunciantes permitidos. - Asocia esta política al balanceador de cargas de aplicaciones externo global o al 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 entidades permitidas para garantizar que solo el tráfico depurado 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 mediante 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 crear políticas de seguridad de Google Cloud Armor que rechacen el tráfico de una dirección IP o un rango CIDR. En la siguiente ilustración, la política de seguridad de Google 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
Usa el lenguaje de reglas personalizadas de Google Cloud Armor para definir una o más expresiones en la condición de coincidencia de una regla. Cuando Google 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, ya sea que se deniegue o se permita el tráfico entrante.
Los siguientes ejemplos son expresiones escritas en la extensión de Google Cloud Armor del Common Expression Language (CEL). Para obtener más información, consulta la referencia del lenguaje de reglas personalizadas.
Para definir expresiones en una regla, usa la marca de gcloud --expression o la consola de Google Cloud. Para obtener más información, consulta Crea reglas, expresiones y políticas de seguridad de Google Cloud Armor.
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
Puedes usar Google Cloud Armor para proteger un servidor 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 secuencias de comandos entre sitios (XSS). El contenido de la caché es estático y es probable que no implique un riesgo de un ataque orientado desde la Web. Sin embargo, el servidor de origen del contenido subyacente puede ser una aplicación dinámica con vulnerabilidades de aplicación web conocidas o que puedan llegar a existir. Es posible que, como parte de los requisitos de seguridad o cumplimiento, se requiera que mitigues estos riesgos para evitar que las vulnerabilidades de Internet logren atacar al 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 Google 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.
También puedes usar las 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 de Google Cloud Armor. Para agregar estos conjuntos de expresiones a una regla, usa la consola de Google Cloud o la marca --expression de gcloud.
Para obtener más información, consulta Crea reglas, expresiones y políticas de seguridad.
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):
evaluatePreconfiguredExpr('xss-stable')
En el siguiente ejemplo, se usa una regla preconfigurada para mitigar los ataques de inserción de SQL (SQLi):
evaluatePreconfiguredExpr('sqli-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') && evaluatePreconfiguredExpr('sqli-stable')
Las 10 mejores mitigaciones de OWASP para cargas de trabajo híbridas
Google Cloud Armor ofrece mitigaciones para los siguientes ataques, ya sea que se implementen en Google Cloud, de manera local o en un proveedor de terceros:
- 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.
Las reglas de WAF preconfiguradas de Google Cloud Armor se pueden agregar a una política de seguridad para detectar y denegar solicitudes de capa 7 no deseadas que contengan intentos de SQLi o XSS. Google Cloud Armor detecta las solicitudes maliciosas y las coloca 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 el servicio de backend.
Para defender una carga de trabajo no alojada en Google Cloud de 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 Google 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 Google 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 Google Cloud Armor. Con los NEG de Internet, el servidor de origen se puede ubicar de forma local o con un proveedor de infraestructura externo.
Google Cloud Armor y el resto de la infraestructura perimetral de Google mitigan y descartan los ataques de L3/L4, alertan sobre actividad sospechosa en la capa 7 y están listos para denegar solicitudes no deseadas de la capa 7 con reglas personalizadas. La telemetría y el registro de Google 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 Google 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 de backend con una conexión a Internet NEG como backend.
- Habilita Cloud CDN para este servicio de backend.
- Crea una política de seguridad de Google 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 Google 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 Google 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 con eficiencia desde la caché, un cliente malicioso o defectuoso puede generar un gran volumen de solicitudes que generan un error de caché y requieren que el servidor de origen subyacente se recupere 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 Google Cloud Armor para que coincida con la firma de cualquier cliente que esté causando el problema y, así, rechazar las solicitudes antes de que lleguen al servidor de origen y afecten el rendimiento.
Para lograrlo, sigue estos pasos:
- Crea una política de seguridad de Google 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.
¿Qué sigue?
- Configura políticas de seguridad
- Obtén información sobre el lenguaje de las reglas personalizadas
- Ajusta las reglas de WAF