Insight · ·

Mandantentrennung beginnt unter dem Dashboard

Ein Firmenfilter in der Oberfläche trennt keine Mandanten. Die Grenze muss auch in Abfragen, Exporten, Hintergrundjobs, Caches und Supportwerkzeugen gelten.

Mandantentrennung beginnt unter dem Dashboard

Das Dashboard stimmt, der Export nicht

Ein Nutzer sieht im Dashboard nur die Datensätze seines Unternehmens. Der heruntergeladene Bericht enthält dennoch Zeilen einer anderen Firma. Die Oberfläche funktioniert wie vorgesehen, das Produkt versagt. Der Firmenfilter war lediglich eine Gewohnheit der Bildschirmabfrage, keine durchgesetzte Grenze für sämtliche Datenwege.

In einem Produkt für mehrere Organisationen muss die Mandantenidentität aus einer geprüften Berechtigung stammen. Eine Firmenkennung in URL oder Formular ist zunächst nur eine Behauptung. Der Server muss feststellen, ob die Person für diese Firma handeln darf und ob die konkrete Aktion zulässig ist. Versteckte Navigation leistet das nicht.

Die Grenze dort durchsetzen, wo sie schwer zu vergessen ist

Datenbankrichtlinien können bei gemeinsam genutzten Datenbanken Teil der Trennung sein. PostgreSQL unterstützt Zeilensicherheit, doch Tabelleneigentümer umgehen sie normalerweise und privilegierte Rollen können sie ebenfalls umgehen. Die PostgreSQL-Dokumentation beschreibt diese Grenze ausdrücklich. Ein Test mit einer privilegierten Verbindung kann falsche Sicherheit erzeugen.

Das Isolationsmodell richtet sich nach den Betriebsanforderungen. Gemeinsames Schema, getrennte Schemas und getrennte Datenbanken verursachen jeweils andere Wartungs- und Wiederherstellungsaufgaben. Keine Variante ersetzt die Berechtigungsprüfung an der Anwendungsgrenze. Entscheidend ist, welche Fehler das Modell verhindert und welche weiterhin geprüft werden müssen.

Für Zugriffe auf Kundendaten sollte der Mandantenkontext verpflichtend sein. Fehlender Kontext führt zu einem klaren Fehler, nicht unbemerkt zu einer uneingeschränkten Abfrage. Administrative Zugriffe brauchen einen eigenen, bewusst genutzten Weg mit Begründung und Protokoll.

Hintergrundarbeit muss die Grenze mitnehmen

Ein Export kann laufen, nachdem die auslösende Anfrage beendet ist. Der Auftrag benötigt eine eindeutige Mandantenreferenz und ein festgelegtes Berechtigungsmodell. Gilt die aktuelle Berechtigung des Nutzers oder eine eng definierte Dienstberechtigung? Diese Entscheidung darf nicht zufällig vom verwendeten Worker-Zugang abhängen.

Vor der Auslieferung wird der Zugriff erneut geprüft. Während der Erstellung könnte die Person das Unternehmen verlassen haben. Auch die fertige Datei braucht mandantenbezogene Speicherung und einen geschützten Download. Eine korrekte Datenbankabfrage hilft nicht, wenn der Bericht anschliessend öffentlich abrufbar ist.

Geplante Benachrichtigungen, Suchindizes und Integrationszugänge gehören in dieselbe Betrachtung. Jeder davon ist ein weiterer Datenweg. Ein Hintergrundprozess darf Organisationen nicht zusammenführen, nur weil er ohne Browsersitzung arbeitet.

Caches und Supportwerkzeuge gehören zum Produkt

Ein Cache-Schlüssel nur aus der Datensatzkennung kann Antworten vermischen, die von Mandant oder Berechtigung abhängen. Vor der Wiederverwendung muss feststehen, welche Identitäts- und Zugriffseigenschaften das Ergebnis beeinflussen. Auch Änderungen an Mitgliedschaften brauchen ein definiertes Verhalten, nicht nur Änderungen am Datensatz selbst.

Besondere Aufmerksamkeit verdienen Supportfunktionen. Nutzervertretung, globale Suche oder ein Diagnosepaket können Grenzen umgehen, die die Kundenoberfläche sorgfältig einhält. Zweck und Umfang werden begrenzt, die Nutzung protokolliert. Vollständige sensible Inhalte sollten nicht sichtbar sein, wenn Status und Referenz zur Klärung reichen.

Die unbequeme Realität: Bequeme interne Zugänge werden oft weniger gründlich geprüft als öffentliche Endpunkte. Starke Trennung lässt sich nicht behaupten, wenn die eigenen betrieblichen Abkürzungen ausgenommen bleiben. Die Grenze folgt den Daten, auch während einer Störungsbehebung.

Diese Woche Grenzübertritte versuchen

Getrennte Testorganisationen mit absichtlich ähnlichen Datensatznamen anlegen. Über direkte Anfragen, Exporte, geplante Aufgaben und Suche organisationsfremde Daten lesen und ändern versuchen. Dabei die tatsächliche Anwendungsrolle verwenden, nicht den Administratorzugang.

Anschliessend eine Mitgliedschaft während eines laufenden Exports entfernen und den Dateizugriff prüfen. Den Versuch mit Cache-Antworten und Supportabläufen wiederholen. Für jeden Übergang die erwartete Ablehnung festhalten. Eine wirksame Prüfung umfasst auch sämtliche Wege, die im Dashboard nie auftauchen.