Mandantenfähige Datenisolation: Warum „wir filtern nach Konto" nicht ausreicht

Wenn Sie Immobilien für mehr als einen Eigentümer oder über mehr als eine juristische Person hinweg verwalten, lohnt sich bei jeder Software, in die Sie diese Daten eingeben, eine Frage: Was verhindert tatsächlich, dass die Finanzen von Eigentümer A irgendwo auftauchen, wo das Team von Eigentümer B sie sehen kann? „Wir filtern in der Oberfläche nach Konto“ und „es ist nicht möglich, über Konten hinweg abzufragen“ sind sehr unterschiedliche Antworten — und der Unterschied zählt gerade dann am meisten, wenn etwas schiefgeht, nicht wenn alles wie beabsichtigt funktioniert.

Filterung auf Anwendungsebene ist eine Konvention, keine Garantie

Die meiste Software isoliert Mieterdaten, indem sie jeder Abfrage einen Filter hinzufügt — „nur Zeilen, bei denen company_id übereinstimmt“. Das funktioniert, bis irgendwo im Code eine Abfrage diesen Filter vergisst: ein neuer Endpunkt, eine in Eile geschriebene Reporting-Abfrage, ein Hintergrundjob, der über „alle“ Datensätze statt über die eines einzelnen Unternehmens iteriert. Nichts erzwingt die Regel, außer dass sich jeder Entwickler jedes Mal, für immer, daran erinnert. Für eine Single-Tenant-Anwendung ist das ein geringes Risiko. Für Software, die die Finanz- und Mieterdaten mehrerer Immobilieneigentümer verwaltet, ist das eine andere Art von Problem.

Was Isolation auf Datenbankebene wirklich bedeutet

Die Alternative besteht darin, diese Grenze direkt in der Datenbank durchzusetzen — bei Casement Row-Level Security in Postgres — sodass selbst eine Abfrage, die das Filtern nach Unternehmen vergisst, die Zeilen eines anderen Unternehmens schlicht nicht sehen kann. Das ist keine über eine gemeinsam genutzte Datenansicht gelegte Oberflächen-Beschränkung; die Datenbank selbst verweigert die Rückgabe. Das ist eine deutlich stärkere Garantie als „die Anwendung soll das filtern“, weil sie nicht davon abhängt, dass jede Zeile Anwendungscode korrekt ist.

Warum das speziell für Hausverwaltungen wichtig ist

• Sie sind nicht die einzige Eigentümerin der Daten. Anders als ein typischer Single-Company-SaaS-Nutzer verarbeitet eine Hausverwaltung, die für mehrere Eigentümer handelt, routinemäßig die Finanz- und Mieterdaten anderer Leute — bei einem Datenleck geht es um das Risiko einer anderen Person, nicht nur um Ihr eigenes.
• Eigentümer fragen nach. Ein Eigentümer, der abwägt, ob er einer Hausverwaltung die Daten seines Portfolios anvertraut, hat das Recht zu fragen, wie diese von denen aller anderen isoliert sind — „auf Datenbankebene erzwungen“ ist eine konkrete Antwort; „wir sind vorsichtig“ ist das nicht.

Wie Casement das handhabt

Jede Mieter-Tabelle in Casement trägt eine Unternehmenskennung, die durch Postgres-Row-Level-Security erzwungen wird, nicht nur durch Filterung auf Anwendungsebene — und die Anwendungsebene filtert zusätzlich weiterhin explizit, als zweite Prüfung statt als einzige. Es ist nicht die auffälligste Funktion in einer Produktdemo, aber es ist die, auf der alle anderen aufbauen.

Casement nimmt derzeit eine kleine Anzahl von Pilot-Hausverwaltungen auf. Wenn Sie für mehr als einen Eigentümer verwalten, lohnt es sich, das direkt in einer Live-Demo zu erfragen.