Mulai dari analogi sebelum masuk definisi.

Bayangkan akun AWS seperti gedung besar berisi ruang server, brankas data, ruang tagihan, dan panel kontrol.

Di gedung biasa, tidak semua orang boleh masuk ke semua ruangan. Resepsionis boleh melihat daftar tamu, teknisi boleh masuk ruang mesin, tim keuangan boleh masuk ruang tagihan, tetapi tamu tidak boleh membuka brankas. IAM, singkatan dari AWS Identity and Access Management, melakukan hal yang sama untuk AWS: menentukan siapa yang boleh masuk, apa yang boleh dilakukan, dan ke resource mana akses itu berlaku.

IAM bukan layanan untuk menyimpan data aplikasi. IAM adalah layanan keamanan inti untuk mengelola identitas dan izin. Di level CLF-C02, kamu tidak perlu menjadi ahli menulis policy kompleks, tetapi kamu harus bisa membaca skenario dan memilih pola akses yang aman.

Dua sifat IAM yang penting kamu ingat sejak awal: IAM adalah layanan global, bukan regional, sehingga user, group, role, dan policy yang kamu buat berlaku di seluruh Region tanpa perlu menyalinnya satu per satu. IAM juga gratis, tidak ada biaya tambahan untuk memakai layanan IAM itu sendiri. AWS menyebutnya secara eksplisit: IAM ditawarkan tanpa biaya tambahan. Lihat sumber resmi: AWS IAM FAQs.

AWS menempatkan IAM sangat penting karena domain Security and Compliance memiliki bobot besar di CLF-C02. Exam guide resmi CLF-C02 menempatkan domain Security and Compliance sebesar 30% dan Cloud Technology and Services sebesar 34%, jadi IAM sering muncul sebagai fondasi untuk banyak soal keamanan dan layanan.

Istilah yang wajib hafal sebelum praktik.

IAM terdiri dari beberapa benda kecil yang bekerja bersama, seperti sistem akses kantor modern.

Definisi paling sederhana: authentication menjawab “siapa kamu?”, sedangkan authorization menjawab “kamu boleh melakukan apa?”. IAM mengelola keduanya, tetapi inti ujian sering menanyakan authorization melalui policy, role, dan prinsip least privilege.

Satu istilah lagi yang menyatukan semuanya adalah principal. Principal adalah entitas yang melakukan request ke AWS: bisa root user, IAM user, IAM role yang sedang diasumsikan, atau federated user. Saat kamu membaca soal, ubah kalimatnya menjadi pertanyaan IAM: principal mana yang bertindak, action apa yang diminta, dan ke resource mana, lalu apakah ada policy yang mengizinkan tanpa ada yang menolak.

Tiga komponen yang sering muncul di awal belajar IAM.

User adalah orang atau beban kerja, group adalah departemen, policy adalah aturan akses tertulis.

User

IAM user merepresentasikan identitas di akun AWS dan memiliki kredensial jangka panjang, misalnya password untuk console atau access key untuk akses programatik. AWS best practices saat ini mendorong penggunaan federation dan IAM Identity Center untuk manusia, lalu IAM user hanya untuk use case spesifik yang belum didukung federated users. Namun, untuk belajar dasar IAM, user tetap penting karena menjelaskan cara izin bekerja secara paling gamblang.

Group

Group memudahkan administrasi. Daripada menempel policy ReadOnlyAccess ke 20 user satu per satu, kamu membuat group Auditor, lalu menempel policy ke group itu. Saat user baru masuk tim audit, cukup masukkan ke group dan ia langsung mewarisi semua izinnya. Saat ia pindah tim, cukup keluarkan dari group. Inilah kenapa group membuat izin mudah dirawat: kamu mengelola izin di satu tempat, bukan di tiap orang.

Ada beberapa aturan group yang sering jadi jebakan. Group bukan identitas yang bisa login, ia hanya wadah. Group tidak bisa berisi group lain (tidak ada nested group). Satu user boleh menjadi anggota banyak group sekaligus, dan izinnya adalah gabungan dari semua group plus policy yang menempel langsung padanya.

Policy

Policy adalah dokumen izin berformat JSON. Prinsip utamanya adalah least privilege, yaitu memberi izin minimum yang dibutuhkan untuk menyelesaikan tugas, tidak lebih. Policy yang terlalu luas seperti AdministratorAccess untuk semua orang terlihat praktis di awal, tetapi berbahaya di dunia nyata dan hampir selalu menjadi jawaban yang salah di ujian.

Kenapa least privilege bukan sekadar slogan? Karena setiap izin yang kamu berikan adalah pintu yang bisa disalahgunakan, baik oleh penyerang yang mencuri kredensial maupun oleh kesalahan tangan sendiri. Jika seorang auditor hanya butuh membaca, lalu kredensialnya bocor, kerusakan terbatas pada “bisa dilihat”. Jika auditor itu punya AdministratorAccess, kebocoran yang sama bisa menghapus seluruh akun. Least privilege memperkecil “ledakan” saat sesuatu salah, bukan menyusahkan pekerjaan sehari-hari.

Contoh JSON policy singkat

Berikut satu policy yang mengizinkan membaca objek dari satu bucket S3 saja. Perhatikan kurung kurawal yang menandai awal dan akhir dokumen.

{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::laporan-keuangan/*"
  }
]
}

Mari bedah baris per baris agar JSON tidak terasa menakutkan:

Inilah least privilege dalam wujud nyata: policy di atas hanya membolehkan s3:GetObject pada satu bucket. Ia tidak bisa menghapus objek (s3:DeleteObject), tidak bisa menyentuh bucket lain, dan tidak bisa membuat user IAM. Jika kebutuhan auditor cuma membaca, izin yang lebih besar dari ini adalah risiko tanpa manfaat.

Kunci utama harus disimpan paling aman.

Root user adalah pemilik seluruh gedung, jadi jangan dipakai untuk kegiatan harian.

Saat akun AWS pertama dibuat, root user memiliki akses penuh ke semua layanan dan resource, termasuk hal yang tidak bisa didelegasikan ke IAM user biasa seperti menutup akun atau mengubah AWS Support plan. AWS merekomendasikan root user tidak dipakai untuk tugas harian. Gunakan root user hanya untuk tugas tertentu yang memang memerlukan root, lalu amankan dengan password kuat dan MFA. Lihat sumber resmi: AWS, Root user best practices.

MFA menambahkan lapisan keamanan kedua. Password adalah sesuatu yang kamu tahu, sedangkan perangkat MFA adalah sesuatu yang kamu punya. Jika password bocor, penyerang tetap perlu faktor kedua yang ada secara fisik di tangan pemilik akun, sehingga kebocoran satu faktor saja tidak cukup untuk masuk.

Tipe MFA yang tersedia 2026

AWS kini mendukung tiga jenis perangkat MFA: passkey dan security key berbasis FIDO (misalnya YubiKey atau passkey bawaan perangkat), aplikasi autentikator virtual yang menghasilkan kode TOTP (misalnya Google Authenticator, Authy, atau Duo), dan hardware TOTP token fisik. Root user dan IAM user dapat mendaftarkan hingga delapan MFA device dari tipe mana pun, sehingga akun tidak terkunci hanya karena satu perangkat hilang. Lihat sumber resmi: AWS, Using MFA in AWS.

Simultaneous sign-in

Di AWS Console, beberapa identitas bisa masuk di browser berbeda, profil browser berbeda, atau mode incognito. Dalam praktik belajar, ini membantu membandingkan pengalaman root user, admin, dan user terbatas secara berdampingan. Namun di pekerjaan nyata, jangan berbagi kredensial. Setiap orang harus punya identitas sendiri agar audit trail jelas dan bisa ditelusuri di CloudTrail.

Cara program dan terminal berbicara dengan AWS.

Console seperti dashboard mobil, CLI seperti perintah langsung ke mesin, SDK seperti library untuk aplikasi.

AWS Management Console dipakai lewat browser. AWS CLI dipakai lewat terminal. AWS SDK dipakai oleh kode aplikasi. Ketiganya pada akhirnya memanggil API AWS yang sama, dan agar CLI atau SDK boleh memanggil API itu, mereka membutuhkan kredensial.

Access key adalah kredensial jangka panjang untuk menandatangani request programatik ke AWS CLI, AWS API, atau AWS SDK. Ia terdiri dari access key ID (semacam username) dan secret access key (semacam password). Karena access key jangka panjang berisiko bocor dan tidak otomatis kedaluwarsa, AWS merekomendasikan penggunaan role dan kredensial sementara bila memungkinkan.

Perintah yang aman untuk latihan

aws sts get-caller-identity
aws iam get-user
aws iam list-account-aliases

Perintah aws sts get-caller-identity berguna untuk memastikan identitas apa yang sedang dipakai CLI: ia mengembalikan account ID, user ID, dan ARN. Ini seperti melihat kartu akses yang sedang kamu pegang sebelum membuka pintu, sehingga kamu tidak salah mengira sedang memakai user terbatas padahal sebenarnya sedang sebagai admin.

Pola akses yang paling sering benar untuk layanan AWS.

Role seperti kartu akses tamu yang berlaku sementara dan otomatis dicabut saat waktunya habis.

IAM role tidak memiliki password atau access key permanen seperti user. Role diasumsikan (assume) oleh principal, misalnya layanan AWS, aplikasi, federated user, atau akun AWS lain. Setiap role punya dua bagian: trust policy yang menentukan siapa boleh mengasumsikannya, dan permissions policy yang menentukan apa yang boleh dilakukan setelah diasumsikan. Setelah role diasumsikan, AWS Security Token Service (STS) memberikan kredensial sementara dengan masa berlaku terbatas, lalu kredensial itu hangus sendiri.

Kenapa kredensial sementara lebih aman? Karena ia kedaluwarsa otomatis. Access key statis akan terus berlaku sampai seseorang ingat untuk mencabutnya; bila bocor hari ini dan baru ketahuan tiga bulan lagi, penyerang punya tiga bulan akses. Kredensial sementara dari STS hidup hanya dalam hitungan jam, jadi jendela penyalahgunaannya jauh lebih sempit. Sebagai gambaran, AssumeRole default-nya sekitar 1 jam (dapat dikonfigurasi hingga 12 jam tergantung pengaturan role), sementara token sesi seperti GetSessionToken default 12 jam dengan maksimum 36 jam. Untuk CLF-C02 kamu tidak perlu menghafal angka pastinya; cukup ingat polanya: sementara dan berumur pendek lebih aman daripada permanen.

Contoh paling penting: aplikasi di EC2 perlu membaca objek dari S3. Pemula mungkin ingin menyimpan access key di dalam server. Pola AWS yang lebih aman adalah membuat IAM role dengan izin S3 yang dibutuhkan, lalu menempelkan role itu ke EC2. AWS SDK dan CLI di instance dapat mengambil kredensial sementara secara otomatis melalui instance metadata, sehingga tidak ada access key yang pernah ditulis di kode atau di disk server.

Contoh skenario nyata

Alur sederhana dari login sampai izin diputuskan.

Setiap request AWS melewati pertanyaan dasar: siapa, mau apa, ke resource mana, dan apakah diizinkan.

Saat sebuah request sampai ke AWS, IAM tidak menebak. Ia menjalankan urutan evaluasi yang sama setiap kali. Memahami urutan ini membuat banyak soal CLF-C02 langsung jelas, karena jawaban yang benar biasanya mengikuti aturan ini, bukan intuisi.

Ada tiga aturan emas yang menjelaskan keputusan akhir, dan ketiganya layak kamu hafal:

Untuk CLF-C02, kamu cukup memahami tiga aturan ini. Detail evaluasi policy yang sangat dalam, seperti urutan tepat resource policy versus permission boundary, lebih cocok untuk level Associate atau Specialty. Yang penting kamu ingat: default deny, butuh allow, dan explicit deny mengalahkan allow. Lihat sumber resmi: AWS, Policy evaluation logic.

Walkthrough ringan tanpa harus menghafal semua klik console.

Tujuan hands-on IAM bukan klik cepat, tetapi memahami pola aman yang akan kamu pilih di ujian.

Latihan 1, buat user baca-saja

Latihan 2, pakai CloudShell untuk mengecek identitas

Latihan 3, role untuk layanan

Alat audit ringan yang sering disebut di materi AWS dasar.

IAM bukan hanya membuat user dan policy, tetapi juga memeriksa apakah akses sudah aman dan tidak berlebihan.

Credential report sangat berguna untuk pertanyaan audit dasar. Misalnya, “bagaimana melihat IAM user mana yang belum mengaktifkan MFA?” Jawaban yang masuk akal adalah menggunakan IAM credential report, yang merangkum status MFA, password, dan access key tiap user dalam satu file.

IAM Access Analyzer: gratis atau berbayar?

IAM Access Analyzer punya beberapa fungsi dengan model biaya berbeda, dan ini sering membingungkan saat melihat tagihan. External access analyzer (menemukan resource yang bisa diakses dari luar akun) dan policy validation bersifat gratis. Sementara itu, unused access analyzer (menandai izin yang tidak pernah dipakai) berbayar sekitar 0,20 USD per IAM role atau user per bulan, dan internal access analyzer berbayar sekitar 9 USD per resource yang dipantau per Region per bulan. Untuk CLF-C02 kamu tidak perlu hafal angkanya; cukup ingat bahwa Access Analyzer tidak sepenuhnya gratis dan IAM inti-nya yang gratis. Lihat sumber resmi: AWS, IAM Access Analyzer dan harga Access Analyzer.

Yang terlihat praktis, tetapi sering tidak aman.

Kesalahan IAM biasanya bukan karena AWS rumit, tetapi karena izin dibuat terlalu lebar sejak awal.

Best practice modern 2026

AWS kini menekankan beberapa pergeseran. Untuk manusia, pakai IAM Identity Center atau federation, bukan membuat IAM user manual satu per satu. Untuk workload dan layanan AWS, pakai IAM role, bukan access key jangka panjang. Bila kamu memakai AWS Organizations, ada fitur centralized root access yang memungkinkan management account menghapus kredensial root (password, access key, MFA) dari member account, bahkan akun baru di Organizations kini bisa dibuat tanpa kredensial root sama sekali. Untuk CLF-C02, cukup tahu arah besarnya: kurangi kredensial jangka panjang, hindari root, dan pakai identitas terpusat.

Cara membedakan opsi yang mirip.

Soal IAM sering terasa mudah, tetapi opsi salahnya dibuat mirip dengan praktik nyata yang buruk.

Contoh gaya pertanyaan

Peta ingatan cepat sebelum lanjut ke modul berikutnya.

IAM adalah fondasi keamanan AWS, jadi pahami pola aksesnya, bukan hanya hafal nama fiturnya.

Pemetaan ke domain CLF-C02

Tips ujian cepat

• Jika melihat kata “AWS service needs access to another AWS service”, pikirkan IAM role.
• Jika melihat kata “human users at scale”, pikirkan federation atau IAM Identity Center, bukan membuat banyak IAM user manual.
• Jika melihat kata “root user”, cari jawaban tentang MFA, tidak dipakai harian, dan tidak membuat access key root.
• Jika melihat kata “minimum permissions”, jawabannya mengarah ke least privilege.
• Jika melihat kata “status MFA dan access key semua user”, ingat IAM Credential Report.
• Jika ada explicit deny dan allow bertemu, deny menang.