Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 WORM, 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, objek 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, objek 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 data
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 memastikan bahwa data tidak dapat dimodifikasi atau dihapus oleh pengguna mana pun, termasuk pengguna dengan hak administratif akun.
Pengamanan hukum: Penyimpanan yang tidak dapat diubah untuk blob memungkinkan pengguna menyimpan informasi sensitif yang penting untuk urusan hukum atau bisnis dalam keadaan tidak dapat dirusak selama jangka waktu yang diinginkan hingga pengamanan dicabut. 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 menggunakan perusahaan asesmen independen terkemuka yang khusus 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 Rule 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 dapat 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, pengaturan tersebut akan diterapkan pada semua blob di akun atau kontainer masing-masing. Jika ada penahanan legal pada sebuah kontainer, WORM tingkat versi tidak dapat dibuat untuk kontainer yang sama. Ini karena versi tidak bisa dihasilkan karena pembatasan hukum.
- 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 kali peningkatan terhadap 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 retensi berbasis waktu harus dikunci agar blob berada dalam status tidak dapat diubah (dilindungi dari penulisan dan penghapusan) yang sesuai untuk SEC 17a-4(f) dan kepatuhan peraturan lainnya. Microsoft menyarankan bahwa Anda sebaiknya mengunci kebijakan dalam jangka waktu yang wajar, yaitu 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.
Pencatatan audit kebijakan retensi
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. Pencatatan log 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.
Penahanan 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 penahanan dibatalkan secara eksplisit. Ketika penahanan hukum berjalan, blob dapat dibuat dan dibaca, tetapi tidak dapat dimodifikasi atau dihapus. Gunakan penahanan hukum ketika periode waktu yang diperlukan untuk menyimpan data dalam keadaan WORM tidak diketahui.
Cakupan
Kebijakan penahanan legal dapat dikonfigurasi di salah satu cakupan berikut:
Kebijakan WORM tingkat versi: Penahanan hukum dapat dikonfigurasi pada tingkat versi blob individual untuk pengelolaan yang terperinci terhadap data sensitif.
Kebijakan WORM tingkat kontainer: Penahanan hukum yang dikonfigurasi di tingkat kontainer berlaku bagi seluruh blob yang ada di dalam kontainer tersebut. Blob individual tidak dapat dikonfigurasi dengan kebijakan imutabilitasnya sendiri.
Tagar
Penahanan hukum di tingkat kontainer harus dikaitkan dengan satu atau lebih tag alfanumerik yang ditentukan pengguna yang berfungsi sebagai rangkaian pengenal. Misalnya, tag dapat menyertakan ID kasus atau nama acara.
Penglogan Audit
Setiap kontainer dengan penahanan hukum yang berlaku menyediakan catatan 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 tindakan penahanan hukum 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 pada tingkat wadah | 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 berlaku untuk 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. |
| Fitur dependensi | Tidak ada fitur lain yang merupakan prasyarat atau persyaratan agar fitur ini berfungsi. | Versi adalah prasyarat agar fitur ini dapat 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, akun atau kontainer tersebut hanya dapat dihapus jika kosong. |
| Dukungan untuk Azure Data Lake Storage (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 tingkat versi WORM
Tabel berikut membantu Anda memutuskan jenis kebijakan WORM mana yang akan digunakan.
| Kriteria | Penggunaan WORM tingkat kontainer | Penggunaan WORM pada tingkat versi |
|---|---|---|
| Pengaturan 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 dibedakan berdasarkan akun. Anda tahu bahwa jika menggunakan WORM pada tingkat kontainer, Anda harus melebihi batas maksimum 10.000 kontainer. |
| Minat untuk mengaktifkan pengelolaan versi | Anda tidak ingin berurusan dengan mengaktifkan versi, baik karena biaya, atau karena pekerjaan akan membuat banyak versi tambahan untuk ditangani. | Anda ingin menggunakan penerapan versi, atau tidak keberatan menggunakannya. Anda tahu bahwa jika mereka tidak mengaktifkan pengaturan versi, Anda tidak dapat mengedit atau menimpa blok-blok yang tidak bisa diubah sebagai versi terpisah. |
| Lokasi penyimpanan (Blob Storage vs Data Lake Storage) | Beban kerja Anda sepenuhnya berfokus pada Azure Data Lake Storage. Anda tidak memiliki minat atau rencana langsung untuk beralih menggunakan akun yang tidak memiliki fitur namespace hierarkis yang diaktifkan. | Beban kerja Anda ada di Blob Storage pada akun yang tidak memiliki fitur namespace hierarkis diaktifkan, sehingga Anda dapat langsung menggunakan WORM tingkat versi saat ini. Atau, Anda dapat memilih untuk menunggu hingga versi tersedia untuk akun yang sudah memiliki namespace hierarkis diaktifkan (Azure Data Lake Storage). |
Tingkatan 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 ketidakberubahan untuk page blob yang menyimpan disk VHD untuk komputer virtual aktif tidak disarankan karena penulisan ke disk akan diblokir, atau jika 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.
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 masa retensi soft delete. Blob atau versi yang belum dihapus secara soft delete dilindungi oleh kebijakan kekekalan dan tidak dapat dihapus hingga kebijakan penyimpanan berbasis waktu kedaluwarsa atau tahan hukum dihapus.
Gunakan inventaris blob untuk melacak kebijakan tidak dapat diubah
Inventaris blob Azure Storage memberikan gambaran umum tentang kontainer di akun penyimpanan Anda serta blob, snapshot, 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.
Mengonfigurasi kebijakan dalam skala besar
Anda dapat menggunakan tugas penyimpanan untuk mengonfigurasi kebijakan imutabilitas dalam skala besar di beberapa akun penyimpanan berdasarkan serangkaian kondisi yang Anda tentukan. Tugas penyimpanan adalah sumber daya yang tersedia di Azure Storage Actions; kerangka kerja tanpa server yang dapat Anda gunakan untuk melakukan operasi data umum pada jutaan objek di beberapa akun penyimpanan. Untuk mempelajari selengkapnya, lihat Apa itu Tindakan Azure Storage?.
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 versi WORM, tagihan mungkin lebih tinggi karena Anda telah mengaktifkan versi, dan ada biaya yang terkait dengan penyimpanan versi tambahan. 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 penahanan hukum pada versi blob menimbulkan biaya transaksi penulisan.
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
Penting
Fitur ini tidak kompatibel dengan pemulihan titik waktu dan pelacakan akses terakhir.
Fitur ini kompatibel dengan failover yang tidak direncanakan yang dikelola pelanggan, namun, setiap perubahan yang dilakukan pada kebijakan yang tidak dapat diubah setelah waktu sinkronisasi terakhir (seperti mengunci kebijakan penyimpanan berbasis waktu, memperluasnya, dll.) tidak akan disinkronkan ke wilayah sekunder. Setelah failover selesai, Anda dapat memperbarui perubahan di wilayah sekunder untuk memastikan bahwa wilayah tersebut sudah sesuai dengan persyaratan tidak berubah Anda. 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 objek blob lalu menambah data ke dalamnya. Jika kontainer memiliki kebijakan penyimpanan berbasis waktu aktif atau penahanan legal, pola ini tidak akan berhasil. Untuk informasi selengkapnya, lihat Mengizinkan penulisan blob append yang terlindungi.
Untuk informasi selengkapnya, lihat Dukungan fitur Blob Storage di akun Azure Storage.