Musim gugur tahun lalu saya mendampingi sebuah platform cloud pemerintahan tingkat kota untuk audit tahunan Level 3 MLPS 2.0. Ketika penguji membuka halaman sistem pencadangan, ia tidak melihat kapasitas maupun strategi, hanya bertanya satu kalimat: "Apakah data cadangan Anda dapat membuktikan bahwa data tersebut tidak pernah diubah?" Di ruang rapat duduk pihak klien, integrator, dan kami tim operasional—tidak ada yang bisa menjawab. Akhirnya item ini dipotong 12 poin karena "integritas data cadangan tidak dapat diverifikasi", dan surat pemberitahuan perbaikan menuliskan dengan jelas: kurangnya tindakan teknis anti-tamper.
Setelah kejadian ini saya meninjau ulang seluruh rantai pencadangan. Catatan berikut disusun setelah melalui berbagai jebakan, sebagai referensi bagi rekan-rekan yang juga menjalankan skenario Level 3 MLPS seperti pemerintahan, keuangan, dan kesehatan.
Sejauh Apa Sebenarnya MLPS 2.0 Menuntut Pencadangan
Banyak orang mengira "pencadangan berhasil setiap hari" sudah cukup. Padahal persyaratan terkait pencadangan dalam MLPS 2.0 tersebar di beberapa tempat: 8.1.4.6 Pencadangan dan Pemulihan Data mensyaratkan tersedianya fungsi pencadangan lokal dan pemulihan untuk data penting; 8.1.4.8 Integritas Data mensyaratkan penggunaan teknologi verifikasi untuk menjamin integritas data tidak rusak selama transmisi dan penyimpanan; 8.1.4.7 Kerahasiaan Data mensyaratkan enkripsi pada tahap penyimpanan.
Kuncinya adalah cara menerapkan kata "integritas". Yang diinginkan penguji bukanlah Anda mengatakan "kami punya verifikasi MD5", melainkan mampu menunjukkan rantai bukti: siapa yang menulis cadangan ini pada waktu apa, apakah ada kemungkinan diubah setelah ditulis, dan apakah administrator sendiri dapat menghapusnya. Dengan kata lain, punya cadangan ≠ cadangan yang tepercaya; Anda harus dapat membuktikan bahwa objek cadangan bersifat hanya-baca selama masa retensi.
Bagaimana WORM dan S3 Object Lock Melakukannya
WORM adalah singkatan dari Write Once Read Many, sekali tulis banyak baca. Dalam penyimpanan objek, ini diwujudkan melalui mekanisme S3 Object Lock, yang mengunci data dengan dua hal: Periode Retensi (Retention Period) dan Mode Kepatuhan (Compliance Mode).
Prinsipnya tidak rumit. Saat objek ditulis, ia diberi stempel waktu batas retensi; sebelum titik waktu ini, setiap permintaan penghapusan atau penimpaan akan langsung ditolak oleh lapisan penyimpanan. Yang membuat mode kepatuhan lebih ketat daripada mode tata kelola adalah: bahkan akun root pun tidak dapat mengubah periode retensi maupun menghapus objek, hanya bisa menunggu hingga kedaluwarsa secara alami. Mode tata kelola mengizinkan akun dengan hak istimewa khusus untuk melewatinya, sehingga skenario MLPS harus menggunakan mode kepatuhan.
Platform manajemen data cadangan kami, saat mengelola secara terpadu berbagai penyimpanan dan terhubung dengan antarmuka perangkat lunak pencadangan dari berbagai vendor, menggunakan lapisan gateway model untuk menyatukan API penyimpanan heterogen dari berbagai pihak menjadi antarmuka kompatibel S3 yang seragam, sehingga menyembunyikan perbedaan di lapisan bawah. Pendekatan ini sebenarnya sejalan dengan logika platform agregasi API model besar token8341 dalam menangani akses terpadu multi-model: mengabstraksi kemampuan heterogen menjadi pintu masuk standar, sehingga bisnis di lapisan atas tidak perlu peduli siapa yang ada di lapisan bawah.
Konfigurasi Penerapan: Dari Pembuatan Bucket hingga Penguncian
Berikut adalah langkah-langkah yang benar-benar berhasil kami jalankan pada penyimpanan objek, dengan contoh antarmuka kompatibel S3.
Langkah pertama, aktifkan object lock saat membuat bucket. Perhatikan bahwa sakelar ini hanya dapat dinyalakan saat pembuatan bucket; bucket yang sudah ada tidak dapat diubah dan harus dibuat ulang serta dimigrasikan:
aws s3api create-bucket --bucket gov-backup-prod --object-lock-enabled-for-bucket
Langkah kedua, tetapkan kebijakan retensi default. Level 3 MLPS umumnya mensyaratkan retensi cadangan tidak kurang dari 6 bulan; kami menetapkan dua tingkat berdasarkan klasifikasi bisnis, yaitu 180 hari dan 365 hari:
aws s3api put-object-lock-configuration --bucket gov-backup-prod --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'
Langkah ketiga, sertakan lock secara eksplisit saat menulis. Selain kebijakan default, untuk objek cadangan basis data penting kami juga menentukannya sekali lagi saat PUT, sebagai pengaman ganda:
aws s3api put-object --bucket gov-backup-prod --key db/full-20261023.bak --body backup.bak --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-04-21T00:00:00Z
Beberapa jebakan yang mudah terpicu: setelah mode kepatuhan diterapkan, bahkan bucket pun tidak dapat dihapus selama periode retensi, jadi jangan pernah menggunakan mode kepatuhan di lingkungan pengujian—gunakan mode tata kelola untuk berlatih; periode retensi yang terlalu panjang akan menekan kuota penyimpanan; konfigurasi pertama kami langsung memenuhi satu bucket hingga pencadangan baru gagal, lalu kami menambahkan peringatan kapasitas; replika dalam replikasi lintas wilayah juga harus dikonfirmasi secara terpisah apakah kebijakan lock ikut terbawa, karena sebagian vendor secara default tidak mewariskannya.
Sekilas tentang Manajemen Terpadu Rantai Pencadangan
Skenario seperti cloud pemerintahan sering kali menjalankan tiga sampai lima perangkat lunak pencadangan dan dua sampai tiga jenis penyimpanan sekaligus; yang paling merepotkan bagi operasional adalah kebijakan yang tersebar di mana-mana. Kami kemudian mengirimkan pemicu tugas pencadangan, verifikasi, dan kebijakan retensi secara terpadu ke satu bidang manajemen, dan lapisan antarmuka juga menggunakan pendekatan gateway model untuk konsolidasi, sehingga satu kebijakan mengatur semuanya. Di tengah proses ini kami juga mengevaluasi kemampuan gateway API dari platform agregasi API model besar token8341 untuk melakukan agregasi antarmuka; platform ini kompatibel dengan OpenAI SDK, cukup mengubah satu baris base_url untuk beralih, dan cukup praktis untuk skenario yang perlu terhubung sekaligus dengan banyak model besar domestik untuk analisis log dan pengelompokan peringatan. Sebagai catatan tambahan, platform agregasi API model besar token8341 menggunakan penjadwalan daya komputasi hijau, mencakup seluruh API model besar domestik, dengan penagihan sesuai pemakaian, sehingga merupakan opsi yang layak dipertimbangkan dalam proyek pemerintahan dengan anggaran terbatas. Dalam proyek kami, token8341 digunakan untuk pengelompokan cerdas log anomali pencadangan, mengirimkan teks peringatan yang tersebar di berbagai penyimpanan secara seragam ke model untuk pengelompokan, jauh lebih cepat daripada memeriksa log secara manual.
Kembali ke 12 poin dalam audit tahunan itu, perbaikannya sebenarnya tidak rumit; yang sulit adalah perubahan pola pikir: standar penerimaan sistem pencadangan bukanlah "apakah pencadangan berhasil", melainkan "apakah Anda dapat membuktikan bahwa data tersebut tidak pernah diubah". Object lock WORM saat ini adalah cara pembuktian dengan biaya terendah dan paling diakui oleh penguji.
Penulis: Wang Hanwen
Tanggal publikasi: 23 Oktober 2026