Multi-tenant VPN: delt gateway, per tenant eller per host
En tunnel er ikke tenant-isolation. Sammenlign en delt gateway, gateways per tenant og forbindelser per host på identitetsmapping, routing og udfasning.
Beslut, hvem der lukker en kunde ind, og hvad der forhindrer den kunde i at nå en anden tenants ressourcer. Det er to beslutninger, og valget af IPsec, WireGuard eller et mesh-produkt besvarer ingen af dem. En tunnel, der kommer perfekt op, kan stadig efterlade hver tenant i stand til at nå alle de andre, og en gennemgang, der behandler de to som det samme, godkender det forkerte design. Skriv kunde-til-ressource-kortet først: administratorer, supportadgang, delte tjenester og de stier, der skal forblive afviste.
Start med kortet, ikke med produktet
Det kort er det første artefakt, og hvert valg nedenfor er kun en beslutning om, hvor grænsen, der håndhæver det, bor. Hold det gennemgåeligt: én række per kunde, én række per delt tjeneste og de afviste stier skrevet ud.
Et kort, ingen kan læse, er et kort, ingen vil håndhæve.
Ét adgangspunkt og dets mappingproblem
Hver placering afgøres af ét operationelt spørgsmål, og tabellen er hele sammenligningen.
| 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? |
En delt gateway centraliserer adgang og samler risikoen ét sted: koblingen mellem en tenants identitet og dens politik. Grupper eller tunneladresser skal opløses til de rigtige ressourcetilladelser, og en anden etiket per kunde forhindrer ikke noget i sig selv. Separate routingkontekster kan holde overlappende præfikser, når platformen understøtter det, og designet er komplet. En almindelig delt routingtabel kan ikke skelne to identiske destinationspræfikser, blot fordi folkene bag dem har forskellige konti.
Det er testen for de fleste designs. To tenants, der begge nummererer internt med 10.0.0.0/8, har brug for adskilt routingtilstand, ikke en navngivningskonvention.
En gateway per tenant køber grænser og systemer
Én gateway per kunde gør nogle administrative grænser nemme at forklare, fordi adgang og politik for den kunde ligger sammen. Den formerer også de systemer, der har brug for legitimationsoplysninger, patches, overvågning og en ejer. Og den påtvinger ikke én foreskrevet offentlig adresseordning: deling af endpoints, oversættelse og protokol-demultipleksing afhænger af, hvad implementeringen faktisk understøtter.
Tæl systemerne og menneskene, før du tæller sikkerhedsgevinsten. Et design med fire gateways mere, end teamet kan patche, er ikke mere isoleret i praksis.
Hvis tenantantallet ændrer sig hver måned, har den model brug for en automatiseringshistorie i stedet for en skabelon.
Forbindelser per host flytter arbejdet
En forbindelse på hver hostet maskine fjerner ikke det operationelle arbejde, den flytter det ind i maskinens livscyklus. Tilmelding, politik per maskine, nøglerotation og udskiftning bliver en del af provisioning, og de fejler i samme vindue som maskinen selv. For en håndfuld langlivede hosts på forskellige netværk er det ofte rigtigt, og for en flåde, der allerede har mistet overblikket over, hvilket image der kører hvor, sjældent.
Navngiv en rolle for identitetsudstedelse, opdateringer, fjernelse af adgang, overvågning og gendannelse under hver mulighed. Spørg derefter, hvad der sker den dag, en kunde forlader.
Udfasning hører til i sammenligningen
De fleste sammenligninger springer udfasning over. Fjernelse af en tenant bør ugyldiggøre dens legitimationsoplysninger, droppe dens politik, frigive dens adresser og routingtilstand og lade alle andre urørte. NISTs vejledning i nul-tillidsarkitektur er den rigtige reference her, fordi den placerer autentificering og autorisation på ressourcen i stedet for at stole på en netværksposition, og det gælder også inde i en kundes eget segment.
Afvej tilladte og afviste flows, håndtering af overlappende adresser og udfasningsproceduren, før du afvejer protokolbenchmarks. Vælg derefter en transport og autentificeringsmetode, der passer til den grænse, du valgte. Et ældre produktnavn eller en påstand om, at hver virksomhed skal standardisere på én protokol, afgør intet af det. Det kort, du skrev først, gør.