Was ist Multi-Tenancy?
Software-Multi-Tenancy ist eine Softwarearchitektur , bei der eine einzelne Instanz von Software auf einem Server läuft und mehreren Tenants dient. Systeme, die auf diese Weise entwickelt wurden, sind “geteilt” (anstatt “dediziert” oder “isoliert”).
Ein Tenant ist eine Gruppe von Benutzern, die gemeinsam auf die Softwareinstanz mit spezifischen Berechtigungen zugreifen.
Multi-Tenant-Architektur wird häufig bevorzugt, wenn Dienstleister standardisierte Dienste für mehrere Kunden anbieten. Diese Dienste haben in der Regel minimale Anpassungen, und alle Kunden teilen sich die gleiche Anwendungsinstanz. Wenn die Anwendung aktualisiert wird, gilt dies für alle Kunden gleichzeitig.
Zum Beispiel verwenden CRM (Customer Relationship Management)-Systeme oft eine Multi-Tenant-Architektur, um denselben Service allen Kunden bereitzustellen.
Ein Schlüsselprinzip von Multi-Tenancy ist “Teilen”. Das bedeutet nicht, dass jeder Teil der Lösung geteilt wird; es bedeutet, dass mindestens einige Komponenten über mehrere Tenants hinweg wiederverwendet werden. Dieses umfassendere Konzept zu verstehen, kann dir helfen, die Bedürfnisse deiner Kunden besser zu adressieren.
Welche Anwendungsfälle gibt es für Multi-Tenant-Produkte?
Multi-Tenant-Apps werden häufig in Software-as-a-Service (SaaS)-Produkten wie Produktivitätstools, Kollaborationssoftware usw. verwendet. In diesem Setup stellt jeder „Tenant“ in der Regel einen Geschäftskunden dar, mit mehreren Benutzern (typischerweise Mitarbeitern). In verschiedenen Produkten kann es je nach Kontext als Tenant, Workspace oder Projekt bezeichnet werden. Ein einzelnes Unternehmen könnte auch mehrere Tenants haben, um verschiedene Abteilungen oder Organisationen darzustellen.
In komplexeren Fällen, wie B2B-Anwendungen über SaaS hinaus, bieten Multi-Tenant-Apps eine gemeinsame Plattform für verschiedene Teams, Geschäftskunden und Partnerunternehmen, um auf deine Dienste zuzugreifen.
Warum solltest du Multi-Tenancy in SaaS-Produkten einsetzen?
Skalierung mit Multi-Tenancy
Für Unternehmensgeschäfte ist Multi-Tenancy der Schlüssel, um ihre Anforderungen an Verfügbarkeit, Ressourcenmanagement, Kostenmanagement und Datensicherheit effektiv zu erfüllen. Auf technischer Ebene rationalisiert ein Multi-Tenant-Ansatz deine Entwicklungsprozesse, minimiert technische Herausforderungen und fördert eine nahtlose Expansion.
Schaffung eines einheitlichen Erlebnisses
Wenn man die Wurzeln von SaaS-Produkten untersucht, ist es ähnlich einem Gebäude, das verschiedene Apartments beherbergt. Alle Tenants teilen sich gemeinsame Versorgungsleistungen wie Wasser, Strom und Gas, haben jedoch die unabhängige Kontrolle über die Verwaltung ihres eigenen Raums und ihrer Ressourcen. Dieser Ansatz vereinfacht das Immobilienmanagement.
Sicherheit durch Tenant-Isolation gewährleisten
In einer Multi-Tenancy-Architektur wird der Begriff “Tenant” eingeführt, um Grenzen zu schaffen, die die Ressourcen und Daten unterschiedlicher Tenants innerhalb einer gemeinsamen Instanz trennen und sichern. Dies stellt sicher, dass die Daten und Vorgänge jedes Tenants getrennt und sicher bleiben, auch wenn sie dieselben zugrunde liegenden Ressourcen nutzen.
Wie erreicht man Tenant-Isolation in einer Multi-Tenancy-Architektur?
Wenn man über Multi-Tenant-Anwendungen spricht, ist es immer notwendig, Tenant-Isolation zu erreichen. Dies bedeutet, die Daten und Ressourcen verschiedener Tenants in einem gemeinsamen System (zum Beispiel in einer Cloud-Infrastruktur oder einer Multi-Tenant-Anwendung) getrennt und sicher aufzubewahren. Dies verhindert unautorisierte Versuche, auf die Ressourcen eines anderen Tenants zuzugreifen.
Während die Erklärung abstrakt erscheinen mag, verwenden wir Beispiele und wichtige Details, um die Isolation-Mentalität und die bewährte Praxis zur Erreichung der Tenant-Isolation weiter zu erklären.
Tenant-Isolation steht dem Gedanken des “Teilens” in Multi-Tenancy nicht entgegen
Das liegt daran, dass Tenant-Isolation nicht zwingend ein Infrastrukturressourcen-Level-Konzept ist. Im Bereich Multi-Tenancy und Isolation sehen einige Isolation als strikte Trennung zwischen tatsächlichen Infrastrukturressourcen. Dies führt in der Regel zu einem Modell, bei dem jeder Tenant separate Datenbanken, Recheninstanzen, Konten oder private Clouds hat. In Szenarien mit geteilten Ressourcen, wie Multi-Tenant-Apps, kann der Weg zur Isolation ein logisches Konstrukt sein.
In der Architektur können verschiedene Grade der Ressourcenteilung zwischen Tenants erreicht werden:
Im Allgemeinen gilt: Je mehr Ressourcen unter Tenants geteilt werden, desto geringer sind die Kosten für Systemiteration und Wartung. Umgekehrt, je weniger geteilte Ressourcen, desto höher die Kosten.
Tenant-Isolation konzentriert sich ausschließlich darauf, den Zugriff auf Ressourcen unter Verwendung des „Tenant“-Kontextes einzuschränken. Sie bewertet den Kontext des aktuellen Tenants und verwendet diesen Kontext, um zu bestimmen, welche Ressourcen für diesen Tenant zugänglich sind.
Authentication und Authorization sind nicht gleichbedeutend mit „Isolation“
Authentication und Authorization zu verwenden, um den Zugriff auf deine SaaS-Umgebungen zu steuern, ist wichtig, aber es reicht nicht aus für vollständige Isolation. Diese Mechanismen sind nur ein Teil des Sicherheitspuzzles.
Eine oft gestellte Frage lautet: Kann ich allgemeine Authorization-Lösungen und rollenbasierte Zugangskontrolle verwenden, um Tenant-Isolation zu erreichen?
Du kannst eine Multi-Tenant-App erstellen, aber du kannst nicht behaupten, dass du Tenant-Isolation-Strategien als bewährte Praxis erreicht und eingesetzt hast. Wir empfehlen es im Allgemeinen nicht, weil Tenant-Isolation getrennt von Authentication und Authorization ist.
Um dies zu veranschaulichen, betrachte eine Situation, in der du Authentication und Authorization für dein SaaS-System eingerichtet hast. Wenn sich Benutzer anmelden, erhalten sie ein Token mit Informationen über ihre Rolle, die vorschreiben, was sie in der Anwendung tun können. Dieser Ansatz erhöht die Sicherheit, gewährleistet jedoch keine Isolation.
Verwende „Organisation“ als Kontext zur Darstellung des SaaS-Produkt-Tenants, um Tenant-Isolation zu erreichen
Sich nur auf Authentication und Authorization zu verlassen, wird nicht verhindern, dass ein Benutzer mit der richtigen Rolle auf die Ressourcen eines anderen Tenants zugreift. Daher müssen wir einen „Tenant“-Kontext wie eine Tenant-ID einbeziehen, um den Zugriff auf Ressourcen einzuschränken.
Hier kommt die Tenant-Isolation ins Spiel. Sie verwendet tenantspezifische Kennungen, um Grenzen zu schaffen, ähnlich wie Wände, Türen und Schlösser, und eine klare Trennung zwischen den Tenants sicherzustellen.
Wie werden Identitäten in Multi-Tenant-Apps verwaltet?
Wir haben über Tenant-Isolation gesprochen, aber was ist mit Identitäten? Wie entscheidest du, ob deine Identitäten „isoliert“ sein sollten oder nicht?
Es gibt oft Verwirrung rund um das Konzept der “Identitätsisolation”. Es könnte sich auf Situationen beziehen, in denen ein realer Benutzer zwei Identitäten im allgemeinen Verständnis der Menschen hat.
- Beide Identitäten können innerhalb eines einzigen Identitätssystems existieren. Beispielsweise könnte Sarah neben einer Unternehmens-E-Mail eine persönliche E-Mail registriert haben, die durch Single Sign-On (SSO) verbunden ist.
- Benutzer unterhalten zwei verschiedene Identitäten innerhalb getrennter Identitätssysteme, die völlig getrennte Produkte darstellen. Diese Produkte stehen in keinerlei Zusammenhang zueinander.
Manchmal werden diese Szenarien als “Identitätsisolation” bezeichnet, aber dieser Begriff hilft möglicherweise nicht bei der Entscheidungsfindung.
Anstatt zu fragen, ob du “Identitätsisolation” benötigst, überlege, ob Teile deines Geschäfts oder Produkts separate Identitätssysteme erfordern. Das wird dein Systemdesign leiten. Für Multi-Tenant-Apps sind Identitäten in den meisten Fällen geteilt, während die Ressourcen jedes Tenants getrennt gehalten werden.
In Multi-Tenant-Apps sind Identitäten über die Tenants hinweg geteilt, im Gegensatz zu Tenant-spezifischen Ressourcen und Daten. Es ist wie ein Gebäudeadministrator — du würdest keine zwei separaten Listen der Namen von Tenants führen wollen.
Wenn man nach Tenant-Isolation strebt, taucht oft der Begriff “Organisation” auf, da es eine bewährte Praxis für den Aufbau von Multi-Tenant-Apps ist.
Indem du “Organisation” in vielen CIAM (Customer Identity Management) oder Auth-Diensten verwendest, kannst du Tenant-Isolation in deiner Multi-Tenant-App erreichen und dabei ein einheitliches Identitätssystem beibehalten.
Wie wählst du die richtigen Authorization-Modelle für besseren access control?
Beim Auswählen des richtigen Authorization-Modells berücksichtige folgende Fragen:
- Entwickelst du ein B2C-, B2B- oder eine Kombination aus beiden Arten von Produkten?
- Hat deine App eine Multi-Tenant-Architektur?
- Gibt es in deiner App einen Bedarf an einem bestimmten Isolationsgrad, bestimmt durch die Geschäftseinheit?
- Welche Berechtigungen und Rollen müssen im Kontext der Organisation definiert werden und welche nicht?