Dispositivo de campo, TLS e VPN: qual fronteira protege o quê

Um dispositivo de campo abre uma ligação a um serviço e a pergunta de projeto surge como uma escolha entre VPN e TLS. Esse enquadramento está errado, porque os dois fazem trabalhos diferentes. O TLS autentica o ponto final da aplicação e protege a conversa; enquanto uma VPN controla a acessibilidade e protege os pacotes entre pares. Percorra a ligação do dispositivo para fora e cada camada tem a sua própria resposta.

Se não consegue dizer onde o TLS termina, não consegue dizer em que a aplicação realmente confia.

Descubra onde o TLS termina realmente

Comece na aplicação do dispositivo e siga a ligação até ao processo que conclui o handshake. Se um proxy terminar o TLS antes do mainframe, o caminho protegido acaba no proxy. O salto restante precisa da sua própria proteção documentada.

Chamar a isso de ponta a ponta por suposição é como uma revisão de projeto aprova uma lacuna. Desenhe o ponto de terminação e a âncora de confiança no mesmo diagrama.

O TLS transporta pedidos e respostas nos dois sentidos, por isso uma aplicação bidirecional não precisa intrinsecamente de uma VPN em vez de TLS. O contrário também é verdade: uma implementação pode ainda precisar de uma VPN para outros protocolos no mesmo dispositivo.

Decida o que o dispositivo tem de autenticar

Configure a validação da identidade do servidor e as raízes de confiança previstas. Se cada dispositivo tiver de provar a sua própria identidade, escolha um modelo de autenticação de cliente suportado e registe uma credencial distinta por dispositivo. Credenciais partilhadas transformam um só dispositivo roubado num problema para toda a frota.

Planeie a proteção de chaves, a renovação, a revogação e a recuperação antes do envio. Um dispositivo no campo que não pode ser registado de novo após uma renovação falhada torna-se uma deslocação ao local, e esse custo molda o projeto mais do que o handshake.

Utilize uma biblioteca suportada e as orientações atuais. Orientações modernas de implementação de TLS proíbem negociar TLS 1.0 e 1.1, e uma referência a TLSv1 numa nota de projeto antiga não é um requisito.

Feche quando o handshake falha

Um handshake falhado ou uma verificação de identidade falhada não deve recuar silenciosamente para o protocolo de texto limpo original. Esse recuo é a vulnerabilidade que o trabalho de TLS devia fechar. Torne a falha visível para o operador do dispositivo e para o serviço, e exija o canal protegido para operações sensíveis. Depois deixe a autorização da aplicação decidir o que um dispositivo autenticado pode fazer.

Defina o tempo de vida da ligação, o enquadramento, os tempos limite e o comportamento de repetição como parte do contrato. A cifra não torna uma ordem repetida segura, e uma repetição após uma operação anterior incerta exige uma resposta ao nível da aplicação.

Escreva a regra de recuo. «Volta a ligar sem TLS se o handshake falhar» é uma decisão de projeto, e deve ser explícita.

Dê à VPN apenas o trabalho que ela consegue fazer

Uma VPN pode restringir a acessibilidade e proteger os pacotes até ao seu próprio par. O TLS protege a relação da aplicação com o ponto final escolhido. Os pontos de terminação podem diferir, e nenhum dos dois protege os dados armazenados do ponto final nem o acesso administrativo.

Meça o custo do handshake, a troca de mensagens estável e a reconexão no dispositivo real em vez de assumir que um mecanismo é mais rápido. Depois teste os quatro casos que importam: a troca prevista, uma identidade de servidor errada, um dispositivo não autorizado e uma reconexão após uma operação incerta. Registe o resultado de cada caso, incluindo o erro que o dispositivo mostra.