Saya telah mengikuti pengenalan snapshot immutable di QuTS hero 6.0 dengan sangat antusias dan baru-baru ini membaca sebuah artikel Jepang yang menguji fitur ini secara detail (Yukihito Hara, LinkedIn Japan), yang menunjukkan bahwa snapshot immutable tidak dapat dihapus bahkan melalui SSH atau dengan hak akses root.
Berdasarkan hal tersebut, saya berasumsi bahwa snapshot immutable dimaksudkan untuk melindungi data tidak hanya dari penghapusan yang tidak disengaja, tetapi juga dari tindakan berbahaya atau tidak sah yang dilakukan melalui akun administrator yang telah dikompromikan (misalnya dalam skenario ransomware).
Namun, hal ini menimbulkan pertanyaan konseptual yang penting:
Apakah administrator masih dapat menghapus seluruh storage pool yang berisi snapshot immutable?
Jika ya, bukankah ini secara efektif melemahkan konsep immutability, karena menghapus pool akan menghapus semua volume dan snapshot terlepas dari kebijakan perlindungannya?
Untuk memperjelas:
Saya sepenuhnya memahami bahwa kerusakan fisik pada perangkat keras atau melepas disk tidak dapat dicegah jika seseorang memiliki akses fisik. Itu bukan yang saya tanyakan.
Pertanyaan saya murni tentang perlindungan logis di dalam OS:
Snapshot immutable dilindungi dari penghapusan, bahkan oleh root.
Namun, apakah ada (atau akan ada) perlindungan di level storage pool yang mencegah penghapusan pool secara tidak sengaja atau berbahaya saat snapshot immutable masih berada dalam periode retensinya?
Atau dengan kata lain:
Apakah desain saat ini memang sengaja dibatasi hanya pada perlindungan di level snapshot/volume?
Atau apakah ada rencana untuk memperluas jaminan immutability agar juga mencegah tindakan destruktif di level pool?
Saya sangat menghargai klarifikasi mengenai model ancaman dan tujuan desain yang dimaksudkan di sini.
Terima kasih banyak atas waktu Anda dan untuk fitur baru yang penting ini.
Selamat datang di komunitas. Saya sendiri belum menjalankan hero 6, tapi berikut pendapat saya tentang hal ini.
Tidak ada "perlindungan" untuk menghancurkan atau mengubah storage pool. Imutabilitas WORM (Write Once Read Many) diatur pada level shared folder atau, dalam kasus hero 6, juga pada level snapshot. Dalam pengaturan WORM, tidak setiap folder diatur menjadi immutable (tidak dapat diubah). Anda memang tidak menginginkannya seperti itu. Jika iya, Anda tidak akan pernah bisa menghapus atau mengubah apa pun di NAS.
Selain itu, imutabilitas bisa dibatasi dalam waktu tertentu. Jadi Anda bisa memiliki folder di mana file akan tetap terkunci misalnya selama 5 hari setelah ditulis. Setelah itu, kuncinya akan hilang. Pengaturan lain memungkinkan semuanya tetap terkunci secara permanen.
Saya tidak melihat alasan mengapa Anda ingin imutabilitas pada level storage pool. Itu akan mencegah Anda menambah ruang ke storage pool, dan sebagainya.
WORM membantu melindungi file dari serangan ransomware. File tidak bisa diubah. Sebagian besar waktu, para penjahat yang berhasil masuk ke NAS Anda ingin menginfeksi file Anda agar mereka bisa memeras Anda. Mereka tidak akan meluangkan waktu untuk menghapus pool Anda dan menghancurkannya. Jika mereka melakukannya, berarti semua file telah terhapus dan mereka tidak punya apa-apa lagi untuk dijadikan sandera! Jadi itu bertentangan dengan pola pikir mereka. Selain itu, hal seperti ini biasanya dirancang untuk menyebar dengan cepat—masuk ke sistem, sebarkan malware, lalu keluar. Menghapus pool akan membutuhkan lebih banyak usaha dan kerja.
Jadi, ini adalah pendapat saya dan tidak boleh dianggap sebagai sesuatu yang "resmi."
Terima kasih banyak atas masukan berharga Anda! Terkait masalah yang Anda sampaikan, kami akan meneruskannya kepada tim internal kami untuk evaluasi dan analisis lebih lanjut.
Hai NA9D. Terima kasih atas balasan Anda terkait pertanyaan saya.
Mungkin untuk memperjelas: Saya hanya sedikit bingung mengenai logika internal dari konsep snapshot yang immutable (tidak dapat diubah). Sejauh yang saya pahami, jika Anda mendefinisikan satu unit kecil dari sistem sebagai “harus immutable - bahkan terhadap aksi admin yang telah dikompromikan - untuk memberikan perlindungan non-fisik maksimum”, maka hal ini harus direplikasi ke seluruh hierarki (misalnya pada level storage pool) atau jika tidak, sifat immutable tersebut akan terganggu. Bagi saya, ini berarti implementasinya seharusnya menerapkan pengecekan pada aksi-aksi kritis di storage pool dalam arti “hapus hanya diizinkan jika saat ini tidak ada file immutable yang tersimpan”.
Terkait pertanyaan tentang vektor serangan yang relevan: Saya setuju dengan Anda, bahwa sebagian besar serangan tidak akan ingin menghapus file karena logika pemerasan yang ingin dicapai. Namun, pertimbangkan fakta bahwa penyerang yang canggih dengan akses bisa saja menyalin file ke infrastrukturnya sebelum menghapus dan menggunakan logika “bayar atau file Anda hilang selamanya” yang sama untuk memeras.
Saya mengerti apa yang Anda maksud. Tapi saya tidak ingin sistem yang tidak dapat diubah di mana saya tidak pernah bisa mengatur ulang storage pool saya. Maksud saya, itu berarti begitu Anda mengatur semuanya, semuanya sudah permanen dan tidak ada cara untuk mengubahnya lagi. Itu berarti Anda tidak bisa memperluas pool, menghapus pool karena ingin memindahkan data ke pool baru yang lebih besar, dan sebagainya. Ada banyak masalah dengan apa yang Anda usulkan. File yang tidak dapat diubah saja sudah cukup merepotkan. Saya pernah secara tidak sengaja menyalin beberapa file ke folder yang bersifat immutable ketika saya ingin menaruhnya di sub-folder. Nah, sekarang saya punya dua salinan file, salah satunya berada di tempat yang tidak saya inginkan. Bagaimana jika Anda secara tidak sengaja melakukan hal itu pada sebuah pool?
Saya sangat meragukan ada aktor jahat yang mau meluangkan waktu untuk menyalin sekumpulan file besar ke infrastruktur mereka mengingat waktu yang dibutuhkan untuk transfer. Dan sekalipun mereka melakukannya, itu pun tidak terlalu berguna, apalagi jika NAS memiliki strategi backup yang tepat.