Cómo proteger un SaaS que empezó a sufrir ataques, sin migrar ni reescribir nada

Para proteger un SaaS contra ataques sin migrar la aplicación ni reescribir código, basta con poner Azion delante de la app. El tráfico pasa primero por el Firewall de Azion, con WAF, Bot Manager y rate limiting, y lo que las reglas bloquean no llega a tu servidor, que sigue donde está.

El escenario suele ser este: el SaaS creció rápido, muchas veces con código escrito con ayuda de AI, y de repente aparecen scraping, inicios de sesión masivos e intentos de intrusión. No hay tiempo ni presupuesto para resolverlo como se debe, y el equipo de seguridad, cuando existe, es el propio desarrollador.

Buena parte de ese trabajo puedes delegarla a un agente de programación, como Claude Code, que usa los MCP servers de Azion para escribir la configuración de protección de la aplicación que ya está funcionando, mientras tú revisas cada cambio antes de que llegue a producción.

¿Cómo saber si tu SaaS está bajo ataque?

Las señales más comunes son picos de tráfico en rutas específicas, miles de inicios de sesión fallidos y parámetros extraños en las URL.

El ejemplo aquí es una plataforma SaaS ficticia de pedidos B2B para el comercio minorista, en la que los comerciantes consultan el catálogo con precios negociados y hacen pedidos a los distribuidores. La app responde en app.tusaas.com, se ejecuta en un servidor en alguna nube, accesible por origen.tusaas.com, y nadie quiere tocarla ahora.

En la tabla, cada señal aparece con el ataque que suele indicar y la protección que responde a él. Las rutas son ejemplos; cada app organiza las suyas.

¿Cómo proteger un SaaS y sus API sin migrar la aplicación?

Poniendo Azion delante de ella, como proxy. La aplicación sigue en el servidor de hoy, con el mismo código y la misma base de datos; lo que cambia es el camino del tráfico, que llega primero a Azion, pasa por el Firewall y solo entonces sigue al servidor. Lo que una regla bloquea no llega a la aplicación.

En el Firewall, tres controles hacen el trabajo. Web Application Firewall (WAF) inspecciona cada solicitud HTTP y bloquea patrones de ataque como SQL injection y XSS. El rate limiting define cuántas solicitudes puede hacer una misma IP en un intervalo. Y Bot Manager puntúa cada solicitud para separar la navegación humana de la automatización, como el scraping y el credential stuffing.

Los fragmentos siguientes son ilustrativos y muestran solo las partes que cambian en este escenario; el azion.config.ts completo también declara la application que usa el connector y el workload del dominio. El WAF entra de otra forma, explicada justo después del código. En la configuración, el servidor actual se convierte en un connector, que le indica a Azion a dónde reenviar el tráfico:

connectors: [{
  name: 'servidor-actual',
  type: 'http',
  attributes: {
    addresses: [{ address: 'origen.tusaas.com' }],
    connectionOptions: { transportPolicy: 'force_https' },
    modules: {
      loadBalancer: { enabled: false, config: null },
      originShield: { enabled: false, config: null },
    },
  },
}],

Fuera del archivo de configuración, cambian dos cosas. La primera es el DNS: app.tusaas.com pasa a apuntar a Azion, que también puede emitir el certificado TLS del dominio con Let’s Encrypt en cuanto el DNS apunte allí.

La segunda es el origen, que debe aceptar solo el tráfico que viene de Azion, para que nadie evite la protección llamando al servidor directamente por IP. Para eso, usa Origin Shield: activa en el connector el módulo originShield, desactivado en el fragmento anterior, y Origin IP ACL, y configura el firewall del origen para aceptar solo la lista de IP que publica Azion.

¿Cómo configura Claude Code WAF, Bot Manager y rate limiting a través del MCP de Azion?

El agente de programación, en este caso Claude Code, se conecta a los MCP servers de Azion. A través del servidor de documentación, que es de solo lectura, consulta la documentación, los comandos de la CLI y la referencia de la API, y escribe la política en azion.config.ts. Quien aplica la configuración en la cuenta es azion deploy. La solicitud puede ser así de simple:

“Pon Azion delante de mi app, que responde en app.tusaas.com y se ejecuta en el servidor origen.tusaas.com. Aplica el WAF en modo de observación en todas las rutas, rate limiting por IP en el login y en el catálogo, y Bot Manager Lite en las dos rutas, solo registrando, sin bloquear. Abre un pull request con el cambio.”

El resultado es un Firewall como este, con la instancia de Bot Manager Lite y las reglas que la activan:

firewall: [{
  name: 'firewall-saas',
  functions: true,
  waf: true,
  functionsInstances: [{
    name: 'bot-manager-lite',
    ref: 12345, // ID de la función instalada desde Azion Marketplace en tu cuenta
    args: { action: 'allow', threshold: 30 }, // solo registra, no bloquea
  }],
  rules: [
    {
      name: 'bot-manager-login-y-catalogo',
      criteria: [
        { variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/login' },
        { variable: '${request_uri}', conditional: 'or', operator: 'starts_with', argument: '/api/catalogo' },
      ],
      behaviors: [{ type: 'run_function', attributes: { value: 'bot-manager-lite' } }], // apunta a la instancia anterior
    },
    {
      name: 'rate-limit-catalogo',
      criteria: [{ variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/api/catalogo' }],
      behaviors: [{ type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '10' } }],
    },
    {
      name: 'rate-limit-login',
      criteria: [{ variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/login' }],
      behaviors: [{ type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '5' } }],
    },
  ],
}],

Bot Manager Lite, instalado desde Azion Marketplace y ejecutado como función en el Firewall, puntúa cada solicitud por señales como un user agent ausente, falta de encabezados que un navegador real enviaría y una cookie de sesión que no coincide. Cuando la puntuación llega al threshold, aplica la action configurada. Como no depende solo de la IP, ayuda a identificar bots que cambian de IP en cada intento, algo que el rate limiting por IP no logra. La versión completa, Bot Manager, agrega machine learning y Reputation Intelligence.

Los límites son un punto de partida, para ajustar con el tráfico real. En el catálogo, una solicitud por segundo por IP, con un burst de 10, cubre a un comerciante navegando y hace inviable un scraper que opera desde pocas IP. En el login, un intento por segundo, con un burst de 5, basta para quien se equivocó de contraseña y frena los ataques que vienen de una misma IP. El conteo se hace en cada data center: el exceso entra en cola, y lo que supera el burst recibe el status 429.

El WAF queda fuera de este archivo: azion deploy no crea el WAF a partir del azion.config, y la regla que vincula el WAF al Firewall usa su ID numérico y el modo logging. Por eso, crea ambos con la Azion CLI, con azion create waf y azion create firewall-rule, y ajusta en el WAF la sensibilidad por familia de amenaza. Los archivos JSON de esos comandos pueden quedar en el mismo repositorio y pasar por el mismo pull request.

El agente propone, pero quien aprueba es el equipo. Cuando la rama principal está protegida y azion deploy solo se ejecuta después del merge, cada regla llega como un pull request con el diff completo y ninguna llega a producción sin revisión.

Este flujo aparece con más detalle en El agente que escribe tu código también sugiere tu política de seguridad y en Cómo integrar la seguridad de aplicaciones al despliegue.

¿Cómo proteger el SaaS sin bloquear a clientes reales?

Empezando en modo de observación. Con la app ya en producción, el mayor riesgo es rechazar a un cliente real, por eso el WAF en modo Logging y Bot Manager Lite con la acción allow solo registran las solicitudes que se bloquearían. El rate limiting es la excepción, porque ya frena el exceso desde el primer deploy. Si varios usuarios de un mismo cliente salen por la misma IP, como pasa en redes corporativas, empieza con límites más holgados.

En Real-Time Events, la fuente de datos HTTP Requests muestra, para cada solicitud, campos como wafMatch, con la infracción y el fragmento que activó la regla, y wafScore, con la puntuación por familia de amenaza. Con Debug Rules activado en el Firewall, que viene desactivado por defecto, el evento también muestra qué reglas se ejecutaron; actívalo en el Console después de cada deploy, porque azion deploy guarda el Firewall con esta opción desactivada. Los registros de Bot Manager Lite quedan en la fuente Functions Console, con la puntuación y las reglas que activó cada solicitud. Los eventos están disponibles durante 7 días, y Data Stream los exporta a sistemas externos, alimentando SIEM, data lakes y herramientas de análisis como Splunk, Datadog y BigQuery.

Después de algunos días con tráfico real, tratas los falsos positivos y le pides al agente que cambie al modo de bloqueo, en otro pull request. Si alguien pregunta qué se bloqueó y por qué, los eventos muestran la respuesta; para conservar ese historial más de 7 días, expórtalo con Data Stream.

Paso a paso para proteger un SaaS en producción con Azion

1. Conecta el agente de programación, como Claude Code, a los MCP servers de Azion con un token personal.
2. Pide la configuración: el connector para el servidor actual, el rate limiting en el login y en el catálogo, y Bot Manager Lite con la acción allow en azion.config.ts, además de los comandos de la Azion CLI que crean el WAF y su regla en modo logging.
3. Revisa el pull request con azion.config.ts y aprueba el cambio.
4. Con la Azion CLI autenticada, ejecuta azion deploy, crea el WAF y su regla en el Firewall y apunta el dominio de la app a Azion en el DNS.
5. Emite el certificado TLS del dominio con Let’s Encrypt.
6. Restringe el origen al tráfico que viene de Azion, con Origin Shield y el firewall del origen.
7. Revisa Real-Time Events durante algunos días y trata los falsos positivos.
8. Pídele al agente el cambio al modo de bloqueo, en un nuevo pull request.

Cómo HeroSpark redujo en 99.5% los incidentes de fraude y ataques

Sin el flujo con agente descrito aquí, pero con las mismas protecciones, HeroSpark, plataforma SaaS de educación digital con una solución propia de pagos, HeroPay, enfrentaba fraudes y ataques que consumían a su equipo técnico. Con WAF, Bot Manager y DDoS Protection de Azion, redujo en 99.5% los incidentes de fraude y ataques. Y, con el Security Response Team (SRT) de Azion automatizando la detección y la respuesta, le devolvió al equipo más de 200 horas de trabajo manual al mes.

Seguridad y gobernanza para el SaaS que ya está en producción

Proteger un SaaS bajo ataque no tiene que esperar un replatform ni la contratación de un equipo de seguridad. Con Azion delante de la aplicación, WAF, Bot Manager, rate limiting y DDoS Protection empiezan a funcionar sin cambiar una línea del código de la app, y cada decisión de bloqueo queda registrada en Real-Time Events.

Las protecciones se ejecutan en la misma plataforma, sobre la infraestructura distribuida de Azion, y el bloqueo ocurre en el data center que recibe la solicitud, lejos de tu servidor. Y, como la política vive en un archivo versionado y revisado en pull request, el desarrollador que hoy responde por la seguridad gana un proceso que sigue funcionando cuando el equipo crezca. Si el SaaS todavía está por nacer, el camino completo está en Cómo estructurar un SaaS con AI y seguridad en Azion.

¿Tu SaaS está bajo ataque ahora? Habla con un especialista de Azion para proteger tu app sin migrar, o crea una cuenta gratis para probar la configuración antes.

Preguntas frecuentes

¿Necesito cambiar el código de la aplicación para usar un WAF? No. Declaras la política de seguridad en un archivo de configuración, apuntas el dominio de la app a Azion en el DNS y, para que nadie evite la protección, restringes el origen al tráfico que viene de Azion.

¿Cómo bloquear el scraping en mi SaaS? Combinando Bot Manager Lite, que puntúa cada solicitud por señales como encabezados y cookies de sesión, y no solo por la IP, con rate limiting por IP en las rutas más atacadas, como el catálogo de productos.

¿Bot Manager Lite puede bloquear a clientes reales? Puede, si empieza bloqueando. Por eso entra en modo de observación, con la acción allow, que solo registra, y el bloqueo llega después de algunos días de tráfico real y del ajuste de los falsos positivos.

¿Qué es el credential stuffing? Es el ataque en el que bots prueban, de forma masiva, combinaciones de e-mail y contraseña filtradas de otros servicios, apostando a que parte de los usuarios repite la misma contraseña. En un SaaS, aparece como miles de inicios de sesión fallidos en poco tiempo.

¿Qué es el scraping de precios y por qué es un problema? El scraping es la recopilación automatizada de datos de un sitio o API por parte de bots. En un SaaS B2B, suele apuntar a precios y catálogos, que pueden terminar en manos de competidores, además de sobrecargar el servidor.

¿Un agente de programación puede configurar la seguridad de mi app por sí solo? Puede escribir toda la configuración, pero la aprobación debe seguir en manos del equipo. Pide que el agente entregue cada cambio como pull request en el archivo de configuración, en lugar de modificar la cuenta directamente a través de los MCP servers, y ejecuta el deploy solo después del merge.

¿Funciona si mi SaaS se ejecuta en AWS, Azure o Google Cloud? Sí. La aplicación sigue en la nube donde ya está, o en servidores propios; solo el dominio pasa a apuntar a Azion, que filtra las solicitudes antes de reenviarlas al servidor de origen.

¿Cómo proteger el login contra fuerza bruta y credential stuffing? Con rate limiting por IP en la ruta de login y Bot Manager puntuando cada intento, lo que ayuda contra bots que cambian de IP. En la aplicación, MFA y la verificación de contraseñas filtradas completan la protección. El post sobre seguridad de API financieras muestra la misma combinación aplicada a API con datos sensibles.