meetling
Alle Beiträge
open-sourcesichere-videokonferenzdigitale-souveränität

Open-Source-Videokonferenzen: strategische Freiheit für Unternehmen

von Emanuel Holzmann

Offene Videokommunikation als Teil einer souveränen Unternehmens-IT

Videokommunikation ist strategische Infrastruktur

Videokonferenzen sind längst mehr als ein Hilfsmittel für gelegentliche Online-Meetings. Über sie laufen Bewerbungsgespräche, Vertragsverhandlungen, Vorstandssitzungen, Projektabstimmungen und Gespräche mit Kunden, Kanzleien oder Behörden. In Industrieunternehmen werden Entwicklungsstände besprochen, in Finanzunternehmen personenbezogene und geschäftskritische Informationen, in der Sicherheits- und Rüstungsindustrie möglicherweise Inhalte mit besonders hohem Schutzbedarf.

Damit wird die Videokonferenzplattform zu einem Teil der kritischen Kommunikationsinfrastruktur. Ihre Auswahl betrifft nicht nur Funktionen und Lizenzpreise, sondern auch Informationssicherheit, Datenschutz, Geschäftskontinuität, Beschaffung und die langfristige Handlungsfähigkeit der IT. Das BSI-Kompendium für organisationsinterne Telekommunikationssysteme mit erhöhtem Schutzbedarf betrachtet solche Systeme deshalb über den gesamten Lebenszyklus – von Planung und Beschaffung über Betrieb und Audit bis zum Rückbau.

Eine Open-Source-Videokonferenz ist in diesem Zusammenhang keine rein technische Alternative zu Microsoft Teams, Zoom oder Google Meet. Sie kann Teil einer Unternehmensstrategie sein, mit der Organisationen ihre Abhängigkeiten bewusst gestalten, Datenwege kontrollierbarer machen und realistische Wechselmöglichkeiten erhalten.

Wann Anbieterabhängigkeit zum Unternehmensrisiko wird

Proprietäre Cloudplattformen können leistungsfähig, komfortabel und wirtschaftlich sinnvoll sein. Das Risiko entsteht nicht allein durch die Wahl eines großen Anbieters, sondern durch eine Abhängigkeit, für die es weder Transparenz noch einen belastbaren Ausstiegsplan gibt.

Diese Abhängigkeit reicht häufig weiter als der eigentliche Videocall. Benutzerkonten, Kalender, Einladungsprozesse, Aufzeichnungen, Raumhardware, Telefonie, Compliance-Funktionen und Supportprozesse greifen ineinander. Je tiefer die Plattform in den Arbeitsalltag eingebunden ist, desto aufwendiger wird ein späterer Wechsel. Änderungen an Preisen, Vertragsbedingungen, Produktfunktionen, Schnittstellen oder Datenverarbeitung können dann nur noch begrenzt beantwortet werden.

Für IT-Verantwortliche entstehen dabei mehrere organisatorische Fragen:

  • Kann das Unternehmen den Dienst auch dann weiterführen, wenn der Anbieter sein Produkt oder seine Konditionen grundlegend ändert?
  • Lassen sich Identitäten, Konferenzdaten, Aufzeichnungen und organisatorische Prozesse in ein anderes System überführen?
  • Ist nachvollziehbar, wo Daten verarbeitet und gespeichert werden und welche Unterauftragnehmer beteiligt sind?
  • Gibt es technische Alternativen für den Betrieb, oder ist die Organisation an eine bestimmte Cloud, Lizenz oder Hardware gebunden?
  • Können Sicherheitsanforderungen selbst überprüft werden, oder ist das Unternehmen vollständig auf Herstellerangaben angewiesen?

Auch die NIS2-Richtlinie behandelt Lieferketten, Dienstleisterbeziehungen, Geschäftskontinuität, Schwachstellenmanagement, Zugriffskontrollen und abgesicherte Sprach-, Video- und Textkommunikation als Bestandteile eines risikobasierten Sicherheitsmanagements. Nicht jedes Unternehmen fällt unmittelbar in ihren Anwendungsbereich. Die genannten Themen sind dennoch eine sinnvolle Orientierung für verantwortbare IT-Entscheidungen.

Was Open Source organisatorisch verändert

Open Source bedeutet zunächst, dass der Quellcode unter einer Lizenz verfügbar ist, die Nutzung, Prüfung und – abhängig von den konkreten Lizenzbedingungen – Veränderung und Weitergabe erlaubt. Für Unternehmen ist jedoch weniger entscheidend, ob die eigene IT jede Codezeile liest. Entscheidend ist, welche Handlungsoptionen daraus entstehen.

Prüfbarkeit statt reiner Herstellerauskunft

Einsehbarer Quellcode ermöglicht unabhängigen Fachleuten, Architektur und Implementierung zu untersuchen. Sicherheitsprüfungen können durch den Betreiber, spezialisierte Dienstleister oder Auditoren erfolgen. Fehler werden dadurch nicht automatisch gefunden und schon gar nicht automatisch behoben. Das Unternehmen ist aber nicht ausschließlich auf die Aussagen und Prüfprozesse eines einzigen Herstellers angewiesen.

Die Open-Source-Strategie der Europäischen Kommission hebt genau diese Kontrollmöglichkeit hervor: Offener Code kann unabhängige Audits und reproduzierbare Builds ermöglichen und damit die Kontrolle über Prozesse, Daten und Technologie unterstützen. Die aktuelle Initiative der EU-Kommission zur technologischen Souveränität ordnet Open Source zudem ausdrücklich als Baustein größerer digitaler Autonomie ein.

Wahlfreiheit beim Betrieb

Eine offene Lösung kann grundsätzlich in der eigenen Infrastruktur, in einer Private Cloud, bei einem spezialisierten Betreiber oder als souveräner Managed Service eingesetzt werden. Ob alle Modelle tatsächlich verfügbar und wirtschaftlich sinnvoll sind, hängt vom jeweiligen Projekt, seiner Lizenz, seiner Architektur und dem Dienstleistungsmarkt ab.

Diese Wahlfreiheit verändert die Verhandlungsposition. Betrieb und Software müssen nicht zwingend vom selben Unternehmen bezogen werden. Ein Wechsel des Infrastruktur- oder Supportpartners kann möglich sein, ohne zugleich die gesamte Plattform zu ersetzen. Das reduziert keinen Aufwand auf null, schafft aber Alternativen zu einem technisch und vertraglich schwer auflösbaren Vendor Lock-in.

Ein realistischer Exit wird planbar

Ein Quellcode-Repository allein ist noch keine Exit-Strategie. Für einen belastbaren Wechsel benötigt das Unternehmen dokumentierte Schnittstellen, exportierbare Daten, Kenntnisse über Abhängigkeiten und ein Zielbetriebsmodell. Open Source verbessert die Ausgangslage, weil Software und Know-how nicht vollständig hinter einer Herstellerschnittstelle verschwinden. Anpassungen können weitergeführt, Migrationswerkzeuge entwickelt und Übergangsmodelle aufgebaut werden – vorausgesetzt, Kompetenzen und Verantwortlichkeiten sind vorhanden.

Positive Auswirkungen auf die Unternehmens-IT

Richtig in die IT-Governance eingebettet kann eine Open-Source-Videokonferenz mehr bewirken als die Ablösung eines einzelnen Werkzeugs.

Beschaffung wird vergleichbarer. Neben Lizenz- und Nutzungskosten lassen sich Betrieb, Integration, Support, Exit-Kosten und interne Aufwände getrennt bewerten. Angebote verschiedener Dienstleister können auf derselben technischen Basis eingeholt werden. Das stärkt die Verhandlungsposition und macht den Total Cost of Ownership transparenter.

Verantwortlichkeiten werden klarer. Die Organisation muss festlegen, wer für Plattform, Infrastruktur, Updates, Schwachstellen, Datenschutz und Support verantwortlich ist. Was zunächst nach zusätzlicher Arbeit klingt, verhindert in der Praxis unklare Zuständigkeiten zwischen Fachbereich, Cloudanbieter und interner IT.

Internes Wissen wächst. Dokumentierte Architektur, offene Schnittstellen und zugänglicher Code erleichtern es, Know-how im eigenen Team oder bei mehreren Partnern aufzubauen. Die Organisation bleibt dadurch auch bei einem Dienstleisterwechsel handlungsfähiger.

Integration wird gestaltbar. Identitätsmanagement, Verzeichnisdienste, Kalender, Monitoring, Archivierung oder unternehmensspezifische Workflows können in ein Zielbild eingebunden werden. Dabei sollte jede Anpassung bewusst bewertet werden: Zu viele individuelle Änderungen können Updates erschweren und selbst eine neue Form der Abhängigkeit erzeugen.

Sicherheits- und Compliance-Prozesse erhalten mehr Evidenz. Architektur, Datenflüsse, Komponenten und Abhängigkeiten können nachvollziehbarer dokumentiert werden. Das unterstützt Schutzbedarfsanalysen, Freigaben, Audits und Lieferantenbewertungen. Open Source ersetzt diese Prozesse nicht, kann ihnen aber eine bessere Tatsachengrundlage geben.

Open Source als Baustein digitaler Souveränität

Digitale Souveränität bedeutet nicht, jede Anwendung selbst zu entwickeln und im eigenen Rechenzentrum zu betreiben. Für Unternehmen ist sie vor allem die Fähigkeit, informierte Entscheidungen zu treffen und sie praktisch umzusetzen.

Bei souveräner Videokommunikation betrifft das mehrere Ebenen:

  • Datenhoheit: Das Unternehmen kann Anforderungen an Datenwege, Speicherorte, Löschung und Aufzeichnung festlegen und deren Umsetzung prüfen.
  • Technologische Kontrolle: Architektur, Schnittstellen und Abhängigkeiten sind hinreichend nachvollziehbar, um Risiken bewerten zu können.
  • Betriebliche Wahlfreiheit: On-Premise-, Private-Cloud- und Dienstleistermodelle können anhand des Schutzbedarfs ausgewählt werden.
  • Wechselfähigkeit: Daten, Identitäten, Integrationen und Prozesse lassen sich mit vertretbarem Aufwand in ein anderes Betriebsmodell überführen.
  • Kompetenz: Intern oder vertraglich gesichertes Wissen reicht aus, um Störungen, Änderungen und Sicherheitsfragen nicht vollständig an einen einzelnen Hersteller delegieren zu müssen.

Vollständige digitale Souveränität ist kaum erreichbar

Digitale Souveränität darf nicht mit vollständiger technologischer Unabhängigkeit verwechselt werden. Auch eine konsequent offen und selbstbestimmt aufgebaute Videokonferenzplattform bleibt Teil internationaler Lieferketten. Serverprozessoren, Speicher, Netzwerkchips, Switches, Endgeräte und Teile der Rechenzentrumsinfrastruktur stammen häufig von großen, international tätigen Herstellern. Hinzu kommen Netzbetreiber, Firmware, Betriebssysteme, Zertifizierungsstellen, Container-Komponenten und weitere Dienste, die ein Unternehmen nicht vollständig selbst kontrollieren kann.

Die Alternative besteht deshalb nicht darin, entweder vollständig souverän oder vollständig abhängig zu sein. Sinnvoller ist ein abgestufter Ansatz: Unternehmen sollten entlang der gesamten Architektur prüfen, welche Abhängigkeiten kritisch sind, welche transparent gemacht werden können und wo realistische Ausweichmöglichkeiten bestehen. Bei besonders wichtigen Komponenten können mehrere Bezugsquellen, offene Standards, austauschbare Schnittstellen, dokumentierte Datenexporte, eigene Betriebskenntnisse und vertraglich gesicherte Übergaberechte die Handlungsfähigkeit verbessern.

Eine Open-Source-Videokonferenz löst also nicht alle Abhängigkeiten der zugrunde liegenden Infrastruktur. Sie kann jedoch eine zentrale Anwendungsebene kontrollierbarer machen. Unternehmen sollten digitale Souveränität deshalb so weit umsetzen, wie es technisch, organisatorisch und wirtschaftlich sinnvoll möglich ist – und die verbleibenden Abhängigkeiten bewusst dokumentieren, bewerten und absichern. Ziel ist nicht Unabhängigkeit von allen Dritten, sondern die Steuerung kritischer Abhängigkeiten und die Fähigkeit, bei Veränderungen tatsächlich handeln zu können.

Was offener Quellcode nicht automatisch löst

Open Source ist nicht automatisch sicher. Ein öffentliches Repository garantiert weder aktive Wartung noch sichere Voreinstellungen, schnelle Updates oder einen professionellen Betrieb. Ebenso wenig ergibt sich DSGVO-Konformität allein aus der Lizenz der Software. Entscheidend sind die konkrete Konfiguration, die Datenverarbeitung, Verträge, Prozesse und technischen Schutzmaßnahmen.

Besondere Aufmerksamkeit verdient die Software-Lieferkette. Open-Source-Anwendungen bestehen regelmäßig aus zahlreichen Bibliotheken, Paketen und Container-Komponenten. Die ENISA-Empfehlungen zur Sicherheit von Softwarepaketen weisen darauf hin, dass auch indirekte Abhängigkeiten zur vertrauenswürdigen Codebasis werden und entsprechend geprüft, überwacht und aktualisiert werden müssen. Ihr Bericht zu Good Practices for Supply Chain Cybersecurity empfiehlt ein unternehmensweites Lieferkettenmanagement mit Risikobewertung, Lieferantensteuerung, Schwachstellenbehandlung und Qualitätsanforderungen.

Für eine sichere Videokonferenz für Unternehmen sind deshalb mindestens folgende Voraussetzungen zu klären:

  • dokumentierte Installation, Konfiguration und Betriebsprozesse
  • geregeltes Patch- und Schwachstellenmanagement mit verantwortlichen Personen
  • kontrollierte Quellen für Pakete, Abhängigkeiten und Container-Images
  • Monitoring, sicherheitsrelevante Protokollierung und definierte Alarmwege
  • Backup-, Wiederherstellungs- und Notfallkonzepte mit regelmäßig geprüften Verfahren
  • abgesicherte Identitäts- und Berechtigungsverwaltung, möglichst in die bestehende IAM-Strategie integriert
  • Datenschutz-, Aufzeichnungs-, Aufbewahrungs- und Löschkonzepte
  • Supportwege, Reaktionszeiten und SLAs passend zur Kritikalität
  • Kapazitätsplanung, Hochverfügbarkeit und ein getesteter Umgang mit Teilausfällen

Der tatsächliche Sicherheitsgewinn entsteht aus der Verbindung von Transparenz, professionellem Betrieb und wirksamer Governance.

Betriebsmodelle: selbst betreiben oder betreiben lassen?

Open Source verpflichtet nicht zum Eigenbetrieb. Die passende Form richtet sich nach Schutzbedarf, vorhandenen Kompetenzen, Integrationsgrad und Verfügbarkeitsanforderungen.

Vollständig selbst betriebenes On-Premise-Modell

Software und Daten verbleiben in der kontrollierten Infrastruktur des Unternehmens. Dieses Modell bietet großen Gestaltungsspielraum, verlangt aber eigenes Wissen für Plattform, Netzwerk, Medieninfrastruktur, Updates, Monitoring, Backup und Störungsbehebung. Es eignet sich vor allem, wenn regulatorische, technische oder operative Gründe einen weitgehend eigenen Betrieb rechtfertigen.

Betrieb durch einen spezialisierten Dienstleister

Die Lösung kann in der Infrastruktur des Unternehmens laufen, während ein Dienstleister Installation, Wartung oder Support übernimmt. Verantwortlichkeiten, Zugriffswege, Protokollierung, Reaktionszeiten und Übergaberechte müssen vertraglich eindeutig geregelt sein.

Private Cloud

Eine dedizierte Cloudumgebung kann Kontrolle und Automatisierung verbinden. Entscheidend sind nicht nur der Standort des Rechenzentrums, sondern auch Betreiber, Administrationszugriffe, Unterauftragnehmer, Verschlüsselung, Schlüsselmanagement und Exit-Möglichkeiten.

Souveräner Managed Service

Hier übernimmt ein Anbieter den laufenden Betrieb, während Datenverarbeitung, Hosting, Support und Wechselmöglichkeiten nach definierten Anforderungen gestaltet werden. Das entlastet interne Teams, ohne die Entscheidung über Schutzbedarf und Governance vollständig abzugeben.

Hybridmodell

Hybride Ansätze verteilen Komponenten oder Nutzungsszenarien. Beispielsweise können besonders schützenswerte Besprechungen in einer kontrollierten Umgebung stattfinden, während andere Anwendungsfälle als Managed Service abgedeckt werden. Ein solches Modell benötigt klare Regeln, damit Benutzer wissen, welche Plattform für welchen Schutzbedarf vorgesehen ist.

Prüfliste für die Ablösung von Teams, Zoom oder Google Meet

Ein Wechsel sollte nicht mit einem Funktionsvergleich beginnen, sondern mit den geschäftlichen und regulatorischen Anforderungen. Diese kompakte Prüfliste schafft eine belastbare Grundlage:

  • Schutzbedarf: Welche Gesprächsinhalte, Metadaten und Dokumente werden verarbeitet? Welche Vertraulichkeits-, Integritäts- und Verfügbarkeitsanforderungen gelten?
  • Identitäten und Berechtigungen: Welche Identity Provider, SSO-Verfahren, Rollen, Gastzugänge und Mehrfaktorverfahren sind erforderlich?
  • Kalender und Einladungen: Welche Groupware, Raumressourcen, Stellvertretungen und mobilen Arbeitsabläufe müssen integriert werden?
  • Migration: Welche Konten, Kontakte, Raumstrukturen, Aufzeichnungen oder Richtlinien müssen übernommen werden? Welche Daten können oder sollen bewusst nicht migriert werden?
  • Raumhardware und Telefonie: Können vorhandene Konferenzräume, Kameras, Mikrofone, SIP-Systeme und Einwahlnummern weitergenutzt werden?
  • Aufzeichnungen: Wer darf aufzeichnen, wo werden Dateien gespeichert, wie werden Einwilligung, Zugriff, Aufbewahrung und Löschung geregelt?
  • Datenschutz: Welche Rollen, Verträge, Unterauftragnehmer, Datenstandorte und Drittlandtransfers sind betroffen?
  • Support und Betrieb: Welche Servicezeiten, Eskalationswege, Reaktions- und Wiederherstellungszeiten werden benötigt?
  • Skalierbarkeit und Hochverfügbarkeit: Welche gleichzeitige Nutzung ist realistisch? Wie werden Lastspitzen, Wartungen und Ausfälle einzelner Komponenten behandelt?
  • Notfallbetrieb: Welche Kommunikationsmöglichkeit bleibt bei Ausfall von Internet, Identitätsdienst, Rechenzentrum oder Hauptanbieter verfügbar?
  • Benutzerakzeptanz: Welche Arbeitsabläufe ändern sich? Welche Pilotgruppen, Schulungen und Unterstützungsangebote sind nötig?
  • Exit-Fähigkeit: Sind Datenformate, Schnittstellen, Dokumentation, Betriebswissen und vertragliche Übergaberechte für einen späteren Wechsel vorhanden?

Ein Pilot sollte nicht nur Bild- und Tonqualität testen. Er sollte auch Provisionierung, Gastzugang, Administrationsaufwand, Monitoring, Supportfälle, Barrierefreiheit und Wiederherstellung unter realistischen Bedingungen prüfen.

Wie Meetling bei Bewertung und Migration unterstützt

Meetling basiert laut aktueller Produktdarstellung auf dem offen entwickelten Jitsi-Admin-Projekt. Meetling beschreibt auf seiner Website Unterstützung bei Installation, Wartung und Support sowie SaaS-, Hybrid-Cloud- und On-Premises-Modelle. Die öffentlich dokumentierten Integrationen umfassen unter anderem Keycloak, OpenID Connect und SAML. Weitere Angaben zu Verschlüsselung, Zugriffsschutz und Datenverarbeitung finden Sie auf der Seite Sicherheit und Datenschutz.

Für Unternehmen beginnt ein sinnvolles Projekt jedoch nicht mit der Installation. Zuerst müssen bestehende Videokonferenzlandschaft, Schutzbedarf, regulatorische Anforderungen und betriebliche Fähigkeiten zusammengeführt werden. Darauf aufbauend lässt sich bewerten,

  • welches Hosting- und Betriebsmodell zur Organisation passt,
  • welche Integrationen in Identitäts- und Unternehmenssysteme benötigt werden,
  • wie eine Migration schrittweise und mit vertretbarem Risiko erfolgen kann,
  • welche Verfügbarkeits-, Support- und Sicherheitsprozesse erforderlich sind und
  • wie die Abhängigkeit von proprietären Plattformen realistisch reduziert werden kann.

Fazit: Der Quellcode ist der Anfang, nicht das Betriebskonzept

Eine Open-Source-Videokonferenz kann Unternehmen mehr Kontrolle, bessere Prüfbarkeit und zusätzliche Betriebs- und Wechseloptionen eröffnen. Strategisch wertvoll wird sie, wenn diese Möglichkeiten in Beschaffung, Architektur, Sicherheitsmanagement und Notfallplanung tatsächlich genutzt werden.

Die richtige Frage lautet deshalb nicht: „Ist Open Source sicherer?“ Sondern: „Welche Lösung gibt uns die erforderliche Transparenz und Handlungsfähigkeit – und können wir sie dauerhaft sicher betreiben?“

Wenn Sie prüfen möchten, wie sich Ihre Abhängigkeit von proprietären Videokonferenzanbietern reduzieren lässt, analysieren wir gemeinsam Ihre bestehende Umgebung, Ihren Schutzbedarf sowie ein realistisches Migrations- und Betriebskonzept. Nehmen Sie für eine individuelle Beratung Kontakt mit Meetling auf.