1. Introducción
¡Hola! Te damos la bienvenida al codelab de reglas de WAF preconfiguradas de Cloud Armor.
Google Cloud Armor es la solución de seguridad de red perimetral empresarial de Google que proporciona protección contra DDoS, aplicación de reglas de WAF y administración adaptable a gran escala.
Cloud Armor extendió los conjuntos de reglas de WAF preconfigurados para mitigar contra las 10 vulnerabilidades de seguridad principales de OWASP para aplicaciones web. Los conjuntos de reglas se basan en el conjunto de reglas principales de Modsecurity de OWASP versión 3.0.2 para brindar protección contra algunos de los riesgos de seguridad de aplicaciones web más comunes, como la inclusión de archivos locales (lfi), la inclusión de archivos remotos (rfi), la ejecución remota de código (rce) y muchos más.
En este codelab, aprenderás a mitigar algunas de las vulnerabilidades comunes con las reglas de WAF de Google Cloud Armor.
Qué aprenderás
- Cómo configurar un grupo de instancias y un balanceador de cargas global para admitir un servicio
- Cómo configurar las políticas de seguridad de Cloud Armor con reglas de WAF preconfiguradas para brindar protección contra lfi, rce, escáneres, ataques de protocolo y fijación de sesiones
- Cómo validar que Cloud Armor haya mitigado un ataque mediante la observación de los registros.
Requisitos
- Conocimiento básico de Google Compute Engine ( codelab)
- Conocimiento básico de redes y TCP/IP
- Conocimiento básico de la línea de comandos de Unix/Linux
- Es útil haber completado un recorrido por las herramientas de redes en GCP con Networking in the Google Cloud.
- (Opcional) Completa el lab Cloudnet20 Cloud Armor para aprender a proteger cargas de trabajo con inyección de SQL, reglas basadas en IP y basadas en la ubicación geográfica.
Topología del codelab y caso de uso
Figura 1: Topología del codelab de reglas de WAF de Cloud Armor
La aplicación de OWASP Juice Shop es útil para la capacitación y el conocimiento de la seguridad, ya que contiene instancias de cada una de las 10 vulnerabilidades de seguridad principales de OWASP, por diseño. Un atacante puede aprovecharlo para realizar pruebas. En este codelab, lo usaremos para demostrar algunos ataques a la aplicación y, luego, protegerla con reglas de WAF de Cloud Armor. Un balanceador de cargas de Google Cloud encabezará la aplicación, en el que se aplicarán la política de seguridad y las reglas de Cloud Armor. Se entregará en la Internet pública y se podrá acceder a ella desde casi cualquier lugar y se protegerá con Cloud Armor y las reglas de firewall de VPC.
2. Configuración y requisitos
Configuración del entorno de autoaprendizaje
- Accede a la consola de Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
Recuerde el ID de proyecto, un nombre único en todos los proyectos de Google Cloud (el nombre anterior ya se encuentra en uso y no lo podrá usar). Se mencionará más adelante en este codelab como PROJECT_ID.
- A continuación, deberás habilitar la facturación en la consola de Cloud para usar los recursos de Google Cloud recursos.
Ejecutar este codelab no debería costar mucho, tal vez nada. Asegúrate de seguir las instrucciones de la sección “Realiza una limpieza” en la que se aconseja cómo cerrar recursos para no incurrir en facturación más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de$300.
Inicia Cloud Shell
Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:
El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:
Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.
Antes de comenzar
En Cloud Shell, asegúrate de que el ID del proyecto esté configurado
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
Habilita las APIs
Habilita todos los servicios necesarios
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. Crea la red de VPC
Crear red de VPC
Desde Cloud Shell
gcloud compute networks create ca-lab-vpc --subnet-mode custom
Salida
Created NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4 ca-lab-vpc CUSTOM REGIONAL
Crear una subred
Desde Cloud Shell
gcloud compute networks subnets create ca-lab-subnet \
--network ca-lab-vpc --range 10.0.0.0/24 --region us-central1
Salida
Created NAME REGION NETWORK RANGE ca-lab-subnet us-central1 ca-lab-vpc 10.0.0.0/24
Crea reglas de firewall de VPC
Después de crear la VPC y la subred, configurarás algunas reglas de firewall. Se usará la primera regla de firewall para permitir que todas las IP accedan a la IP externa del sitio web de la aplicación de prueba en el puerto 3000. La segunda regla de firewall se usará para permitir verificaciones de estado desde la IP de origen de los balanceadores de cargas.
Desde Cloud Shell
gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc
Salida
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-js-site ca-lab-vpc INGRESS 1000 tcp:3000 False
Crea reglas de FW para permitir verificaciones de estado de los rangos de verificaciones de estado de Google.
Desde Cloud Shell
gcloud compute firewall-rules create allow-health-check \
--network=ca-lab-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=allow-healthcheck \
--rules=tcp
Salida
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-health-check ca-lab-vpc INGRESS 1000 tcp False
4. Configura la aplicación de prueba
El siguiente paso es crear la aplicación de prueba, en este caso, el servidor web de OWASP Juice Shop.
Cuando creamos la instancia de procesamiento, usamos una imagen de contenedor para asegurarnos de que el servidor tenga los servicios adecuados. Este servidor se implementará en us-central1-c y tendrá una etiqueta de red que permitirá las verificaciones de estado.
Crea la aplicación de OWASP Juice Shop
Usa la conocida aplicación OWASP Juice Shop de código abierto para que funcione como la aplicación vulnerable. También puedes usar esta aplicación para realizar desafíos de seguridad de OWASP a través de su sitio web.
Desde Cloud Shell
gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
--network ca-lab-vpc \
--subnet ca-lab-subnet \
--private-network-ip=10.0.0.3 \
--machine-type n1-standard-2 \
--zone us-central1-c \
--tags allow-healthcheck
Salida
NAME ZONE MACHINE_TYPE PREEMPTIBLE owasp-juice-shop-app us-central1-c n1-standard-2 INTERNAL_IP EXTERNAL_IP STATUS 10.0.0.3 <public IP> RUNNING
Configura el componente de balanceador de cargas de Cloud: grupo de instancias
Crea el grupo de instancias no administrado.
Desde Cloud Shell
gcloud compute instance-groups unmanaged create juice-shop-group \
--zone=us-central1-c
Salida
NAME LOCATION SCOPE NETWORK MANAGED INSTANCES juice-shop-group us-central1-c zone 0
Agrega la instancia de GCE de Juice Shop al grupo de instancias no administrado.
Desde Cloud Shell
gcloud compute instance-groups unmanaged add-instances juice-shop-group \
--zone=us-central1-c \
--instances=owasp-juice-shop-app
Salida
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Configura el puerto con nombre como el de la aplicación Juice Shop.
Desde Cloud Shell
gcloud compute instance-groups unmanaged set-named-ports \ juice-shop-group \ --named-ports=http:3000 \ --zone=us-central1-c
Salida
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Ahora que creaste el grupo de instancias no administrado, el siguiente paso es crear una verificación de estado, un servicio de backend, un mapa de URL, un proxy de destino y una regla de reenvío.
Configura el componente de balanceador de cargas de Cloud: verificación de estado
Crea la verificación de estado del puerto de servicio de Juice Shop.
Desde Cloud Shell
gcloud compute health-checks create tcp tcp-port-3000 \
--port 3000
Salida
Created NAME PROTOCOL tcp-port-3000 TCP
Configura el componente de balanceador de cargas de Cloud: servicio de backend
Crea los parámetros del servicio de backend.
Desde Cloud Shell
gcloud compute backend-services create juice-shop-backend \
--protocol HTTP \
--port-name http \
--health-checks tcp-port-3000 \
--enable-logging \
--global
Salida
NAME BACKENDS PROTOCOL juice-shop-backend HTTP
Agrega el grupo de instancias de Juice Shop al servicio de backend.
Desde Cloud Shell
gcloud compute backend-services add-backend juice-shop-backend \
--instance-group=juice-shop-group \
--instance-group-zone=us-central1-c \
--global
Salida
Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].
Configura el componente Balanceador de cargas de Cloud: Mapa de URL
Crea el mapa de URL para enviar al backend.
Desde Cloud Shell
gcloud compute url-maps create juice-shop-loadbalancer \
--default-service juice-shop-backend
Salida
NAME DEFAULT_SERVICE juice-shop-loadbalancer backendServices/juice-shop-backend
Configura el componente balanceador de cargas de Cloud: proxy de destino
Crea el proxy de destino para al frente del mapa de URL.
Desde Cloud Shell
gcloud compute target-http-proxies create juice-shop-proxy \
--url-map juice-shop-loadbalancer
Salida
NAME URL_MAP juice-shop-proxy juice-shop-loadbalancer
Configura el componente de balanceador de cargas de Cloud: regla de reenvío
Crea la regla de reenvío para el balanceador de cargas.
Desde Cloud Shell
gcloud compute forwarding-rules create juice-shop-rule \
--global \
--target-http-proxy=juice-shop-proxy \
--ports=80
Salida
Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].
Verifica que el servicio de Juice Shop esté en línea
Desde Cloud Shell
PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule --global --format="value(IPAddress)")"
Desde Cloud Shell
echo $PUBLIC_SVC_IP
Salida
<public VIP of service>
Espera unos minutos antes de continuar; de lo contrario, puedes recuperar una respuesta HTTP/1.1 404 Not Found.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP
Salida
HTTP/1.1 200 OK <...>
También puedes ir al navegador para ver la tienda de jugos.
Ahora estamos listos para explorar las vulnerabilidades de Juice Shop y cómo protegernos de ellas con conjuntos de reglas de WAF de Cloud Armor.
5. Demuestra vulnerabilidades conocidas
Para ahorrar tiempo, demostraremos los estados anteriores y posteriores a la propagación de las reglas de WAF de Cloud Armor en pasos condensados.
Observa una vulnerabilidad de LFI: salto de directorio
La inclusión de archivos locales es el proceso de observar los archivos presentes en el servidor mediante la explotación de la falta de validación de entrada en la solicitud para exponer datos sensibles. A continuación, simplemente se muestra que es posible un salto de directorio. En tu navegador o con curl, observa una ruta de acceso existente que entrega la aplicación.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp
Salida
HTTP/1.1 200 OK <...>
Además, observa que el salto de directorio también funciona:
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp/../
Salida
HTTP/1.1 200 OK <...>
Observa una vulnerabilidad de RCE
Remote Code Execution incluye varias situaciones de inyección de comandos de UNIX y Windows que permiten a los atacantes ejecutar comandos del SO que generalmente están restringidos a usuarios con privilegios. A continuación, se muestra una ejecución de comando ls simple pasada.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Salida
HTTP/1.1 200 OK <...>
Puedes quitar las marcas de curl para observar el resultado completo.
Observa el acceso de un escáner conocido
Tanto el comercial como el de código abierto analizan aplicaciones para diversos fines, incluido el análisis en busca de vulnerabilidades. Estas herramientas usan el conocido usuario-agente y otros encabezados. Observa que curl funciona con un encabezado User-Agent conocido:
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Salida
HTTP/1.1 200 OK <...>
Observar un ataque de protocolo: división de HTTP
Algunas aplicaciones web utilizan datos de entrada del usuario para generar los encabezados en las respuestas. Si la aplicación no filtra la entrada correctamente, un atacante podría envenenar el parámetro de entrada con la secuencia %0d%0a (la secuencia CRLF que se usa para separar diferentes líneas). La respuesta puede entonces interpretarse como dos respuestas por cualquier cosa que ocurra con el análisis, como un servidor proxy intermediario, lo que podría mostrar contenido falso en solicitudes posteriores. Inserta la secuencia %0d%0a en el parámetro de entrada, lo que puede hacer que se muestre una página engañosa.
Desde Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Salida
HTTP/1.1 200 OK <...>
Observa la fijación de la sesión
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H session_id=X
Salida
HTTP/1.1 200 OK <...>
6. Define las reglas de WAF de Cloud Armor
Enumera las reglas de WAF preconfiguradas:
Desde Cloud Shell
gcloud compute security-policies list-preconfigured-expression-sets
Salida
EXPRESSION_SET
Sqli-canary
RULE_ID
owasp-crs-v030001-id942110-sqli
owasp-crs-v030001-id942120-sqli
<...>
Crea la política de seguridad de Cloud Armor
Desde Cloud Shell:
gcloud compute security-policies create block-with-modsec-crs \
--description "Block with OWASP ModSecurity CRS"
Actualiza la regla predeterminada de la política de seguridad
Ten en cuenta que la prioridad de la regla predeterminada tiene un valor numérico de 2147483647.
Desde Cloud Shell:
gcloud compute security-policies rules update 2147483647 \
--security-policy block-with-modsec-crs \
--action "deny-403"
Debido a que la regla predeterminada está configurada con acciones de denegación, debemos permitir el acceso desde tu IP. Busca tu IP pública (curl, ipmonkey, whatismyip, etcétera).
Desde Cloud Shell:
MY_IP=$(curl ifconfig.me)
Agrega la primera regla para permitir el acceso desde tu IP (INSERTA TU IP A CONTINUACIÓN)
Desde Cloud Shell:
gcloud compute security-policies rules create 10000 \
--security-policy block-with-modsec-crs \
--description "allow traffic from my IP" \
--src-ip-ranges "$MY_IP/32" \
--action "allow"
Actualiza la política de seguridad para bloquear los ataques de LFI
Aplica el conjunto de reglas principales de ModSecurity de OWASP que evita el salto de directorio para inclusiones de archivos locales.
Desde Cloud Shell:
gcloud compute security-policies rules create 9000 \
--security-policy block-with-modsec-crs \
--description "block local file inclusion" \
--expression "evaluatePreconfiguredExpr('lfi-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear Remote Code Execution (rce)
Según el conjunto de reglas principales de ModSecurity de OWASP, aplica reglas que busquen rce, incluida la inserción de comandos. Se detectan y bloquean los comandos típicos del SO.
Desde Cloud Shell:
gcloud compute security-policies rules create 9001 \
--security-policy block-with-modsec-crs \
--description "block rce attacks" \
--expression "evaluatePreconfiguredExpr('rce-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear los análisis de seguridad
Aplica el conjunto de reglas principal de ModSecurity de OWASP para bloquear escáneres de seguridad conocidos, clientes HTTP con secuencias de comandos y rastreadores web.
Desde Cloud Shell:
gcloud compute security-policies rules create 9002 \
--security-policy block-with-modsec-crs \
--description "block scanners" \
--expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear ataques de protocolo
Según el conjunto de reglas principales de ModSecurity de OWASP, aplica reglas que busquen los caracteres de retorno de carro (CR) %0d y de salto de línea (LF) %0a, y otros tipos de ataques de protocolo, como el contrabando de solicitudes HTTP.
Desde Cloud Shell:
gcloud compute security-policies rules create 9003 \
--security-policy block-with-modsec-crs \
--description "block protocol attacks" \
--expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear la fijación de sesiones
Según el conjunto de reglas principales de ModSecurity de OWASP, se aplican reglas que...
Desde Cloud Shell:
gcloud compute security-policies rules create 9004 \
--security-policy block-with-modsec-crs \
--description "block session fixation attacks" \
--expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
--action deny-403
Conecta la política de seguridad al servicio de backend
Desde Cloud Shell:
gcloud compute backend-services update juice-shop-backend \
--security-policy block-with-modsec-crs \
--global
Las reglas pueden tardar un poco en propagarse (pero no más de 10 minutos). Una vez que estés seguro de que haya transcurrido el tiempo suficiente, prueba las vulnerabilidades demostradas anteriormente para confirmar la aplicación de la regla de WAF de Cloud Armor en el siguiente paso.
7. Observa la protección de Cloud Armor con el conjunto de reglas principales de ModSecurity de OWASP
Confirma que se mitigó la vulnerabilidad de LFI
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?a=../
Salida
HTTP/1.1 403 Forbidden <...>
Confirma que se mitigó el ataque de RCE
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Salida
HTTP/1.1 403 Forbidden <..>
Confirma la detección del escáner conocido
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Salida
HTTP/1.1 403 Forbidden <..>
Confirma que se mitigó un ataque de protocolo
Según el conjunto de reglas principales de ModSecurity de OWASP, versión 3.0.2, el ataque de protocolo se mitiga de la siguiente manera:
Desde Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Salida
HTTP/1.1 403 Forbidden <..>
Confirma que los intentos de corrección de la sesión estén bloqueados
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?session_id=a
Salida
HTTP/1.1 403 Forbidden <..>
8. Revisa las reglas de seguridad de Cloud Armor
Ahora que creamos la política de seguridad, veamos exactamente qué reglas se configuraron.
Las reglas se evalúan por prioridad: los números más bajos se evalúan primero y, una vez que se activan, el procesamiento no continúa para las reglas con valores de prioridad más altos.
- Prioridad 9000: bloquear LFI (inclusión de archivos locales)
- Prioridad 9001: RCE de bloque (ejecución de código remoto/inserción de comandos)
- Prioridad 9002: escáneres de bloque detectados
- Prioridad 9003: ataques de protocolo de bloqueo, como división de HTTP y contrabando de HTTP
- Prioridad 9004: ataques de fijación de sesión en el bloque
- Prioridad 10000: permitir que su IP acceda al sitio web
- Prioridad predeterminada: rechazar.
*Observa la casilla “Permitir tu IP” se configura con el número de prioridad más alto para permitir el acceso al sitio, pero bloquea cualquier ataque.
9. Observa los registros de la política de seguridad de Cloud Armor
En la página de la consola de Cloud Armor, puedes ver los detalles de la política de seguridad y hacer clic en la pestaña Logs seguida del vínculo View policy logs para ir a la página de Cloud Logging. Filtrará automáticamente en función de la política de seguridad de interés, p.ej., resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs) Observa los códigos de respuesta de errores 403 y expande los detalles del registro para observar el nombre de la política de seguridad aplicada, el valor del campo coincidente y, más abajo, los IDs de expresiones preconfiguradas (o el ID de firma). En las siguientes capturas de pantalla, se muestran ejemplos de los registros de las políticas de seguridad aplicadas que se configuraron en este codelab.
Registro de la LFI
Registro de RCE
Registro de detección del escáner
Registro de ataques de protocolo
Registro de fijación de sesiones
10. Limpieza del lab
Ahora que completaste el lab, limpia los recursos.
Ejecuta estos comandos para borrar la política de seguridad de Cloud Armor, el balanceador de cargas, las instancias, las reglas de firewall y la red de VPC.
Quita la política de seguridad de Cloud Armor del servicio de backend
gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global
Borra la política de seguridad de Cloud Armor
Si borras la política de seguridad, se borrarán automáticamente las reglas asociadas.
gcloud -q compute security-policies delete block-with-modsec-crs
Borra los recursos del balanceador de cargas
Estos recursos del balanceador de cargas que se borrarán incluyen la regla de reenvío, target-http-proxies, url-maps, backend, comprobaciones de estado y grupo de instancias.
gcloud -q compute forwarding-rules delete juice-shop-rule --global
gcloud -q compute target-http-proxies delete juice-shop-proxy
gcloud -q compute url-maps delete juice-shop-loadbalancer
gcloud -q compute backend-services delete juice-shop-backend \
--global
gcloud -q compute health-checks delete tcp-port-3000
gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c
Borra la instancia
gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c
Borra las reglas de firewall, la subred y la VPC
gcloud -q compute firewall-rules delete allow-health-check gcloud -q compute firewall-rules delete allow-js-site gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1 gcloud -q compute networks delete ca-lab-vpc
11. ¡Felicitaciones!
Felicitaciones por completar el codelab de reglas de WAF preconfiguradas de Cloud Armor.
Temas abordados
- Cómo configurar un grupo de instancias y un balanceador de cargas de Cloud global
- Cómo configurar las políticas de seguridad de Cloud Armor con reglas de WAF preconfiguradas para brindar protección contra lfi, rce, escáneres, ataques de protocolo y fijación de sesiones
- Cómo validar que Cloud Armor haya mitigado algunos de los 10 ataques principales de OWASP a través de registros
Próximos pasos
- Protege tu aplicación contra las 10 vulnerabilidades principales de OWASP con las reglas de WAF preconfiguradas de Cloud Armor.
- Ajusta las reglas en función de los niveles de sensibilidad
- Usa la referencia del lenguaje de las reglas personalizadas para aplicar medidas de seguridad más específicas.