Mandantenfähigkeit im LMS: Wann Gruppen nicht mehr reichen

„Mandantenfähig“ gehört zu den Anforderungen, die in einem LMS-Kriterienkatalog schnell mit einem Häkchen erledigt sind. Das ist bequem – und erstaunlich unpräzise.

Ein System kann mehrere Unternehmen unter einer gemeinsamen Oberfläche führen. Es kann für jede Organisation eigene Administratoren, Nutzer und Inhalte besitzen. Es kann Daten logisch in derselben Datenbank trennen oder für einzelne Kunden eine eigene technische Umgebung betreiben. All diese Varianten werden im Markt als Multi-Tenancy oder Mandantenfähigkeit bezeichnet.

Für die Auswahl hilft das Wort deshalb erst, wenn klar ist, welche Grenze tatsächlich gebraucht wird. Die entscheidende Frage lautet nicht, ob ein LMS „mandantenfähig“ ist, sondern welche Daten, Rechte, Konfigurationen und Prozesse zwischen zwei Organisationen getrennt bleiben müssen – und wie diese Trennung geprüft wird.

Das führt zu einer zweiten Korrektur: Eine eigene Datenbank oder Instanz pro Kunde kann eine sehr starke Form der Isolation sein. Sie ist aber nicht die Definition eines Mandanten. Ebenso wenig wird aus einer Benutzergruppe automatisch ein Mandant, nur weil sie ein eigenes Logo sieht.

Ein Mandant ist keine Benutzergruppe mit Logo

In einem normalen Organisationsmodell dürfen Grenzen bewusst durchlässig sein. Eine zentrale Personalentwicklung sieht mehrere Standorte. Ein Konzernadministrator weist einen Kurs an verschiedene Gesellschaften aus. Führungskräfte sehen ihre Teams, während die zentrale Administration organisationsübergreifend arbeitet.

Dafür können Gruppen, Organisationseinheiten und Rollen völlig ausreichen. Sie strukturieren Benutzer und Berechtigungen innerhalb eines gemeinsamen Verantwortungsraums.

Ein Mandant wird erst dort interessant, wo eine Organisation als eigener Kontext behandelt werden soll. AWS beschreibt einen Tenant ausdrücklich nicht als einzelnen Benutzer, sondern als eigenen Kunden- beziehungsweise Organisationskontext, dem typischerweise viele Benutzer zugeordnet sind. Dieser Kontext muss bei Zugriffen mitgeführt werden, damit Ressourcen des einen Tenants nicht beim anderen landen.

Für ein LMS ist das mehr als Technik. Ein Kundenadministrator soll vielleicht selbst Benutzer anlegen, Zuweisungen verwalten und Reports exportieren. Er soll das aber ausschließlich für seine Organisation können. Ein Partner soll eigene Inhalte ergänzen dürfen, ohne dadurch fremde Akademiebereiche zu sehen. Eine Konzernzentrale braucht dagegen womöglich bewusst eine übergreifende Sicht.

Damit unterscheiden sich zwei Fragen, die in Lastenheften häufig zusammenfallen: Wer darf innerhalb eines Bereichs was tun? Und wo endet der Bereich selbst?

Isolation endet nicht beim Login

Single Sign-on, Rollen und Berechtigungen sind wichtig. Sie beweisen für sich genommen aber keine Mandantentrennung.

AWS trennt diese Ebenen ausdrücklich. Ein Benutzer kann korrekt authentifiziert und für eine Funktion autorisiert sein und trotzdem auf eine Ressource des falschen Tenants zugreifen, wenn die Anwendung den Tenant-Kontext beim Zugriff nicht zusätzlich durchsetzt. Tenant Isolation soll genau diesen mandantenübergreifenden Zugriff verhindern.

Das ist für Lernplattformen ein nützlicher Realitätscheck. Ein Administrator von Kunde A darf die Funktion „Benutzer anzeigen“ besitzen. Die Funktion ist legitim. Problematisch wird es, wenn seine Suche auch einen Benutzer von Kunde B liefert. Dasselbe gilt für Kurszuweisungen, Zertifikate, Lernhistorien, Reports, Exporte oder API-Aufrufe.

NIST SP 800-210 behandelt Zugriffskontrolle in SaaS ebenfalls als mehrschichtiges Problem. Die Publikation weist darauf hin, dass Autorisierung zentral, dezentral oder hybrid organisiert sein kann und dass unterschiedliche Tenants unterschiedliche Rollen- oder Attributmodelle benötigen können. Für eine LMS-Auswahl folgt daraus keine bestimmte Architektur. Aber es folgt eine Anforderung: Die Plattform muss den jeweiligen Organisationskontext in ihren Zugriffsentscheidungen zuverlässig berücksichtigen.

Eine Rollenmatrix beantwortet also nur einen Teil der Frage. Mandantenfähigkeit braucht zusätzlich eine belastbare Antwort auf: Für welchen Tenant gilt diese Rolle gerade?

Drei Ebenen, die in Ausschreibungen oft vermischt werden

Mandantenfähigkeit liegt nicht auf einer einzigen technischen Skala. Für die Beschaffung hilft trotzdem eine grobe Trennung von drei Betriebsbildern. Sie sind keine Norm, sondern eine redaktionelle Entscheidungshilfe aus den Architekturmustern von NIST, AWS, OWASP und Microsoft.

Der wichtige Punkt steckt in der Mitte. Ein logisch isolierter Tenant kann auf gemeinsamer Infrastruktur sauber getrennt sein. Eine eigene Deployment-Umgebung kann umgekehrt zusätzliche Isolation schaffen, erzeugt aber auch zusätzlichen Betriebsaufwand.

Microsofts Azure Architecture Center beschreibt Isolation deshalb als Spektrum. Einzelne Schichten können gemeinsam genutzt werden, während andere getrennt sind. Eine gemeinsame Anwendung kann beispielsweise auf tenant-spezifische Datenbanken zugreifen. Ebenso sind vollständig dedizierte oder weitgehend gemeinsam genutzte Modelle möglich.

Für einen LMS-Einkäufer ist die technische Umsetzung interessant. Die fachliche Anforderung sollte aber zuerst beschreiben, welche Grenze das Ergebnis erfüllen muss.

Welche Grenze ein LMS tatsächlich trennen muss

Bei Lernplattformen entsteht Mandantentrennung nicht an einer einzigen Stelle. Sie muss über mehrere Objekt- und Prozessarten hinweg konsistent bleiben.

Benutzer und Lernhistorie

Der offensichtlichste Bereich sind personenbezogene Daten: Profile, Gruppenmitgliedschaften, Lernstände, Testergebnisse, Zertifikate und historische Nachweise.

Hier reicht es nicht, die normale Benutzeroberfläche zu prüfen. Exporte, Suchfunktionen, Reports und Schnittstellen sind ebenso Teil der Grenze. OWASP nennt Cross-Tenant Data Leakage und manipulierte Objekt- beziehungsweise Tenant-IDs ausdrücklich als typische Risiken mehrmandantenfähiger Anwendungen.

Administration

Delegierte Administration ist oft der eigentliche Grund für einen Mandanten.

Ein Kunde soll seine Benutzer selbst verwalten, ein Partner seine Teilnehmer zuweisen oder eine Tochtergesellschaft eigene Reports erstellen. Dafür muss die Plattform administrative Rechte nicht nur nach Funktion, sondern auch nach Tenant begrenzen.

Gerade hier unterscheidet sich ein Mandant von einer bloßen Zielgruppe. Ein Kurs kann mehreren Gruppen zugewiesen werden. Ein Tenant besitzt dagegen einen administrativen Kontext, in dem bestimmte Personen handeln dürfen, ohne automatisch Zugriff auf die parallelen Kontexte zu erhalten.

Inhalte und Konfiguration

Nicht alles muss isoliert sein.

Eine zentrale Akademie kann denselben Compliance-Kurs an zwanzig Mandanten ausspielen. Gleichzeitig soll jeder Mandant eigene Inhalte, Zertifikatsvorlagen oder Registrierungsinformationen pflegen können. Die sinnvolle Architektur kann deshalb gemeinsame und tenant-spezifische Objekte gleichzeitig enthalten.

Das gilt auch für Branding, Sprachen, Mailvorlagen, Domains oder Benachrichtigungsregeln. Entscheidend ist nicht maximale Trennung, sondern vorhersehbare Trennung: Was gehört zentral der Plattform, was dem einzelnen Mandanten und was darf bewusst geteilt werden?

Reporting und zentrale Steuerung

Mandantenfähigkeit erzeugt fast immer eine asymmetrische Berechtigungsfrage.

Der lokale Administrator soll nur seinen Bereich sehen. Die zentrale Plattformverantwortung benötigt unter Umständen eine konsolidierte Sicht über alle Mandanten. Ein Konzern möchte vielleicht gruppenweite Compliance-Zahlen, während eine externe Kundenakademie gerade keine organisationsübergreifende Auswertung zulassen soll.

Deshalb sollte Reporting nicht nachträglich geprüft werden. Es ist ein Teil des Mandantenmodells.

Lifecycle und Integrationen

Ein Tenant wird angelegt, verändert und irgendwann beendet. Benutzer wechseln Rollen oder Organisationen. Domains ändern sich. Schnittstellen liefern neue Stammdaten. Kundenverträge enden.

Damit wird Mandantenfähigkeit zu einem Lifecycle-Thema. Wer darf einen Tenant anlegen? Wie werden Benutzer eindeutig zugeordnet? Was passiert bei einem Wechsel? Welche Daten werden exportiert oder gelöscht? Wie verhindern API- oder Importprozesse, dass ein Datensatz im falschen Kontext landet?

Ein sauberer Startbildschirm sagt über diese Fälle wenig aus. Der Betrieb entscheidet sich an den Übergängen.

Eine eigene Datenbank ist eine mögliche Antwort, nicht die Definition

OWASP stellt mehrere Datenbankstrategien nebeneinander: separate Datenbanken, separate Schemas, gemeinsam genutzte Tabellen mit zeilenbasierter Trennung und hybride Modelle. Die Organisation bewertet diese Varianten nach Sicherheitsanforderungen, Compliance-Bedarf und betrieblicher Komplexität.

Auch AWS unterscheidet zwischen Silo-, Pool- und Hybridmodellen. Im Silo bekommt ein Tenant dedizierte Ressourcen. Im Pool teilen Tenants Ressourcen, während Policies und Tenant-Kontext den Zugriff begrenzen. Ein Bridge-Modell kombiniert beides.

Das widerspricht der simplen Formel „echte Mandantenfähigkeit braucht eine eigene Datenbank“.

Eine dedizierte Umgebung hat klare Vorteile. Microsoft nennt insbesondere eine geringere Gefahr versehentlicher Datenlecks und weniger gegenseitige Performance-Effekte. Die andere Seite gehört aber zur Entscheidung: geringere Kosteneffizienz, mehr Deployments, mehr Wartung und zusätzlicher Aufwand für übergreifende Analytics oder Änderungen.

Die unabhängige Cross-Case-Analyse von Ochei, Bass und Petrovski zeigt ebenfalls, dass Isolation mit realen Trade-offs verbunden ist. Ihre Experimente betreffen Cloud-Tools für Softwareentwicklung und lassen sich nicht eins zu eins auf ein LMS übertragen. Relevant ist der Mechanismus: Höhere Isolation verändert Ressourcenteilung, Performance, Customizing und Betriebsaufwand.

Für eine Ausschreibung bedeutet das: Wer „separate Datenbank je Mandant“ fordert, sollte einen Grund dafür haben. Wenn das eigentliche Ziel lautet, dass Kunde A niemals Daten von Kunde B sehen darf, ist zunächst dieses Ergebnis zu spezifizieren. Ob der Anbieter es durch getrennte Datenbanken, Schemas, Policies oder eine hybride Architektur erreicht, ist eine zweite Frage.

Die Gegenposition: Mehr Isolation kann die schlechtere Lösung sein

Bei Security-Themen klingt mehr Trennung zunächst automatisch besser. Das ist zu einfach.

Wenn fünf interne Geschäftsbereiche zur selben Organisation gehören, dieselben zentralen Inhalte nutzen, gemeinsam ausgewertet werden sollen und keine harte Vertraulichkeitsgrenze zwischen ihnen brauchen, kann ein Tenant pro Bereich unnötige Reibung erzeugen. Gemeinsame Administration wird komplizierter, Inhalte müssen über Grenzen verteilt und übergreifende Prozesse bewusst wieder zusammengebaut werden.

Umgekehrt kann eine dedizierte Umgebung sehr sinnvoll sein, wenn ein Kunde besondere regulatorische Anforderungen, eigene Betriebsfenster, harte Performance-Garantien oder eine besonders leicht erklärbare technische Isolationsgrenze verlangt.

Das Ziel ist also nicht möglichst viel Isolation. Das Ziel ist genug Isolation für das tatsächliche Risiko und Betriebsmodell – ohne gemeinsame Prozesse künstlich zu zerlegen.

Genau deshalb sollte die Architekturentscheidung nach der fachlichen Grenzziehung kommen. Erst wird geklärt, was getrennt sein muss. Dann lässt sich bewerten, welches technische Modell diese Grenze mit vertretbarem Aufwand zuverlässig durchsetzt.

Mandantenfähigkeit muss in der Demo angegriffen werden

Eine vorbereitete Demo beweist wenig. Zwei sauber getrennte Startseiten mit unterschiedlichen Logos zeigen vor allem, dass Branding funktioniert.

OWASP und Microsoft empfehlen ausdrücklich, Tenant Isolation zu testen. Für eine LMS-Auswahl lässt sich daraus ein einfaches adversariales Szenario ableiten: zwei Mandanten, ähnliche Benutzer und Inhalte, jeweils ein lokaler Administrator sowie eine zentrale Plattformrolle. Danach wird nicht nur der Soll-Prozess gezeigt. Es wird versucht, die Grenze zu überschreiten.

Das ist kein Penetrationstest und ersetzt keine technische Sicherheitsprüfung. Für die Softwareauswahl ist es trotzdem erheblich aussagekräftiger als die Frage „Unterstützen Sie Mandantenfähigkeit?“.

Microsoft formuliert den Grundgedanken sehr direkt: Unabhängig vom gewählten Isolationsmodell sollte getestet werden, ob Daten eines Tenants versehentlich zu einem anderen gelangen und ob gegenseitige Performance-Effekte akzeptabel sind.

Was eine belastbare LMS-Anforderung daraus macht

Die gute Anforderung beginnt nicht mit dem Architekturwort, sondern mit dem gewünschten Verhalten.

Statt „Das LMS muss mandantenfähig sein“ könnte ein kritischer Prozess beispielsweise so beschrieben werden:

Ein Administrator von Mandant A darf ausschließlich Benutzer, Lernstände, Reports und mandantenspezifische Inhalte von A einsehen oder verändern. Zentral bereitgestellte Kurse dürfen mehreren Mandanten verfügbar gemacht werden, ohne deren Benutzer- und Lerndaten zusammenzuführen. Eine definierte zentrale Plattformrolle darf mandantenübergreifend administrieren und berichten. Die Trennung wird mit zwei Testmandanten über Oberfläche, Export und relevante Schnittstellen geprüft.

Das ist länger als ein Häkchen. Dafür entstehen sofort die richtigen Rückfragen.

Kann ein Benutzer mehreren Mandanten angehören? Sind Administratoren tenant-spezifisch? Welche Objekte sind zentral teilbar? Wie verhalten sich Reports? Wo wird Tenant-Kontext in APIs übertragen? Was bedeutet ein Tenant-Wechsel für historische Nachweise? Welche technische Isolation bietet der Anbieter standardmäßig und welche nur als separates Betriebsmodell?

Erst jetzt wird der Begriff Mandantenfähigkeit entscheidbar.

Die Architektur folgt der Grenze

Mandantenfähigkeit ist für eine Lernplattform weder ein Synonym für Gruppen noch für getrennte Datenbanken.

Gruppen und Rollen strukturieren Menschen innerhalb eines gemeinsamen Kontexts. Ein Tenant schafft eine zusätzliche Organisationsgrenze, die bei Daten, Administration und Prozessen durchgesetzt werden muss. Eine dedizierte technische Umgebung kann diese Grenze weiter verstärken, ist aber nur eine von mehreren möglichen Architekturen.

Wer ein LMS auswählt, sollte deshalb nicht nach dem maximalen Isolationsgrad suchen. Er sollte die benötigte Grenze beschreiben.

Welche Informationen dürfen niemals die Organisation wechseln? Wer darf lokal administrieren? Was bleibt bewusst zentral? Welche Inhalte werden geteilt? Wie funktionieren Reporting, Schnittstellen und Offboarding? Und lässt sich die Trennung mit zwei echten Testmandanten nachweisen?

Wenn diese Fragen beantwortet sind, ist „mandantenfähig“ kein Marketingwort mehr.

Dann ist es eine prüfbare Systemeigenschaft.