Da die Cloud in allen Sektoren unabhängig von der Größe demokratisiert wurde, ist das Multi-Tenant-Modell zu einer Möglichkeit geworden, eine gemeinsame Anwendungsinstanz, Server und physische Infrastruktur gemeinsam zu nutzen. Die Verwendung einer gemeinsamen Umgebung ist jedoch mit einem höheren Risiko und einer Datenkompromittierung verbunden.
Sollten wir der Public Cloud vertrauen? Die Antwort ist natürlich ja. Eine Public Cloud ist in vielerlei Hinsicht sicherer als Ihr eigenes Rechenzentrum. Aber würde die Tatsache, dass viele Clients dieselben physischen Geräte verwenden, nicht ein Sicherheitsproblem darstellen? Ist nicht jedes Multi-Tenant-System von Natur aus weniger sicher? Zunächst müssen die Bedingungen der Multi-Tenant- und Single-Tenant-Umgebung vereinbart werden. Wie Sie vielleicht erwarten, ist die Antwort nicht so einfach, wie es scheint. Betrachten Sie das Beispiel einer einfachen Nicht-Cloud-Anwendung, die in einem Rechenzentrum ausgeführt wird. Das folgende Diagramm zeigt ein solches System.
Diagramm 1: Individuelles Mieter-Infrastrukturmodell. (Bildnachweis: IDG)
Hier sehen Sie zwei Clients, die jeweils eine separate Instanz einer Anwendung auf unterschiedlichen und separaten physischen Servern ausführen. Die beiden Server können sich im selben Rechenzentrum befinden und dieselbe Netzwerkinfrastruktur gemeinsam nutzen, aber sie teilen sich keine anderen physischen Ressourcen. Da sie beide separate Recheninstanzen (mit separaten Servern, Arbeitsspeicher und Speicherarrays) ausführen, ist es äußerst schwierig, wenn nicht unmöglich, dass sich die Informationen des linken Clients mit den Informationen des rechten Clients überschneiden.
Wenn Sie diesem Setup jedoch einen dritten Client hinzufügen möchten, benötigen Sie eine dritte Instanz der App, die den Kauf und die Einrichtung eines dritten physischen Servers mit der entsprechenden installierten Hardware und Software erfordert. und aktualisieren und konfigurieren. Im Allgemeinen ist das Hinzufügen eines neuen Kunden eine sehr langsame, mühsame und teure Aufgabe. Auf der anderen Seite sind die Kunden durch Wände aus physischen Geräten getrennt. Dies ist eine Beispielanwendung in einer Einzelmandantenumgebung mit eigener Datenbank.
Mandantenfähig virtuell
Vergleichen Sie das obige Single-Tenant-Modell mit dem im zweiten Diagramm gezeigten Modell.
Diagramm 2: Ein mandantenfähiges Modell in Verbindung mit Servervirtualisierung. (Bildnachweis: IDG)
In dieser Konfiguration haben Sie dieselben zwei Clients, die zwei separate Instanzen der Anwendung verwenden. Aber in diesem Fall laufen sie alle auf zwei virtuellen Servern, die sich tatsächlich auf demselben physischen Server befinden. Dies ist ein Beispiel für eine gemeinsam genutzte Site mit Servervirtualisierung, die seit den späten 1980er und frühen 1990er Jahren verwendet wird. Die Idee ist, dass sich jede Anwendung auf einem separaten „logischen“ Server befindet, aber beide virtuellen Server sich auf derselben physischen Maschine befinden.
Dieses Modell verbessert die Möglichkeit, Anwendungen und Software einfacher zu verschieben als das Single-Tenant-Modell. Wenn jetzt ein neuer Kunde zu Ihnen kommt, müssen Sie keinen völlig neuen physischen Server mit der richtigen Hardware und Software einrichten. Sie müssen lediglich eine neue Instanz eines virtuellen Servers starten. Es handelt sich um einen einfachen Befehl oder API-Aufruf, der normalerweise einfach durchzuführen ist. Solange der physische Server über genügend Kapazität verfügt, können Sie mehrere virtuelle Server mit einem einzigen API-Aufruf ausführen. Neue Hardware ist nur erforderlich, wenn zusätzliche physische Ressourcen erforderlich sind.
Mandantenfähiges, nachhaltiges Modell
Tatsächlich ist dieses Modell so leistungsfähig, dass es die Grundlage für die Anfänge des Cloud Computing war. Die Servervirtualisierung ermöglichte es Cloud-Computing-Anbietern, virtuelle Serverinstanzen direkt an Organisationen zu verkaufen, sodass diese Instanzen nach Bedarf ausführen und beenden konnten. Es ist die Grundlage des EC2-Dienstes von AWS, dann gleichwertiger Dienste von Microsoft Azure, Google Cloud Platform und anderen öffentlichen Clouds. Neue Instanzen können für einen bestimmten Zeitraum an Kunden geleast und dann für andere Unternehmen freigegeben werden.
Clients sind durch Wände für virtuelle Maschinen getrennt. Dies sind Wände, die Hardwarewänden ähneln, aber durch Virtualisierungssoftware simuliert werden. Und obwohl das Hinzufügen von Clients einfacher ist, müssen immer noch neue virtuelle Serverinstanzen gestartet werden, was Ressourcen verbraucht. Dieses Modell wird als „physisches Multi-Tenant-, hypothetisches Single-Tenant“-Modell bezeichnet. Der Name rührt daher, dass jede virtuelle Instanz einem einzigen Client mit eigener Instanz der Software zugeordnet ist, während die virtuellen Instanzen alle auf gemeinsam genutzten physischen Maschinen laufen.
Einfaches und kostengünstiges SaaS-Modell
Es gibt noch ein weiteres Modell: das Multi-Tenant-Modell. Bei diesem Modell teilen sich mehrere Clients dieselbe Anwendungsinstanz mit einer gemeinsam genutzten Datenbank, die auf denselben Servern und derselben Infrastruktur ausgeführt wird. In diesem Fall sieht das Programm die Trennung eines Clients vom anderen vor – es gibt keine physische Trennung. Clients werden nur durch Programme getrennt. Dieses Modell wird Multi-Tenant-Modell genannt. Es ist allgemein als SaaS-Modell bekannt.
Diagramm 3: Ein mandantenfähiges Modell, das von SaaS-Anwendungen unterstützt wird. (Bildnachweis: IDG)
In diesem Fall ist es sehr einfach, einen Client hinzuzufügen. Es ist keine virtuelle oder physische Hardware erforderlich. Solange der primäre Computer über genügend Ressourcen verfügt, können Sie einen zusätzlichen Client hinzufügen, indem Sie einfach eine Datenbank aktualisieren oder einen Eintrag in der Konfigurationsdatei hinzufügen. Das Hinzufügen von Kunden ist schnell, einfach und kostengünstig.
Ist mandantenfähig sicher?
Ist ein Einzelmieter sicherer als ein Mitbewohner mit mehreren Mitbewohnern? Dies ist eine häufig gestellte Frage, die schwer zu beantworten ist. Beide Formen können sicher sein und beide können gefährlich sein. Wenn es um böswillige Akteure geht, böswillige Personen, die versuchen, das Programm anzugreifen, sind beide Modelle gültig. Beide erfordern sichere Prozesse und Verfahren zum Schutz vor den schlechten Elementen. Aber was ist mit versehentlichen Sicherheitsverletzungen? Was ist beispielsweise mit der versehentlichen Offenlegung der Daten eines Kunden gegenüber einem anderen Kunden? Sicherlich besteht bei einer schlecht konzipierten Multi-Tenant-SaaS-Implementierung die Gefahr, dass Daten anderen Verbrauchern offengelegt werden, die dieselbe gemeinsame Umgebung verwenden. Um sich davon zu überzeugen, schauen Sie sich einfach das folgende Diagramm an.
Abbildung 4, die Sicherheitsprobleme zwischen Kunden veranschaulicht, variiert je nach Miettyp. (Bildnachweis: IDG)
Schauen wir uns zunächst eine echte Single-Tenant-Anwendung an, wie die oben links im Diagramm oben gezeigte. Damit die Daten eines Clients versehentlich einem anderen Client angezeigt werden, müssen sie zwischen physischen Servern übertragen werden. Es ist nicht einfach, und es ist schwer vorstellbar, wie das zufällig passieren konnte. Bei einem Single-Tenant-System ist die Wahrscheinlichkeit geringer, dass gelegentlich Sicherheitsprobleme auftreten.
Die mandantenfähige Anwendung auf einem virtuellen Server, die im oberen rechten Teil des Diagramms dargestellt ist, ist etwas anders. Damit Daten fälschlicherweise in dieser Form angezeigt werden, müssen sie starke hypothetische Grenzen überschreiten. Es ist zwar schwer vorstellbar, dass das passiert, aber es ist nicht unmöglich. Tatsächlich offenbarten die Sicherheitslücken Meltdown und Spectre vor einigen Jahren einen Fehler in der Servervirtualisierung, der diese Art von Offenlegung hätte verursachen können, aber dieser Fehler wurde behoben.
SaaS birgt mehr Risiken
In einer echten Multi-Tenant-Anwendung – einer SaaS-Anwendung – wie der unten im Diagramm gezeigten, besteht eine höhere Wahrscheinlichkeit, dass Softwarefehler Daten zwischen Clients offenlegen. Dies liegt daran, dass die Trennung von Clients vollständig auf der Anwendungsebene erfolgt, ohne Trennung in den zugrunde liegenden oder virtuellen Maschinen. Theoretisch könnte ein Softwarefehler dazu führen, dass die Daten eines anderen Clients unerwartet offengelegt werden.
Es ist ein Risiko. Aber in Wirklichkeit ist dieses Risiko nicht so groß, wie es scheint, wenn ein Kunde hochwertige SaaS-Anwendungen von namhaften Unternehmen nutzt. Alle Sicherheitslücken im Zusammenhang mit einer versehentlichen Offenlegung von Daten zwischen Mietern werden mit Sicherheit sehr schnell behoben. Diesem speziellen Problem wird viel Aufmerksamkeit geschenkt. Aber es ist ein Anliegen, das Kunden berücksichtigen müssen, wenn sie sich für ein SaaS-Unternehmen entscheiden und entscheiden, welche Daten sie ihnen anvertrauen.
Warum mandantenfähig?
Wenn ein einzelner Mandant theoretisch sicherer ist als ein Multi-Tenant, warum sollte man dann einen Multi-Tenant verwenden? Erstens lassen sich Multi-Tenant-Systeme angesichts der oben genannten Anwendungsfälle einfacher erweitern und neue Kunden leichter hinzufügen. Die zusätzlichen Kosten für das Hinzufügen eines neuen Kunden in einem Single-Tenant-System sind ziemlich hoch, da sie die Kosten für neue Hardware, Installation, Konfiguration, Wartung, Software, Upgrades usw. beinhalten. Im Gegensatz dazu sind die Grenzkosten eines neuen Kunden in einem echten Multi-Tenant-SaaS-System fast null; Die Integration kann buchstäblich so einfach sein wie das Hinzufügen einer einzelnen Zeile zu einer Datenbank. Multi-Tenant-SaaS-Systeme ermöglichen es Resellern, „Try before you buy“-Funktionalität in ihre Anwendungen einzubauen und wirklich kostenlose Tarife zu implementieren, während die Rentabilität erhalten bleibt. Dies ist in einer Single-Tenant-App und -Geräten fast unmöglich.
Ein mandantenfähiges System erleichtert auch das Hinzufügen von Ressourcen zu einer laufenden Anwendung, wenn diese mit einer zusätzlichen Last fertig werden muss. Wenn eine Anwendung eine Reihe von Servern erfordert, um die Last zu bewältigen, und der Benutzer eine Traffic-Spitze bemerkt, kann zusätzliche Serverkapazität unterwegs hinzugefügt werden, in Sekunden für ein System mit Multi-Tenant-VMs. Bei einer echten Single-Tenant-Anwendung kann es manchmal Tage oder Wochen dauern, physische Server zu kaufen, zu installieren und zu konfigurieren. Da das Hochskalieren der Kapazität einer Single-Tenant-App lange dauert, muss die Kapazität Monate im Voraus geplant werden. Der Benutzer muss seine Bedürfnisse einschätzen und über ausreichende Überkapazitäten verfügen, um ungewöhnliche oder unerwartete Höhen bewältigen zu können. Meistens bleibt diese zusätzliche Kapazität ungenutzt, was die laufenden Kosten der Anwendung erhöht. Bei einem Multi-Tenant-System kann zusätzliche Kapazität unterwegs nur bei Bedarf hinzugefügt werden, indem mehr virtuelle Server bereitgestellt werden. Da Geräte in einer Multi-Tenant-Infrastruktur gemeinsam genutzt werden, wird überschüssige Kapazität über mehrere Clients hinweg amortisiert.
Mandantenfähige Zukunft
Die Zukunft moderner Anwendungen sind mandantenfähige Anwendungen, die in virtuellen Umgebungen ausgeführt werden. Single-Tenant-Anwendungen werden immer seltener und hauptsächlich für lokale Rechenzentrumsumgebungen reserviert, normalerweise im Metallic-Modus, um die Leistung zu verbessern. Sicherheitsbedenken für mandantenfähige Systeme sind einfach Teil des übergreifenden Sicherheitsrahmens für alle Anwendungen. Sammlung ist die Grundlage der Public Cloud. Es ist das Rückgrat aller wichtigen Produktionsbetriebsumgebungen und definiert, wie Anwendungen heute und in Zukunft erstellt und bereitgestellt werden. Schließlich tobt seit mehr als 15 Jahren die Debatte über die Cloud: Einige Puristen argumentieren, dass eine echte Cloud nur mandantenfähig sein kann und dass der Single-Tenant-Modus ein einfacher Managed Service ist.