Das Backup, das da sein muss, wenn man es braucht.
ISO 27001:2022 A.8.13 (Informationssicherung) ist die Kontrolle für die Wiederherstellbarkeit: die Fähigkeit, Informationen, Software und Systeme nach einem Verlust, einer Beschädigung oder einer fehlerhaften Änderung wiederherzustellen. In der Praxis bedeutet das, zu entscheiden, was gesichert werden muss, Backups dafür zu erstellen, diese Kopien zu schützen und tatsächlich eine Wiederherstellung zu testen, um sicherzustellen, dass die Wiederherstellung funktioniert. Die Wiederherstellbarkeit wird zunehmend im Code bereitgestellt: eine Aufbewahrungsdauer für eine verwaltete Datenbank, ein Snapshot-Zeitplan, eine Lebenszyklusrichtlinie. Das bedeutet, dass es sich um eine Pull-Request-Entscheidung handelt, die mit einer einzigen Zeile deaktiviert werden kann.
The shapes the same control failure takes.
A.8.13 scheitert selten daran, dass jemand die Backups löscht. Es scheitert, wenn eine Änderung leise die Fähigkeit zur Wiederherstellung entfernt. Die wiederkehrenden Muster:
Automatische Backups werden deaktiviert
Die Aufbewahrungsfrist wird auf null gesetzt oder ein geplanter Snapshot oder Backup-Job wird entfernt, sodass ein Speicher, der früher wiederherstellbar war, nun keinen aktuellen Wiederherstellungspunkt mehr hat.
Aufbewahrungsfrist liegt unter dem Wiederherstellungsfenster
Die Aufbewahrungsfrist eines Backups wird so stark verkürzt (z. B. von 30 Tagen auf einen Tag), dass sie nicht mehr den Zeitraum abdeckt, in dem ein Vorfall unbemerkt bleiben kann, bevor eine Wiederherstellung erforderlich ist.
Ein neuer Speicher wird ohne Backup bereitgestellt
Eine Datenbank, ein Bucket oder ein Volume, das echte Daten enthält, wird ohne jede Backup-Konfiguration bereitgestellt, sodass bei einem Verlust nichts zur Wiederherstellung verfügbar ist.
Die Wiederherstellung wird nie überprüft
Ein Schritt, der eine Wiederherstellung testet oder überprüft, wird entfernt, sodass Backups zwar weiterhin erstellt werden, aber niemand weiß, ob sie tatsächlich wiederhergestellt werden können - was A.8.13 erwartet, dass man testet.
Ein Backup bleibt ungeschützt
Ein Snapshot oder Backup wird öffentlich zugänglich gemacht, unverschlüsselt oder zu weit geteilt, sodass die Backup-Kopie selbst zur Schwachstelle wird, vor der sie schützen sollte.
Automatische Backups für die primäre Datenbank deaktiviert.
Ein Team möchte die Kosten für automatische Backup-Speicherung bei einer verwalteten Postgres-Datenbank vor dem Launch sparen und setzt die Aufbewahrungsfrist auf null. Die Instanz hat nun keine automatischen Backups mehr und keine Point-in-Time-Wiederherstellung daraus. Bei Datenverlust oder -beschädigung muss die Wiederherstellung auf andere vorhandene Ressourcen (manueller Snapshot, separates Backup-Tool) zurückgreifen - oft gibt es aber nichts anderes.
resource "aws_db_instance" "primary" { engine = "postgres"- backup_retention_period = 7+ backup_retention_period = 0 # disables automated backups}Durch das Setzen der Aufbewahrungsfrist auf null werden automatische Backups und die Point-in-Time-Wiederherstellung für die primäre Datenbank deaktiviert, sodass bei einem Verlust oder einer Beschädigung kein aktueller automatischer Wiederherstellungspunkt verfügbar ist. A.8.13 (Informationssicherung) geht es um die Fähigkeit zur Wiederherstellung, und es wird erwartet, dass Backups gepflegt und getestet werden. Behalten Sie eine Aufbewahrungsfrist bei, die Ihre Wiederherstellungsanforderungen abdeckt (oder verlagern Sie die Backups auf ein dediziertes Tool), anstatt sie zu deaktivieren, um Speicherplatz zu sparen.
Backup wird daran gemessen, ob eine Wiederherstellung tatsächlich möglich ist.
Ein Prüfer akzeptiert die Aussage 'wir haben Backups' nicht einfach so. Er überprüft, ob Backups für die relevanten Systeme existieren, für den in der Richtlinie festgelegten Zeitraum aufbewahrt werden, geschützt sind und - entscheidend - durch eine tatsächliche Wiederherstellung getestet wurden. Ein Speicher mit deaktivierten Backups, eine Aufbewahrungsfrist, die unter dem Wiederherstellungsfenster liegt, oder eine neue Datenbank ohne Backups sind genau die Art von Lücken, die zu einem Befund führen, und diese entstehen meist durch eine einzelne Änderung in der Infrastrukturkonfiguration. Der Diff ist der günstigste Ort, um sie zu erkennen.
Eine Überprüfung, nicht Ihr Backup-System.
heygrc markiert Änderungen, die A.8.13 betreffen, und verweist auf die Kontrolle, damit die Korrektur im Pull Request erfolgt. Es führt keine Backups durch und testet keine Wiederherstellungen. Es erkennt den Moment, in dem eine Änderung die Fähigkeit eines Speichers zur Wiederherstellung entfernt oder schwächt - direkt im Diff.