Wenn Sie genug Multi-Tenant SaaS Architektur-Artikel lesen, werden Sie feststellen, dass sie alle auf die gleiche Weise beginnen: Row-Level Security ist in Ordnung, wenn Ihre Ingenieure diszipliniert sind; Per-Tenant Datenbanken sind über-Engineered, bis Sie einen Compliance-Grund haben. Die Implikation ist, dass Sie standardmäßig Row-Level Security wählen und zu Isolation wechseln, wenn ein Enterprise-Procurement-Team Sie dazu zwingt.

Diese Rahmung setzt voraus, dass die Kosten des späteren Wechsels gering sind. Bei Speditionen ist das nicht so. Die Procurement-Teams, die Per-Tenant Isolation wichtig machen — SOC 2 Type II Reviews, ISO 27001 Audits, Fortune 500 Vendor Security Fragebogen — kommen am ersten Tag des Gesprächs an, nicht im dritten Jahr. Wenn Ihre Antwort auf „wie separieren Sie Mandanten-Daten" mehrere Absätze und bedingungsabhängig ist, haben Sie das Meeting bereits verloren.

Also haben wir gleich zu Anfang die teurere Wahl getroffen.

Was PulseCargo tatsächlich tut

Jeder Mandant bekommt seine eigene SQL Server Datenbank. Die Benennung ist verständlich:

PulseCargoDb — die Portal-Datenbank, hält Mandanten-Identitäten, Abrechnungspläne, Servicevereinbarungen, Portal-Admin-Konten und die Cross-Tenant Infrastruktur.
PulseCargo__<tenant-slug> — einer pro Kundenmandant, hält alle Daten dieses Mandanten: Sendungen, Bestellungen, Container, Zolleinträge, Rechnungen, Dokumente, Audit-Logs, KI-Query-Logs.

Die Web-Schicht, API-Schicht und Background-Worker erhalten einen Mandanten-Bezeichner bei jeder Anfrage über TenantResolutionMiddleware. Die Middleware sucht den Mandanten-Slug nach, berechnet die Verbindungszeichenfolge für die Datenbank dieses Mandanten und bindet diese Verbindung an den Request-Scope. Jeder Datenbankaufruf im Request — egal ob über Entity Framework Core, Dapper oder direkte ADO — verwendet diese gebundene Verbindung.

Eine Abfrage, die keinen Mandanten-Scope hat, kann sich nicht mit einer Mandanten-Datenbank verbinden. Es gibt keine gemeinsame Tabelle, bei der man die WHERE-Klausel vergessen kann. Die fehlende-WHERE-Klausel Fehlernorm — die häufigste Ursache für Cross-Tenant Datenlecks in gemeinsamen-Schema SaaS — existiert in unserer Codebasis nicht.

Die Kompromisse, die wir akzeptieren

Das ist teurer als Row-Level Isolation auf vier spezifische Weisen. Jede ist real, und jede würden wir wieder treffen.

Höhere Pro-Kunden-Speicherkosten. Jede Mandanten-Datenbank hat ihre eigenen Indizes, Transaktionsprotokolle, Statistiken und Overhead. Die Grenzkosten eines kleinen Mandanten sind höher als in einem gemeinsamen-Schema Modell. Wir bezahlen dafür. Es skaliert linear. Die Kosten eines Cross-Tenant Datenlecks skalieren nicht linear — sie skalieren danach, wie sehr der Anbieter im Geschäft bleiben möchte.

Cross-Tenant Analytik ist mehr Arbeit. Die aggregierten Branchenbenchmarks, die wir als Opt-In-Funktion auf der Professional-Schicht anbieten, erfordern das Durchlaufen von teilnehmenden Mandanten, das Berechnen von Pro-Mandanten-Statistiken und das Schreiben des Aggregats in einen dedizierten Benchmark-Store. Die meisten gemeinsamen-Schema Anbieter bekommen billige Aggregate gratis. Wir zahlen diese Kosten als einen täglichen Background-Job. Der Vorteil ist, dass die Aggregation K-anonym ist (k ≥ 5) nach Konstruktion, und Mandanten sich explizit über ein Flag anmelden, anstatt zu entdecken, dass ihre Daten bereits in dem Haufen waren.

Bereitstellung erfordert mehr Schritte. Ein neuer Mandant erfordert Datenbankerstellung, Schema-Migration, Starter-Pack-Import und EF-Migrations-Verlauf-Backfill. Wir haben ein Skript (scripts/backfill-tenant-ef-history.ps1) und eine Bereitstellungs-Pipeline, die dies automatisieren; es ist etwa ein Zwei-Minuten-Schritt. Nicht kostenlos, aber nicht schmerzhaft.

Schema-Migrationen wenden sich Pro-Datenbank an. Eine Schema-Änderung muss auf jede Mandanten-Datenbank angewendet werden, nicht nur eine. EF Core Migrationen werden während der Bereitstellung Pro-Mandant angewendet, mit Rollback-Wegen. Die Disziplin-Kosten sind real, aber die Bereitstellungs-Pipeline verwaltet das transparent.

Gesamtbetriebskosten: irgendwo zwischen 1,5x und 2x, was gemeinsames-Schema uns auf unserer aktuellen Mandanten-Anzahl kosten würde, asymptotisch gegen etwa 1,2x konvergierend, wenn die Mandanten-Anzahl wächst.

Der Payback — was Isolation dir gibt

Einiges von dem, was Isolation dir gibt, ist offensichtlich. Einiges davon nicht.

Die fehlende-WHERE-Klausel Klasse von Bugs existiert nicht. Eine neue Abfrage, ein Refactoring, eine Stored-Procedure-Migration, das erste PR eines Junior-Ingenieurs — keines davon kann Daten über Mandanten leaken, weil es keine gemeinsame Tabelle gibt, bei der man das Prädikat vergessen kann. ORM-Filter-Bypass über raw SQL? Gleiche Antwort. Cache-Key-Wiederverwendung? Gleiche Antwort.

Background-Jobs können nicht „alle Zeilen" abrufen, ohne einen Mandanten anzugeben. Der Job muss fragen, für welchen Mandanten er läuft, um eine Verbindungszeichenfolge zu bekommen. Der Standard ist „keine Verbindung".

BI-Tools, die direkt verbinden, sind Mandanten-begrenzt nach Berechtigungsnachweis. Power BI Embedded nutzt einen Pro-Mandanten Workspace-Berechtigungsnachweis. Auch wenn ein BI-Berater versucht, etwas Exotisches zu tun, ist der Berechtigungsnachweis, den sie haben, auf Mandanten-Ebene an der Datenbankschicht begrenzt.

Backups sind standardmäßig Mandanten-scoped. Jeder Mandant hat seine eigene Backup-Datei. Wiederherstellen am falschen Ort ist kein „sei vorsichtig" Problem; es ist ein „wird sich nicht verbinden" Problem.

Die Compliance Audit Antwort ist ein Satz. „Wie separieren Sie Mandanten-Daten?" „Jeder Mandant hat seine eigene SQL Server Datenbank, gelöst durch Middleware. Die Verbindungszeichenfolge für einen Mandanten kann die Datenbank eines anderen Mandanten nicht erreichen." Das ist die ganze Antwort. Compliance-Audorer bemerken das innerhalb von fünf Minuten.

Der Audit, den wir an uns selbst durchführten

Am 24.04.2026 führten wir einen umfassenden Mandanten-Isolations-Audit an der Codebasis durch. 61 Controller, ungefähr 140 Endpoints, jeder Datenbankabfrage-Pfad. Wir suchten speziell nach Cross-Tenant Datenexposition: Orte, wo ein Mandant die Daten eines anderen Mandanten sehen könnte, entweder durch API-Fehlverhalten, durch Abfrage-Injektion oder durch gemeinsame-Zustand Bugs.

Null KRITISCHE Erkenntnisse.

Eine INFO-Ebene Erkenntnis identifiziert: ausgehende Integrationsaudit-Protokollierung noch nicht für alle Drittanbieter-Services implementiert (Stripe Connect, TMS-Provider-Probes, KI-Provider). Das ist eine SOC 2 CC4.1 / CC7.2 Nachweislücke, nicht eine Cross-Tenant Exposition. Das Muster ist auf eAdaptor vorhanden; verbleibende Services sind in der Build-Queue. Wir präsentieren diese Lücke ehrlich in unserer Sicherheitsdokumentation, anstatt sie während einer SOC 2 Nachweisüberprüfung zu entdecken.

Der vollständige Audit-Report ist für Sicherheitsteams auf Anfrage teilbar. (Email security@pulsecargo.ai.)

Was das nicht ist

Per-Tenant Datenbank-Isolation ist kein Ersatz für den Rest der Sicherheitsposition. Es ist das Substrat. AES-256 Verschlüsselung im Ruhezustand, TLS 1.3 im Transit, native MFA + SSO, RBAC, Audit-Protokollierung bei jeder Aktion, GDPR / CCPA Self-Service Endpoints, Software-Tresor mit getesteter Rehydrierung, führende Compliance-Frameworks verfolgt — all das muss noch liefern und richtig gemacht werden. Isolation bedeutet nur, dass der Boden unter all dem keine Lücke hat.

Es ist auch kein Ruhmreden. Es gibt kredible Gründe, um Multi-Tenancy mit gemeinsamen-Schema zu liefern — horizontale Skalierung, Kostendisziplin, einfachere Ops — und viele großartige SaaS-Produkte laufen so. Wir haben anders gewählt, weil der Käufer in unserem Markt bemerkt, der Kostenunterschied begrenzt ist und der schlimmste Nachteil, es falsch zu verstehen, unbegrenzt ist.

Wenn Sie ein Spediteur sind, der PulseCargo bewertet, stellen Sie die Frage. Stellen Sie sie jedem Anbieter in Ihrer Bewertung. Wer kann es in einem Satz beantworten, ist wahrscheinlich der sicherere Anbieter.

Möchten Sie die tiefere Version? Das Per-Tenant Database Isolation Architecture Whitepaper erweitert jeden Punkt in diesem Artikel für Sicherheitsteams und Procurement-Reviewer. Der vollständige Tenant Isolation Audit Report ist auf Anfrage teilbar — Email security@pulsecargo.ai.

Dies ist der erste Beitrag in der „Inside PulseCargo" technischen Inhalts-Serie. Wir werden monatlich einen davon veröffentlichen, der die technischen Entscheidungen durchgeht, die das Produkt prägen. Nächstes: wie die Synthetic Intelligence Abruf-Schicht den Mandanten-Kontext separiert hält, wenn das zugrunde liegende Language Model geteilt wird.

Möchten Sie ein 30-Minuten-Briefing?

Wenn Ihr Sicherheits- oder Procurement-Team Fragen hat, die dieser Artikel nicht beantwortet, richten wir einen Anruf ein.

Demo anfragen →