Uma DMZ MQTT é a zona de rede por onde os dados da planta saem da rede de tecnologia operacional (OT) a caminho dos sistemas corporativos e da nuvem, sem permitir que nada de fora volte para dentro. Neste guia você vai entender por que o MQTT se encaixa tão bem em uma DMZ, os três padrões de posicionamento que funcionam na prática, as regras de firewall exatas a solicitar e uma configuração de bridge funcional que encaminha dados OT para um broker na nuvem via TLS.
Por Que o MQTT Combina com uma DMZ Industrial
A maioria das arquiteturas de segurança industrial segue alguma variante do modelo Purdue ou das zonas e condutos da IEC 62443. Os níveis 0 a 2 abrigam sensores, CLPs e IHMs, o nível 3 abriga as operações do site, como SCADA e historiadores, e entre o nível 3 e a rede corporativa (nível 4 em diante) fica uma DMZ industrial, muitas vezes chamada de nível 3.5. A regra da DMZ é simples: nenhum tráfego a atravessa diretamente. Todo fluxo termina na DMZ, e um novo fluxo começa a partir dela.
Os protocolos clássicos de integração têm dificuldade com essa regra. Protocolos de polling como OPC DA, Modbus TCP ou a interface de consulta de um historiador esperam que o consumidor abra uma conexão com o produtor. Isso significa uma conexão de entrada na rede OT, exatamente o que a equipe de segurança quer evitar.
O MQTT inverte a direção. Todo participante é um cliente que se conecta para fora, a um broker. Um gateway no lado OT abre uma conexão TCP de saída, autentica-se e publica. Os consumidores na TI ou na nuvem também se conectam para fora, ao broker, e assinam. Ninguém precisa abrir uma porta de escuta no chão de fábrica, seja em uma mineradora em Minas Gerais ou em uma usina de açúcar e etanol no interior paulista. Os mesmos dados que saem pela DMZ costumam alimentar historiadores, dashboards e um gêmeo digital na nuvem. Depois que você entende o que um broker MQTT faz como ponto de encontro dessas conexões de saída, fica muito mais fácil raciocinar sobre o projeto da DMZ.
Três Padrões de Posicionamento para DMZ MQTT
Não existe um único projeto correto. O padrão certo depende do rigor da sua política de zonas e de quantos sites você tem.
| Padrão | Onde fica o broker | Fluxo a partir da OT | Ideal para |
|---|---|---|---|
| A. Saída direta | Somente na nuvem | O gateway OT se conecta para fora, através do firewall, ao broker na nuvem | Sites pequenos, pilotos, sites sem DMZ formal |
| B. Broker bridge na DMZ | Broker local na DMZ, em bridge com a nuvem | O gateway OT se conecta ao broker da DMZ; o broker da DMZ se conecta para fora, à nuvem | Sites com a regra rígida de "nenhum fluxo atravessa a DMZ" |
| C. Gateway na DMZ | Software de gateway na DMZ, broker na nuvem | Um gateway na DMZ lê o gateway OT ou o servidor OPC UA e publica na nuvem | Plantas que não podem instalar nada nos níveis 2 ou 3 |
Padrão A: só saída, direto para um broker na nuvem
O gateway fica no nível 3 e abre uma conexão TLS na porta 8883 diretamente com um broker MQTT na nuvem. O firewall permite um único destino de saída e uma única porta. O tráfego de retorno flui apenas nessa sessão já estabelecida. Esse padrão é rápido de implantar e perfeitamente aceitável para muitas plantas, mas tecnicamente deixa uma sessão atravessar a DMZ, o que algumas políticas proíbem.
Padrão B: um broker bridge na DMZ
Um broker pequeno, como o Mosquitto, roda em um host endurecido na DMZ. Os gateways OT se conectam a ele por baixo, e o broker da DMZ abre sua própria conexão bridge de saída para a nuvem. Duas sessões separadas, dois conjuntos de credenciais separados, e o host da DMZ é a única máquina que conversa com a internet. Se o link com a nuvem cair, o bridge enfileira as mensagens QoS 1 localmente, o que combina naturalmente com store-and-forward MQTT nos gateways.
Padrão C: um gateway de protocolo na DMZ
Às vezes não é possível instalar nada novo dentro da zona OT. Nesse caso, um gateway na DMZ lê uma interface existente, por exemplo um servidor OPC UA exposto à DMZ por uma regra estreita, e publica MQTT para cima. É o padrão menos elegante, porque agora a DMZ inicia uma conexão para dentro da OT, mas ainda mantém a nuvem completamente isolada da planta. O nosso guia de gateway de borda IIoT explica como escolher esse gateway.
Regras de Firewall para uma DMZ MQTT
Seja qual for o padrão escolhido, escreva as regras antes do pedido de mudança. Equipes de firewall aprovam regras precisas mais rápido do que regras vagas.
| Regra | Origem | Destino | Porta | Direção |
|---|---|---|---|---|
| 1 | Gateway OT (nível 3) | Broker da DMZ | TCP 8883 (ou 1883 dentro de um segmento confiável) | OT para DMZ |
| 2 | Broker da DMZ | Hostname do broker na nuvem | TCP 8883 | DMZ para internet |
| 3 | Consumidores de TI | Hostname do broker na nuvem | TCP 8883 ou 8084 (WSS) | Corporativo para internet |
| 4 | Qualquer | Zona OT | Qualquer | Negar |
| 5 | Internet | Broker da DMZ | Qualquer | Negar |
Algumas observações práticas:
- Use o hostname do broker, não um endereço IP, na regra de saída, ou um objeto FQDN se o seu firewall suportar. IPs de nuvem podem mudar.
- Permita a resolução DNS para o host da DMZ, seja para um resolvedor interno, seja para um servidor upstream específico.
- Mantenha a porta 1883 em texto puro totalmente fora da internet. Use 8883 com TLS para tudo o que sai do site.
- Se houver um proxy com inspeção TLS no caminho, exclua o hostname do broker. A inspeção quebra a validação de certificados e as sessões MQTT de longa duração.
- Timeouts de ociosidade longos importam. Alguns firewalls derrubam sessões TCP ociosas após poucos minutos, então configure o keepalive do MQTT abaixo do timeout de ociosidade do firewall, por exemplo 60 segundos.
Exemplo: um Bridge Mosquitto da DMZ para um Broker na Nuvem
A configuração a seguir implementa o Padrão B. O broker da DMZ escuta apenas na interface voltada para a OT e faz bridge de topics selecionados para um broker ConnectMQ via TLS. Substitua as credenciais pelo nome de usuário, senha e client ID gerados no portal.
# /etc/mosquitto/conf.d/dmz.conf
# Escuta apenas na interface voltada para a zona OT
listener 8883 10.20.0.5
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/dmz-broker.crt
keyfile /etc/mosquitto/certs/dmz-broker.key
allow_anonymous false
password_file /etc/mosquitto/passwd
# Bridge de saída para o broker na nuvem
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
try_private false
keepalive_interval 60
restart_timeout 10 120
# Encaminha apenas telemetria da planta, somente para cima
topic factory1/# out 1 "" connectmq/
A linha topic é onde a política da DMZ é aplicada em software: out significa que as mensagens só fluem do broker da DMZ para a nuvem, nunca de volta para baixo. Um topic local factory1/line1/cnc1/telemetry chega à nuvem como connectmq/factory1/line1/cnc1/telemetry. Use try_private false porque o lado remoto não é outra instância do Mosquitto, e mantenha bridge_insecure false para que o certificado Let's Encrypt do endpoint na nuvem seja validado contra o repositório de CAs do sistema.
Teste o caminho a partir do host da DMZ antes de envolver qualquer dado de CLP:
# No host da DMZ: publica uma mensagem de teste local
mosquitto_pub -h 10.20.0.5 -p 8883 --cafile /etc/mosquitto/certs/ca.crt \
-u gateway01 -P 'local-secret' -i dmz-test-01 \
-t factory1/test/hello -m '{"status":"ok"}' -q 1
# De qualquer máquina com acesso ao broker na nuvem: confirma que chegou
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-reader \
-t 'connectmq/factory1/#' -v
Observe que a ConnectMQ vincula os client IDs às credenciais emitidas, então o segundo cliente precisa de um conjunto de credenciais próprio, obtido no portal, em vez de um ID inventado. Para experimentos antes de ter credenciais, você pode apontar o bridge para o servidor MQTT público (gratuito) na porta 1883 com um prefixo único como connectmq/demo/<random-id>/, mas nunca envie dados reais da planta para uma área pública.
Comandos Devem Descer Algum Dia?
A telemetria subindo é a parte fácil. A pergunta mais difícil é se algo deve voltar para baixo: mudanças de setpoint, download de receitas, reconhecimentos. Um bom padrão para uma primeira implantação é não. Mantenha o bridge apenas out e deixe os operadores alterarem setpoints pela IHM ou pelo SCADA existentes.
Se você realmente precisar de downlink, projete-o explicitamente:
- Faça bridge
inde um único topic de comando estreito, por exemploconnectmq/factory1/line1/cmd/+, nunca de um curinga sobre a árvore inteira. - Deixe um gateway no nível 3 validar cada comando contra uma lista de tags e faixas de valores permitidas antes de escrever no CLP.
- Exija um response topic e correlation data (um recurso do MQTT 5), para que todo comando gere um reconhecimento registrado.
- Mantenha o CLP no comando dos intertravamentos de segurança. Um comando da nuvem deve solicitar uma mudança, não contornar a lógica.
Erros Comuns em DMZ MQTT
Rodar o broker da DMZ com acesso anônimo. A DMZ continua sendo uma zona compartilhada. Exija nomes de usuário e senhas e, de preferência, certificados de cliente no listener voltado para a OT.
Fazer bridge de # nas duas direções. É o jeito mais rápido de transformar uma DMZ cuidadosamente projetada em uma rede plana na camada de aplicação. Faça bridge apenas das subárvores necessárias, e apenas na direção necessária.
Esquecer a sessão. Com cleansession false, o lado da nuvem mantém as assinaturas do bridge e as mensagens QoS 1 enfileiradas durante quedas curtas. Com uma sessão limpa, tudo o que for publicado durante a janela de reconexão pode se perder.
Ignorar os limites do broker. Uma rajada de dados históricos após uma queda pode ultrapassar as cotas por cliente. Limite a taxa do reenvio no gateway e leia os reason codes que o broker retorna.
Onde Entra um Broker MQTT Gerenciado
Tanto no Padrão A quanto no Padrão B, o endpoint na nuvem é um componente que, de outra forma, você teria de construir, expor, atualizar e monitorar por conta própria. Usar um broker MQTT gerenciado tira essa superfície exposta à internet do seu data center. A ConnectMQ oferece TLS na 8883, isolamento multi-tenant, proteção contra flood e bloqueio de IP após falhas repetidas de login, então a única coisa de que a sua DMZ precisa é uma regra de saída. Para organizações que querem o broker dentro da própria conta de nuvem, há também uma opção BYOC gerenciada em seu nome.
Para o panorama de como a DMZ se encaixa com gateways, Sparkplug B e um Unified Namespace, veja o nosso guia completo de IoT industrial com MQTT. Se os seus sites se conectam por redes móveis em vez de um firewall de planta, leia também sobre MQTT sobre rede celular.
Comece a Usar a ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Em minutos você recebe nome de usuário, senha e client ID gerados, que é tudo o que precisa para apontar um bridge da DMZ para a nuvem e ver os topics da sua planta chegarem ao explorador de topics ao vivo. Quando superar o nível gratuito, os planos Serverless pago, Dedicated e BYOC permitem crescer sem redesenhar a DMZ.
Perguntas frequentes
O MQTT exige portas de entrada no firewall da rede OT?
Não. Todo participante MQTT é um cliente que se conecta para fora, a um broker, então a rede OT só precisa de uma regra de saída para o broker da DMZ ou o broker na nuvem. Nada na internet inicia uma conexão para dentro da planta.
Devo usar a porta 1883 ou a 8883 em uma DMZ MQTT?
Use a 8883 com TLS em toda conexão que sai do site ou cruza uma fronteira de zona. A 1883 em texto puro só é aceitável dentro de um único segmento confiável, e mesmo ali o TLS é recomendado.
Preciso de um broker dentro da DMZ?
Nem sempre. Uma conexão de saída direta de um gateway no nível 3 para um broker na nuvem costuma ser aceitável. Um broker bridge na DMZ é a melhor escolha quando a sua política proíbe que qualquer sessão atravesse a DMZ ou quando você quer buffer local.
Aplicações na nuvem podem enviar comandos de volta aos CLPs através da DMZ?
Podem, mas apenas por um topic de comando estreito, com bridge explícito, e um gateway que valide cada comando antes de escrever no CLP. Muitas plantas começam com telemetria apenas para cima e adicionam o downlink depois.
