VPN sempre ativa: separar caminho, permissão e sessão

Manter um túnel ativo o tempo todo é uma decisão de projeto com uma versão legítima e uma versão descuidada. Uma filial que precisa de um aplicativo central durante todo o dia, além de uma rotina de backup noturna, tem motivo. Um laptop deixado conectado num quarto de hotel por três dias é um acidente.

Os dois mostram o mesmo ícone verde e os dois respondem da mesma forma se você perguntar há quanto tempo o túnel está ativo. Esse número não é o interessante. O que importa é o que a conexão mantém acessível, para quem, e o que de fato a encerra.

Três relógios que correm separadamente

O primeiro estado é o caminho. Um túnel e suas políticas tornam um conjunto de serviços alcançável, e um link sem tráfego pode permanecer pronto para a próxima requisição. Por quanto tempo ele fica pronto é uma decisão de implementação, não um temporizador universal.

O segundo estado é a permissão. Uma identidade ou dispositivo aceito pode estar autorizado a usar esse caminho. Essa autorização deve mudar quando um papel muda, um dispositivo desaparece ou se suspeita de comprometimento, e é independente de os pacotes estarem fluindo.

O terceiro estado é a sessão própria do aplicativo. Um cliente de banco de dados, uma área de trabalho remota ou um aplicativo web autentica-se separadamente e mantém seu próprio estado. Fechar o túnel não encerra necessariamente nada disso.

Uma revisão que trata esses pontos como uma única pergunta acaba discutindo temporizadores de inatividade. Os três podem estar saudáveis ou quebrados por conta própria, e uma constatação num deles diz pouco sobre os outros. Uma lista de verificação com três linhas vence um debate sobre um único valor de timeout. Escreva a resposta de cada estado separadamente.

O túnel é um caminho, não um distintivo

Um túnel estabelecido é evidência de que existe um caminho protegido entre dois endpoints. Não é evidência de que todo processo atrás de qualquer endpoint deva alcançar todo serviço do outro lado.

A orientação de zero trust do NIST faz o mesmo ponto pelo outro lado: a localização na rede não deve ser tratada como confiança implícita. Um link de site é um fato de transporte, e a permissão para um host usar um aplicativo é uma decisão separada, com dono próprio.

Um par comprometido ainda pode tentar ações nocivas por meio dos serviços que tem permissão de alcançar. Filtragem e monitoramento reduzem riscos específicos sem apagar as consequências do comprometimento do endpoint. Projete para o caminho e autorize para o serviço.

Justificar um link de site permanente

A versão defensável do sempre ativo nomeia seu propósito com precisão. Quais origens, quais destinos, qual direção e quem é dono de cada entrada. Um firewall de filial que permite a todo host da filial alcançar toda sub-rede central não manteve um link para um propósito nomeado; manteve-o para qualquer coisa que alguém pense depois.

Onde um par não consegue atingir o nível de confiança exigido, estreite a fronteira ou mude o arranjo. Depender de desconexão manual ocasional é um controle de processo, e controles de processo são menos confiáveis exatamente quando um incidente os torna inconvenientes.

Mantenha a justificativa junto da configuração. Uma exceção permanente com propósito escrito pode ser revisada e retirada. Uma sem propósito torna-se permanente por padrão.

Trocar chaves não é revogar

Substituir chaves conforme um cronograma mantém o ciclo de vida da proteção. Renova o material e preserva a confidencialidade. Não remove o direito de acesso de um endpoint.

Se o endpoint ainda tem credenciais válidas e uma política de acesso que o aceita, a próxima negociação restaura o mesmo caminho permitido. É por isso que dizer que as chaves giram a cada hora não é resposta para um dispositivo perdido: o dispositivo perdido também gira, enquanto sua identidade for confiável. Verifique o direito antes de verificar o cronograma. Rotação é higiene, e revogação é decisão de acesso.

Revogação é outro mecanismo, com latência própria: um certificado revogado, uma conta desativada, um grupo alterado, uma regra de rede removida. Cada um entra em vigor num ponto diferente e cada um se comporta de modo diferente para sessões já estabelecidas.

Encerrar o que já está em execução

Pergunte o que a implementação faz com sessões estabelecidas quando o acesso é removido. Ela pode encerrá-las, esperar a expiração ou aplicar algum comportamento documentado no meio. Não presuma que a mudança de admissão de amanhã fechará a conexão de aplicativo de hoje.

Para acesso interativo, coloque limites de sessão e regras de inatividade nas mãos dos donos de identidade e da VPN, e não apenas da equipe de rede. Para um serviço de site, defina o procedimento que a manutenção, uma indisponibilidade ou um incidente de segurança usa para desativar o acesso.

Depois teste três resultados: o trabalho permitido continua funcionando, um serviço não relacionado é negado e o procedimento de remoção produz o resultado documentado. Um projeto sempre ativo é aceitável quando propósito, autorização e capacidade de desligamento estão todos escritos e exercitados. Caso contrário, é uma comodidade que sobreviveu ao seu motivo.