Der häufigste Rat in der Debatte single tenant vs multi tenant ist auch der am wenigsten nützliche: Single Tenant ist sicher, Multi Tenant ist günstig, und die Entscheidung endet bei einer einfachen Beschaffungsmatrix. Diese Denkweise greift in Gebäuden zu kurz, in denen das Netzwerkdesign die größten kommerziellen Auswirkungen hat.
In einem Hotel, einer Studentenresidenz, einem Build-to-Rent-Block, einem Krankenhauscampus oder einem flexiblen Arbeitsbereich lautet die entscheidende Frage: Wer kontrolliert die Netzwerkgrenze? Eine dedizierte Plattform kann bei schlechten Richtlinien immer noch Datenverkehr durchlassen. Eine gemeinsam genutzte physische Infrastruktur kann jeden Mandanten schützen, wenn Identität, Authentifizierung, Routing und Widerruf richtig konzipiert sind. Die Anzahl der Mandanten ist nur die Bezeichnung. Die Grenzkontrolle ist die Architektur.
Wohnungsmarktdaten aus Großbritannien machen es unmöglich, diese Unterscheidung zu ignorieren. Eine Regierungsanalyse identifizierte 459.262 Wohnanlagen, die als gemischt genutzte Wohnformen („mixed tenure“) gelten oder gelten könnten. Diese umfassen 3,33 Millionen Sozialwohnungen, was 79 % der 4,21 Millionen Sozialwohnungen in den offiziellen Wohnungsstatistiken entspricht. Dennoch lag der durchschnittliche Anteil an Sozialmietern bei 80 %, während der Median bei 97 % lag. Dies zeigt, dass Wohnanlagen zwar verschiedene Nutzungsformen aufweisen können, aber meist stark auf eine Belegungsart konzentriert sind. Speziell errichtete Mehrfamilienhäuser machten 54 % der identifizierten Wohnanlagen mit mehreren Wohneinheiten aus, mit einem Median des Sozialmieteranteils von 91 %, verglichen mit 50 % bei umgebauten Wohnungen. Die Gebäudeform verändert das Problem der Betriebsgrenzen, nicht nur der Mietvertrag. (Regierungsanalyse der britischen Regierung zu gemischten Wohnformen im englischen sozialen Wohnungsbau)
Warum die Frage Single Tenant vs Multi Tenant größer ist als SaaS
Enterprise-Teams übernehmen diese Diskussion oft aus der SaaS-Beschaffung. Sie vergleichen dedizierte Instanzen mit einer gemeinsam genutzten Anwendungsinfrastruktur und nehmen an, dass dieselbe Schlussfolgerung für ein physisches Gebäude gilt. Das tut sie nicht. In gemeinsam genutzten Immobilien ist die wichtigere Frage, ob der Betreiber einen Bewohner, Gast, eine Abteilung oder einen Auftragnehmer innerhalb der korrekten Zugangs- und Richtliniengrenzen halten kann.
Eine Single-Tenant-Bereitstellung bietet Ingenieuren in der Regel eine sauberere physische Trennung. Das hilft beim Audit-Umfang, bei der Änderungskontrolle und bei der Schadenseindämmung. Betriebsrisiken werden dadurch nicht beseitigt. Ein schlecht gepatchter Controller, schwache Administrator-Anmeldedaten, eine falsch konfigurierte Firewall-Regel oder ein schlecht abgegrenzter Authentifizierungsdienst können eine dedizierte Umgebung genauso effektiv gefährden wie eine gemeinsam genutzte.
Multi-Tenant-Networking schafft eine andere Verantwortung. Der Betreiber teilt sich Access Points, Switches, Controller, Uplinks und oft auch die Verwaltungsebene und nutzt dann logische Kontrollen, um Benutzer zu trennen. Diese Kontrollen müssen über die Ebenen Wireless, Authentifizierung, Routing, DNS, Überwachung und Support hinweg funktionieren. Ein Mandant ist nicht allein deshalb isoliert, weil er eine andere SSID oder Captive Portal besitzt.
Die praktische Grenze ist nicht die SSID. Es ist die vollständige Kette von der Identität über die Autorisierung, die Weiterleitung des Datenverkehrs, die Telemetrie bis hin zum Entzug von Berechtigungen.
Drei Grenzen, die es zu testen gilt
Betrachten Sie die Architektur als drei separate Fragen:
- Physische Grenze: Welche Access Points, Switches, Controller, Leitungen und Geräte werden gemeinsam genutzt?
- Identitätsgrenze: Wie erkennt das Netzwerk, welche Person, welches Gerät, welcher Raum, welche Abteilung oder welches Unternehmen eine Verbindung herstellt?
- Verwaltungsgrenze: Wer kann Anmeldedaten erstellen, Richtlinien ändern, Telemetriedaten einsehen, Zugriffe genehmigen und diese widerrufen?
Dieser Ansatz ist in Hospitality- und Wohnnetzwerken von Bedeutung, da es den Nutzern egal ist, ob der Anbieter das Design als Cloud-Native, geteilt oder dediziert bezeichnet. Sie erwarten, dass sich ihre Geräte problemlos verbinden und die Geräte ihrer Nachbarn getrennt bleiben. Mitarbeiter erwarten, dass der Zugriff erlischt, wenn ihr Directory-Konto deaktiviert wird. Betreiber erwarten einen einzigen Support-Workflow anstelle einer separaten Infrastruktur für jedes Zimmer oder jeden Bewohner.
Die britische Brandschutzpolitik bietet eine nützliche Parallele. Der Fire Safety Act 2021 stellte klar, dass die Brandschutzverordnung für die Struktur, die Außenwände, die Balkone und die Wohnungseingangstüren in mehrfach belegten Wohngebäuden mit zwei oder mehr Wohneinheiten gilt. Die entsprechenden Vorschriften traten am 23. Januar 2023 in Kraft, während sich historische Kontrollen für Mehrfamilienhäuser nach schweren Bränden entwickelten und eine eigene Risikokategorie für mehrfach belegte Gebäude einführten. (Forschung der britischen Regierung zu gemischten Wohnverhältnissen und zum Brandschutzkontext)
Die Lektion für Netzwerkarchitekten ist eindeutig. Eine gemeinsame Belegung erfordert explizite Kontrollen, aber die Antwort lautet nicht automatisch dedizierte Hardware. Es geht um eine nachweisbare Grenze, die dem Risikoprofil, dem Geschäftsmodell und der operativen Kapazität des Gebäudes entspricht.
Single-Tenant- und Multi-Tenant-Architekturen erklärt
In der Netzwerktechnik bedeutet Single Tenant, dass eine Organisation oder ein Nutzer einen dedizierten Infrastruktur-Stack oder eine dedizierte Betriebsinstanz erhält. Dies kann separate Access Points, Controller, VLANs, Authentifizierungsbereiche, Monitoring und Verwaltungsberechtigungen umfassen. Dieses Design begrenzt gemeinsame Abhängigkeiten, was die Umgebung übersichtlicher macht, wenn die Organisation jeden Endpunkt und jede Richtlinienentscheidung selbst besitzt.
Ein Krankenhausverbund, ein Militärgelände oder ein Unternehmenscampus wählt dieses Modell möglicherweise für den Kern-Traffic, da die internen Identitäts-, Compliance- und Incident-Response-Prozesse eine streng kontrollierte Umgebung erfordern. Eine dedizierte Infrastruktur kann zudem eine maßgeschneiderte Funkplanung, ungewöhnliche Geräteanforderungen und Änderungsfenster unterstützen, die über verschiedene, nicht miteinander verbundene Mieter hinweg nur schwer zu koordinieren wären.
Multi-Tenant-Netzwerke nutzen eine gemeinsame physische Infrastruktur und wenden gleichzeitig logische Kontrollen pro Organisation, Haushalt, Zimmer, Abteilung oder Service an. VLANs, VRFs, RADIUS-Attribute, identitätsbasierte private Pre-shared Keys, Firewall-Richtlinien und Richtlinien-Engines können separate Zugriffskontexte erstellen, ohne dass jede Appliance dupliziert werden muss.
Das physische Netzwerk wird gemeinsam genutzt. Der Sicherheitskontext und das Nutzungserlebnis sollten es jedoch nicht sein. Eine Hotelkette betreibt möglicherweise eine zentral verwaltete Plattform über alle Standorte hinweg, während ein Anbieter von Studentenunterkünften jeden Bewohner oder jede Wohneinheit einer eigenen Richtlinie und einem separaten Anmeldekontext zuordnet.
Single-Tenant- vs. Multi-Tenant-Networking auf einen Blick
| Dimension | Single Tenant | Multi Tenant |
|---|---|---|
| Physische Isolation | Dedizierte Infrastruktur oder operative Instanz | Gemeinsame Switches, Access Points, Controller oder Leitungen |
| Logische Isolation | In der Regel einfacher, da weniger Mandanten die Umgebung teilen | Unerlässlich, erzwungen durch Identität, VLANs, VRFs, Firewall-Regeln und Richtlinien |
| Verwaltungsebene | Dediziert oder streng auf eine Organisation beschränkt | Zentralisiert, mit mandantenfähiger Administration und delegierten Berechtigungen |
| Kosten-Skalierung | Wiederholt Infrastruktur und operativen Aufwand pro Mandant | Teilt Infrastruktur und konzentriert das Management |
| Typischer Kontext | Regulierte Unternehmen, Verteidigung, Kernbereiche des Gesundheitswesens, dedizierte Firmenstandorte | Hotellerie, Studentenwohnheime, BTR, Managed Services, gemeinsam genutzte Arbeitsplätze |
| Hauptfehlerquelle | Duplizierte Umgebungen weichen voneinander ab oder werden vernachlässigt | Ein Richtlinien- oder Identitätsfehler kann sich auf mehrere Mandanten auswirken |
Teams, die Bereitstellungsmuster vergleichen, können diesen Leitfaden für Multi-Tenant-WiFi-Architekturen als praktisches Referenzwerkzeug nutzen - das Design muss jedoch dennoch am tatsächlichen Gebäude- und Betriebsmodell getestet werden.
Die Wahl liegt nicht zwischen sicher und unsicher. Sie liegt zwischen physischer Trennung mit höherer Redundanz und logischer Trennung mit höheren Anforderungen an Design und Governance.
Direkter Vergleich der entscheidenden Kriterien
Die Entscheidung für die Architektur richtet sich nach dem Gebäude und dem Betriebsmodell, nicht nach dem SaaS-Label. Ein Gesundheitsnetzwerk, ein Studentenwohnheim, ein BTR-Objekt und ein Hotel stellen WiFi zwar alle als grundlegenden Dienst bereit, aber ihre tolerierbaren Ausfallgrenzen, Support-Zuständigkeiten und Datenverkehrsmuster unterscheiden sich.
Wählen Sie Single Tenant, wenn ein Fehler innerhalb der physischen Infrastruktur einer einzigen Organisation bleiben muss. Techniker können einen Controller, eine Firewall oder einen Authentifizierungsdienst ändern, ohne ein gemeinsames Wartungsfenster koordinieren zu müssen. Dieser Vorteil bleibt jedoch nur bestehen, wenn jede dedizierte Umgebung ordnungsgemäßes Patch-Management, Monitoring, Dokumentation und Recovery-Tests erhält. Dedizierte Infrastruktur bietet Kontrolle, keine automatische Ausfallsicherheit.
Wählen Sie Multi Tenant, wenn ein Betreiber wiederholbare Dienste für viele Bewohner oder Immobilien bereitstellen muss. Eine gemeinsame Fabric unterstützt standardisierte Richtlinien, zentrale Überwachung und konsistentes Onboarding. Der Betreiber trägt dabei eine größere Governance-Verantwortung: Anmeldedaten, Datenverkehr, Telemetrie und administrativer Zugriff müssen für jeden Mandanten stets korrekt abgegrenzt bleiben.
Fünf Kriterien, die das Design bestimmen
| Kriterium | Single Tenant | Multi Tenant | Ankerpunkt |
|---|---|---|---|
| Isolierung | Physische Trennung begrenzt den gemeinsamen Schadensradius | Logische Trennung muss über jede Steuerungsebene hinweg gelten | Die Isolationsstärke steigt mit dem Grad der Trennung, vom gemeinsamen Schema bis zur Datenbank pro Mandant |
| Sicherheit | Weniger gemeinsame Abhängigkeiten schaffen eine klarere Audit-Grenze | Zentrale Steuerungen verbessern die Konsistenz, aber ein einziger Richtlinienfehler kann mehrere Mandanten betreffen | Sicherheit folgt der Identitätssicherung, Konfiguration, dem Patch-Management und der Überwachung, nicht dem Architektur-Label |
| Kosten | Hardware, Lizenzen, Support-Wege und Wartung wiederholen sich für jeden Mandanten | Gemeinsame Infrastruktur verbessert die Auslastung und reduziert doppelte Arbeit | Die Kosten pro Mandant steigen mit zunehmender Isolation. Der detaillierte Kostenvergleich folgt im nächsten Abschnitt (SaaS-Architekturvergleich für UK) |
| Leistung | Dedizierte Kapazität vermeidet Engpässe zwischen Mandanten | Gemeinsame Kapazität erfordert Einlasskontrolle, QoS und aktive Überwachung | Der Betreiber benötigt explizite Steuerungen für ressourcenintensive Nachbarn und Geräte mit hohem Bedarf |
| Betrieb | Jede Umgebung mag einfacher sein, aber die Gesamtstruktur wird repetitiv | Eine Plattform kann effizient betrieben werden, vorausgesetzt, die Identitäts- und Richtlinienautomatisierung ist ausgereift | Single Tenant konzentriert den operativen Aufwand pro Umgebung. Multi Tenant konzentriert ihn in der Governance und der Steuerungsebene |
Isolation ist eine Design-Eigenschaft
Testen Sie die Isolierung anhand von Traffic-Strömen, nicht anhand von Diagrammen. Kann ein Bewohner das Gerät eines anderen Bewohners erkennen? Kann ein Gast auf Services des Personals zugreifen? Kann ein Support-Administrator die Sitzungsdaten eines anderen Mandanten einsehen? Verliert eine entzogene Identität sofort den Zugriff, auch von Geräten, die zuvor autorisiert waren?
Für beide Modelle gelten dieselben Kriterien. Ein dedizierter Controller liefert keine automatische Antwort darauf, und ein gemeinsam genutzter Controller macht die Umsetzung nicht unmöglich. Entscheidend ist, wo die Durchsetzung stattfindet, wie die Administratorenrechte eingegrenzt sind und wie viel gemeinsame Infrastruktur unter dem jeweiligen Mandanten liegt.
In Studentenwohnheimen und BTR-Objekten (Build-to-Rent) erwarten die Bewohner einen privaten Zugang, obwohl das Gebäude gemeinsame Switches, WiFi und Upstream-Verbindungen nutzt. Hotels stehen vor derselben Grenze zwischen Gästen, Personal und betrieblichen Services. Das Gesundheitswesen bringt zusätzlich verwaltete klinische Geräte und Altsysteme mit sich, sodass das Richtlinienmodell diese Abhängigkeiten schützen muss, ohne den routinemäßigen Support unmöglich zu machen.
Die Performance folgt dem Nachfragemuster
Hotels verzeichnen eine konzentrierte Nachfrage rund um den Check-in, Veranstaltungen und die Abendnutzung. Studentenwohnheime kombinieren eine hohe Gerätedichte mit häufigem Wechsel. Das Gesundheitswesen mischt verwaltete Geräte, persönliche Geräte und Spezialsysteme. Single Tenant kann Kapazitäten reservieren, während Multi Tenant dieselbe Nachfrage bedienen kann, wenn der Betreiber die Sendezeit misst, QoS anwendet und kritischen Datenverkehr von der Freizeitnutzung trennt.
WiFi ist in diesen Immobilien mittlerweile eine tragende Säule. Eine Dienstunterbrechung beeinträchtigt das Erlebnis der Bewohner, den Gästebetrieb und die geschäftlichen Ergebnisse, nicht nur ein technisches Dashboard.
Der praktische Test ist einfach: Kann der Betreiber Engpässe erkennen, bevor die Benutzer sie melden, den verantwortlichen Mandanten oder Dienst identifizieren und Richtlinien ändern, ohne das Netzwerk neu aufzubauen? Wenn nicht, ist das gewählte Isolationsmodell unvollständig.
Kosten, Skalierung und der verdeckte Aufwand der Isolation
Eine dedizierte Infrastruktur sieht in einem Projektplan einfach aus. Jeder Mandant erhält seine eigenen Controller, Switches, Access Points, Lizenzen, Monitoring-Integrationen, Identitätsspeicher, Firmware-Zeitpläne und Support-Prozesse. Die Rechnung enthält die Entwicklungszeit, die für die Bereitstellung, Dokumentation, Prüfung, das Patchen und die Wiederherstellung jeder einzelnen Kopie erforderlich ist.
Ein Single-Tenant-Design dupliziert auch den betrieblichen Aufwand. Ingenieure pflegen separate Vorlagen, prüfen ähnliche Warnmeldungen in verschiedenen Konsolen, wiederholen Firmware-Validierungen und bewahren unabhängige Wiederherstellungsverfahren auf. Diese Trennung ist ihren Preis wert, wenn ein Mieter eine eigene Compliance-Grenze oder ungewöhnliche technische Kontrollen benötigt. Sie führt jedoch zu einer Margenschrumpfung, wenn jeder Mieter denselben Service erhält und keine Richtlinie eine physische Trennung vorschreibt.
Der frühere Kostenvergleich gilt weiterhin, aber Netzwerkbetreiber müssen Ausgaben berücksichtigen, die in SaaS-Tabellen nicht auftauchen. Eine separate Controller-Lizenz kann einen eigenen Vertragsumfang haben. Jede zusätzliche Plattform kann eine Supportvereinbarung, ein Wartungsfenster und eine Firmware-Validierung vor der Bereitstellung erfordern. Ingenieure verbringen zudem Zeit mit dem Testen von Authentifizierung, Überwachung, Failover und Mieter-Übergabe in mehreren Umgebungen. Bei einem stark ausgelasteten Portfolio im Bereich britisches Student Housing, BTR oder Hospitality wirken sich diese Stunden ebenso direkt auf die Dienstleistungsmarge aus wie die Hardware.
Kostenaufstellung pro Mandant
| Kostenposition | Single Tenant, pro Mandant | Multi Tenant, pro Mandant | Hinweise |
|---|---|---|---|
| Physische Infrastruktur | Dedizierter oder reservierter Stack | Gemeinsame Fabric-Zuweisung | Single Tenant erfordert wiederholte Hardware-Anschaffungen und Standortarbeiten |
| Controller- und Plattform-Lizenzierung | Separate Instanz oder separater Lizenzbereich | Gemeinsame Plattform, mandantenfähige Lizenzierung | Vertragsbedingungen können das Ergebnis verändern |
| Identität und Authentifizierung | Separater Bereich oder dedizierte Integration | Gemeinsamer Service mit eingegrenzten Richtlinien | Multi Tenant erfordert eine starke Mandantenzuordnung |
| Überwachung | Separate Dashboards und Alarmierungspfade | Zentrales Dashboard mit Mandantenfiltern | Mangelhafte Filterung kann ein Risiko für die Zugriffskontrolle darstellen |
| Support und Change Management | Mandantenspezifische Zeitfenster und Runbooks | Standardisierte Workflows mit Ausnahmen | Standardisierung verbessert die Skalierung erst bei ausgereiften Richtlinien |
| Wiederherstellung und Tests | Separate Wiederherstellungspläne | Gemeinsame Plattform-Wiederherstellung plus Mandanten-Validierung | Der Betreiber muss die Wiederherstellung auf Mandantenebene nachweisen |
Eine gemeinsam genutzte Plattform verringert Duplikate nur dann, wenn der Betreiber die Mandantengrenzen konsistent durchsetzen kann. Sie benötigt Richtlinienvorlagen, eine schrittweise Bereitstellung, Konfigurationsvalidierung, mandantenspezifische Protokolle und getestete Rollbacks. Ohne diese Kontrollen kann eine gemeinsame Konsole ein Isolationsproblem in ein Zugriffskontrollproblem verwandeln.
Das Netzwerkdesign sollte vor der Inbetriebnahme getestet werden. Teams können einen iPSK subnet designer nutzen, um die identitätsbasierte Segmentierung zu modellieren, die Subnetz-Zuweisung zu prüfen und Adress- oder Richtlinienkonflikte frühzeitig aufzudecken.
Zahlen Sie für physische Isolation, wenn das Unternehmen eine physische Grenze erfordert. Zahlen Sie nicht dafür, nur weil das Design-Team keine vertrauenswürdige logische Grenze aufgebaut hat.
Die richtige Antwort ist oft ein Hybrid-Modell. Halten Sie klinischen Datenverkehr, Zahlungsverkehr, Gebäudemanagement oder Unternehmensdaten auf einem streng kontrollierten, dedizierten Pfad. Nutzen Sie ein gemeinsames, mandantenfähiges Netzwerk für Gäste, Bewohner, Auftragnehmer und andere wechselnde Nutzergruppen. Diese Aufteilung sorgt für Isolierung dort, wo ein Ausfall kommerzielle, regulatorische oder sicherheitsrelevante Folgen hat, während die gemeinsame Infrastruktur die Nachfrage bewältigt, die von Skaleneffekten profitiert.
Praxis-Szenarien für Enterprise-IT und Netzwerkbetreiber
Die Architekturentscheidung wird klarer, wenn Eigentümer, Nutzer und die Auswirkungen von Ausfällen benannt werden. Ein Netzwerk für eine einzelne Organisation ist nicht automatisch ein Single-Tenant-Problem, und ein Netzwerk für viele Menschen ist nicht automatisch ein Multi-Tenant-Problem.
Szenario eins, ein Unternehmenscampus mit 5.000 Arbeitsplätzen
Ein großer Enterprise-Campus mit strengen Anforderungen an die Datenresidenz sollte standardmäßig auf Single-Tenant für Kerndienste setzen. Der entscheidende Faktor ist nicht die Anzahl der Mitarbeiter. Es ist die Notwendigkeit, die physischen, administrativen und auditierbaren Grenzen aufeinander abzustimmen.
Dedizierte Controller, Authentifizierungsdienste, Administrationszugänge und Datenpfade erleichtern den Nachweis der Eigenverantwortung. Sicherheitsteams können den Administratorzugriff auf die eigenen Mitarbeiter beschränken, einen einheitlichen Änderungsprozess definieren und Vorfälle untersuchen, ohne irrelevante Aktivitäten anderer Mandanten filtern zu müssen.
Der Gastzugang kann weiterhin einen separaten logischen Dienst nutzen. Das Kern-Mitarbeiternetzwerk sollte nicht vom selben Richtlinienpfad abhängen wie temporäre Besucher, Vertragspartner oder Event-Teilnehmer.
Szenario zwei, eine Hotelgruppe mit mehreren Standorten
Eine Hotelgruppe, die Immobilien unter einer Marke betreibt, sollte sich im Allgemeinen für ein Multi-Tenant-Modell entscheiden. Ein zentrales Network Operations Center benötigt konsistentes Onboarding, Captive Portal-Richtlinien, Reporting und Incident Response über Hotels, Restaurants und Veranstaltungsorte hinweg. Eine Vervielfältigung der gesamten Verwaltungsumgebung an jedem Standort würde die Standardisierung erschweren, nicht sicherer machen.
Die Grenze muss weiterhin auf Objekt-, Gäste-, Mitarbeiter- und Service-Ebene bestehen. Gäste-Geräte dürfen Point-of-Sale-Systeme nicht erreichen. Mitarbeiter-Identitäten dürfen keine Berechtigungen von Gästen erben. Ein Objekt-Team sollte die für seine Arbeit erforderlichen Informationen sehen können, ohne unbeschränkten Zugriff auf jeden Standort zu erhalten.
Der Kompromiss ist klar. Eine zentralisierte Steuerung gewinnt, vorausgesetzt, der Betreiber kann eine mandantenfähige Verwaltung und Richtlinien für den Datenverkehr durchsetzen.
Szenario drei, UK BTR und Studentenwohnheime
In der Build-to-Rent-Branche und bei zweckgebundenen Studentenunterkünften setzt sich meist ein hybrides Multi-Tenant-Modell durch. Die Bewohner erwarten Privatsphäre auf Apartment- oder Zimmerebene, während der Betreiber von einem einzigen objektweiten physischen Netzwerk, einem einheitlichen Support-Modell und einem zentralisierten Servicemanagement profitiert.
Daten zum britischen Studentenwohnungsmarkt zeigen, dass 93 % der befragten Vermieter in Schottland einen einzigen Mietvertrag verwenden, während 7 % mehrere Mietverträge nutzen. Dies deutet darauf hin, dass administrative Einfachheit nach wie vor die Betriebsmodelle beeinflusst. (Daten zum britischen Studentenwohnungsmarkt)
Die Konnektivität in diesen Gebäuden wird zunehmend zu einer vom Betreiber bereitgestellten Versorgungsleistung und nicht mehr zu einem Vertrag, den jeder Bewohner einzeln abschließt. In der National Student Accommodation Survey 2026 von Save the Student gaben 80 % der Studierenden an, dass ihre Miete mindestens eine zusätzliche Dienstleistung abdeckt, und 48 % gaben an, dass Breitband inbegriffen war, direkt hinter Wasser (63 %), Strom (61 %) und Gas (54 %). Die zuverlässige Bereitstellung ist die schwierigere Aufgabe: Die Jisc-Umfrage 2024/25 unter 15.398 britischen Hochschulstudenten ergab, dass 60 % von Problemen mit der WiFi Konnektivität auf oder außerhalb des Campus berichteten. (Save the Student, National Student Accommodation Survey 2026; Jisc Digital Experience Insights 2024/25)
Das Netzwerk muss daher eine private User Experience bieten, ohne jeden Bewohner in ein separates Infrastrukturprojekt zu verwandeln. Identitätsbasierter Zugriff, Richtlinien pro Einheit, einfache Abrechnung und sofortiger Entzug von Berechtigungen sind wichtiger als die Bezeichnung der Architektur.
Mandantentrennung realisieren ohne Netzwerkduplizierung
Modernes, identitätsgesteuertes Networking bietet eine dritte Option zwischen einem physischen Stack pro Mandant und einem unkontrollierten, gemeinsam genutzten Netzwerk. Der Betreiber teilt sich die Netzwerkinfrastruktur und bindet den Zugriff an die Identität einer Person, einer Wohneinheit, eines Zimmers, einer Abteilung oder eines Geräts.
iPSK ist ein praktischer Ausgangspunkt für Wohnbereiche und gemischte Geräteumgebungen. Anstatt ein einziges gemeinsames Passwort für ein ganzes Gebäude herauszugeben, weist der Betreiber eindeutige private Schlüssel zu und ordnet sie einem Richtlinienkontext zu. Ein Schlüssel kann je nach betrieblicher Anforderung eine Wohnung, ein Zimmer, einen Bewohner, eine Gerätegruppe oder eine Serviceklasse identifizieren.
Die Steuerungsebene in Schichten aufbauen
- Identität dem Zugriff zuordnen. Verwenden Sie RADIUS-Attribute, Verzeichnisgruppen oder einen verwalteten Identitätsdienst, um einen Benutzer oder ein Gerät der richtigen Mandantenrichtlinie zuzuordnen.
- Rollenbasierte Steuerungen anwenden. Mitarbeiter, Bewohner, Gäste, Vertragspartner und Gebäudesysteme sollten unterschiedliche Berechtigungen erhalten. Teams, die diese Ebene evaluieren, können unter role based access control software eine umfassendere Erklärung der Richtlinien nach Rolle finden.
- Verkehr trennen. Nutzen Sie VLANs, VRFs, Firewall-Regeln und Dienstrichtlinien, um laterale Bewegungen zwischen Mandanten zu verhindern und Betriebssysteme zu schützen.
- Lebenszyklus-Ereignisse automatisieren. Richten Sie den Zugriff ein, sobald ein Bewohner oder Mitarbeiter freigegeben wird, und entziehen Sie ihn, wenn sich das Verzeichnis oder der Datensatz in der Immobilienverwaltung ändert.
- Telemetrie eingrenzen. Die zentrale Überwachung sollte den Betreibern nützliche Statusdaten liefern, ohne die Identitäts- oder Sitzungsinformationen eines Mandanten für einen anderen Mandanten offenzulegen.
SSO über Microsoft Entra ID oder Okta kann den Unternehmenszugriff an eine etablierte Identity Governance binden. Das funktioniert gut für Mitarbeiter und verwaltete Benutzer. iPSK bleibt nützlich für Bewohner, Besucher, Legacy-Geräte und Geräte, die keinen modernen Enterprise-Authentifizierungs-Flow durchführen können.
Die identitätsbasierte Netzwerkplattform von Purple ist ein Beispiel für einen Control-Plane-Ansatz, der mieterspezifischen Zugriff über eine gemeinsame Infrastruktur hinweg unterstützt - einschließlich iPSK und Integrationen mit Enterprise-Identity-Providern. Ihr Wert in dieser Architektur liegt nicht in der Existenz einer weiteren SSID. Es ist die Fähigkeit, Identität, Richtlinien, Onboarding und Widerruf zu verbinden, ohne dass für jeden Nutzer ein separates physisches Netzwerk erforderlich ist.
Das Design muss noch getestet werden. Validieren Sie, dass Anmeldedaten nicht ihre beabsichtigte Richtlinie überschreiten können, dass das Onboarding von Geräten die Segmentierung nicht umgeht, dass Administratoren über auf Mandanten beschränkte Berechtigungen verfügen und dass ein Widerruf aktive Sitzungen erreicht. Ein gemeinsam genutztes physisches Netzwerk kann eine private Mandantenerfahrung bieten, aber nur, wenn der Betreiber Identität und Richtlinien als Produktionsinfrastruktur behandelt.
Welche Architektur Sie wann wählen sollten
Nutzen Sie Single Tenant, wenn die Organisation eine dedizierte physische Grenze benötigt und nicht nur einen separaten Login. Das regulierte Gesundheitswesen, Zahlungsumgebungen, die Verteidigung und hochsensible Unternehmens-Workloads sollten hier für Kerndienste ansetzen. Die Architektur vereinfacht die Beweiserhebung und reduziert gemeinsame Abhängigkeiten, erfordert jedoch weiterhin diszipliniertes Patch-Management, Monitoring und Identitätsmanagement.
Nutzen Sie Multi-Tenant-Strukturen, wenn der Betreiber viele Kunden, Bewohner, Räume, Abteilungen oder Immobilien bedient und der Dienst von einer wiederholbaren Bereitstellung abhängt. Das Gastgewerbe, Studentenwohnheime, BTR, Managed Services und gemeinsam genutzte Arbeitsbereiche profitieren in der Regel mehr von zentralisierten Abläufen als von der Duplizierung von Hardware. Die Bedingung ist eine strenge, mandantenfähige Richtlinie, kein lockerer Sicherheitsstandard.
Verwenden Sie einen hybriden Ansatz, wenn ein Standort sowohl hochsensible interne Dienste als auch ein hohes Aufkommen an temporären oder residenten Nutzern umfasst.
Architekturempfehlungs-Matrix
| Szenario | Empfohlenes Modell | Grund |
|---|---|---|
| Regulierter Unternehmenskern, klinische Systeme im Gesundheitswesen oder Zahlungsverkehr | Single Tenant | Die physische und die Audit-Grenze sollten mit der Kontrollgrenze der Organisation übereinstimmen |
| SaaS-Anbieter oder Managed Service Operator mit vielen Kunden | Multi Tenant | Eine gemeinsam genutzte Infrastruktur unterstützt wiederholbare Richtlinien, zentrale Abläufe und eine effiziente Expansion |
| Hotelgruppe mit zentralem Gästeservice | Multi Tenant | Ein einziges Betriebsmodell unterstützt eine konsistente Identität, Support und Servicebereitstellung über alle Standorte hinweg |
| BTR, Studentenwohnheime oder flexible Arbeitsbereiche | Hybrid Multi Tenant | Eine gemeinsam genutzte Infrastruktur funktioniert mit Identität, Richtlinien, Abrechnung und Sperrung pro Bewohner |
| Unternehmensstandort mit Mitarbeiter- und Gäste-WiFi | Hybrid | Sensiblen Unternehmensdatenverkehr streng kontrollieren, während gleichzeitig ein mandantenfähiger Gästezugang angewendet wird |
| Umgebung mit wiederholten "Noisy-Neighbour"-Vorfällen oder Audit-Mängeln | Neu bewerten, dann die betroffenen Dienste isolieren | Die aktuelle Grenze versagt, unabhängig von der Bezeichnung der Architektur |
Migrationsentscheidungen sollten derselben Logik folgen. Erfassen Sie Datenverkehrsklassen, Identitäten, Gerätetypen, Verwaltungsrollen und Ausfalldomänen, bevor Sie eine Plattform auswählen. Warnsignale sind ungeklärte mandantenübergreifende Sichtbarkeit, inkonsistente Richtlinien zwischen Standorten, langsame Zugriffswiderrufe, Support-Teams mit übermäßigem administrativem Zugriff und Mandantenabwanderung aufgrund fehlender Kontrollen oder Funktionsverzögerungen.
Stellen Sie vor der Unterzeichnung des Designs eine Frage: Wem gehört die Netzwerkgrenze, und benötigt diese Person dedizierte Hardware oder eine dedizierte Richtlinie?
Die Zusammenfassung für die Leitlinie ist einfach:
- Wählen Sie ein Single-Tenant-Modell, wenn die physische Isolierung eine geschäftliche oder Compliance-Anforderung ist.
- Wählen Sie ein Multi-Tenant-Modell, wenn die Skalierbarkeit von einer gemeinsamen Infrastruktur und ausgereiften Identitätskontrollen abhängt.
- Wählen Sie ein Hybrid-Modell, wenn sensibler Kern-Traffic und gemeinsam genutzter Zugriff mit hohem Datenaufkommen nebeneinander existieren.
Purple bietet identitätsbasiertes Networking für gemeinsam genutzte Gebäude, einschließlich Zugriffskontrollen auf Mandantenebene und iPSK-basierter Trennung auf gemeinsamer Infrastruktur. Besuchen Sie Purple, um zu prüfen, ob dieser Ansatz zu Ihrem Design für Studentenwohnheime, BTR, Hotellerie, Gesundheitswesen oder Gäste-WiFi in Unternehmen passt, und testen Sie die Netzwerkgrenze mit Ihren eigenen Identitäts-, Widerrufs- und Verkehrsrichtlinien.
