Mandantenisolation für MSPs: Eine Tenant-ID oder ein Login ist keine Autorisierung

Eine vom Client übergebene Tenant-ID, ein X-Tenant-ID-Header, ein funktionierender Login, eine Richtlinie für bedingten Zugriff oder eine SSO-Verbindung liefern jeweils eine nützliche Information — aber keine davon beweist für sich genommen, dass der Aufrufer berechtigt ist, die Daten eines bestimmten Kunden zu sehen. Dieser Leitfaden richtet sich an MSPs und IT-Teams, die Mandantenplattformen betreiben oder einkaufen: Er zeigt, Mechanismus für Mechanismus, wo eine serverseitige Autorisierungsprüfung tatsächlich sitzen muss — von der ersten Anfrage bis zu dem Tag, an dem ein Konto offboardet wird.

Eine Tenant-ID wählt nur einen Kunden aus, sie autorisiert ihn nicht

Eine vom Client übergebene Tenant-ID — im Anfragetext, in einem Query-Parameter oder aus einer Subdomain abgeleitet — ist ein Selektor. Sie teilt der Anwendung mit, welcher Kundenkontext geöffnet werden soll. Das OWASP Multi-Tenant Security Cheat Sheet legt die zugrunde liegende Regel fest: Jede Anfrage muss an einen authentifizierten Principal gebunden werden, dessen Mandantenmitgliedschaft aus serverseitigem Zustand abgeleitet wird; innerhalb des Mandanten müssen objektbezogene Prüfungen erfolgen, und Admin- oder Notfallpfade müssen vom gewöhnlichen Mandantenzugriff getrennt bleiben. Diese Prüfung muss überall greifen, wo eine Mandantengrenze relevant ist, nicht nur an der Eingangstür der API: bei Lese- und Schreibzugriffen, bei administrativen Aktionen und bei Hintergrundjobs, die Arbeit nach Abschluss der ursprünglichen Anfrage übernehmen. Ein durch eine Warteschlange ausgelöster Job, der eine Tenant-ID aus einer Nachricht übernimmt, ohne sie erneut zu prüfen, öffnet genau die Lücke wieder, die die ursprüngliche Prüfung schließen sollte.

Ein X-Tenant-ID-Header oder ein Feld im Body bergen dieselbe Falle

Derselbe Fehler tritt unter dem Namen eines Headers wieder auf. Mandantenfähige APIs akzeptieren häufig einen X-Tenant-ID-Header oder ein Tenant-Feld im Anfragetext, um auszuwählen, welche Kundendaten ein Aufruf betreffen soll — und es ist verlockend, diesen Wert als ausreichend zu behandeln, sobald er korrekt geparst wird. Die OWASP-Leitlinien nennen zwei verwandte Fallstricke: anzunehmen, ein Mandantenkennzeichen sei sicher, weil es lang oder schwer zu erraten ist, statt eine echte Autorisierungsprüfung durchzuführen; und zuzulassen, dass ein eigentlich mandantengebundener Codepfad stillschweigend auf eine ungebundene Abfrage zurückfällt, wenn der erwartete Wert fehlt oder fehlerhaft ist. Beide Fehler ermöglichen es einem authentifizierten, aber nicht zum angeforderten Mandanten gehörenden Aufrufer, auf fremde Daten zuzugreifen.

Ein Login belegt, wer jemand ist — nicht, welchen Mandanten er berühren darf

Authentifizierung beantwortet eine andere Frage als Isolation. Die NIST Special Publication 800-210 zur Zugriffskontrolle für Cloud-Systeme behandelt Mandantenisolation als Eigenschaft, die die Plattform selbst bei jedem API- und Datenpfad durchsetzen muss, wenn eine einzelne Softwareinstanz viele Mandanten bedient — weil der Kunde, der den Dienst nutzt, die zugrunde liegende Infrastruktur nicht kontrolliert. Die Well-Architected SaaS Lens von AWS beschreibt zwei Wege, wie Anbieter dies umsetzen: In einem „Silo“-Modell erhält jeder Mandant dedizierte Ressourcen und eine eingeschränkte Ausführungsrolle — einfacher nachzuvollziehen, aber schwerer im großen Maßstab zu betreiben; in einem „Pool“-Modell teilen sich Mandanten die Infrastruktur, und die Isolation muss innerhalb der Anwendungslogik bei jeder Anfrage durchgesetzt werden. Keines der beiden Modelle ist von sich aus sicherer. Entscheidend ist, ob ein Anbieter konkret zeigen kann, wie eine Anfrage an den Mandanten des Aufrufers gebunden wird, bevor Daten berührt werden — nicht, dass der Aufrufer einen funktionierenden Login besitzt.

Bedingter Zugriff sichert die Anmeldung, nicht den Datenpfad

Microsoft beschreibt bedingten Zugriff als eine Zero-Trust-Richtlinien-Engine nach Wenn-Dann-Logik: Wenn ein Benutzer — oder zunehmend ein KI-Agent — versucht, auf eine Ressource zuzugreifen, muss zuvor eine Bedingung wie Gerätekonformität, Anmelderisiko oder Standort erfüllt sein. Das ist ein wirklich nützliches Tor: Es kann verhindern, dass eine kompromittierte Anmeldeinformation überhaupt eine Sitzung startet, oder eine Sitzung beenden, die verdächtiges Verhalten zeigt. Es hat jedoch keinen Einblick, wie das Backend einer Anwendung entscheidet, sobald eine Sitzung besteht, welche Datensätze welches Kunden ein bestimmter API-Aufruf lesen oder schreiben darf. Verlässt sich eine Plattform bei dieser Entscheidung auf einen vom Client übergebenen Mandantenwert, hat bedingter Zugriff seine Aufgabe zu dem Zeitpunkt bereits erfolgreich und für den Fehler irrelevant erledigt. Ein gut konfiguriertes Anmeldetor vor einer schlecht isolierten API erzeugt dasselbe Datenleck wie ohne dieses Tor. Microsofts Agent-365-Lizenzierung erweitert bedingten Zugriff auf KI-Agenten, doch dieselbe Unterscheidung zwischen Anmeldung und Datenzugriff wird auch dort gelten.

SSO lässt Personen hinein; nur SCIM lässt Austretende hinaus

Föderation beantwortet die Frage „Wer darf sich gerade anmelden?“ Das System for Cross-domain Identity Management, standardisiert als RFC 7644, beantwortet eine andere Frage: Welche Konten sollten überhaupt noch existieren? Microsofts SCIM-Provisioning-Dokumentation beschreibt den üblichen Ablauf: Ein Soft-Delete beim Identitätsanbieter setzt das active-Attribut einer Benutzerressource auf false, und die empfangende Anwendung soll diesen Platz daraufhin deaktivieren oder archivieren. Ohne eine SCIM-Integration hört der Single-Sign-On-Zugang eines Austretenden zwar auf zu funktionieren, doch sein Platz — und jeder daran gebundene verbleibende API-Zugriff — kann unangetastet bestehen bleiben. Auch die Provisioning-Seite braucht einen eigenen Geltungsbereich: Ein SCIM-Bearer-Token sollte pro Kundenmandant ausgestellt und nur am eigenen SCIM-Endpunkt dieses Mandanten akzeptiert werden. Wird ein einziges mandantenübergreifendes SCIM-Geheimnis über mehrere Kunden hinweg geteilt, verwandelt sich ein einzelnes durchgesickertes Token in ein kundenübergreifendes Risiko für Deprovisioning und Kontoübernahme.

Das Deaktivieren des Kontos beendet weder Sitzung noch Token

Verlässt jemand das Unternehmen und ein Administrator deaktiviert dessen Konto beim Identitätsanbieter, liegt die Annahme nahe, die Aufgabe sei damit erledigt. Microsofts eigene Anleitung zum Widerrufen von Zugriff sagt etwas anderes: Das Deaktivieren eines Kontos blockiert neue Anmeldungen, macht aber nicht automatisch bereits ausgestellte Refresh-Token, aktive Sitzungen oder Browser-Cookies ungültig. Um den Zugriff wirklich zu beenden, müssen Sitzungen und Token separat widerrufen und zwischengespeicherte Anmeldeinformationen gelöscht werden — und, wo verfügbar, setzt Continuous Access Evaluation die Sperre schneller durch, als auf den natürlichen Ablauf eines Tokens zu warten. Der NIST-Entwurf zur Sitzungsverwaltung macht einen verwandten Punkt: Der Besitz eines gültigen Zugriffstokens ist kein Beweis dafür, dass eine Sitzung noch legitim offen ist, und Sitzungen beim Identitätsanbieter und bei der Anwendung sind unabhängig voneinander — eine zu beenden, beendet nicht automatisch die andere. Deshalb verlangt das OWASP Session Management Cheat Sheet eine serverseitige Sitzungsinvalidierung mit sowohl Leerlauf- als auch absoluten Timeouts, statt sich darauf zu verlassen, dass der Client Anmeldeinformationen verwirft.

Manche MSPs überlassen diese Control-Plane-Arbeit lieber einem spezialisierten Anbieter, statt sie selbst aufzubauen und zu prüfen; Auris ist eine europäische IAM-as-a-Service-Plattform für adaptive MFA, föderiertes SSO und unveränderliche Audit-Protokolle.

Was zu tun ist

• Die Mandantenmitgliedschaft bei jeder Anfrage aus serverseitigen Identitätsdaten ableiten; niemals allein auf eine vom Client übergebene ID, einen Header oder ein Body-Feld vertrauen.
• Diese Prüfung auf jedem Pfad durchsetzen, an dem eine Mandantengrenze eine Rolle spielt: Lese- und Schreibzugriffe, administrative Aktionen sowie Hintergrund- oder warteschlangengesteuerte Jobs.
• Jeden Mandanten-Selektor ablehnen, der nicht gegen die tatsächlichen Mitgliedschaften des authentifizierten Aufrufers bestätigt wurde, statt anzunehmen, ein langes Kennzeichen sei sicher.
• Bedingten Zugriff, SSO und Mandantenbindung als getrennte Kontrollen mit getrennten Fehlermodi behandeln und jeweils einzeln testen.
• SCIM zusätzlich zu SSO einrichten, jedes SCIM-Token auf einen einzigen Mandanten begrenzen und bestätigen, dass das Konto einer austretenden Person auch im Quellsystem deaktiviert wird, nicht nur beim Identitätsanbieter.
• Beim Offboarding Sitzungen und Refresh-Token für jede von der Person genutzte Anwendung ausdrücklich widerrufen, statt bei „Konto deaktiviert“ stehen zu bleiben.

Quellen: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — Übersicht über bedingten Zugriff, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.