Nachweise nach NIS2 und BSI

Zum Inhaltsverzeichnis

NIS2 und der IT-Grundschutz des BSI verlangen, dass Sicherungen nicht nur laufen, sondern dass sich das belegen lässt. Jedes Target führt dafür ein Nachweis-Protokoll, das sich nachträglich nicht unbemerkt ändern lässt, und erstellt daraus einen signierten Monatsbericht als PDF.

12.1 Was festgehalten wird#

• jede ankommende Sicherung und jeder Spiegel mit Client, Adresse, übertragener Datenmenge und Ergebnis, Abweisungen wegen Kontingent
• jede Wiederherstellung mit Ergebnis
• jeder Job des Target-Schedulers: wodurch er gestartet wurde (Zeitplan, Ereignis, anderer Job, von Hand mit Token und Adresse), worauf er wartete, wie er endete
• jedes Prüf-Restore je Sicherung und Schritt
• Eingriffe in die Daten: gelöschte Läufe, geänderte Aufbewahrung, Bereinigungen mit freigegebenem Platz, gefundene Schäden, Aktionen über die Target-API
• die Uhr des Servers: täglich, ob sie mit NTP abgeglichen ist, und jeder Sprung über 5 Minuten

Konfigurationsänderungen und Anmeldungen stehen nicht darin; sie bleiben im Journal des Servers.

12.2 Wie das Protokoll geschützt ist#

• Kette: Jede Zeile enthält die SHA-256-Prüfsumme ihrer Vorgängerin, über alle Tage hinweg. Wer eine Zeile ändert oder löscht, bricht die Kette.
• Siegel: Jeder Tag wird nach seinem Ende (00:05 Uhr) mit dem Ed25519-Schlüssel des Targets versiegelt und gleich danach geprüft. Weicht etwas ab, bekommt der Betreiber eine Mail.
• Kopie an einem zweiten Ort: jeder Eintrag sofort an einen Syslog-Server oder ein SIEM und/oder jeder versiegelte Tag an ein anderes Target. Fällt die Kopie aus, geht nichts verloren; der Ausfall steht selbst im Protokoll.
• Aufbewahrung: 10 Jahre (keep-years=), nie kürzer als bis zum ältesten Lauf, den die Stores noch haben. Ein signierter Anker hält die Kette prüfbar, wenn alte Tage gelöscht werden.

Abschnitt [audit] in /etc/bkp/bkp_target.cfg

[audit]
keep-years=10
syslog=tls://siem.example.net:6514
syslog-ca=/etc/bkp/siem-ca.pem
copy-target=https://backup-muc1.example.net:9991
copy-token=file:/etc/bkp/audit-copy.token
copy-ca=/etc/bkp/backup-muc1.crt
target-id=backup-fra1
report=monthly

Das empfangende Target legt die Tage unter /var/lib/bkp_target/audit-remote/<target-id>/ ab, nur wenn sie zum hinterlegten öffentlichen Schlüssel passen (/etc/bkp/audit-remote/<target-id>.pub, die audit.pub des sendenden Targets), und ersetzt einen abgelegten Tag nie. bkp_target --sched-validate empfiehlt eine Kopie, solange keine eingerichtet ist.

12.3 Prüfen, exportieren, berichten#

Der Bericht fasst einen Monat zusammen: Sicherungen je Backup mit Erfolgen und Fehlschlägen, Wiederherstellungen, Prüf-Restores, Eingriffe, Schäden, die Jobs und abgelaufene Wartefristen, den Zustand des Protokolls (Kette, Siegel, Kopie, Fingerabdruck des Schlüssels) und die Zuordnung zu den Anforderungen. Mit report=monthly (Standard) erstellt das Target ihn am Monatsersten von selbst, legt ihn 13 Monate lang ab und mailt ihn samt Signatur an den Betreiber; Kunden mit report = yes in target-customers.cfg bekommen ihren eigenen über ihre Sicherungen. report=weekly liefert ihn montags für die Vorwoche.