Belajar Cloud Computing - Identity & Access Management (IAM) Deep Dive

#Pendahuluan

Di episode 2, kalian memahami shared responsibility model: "security IN the cloud" — lapisan data dan akses — adalah tanggung jawab kalian. Episode 3 membahas alat utama untuk tanggung jawab itu: Identity & Access Management (IAM).

IAM adalah sistem yang memutuskan siapa yang boleh mengakses apa di cloud. Kedengarannya sederhana, tapi ini penyebab utama kebocoran data — bukan bug aplikasi, melainkan izin yang terlalu longgar. Episode ini membedah konsep, komponen, dan praktik IAM di AWS, GCP, dan Azure secara berdampingan.

#Autentikasi vs Otorisasi

Dua kata yang sering tertukar, padahal keduanya berbeda tahap:

• Autentikasi — menjawab "siapa kalian?". Membuktikan identitas lewat password, MFA, atau kredensial. Analoginya: menunjukkan kartu identitas di pintu masuk gedung.
• Otorisasi — menjawab "apa yang boleh kalian lakukan?". Setelah identitas terbukti, sistem memeriksa izin. Analoginya: setelah masuk gedung, kartu akses menentukan ruangan mana yang boleh dibuka.

Autentikasi tanpa otorisasi itu seperti memiliki kunci gedung tapi bebas masuk ke semua ruangan — tidak aman. Otorisasi tanpa autentikasi itu seperti punya daftar izin tapi tidak tahu siapa yang masuk — tidak berguna. Cloud butuh keduanya.

#Prinsip Least Privilege dan Zero Trust

Dua prinsip yang menggerakkan semua desain IAM modern:

• Least privilege — berikan izin sesedikit mungkin untuk menyelesaikan tugas, tidak lebih. Kalau sebuah aplikasi hanya perlu membaca file, jangan beri izin menghapus.
• Zero trust — jangan pernah percaya secara default, dari mana pun permintaannya. Setiap akses diverifikasi, bahkan yang berasal dari dalam jaringan sendiri.

Gunakan analogi: di bandara, teknisi bagasi punya izin masuk area bagasi, tidak otomatis ke ruang pilot. Kalau satu izin bocor, kerusakan yang bisa dilakukan terbatas pada area izin itu. Ini konsep blast radius — semakin kecil izin, semakin kecil area yang bisa diledakkan bila kredensial bocor.

#Komponen IAM AWS

AWS membangun IAM dari lima komponen:

• User — identitas untuk manusia (membangun aplikasi, login, dan lain-lain), punya kredensial sendiri.
• Group — kumpulan user agar izin bisa diberikan sekali untuk banyak orang, misalnya group developers.
• Role — identitas yang tidak melekat pada manusia, di-assume oleh user, aplikasi, atau service. Kredensial role bersifat sementara.
• Policy — dokumen JSON yang mendefinisikan izin (ini jantung IAM, dibahas di bawah).
• STS (Security Token Service) — layanan penerbit temporary credentials untuk role assumption (dibahas dalam episode 4).

Model AWS: izin melekat pada user, group, atau role melalui policy; evaluasi akhirnya adalah gabungan semua policy yang berlaku.

#Komponen IAM GCP

GCP memakai pendekatan berbeda: service account dan policy binding.

• Service account — identitas untuk aplikasi dan workload, bukan manusia. Menyimpan kunci atau memakai mekanisme kredensial lain.
• Role — kumpulan izin yang sudah ditentukan (misalnya roles/storage.objectViewer).
• Policy binding — proses "memasangkan" principal (siapa) dengan role (izin apa) pada resource (di mana), ditulis dalam dokumen IAM policy per project.

GCP tidak menganut model deny-explicit di level policy dasar: siapa pun tanpa binding tidak punya akses — akses hanya ada karena ada binding.

#Komponen IAM Azure

Azure memisahkan dua hal yang sering dianggap satu:

• Entra ID (dulu Azure Active Directory) — direktori identitas: user, group, service principal, managed identity, dan autentikasi (login, SSO, MFA).
• RBAC (Role-Based Access Control) — mekanisme otorisasi: siapa (principal) diberi role apa pada scope apa (subscription, resource group, atau resource).

Di Azure, login lewat Entra ID, lalu akses diperiksa RBAC. Managed identity adalah identitas otomatis untuk aplikasi Azure yang tidak perlu menyimpan secret sama sekali — analog dengan service account GCP.

#Anatomi Policy JSON

Di AWS, izin ditulis sebagai policy JSON. Pahami struktur dasarnya karena semua penyedia memakai pola yang mirip:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadOnlyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::assets",
                "arn:aws:s3:::assets/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

Empat elemen kunci:

• Effect — Allow atau Deny. Deny selalu menang atas Allow.
• Action — operasi yang diizinkan/ditolak, dalam format service:Operation.
• Resource — objek yang dituju, ditulis sebagai ARN.
• Condition — syarat tambahan; contoh di atas membatasi akses hanya dari range IP kantor.

#Praktik CLI: AWS, GCP, dan Azure

Mari lihat bentuk praktisnya di CLI. Di AWS, kelola user dan attach policy:

aws iam list-users
aws iam create-user --user-name dev
aws iam attach-user-policy \
  --user-name dev \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam list-attached-user-policies --user-name dev

Perintah aws iam list-users menampilkan semua user di akun — cara cepat memverifikasi siapa yang punya akses. Di GCP dan Azure, pola otorisasinya berbasis assignment:

gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --format="table(bindings.role, bindings.members)"

az role assignment list \
  --assignee user@example.com \
  --output table

Pola di atas menekankan perbedaan filosofi: AWS berorientasi policy yang melekat pada identitas; GCP dan Azure berorientasi binding antara siapa dan role pada suatu scope. Hasil akhirnya sama — kontrol akses granular — tapi kosakatanya berbeda.

#Perbandingan Implementasi IAM

Yang perlu dibawa pulang: apapun nama komponennya, alur berpikirnya sama — siapa (principal) + izin apa (role/policy) + di mana (scope). Kuasai tiga pertanyaan ini, dan IAM di penyedia mana pun mudah dipahami.

#Penutup

Episode 3 memberi kalian bahasa untuk mengontrol akses cloud:

• Autentikasi membuktikan identitas; otorisasi menentukan izin.
• Least privilege dan zero trust meminimalkan blast radius.
• AWS memakai user, group, role, dan policy; GCP memakai service account dan binding; Azure memakai Entra ID dan RBAC.
• Policy JSON adalah dokumen izin: Effect, Action, Resource, dan Condition.

Di episode 4, kalian belajar mempraktikkan semuanya dengan aman: mengapa akun root tidak boleh dipakai sehari-hari, bahaya API key yang hidup selamanya, serta penggunaan temporary credentials dan audit logging untuk meminimalkan risiko.