Fitur Write Once, Read Many (WORM) dari kebijakan retensi di Object Storage Service (OSS) mencegah data dari penghapusan atau modifikasi. Jika Anda ingin mencegah semua pengguna, termasuk pemilik resource, dari memodifikasi atau menghapus objek dalam bucket OSS selama periode tertentu, Anda dapat mengonfigurasi kebijakan retensi untuk bucket tersebut. Selama periode retensi, Anda hanya dapat mengunggah dan membaca objek. Objek hanya dapat dimodifikasi atau dihapus setelah periode retensi berakhir.
Skenario
Fitur WORM yang disediakan oleh kebijakan retensi di OSS membantu perusahaan memenuhi persyaratan regulasi dan kepatuhan dari U.S. Securities and Exchange Commission (SEC) dan Financial Industry Regulatory Authority (FINRA). Fitur ini cocok untuk sektor-sektor seperti keuangan, asuransi, kesehatan, dan sekuritas, serta untuk skenario seperti audit data log dalam Multi-Layer Protection Scheme (MLPS).
OSS telah terakreditasi dan diaudit oleh Cohasset Associates serta memenuhi persyaratan ketat untuk retensi catatan elektronik. Bucket OSS dengan kebijakan retensi yang dikonfigurasi mematuhi regulasi seperti SEC Rule 17a-4(f), FINRA Rule 4511, dan Commodity Futures Trading Commission (CFTC) Rule 1.31. Untuk informasi lebih lanjut, lihat Laporan Penilaian OSS Cohasset.
Prasyarat
Pastikan versioning diaktifkan atau dinonaktifkan untuk bucket tempat Anda ingin menetapkan kebijakan retensi. Anda tidak dapat menetapkan kebijakan retensi jika versioning ditangguhkan. Untuk informasi selengkapnya tentang versioning, lihat Versioning.
Catatan
Anda hanya dapat mengonfigurasi kebijakan retensi untuk bucket.
Anda tidak dapat mengaktifkan OSS-HDFS dan mengonfigurasi kebijakan retensi untuk bucket yang sama.
Selama periode retensi, Anda dapat mengonfigurasi aturan lifecycle untuk mengubah kelas penyimpanan objek dalam bucket guna mengurangi biaya penyimpanan dan memastikan kepatuhan.
Deskripsi aturan
Aturan Aktif
Secara default, kebijakan retensi berbasis waktu berada dalam status InProgress selama 24 jam setelah dibuat. Selama periode ini, resource bucket dilindungi.
Dalam 24 jam setelah kebijakan retensi dibuat
Jika kebijakan retensi belum dikunci, pemilik bucket dan pengguna yang berwenang dapat menghapus kebijakan tersebut.
Jika kebijakan retensi telah dikunci, kebijakan tersebut tidak dapat dihapus dan periode retensinya tidak dapat dipersingkat. Namun, periode retensi dapat diperpanjang. Data dalam bucket dilindungi oleh kebijakan retensi. Jika Anda mencoba menghapus atau memodifikasi data dalam bucket, error
409 FileImmutableakan dikembalikan.
Lebih dari 24 jam setelah kebijakan retensi dibuat
Jika kebijakan retensi belum dikunci lebih dari 24 jam setelah dibuat, kebijakan tersebut menjadi tidak valid dan dapat dihapus.
Penghapusan
Kebijakan retensi berbasis waktu merupakan atribut metadata dari sebuah bucket. Jika bucket dihapus, kebijakan retensi bucket tersebut juga dihapus.
Jika kebijakan retensi belum dikunci dalam 24 jam setelah dibuat, pemilik bucket dan pengguna yang berwenang dapat menghapus kebijakan tersebut.
Jika bucket berisi objek yang dilindungi oleh kebijakan retensi, Anda tidak dapat menghapus bucket atau kebijakan retensi tersebut.
Contoh
Misalnya, Anda membuat kebijakan retensi dengan periode retensi 30 hari untuk sebuah bucket pada 1 Juni 2022, dan segera mengunci kebijakan tersebut. Anda mengunggah tiga objek, file1.txt, file2.txt, dan file3.txt, pada waktu yang berbeda. Tabel berikut mencantumkan tanggal unggah dan tanggal kedaluwarsa objek-objek tersebut.
Nama objek
Tanggal unggah
Tanggal kedaluwarsa objek
file1.txt
1 April 2022
30 April 2022
file2.txt
1 Juni 2022
30 Juni 2022
file3.txt
1 September 2022
30 September 2022
Metode
Gunakan Konsol OSS
Gunakan Alibaba Cloud SDK
Gunakan antarmuka baris perintah ossutil
API Terkait
Operasi di atas didasarkan pada operasi API. Jika program Anda memiliki persyaratan kustomisasi tinggi, Anda dapat langsung membuat permintaan REST API. Untuk membuat permintaan REST API, Anda harus menulis kode secara manual untuk menghitung signature. Untuk informasi selengkapnya, lihat InitiateBucketWorm.
Bekerja dengan versioning
Dalam skenario seperti memberikan perlindungan versi data untuk sistem backup seperti Veeam, melacak catatan modifikasi aset seperti diagram desain sirkuit, atau memenuhi persyaratan pengarsipan kepatuhan di industri keuangan, Anda sering perlu mengizinkan pembaruan data kontinu sekaligus memastikan bahwa semua versi historis bersifat immutable dan tidak dapat dihapus. Untuk mencapai hal ini, Anda dapat membuat kebijakan retensi dan mengaktifkan versioning untuk bucket secara bersamaan. Versioning memastikan bahwa ketika objek ditimpa atau dihapus, versi lamanya tetap disimpan sebagai versi historis, bukan dihapus secara fisik. Kebijakan retensi menetapkan periode perlindungan untuk semua versi objek dalam bucket. Selama periode ini, tidak ada versi yang dapat dihapus atau dimodifikasi.
Ketika versioning dan kebijakan retensi dikonfigurasi untuk bekerja bersama, mereka mengikuti prinsip-prinsip berikut:
Urutan pengaktifan fitur: Tidak ada batasan urutan pengaktifan versioning dan kebijakan retensi. Anda dapat mengonfigurasinya secara fleksibel sesuai kebutuhan.
Batasan transisi status:
Setelah kebijakan retensi dikunci, Anda tidak dapat mengubah status versioning dari "Enabled" menjadi "Suspended".
Anda dapat mengaktifkan kebijakan retensi untuk bucket yang versioning-nya "Suspended". Setelah kebijakan diaktifkan, Anda dapat mengubah status versioning menjadi "Enabled".
Mekanisme perlindungan versi objek:
Kebijakan retensi melindungi semua versi objek. Tidak ada versi yang dapat dihapus atau dimodifikasi selama periode perlindungan.
Anda dapat mengunggah objek dengan nama yang sama untuk membuat versi baru. Versi baru tersebut juga dilindungi oleh kebijakan retensi.
Kebijakan retensi tidak berlaku untuk delete markers. Penghapusan delete markers tidak dibatasi oleh kebijakan retensi.
Sinergi replikasi data:
Bucket sumber dan tujuan mendukung konfigurasi independen untuk versioning dan kebijakan retensi.
Informasi versi ditransmisikan secara normal selama replikasi. Bucket tujuan mengelola versi berdasarkan konfigurasinya sendiri.
Operasi penghapusan versi di bucket sumber tidak disinkronkan ke bucket tujuan yang memiliki kebijakan retensi yang diaktifkan.