Cómo estructurar un SaaS con AI y seguridad en Azion

Un SaaS con AI puede reunir una API serverless, una base de datos, un modelo de lenguaje y herramientas de protección. Cuando estos componentes están distribuidos entre distintos proveedores, el equipo necesita gestionar configuraciones e investigar eventos en más de un entorno.

Al mismo tiempo, los agentes de codificación como Claude Code y Codex pueden acelerar la creación de aplicaciones y API. Para seguir ese ritmo, los equipos necesitan incorporar la revisión y la configuración de los controles de seguridad al flujo de desarrollo.

En Azion Platform, la aplicación, los datos, la inferencia de AI y los controles de seguridad pueden reunirse en un solo lugar, y la política puede declararse como código, revisarse y versionarse junto con la aplicación.

En este artículo, usamos un SaaS financiero ficticio para mostrar cómo se combinan estos componentes y cómo la seguridad entra en el flujo de desarrollo y deploy.

La arquitectura del SaaS de ejemplo

El ejemplo es una app ficticia de gestión financiera para pequeñas empresas que registra movimientos, importa estados de cuenta y tiene un asistente de AI que responde preguntas sobre el flujo de caja. Los pagos llegan por webhook desde un gateway externo.

La siguiente tabla compara una arquitectura distribuida entre proveedores con lo que Azion brinda para cada pieza:

La API se ejecuta en Functions y lee los movimientos en SQL Database. El asistente llama a un modelo de AI Inference desde la propia function, sin clave de otro proveedor, y recibe solo los totales agregados, nunca la tabla completa.

Seguridad en el flujo de desarrollo y deploy

La política de seguridad puede gestionarse de más de una forma. Con Azion CLI, se declara en azion.config.ts, junto al código de la aplicación, y los equipos que usan Terraform declaran los mismos recursos con el provider de Azion. Como en ambos casos la política vive en archivos versionados, los cambios pasan por el mismo proceso de revisión del código. La API, por su parte, permite automatizar cambios desde otras herramientas.

En este flujo, conviene separar dos roles: el agente de codificación, como Claude Code o Codex, ayuda al equipo a desarrollar y configurar el SaaS, mientras que el asistente de AI forma parte del producto y llama a un modelo para responder las preguntas de los usuarios.

Los MCP Servers de Azion dan a los agentes de codificación acceso a la documentación, a los ejemplos de código y a las referencias de la CLI y de la API. Según los permisos otorgados, también pueden crear o modificar recursos de la cuenta, por lo que le corresponde al equipo decidir si el agente prepara cambios para revisión o si los aplica directamente.

Con la configuración en el repositorio, el flujo puede seguir cuatro pasos:

1. El equipo, con o sin un agente de codificación, prepara los cambios del código y de la política en el repositorio.
2. El equipo de seguridad revisa y aprueba los cambios en code review.
3. Azion CLI crea o actualiza en la plataforma la política declarada en el archivo.
4. Real-Time Events permite consultar, por solicitud, cómo actuaron los controles del Firewall.

API y endpoints de AI bajo la misma política

La app tiene rutas distintas, como el login, la importación de estados de cuenta, el asistente de AI y el webhook de pagos, y cada una puede tener reglas propias en el mismo Firewall. El asistente se protege como cualquier otra API, porque también recibe solicitudes HTTP, y lo mismo aplica para los agentes en producción.

La siguiente tabla muestra el riesgo y la protección de cada ruta:

La capa de red no lo resuelve todo: la autorización entre empresas, la verificación de la firma del webhook, la validación de los archivos enviados y la protección contra prompt injection siguen siendo responsabilidad de la aplicación.

Política como código, revisada en code review

El problema comienza en el primer deploy: sin reglas, el login acepta intentos ilimitados y el webhook acepta llamadas de cualquier origen.

El siguiente fragmento ilustra cómo un equipo podría declarar una regla de rate limit en azion.config.ts. Los parámetros deben ajustarse al tráfico y a las necesidades de la aplicación, y la referencia completa del archivo está en la documentación de Azion CLI.

firewall: [
  {
    name: 'finanzas',
    active: true,
    waf: true,
    rules: [
      {
        name: 'login-rate-limit',
        active: true,
        criteria: [
          { variable: '${request_uri}', conditional: 'if', operator: 'starts_with', argument: '/api/auth/login' },
        ],
        behaviors: [
          { type: 'set_rate_limit', attributes: { type: 'second', limitBy: 'client_ip', averageRateLimit: '1', maximumBurstSize: '5' } },
        ],
      },
    ],
  },
],

Con esta regla de rate limit, el login acepta un intento por segundo por IP en cada data center, con un burst de 5: el excedente entra en cola, y lo que supera el burst recibe el status 429. Estos valores son solo un ejemplo y deben calibrarse con el tráfico real, ya que quien se equivoca de contraseña suele intentar pocas veces y un ataque automatizado intenta muchas más.

El webhook, en cambio, usa otra regla, en la que una Network List guarda los rangos de IP del gateway de pagos y el Firewall rechaza lo que venga de fuera de ella.

Como la política está versionada, cada cambio pasa por code review antes de aplicarse. El Firewall también puede reutilizarse: en lugar de copiar las reglas, el deployment de un nuevo workload puede hacer referencia a un Firewall existente por nombre o por ID. De la misma forma, un cambio en una Network List llega a todas las reglas que la referencian, sin tener que editar cada una.

WAF, Bot Manager y DDoS Protection en un solo control plane

En Azion, WAF, Bot Manager, DDoS Protection y Network Shield operan bajo la misma política y la misma observabilidad, lo que evita reglas duplicadas entre herramientas de distintos proveedores. El WAF Rule Set se aplica mediante una regla del mismo Firewall y empieza en modo de aprendizaje (learning), en el que solo identifica y registra las solicitudes sospechosas, sin interrumpir el tráfico.

El paso al modo de bloqueo (blocking), en el que esas solicitudes pasan a ser rechazadas, depende del análisis del tráfico real y de los falsos positivos. Como referencia, la documentación sugiere hacer el cambio después de 3 días en los que ninguna solicitud legítima habría sido bloqueada. Como la política está en el repositorio, este cambio se hace en el archivo de configuración y pasa por el mismo code review que las demás reglas antes de aplicarse.

La inspección y el bloqueo ocurren en el data center que recibe la solicitud, sin esperar el reanuncio de prefijos en redes de terceros, y una solicitud bloqueada por una regla del Firewall no llega al origen. DDoS Protection está siempre activo, sin configuración. Bot Manager, por su parte, puntúa cada solicitud por firmas, fingerprint, reputación y comportamiento, y actúa sobre las que superan el threshold definido por el equipo, antes de que lleguen a la aplicación.

Visibilidad por solicitud para investigación y auditoría

Real-Time Events da acceso a las solicitudes que pasan por el Firewall, con los campos del WAF, disponibles para consulta en hasta 30 segundos y con una retención de 7 días por defecto.

Para investigar un bloqueo, cada evento incluye campos como wafMatch, que muestra la infracción y el fragmento de la solicitud que la activó, y wafScore, que muestra la puntuación por familia de amenaza. Si Debug Rules está activado en la Application o en el Firewall (viene desactivado), el campo stacktrace también indica qué reglas se ejecutaron.

Data Stream exporta estos eventos a sistemas externos y alimenta SIEMs, data lakes y herramientas de análisis. Entre los destinos están Splunk, Datadog, QRadar, Elasticsearch, Kafka, S3, BigQuery y Azure Monitor. En auditorías como las de PCI DSS o LGPD, estos registros ayudan a conformar la evidencia de cómo actuaron los controles, sin reunir logs de varios proveedores, pero no demuestran compliance por sí solos.

Empresas que confían en Azion para proteger sus aplicaciones

Las empresas que no pueden detenerse ya confían en Azion para mantener aplicaciones y API en línea durante ataques. En el sector financiero, Crefisa cuenta con el Firewall de Azion para proteger aplicaciones y API: mitigó millones de ataques complejos, incluidos DDoS, bots maliciosos y amenazas web, y migró decenas de dominios a Azion durante la transición de un data center tradicional a la nube. Lee el caso de Crefisa.

Para otras, la AI y la seguridad forman parte del mismo negocio. Axur, empresa de seguridad digital, llevó la inferencia de sus modelos a AI Inference y logró 5 minutos entre detectar una amenaza y solicitar su remoción, con más de 30.000 remociones automatizadas al mes. Lee el caso de Axur.

Seguridad al ritmo del desarrollo

Con aplicación, datos, inferencia de AI y seguridad en la misma plataforma, el equipo reduce la integración entre proveedores y lleva la política de seguridad al mismo flujo del código. Los agentes de codificación pueden ayudar a preparar las reglas, y el equipo revisa, versiona y reutiliza la política en las próximas aplicaciones, API y agentes en producción.

Empieza gratis o habla con un especialista.

Próximos pasos:

• Documentación de los MCP Servers de Azion (en inglés)
• Referencia de azion.config.ts (en inglés)

Preguntas frecuentes

¿El agente de codificación puede aplicar una política de seguridad sin revisión humana? Depende de los permisos otorgados al agente y del flujo definido por la organización. A través de los MCP Servers de Azion, el agente consulta la documentación y puede crear recursos como reglas del Firewall y Network Lists. Por eso, se recomienda que el equipo de seguridad apruebe los cambios en code review antes del deploy.

¿Cómo proteger un endpoint de AI contra abusos? Con una combinación de controles en el Firewall: rate limit por IP, Bot Manager, WAF y reglas que reducen el volumen de solicitudes, como el bloqueo geográfico. En el código, los límites de tamaño de la pregunta y de tokens de la respuesta completan la protección y ayudan a controlar el costo de inferencia.

¿El WAF de Azion bloquea ataques desde el primer día? Sí, en la mayoría de los casos, porque el WAF detecta señales de ataque incluso cuando no coinciden con una firma completa conocida. Aun así, la recomendación es empezar en modo de aprendizaje y pasar al modo de bloqueo después de analizar el tráfico real y tratar los falsos positivos.

¿El WAF protege contra prompt injection? El WAF filtra ataques web, como SQL injection y XSS, pero prompt injection está en el contenido de los mensajes enviados al modelo. Con Functions, el equipo puede implementar la inspección del contenido JSON de las solicitudes y crear sus propias reglas de negocio como código. En la aplicación, limitar los datos y las herramientas a los que accede el modelo, validar las acciones y revisar las respuestas siguen siendo necesarios.

¿Azion protege tanto aplicaciones serverless como tradicionales, alojadas en la nube u on-premise? Sí. Las aplicaciones serverless se ejecutan en Functions, y las aplicaciones tradicionales, alojadas en otra nube u on-premise, quedan detrás del proxy de Azion. En ambos casos, el mismo Firewall y el mismo WAF Rule Set inspeccionan las solicitudes antes de que lleguen a la aplicación.

¿Qué es la seguridad como código en Azion? Es declarar la política de seguridad, con Firewall, WAF Rule Set, Network Lists y rate limit, en archivos versionados en el repositorio de la aplicación: azion.config.ts, que usa Azion CLI, o los recursos del Terraform provider de Azion. Los cambios pasan por code review y se aplican con la herramienta elegida. Con Functions, también puedes escribir código que trate cada solicitud según las necesidades de la aplicación.