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 Trusted Cloud by S3NS implementaciones.

Las políticas de seguridad de Cloud Armor están disponibles para los balanceadores de cargas de aplicaciones externos regionales.

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

• Grupos de instancias
• Todos los tipos de grupos de extremos de red (NEG) admitidos por tu balanceador de cargas

Cuando usas Cloud Armor para proteger una implementación híbrida o una arquitectura de múltiples nubes, los backends deben ser NEG de Internet o NEG híbridos. Cloud Armor también protege los NEG sin servidores cuando el tráfico se enruta a través de un balanceador de cargas. Si deseas obtener información para enrutar el tráfico a través de tu balanceador de cargas antes de que llegue a tu NEG sin servidores, consulta Controles de entrada.

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

Las políticas de seguridad de Cloud Armor te permiten permitir, denegar, limitar la frecuencia o redireccionar las solicitudes a tus servicios de backend en el Trusted Cloud perímetro, 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).

Requisitos

• El esquema de balanceo de cargas del servicio de backend debe ser EXTERNAL_MANAGED.
• El protocolo del servicio de backend debe ser 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 coinciden con los atributos de las redes de capa 3 a capa 7 para proteger las aplicaciones o los servicios externos. Cada regla se evalúa con respecto al tráfico entrante.

Una regla de política de seguridad de Cloud Armor consiste en una condición de coincidencia y una acción que se realiza cuando se cumple 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 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 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 política de seguridad, Cloud Armor permite, rechaza o redirecciona la solicitud, en función de si la regla es de permiso, de denegación o de redireccionamiento.

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

Un servicio de backend puede tener dos políticas de seguridad a nivel del servicio asociadas al mismo tiempo, pero no puede tener dos políticas de seguridad de backend ni dos políticas de seguridad perimetral al mismo tiempo. Sin embargo, no todos tus servicios de backend deben estar asociados a las mismas políticas de seguridad. Para adjuntar y quitar políticas de seguridad de las funciones y los servicios de backend compatibles, consulta Cómo 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 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 el siguiente diagrama, la política de seguridad de Cloud Armor internal-users-policy está asociada con el servicio de backend test-network.

• De forma opcional, puedes usar el protocolo QUIC con balanceadores de cargas que usen Cloud Armor.

• 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 balanceadores de cargas de aplicaciones externos regionales.

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 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 a nivel del 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

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

Políticas de seguridad de servicios internos

Las políticas de seguridad del servicio interno te permiten configurar la límite de frecuencia de fairshare con Cloud Service Mesh. En lugar de adjuntar una política de seguridad del servicio interno a un servicio de backend o a un bucket de backend, la adjuntas a una política de extremos de Cloud Service Mesh. Para obtener más información sobre las políticas de seguridad del servicio interno, consulta Configura el límite 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 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.

Los números de prioridad pueden tener brechas. Estas brechas te permiten agregar o quitar reglas en el futuro sin afectar el resto de las reglas. Por ejemplo, 1, 2, 3, 4, 5, 9, 12 y 16 es una serie válida de números de prioridad a la que puedes agregar 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 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 con un cuerpo se evalúan en función de reglas preconfiguradas que usan evaluatePreconfiguredWaf. La excepción es la siguiente:

Para las solicitudes HTTP POST, Cloud Armor recibe el encabezado de la solicitud antes del cuerpo (carga útil). Debido a que 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, 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 aplicará.

Después de que Cloud Armor recibe la solicitud HTTP POST con un cuerpo, 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 que contiene contenido potencialmente malicioso esté bloqueado. Cloud Armor inspecciona hasta 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 Limitación de inspección del cuerpo de POST y PATCH.

La expresión evaluatePreconfiguredWaf() 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, Cloud Armor solo procesa solicitudes POST y PATCH. La inspección se limita al límite de inspección configurado, hasta los primeros 64 KB (ya sean 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 de POST con formato JSON (Content-Type = "application/json"). Sin embargo, Cloud Armor no admite otros decodificadores basados en la codificación de contenido o el tipo 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 una dirección IP 9.9.9.1 inicia un ataque XSS en el cuerpo de HTTP POST, solo se bloquea el cuerpo (según la regla 2); el encabezado de HTTP pasa al backend (según la regla 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: 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 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: 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 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 sí modificarla. La acción predeterminada para 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 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. Cloud Armor proporciona atributos del lenguaje de reglas personalizadas 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

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:

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

• Si agregas una dirección IP o un rango de CIDR a una lista de bloqueo, puedes impedir que una dirección IP o un rango de CIDR de origen accedan a los balanceadores de cargas compatibles.

• Agregar una dirección IP o un rango de CIDR a una lista de entidades permitidas 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 devolver un código de estado HTTP 403 Unauthorized, 404 Access Denied o 502 Bad Gateway.

• Si superas las reglas de acción, se puede mostrar un código de estado HTTP 429 Too Many Requests.

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.

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 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 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 asignación de ubicación geográfica para la dirección IP de origen cambió.

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 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 Cloud Armor.

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 del proxy externos globales o balanceadores de cargas de red del proxy clásicos, se aplican las siguientes restricciones:

• 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 la Descripción general del límite de frecuencia.

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 modo de vista previa.

Puedes habilitar el modo de vista previa de una regla con 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 consola deTrusted Cloud .

Si una solicitud activa una vista previa, Cloud Armor continuará evaluando otras reglas hasta que encuentre una coincidencia. La regla coincidente y la de vista previa está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 Cloud Armor rechaza configurando páginas de respuesta personalizadas para los mismos códigos de estado de la serie 4xx o la serie 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 la respuesta de error personalizada. Para ver los pasos de configuración, consulta Configura respuestas de error personalizadas.

Logging

Cloud Armor tiene un registro extenso y te permite definir lo detallado que es el registro. Los registros de 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 reglas 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 Cloud Armor, consulta Visualiza registros.

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 Cloud Armor evalúa en función del cuerpo de la solicitud. Entre los tipos de solicitudes HTTP con un cuerpo de solicitud, Cloud Armor solo procesa solicitudes POST y PATCH.

La inspección se limita al límite de inspección configurado, hasta los primeros 64 KB (ya sean 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 para el cuerpo de la solicitud cuando se usan reglas de WAF preconfiguradas, consulta Actualiza el límite de inspección para las reglas de WAF preconfiguradas.

El resto del cuerpo de la solicitud puede contener cargas útiles que coincidan con la firma de una regla del WAF, que la aplicación podría aceptar. Para mitigar el riesgo de cuerpos de solicitud cuyo tamaño supera 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 Mitiga el riesgo en el cuerpo de la solicitud que supera el límite de inspección configurado.

Cloud Armor puede analizar y aplicar reglas de WAF preconfiguradas para cuerpos de POST y PATCH predeterminados con codificación URL y formato JSON (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, Cloud Armor no decodifica los datos, sino que 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). 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 Cloud Armor no evalúa ningún mensaje después de la primera solicitud.

¿Qué sigue?

• Configura las políticas de seguridad de Cloud Armor
• Soluciona problemas de Cloud Armor