Durchgehend verschlüsselte Teamkommunikation für die Industrie: ein Kundenprojekt mit Tuwunel

3. November 202610 Min. Lesezeit·Tobias Brida

FallstudieTeamkommunikationMatrixTuwunelDatensouveränität

Schriftzug OT Security auf abstraktem rotem Hintergrund

Das Projekt im Überblick

Ein österreichischer Industriebetrieb beauftragte uns, seinen bisherigen SaaS Teamchat durch eine Lösung auf eigener Hardware zu ersetzen. Nachrichten sollten bereits auf den Geräten verschlüsselt werden und erst bei den Empfängern wieder lesbar sein. Wir setzten dafür den offenen Standard Matrix und den in Rust entwickelten Homeserver Tuwunel ein. Die Chatdienste sind ausschließlich über das private VPN des Kunden erreichbar

Diese anonymisierte Fallstudie beschreibt die Umsetzung und die Abnahme mit Stand 3. November 2026

Aspekt	Umsetzung
Umfang	Interne Kommunikation für 20 Nutzer, im Büro und unterwegs
Plattform	Tuwunel Homeserver, Rust, eingebettete RocksDB, ein Container für den Homeserver
Anwendungen	Element Web, Element Desktop und Element X für iOS und Android
Infrastruktur	Debian 13 VM auf dem eigenen KVM Host, mit 2 vCPU, 4 GB RAM und 40 GB Speicher
Netzwerkzugang	Privates Mesh VPN mit Tailscale, ohne öffentlich erreichbare Chatports
Verschlüsselung	Nachrichten und Anhänge von Gerät zu Gerät verschlüsselt, zusätzlich TLS zwischen Clients und Reverse Proxy
Datensicherung	Nächtliche Backups, vor der Übertragung in Schweizer Objektspeicher verschlüsselt, Wiederherstellung geprüft
Umsetzung	Wenige Arbeitstage, einschließlich Pilotphase und Prüfung der Wiederherstellung

Ausgangslage und Ziele

Der Kunde verbindet OT und IT für Fertigungsbetriebe und Rohstoffgewinnung. Im täglichen Austausch geht es um Netzwerkpläne, Steuerungskonfigurationen, Schnittstellen und Wartungsfenster. Seine Auftraggeber vertrauen ihm diese Informationen an, wenn sie ihm Zugang zu ihren Produktionssystemen geben

Entscheidend war daher, wer die Gespräche entschlüsseln kann. Slack und Microsoft Teams verschlüsseln Daten bei der Übertragung und Speicherung. Gewöhnliche Teamnachrichten sind dort jedoch nicht so von Gerät zu Gerät verschlüsselt, dass auch der Dienstanbieter vom Inhalt ausgeschlossen bleibt. Teams bietet E2EE für unterstützte Anrufe und Besprechungen, deren Chatnachrichten sind davon nicht erfasst

Dem Kunden reichte es deshalb nicht, den Chatserver selbst zu betreiben. Auch der Server sollte den Inhalt der Nachrichten nicht lesen können

Die Anforderungen waren konkret:

Verschlüsselung von Gerät zu Gerät als Standard für Teamnachrichten und geteilte Dateien
Betrieb auf eigener Hardware, ohne die Cloud eines Chatanbieters als Backend
Vertraute Bedienung, mit Räumen, Threads, Reaktionen, Dateien sowie Apps für Rechner und Mobilgeräte
Zugang über ein privates Netzwerk, ohne die Chatdienste im Internet zu veröffentlichen
Überschaubarer Betrieb, den ein Team von vier Personen bewältigen kann
Verschlüsselte Backups und eine geprüfte Wiederherstellung, mit klaren Regeln für persönliche Wiederherstellungsschlüssel

Bewertung der Alternativen

Unter den untersuchten Optionen passte Matrix mit Tuwunel am besten zu diesem Betriebsmodell: verschlüsselte Nachrichten, vertraute Anwendungen und eine kleine Installation. Die Entscheidung bezieht sich auf die Anforderungen dieses Kunden

Der Vergleich betrachtet Nachrichten im Teamchat. Entscheidend ist, ob der Dienst selbst Inhalte entschlüsseln kann oder die nutzbaren Schlüssel bei den Teilnehmern bleiben

Option	Eigener Betrieb	E2EE im Chat	Bewertung für dieses Projekt
Slack, Microsoft Teams	Nein	Nicht für gewöhnliche Teamnachrichten	Vom Anbieter verwaltete Verschlüsselung erfüllte die Anforderung nicht
Zulip	Ja	Nicht zwischen Teilnehmern	Gute Themenstruktur, der Server verarbeitet jedoch lesbare Nachrichten
Mattermost	Ja	Nicht eingebaut	Leistungsfähiger Teamchat, Inhalte bleiben für den Server lesbar
Rocket.Chat	Ja	Private Räume und Direktnachrichten	E2EE ist verfügbar, Umfang und Sicherheitsgeschichte erfordern eine genaue Bewertung
Wire	Ja	Ja	Verschlüsselte Alternative mit mehr Diensten im Backend
Matrix mit Synapse	Ja	Ja, durch die Clients	Etablierter Server, im üblichen Produktivbetrieb mit separater PostgreSQL Datenbank
Matrix mit Tuwunel	Ja	Ja, durch die Clients	Gewählt wegen eines Homeserver Containers, eingebetteter Datenbank und der benötigten Element Funktionen

Grundlage des Vergleichs sind die veröffentlichten Informationen von Zulip, Mattermost, Rocket.Chat, Wire und Synapse

Eine auf der ACSAC 2025 veröffentlichte Sicherheitsanalyse fand Schwächen im E2EE Protokoll und in der Implementierung von Rocket.Chat. Die Veröffentlichung der Forscher hält zugleich fest, dass kritische Befunde behoben wurden. Die Untersuchung hilft bei der Bewertung konkreter Versionen, belegt aber keine pauschale Verwundbarkeit aller aktuellen Installationen

Tuwunel ist der offizielle Nachfolger von conduwuit. Laut Projekt ist die Schweizer Regierung der wichtigste Förderer und setzt die Software für Bürger ein. Das Projekt beschreibt eine breite Unterstützung des Matrix Standards und nennt Ausnahmen für spezialisierte Anwendungsfälle

Im Kundenprojekt deckten Element Web, Element Desktop und Element X die benötigten Nachrichtenfunktionen ohne Änderungen an den Clients ab. Tuwunel läuft als einzelner Prozess mit eingebetteter RocksDB. Ein zusätzlicher Datenbankdienst entfällt damit

Aufbau der Lösung

Die Chatdienste laufen in einer kleinen virtuellen Maschine auf dem KVM Host des Kunden. Freigegebene Laptops und Mobiltelefone verbinden sich über Tailscale und erreichen Caddy per HTTPS. Caddy leitet Matrix Anfragen an Tuwunel weiter und stellt den Webclient von Element bereit

Element Clients erreichen über Tailscale den Caddy Proxy in der Kunden VM, der Element Web ausliefert und Chatanfragen an Tuwunel mit RocksDB weiterleitet, während restic ein verschlüsseltes Backup in Schweizer Objektspeicher überträgt — Privater Zugang, eine VM und ein verschlüsseltes Backup

Caddy erhält seine Zertifikate durch einen DNS Nachweis. Dafür muss kein Webport öffentlich erreichbar sein. Eine kleine Discovery Antwort auf der Firmenwebsite verweist Matrix Clients auf die private Chatadresse. Bei der Anmeldung genügt dadurch die Firmendomain

Diese Discovery Antwort ist öffentlich und nennt den Hostnamen des Chatservers. Für den Zugriff auf den Chat bleibt eine autorisierte Verbindung über das VPN erforderlich

Der Chatserver steht auf eigener Hardware, die gesamte Lösung ist jedoch nicht von externen Diensten getrennt. Tailscale Koordination, DNS und Zertifikate, Softwareupdates, mobile Pushdienste und der Speicher für verschlüsselte Backups bleiben externe Abhängigkeiten. Tailscale beschreibt dazu die Trennung zwischen Steuerung und Datenverkehr

Sicherheitskonzept

Privater Netzwerkzugang und Verschlüsselung auf den Endgeräten ergänzen einander. Jede Ebene begrenzt ein anderes Risiko

Ebene	Maßnahme	Adressiertes Risiko
Nachrichteninhalt	E2EE in jedem für Teamkommunikation verwendeten Raum, Nachrichten und Anhänge werden auf den Clients verschlüsselt	Lesen einer kopierten Serverdatenbank oder Sicherung ohne die Schlüssel der Nutzer
Gerätevertrauen	Neue Geräte durch Emoji Vergleich oder persönlichen Wiederherstellungsschlüssel verifizieren	Nachrichtenschlüssel an ein unbekanntes Gerät weitergeben
Netzwerk	Chatdienste nur über das private VPN erreichbar, kein öffentlicher Chatzugang	Direkte Scans und Angriffe aus dem Internet auf die Chatdienste
Transport	HTTPS zwischen Clients und Caddy, Zertifikate über DNS Nachweis	Mitschneiden der Verbindung zum Client
Konten	Föderation deaktiviert, Registrierung über kontrollierte Tokens, nach dem Onboarding geschlossen	Unerlaubte Konten und Kommunikation mit externen Matrix Servern
Administration	SSH Schlüssel, Root Anmeldung deaktiviert, automatische Sicherheitsupdates	Erraten von Passwörtern und vermeidbare Angriffsflächen durch bekannte Softwarefehler
Container	Homeserver ohne Root Rechte, Ausweitung der Berechtigungen blockiert	Überhöhte Rechte bei einer kompromittierten Anwendung

Matrix verschlüsselt auf den Clients. Raumzugehörigkeit und weitere Metadaten bleiben auf dem Server sichtbar. Dort können auch verschlüsselte Sicherungen der Nachrichtenschlüssel liegen. Den persönlichen Wiederherstellungsschlüssel zum Entsperren erhält der Server nicht

Geht ein Gerät verloren, wird zuerst sein Zugang zum VPN entzogen und seine Chatsitzung von einem vertrauenswürdigen Gerät aus beendet. Sobald der Entzug greift, endet der weitere autorisierte Zugriff. Bereits gespeicherte Nachrichten und Schlüssel werden dadurch nicht vom verlorenen Gerät gelöscht. Geräteverschlüsselung und Bildschirmsperre bleiben deshalb erforderlich

E2EE schützt außerdem nicht vor einem kompromittierten Endgerät. Ein angegriffener Server, der den Webclient ausliefert, könnte veränderten Clientcode bereitstellen. Die Integrität des Webclients und zeitnahe Updates gehören daher zum Sicherheitskonzept

Datensicherung und Wiederherstellung

Die Sicherung läuft jede Nacht und wird vor dem Verlassen des Servers verschlüsselt. Vor dem Einsatz im Alltag wurde eine vollständige Wiederherstellung erfolgreich geprüft

Der Ablauf bleibt bewusst einfach:

Der Homeserver wird kurz angehalten, während die Datenbank lokal konsistent kopiert wird
Der Homeserver startet wieder, die kurze Unterbrechung ist für 03:00 Uhr geplant
Restic verschlüsselt und dedupliziert die Kopie und die Konfiguration, anschließend erfolgt die Übertragung in Schweizer Objektspeicher
Die Aufbewahrung wird automatisch angewendet: 7 tägliche, 4 wöchentliche und 6 monatliche Sicherungen
Eine Integritätsprüfung liest eine Stichprobe der gespeicherten Daten erneut ein

Zwei unabhängige Verschlüsselungsebenen schützen die Sicherung. Die Nachrichten in der Datenbank wurden bereits von den Matrix Clients verschlüsselt. Restic verschlüsselt zusätzlich die gesicherte Datenbank, Konfiguration und Metadaten vor dem Upload

Die Zugangsdaten für die Wiederherstellung des Backups werden zusätzlich außerhalb der VM aufbewahrt. Ein Serververlust nimmt damit nicht zugleich die Möglichkeit zur Wiederherstellung. Der automatische Sicherungsdienst benötigt weiterhin seine Zugangsdaten auf dem laufenden System, wo sie entsprechend geschützt werden müssen

Die Wiederherstellung des Servers und die Wiederherstellung persönlicher Nachrichtenschlüssel sind getrennte Vorgänge. Jeder Nutzer verwahrt seinen Wiederherstellungsschlüssel im Passwortmanager. Ein Administrator erhält durch das Zurückspielen des Servers allein keinen Zugriff auf verschlüsselte Gespräche

Einführung und täglicher Betrieb

Das Onboarding dauerte rund zehn Minuten pro Person. Alle Teammitglieder durchliefen denselben Ablauf:

VPN App auf Laptop und Mobiltelefon installieren und anmelden
Im Webclient mit Firmenauftritt ein Konto über einen Registrierungstoken anlegen
Sichere Schlüsselsicherung einrichten und den persönlichen Wiederherstellungsschlüssel im Passwortmanager speichern
Element X auf dem Mobiltelefon installieren, anmelden und das Gerät vom Laptop aus verifizieren

Bei der Anmeldung geben Nutzer die Firmendomain ein. Die Discovery Antwort der Website liefert die Chatadresse, das VPN ermöglicht den Zugang

Der Arbeitsbereich besteht aus einem privaten Space mit Räumen für Projekte und Themen. Threads, Reaktionen, Erwähnungen und Dateifreigaben bieten vertraute Abläufe. Mobile Pushdienste melden neue Aktivität, ohne entschlüsselte Nachrichteninhalte zu erhalten. Zum Abrufen und Entschlüsseln benötigt die App Zugang über das VPN

Bekannte Grenzen

Verschlüsselung schützt Inhalte. Für Metadaten, Geräte, Wiederherstellung und Integrationen braucht es weiterhin klare Regeln

Grenze	Auswirkung	Umgang in diesem Projekt
Metadaten	Der Server sieht Raumzugehörigkeit, Zeitpunkte und Nachrichtengrößen	Server privat halten und unter eigener Administration betreiben
Nachrichtensuche	Der Server kann verschlüsselte Inhalte nicht durchsuchen	Lokalen Suchindex in Element Desktop verwenden, eingeschränktere Suche im Web und auf Mobilgeräten berücksichtigen
Anmeldung per QR Code	In der eingesetzten Kombination aus Server und Clients nicht verfügbar	Manuell anmelden und Gerät verifizieren, rund 30 Sekunden zusätzlicher Aufwand
Wiederherstellungsschlüssel	Ohne Geräte und Wiederherstellungsschlüssel kann der bisherige Verlauf unzugänglich werden	Schlüssel beim Onboarding im persönlichen Passwortmanager sichern
Integrationen	Ein einfacher Webhook bildet keinen verschlüsselten Matrix Teilnehmer	Einen Bot mit E2EE Unterstützung und eigenen Geräteschlüsseln einsetzen
VPN Zugang	Jedes Gerät benötigt VPN Zugang, externe Partner können nicht direkt beitreten	Den Arbeitsbereich intern halten und Partnerzugang getrennt planen
Externe Dienste	VPN Koordination, Zertifikate, Pushzustellung und externer Speicher bleiben abhängig von Dritten	Diese Dienste in den Betrieb einplanen und die Lösung nicht als isoliertes System behandeln
Wechsel der Serversoftware	Die vollständige Datenübernahme in eine andere Implementierung ist nicht garantiert	Unterstützte Migrationswege vor einem Wechsel prüfen

Element dokumentiert die lokale Suche im Desktopclient. Funktionen anderer Clients können sich mit neuen Versionen ändern. Suche und Anmeldeverfahren sollten daher bei Updates erneut geprüft werden

Ergebnis und Nutzen für Industriebetriebe

Der interne Chat läuft jetzt auf Infrastruktur, die der Kunde selbst kontrolliert. Nachrichten und Anhänge werden auf den Geräten der Teilnehmer verschlüsselt, der Chatserver ist nicht öffentlich erreichbar. Die Umsetzung dauerte wenige Arbeitstage, im Betrieb genügt eine kleine virtuelle Maschine

Kontrolle über Betriebsdaten: Die primäre Chatdatenbank bleibt auf eigener Hardware, verschlüsselte Sicherungen liegen in Schweizer Objektspeicher
Privater Zugang: Chatdienste sind nur über das autorisierte VPN erreichbar
Geprüfte Wiederherstellung: Nächtliche verschlüsselte Backups und ein abgeschlossener Wiederherstellungstest vor der Einführung
Vertraute Anwendungen: Das Team nutzt Webclient, Desktopclient und mobile Apps mit bekannten Abläufen
Keine Chatlizenzgebühren für die gewählte Software: Infrastruktur, Speicher, VPN Dienste und Wartung bleiben Betriebskosten

Produktionsbetriebe, Ingenieurbüros und Zulieferer tauschen täglich Netzwerkpläne, Maschinenparameter und Wartungsinformationen aus. Eine solche Lösung hält diese Gespräche auf Infrastruktur, die sie selbst administrieren

In einem Werk gehört der Server in eine geeignete IT Zone mit kontrolliertem Zugang. Die Trennung von Steuerungssystemen bleibt bestehen. Ein Bot mit E2EE Unterstützung kann Maschinenalarme oder Informationen zur Schichtübergabe in eigene Räume senden. Dafür braucht es ein separates Zugriffskonzept, eine solche Integration war nicht Teil dieses Kundenprojekts

Quellen

Projektumfang, Ressourcenzuteilung, Umsetzungsdauer und Wiederherstellungsergebnis stammen aus diesem Kundenprojekt. Die folgenden Quellen belegen den technischen Hintergrund