Quando a segurança não é mais uma opção: vamos falar sobre o campo de batalha invisível em microsserviços

Imagine que você passou vários meses construindo um sistema de controle de servo motor. Os servos de cada junta são ajustados com extrema precisão e os movimentos dos braços robóticos são tão suaves quanto uma dança. Mas uma manhã, você descobre que um módulo “falhou” de repente – não uma falha mecânica, mas alguém entrou por uma pequena porta que você nem percebeu e alterou silenciosamente alguns parâmetros. Todo o sistema ainda está funcionando, mas você sabe, algo está diferente.

Este é provavelmente o sentimento que muitas pessoas enfrentam todos os dias no mundo dos microsserviços.

Por que estamos sempre remendando buracos?

Certa vez, alguém me fez uma pergunta: por que muitas equipes sempre “corrigem” problemas de segurança? Na verdade, a resposta é bem simples - porque no início você não sabe onde fica a porta.

A arquitetura de microsserviços é como um sistema de transmissão mecânica complexo. Cada serviço é uma engrenagem independente, eles giram de forma independente e engrenam entre si. O problema é que quanto mais engrenagens houver, mais lacunas haverá. Você olha para o eixo de transmissão principal e esquece que aquela pequena bomba de lubrificação também pode ficar presa. No momento em que você ouve qualquer ruído anormal, o desgaste já ocorreu.

A abordagem tradicional é cobrir todo o sistema com uma capa protetora. Mas os microsserviços não gostam de coberturas – eles precisam respirar e escalar com flexibilidade. Assim, a segurança se torna a arte de colocar fita adesiva em todos os pontos de conexão. Compense aqui hoje, compense lá amanhã, sempre em dia.

Outra perspectiva: a segurança deve ser incorporada ao sistema

Alguns anos atrás, de repente descobri algo enquanto depurava um braço robótico de seis eixos. O melhor mecanismo de segurança não é uma fechadura externa, mas as “propriedades mecânicas” incorporadas ao design. Assim como os circuitos de realimentação dentro dos servos, eles não são instalados posteriormente, mas fazem parte da rotação do motor.

A segurança dos microsserviços também deveria ser assim. Não deveria ser um item de uma lista de verificação, mas um atributo inerente a todo serviço.

Mas como?

Desmascarando três mitos comuns

Mito 1: “Isso é suficiente se tivermos um firewall” É como instalar uma fechadura na porta da sua oficina, mas deixar as janelas abertas. A comunicação entre microsserviços geralmente ocorre na rede interna e não é visível para o firewall. Essas chamadas de serviço a serviço são como transferir peças entre várias estações de trabalho em uma oficina – mesmo que a porta esteja trancada, as peças ainda circulam internamente.

Mito 2: “Usamos a mais recente tecnologia de criptografia” A criptografia é importante, mas é como aplicar o melhor óleo antiferrugem em engrenagens de precisão. Se a pessoa que aplicou o óleo esqueceu um rolamento pequeno ou aplicou-o com muita espessura e afetou a dissipação de calor, o problema ainda existe. Configurações incorretas de criptografia, confusão no gerenciamento de chaves, certificados expirados... esses são os detalhes que dão errado com mais frequência do que eles próprios.

Mito 3: “Nosso código é todo revisado” A revisão manual é ótima, mas é como inspecionar visualmente cada engrenagem em busca de marcas de dentes. Quando você tem centenas de serviços, atualizados toda semana, sempre falta alguma coisa. Sem mencionar as bibliotecas de terceiros nas quais você confia - assim como o equipamento acabado que você compra, você acredita na sua qualidade, mas você realmente entende cada processo de tratamento térmico?

uma estratégia mais inteligente

Mais tarde, desenvolvi um hábito: cada vez que desenho um novo módulo, faço-me duas perguntas:

1. Se este serviço quer fazer coisas ruins, até onde pode ir?
2. Se alguém quiser fazer algo ruim com este serviço, por onde começar?

Isso pode parecer um pouco neurótico, mas funciona. Assim como ao projetar uma estrutura mecânica, você não considera apenas como ela se move, mas também o que fazer se ficar presa.

Especificamente, vou me concentrar nestes lugares:

• A identidade não é apenas uma chave. Dar a cada serviço uma identidade clara é como atribuir um número a cada ferramenta da oficina. Mas o mais importante é que a identidade deve ter um escopo de autoridade claro – esta chave só pode apertar porcas de um determinado tamanho, este soldador só pode ser usado em uma determinada estação de trabalho. As permissões devem ser detalhadas e suficientes.

• As conversas precisam de supervisão. Cada chamada entre serviços deve ser registrada e inspecionável. Não monitorando, mas como um cartão de fluxo de trabalho na oficina - quem fez qual parte, entregou a quem e quando foi concluída. Dessa forma, quando houver algum problema em um determinado link, você poderá encontrar pistas rapidamente.

• A configuração padrão é “Negar”. A configuração padrão em muitos sistemas é “Permitir” até que você a desative explicitamente. É como um workshop onde todas as ferramentas estão disponíveis por padrão. Uma abordagem melhor é fazer o oposto: todas as operações são negadas por defeito e apenas aquelas que são claramente necessárias são permitidas. Embora a configuração inicial seja mais problemática, é muito mais segura a longo prazo.

• Não confie na rede interna. A oficina não precisa de gerenciamento interno? Muito pelo contrário. Deve-se presumir que o interior é tão perigoso quanto o exterior – um serviço comprometido pode se tornar um trampolim para ataques a outros serviços. A comunicação entre serviços também requer autenticação e criptografia, mesmo que estejam na mesma sala de computadores.

existirpotênciana prática

Certa vez, precisávamos atualizar o sistema automatizado de controle da linha de produção de um cliente. O sistema original tinha uma arquitetura monolítica e as medidas de segurança estavam concentradas na borda. Ao migrar para microsserviços, não nos apressamos em escrever um novo código, mas primeiro desenhamos um “mapa de confiança”.

Cada serviço é um nó e as conexões entre os nós representam relacionamentos de comunicação. Depois fizemos algo divertido: colorimos cada linha. Verde indica alta confiança, amarelo indica confiança limitada e vermelho indica necessidade de revisão rigorosa.

A imagem resultante parecia uma pintura abstrata – principalmente amarela, muito pouco verde e vermelho espalhado aqui e ali. O cliente ficou um pouco nervoso ao ver: “Com tantas restrições o sistema não vai funcionar?”

Eu disse não. É como instalar limitadores e sensores de torque em cada junta de um braço robótico – eles não interferem no movimento normal e só funcionam quando há alguma anormalidade. Três meses depois, o sistema entrou no ar e a equipe de operação e manutenção informou que embora a configuração fosse um pouco complicada, eles conseguiam dormir muito mais tranquilos à noite.

De volta à pergunta original

O que deveria ser a segurança? No projeto mecânico, é o fator de segurança de materiais, estruturas de suporte redundantes e análise do modo de falha. Nos microsserviços, é a consciência da identidade de cada parte do código, os limites claros entre os serviços e a atitude cautelosa padrão.

Não é um complemento, mas parte da filosofia de design. Assim como você não pensa em proteção contra poeira após a instalação do trilho-guia de precisão, você sabe que ele funciona em um ambiente limpo desde o início.

Agora, quando você olha para sua própria arquitetura de microsserviços, pode querer mudar sua perspectiva: as chamadas entre serviços não são apenas transmissão de dados, mas também transferência de confiança. E toda transferência deve ter supervisão e proteção adequadas.

Afinal, bons sistemas não desenvolvem resiliência somente depois que surgem vulnerabilidades. Deve impedir que os ataques comecem antes que as vulnerabilidades apareçam. A diferença entre isso geralmente é a diferença entre a operação estável diária e os reparos de emergência noturnos.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular,potênciaintegra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas. A Kpower forneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.