Prácticas recomendadas de Google Cloud Armor

En esta página, se proporcionan prácticas recomendadas para optimizar y ajustar las implementaciones de Google Cloud Armor.

Google Cloud Armor se implementa con el balanceador de cargas de aplicaciones externo global, el balanceador de cargas de aplicaciones clásico o el balanceador de cargas de red de proxy externo. Cuando implementas Google Cloud Armor, adjuntas una política de seguridad al servicio de backend del balanceador de cargas que deseas proteger. Una política de seguridad consiste en una colección de reglas preconfiguradas y personalizadas que tú determinas.

Creación de políticas de seguridad y reglas

Las siguientes secciones contienen prácticas recomendadas y sugerencias para las nuevas reglas y políticas de seguridad.

Proporciona descripciones de las reglas

Usa las descripciones de reglas para proporcionar contexto adicional sobre por qué se creó cada regla y la función prevista de la regla. El campo descripción está limitado a 64 caracteres, por lo que las referencias a las bases de datos de administración de configuración o a otros repositorios son la forma más eficiente de capturar contexto.

Considera el espaciado de prioridad

Cuando configures las reglas, deja un intervalo de al menos 10 entre los valores de prioridad de cada regla. Por ejemplo, las dos primeras reglas en una política de seguridad podrían tener prioridades 20 y 30. Esto te permite insertar más reglas cuando las necesites. Además, recomendamos que agrupes las reglas similares en bloques, lo que deja intervalos más grandes entre los grupos.

Usa el modo de vista previa

Las reglas de la política de seguridad, incluidas las firmas del Proyecto abierto de seguridad de aplicaciones web (OWASP), pueden tener efectos impredecibles en tu aplicación. Usa el modo de vista previa para evaluar si la introducción de una regla tendrá un impacto negativo en el tráfico de producción.

Habilita la protección adaptable de Google Cloud Armor

Habilita la protección adaptable para obtener protección adicional de tus aplicaciones. La protección adaptable supervisa el tráfico y, según sea necesario, recomienda reglas nuevas para tus políticas de seguridad. Además, te recomendamos que implementes una política de alertas para asegurarte de que las personas adecuadas reciban alertas sobre posibles ataques. La protección adaptable es más adecuada para la protección volumétrica. Los ataques que no son volumétricos podrían no activar la protección adaptable.

Habilita el análisis de JSON

Si la aplicación envía contenido JSON en el cuerpo de las solicitudes POST, asegúrate de habilitar el análisis de JSON. Si no habilitas el análisis de JSON, Google Cloud Armor no analiza el contenido JSON de los cuerpos POST por las reglas de WAF preconfiguradas, y los resultados pueden contener ruido y generar falsos positivos. Para obtener más información, consulta Análisis de JSON.

Prueba la lógica

Una regla se activa cuando su condición de coincidencia se evalúa como verdadera. Por ejemplo, la condición de coincidencia origin.region_code == 'AU' se evalúa como verdadera si el código de región de la solicitud es AU. Si una regla de mayor prioridad se evalúa como verdadera, se ignora la acción en una regla de menor prioridad. En el siguiente ejemplo, imagina que deseas crear una política de seguridad para bloquear usuarios de la región AU, excepto para el tráfico dentro del rango de direcciones IP 10.10.10.0/24. Considera la siguiente política de seguridad con dos reglas:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

En este ejemplo, Rule1 permite el tráfico que se origina en el rango de direcciones IP 10.10.10.0/24. Debido a que Rule1 es la regla de mayor prioridad, ese tráfico se permite antes de evaluarse con Rule2, lo que significa que Google Cloud Armor no lo evalúa con Rule2 (ni ninguna otra regla restante).

Cuando crees políticas de Google Cloud Armor, prueba la lógica de las reglas para asegurarte de lograr el comportamiento deseado. Para ello, te recomendamos que generes tráfico sintético a fin de comprender qué reglas bloquean el tráfico y verifiques que tus resultados sean coherentes con tus decisiones de diseño de reglas. Si no estás seguro de cómo una solicitud puede fluir a través del sistema, usa el modo de vista previa para ver qué regla coincide con la solicitud.

Identifica las direcciones IP de origen de los analizadores

Los escáneres de seguridad se pueden ubicar dentro o fuera de Google. Si deseas realizar una evaluación externa y sin filtrar de tu aplicación, puedes permitir explícitamente el tráfico según la dirección IP (o cualquier otro token) antes de evaluarla con cualquier otra regla.

Agrupa y ordena las reglas de tu política de seguridad

Tus aplicaciones pueden entregar contenido a diferentes subconjuntos de tus clientes. En el siguiente ejemplo, se muestra cómo denegar el tráfico de ciertas áreas geográficas o rangos de IP y, por lo tanto, configurar la primera regla en la política para rechazar ese tráfico. Además, debes permitir de manera explícita parte del tráfico a la aplicación sin que la política de seguridad lo procese. Para este ejemplo, recomendamos la siguiente estructura de prioridad de reglas, de mayor a menor prioridad:

  1. Reglas de denegación explícitas (ASN, región, rangos de IP)
  2. Reglas de permiso explícitas de confianza (scanners, sistemas confiables: usar con extrema precaución)
  3. Reglas de seguridad (OWASP, reglas personalizadas)
  4. Reglas de permiso explícitas (ASN, presencia del valor del encabezado, rango de IP)
  5. Reglas de denegación predeterminadas

Usa reCAPTCHA para la administración de bots

Google Cloud Armor se integra en reCAPTCHA de Google para la detección de bots en la capa de WAF. En esta integración, reCAPTCHA genera tokens de reCAPTCHA, y Google Cloud Armor realiza el proceso de evaluación de tokens en lugar de reCAPTCHA. Esto reduce la carga de origen, lo que podría reducir tus costos, y coloca los controles de seguridad más cerca del usuario final que tus backends. Para obtener más información, consulta la descripción general de la administración de bots.

Establece umbrales de límites de frecuencia

La limitación de frecuencia es una función flexible y valiosa para evitar el abuso y mitigar las amenazas de gran volumen, como el uso excesivo de credenciales o los ataques de DSD de L7. Cuando implementas el límite de frecuencia por primera vez, es importante elegir un umbral que tenga sentido para tu aplicación. Recomendamos que comiences por aplicarlos en el modo de vista previa. A medida que analizas y comprendes el perfil de tráfico, puedes ajustar los parámetros de límite de frecuencia. Además, es importante tener en cuenta la prioridad que asignas a la regla de límite de frecuencia. Una regla de mayor prioridad puede permitir o rechazar el tráfico de forma explícita antes de que se evalúe en función de la regla de límite de frecuencia.

Ajuste de reglas

Las aplicaciones web pueden permitir solicitudes que parecen ser ataques y podrían permitir, o incluso exigir, que los usuarios envíen solicitudes que coincidan con las firmas en las reglas de WAF preconfiguradas. Es fundamental que valides las reglas de Google Cloud Armor en la aplicación y abordes cualquier resultado que no sea relevante para la aplicación antes de ascender la regla mediante la inhabilitación del modo de vista previa en una aplicación de producción. En las siguientes secciones, encontrarás prácticas recomendadas y sugerencias para ajustar las reglas de WAF preconfiguradas.

Elige tu nivel de sensibilidad de las reglas de WAF preconfiguradas

Cuando implementas cualquiera de las reglas de WAF preconfiguradas, puedes elegir un nivel de sensibilidad adecuado en función de los requisitos de seguridad y los cronogramas. Te recomendamos que comiences con un nivel de sensibilidad de 1 para la mayoría de las aplicaciones que deben cumplir con los requisitos de seguridad de tu organización. Las reglas configuradas para la sensibilidad 1 usan firmas de alta fidelidad y reducen el ruido potencial de la regla. Las firmas asociadas con sensibilidades más altas pueden detectar y evitar un conjunto más grande de intentos de aprovechamiento, a expensas del posible ruido para algunas aplicaciones protegidas. Sin embargo, es posible que las cargas de trabajo sujetas a requisitos de seguridad más estrictos prefieran el nivel de sensibilidad más alto. Para estos casos de uso, puede haber una gran cantidad de ruido o resultados irrelevantes, que debes abordar con el ajuste antes de que la política de seguridad entre en producción.

Habilita el registro detallado

Si necesitas información adicional sobre qué atributos de solicitud y cargas útiles activan una regla de WAF en particular, habilita el registro detallado. El registro detallado proporciona detalles de las solicitudes que activan reglas específicas, incluido un fragmento de la parte maliciosa de la solicitud, lo que es útil para solucionar problemas y ajustar Google Cloud Armor. Debido a que el registro detallado puede hacer que el contenido de la solicitud del usuario final se registre en Cloud Logging, existe la posibilidad de que acumules PII del usuario final en tus registros. Como resultado, no recomendamos ejecutar cargas de trabajo de producción con el registro detallado habilitado durante períodos largos.

Usa reglas estables o de versión canary

Existen dos tipos de reglas de WAF preconfiguradas de Google Cloud Armor: estables y de versión canary. Cuando se agregan nuevas reglas al conjunto actual de reglas principales de ModSecurity (CRS), las publicamos en las compilaciones de reglas de versión canary antes de publicarlas automáticamente en las compilaciones de reglas estables. Recomendamos que implementes las reglas de versión canary en un entorno de pruebas para que puedas ver los efectos de cualquier cambio y adición en tu entorno. Puedes verificar los nombres de reglas en la página Ajusta las reglas de WAF de Google Cloud Armor para verificar si la compilación de versión canary está sincronizada con la compilación estable.

Registro y supervisión

Las siguientes secciones contienen prácticas recomendadas y sugerencias para configurar el registro y la supervisión.

Usa Security Command Center

Google Cloud Armor se integra de forma automática en Security Command Center. Google Cloud Armor exporta diferentes resultados a Security Command Center:

  • Aumentos repentinos de tráfico permitidos
  • Aumento en la proporción de denegación

Asegúrate de que tu personal de seguridad web analice estos resultados.

Elige una tasa de muestreo de Cloud Logging

Los registros por solicitud de Google Cloud Armor usan el balanceador de cargas de aplicaciones externo global o la infraestructura de registro del balanceador de cargas de aplicaciones clásico. Como resultado, la generación de registros de Google Cloud Armor está sujeta a la tasa de muestreo de registro configurada en el balanceador de cargas. Recomendamos mantener la tasa de muestreo en 1 cuando ajustes e implementes de forma activa Google Cloud Armor. Una vez que finalices el ajuste y la implementación de Google Cloud Armor, te recomendamos que mantengas activado el registro de solicitudes completo. Sin embargo, es posible que prefieras disminuir el muestreo a una tasa más baja. Tanto el balanceador de cargas de aplicaciones externo global como el balanceador de cargas de aplicaciones clásico no habilitan los registros de forma predeterminada, por lo que es importante que habilites el registro de forma manual.

Usa el panel de Cloud Monitoring

Es esencial tener una vista clara de lo que sucede en tu configuración de Google Cloud Armor. Para facilitar esta tarea, puedes usar el panel de seguridad. Además, puedes exportar registros de Google Cloud Armor directamente desde Logging a tu propia plataforma. Si usas la protección adaptable, es importante tener una ruta de elevación para cualquier alerta de protección adaptable que se active.

Administración general

A continuación, se proporcionan prácticas recomendadas adicionales y sugerencias para configurar Google Cloud Armor.

Configura el control de acceso de Identity and Access Management

De acuerdo con las prácticas recomendadas generales de Google Cloud IAM, asegúrate de que las personas correctas tengan acceso a Google Cloud Armor. El rol Compute Security Admin es necesario para configurar, modificar, actualizar y borrar las políticas de seguridad de Google Cloud Armor. Además, se requiere el rol Compute Network Admin o el permiso compute.backendServices.setSecurityPolicy para vincular una política de seguridad de Google Cloud Armor a un servicio de backend.

Minimiza la cantidad de políticas

Una política de Google Cloud Armor se puede volver a usar en varios servicios de backend. Te recomendamos que tengas un conjunto coherente de políticas de seguridad reutilizables.

Usar Terraform

Para garantizar que las opciones de configuración se puedan revertir con facilidad, así como reproducirse en todos los proyectos, recomendamos usar Terraform. Google Cloud Armor tiene una integración con Terraform completa para las funciones de GA.

Configura Google Cloud Armor con Google Kubernetes Engine

Si usas GKE, debes configurar Google Cloud Armor y otras funciones de entrada a través de parámetros BackendConfig. Te recomendamos que no configures de forma manual un balanceador de cargas de aplicaciones externo global ni un balanceador de cargas de aplicaciones clásico para que funcione como un punto de entrada. Para obtener más información sobre cómo configurar Google Cloud Armor con GKE, consulta Configura características de entrada.