Apa Itu Cloud Security? Panduan Shared Responsibility Model untuk Pemula
Saya masih inget banget pertama kali denger istilah cloud security. Waktu itu tahun 2016, saya lagi ngebug bounty di sebuah startup fintech Indonesia yang infrastrukturnya full di AWS. Saya lapor ke mereka kalau S3 bucket mereka public, semua data KYC customer — termasuk foto KTP, selfie, bahkan slip gaji — bisa diakses siapa aja. Respon CTO-nya? “Lah, bukannya AWS itu aman ya? Katanya udah comply ISO 27001.” Nah, dari situlah saya sadar — banyak orang Indonesia masih belum paham apa itu cloud security sebenarnya. Mereka pikir pindah ke cloud otomatis semua aman. Padahal kenyataannya? Jauh dari itu.
Jadi gini, cloud security itu bukan cuma fitur yang kamu checklist pas bikin akun AWS. Cloud security adalah seluruh praktik, teknologi, dan kebijakan yang kamu terapkan buat melindungi data, aplikasi, dan infrastruktur yang jalan di lingkungan cloud. Ini mencakup kontrol akses, enkripsi data, keamanan jaringan, monitoring, logging, dan masih banyak lagi. Dan yang paling penting — ini tanggung jawab kamu juga, bukan cuma penyedia cloud.
Cara Kerja Shared Responsibility Model
Pertama-tama, kamu harus ngerti dulu konsep paling fundamental di cloud security: shared responsibility model. Model ini berlaku di semua provider besar — AWS, Google Cloud, Azure. Intinya sederhana: penyedia cloud (misal AWS) bertanggung jawab atas security OF the cloud, sementara kamu sebagai customer bertanggung jawab atas security IN the cloud.
Apa yang Dijamin Sama AWS (Security OF the Cloud)
Jadi AWS itu ngamanin layer fisik dan infrastruktur dasarnya. Mereka yang jagain keamanan data center — CCTV, biometrik, security guard, fire suppression system, power backup, semua itu urusan mereka. Mereka juga yang nge-maintain keamanan hardware fisik: server, storage device, networking gear. Hypervisor yang virtualisasikan compute resource, itu juga mereka yang secure. Intinya, semua yang secara fisik ada di data center AWS dan semua software yang bikin layanan cloud bisa jalan — itu tanggung jawab AWS.
Nah, ini yang sering bikin orang salah paham. Mereka liat AWS punya compliance segambreng — ISO 27001, SOC 1/2/3, PCI DSS Level 1, FedRAMP, HIPAA — terus mikirnya “Wah, berarti data gue aman dong.” Padahal compliance AWS itu cuma nge-cover sisi mereka. Data kamu yang ada di EC2 instance atau di S3 bucket? Itu tanggung jawab kamu sepenuhnya.
Apa yang Jadi Tanggung Jawab Kamu (Security IN the Cloud)
Ini bagian yang paling sering diabaikan. Keamanan data yang kamu simpan di cloud, itu tanggung jawab kamu. Enkripsi data, klasifikasi data, access management, semua kamu yang atur. Konfigurasi aplikasi dan OS yang kamu deploy juga kamu yang pegang — mau EC2 instance kamu patch security update tepat waktu apa enggak, itu keputusan kamu. Firewall rules, security group, network ACL — kamu yang konfigurasi. IAM policy, user permission, API keys — kamu yang tentuin siapa bisa akses apa.
Saya pernah ngeliat startup yang pakai AWS root account buat daily operations sehari-hari. Root access key-nya di-hardcode di source code yang di-push ke public GitHub repository. Dan mereka heran kenapa AWS bill-nya tiba-tiba 50 ribu dolar dalam semalam. Jadi korban crypto mining attack dari akun mereka sendiri. Itu contoh nyata security IN the cloud yang gagal total.
Analoginya Gampang: Apartemen vs Keamanan Isinya
Biar lebih gampang, bayangin cloud provider itu kayak pemilik apartemen mewah. Si pemilik apartemen udah nyediain satpam 24 jam, CCTV di lobi dan koridor, pintu masuk pakai kartu akses, sistem alarm kebakaran. Itu semua security OF the cloud. Tapi kamar apartemen kamu isinya apa, pintu kamar kamu dikunci atau enggak, jendela kamu ditutup rapat atau terbuka lebar, barang berharga kamu disimpen di brankas atau digeletakin di meja — itu semua keputusan kamu. Mau satpam apartemen sekeren apapun, kalau kamu ninggalin pintu kamar terbuka lebar, ya maling tetap bisa masuk.
Miskonsepsi Cloud Security yang Sering Banget Terjadi
Selain mikir cloud otomatis aman, ada beberapa miskonsepsi lain yang sering saya temuin saat audit startup di Indonesia.
“Data Kita Kan di Indonesia, Jadi Aman”
Banyak yang mikir karena pilih region Singapore (yang secara geografis deket Indonesia), otomatis data mereka terlindungi UU Indonesia. Ini salah besar. Ketentuan lokasi data diatur sama regulasi seperti GDPR di Eropa atau PDP di Indonesia. Tapi AWS region cuma nentuin di mana data disimpan secara fisik, bukan di mana yurisdiksi hukumnya berlaku. Belum lagi soal akses — kalau IAM policy kamu salah setting, orang dari mana aja bisa akses, mau region-nya di Jakarta sekalipun.
“Kita Pakai Managed Service, Jadi Nggak Perlu Mikir Security”
Ini juga bahaya. Managed service seperti RDS, ECS, atau Lambda emang ngurangin beban operasional kamu. AWS yang ngurus patching OS dan hardening dasar. Tapi konfigurasi security group buat RDS, IAM role buat Lambda function, VPC setting, enkripsi at-rest — itu semua tetap di tangan kamu. Managed service itu kayak kamu nyewa mobil plus supir. Supir yang nyetir, tapi destinasi dan rute tetap kamu yang tentuin. Kalau kamu suruh supir masuk gang gelap jam 3 pagi, ya risikonya tanggung sendiri.
“Cloud Security Sama Aja Kayak On-Premise Security”
Ini perbedaan fundamental yang harus dipahami. Di on-premise, perimeter security adalah segalanya. Kamu punya firewall di edge network, semua traffic harus lewat situ. Di cloud, konsep perimeter tradisional udah nggak relevan. Microservice kamu satu ada di public subnet, satu di private subnet. S3 bucket bisa diakses langsung dari internet tanpa lewat VPC firewall. Identity jadi perimeter baru — siapa yang bisa akses apa, itu yang ngegantiin konsep firewall tradisional.
Kenapa Ini Penting Banget Buat Startup Indonesia
Saya perhatiin, startup Indonesia sering punya pola yang sama. Awal berdiri, tim engineering cuma 3-5 orang. Mereka buru-buru launch produk, nge-setup infrastruktur di cloud seadanya. Prioritaskan speed over security. Semua akses pakai root credential yang dishare di group WhatsApp. Environment production dan development dicampur di satu VPC. Database production bisa diakses dari IP kantor (atau bahkan dari mana aja — 0.0.0.0/0).
Masalahnya, pattern ini sering kebawa sampai startup udah punya puluhan engineer dan jutaan user. Dan begitu ada security incident — entah itu data breach, account takeover, atau resource hijacking — dampaknya bisa fatal. Saya pernah tangani kasus di mana startup healthtech Indonesia kehilangan akses ke seluruh infrastruktur AWS mereka karena root account-nya dikompromi. Backup nggak ada, disaster recovery plan nggak ada. Akhirnya? Mereka harus bangun ulang dari nol. Kerugian bukan cuma finansial, tapi juga kepercayaan user yang udah susah payah dibangun bertahun-tahun.
Dasar-Dasar IAM yang Wajib Kamu Pahami
Sekarang kita ngomongin IAM (Identity and Access Management). Ini pondasi paling dasar dari cloud security. IAM itu kayak sistem keamanan kantor yang nentuin: siapa yang boleh masuk, jam berapa, ke ruangan mana aja, dan ngapain aja di dalam.
Jangan Pernah Pakai Root Account
Root account itu kayak “master key” yang bisa buka semua pintu. Begitu bikin AWS account, hal pertama yang harus kamu lakuin adalah enable MFA di root account, terus simpen credential-nya di tempat super aman — jangan dipakai buat operasional harian. Bikin IAM user terpisah buat masing-masing engineer, bahkan untuk kamu sendiri sebagai CTO atau tech lead.
Gunakan Policy Sesuai Prinsip Least Privilege
Konsep dasarnya gampang: kasih akses seminim mungkin yang dibutuhkan buat ngerjain tugas. Jangan asal kasih AdministratorAccess ke semua orang biar “nggak ribet”. Itu pembunuh keamanan nomor satu di cloud. Bikin custom policy per role — developer cuma bisa akses services yang dia develop, DevOps bisa manage infrastructure tapi nggak bisa akses database, dan seterusnya.
IAM Role Lebih Aman daripada Access Key
Kalau aplikasi kamu jalan di EC2 atau Lambda, jangan pernah hardcode access key. Gunakan IAM role. Role itu credential sementara yang otomatis di-rotate sama AWS. Jadi kalau ada yang bocor, masa berlakunya udah habis sebelum sempat dipakai attacker. Access key yang di-hardcode itu kayak ninggalin kunci rumah di bawah keset — semua orang tahu di mana nyarinya.
Penutup: Cloud Security Itu Perjalanan, Bukan Destinasi
Setelah 8 tahun lebih main di bug bounty dan cloud security, satu hal yang paling saya pelajari adalah: nggak ada yang namanya 100% aman. Cloud security itu continuous process. Kamu harus terus monitor, audit, update, dan improve. AWS sendiri nge-release puluhan fitur baru tiap tahun. Attack vector juga makin canggih. Jadi paham apa itu cloud security dan shared responsibility model ini jadi bekal pertama yang wajib kamu punya.
Mulai dari yang paling sederhana dulu: cek S3 bucket kamu, pastiin nggak ada yang public. Review IAM policy, matiin access key yang nggak dipakai. Enable MFA di semua akun. Itu langkah kecil yang dampaknya luar biasa besar. Soalnya percaya deh — lebih baik kamu yang nemuin security hole di infrastruktur sendiri, daripada orang lain yang nemuin duluan.
