Descripción general de la política de seguridad

Las políticas de seguridad de Google Cloud Armor protegen la aplicación, ya que proporcionan un filtrado de capa 7 y limpian las solicitudes entrantes de ataques web comunes o de otros atributos de capa 7 para bloquear el tráfico antes de que acceda a los servicios de backend con balanceo de cargas o los buckets de backend. Cada política de seguridad está compuesta por un conjunto de reglas que filtran el tráfico según condiciones como la dirección IP de una solicitud entrante, el rango de IP, el código regional o los encabezados de solicitud.

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.

Los backends para el servicio de backend pueden ser cualquiera de los siguientes:

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. Google Cloud Armor también protege los NEG sin servidores cuando el tráfico se enruta a través de un balanceador de cargas. Para asegurarte de que solo el tráfico que se enruta a través de tu balanceador de cargas alcance el NEG sin servidores, consulta Controles de entrada.

Protege tus implementaciones de Google Cloud con las 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, permitir o redireccionar las solicitudes 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.

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 coinciden con los atributos de la capa 3 a la capa 7 para proteger 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 específico (también conocido como reglas de listas de entidades permitidas y de bloqueo de direcciones IP). 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 una solicitud entrante coincide con una condición en una regla de una política de seguridad, Google Cloud Armor permite, rechaza o redirecciona la solicitud, en función de si la regla es de permiso, de denegación o de redireccionamiento. Puede haber parámetros de acción adicionales para aplicar, como insertar encabezados de la solicitud. Esta función forma parte de la administración de bots de Google Cloud Armor. Para obtener más información sobre la administración de bots, consulta la descripción general de la administración de bots.

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, pero no todos los servicios de backend deben estar asociados a la misma política de seguridad.

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)

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 HTTP(S) externos que se encuentren en cualquiera de los siguientes niveles de servicio de red:

    • Nivel Premium
    • Nivel Estándar
  • Puedes usar las políticas de seguridad con GKE y el controlador de Ingress predeterminado.

Tipos de políticas de seguridad

En la siguiente tabla, se muestran los tipos de políticas de seguridad y lo que puedes hacer con ellas. Una marca de verificación (✔) indica que el tipo de política de seguridad admite la función.

Política de seguridad de backend Política de seguridad de Edge (vista previa)
Punto de unión (recurso protegido) Servicio de backend
  • Servicio de backend
  • Bucket de backend
Acciones de la regla
  • Permitir
  • Denegar
  • Redireccionar (GOOGLE_RECAPTCHA y EXTERNAL_302); Vista previa
  • Permitir
  • Denegar
Dirección IP de origen
Ubicación geográfica de origen
Administración de bots ✔ (Vista previa)
Filtrado de capa 7
WAF
Protección adaptable
Listas de direcciones IP con nombre

Políticas de seguridad de backend

Las políticas de seguridad de backend se usan para proteger los servicios de backend expuestos por un balanceador de cargas de HTTP(S) externo. Se pueden usar para filtrar solicitudes y proteger servicios de backend que contengan grupos de instancias o grupos de extremos de red (NEG), incluidos los NEG de Internet, los zonales y los sin servidores.

Políticas de seguridad perimetral

Las políticas de seguridad perimetral permiten a los usuarios configurar las políticas de filtrado y control de acceso para el contenido que se almacena en caché. Esto incluye extremos, como servicios de backend habilitados de Cloud CDN y buckets de Cloud Storage. Las políticas de seguridad perimetral admiten el filtrado basado en un subconjunto de parámetros, a diferencia de las políticas de seguridad de backend.

Las políticas de seguridad perimetral se pueden configurar para filtrar solicitudes antes de que se entreguen desde la caché de Google. Las políticas de seguridad perimetral se implementan y se aplican en el perímetro más externo de la red de Google, más arriba de donde se encuentra la caché de Cloud CDN. Las políticas de seguridad perimetral pueden coexistir con las políticas de seguridad de backend para proporcionar dos capas de protección. Se pueden aplicar a un servicio de backend de forma simultánea, sin importar los recursos a los que apunte el servicio de backend (por ejemplo, grupos de instancias o grupos de extremos de red). Solo las políticas de seguridad perimetral se pueden aplicar a los depósitos de backend.

Orden de evaluación de reglas

El orden de evaluación de la regla se determina mediante la prioridad de la regla, desde el número más bajo hasta el número 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, existe una excepción cuando las solicitudes HTTP POST se evalúan en función de reglas preconfiguradas que usan 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 a los encabezados y al cuerpo de la solicitud. Como resultado, es posible que las reglas de prioridad más baja que permiten el encabezado de una solicitud coincidan antes que las reglas de prioridad más alta que bloquean el cuerpo de la solicitud. En estos casos, es posible que la parte del encabezado HTTP de la solicitud se envíe al servicio de backend de destino, pero el cuerpo de POST con contenido potencialmente malicioso esté bloqueado.

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 permitir, pero puedes cambiarla a denegar.

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 (usando EXPORT o DESCRIBE, respectivamente).

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, ejecuta el comando DESCRIBE.

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.

Tipos de 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: Estos son algunos ejemplos:

  • 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).

  • Si superas las reglas de acción, se puede mostrar un HTTP 429 (Demasiadas solicitudes).

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.2 del conjunto de reglas principales de Modsecurity de OWASP.

Reglas de administración de bots

Puedes usar reglas de administración de bots para hacer lo siguiente:

  1. Redireccionar solicitudes para la evaluación de reCAPTCHA Enterprise con desafíos manuales opcionales
  2. Evaluar los tokens de reCAPTCHA Enterprise adjuntos a una solicitud y aplicar la acción configurada según los atributos del token
  3. Redireccionar las solicitudes hacia la URL alternativa configurada con una respuesta 302
  4. Insertar encabezados personalizados en las solicitudes antes de enviarlos mediante proxy a los backends

Para obtener más información sobre la administración de bots, consulta la descripción general de la administración de bots.

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.

Reglas de límite de frecuencia

Puedes usar reglas de límite de frecuencia para hacer lo siguiente:

  • Regular las solicitudes por cliente según un umbral que configures.
  • Bloquear temporalmente a los clientes que superen el umbral de solicitud que estableciste para una duración configurada

Para obtener más información sobre el límite de frecuencia y su funcionamiento, consulta Descripción general del límite de frecuencia.

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.

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.

Registro

Google Cloud Armor tiene un registro extenso y te permite definir lo detallado que es el registro. Para obtener información completa sobre el registro, consulta Usa el registro de solicitudes.

Análisis JSON y registro detallado

De forma predeterminada, Google Cloud Armor no analiza el contenido JSON de los cuerpos POST cuando se evalúan las reglas de WAF preconfiguradas. Esto puede provocar que las reglas de WAF produzcan ruido y generen coincidencias positivas falsas en las solicitudes entrantes si las cargas de trabajo protegidas entregan API de REST o reciben solicitudes con JSON en el cuerpo de POST (Content-Type = "application/json").

Una regla ruidosa se activa con solicitudes que probablemente considerarías como falsos positivos. Por ejemplo, un cuerpo de solicitud JSON, como '{"test": "123"}', activa la regla de inyección de SQL owasp-crs-v030001-id942431-sqli si el análisis de JSON no está habilitado.

Te recomendamos que habilites el análisis de JSON si esperas que tu carga de trabajo reciba solicitudes con Content-Type = "application/json", por ejemplo, si entregas API de REST.

A fin de reducir el ruido y los falsos positivos, puedes configurar Google Cloud Armor para analizar el contenido JSON de los cuerpos POST. Esto significa que Google Cloud Armor ignora los caracteres estructurales del mensaje JSON en el cuerpo de POST y solo observa los valores proporcionados por el usuario final en el mensaje JSON. Para obtener más información sobre las reglas de WAF preconfiguradas, consulta Ajusta las reglas de WAF de Google Cloud Armor.

Además, es posible que no sepas por qué una solicitud de WAF preconfigurada se activó mediante una solicitud en particular. Los registros de eventos predeterminados de Google Cloud Armor contienen la regla que se activó, así como la firma secundaria. Sin embargo, es posible que debas identificar los detalles de la solicitud entrante que activó la regla para solucionar problemas, validar o realizar ajustes.

Puedes ajustar el nivel de detalle que se ingresa en tus registros. Te recomendamos habilitar el registro detallado solo cuando creas una política, realizas cambios en ella o solucionas sus problemas. Si habilitas el registro detallado, este estará activo para las reglas en modo de vista previa y para las reglas activas (sin vista previa) durante las operaciones estándar.

Para obtener más información sobre el registro detallado, consulta Usa el registro de solicitudes.

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

Cada solicitud HTTP(S) que se evalúa en función de una política de seguridad de Google Cloud Armor 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) para cada servicio de backend protegido por una política de seguridad.

Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S) y Usa el registro de solicitudes.

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

Limitaciones

  • Las políticas de seguridad de backend solo se aplican a las solicitudes de error de caché aprobadas por las políticas de seguridad perimetral.

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.

¿Qué sigue?