Adotar microsserviço costuma ser vendido como decisão puramente positiva: times mais autônomos, deploys independentes, sistema mais fácil de escalar. O que raramente entra nessa conta é o outro lado da divisão: cada serviço novo é também uma porta nova, com sua própria autenticação, suas próprias dependências e seu próprio risco de configuração errada.
O diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira, destaca que a arquitetura de microsserviço multiplica a superfície de ataque de um jeito que raramente aparece na decisão inicial de adotar o modelo. Um monólito concentra a maior parte do risco no perímetro da aplicação e no acesso ao banco de dados; dez ou vinte serviços interligados multiplicam os pontos por onde algo pode dar errado.
Um serviço vira dez, e cada um é uma porta nova
Em um monólito, boa parte do controle de segurança se concentra em poucos lugares: a borda da aplicação, a camada de autenticação central e o acesso ao banco de dados. Auditar esse perímetro, embora trabalhoso, tem escopo relativamente definido, porque o número de pontos a revisar é pequeno e conhecido de antemão por quem cuida da segurança.
Ao quebrar essa aplicação em microsserviços, cada peça passa a ter API própria, banco ou cache próprio, pipeline de entrega próprio e, em muitos casos, uma conta de serviço com permissões específicas. O número de lugares onde um erro de configuração pode abrir uma brecha cresce na mesma proporção do número de serviços, mesmo que cada um deles, isoladamente, pareça mais simples que o monólito original.
Onde nascem os novos pontos de entrada?
Boa parte do risco adicional não vem dos serviços voltados ao usuário final, e sim da comunicação interna entre eles: filas de mensagens, caches compartilhados, registros de imagem de contêiner e integrações com serviços de terceiros usados na esteira de entrega. Cada um desses componentes troca dados e executa ação em nome do negócio, muitas vezes sem o mesmo nível de escrutínio aplicado à porta de entrada principal.
Jean Pierre Lessa e Santos Ferreira informa que um erro comum é presumir que tráfego originado de dentro da própria rede é automaticamente confiável. Um endereço IP interno não comprova a identidade de quem está fazendo a chamada, e essa suposição de confiança implícita costuma ser o ponto que um invasor explora depois de comprometer qualquer serviço, mesmo um aparentemente pouco relevante.
Por que um serviço comprometido pode virar acesso à rede inteira?
Quando o modelo de segurança assume que tudo dentro do ambiente é confiável por padrão, um único segredo exposto ou uma imagem de contêiner contaminado pode abrir caminho para movimentação lateral, o deslocamento do invasor de um serviço comprometido para outros, mais sensíveis, sem passar de novo pelo perímetro externo.
Jean Pierre Lessa e Santos Ferreira considera que o dano real de um incidente em microsserviços costuma ser medido pelo raio de alcance da falha, não pelo ponto exato de entrada. Um serviço de baixo risco, comprometido primeiro, pode servir de trampolim para dados e sistemas muito mais críticos, se não houver barreira entre eles.
Segurança como parte do desenho da arquitetura, não como camada adicional
Segmentação por rede ajuda, mas sozinha não resolve o problema, porque não verifica identidade nem autorização por chamada. O modelo mais eficaz combina autenticação mútua entre serviços, criptografia no tráfego interno e permissões restritas ao mínimo necessário para cada função, decisões tomadas no momento em que o serviço é desenhado, não adicionadas depois que ele já está em produção.
Jean Pierre Lessa e Santos Ferreira revela que empresas que tratam segurança como parte do desenho da arquitetura, e não como camada aplicada por cima no fim do projeto, conseguem manter a velocidade de entrega que motivou a adoção de microsserviço em primeiro lugar, sem transformar cada novo serviço em uma negociação manual com o time de segurança.
