Single-Tenant- vs. Multi-Tenant-PaaS: Änderungen auf Infrastrukturebene für regulierte Branchen

Regulierte Teams bekommen oft die Anforderung „Single-Tenant“ auferlegt, meist von der Beschaffungsabteilung, einem Auditor oder dem Sicherheitsteam eines potenziellen Kunden, ohne dass erklärt wird, wozu das gut sein soll. Es ist eine kostspielige Einschränkung, die man nicht einfach so hinnehmen sollte.

Der Begriff „Tenancy“ entspricht selten dem, was tatsächlich benötigt wird. Was ein Prüfer überprüft, ist, ob du eine Reihe von Garantien nachweisen kannst: dass deine Daten isoliert sind, dass ein „lauter Nachbar“ deine Workload nicht lahmlegen kann, dass sich die Daten dort befinden, wo es die Vorschriften vorschreiben, dass du Nachweise für deine Kontrollmaßnahmen vorlegen kannst und dass ein Ausfall an einer Stelle auch dort bleibt. Nur einige dieser Garantien erfordern tatsächlich eine dedizierte Infrastruktur. Die meisten tun dies nicht.

Teams, die das unhinterfragt akzeptieren, neigen dazu, die teuerste Variante davon zu kaufen und den Prüfer trotzdem nicht zufrieden zu stellen, weil es bei den entscheidenden Fragen um Isolation und Nachweise ging – und nicht um Hardware. Die sinnvollere Frage ist, welche Garantien du nachweisen musst und wo auf dem Spektrum von „gemeinsam genutzt“ bis „dediziert“ jede Workload angesiedelt sein muss. Dieser Beitrag geht auf beides ein – auf der Ebene der Infrastruktur.

Was „Single-Tenant“ und „Multi-Tenant“ auf Infrastrukturebene bedeuten

Ein Tenancy-Modell beschreibt, wie die Workload eines Kunden von der eines anderen getrennt wird. 

1. Bei Single-Tenant erhält jeder Kunde einen dedizierten Stack: eigene Rechenleistung, oft eine eigene Datenbank, manchmal eigene Hardware. Nichts wird mit einem anderen Kunden geteilt. Die Isolation lässt sich einfach erklären, ist aber auch die teuerste und langsamste Variante bei der Bereitstellung.
2. Beim Multi-Tenant-Modell laufen viele Kunden auf einer gemeinsamen Infrastruktur, getrennt durch Software statt durch dedizierte Hardware. Die Bereitstellung ist effizient und schnell, und die Sicherheit hängt davon ab, wie gut der Anbieter die Trennung zwischen den Mandanten durchsetzt. Viele konforme, regulierte Systeme laufen auf diese Weise.

Sowohl Single-Tenant als auch Multi-Tenant beschreiben die beiden Extreme eines Spektrums, und die meisten Plattformen liegen heute eher dazwischen als an einem der beiden Enden. Dieser Mittelweg ist die dritte Option, und sie wird in der Diskussion am häufigsten außer Acht gelassen.

3. Strenge Isolation pro Projekt in einer gemeinsam genutzten cloud-basierten Infrastruktur – genau da liegen die meisten modernen Platform-as-a-Service-Lösungen, und genau diesen Punkt übersehen die Leute oft. Jedes Projekt läuft in seiner eigenen isolierten Umgebung auf einer gemeinsam genutzten cloud-basierten Infrastruktur, mit einer Option für dedizierte Cluster für Workloads, die physisch getrennte Ressourcen benötigen. Das bietet fast alle Isolationsvorteile von Single-Tenant, ohne dass für jede Workload die Kosten eines Single-Tenant anfallen. 

Es ist wichtig, alle drei Optionen zu nennen, denn eine als „Single-Tenant“ formulierte Anforderung wird oft durch die dritte Option zu einem Bruchteil der Kosten erfüllt.

Abwägungen: Kosten, Betrieb und Geschwindigkeit über das gesamte Spektrum

Bevor du herausfindest, welche Option du brauchst, ist es hilfreich zu wissen, was dich jede einzelne kostet, denn die Unterschiede sind groß und nicht nur finanzieller Natur.

• Vollständiges Single-Tenant bietet die stärkste und einfachste Isolation, was manchmal vertraglich vorgeschrieben ist. Es ist jedoch auch mit den höchsten Infrastrukturkosten, dem größten betrieblichen Aufwand und der langsamsten Bereitstellung verbunden, da der Stack jedes Kunden separat eingerichtet und gewartet wird.
• Multi-Tenant ist am effizientesten und am schnellsten bereitzustellen; dabei musst du darauf vertrauen und überprüfen, dass der Anbieter die Trennung zwischen den Mandanten gewährleistet. Für Workloads, deren regulatorische Anforderungen durch eine starke logische Trennung erfüllt werden, ist dies oft die sinnvolle Wahl.
• Eine strenge Isolierung mit einer dedizierten Option bei Bedarf zielt auf einen Mittelweg ab: Der Großteil der Isolierungsvorteile gilt standardmäßig, während dedizierte Ressourcen für die Workloads reserviert sind, die tatsächlich eine physische Trennung erfordern. So bleiben Kosten und Betriebsaufwand proportional zum tatsächlichen Bedarf, anstatt für alles das teuerste Modell anzuwenden.

Der Fehler, den es zu vermeiden gilt, ist, für die gesamte Infrastruktur die Kosten eines Single-Tenant-Modells zu zahlen, nur um eine Anforderung zu erfüllen, die eigentlich nur für eine einzige Workload gilt.

Warum regulierte Branchen nach Single-Tenant verlangen

„Wir brauchen Single-Tenant“ ist meist eine Kurzformel, die vom Sicherheitsteam, einer Beschaffungscheckliste oder einem Wirtschaftsprüfer vorgegeben wird. Dahinter verbergen sich eine Reihe echter Anforderungen, und jede davon ist eine Garantie, die du nachweisen musst – und kein Hosting-Modell, das du einfach kaufst.

• Datenisolierung. Ein Kunde darf niemals auf die Daten eines anderen zugreifen. Das ist die zentrale Sorge, und sie wird durch nachweisbare Isolierung erfüllt – dedizierte Hardware ist eine Möglichkeit, diese zu gewährleisten, aber nicht die einzige.
• Keine Konflikte durch „laute Nachbarn“. Die performance einer regulierten Workload darf nicht durch Traffic-Spitzen eines anderen Mandanten beeinträchtigt werden. Dies erfordert dedizierte oder garantierte Ressourcen für die Workloads, die diese benötigen – nicht unbedingt einen vollständig dedizierten Stack für alles, was du betreibst.
• Datenaufbewahrungsort. Vorschriften legen oft fest, in welchem Land oder welcher Region sich die Daten physisch befinden. Hier geht es darum, wo du eine Workload platzieren kannst – das ist eine Eigenschaft der cloud-Abdeckung der Plattform, nicht der Mandantenverteilung.
• Recht auf Prüfung und Nachweis von Kontrollmaßnahmen. Du musst nachweisen können, welche Kontrollmaßnahmen du hast, wann sie geändert wurden und wer die Änderung genehmigt hat. Hier geht es um die Nachweise, die die Plattform liefert, und das ist unabhängig vom Mandantenmodell.
• Eindämmung des Ausbreitungsradius. Ein Vorfall an einer Stelle darf sich nicht ausbreiten. Hier geht es um Isolation und Segmentierung, die eine strenge Isolation pro Projekt gewährleistet – auch ohne einen dedizierten Stack pro Kunde.

Nur zwei dieser fünf Punkte erfordern tatsächlich eine dedizierte Infrastruktur: garantierte Ressourcen und physische Trennung, wenn dies vertraglich ausdrücklich gefordert wird. Die anderen drei lassen sich auf einer streng isolierten, gemeinsam genutzten Infrastruktur erfüllen.

Warum die Antwort auf der Infrastrukturebene liegt

Schau dir noch einmal die Liste der Anforderungen an und achte darauf, was in keiner davon erwähnt wird: wie viele Kunden sich eine Maschine teilen. Die Datenisolierung wird durch Netzwerksegmentierung und Zugriffskontrolle durchgesetzt. Der Standort wird dadurch bestimmt, in welcher Region eine Workload läuft. Der Nachweis für die Kontrollen ergibt sich aus den Aufzeichnungen der Plattform bei der Bereitstellung. Die Eindämmung des Ausbreitungsradius ist eine Eigenschaft der Segmentierung. Jedes dieser Elemente ist eine Infrastrukturkontrolle, und ein Tenancy-Modell ist bestenfalls ein grober Ersatz dafür, diese zu haben.

Deshalb ist die Frage „Single-Tenant oder Multi-Tenant?“ ein so wenig hilfreicher Ausgangspunkt. Sie bezieht sich eher auf die Verpackung als auf den Inhalt. Zwei Plattformen können sich beide als Single-Tenant bezeichnen und sich dennoch enorm darin unterscheiden, wie sie Netzwerke segmentieren, was sie protokollieren und welche Regionen sie erreichen können. Zwei andere können beide Multi-Tenant sein und sich bei denselben Kriterien dennoch überhaupt nicht ähneln.

Die Entscheidung muss also eine Ebene tiefer getroffen werden. Anstatt ein Mandantenmodell auszuwählen und zu hoffen, dass die Kontrollmechanismen dann von selbst folgen, musst du herausfinden, welche Kontrollmechanismen du nachweisen musst, überprüfen, ob eine Plattform diese bereitstellt, und das Mandantenmodell einfach so nehmen, wie es gerade ist. Der Rest dieses Artikels dreht sich um diese Ebene: die Fragen, die es zu stellen lohnt, und die Änderungen, die es wert sind, vorgenommen zu werden.

Die Fragen auf Infrastrukturebene, die man einer PaaS stellen sollte

Das sind die Fragen, die man jeder in Betracht gezogenen Plattform stellen sollte. Jede zielt eher auf eine Kontrollmaßnahme als auf eine Bezeichnung ab, und die Antworten sind meist aufschlussreicher als alles, was auf einer Seite mit Features steht.

Wie werden Mandantendaten isoliert?

Frag nach dem Mechanismus, nicht nach dem Marketingbegriff. Wird die Trennung durch dedizierte Infrastruktur, durch Netzwerksegmentierung, durch projektbezogene Isolierung oder durch eine Kombination davon durchgesetzt? Ein klares, dokumentiertes Isolationsmodell ist wichtiger als die Bezeichnung, die damit verbunden ist.

Sind Rechen- und Datenressourcen dediziert oder gemeinsam genutzt, und kannst du bei Bedarf dedizierte Ressourcen erhalten?

Für die meisten Workloads reichen garantierte Ressourcen auf isolierter Infrastruktur aus. Für diejenigen, die wirklich physisch getrennte Rechenressourcen benötigen, stellt sich die Frage, ob die Plattform eine dedizierte Option bietet, ohne dich zu einer anderen Arbeitsweise zu zwingen.

Wo befinden sich die Daten physisch?

Prüfe, welche Regionen und welche cloud-Anbieter verfügbar sind und ob du eine Workload dort platzieren kannst, wo es die Residenzvorschriften erfordern. Eine Plattform mit nur einem Anbieter schränkt deine Möglichkeiten hier schon von vornherein ein.

Gilt die Compliance für alle Umgebungen oder nur für die Produktion?

Hier geraten viele Teams in Schwierigkeiten. Wenn Zertifizierungen und Kontrollen nur für die Produktivumgebung gelten, liegen deine Staging- und Preview-Umgebungen, die oft Kopien von echten Daten enthalten, außerhalb des Compliance-Rahmens. Frag nach, ob die Compliance für alle Umgebungen gilt.

Welche Audit-Nachweise kann die Plattform liefern, und wie?

Die beste Antwort ist, dass diese Nachweise automatisch als Nebenprodukt deiner Bereitstellungsvorgänge generiert werden, anstatt vor jedem Audit manuell zusammengestellt zu werden. Frag nach, ob Änderungsverläufe, Zugriffsprotokolle und Bereitstellungsaufzeichnungen standardmäßig vorhanden sind und alle Umgebungen abdecken.

Wer ist für was verantwortlich?

Jede Plattform teilt sich die Verantwortung mit dem Kunden. Frag schriftlich nach dem Modell der geteilten Verantwortung: Welche Infrastrukturkontrollen liegen in der Hand der Plattform und welche Kontrollen auf Anwendungsebene bleiben deine Aufgabe. Klarheit in diesem Punkt verhindert sowohl Doppelarbeit als auch gefährliche Lücken.

Die Änderungen auf Infrastrukturebene, die regulierte Teams benötigen

Zu wissen, was man fragen muss, ist schon die halbe Miete. Die andere Hälfte besteht darin, was du auf deiner Seite veränderst, denn die folgenden Kontrollmaßnahmen machen Compliance zu einem festen Bestandteil deiner Bereitstellungsabläufe und nicht zu etwas, das du vor jedem Audit erst zusammenstellen musst. Das sind die Änderungen, auf die der Titel dieses Artikels hinweist.

• Umgebungen, die identisch aus einer Definition nachgebildet werden. Die häufigste Ursache für Audit-Befunde ist Abweichung: ein Staging-Server, der anders konfiguriert ist als die Produktivumgebung, ein Port, der für einen Test geöffnet und nie wieder geschlossen wurde. Wenn jede Umgebung aus derselben versionsverwalteten Definition aufgebaut wird, ist eine Abweichung nicht mehr möglich, und der Nachweis, dass „Staging mit der Produktivumgebung übereinstimmt“, wird zum Kinderspiel. 
• Von der Plattform durchgesetzte Schutzmaßnahmen. Sicherheitsregeln, die nur in einem Dokument stehen, werden oft umgangen. In die Plattform integrierte Regeln können das nicht. Eine Datenbank ohne definierte öffentliche Route kann zum Beispiel nicht versehentlich offengelegt werden. Das gibt Entwicklern Autonomie innerhalb sicherer Grenzen und beseitigt ganze Risikoklassen bereits durch das Design.
• Automatisch generierte Audit-Nachweise. Änderungsverläufe, Zugriffsprotokolle und Deployment-Aufzeichnungen, die standardmäßig vorhanden sind, verwandeln die Nachweiserfassung aus einem Projekt in eine einfache Abfrage. Bei Audit-Gesprächen geht es nicht mehr darum, Screenshots zusammenzustellen, sondern auf bereits vorhandene Aufzeichnungen zu verweisen. 
• Eine klare Aufteilung der gemeinsamen Verantwortung. Wenn du genau weißt, welche Kontrollmaßnahmen bei der Plattform liegen und welche bei dir, kannst du die Kontrollen auf Infrastrukturebene übernehmen und deine Bemühungen auf die Anwendungsebene konzentrieren, wo dein spezifisches Risiko tatsächlich liegt.

Keine dieser vier Änderungen ist eine Entscheidung zugunsten einer Mandantenumgebung. Zusammen bieten sie das meiste von dem, was „Single-Tenant“ garantieren sollte.

Wie Upsun Isolation und Compliance für regulierte Teams handhabt

Upsun positioniert sich bewusst an mehr als einem Punkt auf dem Spektrum, wodurch es regulierte Anforderungen erfüllen kann, ohne übermäßig aufwendig zu sein.

• Standardmäßig strenge Projektisolierung. Jedes Projekt läuft in seiner eigenen abgeschotteten Umgebung. Es gelangt nichts hinein, außer über drei genehmigte Ports, und Dienste können nicht miteinander kommunizieren, es sei denn, du verbindest sie ausdrücklich miteinander. Technisch wird diese Isolierung durch Namespaces, Seccomp und cgroups durchgesetzt – genau der Mechanismus, dessen Dokumentation Auditoren erwarten.
• Multi-Cloud-Standort. Upsun lässt sich über einen einzigen Workflow auf AWS, GCP, Azure, IBM Cloud oder OVHcloud bereitstellen, sodass eine Workload dort platziert werden kann, wo es eine Standortregel oder ein Vertrag vorschreibt, während die Bereitstellung und die Sicherheitskonfiguration über alle Anbieter hinweg einheitlich bleiben. 
• Compliance in jeder Umgebung. Upsun ist nach ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und TX-RAMP zertifiziert und wendet seine Kontrollmaßnahmen in allen Umgebungen an – nicht nur in der Produktivumgebung. Das ist wichtig, da in Preview- und Staging-Umgebungen oft Kopien sensibler Daten gespeichert sind. 
• Ein klar definiertes Modell der geteilten Verantwortung. Upsun ist für die Infrastrukturebenen zuständig, einschließlich Betriebssystem-Patches, Netzwerkisolierung und -segmentierung, Container-Härtung, physische Sicherheit und Plattformverfügbarkeit. Der Kunde ist für die Anwendungsebene verantwortlich: Anwendungslogik, Datenklassifizierung und Zugriffsentscheidungen. 
• Auditnachweise als Nebenprodukt deiner Bereitstellung. Da der gesamte Umgebungsstack in einer versionsverwalteten `.upsun/config.yaml` definiert ist und jede Bereitstellung sowie jede Konfigurationsänderung protokolliert wird, liegen Änderungsverläufe und Zugriffsprotokolle standardmäßig für jede Umgebung vor. Die Sammlung von Nachweisen erfolgt durch eine Abfrage bereits generierter Datensätze und ist kein Projekt, das vor jedem Audit durchgeführt werden muss. 

Upsun ist keine Single-Tenant-Plattform und muss es auch nicht sein. Es bietet standardmäßig strenge Isolation, dedizierte Infrastruktur dort, wo eine Workload dies erfordert, Residenzkontrolle, Compliance über alle Umgebungen hinweg und automatische Nachweise – also genau die Garantien, die eine „Single-Tenant“-Anforderung normalerweise anstrebt.

Über die Compliance- und Governance-Lösung sowie das Trust Center kannst du die Kontrollmechanismen an deine eigenen Anforderungen anpassen.

Welches Modell passt zu welcher Situation

• Entscheide dich für vollständiges Single-Tenant: Wenn ein bestimmter Vertrag, eine Aufsichtsbehörde oder eine Hardware-Anforderung tatsächlich einen dedizierten Stack pro Kunde vorschreibt und die Kosten sowie der Betriebsaufwand akzeptabel und zu erwarten sind.
• Multi-Tenancy ist in Ordnung: Wenn deine regulatorischen Anforderungen durch eine starke, überprüfbare logische Trennung erfüllt werden und du Wert auf Effizienz und schnelle Bereitstellung legst. Viele konforme Systeme laufen auf diese Weise.
• Strenge Isolation mit einer dedizierten Option bei Bedarf passt zum häufigsten Fall in der Praxis: Du benötigst nachweisbare Isolation, Residenzkontrolle und Prüfnachweise in jeder Umgebung, mit dedizierter Infrastruktur, die für die spezifischen Workloads reserviert ist, die dies erfordern. Hier landen die meisten regulierten Teams, sobald die Anforderung losgelöst vom Begriff „Mandantenmodell“ neu formuliert wird.

Häufig gestellte Fragen

Ist Multi-Tenant-Hosting sicher für regulierte Daten?

Das kann es sein. Viele konforme, regulierte Systeme laufen auf Multi-Tenant-Infrastrukturen. Die Sicherheit hängt von nachweisbarer Isolation und Nachweisen über Kontrollmaßnahmen ab, nicht von der Bezeichnung „Tenancy“. Die Frage, die man stellen muss, ist, wie die Trennung durchgesetzt wird und welche Nachweise die Plattform vorlegen kann – und nicht, ob die Plattform Multi-Tenant ist.

Verlangen PCI DSS oder HIPAA Single-Tenant-Hosting?

Nein. Weder PCI DSS noch HIPAA schreiben eine Single-Tenant-Infrastruktur vor. Beide verlangen spezifische Kontrollmaßnahmen in Bezug auf Isolation, Zugriff und Nachweise, die auf einer streng isolierten Infrastruktur erfüllt werden können. Kläre spezifische Kontrollanforderungen mit deinem Prüfer ab, anstatt davon auszugehen, dass ein bestimmtes Tenancy-Modell erforderlich ist. 

Was ist der Unterschied zwischen Single-Tenant- und dediziertem Hosting?

Sie überschneiden sich, sind aber nicht identisch. „Single-Tenant“ beschreibt die Trennung auf Kundenebene; „dediziertes Hosting“ beschreibt physisch getrennte Ressourcen. Eine Plattform kann dedizierte Ressourcen für eine Workload anbieten, wie zum Beispiel einen dedizierten Cluster, ohne für jeden Teil der Infrastruktur eines Kunden einen vollständig separaten Stack zu betreiben.

Ist Datenresidenz auch ohne Single-Tenancy möglich?

Ja. Bei der Datenresidenz geht es darum, in welcher Region und bei welchem Anbieter eine Workload ausgeführt wird – das ist eher eine Eigenschaft der cloud-Abdeckung der Plattform als ihres Tenancy-Modells. Eine Multi-Cloud-Plattform ermöglicht es dir, eine Workload in einer gewünschten Region zu platzieren, ohne dass ein dedizierter Stack erforderlich ist.

Ist Upsun Single-Tenant oder Multi-Tenant?

Keine der beiden Bezeichnungen trifft zu. Upsun führt jedes Projekt standardmäßig streng isoliert auf einer gemeinsam genutzten cloud-Infrastruktur aus und bietet PCI-zertifizierte dedizierte Cluster für Workloads, die physisch getrennte Ressourcen benötigen. Praktisch gesehen bietet Upsun genau die Isolation, Datenresidenz und Compliance-Garantien, die ein reguliertes Team benötigt – und zwar genau an der richtigen Stelle auf dem Spektrum für jede einzelne Workload.