Segurança OT com MQTT: Protegendo Plantas Industriais ao Enviar Dados para a Nuvem

Segurança OT com MQTT é a prática de tirar dados de uma planta industrial, seja uma fábrica em Joinville ou uma mineradora, sem criar um novo caminho de entrada nela. Este guia aborda os padrões de rede que funcionam, como conexões somente de saída, gateways na DMZ e segmentação, além de higiene de credenciais e monitoramento para dados da planta enviados a um broker na nuvem. Ao final, você terá um projeto de referência e um checklist para discutir com as equipes de OT e de TI.

Por que redes OT exigem uma abordagem diferente

Redes de tecnologia operacional (OT) controlam equipamentos que movimentam, aquecem, misturam e cortam. Elas diferem da TI de escritório de maneiras que moldam cada decisão de segurança:

• A disponibilidade vem primeiro. Um controle de segurança que para a produção costuma ser visto como um risco maior do que a ameaça que ele combate.
• Ciclos de vida longos. CLPs e IHMs ficam em serviço por muitos anos, muitas vezes com firmware que não pode ser atualizado rapidamente.
• Protocolos legados. Modbus, versões antigas de Profinet e muitos protocolos seriais não têm autenticação alguma.
• Consequências físicas. Um comando forjado pode danificar equipamentos ou ferir pessoas, e não apenas vazar dados.

O MQTT é adequado a esse ambiente porque inverte a direção usual do tráfego. Em vez de uma aplicação na nuvem entrar na planta para consultar as máquinas, um gateway dentro da planta envia os dados para fora. Bem feito, isso significa nenhuma regra de firewall de entrada na rede OT.

O princípio central: conexões somente de saída

Todo cliente MQTT abre uma conexão TCP com o broker, nunca o contrário. Um gateway da planta que publica em um broker na nuvem precisa, portanto, de exatamente uma regra de firewall: TCP de saída para o hostname do broker na porta 8883.

Somente de saída não significa livre de riscos. O gateway ainda mantém uma sessão TCP com o mundo externo e, se assinar topics de comando, dados podem fluir de volta para dentro. A pergunta de projeto passa a ser: o que o gateway aceita e como ele valida isso?

Arquitetura de referência

Um projeto em camadas que serve para a maioria das plantas, seguindo de forma aproximada os níveis do modelo Purdue:

1. Nível 0–1: dispositivos de campo e CLPs. Sem rota para a internet. Falam apenas protocolos industriais.
2. Nível 2: rede de supervisão. IHMs e SCADA. Ainda sem rota para a internet.
3. Nível 3/3.5: DMZ industrial. O gateway de borda fica aqui. Ele lê do Nível 2 (por exemplo via OPC UA ou Modbus TCP) através de um firewall que permite apenas esses fluxos específicos.
4. Nível 4–5: corporativo e nuvem. O gateway publica no broker MQTT na nuvem via TLS. Dashboards, analytics e historiadores assinam a partir daqui.

Gateway único ou broker na DMZ?

Duas variantes comuns funcionam bem:

• O gateway publica diretamente no broker na nuvem. A opção mais simples: uma conexão de saída, com store-and-forward no gateway para quedas.
• Um broker local na DMZ faz a ponte com a nuvem. Máquinas ou gateways publicam em um broker na DMZ, e um único cliente de bridge ou relay encaminha os topics selecionados para fora. Isso acrescenta um buffer local e um único ponto para inspecionar e filtrar o tráfego, ao custo de mais um sistema para atualizar e monitorar.

De qualquer forma, o chão de fábrica nunca conversa diretamente com a internet. Para entender como um broker roteia dados, veja o que um broker MQTT faz.

Regras de segmentação que importam

Escreva as regras de firewall de forma que cada uma tenha um motivo que você consiga explicar:

# OT firewall (between Level 2 and DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (OPC UA read)
ALLOW  gateway-01  -> plc-line2:502/tcp    (Modbus TCP read)
DENY   any         -> any                   (default)

# Perimeter firewall (DMZ to internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT over TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (time sync for TLS)
DENY   any         -> any                          (default)
DENY   internet    -> DMZ                          (no inbound)

Tenha estes pontos em mente:

• Prefira hostnames com filtragem de saída em um proxy ou firewall de próxima geração quando os endereços IP do broker puderem mudar.
• Libere apenas a porta 8883. MQTT sem criptografia na 1883 nunca deve sair da planta.
• A hora correta importa: a validação do certificado TLS falha em gateways com o relógio errado.
• Registre em log as conexões negadas vindas do lado OT; tentativas de saída inesperadas são um sinal de alerta precoce.

Higiene de credenciais para gateways

Gateways de planta costumam funcionar sem supervisão por anos, então as credenciais devem ser tratadas com cuidado desde o primeiro dia.

1. Uma identidade por gateway. Se um gateway for comprometido, revogue-o sem mexer nos outros.
2. Identidades separadas para funções separadas. Um publicador de telemetria e um receptor de comandos não devem compartilhar credenciais.
3. Guarde os segredos fora do código-fonte, em um arquivo de configuração protegido ou no repositório de segredos do sistema operacional, legível apenas pela conta de serviço do gateway.
4. Faça a rotação periodicamente e em eventos, como mudanças na equipe ou suspeita de comprometimento. O guia sobre rotação de credenciais MQTT mostra uma abordagem com pouca indisponibilidade.
5. Nunca reutilize credenciais da planta em brokers de teste. Use o servidor MQTT público apenas com client IDs descartáveis e dados fictícios.

Na ConnectMQ, cada broker recebe credenciais geradas, e os client IDs ficam vinculados a essas credenciais, de modo que um client ID vazado, sozinho, não pode ser usado para conectar. Logins com falha repetidos levam ao bloqueio do IP, o que limita a adivinhação de senhas contra as contas dos seus gateways.

Tratando comandos com segurança

Se o caso de negócio exigir setpoints remotos ou mudanças de receita, trate o caminho de comando como um conduíte separado e de maior risco:

• Use topics de comando dedicados e uma identidade de assinante separada.
• Valide cada comando no gateway contra uma lista de permissões: qual tag, qual faixa, quais unidades.
• Exija um topic de resposta ou de confirmação, para que os operadores vejam o que realmente aconteceu. Os response topics do MQTT 5 ajudam aqui.
• Mantenha uma substituição local e garanta que o equipamento falhe de forma segura se o broker estiver inacessível.
• Nunca encaminhe payloads brutos a um CLP.

Muitas plantas decidem que o caminho da nuvem permanece somente leitura e que as escritas acontecem apenas pelas IHMs locais. Essa é uma escolha legítima e comum.

Monitoramento e disponibilidade

Segurança em OT inclui disponibilidade. Planeje para estas situações:

• Queda do broker ou da internet: o gateway armazena dados localmente e os reenvia com backoff quando a conexão volta. A expiração de mensagens impede que dados desatualizados sejam reproduzidos horas depois.
• Falha do gateway: assine $SYS/broker/connection/{clientId}/state na ConnectMQ ou use uma mensagem de last will para que os dashboards mostrem o gateway como offline.
• Tráfego incomum: um gateway que de repente publica dez vezes a sua taxa normal, ou se conecta a partir de um novo endereço IP, merece investigação.
• Limites de cota: o reason code 0x97 do MQTT 5 informa que uma cota do plano foi excedida, para que você distinga isso de problemas de rede.

O dashboard do portal da ConnectMQ, a visualização de dispositivos por nível ISA-95 e as regras de alerta por limite ajudam as equipes de operação a enxergar isso sem construir ferramentas próprias. Os mesmos dados que saem pela conexão de saída podem alimentar um gêmeo digital da planta na nuvem sem abrir nenhum caminho de entrada na rede OT.

Checklist de segurança OT para MQTT

1. Nenhuma regra de firewall de entrada na rede OT para MQTT.
2. O gateway fica em uma DMZ e lê dos CLPs por meio de regras de escopo restrito.
3. Somente TLS na porta 8883 sai do site, com validação do certificado do servidor e hora correta.
4. Uma identidade exclusiva e revogável por gateway e por função.
5. Os caminhos de comando são separados, validados e à prova de falhas, ou simplesmente não existem.
6. Os gateways armazenam dados durante quedas e se reconectam com backoff.
7. O estado de conexão e as taxas de mensagens dos gateways são monitorados.
8. As responsabilidades entre planta, TI e provedor do broker estão documentadas.

Para o lado normativo do mesmo tema, leia IEC 62443 e MQTT. O guia de IoT industrial com MQTT aborda a modelagem de dados, e as melhores práticas de segurança MQTT tratam do fortalecimento geral dos clientes.

Conecte sua planta à ConnectMQ com segurança

Você pode testar este projeto em um único gateway em uma tarde. Crie um broker privado no plano Serverless (Free) em app.connectmq.com (sem cartão de crédito), abra uma regra de saída para a porta 8883 e publique seu primeiro topic ISA-95 via TLS. Quando precisar de isolamento em produção, um broker MQTT gerenciado em uma implantação Dedicated ou BYOC mantém a mesma configuração de cliente.

Perguntas frequentes

O MQTT exige abrir portas de entrada na planta?

Não. Os clientes MQTT se conectam para fora, em direção ao broker, então um gateway da planta só precisa de uma regra de saída para a porta 8883. Os comandos, se houver, voltam pela mesma conexão.

Os CLPs devem se conectar diretamente a um broker na nuvem?

Em geral, não. Manter os CLPs em uma rede isolada e colocar um gateway de borda em uma DMZ limita a exposição e permite controlar exatamente o que sai da planta.

É preciso uma VPN para MQTT da planta para a nuvem?

Normalmente não. MQTT sobre TLS com validação do certificado do servidor e credenciais de cliente fortes oferece um canal criptografado e autenticado sem VPN.

O que acontece com os dados quando a conexão com a internet cai?

Um gateway bem projetado armazena os dados localmente e os reenvia após se reconectar com backoff. A expiração de mensagens pode descartar valores que já não são úteis.