Multi-Tenant-Architektur: Warum Dialer sie benötigen

Wenn Sie ein BPO-Unternehmen, ein Reseller-Geschäft oder eine sonstige Organisation betreiben, die mehrere Kunden über dieselbe Dialer-Plattform bedient, ist Mandantenfähigkeit kein nettes Extra. Sie ist die Grundlage, auf der alles andere aufbaut.

Was Mehrfamilienhausbau tatsächlich bedeutet

Multi-Tenancy bedeutet, dass mehrere unabhängige Clients (Tenants) dieselbe Softwareinfrastruktur nutzen, dabei aber über vollständig voneinander getrennte Daten, Konfigurationen und Compliance-Regeln verfügen. Jeder Tenant agiert, als hätte er sein eigenes, dediziertes System – die zugrundeliegende Plattform wird jedoch gemeinsam genutzt.

Das Schlüsselwort ist isolationNicht Trennung. Nicht Filterung. Isolation.

Warum Isolation wichtig ist

Datenschutz. Die Kontakte, Anrufaufzeichnungen, Agentendaten und Kampagnenergebnisse von Kunde A müssen für Kunde B unsichtbar sein. Nicht nur ausgeblendet – nachweislich unzugänglich. Selbst wenn ein Entwickler einen Fehler in einer Abfrage macht, muss die Datenbank den mandantenübergreifenden Datenzugriff verhindern.

Unabhängigkeit von der Compliance-Abteilung. Kunde A unterliegt möglicherweise den TDRA-Regeln (VAE), Kunde B den CITC-Regeln (Saudi-Arabien) und Kunde C den TCPA-Regeln (USA). Jeder Kunde benötigt eigene Compliance-Regeln, DNC-Listen, Anrufzeiten und ein System zur Erfassung von Einwilligungen. Ein Compliance-Verstoß eines Kunden hat keine Auswirkungen auf andere Kunden.

Aufnahmeisolierung. Anrufaufzeichnungen sind die sensibelsten Daten in einem Contact Center. Die Aufzeichnungen jedes Mandanten müssen in isolierten Speicherpfaden mit mandantenspezifischen Zugriffskontrollen abgelegt werden. Eine signierte URL für die Aufzeichnung von Mandant A darf niemals für Mandant B funktionieren.

Abrechnungsisolierung. Jeder Mieter hat seine eigene Anzahl an Agenten, Nutzungsmetriken und seinen eigenen Abrechnungszyklus. Die Abrechnungsdaten müssen für jeden Mieter korrekt sein und dürfen nicht miteinander verwechselt werden.

Der falsche Weg: Filterung auf Anwendungsebene

Viele Dialer implementieren „Multi-Tenancy“ mit einem einfachen WHERE tenant_id = ? Sie verwenden einen Filter in ihrem Anwendungscode. Jeder Abfrage wird dieser Filter hinzugefügt. Es funktioniert... bis es jemand vergisst.

Die Probleme:

• Ein übersehener Filter = Datenleck bei mehreren Mandanten
• Komplexe Abfragen mit Joins sind leicht fehlerhaft.
• Aggregationsabfragen (Berichte, Dashboards) sind besonders riskant.
• Es gibt kein Sicherheitsnetz, wenn die Anwendung einen Fehler macht.

Anwendungsbasierte Filterung ist keine Isolation. Sie ist ein Best-Effort-Filter, der darauf angewiesen ist, dass jeder Entwickler, jede Abfrage und jeder Codepfad stets fehlerfrei funktioniert. Das ist nicht ausreichend.

Der richtige Weg: Datenbank-Isolation

DialerBee nutzt die Row-Level-Security (RLS) von PostgreSQL als zusätzliche Sicherheitsebene. So funktioniert es:

1. Jeder Tisch im Besitz eines Mieters hat einen tenant_id column
2. RLS-Richtlinien sind für jede Mandantentabelle aktiviert und erzwungen.
3. Zu Beginn jeder Datenbanktransaktion setzen wir SET LOCAL app.current_tenant_id = :tid
4. Die Datenbank selbst filtert jede Abfrage – SELECT, INSERT, UPDATE, DELETE – so, dass nur Zeilen zurückgegeben werden, die dem aktuellen Mandanten entsprechen.
5. Der Anwendungsbenutzer besitzt keine BYPASSRLS-Berechtigung – selbst rohes SQL kann den Filter nicht umgehen.

Das bedeutet: Selbst wenn der Anwendungscode einen Fehler enthält – beispielsweise eine fehlende WHERE-Klausel, einen fehlerhaften JOIN oder eine Aggregation ohne Gruppierung – verhindert die Datenbank den mandantenübergreifenden Datenzugriff. Der Filter der Anwendung ist die primäre Verteidigung. RLS dient als Sicherheitsnetz.

Isolation testen

Die Behauptung der Isolation reicht nicht aus. Sie muss bewiesen werden. DialerBee führt auf jedem API-Endpunkt Tests zur Mandantenisolation durch, die einen Angriff auslösen:

1. Mieter A erstellt eine Ressource (Kontakt, Kampagne, Aufzeichnung usw.).
2. Mandant B versucht GET-, PATCH- und DELETE-Anfragen an dieser Ressource.
3. Jeder Versuch muss den Fehlercode 404 (Nicht gefunden) zurückgeben, niemals 403 (Verboten).

Warum 404 statt 403? Weil 403 („Sie haben keine Berechtigung“) bestätigt, dass die Ressource existiert. 404 („Nicht gefunden“) gibt keine Auskunft. Mandant B sollte gar nicht wissen, dass die Ressource existiert.

Diese Tests werden im CI-System bei jeder Codeänderung ausgeführt. Schlägt ein Test fehl, wird der Code nicht zusammengeführt.

Was Partner fordern sollten

Wenn Sie einen Dialer für den Einsatz als White-Label-Produkt oder für Wiederverkäufer evaluieren, sollten Sie sich folgende Fragen stellen:

• Wird die Mandantenisolation auf Datenbankebene oder nur im Anwendungscode durchgesetzt?
• Können Sie mir die Testsuite für die adversarielle Isolation zeigen?
• Was passiert, wenn eine Abfrage versehentlich den Mandantenfilter auslässt?
• Werden Anrufaufzeichnungen in mandantenisolierten Pfaden gespeichert?
• Kann ein Verstoß eines Mieters gegen die Mietbestimmungen Auswirkungen auf einen anderen Mieter haben?
• Wird ein Mandant, den ich über das Partnerportal erstelle, sofort von allen anderen Mandanten isoliert?

Wenn eine dieser Fragen unklar ist, suchen Sie weiter. Eine fehlerhafte Implementierung von Multi-Tenancy ist schlimmer als gar keine Multi-Tenancy – denn sie vermittelt ein trügerisches Sicherheitsgefühl.