Ein Paket pro Firma

Der stille Kompromiss vieler Cloud-Produkte

Multi-Tenant-Architektur — viele Kunden auf derselben gemeinsamen Infrastruktur, sauber voneinander logisch getrennt — ist aus gutem Grund der Standard in der SaaS-Welt: Sie ist günstiger zu betreiben, einfacher zu aktualisieren, und ein einzelnes Team kann tausende Kunden gleichzeitig bedienen. Der Kompromiss dabei wird selten offen ausgesprochen: Alle Kunden teilen sich am Ende dieselbe Angriffsfläche. Eine Schwachstelle in der Mandantentrennung, ein falsch konfigurierter Zugriff, ein kompromittiertes Administratorkonto beim Anbieter — und im schlechtesten Fall sind nicht nur die Daten eines Kunden betroffen, sondern viele auf einmal.

Für ein Werkzeug, das mit personenbezogenen Daten aus Jira und Confluence arbeitet, wäre dieser Kompromiss an der falschen Stelle eingegangen. JiCo verzichtet deshalb von Grund auf auf das Konzept eines gemeinsamen Mandantensystems — nicht als nachträgliche Härtungsmaßnahme, sondern weil es die Architektur gar nicht erst vorsieht.

Warum es kein „Konto" im Sinne einer Cloud gibt

JiCo läuft lokal, auf der Maschine der jeweiligen Anwenderin oder auf einem Server, den das Unternehmen selbst betreibt — nicht als gemeinsam genutzter Dienst, den mehrere Kunden über das Internet ansprechen. Es gibt deshalb schlicht keinen Datenbestand, in dem die Daten mehrerer Firmen nebeneinander lägen, egal wie sauber getrennt. Ein Sicherheitsvorfall bei einer Installation bleibt technisch auf genau diese eine Installation begrenzt, weil es keine gemeinsame Infrastruktur gibt, über die er sich ausbreiten könnte.

Das ist der Unterschied zwischen „wir trennen die Mandanten sorgfältig" und „es gibt für einen Angreifer physisch nichts, worüber sich ein einzelner Vorfall auf andere Kunden ausweiten ließe". Die zweite Aussage ist stärker, weil sie nicht von der Korrektheit einer Trennungslogik abhängt, die sich mit jeder neuen Funktion erneut bewähren müsste.

Ein Paket gehört zu genau einem Vertriebspartner

Diese Haltung setzt sich in der Auslieferung selbst fort. Ein ausgeliefertes JiCo-Paket gehört immer zu genau einem Vertriebspartner — sei es drkv selbst oder ein Reseller, der JiCo unter eigenem Namen vertreibt. Jedes Paket nimmt technisch ausschließlich Lizenzen an, die mit den Schlüsseln genau dieses einen Partners signiert wurden; Anfragen für neue oder zusätzliche Lizenzen gehen an dessen Lizenz-Portal, nicht an eine zentrale, gemeinsame Stelle für alle Partner gleichzeitig.

Das bedeutet in der Praxis: Selbst innerhalb desselben Vertriebspartners gibt es keinen gemeinsamen Bestand an Jira-/Confluence-Daten — das Lizenz-Portal verwahrt nur Konten und Lizenzen, dazu kommt ein gemeinsamer Signaturschlüssel. Wo die zuständige Lizenzstelle für die eigene Installation liegt, lässt sich jederzeit im Panel unter Einstellungen nachsehen — eine bewusst transparente, keine versteckte Zuordnung.

Der Preis dieser Entscheidung ist real

Dieser Ansatz hat einen offensichtlichen Nachteil, den man nicht kleinreden sollte: Er ist aufwendiger als eine zentrale Cloud-Lösung. Updates müssen auf jeder einzelnen Installation eingespielt werden, statt einmal zentral ausgerollt zu werden. Ein Support-Team kann nicht auf einen Blick den Zustand aller Kunden gleichzeitig einsehen, wie es bei einem zentralen Dashboard möglich wäre. Und ein Kunde, der schnell auf mehreren Rechnern gleichzeitig arbeiten möchte, braucht dafür ebenso viele einzelne Lizenzen, keine einzige, zentral verwaltete.

Diese Kosten sind kein Versehen, sondern die andere Seite derselben Entscheidung: Wer keine gemeinsame Infrastruktur betreibt, kann sie auch nicht zentral und effizient pflegen. JiCo trifft diesen Kompromiss bewusst zugunsten der Sicherheitsarchitektur, nicht aus Unwissen über den Betriebsaufwand, den er verursacht.

Auch eine Sperre bleibt Sache des eigenen Partners

Diese Trennung zieht sich bis in die Frage hinein, was passiert, wenn eine Lizenz gesperrt werden muss — etwa nach wiederholt ausgebliebener Zahlung. Die Sperrliste, die dafür in jedes neu gebaute Paket eingebettet wird, enthält ausschließlich Lizenz-IDs, signiert mit dem Schlüssel genau des einen Vertriebspartners, dem das jeweilige Paket zugeordnet ist. Ein Partner kann damit ausschließlich Lizenzen sperren, die er selbst einmal ausgestellt hat — es gibt keine gemeinsame, gar zentral von drkv kontrollierte Sperrliste über alle Partner hinweg, die versehentlich auch fremde Kunden träfe.

Was das für die Kaufentscheidung praktisch bedeutet

Für Unternehmen, die JiCo einsetzen wollen, heißt das konkret: Es gibt keinen Punkt, an dem man sich fragen müsste, ob die eigenen Jira-Daten irgendwo neben denen eines Wettbewerbers liegen, weil es diesen gemeinsamen Ort schlicht nicht gibt. Es gibt auch keine Migration in eine gemeinsame neue Version, die alle Kunden gleichzeitig betrifft — jede Installation aktualisiert sich in ihrem eigenen Tempo, mit ihren eigenen Freigaben.

Der Preis dafür ist ein Stück des Komforts, den eine zentrale Cloud-Lösung bieten würde. Für ein Werkzeug, dessen einziger Daseinszweck der kontrollierte Umgang mit sensiblen Unternehmensdaten ist, ist das ein Kompromiss, den JiCo bewusst zugunsten der Sicherheit statt zugunsten der Bequemlichkeit trifft.