IoT-Sicherheit – Best Practices: vernetzte Geräte vor Angriffen schützen

Ein ungesichertes IoT-Gerät ist nicht nur ein Risiko für seinen Besitzer — es ist ein Knoten in einem potenziellen Botnet, ein Angriffspunkt für Netzwerkeindringlinge und eine Haftungsquelle nach DSGVO und NIS2. Sicherheit muss vom ersten Tag an mitgedacht und nicht erst nach der Auslieferung nachgerüstet werden.

Geräteidentität: X.509-Zertifikate

Root CA (offline, air-gapped)
  └── Intermediate CA (Werks-HSM)
       └── Gerätezertifikat (eindeutig pro Gerät)
            • privater Schlüssel im ATECC608B Secure Element
            • öffentliches Zertifikat im Werk in NVS gebrannt
            • authentifiziert sich per mTLS am Azure IoT Hub

TLS 1.3 für die gesamte Cloud-Kommunikation

esp_mqtt_client_config_t cfg = {
    .cert_pem        = azure_root_ca_pem,
    .client_cert_pem = device_cert_pem,
    .client_key_pem  = device_key_pem,
};

Netzwerksegmentierung

IoT-Geräte sollten sich in einem dedizierten VLAN befinden. Verwenden Sie Firewall-Regeln, um nur ausgehende MQTT/HTTPS-Verbindungen zu bekannten Endpunkten zuzulassen — keine eingehenden Verbindungen, keine laterale Bewegung.

Sicheres Lebenszyklus-Management von Geräten

Sicherheit endet nicht mit der Auslieferung. Ein Gerät im Feld hat einen Lebenszyklus: Es erhält Firmware-Updates, seine Zertifikate laufen ab und müssen erneuert werden, sein Besitzer kann wechseln, und schließlich erreicht es das Ende seiner Lebensdauer und muss sicher außer Betrieb genommen werden. Jede Phase hat Sicherheitsanforderungen, die von Anfang an in das System eingeplant werden müssen.

Die Zertifikatserneuerung erfordert einen sicheren OTA-Kanal, um neue Zertifikate vor dem Ablauf der alten auszuliefern. Wenn ein Gerät über einen längeren Zeitraum offline war und sein Zertifikat während dieser Offline-Zeit abläuft, kann es sich bei der Wiederverbindung nicht authentifizieren — es macht sich aus Konnektivitätssicht praktisch selbst unbrauchbar. Entwerfen Sie einen Bootstrap-Mechanismus, der es Geräten ermöglicht, sich mit einem neuen Zertifikat und einem sekundären Berechtigungsnachweis neu zu registrieren, etwa einer mit einem Werksschlüssel signierten Geräteseriennummer, die im Sicherheitselement gespeichert ist.

Bedrohungsmodellierung für IoT-Produkte

Führen Sie vor der Fertigstellung Ihrer Sicherheitsarchitektur eine formale Bedrohungsmodellierung nach der STRIDE-Methodik durch: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege. Identifizieren Sie für jede Bedrohung die Angriffsfläche, die Wahrscheinlichkeit und die Auswirkung und definieren Sie dann Gegenmaßnahmen. Diese Übung deckt regelmäßig Sicherheitslücken auf, die beim ursprünglichen Design nicht offensichtlich waren — insbesondere im Zusammenhang mit Szenarien des physischen Zugriffs und Angriffen auf die Lieferkette.

Gängige IoT-Bedrohungsszenarien, die die Bedrohungsmodellierung aufdeckt: ein böswilliger Akteur, der Firmware aus einem Produktionsgerät extrahiert, um Ihr geistiges Eigentum zurückzuentwickeln (durch Flash-Verschlüsselung entschärft); ein betrügerisches Gerät, das falsche Telemetriedaten einspeist, indem es sich als legitimes Gerät ausgibt (durch gerätespezifische X.509-Zertifikate entschärft); eine Kompromittierung der Lieferkette, bei der Komponenten durch manipulierte Teile ersetzt werden (durch Werksprovisionierungsverfahren und Hardware-Bindung an das Sicherheitselement entschärft).

Planung der Vorfallsreaktion

Wenn ein Sicherheitsvorfall eintritt — und bei jedem im großen Maßstab eingesetzten Produkt wird das irgendwann der Fall sein — bestimmt Ihr Reaktionsplan, ob es sich um eine kontrollierte Offenlegung oder eine Krise handelt. Definieren Sie Ihre Vorfallsreaktionsverfahren vor der Markteinführung: wie man kompromittierte Geräte identifiziert, wie man Zertifikate aus der Ferne widerruft, wie man Notfall-Patches ausrollt und wie man mit betroffenen Kunden kommuniziert. Azure IoT Hub bietet über die Geräteregistrierung einen gerätespezifischen Zertifikatswiderruf — ein kompromittiertes Gerät kann innerhalb von Sekunden über das Cloud-Dashboard getrennt und sein Zertifikat für ungültig erklärt werden.