BYOC vs. klassisches SaaS: Was ist sicherer?

Kein Modell ist auf magische Weise “unhackbar” — aber sie versagen auf sehr unterschiedliche Weise. Klassisches mandantenübergreifendes SaaS hält jeden Kunden in einer zentralen Datenbank, ein einziger Breach kann also Tausende Organisationen auf einmal offenlegen. BYOC (Bring Your Own Cloud) entfernt diese zentrale Datenbank vollständig: Die Daten jeder Organisation liegen isoliert auf ihrem eigenen Cloud-Konto, der Schadensradius eines Vorfalls pro Mandant ist also ein Mandant, nicht der gesamte Kundenstamm. Dieser strukturelle Unterschied — plus was er für Datenresidenz und Ausstieg bedeutet — ist hier gemeint, wenn von “sicherer” die Rede ist.

Dieser Beitrag vergleicht die beiden Sicherheitsmodelle ehrlich: beim Schadensradius, der Mandanten-Isolation, der Datenresidenz, der Breach-Eindämmung und dem, was beim Verlassen passiert. Er baut auf dem Modell auf, das in was ein BYOC Agency OS ist beschrieben wird; wenn dir der Begriff neu ist, fang dort an.

Wie speichert klassisches mandantenübergreifendes SaaS deine Daten?

Die meiste Business-Software, die du nutzt, ist mandantenübergreifendes SaaS. Der Anbieter betreibt eine Anwendung gegen eine zentrale Datenbank, und jeder Kunde — “Mandant” im Fachjargon — teilt sie sich. Deine CRM-Kontakte und die eines Wettbewerbers sitzen in denselben Tabellen, auseinandergehalten durch Anwendungslogik: typischerweise eine Mandanten-ID-Spalte auf jeder Zeile, auf die der Code bei jedem Lesen und Schreiben filtern soll.

Das ist ein ehrlich gutes Entwicklungsmuster. Es ist günstig zu betreiben, leicht zu aktualisieren und es skaliert. Aber es konzentriert Daten. Die Datensätze Tausender Unternehmen landen in einem Schema, auf einer Infrastruktur, die nur der Anbieter kontrolliert, erreichbar über eine Anwendung und einen Satz von Datenbank-Zugangsdaten. Diese Konzentration ist die Wurzel des Sicherheits-Kompromisses.

Was ist “Schadensradius”, und warum spricht er für BYOC?

Schadensradius ist, wie viel offengelegt wird, wenn eine Sache schiefgeht: ein geleaktes Zugangsdatum, ein fehlkonfigurierter Storage-Bucket, eine ungepatchte Schwachstelle, ein böswilliger Insider. Die Frage ist nicht nur “wie wahrscheinlich ist ein Vorfall”, sondern “wie schlimm ist es, wenn einer passiert”.

Bei mandantenübergreifendem SaaS ist der Schadensradius eines Vorfalls auf Datenbankebene der gesamte Kundenstamm. Ein Breach des zentralen Speichers ist potenziell die Daten aller auf einmal. Die Geschichte belegt das: Die größten SaaS-Breaches sind gerade deshalb so groß, weil ein einziger Ausfallpunkt vor Tausenden Mandanten saß.

In einem BYOC-Modell gibt es keinen zentralen Speicher, den man knacken könnte. Die Daten jeder Organisation liegen auf ihrem eigenen Cloud-Konto, ein Vorfall pro Mandant bleibt also auf diesen einen Mandanten begrenzt. Es gibt keine geteilte Datenbank, über die man weiterspringen könnte, und kein einzelnes Ziel, dessen Kompromittierung die Datensätze aller liefert. Du hast einen Vorfall nicht unmöglich gemacht — du hast gedeckelt, wie weit er sich ausbreiten kann.

Sind meine Daten wirklich isoliert? Multi-Tenant vs. Isolation pro Mandant

“Isolation” ist der Punkt, an dem Marketing und Architektur oft auseinandergehen, es lohnt sich also, bei den Stufen genau zu sein:

• Logische Isolation (typisches SaaS). Eine Datenbank, ein Schema, Mandanten getrennt durch eine Mandanten-ID und Anwendungscode. Hat dieser Code einen Bug — einen fehlenden Filter, eine kaputte Zugriffsprüfung — oder verschafft sich jemand Zugriff auf Datenbankebene unterhalb der Anwendung, kann die Trennung zwischen Mandanten versagen. Das ist das klassische mandantenübergreifende Sicherheitsrisiko: Isolation hängt davon ab, dass Software sich überall und jedes Mal perfekt verhält.
• Instanz-Isolation (“dediziert auf dem Konto des Anbieters”). Manche Anbieter geben größeren Kunden eine separate Datenbank — aber immer noch auf dem Cloud-Konto des Anbieters. Besser als ein geteiltes Schema, doch der Anbieter hält weiterhin die Daten jedes Kunden unter seiner eigenen Kontrolle, das gebündelte Ziel bleibt also bestehen.
• Konto-Isolation (BYOC). Die Datenbank jeder Organisation wird auf ihrem eigenen Cloud-Konto angelegt. Isolation ist eine Grenze zwischen getrennten Konten, kein Filter innerhalb eines geteilten Systems. Es gibt keinen zentralen Ort, an dem die Daten aller Kunden nebeneinander liegen, ein Durchsickern zwischen Kunden hat also kein geteiltes Medium, durch das es reisen könnte.

sSystm nutzt Konto-Isolation: Bei der Anmeldung mit deinem Cloudflare-Konto legt die Plattform eine dedizierte Cloudflare-D1-Datenbank auf deinem Konto an. Die Isolation zwischen deiner Agentur und jedem anderen Kunden ist die Isolation zwischen zwei getrennten Cloud-Konten. Wie dieses Datenmodell aufgebaut ist, kannst du genau auf der Seite Sicherheit & Datenmodell nachlesen.

BYOC vs. mandantenübergreifendes SaaS: der Sicherheitsvergleich

Dimension	Klassisches mandantenübergreifendes SaaS	BYOC (Bring Your Own Cloud)
Wo die Daten liegen	Eine zentrale Datenbank auf dem Konto des Anbieters	Eine dedizierte Datenbank auf deinem Cloud-Konto
Schadensradius eines Breaches	Alle Mandanten — ein Breach kann jeden offenlegen	Ein Mandant — begrenzt auf ein einzelnes Konto
Mandanten-Isolation	Logisch (Mandanten-ID + App-Code)	Auf Kontoebene (getrennte Cloud-Konten)
Einzelnes hochwertiges Ziel	Ja — der geteilte Speicher	Kein zentraler Speicher als Ziel
Datenresidenz	Anbieter-Richtlinie (“wir hosten in der EU”)	Beim Anlegen gewählt, optionale harte EU-Garantie
Breach-Eindämmung	Hängt von Erkennung & Reaktion des Anbieters ab	Strukturell auf ein Konto begrenzt
Ausstieg / Eigentum	Daten exportieren, dann woanders neu aufbauen	Datenbank gehört dir schon — nichts zu exportieren

Das Muster über die Tabelle hinweg ist durchgängig: Mandantenübergreifendes SaaS optimiert für die betriebliche Bequemlichkeit des Anbieters und konzentriert das Risiko; BYOC verteilt die Daten und mit ihnen das Risiko.

Welches Modell dämmt einen Breach besser ein?

Bei Eindämmung geht es darum, was ein Angreifer nach einem ersten Fußfassen erreichen kann. In einem zentralen mandantenübergreifenden System steht ein Angreifer, der unter die Anwendung gelangt — zur Datenbank, zu den Backups, zum Admin-Tooling — bereits vor jedem Mandanten. Laterale Bewegung ist trivial, weil es nirgendwo anders hinzugehen gibt: Es ist alles ein Speicher.

In einem BYOC-Modell übergibt das Kompromittieren der Anwendungsschicht der Plattform keine zentrale Datenbank, weil es keine gibt. Die Daten jedes Mandanten sitzen hinter der Grenze eines getrennten Cloud-Kontos. Um eine zweite Organisation zu erreichen, müsste ein Angreifer ein zweites Konto knacken. Das ist der Unterschied zwischen einem Breach, der skaliert, und einem, der es nicht tut.

Deshalb rahmen wir BYOC so ein, dass es die Angriffsfläche und den Schadensradius verändert, statt Unverwundbarkeit zu versprechen. Eine Schwachstelle in irgendeiner Software muss weiterhin gepatcht werden, und dein Cloud-Konto ist jetzt Teil des Sicherheitsbildes — es gehört dir, du musst es also absichern (starke Zugangsdaten, Zugriff nach dem Least-Privilege-Prinzip, MFA). BYOC verschiebt einen Teil der Verantwortung zu dir, im Tausch dafür, den einzelnen größten Punkt gebündelten Versagens zu entfernen. Es ist ein Handel, und für Agenturen, deren ganzes Geschäft Kundendaten sind, ist es meist der richtige.

Was ist mit Datenresidenz und DSGVO?

Residenz ist der Punkt, an dem die beiden Modelle am sichtbarsten auseinandergehen. In herkömmlichem SaaS ist “wir hosten in der EU” eine Richtlinie — ein Versprechen, das sich mit einem neuen Unterauftragsverarbeiter, einer neuen Region oder einem neuen Eigentümer ändern kann. Wenn eine Aufsichtsbehörde oder ein Enterprise-Kunde fragt wo genau liegt dieser Datensatz und wer kann darauf zugreifen, ist ein zentraler mandantenübergreifender Cluster ein unangenehmes Ding, auf das man zeigen müsste.

Bei BYOC ist die Antwort strukturell. Weil die Datenbank auf deinem Konto angelegt wird, wählst du ihre Jurisdiktion beim Anlegen. sSystm lässt dich deine Region beim Anmelden wählen, inklusive einer harten EU-Jurisdiktions-Garantie für die Datenbank — Residenz per Konstruktion, nicht per Versprechen. Auf den Compliance-Aspekt gehen wir tiefer ein in Datenresidenz, DSGVO und Agenturen. Nichts davon ist Rechtsberatung, aber “die Daten liegen physisch in einer EU-gebundenen Datenbank auf unserem eigenen Konto” ist eine materiell stärkere Position als eine Zeile in den Bedingungen eines Anbieters.

Was passiert mit meinen Daten, wenn ich gehe?

Sicherheit schließt das Ende der Beziehung ein, nicht nur die Mitte. Bei klassischem SaaS bedeutet Gehen, deine Datensätze über die API zu exportieren, die der Anbieter gerade anbietet, und die Beziehungen zwischen ihnen woanders neu aufzubauen — und bis du das tust, liegen deine Daten weiterhin im Speicher des Anbieters. Das Deprovisioning läuft nach seinem Zeitplan, nicht deinem.

Bei BYOC ist der Ausstieg für die Daten ein Nicht-Ereignis. Die Datenbank war immer auf deinem Konto; trenne die Plattform, und der Anbieter verliert den Zugriff, während du alles behältst — Datensätze, Inhalte und Backups — genau dort, wo sie waren. Es gibt keinen Export-Schritt, weil es nichts zurückzulassen gibt. Diese Eigenschaft überschneidet sich stark mit dem Lock-in, den wir in SaaS-Vendor-Lock-in und wie man ihn vermeidet behandeln.

Also, was ist sicherer?

Ehrlich: Es hängt von deinem Bedrohungsmodell ab, und keine Architektur ersetzt es, die Grundlagen gut zu machen. Aber wenn deine Hauptsorge das Szenario ist, das Agenturinhaber nachts wachhält — ein Vorfall legt alle unsere Kunden auf einmal offen —, dann ist BYOC das stärkere Modell, weil dieser spezielle Fehlermodus nicht existiert, wenn es keine zentrale Datenbank gibt. Es schrumpft den Schadensradius von allen auf einen, macht Mandanten-Isolation zu einer Grenze zwischen Konten und macht Residenz und Ausstieg zu Eigenschaften der Architektur statt zu Klauseln in einem Vertrag.

Das ist die Wette, auf der sSystm gebaut ist. Du kannst auf der Seite Sicherheit & Datenmodell nachsehen, wie das Datenmodell funktioniert, statt uns beim Wort zu nehmen, und die weitere Philosophie in was ein BYOC Agency OS ist sehen.