SaaS-Mandantenisolierung bedeutet, dass ein Kunde nur auf Datensätze und Operationen zugreifen kann, zu deren Nutzung seine Organisation berechtigt ist. Eine Mandantenauswahl in der Oberfläche reicht nicht. Die Grenze muss halten, wenn Anfragen, Hintergrundaufgaben, Caches und Dateidownloads die zugrunde liegenden Systeme erreichen.
Testen Sie Mandantenisolierung mit getrennten Organisationen, normalen Benutzerrollen und bewussten Versuchen, ihre Grenzen zu überschreiten. Prüfen Sie Lese- und Schreibzugriffe, Dateien, zwischengespeicherte Antworten und Hintergrundarbeit anhand derselben Zugriffsregeln. Fordern Sie Nachweise der durchgesetzten Backendgrenze, bevor Sie Kunden mit sensiblen oder geschäftlich wichtigen Datensätzen aufnehmen.
Stellen Sie sich ein Kundenportal vor, in dem jede Organisation ihre eigenen Bestellungen sieht. Die Listenansicht ist korrekt, aber ein heruntergeladener Export enthält Zeilen einer anderen Organisation. Das ist ein Isolierungsfehler, selbst wenn Anmeldung und gewöhnlicher Seitenpfad wie vorgesehen funktionieren.
Dieser Leitfaden hilft Verantwortlichen, Prüfung und Behebung abzugrenzen. Er behauptet weder, dass ein bestimmtes Datenbanklayout Sicherheit garantiert, noch dass eine Checkliste eine vollständige Anwendungsprüfung ersetzt.
SaaS-Mandantenisolierung vor der Speicherwahl definieren
Klären Sie, was ein Mandant im Produkt bedeutet. Das kann eine Kundenorganisation, eine juristische Person oder ein Arbeitsbereich sein. Dokumentieren Sie, wie Nutzer Mandanten beitreten, verlassen und wechseln und welche Supportrollen übergreifend handeln dürfen. Unklare Regeln führen zu unklaren Tests.
OWASPs Sicherheitsanleitung für Mehrmandantensysteme beschreibt Isolierung über Datenbank-, Cache-, Speicher- und Rechengrenzen hinweg. Sie unterscheidet außerdem eine vom Client gelieferte Mandantenauswahl von serverseitig geprüften Befugnissen. Nutzen Sie diese Unterscheidung bei der Bewertung des tatsächlichen Anfragepfads.
Definieren Sie Dateneigentum ausdrücklich. Ein gemeinsamer Produktkatalog kann bewusst mehreren Kunden sichtbar sein, während Auftragsnotizen einem Mandanten gehören. Tests müssen den Unterschied kennen, um Lecks zu erkennen, ohne absichtlich geteilte Informationen als Defekt einzustufen.
Erfassen Sie administrative Ausnahmen. Können Supportmitarbeiter Kundendatensätze einsehen, erklären Sie, wer Zugriff gewährt, wie er begrenzt wird und wie seine Nutzung protokolliert wird. Ein mächtiger Supportpfad sollte als beabsichtigte Fähigkeit geprüft und nicht außerhalb des normalen Mandantenmodells versteckt werden.
Mandantenkontext durch die Anfrage verfolgen
Beginnen Sie mit einem authentifizierten Nutzer und prüfen Sie dessen aktuelle Mitgliedschaft oder Dienstbefugnis. Verfolgen Sie den gewählten Mandanten durch Geschäftslogik und Datenzugriff. Prüfen Sie, dass geänderte Header, Pfadwerte oder Anfrageinhalte keine Befugnisse einer anderen Organisation einsetzen können.
Zufällig wirkende Kennungen erschweren möglicherweise das Raten, begründen aber keine Berechtigung. OWASPs Autorisierungsanleitung empfiehlt Zugriffsprüfungen bei jeder Anfrage. Testen Sie eine legitim von einem anderen Mandanten erhaltene Kennung, statt darauf zu vertrauen, ob ein Prüfer sie erraten kann.
| Grenze | Beispiel einer versuchten Änderung | Akzeptiertes Ergebnis |
|---|---|---|
| Datensatzabfrage | Bekannte Auftragskennung eines anderen Mandanten anfragen | Ablehnung ohne Datensatzoffenlegung |
| Aktualisierung | Fremde Mandantenkennung in gültiger Nutzlast senden | Keine unautorisierte Änderung |
| Mandantenwechsel | Organisation ohne Mitgliedschaft auswählen | Server lehnt den angefragten Umfang ab |
| Sammelendpunkt | Kennungen mehrerer Mandanten übermitteln | Definierte Ablehnung ohne teilweise Offenlegung |
| Supportaktion | Normale Rolle auf privilegiertem Pfad verwenden | Ablehnung und hilfreiche Untersuchungsnachweise |
Wiederholen Sie diese Überlegungen für Suche, Exporte und alternative APIs. Der erste korrekte Detailbildschirm beweist nicht, dass ein Sammelbericht, mobiler Endpunkt oder alter Kompatibilitätspfad dieselbe Grenze durchsetzt.
Datenbankansätze anhand ihrer tatsächlichen Kontrollen vergleichen
Getrennte Datenbanken, Schemas und gemeinsame Tabellen schaffen unterschiedliche betriebliche Abwägungen. Keiner dieser Ansätze beseitigt die Pflicht, Zugangsdaten, Rollen, Abfragen und administrative Pfade zu prüfen. Das Angebot sollte benennen, wo die Grenze durchgesetzt wird und was bei einem fehlenden Filter im Anwendungscode geschieht.
| Ansatz | Zu prüfende Grenze | Einzuplanende Betriebsarbeit |
|---|---|---|
| Getrennte Datenbanken | Verbindungs- und Zugangsbefugnisse | Provisionierung, Migrationen und getrennte Backups |
| Getrennte Schemas | Datenbankrollen und Namensraumauswahl | Rechtevergabe, Migrationsdisziplin und administrativer Zugriff |
| Gemeinsame Tabellen | Mandanteneigentum und durchgesetzte Zugriffsregeln | Abfrageabdeckung, Anfragerollen und Negativtests |
| Hybrid | Dokumentierte Regel für jede Datenklasse | Klares Routing und konsistente Vorfalluntersuchung |
Behandeln Sie den Wechsel zu getrennten Datenbanken nicht als Standardreparatur jedes Defekts. Ein begrenzter Autorisierungsfehler kann gezielt behoben werden. Umgekehrt genügt ein Filter in einem Controller nicht, wenn Exporte, Jobs und Supportwerkzeuge weiterhin unbegrenzten Zugriff nutzen.
Mit der tatsächlich produktiv verwendeten Anfragerolle testen
PostgreSQLs Dokumentation zur Zeilensicherheit erklärt wichtige Ausnahmen, darunter privilegierte Rollen und Tabelleneigentum. Vertraut das Produkt auf Zeilenregeln, prüfen Sie diese mit der tatsächlichen eingeschränkten Anfragerolle. Ein Test als Datenbankadministrator bildet nicht die Grenze der gewöhnlichen Anwendung ab.
Nehmen Sie Bereitstellungs- und Migrationskonten in das Inventar auf. Sie brauchen möglicherweise berechtigterweise umfassenderen Zugriff, dürfen aber nicht zur gewöhnlichen Identität für Kundenanfragen werden. Dokumentieren Sie, wie die Laufzeit ihre vorgesehenen Befugnisse erhält und wie dies nach Bereitstellung geprüft wird.
Caches, Dateien und abgeleitete Ausgaben prüfen
Prüfen Sie Cacheschlüssel und den Umfang gespeicherter Ergebnisse. Ein Cacheeintrag für eine Organisation darf nicht zur Antwort für eine andere werden, nur weil beide Anfragen einen bequemen Pfad oder Filter teilen. Testen Sie den zweiten Mandanten, nachdem der erste den Cache gefüllt hat.
Dateien brauchen eigene Abnahmenachweise. Prüfen Sie Uploadzugehörigkeit, Vorschauzugriff, Downloads und generierte Berichte. Eine Seite kann Zugriff korrekt ablehnen, während eine Anhangs-URL über einen anderen Pfad erreichbar bleibt. Nehmen Sie alte und früher ausgestellte Links in den vereinbarten Prüfungsumfang auf.
Prüfen Sie abgeleitete Daten wie Suchindizes, Empfehlungen und Analyseexporte. Klären Sie, ob das System Mandantenbeschränkungen beim Abrufen und nicht nur beim Einfügen durchsetzt. Informationen können die Grenze über eine Zusammenfassung überschreiten, selbst wenn der Quelldatensatzendpunkt geschützt ist.
Verwenden Sie kontrollierte Testdaten verschiedener Organisationen. Geben Sie ihnen genügend erkennbare Inhalte zur Identifikation einer Vermischung, ohne echte Kundendokumente in die Prüfung zu kopieren. Das erleichtert die Diagnose unerwarteter Cachetreffer oder gemischter Exporte.
Hintergrundaufgaben und Mitgliedschaftsänderungen durchspielen
Hintergrundarbeit sollte geprüften Mandantenkontext durch die Warteschlange bis zur Operation tragen. Prüfen Sie verzögerte, wiederholte oder von einem anderen Worker übernommene Jobs. Ein gültiger Mandantenumfang in der Webanfrage beweist nicht, dass der spätere Job ihn erhält.
Testen Sie Mitgliedschaftsänderungen. Ein aus einer Organisation entfernter Nutzer darf nicht entgegen vereinbarten Regeln über eine gespeicherte Sitzung, einen Export oder eine wartende Operation normalen Zugriff behalten. Definieren Sie das vorgesehene Verhalten für vor dem Widerruf bereits angenommene Arbeit.
Supportzugriff im Namen eines Nutzers und Mandantenlöschung verdienen ebenfalls bewusste Prüfung. Erklären Sie, wie Betreiber eine privilegierte Sitzung verlassen und wie Restdateien, Jobs und Referenzen behandelt werden. Die richtige Löschregel hängt von den Aufbewahrungspflichten des Produkts ab; die Prüfung sollte die gewählte Regel verifizieren, statt eine zu erfinden.
Unser Leitfaden zur Softwareprojektübernahme ist relevant, wenn das aktuelle Team diese Pfade nicht erklären kann. Verantwortung für Bereitstellung, Datenzugriff und Betriebsdokumentation zurückzugewinnen kann dazu beitragen, die Grenze wartbar zu machen.
Einen hilfreichen Prüfbericht festlegen
Fordern Sie Befunde, die Akteur, Mandant, Operation und beobachtete Wirkung zeigen. Fügen Sie relevante Anfrage- und Zielnachweise mit angemessen kontrollierten sensiblen Werten hinzu. Ein Befund namens Zugriffskontrolle ohne reproduzierbaren Pfad ist schwer zu reparieren und erneut zu prüfen.
OWASP ASVS kann umfassendere Anwendungssicherheitsanforderungen unterstützen. Behalten Sie daneben die mandantenspezifische Abnahmematrix, damit der Prüfer erkennt, welche Organisationen, Rollen und Ressourcentypen untersucht wurden.
Trennen Sie bestätigte Defekte von ungeprüften Pfaden. Konnte der Prüfer einen privaten Speicherdienst oder einen administrativen Export nicht einsehen, sagen Sie das. Eine ehrliche Umfangsbegrenzung ist hilfreicher als die unbelegte Schlussfolgerung, sämtliche Mandantendaten seien isoliert.
Wiederholen Sie nach Behebung den ursprünglichen Fehlerfall und angrenzende legitime Fälle. Eine Reparatur, die alle Downloads blockiert, kann das Leck stoppen, aber das Produkt beschädigen. Abnahme braucht sowohl die Ablehnung unautorisierten Zugriffs als auch die Fortsetzung erlaubter Kundenarbeit.
Die tatsächliche Produktgrenze budgetieren
Grenzen Sie die Prüfung nach Ressourcentypen, Rollen und Betriebspfaden statt allein nach Seitenzahl ab. Berücksichtigen Sie externe Dateien, Caches, Hintergrundaufgaben und Supportzugriff, wenn sie mandanteneigene Informationen offenlegen können. Ein kleines Portal kann eine umfassendere Grenze haben, als seine Oberfläche vermuten lässt.
| Arbeitspaket | Liefergegenstand | Zu klärende Annahme |
|---|---|---|
| Grenzabbildung | Mandanten- und Rollenmodell | Verfügbarkeit von Architekturwissen |
| Verifizierung | Positive und negative Zugriffsnachweise | Kontrollierte Konten und Umgebungen |
| Behebung | Korrigierte Durchsetzung und Regressionsprüfungen | Notwendigkeit struktureller Änderungen |
| Übergabe | Wiederholbare Tests und bekannte Ausschlüsse | Verantwortung nach Kundenaufnahme |
Fordern Sie Angebote in GBP, getrennt nach Prüfung und Behebung. Akzeptieren Sie keine universelle Zusicherung auf Basis eines Anmeldetests oder automatischen Scans allein. Der wertvolle Liefergegenstand sind Nachweise über Zugriffsgrenzen, auf die Ihre Kunden angewiesen sein werden.
Unsere Anwendungssicherheitsleistung bietet einen Ausgangspunkt für diesen Umfang. Senden Sie uns das Mandantenmodell und die Entscheidung zur Kundenaufnahme , um Prüfung, gezielte Reparaturen und die vor Eröffnung des nächsten Kundenkontos nötigen Nachweise zu besprechen.
Häufig gestellte Fragen
Was ist SaaS-Mandantenisolierung? Sie ist die durchgesetzte Trennung der Daten und erlaubten Operationen von Kundenorganisationen. Die Grenze muss bei Anwendungsanfragen, Speicherung, Caches, Dateien und Hintergrundarbeit halten, einschließlich der vom Produkt definierten administrativen Ausnahmen.
Garantieren getrennte Datenbanken Isolierung? Nein. Zugangsdaten, Routing, Supportwerkzeuge, Exporte und Backups können weiterhin Grenzen überschreiten. Getrennte Datenbanken können Teil des Konzepts sein, aber die tatsächlichen Zugriffspfade müssen geprüft werden.
Reichen zufällige Datensatzkennungen aus? Nein. Sie können einfache Aufzählung erschweren, sind aber keine Berechtigungsprüfungen. Testen Sie den Zugriff mit einer echten Kennung eines anderen kontrollierten Mandanten und bestätigen Sie die serverseitige Ablehnung.
Sollten wir erlaubten Zugriff und Ablehnungen testen? Ja. Eine Behebung, die jede Anfrage ablehnt, kann ein beschädigtes Produkt verdecken. Verifizieren Sie, dass normale Nutzer ihre vorgesehenen Operationen behalten und mandantenübergreifende Versuche abgelehnt werden.
Warum brauchen Caches separate Tests? Sie können Daten zurückgeben, ohne den ursprünglichen Datenzugriffspfad zu wiederholen. Füllen Sie einen Cache unter einem Mandanten und prüfen Sie das Ergebnis unter einem anderen. Bestätigen Sie, dass sein Umfang die vorgesehenen Befugnisse erhält, statt nur einen bequemen Schlüssel zu teilen.
Wie sollte Supportzugriff funktionieren? Definieren Sie, wer ihn erhalten darf, welchen Umfang er gewährt, wie lange er gilt und wie Aktionen protokolliert werden. Testen Sie Eintritt, Nutzung und Austritt aus diesem privilegierten Kontext. Das Konzept sollte die Ausnahme ausdrücklich und überprüfbar machen.
Was ist, wenn wir Sicherheit auf Zeilenebene nutzen? Testen Sie sie mit der tatsächlichen Anfragerolle der Anwendung und berücksichtigen Sie Operationen, die gewöhnliche Controller umgehen. Privilegierte Datenbankrollen und andere Zugriffspfade können sich anders verhalten. Zeilenregeln sind eine zu verifizierende Kontrolle, kein Grund, die Prüfung auszulassen.
Was sollte ein Anbieter vor dem Angebot erhalten? Eine Beschreibung von Mandanten und Rollen, Ressourcentypen, externer Speicherung und Hintergrundoperationen. Benennen Sie verfügbare Prüfumgebungen und kontrollierte Konten sowie die Entscheidung, welche die Prüfung unterstützen muss.