Na última década, a busca por ciclos de desenvolvimento mais rápidos, alta disponibilidade, dimensionamento seletivo sob demanda e desacoplamento em geral direcionou organizações orientadas por tecnologia para a arquitetura de microsserviços. Como resultado, muitas chamadas de funções seguras em software monolítico se transformaram em chamadas de API entre microsserviços em redes não seguras. Ou seja, embora essa transição tenha resolvido muitos desafios operacionais e comerciais, ela deu origem a alguns novos desafios de segurança.
A situação de segurança é agravada com a proliferação de software de código aberto, conteinerização e infraestrutura como código (IaC). Agora que integrar ou modificar um microsserviço pode ser uma tarefa de 15 minutos, as equipes de segurança podem não ter a oportunidade oportuna de analisar a segurança dos microsserviços adequadamente. A introdução de uma avaliação de segurança abrangente como uma fase de preparação em pipelines de implantação quase sempre recebe uma reação desfavorável da equipe de DevOps. Mesmo que alguém tenha sucesso em controlar a implantação de forma eficiente, muitos problemas de segurança — especialmente ataques em tempo de execução — não podem ser identificados no momento da implantação.
Embora os desenvolvedores e as equipes de DevOps tenham motivos para abraçar calorosamente a transição para microsserviços, as equipes de segurança lutam cada vez mais para acompanhar um volume crescente de APIs, mudanças nas definições e comportamentos de API, falta de documentação de API (especialmente em componentes de código aberto), diversos protocolos e estruturas de carga útil. Agora que muitas chamadas de funções internas entre módulos se tornaram chamadas de API entre microsserviços, a superfície de ataque explodiu e gerenciar a segurança se tornou extremamente difícil muito rapidamente.
Mesmo em média escala em um ambiente de microsserviços, definir e manter uma lista de comportamentos normais e aceitáveis para cada ponto de extremidade da API antes que qualquer microsserviço seja implantado ou atualizado é muito desafiador, se não impossível. Isso também inclui manter uma política de autorização para cada ponto de extremidade da API. Adições de novos microsserviços, remoção de microsserviços obsoletos e sazonalidade no tráfego são as razões previsíveis pelas quais a definição de “normal e aceitável” continua mudando. Há também razões não tão previsíveis, como interrupções intermitentes de rede, ataques DDoS, interrupções de upstream e explorações de segurança, que também podem desempenhar um papel importante.
Considerando todos os fatores a serem considerados para uma segurança adequada, uma grande quantidade de dados precisa ser coletada, correlacionada, processada e aprendida quase em tempo real para tomar decisões de segurança razoáveis e oportunas. Esse requisito torna as soluções e os controles tradicionais inadequados. Felizmente, os avanços no aprendizado de máquina (ML) e a maturidade dos modelos de aprendizado na última década fornecem uma plataforma muito poderosa para enfrentar esses novos desafios de segurança.
O poder do ML nos permite repensar a maneira como definimos, refinamos e implementamos controles de segurança. Ele nos permite lidar com a natureza dinâmica das interações da API e ainda fornecer segurança de API eficaz. Agora discutiremos as três principais etapas para alcançar uma solução abrangente e eficaz baseada em ML.
Conforme discutido anteriormente, a natureza dinâmica e o grande volume de APIs tornam impraticável para desenvolvedores ou equipes de segurança definir e alimentar definições de API de forma significativa para sistemas que protegem os endpoints de API. Com modelos baseados em ML, é possível inserir alguns dados de treinamento offline e deixar que o sistema descubra, identifique, classifique, contabilize e permita/negue chamadas de API de forma autônoma com base no ponto de extremidade da API (por exemplo, caminho da URL no caso de HTTP), chamador, carga útil, etc. Por exemplo, a descoberta de API é realizada usando um gráfico de URL baseado em ML e a classificação de componentes pode ser feita usando aprendizado profundo. Isso permite que o sistema crie, desenvolva e aprenda o escopo e a natureza da comunicação da API ao longo do tempo.
Um sistema bem calibrado para tal descoberta de escopo pode substituir dias, se não semanas, de esforços humanos para cada implantação atualizada em poucas horas.
Esta é a parte central de qualquer solução de segurança baseada em ML. Boas soluções permitem que os controles de segurança observem o comportamento do sistema, criem perfis de comportamento e ajustem o modelo atual (construído usando observações anteriores). Este é um processo contínuo, e uma solução implementada de forma limpa permite que os controles sejam aplicados de forma significativa e oportuna. Por exemplo, se perfis anteriores mostraram que uma sequência específica de chamadas de APIs é um fluxo normal, uma compilação atualizada do aplicativo que implementa algumas chamadas extras no fluxo pode ser aprendida e adicionada ao perfil em questão de horas.
É aqui que o argumento para soluções baseadas em ML é muito fácil de entender, já que o perfil de comportamento e a calibração são tão em tempo real quanto possível.
Os dois primeiros passos nos permitem aprender e nos manter atualizados sobre o que deve ser considerado comportamento “normal e aceitável” no sistema. O passo final é detectar e identificar os padrões de comportamento que estão fora dessa faixa. Por exemplo, se depois de aprender o comportamento normal de centenas de usuários o sistema perceber uma onda repentina de tentativas de login ou download de dados de um usuário específico, ou vários usuários tentando fazer login no mesmo endereço de rede em um curto espaço de tempo, esses comportamentos podem ser rapidamente chamados de anomalias. A detecção de anomalias de API pode ser feita usando aprendizado profundo sequencial não supervisionado.
É importante observar aqui que o atraso do feedback é uma parte muito crítica de todo o ciclo de aprendizagem para não permitir que agentes mal-intencionados ajustem seu comportamento e “voem sob o radar”.
A Figura 2 mostra uma sequência de chamadas de API que é considerada normal e aceitável pelo sistema.
A Figura 3 mostra sequências anômalas de chamadas de API que seriam detectadas e sinalizadas pelo sistema.
É importante observar aqui que o atraso do feedback é uma parte muito crítica de todo o ciclo de aprendizagem para não permitir que agentes mal-intencionados ajustem seu comportamento e “voem sob o radar”.
Depois que essas soluções forem implementadas e começarem a produzir resultados, será possível aproveitá-las para aprimorar controles existentes, como firewalls de aplicativos da Web (WAFs) para tráfego baseado em HTTP.
O ML é poderoso e as soluções baseadas em ML rapidamente se tornaram uma parte essencial da segurança geral em ambientes baseados em microsserviços. Na Volterra, reconhecemos muito cedo a necessidade de ML para nossas operações internas, além de fornecê-lo como um recurso essencial para nossos clientes à medida que eles fazem a transição para aplicativos modernos de forma eficaz, segura e eficiente.