Multi-tenant VPN: gedeelde gateway, per tenant of per host
Een tunnel is geen tenant-isolatie. Vergelijk een gedeelde gateway, gateways per tenant en verbindingen per host op identiteitstoewijzing, routing en uitfasering.
Bepaal wie een klant toelaat en wat die klant verhindert de resources van een andere tenant te bereiken. Dat zijn twee beslissingen, en de keuze voor IPsec, WireGuard of een mesh-product beantwoordt geen van beide. Een tunnel die perfect opkomt, kan nog steeds elke tenant in staat stellen elke andere te bereiken, en een review die de twee als hetzelfde behandelt, keurt het verkeerde ontwerp goed. Schrijf eerst de klant-naar-resource-kaart: beheerders, supporttoegang, gedeelde diensten en de paden die geweigerd moeten blijven.
Begin bij de kaart, niet bij het product
Die kaart is het eerste artefact, en elke keuze hieronder is alleen een beslissing over waar de grens ligt die hem afdwingt. Houd hem reviewbaar: één rij per klant, één rij per gedeelde dienst en de geweigerde paden uitgeschreven.
Een kaart die niemand kan lezen is een kaart die niemand zal afdwingen.
Eén toegangspunt en zijn toewijzingsprobleem
Elke plaatsing wordt beslist door één operationele vraag, en de tabel is de hele vergelijking.
| 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? |
Een gedeelde gateway centraliseert de toelating en concentreert het risico op één plek: de koppeling tussen de identiteit van een tenant en zijn beleid. Groepen of tunneladressen moeten naar de juiste resourcemachtigingen herleiden, en een ander label per klant voorkomt op zichzelf niets. Aparte routingcontexten kunnen overlappende prefixen bevatten wanneer het platform dat ondersteunt en het ontwerp compleet is. Een gewone gedeelde routingtabel kan twee identieke bestemmingsprefixen niet onderscheiden, alleen omdat de mensen erachter verschillende accounts hebben.
Dat is de test voor de meeste ontwerpen. Twee tenants die beide intern nummeren met 10.0.0.0/8 hebben gescheiden routingstatus nodig, geen naamconventie.
Een gateway per tenant koopt grenzen en systemen
Eén gateway per klant maakt sommige administratieve grenzen makkelijk uit te leggen, omdat toelating en beleid voor die klant bij elkaar zitten. Het vermenigvuldigt ook de systemen die inloggegevens, patches, monitoring en een eigenaar nodig hebben. En het dwingt geen één voorgeschreven indeling van openbare adressen af: het delen van eindpunten, vertaling en protocol-demultiplexing hangen af van wat de implementatie echt ondersteunt.
Tel de systemen en de mensen voordat je de veiligheidswinst telt. Een ontwerp met vier gateways meer dan het team kan patchen is in de praktijk niet geïsoleerder.
Als het aantal tenants elke maand beweegt, heeft dat model een automatiseringsverhaal nodig in plaats van een sjabloon.
Verbindingen per host verplaatsen het werk
Een verbinding op elke gehoste machine haalt het operationele werk niet weg, het verplaatst het naar de levenscyclus van de machine. Inschrijving, beleid per machine, sleutelrotatie en vervanging worden onderdeel van provisioning, en ze falen in hetzelfde venster als de machine zelf. Voor een handvol langlevende hosts op verschillende netwerken is dat vaak goed, en voor een vloot die al het spoor kwijt is van welke image waar draait, zelden.
Benoem een rol voor identiteitsuitgifte, updates, het intrekken van toegang, monitoring en herstel onder elke optie. Vraag dan wat er gebeurt op de dag dat één klant vertrekt.
Uitfasering hoort in de vergelijking
De meeste vergelijkingen slaan uitfasering over. Het verwijderen van een tenant moet zijn inloggegevens ongeldig maken, zijn beleid laten vallen, zijn adressen en routingstatus vrijgeven en alle anderen ongemoeid laten. De zero-trust-architectuurrichtlijn van NIST is hier de juiste referentie, omdat die authenticatie en autorisatie op de resource legt in plaats van op een netwerkpositie te vertrouwen, en dat geldt ook binnen het eigen segment van een klant.
Weeg toegestane en geweigerde stromen, de omgang met overlappende adressen en de uitfaseringsprocedure voordat je protocolbenchmarks weegt. Kies dan een transport en authenticatiemethode die passen bij de grens die je koos. Een oudere productnaam, of de bewering dat elk bedrijf op één protocol moet standaardiseren, beslist niets daarvan. De kaart die u eerst schreef, doet dat.