SEW Connectivity Service
Visão Geral
O SEW Connectivity Service baseia-se no SDA Glue, a aplicação para Gateways, disponível para hosts Linux e Windows. O serviço é fornecido pelo SoftEther VPN, que suporta OpenVPN em clientes Windows, estabelecendo um túnel TCP seguro entre uma interface de rede no Gateway e os serviços em nuvem da SEW, como IDEaaS, Backup e VMs de Deployment. Ele também combina os firewalls nativos do sistema operacional, o iptables do Linux e a Windows Filtering Platform (WFP), com uma tabela NAT para conectar softwares específicos de fabricantes, como Siemens TIA Portal e Rockwell Studio 500, diretamente ao dispositivo na camada de controle da manufatura.
Pontos-Chave
O gerenciamento de ativos industriais com a SEW é viabilizado por uma solução de conectividade industrial abrangente e segura, que preenche a lacuna entre os ambientes de manufatura e os serviços baseados em nuvem. Ao aproveitar tecnologias consolidadas e implementar medidas de segurança robustas, o serviço oferece conectividade de nível corporativo, especialmente adaptada para sistemas de automação e controle industrial.
Segurança de Nível Industrial: a integração com o AWS IoT Core fornece conexões TLS seguras com políticas de controle de acesso granulares. Isso segue as melhores práticas de segurança em IoT industrial, permitindo que administradores restrinjam o acesso com base nas propriedades e no contexto do dispositivo.
Base de VPN Comprovada: o serviço utiliza o SoftEther VPN, que oferece criptografia AES de 256 bits e RSA de 4096 bits com alto desempenho de throughput e baixo consumo de memória e CPU, garantindo que os dados em trânsito permaneçam protegidos contra interceptação e acesso não autorizado — ideal para aplicações industriais em que segurança e desempenho são críticos.
Acesso à Rede Zero-Trust: o serviço elimina a necessidade de VPNs estáticas tradicionais ao estabelecer conexões sob demanda. Essa arquitetura Ponto-a-Ponto garante que os usuários possam acessar apenas os dispositivos especificamente autorizados, e não segmentos inteiros da rede, reduzindo significativamente a superfície de ataque.
Design Compatível com a Fábrica: todas as conexões são iniciadas de dentro para fora pelo próprio nó — um Gateway ou uma Workstation — e nunca aceitas como conexões de entrada, de modo que nenhuma regra de firewall de entrada é necessária. Esse design respeita as arquiteturas de segurança industriais existentes, ao mesmo tempo em que fornece recursos seguros de acesso remoto.
Arquitetura
Os pares em uma rede virtual são chamados de Nodes, que são os principais componentes do Connectivity Service. Cada conexão é construída a partir da interação de uma cadeia de Nodes, cada um com uma função específica.
Devices: ativos industriais normalmente localizados na rede segura de manufatura que podem ser acessados por seu endereço IP, por exemplo, PLCs, IHMs e Robôs. Os Devices são declarados no SEW Console para cada Tenant e o acesso dos usuários é gerenciado por Controle de Acesso Baseado em Funções (Role-Based Access Control). A conectividade exige que cada Device esteja vinculado a pelo menos um Gateway de rede.
Gateways: hosts de rede com acesso seguro à Internet e aos Devices gerenciados no SEW Console. Normalmente são IPCs, VMs, containers e até mesmo Raspberry Pis, localizados em uma zona de firewall que requer regras específicas para acessar os recursos da SEW Cloud, como os Tenant Servers. Cada Gateway executa o SDA Glue, que é um serviço do sistema operacional que escuta solicitações de conexão e fornece dados de telemetria.
Workstations: um PC do próprio cliente, utilizado para acessar dispositivos por meio de um Gateway no site de destino. Uma Workstation executa o mesmo software SDA Glue que um Gateway e é configurada de forma idêntica no nível de rede; a única diferença é a função — uma Workstation sempre inicia a conexão de saída em direção a um Gateway e nunca encaminha tráfego adiante para outros dispositivos.
Tenant Servers: hosts bastion executados em um ambiente seguro da SEW Cloud, dedicados a cada Tenant, que conectam a interface de rede do Gateway a uma VM de Serviço SEW ou a outro Gateway. Esses Servers garantem as políticas de filtragem necessárias para assegurar apenas conexões Ponto-a-Ponto, como do IDEaaS para um PLC específico e não para outros dispositivos indesejados na mesma rede do Gateway. Eles também autenticam o acesso dos Gateways com base em uma política de rotação de credenciais a cada conexão.
Service VMs: executam as aplicações necessárias aos Serviços SEW, como IDEaaS, Backup e Pipelines de Deployment. Essas VMs dependem do Connectivity Service para acessar os Devices na camada de rede, por seu endereço IP, o que é essencial para aplicações industriais.
Cloud
Em vez de utilizar VPNs estáticas tradicionais, o SEW Connectivity Service estabelece conexões com ativos industriais mediante solicitações, que são encaminhadas a uma cadeia de Nodes que operam em conjunto para fornecer acesso de rede Ponto-a-Ponto entre os Serviços SEW e os Devices.
Para a rede de manufatura, todas as conexões são iniciadas a partir do Gateway, não exigindo regras de conexão de entrada na fábrica. Para isso, os Nodes ficam constantemente escutando um message broker IoT em busca de solicitações recebidas, que é fornecido pelo AWS IoT Core.
Essa arquitetura permite que os usuários interajam com os ativos da fábrica de qualquer lugar com Internet, a partir de qualquer computador, dependendo apenas do navegador.
%20(1).webp)
Rede
O Gateway é um dispositivo de borda situado entre a camada de controle da manufatura e a Internet, que fornece aos serviços SEW acesso controlado aos ativos definidos no Console. Portanto, é muito importante consolidar uma arquitetura que conecte com segurança a SEW Cloud à infraestrutura local. Recomendamos uma das duas configurações propostas para o Gateway, conforme a seguir.
Gateway na LAN
Esta é a abordagem mais comum, na qual posicionamos o Gateway próximo aos PLCs que são integrados à plataforma SEW. Aqui, um firewall controla estritamente as saídas do Gateway para a Internet.
O Gateway tem acesso à sub-rede em que está localizado, mas um firewall pode ser provisionado no roteador da rede como uma Camada de Controle de Acesso (ACL). Também é comum utilizar um dispositivo Gateway com duas interfaces de rede: uma apontando para a DMZ e outra privada na camada de controle. Essa arquitetura permite zonas de IP repetidas, por exemplo, ambas com a sub-rede 10.0.0.0/24.
Gateway na DMZ
Esta abordagem é muito utilizada quando o Gateway é executado em uma Máquina Virtual dedicada, em algum ponto da infraestrutura de servidores. A equipe de TI fornecerá rotas especiais entre a VM e os PLCs de destino na camada de controle, e provavelmente existirão firewalls tanto no acesso à Internet quanto ao OT.
Também pode existir uma Network Address Translation (NAT) no caminho descendente até os PLCs. No entanto, isso requer atenção: alguns softwares específicos de fabricantes de PLC podem não ser compatíveis com o endereçamento do PLC por meio de um alias de IP; eles podem exigir o acesso ao IP explicitamente configurado no projeto.
Nesse caso, cada PLC na unidade de manufatura deve ter um endereço IP único; caso contrário, podem ocorrer colisões. Além disso, dependendo da infraestrutura de rede, o acesso de Camada 2 dos Gateways aos PLCs pode não funcionar, o que é um recurso futuro para a integração de Redes Industriais em Tempo Real nos serviços SEW.
Software
O SDA Glue é uma aplicação que roda como um serviço do sistema operacional, garantindo alta disponibilidade do Gateway com inicialização e reinicialização automáticas em caso de erros. Para estabelecer os túneis de rede gerenciando recursos de rede como interfaces, rotas e regras de firewall, ele requer elevação como usuário de sistema.
As Atualizações Automáticas estão habilitadas por padrão. O serviço Glue lerá a versão estável mais recente em repository.eu1.sdacosole.io e aplicará a atualização quando não houver conexões ativas. O mecanismo de atualização baixa o novo binário da aplicação, substitui o antigo e reinicia o serviço.
O AWS IoT Core será conectado durante o login, utilizando o endpoint iot.eu1.sdaconsole.io. Uma vez conectado, o serviço Glue ficará constantemente escutando as solicitações da SEW Cloud e publicando dados de telemetria, como o status dos Devices associados ao Gateway. A autenticação IoT é protegida por um ID curto e uma senha de uso único que pode ser obtida no SEW Console. A conexão com o IoT também é protegida por uma chave secreta no binário da aplicação. A conexão com o IoT pode ser configurada para ser estabelecida via MQTT SSL ou WebSocket Secure, ambos na porta 443.
Os mecanismos de rede são diferentes para Linux e Windows. Portanto, eles são descritos separadamente.
Linux
O SDA Glue no Linux baseia-se no SoftEther VPN Client, que é open-source (Apache License 2.0), instalado a partir do mirror da SEW em repository.eu1.sdaconsole.io durante a instalação do Glue.
Para cada conexão, o Glue utiliza o SoftEther Client para criar uma interface de rede NIC e conectá-la ao Tenant Server. Ele também utiliza as ferramentas de IP do Linux para atribuir um endereço IP a essa interface e criar as rotas necessárias entre a Service VM e o Device de destino.
As regras internas de firewall e a tradução NAT são criadas no iptables, que não permite pacotes de rede de entrada no Gateway, mas apenas o encaminhamento de pacotes para o Device de destino.
📚 Gerenciamento de Recursos do Linux nas Conexões
Para entender como o Gateway Linux conecta os serviços em nuvem aos dispositivos da fábrica, vamos percorrer um exemplo concreto com endereços IP específicos que ilustram o fluxo completo.
Considere uma rede de fábrica em que um Device de destino (como um PLC) tenha o endereço IP local 10.0.0.5 e o Gateway esteja na mesma rede com o IP 10.0.0.2. Na SEW Cloud, uma Service VM precisa se conectar a esse Device e receberá o IP de VPN 100.112.20.3, enquanto a interface VPN do Gateway receberá 100.112.10.6.
Estabelecendo o Túnel
Quando uma solicitação de conexão chega, tanto o Gateway quanto a Service VM entram em ação. O Gateway cria uma nova interface de rede virtual chamada vpn_iface e atribui a ela o endereço 100.112.10.6. Simultaneamente, a Service VM na nuvem cria sua própria interface VPN com o IP 100.112.20.3. Ambos os endpoints então se conectam ao Tenant Server, estabelecendo um túnel criptografado seguro entre eles.
Factory Side: Cloud Side:
Gateway Service VM
├─ Local: 10.0.0.2 ├─ VPN: 100.112.20.3
└─ VPN: 100.112.10.6 └─ Target: 10.0.0.5 (via Gateway)
Device
└─ Local: 10.0.0.5
Nesse ponto, o túnel existe, mas os pacotes ainda não sabem para onde ir. O Gateway precisa ensinar ao sistema como rotear o tráfego entre esses dois mundos.
Construindo as Rotas
O Gateway adiciona uma regra de roteamento que cria a conexão entre a rede VPN e o chão de fábrica:
ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface
Essa rota informa ao sistema uma informação crucial: quando o Device em 10.0.0.5 enviar pacotes de resposta, eles devem ser encaminhados através de vpn_iface para alcançar a Service VM em 100.112.20.3. Sem essa rota, o Gateway não saberia como enviar as respostas do Device de volta para a nuvem.
Mas o roteamento sozinho não é suficiente. O firewall do Gateway ainda bloquearia esse tráfego por padrão. Para habilitar a conexão, o Gateway deve permitir explicitamente o encaminhamento bidirecional de pacotes entre a VM e o Device:
iptables -A GLUE_FORWARD -s 100.112.20.3 -d 10.0.0.5 -j ACCEPT
iptables -A GLUE_FORWARD -s 10.0.0.5 -d 100.112.20.3 -j ACCEPT
Essas regras abrem um caminho controlado, permitindo que os pacotes fluam da Service VM para o Device e de volta, mantendo ainda a postura de segurança do Gateway para todo o restante do tráfego. Observe também que o Glue utiliza suas próprias chains no iptables, para não causar conflitos com as demais regras.
Tradução NAT
O Device na fábrica espera se comunicar com endereços IP locais — ele não tem conhecimento da rede em nuvem em 100.112.20.3 e não saberia como responder a pacotes provenientes desse endereço. O Gateway resolve isso mascarando os pacotes da Service VM:
iptables -t nat -A GLUE_POSTROUTING -s 100.112.20.3 -d 10.0.0.5 -j MASQUERADE
Com essa regra de NAT em vigor, quando um pacote chega da Service VM destinado ao Device, o Gateway reescreve seu endereço de origem de 100.112.20.3 para 10.0.0.2. Da perspectiva do Device, parece que ele está se comunicando diretamente com o próprio Gateway — um endereço familiar e confiável em sua rede local. Quando o Device envia sua resposta para 10.0.0.2, o Gateway realiza a tradução inversa, alterando o endereço de destino de volta para 100.112.20.3, para que o pacote alcance a Service VM através do túnel VPN.
Por meio dessa orquestração de tunelamento VPN, roteamento, regras de firewall e tradução NAT, o Gateway cria uma conexão ponto-a-ponto transparente. O Device nunca enxerga a infraestrutura em nuvem — ele simplesmente se comunica com o que parece ser o Gateway em sua rede local em 10.0.0.2. Enquanto isso, a Service VM obtém acesso direto na camada de rede ao Device por seu endereço IP 10.0.0.5, permitindo que aplicações industriais como o TIA Portal ou o Studio 5000 funcionem como se estivessem sendo executadas na própria rede local da fábrica.
Windows
O SDA Glue no Windows não suporta o uso embarcado do SoftEther VPN Client, portanto utiliza o OpenVPN Community Open-Source Client (licença GPL versão 2), instalado a partir do mirror da SEW em repository.eu1.sdaconsole.io durante a instalação do Glue.
Para cada conexão, o Glue utiliza o driver TAP do OpenVPN para criar uma interface de rede e conectá-la ao Tenant Server usando autenticação baseada em certificado. Ele usa a API nativa do Windows para atribuir um IP à interface e criar as rotas necessárias entre a Service VM e o Device de destino.
O Glue também utiliza a Windows Filtering Platform (WFP) para criar camadas e regras de firewall dedicadas. No entanto, ele depende do WinNAT ou do NetNat para declarar a tradução de endereços entre a Service VM e o Device, o que pode não estar habilitado por padrão.
Workstation vs. Gateway: as Workstations e os Gateways utilizam o mesmo cliente Windows e a mesma configuração de conexão descritos acima — mesmo driver TAP do OpenVPN, mesmo endereçamento de interface baseado em WinNAT. A única diferença é a regra de firewall WFP atribuída por conexão pela política do backend: a conexão de uma Workstation sempre recebe uma regra somente de saída restrita ao IP do dispositivo de destino específico através da interface de túnel SEW, enquanto um Gateway pode receber adicionalmente uma regra de encaminhamento para direcionar o tráfego adiante aos dispositivos por trás dele. Portanto, uma Workstation nunca abre caminhos de entrada ou de encaminhamento no host, e nenhuma outra interface de rede, rota ou conexão VPN existente naquele PC é afetada — todas as alterações ficam restritas à interface virtual que o SDA Glue cria para seu próprio túnel.
Resumo
O SEW Connectivity Service oferece uma solução madura, segura e escalável para os desafios de conectividade industrial. Ao combinar tecnologias open-source consolidadas, como o SoftEther VPN, com uma infraestrutura em nuvem de nível corporativo do AWS IoT Core, o serviço fornece a confiabilidade e a segurança exigidas pelas operações industriais, oferecendo ao mesmo tempo a flexibilidade e a facilidade de uso que as equipes de engenharia modernas esperam.
A arquitetura do serviço respeita os princípios de segurança industrial ao mesmo tempo em que viabiliza as iniciativas de transformação digital que impulsionam a eficiência operacional, a colaboração remota e a tomada de decisões baseada em dados. Para organizações que buscam conectar com segurança seus ativos industriais a serviços em nuvem sem comprometer a segurança de rede ou a confiabilidade operacional, o SEW Connectivity Service oferece uma solução abrangente e pronta para produção.