VPN multiinquilino: pasarela compartida, por inquilino ou por host
Un túnel non é illamento entre inquilinos. Compare unha pasarela compartida, pasarelas por inquilino e conexións por host en canto a asignación de identidades, encamiñamento e retirada.
Decida quen admite un cliente e que impide que ese cliente acade os recursos doutro inquilino. Son dúas decisións, e escoller IPsec, WireGuard ou un produto mesh non responde a ningunha. Un túnel que se ergue perfectamente pode deixar igualmente cada inquilino capaz de acadar todos os demais, e unha revisión que trata as dúas cousas como a mesma aproba o deseño equivocado. Escriba primeiro o mapa de cliente a recurso: administradores, acceso de soporte, servizos compartidos e as rutas que deben seguir denegadas.
Comece polo mapa, non polo produto
Ese mapa é o primeiro artefacto, e cada opción de abaixo só é unha decisión sobre onde vive a fronteira que o aplica. Mantéñao revisable: unha fila por cliente, unha fila por servizo compartido e as rutas denegadas escritas.
Un mapa que ninguén pode ler é un mapa que ninguén aplicará.
Un único punto de admisión e o seu problema de asignación
Cada emprazamento decídese cunha soa pregunta operativa, e a táboa é toda a comparación.
| 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? |
Unha pasarela compartida centraliza a admisión e concentra o risco nun só lugar: a asociación entre a identidade dun inquilino e a súa política. Os grupos ou os enderezos de túnel deben resolverse nos permisos de recurso correctos, e unha etiqueta distinta por cliente non impide nada por si soa. Os contextos de encamiñamento separados poden manter prefixos solapados cando a plataforma o admite e o deseño está completo. Unha táboa de encamiñamento compartida simple non pode distinguir dous prefixos de destino idénticos só porque as persoas detrás teñan contas distintas.
Esa é a proba para a maioría dos deseños. Dous inquilinos que numeran internamente con 10.0.0.0/8 necesitan estado de encamiñamento separado, non unha convención de nomes.
Unha pasarela por inquilino compra fronteiras e sistemas
Unha pasarela por cliente fai fáciles de explicar algunhas fronteiras administrativas, porque a admisión e a política dese cliente están xuntas. Tamén multiplica os sistemas que necesitan credenciais, parches, monitorización e un propietario. E non impón unha única disposición prescrita de enderezos públicos: compartir extremos, a tradución e o desmultiplexado de protocolos dependen do que a implementación admita de verdade.
Conte os sistemas e as persoas antes de contar a ganancia de seguridade. Un deseño con catro pasarelas máis das que o equipo pode parchear non é máis illado na práctica.
Se o número de inquilinos se move cada mes, ese modelo necesita un relato de automatización e non unha plantilla.
As conexións por host moven o traballo
Unha conexión en cada máquina aloxada non elimina o traballo operativo, trasládao ao ciclo de vida da máquina. A alta, a política por máquina, a rotación de claves e a substitución pasan a formar parte do aprovisionamento, e fallan dentro da mesma xanela que a propia máquina. Para un feixe de hosts lonxevos en redes distintas adoita ser correcto, e para unha frota que xa perdeu a conta de que imaxe corre onde rara vez o é.
Nomee un rol para a emisión de identidade, as actualizacións, a retirada de acceso, a monitorización e a recuperación en cada opción. Despois pregunte que ocorre o día en que un cliente marcha.
A retirada pertence á comparación
A maioría das comparacións omiten a retirada. Quitar un inquilino debe invalidar as súas credenciais, descartar a súa política, liberar os seus enderezos e o seu estado de encamiñamento e deixar intactos a todos os demais. A guía de arquitectura de confianza cero de NIST é a referencia correcta aquí, porque pon a autenticación e a autorización no recurso en lugar de confiar nunha posición de rede, e iso tamén se aplica dentro do propio segmento dun cliente.
Pese os fluxos permitidos e denegados, o tratamento de enderezos solapados e o procedemento de retirada antes de pesar os referentes de protocolo. Despois escolla un transporte e un método de autenticación que encaixen coa fronteira elixida. Un nome de produto máis antigo, ou a afirmación de que cada empresa debe estandarizarse nun só protocolo, non resolve nada deso. O mapa que escribiu primeiro faino.