Untergeordnete Seiten
  • Linchpin Mobile - Gateway-Service: Sicherheitskonzept
Zum Ende der Metadaten springen
Zum Anfang der Metadaten



Inhaltsverzeichnis


Zusammenfassung

  • Sämtliche Verbindungen sind nach aktuellen Standards verschlüsselt (HTTPS).
  • Es sind in der Regel keine Firewall-Anpassungen auf Kundenseite erforderlich. Ihr Linchpin muss lediglich in der Lage sein, HTTPS-Verbindungen ins Internet aufzubauen.
  • Nutzer der Linchpin Mobile App müssen nicht zwangsläufig über einen Account in Ihrem Benutzerverzeichnis (Active Directory o.ä.) verfügen. Das spart Lizenzkosten.
  • Durch den Verzicht auf eine klassische Passwort-Authentifizierung entfallen Support-Aufwände für vergessene Passwörter und andere Risiken.
  • Durch die Ende-zu-Ende-Verschlüsselung zwischen Mobile App und Linchpin ist weder //SEIBERT/MEDIA noch ein potentieller Angreifer in der Lage, Daten aus Linchpin zu entwenden.
  • Bei //SEIBERT/MEDIA werden keine Daten gespeichert, die Rückschlüsse auf die Identität, andere Benutzerinformationen oder Daten unserer Linchpin Mobile Kunden zulassen.





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.




Das Problem



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:


Die Lösung



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 16.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:


AppGateway ServiceLinchpin Mobile AppQR Code

instance_id

pbkdf2(instance_password)

instance_id

instance_password


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:

AppGateway ServiceLinchpin Mobile AppQR code
 

instance_id

pbkdf2 (instance_password)

device_id

sha256 (device_setup_key)

instance_id

device_id (verknüpft mit Confluence-Benutzerkonto)

device_setup_secret_key

device_setup_key

device_setup_secret_key


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:

AppGateway ServiceLinchpin Mobile AppQR code

device_id

device_password

instance_id

pbkdf2(instance_password)

device_id

pbkdf2(device_password)

instance_id

device_id (verknüpft mit Confluence-Benutzerkonto)

device_setup_secret_key


device_setup_key

device_setup_secret_key

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:

Absender: device_id (authentifiziert über device_password)
Inhalt: AES( "Anfrage für device_secret_key" , device_setup_secret_key)

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:

BezeichnungZweckDevice (App)QR-CodeGateway ServiceLinchpin Mobile App
instance_idIdentifizierung einer installierten Linchpin Mobile App(Haken)(Fehler)(Haken)(Haken)
instance_passwordAuthentifizierung einer installierten Linchpin Mobile App(Fehler)(Fehler)(Warnung) *(Haken)
device_idIdentifizierung eines Zugangsdatensatzes in eine Linchpin Mobile App(Haken)(Fehler)(Haken)(Haken)
device_passwordAuthentifizierung eines Zugangsdatensatzes in eine Linchpin Mobile App(Haken)(Fehler)(Warnung) *(Fehler)
device_setup_keyFlüchtiges Token zum einmaligen Aushandeln permanenter Zugangsdaten zwischen App und Gateway Service(Warnung)(Haken)(Warnung) *(Warnung)
device_setup_secret_keyFlüchtiger Schlüssel zum einmaligen Aushandeln eines permanenten Schlüssels zwischen App und Linchpin Mobile App(Haken) *(Haken) *(Fehler)(Haken) *
device_secret_keyPermanenter Schlüssel für Ende-zu-Ende-Verschlüsselung zwischen App und Linchpin Mobile App(Haken)(Fehler)(Fehler)(Haken)
Confluence-URL
(Fehler)(Fehler)(Fehler)(Haken)
Username des Endbenutzers
(Fehler)(Fehler)(Fehler)(Haken)
Passwort des Endbenutzers
(Fehler)(Fehler)(Fehler)(Fehler)
Inhalte
(Haken)(Fehler)(Fehler)(Haken)

(Haken) * = nur initial gespeichert, wird anschließend rotiert

(Warnung)  = nur im Transit, wird nicht gespeichert

(Warnung) * = nur im Transit, hash wird gespeichert 





  • Keine Stichwörter