Descripción general de la política de seguridad de Google Cloud Armor

Usa las políticas de seguridad de Google Cloud Armor para proteger las aplicaciones que se ejecutan detrás de un balanceador de cargas de ataques de denegación de servicio distribuido (DSD) y otros ataques basados en la Web, ya sea que las aplicaciones se implementen en Google Cloud, en una implementación híbrida o en una arquitectura de múltiples nubes.

Las políticas de seguridad de Google Cloud Armor están compuestas por reglas que filtran el tráfico según los atributos de las capas 3, 4 y 7. Por ejemplo, puedes especificar condiciones que coincidan con la dirección IP, el rango de IP, el código de región o los encabezados de una solicitud entrante.

Las políticas de seguridad de Google Cloud Armor solo están disponibles para los servicios de backend detrás de un balanceador de cargas de HTTP(S) externo. El balanceador de cargas puede estar en el nivel Premium o Estándar. La protección contra DSD se proporciona de forma automática para el balanceo de cargas de HTTP(S), el balanceo de cargas del Proxy SSL y el balanceo de cargas de Proxy TCP.

Se admiten los protocolos HTTP, HTTPS, HTTP/2 y QUIC. Para obtener información sobre cómo configurar Google Cloud Armor en Google Kubernetes Engine (GKE), consulta Configura Google Cloud Armor a través de Ingress.

Los backends del servicio de backend pueden ser instancias de máquinas virtuales (VM) en un grupo de instancias, grupos de extremos de redes zonales (NEG zonales) o grupos de extremos de redes de Internet (NEG de Internet). Cuando usas Google Cloud Armor para proteger una implementación híbrida o una arquitectura de múltiples nubes, los backends deben ser NEG de Internet.

Seguridad perimetral con políticas de seguridad de Google Cloud Armor

El balanceo de cargas de HTTP(S) se implementa en el perímetro de la red de Google en los puntos de presencia (PoP) de Google de todo el mundo. En el nivel Premium, el tráfico de usuario que se dirige a un balanceador de cargas de HTTP(S) externo ingresa al PoP más cercano al usuario. Luego, se balancea la carga a través de la red global de Google al backend más cercano que tenga suficiente capacidad disponible. En el nivel Estándar, el tráfico del usuario ingresa a la red de Google mediante redes de intercambio de tráfico, ISP o tránsito en la región en la que implementaste tus recursos de Google Cloud.

Las políticas de seguridad de Google Cloud Armor te permiten denegar o permitir el acceso al balanceador de cargas de HTTP(S) externo en el perímetro de Google Cloud, lo más cerca posible de la fuente del tráfico entrante. Esto evita que el tráfico no deseado consuma recursos o ingrese a tus redes de la nube privada virtual (VPC).

En el siguiente diagrama, se ilustra la ubicación de los balanceadores de cargas de HTTP(S) externos, la red de Google y los centros de datos de Google.

Política de Google Cloud Armor en el perímetro de la red
Política de Google Cloud Armor en el perímetro de la red (haz clic para ampliar)

Requisitos

Estos son los requisitos para las políticas de seguridad de Google Cloud Armor:

  • El balanceador de cargas debe ser un balanceador de cargas de HTTP(S) externo.
  • El esquema de balanceo de cargas del servicio de backend debe ser EXTERNAL.
  • El protocolo del servicio de backend debe ser HTTP, HTTPS o HTTP/2.

Características de la política de seguridad

Las políticas de seguridad de Google Cloud Armor tienen las siguientes características principales.

  • De forma opcional, puedes usar el protocolo QUIC con balanceadores de cargas que usen Google Cloud Armor.

  • Puedes usar Google Cloud Armor con balanceadores de cargas de HTTP(S) externos que se encuentran en el nivel Premium o Estándar.

  • Puedes usar las políticas de seguridad con GKE y el controlador de Ingress predeterminado.

Políticas de seguridad del balanceo de cargas de HTTP(S)

Cada servicio de backend de un balanceador de cargas de HTTP(S) externo puede hacer referencia a una sola política de seguridad de Google Cloud Armor. Puedes usar la misma política de seguridad con más de un servicio de backend en el mismo balanceador de cargas de HTTP(S) externo o en uno diferente.

Debes designar la prioridad (orden de evaluación de reglas) cuando configuras varias reglas.

Reglas de listas de direcciones IP permitidas y denegadas

Puedes crear reglas de listas de direcciones IP permitidas y denegadas dentro de una política de seguridad: Algunos ejemplos son los siguientes:

  • La lista de bloqueo de direcciones IP o CIDR te permite bloquear una dirección IP de origen o un rango de CIDR para que no accedan a balanceadores de cargas de HTTP(S) externos.

  • Con las listas de anunciantes permitidos para direcciones IP o CIDR puedes permitir que una dirección IP de origen o un rango de CIDR accedan a balanceadores de cargas de HTTP(S) externos.

  • Las direcciones IPv4 e IPv6 son compatibles con las reglas de las listas de direcciones permitidas y denegadas.

  • Las reglas de direcciones IP pueden bloquear o permitir CIDR o direcciones IP de origen individuales. Se admiten direcciones IPv4 e IPv6 de origen, pero las direcciones IPv6 deben tener máscaras de subred menores que /64.

  • Las reglas de denegación pueden mostrar una respuesta HTTP 403 (no autorizado), 404 (acceso denegado) o 502 (puerta de enlace incorrecta).

Motor de aplicación y lenguaje de reglas

El lenguaje de reglas y el motor de aplicaciones proporcionan lo siguiente:

  • La capacidad de escribir expresiones de reglas personalizadas que pueden coincidir con varios atributos de capa 3 a hasta la 7 de las solicitudes entrantes. Google Cloud Armor proporciona un lenguaje flexible para escribir condiciones de coincidencia personalizadas.

  • La capacidad de combinar varias subexpresiones en una sola regla.

  • La capacidad de rechazar o permitir solicitudes en función del código regional de la solicitud entrante. Los códigos de región se basan en los códigos ISO 3166-1 alfa-2. Los códigos de región a veces corresponden a países específicos, pero algunos abarcan un país y sus áreas asociadas. Por ejemplo, el código US incluye todos los estados de Estados Unidos, un distrito y seis áreas periféricas.

Reglas preconfiguradas para XSS, SQLi, LFI, RFI y RCE

Puedes usar reglas preconfiguradas para mitigar los siguientes ataques:

  • Secuencia de comandos entre sitios (XSS)
  • Ataques de inserción de SQL (SQLi)
  • Ataques de inclusión de archivos locales (LFI)
  • Ataques de inclusión de archivos remotos (RFI)
  • Ataques de ejecución de código remoto (RCE)

Estas reglas se basan en la versión 3.0.1. del conjunto de reglas principales de Modsecurity de OWASP.

Reglas preconfiguradas para listas de direcciones IP con nombre

Las reglas preconfiguradas para listas de direcciones IP con nombre proporcionan lo siguiente:

  • Integra las listas de direcciones IP denominadas de proveedores externos con Google Cloud Armor.

  • Simplifica el mantenimiento de los rangos de direcciones IP permitidos o denegados.

  • Sincroniza a diario las listas de los proveedores externos.

  • Aumenta tu capacidad para configurar direcciones IP y rangos en las políticas de seguridad porque las listas de direcciones IP con nombre no están sujetas a límites en la cantidad de direcciones IP por regla.

Modo de vista previa

Puedes obtener una vista previa de los efectos de una regla sin aplicarla. En el modo de vista previa, las acciones se anotan en Cloud Monitoring. Puedes obtener una vista previa de las reglas individuales en una política de seguridad o de cada regla en la política.

Logging

La prioridad de la regla coincidente, la acción asociada, la información relacionada y el nombre de la política de seguridad de Google Cloud Armor se registran para las solicitudes HTTP(S) a tu balanceador de cargas de HTTP(S) externo. Para registrar la información de registro de Google Cloud Armor, debes habilitar el registro de las solicitudes HTTP(S).

Información sobre las políticas de seguridad de Google Cloud Armor

Las políticas de seguridad de Google Cloud Armor son conjuntos de reglas que defines para aplicar reglas de firewall de la capa de aplicación que protegen aplicaciones o servicios externos. Cada regla se evalúa con respecto al tráfico entrante.

Una regla de política de seguridad de Google Cloud Armor consiste en una condición de coincidencia y una acción que se realiza cuando se cumple esa condición. Las condiciones pueden ser tan simples como si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un rango de CIDR en específico (también conocido como reglas de listas de direcciones IP permitidas y denegadas). De manera alternativa, si usas la referencia del lenguaje de reglas personalizadas de Google Cloud Armor, puedes crear condiciones personalizadas que coincidan con varios atributos del tráfico entrante, como la ruta de URL, el método de la solicitud o los valores del encabezado de la solicitud.

Cuando se cumple una condición, la acción consiste en permitir o denegar el tráfico. Según la configuración predeterminada, esta acción se aplica, pero hay una opción de vista previa disponible. Cuando configuras la opción de vista previa como verdadera, se registra la acción en la vista previa, pero no se aplica.

Puedes asociar una política de seguridad de Google Cloud Armor con uno o más servicios de backend. Un servicio de backend solo puede tener una política de seguridad asociada.

Si una política de seguridad de Google Cloud Armor se asocia con cualquier servicio de backend, no se puede borrar. Un servicio de backend se puede borrar sin importar si tiene una política de seguridad asociada.

Si varias reglas de reenvío apuntan a un servicio de backend que tiene una política de seguridad asociada, las reglas de la política se aplican a todo el tráfico que entra a cada una de las direcciones IP de las reglas de reenvío.

En la siguiente ilustración, la política de seguridad internal-users-policy de Google Cloud Armor está asociada con el servicio de backend test-network.

Política de seguridad de Google Cloud Armor en el perímetro de la red
Política de seguridad de Google Cloud Armor en el perímetro de la red (haz clic para ampliar)

Orden de evaluación de reglas

El orden de evaluación de las reglas está determinado por dos factores: la prioridad de la regla y el tipo de regla.

Se les debe asignar una prioridad a las reglas, del número más bajo al más alto. La regla con el valor numérico más bajo asignado tiene la prioridad lógica más alta y se evalúa antes que las reglas con prioridades lógicas más bajas. La prioridad numérica mínima es 0. La prioridad de una regla disminuye a medida que aumenta su número (1, 2, 3, N +1). No puedes configurar dos o más reglas con la misma prioridad. La prioridad para cada regla debe establecerse en un número del 0 al 2147483646, inclusive. El valor de prioridad 2147483647, también conocido como INT-MAX, está reservado para la regla predeterminada.

Entre los números de prioridad, puede haber brechas, lo que te permite agregar o quitar reglas en el futuro sin afectar el resto de las reglas. Por ejemplo, 1, 2, 3, 4, 5, 9, 12, 16 es una serie válida de números de prioridad a la que le podrías agregar reglas numeradas del 6 al 8, del 10 al 11 y del 13 al 15 en otro momento. No es necesario que cambies las reglas existentes, excepto el orden de ejecución.

Por lo general, se aplica la regla de prioridad más alta que coincide con la solicitud. Sin embargo, hay una excepción cuando se ejecutan solicitudes HTTP POST a través de reglas preconfiguradas definidas con evaluatePreconfiguredExpr(). La excepción es la siguiente.

Para las solicitudes HTTP POST, Google Cloud Armor recibe el encabezado de la solicitud antes del cuerpo (carga útil). Debido a que Google Cloud Armor recibe primero la información del encabezado, evalúa las reglas que coinciden con el encabezado, pero no genera coincidencias con ninguna regla preconfigurada en el cuerpo. Si hay varias reglas basadas en encabezados, Google Cloud Armor las evalúa en función de su prioridad según lo previsto.

Después de que Google Cloud Armor reciba el cuerpo de HTTP POST, evalúa las reglas que se aplican al encabezado y al cuerpo de la solicitud. Como resultado, es posible que las reglas de menor prioridad que verifican el encabezado de una solicitud coincidan antes que las de mayor prioridad que verifican el cuerpo de la solicitud.

Ejemplos

En el siguiente ejemplo, las reglas 1, 2 y 3 se evalúan en ese orden para los campos de encabezado IP y HTTP. Sin embargo, si un IP 9.9.9.1 inicia un ataque XSS en el cuerpo HTTP POST, solo el bloqueo se bloquea (en la regla 2) el encabezado HTTP pasa al backend (por regla 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

En el siguiente ejemplo, la política permite la IP 9.9.9.1 sin analizarla en busca de ataques de XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regla predeterminada

Cada política de seguridad de Google Cloud Armor contiene una regla predeterminada que coincide si ninguna de las reglas de mayor prioridad coincide o si no hay otras reglas en la política. A la regla predeterminada se le asigna una prioridad de 2147483647 de forma automática (INT-MAX) y siempre está presente en la política de seguridad.

No puedes borrar la regla predeterminada, pero puedes modificarla. La acción predeterminada para la regla predeterminada es denegar, pero puedes cambiarla a permitir.

Fingerprint

Cada política de seguridad de Google Cloud Armor tiene un campo fingerprint. La huella digital es un hash del contenido almacenado en la política. Cuando crees una política nueva, no proporciones el valor de este campo. Si proporcionas un valor, se ignora. Sin embargo, cuando actualizas una política de seguridad, debes especificar la huella digital actual, que obtienes cuando exportas o describes la política.

La huella digital evita que anules de la actualización de otro usuario. Si la huella digital que proporcionas está desactualizada, significa que la política de seguridad se actualizó desde la última vez que recuperaste la huella digital. Para comprobar las diferencias y recuperar la huella digital más reciente, describe la política de seguridad.

Cómo se manejan las conexiones de WebSocket

El balanceo de cargas de HTTP(S) externo tiene compatibilidad integrada para el protocolo de WebSocket. Los canales de WebSocket se inician a partir de solicitudes HTTP(S). Google Cloud Armor puede bloquear un canal WebSocket para que no se establezca, por ejemplo, si una lista de bloqueo de direcciones IP bloquea la dirección IP de origen. Sin embargo, las transacciones posteriores en el canal no cumplen con el protocolo HTTP y Google Cloud Armor no evalúa ningún mensaje después de la primera solicitud.

Políticas de seguridad de Google Cloud Armor

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 destinos sean las VM de backend con balanceo de cargas y cuyas fuentes sean rangos de IP usados por balanceadores de cargas de HTTP(S) externos. 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 HTTP(S) externo. 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 se procesa a través del balanceador de cargas de HTTP(S) externo con una política de seguridad asociada debería 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 a fin de 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:

  1. Crea dos grupos de instancias, uno en la región us-west1 y otro en la región europe-west1.
  2. Implementa instancias de aplicaciones de backend en las VM de los grupos de instancias.
  3. Crea un balanceador de cargas de HTTP(S) externo 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.
  4. 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.
  5. 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.
  6. Configura las reglas de firewall de permiso de entrada para permitir el tráfico desde el balanceador de cargas de HTTP(S) externo. Para obtener más información, consulta las Reglas de firewall.

IAP y Google Cloud Armor con balanceo de cargas de HTTP(S)

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 HTTP(S) externo, 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 HTTP(S) externo.

Si IAP y las políticas de seguridad de Google Cloud Armor se habilitaron en un servicio de backend de un balanceador de cargas de HTTP(S) externo, primero se realiza la evaluación de IAP. Si IAP bloquea una solicitud, Google Cloud Armor no evalúa esa solicitud. Si IAP autentica correctamente una solicitud, Google Cloud Armor evalúa la solicitud. La solicitud se bloquea si una política de seguridad de Google Cloud Armor genera una decisión de rechazo.

Usa las listas de bloqueo de direcciones IP y las lista de anunciantes permitidos con IAP.
Uso de listas de bloqueo de direcciones IP y lista de anunciantes permitidos 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 Google Cloud necesita acceder 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.

Google Cloud Armor para implementaciones híbridas
Google Cloud Armor para implementaciones híbridas (haz clic para ampliar)

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 HTTP(S) externo 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.

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 garantiza que el servidor de origen de CDN esté protegido contra los ataques de las aplicaciones, mitiga los 10 riesgos principales de OWASP y aplica las políticas de filtrado de la capa 7.

Google Cloud Armor aplica políticas de seguridad para servicios de backend con Cloud CDN habilitado solo para errores de caché, es decir, solicitudes que omiten la caché de Cloud CDN.

Cuando se vincula una política de seguridad a un servicio de backend habilitado para Cloud CDN, Google Cloud Armor evalúa las solicitudes entrantes que no se pueden entregar desde la caché a fin de determinar si deben reenviarse al servidor de origen. Si una regla coincide con la solicitud, se realiza la acción que está configurada en la regla.

Sin embargo, no se aplican las políticas de seguridad vinculadas a un servicio de backend habilitado para Cloud CDN en el caso de los aciertos de caché. Si una solicitud se puede entregar desde la caché, se entrega a cualquier cliente válido, sin importar lo que la política de seguridad hubiera hecho para esa solicitud.

En el siguiente diagrama, se muestra cómo funciona Google Cloud Armor con los orígenes de Cloud CDN.

Uso de Google Cloud Armor con Cloud CDN
Google Cloud Armor con Cloud CDN (haz clic para ampliar)

Google Cloud Armor con apps sin servidores

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 y Cloud Functions, debes tomar medidas especiales para solucionar un problema de seguridad.

Los usuarios que tienen la URL predeterminada para un servicio de Cloud Functions pueden omitir el balanceador de cargas y dirigirse directamente a la URL del servicio. Mediante esta acción, se omiten las políticas de seguridad de Google Cloud Armor. No puedes inhabilitar las URL que Google Cloud asigna de forma automática a los servicios de Cloud Functions.

Para evitar este riesgo de seguridad, puedes usar internal-and-gclb cuando configuras Cloud Functions, que solo permite el tráfico interno y el tráfico enviado a una dirección IP pública expuesta por el balanceador de cargas de HTTP(S) externo. El tráfico que se envía a cloudfunctions.net o a cualquier otro dominio personalizado configurado mediante 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 mediante el balanceador de cargas de HTTP(S) externo.

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.

Casos de uso generales

En esta sección, se presentan varios casos de uso comunes relacionados con las políticas de seguridad de Google Cloud Armor.

Caso de uso 1: Limita el acceso al balanceador de cargas de HTTP(S) externo de Google Cloud

Un caso de uso típico para ubicar direcciones IP de usuarios en una lista de direcciones IP permitidas es cuando al balanceador de cargas de HTTP(S) externo solo lo usa 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.

Restricción del acceso al balanceador de cargas con una lista de admisión
Restricción del acceso al balanceador de cargas con una lista de admisión (haz clic para agrandar)

Para controlar el acceso al balanceador de cargas de HTTP(S) externo, configura una lista de admisión con direcciones IP o rangos de CIDR de origen desde los cuales se permite 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 que tengan direcciones IP 203.0.113.0/24 accedan al balanceador de cargas de HTTP(S) externo. Deseas rechazar todo el resto del tráfico.

Para crear esta configuración, sigue estos pasos:

  1. Crea una política de seguridad de Google Cloud Armor.
  2. En la política de seguridad, incorpora una regla que agregue 203.0.113.0/24 a la lista de anunciantes permitidos como la primera regla. Esta regla tiene la descripción allow 203.0.113.0/24.
  3. 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. Si cambias la regla de allow a deny, se bloquea todo el tráfico que no se origina en el rango 203.0.113.0/24, que está en una lista de anunciantes permitidos.
  4. Asocia esta política con el servicio de backend del balanceador de cargas de HTTP(S) externo

Caso de uso 2: Bloquea el tráfico no autorizado o malicioso en el perímetro con listas de denegación

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.

Restricción del acceso al balanceador de cargas con una lista de denegación
Restricción del acceso al balanceador de cargas con una lista de denegación (haz clic para ampliar)

Caso de uso 3: Permite el tráfico al balanceador de cargas de HTTP(S) externo solo desde un proveedor de seguridad de terceros y otros usuarios autorizados

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 HTTP(S) externo 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.

Restricción del acceso al balanceador de cargas mediante la inclusión en la lista de admisión del tráfico de un proveedor de seguridad externo
Restricción del acceso al balanceador de cargas mediante la inclusión en la lista de admisión del tráfico de un proveedor de seguridad externo (haz clic para agrandar)

Caso de uso 4: Personaliza las defensas con reglas personalizadas que coincidan en los parámetros desde la capa 3 hasta 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 Google Cloud Console. 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 1.2.3.4 y con un usuario-agente que contiene la string WordPress:

inIpRange(origin.ip, '1.2.3.4/32') && 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.

Caso de uso 5: Mitiga los ataques de la capa de la aplicación con reglas preconfiguradas

Usa reglas preconfiguradas para detectar y bloquear ataques comunes de la capa de la aplicación, como XSS y SQLi. 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 Cloud Console o la marca --expression de gcloud. Para obtener más información, consulta Crea reglas, expresiones y políticas de seguridad de Google Cloud Armor.

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 1.2.3.0/24:

inIpRange(origin.ip, '1.2.3.0/24') && evaluatePreconfiguredExpr('sqli-stable')

Casos de uso para implementaciones híbridas

En esta sección, se presentan casos de uso para las políticas de seguridad de Google Cloud Armor con implementaciones híbridas.

Caso de uso: Las 10 mejores mitigaciones de OWASP para cargas de trabajo híbridas

Google Cloud Armor ofrece mitigación de los ataques de inserción de SQL (SQLi) y de secuencias de comandos entre sitios (XSS) para tus aplicaciones, ya sea que se implementen en Google Cloud, de manera local o en un proveedor externo. 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 mejores 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 proteger una carga de trabajo que no está alojada en Google Cloud de ataques de SQLi o XSS en el perímetro de la red de Google, haz lo siguiente:

  1. Configura un balanceador de cargas de HTTP(S) externo con un servicio de backend que tenga un NEG de Internet como backend.
  2. Crea una política de seguridad de Google Cloud Armor.
  3. Agrega reglas de SQLi y XSS a la política.
  4. Vincula la política de seguridad al servicio de backend que creaste en el paso 1.
  5. Supervisa la actividad de Google Cloud Armor con Cloud Logging, Cloud Monitoring y los hallazgos enviados a Security Command Center.

Caso de uso: 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:

  1. Configura un balanceador de cargas de HTTP(S) externo con un servicio de backend que tenga un NEG de Internet como backend.
  2. Habilita Cloud CDN para este servicio de backend.
  3. Crea una política de seguridad de Google Cloud Armor.
  4. Vincula la política de seguridad al servicio de backend que creaste en el paso 1.
  5. Accede a las alertas, los registros y la telemetría de Google Cloud Armor en Security Command Center, Cloud Logging y Cloud Monitoring.

Casos de uso con Cloud CDN

En esta sección, se presentan dos casos de uso de Google Cloud Armor con Cloud CDN.

Caso de uso: Mitigación de SQLi y XSS

Puedes usar Google Cloud Armor para proteger un servidor de origen de Cloud CDN de riesgos como los ataques de inserción de SQL (SQLi) y de 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:

  1. Crea o identifica un servicio de backend con CDN habilitado.
  2. Crea una política de seguridad de Google Cloud Armor.
  3. Crea una o más reglas en la política de seguridad para rechazar los ataques de XSS y SQLi.
  4. 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.

Caso de uso: 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:

  1. Crea una política de seguridad de Google Cloud Armor.
  2. Configura una regla; por ejemplo, la siguiente regla deniega el acceso a "/admin":

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
    
  3. Vincula la política de seguridad del paso 1 al servicio de backend que tiene habilitado Cloud CDN.

Registro de solicitudes de balanceo de cargas de HTTP(S)

Cada solicitud HTTP(S) se registra a través de Cloud Logging. Los registros proporcionan detalles como el nombre de la política de seguridad aplicada y la regla de coincidencia, y se informa si se aplicó la regla. El registro de solicitudes para recursos de servicio de backend nuevos está inhabilitado de forma predeterminada. Para asegurarte de que se registren las solicitudes de Google Cloud Armor, debes habilitar el registro de HTTP(S).

Consulta Registro en la lista de bloqueo/lista de anunciantes permitidos de IP para obtener más información.

Para ver los registros de Google Cloud Armor, consulta Visualiza registros.

Limitaciones

  • Una lista de bloqueo/lista de anunciantes permitidos de dirección IP para el balanceo de cargas de HTTP(S) no es compatible con los depósitos de backend de Cloud Storage.

  • Google Cloud Armor no es compatible con el balanceo de cargas de HTTP(S) interno.

  • Las políticas de seguridad se aplican solo para errores de caché de CDN. El contenido se entrega desde la caché incluso si una regla en una política de seguridad deniega la solicitud.

  • Puedes habilitar el modo de vista previa de una regla con la herramienta de línea de comandos de gcloud y la marca --preview de gcloud compute security-policies rules update.

    Para inhabilitar el modo de vista previa, usa la marca --no-preview, que no está documentada actualmente. También puedes usar Cloud Console.

¿Qué sigue?