--- url: 'https://www.corbado.com/id/blog/tantangan-deployment-kunci-sandi-perusahaan' title: 'Tantangan & Solusi Deployment Kunci Sandi Perusahaan' description: 'Terapkan kunci sandi (passkey) di Microsoft Entra ID dalam skala besar. Mencakup tantangan pendaftaran, kunci tersinkronisasi vs terikat perangkat, dan strategi pemulihan.' lang: 'id' author: 'Vincent Delitz' date: '2026-05-22T13:43:56.588Z' lastModified: '2026-05-22T13:45:33.476Z' keywords: 'kunci sandi tersinkronisasi entra, fido2 pekerja, temporary access pass, passkeys' category: 'Passkeys Strategy' --- # Tantangan & Solusi Deployment Kunci Sandi Perusahaan ## Key Facts - Suplemen 1 **NIST SP 800-63B** memvalidasi bahwa kunci sandi tersinkronisasi memenuhi persyaratan AAL2, sehingga cukup tahan phising untuk penggunaan umum tenaga kerja tanpa memerlukan kunci perangkat keras. - **Temporary Access Pass (TAP)** menyelesaikan paradoks *bootstrapping*: kode sandi berbatas waktu memungkinkan karyawan baru untuk mendaftarkan kunci sandi tanpa pernah mengatur kata sandi. - Memaksakan **attestation** di Microsoft Entra ID memblokir semua kunci sandi tersinkronisasi. Gunakan Profil Kunci Sandi untuk menerapkannya secara selektif: diwajibkan untuk admin, dinonaktifkan untuk staf umum. - Model jaminan **tersegmentasi** sangat penting: kunci perangkat keras memenuhi AAL3 untuk admin dan peran dengan hak istimewa, sementara kunci sandi tersinkronisasi memberikan AAL2 bagi pekerja secara lebih luas. ## 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-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](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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys). Untuk mengaktifkan dan mengontrol kunci sandi tersinkronisasi, Entra menggunakan [Profil Kunci Sandi (pratinjau)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles). **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: | Penyedia kunci sandi | Windows | macOS | iOS | Android | | --------------------------------------------------- | --------------------------- | ---------------------------- | --------------------------- | --------------------------------------------------------- | | Apple Passwords (iCloud Keychain) | N/A | Bawaan (Native). macOS 13+ | Bawaan (Native). iOS 16+ | N/A | | Google Password Manager | Bawaan Chrome | Bawaan Chrome | Bawaan Chrome. iOS 17+ | Bawaan (kecuali perangkat Samsung). Android 9+ | | Penyedia lainnya (mis. 1Password, Bitwarden) | Periksa ekstensi peramban | Periksa ekstensi peramban | Periksa aplikasi. iOS 17+ | Periksa aplikasi. Android 14+ | 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: ![pengaturan akun kunci sandi](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_account_settings_946c956180.png) ### 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: | Platform | Versi Minimum | Catatan | | -------- | ------------------------------------------------- | --------------------------------------------------------------- | | Windows | 10 22H2 (untuk WHfB), 11 22H2 (UX kunci sandi terbaik) | Versi lama mungkin memerlukan kunci keamanan FIDO2 | | macOS | 13 Ventura | Diperlukan untuk Platform SSO Secure Enclave Key | | iOS | 17 | Diperlukan sinkronisasi kunci sandi dan alur lintas perangkat | | Android | 14 | Diperlukan kunci sandi tersinkronisasi; versi lama memerlukan kunci keamanan | 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](https://www.corbado.com/passkey-benchmark-2026/webauthn-client-capabilities), 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): | Persona Pengguna | Rekomendasi | Alternatif | | --------------------------------- | ------------------- | ------------------------------------------------------ | | Admin dan pengguna teregulasi ketat | Kunci keamanan FIDO2 | Kunci sandi di Microsoft Authenticator, Smart Card | | Tenaga kerja non-admin | Kunci sandi tersinkronisasi | Kunci keamanan FIDO2, Kunci sandi di Microsoft Authenticator | **Kredensial lokal** (khusus perangkat): | Persona Pengguna | Windows | macOS | iOS | Android | | ------------ | ----------- | -------------------------------------- | ------------------------------- | ------------------------------- | | Admin | WHfB atau CBA | Platform SSO Secure Enclave Key atau CBA | Kunci sandi di Authenticator atau CBA | Kunci sandi di Authenticator atau CBA | | Non-admin | WHfB | Platform SSO Secure Enclave Key | Kunci sandi tersinkronisasi | Kunci sandi tersinkronisasi | 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](https://www.threatscape.com/cyber-security-blog/common-entra-id-mfa-mistakes-you-might-be-making/) 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys): - _Profil A (Admin):_ Enforce Attestation = **Yes** - _Profil B (Staf Umum):_ Enforce Attestation = **No** ### 4.3 Profil Kunci Sandi dijelaskan Anggaplah [Profil Kunci Sandi](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles) 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: ![pengaturan fido2 kunci sandi profil terpilih](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_selected_profiles_8fad7bfc7a.png) Saat mengedit profil kunci sandi, Anda bisa mengonfigurasi penegakan attestation, tipe target (terikat perangkat, tersinkronisasi, atau keduanya), serta batasan spesifik AAGUID: ![pengaturan fido2 kunci sandi](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_800cee0438.png) ### 4.4 Kekuatan Conditional Access & autentikasi Penegakan dapat ditangani lewat kebijakan Conditional Access (CA) dengan memanfaatkan [Kekuatan Autentikasi (Authentication Strengths)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration), 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: | Kombinasi metode autentikasi | Kekuatan MFA | Kekuatan MFA Tanpa Kata Sandi | Kekuatan MFA Tahan Phising | | ----------------------------------------------------- | :----------: | :-----------------------: | :-----------------------------: | | Kunci keamanan FIDO2 | ✅ | ✅ | ✅ | | Windows Hello for Business atau kredensial platform | ✅ | ✅ | ✅ | | Certificate-based authentication (multifaktor) | ✅ | ✅ | ✅ | | Microsoft Authenticator (masuk dari ponsel) | ✅ | ✅ | | | Temporary Access Pass (satu kali dan beberapa kali) | ✅ | | | | Kata sandi ditambah sesuatu yang dimiliki pengguna | ✅ | | | | Federated single-factor plus sesuatu yang dimiliki pengguna | ✅ | | | | Federated multifactor | ✅ | | | | Certificate-based authentication (faktor tunggal) | | | | | Masuk lewat SMS | | | | | Kata sandi | | | | | Federated single-factor | | | | ### 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](https://www.token2.com/site/page/default-mfa-method-for-microsoft-entra-id-users). 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: ![1password passkey entra](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/1password_passkey_entra_e261b05849.png) ### 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys) - Konfigurasi profil menggunakan [Profil Kunci Sandi](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles) 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass) 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](https://janbakker.tech/how-to-create-a-temporary-access-pass-using-logic-apps/). - **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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication) 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](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck) 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 Face Check Microsoft Entra Verified ID yang menunjukkan tahapan Verify, Confirm, dan Review](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/face_check_b5a23174b0.png) 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 | Skenario | Pengguna punya ponsel lama | Pengguna punya laptop tepercaya | Solusi | | --------------- | ------------------ | ----------------------- | ----------------------------------------------------------------------------------------------------------- | | **Skenario Terbaik** | Ya | Ya | Pandu pengguna menambah kunci sandi baru sewaktu ponsel lama masih jalan. Beralih ke "alur ideal." | | **Skenario Umum** | Tidak | Ya | **Laptop sebagai bootstrap:** Gunakan sesi WHfB terautentikasi untuk mendaftar kunci sandi di ponsel baru (Kios Mandiri). | | **Skenario Terburuk** | Tidak | Tidak | Bantuan helpdesk atau SSAR dengan verifikasi identitas tak bisa dihindari. | 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](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-windows). - **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](https://www.corbado.com/passkeys-for-energy) (BLE) untuk membuktikan posisi kedekatannya. Baca rincian terkait [kunci sandi terikat-perangkat dalam Microsoft Authenticator](https://janbakker.tech/things-you-should-know-before-rolling-out-device-bound-passkeys-in-microsoft-authenticator-app/) 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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey). ### 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](https://learn.microsoft.com/en-us/answers/questions/1192906/cannot-register-fido2-key-for-guest-users-on-resou) 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-account-recovery-overview) milik Microsoft Entra ID (sedang dalam Pratinjau / Preview) menunjang proses pemulihan mutu tinggi tak harus merepotkan layanan helpdesk. ![Alur Pemulihan Akun menggunakan Microsoft Entra Verified ID memperlihatkan proses 4 tahapan](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/account_recovery_microsoft_entry_recovery_8c9f369047.png) 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)](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck). 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) | **Notifikasi galat / peringatan eror (symptom)** | **Akar dari penyebabnya (Root cause)** | **Pendekatan remedi / Remediation strategy** | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **"Passkey not registered"** (Windows Desktop) | Adanya paksaan terhadap "Attestation," walaupun pengguna telah memasukkan peranti bukan wujud fisik (e.g. Google Password Manager, iCloud Keychain, 1Password). | Pakai fitur di sisi **Passkey Profiles** buat mendisfungsikan fasilitas opsi peranti (non-aktif di area) "Enforce Attestation" teruntuk user standarnya. | | **"Passkey not registered"** (Mobile App) | AAGUID spesifik untuk pendaftaran di akun otentikasi selulernya Microsoft Authenticator berbasis perangkat seluler baik untuk HP dengan program OS, yakni iOS (sistem operasi ponsel pintar buatan produsen peranti berlambang merek tipe apel gigit) / HP (ponsel pintar berprogram si robot / android) belum disetting secara whitelist di peranti. | Perkenankan (tambahan opsi parameter berupa ID / angka spesifik / alias identitas pengenalnya): Pada area HP berbasis Android: `de1e552d-db1d-4423-a619-566b625cdc84` pada iOS HP bersimbol apel gigt: `90a3ccdf-635c-4729-a248-9b709135078f`. | | **Pilihan / Menu Akses untuk Mendaftarkan Berwujud Abu-Abu / (Greyed Out Options) Tersebab Terjadinya Lingkaran Umpan Berbalik (Loop)** | Individu belum teregistrasi dalam fitur sandi MFA dan CA yang membutuhkan Phishing-Resistant MFA untuk mengakses "Register Security Info". | **Macet di Sesi Bootstrapping.** Pilihlah dan terbitkan jalan darurat sandi bebas / **Temporary Access Pass (TAP)** sehingga bisa melenggang melewati sesi keamanan tersebut di login terawal / MFA check for the initial session. | | **Pemindaian Kode Batang Model Pindaian Gambar 2D Fails / Bermasalah macet berputar terus / Spins** | Opsi bluetooth terpantau non-aktif terhadap suatu perangkat (mesin ponsel maupun komputer), ataupun karena tembok pertahanan firewall secara sepihak memblokir sesi alamat server berupa websocket milik otentikator relay server (`cable.auth.com`). | Aktifkan kembali ketersediaan transmisi bluetooth (proximity check) ini, sesudah itu pastikan relay FIDO / alamat sandi WebAuthn domain terkait terdaftar di whitelist. | | **Tamu Gagal Masuk Ke Akses** | Pihak server asal Entra ID melakukan aksi bloking ke tamu tak tak diundang bagi pemakainya. | **Tinggalkan sajalah masalahnya.** Cobalah Anda menghidupkan tatanan penerimaan (Tamu asing), yakni: **Cross-Tenant Access Trust** guna membuat valid pemegang MFA asing tadi. | ## 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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication) yang diakses khusus pemakaian platform bagi Azure Monitor secara langsung dan tepat dari area tab khusus bernama admin pusat di bagian **Monitoring > Workbooks**: ![Pilihan Microsoft Entra workbooks yang menampilkan pilihan Phishing-Resistant Passwordless Deployment](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/phishing_resistant_passwordless_workbook_6b06c63518.png) 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): ![Enrollment Readiness Phase menampilkan statistik detail berdasarkan tingkat pemisahan platform pengguna perantinya User/Device Pairs Ready vs Not Ready](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/enrollment_phase_165ed80a39.png) 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. ![Enforcement Readiness Phase showing policy satisfaction breakdown with Further Data Analysis](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/detail_analysis_workbook_1c0931ee47.png) 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys). 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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-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)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-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. ## 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](https://au.linkedin.com/in/merill)** dan **[Jan Bakker](https://www.linkedin.com/in/jan-bakker/)** yang rutin mempublikasikan panduan praktis tentang autentikasi Microsoft Entra.