Identity and Access Management (IAM) adalah kerangka kebijakan, proses, dan teknologi yang digunakan organisasi untuk mengelola identitas digital serta mengontrol hak akses pengguna terhadap sistem, aplikasi, dan data.
Singkatnya: IAM memastikan orang yang tepat mendapatkan akses yang tepat, pada waktu yang tepat, dan orang yang tidak berwenang ditolak.
Kebutuhan akses ini semakin mendesak. Menurut IBM X-Force Threat Intelligence Index 2026, 44% serangan siber melibatkan pencurian dan penyalahgunaan kredensial yang sah. Penyerang tidak lagi membobol sistem dari luar. Mereka masuk dengan akun yang sepenuhnya valid.
Di saat yang sama, Pasal 35 UU No. 27 Tahun 2022 mewajibkan Pengendali Data Pribadi di Indonesia melindungi dan memastikan keamanan Data Pribadi yang diprosesnya, termasuk melalui penyusunan dan penerapan langkah teknis operasional. Untungnya, kontrol atas siapa yang bisa mengakses apa adalah inti dari langkah tersebut.
Apa Itu IAM?
IAM adalah disiplin keamanan yang mengurus dua hal sekaligus: identitas (siapa Anda) dan akses (apa yang boleh Anda lakukan). Keduanya dikelola secara end-to-end, mulai dari akun dibuat saat karyawan bergabung, diubah saat ia pindah peran, hingga dicabut saat ia keluar dari organisasi.
IAM adalah halaman login yang sangat secure. Tapi, IAM lebih dari itu karena mencakup:
- Lifecycle akun: pembuatan, perubahan, dan pencabutan akun secara otomatis mengikuti status karyawan (joiner, mover, leaver).
- Kebijakan akses: aturan siapa boleh mengakses data tertentu, dengan tingkat akses apa, dan kapan perlu persetujuan.
- Jejak audit: pencatatan setiap pemberian, penggunaan, dan pencabutan akses, sehingga organisasi tidak mengandalkan “ingat-ingatan” saat insiden atau audit terjadi.
Tanpa IAM, pengelolaan akses biasanya berjalan lewat kombinasi spreadsheet, persetujuan lewat chat, dan “nanti dibereskan”. Pola ini terasa cepat di awal. Tapi di ujungnya menunggu tiga hal yang sama: akun yang tidak dicabut, izin yang menumpuk, dan pertanyaan auditor yang tidak terjawab.
Bagaimana Cara Kerja IAM?
Setiap kali seseorang mencoba mengakses sistem, IAM menjalankan alur yang sama. Microsoft merangkumnya sebagai dua tahap besar: manajemen identitas dan manajemen akses, yang terdiri atas langkah-langkah berikut:
1. Identifikasi
Sistem mengenali siapa atau apa yang meminta akses: karyawan, vendor, partner, perangkat IoT (Internet of Things), hingga aplikasi. Setiap entitas ini memiliki identitas digital tersendiri yang tersimpan dalam basis data atau direktori pusat, seperti Active Directory.
2. Autentikasi
Identitas yang diklaim harus dibuktikan. Pengguna memasukkan kata sandi, kode sekali pakai atau OTP (one-time password), biometrik, atau kunci akses digital. Sistem mencocokkan kredensial ini dengan catatan di direktori pusat. Banyak organisasi menambah multi-factor authentication (MFA) agar satu kata sandi yang bocor tidak cukup untuk membuka pintu.
3. Otorisasi
Setelah identitas terverifikasi, sistem menentukan apa yang boleh dilakukan pengguna. Seorang staf Sales Ops mungkin hanya boleh melihat dashboard pendapatan, sementara Sales Manager boleh mengeditnya.
Aturan ini diambil dari peran, atribut, atau kebijakan yang berlaku. Pada tahap inilah kontrol akses seperti RBAC (role-based access control) dan least privilege mulai bekerja dengan membatasi setiap identitas pada akses minimum yang sesuai tanggung jawabnya.
4. Akses dan pemantauan
Permintaan disetujui atau ditolak sesuai otorisasi. Seluruh aktivitas setelah itu dicatat dalam audit trail: login berhasil dan gagal, perubahan hak akses, hingga persetujuan permintaan baru.
Pencatatan inilah yang memungkinkan organisasi mendeteksi anomali, menyelidiki insiden, dan membuktikan kepatuhan. Tanpa tahap ini, tiga tahap sebelumnya tidak bisa dijadikan bukti ketika ditanya auditor.
Empat Pilar Utama IAM
Implementasi IAM pada umumnya dibangun di atas empat pilar. IBM dan praktisi keamanan menyebutnya sebagai fondasi yang sama: administrasi, autentikasi, otorisasi, dan audit. Hilang satu pilar, kontrol akses menjadi timpang.
1. Administrasi (manajemen lifecycle identitas)
Pilar ini mengelola seluruh siklus hidup identitas: pembuatan akun saat pengguna bergabung, penyesuaian hak akses saat peran berubah, hingga pencabutan akses saat pengguna keluar.
Tanpa pengelolaan yang terstruktur, organisasi berisiko memiliki akun lama yang masih aktif, dan akun tersebut justru menjadi sasaran favorit penyerang karena tidak ada pemiliknya.
2. Autentikasi
Pilar ini memastikan pengguna yang mengakses sistem adalah pemilik identitas yang sah. Selain kata sandi, metode yang umum digunakan mencakup MFA, biometrik, hingga autentikasi tanpa kata sandi (passwordless). Autentikasi berbasis risiko menambah faktor verifikasi hanya ketika ada sinyal bahaya, misalnya login dari perangkat atau lokasi baru.
3. Otorisasi
Setelah identitas terverifikasi, pilar ini menentukan batas akses. Pendekatan yang paling umum adalah RBAC (Role-Based Access Control), yang menetapkan hak akses berdasarkan peran pekerjaan. Dikombinasikan dengan prinsip least privilege, setiap pengguna hanya memperoleh akses minimum yang dibutuhkan untuk bekerja—tidak lebih.
4. Audit
Pilar ini memastikan ketiga pilar lainnya benar-benar berfungsi. Seluruh aktivitas akses dipantau dan dicatat: siapa mengakses apa, kapan, dan dengan persetujuan siapa. Audit menjadi fungsi tata kelola inti untuk kepatuhan terhadap regulasi sekaligus bahan investigasi ketika terjadi insiden.
Contoh IAM dalam Praktik: Onboarding dan Offboarding
Empat pilar di atas paling mudah dipahami lewat satu skenario: onboarding karyawan baru di perusahaan menengah.
Bayangkan perusahaan merekrut Sales Ops baru. Di hari pertama, ia butuh akses ke lima hal: email perusahaan, CRM, spreadsheet forecast, tool ticketing internal, dan folder proposal beserta pricing.
Tanpa IAM, prosesnya berjalan lewat chat. HR menghubungi IT untuk membuat akun email, Sales Lead meminta akses CRM lewat pesan singkat, tim finance meminta akses folder pricing “sementara”… dan sebagian akses diberikan tanpa catatan karena dianggap darurat.
Dua bulan kemudian karyawan itu pindah peran. Akses lamanya tetap aktif, karena tidak ada sistem yang memetakan perubahan peran ke perubahan akses. Skenario ini benar terjadi; akun valid yang tidak pernah dicabut adalah tepat jenis celah yang dipakai 30% serangan dalam data X-Force di atas.
Dengan IAM, sumber identitas (biasanya HRIS, sistem informasi kepegawaian) menjadi pemicunya. Status joiner otomatis membuat akun dan paket akses dasar untuk role “Sales Ops”. Akses sensitif seperti folder pricing melewati persetujuan pemilik data, bukan sekadar titipan chat.
Dan saat status berubah menjadi leaver, seluruh akses dicabut otomatis—termasuk sesi yang sedang aktif. Yang berubah bukan hanya kecepatannya, tetapi jejaknya: siapa menyetujui, kapan aktif, dan kapan dicabut, semuanya tercatat.
Autentikasi vs Otorisasi: Apa Bedanya?
Autentikasi memverifikasi siapa Anda; otorisasi menentukan apa yang boleh Anda lakukan. Dua istilah ini paling sering tertukar karena keduanya berjalan berurutan setiap kali login, padahal keduanya menjawab pertanyaan yang berbeda.
| Aspek | Autentikasi | Otorisasi |
|---|---|---|
| Pertanyaan yang dijawab | “Kamu siapa?” | “Kamu boleh melakukan apa?” |
| Terjadi kapan | Saat login, sebelum akses diberikan | Setelah identitas terverifikasi |
| Contoh | Kata sandi, OTP, biometrik | Boleh lihat data payroll, tidak boleh edit |
| Jika lemah | Akun mudah diambil alih (account takeover) | Akses kebablasan (permission creep) |
Analoginya: autentikasi adalah petugas yang memeriksa KTP Anda di pintu masuk; otorisasi adalah daftar ruangan yang boleh Anda masuki. Organisasi yang kuat di autentikasi tetapi lemah di otorisasi tetap berisiko, karena orang yang “sah” bisa memiliki akses yang jauh melebihi kebutuhannya.
IAM, SSO, dan MFA: Apa Perbedaannya?
IAM adalah kerangka induk; single sign-on (SSO) dan multi-factor authentication (MFA) adalah komponen di dalamnya. Ketiganya sering dianggap sama, padahal berada pada lapisan yang berbeda.
| Aspek | IAM | SSO | MFA |
|---|---|---|---|
| Definisi | Payung besar: kebijakan, proses, dan teknologi pengelolaan identitas dan akses | Satu sesi login untuk banyak aplikasi | Verifikasi identitas dengan lebih dari satu faktor |
| Fungsi | Kontrol akses end-to-end | Memudahkan dan memusatkan login | Memperkuat pembuktian identitas |
| Posisi | Kerangka induk | Komponen di dalam IAM | Metode autentikasi di dalam IAM |
Jadi, jika ada yang berkata “kami sudah pakai SSO, berarti sudah ada IAM”, itu belum tepat. SSO hanya mengurus satu bagian dan biasanya bagian yang paling terlihat di permukaan.
IAM mencakup jauh lebih luas: kebijakan siapa yang boleh masuk, kapan akses dicabut, siapa yang menyetujui, dan bagaimana semuanya tercatat.
Komponen dan Teknologi dalam IAM
Sistem IAM modern tersusun dari beberapa komponen yang bekerja terintegrasi.
Single Sign-On (SSO)
SSO memungkinkan pengguna mengakses berbagai aplikasi dengan satu set kredensial. Selain mengurangi friksi login, SSO memusatkan kontrol sesi—kebijakan MFA dan pencabutan akses cukup diterapkan di satu titik.
Protokol standar yang umum dipakai adalah SAML (Security Assertion Markup Language) dan OIDC (OpenID Connect), yang membuat identitas dari satu penyedia bisa dipercaya oleh banyak aplikasi.
Multi-Factor Authentication (MFA)
MFA menambah faktor pembuktian selain kata sandi: kode OTP, push notification, atau biometrik. Tujuannya sederhana: satu kata sandi yang bocor tidak lagi cukup untuk membajak akun.
Untuk aplikasi prioritas tinggi seperti email korporat, VPN, dan admin console, MFA sebaiknya diwajibkan, jangan sekedar opsional. Untuk aplikasi lain, autentikasi adaptif dapat meminta faktor tambahan hanya ketika ada sinyal risiko, misalnya login dari perangkat atau lokasi yang belum dikenal.
Kontrol Akses (RBAC, ABAC, Least Privilege)
RBAC memberi akses berdasarkan peran (“Finance”, “HR”, “Sales Ops”), sedangkan ABAC (Attribute-Based Access Control) memperhalus dengan atribut seperti lokasi, unit, atau status proyek.
Contohnya: folder pricing hanya bisa dibuka oleh pengguna dengan atribut “Commercial Approved” yang masih terikat proyek aktif, bukan oleh orang yang kebetulan memegang role Sales. Keduanya sebaiknya berdiri di atas prinsip least privilege: akses minimum untuk bekerja, dicabut begitu tidak dibutuhkan lagi.
Provisioning dan Deprovisioning
Provisioning adalah pemberian akses secara terkontrol, idealnya otomatis berbasis event: joiner membuat akun dan role dasar, mover mengubah akses sesuai peran baru, leaver mencabut seluruh akses termasuk sesi aktif.
Standar seperti SCIM (System for Cross-domain Identity Management) membuat akun di aplikasi tetap sinkron dengan sumber identitas tanpa pengetikan manual. Otomasi ini adalah “mesin” yang mencegah akun yatim (orphan account) menumpuk dan yang membedakan IAM dari sekadar direktori pengguna.
Access Review dan Approval Workflow
Access review berkala menjaga akses tetap relevan: akses ke data sensitif dan keuangan sebaiknya ditinjau tiap kuartal, akses standar cukup tiap semester atau tahunan. Idealnya, pemilik aplikasi atau data yang menyetujui permintaan akses, bukan hanya IT yang menjadi “tukang stempel” tanpa konteks risiko.
Setiap review harus menghasilkan bukti yang bisa ditunjukkan ke auditor: siapa meninjau, keputusan apa, kapan, dan tindak lanjutnya. Review tanpa rekaman itu sama saja dengan tidak melakukan review.
Privileged Access Management (PAM)
PAM adalah kontrol khusus untuk akses istimewa: akun admin, root, database admin. Karena dampak penyalahgunaannya paling besar, PAM menambah kontrol yang lebih ketat seperti akses sementara (time-bound), approval just-in-time, session recording, dan break-glass account untuk kondisi darurat.
Praktik berbagi satu akun admin antar tim membuat aktivitas admin hampir mustahil dilacak ke individu saat insiden terjadi; PAM ada persis untuk menutup celah ini.
Layanan Direktori dan Audit Trail
Direktori pusat (misalnya Active Directory, LDAP) menjadi sumber kebenaran identitas: satu tempat yang menyimpan siapa saja pengguna, atributnya, dan hak akses dasarnya.
Sementara audit trail merekam login, kegagalan login, eskalasi hak akses, dan persetujuan yang merupakan bahan baku utama kepatuhan dan investigasi insiden. Keduanya sebaiknya terpusat: log yang tersebar di tiap aplikasi hampir tidak pernah ditelusuri sampai tuntas saat insiden terjadi.
Manfaat IAM untuk Bisnis
Manfaat IAM paling terasa ketika pengelolaan akses tidak lagi bergantung pada orang tertentu, chat, atau spreadsheet, melainkan pada aturan dan bukti yang konsisten.
Mengurangi risiko keamanan
Menurut IBM Cost of a Data Breach Report 2026, rata-rata biaya pelanggaran data mencapai rekor USD 4,99 juta, dan pelanggaran yang melibatkan penyalahgunaan akun valid menelan USD 5,07 juta dengan 243 hari sebelum teridentifikasi dan ditanggulangi.
Laporan yang sama menempatkan IAM sebagai faktor pengurang biaya pelanggaran terbesar kedua: organisasi yang menerapkannya menghemat rata-rata USD 225.622. Sebaliknya, hak akses berlebihan dan pengelolaan role yang buruk justru menaikkan biaya rata-rata USD 177.313. MFA mempersulit pembajakan akun; least privilege membatasi gerakan penyerang yang berhasil masuk; audit trail mempercepat deteksinya.
Meningkatkan efisiensi operasional
Onboarding dan offboarding lebih cepat karena akses standar otomatis dan akses sensitif cukup melewati alur persetujuan yang jelas. Tiket helpdesk menurun, terutama reset kata sandi dan permintaan akses manual. Ketergantungan pada “orang IT tertentu yang tahu caranya” berkurang.
Mendukung kepatuhan regulasi
Untuk organisasi di Indonesia, Pasal 35 UU PDP mewajibkan Pengendali Data Pribadi melindungi dan memastikan keamanan Data Pribadi yang diprosesnya, termasuk melalui langkah teknis operasional. IAM adalah jawaban operasionalnya karena IAM dapat berfungsi sebagai bukti siapa memiliki akses, siapa menyetujui, dan kapan akses dicabut.
Standar internasional seperti ISO/IEC 27001:2022 (kontrol akses 5.15–5.18 pada Annex A) dan PCI DSS (Persyaratan 7 dan 8) juga menuntut hal serupa. Tanpa IAM, memenuhi permintaan auditor berarti menyusun ulang bukti secara manual setiap kali diperiksa.
Meningkatkan produktivitas tanpa mengorbankan kontrol
SSO mengurangi login berulang, MFA berbasis risiko hanya meminta verifikasi tambahan saat ada sinyal bahaya, dan self-service reset password memindahkan beban dari helpdesk ke pengguna. Kontrol dan kenyamanan tidak harus saling meniadakan.
Tren IAM di Masa Depan: Zero Trust, AI, dan ITDR
Terdapat tiga tren yang saat ini, dan di masa mendatang, membentuk arah IAM. Ketiganya menjawab satu kenyataan: identitas kini menjadi perimeter keamanan yang baru.
Zero Trust meninggalkan asumsi lama bahwa segala sesuatu di dalam jaringan otomatis bisa dipercaya. Prinsipnya ringkas: never trust, always verify. Setiap permintaan akses diverifikasi berkelanjutan, apa pun asalnya, baik itu di kantor, rumah, atau perangkat pribadi.
Microsoft menempatkan IAM sebagai fondasi praktis dari kerangka kerja ini. Hal ini sangat relevan: IBM X-Force Threat Intelligence Index 2026 mencatat lonjakan 44% serangan yang dimulai dari eksploitasi aplikasi publik, banyak di antaranya dimungkinkan oleh autentikasi yang hilang atau lemah.
AI di dua arah. Di sisi pertahanan, AI memungkinkan autentikasi berbasis risiko: sistem menilai tiap percobaan login secara real-time dari lokasi, perangkat, dan pola perilaku, lalu meminta verifikasi tambahan hanya saat ada sinyal bahaya. Di sisi ancaman, AI generatif justru memperbanyak identitas non-manusia di jaringan seperti agen AI, service account, beban kerja otomatis.
IBM mencatat identitas non-manusia sudah melebihi manusia dengan rasio 10:1 di perusahaan rata-rata, dan identitas inilah yang sering punya akses tinggi dengan kredensial paling kurang terlindungi. Data terbaru mempertegas urgensi ini: menurut IBM Cost of a Data Breach Report 2026, 92% organisasi yang mengalami insiden terkait AI tidak memiliki kontrol akses yang memadai, dan hanya 46% yang mengamankan identitas non-manusia dalam alur kerja AI mereka.
ITDR (Identity Threat Detection and Response) menutup celah yang tidak diurus IAM tradisional: mendeteksi dan merespons serangan yang menargetkan identitas itu sendiri, seperti phishing, MFA fatigue, dan eskalasi hak akses. IAM mencegah akses salah masuk; ITDR mengawasi ketika akses yang sah mulai berperilaku aneh.
Tantangan Implementasi IAM
IAM jarang gagal karena tool-nya buruk. Kegagalan biasanya bersumber dari data identitas dan kepemilikan akses yang tidak dibereskan sejak awal.
- Aplikasi legacy yang sulit diintegrasikan. Mulai dari aplikasi yang mendukung SSO standar untuk kemenangan cepat; perlakukan aplikasi lama sebagai exception dengan kontrol kompensasi seperti akses terbatas dan review ketat.
- Data identitas berantakan. Duplikat akun, email ganda, status kontrak yang tidak jelas. Tentukan satu sumber kebenaran (biasanya HRIS), rapikan atribut minimum, lalu deduplikasi bertahap.
- Permission creep. Akses menumpuk setelah pindah peran atau proyek baru. Gunakan role dasar yang stabil plus akses tambahan yang time-bound dan wajib direview.
- Resistensi pengguna. Terapkan MFA bertahap berbasis risiko, pilih metode minim friksi, dan jelaskan alasannya dalam bahasa dampak bisnis, bukan jargon keamanan.
- Kepemilikan akses tidak jelas. IT menjadi pemberi persetujuan tanpa konteks data. Tetapkan pemilik untuk setiap aplikasi dan data sensitif.
- Konflik keamanan vs kecepatan bisnis. Bedakan akses standar (otomatis, cepat) dari akses sensitif (perlu persetujuan dan review).
Pola kegagalannya khas: SSO sudah terpasang, tetapi pemetaan role kacau. Pengguna tetap meminta akses manual, izin di aplikasi tetap berantakan, dan audit tetap sulit karena tidak ada korelasi antara role, persetujuan, dan akses aktual.
Tiga ekspektasi keliru yang perlu diluruskan
Sebelum memulai, luruskan dulu tiga klaim keliru tentang IAM:
- “IAM itu urusan tool.” Salah. Tool yang dipasang sebelum role, workflow, dan data siap hanya memindahkan kekacauan dari spreadsheet ke aplikasi—dengan biaya lisensi di atasnya.
- “Dengan IAM, kami 100% aman.” Tidak ada sistem yang menjanjikan itu. IAM menurunkan risiko secara signifikan, tetapi salah konfigurasi role dan pengecualian yang tak terkendali tetap bisa menjadi celah.
- “IAM itu proyek sekali jadi.” IAM adalah program, bukan proyek. Ia butuh review berkala, perbaikan role mapping, dan penyesuaian setiap kali organisasi berubah.
Langkah Implementasi IAM
Implementasi yang realistis berfokus pada dua hal: lingkup yang tepat dan urutan yang benar. Berusaha meng-IAM-kan semua aplikasi sekaligus biasanya membuat tim kelelahan sebelum dampak pertama terlihat.
Langkah 1: Tentukan lingkup dan tujuan
Mulai dari aplikasi yang paling sering dipakai, paling sensitif, paling sering memicu tiket helpdesk, atau paling sering ditanyakan auditor. Tetapkan tujuan konkret: konsolidasi login, perbaikan proses joiner-mover-leaver untuk aplikasi kritikal, atau penutupan akses nyangkut berisiko tinggi.
Langkah 2: Tetapkan pemangku kepentingan
IAM selalu lintas fungsi: IT (integrasi teknis), Security (kebijakan dan monitoring), HR (sumber status karyawan), pemilik aplikasi/data (persetujuan akses), dan vendor bila ada. Peran siapa bertanggung jawab atas apa harus jelas sejak awal.
Langkah 3: Inventarisasi identitas dan sistem
Petakan sumber data identitas, daftar aplikasi dan cara pengguna login hari ini, lokasi data sensitif, serta akun vendor dan admin yang ada. Tanpa inventaris, Anda menambal akses berdasarkan permintaan, bukan berdasarkan peta risiko.
Langkah 4: Desain role dan kebijakan akses
Mulai dari role yang paling umum, bukan role yang paling sempurna. Tetapkan mekanisme exception: siapa boleh mengajukan akses tambahan, siapa menyetujui, berapa lama berlaku, dan kapan direview ulang.
Langkah 5: Terapkan SSO dan MFA berbasis prioritas
Urutan yang sering berhasil: SSO untuk aplikasi mudah diintegrasikan dan berdampak besar, MFA wajib untuk aplikasi kritikal, lalu autentikasi berbasis risiko untuk mengurangi friksi. Tujuannya memaksimalkan dampak pada risiko tertinggi terlebih dahulu.
Langkah 6: Otomatiskan joiner-mover-leaver
Ini mesin yang mengubah proses manual menjadi sistemik. Joiner mendapat akun inti dan role dasar otomatis; mover mendapat perubahan akses mengikuti peran baru; leaver kehilangan seluruh akses secara otomatis, termasuk sesi aktif.
Langkah 7: Jadwalkan access review berkala
Tinjau secara berkala akses ke data sensitif, keuangan, admin, dan vendor. Pastikan setiap review menghasilkan bukti: siapa meninjau, keputusan apa, kapan, dan tindak lanjutnya.
Langkah 8: Tambahkan PAM bila diperlukan
PAM dibutuhkan ketika akun admin dipakai bersama, akses root sering digunakan, atau aktivitas admin memerlukan pencatatan sesi. Mulai dari akun privileged paling kritikal, lengkapi dengan break-glass account dan akses time-bound.
Kesimpulan
IAM yang baik bukan yang paling canggih, melainkan yang paling konsisten: identitas rapi, persetujuan jelas, akses diberikan otomatis saat memang dibutuhkan, dicabut saat waktunya tiba, dan setiap keputusan meninggalkan jejak. Jika harus memilih prioritas, dahulukan lifecycle dan deprovisioning daripada mengejar fitur yang tampak mengesankan tetapi tidak menutup risiko paling nyata.
Yang membedakan implementasi berhasil dan gagal biasanya bukan teknologinya, melainkan kesediaan menyepakati hal dasar: sumber identitas, pemilik akses, definisi role, dan aturan exception. Setelah itu, tool benar-benar menjadi akselerator—bukan pengganti proses.
FAQ: Identity and Access Management
IAM adalah kombinasi kebijakan, proses, dan teknologi untuk mengelola identitas digital serta mengontrol hak akses pengguna terhadap sistem, aplikasi, dan data perusahaan yang dimulai dari akun dibuat saat karyawan bergabung hingga dicabut saat ia keluar.
Belum. SSO hanya memusatkan login. IAM mencakup lebih luas: kebijakan siapa yang boleh mengakses apa, siklus hidup akun (joiner-mover-leaver), alur persetujuan, hingga audit. SSO adalah komponen di dalam IAM, bukan penggantinya.
Untuk mencegah akun yatim (orphan account) dan penumpukan hak akses (privilege creep), ketika karyawan yang sudah resign atau pindah divisi masih memiliki akses ke data sensitif karena tidak dicabut otomatis.
PAM (Privileged Access Management) fokus pada akun dengan hak akses tinggi seperti administrator, dengan kontrol lebih ketat: akses time-bound, approval just-in-time, dan session recording. IAM mengelola seluruh identitas dan akses pengguna secara umum; PAM menangani subset yang berisiko paling tinggi.
Pasal 35 UU No. 27 Tahun 2022 mewajibkan Pengendali Data Pribadi melindungi dan memastikan keamanan Data Pribadi yang diprosesnya, termasuk melalui langkah teknis operasional. IAM menyediakan langkah tersebut sekaligus buktinya: siapa memiliki akses, siapa menyetujui, kapan diberikan, dan kapan dicabut.
IAM merekam audit trail yang menjawab pertanyaan dasar auditor: siapa melakukan apa, mengapa ia memiliki akses itu, dan siapa yang menyetujuinya. Perusahaan tidak perlu mengandalkan ingatan atau catatan manual saat diperiksa.
