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

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

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

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 Trusted 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 Trusted 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_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.

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

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

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 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 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 Trusted 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.

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
• Solucionar problemas de Cloud Armor