IEC 62443 e MQTT: Protegendo a Mensageria Industrial com Zonas e Conduítes

Projetar MQTT segundo a IEC 62443 significa posicionar um fluxo de dados MQTT dentro do modelo de zonas e conduítes que as equipes de segurança industrial já utilizam. Este guia mapeia os principais conceitos da IEC 62443 em uma arquitetura típica de CLPs, gateways de borda e um broker na nuvem, para que você consiga explicar seu projeto na linguagem que os revisores de segurança OT esperam. É um guia de engenharia, não uma orientação jurídica ou de certificação: a conformidade é avaliada para o seu sistema e a sua organização, e não concedida por um único produto.

Uma breve introdução à IEC 62443

A IEC 62443 é uma série de normas para a segurança de sistemas de automação e controle industrial (IACS). Ela é escrita para vários públicos: proprietários de ativos que operam plantas, integradores de sistemas que constroem soluções e fornecedores de produtos que fabricam componentes. Alguns conceitos são os mais importantes para o projeto de mensageria:

• Zonas: grupos de ativos com requisitos de segurança compartilhados, como uma célula de CLPs ou uma rede de TI corporativa.
• Conduítes: os caminhos de comunicação entre zonas, com seus próprios requisitos de segurança.
• Requisitos fundamentais (FR): sete categorias que estruturam os requisitos técnicos: controle de identificação e autenticação, controle de uso, integridade do sistema, confidencialidade dos dados, fluxo de dados restrito, resposta oportuna a eventos e disponibilidade de recursos.
• Níveis de segurança (SL): metas de SL 1 a SL 4 que descrevem quão capaz é o atacante ao qual a zona ou o conduíte deve resistir, do uso indevido casual a ataques sofisticados e com muitos recursos.
• Avaliação de riscos: o processo (descrito na parte 3-2) que define zonas, conduítes e níveis de segurança alvo.

Várias partes são relevantes para projetos MQTT. A parte 3-3 lista requisitos de segurança de sistema, a parte 4-2 trata de requisitos de componentes e a parte 2-1 aborda o programa de segurança do proprietário do ativo.

Por que o MQTT se encaixa no modelo de zonas e conduítes

O MQTT tem uma propriedade de que os arquitetos de segurança gostam: os clientes sempre se conectam de dentro para fora, em direção ao broker. Um gateway de CLP publica em um broker; nada precisa se conectar de fora para dentro da planta. Isso torna o caminho de comunicação fácil de descrever como um único conduíte com direção, protocolo e porta definidos.

Compare isso com protocolos de polling, em que um sistema central entra na rede da planta para ler valores. Cada polling é um fluxo de entrada que precisa ser liberado nos firewalls. Com MQTT, a planta inicia a conexão e o firewall pode permanecer fechado para entrada.

Mapeando uma arquitetura MQTT em zonas e conduítes

Uma arquitetura MQTT industrial típica tem quatro zonas:

E três conduítes:

1. Conduíte controle-borda: acesso somente leitura via protocolo industrial do gateway aos CLPs.
2. Conduíte borda-broker: MQTT sobre TLS na porta 8883, somente de saída, do gateway ou da DMZ para o broker.
3. Conduíte broker-consumidor: MQTT sobre TLS das aplicações de analytics e dashboards para o broker.

Os níveis de segurança alvo na tabela não são fixos de propósito. Eles vêm da sua avaliação de riscos, e a mesma arquitetura pode ser SL 2 em uma planta em Joinville e SL 3 em uma mineradora em Minas Gerais.

Documente cada conduíte

Para cada conduíte, registre: pontos de extremidade, direção do estabelecimento da conexão, protocolo e porta, método de autenticação, criptografia, topics ou dados permitidos e o que acontece quando ele falha. Os revisores vão pedir exatamente esses detalhes.

Aplicando os requisitos fundamentais ao MQTT

Comandos merecem uma análise própria

Enviar telemetria para fora de uma planta é um nível de risco. Enviar comandos para dentro de uma planta é outro. Muitas organizações mantêm o conduíte da nuvem estritamente somente leitura e tratam as escritas localmente. Se você precisa de setpoints remotos, separe-os: topics diferentes, credenciais diferentes, validação no gateway e limites para os valores que o gateway vai repassar ao CLP. A zona de controle nunca deve executar payloads brutos vindos de um broker.

Onde um broker MQTT gerenciado se encaixa

Nesse modelo, o broker na nuvem é uma zona e o link borda-broker é um conduíte. Um broker MQTT gerenciado não torna seu sistema conforme à IEC 62443, e você deve desconfiar de qualquer fornecedor que dê a entender o contrário. O que ele pode fazer é fornecer controles que você referencia na sua própria avaliação.

A ConnectMQ fornece os seguintes controles, que podem apoiar essa avaliação:

• TLS na porta 8883 e WebSockets seguros na 8084, com certificado Let's Encrypt (FR3, FR4).
• Autenticação com credenciais geradas, com client IDs vinculados a essas credenciais (FR1).
• Isolamento multi-tenant, ou um cluster isolado nos planos Dedicated, ou implantação na sua própria conta de nuvem com BYOC (FR5).
• Cotas por plano com reason code 0x97 do MQTT 5, proteção contra inundação e bloqueio de IP após logins com falha repetidos (FR6, FR7).
• Visibilidade do estado de conexão por meio de $SYS/broker/connection/{clientId}/state, além de dashboards no portal e regras de alerta por limite (FR6).

A ConnectMQ não oferece ACLs por topic, então use brokers ou credenciais separados por zona de confiança quando a separação no nível de topic for necessária e aplique a filtragem de comandos no seu gateway de borda. Registre essas responsabilidades na sua matriz de responsabilidade compartilhada. O guia de broker MQTT na nuvem compara os modelos compartilhado, dedicado e BYOC, o que muitas vezes importa para o projeto das zonas.

Exemplo: gateway de borda publicando na zona do broker

O gateway é onde está a maior parte do trabalho de segurança. Um gateway mínimo em Python que lê valores localmente e publica via TLS pode ser assim:

import json
import time
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"  # obtido no portal da ConnectMQ
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"

def read_plc_values():
    # Substitua pela sua leitura OPC UA ou Modbus; o gateway apenas lê.
    return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()  # verifica o certificado do broker com as CAs do sistema
client.reconnect_delay_set(min_delay=2, max_delay=300)

client.connect(BROKER, 8883, keepalive=60)
client.loop_start()

while True:
    payload = read_plc_values()
    payload["ts"] = int(time.time())
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(10)

Repare no que está ausente: nenhuma porta de entrada no gateway, nenhuma assinatura de topics de comando, nenhuma credencial compartilhada com outros gateways. O topic segue uma hierarquia no estilo ISA-95, o que também torna as fronteiras das zonas visíveis no modelo de dados. O guia de IoT industrial com MQTT explica essa estrutura com mais profundidade.

Checklist de revisão para um projeto MQTT segundo a IEC 62443

1. Uma avaliação de riscos define zonas, conduítes e níveis de segurança alvo para os fluxos MQTT.
2. Toda conexão MQTT que cruza uma fronteira de zona usa TLS e verifica o certificado do servidor.
3. Todas as conexões são iniciadas do lado da planta para fora; nenhuma porta de entrada na zona de controle.
4. Cada gateway e cada aplicação têm credenciais exclusivas e revogáveis.
5. Os caminhos de comando são separados da telemetria e validados no gateway.
6. Os gateways armazenam dados em buffer quando o conduíte cai e se recuperam sem causar inundação.
7. Estado de conexão, logins com falha e taxas anormais são monitorados, com uma resposta definida.
8. As responsabilidades compartilhadas com o provedor do broker estão documentadas.

Para o lado de rede deste checklist, leia segurança MQTT para redes OT e, para o lado de identidade, o artigo sobre zero trust para mensageria IoT.

Construa seu conduíte de dados industriais na ConnectMQ

Você pode prototipar o conduíte borda-broker hoje mesmo. Crie um broker privado no plano Serverless (Free) em app.connectmq.com (sem cartão de crédito), conecte um gateway via TLS e veja os topics ISA-95 aparecerem na visualização de dispositivos do portal. Quando o projeto exigir isolamento, um broker MQTT gerenciado em uma implantação Dedicated ou BYOC mantém a mesma configuração de cliente. Para um teste rápido sem credenciais, o servidor MQTT público também funciona, mas apenas com dados fictícios, nunca com dados reais da planta. As melhores práticas de segurança MQTT se aplicam em todas as etapas.

Perguntas frequentes

O MQTT é permitido pela IEC 62443?

A IEC 62443 não proíbe nem prescreve protocolos específicos. Ela exige que a comunicação entre zonas atenda aos requisitos de segurança do seu conduíte, algo que MQTT sobre TLS com autenticação forte pode atender.

Um broker MQTT na nuvem pode ser certificado IEC 62443 para a minha planta?

A certificação se aplica a produtos, processos ou sistemas específicos em relação a partes específicas da norma. A conformidade do seu sistema como um todo é avaliada para a sua planta; um provedor de broker só pode fornecer controles que você referencia nessa avaliação.

Os comandos devem fluir da nuvem para dentro da planta?

Somente se a avaliação de riscos permitir. Muitos sites mantêm o conduíte da nuvem somente leitura, e os que permitem comandos os separam, validam no gateway e limitam o que pode ser alterado.

Preciso de um broker local na DMZ?

Nem sempre. Um broker na DMZ acrescenta buffer e um ponto de inspeção, enquanto um gateway publicando diretamente em um broker na nuvem via TLS é mais simples. A avaliação de riscos e o nível de segurança alvo decidem.