Der Aufbau einer Multi-Tenant-App kann herausfordernd sein, da viele Aspekte berücksichtigt werden müssen. Dieser Artikel fasst alle unsere früheren Blog-Beiträge zusammen, die das Verständnis von Multi-Tenant- und Organisation-Praktiken behandeln. Für einen schnellen Einstieg und um Zeit zu sparen, lies einfach diesen Artikel; er enthält alles, was du brauchst! Die allgemeinen Richtlinien sind in den folgenden Schritten zusammengefasst: 1. Verstehe die Multi-Tenant-Architektur 2. Mache die Anwendungsfälle deiner Multi-Tenant-App deutlich 3. Erreiche Tenant-Isolation 4. Definiere, wie du die Identitäten verwalten möchtest 5. Wähle die geeigneten Autorisierungsmodelle ## Verstehe die Multi-Tenant-Architektur Software-Multi-Tenancy ist eine [Software-Architektur](https://en.wikipedia.org/wiki/Software_architecture), bei der eine einzelne [Instanz]() von [Software](https://en.wikipedia.org/wiki/Computer_software) auf einem Server läuft und mehreren Tenants dient. Systeme, die auf solche Weise entworfen sind, sind "gemeinsam genutzt" (anstatt "dediziert" oder "isoliert"). Ein Tenant ist eine Gruppe von Benutzern, die gemeinsam mit spezifischen Rechten auf die Software-Instanz zugreifen. multi-tenant

Eine der wichtigsten Denkweisen bei Multi-Tenancy ist "geteilt". In der breiteren Definition von Multi-Tenancy bedeutet es nicht, dass **alle** Komponenten in einer Lösung geteilt sind. Es bedeutet vielmehr, dass zumindest **einige** Komponenten einer Lösung über mehrere Tenants hinweg wiederverwendet werden. Ein breiteres Verständnis dieses Begriffs kann dir helfen, die Bedürfnisse deiner Kunden besser nachzuvollziehen und nachzuvollziehen, wo sie herkommen. Sobald du die Multi-Tenant-Architektur verstanden hast, besteht der nächste Schritt darin, deine App auf reale Szenarien anzuwenden und sich auf spezifische Produkt- und Geschäftsbedürfnisse zu konzentrieren. ## Mache die Anwendungsfälle deiner Multi-Tenant-App deutlich ### SaaS Multi-Tenant-Apps finden oft ihren Platz in Business-to-Business (B2B)-Lösungen wie Produktivitätswerkzeugen, Kollaborationssoftware und anderen Software-as-a-Service (SaaS)-Produkten. In diesem Kontext repräsentiert jeder "Tenant" typischerweise einen Geschäftskunden, der mehrere Benutzer (seine Mitarbeiter) haben könnte. Außerdem könnte ein Geschäftskunde mehrere Tenants haben, um verschiedene Organisationen oder Geschäftsbereiche zu repräsentieren. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### Allgemeine B2B-Anwendungsfälle B2B-Anwendungen gehen über SaaS-Produkte hinaus und beinhalten häufig die Nutzung von Multi-Tenant-Apps. In B2B-Kontexten dienen diese Apps als gemeinsame Plattform für verschiedene Teams, Geschäftskunden und Partnerunternehmen, um auf deine Anwendungen zuzugreifen. Betrachte zum Beispiel ein Fahrdienstunternehmen, das sowohl B2C- als auch B2B-Apps anbietet. Die B2B-Apps dienen mehreren Geschäftskunden, und eine Multi-Tenant-Architektur kann helfen, das Management ihrer Mitarbeiter und Ressourcen zu unterstützen. Um dies zu veranschaulichen, wenn das Unternehmen ein einheitliches Benutzeridentitätssystem aufrechterhalten möchte, kann es eine Architektur wie im folgenden Beispiel entwerfen: Sarah hat sowohl eine persönliche als auch eine geschäftliche Identität. Sie nutzt den Fahrdienst sowohl als Passagier als auch als Fahrerin in ihrer Freizeit. In ihrer beruflichen Rolle verwaltet sie auch ihr Geschäft und nutzt diese geschäftliche Identität, um Partner bei Unternehmen 1 zu sein.

### Warum solltest du Multi-Tenancy in SaaS-Produkten verwenden #### 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 die Einführung eines Multi-Tenant-Ansatzes deine Entwicklungsprozesse, minimiert technische Herausforderungen und fördert eine nahtlose Expansion. #### Einen einheitlichen Erfahrungsbereich schaffen Wenn man auf die Wurzeln der SaaS-Produkte blickt, ist es wie ein Gebäude, das verschiedene Wohnungen beherbergt. Alle Tenants teilen sich gemeinsame Einrichtungen wie Wasser, Strom und Gas, behalten jedoch die unabhängige Kontrolle über die Verwaltung ihres eigenen Raums und ihrer Ressourcen. Dieser Ansatz vereinfacht die Immobilienverwaltung. #### 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 verschiedener Tenants innerhalb einer gemeinsamen Instanz voneinander trennen und sichern. Dies stellt sicher, dass die Daten und Operationen jedes Tenants individuell und sicher bleiben, auch wenn sie dieselben zugrunde liegenden Ressourcen nutzen. ## Erreiche Tenant-Isolation Beim Diskutieren von Multi-Tenant-Anwendungen ist es immer notwendig, **Tenant-Isolation** zu erreichen. Das bedeutet, die Daten und Ressourcen verschiedener Tenants in einem gemeinsamen System (zum Beispiel einer Cloud-Infrastruktur oder einer Multi-Tenant-Anwendung) getrennt und sicher zu halten. Dies verhindert unbefugte Versuche, auf die Ressourcen eines anderen Tenants zuzugreifen. Während die Erklärung abstrakt erscheinen mag, werden wir Beispiele und wichtige Details verwenden, um die Isolationsmentalität und die besten Praktiken zu erläutern, um Tenant-Isolation zu erreichen. ### Tenant-Isolation widerspricht nicht der "geteilten" Denkweise von Multi-Tenancy Das liegt daran, dass Tenant-Isolation keine Infrastruktur-Ressourcenebene-Konstruktion sein muss. Im Bereich der Multi-Tenancy und Isolation betrachten einige die Isolation als eine strikte Trennung zwischen tatsächlichen Infrastrukturressourcen. Dies führt normalerweise 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 Isolierung eine logische Konstruktion sein. Tenant-Isolation konzentriert sich ausschließlich darauf, den "Tenant"-Kontext zu verwenden, um den Zugriff auf Ressourcen zu beschränken. Sie bewertet den Kontext des aktuellen Tenants und nutzt diesen Kontext, um zu bestimmen, welche Ressourcen für diesen Tenant zugänglich sind. ### Authentifizierung und Autorisierung sind nicht gleichbedeutend mit "Isolation" Die Nutzung von Authentifizierung und Autorisierung zur Zugriffskontrolle auf deine SaaS-Umgebungen ist wichtig, aber sie reicht nicht aus, um vollständige Isolierung zu erreichen. Diese Mechanismen sind nur ein Teil des Sicherheitspuzzles. Menschen fragen oft, ob allgemeine Autorisierungslösungen und rollenbasierte Zugriffskontrolle verwendet werden können, um Tenant-Isolation zu erreichen? Hier ist das Problem: Du kannst eine Multi-Tenant-App erstellen, aber du kannst nicht sagen, dass du Tenant-Isolationsstrategien als Best Practice erreicht und umgesetzt hast. Wir empfehlen es im Allgemeinen nicht, weil Tenant-Isolation ist getrennt von Authentifizierung und Autorisierung. Um dies zu veranschaulichen, betrachte eine Situation, in der du Authentifizierung und Autorisierung für dein SaaS-System eingerichtet hast. Wenn sich Benutzer anmelden, erhalten sie ein Token, das Informationen über ihre Rolle enthält, die diktieren, was sie in der Anwendung tun können. Dieser Ansatz erhöht die Sicherheit, gewährleistet jedoch keine Isolation. ### Verwende "Organisation", um den SaaS-Produkttenant darzustellen und Tenant-Isolation zu erreichen Wenn du dich nur auf Authentifizierung und Autorisierung verlässt, verhindert dies nicht, dass ein Benutzer mit der richtigen Rolle auf die Ressourcen eines anderen Tenants zugreift. Deshalb müssen wir einen "Tenant"-Kontext einbeziehen, wie zum Beispiel eine Tenant-ID, um den Zugriff auf Ressourcen einzuschränken. Das ist der Punkt, an dem Tenant-Isolation ins Spiel kommt. Sie verwendet tenantspezifische Kennungen, um Grenzen zu schaffen, ähnlich wie Wände, Türen und Schlösser, die eine klare Trennung zwischen den Tenants gewährleisten. ## Identitäten in Multi-Tenant-Apps Wir haben Tenant-Isolation besprochen, aber was ist mit Identitäten? Wie entscheidest du, ob deine Identitäten "isoliert" sein sollten oder nicht? Es gibt oft Verwirrung rund um den Begriff "Identitätsisolation". Es könnte sich auf Situationen beziehen, in denen ein realer Benutzer zwei Identitäten im allgemeinen Verständnis der Menschen hat. 1. Beide Identitäten können innerhalb eines einzigen Identitätssystems existieren. Zum Beispiel könnte Sarah eine persönliche E-Mail-Adresse registriert haben, die neben einer Unternehmens-E-Mail-Adresse verbunden ist, die durch Single Sign-On (SSO) verknüpft ist. 2. Benutzer behalten zwei separate Identitäten in verschiedenen Identitätssystemen, die vollständig separate Produkte repräsentieren. Diese Produkte stehen in keinerlei Zusammenhang zueinander. Zuweilen werden diese Szenarien als "Identitäten isoliert" bezeichnet. Doch dieses Label könnte nicht bei der Entscheidungsfindung helfen. Statt zu bestimmen, ob du "Identitätsisolation" benötigst, überlege ob du oder ein Teil deines Geschäfts oder Produkts separate Identitätssysteme aufrechterhalten musst Diese Antwort kann dein Systemdesign leiten. Für eine kurze Antwort bezüglich einer Multi-Tenant-App, In den meisten Fällen werden in Multi-Tenant-Apps Identitäten geteilt, während die Ressourcen jedes Tenants isoliert sind. In Multi-Tenant-Anwendungen sind Identitäten im Gegensatz zu tenantspezifischen Ressourcen und Daten zwischen mehreren Tenants geteilt. Stell dir vor, du wärst der Gebäudeverwalter; du möchtest wahrscheinlich nicht zwei separate Namenslisten führen, um die Identitäten deiner Tenants zu verwalten. Wenn du Tenant-Isolation anstrebst, hast du vielleicht bemerkt, dass immer wieder der Begriff "Organisation" betont wird, der oft als Best Practice für den Aufbau von Multi-Tenant-Anwendungen angesehen wird. Durch die Anwendung des Begriffs "Organisation" kannst du Tenant-Isolation in deiner Multi-Tenant-Anwendung erreichen und gleichzeitig ein einheitliches Identitätssystem beibehalten. ## Wähle die Autorisierungsmodelle für eine bessere Zugriffskontrolle ### Das geeignete Autorisierungsmodell auswählen und entwerfen Wenn du das richtige Autorisierungsmodell auswählst, betrachte diese Fragen: 1. Entwickelst du ein B2C-, B2B- oder eine Kombination aus beiden Produkttypen? 2. Hat deine App eine Multi-Tenant-Architektur? 3. Gibt es in deiner App einen Bedarf an einem bestimmten Isolationsniveau, wie es von der Geschäftseinheit bestimmt wird? 4. Welche Berechtigungen und Rollen müssen im Kontext der Organisation definiert werden und welche nicht? ### Verstehe verschiedene Autorisierungsmodelle in Logto #### Rollenbasierte Zugriffskontrolle RBAC (Role-Based Access Control) ist eine Methode, um Benutzerberechtigungen basierend auf ihren Rollen zu vergeben, damit ein effektives Management des Ressourcenzugriffs ermöglicht wird. Diese gängige Technik untermauert die Zugriffskontrolle und ist ein wesentlicher Bestandteil der Autorisierungsfunktionen von Logto. Als umfassende Identitätsmanagementplattform bietet Logto maßgeschneiderte Lösungen für verschiedene Schichten und Entitäten, die Entwicklern und Unternehmen für unterschiedliche Produktarchitekturen dienen. #### API-rollenbasierte Zugriffskontrolle Um allgemeine API-Ressourcen zu schützen, die nicht spezifisch für eine Organisation sind und keine kontextbezogenen Beschränkungen benötigen, ist die **_API RBAC_**-Funktion ideal. Registriere einfach die API und weise jeder Ressource Berechtigungen zu. Dann steuere den Zugriff durch die Beziehung zwischen Rollen und Benutzern. API-Ressourcen, Rollen und Berechtigungen sind hier "demokratisiert" unter einem einheitlichen Identitätssystem. Dies ist ziemlich üblich bei B2C-Produkten mit weniger Hierarchie und braucht keine sehr tiefe Isolationsebene. #### Organisation-rollenbasierte Zugriffskontrolle In der B2B- und Multi-Tenant-Umgebung ist Tenant-Isolation notwendig. Um dies zu erreichen, werden Organisationen als Kontext für Isolation verwendet, was bedeutet, dass RBAC nur dann wirksam ist, wenn ein Benutzer zu einer bestimmten Organisation gehört. Organisation RBAC konzentriert sich auf die Zugriffskontrolle auf Organisationsebene anstatt auf API-Ebene. Dies bietet langfristig erhebliche Flexibilität für die Selbstverwaltung auf Organisationsebene, bleibt jedoch innerhalb eines einheitlichen Identitätssystems. Ein Hauptmerkmal von Organisation RBAC ist, dass Rollen und Berechtigungen im Allgemeinen über alle Organisationen hinweg gleich sind, was das "Organisationstemplate" von Logto äußerst sinnvoll macht, um die Entwicklungseffizienz zu verbessern. Dies stimmt mit der geteilten Philosophie von Multi-Tenant-Apps überein, in der Zugriffskontrollrichtlinien und Identitäten gemeinsame Infrastrukturkomponenten über alle Tenants (App-Tenants) hinweg sind, eine gängige Praxis bei SaaS-Produkten. ## Abschluss Dieser Artikel bietet alles, was du brauchst, um mit der Vorbereitung und Konfiguration von Multi-Tenant-Apps zu beginnen. Probiere Logto noch heute aus und beginne, Best Practices für die Entwicklung von Multi-Tenant-Apps mit Organisationen anzuwenden. Probiere Logto Cloud kostenlos aus