Identitätsmanagement für Multi-Mandanten-Architekturen B2B vs. Multi-Tenant-Ansätze: Wann eignet sich welches Modell?

Die Verwaltung von Identitäten in einer Multi-Tenant-Umgebung stellt Unternehmen vor komplexe Herausforderungen. Ein durchdachtes Identitätsmanagement ist jedoch entscheidend für den Erfolg in der Cloud. Der Beitrag zeigt Lösungsansätze und Möglichkeiten.

Die Verwaltung von Identitäten und Ressourcen in einer Multi-Tenant-Umgebung stellt Unternehmen vor große Herausforderungen. Microsoft bietet mit Entra ID und Azure verschiedene Ansätze, um Mandantenstrukturen effizient zu betreiben. Besonders die Einführung der Multi-Tenant-Organisation in Entra ID und die erweiterten Funktionen von Entra Connect ermöglichen eine vereinfachte Synchronisation und Authentifizierung in komplexen IT-Landschaften. Zusatztools können dabei helfen, mehr Ordnung in das System zu bringen sowie die Synchronisierung zu vereinfachen.

Entra ID Multi-Tenant-Organisation: Verbesserte Zusammenarbeit und Identitätsverwaltung

Bildergalerie

Bildergalerie mit 5 Bildern

Unternehmen mit mehreren Azure Entra ID Tenants, sei es durch Fusionen, Übernahmen oder bewusste Isolation einzelner Bereiche, stehen vor Herausforderungen bei der Identitätsverwaltung. Nutzer erscheinen solchen Szenarien in Microsoft Teams und andere Diensten oft doppelt: Einmal als externer Kontakt mit dem Hinweis "(extern)" und ein weiteres Mal als "Gast", wenn sie für den Zugriff auf Ressourcen eingeladen wurden. Diese Fragmentierung führt zu Verwirrung, erschwert die Kommunikation und zwingt Anwender dazu, zwischen Tenants zu wechseln, um Nachrichten und Meetings zu sehen.

Die Multi-Tenant-Organisation in Entra ID löst dieses Problem durch eine zentrale Verwaltung aller Tenants unter einem gemeinsamen organisatorischen Dach. Ein Tenant fungiert als Owner, während andere Tenants beitreten können. Microsoft Teams und andere Dienste, auch in Microsoft 365, zeigen nun nur noch eine einzige, "echte" Identität pro Nutzer an. Dadurch wird nicht nur das Nutzererlebnis verbessert, sondern auch die Synchronisation zwischen Tenants vereinfacht. Die integrierte Cross-Tenant-Synchronisation sorgt automatisch dafür, dass Nutzer in allen verbundenen Tenants als Gäste hinzugefügt werden, ohne dass eine manuelle Verwaltung erforderlich ist.

Zusätzlich können Lösungen wie RealIdentity von FirstAttribute die Verwaltung in Multi-Tenant-Umgebungen weiter optimieren. Die Plattform ermöglicht eine zentrale Steuerung von Identitäten über verschiedene Tenants hinweg. Da RealIdentity externe Identitäten direkt integriert, kann es auch B2B-Zugriffsmodelle verbessern, indem das Tool die Authentifizierung über mehrere Tenants hinweg gewährleistet. So profitieren Unternehmen von einer konsistenten und übersichtlichen Identitätsverwaltung, während Nutzer ohne Umwege oder manuelle Eingriffe auf alle relevanten Ressourcen zugreifen können.

Mit der Multi-Tenant-Synchronisation in Entra Connect ist es außerdem möglich, ein einzelnes Active Directory-Objekt (Benutzer, Gruppen, Geräte) mit mehreren Azure Entra Tenants zu synchronisieren. Während zuvor eine 1:1-Zuordnung erforderlich war, entfällt in aktuellen Versionen das manuelle Anlegen von Benutzern in verschiedenen Tenants. Zudem werden Kennwort-Hashes mit allen synchronisierten Tenants geteilt, sodass sich Benutzer mit demselben Passwort in mehreren Umgebungen anmelden können.

B2B vs. Multi-Tenant-Anwendungen in Entra ID

Die Entscheidung zwischen B2B-Kollaboration und einer echten Multi-Tenant-Architektur hängt stark von den Anforderungen an Identitätsmanagement und Zugriffskontrolle ab. B2B-Gäste haben keine eigenen Anmeldeinformationen im Ziel-Tenant, sondern authentifizieren sich über ihren eigenen Tenant oder externe Identitätsanbieter. Im Gegensatz dazu erfordern Multi-Tenant-Anwendungen Service-Principals in jedem Tenant, der die App nutzt, was den administrativen Aufwand erhöht.

Ein weiterer entscheidender Unterschied besteht in den Zugriffsmöglichkeiten: B2B-Accounts können nicht auf Ressourcen in ihrem eigenen Tenant zugreifen, während Multi-Tenant-Apps diese Möglichkeit bieten. In B2B-Szenarien kann der Admin des Ziel-Tenants Gastkonten zentral verwalten, während Multi-Tenant-Apps Nutzer aus vielen Tenants direkt authentifizieren können.

Architekturmodelle für Multi-Tenant-Umgebungen in Azure

Je nach Anforderungen kommen unterschiedliche Isolationsebenen zum Einsatz:

• Vollständig dedizierte Deployments pro Tenant bieten maximale Isolation, sind jedoch teuer.

• Horizontale Partitionierung erlaubt es, dass sich einige Tenants Infrastrukturen teilen, während andere dedizierte Ressourcen erhalten.

• Geteilte Infrastruktur mit separaten Datenbanken pro Tenant kombiniert Effizienz mit gewisser Isolation.

• Volle Mandantenfähigkeit mit gemeinsamer Datenhaltung nutzt eine strikte logische Trennung auf Applikationsebene.

Die Wahl des richtigen Modells beeinflusst sowohl Skalierbarkeit als auch Sicherheit. Herausforderungen wie „Noisy Neighbors“, also Performance-Probleme durch übermäßige Ressourcennutzung einzelner Tenants, müssen dabei berücksichtigt werden.

Skalierungs- und Kostenherausforderungen in Multi-Tenant-Umgebungen

Ein zentrales Problem bei der Skalierung sind Azure-Subscription-Limits, wie die maximale Anzahl von 980 Resource Groups pro Subscription. Um dies zu umgehen, müssen Ressourcen strategisch auf verschiedene Subscriptions verteilt werden. Die Verwaltung von Kosten in einer Multi-Tenant-Umgebung ist ein wichtiger Faktor, um wirtschaftlich nachhaltig zu operieren und gleichzeitig eine hohe Servicequalität sicherzustellen. Eine effektive Methode zur Kostenkontrolle besteht in der Kombination aus Tagging, API-Monitoring und Tenant-spezifischer Ressourcenzuordnung.

Tagging ermöglicht es, Cloud-Ressourcen mit Metadaten zu versehen, sodass sie bestimmten Tenants oder Geschäftsbereichen zugeordnet werden können. In Azure können Tags wie "Tenant-ID", "Abteilung" oder "Kostenstelle" verwendet werden, um eine detaillierte Abrechnung und Analyse der genutzten Ressourcen zu ermöglichen. Dadurch lassen sich Kosten transparent aufschlüsseln und einzelne Tenants verursachungsgerecht abrechnen.

API-Monitoring spielt eine entscheidende Rolle bei der Überwachung von Ressourcennutzung und Performance. Durch den Einsatz von Telemetrie- und Logging-Diensten wie Azure Monitor oder Application Insights können Unternehmen nachverfolgen, wie viele Anfragen pro Tenant eingehen, wie hoch die Last auf gemeinsam genutzten Ressourcen ist und ob einzelne Tenants überproportional viele Ressourcen beanspruchen. Das ist besonders wichtig, um frühzeitig "Noisy Neighbors" zu identifizieren, also Tenants, die durch hohe Lasten andere Nutzer negativ beeinflussen könnten.

Die Tenant-spezifische Ressourcenzuordnung ermöglicht eine feinere Steuerung der Infrastruktur. Je nach Anforderungen können bestimmte Tenants dedizierte Ressourcen erhalten, während andere auf gemeinsam genutzte Instanzen zugreifen. So können etwa Premium-Kunden eine eigene Datenbank oder exklusive Compute-Ressourcen erhalten, während kleinere Kunden sich eine gemeinsam genutzte Infrastruktur teilen.

Neben der reinen Kostenkontrolle ist die dynamische Skalierung der Infrastruktur entscheidend für eine effiziente Nutzung von Cloud-Ressourcen. Auto-Scaling sorgt dafür, dass sich Rechenkapazitäten automatisch an das aktuelle Lastverhalten anpassen. In Azure lassen sich Skalierungsregeln definieren, die bei hoher CPU- oder Speichernutzung automatisch zusätzliche Instanzen bereitstellen und bei geringer Last wieder herunterfahren. Das reduziert unnötige Kosten und stellt sicher, dass immer ausreichend Kapazitäten vorhanden sind.

Ein weiteres zentrales Konzept ist das Ressourcen-Sharding, das eine gezielte Verteilung von Tenants auf verschiedene Infrastruktur-Komponenten ermöglicht. Zum Beispiel kann eine große Anzahl an Tenants über mehrere Datenbanken oder Compute-Cluster verteilt werden, um Lastspitzen auszugleichen und die Skalierbarkeit zu erhöhen. Durch ein intelligentes Sharding lassen sich Skalierungsgrenzen einzelner Ressourcen umgehen und eine gleichmäßige Verteilung der Arbeitslast gewährleisten.

Beispiel: Kubernetes-Architektur für Multi-Tenant-Deployments

Azure Kubernetes Service (AKS) bietet in diesem Zusammenhang sowohl physische als auch logische Isolation für Multi-Tenant-Umgebungen. Namespace-basierte Mandantentrennung mit rollenbasierter Zugriffskontrolle (RBAC) und Netzwerkrichtlinien stellt sicher, dass einzelne Tenants isoliert bleiben. Zusätzlich lassen sich Ressourcenbegrenzungen pro Namespace konfigurieren, um "Noisy Neighbor"-Effekte zu vermeiden. Kosten können mit Tools wie Kubecost transparent auf einzelne Tenants umgelegt werden.

RealIdentity als zentrale Lösung für Identitätsmanagement

RealIdentity bietet eine zentrale Identitätsverwaltung, die speziell auf die Herausforderungen in Multi-Tenant-Umgebungen ausgelegt ist. Eine der größten Schwierigkeiten ist die Verwaltung von Nutzern über mehrere Tenants hinweg, insbesondere wenn sich Unternehmen mit fragmentierten Identitätssilos konfrontiert sehen. RealIdentity löst dieses Problem, indem es Identitäten aus verschiedenen Tenants konsolidiert und eine einheitliche Authentifizierung ermöglicht.

Gerade im Zusammenspiel mit Microsoft Entra ID kann RealIdentity die Multi-Tenant-Synchronisation effizient unterstützen. Durch die automatische Verwaltung von Gastnutzern und die Vermeidung doppelter Identitäten erleichtert es die Zusammenarbeit über Tenant-Grenzen hinweg. Das reduziert den Verwaltungsaufwand und erhöht die Sicherheit, da jeder Benutzer nur eine einzige, zentral verwaltete Identität erhält.

Auch im Bereich der Compliance und des Kostenmanagements bietet RealIdentity Vorteile. Die mandantenübergreifende Verwaltung von Zugriffsrechten ermöglicht eine präzisere Kontrolle über Berechtigungen, was insbesondere für Unternehmen mit strengen regulatorischen Anforderungen wichtig ist. Gleichzeitig erleichtert RealIdentity die Abrechnung und Kostenverteilung, indem es Identitäts- und Nutzungsdaten transparent macht.

(ID:50391461)