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 tu aplicación proporcionando datos de capa 7 mediante el filtrado y el borrado de las solicitudes entrantes para ataques web comunes u otros ataques para bloquear el tráfico antes de que llegue a las cargas servicios de backend o 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 están disponibles para las siguientes cargas del balanceador de cargas y los extremos:
- 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:
- Grupos de instancias
- Grupos de extremos de red (NEG) zonales
- NEG sin servidores: Uno o más servicios de App Engine, Cloud Run o Cloud Functions
- NEG de Internet para backends externos
- Buckets en Cloud Storage
Cuando usas Google Cloud Armor para proteger una implementación híbrida o una backend, 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 a balanceadores de cargas de red de transferencia externos, el reenvío de protocolos y las VMs 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, rechazar, limitar o redireccionar solicitudes a tus servicios de backend en el perímetro de Google Cloud, lo más cerca posible del origen 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. balanceadores de cargas de aplicaciones clásicos, la Red y los centros de datos de Google.
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
oINTERNAL_MANAGED
. - El protocolo del servicio de backend debe ser
HTTP
,HTTPS
,HTTP/2
,UDP
TCP
,SSL
oUNSPECIFIED
.
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 con él, pero no es necesario que todos tus servicios de backend estén asociados con el con 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
.
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 un ataque de detección del 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 ellos. 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 que expone 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 los servicios de backend que hacen referencia grupos de instancias o grupos de extremos de red (NEG), como Internet, Zonal, NEG 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 la Descripción general de los grupos de extremos de red.
Cuando se usan balanceadores de cargas de red del proxy externos globales o balanceadores de cargas de red del proxy clásico,
Google Cloud Armor aplica la política de seguridad
la acción de la regla deny
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 de backend tienen el valor opcional de la marca type
CLOUD_ARMOR
.
Si no configuras 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. Se implementan y aplican las políticas de seguridad perimetrales cerca del perímetro más externo de la red de Google, en sentido ascendente reside 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 perimetral se evalúan y aplican 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 evita que IAP entregue una página de acceso o intente autenticar al usuario.
Las políticas de seguridad perimetral tienen el valor de la marca type
CLOUD_ARMOR_EDGE
.
Políticas de seguridad perimetral de red
Las políticas de seguridad perimetral de red permiten configurar reglas para bloquear el tráfico en perímetro de la red de Google. Aplicar las políticas de seguridad perimetral de red consumen recursos de VM o de host, lo que ayuda a evitar que el tráfico de alto volumen agotar recursos en la carga de trabajo objetivo o provocar una denegación de servicio. Puedes configurar políticas de seguridad perimetral de red para lo siguiente: 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 según parámetros como políticas de seguridad de backend, y son el único tipo de política para admitir filtrado de desplazamiento de bytes. Recomendar en la tabla Tipos de políticas de seguridad para obtener una lista completa parámetros disponibles.
Las políticas de seguridad perimetral de red tienen el valor de la marca type
CLOUD_ARMOR_NETWORK
.
Para configurar las políticas de seguridad perimetral de red, debes
primero configurarás la protección avanzada contra DSD de red en la región en la que
tienes la intención de crear las políticas. Para obtener más información sobre ataques
protección, 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
. La acción del encabezado de solicitud personalizado, si coincide durante el cuerpo
procesamiento previo, no entra en vigor.
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 POST
con formato JSON
(Content-Type = "application/json"
). Sin embargo, Google Cloud Armor no
admite otros decodificadores de tipo de contenido o codificación de contenido 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 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 creas un
nueva política, 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 el ISO 3166-1 alfa-2 en la nube. 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:
Lista de bloqueo para direcciones IP/CIDR te permite bloquear una dirección IP de origen o un rango de CIDR de el acceso a los balanceadores de cargas admitidos.
En la lista de entidades permitidas para direcciones IP o CIDR, puedes permitir que una fuente Dirección IP o rango CIDR para acceder a los balanceadores de cargas admitidos.
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) o502
(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 según el Conjunto de reglas principales (CRS) de ModSecurity de OWASP para ayudarte a detectar lo siguiente:
- 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:
- Solicitudes de redireccionamiento para la evaluación de reCAPTCHA con desafíos manuales.
- Evalúa los tokens de reCAPTCHA adjuntos a una solicitud y aplícalos la acción configurada según los atributos del token.
- Redireccionar las solicitudes hacia la URL alternativa configurada con una respuesta 302
- 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 usas el límite de frecuencia con balanceadores de cargas de red de proxy externos globales o balanceadores de cargas de red del 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 clave
ALL
yIP
. - Si intentas usar el tipo de clave
HTTP-HEADER
oHTTP-COOKIE
con balanceadores de cargas TCP/SSL, el tipo de clave se interpreta comoALL
y, de la misma manera,XFF-IP
se interpreta comoIP
.
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 de la versión preliminar .
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
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 códigos de estado HTTP para errores que generan los balanceadores de cargas o las instancias de backend generar. Además, puedes configurar códigos de error personalizados para el tráfico que Google Cloud Armor rechaza mediante la configuración de páginas de respuesta personalizadas para el mismo Códigos de error de serie 4xx o 5xx que reglas de tu política de seguridad existente usar.
Para obtener más información sobre las respuestas de error personalizadas, consulta el Descripción general de la respuesta de error personalizada. Para conocer los pasos de configuración, consulta Configura respuestas de error personalizadas.
Logging
Google Cloud Armor tiene un registro extenso y te permite definir qué tan se encuentran los registros. Para obtener información completa sobre los registros, consulta Usa el registro de solicitudes. Para obtener más información registro detallado, consulta Registro detallado.
Para ver los registros de Google Cloud Armor, consulta Visualiza los 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 del proxy externo
Puedes configurar el registro de balanceadores de cargas de red del proxy externos de la siguiente manera: con los comandos de Google Cloud CLI como se muestra Registro y supervisión del balanceo de cargas del proxy TCP/SSL. No puedes habilitar el registro de 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
La expresión evaluatePreconfiguredExpr()
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 solicitud HTTP con un cuerpo de solicitud, solo Google Cloud Armor procesa
POST
solicitudes.
La inspección se limita a los primeros 8 KB del cuerpo POST
, que se decodifica
como los parámetros de consulta de la URL. El resto del cuerpo POST
puede contener
malicioso, que tu aplicación podría aceptar. Para mitigar el riesgo de
POST
cuyo tamaño supere 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 POST
con codificación URL y formato JSON (Content-Type = "application/json"
),
en cuyo caso las reglas se aplican de forma independiente a los nombres y valores decodificados de
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 en el canal no cumplen con el protocolo HTTP Google Cloud Armor no evalúa ningún mensaje después de la primera solicitud.
¿Qué sigue?
- Configura, reglas, expresiones y políticas de seguridad
- Obtén información sobre las funciones de los niveles de Cloud Armor Enterprise
- Más información sobre las listas de direcciones IP con nombre
- Soluciona problemas