IAM AWS untuk Pemula — Cara Kelola Akses Cloud yang Aman dan Tidak Over-Privilege

Beberapa bulan lalu, saya dipanggil salah satu startup di Jakarta buat bantu mereka selesein masalah yang aneh. Jadi ceritanya, tiba-tiba AWS bill mereka melonjak 800% dalam satu bulan. Setelah saya check, ternyata ada puluhan EC2 instance GPU kelas atas (p4d.24xlarge — yang harganya sekitar $32 per jam!) nyala tanpa henti selama hampir tiga minggu. Siapa yang bikin? Salah satu developer magang yang bikin instance “buat eksperimen ML” terus lupa matiin. Gimana bisa magang bisa bikin instance semahal itu? Ya karena semua orang di perusahaan itu — termasuk anak magang — dikasih permission AdministratorAccess penuh. “Biar nggak ribet ngurusin permission,” kata CTO-nya. Padahal belajar IAM AWS untuk pemula itu investasi kecil yang nyegah bencana segede ini.

Nah, cerita tadi adalah contoh sempurna kenapa IAM AWS untuk pemula adalah topik yang kritis banget. IAM (Identity and Access Management) itu kayak sistem door access di kantor mewah — kamu harus nentuin siapa yang boleh masuk ruangan mana, dan jam berapa. Kalau semua orang dikasih master key yang bisa buka semua pintu (termasuk ruang server dan brankas), cepat atau lambat bakal ada bencana.

Apa Itu IAM AWS?

Jadi, IAM AWS adalah layanan AWS yang ngatur identitas (siapa yang melakukan sesuatu) dan akses (apa yang boleh mereka lakukan). Sederhananya: IAM itu satu-satunya gerbang autentikasi dan otorisasi di ekosistem AWS kamu. Mau akses console management, pake CLI, jalanin Lambda function, atau deploy lewat Terraform — semuanya lewat IAM. Dan karena sifatnya yang global (IAM itu service global, bukan regional kayak EC2), artinya sekali kamu bikin IAM entity, dia berlaku di seluruh region AWS.

Buat pemula, IAM sering kali terasa intimidating. Console-nya banyak menu, terminology-nya banyak banget, dan dokumentasi AWS-nya… well, kadang terasa kayak baca buku telepon. Tapi tenang, di artikel ini saya bakal jelasin dengan bahasa manusia normal. Sebagai seseorang yang udah 8 tahun berkecimpung di security — dan udah terlalu sering liat IAM configuration yang kacau balau — saya janji bakal jelasin semuanya dengan sederhana.

User, Group, dan Role — Kapan Pakai yang Mana?

Pertama-tama, kamu harus paham tiga aktor utama di IAM: User, Group, dan Role.

IAM User — Buat Manusia (atau Aplikasi Lama)

IAM User adalah identitas individual untuk manusia (atau kadang aplikasi) yang butuh akses ke AWS. Setiap user punya credential sendiri — bisa berupa password (buat login ke console) atau access key (buat CLI/SDK/API calls).

Aturan emas: satu manusia = satu IAM user. Jangan bikin user barengan kayak “tim-dev” yang dipakai rame-rame. Kenapa? Karena kalau nanti ada insiden keamanan — misalnya ada yang ngehapus production database — kamu nggak bisa trace siapa yang ngelakuin. CloudTrail cuma nyatet “User: tim-dev melakukan DeleteTable” — dan semua orang di tim dev bisa nunjuk orang lain.

IAM User Group — Buat Mengelompokkan User dengan Job yang Sama

Daripada attach policy ke user satu-satu (yang cepat atau lambat bakal jadi maintenance nightmare), gunakan IAM Group. Misalnya, semua developer backend masuk ke grup “BackendDevs”, semua data engineer masuk ke “DataEngineers”. Policy-nya di-attach ke grup, bukan ke user individual. Jadi kalau ada developer baru masuk, tinggal masukin ke grup — udah otomatis dapet permission yang sesuai.

Saya biasanya bikin grup berdasarkan fungsi, bukan berdasarkan hierarki organisasi. Jadi bukan grup “Division-X” atau “Squad-Y”, tapi grup seperti “DatabaseAdmins”, “ServerlessDevelopers”, “NetworkEngineers”. Lebih gampang dikelola dari sisi permission.

IAM Role — Buat Aplikasi dan Service

Role adalah konsep yang paling powerful dan paling sering disalahpahami di IAM. Berbeda dengan User yang punya credential permanen (password atau access key), Role ngasih temporary credential yang otomatis di-rotate. Role dipakai sama AWS services (EC2, Lambda, ECS, dll) atau buat cross-account access.

Contoh paling umum: EC2 instance kamu butuh akses baca dari S3 bucket. Daripada hardcode access key di dalam instance (yang bahaya banget), kamu attach IAM Role ke instance tersebut. AWS secara otomatis ngasih temporary credential lewat Instance Metadata Service (IMDS) dan me-rotate-nya secara berkala. Kalau credential ini bocor, dia cuma valid beberapa jam — bukan selamanya kayak access key.

Prinsipnya gampang: manusia pakai User, service/aplikasi pakai Role. Jangan campur-campur.

Cara Bikin IAM Policy yang Least Privilege

Sekarang masuk ke bagian yang paling krusial: IAM Policy. Policy adalah JSON document yang mendefinisikan permission — siapa boleh ngapain ke resource apa.

Memahami Struktur Policy

Policy punya beberapa elemen kunci:

• Effect: Allow atau Deny
• Action: operasi API yang diizinkan (contoh: s3:GetObject)
• Resource: resource AWS mana yang dimaksud (bisa spesifik ARN atau wildcard *)
• Condition (opsional): syarat tambahan (contoh: cuma bisa akses dari IP tertentu)

Jangan Pernah Pakai Wildcard * Sendirian

Ini dosa terbesar di IAM. Policy kayak gini:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

adalah kunci surga buat siapa aja yang dapet akses ke credential tersebut. Dengan policy ini, seseorang bisa bikin resource apapun, hapus apapun, bahkan bikin user baru dengan permission lebih tinggi. Ini yang bikin kasus developer magang bisa bikin GPU instance mahal.

Sebagai gantinya, spesifikkan Action dan Resource. Misalnya buat developer yang cuma perlu akses ke S3 bucket tertentu:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
  "Resource": [
    "arn:aws:s3:::myapp-dev-bucket",
    "arn:aws:s3:::myapp-dev-bucket/*"
  ]
}

Lihat perbedaannya? Sekarang dia cuma bisa baca/tulis di satu bucket spesifik. Nggak bisa bikin EC2, nggak bisa akses database, nggak bisa ngapa-ngapain selain tiga operasi itu.

Gunakan AWS Managed Policy Sebagai Starting Point

AWS nyediain banyak Managed Policy siap pakai — misalnya ReadOnlyAccess, AmazonS3FullAccess, AWSLambdaBasicExecutionRole. Ini bisa jadi starting point yang bagus. Tapi jangan langsung pakai mentah-mentah. Review dulu policy-nya, pastiin sesuai sama kebutuhan kamu, dan kalau bisa, modifikasi biar lebih restrictive.

Manfaatkan Condition Keys

Condition keys adalah fitur yang powerful banget tapi jarang dipakai. Contohnya, kamu bisa bikin policy yang cuma mengizinkan akses dari IP kantor:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Atau cuma izinkan akses selama jam kerja:

{
  "Condition": {
    "DateGreaterThan": {"aws:CurrentTime": "2022-01-01T09:00:00Z"},
    "DateLessThan": {"aws:CurrentTime": "2022-01-01T18:00:00Z"}
  }
}

Atau mewajibkan MFA:

{
  "Condition": {
    "Bool": {"aws:MultiFactorAuthPresent": "true"}
  }
}

Condition keys ini ibarat lapisan keamanan tambahan yang bisa nyegah banyak skenario serangan.

Kesalahan Umum yang Sering Banget Terjadi

Pakai Root Account Buat Operasional

Root account itu kayak tombol nuklir. Dia punya akses tak terbatas ke semua hal, termasuk billing, penghapusan akun, dan perubahan setting fundamental yang nggak bisa dilakukan user biasa. Root account harus dikunci mati: enable MFA hardware (bukan virtual MFA yang lebih gampang di-phishing), simpan credential-nya di tempat aman (idealnya di safe fisik atau password manager offline), dan jangan pernah dipakai buat kegiatan sehari-hari.

Shared Access Key

Ini kebiasaan buruk yang sering saya liat. Satu access key dishare ke seluruh tim lewat group chat, file share, atau bahkan di-hardcode ke private git repo. Access key yang dishare itu ibarat kunci rumah yang difotokopi buat semua anggota keluarga besar. Begitu satu orang kehilangan kuncinya, semua orang harus ganti kunci.

Solusinya: bikin IAM user individual buat tiap orang (atau lebih baik lagi, federasi dengan SSO seperti AWS SSO atau Okta). Rotasi access key secara berkala — minimal 90 hari sekali. Matiin access key yang udah nggak kepakai.

Lupa Enable MFA

Saya masih sering nemuin IAM user dengan permission AdministratorAccess tapi tanpa MFA. Satu phished password aja, dan attacker literally bisa ngapain aja di akun AWS kamu. MFA adalah salah satu kontrol keamanan paling murah dan paling efektif yang ada. Nggak ada alasan buat nggak pakai.

Nggak Menggunakan IAM Access Analyzer

IAM Access Analyzer itu tools gratis dari AWS yang bisa identifikasi resource di akun kamu yang bisa diakses dari luar (publicly accessible atau cross-account). Ini tools super underrated. Seringkali kamu nggak sadar ada S3 bucket, KMS key, atau Lambda function yang policy-nya kelewat longgar, dan Access Analyzer bakal nge-flag itu. Cukup sekali klik buat enable, dan hasilnya bisa jadi buka mata banget.

Password Policy yang Terlalu Lemah

Kalau kamu masih pakai IAM user (bukan federasi SSO), pastiin password policy kamu strong. Minimal: minimum 14 karakter, wajib campur uppercase/lowercase/angka/simbol, expire setiap 90 hari, dan nggak boleh reuse 5 password terakhir. Ini setting yang ada di IAM dashboard — cuma butuh 2 menit buat setup.

Strategi Implementasi IAM di Dunia Nyata

Jadi gimana cara terbaik buat mulai nerapin IAM yang bener? Ini pendekatan yang biasa saya rekomendasikan ke klien:

Tahap 1: Audit. Gunakan IAM Access Analyzer dan AWS Security Hub buat dapetin gambaran kondisi IAM kamu sekarang. Fokus ke finding yang critical dulu: user tanpa MFA, policy dengan wildcard *:*, access key yang udah lama aktif.

Tahap 2: Bersihkan. Hapus user yang nggak aktif. Matiin access key yang nggak kepakai. Replacе policy wildcard dengan policy spesifik. Enable MFA di semua user (terutama yang punya akses privileged).

Tahap 3: Standardisasi. Bikin grup berdasarkan fungsi kerja. Bikin custom policy yang sesuai kebutuhan masing-masing grup. Setup password policy yang kuat.

Tahap 4: Otomasi. Gunakan AWS Organizations dan SCP (Service Control Policies) buat enforce guardrail di level organisasi. Integrasikan IAM dengan sistem SSO yang ada. Setup notifikasi otomatis untuk perubahan-perubahan kritis.

Tahap 5: Monitor. Aktifkan CloudTrail di semua region. Setup CloudWatch alarm untuk event-event mencurigakan. Review laporan IAM Credential Report secara berkala (seminggu sekali minimal).

Ingat: IAM itu bukan set-and-forget. Ini continuous process. Begitu kamu pikir semuanya udah aman, biasanya justru di situ ada yang kelewat.

Penutup

IAM AWS untuk pemula mungkin terlihat overwhelming di awal. Banyak istilah, banyak konsep, banyak best practice. Tapi percayalah, investasi waktu buat belajar IAM sekarang bakal nyegah sakit kepala (dan sakit dompet) yang jauh lebih besar di masa depan. Mulailah dari yang sederhana: enable MFA, jangan pakai root account, jangan kasih AdministratorAccess ke sembarang orang, dan review policy secara berkala.

Kalau mau tes pemahaman kamu, coba login ke IAM console sekarang, liat daftar user yang ada, dan tanya ke diri sendiri: “Apa bener semua orang ini butuh akses yang mereka punya sekarang?” Kalau jawabannya “nggak yakin”, berarti udah waktunya buat audit IAM. Let me know di kolom komentar kalau kamu nemuin hal-hal mengejutkan di IAM audit kamu — saya penasaran!