Sicherheitsmodell

SmartFleet verbindet Anlagen in Kundennetzen mit einem Server im Internet. Diese Seite erklärt, wer wem vertraut, was verschlüsselt ist und was ein Angreifer bräuchte.

Keine offenen Ports beim Kunden

Das Gateway baut jede Verbindung selbst auf: zum Server über HTTPS und, beim LoxBerry nur während einer Fernwartung, eine verschlüsselte Verbindung für die Fernwartungsadresse. Das SmartFleet-Gateway wickelt auch die Fernwartung über seine Verbindung zum Server ab. Im Kundennetz muss kein Port geöffnet und keine Portweiterleitung eingerichtet werden. Der Server hat keinen Weg ins Kundennetz; er kann dem Gateway nur Aufträge hinterlegen, die es beim nächsten Kontakt abholt und prüft.

Jede Meldung ist signiert

• Beim Einrichten erhält der Server ein Zertifikat, das auf eine gemeinsame Wurzel von SmartFleet zurückgeht. Der private Schlüssel des Servers entsteht auf dem Server und verlässt ihn nie.
• Beim Koppeln erzeugt das Gateway ein eigenes Schlüsselpaar. Der Server stellt ihm ein Zertifikat aus. Auch dieser private Schlüssel bleibt auf dem Gateway.
• Jede Meldung des Gateways ist mit seinem Schlüssel signiert, jede Antwort und jeder Auftrag des Servers mit dem des Servers. Beide Seiten prüfen die Signatur und verwerfen alles andere. Wiederholte Meldungen werden erkannt und abgewiesen.

Verwendet werden Ed25519-Signaturen und die gepflegten Kryptografie-Bibliotheken der Plattformen (libsodium auf dem Server und auf dem SmartFleet-Gateway, OpenSSL auf dem LoxBerry).

Der Bereitstellungscode

Ein Code für einen neuen Standort ist 24 Stunden gültig und nur einmal verwendbar. Er enthält die Adresse und das Zertifikat des Servers. Das Gateway prüft vor dem Koppeln, ob unter der Adresse wirklich dieser Server antwortet, und bricht sonst ab, ohne etwas zu senden. Ein abgefangener, schon eingelöster Code ist wertlos.

Fernwartung: drei Schlösser

Für eine Fernwartung braucht ein Angreifer drei Dinge gleichzeitig:

1. einen Zugang zur Partner-UI – ohne ihn entsteht kein Auftrag
2. das Fernwartungs-Passwort des Kunden – der Server kennt es nicht; das Gateway prüft eine daraus berechnete Antwort
3. den Signaturschlüssel des Servers – ohne ihn verwirft das Gateway den Auftrag

Wer nur die Datenbank des Servers erbeutet, hat den Signaturschlüssel nicht; der liegt in config.php. Zusätzlich kann der Kunde die Fernwartung am Gateway jederzeit sperren (am SmartFleet-Gateway mit Fernwartung erlaubt, im Plugin mit der Sperre), und jede Fernwartung endet nach 6 Stunden von selbst.

Passwort-Tresor: Ende-zu-Ende verschlüsselt

Der Tresor wird im Browser verschlüsselt und entschlüsselt. Das Masterpasswort verlässt den Browser nie; der Server speichert nur Chiffretext und öffentliche Schlüssel. Überträgt das Gateway Passwörter, verschlüsselt es sie selbst mit dem öffentlichen Schlüssel des Tresors. Der Browser prüft beim Öffnen, ob die gespeicherten Schlüssel zusammenpassen, und verweigert das Öffnen, wenn jemand sie auf dem Server getauscht hat.

Projektdateien

Projektdateien enthalten Zugangsdaten. Der Server speichert sie nur an einem Standort mit Passwort-Tresor und verschlüsselt sie schon beim Empfang, Stück für Stück, mit einem eigenen Schlüssel je Datei (XChaCha20-Poly1305). Diesen Schlüssel verschlüsselt er mit dem öffentlichen Schlüssel des Tresors; öffnen kann ihn nur der Browser mit dem Masterpasswort. Zum Herunterladen gibt der Browser nur den Schlüssel der einen Datei frei, nie das Masterpasswort. Nach dem Empfang hält der Server den Schlüssel kurz offen, um die Datei auszuwerten (Systemwerte, Vorschau der Dokumentation), höchstens 24 Stunden. Ohne Tresor wird die Datei nach der Auswertung gelöscht.

Wer Datenbank und Ablage des Servers kopiert, kann gespeicherte Projektdateien danach nicht lesen. Gegen einen Angreifer, der den laufenden Server kontrolliert, schützt das nicht: Er sieht eine Datei, während sie ausgewertet oder heruntergeladen wird.

Backups

Das Gateway verschlüsselt jedes Backup, bevor es das Kundennetz verlässt, mit einem eigenen Schlüssel und versiegelt diesen für den Passwort-Tresor des Standorts. Der Server kann ein Backup nicht lesen; ohne Tresor entsteht keins. Beim Herunterladen öffnet der Browser den Tresor mit dem Masterpasswort und gibt nur den Schlüssel dieses einen Backups frei. Ältere Backups sind noch mit dem Passwort des jeweiligen Miniservers verschlüsselt (AES, 7z). Alle liegen auf dem Server in einem aus dem Netz gesperrten Verzeichnis unter zufälligen Namen. Herunterladen kann sie nur ein angemeldeter Nutzer mit mindestens der Rolle Betrachter Plus.

Anmeldung

• Passwörter sind nur als Hash gespeichert.
• Zweiter Faktor per Authenticator-App oder E-Mail, auf Wunsch für alle vorgeschrieben.
• Die Anmeldung bremst nach Fehlversuchen, getrennt nach Herkunft.
• Der Notzugang lässt sich nur mit Dateizugriff auslösen und ersetzt die Anmeldung nicht.
• Jede Aktion in der Partner-UI wird vor ihrer Ausführung protokolliert.

Updates

Serverupdates sind mit einem eigenen Release-Schlüssel signiert. Der Server prüft die Signatur und die Prüfsumme jeder Datei, bevor er etwas ersetzt, und sichert vorher den alten Stand.

Was der Betreiber selbst tun sollte

• Den Server nur über HTTPS betreiben.
• config.php sicher aufbewahren und setup.php nach der Einrichtung löschen.
• Für alle Nutzer einen zweiten Faktor vorschreiben.
• Offene Freigabelinks nur befristet vergeben.
• Automatische Updates eingeschaltet lassen.