Duas portas VPN em série: o que cada uma realmente decide
Dois estágios de VPN em série deveriam significar duas decisões de permissão separadas. Nomeie o que cada porta verifica e depois teste o que a interna nega.
Encadear duas VPNs costuma ser vendido como criptografia extra, que é a coisa menos interessante que faz. O produto real é uma segunda decisão de autorização, tomada por outro proprietário sobre outro conjunto de recursos. Se os dois estágios aceitam a mesma credencial e alcançam os mesmos destinos, a porta interna é decoração com latência extra. Decidir se essa segunda decisão vale o seu custo operacional começa por nomear o que cada porta realmente verifica.
Um túnel, depois uma segunda decisão
A porta externa responde a uma pergunta ampla: este é um dispositivo de funcionário aprovado e pode alcançar a rede interna geral. A porta interna responde a uma mais estreita: esta identidade carrega o direito de manutenção e pode alcançar estes pontos finais de gestão específicos. São perguntas diferentes com proprietários diferentes, e nenhuma implica a outra. A existência de um caminho pelos dois estágios não é autoridade para usar o que está atrás do segundo. Chegar à entrada distante prova que uma rota funciona, e nada mais.
O princípio é antigo e ainda é ignorado: a localização na rede não argumenta nada por si só. Resumo da arquitetura de confiança zero do NIST diz isso claramente, rejeitando a confiança implícita que decorre de onde veio uma conexão ou de quem é dono da rede. Aplicado aqui, chegar à entrada interna é um pré-requisito para os seus recursos, nunca a permissão para usá-los.
Anote o que cada porta verifica
Para cada estágio, registe a identidade que verifica, os destinos que permite e as condições em que pode ser ignorado. A porta externa pode legitimamente permitir serviços internos comuns mais o ouvinte da porta interna, e nada mais. A porta interna pode exigir uma reivindicação de função e permitir apenas os endereços de gestão nomeados no registo de alterações. A aplicação no extremo distante mantém a última palavra sobre que operações essa função pode executar, pelo que a cadeia acrescenta uma porta sem substituir a autorização da aplicação.
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
Duas omissões quebram o desenho em silêncio. Se o domínio externo já alcança diretamente cada destino sensível, a porta interna é opcional em vez de obrigatória. Se um ouvinte público ou uma segunda rota privada oferece o mesmo acesso, o caminho previsto é uma opção entre várias. Atribua também um proprietário a cada conjunto de regras, e faça o contrato deles nomear os serviços de destino, as identidades de origem permitidas, o DNS privado, a tradução de endereços e quem responde quando a entrega falha. Um endereço de confiança na rede externa nunca deve substituir a autorização do domínio interno.
Teste os casos de negação, não o caminho feliz
Uma ligação bem-sucedida pelas duas portas prova muito pouco, porque é o caso que todos testaram durante a implementação. Os casos interessantes são aqueles em que um estágio passa e o outro recusa. Três deles cobrem a maior parte do risco, e cada um tem um resultado esperado que pode ser verificado em vez de discutido.
Com o acesso geral aprovado e a função sensível ausente, o trabalho comum deve continuar enquanto o destino sensível é negado. Aprove os dois estágios e o conjunto alcançável deve ser os pontos finais de manutenção nomeados no registo de alterações, nada mais amplo. Com o direito revogado a meio da sessão, a política de sessão acordada deve entrar em vigor sem desmontar o acesso geral não relacionado. Se essa revogação termina uma sessão existente imediatamente ou na próxima reautenticação é uma decisão de política que o contrato já deveria conter. Quem escreveu os casos de aceitação não é a pessoa que os deveria interpretar durante um incidente.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"
Conte as dependências que acrescentou
Cada estágio extra acrescenta um componente que pode falhar e uma rota que deve aninhar-se corretamente dentro do túnel externo. Durante uma falha parcial, o caminho externo mantém-se de pé enquanto o interno está inalcançável, pelo que o utilizador vê um ícone de VPN saudável ao lado de um serviço que nunca responde.
Verifique as rotas e as regras de bloqueio em caso de falha, não apenas no caso normal. Uma rota predefinida empurrada pelo túnel externo pode capturar o endereço da própria porta interna, o que transforma o segundo estágio numa ligação que se estabelece e depois cai. Registe o que deve permanecer bloqueado enquanto o túnel interno não existe, porque um retrocesso acidental à sua volta é pior do que uma interrupção limpa. Use a mesma forma de sonda nos dois saltos, para que cada um seja medido em vez de presumido. Dois indicadores de ligação não estabelecem nem aninhamento nem isolamento.
O que a segunda porta não lhe pode comprar
Pergunte se as duas portas partilham uma credencial, uma autoridade de certificação ou um plano de gestão. Onde o fazem, partilham também os seus modos de falha mais importantes, e o segundo estágio custa mais do que a independência que parece acrescentar. Sessões criptográficas separadas não criam controlos administrativos separados.
Mantenha a porta interna enquanto impuser um requisito que possa enunciar e testar, como uma função que o domínio externo nunca verifica. Remova-a quando a sua única tarefa for reautenticar a mesma identidade contra os mesmos destinos. De qualquer forma, registe o requisito, o proprietário e o comportamento em caso de falha juntos, para que a próxima revisão discuta o requisito e não o diagrama.