Pulihkan database ledger setelah diubah

  • Artikel

Berlaku untuk: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

Bagaimana cara memulihkan setelah perubahan terjadi?

Cara paling mudah untuk memperbaiki segala jenis perusakan adalah dengan memulihkan database ke cadangan terbaru yang dapat diverifikasi. Untuk mencapainya, Anda dapat memulihkan database ke titik waktu yang berbeda dan memverifikasi ledger menggunakan hash database sebelumnya. Titik waktu terbaru yang berhasil diverifikasi adalah titik waktu terbaru yang dijamin tidak akan dirusak dan dapat digunakan untuk melanjutkan pemrosesan transaksi. Untuk alasan ini, sangat penting bagi pencadangan agar cukup sering untuk mendekat sedekat mungkin dengan waktu perubahan. Penjadwalan cadangan secara otomatis dilakukan untuk Azure SQL Database. Meskipun teknik ini sederhana, ini memiliki peringatan penting: jika ada transaksi yang dijalankan setelah perubahan terjadi, Anda perlu menerima bahwa transaksi ini akan hilang atau mereka perlu memperbaiki tabel ledger secara manual dengan memasukkan kembali informasi untuk transaksi terverifikasi dan merekomputasi hash untuk transaksi baru ini yang terjadi setelah peristiwa perusakan pertama dalam ledger database.

Kategori perubah

Tergantung pada jenis perubahan, ada kasus di mana Anda dapat memperbaiki ledger tanpa kehilangan data. Anda harus mempertimbangkan dua kategori peristiwa yang merusak.

Perubahan tidak memengaruhi transaksi lebih lanjut

Peristiwa perubahan memodifikasi beberapa data yang disimpan di ledger tetapi tidak memengaruhi transaksi lebih lanjut. Ini mungkin karena serangan terdeteksi sebelum transaksi apa pun akan beroperasi atas data yang diubah atau karena serangan hanya memengaruhi data dengan cara yang tidak memengaruhi transaksi baru. Misalnya, jika Anda menggunakan tabel ledger untuk menyimpan detail transaksi perbankan, mengubah detail transaksi yang ada tidak berdampak pada transaksi baru, yang akan bekerja atas saldo saat ini.

Karena perubahan tidak memengaruhi transaksi apa pun yang terjadi setelah peristiwa perusakan, eksekusi transaksi baru dan hasil yang dihasilkan sudah benar. Berdasarkan itu, idealnya Anda harus membawa ledger ke keadaan yang konsisten tanpa memengaruhi transaksi ini.

Jika penyerang tidak mengubah ledger tingkat database, ini mudah dideteksi dan diperbaiki. Ledger database dalam keadaan konsisten dengan semua hash database yang dihasilkan, dan setiap transaksi baru yang ditambahkan ke telah di-hash menggunakan hash yang valid dari transaksi sebelumnya. Berdasarkan itu, setiap hash database yang dihasilkan, bahkan untuk transaksi setelah perubahan terjadi, masih valid. Anda dapat mencoba mengambil payload ledger tabel yang benar untuk transaksi yang diubah dari cadangan yang masih dapat divalidasi agar aman (menggunakan validasi ledger pada mereka) dan memperbaiki database operasional dengan menimpa data yang diubah dalam ledger tabel. Ini akan membuat transaksi baru yang mencatat transaksi perbaikan.

Mengubah data yang terpengaruh yang digunakan oleh transaksi lebih lanjut

Peristiwa perusakan memengaruhi data yang kemudian digunakan oleh transaksi lebih lanjut, oleh karena itu memengaruhi eksekusinya. Misalnya, dalam aplikasi perbankan di mana saldo rekening saat ini disimpan dalam tabel ledger, memodifikasi status tabel saat ini dapat menjadi bencana untuk transaksi lebih lanjut karena dapat memungkinkan transaksi baru untuk overspend.

Jika penyerang mengubah ledger database, merekomputasi hash blok untuk membuatnya konsisten secara internal (sampai diverifikasi terhadap hash database eksternal), maka transaksi baru dan hash database akan dihasilkan melalui hash yang tidak valid. Ini mengarah ke fork dalam ledger, karena hash database baru yang dihasilkan peta ke status tidak valid dan bahkan jika Anda memperbaiki ledger dengan menggunakan cadangan sebelumnya, semua hash database ini secara permanen tidak valid. Selain itu, karena ledger database rusak, Anda tidak dapat mempercayai detail tentang transaksi yang terjadi setelah perubahan hingga Anda memverifikasinya. Berdasarkan itu, perubahan dapat berpotensi dikembalikan dengan:

  1. Menggunakan cadangan untuk memulihkan status untuk transaksi yang dirusak.
  2. Memverifikasi bagian ledger setelah transaksi terakhir dipulihkan oleh cadangan dan sampai akhir ledger. Untuk ini, Anda harus menggunakan hash database dari bagian bercakar dari rantai. Meskipun hash database tidak cocok dengan bagian asli ledger, database masih dapat memverifikasi bagian fork ledger belum dirusak. Jika ini juga menunjukkan perubahan, ini berarti bahwa telah ada lebih dari satu peristiwa yang merusak dan prosesnya perlu diterapkan secara rekursif untuk memulihkan berbagai bagian ledger dari cadangan.
  3. Perbaiki ledger tabel secara manual dengan memasukkan kembali informasi untuk transaksi terverifikasi dan komputasi ulang hash untuk transaksi baru ini yang terjadi setelah peristiwa perusakan pertama di ledger database.

Konten terkait