MCP-Mandantentrennung: Negative Tests für Gateways
Testen Sie die MCP-Mandantentrennung bei Argumenten, Caches, Sitzungen, Zugängen, Warteschlangen und Exporten mit gepaarten synthetischen Testdaten.
Tests zur MCP-Mandantentrennung sollen nachweisen, dass ein authentifizierter Aufrufer keine fremden Objekte, Zugangsdaten, Caches, Sitzungen oder wartenden Aufgaben nutzen kann. Wer nur sichtbare Suchergebnisse prüft, übersieht viele Grenzen. Verfolgen Sie die Anfrage durch Gateway, Konnektor und Nachweisspeicher. Ersetzen Sie den Mandantenkontext gezielt an den Stellen, an denen das System einer falschen Quelle vertrauen könnte.
Diese Matrix richtet sich an Teams, die mehrere Organisationen oder getrennte Geschäftsbereiche über eine gemeinsame MCP-Bereitstellung bedienen. Alle Beispiele verwenden synthetische Mandanten A und B mit getrennten Verantwortlichen und Testdatensätzen. Führen Sie die Versuche ausschließlich in einer dafür freigegebenen Umgebung aus. Geprüft werden die Grenzen Ihrer Bereitstellung. Die Methode stellt keine Zertifizierung des MCP-Protokolls dar.
Die vertrauenswürdige Herkunft des Mandantenkontexts festlegen
Der Mandantenkontext sollte aus einer geprüften Identität und einer erlaubten Zuordnung stammen, nicht aus einem beliebigen Modellargument. Manche Systeme erlauben Administratoren die Auswahl eines Mandanten. Auch diese Auswahl muss gegen aktuelle Berechtigungen geprüft werden. Eine Mandantenkennung in URL, Prompt oder Anfrage ist eine zu validierende Eingabe. Sie belegt selbst keine Zugriffsberechtigung und darf sie deshalb nicht ersetzen.
Die MCP-Autorisierungsspezifikation beschreibt Anforderungen für HTTP-Autorisierung einschließlich der Prüfung der vorgesehenen Ressource. Die Prüfung der Zielgruppe ersetzt nicht die Mandanten- und Objektprüfungen Ihrer Anwendung. Zwei Mandanten können denselben Ressourcenserver verwenden und trotzdem keinen Zugriff aufeinander haben dürfen. Beide Grenzen müssen im Integrationsentwurf ausdrücklich beschrieben und anschließend überprüft werden.
Gepaarte Testdaten vor den Prüfbedingungen erstellen
Erstellen Sie dieselbe Objektkennung in beiden Mandanten mit sichtbar unterschiedlichen synthetischen Inhalten. Damit finden Sie Speicher- oder Cacheschlüssel, denen der Mandantenkontext fehlt. Legen Sie außerdem eine Kennung an, die nur bei Mandant B existiert. Die Antwort an Mandant A muss dem vereinbarten Verhalten zur Nichtoffenlegung entsprechen. Sie darf weder Daten von B noch unnötige Informationen über die Existenz des Objekts preisgeben.
Verwenden Sie getrennte Konnektorzugänge und Nachweisziele für die Testdaten. Erfassen Sie, welchen Zugang der Konnektor tatsächlich auswählt, ohne das Geheimnis zu protokollieren. Eine korrekte Antwort der Anwendung genügt nicht, wenn der vorgeschaltete Aufruf mit weitreichenden Berechtigungen bereits fremde Daten geladen hat und diese erst nachträglich herausfiltert. Die Auswahl des Zugangs ist eine eigene zu prüfende Grenze.
| Grenze | Negativer Test | Erwartete Beobachtung |
|---|---|---|
| Werkzeugargumente | Mandant A übergibt eine Objektreferenz von Mandant B | Keine unerlaubten Daten oder Wirkungen gelangen zum Aufrufer |
| Cache | Beide Mandanten fragen dieselbe lokale Kennung ab | Jeder erhält nur seinen eigenen erlaubten Datensatz |
| Sitzung | Eine Sitzungsreferenz wird unter anderer Identität wiederverwendet | Die Sitzungszugehörigkeit wird vor der Fortsetzung geprüft |
| Konnektor | Eine Mandantenauswahl wird vor dem Laden des Zugangs ersetzt | Die Zugangsauswahl bleibt an den geprüften Kontext gebunden |
| Warteschlange | Eine alte Aufgabe wird nach Entzug der Berechtigung wiederholt | Vor der Ausführung wird die aktuelle Befugnis erneut geprüft |
| Nachweisexport | Ein Belegpaket eines anderen Mandanten wird angefordert | Der Zugriff wird ohne Offenlegung geschützter Inhalte verweigert |
Die Tabelle ist ein Ausgangspunkt und kein vollständiges Bedrohungsmodell. Ergänzen Sie Grenzen Ihrer Bereitstellung: Objektspeicher, Vektorindizes, Suchfilter, Tracing, Supportoberflächen und Sicherungen. Für jeden zusätzlichen Datenweg muss eine verantwortliche Person erklären können, wie der Mandantenkontext dort durchgesetzt wird. Eine sichere Hauptschnittstelle schützt nicht automatisch alternative Wege, die dieselben Informationen bereitstellen.
Caches und Abrufe getrennt testen
Füllen Sie den Cache mit einem Ergebnis von Mandant B und fragen dieselbe Kennung anschließend als Mandant A ab. Wiederholen Sie den Versuch in umgekehrter Reihenfolge. Untersuchen Sie den Cacheschlüssel und gemeinsam genutzte Zwischenspeicher in der Anwendung. Eine korrekt eingeschränkte Datenbankabfrage kann durch einen falsch abgegrenzten Cache ausgehebelt werden, der das Ergebnis des vorherigen Aufrufers zurückgibt.
Prüfen Sie bei Suchsystemen sowohl die erste Suche als auch den späteren Abruf eines zitierten Dokuments. Ein Filter auf Suchergebnissen schützt keinen getrennten Download-Endpunkt. Verwenden Sie eine Referenz, die ein Aufrufer erraten oder aus einem alten Protokoll erhalten könnte. Der Abruf muss seine eigene Autorisierungsprüfung durchführen. Er darf nicht voraussetzen, dass jede übergebene Referenz aus einer erlaubten aktuellen Suche stammt.
Asynchrone Arbeit nach Berechtigungsänderungen verfolgen
Stellen Sie eine synthetische Aktion in die Warteschlange, solange die ausführende Person bei Mandant A berechtigt ist. Entziehen Sie die relevante Berechtigung vor der Ausführung. Definieren Sie, ob die Aktion stoppen, erneut freigegeben werden oder unter einer eng begrenzten dauerhaften Erlaubnis weiterlaufen muss. Prüfen Sie das gewählte Verhalten zur Ausführungszeit. Eine Warteschlangennachricht darf keine unbegrenzt gültige Kopie früherer Befugnisse werden.
Wiederholen Sie den Versuch, nachdem die Person den Mandanten gewechselt hat. Die Wiederholung muss sich auf die ursprüngliche mandantengebundene Operation und die geltenden Regeln beziehen. Eine neue Benutzersitzung darf die alte Aufgabe nicht versehentlich in den neuen Mandanten umleiten. Erhalten Sie die Operationskennung und weisen widersprüchlichen Kontext zurück, statt das gewünschte Ziel aus der aktuellen Oberfläche zu erraten.
Das empfangende System statt nur der Fehlermeldung beobachten
Ein Gateway kann einen Fehler melden, nachdem das geschützte System eine Aktion bereits angenommen hat. Kontrollieren Sie deshalb bei jedem Ablehnungstest den synthetischen Empfänger oder dessen Transaktionsdatensatz. Es darf keine verbotene Wirkung entstanden sein. Erfassen Sie Gateway-Entscheidung und Beobachtung am Ziel unabhängig voneinander. Widersprechen sie sich, ist die Kontrolle fehlgeschlagen, selbst wenn der Nutzer „Zugriff verweigert“ gesehen hat.
Untersuchen Sie außerdem Protokolle und Fehlerantworten auf fremde Mandanteninhalte. Eine Fehlerbehandlung, die das vollständige geladene Objekt ausgibt, kann Daten über das Monitoring offenlegen, obwohl die normale Antwort sauber bleibt. Verwenden Sie synthetische Erkennungszeichen, nach denen sich Testprotokolle und Exporte durchsuchen lassen. Echte Geheimnisse oder personenbezogene Daten sind dafür nicht erforderlich und sollten nicht eigens eingebracht werden.
Einen fehlgeschlagenen Trennungstest beheben
Stoppen Sie den betroffenen Testpfad, sichern die Nachweise und ermitteln die erste Grenze, an der der vertrauenswürdige Kontext verloren ging. Vermeiden Sie eine oberflächliche Korrektur, die nur die sichtbare Antwort filtert. Reparieren Sie die Autorisierungs- oder Speicherauswahl und wiederholen die gepaarten Fälle über alle betroffenen Wege. Dazu gehören Hintergrundverarbeitung und Exporte genauso wie die unmittelbar sichtbare Anfrage.
Kann die Feststellung eine bestehende Bereitstellung betreffen, folgen Sie dem Incident-Verfahren der Organisation, um Umfang und Meldeverantwortung zu klären. Dieser Artikel bestimmt keine gesetzlichen Pflichten. Halten Sie den technischen Sachverhalt präzise fest: Welche Inhalte waren zugänglich, unter welcher Identität, in welchem Zeitraum und mit welchen beobachteten Folgen? Trennen Sie nachgewiesene Zugriffe von lediglich möglichen Zugriffen.
Einen wiederholbaren Abnahmenachweis definieren
Speichern Sie Testkennungen, Kandidatenstand, erwartetes Verhalten und beobachteten Empfängerzustand für jeden Fall. Ergänzen Sie eine positive Kontrolle, die erlaubten Zugriff bestätigt. Ein Gateway, das alles ablehnt, hat keine brauchbare Mandantentrennung nachgewiesen. Halten Sie positive und negative Ergebnisse getrennt, damit Verbesserungen der Verfügbarkeit keine Verschlechterung der Zugriffsgrenzen verdecken.
Führen Sie die Matrix nach Änderungen an Identitätszuordnung, Routing, Zugangsauswahl, Speicherschlüsseln oder Warteschlangen erneut aus. Ein bestandener Test für eine Gateway-Version belegt keine Trennung in einer späteren Architektur. Das nützliche Ergebnis ist ein wiederholbarer Grenztest mit klarer Verantwortung im Plattformteam, der bei eingeschleustem fremdem Mandantenkontext sichtbar fehlschlägt und eine Korrektur auslöst.
Vorlage und ergänzende Umsetzungsleitfäden nutzen
Nutzen Sie den übergeordneten Leitfaden für die umfassendere Architektur und wenden Sie diesen Artikel auf eine klar begrenzte Umsetzung an. Die ergänzenden Artikel behandeln verwandte Entscheidungen, ohne diese Vorlage zu ersetzen.
Bearbeitbare Vorlage herunterladen. Nächster Schritt.
Technischer Entwurf vom 18. Oktober 2026. Primärquellen wurden an diesem Datum geprüft; die fachliche Prüfung steht noch aus. Die Vorlagen beschreiben vorgeschlagene Tests, keine gemessenen Kundenergebnisse. OATI bleibt eine Entwicklervorschau. Lokale Implementierungsnachweise belegen keine unabhängige Prüfung, Kundenabnahme oder Produktionsreife einer konkreten Bereitstellung.