„Open Source“ kann im MDM vier verschiedene Dinge heißen: vollständig quelloffen, Open Core, Source-Available oder ein Gratis-Tarif. Nur die ersten beiden geben dir Rechte, die in einem Security-Review oder bei einem Anbieterwechsel zählen.
Die anderen beiden sind meist nur ein freundlicherer Name für eine Preisstufe.
Der Begriff steht auf fast jeder Produktseite für Mobile Device Management. Was dahintersteckt, lässt sich in etwa zwanzig Minuten klären. Tu das, bevor eine Flotte mit mehreren tausend Geräten von der Antwort abhängt.
Vier Dinge, die Anbieter damit meinen
- Vollständig quelloffen: Der Code steht unter einer Lizenz, die die Open Source Initiative anerkennt, etwa Apache 2.0, GPL oder AGPL. Du kannst ihn lesen, betreiben, verändern und deine veränderte Version beliebig lange weiterbetreiben.
- Open Core: Ein kostenloser Kern ist wirklich offen. Die Funktionen, die über einen Unternehmenseinsatz entscheiden, stecken in einer geschlossenen kommerziellen Edition. Etwa Single Sign-on, Audit-Logging, Mandantenfähigkeit oder Compliance-Reports. Den offenen Teil kannst du prüfen, im Einsatz hättest du aber die kommerzielle Edition.
- Source-Available: Du kannst den Code lesen, aber die Lizenz schränkt ein, was du damit tun darfst. Die Business Source License, die Server Side Public License und die Elastic License gehören hierher. Keine davon ist von der OSI anerkannt, trotzdem nennen Anbieter ihre Produkte damit offen.
- Gratis-Tarif: Nichts ist offen. Das Produkt ist nur unterhalb einer bestimmten Geräteanzahl kostenlos.
Der Test braucht eine E-Mail. Frag nach dem Lizenznamen und der Repository-URL und gleiche die Lizenz mit der OSI-Liste ab. Vage Antworten bedeuten meist Open Core oder Source-Available.
Die Lizenz entscheidet, was du mit deinen eigenen Änderungen darfst
Permissive Lizenzen wie Apache 2.0, MIT und BSD erlauben dir, die Software zu verändern und deine Änderungen für dich zu behalten.
Copyleft-Lizenzen wie die GPL verlangen, dass du deine Änderungen veröffentlichst, wenn du die veränderte Software weitergibst.
Die AGPL dehnt diese Pflicht auf Software aus, die über ein Netzwerk angeboten wird. Angenommen, du veränderst eine AGPL-lizenzierte Management-Plattform und verwaltest damit Geräte für Dritte. Dann kann die Pflicht greifen, obwohl du niemandem eine Datei geliefert hast.
Für eine interne IT-Abteilung kommt das selten vor. Für ein Unternehmen, das Geräte im Auftrag seiner Kund*innen verwaltet, ist es eine Frage für die Rechtsabteilung, nicht für die IT. Frag vor dem Rollout, nicht danach.
Server und Agent sind zwei verschiedene Codebasen
Hier werden die meisten Open-Source-Versprechen in dieser Kategorie dünn. Ein MDM besteht aus einem Server und einem Agent.
Der Server enthält die Konsole und die Datenbank. Der Agent läuft mit privilegiertem Zugriff auf dem Gerät und setzt die Regeln tatsächlich durch.
Das veröffentlichte Repository ist meist der Server. Dein Security-Team interessiert sich für den Agent, weil er die Berechtigungen hat.
Die Frage für ein Security-Review ist also enger als „Ist es Open Source?“. Bekommt dein*e Auditor*in den Quellcode des Agents, und zu welchen Bedingungen? Kannst du prüfen, dass die Binärdatei, die du ausrollst, aus diesem Code gebaut wurde?
Ein Repository, das du lesen kannst, ist weniger wert, wenn niemand bestätigen kann, dass das Paket auf zehntausend Geräten daraus stammt.
Offener Code und Datenhoheit sind getrennte Fragen
Eine offene Lizenz sagt dir, was die Software tut. Wo sie läuft, ist eine eigene Entscheidung.
Ein Produkt kann vollständig quelloffen sein und trotzdem nur als gehosteter Dienst des Anbieters angeboten werden. Dann liegen dein Geräteinventar, dein Standortverlauf und deine Compliance-Daten in der Cloud des Anbieters, unter dessen Betriebshoheit.
Ob es Self-Hosting überhaupt gibt, entscheidet jeder Anbieter unabhängig von der Lizenz. Viele Open-Source-Plattformen bieten es nicht an.
Beide Antworten zählen für eine DSGVO-Bewertung, und sie kommen aus unterschiedlichen Fragen.
Für die Daten selbst frag, welche Felder der Agent erhebt und wie oft. Frag, wie lange sie gespeichert werden und ob sich die Erhebung einschränken lässt.
Für das Hosting frag, wo die Datenbank physisch liegt und welche Angestellten des Anbieters darauf zugreifen können. Stell sicher, dass dieser Zugriff im Auftragsverarbeitungsvertrag steht und nicht nur auf einer Webseite beschrieben ist.
Die Ausstiegskosten, die Lizenzen nicht lösen
Das übliche Argument für Open Source in dieser Kategorie lautet, dass es vor Lock-in schützt. Es hilft, aber die größten Kosten eines Wechsels haben nichts mit der Lizenz zu tun.
Unter Android hält das Verwaltungssystem, das ein Gerät eingerichtet hat, den Device Owner. Ein neues System kann das nicht übernehmen.
Bei vollständig verwalteten Geräten, dedizierten Geräten und unternehmenseigenen Geräten mit Arbeitsprofil bedeutet ein Plattformwechsel einen Werksreset und eine neue Registrierung für jedes Gerät. Alle lokalen Daten gehen verloren, sofern sie nicht vorher gesichert wurden. Unser Leitfaden zu Android Enterprise erklärt die Besitzmodelle.
Googles eigener Migrationspfad verschiebt Geräte von einem eigenen Agent zu Android Device Policy innerhalb desselben Enterprise. Zwischen zwei Anbietern verschiebt er keine Geräte.
Wie Jason Baytons EMM-Migrationsleitfaden es formuliert, gibt es einen Anbieterwechsel ohne Löschen derzeit nicht.
Die Ausnahme ist das BYOD-Arbeitsprofil. Du kannst es entfernen und neu registrieren, ohne private Daten anzufassen.
Für die meisten Firmenflotten sind die Ausstiegskosten also körperlicher Natur. Jemand fasst jedes Gerät an, oder alle Angestellten befolgen die Anleitung korrekt, und das Supportaufkommen steigt für einige Wochen. Zero-Touch und Knox Mobile Enrollment reduzieren den Aufwand, aber nicht den Reset.
Was die Lizenz verändert, sind Zeitplan und Rückfallebene.
Mit einer offenen, selbst gehosteten Plattform kannst du den alten Server auf eigener Hardware weiterlaufen lassen, während du in Etappen migrierst. Du kannst die Datenbank exportieren, weil sie dir gehört. Ein Anbieter, der die Preise erhöht oder den Betrieb einstellt, setzt dir keine Frist.
Bei einer gehosteten Plattform ist das Dienstende des Anbieters dein Projekttermin. Du migrierst in seinem Tempo.
Sechs Fragen, die du vor der Unterschrift schickst
- Welche Lizenz, und wie lautet die Repository-URL? Ist die Lizenz von der OSI anerkannt?
- Welche Funktionen stecken in der offenen Edition, welche gibt es nur kommerziell?
- Ist der Quellcode des Geräte-Agents verfügbar, und können wir unseren ausgerollten Build dagegen prüfen?
- Können wir selbst hosten? Wenn ja, unterstützt das die kommerzielle Edition oder nur die kostenlose?
- Welche Daten erhebt der Agent, wo liegen sie, und welche Angestellten des Anbieters können darauf zugreifen?
- Wenn wir in drei Jahren gehen: Was bekommen wir als Export, und was muss mit jedem Gerät passieren?
Was die Antwort wert ist
Open Source beantwortet zwei Fragen gut. Können deine eigenen Leute prüfen, was mit privilegiertem Zugriff auf deinen Geräten läuft? Und kannst du die Plattform weiterbetreiben, wenn die kommerzielle Beziehung endet?
Es beantwortet nicht, wo die Daten liegen. Das entscheidet das Hosting-Modell. Es beantwortet auch nicht, was ein Wechsel kostet. Das entscheidet das Android-Besitzmodell.
Bewerte beides getrennt. Eine permissive Lizenz und eine reine Anbieter-Cloud können im selben Produkt stecken, und das tun sie häufig.
Transparenzhinweis: Dieser Beitrag wurde in Kooperation mit Headwind Computer Systems & Communication Equipment Software entwickelt.