Hari ini saya mulai masuk ke topik yang selama ini terasa paling “jauh” dari keseharian saya sebagai programmer: keamanan cloud. Selama ini saya terbiasa berpikir server itu sesuatu yang saya sewa, login, lalu jaga sendiri. Ternyata begitu pindah ke cloud, modelnya berubah total — dan kesalahpahaman soal ini adalah sumber kebocoran data paling sering yang saya baca. Ini yang saya catat dari belajar tentang shared responsibility, IAM least privilege, dan kasus bucket S3 yang terbuka ke publik.
Shared Responsibility: Siapa yang Menjaga Apa?
Di episode #6 saya belajar bahwa firewall adalah pintu gerbang yang saya pasang dan saya jaga. Di cloud, gambarannya jadi seperti menyewa apartemen: pemilik gedung yang memastikan dinding, lift, dan pintu utama kokoh — tapi isi kamar, gembok lemari, dan siapa yang boleh masuk ke kamarmu adalah urusanmu. AWS menyebutnya shared responsibility model: bagian “security of the cloud” (hardware, jaringan, data center, virtualization) ditangani penyedia, sedangkan bagian “security in the cloud” (OS patch, konfigurasi service, access key, data, firewall virtual) tetap tanggung jawab kita sebagai pelanggan.
Ini berarti bagi saya: meski AWS bilang “infra kami sudah aman”, saya tetap bisa membuka data saya sendiri lewat konfigurasi yang salah. Kecerdikan penyedia tidak menutupi kelalaian konfigurasi di sisi pelanggan.
IAM Least Privilege: Beri Hak Seminimal Mungkin
Analogi paling dekat: di kantor lama, kartu akses saya cuma membuka lantai saya. Kalau kartu itu bisa membuka semua lantai termasuk ruang server, satu kartu hilang = seluruh gedung terekspos. Prinsipnya sama dengan IAM least privilege: user, role, atau service hanya diberi izin persis yang dibutuhkan pekerjaannya, tidak lebih.
Kesalahan umum yang saya temukan sendiri waktu dulu iseng-iseng: memberi izin * supaya “biar tidak error lagi” saat setup. Pola berbahaya itu terlihat seperti ini:
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}Sebagai obatnya, batasi Action ke daftar yang benar-benar dipakai (misal hanya s3:GetObject pada satu bucket tertentu), dan hindari key yang dipakai lintas environment. Saya terapkan dengan begini: satu key/role per keperluan, bukan satu key raksasa untuk semuanya, supaya kalau bocor dampaknya terbatas ke satu fungsi.
Kasus Klasik: Bucket S3 yang Terbuka
Object storage seperti S3 secara default bersifat privat — hanya pemilik akun yang bisa mengakses. Masalah muncul saat seseorang menonaktifkan proteksi demi “sementara testing” atau memasang ACL public-read, lalu lupa mengembalikannya. Begitu publik, semua orang yang tahu URL bisa mengunduh isinya; tidak perlu tools canggih, cukup browser.
Untungnya AWS sekarang membalik default-nya: bucket baru otomatis mengaktifkan S3 Block Public Access — empat pengaturan independen (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) yang bisa dipasang di level bucket, akun, sampai organisasi, dengan aturan “paling ketat yang menang”. Artinya proteksi ada di depan, tinggal kita jangan menonaktifkannya sembarangan. Kalau memang butuh publik (misal hosting website statis), nonaktifkan di bucket itu saja dengan sadar risiko.
Yang membuat saya berhenti sejenak: di on-premise, kalau saya salah konfigurasi firewall paling buruk data hanya terekspos ke jaringan kantor. Di cloud, service yang salah konfigurasi bisa langsung terhubung ke internet publik dalam hitungan menit sejak dibuat. Kecepatan provisioning yang jadi keunggulan cloud justru mempercepat kesalahan konfigurasi juga — dan itulah mengapa guardrail seperti Block Public Access serta policy least privilege harus dipasang sejak awal, bukan menyusul.
Checklist Kecil yang Saya Pakai
- Audit berkala izin: cari policy dengan
"Action": "*"atau"Resource": "*"lalu persempit. - Aktifkan MFA untuk akun admin (lanjutan dari pembahasan autentikasi di episode #3).
- Aktifkan Block Public Access di level akun kalau tidak ada kebutuhan publik.
- Matikan atau rotasi access key yang tidak terpakai; jangan simpan key di kode atau git (materi episode #18 akan membahas secrets management).
- Gunakan audit log bawaan (CloudTrail dkk) — konsepnya lanjutan dari audit log Linux di episode #14.
Kesimpulan yang saya bawa: cloud tidak otomatis aman dan tidak otomatis berbahaya — yang menentukan adalah konfigurasi kita. Dan karena konfigurasi bisa diubah siapa pun dengan izin cukup, justru itulah alasan izin harus dibatasi serendah mungkin.
Sumber
AWS Shared Responsibility Model
Komentar Terbaru