Tantangan & Solusi Deployment Kunci Sandi Perusahaan

1. Pendahuluan: realitas operasional kunci sandi perusahaan bagi karyawan#

Kunci sandi telah hadir di dunia kerja. Pertanyaannya bukan lagi "apakah teknologi ini berfungsi?". Pertanyaannya sekarang adalah "bagaimana kita mengoperasikan ini dalam skala besar?". Titik-titik gesekan telah berpindah ke lapisan operasional: masalah "ayam dan telur" pada pendaftaran awal (bootstrapping), perbedaan antara kunci sandi terikat perangkat dan tersinkronisasi, interoperabilitas lintas platform, dan mekanisme pemulihan yang tidak mengembalikan kerentanan seperti kata sandi.

Panduan ini membahas tantangan nyata penerapan kunci sandi di lingkungan Microsoft Entra ID, mencakup jebakan konfigurasi, alur kerja operasional, dan strategi pemulihan. Secara spesifik, kita akan membahas pertanyaan-pertanyaan berikut:

1. Apa perbedaan antara kunci sandi terikat perangkat dan tersinkronisasi di Entra ID?
2. Bagaimana cara melakukan bootstrap kunci sandi untuk karyawan baru tanpa kata sandi?
3. Bagaimana cara pengguna memulihkan akses ketika mereka mendapatkan ponsel baru dan kehilangan akses ke autentikator mereka?
4. Kesalahan konfigurasi apa yang menyebabkan kegagalan pendaftaran kunci sandi?
5. Bagaimana cara menangani tamu B2B saat mewajibkan MFA yang tahan phising?
6. Haruskah saya menggunakan kunci keamanan perangkat keras (YubiKey) atau kunci sandi seluler?
7. Bagaimana cara menangani perangkat macOS bersama dengan Windows dalam deployment kunci sandi?
8. Langkah proaktif apa yang mencegah beban berlebih pada helpdesk dari penggantian ponsel?

2. Memahami kunci sandi di Microsoft Entra#

Di Entra, "kunci sandi" = kredensial FIDO2/WebAuthn. Alih-alih kata sandi, pengguna membuktikan kepemilikan kunci privat yang tersimpan di dalam autentikator. Kredensial ini tahan phising karena WebAuthn mengikat kredensial tersebut ke asal masuk (sign-in) yang sebenarnya (sehingga situs phising yang terlihat mirip tidak dapat memutarnya ulang). Lihat ikhtisar dari Microsoft di dokumentasi konsep Passkeys (FIDO2).

Entra secara efektif mendukung dua "mode" kunci sandi yang berperilaku berbeda.

2.1 Kunci sandi terikat perangkat di Entra#

Kunci sandi ini terikat ke satu perangkat fisik (tidak dapat disinkronkan). Kunci privat ada pada elemen perangkat keras tertentu (TPM di laptop, Secure Element di YubiKey). Kunci ini tidak dapat diekspor.

Di Entra, konsep terikat perangkat ini umumnya berupa:

• Kunci sandi Microsoft Authenticator
• Windows Hello atau Windows Hello for Business (WHfB) (tidak disinkronkan sejak Januari 2026)
• Kunci keamanan FIDO2 (kunci perangkat keras seperti YubiKey)
• Kartu pintar (Smartcards)

Panduan pengaturan dasar dari Microsoft untuk kunci sandi terikat perangkat dapat ditemukan di sini: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Kasus penggunaan: Akses dengan hak istimewa tinggi, akun "darurat", lingkungan stasiun kerja bersama. Kekurangan: Hambatan tinggi. Kehilangan perangkat berarti hilangnya kredensial. Biaya operasional tinggi (misalnya mengirim YubiKey).

2.2 Kunci sandi tersinkronisasi di Entra#

Ini adalah kunci sandi yang tersimpan dalam ekosistem penyedia dan disinkronkan di seluruh perangkat pengguna (misalnya iCloud Keychain, Google Password Manager, atau penyedia pihak ketiga). Kunci privat dienkripsi dan disimpan di fabric sinkronisasi penyedia cloud.

Sejak Januari 2026, di Entra, kunci sandi tersinkronisasi ditangani melalui fitur pratinjau: Kunci sandi tersinkronisasi (pratinjau). Untuk mengaktifkan dan mengontrol kunci sandi tersinkronisasi, Entra menggunakan Profil Kunci Sandi (pratinjau).

Kesesuaian regulasi: Baru-baru ini divalidasi oleh Suplemen 1 NIST SP 800-63B sebagai kredensial yang memenuhi persyaratan AAL2. Ini merupakan kemenangan regulasi besar yang memvalidasi bahwa kunci sandi tersinkronisasi cukup "tahan phising" untuk digunakan oleh tenaga kerja umum.

Kasus penggunaan: Pekerja berpengetahuan, pengguna BYOD, kemudahan eksekutif. Kekurangan: Jaminan "lebih rendah" dari perangkat keras. Bergantung pada keamanan alur pemulihan akun dari penyedia cloud.

Berikut adalah ringkasan penyedia kunci sandi tersinkronisasi yang didukung Entra:

Pada halaman Info Keamanan pengguna, kunci sandi tersinkronisasi dan terikat perangkat dibedakan dengan jelas. Di bawah ini Anda dapat melihat bagaimana kunci sandi tersinkronisasi (dari 1Password) dan kunci sandi terikat perangkat (YubiKey 5C NFC) ditampilkan:

2.3 Keselarasan regulasi: Level NIST AAL#

• AAL3 secara historis memerlukan autentikator berbasis perangkat keras dan terikat perangkat (seperti YubiKey atau Smart Card) yang menggunakan kunci privat yang tidak dapat diekspor.
• AAL2 sekarang dapat dicapai dengan kunci sandi tersinkronisasi berdasarkan panduan NIST.
• Nuansa: Walaupun kunci sandi tersinkronisasi (seperti iCloud) sangat baik bagi pengguna standar, hal itu mungkin tidak secara ketat memenuhi persyaratan "non-eksporabilitas" AAL3 untuk level hak istimewa tertinggi. Oleh karena itu, diperlukan strategi tersegmentasi: Kunci perangkat keras untuk Admin (AAL3), Kunci Sandi Tersinkronisasi untuk pekerja umum (AAL2).

2.4 Persyaratan kesiapan perangkat#

Untuk memastikan perangkat siap bagi autentikasi tanpa kata sandi yang tahan phising, perangkat harus menjalankan versi minimum berikut:

Sistem operasi yang lebih lama mungkin memerlukan autentikator eksternal (kunci keamanan FIDO2) untuk mendukung autentikasi tanpa kata sandi yang tahan phising.

Selain persyaratan versi minimum, dukungan kemampuan dari sisi peramban juga bervariasi bergantung platform. Menurut Analisis kapabilitas klien WebAuthn Corbado Passkey Benchmark 2026, dukungan peramban Q1 2026 berada pada 97–100% untuk Conditional Get dan Hybrid Transport tetapi hanya 83–92% untuk Conditional Create pada kombinasi peramban konsumen biasa — hambatan yang paling terasa di Windows karena Windows Hello bukan merupakan alur Conditional Create, dan Edge secara khusus melaporkan dukungan Conditional Create yang sangat rendah dalam kumpulan data yang sama. Tolok ukur tersebut mencakup deployment B2C untuk konsumen alih-alih lingkungan pekerja, namun batasan kapabilitas peramban/OS yang sama tetap berlaku untuk rollout Entra ID; populasi Edge yang berat di perusahaan dapat berada jauh di bawah rentang Conditional Create campuran 83–92%.

2.5 Rekomendasi kredensial per persona pengguna#

Microsoft merekomendasikan pendekatan berbasis persona pengguna dalam pengerahan kredensial. Peran yang berbeda memiliki persyaratan keamanan dan tingkat toleransi hambatan yang berbeda:

Kredensial portabel (dapat digunakan di berbagai perangkat):

Kredensial lokal (khusus perangkat):

Tujuan akhirnya: Sebagian besar pengguna harus memiliki minimal satu kredensial portabel ditambah kredensial lokal pada setiap perangkat komputasi mereka.

3. Pengalaman dari Deployment Kunci Sandi Langsung#

Saat berbicara dengan organisasi yang telah menerapkan kunci sandi, beberapa poin hambatan dan pola dunia nyata dapat dikenali.

3.1 Pergeseran operasional#

"Tantangannya bukan terletak pada tumpukan teknologi, melainkan lapisan operasionalnya." Ini menegaskan bahwa rintangan teknis seperti kesalahan "Passkey not registered" atau tidak munculnya opsi Windows Hello pada perangkat pribadi bukanlah anomali, melainkan hambatan sistemik yang melekat pada tingkat kematangan ekosistem saat ini. Untuk operasi perusahaan, kuncinya adalah memisahkan kegagalan yang wajar dan tak terduga dalam pemantauan. Kelompokkan kesalahan WebAuthn secara eksplisit dan lacak NotAllowedError, AbortError, serta kesalahan kunci sandi Credential Manager sebagai sinyal berbeda. Playbook analitik autentikasi kami memberikan kerangka kerja untuk mengklasifikasikan sinyal ini, dan analitik kunci sandi mencakup KPI spesifik kunci sandi seperti aktivasi dan tingkat masuk (login).

3.2 Pendaftaran: momen penentuan#

Pendaftaran adalah fase paling sulit dalam pengerahan (deployment), dan membutuhkan manajemen perubahan yang signifikan.

• Kerumitan pra-registrasi: Memasukkan karyawan baru yang tidak memiliki kredensial sebelumnya merupakan masalah utama. Ketergantungan pada pendaftaran yang dimediasi admin menciptakan pengalaman pengguna yang terputus-putus.
• Fragmentasi platform: "Frustrasi pengguna dengan langkah-langkah" disebabkan oleh iterasi independen dari peramban, Sistem Operasi, dan pengelola kata sandi. Hal ini mengakibatkan inkonsistensi sementara, di mana alur berhasil di Chrome/Windows namun gagal di Safari/macOS atau gagal di perangkat pribadi yang tidak dikelola sementara sukses di perangkat perusahaan.

3.3 Kesenjangan model mental#

"Pengguna tidak butuh kriptografi, mereka butuh model mental". Kebingungan terminologi membebani kognitif:

• Passkey (Kunci Sandi)
• Security Key (Kunci Keamanan)
• Hardware Key (Kunci Perangkat Keras)
• YubiKey
• Passwordless (Tanpa Kata Sandi)
• Windows Security
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Phone Sign-in (Masuk dengan Ponsel)

Bagi pengguna yang tidak melek teknologi atau bahkan yang memahaminya, perbedaan istilah-istilah ini tidak selalu jelas.

Kami menyarankan untuk menghindari jargon teknis seperti "tahan phising" atau "pasangan kunci" dalam komunikasi pengguna akhir. Sebaliknya, fokuskan pada konsep "buka kunci": "Gunakan wajah Anda untuk membuka sistem perusahaan," mirip dengan saat membuka kunci ponsel mereka.

3.4 Keterbatasan komunikasi#

Adopsi yang kuat pada awalnya adalah kunci keberhasilan, namun komunikasi saja tidak cukup. Anda tidak bisa sering mengirim email meminta pengguna memeriksa metode autentikasi mereka. Pada umumnya, Anda tidak dapat merencanakan perilaku pengguna dengan baik. Fakta ini mendorong kebutuhan akan langkah-langkah teknis proaktif ketimbang hanya mengandalkan edukasi pengguna.

4. Analisis Mendalam Konfigurasi Microsoft Entra ID#

Mengerahkan kunci sandi di lingkungan perusahaan menuntut pemahaman dan pengaturan kebijakan yang saling terkait. Kunci sandi bukan sekadar fitur yang bisa dinyalakan begitu saja, karena ia berdampak besar pada pekerjaan sehari-hari karyawan.

4.1 Kebijakan metode autentikasi#

Portal MFA dan SSPR lawas sudah tidak lagi digunakan (deprecated). Semua konfigurasi FIDO2 harus dilakukan di area (blade) Authentication Methods Policy yang terpadu.

• Metode Kunci Keamanan FIDO2: Harus diaktifkan dan ditargetkan. Disarankan menargetkan "Semua Pengguna" (All Users) untuk pengaktifan, tetapi kendalikan penegakannya melalui Conditional Access.
• Pembatasan Kunci (AAGUID): Setiap perangkat FIDO2 (mis. YubiKey 5 NFC, Microsoft Authenticator di iOS, Google Password Manager) memiliki Authenticator Attestation GUID (AAGUID) unik. Sebagai praktik terbaik, untuk lingkungan dengan keamanan tinggi, gunakan pengaturan "Enforce Key Restrictions" agar hanya Mengizinkan AAGUID tertentu yang disetujui. Ini mencegah pengguna mendaftarkan kunci keamanan "pasar gelap" yang murah dan belum terverifikasi.

4.2 Attestation: titik keputusan penting#

Salah satu keputusan konfigurasi paling signifikan adalah "Enforce Attestation".

• Fungsinya: Memaksa autentikator untuk membuktikan secara kriptografis merek dan modelnya kepada Entra ID saat pendaftaran.
• Konflik: Kunci Sandi Tersinkronisasi (yang disimpan dalam penyedia perangkat lunak seperti iCloud Keychain, Bitwarden, atau Google Password Manager) umumnya tidak mendukung attestation karena mereka berbasis perangkat lunak dan agnostik-platform. Mereka tidak dapat menandatangani tantangan dengan sertifikat kumpulan (batch) perangkat keras.
• Dampak (Trade-off):
  • Diatur ke YES: Diwajibkan untuk jaminan tinggi (AAL3). Memastikan kunci terikat ke perangkat keras. Memblokir penyedia kunci sandi berbasis perangkat lunak.
  • Diatur ke NO: Membolehkan Kunci Sandi Tersinkronisasi. Menurunkan sedikit jaminan (AAL2). Mengizinkan penyedia kunci sandi berbasis perangkat lunak.

Anda tidak dapat menerapkan kebijakan global "No Attestation" jika Anda memiliki admin hak istimewa tinggi yang membutuhkan kunci perangkat keras. Anda harus menggunakan Passkey Profiles (Pratinjau):

• Profil A (Admin): Enforce Attestation = Yes
• Profil B (Staf Umum): Enforce Attestation = No

4.3 Profil Kunci Sandi dijelaskan#

Anggaplah Profil Kunci Sandi sebagai mekanisme untuk menentukan:

• "Pengguna ini bisa memakai kunci sandi tersinkronisasi"
• "Pengguna ini harus menggunakan terikat perangkat saja"
• "Attestation diwajibkan vs tidak diwajibkan" (dan karenanya: kunci sandi tersinkronisasi diizinkan vs dikecualikan)
• "Batasi ke jenis autentikator tertentu (pembatasan AAGUID)"

Di bawah ini Anda bisa melihat halaman pengaturan Passkey (FIDO2) di pusat admin Microsoft Entra tempat Anda mengonfigurasi profil kunci sandi:

Saat mengedit profil kunci sandi, Anda bisa mengonfigurasi penegakan attestation, tipe target (terikat perangkat, tersinkronisasi, atau keduanya), serta batasan spesifik AAGUID:

4.4 Kekuatan Conditional Access & autentikasi#

Penegakan dapat ditangani lewat kebijakan Conditional Access (CA) dengan memanfaatkan Kekuatan Autentikasi (Authentication Strengths).

• Kekuatan MFA Tahan Phising: Kekuatan bawaan ini mewajibkan FIDO2, Windows Hello for Business (WHfB), atau Certificate-Based Authentication (CBA).
• Jebakan Penguncian (Lockout Trap): Jika Anda membuat kebijakan CA yang mewajibkan "Phishing-Resistant MFA" untuk "All Cloud Apps" dan menerapkannya kepada "All Users," Anda seketika akan mengunci setiap pengguna yang belum mendaftarkan kunci sandi. Mereka bahkan tidak bisa masuk untuk mendaftarkannya.
• Paradoks "Register Security Info": Ini adalah Tindakan Pengguna spesifik di dalam CA. Jika Anda mewajibkan Phishing-Resistant MFA untuk melakukan tindakan Register Security Information, Anda membuat ketergantungan melingkar (ayam dan telur). Pengguna tidak dapat mendaftarkan kunci sandi pertama mereka karena butuh kunci sandi untuk mengakses halaman pendaftaran tersebut.

Berikut adalah ringkasan metode autentikasi apa yang memenuhi persyaratan kekuatan apa:

4.5 Autentikasi pilihan sistem (System-preferred authentication)#

Fitur "System-preferred multifactor authentication" dari Entra ID memaksa mesin masuk (sign-in) untuk meminta pengguna menggunakan metode terdaftar yang paling aman.

Jika seorang pengguna mendaftarkan SMS maupun kunci sandi, sistem secara asali akan menggunakan kunci sandi. Hal ini mendorong adopsi kunci sandi secara organik tanpa harus ada penegakan keras. Pada dasarnya fitur ini "meningkatkan" posisi keamanan pengguna secara otomatis setelah mereka mendaftarkan kredensial tersebut.

Di bawah ini Anda dapat melihat pengalaman masuk dengan kunci sandi. Pengguna diminta untuk menggunakan "Face, fingerprint, PIN or security key" dan mereka dapat memilih kunci sandi dari ekstensi peramban atau pengelola kredensial sistem:

4.6 Pertimbangan macOS: Platform SSO#

Bagi organisasi yang memiliki lingkungan campuran Windows/macOS, macOS Platform SSO memberikan perangkat yang setara dengan Windows Hello for Business di ekosistem Apple. Dikombinasikan dengan solusi MDM, Anda dapat mencapai hal berikut:

• Kredensial terikat perangkat yang tertaut ke Secure Enclave Mac
• Pengalaman SSO di seluruh aplikasi native (asli) dan aplikasi web
• Autentikasi tahan phising yang memenuhi persyaratan AAL2/AAL3

Catatan: macOS Platform SSO mensyaratkan macOS 13+ dan konfigurasi MDM yang tepat. Pengaturan ini berbeda jauh dengan WHfB di Windows, sehingga Anda perlu merencanakan jalur pengerahan terpisah.

5. Kesalahan konfigurasi umum: mengapa "ini hanya berfungsi di Microsoft Authenticator"#

Jika tujuan Anda adalah kunci sandi tersinkronisasi di perangkat tak terkelola (unmanaged), berikut ini adalah penghalang utamanya:

5.1 Kunci sandi tersinkronisasi tidak diaktifkan/ditargetkan#

Tidaklah cukup hanya dengan menyalakan "FIDO2" secara umum di Entra. Untuk kunci sandi tersinkronisasi, Anda biasanya membutuhkan:

• Jalur fitur pratinjau yang dijelaskan dalam Kunci sandi tersinkronisasi (pratinjau)
• Konfigurasi profil menggunakan Profil Kunci Sandi

Jika suatu grup tidak ditargetkan oleh profil yang membolehkan kunci sandi tersinkronisasi, Anda akan kembali tertarik ke dunia yang "hanya terikat perangkat".

5.2 Attestation diwajibkan (memblokir kunci sandi tersinkronisasi)#

Ini menjadi penyebab sebagian besar pertanyaan di organisasi yang sadar keamanan:

• Entra dapat mewajibkan attestation untuk beberapa skenario kunci sandi (membantu memvalidasi jenis/sumber autentikator)
• Kunci sandi tersinkronisasi tidak mendukung attestation di Entra, sehingga bila attestation diwajibkan, pendaftaran kunci sandi tersinkronisasi akan gagal dan Anda akhirnya hanya akan memiliki opsi terikat perangkat

5.3 Daftar izinkan (allow-listing) AAGUID memblokir penyedia#

Entra mengizinkan Anda membatasi autentikator apa yang diizinkan (biasanya melalui daftar izin/blokir AAGUID). Jika Anda hanya mengizinkan Microsoft Authenticator (atau sekelompok kecil autentikator lain), penyedia tersinkronisasi pihak ketiga secara implisit akan terblokir. Bagian membingungkannya adalah bahwa autentikasi lokal (mis. Touch ID, Face ID, pemindaian biometrik Windows) berhasil namun halaman masuk Entra menampilkan pesan kesalahan.

5.4 Conditional Access memaksakan jenis kunci sandi tertentu#

Meskipun kunci sandi diaktifkan, Conditional Access (CA) secara efektif dapat memaksa pengguna untuk hanya menggunakan beberapa metode tertentu (mis. "Hanya Authenticator" atau kekuatan yang dikonfigurasi tidak mengizinkan profil kunci sandi yang dimaksudkan). Dalam praktiknya ini menciptakan "ketergantungan Authenticator" bahkan saat rencananya adalah kunci sandi tersinkronisasi.

5.5 Tamu B2B vs akun anggota#

Apabila mitra eksternal adalah pengguna tamu B2B di tenant resource, ada batasan yang sudah diketahui seputar di mana/bagaimana mereka bisa mendaftarkan metode autentikasi. Hal ini seringkali menjadi pertanyaan "kenapa gagal?" padahal tujuannya adalah "mitra menggunakan kunci sandi di tenant kami."

6. Tantangan Operasional & Solusinya#

6.1 Paradoks Bootstrapping#

Masalah paling meresap ("Pendaftaran adalah bagian tersulit") adalah masalah bootstrapping: Bagaimana cara Anda secara aman menerbitkan kredensial dengan jaminan tinggi ke pengguna yang belum punya kredensial (atau hanya punya kredensial dengan jaminan rendah)?

6.1.1 Temporary Access Pass (TAP)#

Temporary Access Pass (TAP) adalah pendekatan arsitektural untuk orientasi tanpa kata sandi (passwordless onboarding).

• Apa itu: Sebuah kode sandi sementara dengan entropi tinggi (misalnya 1 jam) yang diperlakukan oleh Entra ID sebagai metode "autentikasi kuat" (strong authentication). Ini mengesampingkan kebutuhan atas kata sandi atau MFA yang ada.
• Alur Kerja:
  1. Verifikasi Identitas: Identitas karyawan baru diverifikasi (misalnya lewat proses SDM atau verifikasi Manajer).
  2. Penerbitan: Seorang admin (atau Logic App otomatis) membuat TAP untuk pengguna.
  3. Masuk "Ajaib": Pengguna pergi ke aka.ms/mysecurityinfo. Mereka memasukkan nama pengguna dan TAP tersebut.
  4. Pendaftaran: Karena TAP telah memenuhi persyaratan "Strong Auth", pengguna diizinkan untuk mengakses area Security Info. Mereka mengklik "Add Method" dan mendaftarkan kunci sandi mereka.
  5. Tahap Konstan (Steady State): TAP kadaluarsa. Pengguna kini punya kredensial yang tahan phising. Mereka tidak pernah mengetikkan kata sandi sekalipun.

6.1.2 Otomatisasi melalui Graph API#

Untuk organisasi besar, penerbitan TAP manual tidak terukur skalanya. Praktik terbaik adalah mengotomatisasi melalui Microsoft Graph API.

• Skenario: Karyawan baru diproses di sistem SDM (Workday/SuccessFactors).
• Pemicu: Acara provisioning akan memicu Azure Logic App.
• Tindakan: Logic App memanggil POST di Graph API /users/{id}/authentication/temporaryAccessPassMethods.
• Pengiriman: TAP secara aman dikirimkan kepada manajer rekrutmen atau email pribadi pengguna (terenkripsi) agar dapat mengakses sistem di hari pertama kerja.

6.1.3 Microsoft Entra Verified ID untuk onboarding berjaminan tinggi#

Untuk onboarding jarak jauh atau skenario yang membutuhkan jaminan identitas tinggi, solusi Entra Verified ID dari Microsoft dengan fitur Face Check memberikan jalur pendaftaran tanpa kata sandi:

1. Pembuktian Identitas: Pengguna baru memverifikasi identitas lewat mitra IDV (pemindaian ID pemerintah).
2. Pencocokan Biometrik: Face Check membandingkan swafoto (selfie) langsung dengan foto di dokumen identitas menggunakan Azure AI Vision. Hanya skor tingkat kepercayaan kecocokan yang dibagikan (tidak ada data biometrik mentah).
3. Kredensial Terverifikasi (Verified credential) diterbitkan: Pengguna menerima kredensial Verified ID.
4. Penerbitan TAP: Setelah verifikasi berhasil, sistem akan menerbitkan sebuah Temporary Access Pass.
5. Bootstrap Kunci Sandi: Pengguna mendaftarkan kunci sandi pertama mereka memakai TAP tersebut.

Alur Face Check memandu pengguna melalui tiga tahapan: Verifikasi (bagikan kredensial), Konfirmasi (lakukan pindaian wajah), dan Tinjauan (lihat hasil kecocokan):

Alur ini memungkinkan akun benar-benar tanpa kata sandi dari hari pertama. Tidak ada kata sandi yang pernah dibuat.

6.2 Masalah penggantian ponsel (tantangan skala tersembunyi)#

Ini seringkali menjadi sumber panggilan ke helpdesk terbesar dalam deployment kunci sandi. Organisasi dengan populasi BYOD skala besar (misalnya lebih dari 10.000 perangkat) dapat melihat peningkatan besar pada panggilan bantuan teknis (support calls) sekadar karena pengguna membeli ponsel baru namun tidak mengetahui cara mendaftarkan kembali metode autentikasi mereka.

Ketika Anda memasukkan kunci sandi ke dalam skenario ini, masalah ini menjadi semakin kritis karena:

• Pengguna menginstal aplikasi (seperti Outlook) pada ponsel barunya
• Aplikasi-aplikasi ini meminta pengguna untuk melakukan autentikasi
• Prompt (permintaan) MFA muncul di ponsel yang lama (yang mungkin sudah mereka jual atau reset/hapus)
• Pengguna terkunci dan harus menelepon helpdesk

6.2.1 Matriks skenario untuk penggantian ponsel#

Tujuannya adalah mengalihkan sebanyak mungkin kasus ke dalam dua baris pertama agar meminimalisir keterlibatan helpdesk.

6.2.2 Trik pendaftaran Intune#

Sebuah wawasan cerdas: Menjadikan kunci sandi sebagai syarat pendaftaran Intune akan memaksa pengguna merampungkan pengaturan Microsoft Authenticator di ponsel baru dengan segera - sebelum mereka dapat membuka aplikasi perusahaan.

• Kondisi saat ini: Pendaftaran Intune mensyaratkan eskalasi (step-up) MFA. Artinya, jika Anda ingin log masuk di ponsel baru, Anda menginstal Outlook di sana. Tetapi, notifikasi MFA masuk ke ponsel lama.
• Dengan persyaratan kunci sandi: Pengguna wajib menyetel Microsoft Authenticator sebagai kunci sandi di ponsel baru lebih dulu sebelum merampungkan pendaftaran. Hal ini langsung dilakukan (di hari penggantian ponsel) ketimbang menunggu berbulan-bulan sampai ponsel lama sudah tidak ada.

Ini tidak menyelesaikan persoalan pemulihan, namun menggeser linimasanya. Pengguna dapat mendaftarkan perangkat baru tatkala mereka masih bisa mengakses perangkat yang lama.

6.3 Kunci keamanan perangkat keras hadir dengan persoalan logistik#

Kunci perangkat keras (YubiKey, dll.) adakalanya diposisikan sebagai solusi pamungkas. Di atas kertas mungkin begitu, namun di dunia nyata menghadirkan tantangan tambahan:

• Mimpi buruk logistik: Organisasi yang tadinya menerapkan token fisik (seperti RSA SecurID) kerap menghabiskan waktu bertahun-tahun untuk berusaha melenyapkannya. Mengganti satu program token fisik dengan token fisik lain tidaklah menarik.
• Pengiriman langsung (Drop-shipping): Yubico bisa langsung mengirim kunci ke pengguna dan kuncinya tidak perlu penggantian baterai setiap beberapa tahun (tidak seperti SecurID). Namun, jika seorang pegawai melupakan kuncinya, mereka tidak akan bisa masuk (untuk jenis desktop bersama).
• Beban Tim TI Lokal: Supervisor lokal seharusnya tidak otomatis menjadi staf TI saat ada staf yang melupakan kuncinya.
• Biaya: Kunci perangkat keras akan menambah ongkos per-pengguna seiring meningkatnya tenaga kerja.

Kapan kunci perangkat keras diperlukan:

• Admin Tingkat 0 (Tier 0): Admin domain, akun darurat
• Stasiun kerja bersama (Shared workstations): Kios-kios, pabrik, komputer jinjing / tablet lapangan
• Kontraktor tanpa fasilitas BYOD: Pengguna luar yang tidak menggunakan gawai mereka sendiri

6.4 Masalah perangkat tidak terkelola (unmanaged)#

Banyak pengguna yang mengeluh karena mereka tidak bisa melihat pilihan masuk dengan kunci sandi dari peranti pribadi. Ini merupakan tipe rintangan "unmanaged device" (perangkat tidak terkelola) yang biasa terjadi.

6.4.1 Analisis pesan kesalahan "Passkey not registered"#

Pengguna mungkin tidak bisa menambah kunci sandi di perangkat pribadi mereka, namun bisa melakukannya di perangkat korporat. Kemungkinan hal ini disebabkan oleh Intune Compliance Policies (Kebijakan Kepatuhan Intune) yang berinteraksi dengan alur registrasi.

• Mekanisme: Windows Hello for Business (WHfB) pada dasarnya adalah kredensial platform. Ia terikat ke TPM perangkat tertentu (sebagai kunci sandi terikat perangkat).
• Batasan: Supaya bisa mendaftar WHfB, perangkat harus dikategorikan sebagai Joined (baik Entra Joined atau Hybrid Joined) pada tenant. Perangkat perseorangan yang statusnya cuma "Registered" (Workplace Joined) kemungkinan kena aturan kebijakan Intune yang mencegah penyediaan (provisioning) kontainer WHfB manakala peranti itu belum dikelola seutuhnya atau belum menuruti aturan. Simak Persyaratan proses masuk (sign-in) kunci keamanan FIDO2.
• Opsi "Passkey": Di peranti pribadi, harusnya para pengguna mendaftarkan FIDO2 Security Key (perantauan) atau Kunci Sandi Lintas-Perangkat / Cross-Device Passkey (lewat ponsel mereka), bukan Windows Hello for Business (kecuali sudah ada pendaftaran BYOD yang didukung secara paripurna).
• Masalah Visibilitas Entra ID: Jika opsi "Windows Hello" tidak terpampang, itu berarti perangkat tersebut belum menyelesaikan pendaftaran MDM sebagai sebuah prasyarat.

6.4.2 Kegagalan Autentikasi Lintas-Perangkat / Cross-Device Authentication (CDA)#

Pada peranti tidak terkelola, banyak pengguna lantas memakai langkah Cross-Device Authentication (CDA) (yakni pemindaian kode QR di PC menggunakan ponsel mereka).

• Ketergantungan terhadap Bluetooth: Metode CDA mensyaratkan fungsi Bluetooth agar selalu nyala pada kedua alat. Mereka tak harus di-"pairing", akan tetapi mereka diharuskan untuk melakukan jabat tangan (handshake) Bluetooth Low Energy (BLE) untuk membuktikan posisi kedekatannya. Baca rincian terkait kunci sandi terikat-perangkat dalam Microsoft Authenticator untuk penjelasan selengkapnya.
• Penghalang Kebijakan Perusahaan: Kalau opsi Bluetooth tak diaktifkan di PC atas alasan "kemanan" via BIOS atau GPO, hal itu akan memutus seluruh mekanisme dasar kredensial perantauan (roaming).
• Pemblokiran Websocket: Proses CDA memakai jalur websocket untuk terkoneksi ke alamat cable.ua5v.com atau cable.auth.com. Sejumlah kebijakan firewall ketat maupun pengaturan Zscaler sangat sering menghadang domain ini, dan jadinya alur scan kode QR macet total ataupun diam-diam gagal. Baca panduan tentang dokumentasi kunci sandi Microsoft Authenticator.

6.5 Identitas B2B dan pihak eksternal#

Persoalan lain untuk suatu perusahaan ialah mengenai konsultan dari pihak di luarnya (Pengguna Tamu B2B).

• Masalah: Seorang konsultan berupaya masuk pada sebuah web SharePoint. Sementara pihak tenant memaksakan suatu Kebijakan Akses Bersyarat (Conditional Access) perihal kewajiban "MFA Tahan Phising".
• Kegagalan: Konsultan tersebut mencoba untuk mendaftarkan peranti FIDO2 miliknya pada tenant yang memberi akses (resource tenant). Pendaftaran ini akan berakhir dengan kegagalan. Hal ini terjadi karena Entra ID tidak memperbolehkan para pengguna tamu meregistrasi kredensial FIDO2 mereka ke dalam resource tenant.
• Solusi: Cross-Tenant Access Settings
  • Logika: Daripada mendikte pihak tamu untuk meregistrasi kredensial barunya pada wilayah Anda, maka Anda bisa mempercayai langsung kepada kredensial manapun yang mereka pergunakan dalam instansi mereka.
  • Konfigurasi: Akses ke External Identities > Cross-tenant access settings. Sesudahnya, pilih bagian organisasi mitra terkait. Selanjutnya, di area Inbound Trust, beri contreng pada "Trust multifactor authentication from Microsoft Entra tenants".
  • Hasil: Saat sang konsultan masuk login (sign in) mempergunakan YubiKey mereka di tenant asalnya, maka server (tenant) Anda bakal mendapatkan pernyataan konfirmasi perihal "MFA Satisfied + Phishing Resistant" tersebut. Akses lalu akan diperkenankan otomatis. Dengan demikian, tugas pengaturan kredensial dialihkan pada sang rekan, hal ini ikut menyunat berbagai risiko juga akan meredam angka pelaporan masalah TI Anda.

7. Strategi pemulihan#

Sering kali kebijakan soal langkah pemulihan belum siap sesudah tahap pengerahan awal. Pada dasarnya terdapat ragam solusi pemulihan yang berpulang lagi menyesuaikan kebutuhan organisasi.

7.1 Pemulihan Akun Mandiri (SSAR) Berbasiskan Verified ID#

Fasilitas baru dari Pemulihan Akun Mandiri (Self-Service Account Recovery / SSAR) milik Microsoft Entra ID (sedang dalam Pratinjau / Preview) menunjang proses pemulihan mutu tinggi tak harus merepotkan layanan helpdesk.

1. Pemicu: Pengguna sama sekali tak dapat melakukan pendaftaran masuk (sign in). Pengguna memilih pada bagian "Recover my account."
2. Verifikasi Identitas: User ini lalu dilarikan ke laman perantara Identity Verification (IDV) di luar sistem (contoh: Onfido, IDemia).
3. Pemeriksaan Dokumen: Mereka lalu diarahkan untuk memindai bukti surat seperti kartu lisensi mengemudi, identitas resmi yang diakui atau bisa juga melalui dokumen paspor memanfaatkan tangkapan dari piranti kamera ponselnya.
4. Cek Keberadaan (Liveness Check): Mengawali pemeriksaan, partisipan mempergunakan swafoto dengan langkah Pengecekan Wajah (Face Check). Pencocokan ini selanjutnya akan diadukan selaras berdasarkan wajah identitasnya (yang pastinya terkait dengan potret wajah awal di server Entra ID mereka). Rujukan kecocokannya mengedepankan platform pemrograman antarmuka (API) Wajah Azure AI Vision dan murni menampilkan hasil poin tingkat kepercayaannya saja. Tiada bentuk pindaian mentah dikirim pada program aplikasi.
5. Pemulihan (Restoration): Jikalau verifikasi berhasil, sistem lalu dengan spontan membuat sebuah kunci Temporary Access Pass (TAP) menuju pemiliknya.
6. Pendaftaran Ulang: Pengguna mempergunakan TAP-nya dalam mendaftarkan kata sandi terkini (kunci sandi baru) sesegera mungkin.

Rekomendasi: Penggunaan jalur otomat dengan sistem pencocokan wajah akan menjadi alternatif mutakhir dibandingkan cara lama: "Panggilan Layanan Bantuan," di mana langkah ini malah sangat mudah menjadi target eksploitasi peretasan psikologis / rekayasa sosial (social engineering) seperti (Peniruan berbasis Deepfake Voice).

7.2 Pemulihan dengan Bantuan Manajer lewat My Staff#

Misalkan tujuan kita mengurangi tanggungan layanan keluhan, tapi kita tak diperbolehkan memberikan izin akses sepenuhnya pada sistem self-service, pihak pengembang Microsoft Entra sebenarnya menyematkan pilihan bantuan administratif spesifik, yakni pendelegasian yang punya sandi My Staff.

• Cara Operasi: Mendelegasikan kewenangan khusus berbatas waktu pada "Para Pengawas" di area timnya (bisa via Unit Admin Entra).
• Alur Utama: Manakala akses terputus, mereka dibolehkan menghubungi admin spesifik daerah itu, di mana mereka dapat menggunakan pintu portal My Staff sebagai jembatan bagi tugas terkait seperti mengubah kata kunci (password) dan nomor seluler yang bersangkutan.
• Manfaat Utamanya: Ini pastinya menggeserkan tugas-tugas dasar urusan kata sandi yang sebelumnya cuma bisa dipertanggungjawabkan pada biro bagian depan (helpdesk pusat) jadi menolong penyelesaian pertolongan yang lebih cepat.

7.3 Kios Pemulihan Mandiri (Intranet)#

Mengingat masih seringnya pegawai menyimpan perangkat khusus, contohnya laptop berfasilitas keamanan tinggi terikat sandi peranti WHfB, sangat relevan sekali kita membentuk antarmuka khusus (berstatus intranet).

• Membangun: Berbentuk portal web minimalis dengan keharusan akses mempergunakan (sandi masuk tangguh) tipe keamanan WHfB.
• Langkah Operasi (Action): Sesaat telah divalidasi keabsahannya, ada tautan berbunyi "Saya telah beralih pada peranti gawai baru". Program antarmuka intranet lantas memerintahkan pemakaian layanan belakang yang tersambung Microsoft Graph API untuk melahirkan akses sandi sementara yakni (TAP) agar nampak ke permukaannya secara langsung.
• Hasil: Kemudian orang itu bisa meletakkan kombinasi angka TAP pada perangkat anyarnya buat mereset Microsoft Authenticator-nya. Betul-betul nihil campur tangan operator pusat keluhan masalah.

Sebetulnya pendekatan inilah yang menjadi tuas utama untuk mengatasi pemutihan metode "kredensial tanpa sandi" yang tak memperlemah tatanannya sedikitpun. Sewaktu metode penggunaan alat pangku (laptop) telah diterapkan untuk langkah mereset dan pendaftaran autentikasi ini, otomatis jumlah tanggungan terkait panggilan informasi berkurang signifikan lantaran mereka tahu bagaimana me-reset kuncinya sekalipun mungkin tak memahaminya di bagian luar kerjanya.

8. Rekomendasi Terkait Tatanan Deployment Kunci Sandi Korporat#

Tetapkan penyebarannya berdasarkan konsep per kategori atau Fase Tahap Kedewasaan (Maturity Stages). Terimalah bahwa akan dihadapkan kepada keruwetannya sendiri ("Bukan hal teknologi, sebaliknya lapisan tatanan operasional merupakan rintangan utama") hingga siapkan strategi penyelesaian.

8.1 Tindakan Langsung ("Fase Perbaikan / Fix-It")#

1. Pemeriksaan Bluetooth dan Firewall Sistem: Sediakan jaminan perangkat dapat tersambung via bluetooth komputernya (mendukung verifikasi interaksi kedekatan/proximity) lalu whitelist-lah tautan akses dari relay berbasiskan tautan FIDO maupun WebAuthn, (\*.cable.auth.com) yang fungsinya bisa memperbaiki sinkronisasi antar berbagai alat peranti.
2. Hidupkan Skema Cross-Tenant Trust: Segeralah abaikan registrasi secara tersendiri buat akun milik kelompok eksternal / para pengguna luar peranti ini. Lebih disarankan untuk menyalakan tatanan Inbound Trust buat para penilai (partner) tersebut biar dapat menghalau kemacetan pintu login B2B dari instansinya secara langsung seketika.
3. Persiapkan Skema TAP Menghadapi Tahapan Onboarding: Putuskan untuk mendelegasikan opsi kebijakan untuk menetapkan Temporary Access Pass untuk tiap individu peranti / staf rekrutan awal yang gunanya menyelesaikan perselisihan dari sistem blokir antara ayam versus telor.

8.2 Segala Keputusan Taktis ("Tahap Tatanan Arsitektural / Architecture")#

1. Jalankan "Asas Hybrid":
   • Tier 0 (Administrator): Berikan paksaan kepada Attestation atau persyaratan bukti peranti berwujud maupun Key Restrictions. Jadi harus YubiKey dan semacam (AAL3).
   • Tier 1 (Tenaga Kerja): Abaikan saja aturan paksaan khusus atau Attestation ini dengan merancang fungsi ini menjadi area ranah non-wajib melalui parameter di tab Passkey Profiles. Persilakan penggunaan fitur sinkronisasinya hingga memotong level friksi operasional sembari menyesuaikan AAL2 bagi para karyawan.
2. Kalkulasikan Untuk Perangkat Apple Khusus (macOS): Padukan tatanan peranti MDM milik JAMF lewat penggunaan layanan skema perizinan Apple terintegrasi layaknya sebuah sistem Platform SSO sebagai sarana untuk mendampingi alat penyokong sandi sistem WHfB bawaan sistem operasi PC Windows itu sendiri.

8.3 Kesiapan Menghadapi Perkembangan Fase Ke Depannya ("Optimalisasi Fase / Optimization")#

1. Rencanakan Model SSAR: Inisialisasikan tahap pilot project demi tatanan SSAR Berstatus Verified ID demi menghindarkan ranah helpdesk dari sasaran empuk atas sasaran penipu bermotif social engineering di kemudian harinya.
2. Fokus pada Penerapan Sandi Utama Pada Fitur Sistem-Preferred Auth: Implementasikan tatanan standar itu lalu paksa sistem ini menaikkan pamor secara halus "upgrade" kepada kalangan yang mempergunakan fitur masuk ini, demi merajut percepatan jumlah para pengguna.
3. Deploy Opsi Model Skema Pendukung Sistem Ter-Recovery: Bangun TAP Model Delegasi Peran via fitur tab fungsionalitas My Staff serta dipadukan juga Kios Model Peranti Bantuan Mandiri.
4. Intune Passkey Requirement: Anda patut membuat paksaan menggunakan kredensial berupa sandi digital (passkey) ke ranah kewajiban (enrollment Intune) saat menapaki sesi pendaftaran masuk, demi mempercepat implementasinya dari dini (awal fase pendaftaran alat).

8.4 Matriks Penanganan Masalah Secara Khusus (Troubleshooting Matrix)#

9. Pantau deployment Anda menggunakan Workbooks untuk Kata Sandi Khusus Bebas Tahan Phishing (Phishing-Resistant Passwordless Workbook)#

Microsoft sendiri sudah pernah mengeluarkan edisi buku atau log laporan Phishing-Resistant Passwordless Workbook yang diakses khusus pemakaian platform bagi Azure Monitor secara langsung dan tepat dari area tab khusus bernama admin pusat di bagian Monitoring > Workbooks:

Pilihan fungsional workbook-nya ada dua bagian terkemuka, yaitu:

9.1 Sesi Bagian Penyelarasan Enrollment (Fase Enrollment Readiness Phase)#

Manfaatkan log halaman khusus pemantauan masuk untuk memperhitungkan para pemakai atau siapa-siapa saja saja yang dinilai sukses mengakses maupun mana alat akses saja yang ternyata gagal. Gunakanlah filter pembedanya dengan menyetel variasi penyeleksian alat melalui tipe mesin pemakaiannya (yakni alat komputer desktop berbasis Windows, macOS Apple, sistem iOS, atau jenis Android) dan tipe parameter penggunaan jenis kunci aplikasinya (Authenticator App Passkey, sandi tipe Hardware / FIDO2 Security Key, maupun model bersertifikat perizinan via file atau Certificate-Based Authentication):

Catatan datanya mencatat bahwa:

• Pemakai Yang Tercatat dan Alat Mesin Terakui Masuk atau Biasa Disebut: User/Device Pairs Ready for Enrollment: kelompok perangkat ini dinilai bebas masalah.
• Akses Pengguna Ataupun Komputer Tak Diberi Persetujuan atau User/Device Pairs Not Ready: daftar orang maupun alat ini tidak memenuhi tahapan pendaftarannya, (ada indikator yang menyebut perangkat bersistem terlampau usang dll).

Kemudian untuk laporannya dapat ditarik untuk mendapatkan panduan terhadap target remidiasi tindakan khusus, berupa misal pembaharuan OS (OS upgrades), perangkat atau alternatif autentikasinya (alternative credential options).

9.2 Penegakan / Kewajiban Pelaksanaan (Enforcement Readiness Phase)#

Begitu tenaga kerja di lingkungan organisasi siap menjalankan MFA Tahan Phising, buka menu laporan masuknya di sebelah Enforcement Readiness. Sebelumnya pastikan terlebih dahulu, yakni melalui pembentukan sebuah kerangka skenario laporan yang berfungsi membaca tingkat pelaporannya saja (Report-Only) yang ada di Conditional Access. Dari sini Anda bakalan menatap sejumlah keterangan masuk guna dapat membaca laporan jikalau opsi pemaksaan tadi mulai diterapkan (Enforcement active) di hari ke depannya.

Dari Dashboard kita bisa menyimak:

• Total jumlah pegawai / users yang dimonitor
• Report Only Success - individu berhasil masuk ke skenario tatanannya
• Policy Not Satisfied - anggota-anggota ini (akan keblokir jika tidak segera dituntaskan solusinya!)
• Device State, Device Platform dan Client App merupakan data penjabarannya

Arahkan layar pengguna menuju pada bagian parameter ini: Further Data Analysis guna melakukan proses investigasinya. Inilah bekal krusial yang bisa diperbantukan sebelum tahapan kewajiban diberlakukan kepada karyawannya.

9.3 Terapkan pemaksaan deployment yang disertai opsi pengawalan via area khusus tiket keluhan (Wave-based rollout)#

Bagi Microsoft disarankan guna mencoba tahapan penyesuaian pengerahan berdasarkan "ombak" dengan menanti siklusnya dari awal, amati tingkatan komplain dan angka pengaduannya (help desk ticket):

• Tingkatan tiket tinggi: Tunda proses penerapannya, adakan pembinaan sosialisasi bagi mereka
• Laporan keluhan makin sedikit: Angka aman buat menyiagakan penerapannya agar jalan ulang

Aturlah sedemikian juga terhadap penyusunan Entra ID via grup per tingkat ombak (gelombang per kelompoknya). Melakukan proses demi per tahap menihilkan timbunan pengerjaan khusus di kalangan staf pendukung (help desk).

10. Daftar Periksa untuk Percobaan Kunci Sandi Tersinkronisasi (Synced Passkey pilot checklist)#

Semisal arah sasaran yang hendak dicapai ialah menyajikan tatanan bebas tanpa campur tangannya aplikasi (dependency), patuhilah skema postur di perancangan pilot ini:

1. Jalankan tatanan pratinjau (Enable synced passkeys preview) Buka arahan langkah di Kunci sandi tersinkronisasi (pratinjau).

2. Pergunakanlah Passkey Profiles model pratinjau agar tersasar ke dalam tatanan proyek rintisan grup uji cobanya Susun dan distribusikan tatanan profil terkait supaya tatanannya mengizinkan tersedianya passkey tipe sinkronisasi (synced) yang rincian arahannya terpublikasikan pada laman petunjuk: Passkey Profiles.

3. Pastikan untuk saat pengujian meniadakan model kewajiban sandi perangkat (do not enforce attestation) Keharusan sistem menggunakan pemaksaan pada tahapan attestation itu secara logis menyisihkan keberadaan kunci sinkronisasinya sesuai paparan tentang bahasan spesifik yang terdapat di dokumentasi: Dokumentasi konsep Passkeys (FIDO2).

4. Jangan bersikap amat kaku bagi parameter AAGUID sedari permulaan (Avoid strict AAGUID allow-lists initially) Gunakan posisi melonggarkan daftarnya dulu untuk menginspeksi jalurnya, perlahan baru ketatkan bilamana sudah mendapatkan kejelasan terhadap provider (pemasok/penyedia kunci) yang semestinya dikelola atau dilegalkan, yakni Mengaktifkan passkey (FIDO2).

5. Kaji kembali kewajiban pada Kebijakan Bersyarat untuk Menihilkan Ketergantungan Authenticator (Confirm Conditional Access doesn't force Microsoft Authenticator) Upayakan melihat apakah bagian peranti kekuatan (auth strengths) maupun setelan CA itu sudah mengakomodir rancang passkey profile tadi sebagaimana peruntukannya semula. (Sebab jikalau tatanannya itu abai pada tahap prasyarat yang ini, hasilnya malah terlihat kelewat serupa akan tatanan berbasis dependency via Authenticator).

6. Konfirmasi kesahihan tipe profil identitas bagi pengelompokan akun khusus di dalamnya (Validate the identity model (member vs guest)) Coba inspeksi bilamana sasaran pengujian menyentuh kategori status tamu yang perlakuan sokongan pada wewenang (tenant model) ini sudah sepantasnya diproyeksikan, ketimbang memboroskan tenaga untuk merombak parameter profiles.

11. Kesimpulan#

Mengerahkan skenario pengerahan kunci identitas perusahaan memang terbilang terjal serta bertalian erat satu sama lain secara prosedural-operasionalnya, namun jalan di bagian depannya sepertinya sungguh cukup gamblang terpapar. Adapun penjelasan dari sederet teka-teki, sejurus pertanyaan pokok tentang keraguan dari tataran teknis di atas ialah:

1. Terikat peranti fisik kontra Tersinkronisasi silang perangkat (Device-bound vs synced passkeys): Penggunaan tipe terikat (sebutlah produk autentikator raksasa IT, Hello untuk Windows, atau berupa cip pintar) ini tidak bisa dipindahkan menuju peranti liyan hingga ia disahkan menduduki jaminan tinggi ke kasta AAL3. Yang tipe sinkronisasi layaknya iCloud Keychain kepunyaan raksasa Apple, Google Password Manager dapat berdikari (mandiri lintas piranti) menyabet tingkatan spesifikasi tatanan sandi tingkat kedua. Para pelaku komersial lazim membutuhkan dua racikan terpisah tadi, peranti fisik diserahkan para pelindung administratornya. Sedangkan staf pekerja lazim ditugasi mengadopsi (kategori AAL2) kunci lintas peranti / perangkat.

2. Langkah menjejalkan kredensial untuk tenaga awal mula (Bootstrapping new employees): Praktik pengaplikasian jenis parameter Temporary Access Pass (TAP) dipandang jitu menyelesaikan teka-teki ayam dan si telor pendaftaran. Apabila berhadapan ke arah model pengerahan organisasi bermassa kolosal, otomatisasi bisa diracik ulang lewat saluran (Graph API). Jika kebutuhannya tingkat pengamanan berlapisan kuat, pastikan disuntik perisai pemindaian berbasis Wajah (Entra Verified ID dan Face Check).

3. Problem pasca lenyapnya perangkat handphone dan proses perbaikannya: Sajikan pilihan dari bermacam langkah yang disediakan misal memakai mesin pelayanan sendiri yang diakses (laptop). Ada (Manager-Assisted TAP) di antarmuka tab My Staff atau ada juga layanan biro mandiri perbaikan dari Verified ID, SSAR buat perpaduannya.

4. Biang kerok setelan kesalahan teknis (Configuration mistakes): Perkara umum di seputar kekacauan attestation memakan persentase kealpaan secara massal, atau bisa dari mengabaikan langkah kunci pratinjau dalam tahapan sinkronisasinya (AAGUID yang ditekan terlalu sempit) dengan skema dari Conditional Access (CA) sampai bermuara pada suatu permasalahan putaran / lingkaran tanpa batas masalah tak terselesaikan (circular dependencies).

5. Kalangan Pengunjung Eksternal perusahaan (B2B guests): Tak dianjurkan bagi sebuah instansi mencatat para tamunya ke registrasi dari passkey. Gantilah perizinan Cross-Tenant Access Trust supaya penyedia akun dari perusahan pihak pertama bisa diintegrasikan ke tempat tujuan Anda.

6. Kunci dari elemen (Security Hardware) fisikal lawan versus model mobile kredensial handphone: Benda-benda fisis diperuntukkan buat tenaga yang meresap wewenang tinggi dari jabatannya di administrasi teknis namun menghimpun pekerjaan berat untuk menata pasokannya jika ditatap lewat sudut ruang dimensi berskala besar. Kunci tipe lunak dalam sarang telepon akan lebih leluasa.

7. Piranti dari macOS dibaurkan beserta platform si jendela (Windows): Kerahkan saja sistem penyatu sandinya (Platform SSO) di ranah MDM maupun JAMF guna merangkul kedua instrumen itu dalam melaju di tatanan yang satu irama alur workflow-nya.

8. Siaga dari aspek proaktif (Proactive measures): Adanya kelebihan untuk menyelisik eksistensi sebuah piranti niraktif sembari meneruskan peringatan bagi pemakainya supaya merampungkannya secepat mungkin dari peranti penunjang / Intune biar mengelak pemblokiran. Lakukan langkah awal wajib dengan mensyaratkan pencatatan di dalam perangkat yang terakses Intune untuk percepatan adaptasinya demi menghapus pemakaian kata keramat call-helpdesk.

Infrastruktur dan mesin IT sesungguhnya selalu bersiaga melancarkan fungsinya. Inti pertentangannya mengarah dan merujuk di operasional dan langkah perbaikan atas musibah. Manakala tataran prasarana dipoles solid, pemusatan penajaman ke titik implementasi kunci sandi login memegang kunci utama kelancaran transisi sebagai fondasi kokoh untuk kredensial autentikasi.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

Pertanyaan yang Sering Diajukan (FAQ)#

Mengapa mengaktifkan MFA tahan phising di Conditional Access mengunci semua pengguna saya?#

Membuat kebijakan Conditional Access yang mewajibkan MFA tahan phising untuk semua aplikasi cloud akan segera memblokir pengguna yang belum mendaftarkan kunci sandi, termasuk memblokir akses ke halaman pendaftaran Security Info itu sendiri. Ketergantungan melingkar ini, yang disebut paradoks 'Register Security Info', berarti Anda harus menerbitkan Temporary Access Pass kepada pengguna yang terkena dampak sebelum mengaktifkan penegakan kebijakan, sehingga mereka dapat menyelesaikan pendaftaran awal.

Bagaimana cara menangani pengguna tamu B2B ketika tenant saya mewajibkan MFA tahan phising?#

Entra ID tidak mendukung pengguna tamu untuk mendaftarkan kunci FIDO2 di tenant sumber daya (resource tenant), sehingga upaya untuk memaksakan pendaftaran kunci sandi bagi tamu akan gagal. Solusi yang benar adalah mengonfigurasi Cross-Tenant Access Settings di bawah External Identities untuk memercayai klaim MFA dari tenant asal tamu, yang berarti penggunaan YubiKey di organisasi mereka sendiri sudah memenuhi persyaratan MFA tahan phising Anda tanpa perlu pendaftaran di tenant Anda.

Apa yang menyebabkan autentikasi kode QR lintas perangkat gagal diam-diam saat masuk dengan kunci sandi?#

Autentikasi Lintas Perangkat (Cross-Device Authentication) memerlukan Bluetooth yang aktif di PC maupun ponsel untuk menyelesaikan jabat tangan kedekatan BLE (Bluetooth Low Energy), sehingga kebijakan perusahaan apa pun yang menonaktifkan Bluetooth akan memutus alur ini sepenuhnya. Alur ini juga menggunakan koneksi WebSocket ke cable.auth.com, yang sering kali diblokir oleh firewall atau konfigurasi Zscaler, sehingga pemindaian kode QR menggantung atau gagal tanpa pesan kesalahan yang jelas.

Bagaimana cara memantau karyawan mana yang sudah siap untuk penegakan MFA tahan phising sebelum saya mengaktifkannya?#

Phishing-Resistant Passwordless Workbook dari Microsoft, yang dapat diakses melalui pusat admin Entra di bawah Monitoring > Workbooks, menyediakan tampilan Enrollment Readiness yang menunjukkan pasangan pengguna/perangkat mana yang dapat mendaftar berdasarkan platform dan jenis kredensial. Untuk kesiapan penegakan, buat kebijakan Conditional Access dengan mode 'report-only' (hanya laporan) yang mewajibkan MFA tahan phising sehingga log masuk akan mengungkap pengguna mana yang akan diblokir sebelum Anda mengaktifkan penegakan secara langsung.

Apa strategi pemulihan terbaik bagi karyawan yang mendapatkan ponsel baru dan kehilangan akses ke kunci sandi mereka?#

Pendekatan yang disarankan dilakukan secara berlapis: Kios Pemulihan Mandiri (Self-Service Recovery Kiosk) yang menggunakan laptop yang diamankan dengan WHfB akan membuat Temporary Access Pass melalui Graph API dan mencakup sebagian besar kasus tanpa keterlibatan helpdesk. Bagi pengguna tanpa laptop, Manager-Assisted TAP melalui portal My Staff mendelegasikan pemulihan ke manajer langsung, dan Self-Service Account Recovery dengan Entra Verified ID biometrik Face Check menangani kasus tepi (edge cases) yang memerlukan verifikasi ulang identitas secara penuh.

Bacaan lebih lanjut#

Untuk mendalami secara detail penerapan FIDO2/kunci sandi perusahaan, ikuti ahli seperti Merill Fernando dan Jan Bakker yang rutin mempublikasikan panduan praktis tentang autentikasi Microsoft Entra.