Como estruturar um SaaS com AI e segurança na Azion

Um SaaS com AI pode reunir uma API serverless, um banco de dados, um modelo de linguagem e ferramentas de proteção. Quando esses componentes ficam distribuídos entre diferentes fornecedores, a equipe precisa gerenciar configurações e investigar eventos em mais de um ambiente.

Ao mesmo tempo, agentes de codificação como Claude Code e Codex podem acelerar a criação de aplicações e APIs. Para acompanhar esse ritmo, as equipes precisam incorporar a revisão e a configuração dos controles de segurança ao fluxo de desenvolvimento.

Na Azion Platform, aplicação, dados, inferência de AI e controles de segurança podem ser reunidos em um só lugar, e a política pode ser declarada como código, revisada e versionada junto à aplicação.

Neste artigo, usamos um SaaS financeiro fictício para mostrar como esses componentes se combinam e como a segurança entra no fluxo de desenvolvimento e deploy.

A arquitetura do SaaS de exemplo

O exemplo é um app fictício de gestão financeira para pequenas empresas que registra lançamentos, importa extratos e tem um assistente de AI que responde perguntas sobre o caixa. Os pagamentos chegam por webhook de um gateway externo.

A tabela abaixo compara uma arquitetura distribuída entre fornecedores com o que a Azion oferece para cada peça:

A API roda em Functions e lê os lançamentos no SQL Database. O assistente chama um modelo do AI Inference pela própria function, sem chave de outro provedor, e recebe só os totais agregados, nunca a tabela inteira.

Segurança no fluxo de desenvolvimento e deploy

A política de segurança pode ser gerenciada de mais de uma forma. Com a Azion CLI, ela fica declarada no azion.config.ts, ao lado do código da aplicação, e equipes que usam Terraform declaram os mesmos recursos com o provider da Azion. Como nesses dois casos a política vive em arquivos versionados, as mudanças passam pelo mesmo processo de revisão do código. Já a API permite automatizar alterações a partir de outras ferramentas.

Nesse fluxo, vale separar dois papéis: o agente de codificação, como Claude Code ou Codex, ajuda a equipe a desenvolver e configurar o SaaS, enquanto o assistente de AI faz parte do produto e chama um modelo para responder às perguntas dos usuários.

Os MCP Servers da Azion dão a agentes de codificação acesso à documentação, aos exemplos de código e às referências da CLI e da API. Conforme as permissões concedidas, eles também podem criar ou alterar recursos da conta, e por isso cabe à equipe decidir se o agente prepara alterações para revisão ou se aplica mudanças diretamente.

Com a configuração no repositório, o fluxo pode seguir quatro etapas:

1. A equipe, com ou sem um agente de codificação, prepara as alterações do código e da política no repositório.
2. O time de segurança revisa e aprova as alterações em code review.
3. A Azion CLI cria ou atualiza na plataforma a política declarada no arquivo.
4. O Real-Time Events permite consultar, por requisição, como os controles do Firewall atuaram.

APIs e endpoints de AI sob a mesma política

O app tem rotas distintas, como o login, a importação de extratos, o assistente de AI e o webhook de pagamentos, e cada uma pode ter regras próprias no mesmo Firewall. O assistente é protegido como qualquer outra API, porque também recebe requisições HTTP, e o mesmo vale para agentes em produção.

A tabela abaixo mostra o risco e a proteção de cada rota:

A camada de rede não resolve tudo: autorização entre empresas, verificação da assinatura do webhook, validação dos arquivos enviados e proteção contra prompt injection continuam sendo responsabilidade da aplicação.

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

O problema começa no primeiro deploy: sem regras, o login aceita tentativas sem limite e o webhook aceita chamadas de qualquer origem.

O trecho abaixo ilustra como uma equipe poderia declarar uma regra de rate limit no azion.config.ts. Os parâmetros devem ser ajustados ao tráfego e às necessidades da aplicação, e a referência completa do arquivo está na documentação da Azion CLI.

firewall: [
  {
    name: 'financeiro',
    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' } },
        ],
      },
    ],
  },
],



Com essa regra de rate limit, o login aceita uma tentativa por segundo por IP em cada data center, com burst de 5: o excesso entra em fila, e o que passa do burst recebe status 429. Esses valores são apenas um exemplo e devem ser calibrados com o tráfego real, já que quem erra a senha costuma tentar poucas vezes e um ataque automatizado tenta muito mais.

Já o webhook usa outra regra, em que uma Network List guarda as faixas de IP do gateway de pagamento e o Firewall nega o que vier de fora dela.

Como a política fica versionada, cada alteração passa por code review antes de ser aplicada. O Firewall também pode ser reutilizado: em vez de copiar as regras, o deployment de um novo workload pode referenciar um Firewall existente pelo nome ou pelo ID. Da mesma forma, uma alteração em uma Network List chega a todas as regras que a referenciam, sem que cada uma precise ser editada.

WAF, Bot Manager e DDoS Protection em um control plane

Na Azion, WAF, Bot Manager, DDoS Protection e Network Shield operam sob a mesma política e a mesma observabilidade, evitando regras duplicadas entre ferramentas de fornecedores diferentes. O WAF Rule Set é aplicado por uma regra do mesmo Firewall e começa em modo de aprendizado (learning), em que apenas identifica e registra as requisições suspeitas, sem interromper o tráfego.

A passagem para o modo de bloqueio (blocking), em que essas requisições passam a ser recusadas, depende da análise do tráfego real e dos falsos positivos. Como referência, a documentação sugere fazer a troca depois de 3 dias em que nenhuma requisição legítima teria sido bloqueada. Como a política está no repositório, essa mudança é feita no arquivo de configuração e passa pelo mesmo code review das demais regras antes de ser aplicada.

A inspeção e o bloqueio acontecem no data center que recebe a requisição, sem esperar reanúncio de prefixo em redes de terceiros, e uma requisição bloqueada por uma regra do Firewall não chega à origem. O DDoS Protection está sempre ligado, sem configuração. Já o Bot Manager pontua cada requisição por assinaturas, fingerprint, reputação e comportamento e age sobre as que passam do threshold definido pela equipe, antes de chegarem à aplicação.

Visibilidade por requisição para investigação e auditoria

O Real-Time Events dá acesso às requisições que passam pelo Firewall, com os campos do WAF, disponíveis para consulta em até 30 segundos e com retenção de 7 dias por padrão.

Para investigar um bloqueio, cada evento traz campos como o wafMatch, que lista a infração e o trecho da requisição que a disparou, e o wafScore, que mostra a pontuação por família de ameaça. Se o Debug Rules estiver ativado na Application ou no Firewall (ele vem desligado), o campo stacktrace também indica quais regras foram executadas.

O Data Stream exporta esses eventos para sistemas externos, abastecendo SIEMs, data lakes e ferramentas de análise. Entre os destinos estão Splunk, Datadog, QRadar, Elasticsearch, Kafka, S3, BigQuery e Azure Monitor. Em auditorias como as de PCI DSS ou LGPD, esses registros ajudam a compor a evidência de como os controles atuaram, sem juntar logs de vários fornecedores, mas não demonstram conformidade sozinhos.

Quem confia na Azion para proteger suas aplicações

Empresas que não podem parar já confiam na Azion para manter aplicações e APIs no ar durante ataques. No setor financeiro, a Crefisa conta com o Firewall da Azion para proteger aplicações e APIs: mitigou milhões de ataques complexos, incluindo DDoS, bots maliciosos e ameaças web, e migrou dezenas de domínios para a Azion durante a transição de um data center tradicional para a cloud. Veja o case da Crefisa.

Para outras, AI e segurança fazem parte do mesmo negócio. A Axur, empresa de segurança digital, levou a inferência dos seus modelos para o AI Inference e chegou a 5 minutos entre detectar uma ameaça e pedir sua remoção, com mais de 30 mil remoções automatizadas por mês. Veja o case da Axur.

Segurança no ritmo do desenvolvimento

Com aplicação, dados, inferência de AI e segurança na mesma plataforma, a equipe reduz a integração entre fornecedores e traz a política de segurança para o mesmo fluxo do código. Agentes de codificação podem ajudar a preparar as regras, e a equipe revisa, versiona e reutiliza a política nas próximas aplicações, APIs e agentes em produção.

Comece grátis ou fale com um especialista.

Próximos passos:

• Documentação dos MCP Servers da Azion
• Referência do azion.config.ts

Perguntas frequentes

O agente de codificação pode aplicar uma política de segurança sem revisão humana? Isso depende das permissões concedidas ao agente e do fluxo definido pela organização. Pelos MCP Servers da Azion, o agente consulta a documentação e pode criar recursos como regras do Firewall e Network Lists. Por isso, recomenda-se que o time de segurança aprove as alterações em code review antes do deploy.

Como proteger um endpoint de AI contra abuso? Com uma combinação de controles no Firewall: rate limit por IP, Bot Manager, WAF e regras que reduzem o volume de requisições, como bloqueio geográfico. No código, limites de tamanho da pergunta e de tokens da resposta completam a proteção e ajudam a controlar o custo de inferência.

O WAF da Azion bloqueia ataques desde o primeiro dia? Sim, na maior parte dos casos, porque o WAF detecta sinais de ataque mesmo quando eles não correspondem a uma assinatura completa conhecida. Ainda assim, a recomendação é começar no modo de aprendizado e passar para o modo de bloqueio depois de analisar o tráfego real e tratar os falsos positivos.

O WAF protege contra prompt injection? O WAF filtra ataques web, como SQL injection e XSS, mas prompt injection está no conteúdo das mensagens enviadas ao modelo. Com Functions, a equipe pode implementar a inspeção do conteúdo JSON das requisições e criar suas próprias regras de negócio como código. Na aplicação, limitar os dados e as ferramentas que o modelo acessa, validar as ações e revisar as respostas continuam sendo necessários.

A Azion protege tanto aplicações serverless quanto tradicionais, hospedadas em cloud ou on-premise? Sim. Aplicações serverless rodam em Functions, e aplicações tradicionais, hospedadas em outra cloud ou on-premise, ficam atrás do proxy da Azion. Nos dois casos, o mesmo Firewall e o mesmo WAF Rule Set inspecionam as requisições antes de chegarem à aplicação.

O que é segurança como código na Azion? É declarar a política de segurança, com Firewall, WAF Rule Set, Network Lists e rate limit, em arquivos versionados no repositório da aplicação: o azion.config.ts, usado pela Azion CLI, ou os recursos do Terraform provider da Azion. As alterações passam por code review e são aplicadas pela ferramenta escolhida. Com Functions, também é possível escrever código que trata cada requisição conforme a necessidade da aplicação.