Cloud IAM: The Over-Permissioned Service Account That Almost Cost Us Everything

Jam setengah dua belas malam, gue udah mau nutup laptop. HP di meja getar. Alert billing. Tagihan naik gila-gilaan dalam hitungan menit, dan ada EC2 instance baru ke-spawn di region yang bahkan gak pernah kita pake buat production. Jantung gue langsung deg-degan, karena gue tau persis apa artinya: ada orang lain yang lagi make akun cloud kita, dan dia lagi mining crypto pake duit kita.

Gue buru-buru buka konsol, revoke semua yang bisa di-revoke, matiin instance-nya, terus mulai bongkar. Dan di sinilah bagian yang bikin gue gak bisa tidur sampai pagi: pelakunya bukan hacker jagoan. Bukan exploit zero-day. Pelakunya adalah service account yang kita bikin sendiri enam bulan lalu, dengan policy AdministratorAccess nempel di badannya, dan access key-nya ke-commit ke repository publik gara-gara satu developer keceplosan nge-push file .env yang salah.

Malam itu gue belajar pelajaran paling mahal dalam karir cloud gue: di dunia cloud, identitas adalah perimeter baru. Dan kalau identitas lo terlalu kuat, satu kesalahan kecil udah cukup buat bikin semuanya runtuh.

Akar Masalahnya: Over-Permissioned Service Account

Biar lo kebayang, service account itu semacam "user robot" yang dipake buat kerjaan otomatis. Misalnya aplikasi yang butuh akses ke S3 buat nyimpen file, atau CI/CD yang butuh push ke ECR. Namanya robot, seharusnya dia cuma boleh ngelakuin satu-dua hal spesifik. Tapi kenyataannya, karena males mikir dan pengen cepet kelar, kita sering kasih dia AdministratorAccess. Masuk akal kan, kasih akses paling gede biar gak ada error "Access Denied" yang ganggu.

Itu keputusan yang keliatan pintar selama lima menit, dan jadi bom waktu selama berbulan-bulan.

Waktu gue retrospeksi, gue sadar ada beberapa kesalahan klasik yang bikin malam itu jadi parah banget. Pertama, kita gak pernah mikir "akses minimum". Service account buat aplikasi upload foto kok dikasih akses buat bikin EC2 instance? Buat bikin IAM user baru? Buat ngubah security group? Semua itu gak relevan sama kerjaannya, tapi karena policy-nya AdministratorAccess, dia bisa semua.

Kedua, access key-nya long-lived dan gak pernah dirotasi. Sekali ke-commit ke repo, key itu tetep valid selamanya sampai ada yang nemu. Gak ada expiry, gak ada rotasi otomatis, gak ada deteksi. Key itu nganggur di sana kayak kunci rumah yang ditaro di bawah keset, nunggu orang jahat lewat.

Ketiga, kita gak punya visibility. Gak ada yang namanya ngawasin siapa yang akses apa. Waktu key itu dipake dari IP asing buat spawn instance, gak ada satu pun alarm yang bunyi — kecuali alert billing yang untungnya masih kebangun.

Prinsip Least Privilege, Beneran Dipraktekin

Setelah insiden itu, gue mulai bener-bener ngerombak cara kita ngasih akses. Prinsip dasarnya cuma satu: kasih akses sekecil mungkin, secukupnya buat ngerjain tugas, dan gak lebih. Di atas kertas ini simple, tapi prakteknya butuh disiplin.

Pertama-tama, gue ganti pendekatan dari "kasih AdministratorAccess terus nanti dipersempit kalau error" jadi "mulai dari kosong, tambahin satu-satu izin yang bener-bener dibutuhin". Iya, ini lebih ribet. Awalnya bakal banyak nemu "Access Denied", dan setiap kali itu gue catat izin apa yang kurang, terus tambahin. Setelah beberapa iterasi, service account jadi punya policy yang ramping dan gak bisa dipake buat hal-hal di luar tugasnya.

Gue juga mulai pake role dengan permission boundary dan condition. Permission boundary itu ibarat pagar yang ngebatesin seberapa gede izin yang bisa dikasih — walaupun ada yang iseng kasih AdministratorAccess, tetap aja gak bisa tembus karena dibatasi pagar. Sementara condition itu bikin izin jadi bersyarat: misalnya cuma boleh akses kalau sumber IP-nya dari network kantor, atau cuma boleh ngapus bucket kalau request-nya pake MFA.

Satu hal yang paling ngefek menurut gue adalah memindahin dari long-lived access key ke temporary credentials. Pake IAM role yang dipanggil lewat STS, credential-nya otomatis expired dalam sejam dan gak perlu disimpen di file .env. Dengan gini, walaupun ada yang bocor, umurnya cuma sejam. Bandingin sama access key yang valid selamanya — jauh banget bedanya.

SCP dan Guardrail di Level Organisasi

Gue juga belajar satu hal yang sering kelewat: least privilege itu bukan cuma tanggung jawab masing-masing tim, tapi harus dijaga dari level paling atas. Di sini gue mulai pake Service Control Policies (SCP) buat nge-lock hal-hal yang gak boleh dilakuin siapa pun di seluruh organisasi. Contohnya: gak boleh matiin CloudTrail, gak boleh ngubah logging, gak boleh pake region tertentu yang gak kita pake. Ini guardrail yang bikin "kesalahan satu orang" gak langsung jadi bencana.

Analoginya gampang: kalau IAM policy itu ngatur siapa yang boleh masuk ruangan mana, SCP itu ngatur bahwa di gedung ini sama sekali gak ada pintu ke lantai yang berbahaya. Jadi walaupun ada yang salah kasih akses, tetap gak bisa masuk karena pintunya gak ada.

Deteksi Itu Sama Pentingnya dengan Pencegahan

Setelah semua guardrail dipasang, gue sadar kalau pencegahan aja gak cukup. Lo harus bisa ngedeteksi kalau ada yang salah. Di sinilah IAM Access Analyzer masuk. Tool ini ngebantu nemuin policy yang terlalu permisif, kayak resource yang kebuka ke publik atau role yang bisa di-assume sama akun luar. Gue sempet ngejalanin ini ke semua akun dan nemu beberapa S3 bucket yang policy-nya masih kebablasan, beberapa role yang bisa di-assume dari akun eksternal yang udah lama gak dipake, dan satu-dua policy yang sebenarnya nyalahin prinsip least privilege tanpa kita sadari.

Selain Access Analyzer, gue juga mulai rajin ngecek CloudTrail. Log semua aktivitas API itu penting banget — dari log ini lo bisa tau siapa ngapain, dari mana, pake credential apa. Waktu insiden malam itu terjadi, kalau aja kita udah pasang alerting di CloudTrail buat event yang mencurigakan (kayak RunInstances dari IP asing atau dari service account yang harusnya gak pernah bikin instance), mungkin kita bisa nangkep itu dalam hitungan menit, bukan setengah jam.

Kebiasaan Kecil yang Bikin Bedanya Besar

Yang paling gue sadari setelah semua ini adalah: security di cloud itu bukan proyek sekali jalan, tapi kebiasaan harian. Rotasi credential itu harus dijadwalin, bukan "nanti kalau sempet". Review policy itu harus rutin, bukan cuma pas ada insiden. Dan yang paling penting, budaya "kasih akses paling gede biar gampang" harus diganti jadi "kasih akses paling kecil, nanti dinaikin kalau perlu".

Gue mulai ngebuat checklist kecil buat diri sendiri setiap kali mau bikin service account baru: Apa persisnya tugas dia? Resource apa aja yang dia sentuh? Action apa yang dia butuhin (read, write, delete)? Bisa gak pake role temporary daripada key long-lived? Udah di-boundary belum? Siapa yang bakal nge-review? Lima pertanyaan ini kedengeran sepele, tapi efeknya gede banget buat mastiin gak ada lagi service account AdministratorAccess yang nganggur di pojokan.

Satu lagi yang gak kalah penting: pisahin environment. Service account buat production itu gak boleh sama dengan yang buat development. Key yang dipake CI/CD buat staging jangan pernah dipake buat production. Kalau terlanjur jadi satu, satu kebocoran di lingkungan yang paling santai langsung bisa ngerembet ke yang paling kritis.

Penutup

Malam itu gue kehilangan tidur, tapi gue dapet pelajaran yang gak akan gue lupain. Di cloud, lo gak cuma ngamankan server — lo ngamankan identitas. Dan identitas yang terlalu kuat itu sama bahayanya dengan identitas yang bocor, karena keduanya sama-sama ninggalin pintu kebuka.

Kalau lo sekarang lagi pegang satu akun cloud dan di sana masih ada service account dengan AdministratorAccess, gue cuma mau bilang satu hal: buka sekarang, persempit, dan rotasi key-nya. Jangan nunggu alert billing bunyi tengah malam buat nyadar bahwa kasih akses paling gede itu bukan solusi — itu justru akar masalahnya. Least privilege bukan sekadar jargon yang enak disebut di rapat; itu tameng yang nentuin apakah satu keceplosan kecil bakal jadi bencana atau cuma jadi catatan yang lo benahin lima menit.