Viele Unternehmen sind stolz, wenn sie sich zu einer Entscheidung für Software-as-a-Service durchgerungen haben. Dabei ist SaaS nicht mehr als ein Überbegriff für alle Softwarelösungen, die extern betrieben werden. Wie der Anbieter sie jeweils bereitstellt, kann in der Praxis sehr unterschiedlich aussehen. Um Aufwand und Kosten zu minimieren, bündelt er häufig die Kunden mit ähnlichen Anforderungen nicht nur auf einer zentralen Plattform, sondern bedient sie auch aus einer einzigen Softwareinstanz heraus. Das kann gravierende Folgen haben und selbst große Unternehmen in Bedrängnis bringen.
Cloud-Kunden als Kollateral-Schaden
Im Sommer 2021 musste die Einzelhandelskette Coop in Schweden insgesamt 800 Läden zeitweilig schließen: Weder die konventionellen Kassen noch die Self-Checkout-Systeme funktionierten. Grund dafür war eine Cyberattacke, die eigentlich nicht Coop galt: Die verwendete Malware wurde von einem Softwarepartner eingeschleppt, der seinerseits ebenfalls nur Kollateral-Schaden eines großangelegten Angriffs auf den Softwareanbieter Kaseya war. Dass statt eines einzelnen Unternehmens plötzlich eine ganze Reihe von Kaseya-Kunden Probleme bekam, hatte einen einfachen Grund: Der Coop-Partner nutzte eine Software, die auf einer Multi-Tenant-Architektur bereitgestellt wurde. Hier laufen die Anwendungen für unterschiedliche Kunden auf einer Softwareinstanz, die wiederum auf eine gemeinsame Datenbank zugreift. Sind die Anwendungen nicht sauber voneinander getrennt, können sie sich gegenseitig infizieren oder zu enormen Performance-Einbußen führen. Das bedeutet im Klartext: Wird ein Kunde angegriffen, sind meist andere mit betroffen.
Eine teure Alternative
Eine derartige Architektur erleichtert insgesamt den unberechtigten Zugriff auf die Daten anderer Unternehmen – sei es, um sie zu stehlen oder um sie böswillig zu manipulieren. Organisationen, die in wettbewerbsintensiven oder sicherheitskritischen Branchen aktiv sind, bestehen deshalb darauf, dass SaaS-Anbieter ihnen eine eigene Server-Plattform bereitstellen – einen „Dedicated Server“.
Damit geht allerdings ein Hauptvorteil des Cloud-Modells verloren: der Skaleneffekt. Platt gesagt, wird der Betrieb einer Software umso preisgünstiger, je mehr Kunden dieselben Funktionen auf einer gemeinsamen Plattform nutzen. Wer jedoch eine individuelle Installation benötigt, bekommt sie von den meisten Anbietern auch bereitgestellt – logischerweise jedoch gegen einen hohen Aufpreis.
Multi-Instance statt Multi-Tenant
Für Unternehmen, die nicht gerade Medikamente gegen Morbus Alzheimer entwickeln oder den strengen KRITIS*-Bestimmungen genügen müssen, ist ein solcher Aufwand sicherlich „Overkill“. Aber es gibt einen vernünftigen Kompromiss: Die Software von derselben Plattform zu beziehen wie die Mitbewerber ist wenig problematisch – solange jeder Kunde eine ausführbare Kopie der Anwendung (eine eigene „Instanz“) erhält, die nur er selbst nutzen kann.
In einer sogenannten Multi-Instance-Architektur* ist jede Instanz genau einem Kunden zugeordnet, und dessen Stamm- und Bewegungsdaten werden in einer separaten SQL-Datenbank abgelegt. Der Vorteil: Die Instanzen sind klar abgegrenzt, die Daten sicher verschlüsselt. So lassen sich Vermischungen und unberechtigte Zugriffe weitgehend ausschließen. Dieses Konzept ist im Marktsegment Beschaffungs-Software allerdings noch nicht richtig angekommen und Stand heute eher die Ausnahme als die Regel.
Wenn der Standard gesprengt wird
Das ist schade und auch erstaunlich, denn neben dem Sicherheitsaspekt spricht noch ein anderes Kriterium für Multi-Instance-Lösungen: Sie erlauben individuellere und flexiblere Implementierungen, die den tatsächlichen Bedürfnissen der Kunden entsprechen.
In einem Multi-Tenant-System bestimmt der Anbieter, was seine Kunden brauchen. Doch jedes Unternehmen hat nun einmal seine eigenen Prozesse – ganz besonders im Einkauf. Benötigt es eine Funktion, die im Standard nicht enthalten ist, bekommt es häufig zu hören: „Das brauchen Sie nicht, das können Sie auch mit der Funktion xy abdecken.“
Es sei denn, der Anbieter hat dieselbe Anforderung bereits mehrfach erhalten. In diesem Fall erwägt er vielleicht, sie irgendwann einmal umzusetzen, weil er sie an unterschiedliche Kunden weiterverkaufen kann. Er wird sich aber meist hüten, einen konkreten Termin zu versprechen, denn er muss zunächst herausfinden, wie sich die Änderung oder Ergänzung auf die innere Struktur des Software-Services auswirkt. Diese Situation ähnelt der eines Installateurs, der auf Kundenwunsch ein Waschbecken versetzen oder ein zweites anbringen soll und erst einmal die Rohrleitungen unter dem Wandputz prüfen und anpassen muss.
Was aus Sicht des Kundenunternehmens ganz einfach aussieht – und es auch sein sollte, beispielsweise ein alternativer Workflow für Genehmigungen – erfordert innerhalb einer Multi-Tenant-Umgebung intensive strategische und taktische Überlegungen. Manchmal kommt der Anbieter an den Punkt, wo er zu zweifeln beginnt, ob der dafür notwendige Aufwand sich am Ende überhaupt auszahlt.
In einer Multi-Instance-Architektur lässt sich die Anwendung von Anfang an deutlich individueller konfigurieren. Der Kunde kann auch mit einer Standardkonfiguration beginnen, die nach und nach ausgebaut wird. Basiert die Software auf Low-Code- oder No-Code-Technologie, können verantwortliche Administratoren sie über eine grafische Oberfläche leicht eigenständig anpassen – ganz ohne aufwändige Programmierung. In Zeiten knapper Budgets schmeckt diese Souveränität auch dem internen IT-Team besser als die regelmäßige Beauftragung externer Dienstleister.
Einkaufstipp: Penetrationstest bitte
Mit den Einzelheiten ihrer Softwarearchitektur halten die Anbieter gern hinter dem Berg. Viele kennen zwar die Vorteile einer Multi-Instance-Lösung, können oder wollen sie aber aus unterschiedlichen Gründen nicht anbieten. Entscheidungsträger, die es genau wissen wollen, sollten exakt danach fragen und den künftigen Softwarelieferanten um einen Penetrationstest bitten. Der besteht unter anderem darin, eine riesige Menge an Anfragen, etwa 10.000 in der Minute, an den jeweiligen Server zu schicken und ihn mit Spezialsoftware umfassend auf Sicherheitslücken zu prüfen.
Betreibt der Softwarelieferant eine Multi-Instance-Lösung, wird er sich darauf einlassen. In einem Multi-Tenant-System würde dieser Penetrationstest den Softwaredurchsatz aller angeschlossenen Kunden in die Knie zwingen.
Entscheider, die besonders großen Wert auf ein hohes Sicherheits-Level legen, können neben der Prüfung der NIST 800–53-, ISO/IEC 27001– und SOC 2-Zertifizierungen den SaaS-Anbieter zusätzlich fragen, ob er auch die US-Bundesbehörden beliefern dürfte. Will der das zu Recht bejahen, muss er auf dem so genannten FedRAMP-Marktplatz gelistet sein. Dies lässt sich leicht mit einer Kurzrecherche auf marketplace.fedramp.gov prüfen.
Individueller und flexibler
Die dortige Listung ist an harte Kriterien geknüpft: Das Federal Risk and Authorization Management Programm, wie FedRAMP ausgeschrieben heißt, ist ein standardisierter Ansatz für die Sicherheitsbewertung, Autorisierung und Überwachung von Cloud-Produkten und Services, die an US-Behörden geliefert werden. Das Programm soll vier Qualitätsmerkmale sicherstellen: dass die IT-Systeme und -Dienste eine angemessen hohe Informationssicherheit mitbringen, dass sie keine Doppelaufwände verursachen, die Kosten für das Risiko-Management verringern sowie eine schnelle und kostengünstige Beschaffung von Informationssystemen ermöglichen.
Bild: Heike ZonsJan-Hendrik Sohn
Regional Vice President DACH und CEE von Ivalua
Gut zu wissen
Multiple Instances: Mandanten werden einzelne Anwendungsinstanzen zugeordnet; alle Nutzer teilen die selbe Hardware, aber die Anwendung wird auf eigenen virtuellen Servern betrieben
Multi-Tenancy: Alle Nutzer teilen sich dieselbe Software, Hardware sowie Infrastruktur; die Daten aller Nutzer sind in selben System. Eine Multi-Tenancy-Architektur versorgt mit einer einzigen Softwareinstanz mehrere unterschiedliche Nutzer. Jeder User hat zwar seine eigenen Zugriffsrechte, Konfigurationsdetails, Daten und Datenpräsentationen, greift jedoch auf dieselbe Software, Systemumgebung und Hardware zu.
*Kritische Infrastrukturen (KRITIS) sind Organisationen und Einrichtungen mit wichtiger Bedeutung für das staatliche Gemeinwesen, bei deren Ausfall oder Beeinträchtigung nachhaltig wirkende Versorgungsengpässe, erhebliche Störungen der öffentlichen Sicherheit oder andere dramatische Folgen eintreten würden.
Quelle: www.ahd.de
