Release Notes: September-2026-Release

Veröffentlichungsdatum: 17. September 2026 Zielgruppe: Enterprise-Administratoren, SREs und CISOs

Dieses Release umfasst alle Änderungen, die zwischen dem StateWarden-Agent-Release 1.2.0 (13. Juli 2026) und dem 17. September 2026 ausgeliefert wurden. Die zentrale Neuerung ist Ransomware Protection (Active Defense): Agenten erkennen jetzt während Backups Schreibmuster, die für Ransomware typisch sind, und führen autonom eine konfigurierbare Reaktionsrichtlinie aus - bis hin zum Netzwerk-Lockdown des betroffenen Hosts. Das Release bringt außerdem den Audit-Pack-Nachweisbericht für NIS2-/KSC-/BSIG-Audits, die Cockpit-Seite „Realm-Übersicht", die Propagation von Schlüssel-Epochen über die gesamte Backup-Kette, eine strikte Fehlerberichterstattung für Backups und eine Reihe flottenweiter Vigil-Scan-Fixes.

Hinweise zur Verfügbarkeit bei gestuften Rollouts finden Sie am Ende dieses Dokuments; nicht jede Komponentenversion ist zum Zeitpunkt der Veröffentlichung allgemein verfügbar.

Ransomware Protection (Active Defense)

Autonome Ransomware-Reaktion (Agent 1.5.0, 8. September)

Entropiebasierte Erkennung in der Backup-Pipeline: Geänderte Chunks werden während des Backup-Laufs auf Schreibmuster mit hoher Entropie analysiert. Die Erkennungsschwellenwerte sind konfigurierbar: Mindestanzahl geänderter Chunks (Standard 50, etwa 50 MB), Entropie-Obergrenze (Standard 7.8 auf der Skala von 0 bis 8) und Anteil geänderter Daten (Standard 0.90 - 90 % der geänderten Daten müssen dem Muster entsprechen).
Reaktions-Executor: Bei Erkennung führt der Agent die konfigurierte Richtlinie sofort aus, ohne auf eine Eingabe der Control Plane zu warten. Agent 1.5.0 implementiert zwei Aktionen: Backup unter Quarantäne stellen (das Backup wird abgeschlossen, aber markiert) und Nur Alarm (das Backup wird abgebrochen und mit entsprechendem Grund als fehlgeschlagen gemeldet).
Audit-Trail: Jede Erkennung wird mit der konfigurierten Aktion und deren Ausführungsergebnis im Audit-Log protokolliert. Unter Quarantäne abgeschlossene Backups werden als möglicherweise infiziert markiert und im Dashboard entsprechend gekennzeichnet, einschließlich einer Warnung im Wiederherstellungsdialog.
Das Dashboard steuert die Verwaltung der Reaktionsrichtlinie abhängig von der Agent-Version.

Netzwerk-Lockdown und Ausschalten (Agent 1.6.0, 9. September)

Netzwerk-Lockdown: Eine Default-Deny-Netzwerkrichtlinie, die auf dem Host angewendet wird. Der Lockdown lässt nur den Artemis-Steuerkanal und das aktive Driad-Speicherziel offen, plus DNS (udp/53) und NTP (udp/123) - so bleibt der Verwaltungskanal aktiv, was den Lockdown remote umkehrbar macht. Unter Linux verwendet der Agent nftables (dedizierte Tabelle inet statewarden_lockdown) mit iptables-Fallback; bestehende Benutzerregeln werden niemals gelöscht. Unter Windows setzt er die Firewall-Profilrichtlinie auf „Eingehend/Ausgehend blockieren" und fügt deterministische Allow-Regeln hinzu. Der Lockdown-Zustand wird auf der Festplatte persistiert und beim Start erneut angewendet, sodass er einen harten Reset übersteht.
Ausschalten: Leitet ein verzögertes (20 s) Herunterfahren des Systems ein. Die Verzögerung garantiert, dass Audit-Events und der finale Aufgabenbericht geschrieben werden, bevor die Maschine herunterfährt.
Aufhebung: Ein gesperrter Host kann vom Dashboard aus wieder in den normalen Netzwerkbetrieb versetzt werden. Die Aktion ist durch eine MFA-Abfrage geschützt und wird im Audit-Log protokolliert.
Diese beiden Aktionen erfordern Agent 1.6.0 oder neuer. Ältere Agenten (1.5.0), die eine Lockdown- oder Ausschalten-Richtlinie erhalten, stufen sicher auf „Nur Alarm" herab und protokollieren die Herabstufung im Audit-Log.

Verwaltung der Reaktionsrichtlinie (WebAPI 0.7.0 / 0.8.0, 9. September)

Realm-Standards und gerätebezogene Overrides: Reaktionsrichtlinien werden pro Realm mit gerätebezogenen Overrides verwaltet. Alle Richtlinienänderungen erfordern eine MFA-Bestätigung und werden im Realm-Audit-Log protokolliert.
Push der effektiven Richtlinie: Die effektive Richtlinie (Geräte-Override, sonst Realm-Standard, sonst eingebaute Standardwerte) wird serverseitig berechnet und automatisch an die Agenten gepusht. Agenten lösen die Vererbung niemals selbst auf. Virtuelle Maschinen fallen unter die Richtlinie des Agenten ihres übergeordneten Hypervisors - ein Agent setzt eine Richtlinie durch.
Eingebauter Standard: Realms ohne gespeicherte Richtlinie sind dennoch geschützt: Der eingebaute Standard löst einen Alarm aus und stellt das Backup unter Quarantäne, mit den Standardschwellenwerten. Das Zurücksetzen einer Richtlinie kehrt zu diesem Standard zurück, statt den Schutz zu deaktivieren.

Dashboard: Seite „Ransomware-Schutz"

Eine neue Seite Ransomware-Schutz (/active-defense) verwaltet den Realm-Standard: Auswahl der Reaktionsaktion (Backup unter Quarantäne stellen / Nur Alarm / Netzwerk-Lockdown / Ausschalten), Entropie-Schwellenwerte mit Inline-Beispielen und Erkennungsmethoden.
Ein Tab für gerätebezogene Overrides im Gerätedetail-Dialog zeigt jedes Feld mit einem Badge GEERBT oder BENUTZERDEFINIERT und Rücksetzung auf Vererbung per Ein-Klick.
Netzwerk-Lockdown und Ausschalten sind nur für Geräte mit Agent 1.6.0 oder neuer wählbar; Geräte mit älteren Agenten sind entsprechend gekennzeichnet und stufen auf „Nur Alarm" herab.
Geräte unter einem aktiven Lockdown zeigen ein Badge NETZWERK-LOCKDOWN mit der Aktion Netzwerk wiederherstellen. Infizierte Backups zeigen einen Chip MÖGLICHERWEISE INFIZIERT in Backup-Listen und ein Warnbanner im Wiederherstellungsablauf.

Backup-Zuverlässigkeit und Schlüsselverwaltung

Propagation der Schlüssel-Epochen (Agent 1.3.0, 3. September)

Die Schlüsselrotation hinterließ bisher Lücken, die still nicht wiederherstellbare Backups erzeugen konnten (Manifeste mit gemischten alten/neuen Schlüsseln) oder mit einem widerrufenen Schlüssel geschriebene Backups als completed meldeten. Schlüssel-Epochen propagieren jetzt End-to-End:

Pre-Flight-Blockierung bei veraltetem Schlüssel: Wenn die Schlüssel-Epoche des Servers neuer ist als die des Agenten, wird das Backup abgebrochen, bevor irgendwelche Daten geschrieben werden - mit explizitem Fehlergrund - statt ein ungültiges Backup zu erzeugen.
CBT-Epochen-Validierung: Der an eine frühere Schlüssel-Epoche gebundene inkrementelle Tracking-Zustand wird unter Linux und Windows verworfen und neu als Baseline erfasst; das erste Backup nach einer Rotation ist automatisch eine vollständige Baseline.
Erzwungene Vollbackups: Eine vollständige Baseline wird automatisch erzwungen, wann immer die Kette es erfordert - bei manuellem Trigger, bei leerer Backup-Kette oder bei einem Wechsel der Schlüssel-Epoche. Jedes Backup zeichnet die Schlüssel-Epoche auf, unter der es geschrieben wurde.
Dashboard: Backups, die unter einer früheren Schlüssel-Epoche geschrieben wurden, zeigen den Zustand VERALTETER SCHLÜSSEL, und „Backup jetzt starten" bietet einen Pfad „Vollbackup erzwingen".

Backup-Fehlerresilienz (Agent 1.4.0, 6. September)

Ehrliche Fehlerberichterstattung: Geplante Backups und alle Proxmox-Codepfade melden jetzt Failed, statt Fehler still zu verwerfen; ein VM-Backup meldet kein Completed mehr, wenn der Manifest-Upload fehlgeschlagen ist.
Erkennung hängender Aufgaben: Artemis erkennt Backups, die 30 Minuten lang keinen Fortschritt zeigen. Agenten, die mitten im Backup abgebrochen sind, werden über ein In-Flight-Journal auf der Festplatte und über einen finalen Statusbericht beim sauberen Herunterfahren erkannt.
Sichtbare Konsequenzen: Fehlgeschlagene Backups erhalten einen strukturierten Fehlergrund, werden aus dem Speicher entfernt (nur Backup-Artefakte - mit gesunden Backups geteilte Chunks werden niemals angefasst), erscheinen in der UI mit lokalisiertem Grund und lösen eine E-Mail-Benachrichtigung an die Realm-Mitglieder aus.
Fortschrittsberichte: Der Backup-Fortschritt wird jetzt zusätzlich zu den Byte-Zählern als echter Prozentwert gemeldet.

Security-UX-Verbesserungen (Dashboard 0.6.0 / WebAPI 0.9.0, 14. September)

Das Panel PRIORITÄRE GERÄTE auf der Seite „Bedrohungslandschaft" reiht die Flotte nach kritischen Befunden, aktiven Befunden und Risikowert, mit Deep Links in die Triage.
Schwachstellen-Triage: Gerätefilter mit Zählern, Gruppierung nach Gerät, Deep Links (?device=<uuid>), klickbare Zeilen mit Befunddetails-Dialog und Massen-Triage-Entscheidungen für bis zu 500 Befunde gleichzeitig.
Exporte und Berichte: CSV-Export unter Berücksichtigung aktiver Filter und PDF-Berichte pro Gerät oder pro Realm, auf Abruf generiert, einschließlich eines optionalen linierten Notizbereichs für Papier-Workflows.
Befund-Antworten enthalten jetzt den Gerätenamen/Hostnamen, und die Verlaufssuche findet Gerätenamen.
Badge „Keine Daten": Geräte, die noch nie gescannt wurden (z. B. agentenlose VMs), zeigen kein grünes „Sicher"-Badge mehr - sie zeigen einen neutralen Zustand „Keine Daten", bis der erste Scan abgeschlossen ist.

Vigil-Scan-Fixes (Agent 1.6.2, 14. September)

Drei unabhängige plattformübergreifende Fehler hatten sich überlagert und den geplanten Sicherheitsscan auf einem Großteil der Flotte still deaktiviert:

Dateisystem-Scans seit April flottenweit defekt: Ein Defekt im Upload der Scanberichte führte dazu, dass jeder Malware-Scanbericht als nicht autorisiert abgelehnt wurde. Behoben; der erste erfolgreiche flottenweite Dateisystem-Scan seit dem 24.04.2026 wurde noch in derselben Nacht aufgezeichnet.
Fehlender Standard-Scanzeitplan: Agenten, die nie einen Konfigurations-Push erhalten hatten, besaßen überhaupt keinen Sicherheitszeitplan. Der Scheduler greift jetzt auf eingebaute Standardwerte zurück (Inventar alle 1440 Min., Malware-Scan alle 720 Min.) und heilt sich beim nächsten Lauf selbst - betroffene Geräte stellen sich ohne manuellen Eingriff wieder her, sobald sie aktualisiert werden.
Geplante Scans mit null Dateien: Der manuelle Scan-Trigger konnte in die Pfade geplanter Scans auslaufen und Scans mit null Dateien erzeugen. Dies wird jetzt agentenseitig verhindert.
Fehlersichtbarkeit: Scan-Fehler werden jetzt als Audit-Events (Artemis 0.6.1) aufgezeichnet, sichtbar in Gerätelogs und Benachrichtigungen, und Scan-Abschlusszeiten werden korrekt erfasst.

Audit Pack (WebAPI 0.10.0 / Dashboard 0.7.0, 14. September)

Audit-Nachweisberichte

Audit-Nachweisdatensatz: Das Audit Pack erzeugt einen strukturierten Audit-Nachweisdatensatz für einen wählbaren Zeitraum (Standard 90 Tage, maximal 400) und ein Rechtsraumprofil. Der Zugriff erfordert die Berechtigung realm.view_audit_logs; jede Berichtserstellung wird selbst im Audit-Log protokolliert.
Die neue Dashboard-Seite /audit-pack rendert ein On-Demand-PDF für NIS2-Audits mit Rechtsraumprofilen für die EU-Baseline, Polen (KSC), Deutschland (BSIG/NIS2UmsuCG) und Frankreich (ReCyF - deutlich als „Promulgation ausstehend" gekennzeichnet).
Das Rückgrat des Berichts ist eine Anforderungsabdeckungsmatrix, die jede gesetzliche Anforderung auf ihren Nachweis abbildet (abgedeckt / teilweise abgedeckt / nicht abgedeckt), plus Nachweisanhänge (Mitglieder, Sitzungen, Authentifizierungsereignisse, Änderungsprotokoll, Backup-Status, Wiederherstellungsverlauf, Sicherheitsstatus, Infrastruktur, Versionen).
Organisatorische Anforderungen, die Software nicht nachweisen kann (Schulung, Risikopolitik, Lieferkette, Personal, physische Sicherheit), werden durch eine Bestätigungscheckliste des Kunden abgedeckt, die als KUNDENERKLÄRUNGEN gedruckt wird.

Erweitertes Audit-Logging

Ein neues Konto-Audit-Log zeichnet Authentifizierungs-, MFA-, Sitzungs-, Registrierungs- und Kontoeinstellungsereignisse mit IP-Adresse und User Agent auf.
Die Abdeckung des Realm-Logs wurde auf IAM-Mitgliedschaftsänderungen, Änderungen an Backup-Richtlinien, den Lebenszyklus von Kopplungscodes, Unterdrückungsregeln und Entscheidungen der Schwachstellen-Triage erweitert.
Artemis 0.7.0 ergänzt Audit-Events für den gesamten Kopplungslebenszyklus: Gerätekopplung, Recovery-Kopplung und abgelehnte Kopplungsversuche.

Agent 1.7.0: Verifizierte Updates und Audit-Events für Restore/Update

OTA-Update-Verifizierung (Dual-Modus): Der Updater verifiziert den SHA256-Hash der Update-Payloads. Ein wohlgeformter Hash wird fail-closed durchgesetzt (Abweichung = Update abgelehnt); Payloads ohne wohlgeformten Hash nutzen den Legacy-Pfad, eskalieren das Update-gestartet-Event auf WARNING und markieren alle Update-Events als nicht hash-verifiziert. TLS gegen den Distributionsserver ist jetzt strikt (öffentlich vertrauenswürdiges Zertifikat erforderlich). Die Hash-Durchsetzung wird in einem zukünftigen Release verpflichtend, sobald die Flotte den neuen Updater verwendet.
Neue Audit-Events: Agentenstart, Update-Lebenszyklus, Backup-Start und Ergebnisse von Bare-Metal-Restores werden jetzt aufgezeichnet.
Wahrheitsgemäße Restore-Ergebnisse: Proxmox-Restores, die teilweise fehlschlagen, werden jetzt als fehlgeschlagen statt als abgeschlossen gemeldet und starten die VM nach einem Teilfehler nicht mehr automatisch. Erfolgreiche Restores melden Chunk- und Byte-Zahlen.

Realm-Übersicht (WebAPI 0.11.0 / Dashboard 0.8.0, 16. September)

Ein neues Cockpit /overview beantwortet die Frage „Was passiert gerade in meinem Realm?" aus einer einzigen serverseitig berechneten Übersicht.
KPI-Kacheln: Flottenstatus (online/offline, 7-Tage-Schutzabdeckung), Backups der letzten 24 Std. (einschließlich übertragener Bytes), Sicherheitsstatus, die effektive Active-Defense-Aktion, die den Realm schützt (mit Indikator „Standard"/„Angepasst"), Speicherkontingent mit Schwellenwert-Einfärbung, Deduplizierungsrate mit dreistufiger Aufschlüsselung (Restore-Größe → deduplizierte Datengröße → physisch gespeicherte Backups + Metadaten) und Backup-Zuverlässigkeit (30-Tage-Erfolgsrate, Anzahl der Wiederherstellungspunkte, ältester Wiederherstellungspunkt).
Diagramme: 30-tägige Backup-Aktivität (segmentierte Spalten pro Tag, abgeschlossen vs. fehlgeschlagen) und ein Diagramm zum geschützten Datenfluss (logische vs. übertragene Bytes pro Tag).
Handlungsbedarf: Eine serverseitig berechnete Liste fehlgeschlagener Backups, möglicherweise infizierter Backups, kritischer Befunde, Offline-Geräte und Geräte ohne Backup-Richtlinie, jeweils mit Deep Link zur relevanten Seite. Ein Feed der letzten Aktivitäten rundet die Seite ab.
Berechtigungen pro Abschnitt: Jeder Abschnitt ist durch dieselbe Berechtigung geschützt wie seine dedizierte Seite; Abschnitte, die der Benutzer nicht sehen darf, werden vollständig ausgelassen statt ausgegraut angezeigt. Die Seite aktualisiert sich alle 30 Sekunden.

Plattform- und Agent-Wartung

Agent 1.2.2: Log-Rotation - täglich rotierende Logs mit automatischer Bereinigung von Dateien älter als 7 Tage unter Linux und Windows.
Agent 1.2.3: iSCSI-Unmount-Fix.
Agent 1.2.7: Cascade-Crypto-Integration.
Agent 1.2.11: Fixes für inkrementelle Windows-CBT-Backups (USN-Journal).
Agenten 1.3.1 bis 1.3.4: Fixes für iSCSI Instant Mount unter Windows - randomisierte MBR-Festplattensignaturen zur Vermeidung von Signaturkollisionen zwischen gemounteten Backup-Festplatten, sowie ein Fix für das von Partmgr persistierte OFFLINE-Attribut, das die wiederverwendete PnP-Festplatteninstanz korrumpierte und jeden Mount nach dem ersten Unmount offline erscheinen ließ.
Agent 1.6.1: QMP-Read-Buffer-Fix - Proxmox-VM-Backups schlugen bei VMs fehl, deren QMP-Antworten den 4-KiB-Zeilenpuffer des Agenten überschritten (abhängig von der Hardware-Konfiguration, z. B. VMs mit mehreren Festplatten).
WebAPI 0.8.1: Kopplungscodes werden jetzt ausschließlich in Großbuchstaben generiert (A-Z0-9), mit case-insensitiver Eingabe, Widerruf und Kopplung; die Meldung der Restore-Größe wurde korrigiert (historische abgeschlossene Backups zeigen ohne Datenmigration korrekte Restore-Größen an).
Windows-MSI-Installer: Ein Fehler bei frischen Windows-10-Installationen wurde behoben. Das MSI paketierte zuvor eine MSVC-kompilierte Binärdatei, die das VC++ Redistributable erforderte; es liefert jetzt denselben GNU-Toolchain-Build wie jedes andere Windows-Artefakt, und die CI lehnt jede Windows-Binärdatei ab, die VCRUNTIME140/MSVCP140 importiert.

Verfügbarkeit

Agenten 1.3.x bis 1.6.2 sind allgemein verfügbar und werden per OTA auf der Flotte ausgerollt.
Agent 1.7.0 (OTA-Hash-Verifizierung, neue Audit-Events, wahrheitsgemäße Restore-Ergebnisse) ist Stand 17. September nur im Testkanal verfügbar; der flottenweite Rollout folgt nach der Testkanal-Validierung.
Realm-Übersicht (WebAPI 0.11.0 / Dashboard 0.8.0) wird schrittweise ausgerollt, WebAPI vor Dashboard. Bis zum Abschluss des Rollouts kann die Übersichtsseite nicht verfügbar sein oder Teildaten anzeigen.

Komponentenversionen

Core-Agent (sw): 1.7.0 (Testkanal; die allgemeine Flotte bleibt auf 1.6.2)
WebAPI: 0.11.0
Dashboard: 0.8.0
Artemis: 0.7.0
Vigil: 1.4.0
Driad: 0.7.0
Hermes: 0.2.0