Wie funktioniert Linchpin Mobile Gateway?

Das Linchpin Mobile Gateway verhält sich wie ein Proxy, der es berechtigten mobilen Geräten ermöglicht, auf Systeme (wie Confluence oder Linchpin) hinter einer Firewall zuzugreifen. Dies wird durch eine Websocket-Verbindung ermöglicht, die vom System hinter der Firewall zum Linchpin Mobile Gateway aufgebaut und aufrechterhalten wird. Dabei spielt es keine Rolle, ob das Linchpin Mobile Gateway von //SEIBERT/MEDIA in der Cloud oder in Ihrer eigenen Infrastruktur gehostet wird - beide Möglichkeiten nutzen die gleiche Technologie.

Bei Linchpin Mobile wird die Websocket-Verbindung zum Gateway durch die Linchpin Mobile Confluence App hergestellt. Nach der erfolgreichen Verbindung von Confluence mit dem Gateway können mobile Geräte mit der Linchpin Mobile App auch eine Websocket-Verbindung zum Gateway herstellen. Ab diesem Zeitpunkt ist es möglich, dass die mobilen Geräte mit einer Confluence-Instanz hinter einer Firewall über das Linchpin Mobile Gateway auf Basis eines Pub/ Sub-Musters kommunizieren.

Wie sichern wir Ihre Informationen?

Um Ihre Daten zu sichern, setzen wir auf eine Ende-zu-Ende verschlüsselte Websocket-Verbindung. Alle Daten werden auf dem Mobilgerät des Mitarbeiters verschlüsselt, bevor sie über das Linchpin Mobile Gateway weitergeleitet werden. Das Plugin von Linchpin Mobile, das in Ihrer Confluence-Instanz installiert ist, kann die Daten entschlüsseln und schließlich verarbeiten.

Dadurch sind Ihre Daten nicht nur für //SEIBERT/MEDIA, sondern auch für Dritte unzugänglich. Und mit unserer Linchpin Mobile Gateway Vor-Ort-Option haben Sie das Gateway selbst unter Kontrolle, für noch mehr Sicherheit.

Im Regelfall ist es nicht möglich für einen Mitarbeiter, mit einer mobilen App außerhalb des Unternehmensnetzwerkes oder von Zuhause auf ein Linchpin zuzugreifen, das sich hinter einer Firewall befindet. Klassisch gibt es hier zwei Möglichkeiten:

1. Linchpin wird in einer DMZ (demilitarisierte Zone) betrieben und kann grundsätzlich aus dem Internet erreicht werden
2. Jeder Mitarbeiter bekommt einen VPN-Zugang

Beide Ansätze haben ihre Probleme. Ein freier Zugang aus dem Internet vergrößert die Angriffsoptionen auf die LINCHPIN Applikation und den Server enorm. Ein VPN-Zugang für jeden Mitarbeiter bedeutet für die IT des Unternehmens hohen administrativen Aufwand und für die Belegschaft nur eine weitere Hürde bei der Nutzung von Applikationslösungen deren Mehrwert dringend auch über einen externen Zugriff schnell und einfach verfügbar sein sollte. 

Der Linchpin Mobile Gateway Service von //SEIBERT/MEDIA bietet eine dritte Alternative:

Eine eigene für diesen Zweck entwickelte Linchpin Mobile App wird in Linchpin installiert und initiiert eine ausgehende Verbindung zum Gateway Service. Am Gateway Service wird diese Verbindung in eine bidirektionale Websocket-Verbindung umgewandelt und permanent offen gehalten. So können Gateway Service und die Linchpin Linchpin Mobile App jeder Zeit Daten austauschen, ohne dass der Gateway Service (oder eine dritte Partei aus dem Internet) in der Lage sein muss, aktiv selbst eine eingehende Verbindung zu Linchpin aufzubauen. Es müssen also keine eingehenden Verbindungen in der Firewall erlaubt werden.

Steht die bidirektionale Websocket-Verbindung zwischen der Linchpin Mobile App und Gateway Service, können autorisierte Apps Anfragen an den Gateway Service schicken, der diese über die bestehende Verbindung an die Linchpin Mobile App weiterleitet.

Sicherheit und Datenschutz

Zunächst gelten für den Gateway Service die gleichen Grundsicherungsmaßnahmen wie für alle IT-Systeme bei //SEIBERT/MEDIA, u.a.:

• Verwendung aktueller Linux-Betriebssysteme (aktuell Ubuntu 20.04 LTS) mit automatischen Sicherheitsupdates
• Firewall blockiert Zugriff auf interne Dienste aus dem Internet. Wartung, Backup, Monitoring erfolgen nur über internes Netzwerk.
• Klar definierte Zugriffsrechte für Administratoren auf Personenbasis, keine allgemeinen Admin-Konten
• Detaillierte automatische Protokollierung aller auf dem System durchgeführten Tätigkeiten (Audit-Log und Berichtswesen)
• Hosting im ISO 27001- und ISO 9001-zertfizierten Rechenzentrum in Frankfurt am Main bei einem deutschen Anbieter mit Vertrag zur Auftragsdatenverarbeitung nach BDSG.

Die wichtigste Sicherheitsmaßnahme sehen wir hier aber nicht im operativen Bereich, sondern schon im Konzept: 

Der Gateway Service speichert keinerlei Daten oder sonstige Informationen, die Rückschlüsse auf die Identität unserer Kunden oder deren Mitarbeiter zulassen. Inhalte werden nicht gespeichert und können durch die Ende-zu-Ende-Verschlüsselung weder von //SEIBERT/MEDIA-Mitarbeitern noch von potentiellen Angreifern eingesehen werden.

Das Konzept zielt vollständig auf einen transparenten Tunnel ab, der nicht wissen muss, welche Inhalte übertragen werden. Der folgende Abschnitt erläutert im Detail, wie diese Architektur umgesetzt ist.

Ablauf im Detail

Phase 1: Aufbau der Verbindung zwischen Linchpin Mobile App und Gateway Service

Nach der Installation der Linchpin Mobile App in LINCHPIN meldet sich dieses initial und automatisch beim Gateway Service an. Dazu wird eine einfache HTTPS-Anfrage von Linchpin Mobile App an den Gateway Service verschickt:

Der Gateway Service generiert nun zufällige Zugangsdaten für die App: eine sog. instance_id als Benutzernamen und ein instance_password, beide enthalten jeweils 128 zufällige Bits. Die nötige Entropie wird über haveged sichergestellt. Diese Zugangsdaten werden als Antwort an die Linchpin Mobile App gesandt und dort gespeichert. Der Gateway Service speichert nur einen PBKDF2-Hash (100000 Iterationen) des Passworts. Die folgende Tabelle gibt einen Überblick über die gespeicherten Informationen:

Im zweiten Schritt wird nun erneut von der Linchpin Mobile App eine HTTPS-Anfrage an den Gateway Service gestellt. Statt einer Antwort seitens des Gateway Service findet nun aber ein Upgrade der Verbindung auf eine sog. Websocket-Verbindung statt. Diese Verbindung ist weiterhin per HTTPS verschlüsselt, ermöglicht aber einen bidirektionalen Datenaustausch und wird für unbestimmte Zeit gehalten. Innerhalb der Websocket-Verbindung wird nun eine MQTT-Sitzung aufgebaut, die über die zuvor ausgetauschte instance_id und das instance_password authentifiziert wird.

Phase 2: Registrierung eines Geräts

Damit ein Benutzer den Gateway Service verwenden kann, muss das entsprechende Gerät erst registriert werden. Dazu authentifiziert sich die Linchpin Mobile App mit seiner instance_id und dem instance_password per HTTP Basic Auth an der REST-API des Gateway Service und bittet um die Erstellung eines Gerätes. Der Gateway Service generiert dazu die sog. device_id, die das Gerät künftig zwischen Gateway Service und Linchpin Mobile App identifiziert, und einen sog. device_setup_key. Dieser device_setup_key wird von Linchpin Mobile nicht dauerhaft gespeichert, sondern in einen QR code integriert. Parallel generiert die Linchpin Mobile App einen device_setup_secret_key, der sowohl in Linchpin als auch im QR code gespeichert wird.

Hier ein aktualisierter Überblick über die gespeicherten Daten zu diesem Zeitpunkt:

Der QR code kann nun ausgedruckt oder dem Benutzer am Bildschirm angezeigt werden. Über die Kamera des Endgerätes liest die App device_setup_key und device_setup_secret_key aus dem QR code aus. Daraufhin kontaktiert die App die REST-API des Gateway Service und tauscht ihren device_setup_key gegen ihre device_id und ein vom Gateway Service zufällig generiertes device_password ein:

Daraus ergibt sich folgende Situation bei den gespeicherten Daten:

Der device_setup_key ist zu diesem Zeitpunkt invalidiert und spielt keine Rolle mehr.

Phase 3: Anfrage der App an die Linchpin Mobile App

Von nun an kann die App mit der Linchpin Mobile App kommunizieren. Die erste Anfrage wird dazu verwendet, einen neuen device_secret_key zu erstellen, da der aktuelle device_setup_secret_key ja noch im QR code enthalten ist und dementsprechend nicht dauerhaft gültig sein sollte (so kann ein QR code ohne Sicherheitsbedenken einfach im Papierkorb entsorgt werden). Die App schickt dazu folgende Anfrage (abstrakt dargestellt) an den Gateway Service:

Der Inhalt der Anfrage ist symmetrisch per AES verschlüsselt und kann dementsprechend vom Gateway Service nicht gelesen werden (da dieser den device_setup_secret_key nicht kennt). Der Gateway Service kann aber die device_id prüfen und die Nachricht an die damit verknüpfte instance_id weiterleiten. Über diese Verbindung wird dann die Anfrage zur Linchpin Mobile App weitergereicht.

Die Linchpin Mobile App empfängt diese Nachricht über die Websocket-Verbindung, kann der device_id einen device_setup_secret_key zuordnen und damit den Inhalt entschlüsseln. Nun kann die Linchpin Mobile App einen device_secret_key generieren, in der Antwort mit dem device_setup_secret_key verschlüsseln und über den gleichen Weg zurück an die App senden. Sobald die App den device_secret_key empfängt, wird der device_setup_secret_key verworfen. Damit sind alle im QR code enthaltenen Daten invalidiert und können nicht von nicht autorisierten Dritten wiederverwendet werden.

Alle folgenden Anfragen der App folgen dem gleichen Schema: Über die device_id werden Anfragen im Gateway Service einer instance_id und der damit verknüpften Websocket-Verbindung zugeordnet. Der komplette Inhalt der Anfrage ist mit dem device_secret_key verschlüsselt und damit für den Gateway Service nicht lesbar. Gleiches gilt für die Antwort von Linchpin Mobile.

Über die Verknüpfung der device_id mit dem Confluence-Benutzerkonto kann die Linchpin Mobile App auf die Rechte des Benutzers zugeschnittene Inhalte liefern.

Datenhaltung

Zum Abschluss noch ein Überblick darüber, welche Stelle welche Informationen sieht:

Bezeichnung	Zweck	Device (App)	QR-Code	Gateway Service	Linchpin Mobile App
instance_id	Identifizierung einer installierten Linchpin Mobile App
instance_password	Authentifizierung einer installierten Linchpin Mobile App			*
device_id	Identifizierung eines Zugangsdatensatzes in eine Linchpin Mobile App
device_password	Authentifizierung eines Zugangsdatensatzes in eine Linchpin Mobile App			*
device_setup_key	Flüchtiges Token zum einmaligen Aushandeln permanenter Zugangsdaten zwischen App und Gateway Service			*
device_setup_secret_key	Flüchtiger Schlüssel zum einmaligen Aushandeln eines permanenten Schlüssels zwischen App und Linchpin Mobile App	*	*		*
device_secret_key	Permanenter Schlüssel für Ende-zu-Ende-Verschlüsselung zwischen App und Linchpin Mobile App
Confluence-URL
Username des Endbenutzers
Passwort des Endbenutzers
Inhalte

* = nur initial gespeichert, wird anschließend rotiert

  = nur im Transit, wird nicht gespeichert

 * = nur im Transit, hash wird gespeichert