Quando a segurança não for mais uma questão de múltipla escolha: reflexões práticas sobre sistema único e microsserviços

Você ainda se lembra do vago desconforto que sentiu quando o sistema foi atualizado da última vez? Às três da manhã, o café estava meio frio e o registro que rolava na tela saltou do nada. Toda a equipe olhou para a mesma enorme base de código, como se estivesse procurando uma agulha em uma floresta escura. Esta é a experiência diária de muitas equipes quando se deparam com uma única arquitetura de sistema - a segurança é como uma enorme rede, mover-se em um local afeta todo o corpo.

Agora imagine outro cenário: uma manhã, você descobre que o módulo de pagamento está com acesso anormal. Não há necessidade de desligar toda a plataforma de comércio eletrônico, apenas isolar rapidamente aquela pequena unidade de serviço. A arquitetura de microsserviços nos dá a possibilidade dessa “cirurgia de precisão”. Mas isso realmente significa que é mais seguro? Ou apenas muda o problema de segurança?

Dilema da segurança: o fardo da integração e o desafio da fragmentação

O sistema único é como um antigo castelo com paredes grossas e portões rígidos. Os benefícios são óbvios: fronteiras claras e defesa centralizada. Todos os fluxos de dados ocorrem em canais internos e os pontos de monitoramento podem ser configurados em menos locais, porém mais precisos. Mas perigos ocultos também estão escondidos no mesmo lugar - assim que alguém passar pelo portão, todo o castelo ficará exposto. O que é ainda mais problemático é que à medida que o negócio se expande, o castelo continua a acrescentar andares e os corredores são tão complicados que até os próprios guardas podem se perder.

E quanto aos microsserviços? É mais como uma casa em um bairro moderno. Cada casa é trancada individualmente e possui seu próprio sistema de segurança. Um incêndio num edifício não se espalhará imediatamente para a porta seguinte. Parece ideal, certo? Mas as comunidades precisam de estradas públicas, condutas partilhadas e patrulhas uniformes nas propriedades. Esses pontos de conexão – gateways de API, malhas de serviço, filas de mensagens – tornam-se novas superfícies de ataque. Agora você tem que proteger não uma parede, mas dezenas de entradas e passagens invisíveis entre elas.

Certa vez, alguém nos perguntou: “Qual arquitetura é mais segura?” Esta pergunta é como perguntar “O que é mais perigoso, uma faca ou uma arma” – depende de quem a está usando e como.potênciaVimos dois extremos em projetos na área de servocontrole: algumas fábricas colocaram todo o sistema de controle da linha de produção em um único aplicativo e, como resultado, uma vulnerabilidade em um determinado protocolo de sensor desligou toda a linha por três dias; também há clientes que dividem excessivamente os microsserviços, e a lógica de autenticação está espalhada em mais de uma dezena de serviços, e mesmo eles não conseguem descobrir a cadeia de permissão.

Rompendo a névoa conceitual: a segurança não é um acessório da arquitetura

Conversamos com diversas equipes técnicas e descobrimos um fenômeno interessante: na hora de escolher uma arquitetura, a segurança é frequentemente discutida. Todos competem primeiro por desempenho, velocidade de desenvolvimento e custos de operação e manutenção. Depois de finalizada a estrutura, eles se viram e perguntam: “A propósito, como melhorar a segurança?” É como considerar materiais à prova de fogo após a construção da casa.

A segurança do mundo real precisa ser integrada antecipadamente no DNA arquitetônico. existirpotênciaNos projetos de atualização de automação mecânica dos quais participamos, descobrimos que esses casos de sucesso tinham uma coisa em comum: independentemente da arquitetura escolhida, a equipe havia traçado um “mapa de segurança” antecipadamente. Para um único sistema, este mapa marca os principais nós do fluxo de dados e os limites da defesa em camadas; para microsserviços, o mapa torna-se uma topologia de rede, com a relação de confiança de cada nó de serviço claramente marcada em vermelho.

Como fazer isso especificamente? Aqui está um ponto de partida simples: se o seu sistema fosse atacado amanhã, com o que você estaria mais preocupado? Em um único sistema, a resposta geralmente é o conjunto de conexões de banco de dados e o módulo de autenticação; em microsserviços, a questão se volta para a configuração do mecanismo de descoberta de serviço e do gateway de API. Onde há preocupação é onde o reforço deve ser feito.

A arte do equilíbrio na prática:potêncianotas de observação

No ano passado, auxiliamos na migração da arquitetura de um projeto de robô de armazém. Seu programa de controle monolítico original estava em execução há sete anos e o código era como uma videira desamarrada. A equipe quer dividi-lo em microsserviços, mas teme perder o controle da segurança. Fizemos um experimento: separamos primeiro o módulo de análise de log.

O resultado? Novos problemas surgiram nos primeiros dois meses – a gestão de certificados para comunicação entre serviços foi mais complexa do que o esperado e as ferramentas de monitorização necessitaram de ser readaptadas. Mas a partir do terceiro mês, as vantagens surgiram: quando o Core Motion Control precisou de um patch de emergência, eles atualizaram apenas esse serviço, reduzindo o escopo dos testes em 60% e encurtando a janela de vulnerabilidade de dois dias para quatro horas.

Por outro lado, também vimos o caso oposto. Um cliente ouviu falar tanto sobre os benefícios dos microsserviços que dividiu o sistema compacto original de monitoramento de máquinas-ferramenta em mais de 20 serviços. A complexidade da implantação aumenta, as políticas de segurança entram em conflito entre si e o desempenho diminui. Eles tiveram que recombinar sete serviços fortemente acoplados em “pequenos monólitos”. É como transformar uma boa faca em migalhas.

Escrito em: Esqueça os debates, concentre-se nas questões

No trabalho diário da Kpower, preferimos ajudar os clientes a desenhar dois mapas: um é o mapa real da superfície de ataque da arquitetura atual e o outro é o plano de expansão dos negócios três anos depois. Quando as duas imagens são empilhadas, muitas vezes fica evidente qual arquitetura pode equilibrar melhor segurança e desenvolvimento.

Em última análise, não existe uma arquitetura perfeita, apenas uma estratégia de segurança em constante adaptação. Esteja você no muro alto e sólido de um único sistema ou andando na comunidade interconectada de microsserviços, lembre-se de perguntar uma vez por semana: se um invasor estiver estudando meu sistema no momento, por onde ele provavelmente começará? A resposta indicará a direção do reforço.

Afinal, uma boa defesa não consiste em escolher a arquitetura mais moderna, mas em fazer com que cada costura da arquitetura escolhida resista ao teste das três da tarde. Quando o alarme dispara, você deseja estar em um sistema que responda rapidamente e isole com precisão – seja qual for o nome.

Fundada em 2005, a Kpower tem se dedicado a ser 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, a Kpower integra 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.