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.

GateIdentity it checksDestinations it permitsHow it could be skippedWhen it is removed
Outer gatewayEmployee account plus a managed device postureGeneral internal services and the inner gateway's listenerAny alternate path to the same destinations, including a public listenerOrdinary work stops and the inner stage becomes unreachable
Inner gatewayA maintenance entitlement or role claim on that identityThe named management addresses in the change recordDirect routes from the outer domain to those addressesMaintenance 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.

Artigos relacionados