Kupas Tuntas Identity & Access Management (IAM): Dari Konsep Dasar Sampai Implementasi Modern di Dunia DevOps

Kalau diingat-ingat, berapa kali tim kita kewalahan cuma gara-gara urusan hak akses? Entah itu service account nyasar yang lupa dihapus, token bocor di repositori git, atau developer yang mendadak bingung kenapa gak bisa query ke DB staging.

Di arsitektur cloud-native modern, garis pertahanan utama kita bukan lagi sekadar tembok firewall. Titik tumpunya ada di Identity and Access Management (IAM).

Banyak orang mikir IAM itu cuma soal bikin halaman login dan simpan password. Padahal kalau ditarik ke kacamata arsitektur IT, IAM adalah fondasi yang ngatur siapa boleh nyentuh apa, kapan, dan atas dasar apa.

Di artikel ini, kita bakal bedah IAM sampai ke akar-akarnya dengan bahasa yang lebih santai dan gampang dipahami.

1. Filosofi Dasar & 4 Pilar IAM

Kalau mau diperkasat, inti dari IAM itu sederhana:

"Ngepasin supaya entitas yang bener dapet akses ke resource yang bener, di waktu yang bener, dan dengan alasan bisnis yang jelas."

[ User / Bot / Service ] 
       │
       ▼
 1. Identification      ──► "Gua si A" (Klaim Identitas)
       │
       ▼
 2. Authentication      ──► "Buktikan!" (Cek Kredensial)
       │
       ▼
 3. Authorization       ──► "Boleh ngapain aja?" (Cek Izin Akses)
       │
       ▼
 4. Accounting & Audit  ──► "Ngapain aja tadi?" (Log Audit)

Di dalam sistem, alurnya selalu muter di 4 tahap ini:

1. Identification: Entitas (user, bot, atau pod K8s) ngasih tahu siapa dirinya.

   • Bentuknya: Username, Email, Client ID, atau Service Account Name.

2. Authentication (AuthN): Pembuktian balik. Sistem nanya: "Beneran lo yang punya ID ini?"

   • Mekanismenya: Password/PIN (something you know), OTP/Passkey (something you have), atau Biometrik (something you are).

3. Authorization (AuthZ): Setelah terbukti bener, baru dicek batas hak aksesnya.

   • Contoh: Boleh baca data (GET), tapi gak boleh hapus data (DELETE).

4. Accounting & Auditing: Semua jejak digital dicatat secara rapi. Ini berguna banget pas ada audit atau insiden keamanan.

2. AuthN vs AuthZ: Bedanya Tipis tapi Vital

Anak-anak yang baru terjun ke dunia IT sering banget kebalik antara dua istilah ini. Beda fungsi dan beda respon HTTP-nya!

Parameter	Authentication (AuthN)	Authorization (AuthZ)
Fokus Pertanyaan	"Lo siapa sebenarnya?"	"Lo berhak ngelakuin aksi ini gak?"
Kapan Dieksekusi	Di awal pas bikin sesi/koneksi	Tiap kali ada request masuk ke API
Error Kalau Gagal	401 Unauthorized	403 Forbidden
Protokol Populer	OpenID Connect (OIDC), SAML, FIDO2	OAuth 2.0 (Scopes), OPA

3. Tiga Model Access Control (RBAC, ABAC, PBAC)

Gimana cara kita ngatur aturan izin akses di backend? Ada tiga pola umum:

┌─────────────────────────────────────────────────────────────┐
│                   ACCESS CONTROL MODELS                     │
├──────────────────────┬──────────────────────┬───────────────┤
│    RBAC (Static)     │    ABAC (Dynamic)    │ PBAC (Policy) │
│                      │                      │               │
│ User ──► Role ──► Perm │ User + Resource + Env│ Engine Terpisah│
│ (e.g. Role DevOps)   │ (e.g. IP, Waktu, Dept)│ (e.g. OPA)    │
└──────────────────────┴──────────────────────┴───────────────┘

• RBAC (Role-Based Access Control): Hak akses ditempelin ke peran (role).

  • Realita: Enak di awal, tapi pas tim makin gede, bakal kena masalah Role Explosion (pusing ngurusin ratusan role yang mirip-mirip).

• ABAC (Attribute-Based Access Control): Lebih luwes. Akses nimbang atribut user, atribut data, plus kondisi lingkungan (lokasi IP, jam kerja, kesehatan perangkat).

• PBAC (Policy-Based Access Control): Aturan otorisasi dipisah dari source code aplikasi dan ditaruh di engine khusus kayak Open Policy Agent (OPA).

4. Siklus Identitas: Siklus JML di Lapangan

Identitas di organisasi itu gak pernah statis. Sebagai tim Operations, kita harus ngawal siklus JML (Joiner, Mover, Leaver):

• Joiner (Provisioning): Ada orang atau microservice baru? Otomatis bikinin akun dan hak akses dasar via CI/CD atau SCIM.

• Mover (Access Adjustment): Orang pindah divisi atau promosi? Sesuaikan hak aksesnya. Akses divisi lama wajib dicabut.

• Leaver (Deprovisioning): Ini babak paling rawan. Pas karyawan resign, aksesnya wajib di-revoke detik itu juga. Kalau telat, akun melayang (ghost accounts) ini bakal jadi sasaran empuk peretas.

5. Soal "Alasan Bisnis" (Right Reason): Kenapa Penting?

Pernah gak mikir: "Kan dia udah login (AuthN) dan jabatannya sesuai (AuthZ), ya kasih aja lah aksesnya?"

Nah, pemikiran kayak gini yang bikin kebocoran data internal (insider threat) sering kejadian. Orang punya kapabilitas teknis belum tentu punya alasan bisnis buat buka data itu sekarang.

[ User Sah ] ──► [ Punya Role ] ──► [ Jam Kerja ] ──► [ ADA ALASAN BISNIS GAK? ]
(Dokter A)        (Akses Medis)      (Shift Pagi)        (Apakah pasiennya?)

Biar Makin Bayang, Ini Contoh Nyatanya:

1. Aplikasi Rumah Sakit: Dokter A punya jabatan "Dokter Spesialis". Tanpa kriteria Right Reason, dia bisa iseng buka rekam medis tetangganya yang lagi dirawat. Tapi kalau pakai Right Reason, sistem cuma ngebuka rekam medis pasien yang ada di daftar jadwal periksanya hari itu.

2. Core Banking: CS bank punya wewenang ngecek saldo nasabah. Kalau gak ditautkan ke nomor tiket pelayanan aktif, CS bisa aja iseng ngintip saldo orang tanpa izin.

3. Akses DB Production (DevOps): Dibanding ngasih akses SSH root permanen ke engineer, lebih aman pakai Just-In-Time (JIT) Access. Akses root cuma aktif 1 jam kalau ada tiket insiden kritis yang disetujui lead.

6. Prinsip Arsitektur IAM Modern

Ada tiga prinsip penting kalau kita mau bangun infrastruktur yang kokoh:

1. Principle of Least Privilege (PoLP): Kasih akses seperlunya aja. Batasi ruang gerak sejak awal (default to deny).

2. Zero Trust Architecture (ZTA): Anggap jaringan internal itu sama bahayanya dengan jaringan publik. Never trust, always verify.

3. Identity Federation & SSO: Pusatkan urusan autentikasi ke satu tempat (Identity Provider), biar aplikasi tinggal nerima beres.

7. Peta Software & Tool IAM Pilihan DevOps

Biar gak bingung milih tooling, ini beberapa software IAM yang sering dipakai di industri:

Kategori	Software Populer	Model Deployment	Cocok Buat Apa?
IDaaS (Cloud)	Okta, Microsoft Entra ID, Auth0	Managed SaaS	SSO kantor, CIAM, dan manajemen user enterprise
Self-Hosted	Keycloak, Authentik, FreeIPA	Docker / K8s / On-Prem	IdP mandiri berbasis OIDC/SAML buat microservices
PAM (Privileged Access)	Teleport, CyberArk, BeyondTrust	Hybrid / Enterprise	Ngamankan akses SSH, K8s cluster, & DB tanpa password permanen
Policy Engine	Open Policy Agent (OPA), AWS VP	Cloud-Native	Otorisasi terpisah berbasis Policy-as-Code
Secrets & Machine IAM	HashiCorp Vault, CyberArk Conjur	Self-Hosted / SaaS	Manajemen API Key, sertifikat mTLS, & kredensial DB dinamis

8. Gimana IAM Ngobrol Sama Aplikasi? (SAML & OIDC)

Gimana sih caranya software IAM (seperti Keycloak atau Okta) komunikasi sama aplikasi backend kita?

A. SAML 2.0 (Format XML)

Protokol tua yang langganan dipakai di lingkungan enterprise.

🏢 Analogi SAML: > Kamu mau masuk ke Ruang VIP (Aplikasi). Resepsionis gak kenal kamu dan minta kamu ke Pos Satpam (IAM). Satpam meriksa KTP kamu, lalu nerbitin Surat Pengantar (XML Assertion) yang dicap Stempel Hologram Basah (Digital Signature). Surat itu dimasukkan ke amplop dan kamu bawa balik ke resepsionis. Resepsionis liat stempelnya asli, lalu ngebuka pintu.

B. OpenID Connect (OIDC) & OAuth 2.0 (Format JSON)

Standar modern yang ringan dan ramah banget buat web/mobile apps.

• OAuth 2.0: Kerangka kerja Otorisasi ("Boleh ngapain aja?").

• OIDC: Lapisan Autentikasi di atas OAuth 2.0 ("Siapa kamu?").

🎡 Analogi OIDC & OAuth2: > Kamu datang ke Taman Hiburan (System Architecture):

• OIDC = Name Tag VIP (ID Token): Bikin aplikasi tahu siapa namamu ("Halo, Budi!").

• OAuth 2.0 = Gelang QR Code Wahana (Access Token): Gelang tangan yang nyatet wahana mana aja yang boleh kamu naiki.

• Mekanisme Akses: Pas mau naik Roller Coaster (API Endpoint), kamu tinggal scan gelang QR Code-mu. Petugas wahana cukup verifikasi QR Code itu secara lokal tanpa perlu balik nanya ke loket utama.

[ User / Browser ] ──(1. Login)──► [ IAM / IdP (Keycloak/Okta) ]
        │                                    │
        │◄───(2. Balikin Access Token/JWT)───┘
        │
        └────(3. Request + Bearer Token)───► [ Backend API / Microservice ]
                                                       │
                                              (4. Cek Signature Lokal)

C. SCIM & Engine Otorisasi Terpisah

• SCIM 2.0: REST API buat sinkronisasi data user. Pas ada user baru di IAM, IAM bakal manggil API aplikasi buat bikin akun secara otomatis.

• Decoupled Authorization: Aplikasi (PEP) nanya ke OPA (PDP) via payload JSON cepat: "User ini boleh hapus data X gak?". OPA ngebalas true atau false.

9. Catatan Penutup & Checklist Praktis

Urusan IAM ini gak cuma tugas tim Security, tapi gabungan antara tim DevOps dan Security (DevSecOps).

🚀 Checklist Praktis Buat Tim DevOps:

1. ✅ Stop Simpan Kredensial di Code: Jangan pernah hardcode password DB atau API Key di repositori. Pakai Secrets Manager kayak HashiCorp Vault.

2. ✅ Manfaatin Standard Protocol: Hindari bikin sistem login sendiri dari nol. Pakai IdP teruji kayak Keycloak atau Auth0.

3. ✅ Atur Masa Berlaku Token (Short-lived): Pastikan Access Token JWT punya durasi expired yang singkat (misal 15-30 menit).

4. ✅ Mulai Lirik Policy-as-Code: Pisahin logika otorisasi dari source code pakai OPA.

Gimana kawan-kawan, kira-kira arsitektur IAM di sistem kamu sekarang udah rapi atau masih banyak pakai cara manual? Kalau ada pengalaman unik atau kendala pas setup IAM, yuk ngobrol di kolom komentar! 🚀