Mandantenfähiges VPN: gemeinsames Gateway, pro Mandant oder pro Host
Ein Tunnel ist keine Mandantentrennung. Vergleichen Sie ein gemeinsames Gateway, Gateways pro Mandant und Verbindungen pro Host bei Identitätszuordnung, Routing und Außerbetriebnahme.
Entscheiden Sie, wer einen Kunden zulässt und was diesen Kunden daran hindert, die Ressourcen eines anderen Mandanten zu erreichen. Das sind zwei Entscheidungen, und die Wahl von IPsec, WireGuard oder einem Mesh-Produkt beantwortet keine von beiden. Ein Tunnel, der einwandfrei zustande kommt, kann immer noch jedem Mandanten Zugriff auf jeden anderen lassen, und eine Prüfung, die beides als dasselbe behandelt, genehmigt das falsche Design. Schreiben Sie zuerst die Kunde-zu-Ressource-Zuordnung: Administratoren, Supportzugang, gemeinsame Dienste und die Pfade, die gesperrt bleiben müssen.
Beginnen Sie mit der Zuordnung, nicht mit dem Produkt
Diese Zuordnung ist das erste Artefakt, und jede Wahl unten ist nur eine Entscheidung darüber, wo die Grenze liegt, die sie durchsetzt. Halten Sie sie prüfbar: eine Zeile pro Kunde, eine Zeile pro gemeinsamem Dienst und die gesperrten Pfade ausgeschrieben.
Eine Zuordnung, die niemand lesen kann, ist eine Zuordnung, die niemand durchsetzen wird.
Ein Zulassungspunkt und sein Zuordnungsproblem
Jede Platzierung entscheidet sich an einer einzigen betrieblichen Frage, und die Tabelle ist der ganze Vergleich.
| 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? |
Ein gemeinsames Gateway zentralisiert die Zulassung und bündelt das Risiko an einer Stelle: der Verknüpfung zwischen der Identität eines Mandanten und seiner Richtlinie. Gruppen oder Tunneladressen müssen zu den richtigen Ressourcenberechtigungen aufgelöst werden, und ein anderes Etikett pro Kunde verhindert für sich genommen nichts. Getrennte Routingkontexte können überlappende Präfixe halten, wenn die Plattform das unterstützt und das Design vollständig ist. Eine einfache gemeinsame Routingtabelle kann zwei identische Zielpräfixe nicht auseinanderhalten, nur weil die Menschen dahinter verschiedene Konten haben.
Das ist der Test für die meisten Designs. Zwei Mandanten, die intern beide mit 10.0.0.0/8 nummerieren, brauchen getrennten Routingzustand, keine Namenskonvention.
Ein Gateway pro Mandant kauft Grenzen und Systeme
Ein Gateway pro Kunde macht manche administrativen Grenzen leicht erklärbar, weil Zulassung und Richtlinie für diesen Kunden zusammen liegen. Es vervielfacht aber auch die Systeme, die Zugangsdaten, Patches, Überwachung und einen Eigentümer brauchen. Und es erzwingt keine einzige vorgeschriebene Anordnung öffentlicher Adressen: Endpunktfreigabe, Übersetzung und Protokoll-Demultiplexing hängen davon ab, was die Implementierung tatsächlich unterstützt.
Zählen Sie die Systeme und die Menschen, bevor Sie den Sicherheitsgewinn zählen. Ein Design mit vier Gateways mehr, als das Team patchen kann, ist in der Praxis nicht isolierter.
Wenn sich die Mandantenzahl jeden Monat ändert, braucht dieses Modell eine Automatisierungsgeschichte statt einer Vorlage.
Verbindungen pro Host verschieben die Arbeit
Eine Verbindung auf jeder gehosteten Maschine beseitigt die Betriebsarbeit nicht, sie verlagert sie in den Lebenszyklus der Maschine. Registrierung, Richtlinie pro Maschine, Schlüsselrotation und Austausch werden Teil der Bereitstellung, und sie scheitern im selben Fenster wie die Maschine selbst. Für eine Handvoll langlebiger Hosts in getrennten Netzen ist das oft richtig, und für einen Fuhrpark, der längst den Überblick verloren hat, welches Image wo läuft, selten.
Benennen Sie eine Rolle für Identitätsausgabe, Updates, Zugriffsentzug, Überwachung und Wiederherstellung unter jeder Option. Fragen Sie dann, was am Tag passiert, an dem ein Kunde geht.
Die Außerbetriebnahme gehört in den Vergleich
Die meisten Vergleiche überspringen die Außerbetriebnahme. Das Entfernen eines Mandanten sollte seine Zugangsdaten ungültig machen, seine Richtlinie fallen lassen, seine Adressen und seinen Routingzustand freigeben und alle anderen unberührt lassen. Die Zero-Trust-Architekturleitlinie von NIST ist hier die richtige Referenz, weil sie Authentifizierung und Autorisierung auf die Ressource legt, statt einer Netzposition zu vertrauen, und das gilt auch innerhalb des eigenen Segments eines Kunden.
Wägen Sie erlaubte und gesperrte Flüsse, den Umgang mit überlappenden Adressen und das Außerbetriebnahmeverfahren ab, bevor Sie Protokollbenchmarks abwägen. Wählen Sie dann ein Transport- und Authentifizierungsverfahren, das zur gewählten Grenze passt. Ein älterer Produktname oder die Behauptung, jedes Unternehmen müsse sich auf ein Protokoll standardisieren, entscheidet nichts davon. Die Zuordnung, die Sie zuerst geschrieben haben, entscheidet es.