Technische Kernaussagen
- Authentizität, Berechtigung, Kompatibilität und Betriebsbereitschaft getrennt prüfen.
- Ein bootfähiger bekannter Stand muss lokal erhalten bleiben.
- Rollout nach Maschinenkohorten mit Stopppunkten statt flottenweit auf einmal.
Ein Update besteht aus vier Entscheidungen
Server, Benutzer, Controller und Maschine beantworten unterschiedliche Fragen: Ist das Artefakt echt, ist das Ziel erlaubt, ist es kompatibel und ist der Prozess bereit?[2][3][1]
- Signierte Metadaten binden Hash, Größe, Version und Ablauf
- Richtlinien binden Release an Organisation und Ziel
- Der Controller prüft Hardware, OS, Runtime und Schema
- Lokale Zustände bestimmen Installation und Neustart
Metadaten signieren, nicht nur Binärdateien
Eine Signatur allein verhindert weder alte gültige Releases noch Mix-and-match oder Freeze-Angriffe. TUF und Uptane ergänzen Rollen, Versionen, Hashes und Ablaufzeiten.[2][3]
Installation als rücksetzbare Transaktion behandeln
Download in einen inaktiven Bereich, Prüfung vor Aktivierung, atomarer Wechsel und ein bootfähiger Vorgänger begrenzen Stromausfall und defekte Releases.[4][1]
| Phase | Nachweis | Recovery |
|---|---|---|
| Download | Hash, Größe, Platz | Teil löschen |
| Stage | Signatur, Kompatibilität | Aktivstand behalten |
| Aktivieren | Atomarer Slot-Wechsel | Vorigen Slot booten |
| Prüfen | Lokale Gesundheit | Automatisch zurück |
| Commit | Stabile Beobachtung | Audit speichern |
Ein laufender Prozess ist noch keine gesunde Maschine
Gesundheit umfasst Runtime, Konfiguration, I/O-Adapter, Watchdog, Telemetriealter, Ressourcen und maschinenspezifische Invarianten.[1]
Entscheidende Prüfungen bleiben lokal. Cloud-Verlust darf weder Rollback-Schleifen noch das Übergehen lokaler Interlocks auslösen.
Kohorten, Beobachtungsfenster und Stop-Regeln
- Interner Hardware-Zwilling
- Eine unkritische Kundenmaschine
- Start, Stopp und Reconnect beobachten
- Kleine diverse Kohorte
- Bei Grenzwert automatisch stoppen
- Neue Freigabe für den Rest
Kohorten sollen Hardware- und Standortvielfalt sichtbar machen; Prozentwerte allein tun das nicht.[1][5]
Nachweise über den Produktlebenszyklus behalten
Version, Hash, Freigabe, Kompatibilität, Aktivierung, Gesundheit und Rollback-Grund gehören pro Maschine in die Historie.[5][6]
- Schlüsselkompromittierung testen
- Abgelaufene Metadaten testen
- In jeder Phase Strom trennen
- Vollen Speicher und falsches Schema testen
- Rollback ohne Remote-Zugang messen
Häufig gestellte Fragen
Reicht Image-Signing?
Nein. Freshness, Rollback-Schutz, Zielberechtigung, Kompatibilität, Aktivierung, Gesundheit und lokale Recovery bleiben nötig.
Soll ein Update automatisch aktiv werden?
Download und Prüfung oft ja; Aktivierung folgt Freigabefenster, Maschinenzustand und lokaler Policy.
Wie lange den Vorgänger behalten?
Mindestens bis alle lokalen und entfernten Beobachtungskriterien erfüllt sind.
Quellen und Standards
- NIST SP 800-82 Rev. 3: Guide to Operational Technology SecurityNational Institute of Standards and Technology, September 2023
- The Update Framework specificationThe Update Framework
- Uptane Standard for Design and Implementation 1.1.0Uptane
- IoT Security Verification Standard: Software Platform RequirementsOWASP Foundation
- NIST SP 800-218: Secure Software Development FrameworkNational Institute of Standards and Technology, February 2022
- Regulation (EU) 2024/2847: Cyber Resilience ActEUR-Lex
BootCtrl Engineering hat die technischen Aussagen und Quellenlinks zuletzt am 26. Juli 2026 geprüft. Produktaussagen werden mit den aktuellen Implementierungs-Repositories abgeglichen; Roadmap-Arbeit wird nicht als verfügbare Funktion dargestellt.
