IAM — Security best practices
Sebagian besar insiden keamanan AWS bukan hasil eksploitasi canggih, melainkan kredensial yang bocor dan izin yang terlalu lebar. Ini daftar penawarnya.
Intisari
- Kredensial sementara mengalahkan kredensial permanen — selalu, tanpa pengecualian.
- MFA untuk semua manusia; root disimpan dan tidak dipakai.
- Mulai dari izin lebar boleh, asal dipersempit pakai data pemakaian nyata (IAM Access Analyzer).
- Jangan tempelkan policy ke user satu per satu — pakai group atau permission set.
- Audit itu perbuatan berulang: Access Analyzer, credential report, dan last accessed adalah rutinitas, bukan proyek.
Urutan prioritas
Dokumen resminya panjang. Kalau kamu cuma sanggup mengerjakan lima hal, kerjakan lima ini — dampaknya paling besar per menit yang dihabiskan:
| # | Praktik | Kenapa ini duluan |
|---|---|---|
| 1 | Pakai kredensial sementara (Identity Center / role) | Menghapus seluruh kelas masalah "key bocor" |
| 2 | MFA untuk semua manusia, terutama root | Password bocor jadi tidak cukup untuk masuk |
| 3 | Simpan root, jangan dipakai | Satu-satunya identitas yang tidak bisa dibatasi |
| 4 | Least privilege, dipersempit berkala | Membatasi kerusakan saat sesuatu memang jebol |
| 5 | Nyalakan CloudTrail dan benar-benar dibaca | Tanpa jejak, kamu tidak tahu apa yang terjadi |
Least privilege yang realistis
Menulis policy sempurna dari nol itu tidak realistis — kamu belum tahu API apa saja yang dipanggil aplikasimu. Cara yang benar-benar berhasil adalah dua tahap:
- Mulai dengan izin yang cukup lebar di lingkungan pengembangan supaya kamu tidak terhambat.
- Setelah beberapa hari, buka IAM Access Analyzer yang menghasilkan policy dari aktivitas CloudTrail nyata, lalu ganti policy lebarmu dengan hasilnya.
Kolom Last accessed di konsol IAM juga menjawab satu pertanyaan yang mahal kalau ditebak: layanan mana yang izinnya diberikan tapi tidak pernah dipakai sama sekali. Itu kandidat penghapusan yang aman.
Yang sering keliru: "least privilege" dibaca sebagai "tulis policy paling ketat sejak awal". Yang benar: persempit berdasarkan bukti. Policy ketat yang ditulis berdasarkan tebakan biasanya salah di dua arah sekaligus — terlalu longgar di tempat yang berbahaya, terlalu ketat di tempat yang bikin aplikasi mati jam 2 pagi.
Yang khusus relevan untuk aplikasi GenAI
| Praktik | Bentuk konkretnya di Bedrock |
|---|---|
| Batasi model, bukan cuma layanan | Resource menunjuk ARN foundation model tertentu, bukan "*" |
| Kunci region | Condition pada aws:RequestedRegion — mencegah data mengalir ke region yang tidak kamu setujui |
| Pisahkan baca dan tulis pada knowledge base | bedrock:Retrieve untuk aplikasi, izin ingest hanya untuk pipeline |
| Jangan beri Lambda izin IAM | Fungsi yang bisa mengubah IAM bisa menaikkan hak aksesnya sendiri |
Rutinitas audit
| Alat | Menjawab |
|---|---|
| IAM Access Analyzer (external access) | Resource mana yang bisa diakses dari luar akunku? |
| IAM Access Analyzer (unused access) | Role dan izin mana yang menganggur? |
| Credential report | Masih ada access key jangka panjang? Sejak kapan? |
| CloudTrail | Siapa memanggil apa, kapan, dari mana? |
Latihan: unduh credential report dari konsol IAM dan pastikan tiga hal: root punya MFA, root tidak punya access key, dan tidak ada IAM user dengan access key aktif. Kalau salah satu tidak terpenuhi, perbaiki sekarang — sisa roadmap ini akan menambah izin di atas fondasi itu.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.