Do código aprovado à proteção em produção

Uma nova API entra em produção. A equipe revisou o código e testou a funcionalidade, mas as regras de proteção estão ativas? O WAF foi associado à aplicação? Os limites de requisições foram configurados para as rotas sensíveis? Essas verificações ajudam a evitar um intervalo entre a publicação e a proteção do tráfego.

Aplicações, APIs e endpoints de agentes de AI precisam dessa proteção desde as primeiras requisições. SAST e SCA ajudam a identificar riscos no código e nas dependências antes do deploy; WAF, regras de Firewall e controles contra automação abusiva atuam sobre o tráfego em produção. Integrar essas etapas exige definir a proteção necessária, aplicá-la na publicação e verificar seu funcionamento.

O custo da proteção configurada depois do deploy

Cada vez mais, aplicações combinam microsserviços, APIs internas, integrações externas e componentes serverless. Essa arquitetura pode acelerar as entregas, mas também amplia os pontos que recebem tráfego e precisam de proteção.

Quando a configuração de segurança acontece depois do deploy, por tickets ou alterações manuais em consoles separados, pode surgir uma janela de exposição. Conforme o número de aplicações cresce, as revisões podem deixar de acompanhar as entregas, e novas aplicações entram em produção com menos proteção que as já revisadas.

Essa fragmentação também pesa na operação:

Frente	Efeito operacional	Como perceber
Custo	Configurações repetidas e possível duplicação de eventos no SIEM e Analytics.	A equipe consulta vários consoles para explicar um bloqueio e concilia evidências divergentes.
Eficiência e investigação	Manter políticas em ferramentas diferentes aumenta o trabalho operacional.	Localizar a causa de um falso positivo e ajustar a regra leva horas.
Segurança e disponibilidade	Novas aplicações podem receber menos proteção que as já revisadas.	Uma aplicação aparece no inventário sem a política prevista.

Uma base de proteção reutilizável ajuda a reduzir esse esforço. A equipe de segurança define e aprova os controles comuns; a engenharia os associa às aplicações durante a publicação. Regras específicas e exceções continuam sendo avaliadas conforme o risco de cada caso.

Uma base aprovada para cada nova aplicação

O ponto de partida é definir o conjunto mínimo de regras de Firewall, WAF, Network Lists e rate limiting que a organização considera adequado. Essa base pode ser compartilhada entre aplicações e ajustada conforme as rotas, a exposição e o comportamento esperado do tráfego.

A mesma lógica atende aplicações desenvolvidas com AI e endpoints públicos de agentes. A ferramenta usada para escrever o código não substitui a revisão de segurança, e um endpoint de agente também precisa dos controles aplicados às demais APIs. O agente de codificação ocupa outro papel: pode apoiar a equipe na preparação das configurações, que seguem as permissões e aprovações da organização.

Reutilizar uma política evita recriar os mesmos controles a cada publicação. Uma Network List, por exemplo, pode ser atualizada uma vez e refletir a mudança nas regras que a utilizam. A equipe mantém uma base comum e revisa os ajustes necessários para cada aplicação.

Como integrar a proteção à publicação

1. Mapeie as entradas de tráfego

Identifique domínios, rotas, APIs, endpoints de agentes e integrações. O inventário precisa mostrar por onde o tráfego entra e quais serviços ele pode alcançar. Esse mapeamento orienta a escolha dos controles e das exceções.

2. Defina e associe os controles

Parta da base aprovada e ajuste a proteção ao risco da aplicação. WAF pode proteger rotas públicas, enquanto rate limiting ajuda a controlar a frequência de acessos a endpoints como /login. Configure as regras no Firewall da Azion e associe a proteção à aplicação.

Para equipes que usam infraestrutura como código, a configuração pode ser versionada junto à aplicação. Isso permite acompanhar quais controles foram propostos e o histórico das alterações.

3. Revise mudanças e exceções

A equipe de segurança avalia regras, limites e alterações sensíveis antes da publicação. Rotas como /login e /checkout podem exigir controles adicionais e uma aprovação específica.

A revisão segue o processo adotado pela organização. Em fluxos com configurações versionadas, o pull request e o histórico do repositório ajudam a identificar quem propôs e aprovou uma mudança.

4. Aplique a configuração no fluxo adotado pela equipe

Os controles podem ser configurados na Azion pelo Console, API, CLI ou Terraform. A execução também pode integrar um pipeline de CI/CD ou ser realizada por um desenvolvedor autorizado.

Agentes de codificação podem ajudar a preparar as configurações com apoio do Azion MCP Server e operar ferramentas conforme as permissões concedidas. Alterações sensíveis continuam sujeitas às aprovações e à separação entre ambientes.

5. Valide a proteção depois do deploy

Confirme a associação da aplicação ao Firewall e consulte os eventos no Real-Time Events para verificar a atuação do WAF. Requisições de teste ajudam a validar bloqueios, limites e exceções antes que um incidente revele um erro de configuração.

O resultado esperado reúne três evidências: a aplicação entrou em produção com as regras previstas, uma requisição de teste recebeu o bloqueio esperado e a equipe encontrou o registro desse evento.

Da configuração ao resultado de uma requisição

Na Azion, a proteção atua antes que o tráfego permitido siga para a origem. O data center que recebe a requisição executa as regras de Firewall, com WAF e Bot Manager acionados conforme os critérios definidos no Rules Engine. DDoS Protection permanece ativo na rede distribuída pelos mais de 100 data centers da plataforma.

Quando o caso exige lógica específica, Functions podem executar código próprio ou de soluções do Marketplace no fluxo da requisição. Essa lógica também pode chamar o AI Inference para apoiar uma análise. O ebook detalha essa arquitetura e os componentes envolvidos.

Para validar a política aplicada, a equipe consulta os campos dos eventos no Real-Time Events pela interface ou API:

• Waf Match indica as infrações detectadas na requisição.
• Waf Score mostra a pontuação por tipo de ameaça. Adocumentação de WAF Score explica a leitura desse campo.
• Stack Trace identifica as regras executadas quando o Debug Rules está ativo.

Os eventos ficam disponíveis, em média, entre 20 e 40 segundos, com retenção de 7 dias na plataforma. Para retenção mais longa e correlação com outros sinais, o Data Stream pode enviá-los às ferramentas de análise e SIEM da organização.

Quem define, quem aplica e quem verifica

A proteção precisa de responsabilidades claras ao longo desse processo. O ebook apresenta um exemplo de divisão que pode ser adaptado à organização:

Responsável	Papel no processo	Evidência
Segurança	Define a proteção mínima, aprova exceções e requisitos de retenção.	Revisões, versões da política e critérios de bloqueio.
Engenharia	Associa a política à aplicação durante o deploy.	Configuração versionada, pipeline e testes.
Infraestrutura	Mantém origens, automação e observabilidade.	Estado dos recursos, eventos e envio ao SIEM.
Auditoria e risco	Confirma a aplicação dos controles aprovados.	Aprovações e registros por requisição.

A configuração e seu histórico ajudam a identificar a política prevista. Os eventos de tráfego mostram o que aconteceu com uma requisição. A plataforma também registra quem definiu ou modificou uma configuração e quando isso ocorreu, apoiando a rastreabilidade.

Essas informações facilitam investigações e a reunião de evidências para auditorias. Os requisitos de aprovação e retenção seguem as normas e os processos de cada organização. A participação de um agente de codificação preserva essa divisão de responsabilidades.

Exemplo de uma nova API pública

Um time lança uma API para parceiros. Ela precisa aceitar o volume legítimo previsto, mas também receber proteção contra tentativas automatizadas de enumeração e exploração.

A equipe parte da base de produção aprovada e acrescenta limites adequados à API. A configuração é revisada antes da publicação e, no deploy, a aplicação recebe a associação ao Firewall e ao WAF.

Depois da publicação, requisições controladas validam a proteção. A equipe consulta os eventos no Real-Time Events para confirmar as regras executadas e envia os registros ao SIEM pelo Data Stream. Uma atualização posterior na base compartilhada pode beneficiar outras aplicações que a referenciam, sem recriar as mesmas regras em cada domínio.

Esse exemplo conecta as etapas: definir os controles, revisar a configuração, aplicá-la e verificar o resultado no tráfego.

Comece por uma aplicação e amplie o modelo

Escolha uma aplicação pública, uma API com volume conhecido ou o endpoint público de um agente de AI. Com a proteção aplicada e os testes validados, a base de regras pode ser estendida a outras aplicações, com ajustes conforme cada contexto.

O ebookSegurança de aplicações e agentes de AI desde o deploy reúne os cinco princípios, a arquitetura de referência e os cenários para aprofundar esse processo. Ele também apresenta caminhos para evoluir a proteção, comomTLS,criptografia pós-quântica e ocaso da HeroSpark.

Baixar o ebook completo →