Wiederherstellen der Ledgerdatenbank nach einer Manipulation
Gilt für: 
SQL Server 2022 (16.x) Azure SQL-Datenbank Azure SQL Managed Instance
Wiederherstellen einer Datenbank nach einer Manipulation
Die einfachste Reparaturmöglichkeit nach einer Manipulation besteht darin, die neueste, überprüfbare Sicherung der Datenbank wiederherzustellen. Stellen Sie zu diesem Zweck die Datenbank zu unterschiedlichen Zeitpunkten wieder her, und überprüfen Sie den Ledger anhand früherer Datenbankdigests. Die späteste Wiederherstellung, die erfolgreich überprüft werden kann, wurde garantiert nicht manipuliert und kann daher weiterhin für die Verarbeitung von Transaktionen verwendet werden. Aus diesem Grund ist es wichtig, regelmäßige Sicherungen durchzuführen, um dem Zeitpunkt der Manipulation so nahe wie möglich zu kommen. Die Sicherungszeitplanung erfolgt für Azure SQL-Datenbank automatisch. Diese einfache Technik hat jedoch einen entscheidenden Nachteil: Wurden alle Transaktionen nach der Manipulation ausgeführt, müssen Sie akzeptieren, dass diese Transaktionen verloren gehen oder die Ledgertabelle manuell repariert werden muss. Hierfür müssen die Informationen für die überprüften Transaktionen neu eingefügt und die Hashwerte für diese neuen Transaktionen, die nach dem ersten Manipulationsereignis im Datenbankledger ausgeführt wurden, neu berechnet werden.
Manipulationskategorien
Je nach Art der Manipulation kann der Ledger auch repariert werden, ohne dass Daten verloren gehen. Es gibt zwei Kategorien von Manipulationsereignissen.
Die Manipulationen wirken sich nicht auf weitere Transaktionen aus
Durch das Manipulationsereignis wurden zwar einige im Ledger gespeicherte Daten geändert, doch sind keine weiteren Transaktionen davon beeinflusst. Dies kann der Fall sein, wenn der Angriff entdeckt wurde, bevor weitere Transaktionen für die manipulierten Daten ausgeführt wurden, oder wenn die Daten auf eine Weise manipuliert wurden, die sich nicht auf neue Transaktionen auswirkt. Wenn Sie z. B. in einer Ledgertabelle Details zu Banktransaktionen speichern, wirkt sich eine Manipulation vorhandener Transaktionen nicht auf neue Transaktionen aus, die für das aktuelle Guthaben ausgeführt werden.
Da die Manipulation keine Auswirkungen auf Transaktionen nach dem Manipulationsereignis besitzt, sind die neuen Transaktionsausführungen und die generierten Ergebnisse korrekt. In diesem Fall sollten Sie den konsistenten Zustand des Ledgers möglichst wiederherstellen, ohne diese Transaktionen zu beeinträchtigen.
Wurde der Ledger nicht auf Datenbankebene angegriffen, kann die Manipulation einfach erkannt und repariert werden. Der Datenbankledger befindet sich in einem konsistenten Zustand, alle Datenbankdigests wurden generiert, und für alle neuen angefügten Transaktionen wurde mithilfe der gültigen Hashes früherer Transaktionen ein Hashwert erstellt. Somit sind alle generierten Datenbankdigests auch für Transaktionen gültig, die nach der Manipulation ausgeführt wurden. Sie können versuchen, die korrekten Nutzdaten des Tabellenledgers für die manipulierten Transaktionen aus Sicherungen abzurufen, die als sicher eingestuft werden können (durch Anwenden der Ledgerüberprüfung), und die Betriebsdatenbank durch Überschreiben der manipulierten Daten im Tabellenledger zu reparieren. Dadurch wird eine neue Transaktion zur Erfassung der Reparaturtransaktionen erstellt.
Die Manipulationen wirken sich auf Daten aus, die von weiteren Transaktionen genutzt werden
Das Manipulationsereignis hat Auswirkungen auf Daten, die anschließend von weiteren Transaktionen verwendet wurden und sich somit auf deren Ausführung auswirken. Wird z. B. in einer Banking-App, in der das aktuelle Kontoguthaben in einer Ledgertabelle gespeichert wird, der aktuelle Zustand der Tabelle geändert, kann dies für weitere Transaktionen schwerwiegende Folgen haben, da neue Transaktionen möglicherweise zu Kontoüberschreitungen führen können.
Wurde der Datenbankledger manipuliert, müssen die Hashwerte von Blöcken für die interne Konsistenz neu berechnet werden (bis zur Überprüfung anhand externer Datenbankdigests) und anschließend neue Transaktionen und Datenbankdigests für ungültige Hashwerte generiert werden. Dies führt zu einer Verzweigung im Ledger, da die neuen generierten Datenbankdigests einem ungültigen Zustand zugeordnet werden und sämtliche Datenbankdigests auch dann dauerhaft ungültig sind, wenn Sie den Ledger mithilfe früherer Sicherungen reparieren. Zudem können Sie Details aus dem fehlerhaften Ledger zu den Transaktionen nach der Manipulation erst wieder trauen, wenn Sie diese überprüft haben. Sie können die Auswirkungen der Manipulation auf folgende Weise rückgängig machen:
- Wiederherstellen des Zustands manipulierter Transaktionen mithilfe von Sicherungen.
- Überprüfen des Ledgers ab der letzten Transaktion, die von der Sicherung wiederhergestellt wurde, bis zum Ende. Verwenden Sie hierzu die Datenbankdigests aus dem verzweigten Teil der Kette. Obwohl die Datenbank-Digests nicht mit dem ursprünglichen Teil des Ledgers übereinstimmen, kann trotzdem überprüft werden, ob der verzweigte Teil des Ledgers manipuliert wurde. Werden auch dort Manipulationen entdeckt, bedeutet dies, dass weitere Manipulationsereignisse aufgetreten sind und der Prozess rekursiv angewendet werden muss, um die unterschiedlichen Teile des Ledgers aus Sicherungen wiederherzustellen.
- Reparieren Sie die Tabellenledger manuell, indem Sie die Informationen für die überprüften Transaktionen neu einfügen und die Hashwerte für diese neuen Transaktionen, die nach dem ersten Manipulationsereignis im Datenbankledger aufgetreten sind, neu berechnen.