Menyimpan data blob penting bisnis dengan penyimpanan yang tidak dapat diubah dalam status tulis sekali, baca banyak (WORM)
Penyimpanan yang tidak dapat diubah untuk Azure Blob Storage memungkinkan pengguna untuk menyimpan data yang penting bagi perusahaan dalam status WORM (Tulis Sekali, Baca Banyak). Saat dalam kondisi CACING, data tidak dapat diubah ataupun dihapus untuk interval yang ditentukan pengguna. Dengan mengonfigurasi kebijakan yang tidak bisa diubah untuk data blob, Anda dapat melindungi data Anda dari penimpaan dan penghapusan.
Penyimpanan yang tidak dapat diubah untuk Azure Blob Storage mendukung dua jenis kebijakan yang tidak dapat diubah:
Kebijakan penyimpanan berbasis waktu: Dengan kebijakan retensi berbasis waktu, pengguna dapat menetapkan kebijakan untuk menyimpan data selama interval tertentu. Ketika kebijakan penyimpanan berbasis waktu ditetapkan, blob dapat dibuat dan dibaca, tetapi tidak dimodifikasi atau dihapus. Setelah periode retensi berakhir, blob dapat dihapus tetapi tidak diganti.
Kebijakan pengamanan hukum: Pengamanan hukum menyimpan data yang tidak dapat diubah sampai pengamanan hukum tersebut secara eksplisit dihapus. Ketika pengamanan hukum ditetapkan, maka blob dapat dibuat dan dibaca, tetapi tidak dimodifikasi atau dihapus.
Kebijakan ini dapat diatur secara bersamaan satu sama lain. Misalnya, pengguna dapat memiliki kebijakan penyimpanan berbasis waktu dan penahanan legal yang ditetapkan pada tingkat yang sama dan pada saat yang sama. Agar penulisan berhasil, Anda harus mengaktifkan penerapan versi atau tidak memiliki kebijakan penahanan legal atau penyimpanan berbasis waktu pada data. Agar penghapusan berhasil, tidak boleh ada kebijakan penahanan legal atau penyimpanan berbasis waktu pada data juga.
Diagram berikut menunjukkan bagaimana kebijakan penyimpanan berbasis waktu dan penahanan legal mencegah operasi tulis dan hapus saat berlaku.
Ada dua fitur di bawah payung penyimpanan yang tidak dapat diubah: WORM tingkat kontainer dan WORM tingkat versi. WORM tingkat kontainer memungkinkan kebijakan diatur pada tingkat kontainer saja, sementara WORM tingkat versi memungkinkan kebijakan diatur pada tingkat akun, kontainer, atau versi.
Tentang penyimpanan yang tidak berubah untuk blob
Penyimpanan yang tidak dapat diubah membantu organisasi layanan kesehatan, lembaga keuangan, dan industri terkait—terutama organisasi broker-dealer—untuk menyimpan data dengan aman. Penyimpanan yang tidak dapat diubah dapat digunakan dalam skenario apa pun untuk melindungi data penting dari modifikasi atau penghapusan.
Aplikasi umum meliputi:
Kepatuhan terhadap peraturan: Penyimpanan yang tidak dapat diubah untuk Azure Blob Storage membantu organisasi mengatasi SEC 17a-4(f), CFTC 1.31(d), FINRA, dan peraturan lainnya.
Retensi dokumen yang aman: Penyimpanan yang tidak dapat diubah untuk penyimpanan Blob Azure memastikan bahwa data tidak dapat dimodifikasi atau dihapus oleh pengguna mana pun, termasuk pengguna dengan hak istimewa administratif akun.
Pengamanan hukum: Penyimpanan yang tidak dapat diubah untuk penyimpanan Blob Azure memungkinkan pengguna untuk menyimpan informasi sensitif yang penting untuk urusan hukum atau bisnis dalam keadaan anti-perusakan selama durasi yang diinginkan hingga pengamanan tersebut dihapus. Fitur ini tidak terbatas hanya pada kasus penggunaan hukum tetapi juga dapat dianggap sebagai penangguhan berbasis peristiwa atau kunci perusahaan, di mana kebutuhan untuk melindungi data berdasarkan pemicu peristiwa atau kebijakan perusahaan diperlukan.
Kepatuhan peraturan
Microsoft mengandalkan jasa kantor penilaian independen terkemuka yang sangat ahli dalam manajemen rekaman dan tata kelola informasi, Cohasset Associates, untuk mengevaluasi penyimpanan Blob yang tidak dapat diubah dan kepatuhannya terhadap persyaratan khusus untuk industri jasa keuangan. Cohasset memvalidasi penyimpanan yang tidak dapat diubah, ketika digunakan untuk menyimpan Blob dalam status WORM, memenuhi persyaratan penyimpanan yang relevan dari CFTC Ruke 1.31(c)-(d), FINRA Rule 4511, dan SEC Rule 17a-4(f). Microsoft menargetkan set aturan ini, karena mewakili panduan paling preskriptif secara global untuk retensi rekaman bagi lembaga keuangan.
Laporan Cohasset tersedia di Pusat Kepercayaan Layanan Microsoft. Azure Trust Center berisi informasi detail tentang sertifikasi kepatuhan Microsoft. Untuk meminta surat pengesahan dari Microsoft mengenai kepatuhan kekekalan WORM, silakan hubungi Dukungan Azure.
Kebijakan penyimpanan berbasis waktu
Kebijakan penyimpanan berbasis waktu menyimpan data blob dalam format WORM untuk interval tertentu. Ketika kebijakan penyimpanan berbasis waktu telah diatur, klien dapat membuat dan membaca blob, tetapi tidak dapat mengubah atau menghapusnya. Setelah interval retensi kedaluwarsa, blob dapat dihapus tetapi tidak ditimpa.
Cakupan
Kebijakan penyimpanan berbasis waktu dapat dikonfigurasi pada cakupan berikut:
- Kebijakan WORM tingkat versi: Kebijakan penyimpanan berbasis waktu dapat dikonfigurasi di tingkat akun, kontainer, atau versi. Jika dikonfigurasi pada tingkat akun atau kontainer, itu akan diwariskan oleh semua blob di akun atau kontainer masing-masing.
- Kebijakan WORM tingkat kontainer: Kebijakan penyimpanan berbasis waktu yang dikonfigurasi pada tingkat kontainer berlaku untuk semua blob dalam kontainer tersebut. Blob individual tidak dapat dikonfigurasi dengan kebijakan imutabilitasnya sendiri.
Interval retensi untuk kebijakan berbasis waktu
Interval retensi minimum untuk kebijakan penyimpanan berbasis waktu adalah satu hari, sedangkan maksimumnya adalah 146.000 hari (400 tahun). Saat Anda mengonfigurasi kebijakan penyimpanan berbasis waktu, objek yang terpengaruh tetap dalam status tidak dapat diubah selama periode retensi yang efektif. Periode retensi yang berlaku untuk objek sama dengan selisih waktu pembuatan blob dan interval retensi yang ditentukan pengguna. Karena interval retensi kebijakan dapat diperpanjang, penyimpanan yang tidak dapat diubah menggunakan nilai terbaru dari interval retensi yang ditentukan pengguna untuk menghitung periode retensi yang berlaku.
Contohnya, misalkan pengguna membuat kebijakan penyimpanan berbasis waktu dengan interval penyimpanan lima tahun. Blob yang ada dalam kontainer tersebut, testblob1, dibuat satu tahun yang lalu, sehingga periode retensi yang berlaku untuk testblob1 adalah empat tahun. Jika blob baru, testblob2, diunggah ke kontainer, maka periode retensi yang berlaku untuk testblob2 adalah lima tahun sejak waktu pembuatannya.
Kebijakan terkunci versus tidak terkunci
Saat pertama kali mengonfigurasi kebijakan penyimpanan berbasis waktu, kebijakan tersebut tidak terkunci untuk tujuan pengujian. Setelah selesai menguji, Anda dapat mengunci kebijakan sehingga sepenuhnya mematuhi SEC 17a-4(f) dan kepatuhan peraturan lainnya.
Kebijakan terkunci dan tidak terkunci melindungi terhadap penghapusan dan penimpaan. Namun, Anda dapat mengubah kebijakan tidak terkunci dengan mempersingkat atau memperpanjang periode retensi. Anda juga dapat menghapus kebijakan yang tidak terkunci. Anda tidak dapat menghapus kebijakan penyimpanan berbasis waktu yang terkunci. Anda dapat memperpanjang periode retensi, tetapi tidak dapat menguranginya. Maksimal lima peningkatan ke periode retensi yang berlaku diperbolehkan selama masa kebijakan terkunci yang ditentukan di tingkat kontainer. Untuk kebijakan yang dikonfigurasi untuk versi blob, tidak ada batasan jumlah peningkatan ke periode efektif.
Penting
kebijakan penyimpanan berbasis waktu harus dikunci agar blob berada dalam status yang tidak dapat diubah (dilindungi dari penulisan dan penghapusan) yang sesuai untuk SEC 17a-4(f) dan kepatuhan peraturan lainnya. Microsoft menyarankan agar Anda mengunci kebijakan dalam waktu yang wajar, biasanya kurang dari 24 jam. Meskipun status tidak dikunci memberikan perlindungan imutabilitas, penggunaan status tidak dikunci untuk tujuan apa pun selain uji coba fitur jangka pendek tidak disarankan.
Pengelogan audit kebijakan penyimpanan
Setiap kontainer dengan kebijakan retensi berbasis waktu yang diaktifkan menyediakan log audit kebijakan. Log audit mencakup hingga tujuh perintah retensi berbasis waktu untuk kebijakan retensi berbasis waktu yang terkunci. Pengelogan biasanya dimulai setelah Anda mengunci kebijakan. Entri log berisi ID pengguna, jenis perintah, tanda waktu, dan interval retensi. Log audit dipertahankan untuk masa pakai kebijakan sesuai dengan pedoman peraturan SEC 17a-4(f).
Log Azure Activity menyediakan log yang lebih komprehensif dari semua aktivitas layanan pengelolaan. Log sumber daya Azure menyimpan informasi operasi data. Merupakan tanggung jawab pengguna untuk menyimpan log tersebut secara terus-menerus, karena mungkin diperlukan untuk tujuan terkait peraturan atau lainnya.
Perubahan ke kebijakan retensi berbasis waktu di tingkat versi tidak diaudit.
Pengamanan hukum
Penahanan hukum adalah kebijakan imutabilitas sementara yang dapat diterapkan untuk tujuan penyelidikan hukum atau kebijakan perlindungan umum. Penahanan legal menyimpan data blob dalam format Write-Once, Read-Many (WORM) hingga penangguhan dihapus secara eksplisit. Ketika penahanan legal berjalan, blob dapat dibuat dan dibaca, tetapi tidak dapat dimodifikasi atau dihapus. Gunakan penahanan legal ketika periode waktu data harus disimpan dalam keadaan WORM tidak diketahui.
Cakupan
Kebijakan penahanan legal dapat dikonfigurasi di salah satu cakupan berikut:
Kebijakan WORM tingkat versi: Penahanan legal dapat dikonfigurasi pada tingkat versi blob individual untuk manajemen terperinci data sensitif.
Kebijakan WORM tingkat kontainer: Penahanan legal yang dikonfigurasi di tingkat kontainer berlaku untuk semua blob dalam kontainer tersebut. Blob individual tidak dapat dikonfigurasi dengan kebijakan imutabilitasnya sendiri.
Tag
Penahanan legal tingkat kontainer harus dikaitkan dengan satu atau lebih tag alfanumerik yang ditentukan pengguna yang berfungsi sebagai string pengenal. Misalnya, tag dapat menyertakan ID kasus atau nama acara.
Penglogan Audit
Setiap kontainer dengan penahanan legal yang berlaku memberikan log audit kebijakan. Log berisi ID pengguna, jenis perintah, stempel waktu, dan tag penahanan legal. Log audit dipertahankan untuk masa pakai kebijakan sesuai dengan pedoman peraturan SEC 17a-4(f).
Log Azure Activity menyediakan log yang lebih komprehensif dari semua aktivitas layanan pengelolaan. Log sumber daya Azure menyimpan informasi operasi data. Merupakan tanggung jawab pengguna untuk menyimpan log tersebut secara terus-menerus, karena mungkin diperlukan untuk tujuan terkait peraturan atau lainnya.
Perubahan pada penahanan legal di tingkat versi tidak diaudit.
Opsi fitur penyimpanan yang tidak dapat diubah
Tabel berikut menunjukkan perincian perbedaan antara WORM tingkat kontainer dan WORM tingkat versi:
| Kategori | WORM tingkat kontainer | WORM tingkat versi |
|---|---|---|
| Tingkat granularitas kebijakan | Kebijakan hanya dapat dikonfigurasi di tingkat kontainer. Setiap objek yang diunggah ke dalam kontainer mewarisi kumpulan kebijakan yang tidak dapat diubah. | Kebijakan dapat dikonfigurasi di tingkat akun, kontainer, atau blob. Jika kebijakan ditetapkan di tingkat akun, semua blob yang diunggah ke akun tersebut mewarisi kebijakan. Logika yang sama mengikuti kontainer. Jika kebijakan diatur pada beberapa tingkat, urutan prioritas selalu Blob -> Kontainer -> Akun. |
| Jenis kebijakan yang tersedia | Dua jenis kebijakan yang berbeda dapat ditetapkan di tingkat kontainer: Kebijakan penyimpanan berbasis waktu dan penahanan hukum. | Pada tingkat akun dan kontainer, hanya kebijakan retensi berbasis waktu yang dapat diatur. Pada tingkat blob, kebijakan penyimpanan berbasis waktu dan penahanan legal dapat ditetapkan. |
| Dependensi fitur | Tidak ada fitur lain yang merupakan prasyarat atau persyaratan agar fitur ini berfungsi. | Penerapan versi adalah prasyarat untuk fitur ini yang akan digunakan. |
| Pengaktifan untuk akun/kontainer yang ada | Fitur ini dapat diaktifkan kapan saja untuk kontainer yang ada. | Bergantung pada tingkat granularitas, fitur ini mungkin tidak diaktifkan untuk semua akun/kontainer yang ada. |
| Penghapusan akun/kontainer | Setelah kebijakan penyimpanan berbasis waktu dikunci pada kontainer, kontainer hanya dapat dihapus jika kosong. | Setelah WORM tingkat versi diaktifkan pada tingkat akun atau kontainer, WORM hanya dapat dihapus jika kosong. |
| Dukungan untuk Azure Data Lake Storage Gen2 (akun penyimpanan yang mengaktifkan namespace hierarkis) | Kebijakan WORM tingkat kontainer didukung di akun yang memiliki namespace hierarkis. | Kebijakan WORM tingkat versi belum didukung di akun yang memiliki namespace hierarkis. |
Untuk mempelajari selengkapnya tentang WORM tingkat kontainer, lihat Kebijakan WORM Tingkat Kontainer. Untuk mempelajari lebih lanjut tentang WORM tingkat versi, silakan kunjungi kebijakan WORM Tingkat versi.
Tingkat kontainer vs WORM tingkat versi
Tabel berikut membantu Anda memutuskan jenis kebijakan WORM mana yang akan digunakan.
| Kriteria | Penggunaan WORM tingkat kontainer | Penggunaan WORM tingkat versi |
|---|---|---|
| Organisasi data | Anda ingin mengatur kebijakan untuk himpunan data tertentu, yang dapat dikategorikan berdasarkan kontainer. Semua data dalam kontainer tersebut perlu disimpan dalam keadaan WORM untuk jumlah waktu yang sama. | Anda tidak dapat mengelompokkan objek berdasarkan periode retensi. Semua blob harus disimpan dengan waktu retensi individual berdasarkan skenario blob tersebut, atau pengguna memiliki beban kerja campuran sehingga beberapa grup data dapat diklusterkan ke dalam kontainer sementara blob lain tidak dapat. Anda mungkin juga ingin mengatur kebijakan tingkat kontainer dan kebijakan tingkat blob dalam akun yang sama. |
| Jumlah data yang memerlukan kebijakan yang tidak dapat diubah | Anda tidak perlu menetapkan kebijakan pada lebih dari 10.000 kontainer per akun. | Anda ingin menetapkan kebijakan pada semua data atau data dalam jumlah besar yang dapat diurai oleh akun. Anda tahu bahwa jika Anda menggunakan WORM tingkat kontainer, Anda harus melebihi batas 10.000 kontainer. |
| Minat untuk mengaktifkan penerapan versi | Anda tidak ingin berurusan dengan mengaktifkan penerapan versi baik karena biaya, atau karena beban kerja akan membuat banyak versi tambahan untuk ditangani. | Anda ingin menggunakan penerapan versi, atau tidak keberatan menggunakannya. Anda tahu bahwa jika mereka tidak mengaktifkan penerapan versi, Anda tidak dapat terus mengedit atau menimpa blob yang tidak dapat diubah sebagai versi terpisah. |
| Lokasi penyimpanan (Blob Storage vs Data Lake Storage Gen2) | Beban kerja Anda sepenuhnya berfokus pada Azure Data Lake Storage Gen2. Anda tidak memiliki minat atau paket langsung untuk beralih menggunakan akun yang tidak mengaktifkan fitur namespace hierarkis. | Beban kerja Anda ada di Blob Storage di akun yang tidak mengaktifkan fitur namespace hierarkis, dan dapat menggunakan WORM tingkat versi sekarang, atau Anda bersedia menunggu penerapan versi tersedia untuk akun yang mengaktifkan namespace hierarkis (Azure Data Lake Storage Gen2). |
Tingkat akses
Semua tingkatan akses blob mendukung penyimpanan yang tidak dapat diubah. Anda dapat mengubah tingkat akses blob dengan operasi Penetapan Tingkat Blob. Untuk informasi selengkapnya, lihat Tingkat akses untuk data blob.
Konfigurasi redundansi
Semua konfigurasi redundansi mendukung penyimpanan yang tidak dapat diubah. Untuk informasi selengkapnya tentang konfigurasi redundansi, lihat Redundansi Azure Storage.
Jenis blob yang direkomendasikan
Microsoft merekomendasikan agar Anda mengonfigurasi kebijakan kekekalan terutama untuk blob blok dan blob tambahan. Mengonfigurasi kebijakan kekekalan untuk blob halaman yang menyimpan disk VHD untuk komputer virtual aktif tidak disarankan karena penulisan ke disk akan diblokir, atau jika penerapan versi diaktifkan, setiap penulisan disimpan sebagai versi baru. Microsoft menyarankan agar Anda meninjau dokumentasi secara menyeluruh dan menguji skenario Anda sebelum mengunci kebijakan berbasis waktu. Microsoft menyarankan agar Anda meninjau dokumentasi secara menyeluruh dan menguji skenario Anda sebelum mengunci kebijakan berbasis waktu.
Penyimpanan yang tidak dapat diubah dengan penghapusan sementara blob
Ketika penghapusan sementara blob dikonfigurasi untuk akun penyimpanan, kebijakan itu berlaku untuk semua blob dalam akun terlepas dari apakah pengamanan hukum atau kebijakan retensi berbasis waktu berlaku. Microsoft merekomendasikan untuk mengaktifkan penghapusan sementara untuk perlindungan tambahan sebelum kebijakan imutabilitas diterapkan.
Jika Anda mengaktifkan penghapusan sementara blob lalu mengonfigurasi kebijakan kekekalan, blob apa pun yang telah dihapus sementara akan dihapus secara permanen setelah kebijakan penyimpanan penghapusan sementara kedaluwarsa. Blob yang dihapus sementara dapat dipulihkan selama periode retensi penghapusan sementara. Blob atau versi yang belum dihapus sementara dilindungi oleh kebijakan kekekalan dan tidak dapat dihapus sementara sampai setelah kebijakan penyimpanan berbasis waktu kedaluwarsa atau penahanan legal dihapus.
Gunakan inventaris blob untuk melacak kebijakan kekekalan
Inventaris blob Azure Storage memberikan gambaran umum tentang kontainer di akun penyimpanan Anda dan blob, rekam jepret, dan versi blob di dalamnya. Anda dapat menggunakan laporan inventaris blob untuk memahami atribut blob dan kontainer, termasuk apakah sumber daya memiliki kebijakan kekekalan yang telah dikonfigurasi.
Saat Anda mengaktifkan inventarit blob, Azure Storage menghasilkan laporan inventori setiap hari. Laporan ini memberikan ringkasan tentang data Anda untuk persyaratan bisnis dan kepatuhan.
Untuk informasi selengkapnya tentang inventaris blob, lihat inventaris blob Azure Storage.
Catatan
Anda tidak dapat mengonfigurasi kebijakan inventori di akun jika dukungan untuk kekekalan tingkat versi diaktifkan pada akun tersebut, atau jika dukungan untuk imutabilitas tingkat versi diaktifkan pada kontainer tujuan yang ditentukan dalam kebijakan inventori.
Harga
Tidak ada biaya kapasitas tambahan untuk menggunakan penyimpanan yang tidak dapat diubah. Data yang tidak dapat diubah dihargai dengan cara yang sama seperti data yang dapat diubah. Jika Anda menggunakan WORM tingkat versi, tagihan mungkin lebih tinggi karena Anda telah mengaktifkan penerapan versi, dan ada biaya yang terkait dengan versi tambahan yang disimpan. Tinjau kebijakan harga penerapan versi untuk informasi selengkapnya. Untuk detail harga Azure Blob Storage, lihat Halaman harga Azure Storage.
Membuat, memodifikasi, atau menghapus kebijakan retensi berbasis waktu atau pengamanan hukum pada versi blob menimbulkan biaya transaksi tulis.
Jika Anda gagal membayar tagihan dan akun Anda memiliki kebijakan penyimpanan berbasis waktu aktif yang berlaku, kebijakan penyimpanan data normal berlaku sebagaimana diatur dalam syarat dan ketentuan kontrak Anda dengan Microsoft. Untuk informasi umum, lihat Manajemen data di Microsoft.
Dukungan fitur
Fitur ini tidak kompatibel dengan pemulihan titik waktu dan pelacakan akses terakhir. Kebijakan kekekalan tidak didukung di akun yang mengaktifkan protokol Network File System (NFS) 3.0 atau Protokol Transfer File SSH (SFTP).
Beberapa beban kerja, seperti Cadangan SQL ke URL, membuat blob lalu menambahkannya. Jika kontainer memiliki kebijakan penyimpanan berbasis waktu aktif atau penahanan legal, pola ini tidak akan berhasil. Lihat Izinkan penulisan blob tambahan yang dilindungi untuk detail selengkapnya.
Untuk informasi selengkapnya, lihat Dukungan fitur Blob Storage di akun Azure Storage.