Object Storage Security: The Public Bucket That Exposed Our Backups

Gue masih inget malam itu dengan jelas. Jam dua belas lewat, kantor udah sepi, gue tinggal sendirian nungguin build pipeline yang lagi nyangkut. Bukan karena gue kerasan lembur, tapi karena esok paginya ada demo ke klien dan backup database malam itu belum masuk ke tempat yang seharusnya. Waktu gue buka konsol cloud buat ngecek status upload, mata gue nggak sengaja mampir ke satu baris kecil di pengaturan bucket: "Public access: Enabled".

Jantung gue sempet ngegas. Bucket itu isinya backup produksi. Berarti siapa pun di dunia ini, asal tau URL-nya, bisa unduh database kami. Nggak perlu password, nggak perlu token, nggak perlu izin apa-apa. Cuma link.

Itu momen di mana gue sadar kalau selama ini gue nganggep "cloud itu aman secara default". Ternyata nggak. Cloud itu aman kalau lo yang ngatur. Dan malam itu, gue yang salah ngatur.

Cerita ini gue tulis bukan buat ngebikin lo takut sama cloud, tapi buat nunjukin betapa gampangnya satu penyimpanan objek kebuka ke publik, dan gimana cara gue sekarang ngamankan object storage biar kejadian kayak malam itu nggak keulang.

Object Storage Itu Sebenarnya Apa Sih

Sebelum lanjut, gue mau pastiin kita sepaham dulu soal istilahnya. Object storage itu model penyimpanan di mana lo naruh file sebagai "objek" di dalam "bucket". Bukan kayak hard disk yang punya folder hierarki, tapi lebih kayak lemari raksasa berisi kotak-kotak yang masing-masing dikasih nama unik. Di AWS namanya S3, di Google Cloud namanya Cloud Storage, di Azure namanya Blob Storage. Prinsipnya sama: lo upload file, lo dapet URL, lo atur siapa yang boleh akses.

Bedanya sama database: object storage itu murah, awet, dan emang dibikin buat naruh file mentah dalam jumlah gede. Makanya hampir semua perusahaan pakai ini buat backup, asset gambar, log, file statis frontend, sampai arsip dokumen. Semuanya nyangkut di sini.

Masalahnya: karena sifatnya yang "kasih URL terus bisa diakses", object storage adalah salah satu tempat paling sering salah konfigurasi di seluruh ekosistem cloud. Laporan tiap tahun soal kebocoran data hampir selalu ada satu penyebab yang sama: bucket terbuka.

Malam Itu Gue Temukan Bucket yang Terbuka

Balik ke malam itu. Setelah panik lima detik, gue langsung cek access log. Pertanyaan pertama di kepala gue: "udah ada yang download belum ya?" Kalau udah, berarti bukan cuma soal nutup pintu, tapi soal damage control.

Ternyata ada beberapa request dari IP yang gue nggak kenal. Gue nggak bisa pastiin mereka beneran ngunduh data atau cuma bot internet yang lagi ngacak-ngacak URL. Tapi jujur, di titik itu nggak ada bedanya. Kalau pintunya kebuka, kita harus anggap data udah terlanjur keliatan.

Gue lakuin tiga hal dalam sepuluh menit pertama. Pertama, matiin public access di bucket itu. Kedua, ganti credential dan key yang pernah disimpen di situ. Ketiga, catet waktu kejadian dan kirim laporan ke atasan sebelum besok pagi dia dapet kabar dari orang lain. Itu pelajaran pertama: kalau lo nemu insiden, kabarin orang yang berwenang sebelum mereka nemu sendiri.

Tapi yang bikin gue geleng-geleng bukan kejadiannya. Yang bikin gue mikir adalah gimana bisa kejadian. Bucket itu nggak di-set public hari itu juga. Dia public dari berbulan-bulan lalu, pas ada satu engineer (bukan gue, tenang aja) yang butuh share file demo ke klien dan milih jalan pintas: buat bucket jadi public biar gampang. Habis itu lupa balikin. Pelan-pelan file demo itu pindah, dan akhirnya bucket itu dipake buat backup produksi tanpa ada yang ngecek status aksesnya lagi.

Itulah bahayanya: kebocoran cloud jarang terjadi karena hacker jago. Kebanyakan terjadi karena kita sendiri yang buka pintunya, terus lupa nutup.

Kenapa Bucket Bisa Kebuka Padahal Kita Nggak Sengaja

Gue habis kejadian itu mulai riset cara kerja permission di object storage. Ternyata ada beberapa lapisan yang kalau lo nggak paham, gampang bentrok dan bikin lubang.

Lapisan pertama adalah access control list, atau ACL. Ini pengaturan per-file atau per-bucket yang bilang "akun ini boleh baca, akun itu nggak". Masalahnya ACL sering di-set terlalu longgar cuma buat testing, terus ketularan ke production.

Lapisan kedua adalah bucket policy. Ini dokumen JSON yang nyebutin aturan akses: siapa boleh, dari IP mana, pakai kondisi apa. Banyak orang nulis policy dengan wildcard "*" di principal, maksudnya "semua orang", terus kaget pas emang semua orang bisa akses.

Lapisan ketiga adalah public access block, fitur khusus yang harusnya nyala secara default di layanan cloud modern, tapi sering dimatiin karena "bikin repot pas develop". Nah, inilah yang kejadian di bucket gue. Fitur pelindungnya dimatiin, terus satu kesalahan kecil di atasnya langsung jadi lubang lebar.

Pelajaran yang gue dapet: jangan pernah manjain kemudahan dengan mematikan fitur keamanan. Kalau public access block bikin repot pas testing, berarti cara testing lo yang salah, bukan fiturnya.

Prinsip Least-Privilege di Level Penyimpanan

Setelah kejadian itu, gue mulai terapin prinsip least-privilege secara ketat di semua bucket. Intinya sederhana: kasih akses seminimal mungkin, cuma ke yang butuh, cuma buat yang dikerjain.

Dulu gue suka kasih satu credential yang bisa baca-tulis ke semua bucket sekaligus biar gampang. Praktis memang, tapi kalau credential itu bocor, musuh dapet kunci ke seluruh kerajaan. Sekarang gue pecah: ada credential khusus buat service backup yang cuma boleh nulis ke bucket backup, nggak boleh baca bucket lain. Ada credential khusus buat aplikasi frontend yang cuma boleh baca asset publik, nggak boleh sentuh apa pun selain itu.

Dampaknya pas ada insiden jadi kecil. Kalau satu key bocor, yang kebuka cuma satu sudut kecil, bukan seluruh gudang. Ini prinsip yang berlaku di semua sisi security, tapi di object storage rasanya paling gampang diabaikan karena "file aja kok harus dijagain ketat".

Enkripsi Bukan Cuma Centang Kotak

Hal berikutnya yang gue benahin adalah enkripsi. Banyak orang mikir kalau storage udah nyediain opsi "encrypt at rest" terus aman. Gue juga dulu mikir gitu. Tapi pas gue pelajari lebih dalam, enkripsi punya detail yang nentuin apakah dia beneran nyelamatin lo atau cuma pajangan.

Pertama, siapa yang pegang key-nya. Kalau cloud provider yang pegang key dan lo nggak ngatur apa-apa, artinya provider bisa baca data lo kapan aja. Buat sebagian kasus itu oke, tapi buat data sensitif kayak backup database, gue lebih suka pakai key sendiri yang gue simpen di layanan manajemen key terpisah. Jadi kalau ada yang mau baca file, dia butuh key dari brankas lain, bukan cuma akses ke bucket.

Kedua, enkripsi nggak berguna kalau bucket-nya sendiri kebuka ke publik. Orang yang akses lewat jalur publik bakal dapet file yang otomatis di-decrypt sama layanan, karena dari sisi sistem dia "berhak akses". Enkripsi melindungi lo dari pencuri yang nyolong hard disk cloud, bukan dari salah konfigurasi akses. Dua-duanya harus beres.

Itu yang bikin gue sadar: security itu rantai, dan rantai putus di mata rantai terlemah. Bucket public plus enkripsi kuat tetaplah bucket public.

Logging dan Audit: Siapa yang Sentuh File Kita

Satu hal yang bikin gue malu pas insiden itu: gue nggak punya log akses yang rapi buat bucket tersebut. Gue cuma bisa nebak dari akses mentah yang seadanya. Kalau gue punya audit log yang jalan dari awal, gue bisa pastiin kapan pertama kali bucket di-set public, siapa yang melakukannya, dan apa aja yang sempet diunduh.

Sekarang gue wajibin logging akses di setiap bucket penting. Setiap read, write, delete, dan perubahan policy tercatat ke sistem terpisah yang nggak bisa dihapus sembarangan. Gue juga kirim log itu ke dashboard yang gue cek seminggu sekali, bukan cuma pas ada alarm darurat.

Manfaatnya nggak cuma buat insiden. Logging yang rapi bikin gue paham pola akses normal, jadi kalau ada anomali, gue langsung ngeh. Misalnya tiba-tiba ada download besar-besaran jam tiga pagi dari negara yang tim gue nggak punya cabang di situ. Itu sinyal, dan sinyal cuma berguna kalau lo punya alat buat terima dan baca sinyalnya.

Public Access Block dan Guardrail yang Harus Nyala

Gue sekarang selalu nyalain public access block di level akun, bukan cuma di level bucket. Bedanya: kalau di level akun, semua bucket baru otomatis terlindungi, dan nggak ada satu engineer pun bisa asal nyalain public tanpa lewat proses yang gue set.

Selain itu gue pasang guardrail berupa policy organisasi yang melarang bucket public kecuali ada pengecualian tertulis. Jadi kalau ada yang butuh share file ke publik, dia harus lewat review, bukan sekadar klik tombol. Ini kedengarannya birokratis, tapi setelah ngerasain malam itu, gue lebih suka repot dikit daripada kebakaran besar.

Gue juga rutin jalanin tool pemindai konfigurasi yang ngecek semua bucket dan kasih laporan kalau ada yang nyimpang dari standar. Banyak layanan cloud punya fitur semacam ini gratis, dan gue anggap ini sebagai alarm dasar yang harus nyala sebelum lo mikirin defense yang lebih canggih.

Cara Gue Sekarang Audit Storage Tiap Minggu

Biar nggak kejadian dua kali, gue bikin ritual kecil: tiap Jumat sore, gue duduk sepuluh menit dan jalanin daftar cek yang simpel tapi ketat.

Satu, cek daftar bucket dan pastiin jumlahnya masuk akal. Kalau tiba-tiba ada bucket baru yang gue nggak tau, itu harus dijelasin. Dua, pastiin public access block nyala di semua bucket produksi. Tiga, cek log akses buat nyari anomali. Empat, muter ulang credential yang dipake buat akses storage, karena key lama yang nggak pernah diputer itu mangsa empuk. Lima, pastiin enkripsi pakai key yang masih valid dan nggak kedaluwarsa.

Ritual ini keliatan sepele, tapi dia yang bikin gue tidur tenang. Security bukan soal alat paling canggih, tapi soal kebiasaan yang konsisten. Alarm canggih pun nggak berguna kalau nggak ada yang pernah ngecek.

Jangan Sampai Lo Jadi Gue yang Malam Itu

Kalau ada satu pesan yang gue pengen lo bawa pulang dari cerita ini, itu adalah: object storage itu kepanjangan dari "tempat lo naruh rahasia perusahaan". Perlakuan lo ke situ harus selayaknya brankas, bukan laci terbuka.

Gue nggak mau lo harus ngerasain detik-detik di mana lo ngedapetin status "Public access: Enabled" di bucket yang isinya backup produksi. Detik itu berasa lama banget. Lebih baik lo repot sekarang: nyalain public access block, batasin akses tiap credential, nyalain log, dan rutin audit. Sepuluh menit tiap minggu jauh lebih murah dari satu malam yang hancur dan satu laporan insiden yang harus lopertanggungjawabkan di depan manajemen.

Cloud itu bukan musuh lo. Salah konfigurasi yang dibiarin itulah musuhnya. Dan musuh itu paling sering lahir dari kebiasaan kita sendiri yang milih jalan pintas daripada jalan yang aman.

Jadi sebelum lo tutup tab konsol cloud hari ini, mampir sebentar ke daftar bucket lo. Cek status aksesnya. Kalau ada satu yang kebuka dan lo nggak punya alasan kuat kenapa itu harus kebuka, tutup sekarang. Gue berani taruhan, tindakan lima menit itu bakal nyelamatin lo dari cerita buruk yang mirip punya gue.