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 del 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, quieres permitir de manera explícita que ingrese algo de 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:
- Reglas de denegación explícitas (ASN, región, rangos de IP)
- Reglas de permiso explícitas de confianza (scanners, sistemas confiables: usar con extrema precaución)
- Reglas de seguridad (OWASP, reglas personalizadas)
- Reglas de permiso explícitas (ASN, presencia del valor del encabezado, rango de IP)
- Reglas de denegación predeterminadas
Usa reCAPTCHA Enterprise para la administración de bots
Google Cloud Armor se integra a reCAPTCHA Enterprise de Google para la detección de bots en la capa de WAF. En esta integración, reCAPTCHA Enterprise genera tokens de reCAPTCHA y Google Cloud Armor realiza el proceso de evaluación de los tokens en lugar de reCAPTCHA Enterprise. Esto reduce la carga de origen, lo que podría reducir los costos, y coloca los controles de seguridad más cerca del usuario final que de los 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 integración completa con Terraform para las funciones de DG.
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 uno clásico para que funcionen como punto de entrada. Para obtener más información sobre cómo configurar Google Cloud Armor con GKE, consulta Configura características de entrada.