Feldgerät, TLS und VPN: Welche Grenze schützt was

Ein Feldgerät öffnet eine Verbindung zu einem Dienst, und die Designfrage kommt als Wahl zwischen VPN und TLS. Diese Rahmung ist falsch, weil beide unterschiedliche Aufgaben erfüllen. TLS authentifiziert den Anwendungsendpunkt und schützt das Gespräch; ein VPN kontrolliert die Erreichbarkeit und schützt Pakete zwischen Peers. Verfolgen Sie die Verbindung vom Gerät nach außen, und jede Schicht hat ihre eigene Antwort.

Wenn Sie nicht sagen können, wo TLS endet, können Sie nicht sagen, worauf die Anwendung tatsächlich vertraut.

Finden Sie heraus, wo TLS tatsächlich endet

Beginnen Sie bei der Geräteanwendung und folgen Sie der Verbindung bis zu dem Prozess, der den Handshake abschließt. Wenn ein Proxy TLS vor dem Mainframe beendet, endet der geschützte Pfad am Proxy. Der verbleibende Sprung braucht seinen eigenen dokumentierten Schutz.

Das per Annahme Ende-zu-Ende zu nennen, ist der Weg, auf dem eine Designprüfung eine Lücke absegnet. Zeichnen Sie Endpunkt und Vertrauensanker in dasselbe Diagramm.

TLS überträgt Anfragen und Antworten in beide Richtungen, daher braucht eine bidirektionale Anwendung nicht von Natur aus ein VPN statt TLS. Das Umgekehrte gilt ebenfalls: Ein Deployment kann für andere Protokolle auf demselben Gerät weiterhin ein VPN benötigen.

Entscheiden Sie, was das Gerät authentifizieren muss

Konfigurieren Sie die Prüfung der Serveridentität und die vorgesehenen Vertrauensanker. Wenn jedes Gerät seine eigene Identität nachweisen muss, wählen Sie ein unterstütztes Client-Authentifizierungsmodell und registrieren Sie je Gerät eigene Anmeldedaten. Gemeinsame Anmeldedaten machen aus einem gestohlenen Gerät ein Problem für die gesamte Flotte.

Planen Sie Schlüsselschutz, Erneuerung, Widerruf und Wiederherstellung vor dem Versand. Ein Gerät im Feld, das nach einer fehlgeschlagenen Erneuerung nicht erneut registriert werden kann, wird zum Vor-Ort-Einsatz, und diese Kosten prägen das Design stärker als der Handshake.

Verwenden Sie eine unterstützte Bibliothek und aktuelle Vorgaben. Moderne Vorgaben zur TLS-Bereitstellung verbieten die Aushandlung von TLS 1.0 und 1.1, und ein TLSv1-Verweis in einer alten Designnotiz ist keine Anforderung.

Schließen, wenn der Handshake scheitert

Ein fehlgeschlagener Handshake oder eine fehlgeschlagene Identitätsprüfung darf nicht stillschweigend auf das ursprüngliche Klartextprotokoll zurückfallen. Dieser Rückfall ist die Schwachstelle, die die TLS-Arbeit schließen sollte. Machen Sie das Scheitern für den Gerätebetreiber und für den Dienst sichtbar, und verlangen Sie den geschützten Kanal für sensible Vorgänge. Lassen Sie dann die Anwendungsautorisierung entscheiden, was ein authentifiziertes Gerät tun darf.

Definieren Sie Verbindungslebensdauer, Framing, Zeitlimits und Wiederholungsverhalten als Teil des Vertrags. Verschlüsselung macht einen wiederholten Befehl nicht sicher, und ein Wiederholungsversuch nach einem ungewissen vorherigen Vorgang braucht eine Antwort auf Anwendungsebene.

Schreiben Sie die Rückfallregel auf. „Es verbindet sich ohne TLS neu, wenn der Handshake scheitert“ ist eine Designentscheidung, und sie sollte ausdrücklich sein.

Geben Sie dem VPN nur die Aufgabe, die es erfüllen kann

Ein VPN kann die Erreichbarkeit einschränken und Pakete zu seinem eigenen Peer schützen. TLS schützt die Anwendungsbeziehung zum ausgewählten Endpunkt. Ihre Endpunkte können sich unterscheiden, und keines von beiden sichert die gespeicherten Daten oder den administrativen Zugang des Endpunkts.

Messen Sie Handshake-Kosten, stetigen Nachrichtenaustausch und Wiederverbindung am tatsächlichen Gerät, statt anzunehmen, ein Mechanismus sei schneller. Testen Sie dann die vier Fälle, die zählen: den vorgesehenen Austausch, eine falsche Serveridentität, ein nicht autorisiertes Gerät und eine Wiederverbindung nach einem ungewissen Vorgang. Halten Sie das Ergebnis für jeden Fall fest, einschließlich des Fehlers, den das Gerät anzeigt.