Protocolos e Arquitetura · 6 min de leitura
Padronizar arquitetura entre plantas é uma boa decisão de engenharia. Ela reduz custo, acelera projetos e facilita a manutenção. O que quase ninguém coloca na conta é que, quando o desenho carrega um defeito, a padronização replica o defeito com a mesma eficiência com que replica a qualidade.
O alerta do FBI e da EPA sobre MicroLogix
Em 30 de julho de 2026, FBI e EPA publicaram um comunicado conjunto sobre ataques a controladores Allen-Bradley MicroLogix 1100 e 1400. Utilities de saneamento em pelo menos sete estados dos Estados Unidos reportaram incidentes desde 27 de julho. Os efeitos descritos foram perda de pressão e alagamento.
O ponto técnico mais importante é o que não aconteceu: não houve exploração de vulnerabilidade. Os atacantes alcançaram dispositivos expostos e trocaram IP e senha. Uma das organizações percebeu o problema porque o arquivo de projeto tinha sido alterado, e a divergência de ladder entre plantas denunciou a mudança.
Passei uma década na Rockwell e conheço bem esses controladores. MicroLogix 1100 e 1400 são produtos em fim de linha. Um ativo em fim de linha exposto à internet não é falha de firewall, é falha de inventário: ninguém sabia que ele estava lá, ou ninguém sabia que ele estava alcançável.
O parágrafo que quase ninguém citou
O comunicado tem um parágrafo pouco comentado. Ele diz que semelhanças na arquitetura fornecida por terceiros permitiram aos atacantes multiplicar o sucesso entre clientes. Mesmo desenho, mesmo vetor, aplicado em série.
Isso muda a leitura do incidente. O problema não foi um cliente descuidado. Foi uma decisão de arquitetura tomada uma vez e entregue muitas vezes, que transformou uma fraqueza local em uma fraqueza de frota. O atacante não precisou estudar cada rede; bastou estudar uma.
Para o dono do ativo, a consequência é desconfortável. Se o seu sistema foi entregue pelo mesmo fornecedor e com o mesmo desenho de um sistema atacado, a pergunta não é se você é alvo, mas se o mesmo caminho existe na sua rede. Responder isso exige saber o que está conectado, com qual configuração e alcançável de onde.
O mesmo padrão, sem atacante: um caso brasileiro
O mesmo mecanismo aparece em confiabilidade, sem nenhum atacante envolvido. Fomos chamados para uma falha intermitente numa linha que estava havia meses sem conclusão. Na auditoria, três achados explicavam o comportamento.
A intermitência vinha sendo tratada como problema de equipamento. Peças tinham sido trocadas, parâmetros revisados, e a falha voltava. Nenhum dos chamados abertos até ali apontava para a rede, porque a rede estava de pé sempre que alguém ia conferir.
Depois disso, auditamos outra planta do mesmo grupo. Mesmo integrador, mesmo ano de projeto, mesmo desenho. Os três achados estavam lá, na mesma configuração. A diferença é que essa segunda planta nunca tinha reclamado de nada.
- Anel que não era anel: as duas pernas fechavam no mesmo switch, anulando a redundância.
- Prioridade RSTP em valor default, elegendo como raiz um switch de painel de campo.
- Dois enlaces de fibra com perda acima do budget óptico.
Por que cada achado passa despercebido
O anel com as duas pernas no mesmo switch funciona normalmente enquanto aquele switch está bem. A redundância existe no desenho, mas não existe na rede física. O dia em que o switch falha, as duas pernas caem juntas e o segmento inteiro fica isolado.
No RSTP, a ponte raiz é eleita pela menor prioridade configurada e, em caso de empate, pelo menor endereço MAC. Quando ninguém ajusta a prioridade, todos os switches ficam no valor default e a eleição é decidida pelo MAC, o que pode colocar um switch de painel de campo no centro da árvore. Qualquer instabilidade nesse switch passa a provocar recálculo da topologia inteira.
Enlace de fibra com perda acima do budget costuma estabelecer link e passar tráfego. Ele opera sem margem e passa a gerar erros quando as condições pioram. Nenhum desses três defeitos impede a rede de funcionar no comissionamento, e é por isso que eles sobrevivem ao aceite.
O ponto em comum é que os três defeitos só aparecem quando alguém mede. A topologia real precisa ser descoberta no campo, a configuração de cada switch precisa ser lida e a perda de cada fibra precisa ser medida com instrumento. Olhar o diagrama, nesse caso, é olhar para o que deveria existir.
Não é culpa do integrador
O integrador entregou segundo a prática de mercado. O projeto foi aprovado, a rede foi comissionada e funcionou. Nenhum desses achados aparece em teste funcional, e a maior parte dos escopos de entrega não pede mais do que isso.
Também não é culpa de quem aprovou. O comissionamento verificou o que costuma ser verificado: comunicação estabelecida, equipamentos respondendo, linha produzindo. A verificação de que as pernas do anel terminam em switches diferentes, de qual switch é a raiz e de qual é a perda real de cada fibra raramente está no roteiro de aceite.
O ponto é outro: uma decisão de arquitetura tomada uma vez se replica em silêncio. Quem compara a rede real com o desenho é a medição independente, feita com instrumento e com a topologia descoberta no campo, e não lida no diagrama. Se o grupo padronizou o projeto, qualidade e defeito se replicam juntos.
O que muda para a gestão de um grupo com várias plantas
Para grupos industriais com várias unidades, a padronização cria uma oportunidade que quase nunca é aproveitada. Um achado em uma planta é uma hipótese forte para todas as outras que seguiram o mesmo desenho. Auditar uma unidade com profundidade e verificar o mesmo padrão nas demais custa muito menos do que esperar cada uma reclamar.
O mesmo raciocínio vale para segurança. Inventário de ativos, incluindo os que estão em fim de linha, e mapa real de quais dispositivos são alcançáveis de onde, são a base para qualquer decisão sobre exposição. Sem isso, a primeira notícia sobre o próprio parque pode vir de um comunicado do FBI.
A pergunta prática para o comitê técnico do grupo é direta. Quando foi a última vez que alguém comparou, com medição, a rede real de cada planta com o desenho padrão que todas deveriam seguir?
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.