O que torna uma arquitetura de gateway IoT segura?
Com o advento da Indústria 4.0 e da IoT Industrial, tem havido um interesse crescente em conectar sistemas de fábrica a serviços em nuvem. As empresas que buscam obter insights sobre seus processos podem executar análises em plataformas IoT baseadas em nuvem e usar os resultados para melhorar o desempenho. Uma maneira popular de fazer a conexão de seus equipamentos com a nuvem tem sido usar o OPC UA para comunicações de dados na planta e um gateway MQTT para enviar seus dados para a nuvem. Embora esta combinação forneça alguns recursos de segurança desejáveis, ela pode não atender às necessidades de todos. Para explicar o porquê, vamos analisar primeiro um cenário típico de gateway IoT e, em seguida, um cenário aprimorado que melhora substancialmente a segurança da planta.
Cenário Típico
O gateway IoT típico combina dois tipos de comunicação de dados: na fábrica e da fábrica para a nuvem. OPC UA é frequentemente recomendado para comunicações seguras na fábrica para Indústria 4.0 e IoT Industrial. Isso ocorre porque o OPC UA oferece segurança multicamadas, incluindo autenticação e autorização na camada de aplicação, bem como criptografia e integridade de dados por meio do uso de certificados na camada de transporte. Mas para conexões fora da planta, o OPC UA não é seguro porque requer a abertura de uma porta de firewall para permitir que um cliente se conecte à planta.
Para conexões planta-nuvem, o MQTT é frequentemente usado. MQTT é um protocolo útil para um gateway IoT porque os serviços de nuvem populares como Microsoft Azure, Google Cloud e AWS IoT Core o suportam. Com o MQTT você pode fazer uma conexão de saída da planta para o serviço de nuvem sem abrir nenhuma porta de firewall de entrada. Isto é essencial para a segurança da planta. Assim, um gateway IoT de software como o DataHub IoT Gateway da Skkynet pode oferecer conectividade segura dentro da planta por meio de sua interface OPC UA e uma conexão de saída segura para um serviço em nuvem via MQTT.
Qualquer software de gateway IoT deve ser totalmente compatível e suportar os recursos de segurança OPC UA. E, além da conexão de saída segura do MQTT, ele deve suportar algum tipo de camada de transporte segura, como segurança baseada em certificado SSL. Com essa combinação implementada, você pode esperar um caminho de dados razoavelmente seguro do dispositivo até a nuvem.
No entanto, há uma desvantagem. O gateway IoT típico que envia dados OPC UA para a nuvem precisa de uma conexão direta com a Internet. Se a política de segurança de uma empresa não permite uma conexão direta à Internet na fábrica, então é necessário algo mais.
Corrente de conexões
Para uma comunicação IoT mais segura, muitas empresas preferem usar um computador isolado executado fora da rede da planta, muitas vezes chamado de DMZ (Zona Desmilitarizada). Ou uma empresa pode querer enviar os dados primeiro ao departamento de TI para acessar partes do fluxo de dados antes de enviá-los para a nuvem. Na verdade, os sistemas de produção altamente seguros normalmente não têm uma ligação direta à Internet e, por isso, são obrigados a direcionar o tráfego através de TI ou de uma DMZ. Ambos os casos de uso exigem uma arquitetura multi-hop, também conhecida como “daisy chain”. Em uma conexão em cadeia robusta, cada salto deve retransmitir de forma confiável todos os dados recebidos, ao mesmo tempo que informa os clientes downstream sobre quaisquer falhas nas conexões de rede em qualquer lugar ao longo da cadeia. Infelizmente, nem o OPC UA nem o MQTT foram projetados para esta tarefa.
O protocolo OPC UA assume que um cliente estará conectado diretamente a um servidor e que o servidor é a fonte primária de informações. Em uma cadeia, os saltos ao longo da cadeia devem ser clientes e servidores, portanto, cada salto deve reconstruir o modelo de dados e o comportamento do servidor original. O protocolo OPC UA é simplesmente complexo demais para fazer isso. Além disso, o protocolo OPC UA exige que o cliente se conecte ao servidor, o que significa que cada salto na cadeia deve abrir-se para conexões de entrada, que é exatamente o comportamento que o sistema está tentando evitar.
O MQTT pode ser conectado em série com corretores especialmente projetados, mas exige que cada nó da cadeia esteja ciente de que faz parte da cadeia e seja configurado individualmente. Todos os clientes no sistema precisam estar cientes de todos os outros clientes de origem de dados e devem ser configurados para associar cada item de dados a uma mensagem de status de conexão dependente da origem. Em sistemas não triviais isto impõe um enorme custo de manutenção. Além disso, as garantias de qualidade de serviço do MQTT não podem se propagar pela cadeia, portanto, uma configuração multi-hop não seria capaz de garantir que os clientes tenham os valores mais recentes.
Cenário aprimorado
O que é necessário é um cenário novo e aprimorado, que possa espelhar o conjunto completo de dados em cada nó e fornecer acesso a esses dados tanto para clientes qualificados quanto para o próximo nó da cadeia. Isto, por exemplo, daria ao departamento de TI acesso total aos dados, mesmo quando estes estão a ser transferidos para o serviço na nuvem.
Este cenário aprimorado pode ser implementado usando um produto de middleware como o DataHub, instalado em cada nó. O DataHub é capaz de encapsular os dados entre um nó na planta e um DMZ ou servidor de TI sem abrir nenhuma porta de firewall de entrada na planta. Um segundo DataHub, instalado na DMZ ou no servidor de TI, pode então passar os dados para o serviço MQTT.
A conexão DataHub para DataHub usa o DataHub Transfer Protocol (DHTP), que envia e recebe dados em tempo real usando TCP através de uma LAN, WAN ou Internet. A conexão OPC UA com o DataHub na planta é de um único salto. E a conexão MQTT do DataHub ao serviço de nuvem também ocorre em um único salto. O DHCP lida com as conexões em cadeia, espelhando o conjunto completo de dados e o status da conexão em cada nó. O DataHub permite o acesso a esses dados por clientes qualificados, bem como repassá-los para o próximo nó da cadeia, mantendo a consistência dos dados. A garantia de Qualidade de Serviço DHCP garante que qualquer cliente ou ponto intermediário na cadeia será consistente com a fonte original, mesmo que alguns eventos devam ser descartados para acomodar largura de banda limitada. Se uma conexão de rede for perdida, o DataHub atualizará automaticamente as qualidades dos dados de todos os pontos de dados relacionados para garantir que todos os clientes da cadeia estejam imediatamente cientes dessa perda de conexão.
O resultado é que existe uma maneira comprovada de configurar uma conexão de gateway MQTT com segurança por meio de uma DMZ, do departamento de TI ou de outro nó da Internet. A maioria dos produtos de gateway IoT não são adequados para a tarefa e podem oferecer apenas o cenário típico de OPC UA para MQTT. Isso pode ser bom para sistemas não críticos, mas as aplicações industriais exigem mais. Para aqueles que precisam proteger suas plantas usando uma DMZ, ou que desejam enviar seus dados para o departamento de TI antes de passá-los para a nuvem, o middleware DataHub da Skkynet oferece uma solução segura e robusta.
Skkynet®, DataHub®, SkkyHub™, WebView™, os logotipos Skkynet e DataHub são marcas registradas ou marcas comerciais usadas sob licença pelo grupo de empresas Skkynet (“Skkynet”).
Todos e quaisquer direitos de propriedade intelectual associados ao presente documento e ao seu conteúdo (incluindo, mas não se limitando a: texto, relatório, planilha, apresentação, imagens gráficas, marcas registradas, logotipos, traduções, etc.) são de propriedade exclusiva da PARAGON TECNOLOGIA LTDA.. Nesse sentido, o conteúdo não pode, sob qualquer pretexto, ser vendido, cedido, distribuído, transmitido, copiado, modificado ou descompilado, de qualquer forma, sem o Consentimento prévio, e por escrito, da PARAGON TECNOLOGIA LTDA.. Ademais, qualquer uso não autorizado do conteúdo é expressamente proibido e pode constituir uma violação da lei.
