Ainda precisa de uma VPN de site quando a aplicação usa mTLS e SSO?
Percorra os canais que o início de sessão da aplicação nunca cobre e decida depois se o acesso à rede privada é redundante ou continua a ser o único caminho até ao anfitrião.
Inicia sessão por mTLS, o painel carrega, e a afirmação de que a VPN de site já é redundante soa razoável mais ou menos o tempo que leva até precisar de restaurar uma base de dados às duas da manhã. A fronteira TLS da aplicação descreve um único canal. O anfitrião, a base de dados, o destino das cópias de segurança e a conta na nuvem levam cada um o seu próprio caminho de entrada, a sua própria identidade e o seu próprio aprovador, e nenhum deles é exercitado por um início de sessão bem-sucedido.
Caminhe para fora a partir do ecrã de início de sessão
Inicie sessão como um utilizador comum e anote cada salto que o pedido toca: navegador, periferia, ouvinte da aplicação, armazém de sessões, API de backend. Cada salto tem um proprietário e uma decisão de autenticação. Agora repita o percurso para a pessoa que aplica correções no anfitrião e para a tarefa que escreve a cópia de segurança noturna. Esses percursos costumam divergir logo no primeiro salto.
Essa divergência é a pergunta que vale a pena responder. Uma VPN de site só é redundante quando cada canal desse segundo percurso tem uma política de entrada e autorização que se sustenta sozinha.
Cinco canais que o início de sessão da aplicação nunca cobre
A tabela abaixo é um modelo de inventário, não uma lista de verificação de implementação. Preencha a segunda coluna com o que o seu próprio ambiente aplica realmente hoje.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Partilhar um fornecedor de identidade não funde estas autorizações. Um utilizador que pode enviar um pedido de API não fica por isso autorizado a substituir um disco de máquina virtual nem a restaurar uma base de dados com as credenciais da aplicação. O NIST, no resumo da arquitetura de confiança zero, mantém a autenticação e a autorização dos recursos separadas da localização de rede exatamente por este motivo.
Um engenheiro de suporte que consegue ler um ticket não fica por isso autorizado a abrir uma consola no anfitrião que está por trás.
Um caminho só é real se a alternativa permanecer fechada
Restringir a acessibilidade a ouvintes administrativos privados é uma substituição legítima de uma VPN de site, desde que a restrição seja aplicada e não apenas desenhada. A falha habitual é um ouvinte alternativo de que ninguém se lembrou: um serviço ainda ligado a todas as interfaces, uma regra de grupo de segurança aberta para um empreiteiro, uma porta de gestão acessível a partir da internet.
Verifique ouvintes, não diagramas. No anfitrião, liste o que está realmente ligado com ss -ltnp e confirme que as portas administrativas estão num endereço privado. Na consola da nuvem, leia as regras de entrada da sub-rede de carga de trabalho e procure 0.0.0.0/0 em qualquer coisa administrativa. Depois experimente a ligação a partir de fora do caminho privado, porque é esse teste que responde à pergunta.
Uma única regra aberta ao mundo no SSH anula todos os argumentos que o desenho do túnel apresentou.
Escreva o mapa antes de comparar desenhos
Para cada linha do inventário, registe quem aprova identidades, quem atualiza as regras de acesso, quem remove credenciais quando alguém sai e quem trata da recuperação quando o próprio caminho se rompe. Quatro nomes por linha bastam para expor as linhas em que a resposta é uma conta partilhada e uma página de wiki com três anos.
Depois valide uma permissão e uma negação por canal. Uma permissão prova que a identidade prevista consegue chegar ao recurso pelo caminho previsto. Uma negação prova que uma identidade semelhante não consegue, e é este o teste que as pessoas saltam, e por isso os ouvintes alternativos sobrevivem às auditorias. Compare o desenho proposto com estes resultados, não com a configuração TLS da aplicação, que nunca exercitou nenhum deles.
Onde uma VPN de site ainda ganha o seu lugar
Um túnel ou uma porta estreita é a resposta certa quando um recurso não tem autenticação própria por pedido: portas de manutenção de bases de dados, destinos de cópias de segurança, consolas de hipervisor, gestão fora de banda. Esses ouvintes confiam na rede, por isso a rede tem de ser o que autentica o chamador.
Não é a única resposta. Uma porta que termina a autorização por recurso pode ser mais estreita do que um túnel de toda a sub-rede e deixa um rasto de auditoria melhor do que um anfitrião de salto partilhado.
Ordem do trabalho: complete o inventário, feche as alternativas, valide uma negação por linha e só então retire o túnel. Se uma linha não conseguir produzir uma negação, mantenha o caminho privado até conseguir.