Interpretation der CRA-Anforderungen an Webschnittstellen von embedded Geräten

Viele eingebettete Geräte verfügen über einen integrierten Webserver, der eine browserbasierte Schnittstelle für die Konfiguration und Verwaltung innerhalb von Intranets (privaten Netzwerken) bereitstellt. Dieses Design ist zwar praktisch, wirft jedoch Sicherheitsaspekte auf, die im Rahmen moderner Cybersicherheitsvorschriften nicht immer einfach zu interpretieren sind.

Die Europäische Union legt mit dem EU-Gesetz zur Cyberresilienz (CRA) – einer marktprägenden Verordnung, die für praktisch jedes Produkt gilt, das Software oder Konnektivität enthält – die Messlatte für die Cybersicherheit bei allen Produkten mit digitalen Elementen höher. Der CRA verpflichtet Hersteller innerhalb und außerhalb der EU, während des gesamten Lebenszyklus eines Produkts festgelegte Cybersicherheitsanforderungen zu erfüllen. Bei Produkten mit eingebetteten Webschnittstellen ist es unerlässlich zu verstehen, wie diese Anforderungen in der Praxis anzuwenden sind, da eine Nichteinhaltung zu einem gesperrten Marktzugang, Produktrückrufen und erheblichen Strafen führen kann.

Die CRA, deren vollständige Umsetzung für 2027 vorgesehen ist, schafft einen Rahmen für die Bewertung von Cybersicherheitsrisiken bei Produkten mit netzwerkzugänglichen Schnittstellen. Bei Produkten, die einen eingebetteten Webserver enthalten, auf den über Standard-Webbrowser zugegriffen werden kann, werden die Anforderungen der CRA in der Regel nicht nur daran gemessen, ob eine Verschlüsselung aktiviert ist, sondern auch daran, wie das Vertrauensverhältnis zwischen dem Browser und dem Gerät hergestellt wird.

In diesem Zusammenhang spielt die praktische Auslegung von TLS, der Zertifikatsverwaltung und den Annahmen zur Bereitstellung eine zentrale Rolle. Das Verhalten des Browsers, insbesondere der Umgang mit nicht vertrauenswürdigen oder selbstsignierten Zertifikaten, hat direkten Einfluss darauf, ob eine verschlüsselte Verbindung als authentifiziert und somit als geeignet für den Schutz einer Webschnittstelle im Rahmen der CRA angesehen wird.

Wie wir zeigen werden, reicht die bloße Aktivierung von TLS nicht aus. In den meisten realen Einsatzszenarien erfüllen eingebettete Webserver, die TLS verwenden, die CRA-Anforderungen dennoch nicht, da moderne Browser Vertrauen, Zertifikate und Authentifizierung unterschiedlich handhaben. Im folgenden Abschnitt „Empfehlungen“ wird detailliert erläutert, warum dieses Problem besteht.

Kommunikation im Klartext (http://) in Umgebungen mit starken Einschränkungen

In Szenarien, in denen der netzwerkbasierte Zugriff nicht nur eingeschränkt, sondern vollständig ausgeschlossen ist, wie beispielsweise in Air-Gapped-Netzwerken, kann die Kommunikation im Klartext für eine Webschnittstelle eine sinnvolle Designentscheidung sein.
Beispiele

Physisch isolierte Systeme:
Geräte ohne kabelgebundene oder drahtlose Netzwerkschnittstellen, bei denen die Interaktion ausschließlich über Wechselmedien erfolgt, bieten keine Angriffsfläche für Netzwerkangriffe. In solchen Fällen gibt es keinen Datenübertragungskanal, der kryptografischen Schutz erfordert.

Hardware-erzwungene unidirektionale Kommunikation:
Systeme, die auf streng einseitigen Datenpfaden basieren, bei denen eine Rückkommunikation physisch unmöglich ist, können eine Klartextübertragung auf der Einwegseite zulassen, wenn der Durchsetzungsmechanismus im Hardware-Design selbst verankert ist.

In diesen Fällen verlagert sich der Fokus der CRA von der Kryptografie hin zur Sicherstellung, dass die Annahmen hinter der Isolation korrekt sind, dokumentiert werden und über die Zeit hinweg aufrechterhalten bleiben.

Netzwerkumgebungen und die Rolle von TLS (https://)

Viele eingebettete Systeme werden in Netzwerken betrieben, die durch Segmentierung, Zugriffskontrollen und Betriebsverfahren sorgfältig verwaltet werden. Diese Ansätze sind weit verbreitet und oft wirksam, um Sicherheitsrisiken zu minimieren.

Aus Sicht der CRA werden solche Umgebungen jedoch in der Regel als erreichbare Netzwerke behandelt, da sie während der gesamten Lebensdauer des Produkts von der Korrektheit der Konfiguration und der Einhaltung von Betriebsvorschriften abhängen. Beispiele hierfür sind:

• Segmentierte oder VLAN-basierte Netzwerke
• Firewalls und Routing-Kontrollen
• Wartungs- oder Diagnosezugriffspfade
• Gemeinsam genutzte lokale Netzwerke, die von Bedienern, HMIs oder Servicegeräten genutzt werden

In diesen Situationen wird im Allgemeinen erwartet, dass vertrauenswürdiges TLS (d. h. ohne Zertifikatswarnungen des Browsers) Webschnittstellen schützt und Vertraulichkeit, Integrität sowie authentifizierte Kommunikation für Daten während der Übertragung gewährleistet.

Eine lebenszyklusorientierte Perspektive

Ein nützlicher Ansatz zur Betrachtung der CRA-Konformität besteht darin, das Produkt über seine gesamte Betriebsdauer hinweg zu betrachten:

Sofern es ein realistisches Szenario gibt, in dem die Webschnittstelle über ein Netzwerk erreichbar sein könnte, bietet TLS eine klare und vertretbare Mindestanforderung.

Wo eine Netzwerkzugänglichkeit eindeutig ausgeschlossen werden kann, ist der Betrieb im Klartext möglicherweise weiterhin akzeptabel, vorausgesetzt, die Kontrollen, die diese Schlussfolgerung stützen, sind explizit und überprüfbar.

Dieser Ansatz hilft, die Abhängigkeit von engen Annahmen zur Bereitstellung zu vermeiden, und unterstützt eine konsistente Argumentation zur Compliance.

Browserbasierter Zugriff und Vertrauensaufbau

Wenn über Standard-Webbrowser auf eingebettete Webschnittstellen zugegriffen wird, wird die Zertifikatsverwaltung Teil der Sicherheitsbewertung.

Moderne Browser prüfen nicht nur, ob der Datenverkehr verschlüsselt ist, sondern auch, ob die Identität des Servers über eine vertrauenswürdige Zertifikatskette authentifiziert werden kann. Zertifikatswarnungen, die häufig mit selbstsignierten oder manuell verwalteten Zertifikaten verbunden sind, weisen darauf hin, dass zwar eine Verschlüsselung vorliegt, die Identität der Gegenstelle jedoch nicht auf eine Weise festgestellt wurde, die der Browser automatisch validieren kann.

Aus Sicht der CRA ist authentifizierte Kommunikation eine wichtige Ergänzung zur Verschlüsselung, insbesondere in Umgebungen, in denen aktive Netzwerkangriffe im Bereich des Möglichen liegen. Im Gegensatz zu einigen anderen Client-Tools bieten Browser kein persistentes „Trust-on-First-Use“-Modell (TOFU), und Überschreibungen durch den Benutzer stellen keine dauerhaften Vertrauensbeziehungen her.

Aus diesem Grund wird der browserbasierte Zugriff auf eingebettete Geräte üblicherweise anhand der Verfügbarkeit einer betrieblich tragfähigen, vom Browser als vertrauenswürdig eingestuften Zertifikatsstrategie bewertet.

Ein konservativer und breit anwendbarer Ansatz

Für viele OEM-Produkte, insbesondere solche, die in unterschiedlichen Kundenumgebungen eingesetzt werden, entspricht eine konservative Grundhaltung gut den Erwartungen der CRA:

    Netzwerkumgebungen als potenziell gefährdet behandeln
    TLS standardmäßig für Webschnittstellen aktivieren
    Zertifikatsstrategien vermeiden, die zu Browserwarnungen oder manuellen Vertrauensausnahmen führen

Diese Leitlinien gelten vor allem für Schnittstellen, auf die über einen Standard-Webbrowser zugegriffen wird, bei denen der Gerätehersteller keine Kontrolle über den Client-Vertrauensspeicher oder die Browserrichtlinien hat.

Eine private PKI kann gut funktionieren, wenn der Hersteller sowohl das Gerät als auch die Client-Software (z. B. dedizierte Desktop- oder mobile Apps) kontrolliert und Vertrauensanker vorinstallieren kann. Dieses Modell eignet sich nicht für den allgemeinen Browserzugriff, da Browser nicht vertrauenswürdige Zertifikate als nicht authentifiziert behandeln und Warnungen anzeigen.

Zudem werden die Gültigkeitsdauern von Zertifikaten verkürzt (200 Tage ab März 2026, 100 Tage ab März 2027 und 47 Tage bis März 2029), was eine manuelle Erneuerung zunehmend unpraktisch macht.

Die praktische Anforderung für browserbasierte eingebettete Schnittstellen ist daher eine automatisierte, vom Browser vertrauenswürdige Verwaltung des Zertifikatslebenszyklus: Ausstellung, Installation und Erneuerung von Zertifikaten über die gesamte Produktlebensdauer hinweg.

Lösung:

In der Praxis stellen automatisierte Geräte-PKI-Lösungen wie SharkTrust die fehlende Infrastruktur bereit, wenn ein Gerät in einem privaten Netzwerk eine browserbasierte Schnittstelle zur Verfügung stellt: vertrauenswürdige Geräteidentität, automatisierte Zertifikatsausstellung und kontinuierliche Zertifikatserneuerung, ohne dass ein Eingreifen des Benutzers erforderlich ist.

Weiterführende Informationen: