Mandantenisolierung in einer Multi-Tenant-Anwendung
Mandantenisolierung ist ein Schlüsselkonzept in Multi-Tenant-Anwendungen. In diesem Artikel werden wir besprechen, was es ist und wie es erreicht werden kann.
Product & Design
Hallo zusammen! In diesem Kapitel bauen wir auf unseren früheren Diskussionen zu Multi-Tenant-Themen auf. Wenn du die vorherigen Artikel noch nicht gelesen hast, empfehlen wir, zuerst mit diesen zu beginnen!
Bei der Diskussion über Multi-Tenant-Anwendungen ist es wichtig, an Mandantenisolierung zu denken. Dies bedeutet, die Daten und Ressourcen verschiedener Mandanten innerhalb eines gemeinsamen Systems (zum Beispiel einer Cloud-Infrastruktur oder einer Multi-Tenant-Anwendung) getrennt und sicher zu halten.
Das Ziel der Mandantenisolierung ist sicherzustellen, dass die Daten und Operationen jedes Mandanten voneinander getrennt und sicher bleiben, auch wenn sie dieselben zugrunde liegenden Ressourcen nutzen.
In einem Software-as-a-Service (SaaS)-Szenario beinhaltet die Mandantenisolierung das Erstellen von Strukturen innerhalb des SaaS-Frameworks, die den Ressourcen-Zugang streng regulieren. Dies verhindert unbefugte Versuche, auf die Ressourcen eines anderen Mandanten zuzugreifen.
Auch wenn die Erklärung abstrakt erscheinen mag, werden wir Beispiele und wichtige Details verwenden, um die Isolationsmentalität weiter zu erklären.
Mandantenisolierung widerspricht nicht dem "geteilten" Ansatz der Multi-Tenancy
Dies liegt daran, dass die Mandantenisolierung nicht unbedingt eine Infrastrukturressourcen-Ebene darstellt. Im Bereich der Multi-Tenancy und Isolierung betrachten einige die Isolierung als eine strikte Trennung zwischen tatsächlichen Infrastrukturressourcen. Dies führt normalerweise zu einem Modell, bei dem jeder Mandant separate Datenbanken, Recheninstanzen, Konten oder private Clouds hat. In gemeinsamen Ressourcenszenarien, wie Multi-Tenant-Apps, kann der Weg zur Erreichung der Isolierung eine logische Konstruktion sein.
Die Mandantenisolierung konzentriert sich ausschließlich darauf, den Zugriff auf Ressourcen im "Mandanten"-Kontext zu begrenzen. Sie bewertet den Kontext des aktuellen Mandanten und verwendet diesen Kontext, um zu bestimmen, welche Ressourcen für diesen Mandanten zugänglich sind. Diese Isolierung wird auf alle Benutzer innerhalb dieses Mandanten angewendet. Jeder Versuch, auf eine Mandantenressource zuzugreifen, sollte sich lediglich auf diejenigen Ressourcen beschränken, die diesem Mandanten gehören.
Isolierung erfolgt auf unterschiedlichen Ebenen
Wenn wir verstehen, dass Isolierung nicht streng an die Infrastrukturressourcenebenen gebunden ist und keine klare Trennung zwischen physischer Infrastruktur darstellt, führt dies zu einer Schlussfolgerung wie dieser:
Anstatt Isolierung als einfaches "Ja" oder "Nein" zu betrachten, sollten Sie sie als ein Spektrum ansehen. Sie können Teile Ihres Systems so einrichten, dass sie basierend auf Ihren Bedürfnissen mehr oder weniger isoliert sind.
Das folgende Diagramm veranschaulicht dieses Isolationsspektrum.
Authentifizierung und Autorisierung sind nicht gleich "Isolierung"
Die Verwendung von Authentifizierung und Autorisierung zur Kontrolle des Zugriffs auf Ihre SaaS-Umgebungen ist wichtig, reicht jedoch nicht für eine vollständige Isolierung aus. Diese Mechanismen sind nur ein Teil des Sicherheitspuzzles.
Oft wird die Frage gestellt, ob man allgemeine Autorisierungslösungen und rollenbasierte Zugangskontrolle nutzen kann, um Mandantenisolierung zu erreichen. Sie können eine Multi-Tenant-App erstellen, aber das bedeutet nicht, dass Sie die Strategien zur Mandantenisolierung als Best Practice angewandt haben. Wir empfehlen dies im Allgemeinen nicht, weil
Um dies zu veranschaulichen, betrachten Sie eine Situation, in der Sie Authentifizierung und Autorisierung für Ihr SaaS-System eingerichtet haben. Wenn sich Benutzer anmelden, erhalten sie ein Token mit Informationen über ihre Rolle, die bestimmen, was sie in der Anwendung tun können. Dieser Ansatz erhöht die Sicherheit, gewährleistet jedoch keine Isolierung.
Hier ist der Haken: Ohne die Einbeziehung des "Mandanten"-Kontexts, wie zum Beispiel einer Mandanten-ID, um den Zugriff auf Ressourcen einzuschränken, verhindert die ausschließliche Abhängigkeit von Authentifizierung und Autorisierung nicht, dass ein Benutzer mit der richtigen Rolle auf die Ressourcen eines anderen Mandanten zugreift.
Hier kommt die Mandantenisolierung ins Spiel. Sie verwendet mandantenspezifische Kennungen, um Grenzen zu setzen, ähnlich wie Wände, Türen und Schlösser, um eine klare Trennung zwischen Mandanten zu gewährleisten.
Identität in Multi-Tenancy-Apps
Wir haben über Mandantenisolierung gesprochen, aber was ist mit Identitäten? Wie entscheidest du, ob deine Identitäten "isoliert" sein sollten oder nicht?
Es gibt oft Verwirrung um das Konzept der "Identitätsisolierung." Es könnte sich auf Situationen beziehen, in denen ein realer Benutzer in der allgemeinen Vorstellung zwei Identitäten hat.
- Beide Identitäten können innerhalb eines einzigen Identitätssystems existieren. Zum Beispiel könnte Sarah eine persönliche E-Mail neben einer Unternehmens-E-Mail haben, die durch Single Sign-On (SSO) verbunden sind.
- Benutzer halten zwei verschiedene Identitäten innerhalb separater Identitätssysteme, die völlig unterschiedliche Produkte repräsentieren. Diese Produkte sind völlig unabhängig voneinander.
Manchmal werden diese Szenarien als "Identität isoliert" bezeichnet. Doch dieses Etikett könnte nicht bei der Entscheidungsfindung helfen.
Anstatt zu bestimmen, ob du "Identitätsisolierung" benötigst, solltest du in Betracht ziehen, ob du oder ein Teil deines Unternehmens oder Produkts separate Identitätssysteme aufrechterhalten müssen. Diese Antwort kann deinem Identity and Access Management (IAM)-Systemdesign Orientierung geben. Kurzum, was eine Multi-Tenant-App betrifft,
In den meisten Fällen sind in Multi-Tenant-Apps die Identitäten geteilt, während die Ressourcen jedes Mandanten isoliert sind.
In Multi-Tenant-Anwendungen werden, im Gegensatz zu mandantenspezifischen Ressourcen und Daten, Identitäten unter mehreren Mandanten geteilt. Stelle dir vor, du bist der Hausverwalter; du möchtest nicht zwei separate Namenslisten führen, um die Identitäten deiner Mieter zu verwalten.
Wenn du Mandantenisolierung anstrebst, hast du möglicherweise den wiederkehrenden Schwerpunkt auf dem Begriff "Organisation" beobachtet, der oft als Best Practice für den Aufbau von Multi-Tenant-Anwendungen angesehen wird.
Durch den Einsatz des Begriffs "Organisation" kannst du eine Mandantenisolierung in deiner Multi-Tenant-Anwendung erreichen, während du ein einheitliches Identitätssystem beibehältst. Dies ermöglicht mehreren "Organisationen" eine unabhängige Koexistenz, während sie tenant-agnostische Ressourcen innerhalb der Anwendung teilen. Ähnlich wie Bewohner eines Gebäudes nutzt jede Organisation die Anwendung, ohne sich um ihre Nachbarn zu sorgen, da die "Organisation" die notwendige Trennung in Form von Wänden, Fluren, Türen und Schlössern bietet. Sie teilen die gesamte Gebäudeinfrastruktur, das Innenarchitektur-System und verschiedene greifbare oder immaterielle Komponenten.
Logto führt im November die "Organisations"-Funktion ein
Logto befindet sich derzeit in der aktiven Entwicklung der "Organisations"-Funktion, mit dem Ziel einer Einführung im November 2023. Diese Funktion ist speziell darauf zugeschnitten, die Anforderungen an die Mandantenisolierung zu erfüllen, die für den Aufbau eines SaaS-Produkts erforderlich sind, und dabei den Industriestandards und Best Practices gerecht zu werden.
Im kommenden Kapitel werden wir tiefer in die "Organisations"-Funktion eintauchen und wie Logto die Implementierung von Best Practices für den Aufbau einer Multi-Tenant-Anwendung erleichtert.