VPN multi-locataires : passerelle partagée, par locataire ou par hôte
Un tunnel n’est pas une isolation entre locataires. Comparez une passerelle partagée, des passerelles par locataire et des connexions par hôte sur le mappage des identités, le routage et le retrait.
Décidez qui admet un client et ce qui empêche ce client d’atteindre les ressources d’un autre locataire. Ce sont deux décisions, et choisir IPsec, WireGuard ou un produit mesh ne répond à aucune des deux. Un tunnel qui monte parfaitement peut encore laisser chaque locataire joindre tous les autres, et une revue qui traite les deux comme une seule chose approuve la mauvaise conception. Écrivez d’abord la carte client-vers-ressource : administrateurs, accès du support, services partagés et les chemins qui doivent rester refusés.
Commencez par la carte, pas par le produit
Cette carte est le premier artefact, et chaque choix ci-dessous n’est qu’une décision sur l’endroit où vit la frontière qui l’applique. Gardez-la relisible : une ligne par client, une ligne par service partagé et les chemins refusés écrits noir sur blanc.
Une carte que personne ne peut lire est une carte que personne n’appliquera.
Un seul point d’admission et son problème de mappage
Chaque emplacement se décide sur une seule question opérationnelle, et le tableau est toute la comparaison.
| 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? |
Une passerelle partagée centralise l’admission et concentre le risque en un seul endroit : l’association entre l’identité d’un locataire et sa politique. Les groupes ou les adresses de tunnel doivent se résoudre en droits d’accès aux ressources corrects, et une étiquette différente par client n’empêche rien en soi. Des contextes de routage séparés peuvent contenir des préfixes qui se chevauchent lorsque la plateforme le permet et que la conception est complète. Une simple table de routage partagée ne peut pas distinguer deux préfixes de destination identiques simplement parce que les personnes derrière ont des comptes différents.
C’est le test de la plupart des conceptions. Deux locataires qui numérotent en interne avec 10.0.0.0/8 ont besoin d’un état de routage séparé, pas d’une convention de nommage.
Une passerelle par locataire achète des frontières et des systèmes
Une passerelle par client rend certaines frontières administratives faciles à expliquer, parce que l’admission et la politique de ce client vont ensemble. Elle multiplie aussi les systèmes qui ont besoin d’identifiants, de correctifs, de supervision et d’un propriétaire. Et elle n’impose pas un agencement unique d’adresses publiques : le partage de points de terminaison, la traduction et le démultiplexage de protocoles dépendent de ce que l’implémentation prend réellement en charge.
Comptez les systèmes et les personnes avant de compter le gain de sécurité. Une conception avec quatre passerelles de plus que ce que l’équipe peut corriger n’est pas plus isolée en pratique.
Si le nombre de locataires bouge chaque mois, ce modèle a besoin d’une histoire d’automatisation plutôt que d’un gabarit.
Les connexions par hôte déplacent le travail
Une connexion sur chaque machine hébergée ne supprime pas le travail d’exploitation, elle le déplace dans le cycle de vie de la machine. L’enrôlement, la politique par machine, la rotation des clés et le remplacement font partie du provisionnement, et ils échouent dans la même fenêtre que la machine elle-même. Pour une poignée d’hôtes de longue durée sur des réseaux distincts, c’est souvent juste, et pour un parc qui a déjà perdu la trace de quelle image tourne où, rarement.
Nommez un rôle pour l’émission d’identité, les mises à jour, le retrait d’accès, la supervision et la reprise dans chaque option. Demandez ensuite ce qui se passe le jour où un client s’en va.
Le retrait fait partie de la comparaison
La plupart des comparaisons sautent le retrait. Retirer un locataire devrait invalider ses identifiants, abandonner sa politique, libérer ses adresses et son état de routage et laisser tous les autres intacts. Les recommandations d’architecture zéro confiance du NIST sont la bonne référence ici, car elles placent l’authentification et l’autorisation sur la ressource au lieu de faire confiance à une position réseau, et cela vaut aussi à l’intérieur du segment propre d’un client.
Pesez les flux autorisés et refusés, le traitement des adresses qui se chevauchent et la procédure de retrait avant de peser les repères de protocole. Choisissez ensuite un transport et une méthode d’authentification adaptés à la frontière retenue. Un nom de produit plus ancien, ou l’affirmation que chaque entreprise doit se standardiser sur un seul protocole, ne tranche rien de tout cela. La carte que vous avez écrite en premier le fait.