Rencanakan solusi verifikasi Microsoft Entra ID Terverifikasi Anda

Layanan MICROSOFT Entra Verified ID (Microsoft Entra VC) Microsoft memungkinkan Anda mempercayai bukti identitas pengguna tanpa memperluas batas kepercayaan Anda. Dengan Microsoft Entra VC, Anda membuat akun atau bergabung dengan penyedia identitas lain. Ketika solusi menerapkan pertukaran verifikasi menggunakan kredensial yang dapat diverifikasi, solusi ini memungkinkan aplikasi untuk meminta kredensial yang tidak terikat ke domain tertentu. Pendekatan ini memudahkan untuk meminta dan memverifikasi kredensial dalam skala besar.

Jika Anda belum melakukannya, kami sarankan Anda meninjau gambaran umum arsitektur ID Terverifikasi Microsoft Entra. Anda juga ingin meninjau Merencanakan solusi penerbitan ID Terverifikasi Microsoft Entra Anda.

Cakupan panduan

Konten ini mencakup aspek teknis perencanaan untuk solusi verifikasi kredensial yang dapat diverifikasi menggunakan produk dan layanan Microsoft. Solusi ini berinteraksi dengan sistem kepercayaan, saat ini mendukung DID Web. DID Web adalah infrastruktur kunci publik terpusat.

Teknologi pendukung yang tidak spesifik untuk solusi verifikasi berada di luar cakupan. Misalnya, situs web digunakan dalam solusi verifikasi kredensial yang dapat diverifikasi tetapi merencanakan penyebaran situs web tidak tercakup secara rinci.

Saat Merencanakan solusi verifikasi, Anda harus mempertimbangkan kemampuan bisnis apa yang ditambahkan atau dimodifikasi. Anda juga harus mempertimbangkan kemampuan TI apa yang dapat digunakan kembali, dan kemampuan apa yang harus ditambahkan untuk membuat solusi. Pertimbangkan juga pelatihan apa yang diperlukan untuk orang-orang yang terlibat dalam proses bisnis dan orang-orang yang mendukung pengguna akhir dan staf solusi. Artikel ini tidak tercakup dalam konten ini. Sebaiknya tinjau Microsoft Azure Well-Architected Framework untuk informasi yang mencakup artikel ini.

Komponen solusi

Sebagai bagian dari rencana Anda untuk solusi verifikasi, Anda harus mengaktifkan interaksi antara pemverifikasi, subjek, dan penerbit. Dalam artikel ini, istilah pihak yang mengandalkan dan pemverifikasi digunakan secara bergantian. Diagram berikut menunjukkan komponen arsitektur verifikasi Anda.

Layanan Microsoft Entra Verified ID

Dalam konteks solusi pemverifikasi, layanan ID Terverifikasi Microsoft Entra adalah antarmuka antara komponen Solusi Microsoft dan sistem kepercayaan. Layanan ini menyediakan kunci yang diatur ke Key Vault, menyediakan pengidentifikasi terdesentralisasi (DID).

Penyewa Microsoft Entra

Layanan ini memerlukan penyewa Microsoft Entra yang menyediakan sarana kontrol Manajemen Identitas dan Akses (IAM) untuk sumber daya Azure yang merupakan bagian dari solusi. Setiap penyewa Microsoft Entra menggunakan layanan ID Terverifikasi Microsoft Entra multipenyewa, dan mengeluarkan satu dokumen DID yang mewakili pemverifikasi. Jika Anda memiliki beberapa pihak yang mengandalkan menggunakan layanan verifikasi Anda, semuanya menggunakan DID pemverifikasi yang sama. DID pemverifikasi menyediakan penunjuk ke kunci publik yang memungkinkan subjek dan penerbit memvalidasi pesan yang berasal dari pihak yang mengandalkan.

Azure Key Vault

Layanan Azure Key Vault menyimpan kunci pemverifikasi Anda, yang dihasilkan saat Anda mengaktifkan layanan penerbitan ID Terverifikasi Microsoft Entra. Kunci digunakan untuk memberikan keamanan pesan. Setiap pemverifikasi memiliki satu set kunci yang digunakan untuk menandatangani, memperbarui, dan memulihkan VC. ID terverifikasi menggunakan set kunci ini setiap kali Anda melayani permintaan verifikasi. Set kunci Microsoft saat ini menggunakan Kriptografi Kurva Elips (ECC) SECP256k1. Kami sedang menjelajahi skema tanda tangan kriptografi lainnya yang diadopsi oleh komunitas DID yang lebih luas.

Api Layanan Permintaan

Antarmuka pemrograman aplikasi (API) memberi pengembang metode untuk mengabstraksi interaksi antar komponen solusi untuk menjalankan operasi verifikasi.

Sistem Kepercayaan

ID Terverifikasi Microsoft Entra saat ini mendukung DID Web sebagai sistem kepercayaan, di mana dokumen DID dihosting di server web penerbit.

Aplikasi Microsoft Authenticator

Microsoft Authenticator adalah aplikasi seluler. Authenticator mengatur interaksi antara pengguna, layanan Microsoft Entra VC, dan kontrak yang digunakan untuk mengeluarkan VC. Ini bertindak sebagai dompet digital di mana pemegang VC menyimpan VC, termasuk kunci pribadi subjek VC. Authenticator juga merupakan mekanisme yang digunakan untuk menyajikan VC untuk verifikasi.

Pihak yang mengandalkan (RP)

Antarmuka depan web

Front end web pihak yang mengandalkan menggunakan API Layanan Permintaan untuk memverifikasi VC dengan menghasilkan tautan mendalam atau kode QR yang digunakan dompet subjek. Tergantung pada skenarionya, ujung depan dapat menjadi situs web yang dapat diakses publik atau internal untuk mengaktifkan pengalaman pengguna akhir yang memerlukan verifikasi. Namun, titik akhir yang diakses dompet harus dapat diakses publik. Secara khusus, ini mengontrol pengalihan ke dompet dengan parameter permintaan tertentu.

Logika bisnis

Anda dapat membuat logika baru atau menggunakan logika yang ada yang khusus untuk pihak yang mengandalkan dan meningkatkan logika tersebut dengan presentasi VC.

Desain khusus skenario

Berikut ini adalah contoh desain untuk memenuhi kasus penggunaan tertentu. Pertama adalah untuk proses orientasi akun, digunakan untuk mengurangi waktu, biaya, dan risiko yang terkait dengan orientasi karyawan baru. Yang kedua adalah untuk pemulihan akun, yang memungkinkan pengguna akhir memulihkan atau membuka kunci akun mereka menggunakan mekanisme layanan mandiri. Yang ketiga adalah untuk mengakses aplikasi dan sumber daya bernilai tinggi, khususnya untuk kasus penggunaan bisnis-ke-bisnis di mana akses diberikan kepada orang-orang yang bekerja untuk perusahaan lain.

Pengenalan akun

Kredensial terverifikasi dapat digunakan untuk memungkinkan proses orientasi yang lebih cepat dengan mengganti beberapa interaksi manusia. VC dapat digunakan untuk onboarding karyawan, siswa, warga negara, atau orang lain untuk mengakses layanan. Misalnya, daripada karyawan yang perlu pergi ke kantor pusat untuk mengaktifkan lencana karyawan, mereka dapat menggunakan VC untuk memverifikasi identitas mereka untuk mengaktifkan lencana yang dikirimkan kepada mereka dari jarak jauh. Ketimbang seorang warga negara yang menerima kode yang harus ditukar untuk mengakses layanan pemerintah, mereka dapat menggunakan VC untuk membuktikan identitas mereka dan mendapatkan akses.

Elemen lain

Portal orientasi akun: Sebuah front end web yang mengatur panggilan API Layanan Permintaan untuk presentasi dan validasi VC, serta logika untuk orientasi akun.

Logika / alur kerja kustom: Logika tertentu dengan langkah-langkah khusus organisasi sebelum dan sesudah memperbarui akun pengguna. Contohnya mungkin termasuk alur kerja persetujuan, validasi lain, pengelogan, pemberitahuan, dan sebagainya.

Sistem identitas target: Repositori identitas khusus organisasi yang perlu berinteraksi dengan portal orientasi saat memasukkan subjek. Sistem yang akan diintegrasikan ditentukan berdasarkan jenis identitas yang ingin Anda onboarding dengan validasi VC. Skenario umum verifikasi identitas untuk pendaftaran meliputi:

• Identitas Eksternal yang diintegrasikan oleh Microsoft Entra ID menggunakan API untuk mengeluarkan undangan business-to-business (B2B), atau penetapan pengelolaan hak akses ke paket.

• Identitas karyawan, yang dalam sistem identitas terpusat sudah di-onboard melalui sistem sumber daya manusia (SDM). Dalam hal ini, verifikasi identitas mungkin diintegrasikan sebagai bagian dari tahap alur kerja SDM yang ada.

Pertimbangan Desain

• Penerbit: Onboarding akun cocok untuk layanan pemeriksaan identitas eksternal sebagai penerbit kredensial terverifikasi (VC). Contoh pemeriksaan untuk onboarding meliputi: pemeriksaan keaktifan, validasi dokumen yang dikeluarkan oleh pemerintah, konfirmasi alamat, atau konfirmasi nomor telepon, dan sebagainya.

• Menyimpan Atribut VC: Jika memungkinkan, jangan menyimpan atribut dari VC di penyimpanan khusus aplikasi Anda. Berhati-hatilah dengan data pribadi. Jika alur tertentu dalam aplikasi Anda memerlukan informasi ini, pertimbangkan untuk meminta VC untuk mengambil klaim sesuai permintaan.

• Korelasi Atribut VC dengan sistem back-end: Saat menentukan atribut VC dengan penerbit, buat mekanisme untuk menghubungkan informasi dalam sistem back-end setelah pengguna menyajikan VC. Mekanisme ini biasanya menggunakan pengidentifikasi unik yang terikat waktu dalam konteks RP Anda dalam kombinasi dengan klaim yang Anda terima. Beberapa contoh:

  • Karyawan baru: Ketika alur kerja SDM mencapai titik di mana pemeriksaan identitas diperlukan, RP dapat menghasilkan tautan dengan pengidentifikasi unik yang terikat waktu. RP kemudian mengirimkannya ke alamat email kandidat pada sistem SDM. Pengidentifikasi unik ini harus cukup untuk menghubungkan informasi seperti firstName, lastName dari permintaan verifikasi VC ke catatan SDM atau data yang mendasar. Atribut dalam VC dapat digunakan untuk menyelesaikan atribut pengguna dalam sistem SDM, atau untuk memvalidasi akurasi atribut pengguna tentang karyawan.

  • Identitas eksternal - undangan: Saat pengguna eksternal diundang ke sistem target, RP dapat menghasilkan tautan dengan pengidentifikasi unik yang mewakili transaksi undangan. Tautan ini dapat dikirim ke alamat email pengguna eksternal. Pengidentifikasi unik ini harus cukup untuk menghubungkan permintaan verifikasi VC ke catatan undangan atau data yang mendasarinya dan melanjutkan proses provisi. Atribut dalam VC dapat digunakan untuk memvalidasi atau menyelesaikan atribut pengguna eksternal.

  • Identitas eksternal - layanan mandiri: Ketika identitas eksternal mendaftar ke sistem target melalui layanan mandiri (misalnya, aplikasi B2C) atribut dalam VC dapat digunakan untuk mengisi atribut awal akun pengguna. Atribut VC juga dapat digunakan untuk mengetahui apakah profil sudah ada.

• Interaksi dengan sistem identitas target: Komunikasi layanan ke layanan antara antarmuka depan web dan sistem identitas target Anda perlu diamankan sebagai sistem yang berhak istimewa tinggi, karena dapat membuat akun baru. Berikan front end web peran dengan hak istimewa sekecil mungkin. Beberapa contohnya meliputi:

  • Untuk membuat pengguna baru di Microsoft Entra ID, situs web RP dapat menggunakan prinsipal layanan yang diberikan cakupan User.ReadWrite.All MS Graph untuk membuat pengguna, dan cakupan UserAuthenticationMethod.ReadWrite.All untuk mengatur ulang metode autentikasi.

  • Untuk mengundang pengguna ke Microsoft Entra ID menggunakan kolaborasi B2B, situs web RP dapat menggunakan prinsipal layanan yang diberikan cakupan MS Graph dari User.Invite.All untuk membuat undangan.

  • Jika RP Anda berjalan di Azure, gunakan Identitas Terkelola untuk memanggil Microsoft Graph. Menggunakan identitas terkelola menghapus risiko mengelola kredensial perwakilan layanan dalam file kode atau konfigurasi. Untuk mempelajari selengkapnya tentang Identitas terkelola, buka Identitas terkelola untuk sumber daya Azure.

Mengakses aplikasi bernilai tinggi di dalam organisasi

Kredensial yang dapat diverifikasi dapat digunakan sebagai bukti lain untuk mengakses aplikasi sensitif di dalam organisasi. Misalnya, VC juga dapat digunakan untuk memberi karyawan akses ke aplikasi lini bisnis berdasarkan mencapai kriteria tertentu, seperti sertifikasi.

Elemen lain

Frontend web pihak pengandalan adalah antarmuka depan web aplikasi yang telah ditingkatkan melalui panggilan API Layanan Permintaan untuk penyajian dan validasi VC sesuai kebutuhan bisnis Anda.

Logika otorisasi akses pengguna adalah lapisan logika aplikasi yang mengotorisasi akses pengguna. Ditingkatkan untuk memanfaatkan atribut pengguna di dalam VC agar dapat membuat keputusan otorisasi.

Layanan backend dan dependensi lainnya: Mewakili logika aplikasi lainnya, yang biasanya tidak berubah oleh dimasukkannya pemeriksaan identitas melalui VC.

Pertimbangan Desain

• Tujuan: Tujuan skenario menentukan jenis kredensial dan pengeluar sertifikat apa yang diperlukan. Skenario umum meliputi:

  • Otorisasi: Dalam skenario ini, pengguna menyajikan VC untuk membuat keputusan otorisasi. VC yang dirancang untuk bukti penyelesaian pelatihan atau memegang sertifikasi tertentu, cocok untuk skenario ini. Atribut VC harus berisi informasi terperinci yang kondusif untuk keputusan otorisasi dan audit. Misalnya, VC digunakan untuk mensertifikasi individu dilatih dan dapat mengakses aplikasi keuangan sensitif. Logika aplikasi dapat memeriksa klaim departemen untuk otorisasi yang terperinci dan menggunakan ID karyawan untuk keperluan audit.

  • Konfirmasi verifikasi identitas: Dalam skenario ini, tujuannya adalah untuk mengonfirmasi bahwa orang yang sama yang awalnya melakukan onboarding memang yang mencoba mengakses aplikasi bernilai tinggi. Kredensial dari penerbit verifikasi identitas akan sangat sesuai. Logika aplikasi harus memvalidasi bahwa atribut dari VC selaras dengan pengguna yang masuk ke aplikasi.

• Periksa Pencabutan: Saat menggunakan VC untuk mengakses sumber daya sensitif, adalah umum untuk memeriksa status VC dengan penerbit asli dan menolak akses untuk VC yang dicabut. Saat bekerja dengan penerbit, pastikan bahwa pencabutan secara eksplisit dibahas sebagai bagian dari desain skenario Anda.

• Pengalaman Pengguna: Saat menggunakan VC untuk mengakses sumber daya sensitif, ada dua pola yang dapat Anda pertimbangkan.

  • Autentikasi bertingkat: pengguna memulai sesi dengan aplikasi menggunakan mekanisme autentikasi yang ada. Pengguna harus menyajikan VC untuk operasi bernilai tinggi tertentu dalam aplikasi seperti persetujuan alur kerja bisnis. Ini cocok untuk skenario di mana operasi bernilai tinggi seperti itu mudah diidentifikasi dan diperbarui dalam alur aplikasi.

  • Pembentukan sesi: Pengguna harus menyajikan VC sebagai bagian dari memulai sesi dengan aplikasi. Memperkenalkan modal ventura sangat cocok ketika keseluruhan aplikasi bernilai tinggi.

Mengakses aplikasi di luar batas organisasi

Kredensial yang dapat diverifikasi juga dapat digunakan oleh pihak yang mengandalkan yang ingin memberikan akses atau manfaat berdasarkan keanggotaan atau hubungan kerja dari organisasi yang berbeda. Misalnya, portal e-niaga dapat menawarkan manfaat seperti diskon kepada karyawan perusahaan tertentu, siswa dari lembaga tertentu, dll.

Sifat kredensial yang dapat diverifikasi yang terdesentralisasi memungkinkan skenario ini tanpa membangun hubungan federasi.

Elemen lain

Frontend web pihak terpercaya: Ini adalah frontend web aplikasi yang ditingkatkan melalui panggilan API Layanan Permintaan untuk penyajian dan validasi VC, berdasarkan kebutuhan bisnis Anda.

Logika otorisasi akses pengguna: Lapisan logika dalam aplikasi yang mengotorisasi akses pengguna dan ditingkatkan untuk menggunakan atribut pengguna di dalam VC untuk membuat keputusan otorisasi.

Layanan backend dan dependensi lainnya: Mewakili logika aplikasi lainnya, yang biasanya tidak berubah oleh dimasukkannya pemeriksaan identitas melalui VC.

Pertimbangan Desain

• Tujuan: Tujuan skenario menentukan jenis kredensial dan pengeluar sertifikat apa yang diperlukan. Skenario umum meliputi:

  • Autentikasi: Dalam skenario ini, pengguna harus memiliki VC untuk membuktikan pekerjaan atau hubungan mereka dengan organisasi tertentu. Dalam hal ini, RP harus dikonfigurasi untuk menerima VC yang dikeluarkan oleh organisasi target.

  • Otorisasi: Berdasarkan persyaratan aplikasi, aplikasi mungkin menggunakan atribut VC untuk keputusan dan audit otorisasi terperinci. Misalnya, jika situs web e-niaga menawarkan diskon kepada karyawan organisasi di lokasi tertentu, mereka dapat memvalidasi kelayakan diskon berdasarkan klaim negara/wilayah di VC (jika ada).

• Periksa Pencabutan: Saat menggunakan VC untuk mengakses sumber daya sensitif, adalah umum untuk memeriksa status VC dengan penerbit asli dan menolak akses untuk VC yang dicabut. Saat bekerja dengan penerbit, pastikan bahwa pencabutan secara eksplisit dibahas sebagai bagian dari desain skenario Anda.

• Pengalaman Pengguna: Pengguna dapat menyajikan VC sebagai bagian dari memulai sesi dengan aplikasi. Biasanya, aplikasi juga menyediakan metode alternatif untuk memulai sesi untuk mengakomodasi kasus di mana pengguna tidak memiliki VC.

Pemulihan akun

Kredensial yang dapat diverifikasi dapat digunakan sebagai pendekatan untuk pemulihan akun. Misalnya, ketika pengguna perlu memulihkan akun mereka, mereka mungkin mengakses situs web yang mengharuskan mereka menyajikan VC dan memulai reset kredensial Microsoft Entra dengan memanggil API MS Graph seperti yang ditunjukkan dalam diagram berikut.

Nota

Meskipun skenario yang kami jelaskan di bagian ini khusus untuk memulihkan akun Microsoft Entra, pendekatan ini juga dapat digunakan untuk memulihkan akun di sistem lain.

Elemen Lain

Portal akun: Front end web yang mengatur panggilan API untuk presentasi dan validasi VC. Orkestrasi ini dapat menyertakan panggilan Microsoft Graph untuk memulihkan akun di ID Microsoft Entra.

Logika atau alur kerja kustom: Logika dengan langkah-langkah khusus organisasi sebelum dan sesudah memperbarui akun pengguna. Logika kustom mungkin mencakup alur kerja persetujuan, validasi lain, pengelogan, pemberitahuan, dll.

Microsoft Graph: Mengekspos API transfer status representasional (REST) dan pustaka klien untuk mengakses data Microsoft Entra yang digunakan untuk melakukan pemulihan akun.

Direktori perusahaan Microsoft Entra: Penyewa layanan Microsoft Entra yang berisi akun yang sedang dibuat atau diperbarui melalui portal akun.

Pertimbangan desain

Korelasi Atribut VC dengan ID Microsoft Entra: Saat menentukan atribut VC yang bekerja sama dengan penerbit, pastikan Anda menyetujui klaim yang mengidentifikasi pengguna. Misalnya, jika penyedia verifikasi identitas (IDV) memverifikasi identitas sebelum onboarding karyawan, pastikan bahwa VC yang dikeluarkan menyertakan klaim yang dapat dicocokkan dengan sistem internal. Klaim tersebut mungkin berupa nomor telepon, alamat, atau tanggal lahir. RP dapat meminta informasi yang tidak ditemukan di VC sebagai bagian dari proses ini, seperti empat digit terakhir nomor jaminan sosial (SSN) mereka.

Peran VC dengan Kemampuan Reset Kredensial Microsoft Entra yang Ada: MICROSOFT Entra ID memiliki kemampuan pengaturan ulang kata sandi mandiri (SSPR) bawaan. Kredensial yang Dapat Diverifikasi dapat digunakan untuk menyediakan cara lain untuk memulihkan jika pengguna tidak memiliki akses ke atau kehilangan kontrol metode SSPR. Dalam skenario di mana pengguna telah kehilangan komputer dan ponsel, pengguna dapat mendapatkan kembali VC dari penerbit bukti identitas dan menyerahkannya untuk memulihkan kembali akun mereka dari jarak jauh.

Demikian pula, Anda dapat menggunakan VC untuk menghasilkan kode akses sementara yang memungkinkan pengguna untuk mengatur ulang metode autentikasi MFA mereka tanpa kata sandi.

Otorisasi: Buat mekanisme otorisasi seperti grup keamanan yang diperiksa RP sebelum melanjutkan pemulihan kredensial. Misalnya, hanya pengguna dalam grup tertentu yang mungkin memenuhi syarat untuk memulihkan akun dengan VC.

Interaksi dengan Microsoft Entra ID: Komunikasi layanan-ke-layanan antara antarmuka web dan Microsoft Entra ID harus diamankan sebagai sistem dengan hak istimewa tinggi karena dapat mengatur ulang data otentikasi karyawan. Berikan front end web peran dengan hak istimewa sekecil mungkin. Beberapa contohnya meliputi:

• Berikan situs web RP kemampuan untuk menggunakan perwakilan layanan yang diberikan cakupan UserAuthenticationMethod.ReadWrite.All MS Graph untuk mengatur ulang metode autentikasi. Jangan berikan User.ReadWrite.All, yang memungkinkan kemampuan untuk membuat dan menghapus pengguna.

• Jika RP Anda berjalan di Azure, gunakan Identitas Terkelola untuk memanggil Microsoft Graph. Identitas Terkelola menghilangkan risiko terkait pengelolaan kredensial prinsipal layanan dalam kode atau file konfigurasi. Untuk informasi selengkapnya, lihat Identitas terkelola untuk sumber daya Azure.

Merencanakan manajemen identitas

Berikut ini adalah pertimbangan IAM saat mengintegrasikan VC ke pihak yang bergantung. Pihak yang mengandalkan biasanya adalah aplikasi.

Otentikasi

• Subjek VC haruslah manusia.

• Seseorang memiliki VC di dalam dompetnya dan harus mempersembahkannya secara interaktif. Alur non-interaktif seperti alur bertindak atas nama tidak didukung.

Otorisasi

• Presentasi VC yang sukses dapat dianggap sebagai gerbang otorisasi kasar dengan sendirinya. Atribut VC juga dapat digunakan untuk penentuan otorisasi yang lebih rinci.

• Tentukan apakah VC yang kedaluwarsa memiliki arti dalam aplikasi Anda; jika demikian, periksa nilai exp klaim (waktu kedaluwarsa) VC sebagai bagian dari pemeriksaan otorisasi. Salah satu contoh di mana kedaluwarsa tidak relevan adalah mengharuskan dokumen yang dikeluarkan pemerintah seperti SIM untuk memvalidasi apakah subjek lebih dari 18. Klaim tanggal lahir tetap valid, bahkan jika VC kedaluwarsa.

• Tentukan apakah VC yang dicabut memiliki arti terhadap keputusan otorisasi Anda.

  • Jika tidak relevan, lewati panggilan untuk memeriksa API status (yang aktif secara default).

  • Jika relevan, tambahkan penanganan pengecualian yang tepat dalam aplikasi Anda.

Profil Pengguna

Anda dapat menggunakan informasi dalam VC yang disajikan untuk membangun profil pengguna. Jika Anda ingin menggunakan atribut untuk membangun profil, pertimbangkan item berikut.

• Ketika VC dikeluarkan, VC berisi gambaran atribut saat penerbitan. VC mungkin memiliki periode berlaku yang panjang, dan Anda perlu menentukan berapa usia atribut yang dianggap cukup baru untuk digunakan sebagai bagian dari profil.

• Jika VC perlu disajikan setiap kali subjek memulai sesi dengan RP, pertimbangkan untuk menggunakan output presentasi VC untuk membangun profil pengguna yang tidak persisten dengan atribut . Profil pengguna yang tidak persisten membantu mengurangi risiko privasi yang terkait dengan penyimpanan properti pengguna saat tidak aktif. Aplikasi Anda mungkin perlu menyimpan atribut subjek secara lokal. Jika demikian, hanya simpan klaim yang dibutuhkan aplikasi Anda. Jangan simpan seluruh VC.

• Jika aplikasi memerlukan penyimpanan profil pengguna persisten:

  • Pertimbangkan menggunakan klaim sub sebagai pengidentifikasi pengguna yang tidak dapat diubah. Ini adalah atribut unik buram yang konstan untuk pasangan subjek/RP tertentu.

  • Tentukan mekanisme untuk menghapus profil pengguna dari aplikasi. Karena sifat terdesentralisasi dari sistem ID Terverifikasi Microsoft Entra, tidak ada siklus hidup provisi pengguna aplikasi.

  • Jangan menyimpan klaim data pribadi yang dikembalikan dalam token VC.

  • Hanya simpan klaim yang diperlukan untuk logika pihak yang mengandalkan.

Rencanakan performa

Seperti halnya solusi apa pun, Anda harus merencanakan kinerja. Area fokus termasuk latensi, throughput, dan skalabilitas. Selama fase awal siklus rilis, performa seharusnya tidak menjadi perhatian. Namun, ketika adopsi solusi Anda menghasilkan banyak kredensial yang dapat diverifikasi dan sudah diverifikasi, perencanaan kinerja mungkin menjadi komponen penting dari solusi Anda.

Item berikut ini menyediakan area yang perlu dipertimbangkan saat merencanakan performa:

• Layanan penerbitan ID Terverifikasi Microsoft Entra disebarkan di wilayah Azure Eropa Barat, Eropa Utara, US Barat 2, dan US Tengah Barat. Untuk membatasi latensi, tempatkan front end verifikasi (situs web) dan penyimpanan kunci Anda di wilayah terdekat.

• Model berdasarkan throughput:

  • Kapasitas verifikasi VC tunduk pada batas layanan Azure Key Vault.

  • Setiap verifikasi VC memerlukan satu operasi tanda tangan Key Vault.

  • Anda tidak dapat mengontrol pembatasan; namun, kami sarankan Anda membaca panduan pembatasan Azure Key Vault sehingga Anda memahami bagaimana pembatasan dapat memengaruhi performa.

Rencana untuk keandalan

Untuk merencanakan ketersediaan tinggi dan pemulihan bencana, kami menyarankan item berikut:

• Layanan ID Terverifikasi Microsoft Entra disebarkan di wilayah Eropa Barat, Eropa Utara, US Barat 2, dan US Tengah Barat, Australia, dan Jepang Azure. Pertimbangkan untuk menyebarkan server web pendukung dan aplikasi pendukung di salah satu wilayah tersebut, khususnya di wilayah tempat Anda mengharapkan sebagian besar lalu lintas validasi Anda berasal.

• Tinjau dan gabungkan praktik terbaik dari ketersediaan dan redundansi Azure Key Vault saat Anda merancang untuk tujuan ketersediaan dan redundansi Anda.

Merencanakan keamanan

Saat Anda merancang untuk keamanan, pertimbangkan hal berikut:

• Semua pihak yang bergantung (RPs) dalam satu tenant memiliki batas kepercayaan yang sama karena mereka berbagi DID yang sama.

• Tentukan service principal khusus untuk situs web yang mengakses Key Vault.

• Hanya layanan ID Terverifikasi Microsoft Entra dan perwakilan layanan situs web yang harus memiliki izin untuk menggunakan Key Vault untuk menandatangani pesan dengan kunci privat.

• Jangan menetapkan izin administratif identitas manusia ke Key Vault. Untuk informasi selengkapnya tentang praktik terbaik Key Vault, lihat Garis Besar Keamanan Azure untuk Key Vault.

• Tinjau Mengamankan lingkungan Azure dengan ID Microsoft Entra untuk praktik terbaik dalam mengelola layanan pendukung untuk solusi Anda.

• Mengurangi risiko spoofing dengan:

  • Menerapkan verifikasi DNS untuk membantu pelanggan mengidentifikasi merek penerbit.

  • Gunakan domain yang bermakna bagi pengguna akhir.

• Mengurangi risiko penolakan layanan terdistribusi (DDOS) dan pembatasan sumber daya Key Vault. Setiap permintaan presentasi VC menghasilkan operasi penandatanganan Key Vault yang bertambah menuju batas layanan. Sebaiknya lindungi lalu lintas dengan menggabungkan autentikasi atau captcha alternatif sebelum menghasilkan permintaan penerbitan.

Merencanakan operasi

Saat Anda merencanakan operasi, kami sarankan Anda mencatat setiap upaya validasi kredensial sebagai bagian dari audit Anda. Gunakan informasi tersebut untuk audit dan pemecahan masalah. Selain itu, pertimbangkan untuk menghasilkan pengidentifikasi transaksi unik (ID) yang dapat dirujuk pelanggan dan teknisi dukungan jika diperlukan.

Sebagai bagian dari perencanaan operasional Anda, pertimbangkan untuk memantau hal-hal berikut:

• Untuk skalabilitas:

  • Memantau validasi VC yang gagal sebagai bagian dari metrik keamanan aplikasi end-to-end.

  • Pantau latensi end-to-end proses verifikasi identitas.

• Untuk keandalan dan dependensi:

  • Pantau dependensi yang mendasar yang digunakan oleh solusi verifikasi.

  • Ikuti pemantauan dan pemberitahuan Azure Key Vault.

• Untuk keamanan:

  • Aktifkan pengelogan untuk Key Vault untuk melacak operasi penandatanganan, dan untuk memantau dan memperingatkan perubahan konfigurasi. Lihat Cara mengaktifkan pengelogan Key Vault untuk informasi selengkapnya.

  • Arsipkan log dalam Security Information and Event Management (SIEM), seperti Microsoft Sentinel untuk penyimpanan jangka panjang.

Langkah selanjutnya

Pelajari selengkapnya tentang merancang solusi VC

• Gambaran umum ID Terverifikasi Microsoft Entra

• Merencanakan solusi penerbitan ID Terverifikasi Microsoft Entra Anda

Menerapkan Kredensial yang Dapat Diverifikasi

• Pengenalan Microsoft Entra Verified ID

• Mulai menggunakan Kredensial yang Dapat Diverifikasi

Tanya Jawab Umum