Portátil de trabalho numa VPN pessoal: o que atravessa realmente

Ligar um portátil da empresa a uma VPN doméstica coloca-o em dois locais ao mesmo tempo, e a pergunta interessante é mais pequena e mais útil do que a alarmante. Ninguém estendeu um cabo Ethernet entre o escritório e a casa, e nenhuma rota faz da rede doméstica uma extensão da sub-rede corporativa. O que existe é um único ponto final com acesso aos dois ambientes, e três mecanismos separados decidem o que pode realmente mover-se entre eles. Percorrer esses três, do ponto final para fora, produz uma resposta sobre a qual um administrador pode agir em vez de um debate sobre rótulos.

Comece no ponto final, não no diagrama de rede

O ponto final é onde as duas ligações se encontram, por isso é aí que começa a revisão: que processos correm, o que podem alcançar e quem os controla. Um diagrama que mostra duas nuvens ligadas a um portátil é exato e inútil, porque implica uma ligação que pode não existir. Substitua-o por uma lista das aplicações que conseguem falar com cada ambiente, e anote sob que conta corre cada uma. Esse enquadramento mantém também a revisão proporcionada, já que um portátil com dois túneis não é o mesmo objeto que duas redes unidas.

Essa lista é o inventário a partir do qual trabalha o resto da revisão. Se contiver um cliente de sincronização, um perfil de navegador com sessão iniciada nos dois ambientes e um agente de compilação com credenciais, a revisão já tem os seus sujeitos.

Três pontos de travessia, revistos separadamente

O acesso das aplicações é o primeiro ponto de travessia e não exige qualquer encaminhamento. Um separador do navegador, um cliente de sincronização ou um agente de compilação no ponto final podem ler de um recurso num ambiente e enviar dados para um recurso no outro. Essa capacidade existe quer o sistema operativo encaminhe pacotes entre interfaces quer não, e é o mecanismo que as pessoas perdem quando concluem que sem ponte não há risco. Ler a lista de aplicações é, por isso, mais informativo do que ler a lista de interfaces.

A identidade e os dados formam o segundo ponto de travessia. As credenciais corporativas, os cookies de sessão, os documentos descarregados e os direitos de gestão vivem no ponto final, e aderir a outra rede não os divulga por si só. O que muda é o conjunto de partes que poderiam influenciar o ponto final enquanto este detém essas credenciais, e isso é uma questão sobre a fiabilidade da rede pessoal e não sobre o encaminhamento. É um juízo que o proprietário do ponto final não pode fazer sozinho, e não é respondido pela ausência de uma regra de encaminhamento.

O encaminhamento de rede é o terceiro, e o único que pode transformar o portátil num dispositivo de trânsito. O encaminhamento de IP, a partilha de ligação à Internet, um proxy ou uma função de ponte podem fazê-lo, e cada um é uma configuração que está ou não ativa. Inspecione esse estado diretamente em vez de o inferir da presença de um cliente VPN. Numa máquina gerida a resposta é habitualmente não, e verificá-la transforma uma suposição num facto que vale a pena registar.

Peça um recurso, não duas redes

A maioria dos requisitos reais é mais estreita do que parece à primeira vista: uma consola, uma partilha de ficheiros, uma aplicação web interna. Formule o requisito dessa forma e deixe o proprietário do recurso decidir se pertence a este ponto final. Um pedido formulado como união de duas redes é difícil de aprovar e fácil de recusar; um pedido para um serviço nomeado tem resposta.

Se a resposta for sim, prefira o caminho suportado mais estreito e mantenha-o dentro dos controlos existentes da organização. Um segundo perfil gerido ou uma entrada de aplicação de âmbito limitado preservam a monitorização e a política; uma configuração pessoal concorrente substitui-as em silêncio, e ninguém sabe qual vence após a próxima atualização.

Inclua os efeitos de DNS e de rotas

A resolução de nomes muda no momento em que um segundo perfil está ativo. Um cliente pessoal pode impor o seu próprio resolver, um navegador pode usar o seu próprio DNS cifrado, e uma tabela de políticas pode encaminhar nomes internos para um servidor diferente do que a configuração corporativa espera. Nenhum desses casos exige encaminhamento, e qualquer deles pode enviar um nome de anfitrião interno para o local errado.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Capture essas três saídas antes e depois de o segundo perfil se ligar. A diferença entre elas é o efeito que chega realmente ao utilizador, e é muitas vezes maior do que a alteração de encaminhamento descrita pelo ticket. Guarde ambas as capturas para que um revisor posterior veja o que mudou e não o que se pretendia.

Verifique e mantenha uma saída

Teste a aplicação aprovada a partir do processo e do contexto de utilizador reais, e não de uma shell de administrador na mesma máquina. Depois confirme que os destinos não relacionados permanecem inalcançáveis onde o desenho o exige: uma fronteira que ninguém testou é uma fronteira que ninguém pode reivindicar. Desligar o túnel pessoal deveria restaurar o estado anterior, e essa restauração merece ser verificada enquanto alguém ainda observa.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

A orientação do NIST sobre arquitetura de confiança zero é útil aqui porque remove a localização na rede como fonte automática de confiança, que é exatamente a suposição em causa. A pergunta não é se a rede doméstica é fiável por natureza; é quem pode alcançar que recurso, a partir de que ponto final e através de que ponto de aplicação. Responda a essas três, e guarde as provas com a decisão.