Información general sobre 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 Cloud Armor están disponibles para los siguientes tipos de balanceadores de carga y endpoints:

• Todos los balanceadores de carga de aplicación externos, incluidos los clásicos
• Balanceador de carga de aplicación interno regional
• Balanceador de carga de red con proxy externo global (TCP/SSL)
• Balanceador de carga de red de proxy clásico (TCP/SSL)
• Balanceador de carga de red de paso a través externo (TCP/UDP)
• Reenvío de protocolos externos
• Máquinas virtuales con direcciones IPv4 externas o intervalos de direcciones IPv6 externas asignados a una interfaz de red (NIC)

El balanceador de carga puede estar en el nivel Premium o Standard.

Los backends del servicio de backend pueden ser cualquiera de los siguientes:

• Grupos de instancias
• Todos los tipos de grupos de puntos finales de red (NEG) admitidos por tu balanceador de carga
• Segmentos de Cloud Storage

Cuando usas Cloud Armor para proteger un despliegue híbrido o una arquitectura multinube, los back-ends deben ser NEGs de Internet o NEGs híbridos. Cloud Armor también protege las NEGs sin servidor cuando el tráfico se enruta a través de un balanceador de carga. Para obtener información sobre cómo enrutar el tráfico a través de tu balanceador de carga antes de que llegue a tu NEG sin servidor, consulta Controles de entrada.

Protege tus Google Cloud despliegues con políticas de seguridad de Cloud Armor

Las políticas de seguridad de Cloud Armor te permiten permitir, denegar, limitar la frecuencia o redirigir solicitudes a tus servicios de backend en el Google Cloud borde, lo más cerca posible de la fuente del tráfico entrante. De esta forma, se evita que el tráfico no deseado consuma recursos o entre en tus redes de nube privada virtual (VPC).

Requisitos

• El esquema de balanceo de carga del servicio de backend debe ser EXTERNAL, EXTERNAL_MANAGED o INTERNAL_MANAGED.
• El protocolo del servicio de backend debe ser uno de los siguientes: HTTP, HTTPS, HTTP/2, UDP, TCP, SSL o UNSPECIFIED.

Acerca de las políticas de seguridad de Cloud Armor

Las políticas de seguridad de Cloud Armor son conjuntos de reglas que se aplican a atributos de redes de las capas 3 a 7 para proteger aplicaciones o servicios orientados al exterior. Cada regla se evalúa en relación con el tráfico entrante.

Una regla de política de seguridad de Cloud Armor consta de una condición de coincidencia y una acción que se debe llevar a cabo cuando se cumpla esa condición. Por ejemplo, una condición puede ser si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un intervalo CIDR específicos (también conocidos como reglas de lista de permitidas y de denegadas de direcciones IP). También puedes usar la referencia del lenguaje de reglas personalizadas de Cloud Armor para crear condiciones personalizadas que coincidan con varios atributos del tráfico entrante, como la ruta de la URL, el método de solicitud o los valores del encabezado de solicitud.

Cuando una solicitud entrante coincide con una condición de una regla de política de seguridad, Cloud Armor permite, deniega o redirige la solicitud en función de si la regla es de permiso, de denegación o de redirección. Se pueden aplicar parámetros de acción adicionales, como insertar encabezados de solicitud. Esta función forma parte de la gestión de bots de Cloud Armor. Para obtener más información sobre la gestión de bots, consulta el resumen de la gestión de bots.

Cloud Armor ofrece dos categorías de políticas de seguridad: políticas de seguridad jerárquicas y políticas de seguridad a nivel de servicio. Las políticas de seguridad jerárquicas se adjuntan a nivel de organización, carpeta o proyecto, mientras que las políticas de seguridad a nivel de servicio se asocian a uno o varios servicios de backend. Para obtener más información sobre las políticas de seguridad jerárquicas, consulta el artículo Descripción general de las políticas de seguridad jerárquicas.

Un servicio de backend puede tener dos políticas de seguridad a nivel de servicio asociadas al mismo tiempo, pero no puede tener dos políticas de seguridad de backend ni dos políticas de seguridad de perímetro al mismo tiempo. Sin embargo, no es necesario que todos tus servicios de backend estén asociados a las mismas políticas de seguridad. Para adjuntar y quitar políticas de seguridad de los servicios y las funciones de backend compatibles, consulta Adjuntar y quitar políticas de seguridad.

Si una política de seguridad de Cloud Armor está asociada a algún servicio de backend, no se puede eliminar. Un servicio de backend se puede eliminar independientemente de 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 llega a cada una de las direcciones IP de las reglas de reenvío.

En el siguiente diagrama, la política de seguridad de Cloud Armor internal-users-policy está asociada al servicio de backend test-network.

• También puedes usar el protocolo QUIC con balanceadores de carga que usen Cloud Armor.

• Puedes usar Cloud Armor con balanceadores de carga que estén en cualquiera de los siguientes niveles de servicio de red:

  • Nivel premium
  • Nivel Estándar

• Puedes usar 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 umbral especificado por el usuario al configurar uno de los siguientes balanceadores de carga:

  • Balanceador de carga de aplicación externo global
  • Balanceador de carga de aplicación clásico
  • Balanceador de carga de aplicación externo regional
  • Balanceador de carga de aplicación interno regional
  • Balanceador de carga de red con proxy externo global (TCP/SSL)
  • Balanceador de carga de red de proxy clásico (TCP/SSL)

Además, puede configurar reglas de WAF preconfiguradas de Google Cloud Armor, que son reglas de cortafuegos de aplicación web (WAF) complejas con decenas de firmas que se compilan a partir de los estándares de software libre del sector. Cada firma corresponde a una regla de detección de ataques del conjunto de reglas. Google ofrece estas reglas tal cual. Las reglas permiten a Cloud Armor evaluar docenas de firmas de tráfico distintas haciendo referencia a reglas con nombres prácticos, en lugar de requerir que definas cada firma manualmente. 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 a nivel de servicio 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

• Balanceador de carga de aplicación externo global
• Balanceador de carga de aplicación clásico
• Balanceador de carga de aplicación externo regional
• Balanceador de carga de aplicación interno regional
• Balanceador de carga de red con proxy externo global
• Balanceador de carga de red de proxy clásico

Las políticas de seguridad de backend se usan para filtrar solicitudes y proteger los servicios de backend que hacen referencia a grupos de instancias o a cualquiera de los tipos de NEG admitidos que se encuentran detrás de los tipos de balanceadores de carga que se han indicado anteriormente. Para obtener más información sobre los NEGs que admite tu balanceador de carga, consulta la información general sobre los grupos de puntos finales de red.

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

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

Políticas de seguridad de Edge

Las políticas de seguridad perimetral permiten a los usuarios configurar políticas de filtrado y control de acceso para el contenido almacenado en caché, incluidos los endpoints como los servicios de backend habilitados para Cloud CDN y los segmentos de Cloud Storage. Las políticas de seguridad de Edge admiten el filtrado basado en un subconjunto de parámetros en comparación con las políticas de seguridad de backend. No puedes definir una política de seguridad de edge como política de backend. Las políticas de seguridad de Edge se admiten en los siguientes endpoints:

• Balanceador de carga de aplicación externo global
• Balanceador de carga de aplicación clásico

Las políticas de seguridad perimetral se pueden configurar para filtrar las solicitudes antes de que se sirvan 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, antes de la ubicación de la caché de Cloud CDN. Las políticas de seguridad de Edge pueden coexistir con las políticas de seguridad de backend para proporcionar dos capas de protección. Se pueden aplicar simultáneamente a un servicio de backend, independientemente de los recursos a los que apunte el servicio de backend (por ejemplo, grupos de instancias o grupos de puntos finales de red). Solo se pueden aplicar políticas de seguridad perimetrales a los backend buckets.

Cuando las políticas de seguridad perimetrales y las políticas de seguridad de backend se adjuntan al mismo servicio de backend, las políticas de seguridad de backend solo se aplican a las solicitudes de fallos de caché que hayan superado las políticas de seguridad perimetrales.

Las políticas de seguridad perimetral se evalúan y se aplican antes que Identity-Aware Proxy (IAP). Una solicitud bloqueada por una política de seguridad perimetral se deniega antes de que IAP evalúe la identidad del solicitante. Si se bloquea una solicitud con una regla en la política de seguridad perimetral, se impide que IAP muestre una página de inicio de sesión o intente autenticar al usuario de otro modo.

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

Políticas de seguridad de perímetro de red

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

• Balanceadores de carga de red de paso a través externos
• Reenvío de protocolos
• VMs con direcciones IP públicas

Las políticas de seguridad de borde 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 por desplazamiento de bytes. Para ver una lista completa de los parámetros disponibles, consulta la tabla Tipos de políticas de seguridad.

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

Políticas de seguridad de servicios internos

Las políticas de seguridad de servicios internos te permiten configurar la limitación de la frecuencia de uso compartido con Cloud Service Mesh. En lugar de adjuntar una política de seguridad de servicio interno a un servicio de backend o a un segmento de backend, la adjuntas a una política de endpoint de Cloud Service Mesh. Para obtener más información sobre las políticas de seguridad de los servicios internos, consulta Configurar la limitación de frecuencia con Cloud Armor en la documentación de Cloud Service Mesh.

Orden de evaluación de reglas

El orden de evaluación de las reglas se determina por la prioridad de la regla, 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 de cada regla debe ser un número entre 0 y 2147483646 (ambos incluidos). El valor de prioridad 2147483647, también conocido como INT-MAX, se reserva para la regla predeterminada.

Los números de prioridad pueden tener huecos. Estos espacios te permiten añadir o quitar reglas en el futuro sin que afecte al 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 puede añadir reglas numeradas del 6 al 8, del 10 al 11 y del 13 al 15 en el futuro. No es necesario que cambies las reglas, solo el orden de ejecución.

Normalmente, se aplica la regla de mayor prioridad que coincida con la solicitud. Sin embargo, hay una excepción cuando las solicitudes HTTP POST con un cuerpo se evalúan en función de reglas preconfiguradas que usan evaluatePreconfiguredWaf. La excepción es la siguiente:

En las solicitudes HTTP POST, Cloud Armor recibe el encabezado de la solicitud antes del cuerpo (carga útil). Como Cloud Armor recibe primero la información de la cabecera, evalúa las reglas que coinciden con la cabecera, pero no coincide con ninguna regla preconfigurada en el cuerpo. Si hay varias reglas basadas en encabezados, Cloud Armor las evalúa según su prioridad, como es habitual. Ten en cuenta que las acciones redirect y la inserción de acciones de encabezado personalizadas solo funcionan durante la fase de procesamiento del encabezado. La acción redirect, si coincide durante la siguiente fase de procesamiento del cuerpo, se traduce en una acción deny. La acción del encabezado de solicitud personalizado no se aplica si se encuentra una coincidencia durante la fase de procesamiento del cuerpo.

Cuando Cloud Armor recibe la solicitud HTTP POST con un cuerpo, evalúa las reglas que se aplican tanto a los encabezados como al cuerpo de la solicitud. Por lo tanto, es posible que se apliquen reglas de menor prioridad que permiten el encabezado de una solicitud antes que reglas de mayor prioridad 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 backend de destino, pero que se bloquee el cuerpo que contiene contenido potencialmente malicioso. Cloud Armor inspecciona los primeros 64 kB (según el límite de inspección configurado de 8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del cuerpo de la solicitud. Para obtener más información sobre esta limitación, consulta el artículo Limitación de la inspección del cuerpo de las solicitudes POST y PATCH.

La expresión evaluatePreconfiguredWaf() de las reglas preconfiguradas es la única que se evalúa en el cuerpo de la solicitud. Todas las demás expresiones se evalúan solo con respecto al encabezado de la solicitud. De los tipos de solicitudes HTTP con un cuerpo de solicitud, Cloud Armor solo procesa las solicitudes POST y PATCH. La inspección se limita al límite de inspección configurado, hasta los primeros 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del cuerpo de la solicitud, y se decodifica como parámetros de consulta de URL. Cloud Armor puede analizar y aplicar reglas de WAF preconfiguradas para cuerpos POST con formato JSON (Content-Type = "application/json"). Sin embargo, Cloud Armor no admite otros decodificadores basados en Content-Type o Content-Encoding de HTTP, 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 una dirección IP 9.9.9.1 lanza un ataque XSS en el HTTP POST cuerpo, solo se bloquea el cuerpo (por la regla 2); el HTTP encabezado se envía al backend (por la regla 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('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 IP 9.9.9.1 sin analizarlo para detectar 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: evaluatePreconfiguredWaf('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Regla predeterminada

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

No puedes eliminar la regla predeterminada, pero sí puedes modificarla. La acción predeterminada de la regla predeterminada es deny, pero puedes cambiarla a allow.

Huella digital

Cada política de seguridad de Cloud Armor tiene un campo fingerprint. La huella digital es un hash del contenido almacenado en la política. Cuando cree una política, no indique el valor de este campo. Si proporciona un valor, se ignora. Sin embargo, cuando actualizas una política de seguridad, debes especificar la huella actual, que obtienes al exportar o describir la política (con EXPORT o DESCRIBE, respectivamente).

La huella digital te protege para que no se sobrescriba la actualización de otro usuario. Si la huella digital que proporcionas no está actualizada, significa que la política de seguridad se actualizó desde la última vez que obtuviste la huella digital. Para comprobar si hay diferencias y obtener la huella digital más reciente, ejecuta el comando DESCRIBE.

Lenguaje de reglas y motor de cumplimiento

El lenguaje de reglas y el motor de aplicación proporcionan lo siguiente:

• Posibilidad de escribir expresiones de reglas personalizadas que puedan coincidir con varios atributos de las capas 3 a 7 de las solicitudes entrantes. Cloud Armor proporciona atributos de lenguaje de reglas personalizadas para escribir condiciones de coincidencia personalizadas.

• La posibilidad de combinar hasta 5 subexpresiones en una sola regla.

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

Tipos de reglas

Cloud Armor tiene los siguientes tipos de reglas.

Reglas de listas de direcciones IP permitidas y denegadas

Puedes crear reglas de listas de permitidas y de denegadas de direcciones IP en una política de seguridad. Estos son algunos ejemplos:

Puedes crear reglas de listas de permitidos y de denegación de direcciones IP en una política de seguridad. Estos son algunos ejemplos:

• Si añades una dirección IP o un intervalo CIDR a una lista de denegación, podrás bloquear el acceso a balanceadores de carga compatibles desde una dirección IP o un intervalo CIDR de origen.

• Si añades una dirección IP o un intervalo CIDR a una lista de permitidas, podrás permitir que una dirección IP o un intervalo CIDR de origen accedan a los balanceadores de carga admitidos.

• Se admiten direcciones IPv4 e IPv6 en las reglas de listas de permitidas y de denegadas.

• Las reglas de denegación pueden devolver un código de estado HTTP 403 Unauthorized, 404 Access Denied o 502 Bad Gateway.

• Las reglas de acción de superación pueden devolver un código de estado HTTP 429 Too Many Requests.

Reglas de geografía de la fuente

Puede permitir o denegar las solicitudes que procedan de zonas geográficas seleccionadas definidas por el código de país Unicode.

Cloud Armor usa nuestra propia base de datos de geolocalización de IPs para identificar la ubicación geográfica de la solicitud. La base de datos se actualiza periódicamente. Aunque no podemos garantizar una cadencia de actualización concreta, durante las operaciones normales, las asignaciones que usa Cloud Armor se actualizan aproximadamente una vez a la semana.

Las asignaciones actualizadas deben propagarse a la infraestructura de Google en todo el mundo. El proceso de lanzamiento se lleva a cabo de forma gradual, normalmente durante varios días, en varias zonas y regiones en las que se ha implementado Cloud Armor. Debido a este proceso de lanzamiento gradual, es posible que las solicitudes de la misma dirección IP de origen se gestionen de forma incoherente durante un lanzamiento cuando haya cambiado la asignación de geolocalización de la dirección IP de origen.

Reglas de WAF preconfiguradas

Cloud Armor proporciona una lista completa de reglas de WAF preconfiguradas basadas en el conjunto de reglas principales (CRS) de OWASP para ayudarte a detectar lo siguiente:

• Ataques de inyección SQL
• Ataques de cross-site scripting
• Ataques de inclusión de archivos locales
• Ataques de inclusión de archivos remotos
• Ataques de ejecución remota de código
• Ataques de cumplimiento de métodos
• Ataques de detección de escáneres
• Ataques de protocolo
• Ataques de inyección de PHP
• Ataques de fijació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 Cloud Armor.

Reglas de gestión de bots

Puede usar reglas de gestión de bots para hacer lo siguiente:

1. Redirige las solicitudes de evaluación de reCAPTCHA con retos manuales opcionales.
2. Evalúa los tokens de reCAPTCHA adjuntos a una solicitud y aplica la acción configurada en función de los atributos del token.
3. Redirige las solicitudes a la URL alternativa que hayas configurado con un código de estado 302.
4. Inserta encabezados personalizados en las solicitudes antes de enviarlas a tus back-ends a través de un proxy.

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

Reglas preconfiguradas para listas de direcciones IP con nombre

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

• Integra listas de direcciones IP con nombre de proveedores externos con Cloud Armor.

• Simplifica el mantenimiento de los intervalos de direcciones IP permitidas o denegadas.

• Sincronizar las listas de proveedores externos a diario.

• Aumenta tu capacidad para configurar direcciones y rangos de IP en políticas de seguridad, ya que las listas de direcciones IP con nombre no están sujetas a límites en el número de direcciones IP por regla.

Reglas de limitación de frecuencia

Puede usar reglas de limitación de frecuencia para hacer lo siguiente:

• Limita las solicitudes por cliente en función de un umbral que configures.
• Banea temporalmente a los clientes que superen un umbral de solicitudes que hayas definido durante un periodo configurado.

Cuando usas la limitación de frecuencia con balanceadores de carga de red con proxy externo global o balanceadores de carga de red con proxy clásicos, se aplican las siguientes restricciones:

• Cloud Armor solo aplica acciones de limitación de frecuencia, como la limitación o la prohibición, en las nuevas solicitudes de conexión de los clientes.
• Solo se admiten los tipos de clave ALL y IP.
• Si intentas usar el tipo de clave HTTP-HEADER o HTTP-COOKIE con balanceadores de carga TCP/SSL, el tipo de clave se interpreta como ALL y, del mismo modo, XFF-IP se interpreta como IP.

Para obtener más información sobre la limitación de la frecuencia y cómo funciona, consulta la descripción general de la limitación de la frecuencia.

Para obtener más información sobre la limitación de la frecuencia y cómo funciona, consulta la descripción general de la limitación de la frecuencia.

Modo de vista previa

Puedes previsualizar los efectos de una regla sin aplicarla. En el modo de vista previa, las acciones se registran en Cloud Monitoring. Puedes obtener una vista previa de reglas concretas de una política de seguridad o de todas las reglas de la política. Se te cobrará la tarifa normal por solicitud de las reglas en modo de vista previa.

Para habilitar el modo de vista previa de una regla, puedes usar Google Cloud CLI y la marca --preview del comando gcloud compute security-policies rules update.

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

Si una solicitud activa una vista previa, Cloud Armor sigue evaluando otras reglas hasta encontrar una coincidencia. Tanto la regla que coincide como la de vista previa están disponibles en los registros.

Respuestas de error personalizadas

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

Para obtener más información sobre las respuestas de error personalizadas, consulta el resumen de las respuestas de error personalizadas. Para ver los pasos de configuración, consulta Configurar respuestas de error personalizadas.

Almacenamiento de registros

Cloud Armor tiene un registro exhaustivo y te permite definir el nivel de detalle de los registros. Los registros de Cloud Armor se generan en función de la primera regla (la de mayor prioridad) que coincida 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 reglas que coinciden con prioridades inferiores.

Para obtener información completa sobre el registro, consulta Usar el registro de solicitudes. Para obtener más información sobre el registro detallado, consulta Registro detallado. Para ver los registros de Cloud Armor, consulta el artículo sobre cómo ver registros.

Registro de solicitudes del balanceador de carga de aplicación externo

Cada solicitud HTTP(S) que se evalúa con una política de seguridad de Cloud Armor se registra mediante Cloud Logging. Los registros proporcionan detalles como el nombre de la política de seguridad aplicada, la regla coincidente y si se ha aplicado la regla. El registro de solicitudes de los nuevos recursos de servicio de backend está inhabilitado de forma predeterminada. Para registrar las solicitudes de Cloud Armor, debes habilitar el registro de HTTP(S) en cada servicio de backend protegido por una política de seguridad.

Para obtener más información, consulta Registro y monitorización de balanceadores de carga de aplicaciones externos.

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

Puedes configurar el registro de los balanceadores de carga de red de proxy externo mediante los comandos de la CLI de Google Cloud que se indican en Registro y monitorización del balanceo de carga de proxy TCP/SSL. No puedes habilitar el registro de los balanceadores de carga de red de proxy externo mediante la consola Google Cloud .

Limitaciones

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

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

La expresión evaluatePreconfiguredWaf de las reglas preconfiguradas es la única expresión que Cloud Armor evalúa en el cuerpo de la solicitud. De los tipos de solicitudes HTTP con un cuerpo de solicitud, Cloud Armor solo procesa las solicitudes POST y PATCH.

La inspección se limita al límite configurado, hasta los primeros 64 kB (8 kB, 16 kB, 32 kB, 48 kB o 64 kB) del cuerpo de POST o PATCH. Para obtener más información sobre cómo configurar el límite de inspección del cuerpo de la solicitud al usar reglas de WAF preconfiguradas, consulta Actualizar el límite de inspección de reglas de WAF preconfiguradas.

El resto del cuerpo de la solicitud puede contener cargas útiles que coincidan con una firma de regla de WAF, que tu aplicación podría aceptar. Para reducir el riesgo de que el tamaño del cuerpo de la solicitud supere el límite de inspección configurado (hasta los primeros 64 kB, ya sean 8 kB, 16 kB, 32 kB, 48 kB o 64 kB), consulta Reduce el riesgo de que el tamaño del cuerpo de la solicitud supere el límite de inspección configurado.

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

Cómo se gestionan las conexiones WebSocket

Los balanceadores de carga de aplicaciones externos globales tienen compatibilidad integrada con el protocolo WebSocket. Los canales WebSocket se inician a partir de solicitudes HTTP(S). Cloud Armor puede impedir que se establezca un canal WebSocket, por ejemplo, si una lista de denegación de direcciones IP bloquea la dirección IP de origen. Sin embargo, las transacciones posteriores del canal no se ajustan al protocolo HTTP y Cloud Armor no evalúa ningún mensaje después de la primera solicitud.

Siguientes pasos

• Configurar políticas de seguridad de Cloud Armor
• Información sobre las funciones de los niveles Enterprise de Cloud Armor
• Información sobre las listas de direcciones IP con nombre
• Solucionar problemas de Cloud Armor
• Cuotas y límites