Cara memilih platform IAM dimulai dari memetakan pengguna dan aplikasi yang perlu dilindungi, lalu menguji calon platform dengan skenario nyata sebelum kontrak ditandatangani. Sistem IAM (identity and access management) mengatur siapa boleh masuk ke aplikasi apa, dan salah pilih langsung terasa ketika akses karyawan yang sudah keluar gagal dicabut.
Menurut ENISA Threat Landscape 2025, phishing menjadi metode intrusi awal pada sekitar 60% kasus yang diamati badan keamanan siber Uni Eropa itu sepanjang Juli 2024 sampai Juni 2025. Phishing kerap mengincar kata sandi dan sesi login, sehingga platform IAM ikut menentukan apakah kredensial curian bisa langsung dipakai penyerang.
Artikel ini membahas tujuh kriteria utama platform IAM dan enam langkah memilihnya, lengkap dengan contoh matriks penilaian untuk membandingkan vendor.
Kriteria Utama dalam Memilih Platform IAM
Kriteria utama dalam memilih platform IAM mencakup integrasi, autentikasi tahan phishing, otomatisasi siklus hidup akses, log audit, keamanan data vendor, ketersediaan layanan, dan kemudahan pakai. Ketujuhnya menentukan apakah platform bisa mengamankan akses tanpa menambah kerja manual tim IT.
Integrasi dengan Sistem yang Sudah Berjalan
Platform IAM hanya berguna jika bisa terhubung ke aplikasi dan sumber data karyawan yang sudah Anda pakai. Periksa kemampuan berikut pada setiap calon platform:
- Sinkronisasi dengan sistem HR (HRIS) sebagai sumber data karyawan, agar akun dibuat dan dinonaktifkan mengikuti status kepegawaian.
- Dukungan Active Directory atau LDAP, yaitu layanan direktori pengguna di server lokal, jika perusahaan masih memakainya.
- Dukungan SAML 2.0 dan OpenID Connect (OIDC), dua protokol standar untuk menghubungkan SSO (single sign-on, login sekali untuk semua aplikasi kerja) ke aplikasi.
- Dukungan SCIM, yaitu standar untuk membuat, mengubah, dan menghapus akun pengguna di aplikasi lain secara otomatis.
- Cara platform menangani aplikasi lama yang tidak mendukung SAML atau OIDC, misalnya lewat agen terpasang atau konektor berbasis API.
Aplikasi tanpa dukungan SCIM tetap bisa memakai SSO, tetapi admin mungkin masih harus membuat dan mencabut akunnya secara manual.
Autentikasi yang Tahan Phishing
Tidak semua MFA (multi-factor authentication, verifikasi dengan dua faktor atau lebih) tahan phishing. Kode OTP (kode sekali pakai) lewat SMS atau aplikasi autentikator masih bisa diketik korban di halaman login palsu, dan notifikasi push bisa disetujui korban tanpa curiga.
Pedoman NIST SP 800-63B-4, acuan autentikasi dari lembaga standar Amerika Serikat, mewajibkan sistem dengan tingkat jaminan AAL2 (dua faktor) menawarkan minimal satu opsi tahan phishing. Opsi ini umumnya berupa passkey atau security key berbasis FIDO2/WebAuthn, yaitu kunci kriptografi di perangkat pengguna yang hanya merespons domain asli sehingga tidak bisa dipakai di situs palsu.
Periksa juga kemampuan berikut:
- Dukungan passkey dan security key untuk semua pengguna, dengan opsi mewajibkannya bagi akun admin.
- Akses bersyarat (conditional access) yang menilai perangkat, lokasi, jam akses, dan tingkat risiko sebelum mengizinkan login.
- Alur pemulihan akun yang aman saat pengguna kehilangan ponsel. Alur yang lemah bisa dimanfaatkan penyerang yang menyamar sebagai karyawan lewat helpdesk.
Jika vendor menawarkan login biometrik, cari tahu lokasi pencocokan data biometriknya. NIST lebih menyarankan pencocokan lokal di perangkat pengguna daripada pencocokan terpusat di server.
Data biometrik tergolong data pribadi spesifik menurut Pasal 4 ayat (2) UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP). Berbeda dengan kata sandi, data ini tidak bisa diganti jika bocor.
Otomatisasi Siklus Hidup Akses
Siklus hidup akses mencakup tiga peristiwa, yaitu karyawan bergabung, pindah jabatan, dan keluar. Platform yang tepat memberi akses berdasarkan peran (role-based access control atau RBAC) dan mengubahnya otomatis begitu status di sistem HR berubah, tanpa menunggu tiket ke tim IT.
Peristiwa pindah jabatan paling mudah terlewat. Karyawan yang dimutasi tetap aktif bekerja, padahal akses dari jabatan lamanya bisa ikut terbawa dan menumpuk tanpa otomatisasi, kondisi yang disebut privilege creep.
Pencabutan akses saat karyawan keluar harus menjangkau semua aplikasi, termasuk aplikasi di luar email dan direktori utama. Akun yang tetap aktif setelah pemiliknya pergi berubah menjadi orphaned account, yaitu akun tanpa pemilik sah yang bisa dipakai penyerang tanpa terdeteksi.
Otomatisasi berbasis data HR tidak menjangkau akun layanan (service account) yang dipakai aplikasi untuk saling terhubung, karena akun ini tidak tercatat di sistem HR. Pilih platform yang bisa mencatat pemilik dan tanggal kedaluwarsa setiap akun layanan dan akun integrasi.
Log Audit dan Laporan Akses
Platform IAM yang tepat mencatat setiap login dan perubahan akses, lalu menyajikannya sebagai laporan siap pakai tentang siapa memegang akses ke aplikasi apa. Catatan ini membantu memenuhi Pasal 31 UU PDP, yang mewajibkan perusahaan sebagai pengendali data merekam seluruh kegiatan pemrosesan data pribadi.
Perhatikan masa simpan log dan kemampuan platform mengekspor atau mengirim log ke SIEM (sistem pemantauan keamanan terpusat) milik perusahaan.
Jika auditor rutin meminta bukti tinjauan akses, yaitu pemeriksaan berkala untuk memastikan setiap akses masih diperlukan, periksa apakah platform menyediakan fitur ini. Tanpa fitur tersebut, Anda perlu menambah modul tata kelola identitas (IGA) terpisah.
Keamanan dan Lokasi Data di Sisi Vendor
Vendor IAM yang mengolah data karyawan atas nama Anda berstatus prosesor data, sehingga kewajiban keamanan Pasal 35 dan Pasal 39 UU PDP juga berlaku baginya (Pasal 52). Minta bukti penerapannya, misalnya sertifikat ISO/IEC 27001 (standar internasional sistem manajemen keamanan informasi) beserta daftar layanan yang tercakup.
Untuk platform berbasis cloud, tanyakan di negara mana data pengguna disimpan dan diproses. Jika lokasinya di luar Indonesia, Pasal 56 UU PDP mewajibkan Anda memastikan negara tujuan memiliki tingkat pelindungan data yang setara atau lebih tinggi.
Bila syarat itu tidak terpenuhi, Anda wajib memastikan ada pelindungan yang memadai dan bersifat mengikat, dan jika itu pun tidak ada, Anda harus mendapatkan persetujuan subjek data.
Ketersediaan, Skalabilitas, dan Akses Darurat
Platform IAM menjadi pintu masuk ke semua aplikasi, dan gangguan pada platform ini bisa menghentikan kerja seluruh karyawan sekaligus. Tanyakan cara vendor menjaga layanan tetap berjalan, misalnya lewat pusat data cadangan di wilayah lain, beserta riwayat gangguannya dalam setahun terakhir.
Pastikan platform mendukung akun darurat (break-glass account), yaitu akun admin cadangan untuk masuk saat layanan IAM bermasalah. Platform sebaiknya mengirim peringatan setiap kali akun ini dipakai.
Bagi perusahaan yang sedang bertumbuh, pelajari batas jumlah pengguna, aplikasi, dan permintaan login per menit dalam paket yang ditawarkan. Batas yang terlalu rendah bisa menghambat login pada jam sibuk atau memaksa Anda pindah ke paket lebih mahal.
Kemudahan Pakai bagi Pengguna dan Admin
Alur login yang rumit mendorong karyawan mencari jalan pintas, misalnya menyimpan kata sandi di catatan ponsel atau memakai satu kata sandi untuk semua akun. Pilih platform yang menyediakan portal aplikasi satu pintu dan reset kata sandi mandiri, agar karyawan tidak perlu menunggu helpdesk.
Dari sisi admin, kebijakan akses harus bisa diatur lewat antarmuka tanpa menulis kode, dan tugas admin bisa dibagi per divisi atau lokasi. Antarmuka berbahasa Indonesia dan dokumentasi yang jelas mempercepat pelatihan tim internal.
6 Langkah Cara Memilih Platform IAM
Cara memilih platform IAM terdiri atas enam langkah, yaitu memetakan kebutuhan, menetapkan kriteria wajib, menyaring vendor, menguji kandidat, menghitung total biaya, dan mengunci janji vendor dalam kontrak. Langkah kedua sampai keempat memakai ketujuh kriteria di atas sebagai alat ukur.
1. Petakan Pengguna, Aplikasi, dan Masalah Saat Ini
Buat inventaris sebelum menghubungi vendor mana pun. Daftar ini menjadi dasar seluruh evaluasi berikutnya, dan isinya minimal mencakup hal berikut:
- Kelompok pengguna, yaitu karyawan tetap, kontraktor, vendor, dan akun layanan.
- Daftar aplikasi SaaS (perangkat lunak berlangganan berbasis cloud), aplikasi yang dipasang di server sendiri (on-premise), dan aplikasi buatan internal, beserta metode login masing-masing.
- Masalah utama saat ini, misalnya pembuatan akun karyawan baru yang memakan waktu berhari-hari atau tiket reset kata sandi yang terus menumpuk.
Setelah itu, tandai aplikasi berisiko tinggi, yaitu aplikasi yang menyimpan data pelanggan atau data keuangan, serta aplikasi yang memberi akses administrator. Aplikasi inilah yang wajib ikut diuji nanti, selain aplikasi SaaS populer yang konektornya sudah disiapkan vendor.
2. Tetapkan Kriteria Wajib Berdasarkan Masalah dan Regulasi
Putuskan kriteria mana yang wajib dipenuhi sebelum melihat demo vendor, agar penilaian tidak tergiring fitur yang paling menarik saat presentasi. Kriteria wajib lahir dari dua sumber, yaitu masalah dalam inventaris di langkah pertama dan aturan yang mengikat perusahaan.
Jika masalah terbesar Anda adalah akses karyawan keluar yang lambat dicabut, integrasi HRIS dan otomatisasi siklus hidup akses harus masuk daftar wajib. Dari sisi aturan, Pasal 39 UU PDP mewajibkan setiap perusahaan yang mengolah data pribadi, termasuk data karyawan di platform IAM, mencegah data itu diakses secara tidak sah.
Kewajiban ini cukup menjadi dasar untuk memasukkan autentikasi tahan phishing dan log audit ke daftar kriteria wajib.
Bank umum dan penyelenggara sistem pembayaran memiliki kewajiban tambahan dalam regulasi MFA dari OJK dan Bank Indonesia. Di sektor ini dan di sektor yang mengolah data pribadi spesifik seperti data kesehatan, jadikan keamanan dan lokasi data di sisi vendor sebagai kriteria wajib pula.
3. Saring Vendor Menjadi Daftar Pendek
Ubah tujuh kriteria utama menjadi daftar pertanyaan tertulis yang sama untuk setiap vendor, lalu minta jawaban beserta dokumen pendukung seperti daftar konektor resmi dan sertifikat keamanan. Vendor yang tidak bisa membuktikan kriteria wajib secara tertulis tidak perlu masuk tahap berikutnya.
Untuk dua atau tiga kandidat yang tersisa, hubungi pelanggan referensi yang jumlah pengguna dan sektornya mirip dengan perusahaan Anda. Bicaralah tanpa didampingi vendor dan tanyakan apakah pencabutan akses otomatis benar-benar berjalan di aplikasi lama mereka.
4. Jalankan Proof of Concept dengan Skenario Nyata
Proof of concept (PoC) adalah uji coba terbatas calon platform di lingkungan Anda sendiri. Jalankan skenario yang sama untuk setiap kandidat di daftar pendek agar hasilnya bisa dibandingkan.
Demo vendor umumnya hanya memperagakan SSO ke aplikasi SaaS populer. Karena itu, uji minimal lima skenario berikut:
- Login dengan SSO ke satu aplikasi berisiko tinggi dan satu aplikasi lama yang tidak mendukung SAML.
- Nonaktifkan satu karyawan uji di sistem HR, lalu catat berapa lama aksesnya tercabut di setiap aplikasi uji.
- Pindahkan karyawan uji ke divisi lain, lalu periksa apakah akses dari divisi lama ikut dicabut.
- Pulihkan akun pengguna yang kehilangan ponsel atau security key.
- Tarik laporan siapa mengakses aplikasi apa selama masa uji, dalam format yang diterima auditor.
Libatkan HR dan pemilik aplikasi dalam PoC, sebab merekalah yang merasakan langsung hasil otomatisasi akses. Gunakan masa uji yang sama untuk menilai dukungan vendor, misalnya kecepatan respons tiket teknis dan ketersediaan tim di zona waktu Indonesia.
5. Hitung Total Biaya Kepemilikan untuk Minimal Tiga Tahun
Harga lisensi per pengguna hanya sebagian dari biaya platform IAM. Hitung total biaya kepemilikan (total cost of ownership atau TCO) untuk minimal tiga tahun dengan memasukkan komponen berikut:
- Lisensi dan modul tambahan, misalnya MFA tingkat lanjut atau konektor premium.
- Jasa implementasi, termasuk integrasi aplikasi lama dan migrasi data pengguna.
- Perangkat autentikasi seperti security key untuk akun admin.
- Waktu kerja tim internal untuk mengelola platform dan melatih pengguna.
- Biaya keluar, yaitu usaha memindahkan konfigurasi dan data jika suatu saat Anda berganti vendor.
Bandingkan semua penawaran dengan jumlah pengguna dan cakupan aplikasi yang sama, agar selisih harganya mencerminkan perbedaan yang nyata.
6. Kunci Janji Vendor dalam Kontrak
Janji vendor saat demo dan PoC baru mengikat setelah tertulis di kontrak. Tuangkan target ketersediaan layanan dan waktu respons dukungan ke dalam perjanjian tingkat layanan (SLA), lengkap dengan kompensasi jika target meleset.
Sertakan juga klausul pelindungan data yang memuat daftar subprosesor, karena Pasal 51 ayat (5) UU PDP mewajibkan prosesor mendapatkan persetujuan tertulis Anda sebelum melibatkan prosesor lain.
Terakhir, tulis rencana keluar, yaitu format ekspor data pengguna dan log audit (misalnya CSV atau JSON) serta batas waktu vendor menghapus data setelah kontrak berakhir. Tanpa rencana ini, Anda berisiko terkunci pada satu vendor (vendor lock-in).
Contoh Matriks Penilaian Platform IAM
Matriks penilaian mengubah kriteria utama, hasil PoC, dan hitungan TCO menjadi angka yang bisa dibandingkan antarvendor. Beri bobot 3 untuk kriteria wajib, 2 untuk kriteria penting, dan 1 untuk nilai tambah, lalu beri skor 1 sampai 5 berdasarkan bukti yang terkumpul.
Nilai akhir setiap vendor adalah jumlah dari perkalian bobot dan skor di semua kriteria.
| Kriteria | Bobot | Cara menguji | Bukti yang diminta dari vendor |
|---|---|---|---|
| Integrasi dengan sistem yang sudah berjalan | 3 | Hubungkan HRIS dan dua aplikasi prioritas saat PoC | Hasil uji dan daftar konektor resmi |
| Autentikasi tahan phishing | 3 | Login admin memakai passkey atau security key | Dokumentasi dukungan FIDO2 dan kebijakan wajib MFA |
| Otomatisasi siklus hidup akses | 3 | Nonaktifkan dan pindahkan karyawan uji di HRIS | Catatan waktu perubahan akses di setiap aplikasi |
| Log audit dan laporan akses | 3 | Tarik laporan akses selama masa PoC | Contoh laporan dan masa simpan log |
| Keamanan dan lokasi data di sisi vendor | 2 | Periksa lokasi pusat data dan cakupan sertifikat | Dokumen lokasi data, sertifikat keamanan, dan daftar subprosesor |
| Ketersediaan, skalabilitas, dan akses darurat | 2 | Uji login memakai akun darurat | Riwayat gangguan, rencana pusat data cadangan, dan batas paket |
| Kemudahan pakai | 2 | Minta 10 karyawan dari divisi berbeda memakai SSO selama satu minggu | Hasil survei singkat dan jumlah tiket bantuan |
| TCO tiga tahun | 2 | Susun simulasi biaya bersama vendor | Rincian lisensi, implementasi, dan biaya keluar |
| Dukungan vendor | 2 | Ajukan tiket teknis saat PoC | Waktu respons dan SLA tertulis |
| Fitur tambahan dan peta jalan produk | 1 | Tinjau fitur di luar kebutuhan saat ini | Demo fitur dan dokumen peta jalan produk |
Sesuaikan bobot dengan kriteria wajib yang Anda tetapkan di langkah kedua, lalu perlakukan semua kriteria berbobot 3 sebagai syarat gugur. Coret vendor yang mendapat skor 1 atau 2 di salah satu kriteria itu, meskipun total nilainya tinggi.
Isi skor berdasarkan hasil PoC dan jawaban tertulis vendor, bukan kesan saat demo. Simpan matriks beserta buktinya untuk menjawab pertanyaan auditor tentang dasar pemilihan vendor.
Baca juga: 10 Rekomendasi Solusi IAM Terbaik di Tahun 2026
Kesimpulan
Platform IAM terbaik bagi perusahaan Anda adalah platform yang lolos uji dengan aplikasi dan kewajiban kepatuhan Anda sendiri, bukan platform dengan brosur paling lengkap. Jadikan integrasi HRIS, MFA tahan phishing, pencabutan akses otomatis, dan log audit sebagai syarat yang tidak bisa ditawar.
Mulailah minggu ini dengan menyusun inventaris aplikasi beserta metode login dan pemiliknya. Daftar itu menjadi dasar matriks penilaian dan skenario PoC saat Anda menghubungi vendor.
Siap Mengelola Identitas Digital sebagai Strategi Keamanan Bisnis?
Request demo sekarang dan pelajari bagaimana solusi IAM membantu memusatkan proses login pengguna melalui Single Sign-On (SSO), mengotomatisasi onboarding karyawan, serta melindungi data perusahaan dari akses tidak sah tanpa mengganggu produktivitas akibat login berulang.
FAQ
Fitur login bawaan hanya mengatur akses ke satu aplikasi, sedangkan platform IAM memusatkan login dan pengelolaan akun untuk semua aplikasi. Akibatnya, akses karyawan yang keluar cukup dicabut sekali dari satu tempat.
Perlu ketika tim IT mulai kesulitan memastikan akses karyawan yang keluar sudah dicabut di semua aplikasi, atau ketika perusahaan menyimpan data pelanggan yang dilindungi UU PDP. Mulailah dari platform berbasis cloud dengan SSO dan MFA, lalu tambah fitur seiring pertumbuhan.
Pilih cloud jika sebagian besar aplikasi Anda berbasis SaaS dan tim IT terbatas. Pilih on-premise atau hybrid jika aturan sektor mewajibkan data disimpan di infrastruktur sendiri atau sistem inti perusahaan masih berjalan di server lokal.
Pertimbangkan penggantian jika platform tidak mendukung MFA tahan phishing atau tidak bisa terhubung ke HRIS untuk mencabut akses secara otomatis. Saat menilai pengganti, uji juga jalur migrasi data dari platform lama dalam PoC.
