Multi-Tenant-Architekturen: Sicherheitsgewinn oder Kosmetik?

2 Executive Summary

„Wir machen einen zweiten Tenant, dann ist das sicherer.“ Dieser Satz fällt in Architektur-Workshops erstaunlich oft — und er ist ungefähr so belastbar wie „wir kaufen einen zweiten Aktenschrank, dann ist der Datenschutz geregelt.“ Manchmal stimmt er. Oft ist er teuer erkaufte Selbstberuhigung. Dieses Dokument untersucht systematisch, wann eine Multi-Tenant-Architektur in Microsoft 365 / Entra ID einen realen, messbaren Sicherheitsgewinn liefert — und wann sie lediglich Komplexität, Kosten und Kollaborationsreibung produziert, ohne das Risikoprofil substanziell zu verbessern.

Die Kernbefunde in Kurzform:

Befund 1: Die Tenant-Grenze ist eine harte Identitäts- und Verwaltungsgrenze — die stärkste Isolationsgrenze, die die Microsoft-Cloud kennt. Ein Global Admin in Tenant A hat in Tenant B exakt gar nichts zu melden. Das ist ein echter, technisch belastbarer Sicherheitsmechanismus.

Befund 2: Der Sicherheitsgewinn steht und fällt mit den Brücken. Cross-Tenant Sync, B2B-Gäste, gemeinsame Administratoren, gemeinsame Endgeräte und ein gemeinsames On-Premises-AD als Identitätsquelle weichen die Grenze wieder auf. Wer erst trennt und dann alles wieder verbindet, hat am Ende zwei Tenants und ein Sicherheitsniveau — das des schwächeren.

Befund 3: Echter Gewinn entsteht bei getrennten Admin-Populationen, getrennten Risikoprofilen, getrennter Regulatorik oder absehbarer organisatorischer Trennung (M&A, Carve-out) sowie bei konsequenter Dev-/Test-Isolation.

Befund 4: Kosmetik liegt vor, wenn die Trennung dem Organigramm folgt, aber dieselben Menschen, dieselben Geräte und dieselben Prozesse in allen Tenants arbeiten — oder wenn großzügige Synchronisierung die Trennung faktisch aufhebt.

Befund 5: Der Aufwand ist kein Fußnotenthema. Multi-Tenant bedeutet n-fachen Betrieb: Conditional Access, Compliance-Richtlinien, Monitoring, Lizenzverwaltung, Break-Glass-Konzepte und Schulung — pro Tenant. Wer diesen Betriebsaufwand nicht dauerhaft stemmen kann, verschlechtert die Sicherheit unter Umständen sogar.

Die Empfehlung dieses Dokuments lautet daher nicht „Multi-Tenant ja/nein“, sondern: erst Schutzziele und Bedrohungsmodell definieren, dann die reale Admin- und Kollaborationssituation erheben, dann Alternativen innerhalb eines Tenants prüfen — und erst danach über eine Tenant-Trennung entscheiden. Kapitel 6 liefert dafür ein schrittweises Entscheidungs-Framework mit Erfolgskriterien und Exit-Punkten.

✓ Die Ein-Satz-Zusammenfassung Ein zweiter Tenant kauft eine harte Grenze — aber nur, wer die Grenze auch geschlossen hält und den doppelten Betrieb dauerhaft leistet, bekommt dafür Sicherheit. Alle anderen bekommen dafür vor allem Rechnungen.

 

3 Ausgangssituation und Scope

3.1 Fragestellung

Unternehmen und Organisationen stehen regelmäßig vor der Frage, ob sie ihre Microsoft-Cloud-Umgebung in einem einzigen Tenant betreiben oder auf mehrere Tenants aufteilen sollen. Die Motive sind vielfältig: Sicherheitsbedenken, Konzernstrukturen mit rechtlich selbstständigen Töchtern, regulatorische Anforderungen, geplante Zu- oder Verkäufe, Trennung von Produktions- und Testumgebungen — oder schlicht das Bauchgefühl, dass „getrennt“ irgendwie „sicherer“ klingt.

Dieses Dokument beantwortet die Frage bewusst nicht mit einem pauschalen Ja oder Nein, sondern liefert das Handwerkszeug, um sie für eine konkrete Situation fundiert zu beantworten: Welche Sicherheitswirkung hat die Tenant-Grenze technisch tatsächlich? Unter welchen Bedingungen materialisiert sich diese Wirkung — und unter welchen verpufft sie? Welche Kosten- und Aufwandsposten stehen dem gegenüber?

3.2 Was betrachtet wird

Microsoft 365 und Entra ID als Plattform, einschließlich der Cross-Tenant-Mechanismen (B2B Collaboration, Cross-Tenant Access Settings, Cross-Tenant Synchronization, Multi-Tenant Organizations).

Sicherheitsarchitektur: Identitätsgrenzen, Blast Radius, administrative Kontrolle, Richtlinien-Regime, Angriffsflächen.

Governance- und Compliance-Aspekte: Datenresidenz, regulatorische Trennungsgebote, Auditierbarkeit.

Betriebswirtschaftliche Dimension: Betriebsaufwand, Lizenzeffekte, Kollaborationskosten, Projektaufwand für Trennung oder Konsolidierung.

3.3 Was nicht betrachtet wird

Kein konkreter Kundenfall. Alle Szenarien sind generisch formuliert und dienen als Bewertungsmuster.

Keine Migrationsplanung im Detail (Tenant-to-Tenant-Migration ist ein eigenes, umfangreiches Thema und würde den Rahmen sprengen).

Keine Azure-Subscription-Architektur im Detail — der Fokus liegt auf M365 / Entra ID. Wo Azure-Ressourcen die Bewertung beeinflussen, wird darauf hingewiesen.

Kein Vergleich mit Nicht-Microsoft-Plattformen.

3.4 Zielgruppe und Lesehinweis

Das Dokument richtet sich an IT-Leitung, Security-Verantwortliche und Architekten, die eine Tenant-Entscheidung vorbereiten oder eine bestehende Multi-Tenant-Landschaft kritisch hinterfragen wollen. Kapitel 4 erklärt das technische Warum, Kapitel 5 bewertet typische Szenarien mit Vor-/Nachteilen, Chancen/Risiken und Aufwand/Nutzen, Kapitel 6 liefert das Entscheidungs-Framework als konkreten Fahrplan. Wer es eilig hat, liest Executive Summary, Skizze 3 und Kapitel 6 — und kommt für die Begründungen zurück.

 

4 Technischer Hintergrund: Was die Tenant-Grenze wirklich leistet

Bevor über Sicherheitsgewinn oder Kosmetik geurteilt werden kann, muss präzise sein, was ein Tenant technisch ist und welche Grenze er zieht. Genau an dieser Stelle entstehen die meisten Fehlentscheidungen: Es wird eine Grenze gekauft, deren Verlauf niemand exakt kennt.

4.1 Was ein Tenant technisch ist

Ein Tenant ist eine dedizierte, logisch vollständig isolierte Instanz von Entra ID mit allen daran hängenden Microsoft-365-Diensten. Er ist gleichzeitig dreierlei:

Identitätsgrenze: Alle Benutzer, Gruppen, Geräteobjekte, Anwendungsregistrierungen und Rollenzuweisungen existieren ausschließlich innerhalb des Tenants. Es gibt keine tenant-übergreifende Vererbung von Berechtigungen — niemals, unter keinen Umständen.

Verwaltungsgrenze: Sämtliche administrativen Rollen enden an der Tenant-Grenze. Ein Global Administrator, ein Exchange Administrator, ein kompromittiertes Dienstkonto mit weitreichenden Graph-Berechtigungen — alles davon wirkt exakt bis zur Grenze und keinen Millimeter weiter.

Richtliniengrenze: Conditional Access, Compliance-Richtlinien, Purview-Konfiguration, Defender-Einstellungen, Datenresidenz-Zuordnung — jeder Tenant hat sein eigenes, unabhängiges Richtlinien-Regime.

Diese drei Eigenschaften machen die Tenant-Grenze zur härtesten Isolationsgrenze im Microsoft-Cloud-Ökosystem. Härter als jede Berechtigungsstruktur, härter als jede Administrative Unit, härter als jedes Label. Wer diese Grenze überwinden will, braucht entweder explizit konfiguriertes Cross-Tenant-Vertrauen — oder einen handfesten Plattform-Bug, und die sind in dieser Kategorie erfreulich selten.

Skizze 1: Grundmodell — ein Tenant mit logischer Binnentrennung vs. zwei Tenants mit expliziten Brücken

4.2 Was die Grenze trennt — und was sie nicht trennt

Die Tenant-Grenze ist stark, aber sie ist kein Zauberkreis. Sie trennt Identitäten, Verwaltung und Richtlinien — sie trennt aber weder Menschen noch Endgeräte noch Prozesse. Und genau dort entscheidet sich, ob eine Multi-Tenant-Architektur Sicherheit liefert oder nur so aussieht.

Skizze 2: Harte Trennwirkung der Tenant-Grenze vs. Faktoren, die sie nicht adressiert

⚠ Der Klassiker: gleiche Admins, zwei Tenants Wenn dieselben drei Administratoren beide Tenants betreuen — womöglich vom selben Notebook aus, womöglich mit ähnlichen Konten und identischen Gewohnheiten — dann ist die Tenant-Grenze für einen Angreifer ungefähr so hinderlich wie eine Kordel im Museum. Ein erfolgreicher Phishing- oder Token-Diebstahl gegen diese Person öffnet beide Umgebungen. Der Blast Radius wurde nicht verkleinert, er wurde nur auf zwei Rechnungen verteilt.

4.3 Isolationswerkzeuge innerhalb eines einzelnen Tenants

Die Gegenfrage jeder Multi-Tenant-Überlegung lautet: Was leistet ein einzelner Tenant an Binnentrennung? Die Antwort: erstaunlich viel — wenn man die Werkzeuge konsequent einsetzt. Die folgende Tabelle ordnet die wichtigsten Mechanismen ein.

Mechanismus	Was er trennt	Was er nicht trennt	Einordnung
Entra RBAC + scoped Rollen	Administrative Zuständigkeiten nach Rolle und Umfang	Global-Admin-Ebene bleibt tenantweit mächtig	Pflicht, aber keine harte Grenze
Administrative Units (AU)	Delegierte Verwaltung für Teilmengen von Benutzern/Geräten/Gruppen	Nicht alle Workloads AU-fähig; keine Datenisolation	Gut für Konzern-Töchter im Single-Tenant
Conditional Access	Zugriffsbedingungen je Benutzergruppe/App/Standort/Gerät	Keine Verwaltungsgrenze; Fehlkonfiguration wirkt tenantweit	Steuerung, keine Isolation
PIM / Tiering / PAW	Zeitliche und prozedurale Begrenzung privilegierter Zugriffe	Menschlichen Faktor nur bedingt	Größter Sicherheitshebel pro investiertem Euro
Sensitivity Labels / Purview	Datenklassifizierung, Verschlüsselung, DLP	Administrative Kontrolle	Datenschutzwirkung, keine Identitätsgrenze
Information Barriers	Kommunikation/Kollaboration zwischen definierten Segmenten	Verwaltung, Infrastruktur	Nische: regulatorische Kommunikationstrennung

 

Das Fazit dieser Tabelle ist unbequem für Multi-Tenant-Enthusiasten: Ein sauber betriebener Single-Tenant mit konsequentem RBAC, Administrative Units, PIM und einem echten Tiering-Modell deckt einen großen Teil der Trennungsbedarfe ab, die in der Praxis als Begründung für Multi-Tenant vorgetragen werden. Was er nicht abdeckt, ist genau eines: die Begrenzung des Schadens, wenn die höchste Privilegienebene selbst fällt — oder wenn zwei Organisationseinheiten fundamental unterschiedliche Regime brauchen.

4.4 Die Brücken: Cross-Tenant-Mechanismen

Kaum eine Multi-Tenant-Landschaft lebt in völliger Isolation. Menschen müssen zusammenarbeiten, Kalender müssen sichtbar sein, Teams-Chats sollen funktionieren. Microsoft liefert dafür einen ganzen Werkzeugkasten — und jedes dieser Werkzeuge ist, aus Sicherheitssicht betrachtet, ein kontrolliertes Loch in der Grenze:

B2B Collaboration (Gäste): Externe Identitäten werden als Gastobjekte in den Ziel-Tenant eingeladen und dort berechtigt. Kontrollierbar über Cross-Tenant Access Settings — in der Praxis aber oft historisch gewachsen und unkuratiert.

Cross-Tenant Access Settings (Inbound/Outbound): Regeln, welche fremden Tenants unter welchen Bedingungen vertraut wird — inklusive der Frage, ob MFA- und Gerätestatus des Heimat-Tenants akzeptiert werden. Das ist das zentrale Stellwerk der Grenze und verdient entsprechend viel Aufmerksamkeit.

Cross-Tenant Synchronization: Automatisiertes Provisioning von Benutzern aus Tenant A als B2B-Objekte in Tenant B. Komfortabel für nahtlose Kollaboration — und gleichzeitig der Mechanismus, mit dem man eine Tenant-Trennung am gründlichsten wieder einebnen kann.

Multi-Tenant Organization (MTO): Verbund mehrerer Tenants für nahtlose Teams-/People-Search-Erfahrung. Organisatorisch attraktiv, sicherheitstechnisch ein weiterer Vertrauensverbund, der gepflegt werden will.

Hybride Identität: Ein gemeinsames On-Premises Active Directory, das per Entra Connect / Cloud Sync in mehrere Tenants synchronisiert, macht das AD zum gemeinsamen Tier 0 aller Tenants. Fällt das AD, fallen alle Tenants. Die Cloud-Grenze ist dann nachgelagerte Deko.

ℹ Die zentrale Denkfigur dieses Dokuments Sicherheitsgewinn = Härte der Grenze × Disziplin an den Brücken. Beide Faktoren sind multiplikativ verknüpft: Die härteste Grenze nützt nichts, wenn die Brücken offen stehen — und geschlossene Brücken nützen nichts, wenn dieselben Menschen mit denselben Geräten auf beiden Seiten arbeiten.

4.5 Aufwandstreiber im Multi-Tenant-Betrieb

Der Nutzen ist nur die halbe Gleichung. Die folgende Tabelle benennt die Aufwandsposten, die in Multi-Tenant-Entscheidungen regelmäßig unterschätzt werden — meist, weil sie nicht im Projektbudget, sondern im Dauerbetrieb anfallen.

Aufwandsposten	Beschreibung	Charakter
Richtlinien-Pflege × n	Conditional Access, Intune, Defender, Purview, Exchange-/SharePoint-Konfiguration müssen je Tenant gepflegt, getestet und konsistent gehalten werden. Drift zwischen Tenants ist der Normalzustand, nicht die Ausnahme.	Dauerhaft, wächst mit jedem Feature
Monitoring & Incident Response × n	Getrennte Log-Quellen, getrennte Portale, getrennte Alarmierung — oder Aufwand für zentrale Zusammenführung (Sentinel Multi-Tenant, Lighthouse).	Dauerhaft
Lizenz-Splitting	Volumeneffekte gehen verloren; Add-on-Lizenzen (z. B. E5-Security-Komponenten) müssen ggf. mehrfach vorgehalten werden; Lizenzverschiebung zwischen Tenants ist vertraglich und praktisch zäh.	Dauerhaft, direkt kostenwirksam
Kollaborationsreibung	Kalender-Transparenz, Teams-Federation, geteilte Postfächer, gemeinsame Dateiablagen über Tenant-Grenzen: alles möglich, nichts davon reibungslos. Jede Reibung erzeugt Schatten-IT-Druck.	Dauerhaft, schwer messbar, real
Break-Glass & Notfallzugriff × n	Notfallkonten, deren Überwachung, deren regelmäßiger Test — pro Tenant.	Dauerhaft, sicherheitskritisch
Identity Lifecycle	Ein- und Austritte, Wechsel zwischen Organisationseinheiten über Tenant-Grenzen hinweg erfordern Provisioning-Logik statt einer simplen Gruppenänderung.	Dauerhaft, prozessgetrieben
Know-how & Vertretung	Jeder Tenant braucht Menschen, die ihn beherrschen. Kleine Teams, die drei Tenants „nebenbei“ betreiben, betreiben faktisch keinen davon richtig.	Strukturell — der am häufigsten ignorierte Posten

 

★ Aus der Beratungspraxis Die ehrlichste Frage in jedem Multi-Tenant-Workshop lautet nicht „Was gewinnen wir an Sicherheit?“, sondern: „Wer genau pflegt in drei Jahren die Conditional-Access-Richtlinien im zweiten Tenant — mit Namen und Stellenanteil?“ Wenn auf diese Frage betretenes Schweigen folgt, ist die Architekturfrage bereits beantwortet.

 

5 Analysebefunde: Szenarien im Sicherheits-Realitätscheck

5.1 Bewertungslogik

Die folgenden Szenarien werden nach einem einheitlichen Raster bewertet: Vor- und Nachteile (strukturelle Eigenschaften der Architektur), Chancen und Risiken (was sich daraus positiv oder negativ entwickeln kann) sowie Aufwand und Nutzen (was es kostet und was es bringt). Die Einstufung in „echter Sicherheitsgewinn“, „Grauzone“ und „Kosmetik“ folgt einer einfachen Prüflogik:

Prüfstein 1 — Angreiferperspektive: Erhöht die Trennung die Kosten eines realistischen Angreifers messbar? (Muss er einen zweiten, unabhängigen Angriffspfad finden — oder reicht derselbe Mensch, dasselbe Gerät, dieselbe Sync-Regel?)

Prüfstein 2 — Blast Radius: Begrenzt die Trennung den Schaden eines erfolgreichen Angriffs oder eines administrativen Fehlers auf einen Teil der Organisation?

Prüfstein 3 — Alternativlosigkeit: Erfüllt die Trennung eine Anforderung, die innerhalb eines Tenants nicht oder nur mit unvertretbarem Aufwand erfüllbar wäre (Regulatorik, Souveränität, unterschiedliche Richtlinien-Regime)?

Prüfstein 4 — Betriebsrealität: Kann die Organisation den Mehraufwand dauerhaft leisten, ohne dass die Betriebsqualität in einem der Tenants absackt?

Ein Szenario, das keinen der ersten drei Prüfsteine besteht, ist Kosmetik — unabhängig davon, wie gut es sich in einer Management-Präsentation macht.

5.2 Szenarien mit echtem Sicherheitsgewinn

5.2.1 Getrennte Regulatorik, Souveränität oder Datenresidenz

Einordnung: Echter Sicherheits- und Compliance-Gewinn — Kritikalität: hoch

Zwei Organisationsteile unterliegen fundamental unterschiedlichen Regimen: etwa ein regulierter Bereich (KRITIS, Finanzaufsicht, Verteidigungsnähe) neben einem klassischen Bürobereich, unterschiedliche Datenresidenz-Anforderungen oder die Nutzung einer Sovereign-Cloud-Umgebung für einen Teilbereich. Ein Tenant kann genau eine Datenresidenz-Grundkonfiguration und ein Compliance-Grundregime abbilden — wer zwei unvereinbare Regime braucht, braucht zwei Tenants.

Vorteile	Nachteile
• Jedes Regime erhält sein eigenes, widerspruchsfreies Richtlinien-Set • Auditierbarkeit: Der regulierte Bereich ist als geschlossene Einheit prüfbar • Datenresidenz und Cloud-Umgebung pro Bereich frei wählbar • Regulatorische Änderungen betreffen nur den betroffenen Tenant	• Kollaboration zwischen den Bereichen wird spürbar aufwendiger • Doppelte Compliance-Pflege dort, wo sich Anforderungen überschneiden • Personal muss ggf. in beiden Regimen arbeitsfähig sein (zwei Identitäten)

 

Chancen	Risiken
• Saubere Zertifizierung/Auditierung des regulierten Bereichs ohne Seiteneffekte • Klare Verantwortungszuordnung gegenüber Aufsichtsbehörden • Zukunftssicherheit bei verschärfter Regulatorik (NIS2-Nachfolger, sektorspezifische Vorgaben)	• Übersteuerung: Auch unkritische Workloads wandern „sicherheitshalber“ in den strengen Tenant und ersticken dort an Prozessen • Brücken werden aus Bequemlichkeit zu weit geöffnet und unterlaufen das Trennungsziel

 

Aufwand	Nutzen
• Hoch: zweiter Vollbetrieb, ggf. Migration, doppelte Sicherheitswerkzeuge • Dauerhaft: zwei Richtlinien-Regime, zwei Audit-Zyklen	• Hoch: Anforderung ist im Single-Tenant schlicht nicht erfüllbar • Reduzierte Audit-Komplexität pro Bereich • Echte Schadensbegrenzung zwischen den Regimen

 

Fazit: Hier ist Multi-Tenant kein Geschmacksthema, sondern häufig die einzige saubere Lösung. Der Prüfstein „Alternativlosigkeit“ ist erfüllt — der Aufwand ist der Preis der Anforderung, nicht der Architektur.

 

5.2.2 Getrennte Admin-Populationen und Risikoprofile

Einordnung: Echter Sicherheitsgewinn — Kritikalität: hoch, aber an harte Bedingungen geknüpft

Zwei Bereiche mit unterschiedlichen Risikoprofilen — etwa produktionsnahe OT-Umgebung neben Office-IT, oder ein Bereich mit hohem Angriffsdruck neben dem Rest — werden getrennt, und zwar inklusive der Menschen: getrennte Administratoren, getrennte Verwaltungsgeräte (PAWs), getrennte Break-Glass-Konzepte. Erst diese personelle und gerätebezogene Trennung aktiviert den Blast-Radius-Vorteil der Tenant-Grenze.

Vorteile	Nachteile
• Kompromittierung eines Admin-Kontos bleibt auf einen Tenant begrenzt • Fehlkonfigurationen und Skript-Unfälle wirken nur lokal • Unterschiedliche Härtungsgrade ohne gegenseitige Behinderung möglich • Angreifer benötigt zwei unabhängige Angriffspfade	• Doppelte Admin-Mannschaft oder saubere Rollentrennung nötig — das kostet Personal • Wissenssilos: Der eine Tenant-Betrieb lernt nicht automatisch vom anderen • Werkzeuge für tenant-übergreifende Sicht (Lighthouse, Sentinel) nötig

 

Chancen	Risiken
• Vorbild-Effekt: Der stärker gehärtete Tenant setzt Standards, die später übernommen werden können • Realistische Übungsumgebung für Incident Response mit begrenztem Risiko	• Schleichende Personalunion: Nach zwei Jahren betreuen „vorübergehend“ doch dieselben Personen beide Tenants — der Gewinn ist dann weg, die Kosten bleiben • Gemeinsame Endgeräte oder gemeinsames Quell-AD hebeln die Trennung aus

 

Aufwand	Nutzen
• Hoch: getrennte Teams oder strikte Rollentrennung, getrennte PAWs, doppelte Prozesse • Mittel bis hoch: laufende Koordination zwischen den Betriebsteams	• Hoch — aber nur solange die personelle Trennung real gelebt wird • Messbar: Blast Radius eines Admin-Kompromisses halbiert sich tatsächlich

 

Fazit: Der Sicherheitsgewinn ist real und erheblich — aber er hängt zu 100 % an der Disziplin bei Menschen und Geräten. Wer die personelle Trennung nicht dauerhaft finanzieren will, sollte das Geld stattdessen in PIM, Tiering und PAWs im Single-Tenant stecken. Das bringt dann mehr.

 

5.2.3 M&A, Carve-out und absehbare organisatorische Trennung

Einordnung: Echter struktureller Gewinn — Kritikalität: hoch bei konkretem Anlass

Eine Organisationseinheit soll verkauft, verselbstständigt oder als Joint Venture ausgegliedert werden — oder wurde gerade zugekauft und soll bewusst nicht integriert werden. Die Tenant-Grenze bildet hier die künftige (oder bewusst beibehaltene) Unternehmensgrenze technisch exakt ab.

Vorteile	Nachteile
• Verkaufsfähigkeit: Die Einheit ist als geschlossenes Paket übergabefähig • Keine mühsame Datenentflechtung unter Zeitdruck im Transaktionsfall • Klare Verantwortlichkeits- und Haftungsgrenzen ab Tag eins • Due-Diligence-Prüfungen betreffen nur den relevanten Tenant	• Solange die Einheit noch zum Konzern gehört: volle Multi-Tenant-Reibung im Alltag • Doppelstrukturen, die sich bei geplatzter Transaktion als Fehlinvestition erweisen können

 

Chancen	Risiken
• Deutlich schnellere, günstigere und risikoärmere Transaktionsdurchführung • Option, Konzernstandards bewusst nicht auf die Einheit anzuwenden (oder umgekehrt)	• Transaktion verzögert sich um Jahre — die „temporäre“ Doppelstruktur wird zum Dauerzustand ohne strategischen Grund • Übergangs-Brücken (Sync, Gäste) werden nie zurückgebaut

 

Aufwand	Nutzen
• Mittel bis hoch: Aufbau bzw. Nicht-Integration eines vollwertigen Tenants • Befristet gedacht — in der Praxis oft länger als geplant	• Hoch bei konkretem Transaktionshorizont: Entflechtungskosten sinken drastisch • Strategische Flexibilität

 

Fazit: Bei konkretem Trennungshorizont ist die Tenant-Grenze das ehrlichste Abbild der Unternehmensrealität. Ohne konkreten Horizont gilt: Wer „vielleicht irgendwann mal“ verkauft, bezahlt die Reibung sicher und den Nutzen vielleicht.

 

5.2.4 Dev-, Test- und Demo-Tenants

Einordnung: Echter Gewinn bei geringem Aufwand — der unstrittigste Fall

Entwicklungs-, Test- und Demonstrationsumgebungen werden in eigene Tenants ausgelagert, statt im Produktions-Tenant zu experimentieren. Das ist der Fall, in dem sich Fachwelt und gesunder Menschenverstand einig sind.

Vorteile	Nachteile
• Experimente, Preview-Features und Drittanbieter-Tests gefährden die Produktion nicht • Test-Identitäten und Wegwerf-Konfigurationen verschmutzen das Produktivverzeichnis nicht • App-Registrierungen und Berechtigungstests ohne Risiko für echte Daten	• Testergebnisse sind nur so übertragbar, wie der Test-Tenant der Produktion ähnelt • Lizenzen für realistische Tests (E5-Features) kosten auch im Test-Tenant Geld

 

Chancen	Risiken
• Fundierte Change-Prozesse: Erst im Test-Tenant, dann in Produktion • Sichere Spielwiese für Schulung und Skill-Aufbau	• Test-Tenant verwahrlost sicherheitstechnisch und wird selbst zum Einfallstor (echte Daten in Testumgebungen, vergessene Konten, keine MFA) • Konfigurationsdrift macht Tests wertlos

 

Aufwand	Nutzen
• Gering bis mittel: schlanker Betrieb, Entwickler-Lizenzprogramme nutzbar • Diszipliniertes Datenmanagement (keine Echtdaten!) erforderlich	• Hoch im Verhältnis: Produktionsschutz zu kleinem Preis • Beschleunigt sichere Feature-Einführung

 

Fazit: Klare Empfehlung, nahezu bedingungslos. Die einzige Todsünde: echte Produktionsdaten im Test-Tenant. Dann ist der Test-Tenant kein Sicherheitsgewinn, sondern die ungeschützte Kopie der Kronjuwelen.

 

5.3 Grauzone: Konzernstrukturen mit rechtlich selbstständigen Einheiten

Der häufigste Diskussionsfall liegt genau zwischen Gewinn und Kosmetik: ein Konzern mit mehreren rechtlich selbstständigen Töchtern, die eng zusammenarbeiten. Für Multi-Tenant sprechen Haftungstrennung, eigenständige Compliance-Verantwortung der Geschäftsführungen und mögliche spätere Verkäufe. Dagegen sprechen die tägliche Kollaboration, gemeinsame Prozesse und meist eine gemeinsame zentrale IT.

Die Entscheidung hängt hier an Fragen, die nur der konkrete Fall beantworten kann:

Haben die Einheiten wirklich getrennte IT-Verantwortung — oder betreibt eine zentrale IT ohnehin alles? (Zentrale IT für alle Tenants = Prüfstein 1 und 2 weitgehend verfehlt.)

Gibt es materielle regulatorische Unterschiede zwischen den Einheiten — oder nur unterschiedliche Briefköpfe?

Wie hoch ist der reale Kollaborationsgrad? (Tägliche gemeinsame Projektarbeit spricht für Single-Tenant mit AU-Delegation; lose Holding-Struktur verträgt Trennung gut.)

Existiert ein realistisches Verkaufs-Szenario für einzelne Einheiten?

ℹ Faustregel für Konzernstrukturen Je zentraler die IT und je enger die tägliche Zusammenarbeit, desto stärker spricht alles für einen Tenant mit sauberer Binnentrennung (Administrative Units, RBAC, ggf. getrennte Domänen und Branding). Je autonomer die Einheiten in Verantwortung, Regulatorik und Schicksal, desto eher rechtfertigt sich die Trennung. Das Organigramm allein ist kein Architekturargument — die gelebte Verantwortung ist eines.

5.4 Kosmetik-Szenarien: viel Aufwand, wenig Wirkung

5.4.1 Trennung nach Organigramm bei identischer Betriebsmannschaft

Einordnung: Kosmetik — Kritikalität der Fehleinschätzung: hoch

Zwei oder mehr Tenants werden entlang der Organisationsstruktur gebildet („jede Sparte ihr Tenant“), aber dieselbe zentrale IT mit denselben Administratoren, denselben Verwaltungsgeräten und denselben Prozessen betreibt alle Tenants. Häufigstes Motiv: politisches Signal an die Bereichsleitungen oder diffuses Sicherheitsgefühl.

Vorteile	Nachteile
• Saubere optische Trennung in Portalen und Berichten • Bereichs-Eitelkeiten sind bedient	• Kein realer Blast-Radius-Gewinn: Ein kompromittierter Admin öffnet alle Tenants • n-facher Pflegeaufwand für identische Richtlinien • Konfigurationsdrift zwischen den Tenants als neues Sicherheitsrisiko • Kollaborationsreibung im Tagesgeschäft

 

Chancen	Risiken
• Ehrlicherweise: kaum welche, die nicht auch der Single-Tenant böte	• Trügerische Sicherheit — die gefährlichste Form von Unsicherheit • Betriebsteam ist chronisch überlastet, Qualität sinkt in allen Tenants • Audit-Befunde vervielfachen sich, weil jede Lücke n-fach existiert

 

Aufwand	Nutzen
• Hoch und dauerhaft: kompletter Mehrfachbetrieb • Zusätzlich: Werkzeuge und Prozesse für tenant-übergreifende Konsistenz	• Sicherheitstechnisch nahe null • Politisch: kurzfristige Zufriedenheit der Bereichsleitungen

 

Fazit: Das ist der Lehrbuchfall von Kosmetik: Die Grenze existiert auf dem Papier, aber jeder relevante Angriffspfad — Mensch, Gerät, Prozess — verläuft ungehindert durch alle Tenants. Dieselbe Investition in PIM, PAWs und Tiering im Single-Tenant würde ein Vielfaches an realer Sicherheit liefern.

 

5.4.2 Multi-Tenant mit Vollvernetzung („alle mit allen“)

Einordnung: Kosmetik mit Zusatzrisiko — Kritikalität: hoch

Die Tenants werden getrennt — und anschließend per Cross-Tenant Synchronization, großzügigen Cross-Tenant Access Settings und MTO so eng verflochten, dass jeder Benutzer überall arbeiten kann wie zuhause. Motiv: Man wollte Trennung und Komfort gleichzeitig, ohne den Zielkonflikt zu entscheiden.

Vorteile	Nachteile
• Kollaboration funktioniert im Alltag weitgehend reibungslos • Formal existieren getrennte Tenants (für Berichte, Zertifikats-Deckblätter, Organigramme)	• Die Sync– und Vertrauensbeziehungen reproduzieren tenant-übergreifend genau die Zugriffsbreite, die man trennen wollte • Jede Vertrauensbeziehung ist selbst Angriffsfläche und Fehlkonfigurationsquelle • Sicherheitsniveau des Verbunds = Niveau des schwächsten Tenants • Komplexität steigt, Transparenz sinkt: Wer darf was wo? Weiß irgendwann niemand mehr

 

Chancen	Risiken
• Kaum welche — der Komfort wäre im Single-Tenant genauso vorhanden, nur billiger	• Lateral Movement über Tenant-Grenzen hinweg via synchronisierte Identitäten und akzeptierte MFA-Claims • „Vertrauens-Vererbung“: Der schwächste Tenant wird zum Einstiegspunkt für alle • Niemand fühlt sich für die Grenz-Konfiguration insgesamt verantwortlich

 

Aufwand	Nutzen
• Sehr hoch: Mehrfachbetrieb plus Pflege des gesamten Vertrauens- und Sync-Geflechts	• Negativ bis null: mehr Angriffsfläche als ein Single-Tenant, bei höheren Kosten

 

Fazit: Der teuerste Weg, die Sicherheit eines Single-Tenants zu erreichen — oder zu unterbieten. Wer alle Brücken maximal öffnet, hat keine Multi-Tenant-Sicherheitsarchitektur, sondern einen fragmentierten Single-Tenant mit eingebautem Ratespiel.

 

5.4.3 Trennung aus Marken-, Domänen- oder Optik-Gründen

Einordnung: Kosmetik im Wortsinn — Kritikalität: gering, solange man es weiß

Getrennte Tenants, damit jede Marke „ihre“ Umgebung hat: eigene Anmeldeseite, eigenes Branding, eigene Domänenwelt. Sicherheitsargumente werden nachgeschoben, sind aber nicht der Treiber.

Vorteile	Nachteile
• Markenauftritt konsequent bis in die Anmeldemaske • Psychologische Eigenständigkeit der Einheiten	• Sämtliche Multi-Tenant-Betriebskosten für ein Ziel, das auch anders erreichbar wäre • Mehrere Domänen, Company Branding und getrennte Adressräume sind im Single-Tenant längst abbildbar

 

Chancen	Risiken
• Sauberer Startpunkt, falls später echte Trennungsgründe entstehen	• Das Sicherheits-Nachschieben führt zu falschen Erwartungen beim Management („wir sind doch getrennt!“)

 

Aufwand	Nutzen
• Hoch und dauerhaft — für ein primär ästhetisches Ziel	• Sicherheitstechnisch: gering. Markentechnisch: erreichbar, aber überteuert

 

Fazit: Legitim ist das nur, wenn alle Beteiligten wissen, dass sie Optik kaufen und nicht Sicherheit. Problematisch wird es, sobald die Trennung in Sicherheitskonzepten als Kontrolle auftaucht, die sie nicht ist.

 

5.4.4 Compliance-Theater: Trennung als Audit-Argument ohne technische Substanz

Einordnung: Kosmetik mit Haftungsrisiko — Kritikalität: hoch

Die Tenant-Trennung wird primär eingeführt, um in Audits, Ausschreibungen oder gegenüber Kunden „Mandantentrennung“ vorweisen zu können — während Admins, Geräte, Prozesse und großzügige Brücken die Trennung faktisch aufheben. Das Kontrollziel wird behauptet, nicht erreicht.

Vorteile	Nachteile
• Kurzfristig: das Häkchen im Fragebogen	• Die behauptete Kontrolle hält keiner ernsthaften technischen Prüfung stand • Diskrepanz zwischen dokumentierter und realer Architektur ist selbst ein Audit-Befund • Im Schadensfall: Erklärungsnot gegenüber Aufsicht, Versicherern und Kunden

 

Chancen	Risiken
• Keine, die diesen Namen verdienen	• Haftungs- und Reputationsrisiko, wenn die Lücke zwischen Papier und Realität offenbar wird — und sie wird es, spätestens beim ersten Incident

 

Aufwand	Nutzen
• Voller Multi-Tenant-Aufwand plus Aufwand für die Aufrechterhaltung der Fassade	• Negativ: Kosten plus Risiko, ohne Sicherheitssubstanz

 

Fazit: Die gefährlichste Variante, weil sie nicht nur nichts bringt, sondern aktiv Vertrauen bindet, das im Ernstfall nicht gedeckt ist. Wer Mandantentrennung zusagt, muss sie auch an den Brücken, bei den Menschen und auf den Geräten liefern.

 

5.5 Gesamtschau

Skizze 3: Einordnung der Szenarien nach Sicherheitsnutzen und Zusatzaufwand

Szenario	Sicherheitsnutzen	Aufwand	Einstufung
Getrennte Regulatorik / Souveränität / Residenz	Hoch (alternativlos)	Hoch	Echter Gewinn
Getrennte Admin-Populationen + Risikoprofile	Hoch (bedingungsgebunden)	Hoch	Echter Gewinn — nur mit gelebter personeller Trennung
M&A / Carve-out mit konkretem Horizont	Hoch (strukturell)	Mittel–hoch	Echter Gewinn
Dev-/Test-/Demo-Tenant	Hoch (relativ zum Aufwand)	Gering–mittel	Echter Gewinn — Standardempfehlung
Konzern mit selbstständigen Töchtern	Fallabhängig	Hoch	Grauzone — Einzelfallbewertung nach Kap. 6
Trennung nach Organigramm, gleiche Betriebsmannschaft	Nahe null	Hoch	Kosmetik
Multi-Tenant mit Vollvernetzung	Null bis negativ	Sehr hoch	Kosmetik mit Zusatzrisiko
Marken-/Domänen-Optik	Gering	Hoch	Kosmetik (legitim nur bei ehrlicher Deklaration)
Compliance-Theater	Negativ	Hoch	Kosmetik mit Haftungsrisiko

 

 

6 Aktionsplan: Das Entscheidungs-Framework

Dieses Kapitel übersetzt die Analysebefunde in einen konkreten, schrittweisen Entscheidungsprozess. Er ist bewusst so gebaut, dass er an mehreren Stellen mit einem klaren „Stopp — Single-Tenant reicht“ enden kann. Das ist kein Scheitern des Prozesses, sondern sein günstigstes Ergebnis.

Schritt 1: Schutzziele und Bedrohungsmodell festlegen

Priorität: Kritisch · Ziel: Präzise benennen, wovor die Trennung schützen soll — bevor über Architektur gesprochen wird.

1.1 Konkrete Bedrohungsszenarien formulieren: Admin-Kompromittierung, Ransomware, Innentäter, regulatorischer Verstoß, fehlerhafte Massenänderung. „Mehr Sicherheit“ ist kein Szenario, sondern ein Wunsch.

1.2 Je Szenario festhalten: Welcher Schaden soll auf welchen Bereich begrenzt werden?

1.3 Schutzziele priorisieren und vom Management freigeben lassen — schriftlich, damit später niemand ein anderes Ziel erinnert.

Erfolgskriterium: Eine Liste von maximal fünf priorisierten, konkreten Schutzzielen existiert und ist abgenommen.

Exit-/Abbruchkriterium: Wenn kein Schutzziel formuliert werden kann, das über ein Bauchgefühl hinausgeht: Prozess beenden, Single-Tenant härten.

 

Schritt 2: Ist-Aufnahme der Identitäts- und Admin-Realität

Priorität: Kritisch · Ziel: Die Faktoren erheben, die über Wirkung oder Wirkungslosigkeit der Tenant-Grenze entscheiden.

2.1 Administratoren-Inventur: Wer administriert heute was, mit welchen Konten, von welchen Geräten? Gibt es getrennte PAWs, PIM, ein Tiering-Modell?

2.2 Identitätsquellen dokumentieren: Ein gemeinsames On-Premises-AD? Entra Connect / Cloud Sync wohin?

2.3 Endgeräte-Realität: Würden künftig dieselben Clients auf mehrere Tenants zugreifen?

2.4 Bestehende B2B-Beziehungen und externe Vertrauensstellungen inventarisieren.

Erfolgskriterium: Ein belastbares Bild existiert, wer künftig in welchem Tenant mit welchen Geräten arbeiten würde.

Exit-/Abbruchkriterium: Wenn feststeht, dass dieselben Admins mit denselben Geräten alle Tenants betreuen würden und daran nichts änderbar ist: Multi-Tenant als Sicherheitsmaßnahme verwerfen (Kosmetik-Szenario 5.4.1).

 

Schritt 3: Kollaborationsbedarf quantifizieren

Priorität: Hoch · Ziel: Ermitteln, wie viele und wie tiefe Brücken die Trennung sofort wieder bräuchte.

3.1 Reale Zusammenarbeit zwischen den zu trennenden Bereichen messen: gemeinsame Teams, geteilte Postfächer, gemeinsame Dateiräume, Kalenderzugriffe, gemeinsame Anwendungen.

3.2 Für jede Zusammenarbeitsform klären: Funktioniert sie über Tenant-Grenzen — und mit welcher Reibung?

3.3 Den künftigen Brückenbedarf klassifizieren: wenige, eng begrenzte Brücken vs. flächendeckende Vollvernetzung.

Erfolgskriterium: Der Brückenbedarf ist dokumentiert und klassifiziert.

Exit-/Abbruchkriterium: Wenn der Bedarf auf Vollvernetzung hinausläuft (praktisch jeder mit jedem): Prozess beenden — das Ergebnis wäre Szenario 5.4.2, teurer als Single-Tenant und nicht sicherer.

 

Schritt 4: Single-Tenant-Alternative ausarbeiten

Priorität: Hoch · Ziel: Für jedes Schutzziel aus Schritt 1 prüfen, ob es innerhalb eines Tenants erreichbar ist.

4.1 Je Schutzziel die Binnenwerkzeuge durchdeklinieren: RBAC mit scoped Rollen, Administrative Units, PIM, Tiering + PAWs, Conditional Access, Sensitivity Labels, Information Barriers.

4.2 Aufwand der Single-Tenant-Härtung schätzen (einmalig + laufend).

4.3 Ergebnis je Schutzziel festhalten: „im Single-Tenant erreichbar“, „teilweise erreichbar“, „nicht erreichbar“.

Erfolgskriterium: Eine ehrliche Gegenüberstellung existiert. Mindestens ein priorisiertes Schutzziel ist im Single-Tenant nachweislich nicht erreichbar — sonst gibt es keinen Sicherheitsgrund für Multi-Tenant.

Exit-/Abbruchkriterium: Wenn alle Schutzziele im Single-Tenant erreichbar sind: Prozess hier beenden und das Budget in die Single-Tenant-Härtung investieren. Das ist der häufigste — und meist beste — Ausgang.

 

Schritt 5: Brücken-Design und Grenzregime festlegen

Priorität: Kritisch (nur bei Fortführung) · Ziel: Vor der Entscheidung definieren, wie offen die Grenze sein wird — nicht hinterher.

5.1 Cross-Tenant Access Settings als restriktives Grundregime entwerfen: Default deny, explizite Freigaben je Partner-Tenant, je Benutzergruppe, je Anwendung.

5.2 Entscheiden, ob und in welchem Umfang Cross-Tenant Synchronization eingesetzt wird — inklusive Lifecycle (wer räumt Objekte wieder ab?).

5.3 MFA-/Gerätestatus-Vertrauen bewusst entscheiden und begründen.

5.4 Verantwortlichkeit für das Grenzregime benennen: eine Rolle, die die Gesamtsicht über alle Vertrauensbeziehungen hat.

5.5 Getrennte Break-Glass-Konzepte je Tenant definieren.

Erfolgskriterium: Ein dokumentiertes, restriktives Grenzregime mit benannter Verantwortlichkeit liegt vor der Tenant-Entscheidung vor.

Exit-/Abbruchkriterium: Wenn sich kein Verantwortlicher für das Grenzregime findet oder das Regime im Entwurf bereits auf „alles offen“ hinausläuft: zurück zu Schritt 3/4.

 

Schritt 6: Aufwands- und TCO-Betrachtung

Priorität: Hoch · Ziel: Die dauerhafte Kostenrealität transparent machen — vor dem Beschluss.

6.1 Betriebsaufwand je Tenant kalkulieren (Richtlinienpflege, Monitoring, Patch-/Feature-Nachführung, Audits) — mit Personen und Stellenanteilen, nicht mit „das machen wir mit“.

6.2 Lizenzeffekte durchrechnen: verlorene Volumeneffekte, doppelte Add-ons, Testlizenzen.

6.3 Kollaborationsreibung als Kostenfaktor mindestens qualitativ bewerten.

6.4 Gegenrechnung: Was würde dieselbe Investition an Single-Tenant-Härtung erreichen?

Erfolgskriterium: Eine mehrjährige TCO-Gegenüberstellung Multi-Tenant vs. gehärteter Single-Tenant liegt vor.

Exit-/Abbruchkriterium: Wenn der Dauerbetrieb personell nicht darstellbar ist: abbrechen. Ein unterbesetzter Multi-Tenant-Betrieb ist unsicherer als ein gut betriebener Single-Tenant.

 

Schritt 7: Entscheidung, Pilot und Nachprüfung

Priorität: Hoch · Ziel: Entscheiden — und die Entscheidung überprüfbar machen.

7.1 Architekturentscheidung mit Begründung je Schutzziel dokumentieren (Architecture Decision Record).

7.2 Bei Multi-Tenant: mit dem risikoärmsten Kandidaten beginnen (typisch: Dev/Test oder der regulierte Teilbereich), Erfahrungen auswerten, erst dann skalieren.

7.3 Nachprüfung nach 12 Monaten fest einplanen: Wird die personelle Trennung gelebt? Ist das Grenzregime noch restriktiv? Stimmen die Aufwandsannahmen?

7.4 Rückbau-Option offenhalten: dokumentieren, unter welchen Bedingungen konsolidiert würde.

Erfolgskriterium: Entscheidung, Pilot-Auswertung und ein terminierter Review-Zyklus sind dokumentiert.

Exit-/Abbruchkriterium: Wenn die 12-Monats-Nachprüfung zeigt, dass Brücken und Personalunion die Trennung faktisch aufgehoben haben: Konsolidierung ernsthaft prüfen, statt die Fassade weiterzufinanzieren.

 

ℹ Warum so viele Ausstiegspunkte? Weil die Multi-Tenant-Entscheidung asymmetrisch ist: Ein zu Unrecht getrennter Betrieb kostet jahrelang Geld und Nerven und ist nur mit erheblichem Migrationsaufwand rückholbar. Ein zu Unrecht nicht getrennter Betrieb lässt sich später immer noch trennen — mit demselben Aufwand, aber besserer Begründung. Im Zweifel gewinnt daher der Single-Tenant mit konsequenter Härtung.

 

7 Risiken

Beide Architekturpfade tragen Risiken. Ein Entscheidungsdokument, das nur die Risiken des jeweils ungeliebten Pfads auflistet, ist Werbung — deshalb hier beide Seiten.

7.1 Risiken einer Multi-Tenant-Entscheidung

Risiko	Eintritt	Auswirkung	Gegenmaßnahme
Schleichende Personalunion der Admins hebt den Blast-Radius-Gewinn auf	Hoch	Hoch	Personelle Trennung vertraglich/organisatorisch verankern; jährlicher Review (Schritt 7)
Konfigurationsdrift zwischen Tenants erzeugt ungleiches Schutzniveau	Hoch	Mittel–hoch	Policy-as-Code / dokumentierte Baselines, regelmäßiger Konfigurationsvergleich
Brücken werden aus Komfortdruck schrittweise geöffnet	Hoch	Hoch	Grenzregime mit benannter Verantwortung, Änderungen nur mit Sicherheitsfreigabe
Betriebsteam unterdimensioniert, Qualität sinkt in allen Tenants	Mittel	Hoch	TCO-Rechnung mit Stellenanteilen vor Beschluss; Abbruchkriterium Schritt 6
Schatten-IT durch Kollaborationsreibung	Mittel	Mittel	Reibungsarme, offizielle Kollaborationspfade priorisiert bereitstellen
Gemeinsames Quell-AD bleibt gemeinsames Tier 0	Mittel	Hoch	AD-Härtung priorisieren; langfristig Identitätsquellen entflechten

 

7.2 Risiken einer Single-Tenant-Entscheidung

Risiko	Eintritt	Auswirkung	Gegenmaßnahme
Tenantweiter Blast Radius bei Kompromittierung der höchsten Privilegienebene	Gering–mittel	Sehr hoch	PIM, Tiering, PAWs, Break-Glass-Härtung, restriktive Global-Admin-Vergabe
Regulatorische Anforderungen einzelner Bereiche verschärfen sich nachträglich	Mittel	Mittel–hoch	Regulatorik-Monitoring; Trennungsoption als dokumentierter Plan B
Späterer Carve-out erfordert aufwendige Tenant-to-Tenant-Migration	Fallabhängig	Mittel	Saubere Datenstrukturen und Metadaten von Anfang an; Entflechtbarkeit mitdenken
Binnentrennung (AU/RBAC) wird nicht konsequent gepflegt	Mittel	Mittel	Governance-Prozess mit regelmäßigem Access Review

 

⚠ Das übergreifende Risiko: die falsche Begründung Das größte Risiko liegt nicht in der Architektur, sondern in der Begründung. Eine Multi-Tenant-Landschaft, die als Sicherheitsmaßnahme verkauft wurde, aber keine ist, blockiert Budget und Aufmerksamkeit für Maßnahmen, die tatsächlich wirken würden. Umgekehrt wiegt sich ein Single-Tenant ohne Tiering und PIM in einer Geschlossenheit, die bei der ersten Admin-Kompromittierung zur Vollkatastrophe wird. Beide Fehler haben dieselbe Wurzel: Architektur nach Gefühl statt nach Bedrohungsmodell.

 

8 Offene Punkte

Da dieses Dokument bewusst keinen konkreten Fall betrachtet, sind die offenen Punkte als Klärungsliste für die Anwendung auf eine reale Umgebung formuliert. Sie entsprechen den Informationsbedarfen des Entscheidungs-Frameworks aus Kapitel 6.

Nr.	Offener Punkt	Zuständig (typisch)	Benötigt für
OP-1	Priorisierte Schutzziele und akzeptierte Restrisiken	Geschäftsführung / CISO	Schritt 1
OP-2	Vollständige Admin- und Konten-Inventur inkl. Geräteausstattung	IT-Betrieb	Schritt 2
OP-3	Identitätsquellen und Sync-Topologie (AD, Entra Connect, Cloud Sync)	IT-Architektur	Schritt 2
OP-4	Messung der realen Kollaborationsbeziehungen zwischen den Bereichen	IT-Betrieb / Fachbereiche	Schritt 3
OP-5	Regulatorische Anforderungen je Organisationseinheit (aktuell + absehbar)	Compliance / Recht	Schritt 1, 4
OP-6	Transaktions-/Carve-out-Perspektiven der nächsten 3–5 Jahre	Geschäftsführung	Kap. 5.2.3
OP-7	Personalverfügbarkeit für dauerhaft getrennten Betrieb	IT-Leitung / HR	Schritt 6
OP-8	Lizenzsituation und Vertragsstruktur (EA/CSP, Volumeneffekte)	Einkauf / IT-Leitung	Schritt 6
OP-9	Verantwortlichkeit für ein künftiges Grenzregime	CISO / IT-Leitung	Schritt 5

 

 

9 Anhang

9.1 Checkliste: Zehn Fragen vor jeder Tenant-Trennung

1. Welche konkreten Angriffe oder Fehler soll die Trennung eindämmen — und würde sie das in unserer Realität tatsächlich tun?

2. Werden die Tenants von getrennten Menschen mit getrennten Geräten administriert — dauerhaft und verbindlich?

3. Hängen die Tenants an einer gemeinsamen Identitätsquelle (On-Premises-AD)? Falls ja: Ist uns bewusst, dass diese Quelle das gemeinsame Tier 0 bleibt?

4. Wie viele Brücken (Sync, Gäste, Vertrauensstellungen) brauchen wir ab Tag eins — und wer verantwortet ihre Restriktivität?

5. Gibt es mindestens ein Schutzziel, das im Single-Tenant nachweislich nicht erreichbar ist?

6. Haben wir RBAC, Administrative Units, PIM, Tiering und PAWs im Single-Tenant bereits ausgereizt — oder kaufen wir Trennung als Ersatz für unerledigte Hausaufgaben?

7. Können wir den n-fachen Betrieb mit Namen und Stellenanteilen hinterlegen — auch in drei Jahren noch?

8. Was kostet dieselbe Investition an Härtung im Single-Tenant — und was würde sie bringen?

9. Wie und wann überprüfen wir, ob die Trennung noch wirkt (personelle Trennung, Grenzregime, Drift)?

10. Unter welchen Bedingungen würden wir konsolidieren — und ist dieser Rückweg dokumentiert?

 

9.2 Glossar

Begriff	Bedeutung
Tenant	Dedizierte, isolierte Instanz von Entra ID mit zugehörigen Microsoft-365-Diensten; Identitäts-, Verwaltungs- und Richtliniengrenze.
Blast Radius	Ausbreitungsradius eines erfolgreichen Angriffs oder Fehlers — der Bereich, der maximal betroffen sein kann.
B2B Collaboration	Einladung externer Identitäten als Gastobjekte in einen Tenant.
Cross-Tenant Access Settings	Regelwerk, welchen fremden Tenants unter welchen Bedingungen ein- und ausgehend vertraut wird (inkl. MFA-/Gerätestatus-Vertrauen).
Cross-Tenant Synchronization	Automatisiertes Provisioning von Benutzern eines Tenants als B2B-Objekte in einem anderen Tenant.
Multi-Tenant Organization (MTO)	Verbund mehrerer Tenants für nahtlose organisationsübergreifende Zusammenarbeit (u. a. Teams, People Search).
Administrative Unit (AU)	Container in Entra ID zur Delegation administrativer Rechte auf Teilmengen von Benutzern, Gruppen und Geräten.
PIM	Privileged Identity Management — zeitlich begrenzte, genehmigungspflichtige Aktivierung privilegierter Rollen.
PAW	Privileged Access Workstation — dediziertes, gehärtetes Verwaltungsgerät für privilegierte Tätigkeiten.
Tiering	Schichtenmodell privilegierter Zugriffe (Tier 0/1/2) mit strikter Trennung von Konten und Geräten je Schicht.
Break-Glass-Konto	Hochprivilegiertes Notfallkonto außerhalb der regulären Anmeldemechanismen, streng überwacht und regelmäßig getestet.
Tier 0	Die Schicht mit direkter oder indirekter Kontrolle über die gesamte Identitätsinfrastruktur — wer Tier 0 kontrolliert, kontrolliert alles Nachgelagerte.
Carve-out	Herauslösung einer Organisationseinheit aus einem Unternehmen, z. B. für Verkauf oder Verselbstständigung.
Konfigurationsdrift	Schleichendes Auseinanderlaufen eigentlich identisch gedachter Konfigurationen mehrerer Umgebungen.

 

9.3 Faustregeln zum Mitnehmen

✓ Fünf Sätze für den Flurfunk 1. Die Tenant-Grenze trennt Identitäten, Verwaltung und Richtlinien — nicht Menschen, Geräte und Prozesse. 2. Sicherheitsgewinn = Härte der Grenze × Disziplin an den Brücken. Ein Faktor null macht das Produkt null. 3. Wer im Single-Tenant kein Tiering hinbekommt, bekommt im Multi-Tenant zwei Umgebungen ohne Tiering. 4. Dev/Test gehört fast immer in einen eigenen Tenant. Fast alles andere ist begründungspflichtig. 5. Die ehrlichste Architekturfrage lautet: Wer betreibt das — mit Namen und Stellenanteil, auch übermorgen noch?

 

— Ende des Dokuments —