Mandantenisolierung testen: Kann ein Kunde auf die Daten eines anderen zugreifen?

Die Entscheidung, bei der Ihnen dieser Leitfaden hilft

Verwenden Sie zwei synthetische Mandanten und ändern Sie jeweils nur eine Zuordnungsbeziehung. Prüfen Sie jede Aktion einzeln und untersuchen Sie die nachgelagerten Auswirkungen. Eine verweigerte Antwort an einem Endpunkt belegt keine Isolation für Exporte, asynchrone Aufträge oder eine andere Aktion am selben Objekt.

Eine Variable konstant halten

Beginnen Sie mit einer gültigen Anfrage für Tenant A. Wiederholen Sie den Vorgang mit einer Identität aus Tenant B, während das Objekt unverändert bleibt; testen Sie anschließend mit der ursprünglichen Identität ein anderes Objekt. Solche kontrollierten Vergleiche helfen dabei, einen Autorisierungsfehler von einer fehlerhaften Anfrage oder einer fehlenden Voraussetzung zu unterscheiden.

Jeden Vorgang einzeln prüfen

Lesen, aktualisieren, genehmigen, exportieren und löschen können an unterschiedlichen Stellen durchgesetzt werden. Dass ein Listenendpunkt Objekte korrekt filtert, sagt wenig über einen direkten Objektendpunkt oder einen Export-Download aus. Nutzen Sie die dokumentierte Rollenzuordnung, um zu entscheiden, was erlaubt und was verweigert werden soll.

Über den Antwortstatus hinausblicken

Eigentümerschaft des Objekts, persistenten Zustand und Audit-Prinzipal prüfen. Einige Dienste geben eine allgemeine Erfolgsmeldung zurück, bevor ein Hintergrundprozess die Aktion ausführt. Verfolgen Sie den genehmigten Auftrag bis zu seinem Ergebnis und bestätigen Sie, welche Mandantendaten oder Berechtigungen er verwendet hat.

Richtliniengrenze erneut testen

Eine nachhaltige Lösung verknüpft den authentifizierten Sicherheitsprinzipal serverseitig mit dem betreffenden Mandanten, Objekt und Vorgang. Testen Sie sowohl die zulässige Delegierung als auch die Verweigerung. Zufällige Kennungen und ausgeblendete Steuerelemente können die versehentliche Entdeckung erschweren, ersetzen aber nicht die geschäftliche Autorisierungsentscheidung.

Verwenden Sie eine bewusst ausgewählte Vergleichsgruppe

Erstellen Sie zwei Kundenorganisationen mit getrennten synthetischen Ressourcen und Testidentitäten. Bestätigen Sie zunächst, dass jede ihre legitimen Vorgänge ausführen kann. Wiederholen Sie dann einen vereinbarten Vorgang für das Canary-Objekt der anderen Organisation, während die übrige Anfrage unverändert bleibt. So lässt sich das Ergebnis leichter interpretieren als bei einem zufälligen Austausch von Kennungen. Berücksichtigen Sie die tatsächlichen organisationsübergreifenden Rollen des Produkts gesondert; für Support- oder Plattformbetreiber kann eine andere Richtlinie gelten als für gewöhnliche Kundennutzer.

Testen Sie die verschiedenen Vorgangsklassen, sofern vorhanden: Abruf, Änderung, Export, Suche und administrative Aktionen. Ein erfolgreicher Lesevergleich belegt nicht, dass jede Route, die dasselbe Objekt verarbeitet, dieselbe Richtlinienentscheidung verwendet.

Achten Sie auf Kontextänderungen innerhalb des Arbeitsablaufs

Der Ownership-Kontext kann vom Webdienst an eine Warteschlange, einen Worker, einen Cache oder einen Dateispeicher übergeben werden. Identifizieren Sie diese Übergaben im Prüfungsumfang und legen Sie fest, an welcher Stelle die erwartete Entscheidung weiterhin an die anfragende Organisation gebunden sein muss. Ein korrekt abgewiesener Aufruf im Frontend ist ein nützlicher Nachweis; ein asynchroner Export oder ein unabhängig zugänglicher Ergebnislink kann jedoch eine separate Prüfung erfordern. Verwenden Sie synthetische Daten und eine kleine, vom Verantwortlichen genehmigte Auswahl an Vorgängen.

Der Leitfaden zur Autorisierung in Patientenportalen untersucht vergleichbare Änderungen von Berechtigungsbeziehungen, darunter delegierte Zugriffe und deren Widerruf. Die Geschäftsregeln unterscheiden sich, doch in beiden Bereichen ist es sinnvoll, den Lebenszyklus einer Berechtigung zu prüfen und nicht nur ihre erstmalige Einrichtung.

Richtlinie und zulässigen Workflow erneut testen

Formulieren Sie die Abnahmebedingung anhand von Identität, Vorgang und Zuständigkeit. Dokumentieren Sie die verweigerte Antwort und relevante nachgelagerte Zustände sowie, sofern verfügbar, eine Korrelationsreferenz. Überprüfen Sie nach der Behebung, dass der berechtigte Kunde die vorgesehene Aktion weiterhin ausführen kann und die vereinbarte angrenzende Schnittstelle dieselbe Richtlinie anwendet. Wenn die Autorisierung zentralisiert wird, validieren Sie das beobachtete Ergebnis, statt anzunehmen, dass die Architekturänderung allein ausreicht.

Wenn eine Aktion Werte überträgt oder den Transaktionsstatus ändert, verwenden Sie die zusätzlichen Vergleiche in unserem Leitfaden zum Penetrationstest der Zahlungsautorisierung. Mandanteneigentümerschaft und Funktionstrennung nach dem Vier-Augen-Prinzip ergänzen einander; ein Befund sollte benennen, welche Entscheidung fehlschlug, statt „Zugriffskontrolle“ als unerklärten Sammelbegriff zu verwenden.

Setzen Sie die Leitlinien praktisch um

Verwenden Sie die Vorbereitungs-Checkliste, um Annahmen zu dokumentieren, oder sehen Sie sich den fiktiven Bericht der Fintech AG mit Beispielen für Nachweise und Maßnahmenpläne an. Kontaktieren Sie Atlant Security mit einer nicht sensiblen Beschreibung Ihres Umfangs.