VPN multi-inquilino: gateway partilhado, por inquilino ou por anfitrião
Um túnel não é isolamento entre inquilinos. Compare um gateway partilhado, gateways por inquilino e ligações por anfitrião quanto ao mapeamento de identidades, encaminhamento e retirada.
Decida quem admite um cliente e o que impede esse cliente de chegar aos recursos de outro inquilino. São duas decisões, e escolher IPsec, WireGuard ou um produto mesh não responde a nenhuma delas. Um túnel que sobe perfeitamente pode ainda deixar cada inquilino capaz de chegar a todos os outros, e uma revisão que trata as duas coisas como a mesma aprova o desenho errado. Escreva primeiro o mapa de cliente para recurso: administradores, acesso de suporte, serviços partilhados e os caminhos que têm de ficar negados.
Comece pelo mapa, não pelo produto
Esse mapa é o primeiro artefacto, e cada escolha abaixo é apenas uma decisão sobre onde vive a fronteira que a aplica. Mantenha-o revisível: uma linha por cliente, uma linha por serviço partilhado e os caminhos negados escritos.
Um mapa que ninguém consegue ler é um mapa que ninguém vai aplicar.
Um único ponto de admissão e o seu problema de mapeamento
Cada colocação decide-se com uma única pergunta operacional, e a tabela é toda a comparação.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
Um gateway partilhado centraliza a admissão e concentra o risco num só lugar: a associação entre a identidade de um inquilino e a sua política. Os grupos ou os endereços de túnel têm de resolver nas permissões de recurso corretas, e um rótulo diferente por cliente não impede nada por si só. Contextos de encaminhamento separados podem conter prefixos sobrepostos quando a plataforma o suporta e o desenho está completo. Uma tabela de encaminhamento partilhada simples não distingue dois prefixos de destino idênticos só porque as pessoas por trás têm contas diferentes.
É o teste para a maioria dos desenhos. Dois inquilinos que numeram internamente com 10.0.0.0/8 precisam de estado de encaminhamento separado, não de uma convenção de nomes.
Um gateway por inquilino compra fronteiras e sistemas
Um gateway por cliente torna algumas fronteiras administrativas fáceis de explicar, porque a admissão e a política desse cliente ficam juntas. Também multiplica os sistemas que precisam de credenciais, correções, monitorização e um responsável. E não impõe uma única disposição prescrita de endereços públicos: a partilha de pontos finais, a tradução e a desmultiplexagem de protocolos dependem do que a implementação suporta na realidade.
Conte os sistemas e as pessoas antes de contar o ganho de segurança. Um desenho com quatro gateways a mais do que a equipa consegue corrigir não é mais isolado na prática.
Se o número de inquilinos muda todos os meses, esse modelo precisa de uma história de automatização e não de um modelo de ficheiro.
As ligações por anfitrião movem o trabalho
Uma ligação em cada máquina alojada não elimina o trabalho operacional, desloca-o para o ciclo de vida da máquina. O registo, a política por máquina, a rotação de chaves e a substituição passam a fazer parte do aprovisionamento, e falham na mesma janela da própria máquina. Para um punhado de anfitriões duradouros em redes distintas costuma ser correto, e para uma frota que já perdeu o rasto de que imagem corre onde raramente é.
Nomeie um papel para a emissão de identidade, as atualizações, a remoção de acesso, a monitorização e a recuperação em cada opção. Depois pergunte o que acontece no dia em que um cliente sai.
A retirada pertence à comparação
A maioria das comparações ignora a retirada. Remover um inquilino deve invalidar as suas credenciais, largar a sua política, libertar os seus endereços e estado de encaminhamento e deixar todos os outros intactos. As orientações de arquitetura de confiança zero do NIST são a referência certa aqui, porque colocam a autenticação e a autorização no recurso em vez de confiar numa posição de rede, e isso aplica-se também dentro do próprio segmento de um cliente.
Pese os fluxos permitidos e negados, o tratamento de endereços sobrepostos e o procedimento de retirada antes de pesar as referências de protocolo. Depois escolha um transporte e um método de autenticação que sirvam a fronteira que escolheu. Um nome de produto mais antigo, ou a alegação de que todas as empresas devem normalizar-se num só protocolo, não resolve nada disso. O mapa que escreveu primeiro resolve.