Cara Mengamankan S3 Bucket AWS — Jangan Sampai Data Bocor Karena Salah Setting
Mengamankan s3 bucket aws mungkin skill paling basic yang wajib dikuasai siapapun megang infrastruktur AWS. Pertengahan 2019 lalu, dunia cybersecurity heboh gara-gara kasus Capital One. Seorang mantan engineer Amazon (ironis, kan?) berhasil mengakses data 100 juta customer Capital One — termasuk nomor social security, rekening bank, dan skor kredit — lewat S3 bucket yang salah konfigurasi. Kerugiannya? Selain denda 190 juta dolar, reputasi Capital One hancur seketika. Dan tahukah kamu apa yang bikin merinding? Teknik yang dipakai si attacker itu sebenarnya simpel banget — Server-Side Request Forgery (SSRF) yang dieksploitasi lewat misconfigured WAF, terus dipakai buat ngakses metadata IMDS EC2, dapet temporary credential, dan boom — akses ke S3 bucket yang seharusnya private.
Nah, dari kasus itu saya jadi makin yakin: mengamankan s3 bucket aws adalah skill paling basic yang wajib dikuasai siapapun yang megang infrastruktur AWS. Karena kenyataannya, 90% kebocoran data di AWS yang saya temuin selama 8 tahun ngebug bounty berawal dari S3 bucket yang salah setting. Bukan serangan zero-day canggih. Cuma salah centang doang.
Kenapa S3 Bucket Sering Jadi Biang Kerok
Sebelum kita bahas teknisnya, saya pengen kamu ngerti dulu kenapa S3 bucket itu unik dari sisi keamanan. Berbeda dengan EC2 instance yang secara default terisolasi di VPC dan nggak bisa diakses dari internet kecuali kamu assign public IP atau bikin load balancer, S3 bucket justru dirancang biar mudah diakses. Namanya juga Simple Storage Service — AWS bikin proses simpan dan ambil data jadi semudah mungkin. Tapi kemudahan ini yang sering jadi bumerang.
Pertama, S3 bucket nggak terikat VPC. Dia service regional yang endpoint-nya bisa diakses dari mana aja — termasuk dari internet. Kalau setting bucket policy salah, data kamu literally one click away dari orang random di belahan dunia manapun.
Kedua, fitur public access AWS Console itu mirip kayak tombol “bagikan ke semua orang” di Google Drive. Kadang developer yang lagi buru-buru testing atau debug, centang “allow public access” dulu, terus lupa balikin lagi. Satu centang itu cukup buat jadi berita utama di koran besok pagi.
Step-by-Step: Mengamankan S3 Bucket AWS dari A Sampai Z
Oke, sekarang kita masuk ke bagian teknisnya. Saya akan jelaskan langkah demi langkah, dari yang paling basic sampai advanced. Kamu bisa langsung praktik sambil baca.
1. Blokir Semua Public Access di Level Akun
Langkah pertama yang harus kamu lakuin adalah enable “Block Public Access” di level akun AWS. Ini semacam tombol darurat besar yang akan meng-override semua bucket-level setting dan memblokir akses publik secara menyeluruh. Caranya gampang: buka S3 console, klik “Block Public Access settings for this account”, terus centang semua checkbox — termasuk yang bilang “Block public access to buckets and objects granted through any access control lists”.
Kenapa di level akun? Karena setting ini jadi safety net terakhir. Jadi meskipun ada developer yang nggak sengaja bikin bucket baru terus setting-nya public, akses publik tetap keblokir. Ibaratnya kayak kamu pasang gembok besar di gerbang depan sebelum mikirin kunci masing-masing kamar. Banyak banget perusahaan yang skip step ini, dan percaya deh, saya udah terlalu sering nemuin bucket baru muncul tiba-tiba dengan setting public — biasanya hasil eksperimen developer baru yang belum paham security implications.
2. Konfigurasi Bucket Policy dengan Prinsip Least Privilege
Setelah public access diblokir di level akun, sekarang kita setting bucket policy per bucket. Bucket policy adalah JSON document yang mendefinisikan siapa yang boleh akses bucket kamu dan operasi apa yang boleh mereka lakuin.
Prinsip dasarnya sama kayak IAM: least privilege. Jangan pernah kasih "Effect": "Allow", "Principal": "*" kecuali kamu emang sengaja bikin bucket untuk static website hosting. Itu resep bencana. Sebagai gantinya, spesifikkan Principal-nya — misalnya cuma IAM role dari aplikasi kamu, atau cuma user tertentu.
Contoh bucket policy yang aman buat aplikasi web sederhana:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/myapp-ec2-role"
},
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::myapp-bucket/*"
}
]
}
Perhatikan: Principal-nya spesifik ke IAM role tertentu, Action-nya juga dibatasi cuma GetObject dan PutObject (nggak bisa delete, nggak bisa list semua bucket). Resource juga spesifik ke bucket yang bersangkutan.
3. Pilih Skema Enkripsi yang Tepat
Nah ini area yang sering bikin bingung. AWS nyediain beberapa opsi enkripsi buat S3:
SSE-S3 (Server-Side Encryption with S3-Managed Keys) — yang paling simpel. Kamu tinggal centang “enable encryption”, AWS yang ngurus kuncinya. Cocok buat data yang nggak terlalu sensitif dan kamu nggak butuh kontrol penuh atas encryption key. Kelemahannya: kalau AWS punya akses ke kuncinya, secara teknis mereka bisa (walaupun nggak akan) baca data kamu.
SSE-KMS (Server-Side Encryption with KMS-Managed Keys) — lebih aman karena kamu yang kontrol key lifecycle-nya. Kamu bisa tentuin siapa yang bisa pake key buat enkripsi dan dekripsi, bisa audit semua key usage lewat CloudTrail, dan bisa disable key kapan aja. Cocok buat data sensitif yang harus comply sama regulasi tertentu (PCI DSS, HIPAA).
SSE-C (Server-Side Encryption with Customer-Provided Keys) — kamu yang provide key-nya, AWS cuma melakukan enkripsi/dekripsi. AWS nggak nyimpen key kamu. Ini paling aman tapi juga paling ribet karena kamu harus manage key sendiri.
CSE-KMS (Client-Side Encryption) — kamu enkripsi data di sisi client sebelum upload ke S3, AWS cuma nyimpen ciphertext. AWS sama sekali nggak bisa baca data kamu.
Buat kebanyakan use case, SSE-KMS udah pilihan yang pas. Udah cukup aman, compliance-friendly, dan nggak terlalu ribet setup-nya.
4. Aktifkan Access Logging dan Object-Level Logging
Ini step yang super penting tapi sering banget dilewatin. S3 Server Access Logging nyatet semua request ke bucket kamu — IP siapa yang akses, kapan, operasi apa, status sukses atau gagal. Hasil log-nya disimpen di bucket terpisah.
Selain itu, aktifkan juga object-level logging lewat CloudTrail. Bedanya, CloudTrail nge-log API calls (termasuk yang gagal karena permission denied), sedangkan S3 Access Log nge-log request-data events yang berhasil diproses. Dua-duanya penting buat forensic investigation kalau nanti ada insiden.
Saya pernah nanganin kasus di mana S3 bucket sebuah e-commerce bocor dan data ribuan customer tersebar di forum hacker. Dari CloudTrail log, kami bisa trace bahwa credential salah satu developer dicuri lewat phishing email dua minggu sebelumnya. Tanpa logging yang proper, kami nggak akan pernah tahu apa yang sebenernya terjadi dan kapan mulainya.
5. Aktifkan Versioning dan MFA Delete
Versioning mungkin kedengerannya bukan fitur keamanan, tapi percayalah, ini penyelamat hidup. Dengan versioning aktif, setiap kali file di-overwrite atau dihapus, S3 nyimpen versi sebelumnya. Jadi kalau ada ransomware yang enkripsi semua file di bucket kamu, atau ada developer yang nggak sengaja ngehapus folder production, kamu tinggal restore versi sebelumnya.
MFA Delete adalah lapisan tambahan yang mensyaratkan autentikasi multi-faktor buat operasi penghapusan permanen. Jadi meskipun credential AWS kamu dicuri, attacker nggak bisa ngehapus versi lama file atau ngehapus versioning configuration tanpa akses ke MFA device kamu. Setup-nya mungkin agak ribet karena harus lewat CLI, tapi worth every second buat data production.
6. Aktifkan Monitoring Real-Time dengan CloudTrail dan CloudWatch
Jangan cuma pasang CCTV, kamu juga harus ada yang monitor layar CCTV-nya. Gunakan CloudWatch buat bikin alarm real-time. Beberapa event yang wajib kamu monitor:
PutBucketPolicy— ada yang ngubah bucket policyPutBucketAcl— ada yang ngubah ACLDeleteBucket— ada yang ngehapus bucketPutBucketPublicAccessBlock— ada yang ngubah setting public access- Operasi yang melibatkan
rootaccount — ini harus jadi big red flag
Setup CloudWatch alarm yang langsung kirim notifikasi ke Slack atau PagerDuty begitu event di atas terjadi. Respon cepat itu kunci. Saya udah terlalu sering liat insiden yang sebenernya bisa dicegah kalau aja ada yang notice perubahan mencurigakan lebih awal.
Pengalaman Pribadi Nemuin S3 Bucket Terbuka
Saya pengen cerita sedikit pengalaman pribadi. Tahun 2018, saya lagi iseng-iseng scanning asset salah satu unicorn Indonesia pake subdomain enumeration. Nemu subdomain cdn.perusahaanx.com yang di-resolve ke S3 bucket endpoint. Saya coba akses langsung, dan ternyata bucket-nya readable. Isinya? Semua asset gambar, file upload-an user, dan — yang bikin saya kaget — file backup database dalam format SQL dump. Uncompressed. Jadi literally tinggal download dan di-import ke MySQL lokal.
Saya langsung lapor ke tim security mereka lewat program bug bounty internal. Untungnya mereka fast response — direksi langsung turun tangan, bucket-lock dalam 30 menit, dan 2 hari kemudian mereka rilis full post-mortem ke user yang terdampak. Tapi bayangin kalau yang nemuin duluan bukan saya, tapi orang yang niatnya nggak baik.
Dari pengalaman itu, pelajaran yang saya dapet: S3 bucket bukan cuma tempat simpan file static. Developer sering anggap S3 sebagai “dumb storage” yang aman secara default, padahal kenyataannya enggak. Setiap bucket harus di-audit, setiap permission harus di-review, every. single. one.
Penutup
Mengamankan S3 bucket AWS itu sebenarnya nggak sulit. AWS udah nyediain semua tools yang kamu butuhin — Block Public Access, Bucket Policies, KMS, CloudTrail, versioning. Semua udah ada. Masalahnya, tools itu cuma berguna kalau kamu pakai. Dan jujur aja, dari ratusan audit yang saya lakuin, sebagian besar bucket S3 yang kebuka itu problemnya bukan karena teknologi, tapi karena human error: lupa, buru-buru, atau—yang paling sering—nggak tahu kalau settingan itu berbahaya.
Jadi mulai sekarang, sempetin waktu untuk audit semua S3 bucket di akun AWS kamu. Cek satu-satu. Pastiin Block Public Access nyala. Review bucket policy. Aktifkan logging. Aktifkan enkripsi default. Karena percaya deh — data customer kamu itu aset paling berharga. Jangan sampai hilang cuma gara-gara satu centang yang salah.
