Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server 2022 (16.x) und höhere Versionen von Azure SQL-DatenbankAzure SQL Managed Instance
Wie kann nach einer Manipulation die Wiederherstellung erfolgen?
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. Der späteste Zeitpunkt, der erfolgreich überprüft werden kann, ist derjenige, bei dem garantiert ist, dass er nicht manipuliert wurde und zur Fortsetzung der Transaktionsverarbeitung verwendet werden kann. 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. Sie sollten zwei Kategorien von Manipulationsereignissen berücksichtigen.
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 zum Beispiel eine Hauptbuchtabelle verwenden, um Banktransaktionsdetails zu speichern, beeinflusst das Manipulieren bestehender Transaktionen keine neuen Transaktionen, die über die aktuellen Salden hinweg wirken.
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. Das Datenbank-Ledger ist in einem konsistenten Zustand, alle Datenbank-Digests wurden erzeugt, und alle neu daran angehängten Transaktionen wurden unter Verwendung der gültigen Hashes vorheriger Transaktionen gehasht. 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.
Manipulation betraf Daten, die in Nachfolgetransaktionen verwendet 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.
Wenn der Angreifer das Datenbank-Ledger manipuliert und die Hashwerte der Blöcke neu berechnet hat, um es intern konsistent zu machen (bis es mit externen Datenbank-Digests abgeglichen wird), werden anschließend neue Transaktionen und Datenbank-Digests auf Grundlage ungültiger Hashwerte erzeugt. Dies führt zu einem Fork im Ledger, da die neu erzeugten Datenbank-Digests auf einen ungültigen Zustand verweisen, und selbst wenn Sie den Ledger mithilfe früherer Sicherungen reparieren, bleiben all diese Datenbank-Digests dauerhaft ungültig. Zudem können Sie den Angaben zu den Transaktionen, die nach der Manipulation stattgefunden haben, nicht trauen, bis Sie diese verifiziert haben, da der Datenbankledger beschädigt ist. Darauf basierend kann die Manipulation möglicherweise wie folgt rückgängig gemacht werden:
- Wiederherstellen des Zustands manipulierter Transaktionen mithilfe von Sicherungen.
- Überprüfen des Teils des Ledgers nach der letzten durch die Sicherung wiederhergestellten Transaktion und bis zum Ende des Ledgers. Dazu müssen Sie die Datenbank-Digests aus dem abgezweigten Teil der Kette verwenden. Obwohl die Datenbank-Digests nicht mit dem ursprünglichen Teil des Ledgers übereinstimmen, kann dennoch verifiziert werden, dass der abgespaltene Teil des Ledgers nicht manipuliert worden ist. 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.