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

Use las políticas de seguridad de Google Cloud Armor para proteger sus aplicaciones con equilibrio de carga de la Denegación de servicio distribuida (DDoS) 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 varias nubes.

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

Las políticas de seguridad de Google Cloud Armor están disponibles solo para servicios de backend detrás de un equilibrador de carga HTTP(S) externo. El equilibrador de carga puede estar en Nivel Premium o Nivel Estándar. Los protocolos HTTP, HTTPS, HTTP/2 y QUIC son compatibles. Para obtener información sobre cómo configurar Google Cloud Armor en Google Kubernetes Engine, consulte Configuración de Google Cloud Armor a través de Ingress.

Los backends para el servicio de back-end pueden ser máquinas virtuales en un grupo de instancias, grupos de punto final de red zonal (NEG zonales) o grupos de punto final de red de internet (NEG de Internet). Cuando usa Google Cloud Armor para proteger una implementación híbrida o una arquitectura de varias nubes, los backends deben ser NEG de Internet.

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

Google Cloud HTTP(S) Load Balancing se implementa en el borde de la red de Google en puntos de presencia de Google en todo el mundo. En el Nivel Premium, el tráfico de usuarios dirigido a un balanceador de carga HTTP(S) externo ingresa el POP más cercano al usuario y luego se equilibra la carga a través de la red global de Google al backend más cercano que tiene suficiente capacidad disponible. En el nivel estándar, el tráfico de usuarios ingresa a la red de Google a través de redes de pares, ISP o tránsito en la región donde ha implementado sus recursos de Google Cloud.

Las políticas de seguridad de Google Cloud Armor le permiten permitir o denegar el acceso a su equilibrador de carga HTTP(S) externo en el borde 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 sus redes de Virtual Private Cloud (VPC).

El siguiente diagrama ilustra la ubicación de los equilibradores de carga HTTP(S) externos, la red de Google y los centros de datos de Google.

Política de Google Cloud Armor en el borde de la red
Política de Google Cloud Armor en el borde de la red (haga clic para ampliar)

Características de Google Cloud Armor

Google Cloud Armor tiene las siguientes características.

Políticas de seguridad para el equilibrio de carga HTTP(S)

  • Posibilidad de asociar una política de seguridad de Google Cloud Armor con uno o más servicios de backend de equilibrio de carga HTTP(S).
  • Designe la prioridad (orden de evaluación) cuando se configuran varias reglas.
  • Las reglas de denegación se pueden configurar para mostrar un código de error 403, 404 o 502.

La dirección IP permite enumerar y denegar reglas de lista en una política de seguridad de Google Cloud Armor

  • Denegar la lista de direcciones IP / CIDR proporciona la capacidad de bloquear una dirección IP de origen o un rango CIDR para que no accedan a equilibradores de carga HTTP(S) externos.
  • Permitir el listado de direcciones IP / CIDR proporciona la capacidad de permitir que una dirección IP de origen o rango CIDR acceda a equilibradores de carga HTTP(S) externos.
  • Las direcciones IPv4 e IPv6 son compatibles con las reglas de lista de permitidas y denegadas.

Lenguaje de reglas y motor de aplicación

  • Capacidad para escribir expresiones de reglas personalizadas que pueden coincidir en varios atributos de capa 3 a capa 7 de solicitudes entrantes. Google Cloud Armor proporciona un lenguaje flexible para escribir condiciones de coincidencia personalizadas.
  • Posibilidad de combinar múltiples subexpresiones en una sola regla.
  • Capacidad para denegar o permitir solicitudes basadas en el código de región de la solicitud entrante. Los códigos de región se basan en los códigos ISO 3166-1 alpha 2.

Reglas preconfiguradas para XSS y SQLi

  • Mitigue los ataques de scripting entre sitios (XSS) y de inyección SQL (SQLi) mediante el uso de reglas preconfiguradas.
  • Las reglas XSS y SQLi se basan en el conjunto de reglas centrales OWASP Modsecurity versión 3.0.1.

Modo de vista previa

  • Capacidad para previsualizar los efectos de las reglas en una política de seguridad en los registros de Cloud Monitoring sin aplicar las acciones en las reglas.
  • Habilite el modo de vista previa en un nivel por regla.

Logging

  • El nombre de la política de seguridad de Google Cloud Armor, la prioridad de la regla coincidente, la acción asociada y la información relacionada se registran para las solicitudes HTTP(S) en su equilibrador de carga HTTP(S) externo.

Acerca de las políticas de seguridad de Google Cloud Armor

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

Una política de seguridad de Google Cloud Armor regla consiste en una condición de coincidencia y una acción a tomar 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 específica o rango CIDR (también conocido como reglas de lista de direcciones IP permitidas y listas de denegadas). Alternativamente, al usar el lenguaje de reglas personalizadas de Google Cloud Armor, puede crear condiciones personalizadas que coincidan con varios atributos del tráfico entrante, como la ruta URL, el método de solicitud o los valores de encabezado de solicitud.

Cuando se cumple una condición, la acción es permitir o denegar el tráfico. De forma predeterminada, esta acción se aplica, pero hay una opción de vista previa disponible. Cuando establece la opción de vista previa en verdadero, la acción vista previa se registra pero no se aplica.

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

Una política de seguridad de Google Cloud Armor no se puede eliminar si está asociada con algún servicio de back-end. Un servicio de back-end se puede eliminar independientemente de si tiene una política de seguridad de Google Cloud Armor asociada.

Si varias reglas de reenvío apuntan a un servicio de fondo que tiene una política de seguridad de Google Cloud Armor asociada, las reglas de política se aplican para todo el tráfico que ingresa a cada una de estas direcciones IP de reglas de reenvío.

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

Política de seguridad de Google Cloud Armor en el borde de la red
Política de seguridad de Google Cloud Armor en el borde de la red (haga clic para ampliar)

Orden de evaluación de reglas

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

Usted asigna 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 puede configurar dos o más reglas con la misma prioridad. La prioridad para cada regla debe establecerse en un número de 0 a 2147483646 inclusive. El valor de prioridad 2147483647 está reservado para la regla predeterminada.

Los números de prioridad pueden tener huecos, que le permiten agregar o eliminar 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 los que puede agregar reglas numeradas del 6 al 8, del 10 al 11 y del 13 al 15 en el futuro sin ninguna cambio a las reglas existentes, excepto el cambio en el orden de ejecución.

Normalmente, se aplica la regla de mayor prioridad que coincide con la solicitud. Sin embargo, hay una excepción cuando se ejecutan solicitudes HTTP POST a través de reglas preconfiguradas configuradas usando 'EvaluationPreconfiguredExpr()'. 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 coincide con ninguna regla preconfigurada en el cuerpo. Si hay varias reglas basadas en encabezados, Google Cloud Armor las evalúa según su prioridad como se esperaba.

Después de que Google Cloud Armor recibe el cuerpo HTTP POST, evalúa las reglas que se aplican tanto al encabezado como 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 reglas de mayor prioridad que verifican el cuerpo de la solicitud.

Ejemplo

En el siguiente ejemplo, las reglas 1, 2 y 3 se evalúan en ese orden para los campos de encabezado IP y HTTP. Pero, si una IP 9.9.9.1 lanza un ataque XSS en el cuerpo HTTP POST, solo el cuerpo está bloqueado (por la regla 2); el encabezado HTTP pasa al backend (según la 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 9.9.9.1 sin escanear contra ataques 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 automáticamente una prioridad de 2147483647 (max int32) y siempre está presente en la política de seguridad de Google Cloud Armor. No puede eliminar la regla predeterminada, pero puede modificarla. La acción predeterminada para la regla predeterminada es denegar, pero puede cambiar la acción para permitir.

Fingerprint

Cada política de seguridad de Google Cloud Armor tiene un campo fingerprint. La huella digital es un hash de los contenidos almacenados en la política. Cuando cree una nueva política, no proporcione el valor de este campo. Si proporciona un valor, se ignora. Sin embargo, cuando actualiza una política de seguridad de Google Cloud Armor, debe especificar la huella digital actual, que obtiene cuando exporta o describe la política.

La huella digital lo protege de anular la actualización de otro usuario. Si la huella digital que proporciona no está actualizada, significa que la política de seguridad de Google Cloud Armor se actualizó desde la última vez que recuperó la huella digital. Describa la política de seguridad de Google Cloud Armor para verificar las diferencias y recuperar la última huella digital.

Políticas de seguridad de Google Cloud Armor para el equilibrio de carga HTTP(S) y las reglas de firewall VPC

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

  • Las políticas de seguridad de Google Cloud Armor proporcionan seguridad periférica y actúan sobre el tráfico del cliente a Google Front Ends (GFE).
  • Las reglas de firewall de VPC permiten o niegan el tráfico hacia y desde sus backends. Debe crear reglas de entrada que permitan el firewall, cuyos objetivos son las máquinas virtuales de backend con equilibrio de carga, y cuyas fuentes son rangos de IP utilizados por equilibradores de carga externos HTTP(S). Estas reglas permiten que los GFE y los sistemas de comprobación de estado se comuniquen con sus máquinas virtuales de back-end.

Por ejemplo, considere un escenario en el que desea permitir que el tráfico solo del rango CIDR 100.1.1.0/24 y el rango CIDR 100.1.2.0/24 acceda a su equilibrador de carga HTTP(S) externo. Su objetivo es garantizar que el tráfico no pueda llegar directamente a las instancias de equilibrio de carga del back-end; en otras palabras, solo el tráfico externo proxy a través del equilibrador de carga 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 ingreso para restringir el acceso
Uso de la política de seguridad de Google Cloud Armor con firewall de ingreso para restringir el acceso (haga clic para ampliar)

En la ilustración anterior, logra sus objetivos de seguridad configurando su implementación de Google Cloud de la siguiente manera:

  1. Cree dos grupos de instancias, uno en la región us-west1 y otro en la región europe-west1.
  2. Implemente instancias de aplicaciones de back-end en las máquinas virtuales en los grupos de instancias.
  3. Cree un equilibrador de carga HTTP(S) externo en el Nivel Premium. Configure un mapa de URL simple y un único servicio de back-end cuyos backends son los dos grupos de instancias que creó en el paso anterior. Asegúrese de que la regla de reenvío del equilibrador de carga utilice la dirección IP externa 120.1.1.1.
  4. Configure una política de seguridad de Google Cloud Armor que permita el tráfico de 100.1.1.0/24 y 100.1.2.0/24 y niegue el resto del tráfico.
  5. Asociar esta política con el servicio de back-end del equilibrador de carga. Consulte Configuración de políticas de seguridad para obtener instrucciones. Los equilibradores de carga HTTP(S) externos con mapas de URL más complejos pueden hacer referencia a múltiples servicios de back-end. Puede asociar la política de seguridad con uno o más de los servicios de back-end, según sea necesario.
  6. Configurar el ingreso permite reglas de firewall para permitir el tráfico desde el equilibrador de carga HTTP(S) externo. Para obtener más información, consulte Reglas de firewall.

Políticas de seguridad de Google Cloud Armor para HTTP(S) Load Balancing y Identity-Aware Proxy

Identity-Aware Proxy (IAP) verifica la identidad de un usuario y luego determina si se debe permitir que ese usuario acceda a una aplicación. Para habilitar IAP para el equilibrador de carga HTTP(S) externo, habilítelo en los servicios de fondo del equilibrador de carga. Del mismo modo, las políticas de seguridad de Google Cloud Armor de borde están conectadas a los servicios de fondo de un equilibrador de carga HTTP(S) externo.

Si las políticas de seguridad de Google Cloud Armor y el IAP están habilitados para un servicio de back-end de un equilibrador de carga HTTP(S) externo, el resultado de la evaluación de la política de seguridad de Google Cloud Armor y el resultado de IAP se usan juntos para determinar si el tráfico debe permitirse o denegarse en el borde. El tráfico se bloquea cuando una política de seguridad de Google Cloud Armor o configuración IAP da como resultado una decisión denegada. Sin embargo, la evaluación de IAP ocurre primero, por lo que se puede presentar a los usuarios una página que solicita la autenticación, aunque su política de seguridad pueda denegar su solicitud.

Uso de listas de denegación de IP y listas de permitidos con IAP
Uso de listas de denegación de IP y listas de permitidas con IAP (haga clic para ampliar)

Para obtener más información sobre IAP y configuraciones relacionadas, consulte la documentación de Identity-Aware Proxy.

Google Cloud Armor con implementaciones híbridas

En una implementación híbrida, un equilibrador de carga de Google Cloud 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 la nube. Puede usar Google Cloud Armor para proteger tales implementaciones.

En el siguiente diagrama, el equilibrador de carga tiene dos servicios de fondo. Uno tiene un grupo de instancias como back-end. El otro servicio de backend tiene un NEG de Internet como su 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 (haga clic para ampliar)

Cuando adjunta una política de seguridad de Google Cloud Armor al servicio de back-end que tiene un NEG de Internet como back-end, Google Cloud Armor inspecciona cada solicitud L7 que llega al equilibrador de carga HTTP(S) externo destinado a ese servicio de back-end.

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

Puede usar Google Cloud Armor con Cloud CDN para proteger los servidores de origen CDN. Google Cloud Armor garantiza que el servidor de origen CDN esté protegido contra los ataques a las aplicaciones, mitiga los riesgos de los 10 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 back-end con Cloud CDN habilitado solo para errores de caché; es decir, para solicitudes que pierden o omiten el caché de CDN en la nube.

Cuando se adjunta una política de seguridad a un servicio de back-end habilitado para CDN en la nube, Google Cloud Armor evalúa las solicitudes entrantes que no se pueden atender desde la memoria caché en función de la política de seguridad para determinar si deben reenviarse al servidor de origen. Si una regla coincide con la solicitud, se toma la acción configurada en la regla.

Sin embargo, las políticas de seguridad adjuntas a un servicio de back-end habilitado para CDN en la nube no se aplican para los hits de caché. Si una solicitud se puede servir desde la memoria caché, se sirve a cualquier cliente válido, independientemente de lo que la política de seguridad hubiera hecho para esa solicitud.

El siguiente diagrama 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 (haga clic para ampliar)

Casos de uso general

Esta sección presenta varios casos de uso comunes para las políticas de seguridad de Google Cloud Armor.

Caso de uso 1: limitación del acceso al equilibrador de carga HTTP(S) externo de Google Cloud

Un caso de uso típico para colocar las direcciones IP de los usuarios en una lista de permitidos es cuando su equilibrador de carga HTTP(S) externo es utilizado solo por un conjunto específico de usuarios. En el siguiente ejemplo, solo los usuarios de su organización tienen acceso a los servicios detrás de su equilibrador de carga. Estos usuarios tienen direcciones IP o bloques de direcciones asignados por su organización. Puede colocar estas direcciones IP o rangos CIDR en una lista de permisos para que solo estos usuarios tengan acceso al equilibrador de carga.

Restricción del acceso del equilibrador de carga con una lista de permitidos
Restringir el acceso al equilibrador de carga con una lista de permitidos (haga clic para ampliar)

Usted controla el acceso al equilibrador de carga HTTP(S) externo configurando una lista de permisos con direcciones IP de origen o rangos de CIDR de origen desde los cuales se permite el acceso a su equilibrador de carga. La siguiente sección describe más detalladamente esta configuración.

En esta configuración, solo desea permitir que los usuarios de su organización con direcciones IP de 203.0.113.0/24 accedan al equilibrador de carga externo HTTP(S). Desea que se deniegue el resto del tráfico.

Para crear esta configuración, siga estos pasos:

  1. Crea una política de seguridad de Google Cloud Armor:
  2. En la política de seguridad de Google Cloud Armor, agregue una regla que permita las listas 203.0.113.0/24 como la primera regla. Esta regla tiene la descripción "permitir 203.0.113.0/24".
  3. Modifique la regla predeterminada en la política de una regla allow a una regla deny. La regla predeterminada rige el tráfico que no coincide con ninguna de las reglas anteriores. Es la última regla en la política. Cambiar la regla de allow a deny bloquea todo el tráfico que no se origina en el rango 203.0.113.0/24, que está en una lista de permitidos.
  4. Asociar esta política con el servicio de back-end del equilibrador de carga HTTP(S) externo.

Caso de uso 2: bloquee el tráfico no autorizado o malicioso en el borde con listas de denegación

Use las 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 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 desde la dirección IP 198.51.100.1, donde se ha identificado un usuario malintencionado.

Restricción del acceso del equilibrador de carga con una lista de denegación
Restringir el acceso al equilibrador de carga con una lista de denegación (haga clic para ampliar)

Caso de uso 3: permita el tráfico al equilibrador de carga HTTP(S) externo solo desde un proveedor de seguridad externo y otros usuarios autorizados que estén en una lista de permitidos

Si su organización utiliza un proveedor de seguridad externo para eliminar el tráfico, puede permitir que se enumere la dirección IP del proveedor de seguridad para asegurarse de que solo el tráfico eliminado pueda acceder al equilibrador de carga y backends externos HTTP(S).

En la siguiente ilustración, el proveedor de terceros se identifica por el rango CIDR 192.0.2.0/24, y este rango está en una lista de permitidos.

Restringir el acceso al equilibrador de carga al permitir el listado del tráfico de un proveedor de seguridad externo
Restringir el acceso al equilibrador de carga al permitir el listado del tráfico de un proveedor de seguridad externo (haga clic para ampliar)

Caso de uso 4: personalice las defensas con reglas personalizadas que coincidan en los parámetros de la capa 3 a la capa 7

Use el lenguaje de reglas personalizado 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 contra estas expresiones. Si hay una coincidencia, la acción de la regla surte efecto, ya sea denegando o permitiendo el tráfico entrante.

Los siguientes ejemplos son expresiones escritas en la extensión Google Cloud Armor del Lenguaje de expresión común (CEL). Para obtener más información, consulte la referencia de idioma de reglas personalizadas de Google Cloud Armor.

Para definir expresiones en una regla, use la bandera o consola gcloud --expression. Para obtener más información, consulte Creación de políticas y reglas de seguridad de Google Cloud Armor.

En el siguiente ejemplo, las solicitudes de 1.2.3.0/24 (como sus probadores alfa) en la región AU coinciden con la siguiente expresión:

origin.region_code == "AU" && inIpRange(origin.ip, '1.2.3.0/24')

El siguiente ejemplo coincide con las solicitudes de 1.2.3.4 y con un agente de usuario que contiene la cadena WordPress:

inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Para ver ejemplos adicionales, consulte Expresiones de ejemplo en la referencia del lenguaje de reglas. Para obtener información sobre las reglas de ajuste, consulte Ajuste de las reglas WAF de Google Cloud Armor.

Caso de uso 5: mitigue los ataques de la capa de aplicación utilizando reglas preconfiguradas

Utilice reglas preconfiguradas para detectar y bloquear ataques comunes de la capa de aplicación, como XSS y SQLi. Las reglas preconfiguradas son conjuntos de expresiones predefinidas que puede agregar a una política de seguridad de Google Cloud Armor. Para agregar estos conjuntos de expresiones a una regla, use la bandera o consola gcloud --expression. Para obtener más información, consulte Creación de políticas y reglas de seguridad de Google Cloud Armor.

Para obtener más información sobre las reglas preconfiguradas, consulte Reglas preconfiguradas en la referencia del lenguaje de reglas.

El siguiente ejemplo utiliza una regla preconfigurada para mitigar los ataques de secuencias de comandos de sitios cruzados (XSS):

evaluatePreconfiguredExpr('xss-stable')

El siguiente ejemplo utiliza una regla preconfigurada para mitigar los ataques de inyección SQL (SQLi):

evaluatePreconfiguredExpr('sqli-stable')

También puede combinar reglas preconfiguradas con otras expresiones. El siguiente ejemplo utiliza una regla preconfigurada para mitigar los ataques SQLi desde el rango de dirección IP 1.2.3.0/24:

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

Casos de uso para implementaciones híbridas

Esta sección presenta casos de uso para políticas de seguridad de Google Cloud Armor con implementaciones híbridas.

OWASP Top 10 mitigación para cargas de trabajo híbridas

Google Cloud Armor ofrece inyección SQL (SQLi) y mitigación de secuencias de comandos entre sitios (XSS) para sus aplicaciones, ya sea que se implementen en Google Cloud, en las instalaciones o en un proveedor externo. Puede usar estas capacidades para abordar algunos de los riesgos de seguridad de aplicaciones web más comunes, incluidos los identificados en la lista OWASP Top 10.

Las reglas 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 contienen intentos de SQLi o XSS. Google Cloud Armor detecta solicitudes maliciosas y las deja al borde de la infraestructura de Google. Las solicitudes no se envían al servicio de fondo, independientemente de dónde se implemente el servicio de fondo.

Para defender una carga de trabajo no alojada en Google Cloud de ataques SQLi o XSS en el borde de la red de Google:

  1. Configure un equilibrador de carga HTTP(S) externo con un servicio de back-end que tenga un NEG de Internet como back-end.
  2. Crea una política de seguridad de Google Cloud Armor:
  3. Agregue reglas SQLi y XSS a la política.
  4. Adjunte la política de seguridad al servicio de back-end que creó en el paso 1.
  5. Monitoree la actividad de Google Cloud Armor mediante el registro de operaciones, el monitoreo de operaciones y los resultados enviados al Centro de comando de seguridad de la nube.

Cloud CDN servidor de origen externo DDoS defensa y monitoreo de capa 7

Las implementaciones de CDN en la nube con un servidor de origen externo pueden tener la infraestructura de borde de Google como el front-end para el proxy, el almacenamiento en caché y el filtrado de capa 7 de Google Cloud Armor. Al usar NEG de Internet, el servidor de origen puede ubicarse en las instalaciones o con un proveedor de infraestructura externo.

Google Cloud Armor y el resto de la infraestructura de borde de Google mitigan y eliminan los ataques L3/L4, alertan sobre la actividad sospechosa de la Capa 7 y están listos para negar las solicitudes no deseadas de la capa 7 con reglas personalizadas. El registro y la telemetría de Google Cloud Armor en el registro de operaciones, el monitoreo de operaciones y el centro de comando de seguridad en la nube brindan información procesable para las aplicaciones protegidas, independientemente de dónde se implementen.

Para habilitar la protección de Google Cloud Armor para servidores de orígenes externos CDN:

  1. Configure un equilibrador de carga HTTP(S) externo con un servicio de back-end que tenga un NEG de Internet como back-end.
  2. Habilite Cloud CDN para este servicio de fondo.
  3. Crea una política de seguridad de Google Cloud Armor:
  4. Adjunte la política de seguridad al servicio de back-end que creó en el paso 1.
  5. Acceda a las alertas, el registro y la telemetría de Google Cloud Armor en Security Command Center, Cloud Logging y Cloud Monitoring.

Casos de uso con Cloud CDN

Esta sección presenta dos casos de uso para Google Cloud Armor con Cloud CDN.

Caso de uso: mitigación de SQLi y XSS

Puede usar Google Cloud Armor para proteger un servidor de origen Cloud CDN de riesgos como la inyección SQL (SQLi) y los ataques de scripting entre sitios (XSS). El contenido en un caché es estático y presumiblemente no representa un riesgo de un ataque dirigido desde la web. Sin embargo, el servidor de origen de contenido subyacente podría ser una aplicación dinámica con vulnerabilidades conocidas o potenciales de aplicaciones web. Sus requisitos de seguridad o cumplimiento pueden requerir que mitigue estos riesgos para evitar que las vulnerabilidades de Internet ataquen con éxito el servidor de origen.

Para mitigar los riesgos:

  1. Cree o identifique un servicio de fondo con CDN habilitado.
  2. Crea una política de seguridad de Google Cloud Armor:
  3. Cree una o más reglas en la política de seguridad para negar los ataques XSS y SQLi.
  4. Configure uno de los objetivos de la política de seguridad para que sea el servicio de fondo que creó o identificó en el paso 1.

Caso de uso: controles de acceso de capa 7 y ataques de ruptura de caché

Dependiendo de la arquitectura de la aplicación, puede configurar un servicio de back-end para atender las solicitudes de una variedad de URL, incluido el contenido almacenable en caché y no almacenable. En tales escenarios de implementación, cree políticas de seguridad de Google Cloud Armor que denieguen el tráfico no deseado en ciertas rutas de solicitud, pero permitan a todos los clientes acceder a contenido estático en una ruta de solicitud diferente.

En otras situaciones, a pesar de que el contenido se sirve de manera eficiente desde la memoria caché, un cliente malintencionado o defectuoso puede estar generando un gran volumen de solicitudes que provocan una pérdida de memoria caché y requieren que el servidor de origen subyacente busque 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. Puede 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 denegar las solicitudes antes de que lleguen al servidor de origen y afecten el rendimiento.

Puede lograr esto completando los siguientes pasos:

  1. Crea una política de seguridad de Google Cloud Armor:
  2. Configurar una regla; por ejemplo, esto niega el acceso a "/admin": request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
  3. Adjunte la política de seguridad del paso 1 al servicio de back-end que tiene habilitado Cloud CDN.

Registro de solicitud de equilibrio de carga HTTP(S)

Cada solicitud HTTP(S) se registra a través de Cloud Monitoring Logging. Los registros proporcionan detalles como el nombre de la política de seguridad aplicada, la regla de coincidencia y si la regla se hizo cumplir. Para obtener más información, consulte Registro en la documentación de Equilibrio de carga HTTP(S).

Para ver los registros de Google Cloud Armor, consulte Visualización de registros.

Restricciones

  • La lista de denegación de IP/lista de permitidos para HTTP(S) Load Balancing no es compatible con los depósitos de back-end de Cloud Storage.
  • Google Cloud Armor no es compatible con el equilibrio de carga interno HTTP(S).
  • Las políticas de seguridad se aplican solo para errores de caché de CDN.
    • El contenido se sirve desde la memoria caché incluso si una regla en una política de seguridad hubiera denegado la solicitud.

Próximos pasos