Descripción general de la política de seguridad

En esta página, se describe cómo puedes usar las políticas de seguridad de Google Cloud Armor para proteger tus implementaciones de Google Cloud.

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 se pueden configurar en atributos de la capa 3 a la 7. Las reglas pueden filtrar el tráfico según condiciones como 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 están disponibles para los siguientes tipos de extremos y balanceadores de cargas:

  • Balanceador de cargas de aplicaciones externo global (HTTP/HTTPS)
  • Balanceador de cargas de aplicaciones clásico (HTTP/HTTPS)
  • Balanceador de cargas de aplicaciones externo regional (HTTP/HTTPS)
  • Balanceador de cargas de aplicaciones interno regional (HTTP/HTTPS)
  • Balanceador de cargas de red de proxy externo global (TCP/SSL)
  • Balanceador de cargas de red de proxy clásico (TCP/SSL)
  • Balanceador de cargas de red de transferencia externo (TCP/UDP)
  • Reenvío de protocolos
  • VM con direcciones IP públicas

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.

Google Cloud Armor también proporciona protección avanzada contra DSD de red para balanceadores de cargas de red externos de transferencia, el reenvío de protocolos y VMs con direcciones IP públicas. Para obtener más información sobre la protección avanzada contra DSD, consulta Configura la protección avanzada contra DSD de red.

Protege tus implementaciones de Google Cloud con las políticas de seguridad de Google Cloud Armor

El balanceo de cargas externo 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 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 permitir, denegar, limitar la frecuencia o redireccionar las solicitudes a tus servicios de backend 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 aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos, 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 esquema de balanceo de cargas del servicio de backend debe ser EXTERNAL, EXTERNAL_MANAGED o INTERNAL_MANAGED.
  • El protocolo del servicio de backend debe ser HTTP, HTTPS, HTTP/2, UDP, TCP, SSL o UNSPECIFIED.

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.

  • 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 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 de backend con GKE y el controlador de Ingress predeterminado.

  • Puedes usar una política de seguridad predeterminada que limite el tráfico por encima de un límite especificado por el usuario cuando configures uno de los siguientes balanceadores de cargas:

    • Balanceador de cargas de aplicaciones externo global
    • Balanceador de cargas de aplicaciones clásico
    • Balanceador de cargas de aplicaciones externo regional
    • Balanceador de cargas de aplicaciones interno regional
    • Balanceador de cargas de red del proxy externo global
    • Balanceador de cargas de red del proxy clásico
    • Balanceador de cargas de red de transferencia externo

Además, puedes configurar las reglas de WAF preconfiguradas de Google Cloud Armor, que son reglas complejas de firewall de aplicación web (WAF) con decenas de firmas que se compilan a partir de estándares de la industria de código abierto. Cada firma corresponde a una regla de detección de ataques en el conjunto de reglas. Google ofrece estas reglas tal como están. Las reglas permiten que Google Cloud Armor evalúe decenas de firmas de tráfico distintas, ya que consulta las reglas con nombres prácticos en lugar de requerir que definas cada firma de forma manual. Para obtener más información sobre las reglas de WAF preconfiguradas, consulta la descripción general de las reglas de WAF preconfiguradas.

Tipos de políticas de seguridad

En las siguientes tablas, 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íticas de seguridad de backend

Las políticas de seguridad de backend se usan con los servicios de backend expuestos por los siguientes tipos de balanceador de cargas:

  • Balanceador de cargas de aplicaciones externo global
  • Balanceador de cargas de aplicaciones clásico
  • Balanceador de cargas de aplicaciones externo regional
  • Balanceador de cargas de aplicaciones interno regional
  • Balanceador de cargas de red del proxy externo global
  • Balanceador de cargas de red del proxy clásico

Se pueden usar para filtrar solicitudes y proteger servicios de backend que hagan referencia a grupos de instancias o grupos de extremos de red (NEG), incluidos los NEG de Internet, zonales, híbridos y sin servidores. No todos los balanceadores de cargas admiten todos los tipos de NEG. Para obtener más información sobre los NEG que admite tu balanceador de cargas, consulta Descripción general de los grupos de extremos de red.

Cuando se usan balanceadores de cargas de red de proxy externo global o balanceadores de cargas de red de proxy clásico, Google Cloud Armor aplica la acción de la regla deny de la política de seguridad solo en solicitudes de conexión nuevas. La acción deny finaliza la conexión TCP. Además, si proporcionas un código de estado con tu acción deny, el código de estado se ignora.

Las políticas de seguridad del backend tienen el valor opcional de marca type CLOUD_ARMOR. Si no estableces la marca type, el valor predeterminado es CLOUD_ARMOR.

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. No puedes establecer una política de seguridad perimetral como política de backend. Las políticas de seguridad perimetral son compatibles con los siguientes extremos:

  • Balanceador de cargas de aplicaciones externo global
  • Balanceador de cargas de aplicaciones clásico

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 cerca del 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.

Cuando las políticas de seguridad perimetral y de seguridad de backend se vinculan al mismo servicio de backend, estas se aplican solo a las solicitudes de error de caché que pasaron las políticas de seguridad perimetral.

Las políticas de seguridad de Edge se evalúan y aplican antes de Identity-Aware Proxy (IAP). Una solicitud bloqueada por una política de seguridad perimetral se rechaza antes de que IAP evalúe la identidad del solicitante. El bloqueo de una solicitud con una regla en la política de seguridad perimetral impide que IAP entregue una página de acceso o intente autenticar al usuario de otra manera.

Las políticas de seguridad de Edge tienen el valor de la marca type CLOUD_ARMOR_EDGE.

Políticas de seguridad perimetral de red

Las políticas de seguridad de perímetro de red te permiten configurar reglas para bloquear el tráfico en el período de la red de Google. La aplicación forzosa de las políticas de seguridad perimetral de red no consume recursos de VM ni de host, lo que ayuda a evitar que el tráfico de alto volumen agote los recursos de la carga de trabajo de destino o, de lo contrario, cause una denegación de servicio. Puedes configurar políticas de seguridad de red perimetral para los siguientes recursos:

  • Balanceadores de cargas de red de transferencia externos
  • Reenvío de protocolos
  • VM con direcciones IP públicas

Las políticas de seguridad perimetral de red admiten el filtrado basado en algunos de los mismos parámetros que las políticas de seguridad de backend y son el único tipo de política de seguridad que admite el filtrado de offset de bytes. Consulta la tabla Tipos de políticas de seguridad para obtener una lista completa de los parámetros disponibles.

Las políticas de seguridad perimetral de red tienen el valor de marca type CLOUD_ARMOR_NETWORK. Para configurar políticas de seguridad perimetral de red, primero debes configurar la protección avanzada contra DSD de red en la región en la que deseas crear las políticas. Para obtener más información sobre la protección avanzada DSD, consulta Configura la protección avanzada contra DSD de red.

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. Ten en cuenta que las acciones de redirect y las acciones de inserción de encabezado personalizado solo funcionan durante la fase de procesamiento del encabezado. Si la acción redirect coincide durante la siguiente fase de procesamiento del cuerpo, se traduce en una acción deny. Si coincide durante la fase de procesamiento del cuerpo, la acción de encabezado de solicitud personalizado no se aplica.

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. Google Cloud Armor inspecciona los primeros 8 KB del cuerpo POST. Para obtener más información sobre esta limitación, consulta Limitación de inspección del cuerpo de POST.

La expresión evaluatePreconfiguredExpr() para las reglas preconfiguradas es la única expresión que se evalúa en función del cuerpo de la solicitud. Todas las demás expresiones se evalúan solo de acuerdo con el encabezado de la solicitud. Entre los tipos de solicitudes HTTP con un cuerpo de solicitud, Google Cloud Armor solo procesa solicitudes POST. La inspección se limita a los primeros 8 KB del cuerpo POST y se decodifica como parámetros de consulta URL. Google Cloud Armor puede analizar y aplicar reglas de WAF preconfiguradas para cuerpos de POST con formato JSON (Content-Type = "application/json"). Sin embargo, Google Cloud Armor no admite otros decodificadores HTTP basados en el tipo de contenido o la codificación del contenido, como XML, Gzip o UTF-16.

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 deny, pero puedes cambiarla a allow.

Huella digital

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 aplicación 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 hasta 5 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

Google Cloud Armor tiene los siguientes 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 o un rango de CIDR de origen para que no accedan a balanceadores de cargas compatibles.

  • La lista de entidades permitidas de direcciones IP o CIDR te permite aceptar que una dirección IP o un rango de CIDR de origen accedan a los balanceadores de cargas compatibles.

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

  • 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 de geografía de origen

Puedes permitir o rechazar solicitudes que se originaron en áreas geográficas seleccionadas que define el código de país Unicode.

Google Cloud Armor usa nuestra propia base de datos de ubicación geográfica de IP para identificar la ubicación geográfica de la solicitud. La base de datos se actualiza con regularidad. Si bien no podemos garantizar una cadencia de actualización en particular, durante las operaciones normales, las asignaciones que usa Google Cloud Armor se actualizan aproximadamente una vez a la semana.

Las asignaciones actualizadas deben propagarse a la infraestructura de Google de forma global. El proceso de lanzamiento ocurre de forma gradual, por lo general, durante varios días en varias zonas y regiones en las que se implementa Google Cloud Armor. Debido a este proceso de lanzamiento gradual, es posible ver que las solicitudes de la misma dirección IP de origen se manejan de forma inconsistente durante un lanzamiento cuando la dirección IP de origen tiene un cambio en la asignación de ubicación geográfica.

Reglas de WAF preconfiguradas

Google Cloud Armor proporciona una lista completa de reglas de WAF preconfiguradas basadas en el conjunto de reglas principales (CRS) de ModSecurity de OWASP para ayudarte a detectar los siguientes ataques:

  • Ataques de inyección de SQL
  • Ataques de secuencias de comandos entre sitios
  • Ataques de inclusión de archivos locales
  • Ataques de inclusión de archivos remotos
  • Ataques de ejecución de código remoto
  • Ataques de aplicación de métodos
  • Ataques de detección de análisis
  • Ataques de protocolo
  • Ataques de inserción de PHP
  • Ataques de corrección de sesión
  • Ataques de Java
  • Ataques de NodeJS

Para obtener más información, consulta la descripción general de las reglas de WAF preconfiguradas de Google Cloud Armor.

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 con desafíos manuales opcionales
  2. Evaluar los tokens de reCAPTCHA 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.

Cuando se usa el límite de frecuencia con balanceadores de cargas de red de proxy externo global o de proxy clásico, se aplican las siguientes restricciones:

  • Google Cloud Armor solo aplica acciones de límite de frecuencia, como la regulación o el bloqueo de las solicitudes de conexión nuevas de los clientes.
  • Solo se admiten los tipos de claves ALL y IP.
  • Si intentas usar el tipo de clave HTTP-HEADER o HTTP-COOKIE con balanceadores de cargas TCP/SSL, el tipo de clave se interpreta como ALL y, de la misma manera, XFF-IP se interpreta como IP.

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. Se te cobra la tarifa normal por solicitud para las reglas en el modo de vista previa.

Puedes habilitar el modo de vista previa de una regla con la CLI de Google Cloud y la marca --preview de gcloud compute security-policies rules update.

Para inhabilitar el modo de vista previa, usa la marca --no-preview. También puedes usar la consola de Google Cloud.

Si una solicitud activa una vista previa, Google Cloud Armor continuará evaluando otras reglas hasta que encuentre una coincidencia. La regla coincidente y la de vista previa estarán disponibles en los registros.

Respuestas de error personalizadas

Cuando usas un balanceador de cargas de aplicaciones externo global, puedes configurar respuestas de error personalizadas para los códigos de estado HTTP de los errores que generan los balanceadores de cargas o las instancias de backend. Además, puedes configurar códigos de error personalizados para el tráfico que Google Cloud Armor rechaza configurando páginas de respuesta personalizadas para los mismos códigos de error de la serie 4XX o 5XX que usan las reglas de tu política de seguridad existente.

Para obtener más información sobre las respuestas de error personalizadas, consulta la descripción general de las respuestas de error personalizadas. Para ver los pasos de configuración, consulta Configura respuestas de error personalizadas.

Logging

Google Cloud Armor tiene un registro extenso y te permite definir lo detallado que es el registro. Los registros de Google Cloud Armor se generan en función de la primera regla (de mayor prioridad) que coincide con una solicitud entrante, independientemente de si la política de seguridad está en modo de vista previa. Esto significa que no se generan registros para las reglas que no coinciden ni para las que coinciden con prioridades más bajas.

Para obtener información completa sobre el registro, consulta Usa el registro de solicitudes. Para obtener más información sobre el registro detallado, consulta Registro detallado. Para ver los registros de Google Cloud Armor, consulta Visualiza registros.

Registro de solicitudes del balanceador de cargas de aplicaciones externo

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 balanceador de cargas de aplicaciones externo.

Registro de solicitudes del balanceador de cargas de red de proxy externo

Puedes configurar el registro de los balanceadores de cargas de red del proxy externo con los comandos de Google Cloud CLI como se indica en Registro y supervisión del balanceo de cargas del proxy TCP/SSL. No puedes habilitar el registro para los balanceadores de cargas de red de proxy externos con la consola de Google Cloud.

Limitaciones

En las siguientes secciones, se detallan las limitaciones para las políticas de seguridad.

Limitación de la inspección del cuerpo de POST y PATCH

La expresión evaluatePreconfiguredWaf() para las reglas preconfiguradas es la única expresión que Google Cloud Armor evalúa en función del cuerpo de la solicitud. Entre los tipos de solicitudes HTTP con un cuerpo de solicitud, Google Cloud Armor solo procesa solicitudes POST y PATCH.

La inspección se limita a los primeros 8 KB del cuerpo POST o PATCH, que se decodifican como parámetros de consulta de URL. El resto del cuerpo de la solicitud puede contener un código malicioso, que la aplicación podría aceptar. Para mitigar el riesgo de cuerpos de solicitud cuyo tamaño supera los 8 KB, consulta la guía de solución de problemas.

Google Cloud Armor puede analizar y aplicar reglas de WAF preconfiguradas para cuerpos de POST y PATCH con codificación URL y formato JSON predeterminados (Content-Type = "application/json"), en cuyo caso las reglas se aplican de forma independiente en los nombres decodificados y valores en los datos. Para otros tipos de contenido y tipos de codificación, Google Cloud Armor no decodifica los datos, pero aplica las reglas preconfiguradas a los datos sin procesar.

Cómo se manejan las conexiones de WebSocket

Los balanceadores de cargas de aplicaciones externos globales tienen compatibilidad integrada con el protocolo 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?