IAM Group vs Kebijakan Langsung ke User: Mana yang Lebih Baik?

Saat tim engineering berkembang dari 3 orang menjadi 30 orang, pola 'attach policy langsung ke setiap user' mulai terasa seperti utang teknis yang menagih bunga setiap minggu — ada user yang kebanyakan izin, ada yang kekurangan, dan tidak ada yang tahu persis siapa punya akses apa. IAM Group hadir untuk menyelesaikan masalah ini, tapi banyak tim yang salah memahami kapan dan bagaimana menggunakannya secara efektif.

TL;DR: IAM Group vs Kebijakan Langsung ke User

Aspek	Kebijakan Langsung ke User	IAM Group
Skalabilitas	Sulit — setiap user dikelola terpisah	Baik — ubah satu group, berlaku ke semua anggota
Audit & Visibilitas	Harus cek per user satu per satu	Cukup cek policy di group
Risiko Konfigurasi Salah	Tinggi — inkonsistensi antar user	Rendah — konsistensi terjamin di level group
Batas Kebijakan	Maks 10 managed policies per user	Maks 10 managed policies per group, user bisa di banyak group
Onboarding Developer Baru	Harus assign ulang semua policy	Cukup tambah user ke group yang tepat
Rekomendasi AWS	Tidak direkomendasikan untuk tim	Direkomendasikan sebagai praktik terbaik

Bagaimana IAM Group Bekerja

IAM Group bukan entitas yang bisa melakukan autentikasi sendiri — group tidak punya credentials, tidak bisa diasumsikan sebagai role, dan tidak muncul sebagai principal dalam resource policy. Group adalah mekanisme agregasi kebijakan: ketika user menjadi anggota group, semua managed policy dan inline policy yang melekat pada group tersebut secara efektif berlaku untuk user itu juga.

Evaluasi izin IAM tetap mengikuti logika standar: semua policy yang berlaku untuk user (baik dari user langsung, dari group, maupun dari session policy jika menggunakan role) dievaluasi secara bersamaan. Explicit Deny dari mana pun akan selalu menang atas Allow, terlepas dari sumbernya.

graph TD User["IAM User
john.doe"] --> Group["IAM Group
Developers"] Group --> P1["Managed Policy
EC2ReadOnlyAccess"] Group --> P2["Customer Managed Policy
DeveloperS3ReadAccess"] User --> DirectP["Policy Langsung ke User
(Hindari pola ini)"] P1 --> Eval["Evaluasi IAM
Semua policy digabung"] P2 --> Eval DirectP --> Eval Eval --> Deny{"Ada Explicit Deny?"} Deny -- Ya --> Block["Akses Ditolak"] Deny -- Tidak --> Allow{"Ada Allow?"} Allow -- Ya --> Grant["Akses Diberikan"] Allow -- Tidak --> Block2["Akses Ditolak"]

IAM User menjadi anggota satu atau lebih IAM Group.
Setiap group membawa satu atau beberapa managed policy (misalnya AmazonS3ReadOnlyAccess untuk group Developers).
Saat user melakukan API call, IAM mengevaluasi semua policy yang berlaku — dari user langsung, dari semua group yang diikuti, dan dari permission boundary jika ada.
Explicit Deny dari sumber mana pun memblokir akses, terlepas dari Allow yang ada di tempat lain.

Mengapa Kebijakan Langsung ke User Bermasalah di Skala Tim

Bayangkan Anda punya 15 developer. Hari ini, tim memutuskan semua developer perlu akses read-only ke CloudWatch Logs. Dengan pola kebijakan langsung, Anda harus attach policy ke 15 user satu per satu. Minggu depan ada developer baru — lagi-lagi manual. Dua bulan kemudian, Anda ingin mencabut akses tertentu karena audit keamanan, dan Anda harus ingat siapa saja yang pernah diberi akses itu.

Ini bukan sekadar masalah efisiensi. Inkonsistensi yang muncul dari proses manual adalah sumber nyata dari security misconfiguration. Satu user yang terlupakan saat pencabutan akses sudah cukup untuk menjadi temuan audit.

Mengelola izin per user itu seperti mengunci setiap laci meja dengan kunci yang berbeda-beda — secara teknis bisa, tapi saat Anda perlu mengganti semua kunci sekaligus, Anda baru sadar betapa mahalnya keputusan itu.

Implementasi IAM Group untuk Tim Developer

Berikut adalah alur kerja praktis untuk membuat group Developers, melampirkan policy, dan menambahkan user ke dalamnya menggunakan AWS CLI.

Langkah 1: Buat IAM Group

Mulai dengan membuat group. Penamaan yang konsisten penting — gunakan konvensi yang mencerminkan fungsi, bukan nama tim yang bisa berubah.

aws iam create-group \
  --group-name Developers

Langkah 2: Lampirkan Managed Policy ke Group

Daripada menulis inline policy dari nol, gunakan AWS managed policy sebagai baseline, lalu tambahkan customer managed policy untuk kebutuhan spesifik. Contoh berikut melampirkan akses read-only ke Amazon EC2 — sesuaikan dengan kebutuhan aktual tim Anda.

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Langkah 3: Tambahkan User ke Group

Onboarding developer baru kini cukup satu perintah. Semua izin yang melekat pada group langsung berlaku tanpa perlu konfigurasi tambahan per user.

aws iam add-user-to-group \
  --group-name Developers \
  --user-name john.doe

Langkah 4: Verifikasi Keanggotaan dan Policy yang Berlaku

Setelah setup, verifikasi bahwa user benar-benar terdaftar di group dan policy sudah terlampir dengan benar — jangan asumsikan perintah berhasil tanpa konfirmasi.

# Cek anggota group
aws iam get-group \
  --group-name Developers

# Cek policy yang melekat pada group
aws iam list-attached-group-policies \
  --group-name Developers

# Cek semua group yang diikuti user tertentu
aws iam list-groups-for-user \
  --user-name john.doe

Membuat Customer Managed Policy untuk Kebutuhan Spesifik

AWS managed policy memberikan izin yang cukup luas. Untuk tim yang butuh kontrol lebih granular — misalnya developer hanya boleh akses S3 bucket tertentu — buat customer managed policy sendiri, lalu lampirkan ke group.

🔽 Klik untuk melihat contoh customer managed policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::nama-bucket-project-anda",
        "arn:aws:s3:::nama-bucket-project-anda/*"
      ]
    }
  ]
}

Simpan file di atas sebagai dev-s3-policy.json, lalu buat dan lampirkan policy tersebut:

# Buat customer managed policy
aws iam create-policy \
  --policy-name DeveloperS3ReadAccess \
  --policy-document file://dev-s3-policy.json

# Lampirkan ke group (ganti 123456789012 dengan Account ID Anda)
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/DeveloperS3ReadAccess

Pola Multi-Group: Satu User, Beberapa Peran

Satu user IAM bisa menjadi anggota hingga 10 group sekaligus. Ini memungkinkan model komposisi izin yang fleksibel — misalnya seorang tech lead yang juga mengelola infrastruktur bisa masuk ke group Developers sekaligus group Ops.

graph LR Alice["User: alice
Tech Lead"] --> DevGroup["Group: Developers
EC2Read, S3Read"] Alice --> OpsGroup["Group: Ops
CloudWatchFull, EC2Full"] Bob["User: bob
Developer"] --> DevGroup DevGroup --> PolicyDev["Policy Set A"] OpsGroup --> PolicyOps["Policy Set B"] PolicyDev --> EffAlice["Izin Efektif Alice
= A + B"] PolicyOps --> EffAlice PolicyDev --> EffBob["Izin Efektif Bob
= A saja"]

User alice adalah anggota group Developers dan Ops sekaligus.
Izin efektif alice adalah gabungan dari semua policy yang melekat pada kedua group tersebut, ditambah policy langsung ke user jika ada.
User bob hanya di group Developers — izinnya lebih terbatas sesuai perannya.
Explicit Deny di salah satu policy mana pun akan memblokir akses tersebut untuk user yang bersangkutan.

Pengalaman Lapangan: Ketika Asumsi Salah Menyebabkan Eskalasi Izin

Ini pola yang sering terjadi: tim membuat group Developers dan melampirkan beberapa policy. Beberapa bulan kemudian, seseorang menambahkan policy baru langsung ke user tertentu karena 'butuh cepat untuk deadline'. Policy itu tidak pernah dicabut.

Saat audit, ditemukan bahwa user tersebut punya akses ke resource yang tidak seharusnya — bukan karena group-nya salah, tapi karena ada policy inline yang tersembunyi langsung di user. Perintah list-attached-group-policies tidak akan menampilkan ini. Anda harus cek terpisah:

# Cek policy yang melekat langsung ke user (bukan dari group)
aws iam list-attached-user-policies \
  --user-name john.doe

# Cek inline policy yang langsung ditulis di user
aws iam list-user-policies \
  --user-name john.doe

Jika kedua perintah ini mengembalikan hasil yang tidak kosong untuk user biasa, itu sinyal bahwa ada izin yang dikelola di luar group — dan perlu dievaluasi ulang.

Insight penting: kebersihan IAM bukan kondisi awal, melainkan kondisi yang harus dijaga secara aktif.

Batas dan Keterbatasan IAM Group yang Perlu Diketahui

Beberapa batasan IAM Group yang terdokumentasi dan perlu diperhitungkan saat merancang struktur izin:

Satu user IAM dapat menjadi anggota maksimal 10 group.
Satu group dapat memiliki maksimal 10 managed policy yang terlampir.
IAM Group tidak bisa bersarang — group tidak bisa menjadi anggota group lain.
Group tidak bisa diasumsikan sebagai principal dalam resource-based policy (seperti S3 bucket policy). Hanya IAM user, role, dan service yang bisa menjadi principal.
Batas jumlah group per akun AWS bervariasi — selalu periksa Service Quotas di konsol AWS untuk nilai terkini.

Ketidakmampuan group untuk bersarang sering mengejutkan engineer yang terbiasa dengan sistem direktori seperti Active Directory. Di IAM, hierarki organisasi harus dimodelkan melalui kombinasi group dan role, bukan melalui group bertingkat.

IAM Group dan Integrasi dengan Permission Boundary

Permission boundary adalah fitur lanjutan yang membatasi izin maksimum yang bisa dimiliki user atau role, terlepas dari policy apa yang melekat padanya — termasuk policy dari group. Jika tim Anda menggunakan permission boundary, pastikan boundary tersebut tidak secara tidak sengaja memblokir izin yang diberikan melalui group.

# Cek permission boundary yang berlaku untuk user
aws iam get-user \
  --user-name john.doe

Output akan menyertakan field PermissionsBoundary jika boundary sedang aktif. Jika ada izin dari group yang tidak bekerja seperti yang diharapkan, permission boundary adalah lapisan pertama yang harus diperiksa — bukan policy group-nya.

Menggunakan IAM Group: Kesimpulan dan Langkah Selanjutnya

Jawaban singkatnya: gunakan IAM Group, bukan kebijakan langsung ke user, untuk hampir semua skenario tim. Pola group memberikan konsistensi, kemudahan audit, dan skalabilitas yang tidak bisa dicapai dengan pengelolaan per user. Kebijakan langsung ke user hanya masuk akal untuk kasus yang benar-benar unik dan terisolasi — dan bahkan di sana, pertimbangkan apakah IAM Role tidak lebih tepat.

Untuk tim yang sudah terlanjur menggunakan pola per user, AWS IAM Access Analyzer dan AWS Config dapat membantu mengidentifikasi user mana yang masih punya policy langsung yang perlu dimigrasikan ke group.

Glosarium

Istilah	Penjelasan
IAM Group	Koleksi IAM user yang berbagi satu set policy. Group sendiri tidak punya credentials dan tidak bisa melakukan autentikasi.
Managed Policy	Policy IAM yang berdiri sendiri sebagai resource AWS, bisa dilampirkan ke user, group, atau role. Tersedia dalam dua jenis: AWS managed dan customer managed.
Inline Policy	Policy yang ditulis langsung dan tertanam di dalam satu entitas IAM (user, group, atau role). Tidak bisa digunakan ulang di entitas lain.
Permission Boundary	Managed policy yang digunakan sebagai batas maksimum izin untuk user atau role. Izin efektif adalah irisan antara policy yang berlaku dan boundary.
Explicit Deny	Pernyataan `"Effect": "Deny"` dalam policy IAM yang selalu menang atas Allow dari sumber mana pun dalam evaluasi izin.

Cari Blog Ini

SW BBANG I