SDA Connectivity Service
Visão geral
O SDA Connectivity Service baseia-se no SDA Glue, a aplicação para Gateways, disponível para hosts Linux e Windows. O serviço é suportado 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 de nuvem da SDA, tais como IDEaaS, Backup e VMs de Deployment. Também combina firewalls nativos do sistema operativo, iptables do Linux e Windows Filtering Platform (WFP), com uma tabela NAT para ligar software específico do fabricante, como Siemens TIA Portal e Rockwell Studio 500, diretamente ao dispositivo na camada de controlo de produção.
Pontos principais
A gestão de ativos industriais com o SDA é suportada por uma solução de conectividade industrial abrangente e segura, que estabelece a ponte entre os ambientes de produção e os serviços baseados em nuvem. Ao aproveitar tecnologias comprovadas e implementar medidas de segurança robustas, o serviço oferece conectividade de nível empresarial concebida especificamente para sistemas de automação e controlo industrial.
Segurança de nível industrial: a integração com o AWS IoT Core proporciona conexões TLS seguras com políticas de controlo de acesso granulares. Isto segue as melhores práticas de segurança de IoT industrial, permitindo que os administradores restrinjam o acesso com base nas propriedades e no contexto do dispositivo.
Base VPN comprovada: o serviço utiliza o SoftEther VPN, que fornece encriptação AES de 256 bits e RSA de 4096 bits com desempenho de alta velocidade e baixa utilização de memória e CPU, garantindo que os dados em trânsito permaneçam protegidos contra escuta e acesso não autorizado, ideal para aplicações industriais em que a segurança e o 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. Esta arquitetura Ponto-a-Ponto garante que os utilizadores só possam acessar dispositivos especificamente autorizados, e não segmentos de rede inteiros, reduzindo significativamente a superfície de ataque.
Design compatível com a fábrica: todas as conexões são iniciadas para o exterior pelo próprio nó — um Gateway ou uma Workstation — nunca aceitas como conexões de entrada, pelo que nunca são necessárias regras de firewall de entrada. Este design respeita as arquiteturas de segurança industrial existentes, ao mesmo tempo que fornece capacidades de acesso remoto seguro.
Arquitetura
Os pares numa rede virtual são chamados de Nós, que são os principais componentes do Connectivity Service. Cada conexão é construída a partir da interação de uma cadeia de Nós, cada um com uma função específica.
Devices: ativos industriais normalmente localizados na rede segura de produção, que podem ser acessados pelo seu endereço IP, por exemplo PLCs, HMIs e Robôs. Os Devices são declarados na SDA Console para cada Tenant e o acesso dos utilizadores é gerido por Controlo de Acesso Baseado em Funções. A conectividade requer que cada Device esteja associado a pelo menos um Gateway de rede.
Gateways: hosts de rede com acesso seguro à Internet e aos Devices geridos na SDA Console. São normalmente IPCs, VMs, Containers e até Raspberry Pis, localizados numa zona de firewall que requer regras específicas para acessar os recursos da SDA Cloud, como os Tenant Servers. Cada Gateway executa o SDA Glue, que é um serviço do sistema operativo que escuta pedidos de conexão e fornece dados de telemetria.
Workstations: um PC do próprio cliente, utilizado para acessar dispositivos através de um Gateway no site de destino. Uma Workstation executa o mesmo software SDA Glue que um Gateway e é configurada de forma idêntica ao nível da rede; a única diferença é a função — uma Workstation inicia sempre a conexão para o exterior em direção a um Gateway e nunca encaminha tráfego para outros dispositivos.
Tenant Servers: hosts bastião que executam num ambiente seguro da SDA Cloud, dedicados a cada Tenant, que ligam a interface de rede do Gateway a uma VM de Serviço SDA ou a outro Gateway. Estes 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. Também autenticam o acesso dos Gateways com base numa política de rotação de credenciais para cada conexão.
Service VMs: executam as aplicações necessárias aos Serviços SDA, como IDEaaS, Backup e Pipelines de Deployment. Estas VMs baseiam-se no Connectivity Service para acessar os Devices na camada de rede, pelo seu endereço IP, o que é essencial para aplicações industriais.
Nuvem
Em vez de utilizar VPNs estáticas tradicionais, o SDA Connectivity Service estabelece conexões a ativos industriais sob pedido, que são encaminhados para uma cadeia de Nós que operam em conjunto para fornecer acesso de rede Ponto-a-Ponto entre os Serviços SDA e os Devices.
Para a rede de produção, todas as conexões são iniciadas a partir do Gateway, não sendo necessárias regras de conexão de entrada na fábrica. Para isso, os Nós escutam constantemente num message broker IoT à espera de pedidos de entrada, suportado pelo AWS IoT Core.
Esta arquitetura permite que os utilizadores interajam com os ativos na fábrica a partir de qualquer lugar com Internet, de qualquer computador, dependendo apenas de um navegador.
%20(1).webp)
Rede
O Gateway é um dispositivo de borda situado entre uma camada de controlo de produção e a Internet, que fornece aos serviços SDA acesso controlado aos ativos definidos na Console. Por isso, é muito importante consolidar uma arquitetura que ligue de forma segura a SDA Cloud à infraestrutura local. Recomendamos uma das duas configurações propostas para o Gateway, conforme se segue.
Gateway na LAN
Esta é a abordagem mais comum, na qual colocamos o Gateway junto aos PLCs que são integrados na plataforma SDA. Aqui, uma firewall controla estritamente as conexões de saída do Gateway para a Internet.
O Gateway tem acesso à subrede onde está localizado, mas pode ser provisionada uma firewall no router da rede como uma Camada de Controlo de Acesso (ACL). Também é comum utilizar um dispositivo Gateway com duas interfaces de rede: uma apontada para a DMZ e uma privada na camada de controlo. Esta arquitetura permite zonas de IP repetidas, por exemplo, ambas com a subrede 10.0.0.0/24.
Gateway na DMZ
Esta abordagem é muito utilizada quando o Gateway é executado numa Máquina Virtual dedicada, em algum ponto da infraestrutura de servidores. A equipa de TI fornecerá rotas especiais entre a VM e os PLCs de destino na camada de controlo e provavelmente existirão firewalls em ambos os acessos, à Internet e à OT.
Pode também existir uma tradução de endereços de rede (NAT) no sentido descendente até aos PLCs. No entanto, isto requer atenção: alguns softwares específicos de fabricantes de PLC podem não ser compatíveis com o endereçamento do PLC por um alias de IP, podendo exigir o acesso ao IP explicitamente configurado no projeto.
Neste caso, cada PLC na unidade de produção 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 ao PLC pode não funcionar, o que constitui uma funcionalidade futura para a integração de Redes Industriais em Tempo Real nos serviços SDA.
Software
O SDA Glue é uma aplicação que é executada como um serviço do sistema operativo, garantindo alta disponibilidade do Gateway com arranque e reinício automatizados em caso de erros. Para estabelecer os túneis de rede através da gestão de recursos de rede como interfaces, rotas e regras de firewall, requer elevação como utilizador do sistema.
As atualizações automáticas estão ativadas por predefinição. O serviço Glue lê a versão estável mais recente em repository.eu1.sdacosole.io e aplica a atualização quando não existem conexões ativas. O mecanismo de atualização descarrega 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 escutará constantemente os pedidos da SDA Cloud e publicará dados de telemetria, como o estado dos Devices associados ao Gateway. A autenticação IoT é protegida por um ID curto e uma palavra-passe de uso único que pode ser obtida na SDA Console. A conexão ao IoT é também protegida por uma chave secreta no binário da aplicação. A conexão ao 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. Por isso, são descritos separadamente.
Linux
O SDA Glue em Linux baseia-se no SoftEther VPN Client, que é open-source (Apache License 2.0), instalado a partir do mirror da SDA 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. Também utilizará 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.
📚 Gestão de Recursos Linux em Conexões
Para compreender como o Gateway Linux liga os serviços de 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) tem o endereço IP local 10.0.0.5 e o Gateway se encontra na mesma rede com o IP 10.0.0.2. Na SDA Cloud, uma Service VM precisa de se conectar a este Device e receberá o IP de VPN 100.112.20.3, enquanto a interface VPN do Gateway receberá 100.112.10.6.
Estabelecer o túnel
Quando chega um pedido de conexão, tanto o Gateway como a Service VM entram em ação. O Gateway cria uma nova interface de rede virtual chamada vpn_iface e atribui-lhe o endereço 100.112.10.6. Simultaneamente, a Service VM na nuvem cria a sua própria interface VPN com o IP 100.112.20.3. Ambos os pontos finais conectam-se então ao Tenant Server, estabelecendo entre si um túnel seguro e encriptado.
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
Neste ponto, o túnel existe, mas os pacotes ainda não sabem para onde ir. O Gateway precisa de ensinar ao sistema como encaminhar o tráfego entre estes dois mundos.
Construir as rotas
O Gateway adiciona uma regra de encaminhamento que cria a conexão entre a rede VPN e o piso de fábrica:
ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface
Esta rota informa o sistema de um dado crucial: quando o Device em 10.0.0.5 envia pacotes de resposta, estes devem ser encaminhados através de vpn_iface para alcançar a Service VM em 100.112.20.3. Sem esta rota, o Gateway não saberia como enviar as respostas do Device de volta para a nuvem.
Mas o encaminhamento por si só não é suficiente. A firewall do Gateway continuaria a bloquear este tráfego por predefinição. Para ativar 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
Estas 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 tráfego. Note também que o Glue utiliza as suas próprias chains no iptables, para não causar conflitos com as outras regras.
Tradução NAT
O Device na fábrica espera comunicar com endereços IP locais — não tem conhecimento da rede de nuvem em 100.112.20.3 e não saberia como responder a pacotes provenientes desse endereço. O Gateway resolve isto mascarando (masquerading) os pacotes da Service VM:
iptables -t nat -A GLUE_POSTROUTING -s 100.112.20.3 -d 10.0.0.5 -j MASQUERADE
Com esta regra NAT em vigor, quando um pacote chega da Service VM destinado ao Device, o Gateway reescreve o seu endereço de origem de 100.112.20.3 para 10.0.0.2. Da perspetiva do Device, parece que está a comunicar diretamente com o próprio Gateway — um endereço familiar e confiável na sua rede local. Quando o Device envia a sua resposta para 10.0.0.2, o Gateway realiza a tradução inversa, alterando o endereço de destino novamente para 100.112.20.3, para que o pacote alcance a Service VM através do túnel VPN.
Através desta orquestração de tunelamento VPN, encaminhamento, regras de firewall e tradução NAT, o Gateway cria uma conexão ponto-a-ponto transparente. O Device nunca vê a infraestrutura de nuvem — simplesmente comunica com aquilo que parece ser o Gateway na sua rede local em 10.0.0.2. Entretanto, a Service VM obtém acesso direto ao Device na camada de rede pelo 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 a ser executadas na própria rede local da fábrica.
Windows
O SDA Glue em Windows não suporta a utilização integrada do SoftEther VPN Client, por isso utiliza o OpenVPN Community Open-Source Client (licença GPL versão 2), instalado a partir do mirror da SDA 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 utilizando autenticação baseada em certificados. Utiliza 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, 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 ativado por predefinição.
Workstation vs. Gateway: as Workstations e os Gateways utilizam o cliente Windows e a configuração de conexão idênticos aos descritos acima — o mesmo driver TAP do OpenVPN, o 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 recebe sempre uma regra apenas de saída, limitada ao IP do dispositivo de destino específico através da interface de túnel SDA, enquanto um Gateway pode receber adicionalmente uma regra de encaminhamento para transportar o tráfego para dispositivos por trás dele. Uma Workstation nunca abre, portanto, caminhos de entrada ou de encaminhamento no host, e nenhuma outra interface de rede, rota ou conexão VPN existente nesse PC é afetada — todas as alterações estão confinadas à interface virtual que o SDA Glue cria para o seu próprio túnel.
Resumo
O SDA Connectivity Service oferece uma solução madura, segura e escalável para os desafios de conectividade industrial. Ao combinar tecnologias open-source comprovadas como o SoftEther VPN com infraestrutura de nuvem de nível empresarial do AWS IoT Core, o serviço proporciona a fiabilidade e a segurança exigidas pelas operações industriais, oferecendo simultaneamente a flexibilidade e a facilidade de utilização que as equipas de engenharia modernas esperam.
A arquitetura do serviço respeita os princípios de segurança industrial, ao mesmo tempo 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 procuram conectar de forma segura os seus ativos industriais a serviços de nuvem sem comprometer a segurança da rede ou a fiabilidade operacional, o SDA Connectivity Service fornece uma solução abrangente e pronta para produção.