En esta página se describen las prácticas recomendadas para optimizar y ajustar las implementaciones de Google Cloud Armor.
Cloud Armor se implementa con el balanceador de carga de aplicación externo global, el balanceador de carga de aplicación clásico o el balanceador de carga de red con proxy externo. Cuando implementas Cloud Armor, asocias una política de seguridad al servicio de backend del balanceador de carga que quieres proteger. Una política de seguridad consta de un conjunto de reglas preconfiguradas y personalizadas que tú determinas.
Para configurar una política de Cloud Armor que se aplique automáticamente a todos los proyectos de tu organización y que permita que cada proyecto añada sus propias reglas específicas, consulta la guía sobre cómo gestionar Cloud Armor mediante restricciones personalizadas. Este enfoque proporciona una forma centralizada de aplicar políticas de seguridad en toda la organización, al tiempo que mantiene la flexibilidad para las necesidades de cada proyecto.
Creación de políticas y reglas de seguridad
En las siguientes secciones se incluyen prácticas recomendadas y sugerencias para las nuevas políticas y reglas de seguridad.
Proporcionar descripciones de las reglas
Usa descripciones de reglas para proporcionar más contexto sobre por qué se ha creado cada regla y cuál es su función. El campo description tiene un límite de 64 caracteres, por lo que las referencias a bases de datos de gestión de configuración u otros repositorios son la forma más eficiente de registrar el contexto.
Tener en cuenta el espaciado prioritario
Cuando configure las reglas por primera vez, deje un intervalo de al menos 10 entre cada valor de prioridad de regla. Por ejemplo, las dos primeras reglas de una política de seguridad podrían tener las prioridades 20 y 30. De esta forma, puedes insertar más reglas cuando las necesites. Además, le recomendamos que agrupe las reglas similares en bloques y deje intervalos más grandes entre los grupos.
Usar el modo de vista previa
Las reglas de la política de seguridad, incluidas las firmas de Open Web Application Security Project (OWASP), pueden tener efectos impredecibles en tu aplicación. Utilice 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.
Habilitar el análisis JSON
Si tu aplicación envía contenido JSON en el cuerpo de las solicitudes POST, asegúrate de habilitar el análisis JSON. Si no habilitas el análisis JSON, Cloud Armor no analizará el contenido JSON de los cuerpos POST de las reglas de WAF preconfiguradas y los resultados pueden ser ruidosos y generar falsos positivos. Para obtener más información, consulta Análisis de JSON.
Pon a prueba tu 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 tiene el valor "true", se ignora la acción de una regla de menor prioridad. En el siguiente ejemplo, supongamos que quieres crear una política de seguridad para bloquear a los usuarios de la región AU, excepto el tráfico que se encuentre en el intervalo 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 procede del intervalo de direcciones IP 10.10.10.0/24. Como Rule1 es la regla de mayor prioridad, este tráfico se permite antes de evaluarse con Rule2, lo que significa que Cloud Armor no lo evalúa con Rule2 (ni con ninguna otra regla restante).
Cuando crees políticas de Cloud Armor, prueba la lógica de tus reglas para asegurarte de que se comportan como esperas. Para ello, te recomendamos que generes tráfico sintético para saber qué reglas están bloqueando el tráfico y que verifiques que los resultados son coherentes con las decisiones de diseño de tus reglas. Si no sabes cómo puede fluir una solicitud por el sistema, utiliza el modo de vista previa para ver qué regla coincide con la solicitud.
Identificar las direcciones IP de origen de tus escáneres
Tus escáneres de seguridad pueden estar dentro o fuera de Google. Si quieres obtener una evaluación externa y sin filtros de tu aplicación, puedes permitir explícitamente el tráfico en función de la dirección IP (u otro token) antes de evaluarla con respecto a otras reglas.
Agrupar y ordenar reglas en tu política de seguridad
Es posible que tus aplicaciones atiendan a diferentes subconjuntos de tus clientes. En el siguiente ejemplo, quiere denegar el tráfico de determinadas zonas geográficas o intervalos de IP. Por lo tanto, configura la primera regla de su política para denegar ese tráfico. Además, quieres permitir explícitamente que entre tráfico en la aplicación sin que la política de seguridad lo procese. En este ejemplo, recomendamos la siguiente estructura de prioridad de las reglas, de mayor a menor prioridad:
- Reglas de denegación explícitas (ASN, región, intervalos de IP)
- Reglas de permiso explícitas de confianza (escáneres, sistemas de confianza; úsalas con extrema precaución)
- Reglas de seguridad (OWASP y reglas personalizadas)
- Reglas de autorización explícitas (ASN, presencia de valor de encabezado, intervalo de IP)
- Reglas de denegación predeterminadas
Definir umbrales de limitación de frecuencia
La limitación de frecuencia es una función flexible y valiosa que permite evitar abusos y mitigar amenazas de gran volumen, como el relleno de credenciales o los ataques DDoS de capa 7. Cuando implementes la limitación de frecuencia por primera vez, es importante elegir un umbral que tenga sentido para tu aplicación. Te recomendamos que empieces con la aplicación en modo de vista previa. A medida que analices y comprendas el perfil de tráfico, podrás ajustar los parámetros de limitación de la frecuencia. Además, es importante tener en cuenta la prioridad que asignes a la regla de limitación de la frecuencia. Es posible que una regla de mayor prioridad permita o deniegue el tráfico explícitamente antes de que se evalúe con la regla de limitación de frecuencia.
Ajuste de reglas
Las aplicaciones web pueden permitir solicitudes que parezcan ataques y pueden permitir, o incluso requerir, que los usuarios envíen solicitudes que coincidan con las firmas de las reglas de WAF preconfiguradas. Es fundamental que valides tus reglas de Cloud Armor en tu aplicación y que abordes cualquier resultado que no sea relevante para tu aplicación antes de habilitar la regla. Para ello, inhabilita el modo de vista previa en una aplicación de producción. En las siguientes secciones se incluyen prácticas recomendadas y sugerencias para ajustar las reglas de WAF preconfiguradas.
Elegir el nivel de sensibilidad de una regla de WAF preconfigurada
Cuando implementes cualquiera de las reglas de WAF preconfiguradas, podrás elegir el nivel de sensibilidad adecuado en función de tus requisitos de seguridad y plazos. Te recomendamos que empieces con un nivel de sensibilidad 1 en la mayoría de las aplicaciones que deban cumplir los requisitos de seguridad de tu organización. Las reglas configuradas con una sensibilidad de 1 usan firmas de alta fidelidad y reducen el ruido potencial de la regla. Las firmas asociadas a sensibilidades más altas pueden detectar y evitar un mayor número de intentos de exploit, pero a costa de generar ruido en algunas aplicaciones protegidas. Sin embargo, las cargas de trabajo sujetas a requisitos de seguridad más estrictos pueden preferir el nivel de sensibilidad más alto. En estos casos prácticos, puede haber una gran cantidad de ruido o resultados irrelevantes, que debes abordar mediante el ajuste antes de que la política de seguridad entre en producción.
Habilitar el registro detallado
Si necesita más información sobre qué atributos de solicitud y cargas útiles activan una regla de WAF concreta, habilite el registro detallado. El registro detallado proporciona detalles de las solicitudes que activan reglas concretas, incluido un fragmento de la parte infractora de la solicitud, lo que resulta útil para solucionar problemas y ajustar Cloud Armor. Como el registro detallado puede provocar que el contenido de las solicitudes de los usuarios finales se registre en Cloud Logging, existe la posibilidad de que acumules información personal identificable de los usuarios finales en tus registros. Por lo tanto, no recomendamos ejecutar cargas de trabajo de producción con el registro detallado habilitado durante largos periodos.
Usar reglas estables o canary
Hay dos tipos de reglas de WAF preconfiguradas de Cloud Armor: estables y canary. Cuando se añaden nuevas reglas al conjunto de reglas principal (CRS) de OWASP, las publicamos en las compilaciones de reglas canary antes de publicarlas automáticamente en las compilaciones de reglas estables. Te recomendamos que implementes las reglas de lanzamiento de versiones canary en un entorno de pruebas para que puedas ver los efectos de los cambios y las adiciones en tu entorno. Puedes consultar los nombres de las reglas en la página Activar las reglas de WAF de Cloud Armor para comprobar si la compilación canary está sincronizada con la compilación estable.
Almacenamiento de registros y monitorización
En las siguientes secciones se incluyen prácticas recomendadas y recomendaciones para configurar el registro y la monitorización.
Elegir una frecuencia de muestreo de Cloud Logging
Los registros por solicitud de Cloud Armor usan la infraestructura de registro del balanceador de carga de aplicación externo global o del balanceador de carga de aplicación clásico. Por lo tanto, la generación de registros de Cloud Armor está sujeta a la frecuencia de muestreo de registros configurada en el balanceador de carga. Te recomendamos que mantengas la frecuencia de muestreo en 1 cuando estés ajustando e implementando Cloud Armor. Después de ajustar e implementar Cloud Armor, le recomendamos que mantenga activado el registro completo de solicitudes. Sin embargo, puede que prefiera reducir el muestreo a una tasa inferior. Ni el balanceador de carga de aplicación externo global ni el balanceador de carga de aplicación clásico tienen los registros habilitados de forma predeterminada, por lo que es importante que los habilites manualmente.
Usar el panel de control de Cloud Monitoring
Es fundamental tener una visión clara de lo que ocurre en tu configuración de Cloud Armor. Para que te resulte más fácil, puedes usar el panel de control de seguridad. Además, puede exportar los registros de Cloud Armor directamente desde Logging a su propia plataforma.
Gestión general
A continuación, se incluyen prácticas recomendadas y sugerencias adicionales para configurar Cloud Armor.
Configurar el control de acceso de Gestión de Identidades y Accesos
De acuerdo con las Trusted Cloud prácticas recomendadas generales de IAM,
asegúrate de que las personas adecuadas tengan acceso a Cloud Armor. Se necesita el rol Administrador de seguridad de Compute para configurar, modificar, actualizar y eliminar políticas de seguridad de Cloud Armor. Además, se necesita el rol Administrador de redes de Compute o el permiso compute.backendServices.setSecurityPolicy para adjuntar una política de seguridad de Cloud Armor a un servicio de backend.
Minimizar el número de políticas
Una política de Cloud Armor se puede reutilizar en varios servicios de backend. Te recomendamos que tengas un conjunto coherente de políticas de seguridad reutilizables.
Usar Terraform
Para asegurarte de que las configuraciones se puedan revertir fácilmente y reproducir en varios proyectos, te recomendamos que uses Terraform. Cloud Armor tiene una integración completa con Terraform para las funciones de GA.