Warum Arbeitsplatzdaten eine isolierte Datenbank brauchen

Wenn ein IT- oder Sicherheitsteam ein Tool für Arbeitsplatzbuchung bewertet, fragt der Fragebogen meist nach Verschlüsselung, Single Sign-on und dem Standort der Server. Er stellt selten die Frage, die für diese Datenkategorie am wichtigsten ist: Sind die Daten unserer Organisation physisch von denen jedes anderen Kunden getrennt, oder sind sie eine Spalte in einer gemeinsamen Tabelle?

Schreibtischbuchung wirkt wie risikoarme Daten, bis man aufzählt, was sie enthält: wer an welchem Tag in welchem Gebäude war, an welchem Schreibtisch, neben wem, mit welchen Besuchern, und wo das Auto geparkt wurde. Das ist ein Bewegungsprotokoll Ihrer Belegschaft. Es verdient dieselbe Isolation, die Sie für HR- oder Gehaltsdaten verlangen würden.

Dieser Artikel erklärt die zwei Arten, wie SaaS-Anbieter mandantenfähige Daten speichern, warum Desk & Park jeder Organisation eine eigene isolierte Datenbank gibt und was diese Entscheidung für diejenigen bedeutet, die Sicherheit, Datenschutz und Compliance freigeben.

Zwei Architekturen, ein Kompromiss

Fast jedes SaaS-Produkt ist mandantenfähig: Eine Anwendung bedient viele Kunden. Die Frage ist, wo die Grenze zwischen den Kunden liegt.

Gemeinsame Datenbank, Mandantenspalte

Der übliche Ansatz. Die Zeilen aller Kunden liegen in denselben Tabellen, und jede Zeile trägt eine tenant_id. Jede Abfrage muss danach filtern. Die Anwendung, nicht die Datenbank, ist dafür verantwortlich, die Kunden auseinanderzuhalten.

Er ist beliebt, weil er günstig zu betreiben ist: eine Datenbank, ein Schema, eine Migration. Er ist aber auch die Quelle einer ganzen Klasse von Sicherheitsvorfällen. Ein einziges fehlendes WHERE tenant_id = ? in einer von tausenden Abfragen, ein Bericht, der ohne den Filter über Tabellen hinweg joint, ein Caching-Fehler, und Kunde A sieht die Daten von Kunde B. Diese Fehler sind nicht hypothetisch; sie sind eine wiederkehrende Kategorie gemeldeter SaaS-Sicherheitslücken, und sie sind schwer zu finden, weil jede einzelne Abfrage korrekt aussieht.

Isolierte Datenbank pro Organisation

Jeder Kunde bekommt eine eigene Datenbank mit eigenen Tabellen, eigenen Zugangsdaten und eigenen Backups. Die Anwendung verbindet sich mit der richtigen Datenbank für die Organisation, die die Anfrage stellt. Es gibt keinen tenant_id-Filter, den man vergessen könnte, weil es in der Datenbank keinen anderen Mandanten gibt, aus dem etwas durchsickern könnte.

Das kostet den Anbieter mehr betriebliche Disziplin: Hunderte oder Tausende Datenbanken bereitstellen, migrieren und überwachen statt einer. Diese Kosten sind der Punkt. Sie werden vom Anbieter bezahlt, einmal, in Engineering, statt vom Kunden, später, in einem Vorfall.

Wie Desk & Park gebaut ist

Desk & Park läuft mit einer Datenbank-pro-Organisation-Architektur. Konkret:

• Eine Steuerungsebene hält nur, was für Routing und Abrechnung nötig ist: Organisationsnamen, Plan, die Zuordnung einer Organisation zu ihrer Datenbank und den eigenen Audit-Trail der Plattform. Sie enthält keine Buchungen, keine Grundrisse, kein Mitarbeiterverzeichnis.
• Eine PostgreSQL-Datenbank pro Organisation hält alles über diese Organisation: Nutzer, Rollen, Standorte, Karten, Schreibtische, Parkplätze, Räume, Buchungen, Check-ins, Besucher, Benachrichtigungen und das Audit-Log der Organisation.
• Zugangsdaten pro Organisation. Die Anwendung öffnet eine Verbindung zur Datenbank einer Organisation mit Zugangsdaten, die auf diese Datenbank beschränkt sind. Eine Anfrage von Organisation A kann nicht einmal versehentlich gegen die Datenbank von Organisation B ausgeführt werden, weil sie nie eine Verbindung dorthin hält.
• Backups, Wiederherstellung und Löschung pro Organisation. Backups werden pro Datenbank erstellt. Eine Organisation auf den Stand von gestern zurückzusetzen berührt niemanden sonst. Eine Organisation am Ende eines Vertrags zu löschen bedeutet, ihre Datenbank zu verwerfen, was eine überprüfbare, vollständige Löschung ist und kein DELETE WHERE tenant_id, das hofft, jede Zeile gefunden zu haben.

Der Anwendungscode ist gemeinsam; die Daten sind es nicht. Das ist die Grenze, auf die ein Auditor zeigen kann.

Was Isolation denen bringt, die freigeben

Für den CISO: ein kleinerer Schadensradius

Eine Schwachstelle in einer mandantenfähigen Abfrageschicht legt alle Kunden auf einmal offen. Mit isolierten Datenbanken kann dieselbe Fehlerklasse keine Organisationsgrenze überschreiten, weil die Grenze von der Datenbank-Engine und den Verbindungszugangsdaten durchgesetzt wird, nicht von Anwendungslogik. Isolation macht eine Anwendung nicht immun gegen Fehler; sie macht aus einem Fehler an einer Stelle ein Problem eines einzelnen Kunden statt eines plattformweiten.

Für den Datenschutzbeauftragten: klare Antworten auf DSGVO-Fragen

Datenschutzprüfungen stellen vorhersehbare Fragen, und Datenbank-pro-Organisation liefert kurze Antworten.

Das Recht auf Löschung und die Pflicht zur Einschränkung der Verarbeitung werden zu Datenbankoperationen mit klarem Umfang statt zu Anwendungsfunktionen, die auf Vollständigkeit getestet werden müssen.

Für die Compliance-Leitung: eine belastbare Kontrolle

Rahmenwerke wie ISO 27001 und SOC 2 verlangen von einem Anbieter den Nachweis logischer Trennung zwischen Kunden. „Jede Abfrage filtert nach Mandant" ist eine Kontrolle, die für jede neue Abfrage erneut verifiziert werden muss. „Jeder Kunde hat eine eigene Datenbank und eigene Zugangsdaten" ist eine Kontrolle, die einmal, strukturell, verifiziert wird und Bestand hat, während das Produkt wächst. Die zweite ist viel leichter zu belegen, sowohl für den Anbieter als auch für das eigene Audit des Kunden.

Für den CIO: vorhersehbare Leistung und Lebenszyklus

Der aufwendige Bericht einer Organisation bremst nicht den morgendlichen Check-in-Ansturm einer anderen, weil sie keine Tabellen oder Indizes teilen. Migrationen werden pro Datenbank ausgerollt, sodass ein Problem bei einer Organisation erkannt werden kann, bevor es die nächste erreicht. Das Offboarding ist ein Verwerfen, kein Aufräumprojekt.

Der Rest der Sicherheitsgeschichte

Isolation ist das Fundament, nicht das ganze Gebäude. Die Kontrollen, die IT-Teams erwarten, sitzen darauf, und sie sind es wert, aufgezählt zu werden, denn eine gute Architektur mit schwacher Authentifizierung ist immer noch schwach:

• Single Sign-on über OpenID Connect mit Ihrem Identity Provider und SCIM-Provisionierung, damit Ein- und Austritte aus Ihrem Verzeichnis heraus angelegt und deaktiviert werden, nicht von Hand.
• Zwei-Faktor-Authentifizierung (TOTP) und Passkeys (WebAuthn), mit einer Richtlinie auf Organisationsebene, um MFA zu erzwingen.
• Sicherheitsrichtlinien pro Organisation: Sitzungs-Timeout, Passwortregeln, IP-Allowlists.
• Verwaltung aktiver Sitzungen, damit ein Administrator Sitzungen sehen und widerrufen kann.
• Ein Audit-Log pro Organisation, das festhält, wer was geändert hat, in der eigenen Datenbank der Organisation.
• Zahlungen über Stripe, sodass Kartendaten die Plattform überhaupt nie erreichen.
• Rollenbasierter Zugriff: Mitarbeitende sehen und buchen; Administratoren konfigurieren; Vorstandsmitglieder und Führungskräfte bekommen Berichte, die auf ihre Teams eingegrenzt sind.

Nichts davon ist im Enterprise-SaaS ungewöhnlich. Ungewöhnlich ist die Kombination mit einer Datenschicht, in der die Kundengrenze physisch ist.

Fragen, die Sie jedem Workplace-Anbieter stellen sollten

Wenn Sie Tools vergleichen, trennen diese fünf Fragen Marketing von Architektur:

1. Liegen unsere Daten in einer dedizierten Datenbank oder in gemeinsamen Tabellen mit einer Mandantenspalte?
2. Werden Backups, Wiederherstellungen und Löschungen pro Kunde durchgeführt?
3. Welche Zugangsdaten verwendet die Anwendung, um auf unsere Daten zuzugreifen, und sind sie auf uns beschränkt?
4. Wie belegen Sie die Kundentrennung gegenüber Ihren Auditoren?
5. Kann ein Fehler in einem Bericht oder einem Export jemals die Zeilen eines anderen Kunden zurückgeben?

Ein Anbieter mit isolierter Datenbank beantwortet alle fünf mit je einem Satz. Ein Anbieter mit gemeinsamer Datenbank muss einen Testprozess beschreiben.

Isolation sollte der Standard sein

Workplace-Daten sind personenbezogene Daten über die physische Anwesenheit Ihrer Mitarbeitenden. Die für den Anbieter günstigste Architektur legt diese Daten neben die jedes anderen Kunden und vertraut darauf, dass die Anwendung sie auseinanderhält. Desk & Park hat sich für die teurere entschieden, damit die Grenze zwischen Organisationen eine Datenbank ist, kein Filter.

Die technischen Details finden Sie in der Architekturzusammenfassung auf der Seite „So funktioniert es" und in der Datenschutzerklärung der Plattform. Für eine Enterprise-Einführung mit Single Sign-on, SCIM und einer Sicherheitsprüfung finden Sie auf der Preisseite den Enterprise-Kontakt.