Modelo Purdue vs ISA-95 é um dos pontos de confusão mais comuns em arquitetura industrial, porque ambos usam níveis numerados de 0 a 4 e ambos são desenhados como camadas empilhadas. Nesta comparação você vai entender para que cada modelo foi criado, como seus níveis se correspondem, onde realmente diferem e como o MQTT e um Unified Namespace mudam a forma como os dados circulam entre os níveis sem descartar o zoneamento de segurança que as redes no estilo Purdue oferecem.
De onde vem cada modelo
A Purdue Enterprise Reference Architecture foi desenvolvida na Universidade Purdue no início dos anos 1990 como um modelo geral de manufatura integrada por computador. No mundo da segurança industrial, ela virou sinônimo de arquitetura de rede em camadas: o processo físico na base, a TI corporativa no topo e fronteiras controladas entre eles. É amplamente usada como referência em programas de segurança de TO e influenciou a abordagem de zonas e conduítes da ISA/IEC 62443.
A ISA-95, também publicada como IEC 62264, é uma norma de integração. Seu objetivo é definir como sistemas de negócio, como o ERP, e sistemas de operações de manufatura, como o MES, trocam informações: programações de produção, consumo de materiais, capacidade dos equipamentos, resultados de qualidade. Ela fornece modelos de objetos, modelos de atividades e uma hierarquia funcional, além de definir a hierarquia de equipamentos baseada em papéis: empresa, site, área, centro de trabalho e unidade de trabalho.
Em resumo: o Purdue é usado principalmente para responder "como as redes devem ser segmentadas?", enquanto a ISA-95 responde "quais funções existem em cada nível e que informações circulam entre negócios e operações?".
Como os níveis se alinham
A numeração dos níveis coincide o suficiente para ser útil e de forma solta o suficiente para gerar discussões.
| Nível | Modelo Purdue (visão de rede) | Hierarquia funcional ISA-95 | Sistemas típicos |
|---|---|---|---|
| 5 | Rede corporativa | Não definido separadamente | TI corporativa, serviços expostos à internet |
| 4 | Logística de negócios | Planejamento de negócios e logística | ERP, planejamento, e-mail |
| 3.5 | DMZ industrial | Não definido | Jump hosts, servidores de patches, brokers de dados |
| 3 | Operações do site | Gestão das operações de manufatura | MES, historiador, servidores SCADA do site |
| 2 | Controle supervisório da área | Monitoramento e controle supervisório | IHM, clientes SCADA, estações de engenharia |
| 1 | Controle básico | Sensoriamento e atuação | CLPs, controladores DCS, RTUs |
| 0 | Processo físico | O processo físico | Sensores, atuadores, inversores |
Três diferenças se destacam:
- O Nível 3.5 é um conceito do Purdue. A ISA-95 não tem DMZ porque não modela redes. Profissionais de segurança acrescentaram a DMZ industrial entre as redes de operações do site e corporativas para impedir tráfego direto entre TI e TO.
- O Nível 5 aparece em muitos diagramas Purdue como uma camada separada de empresa ou internet. A ISA-95 para no Nível 4.
- A principal contribuição da ISA-95 é a interface entre o Nível 3 e o Nível 4, que os diagramas Purdue tratam como uma única fronteira de firewall.
Modelo Purdue vs ISA-95: principais diferenças
| Aspecto | Modelo Purdue | ISA-95 |
|---|---|---|
| Tipo | Arquitetura de referência | Norma internacional (IEC 62264) |
| Foco principal hoje | Segmentação de rede e segurança | Integração de sistemas e modelos de informação |
| Define modelos de dados | Não | Sim, para produção, qualidade, manutenção, estoque |
| Define hierarquia de equipamentos | Não | Sim, da empresa à unidade de trabalho |
| Define uma DMZ | Sim, normalmente como Nível 3.5 | Não |
| Público típico | Segurança de TO, engenheiros de rede | Arquitetos de MES, integradores, operações |
| Relevância para o projeto de topics MQTT | Indireta, pelo local onde os brokers ficam | Direta, pela hierarquia de equipamentos |
A consequência prática: ao projetar topics MQTT, use a hierarquia de equipamentos ISA-95, explicada no nosso guia da hierarquia de equipamentos ISA-95. Ao decidir onde o broker roda e quais conexões os firewalls permitem, pense em zonas Purdue.
Como o MQTT achata a comunicação entre os níveis
Em uma planta clássica no estilo Purdue, seja uma usina, uma mineradora ou uma fábrica em Campinas, os dados sobem os níveis um salto por vez. Um CLP é lido pelo SCADA no Nível 2, o SCADA alimenta o historiador no Nível 3, o historiador é replicado através da DMZ e o ERP acaba vendo um resumo. Cada salto é uma integração ponto a ponto com seu próprio protocolo, mapeamento e modos de falha.
Uma arquitetura de publicação e assinatura muda o fluxo de dados. Com um broker MQTT como Unified Namespace, qualquer produtor autorizado publica uma vez e qualquer consumidor autorizado assina diretamente. O MES, o historiador, um dashboard, um gêmeo digital e um job de analytics na nuvem leem todos a mesma telemetria da envasadora no mesmo topic. É isso que se quer dizer quando se fala que o MQTT "achata a pirâmide".
É importante ser preciso sobre o que é achatado. A arquitetura de informação fica plana: há um único namespace em vez de uma cadeia de cópias. A arquitetura de rede não precisa ficar: zonas, firewalls e a DMZ continuam existindo. O MQTT ajuda aqui, porque os clientes sempre abrem conexões de saída para o broker. Um gateway no Nível 2 pode publicar em um broker na DMZ ou na nuvem sem que nenhuma porta de entrada seja aberta na rede de controle.
Onde posicionar o broker
| Posicionamento | Como funciona | Considerações |
|---|---|---|
| Broker do site no Nível 3 | Os gateways publicam dentro do site; uma bridge ou consumidor encaminha para cima | Os dados ficam locais; você opera o servidor |
| Broker na DMZ, Nível 3.5 | Clientes de TO se conectam de saída à DMZ; clientes de TI se conectam de cima | Fronteira clara; nenhum lado se conecta à zona do outro |
| Broker na nuvem | Gateways de borda se conectam de saída via TLS a um broker MQTT gerenciado | Nenhum servidor para operar; exige saída para a internet a partir de uma zona controlada |
| Híbrido | Broker do site para consumidores locais, broker na nuvem para a empresa e entre sites | Mais componentes, melhor resiliência e alcance |
Nosso artigo sobre MQTT na DMZ aborda o projeto da DMZ em profundidade, incluindo regras de firewall. Se você escolher um broker MQTT na nuvem, um broker MQTT gerenciado como o ConnectMQ cuida do lado do servidor, e seu firewall só precisa permitir TLS de saída a partir da zona do gateway.
Testando um caminho de saída a partir de uma zona de TO
Antes de definir um posicionamento, verifique se um gateway na zona pretendida alcança o broker na porta correta e se o TLS é validado. Estes comandos podem ser executados com segurança a partir de um gateway Linux ou jump host; eles usam o servidor MQTT público, então não publique nada sensível:
# 1. O TLS de saída na 8883 é permitido e o certificado é validado?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. Publica uma mensagem de teste retida via TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Lê a mensagem de volta a partir de outra zona
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
Uma linha Verify return code: 0 (ok) confirma que a cadeia de certificados é confiável. Se o passo 1 travar, um firewall está bloqueando a 8883; se WebSockets forem a única opção, a porta 8084 com o caminho /mqtt é uma alternativa. O servidor MQTT público (gratuito) serve para essa verificação de conectividade e para testes; o tráfego de produção deve ficar em um broker privado com credenciais.
A segurança continua importando
Um namespace plano deixa os dados fáceis de alcançar, então autenticação e privilégio mínimo importam mais, não menos:
- Somente saída. Os gateways se conectam de saída ao broker; nunca abra portas de entrada nos Níveis 0 a 2.
- TLS em todo lugar. Porta 8883 para MQTT sobre TLS, 8084 para WebSockets seguros.
- Uma identidade por cliente. Emita credenciais por gateway e aplicação, para que cada uma possa ser revogada de forma independente. No ConnectMQ, os client IDs ficam vinculados às credenciais emitidas.
- Caminhos separados de leitura e escrita para controle. Trate topics de comando como de alto risco e mantenha o controle em malha fechada na rede de controle local.
- Monitore as conexões. Fique atento a clientes inesperados e logins com falha. O ConnectMQ bloqueia IPs após repetidas falhas de login e aplica proteção contra flood por tenant.
A relação entre os dois modelos faz parte da discussão mais ampla sobre convergência TI/TO, e nosso guia de MQTT para IoT industrial mostra como essas peças se encaixam em uma arquitetura de planta completa.
Conecte seus níveis com o ConnectMQ
Manter as zonas no estilo Purdue enquanto se achata o fluxo de dados exige um broker que todas as zonas consigam alcançar via TLS de saída. O ConnectMQ é um broker MQTT gerenciado com TLS na 8883, WebSockets seguros na 8084, credenciais por cliente e uma visão de dispositivos ISA-95, disponível em implantações compartilhadas, Dedicated ou BYOC. Comece no plano gratuito Serverless em app.connectmq.com, sem cartão de crédito.
Perguntas frequentes
O modelo Purdue está obsoleto?
Seu fluxo de dados rígido, um salto por vez, está sendo substituído por arquiteturas de publicação e assinatura, mas sua ideia central de segmentar as redes em zonas com fronteiras controladas continua sendo fundamental para a segurança de TO.
A ISA-95 define segurança de rede?
Não. A ISA-95 define funções, modelos de informação e a hierarquia de equipamentos. A segurança de redes e sistemas de automação industrial é tratada pela série ISA/IEC 62443.
Qual modelo devo usar para projetar topics MQTT?
Use a hierarquia de equipamentos ISA-95 para os topics e as zonas no estilo Purdue para decidir onde o broker roda e quais conexões de saída são permitidas.
Um Unified Namespace quebra o modelo Purdue?
Ele muda o fluxo de dados, não necessariamente a segmentação da rede. Com conexões MQTT apenas de saída e um broker na DMZ ou na nuvem, as zonas e os firewalls permanecem no lugar.
