Microsoft Entra Doğrulanmış Kimlik doğrulama çözümünüzü planlama

Genel bakış

Microsoft'un Microsoft Entra Doğrulanmış Kimlik (Microsoft Entra VC) hizmeti, güven sınırınızı genişletmeden kullanıcı kimliği kanıtlarına güvenmenizi sağlar. Microsoft Entra VC ile hesaplar oluşturur veya başka bir kimlik sağlayıcısıyla federasyon oluşturursunuz. Bir çözüm doğrulanabilir kimlik bilgilerini kullanarak doğrulama değişimi uyguladığında, uygulamaların belirli bir etki alanına bağlı olmayan kimlik bilgileri istemesine olanak tanır. Bu yaklaşım, kimlik bilgilerini uygun ölçekte istemeyi ve doğrulamayı kolaylaştırır.

Henüz yapmadıysanız Microsoft Entra Doğrulanmış Kimlik mimarisine genel bakış'ı gözden geçirin. Ayrıca Microsoft Entra Doğrulanmış Kimlik Çözümünüzün Planlanması makalesini gözden geçirin.

Kılavuzun kapsamı

Bu içerik, Microsoft ürün ve hizmetlerini kullanarak doğrulanabilir bir kimlik bilgisi doğrulama çözümü planlamanın teknik yönlerini kapsar. Çözüm, şu anda DID Web'in desteklendiği bir güven sistemiyle arabirim yapar. DID Web merkezi bir ortak anahtar altyapısıdır.

Doğrulama çözümlerine özgü olmayan destekleyici teknolojiler kapsam dışındadır. Örneğin, web siteleri doğrulanabilir bir kimlik bilgisi doğrulama çözümünde kullanılır ancak web sitesi dağıtımının planlanması ayrıntılı olarak ele alınamaz.

Doğrulama çözümünüzü planlarken, hangi iş özelliğinin eklendiğini veya değiştirildiğini göz önünde bulundurmanız gerekir. Ayrıca, hangi BT özelliklerinin yeniden kullanılıp kullanılamayabileceğini ve çözümü oluşturmak için hangi özelliklerin eklenmesi gerektiğini de göz önünde bulundurmanız gerekir. Ayrıca, iş sürecine dahil olan kişiler ve çözümün son kullanıcılarını ve personelini destekleyen kişiler için hangi eğitimin gerektiğini göz önünde bulundurun. Bu konular bu içerikte ele alınmıyor. Daha fazla bilgi için Microsoft Azure Well-Architected Framework'lerini gözden geçirin.

Çözümün bileşenleri

Doğrulama çözümü planınızın bir parçası olarak, doğrulayıcı, konu ve veren arasındaki etkileşimleri etkinleştirmeniz gerekir. Bu makalede bağlı olan taraf ve doğrulayıcı terimleri birbirinin yerine kullanılır. Aşağıdaki diyagramda doğrulama mimarinizin bileşenleri gösterilmektedir.

Microsoft Entra Doğrulanmış Kimlik hizmeti

Bir doğrulayıcı çözümü bağlamında, Microsoft Entra Doğrulanmış Kimlik hizmeti çözümün Microsoft bileşenleri ile güven sistemi arasındaki arabirimdir. Hizmet, anahtar kümesini Key Vault'a yerleştirir ve merkezi olmayan tanımlayıcıyı (DID) temin eder.

Microsoft Entra kiracısı

Hizmet, çözümün parçası olan Azure kaynakları için kimlik ve erişim yönetimi (IAM) denetim düzlemi sağlayan bir Microsoft Entra kiracısı gerektirir. Her Microsoft Entra kiracısı çok kiracılı Microsoft Entra Doğrulanmış Kimlik hizmetini kullanır ve doğrulayıcıyı temsil eden tek bir DID belgesi verir. Doğrulama hizmetinizi kullanan birden çok bağlı olan taraf varsa, hepsi aynı doğrulayıcı DID'yi kullanır. Did doğrulayıcısı, öznelerin ve verenlerin bağlı olan taraftan gelen iletileri doğrulamasını sağlayan ortak anahtara yönelik işaretçiler sağlar.

Azure Key Vault

Azure Key Vault hizmeti, Microsoft Entra Doğrulanmış Kimlik verme hizmetini etkinleştirdiğinizde oluşturulan doğrulayıcı anahtarlarınızı depolar. Anahtarlar ileti güvenliği sağlamak için kullanılır. Her doğrulayıcı, sanal makineleri imzalamak, güncelleştirmek ve kurtarmak için kullanılan tek bir anahtar kümesine sahiptir. Doğrulanmış Kimlik, bir doğrulama isteğine her hizmet oluşturduğunuzda bu anahtar kümesini kullanır. Microsoft anahtar kümesi şu anda Elips Eğrisi Şifrelemesi (ECC) SECP256k1 kullanıyor. Daha geniş DID topluluğu tarafından benimsenen diğer şifreleme imzası şemaları da değerlendiriliyor.

İstek Hizmeti API'si

Uygulama programlama arabirimleri (API'ler), geliştiricilere doğrulama işlemlerini yürütmek için çözümün bileşenleri arasındaki etkileşimleri soyutlama yöntemi sağlar.

Güven sistemi

Microsoft Entra Verified ID şu anda DID belgesinin verenin web sunucusunda barındırıldığı bir güven sistemi olarak DID Web'i desteklemektedir.

Microsoft Authenticator uygulaması

Microsoft Authenticator mobil uygulamadır. Authenticator kullanıcı, Microsoft Entra VC hizmeti ve VM'leri vermek için kullanılan sözleşme arasındaki etkileşimleri düzenler. VC sahibinin, VC'nin konusunun özel anahtarı da dahil olmak üzere VC'yi depoladığı dijital bir cüzdan işlevi görür. Authenticator aynı zamanda doğrulama için doğrulanabilir kimlik bilgilerini sunmak amacıyla kullanılan mekanizmadır.

Bağlı olan taraf (RP)

Web ön yüzü

Bağlı taraf web ön ucu, konunun cüzdanında kullanılacak olan derin bağlantılar veya QR kodları oluşturarak Doğrulama Bilgilerini doğrulamak için İstek Hizmeti API'sini kullanır. Senaryoya bağlı olarak ön uç, doğrulama gerektiren son kullanıcı deneyimlerini etkinleştirmek için herkese açık veya iç bir web sitesi olabilir. Ancak, cüzdanın eriştiği uç noktaların herkese açık olması gerekir. Özellikle, belirli istek parametreleriyle cüzdana yeniden yönlendirmeyi denetler.

İş mantığı

Yeni bir mantık oluşturabilir veya güvenen tarafa özgü mevcut bir mantığı kullanabilir ve bu mantığı doğrulanabilir kimlik bilgilerinin sunumuyla geliştirebilirsiniz.

Senaryoya özgü tasarımlar

Aşağıda, belirli kullanım örneklerini karşılamaya ilişkin tasarım örnekleri verilmiştir. İlk olarak, yeni çalışanların işe alınmasıyla ilişkili süreyi, maliyeti ve riski azaltmak için kullanılan hesap açılışı içindir. İkincisi, bir son kullanıcının self servis mekanizması kullanarak hesabını kurtarmasını veya kilidini açmasını sağlayan hesap kurtarma içindir. Üçüncüsü, özellikle diğer şirketler için çalışan kişilere erişim verilen işletmeler arası kullanım örnekleri için yüksek değerli uygulamalara ve kaynaklara erişim içindir.

Hesap etkinleştirme

Doğrulanabilir kimlik bilgileri, bazı insan etkileşimleri değiştirilerek daha hızlı katılım sağlamak için kullanılabilir. V'ler, hizmetlere erişim sağlamak amacıyla çalışanları, öğrencileri, vatandaşları veya diğer kişileri işe almak için kullanılabilir. Örneğin, bir çalışanın rozetini etkinleştirmek için merkezi bir ofise gitmesi gereken bir çalışan yerine, uzaktan teslim edilen bir rozeti etkinleştirmek üzere kimliğini doğrulamak için bir VC kullanabilir. Kamu hizmetlerine erişmek için kullanması gereken bir kodu alan bir vatandaş yerine kimliğini kanıtlamak ve erişim kazanmak için bir VC kullanabilir.

Diğer öğeler

Başlangıç portalı: VC sunumu ve doğrulaması için İstek Hizmeti API çağrılarını koordine eden ve hesapları uyumlandırma mantığını yöneten bir web arayüzü.

Özel mantık / iş akışları: Kullanıcı hesabını güncelleştirmeden önce ve sonra kuruluşa özgü adımlarla belirli mantık. Örnek olarak onay iş akışları, diğer doğrulamalar, günlüğe kaydetme, bildirimler vb. verilebilir.

Hedef kimlik sistemleri: Konuları eklerken ekleme portalının etkileşim kurması gereken kuruluşa özgü kimlik depoları. Tümleştirecek sistemler, VC doğrulamasıyla eklemek istediğiniz kimlik türlerine göre belirlenir. Ekleme için kimlik doğrulamanın yaygın senaryoları şunlardır:

• Microsoft Entra ID'nin, API'ler kullanarak işletmeler arası (B2B) davetiyeler göndermek veya paketlere hak yönetimi atamaları yapmak için eklediği harici kimlikler.

• Merkezi kimlik sistemlerinde insan kaynakları (İK) sistemleri aracılığıyla hali hazırda entegre edilen çalışan kimlikleri. Bu durumda, kimlik doğrulaması İK iş akışlarının mevcut aşamalarının bir parçası olarak entegre edilebilir.

Tasarımla ilgili dikkat edilecek noktalar

• Veren: Hesap oluşturma süreci, doğrulanabilir kimlik bilgilerini veren olarak dış kimlik doğrulama hizmeti için uygundur. Kimlik doğrulama süreçlerindeki kontroller arasında şunlar yer alır: canlılık kontrolü, devlet tarafından verilen belgelerin doğrulanması, adres veya telefon numarası onayı vb.

• VC özniteliklerini depolama: Mümkün olduğunda, VC'lerin özniteliklerini uygulamanıza özgü deponuzda depolamayın. Kişisel verilere özellikle dikkat edin. Uygulamalarınızdaki belirli akışlar bu bilgileri gerektiriyorsa, VC'nin talep üzerine talepleri almasını istemeyi göz önünde bulundurun.

• Arka uç sistemleriyle VC öznitelik bağıntısı: VC'nin özniteliklerini verenle tanımlarken, kullanıcı VC'yi sunduktan sonra arka uç sistemindeki bilgileri ilişkilendirmek için bir mekanizma oluşturun. Mekanizma genellikle aldığınız taleplerle birlikte RP'niz bağlamında zamana bağlı, benzersiz bir tanımlayıcı kullanır. Bazı örnekler:

  • Yeni çalışan: İk iş akışı kimlik doğrulamasının gerekli olduğu noktaya ulaştığında, RP zamana bağlı benzersiz tanımlayıcıya sahip bir bağlantı oluşturabilir. RP daha sonra bunu İK sistemindeki adayın e-posta adresine gönderir. Bu benzersiz tanımlayıcı, VC doğrulama isteğindeki ad, soyad gibi bilgileri İnsan Kaynakları kaydıyla veya temel alınan veriyle ilişkilendirmek için yeterli olmalıdır. VC'deki öznitelikler, İk sistemindeki kullanıcı özniteliklerini tamamlamak veya çalışanla ilgili kullanıcı özniteliklerinin doğruluğunu doğrulamak için kullanılabilir.

  • Dış kimlikler - davet: Bir dış kullanıcı hedef sisteme davet edildiğinde, RP davet işlemini temsil eden benzersiz tanımlayıcıya sahip bir bağlantı oluşturabilir. Bu bağlantı dış kullanıcının e-posta adresine gönderilebilir. Bu benzersiz tanımlayıcı, VC doğrulama isteğini davet kaydıyla veya temel alınan veriyle ilişkilendirmek ve sağlama iş akışına devam etmek için yeterli olmalıdır. Dış kullanıcı özniteliklerini doğrulamak veya tamamlamak için VC'deki öznitelikler kullanılabilir.

  • Dış kimlikler - self servis: Dış kimlikler self servis (örneğin, B2C uygulaması) aracılığıyla hedef sisteme kaydolduğunda, kullanıcı hesabının ilk özniteliklerini doldurmak için VC'deki öznitelikler kullanılabilir. VC öznitelikleri, bir profilin zaten var olup olmadığını öğrenmek için de kullanılabilir.

• Hedef kimlik sistemleriyle etkileşim: Web ön ucu ile hedef kimlik sistemleriniz arasındaki hizmet-hizmet iletişimi, hesap oluşturabildiğinden yüksek ayrıcalıklı bir sistem olarak güvenli hale getirilmelidir. Web ön ucuna mümkün olan en az ayrıcalıklı rolleri verin. Bazı örnekler şunlardır:

  • Microsoft Entra Id'de yeni bir kullanıcı oluşturmak için RP web sitesi, kullanıcı oluşturmak için MS Graph kapsamı User.ReadWrite.All ve kimlik doğrulama yöntemini sıfırlama kapsamı UserAuthenticationMethod.ReadWrite.All verilen bir hizmet sorumlusu kullanabilir.

  • B2B işbirliği kullanarak kullanıcıları Microsoft Entra ID'ye davet etmek için, RP web sitesi, davetleri oluşturmak amacıyla MS Graph kapsamı User.Invite.All atanmış bir hizmet sorumlusu kullanabilir.

  • RP'niz Azure'da çalışıyorsa, Microsoft Graph'ı çağırmak için Yönetilen Kimlikler'i kullanın. Yönetilen kimliklerin kullanılması, kod veya yapılandırma dosyalarındaki hizmet sorumlusu kimlik bilgilerini yönetme risklerini ortadan kaldırır. Yönetilen kimlikler hakkında daha fazla bilgi edinmek için Azure kaynakları için yönetilen kimlikler bölümüne gidin.

Kuruluşlar içinde yüksek değerli uygulamalara erişme

Doğrulanabilir kimlik bilgileri, kuruluş içindeki hassas uygulamalara erişmek için başka bir kanıt olarak kullanılabilir. Örneğin, VC'ler çalışanların sertifikasyon gibi belirli ölçütlere ulaşmalarına bağlı olarak iş kolu uygulamalarına erişim sağlamak için de kullanılabilir.

Diğer öğeler

Güvenen taraf web arayüzü, iş gereksinimlerinize göre İstek Hizmeti API çağrıları ile VC sunumu ve doğrulaması için geliştirilmiş olan uygulamanın web arayüzüdür.

Kullanıcı erişimi yetkilendirme mantığı , uygulamanın kullanıcı erişimini yetkilendirilen mantıksal katmanıdır. Yetkilendirme kararları almak için VC içindeki kullanıcı özniteliklerini kullanacak şekilde geliştirilmiştir.

Diğer arka uç hizmetleri ve bağımlılıkları: Uygulamanın mantığının geri kalanını temsil eder. Bu mantık genellikle sanal makineler aracılığıyla kimlik doğrulamasının eklenmesiyle değişmez.

Tasarımla ilgili dikkat edilecek noktalar

• Hedef: Senaryonun hedefi, hangi türde bir kimlik belgesi ve veren kuruluşun gerekli olduğunu belirler. Tipik senaryolar şunlardır:

  • Yetkilendirme: Bu senaryoda, kullanıcı yetkilendirme kararı vermek için VC'yi sunar. Bir eğitimin tamamlandığının kanıtı veya belirli bir sertifikayı tutmak için tasarlanan sanal makineler bu senaryo için uygundur. VC öznitelikleri, yetkilendirme kararlarına ve denetime uygun ayrıntılı bilgiler içermelidir. Örneğin VC, bireyin eğitilmiş olduğunu onaylamak için kullanılır ve hassas finansal uygulamalara erişebilir. Uygulama mantığı, ayrıntılı yetkilendirme için departman talebine bakabilir ve denetim amacıyla çalışan kimliğini kullanabilir.

  • Kimlik doğrulama onayı: Bu senaryoda amaç, başlangıçta eklenen kişinin gerçekten de yüksek değerli uygulamaya erişmeye çalışan kişi olduğunu onaylamaktır. Kimlik doğrulama sağlayıcısından alınan bir belge iyi bir seçim olacaktır. Uygulama mantığı, VC'deki özniteliklerin uygulamada oturum açan kullanıcıyla uyumlu olduğunu doğrulamalıdır.

• İptali kontrol etme: Hassas kaynaklara erişmek için doğrulama kimlik bilgilerini (VC) kullanırken, özgün verenle VC'nin durumunu kontrol etmek ve iptal edilen VC'lerin erişimini reddetmek yaygın bir durumdur. Verenlerle çalışırken, iptal işleminin senaryonuzun tasarımının bir parçası olarak açıkça tartışıldığından emin olun.

• Kullanıcı deneyimi: Hassas kaynaklara erişmek için VM'leri kullanırken dikkate almanız gereken iki desen vardır.

  • Adım adım kimlik doğrulaması: Kullanıcılar mevcut kimlik doğrulama mekanizmalarıyla uygulamayla oturumu başlatır. Kullanıcıların, uygulama içinde iş iş akışlarının onayları gibi belirli yüksek değerli işlemler için bir VC sunması gerekir. Bu, yüksek değerli işlemlerin uygulama akışları içinde kolayca tanımlanabileceği ve güncelleştirildiği senaryolar için uygundur.

  • Oturum oluşturma: Kullanıcıların uygulamayla oturumu başlatmanın bir parçası olarak bir VC sunması gerekir. Tüm uygulamanın doğası yüksek değerli olduğunda, bir VC'nin sunulması uygun bir seçenek olur.

Kuruluş sınırları dışındaki uygulamalara erişme

Doğrulanabilir kimlik bilgileri, farklı bir kuruluşun üyeliğine veya istihdam ilişkisine göre erişim veya avantajlar vermek isteyen bağlı taraflar tarafından da kullanılabilir. Örneğin, bir e-ticaret portalı belirli bir şirketin çalışanlarına, belirli bir kurumun öğrencilerine vb. indirimler gibi avantajlar sunabilir.

Doğrulanabilir kimlik bilgilerinin merkezi olmayan yapısı, federasyon ilişkileri kurmadan bu senaryoyu etkinleştirir.

Diğer öğeler

Bağlı olan taraf web ön ucu: Bu, iş gereksinimlerinize göre VC sunusu ve doğrulaması için İstek Hizmeti API'si çağrıları aracılığıyla geliştirilmiş olan uygulamanın web ön ucudur.

Kullanıcı erişimi yetkilendirme mantığı: Uygulamadaki kullanıcı erişimini yetkilendirilen ve yetkilendirme kararları almak için VC içindeki kullanıcı özniteliklerini kullanacak şekilde geliştirilmiş mantıksal katman.

Diğer arka uç hizmetleri ve bağımlılıkları: Uygulamanın mantığının geri kalanını temsil eder. Bu mantık genellikle sanal makineler aracılığıyla kimlik doğrulamasının eklenmesiyle değişmez.

Tasarımla ilgili dikkat edilecek noktalar

• Hedef: Senaryonun hedefi, hangi türde bir kimlik belgesi ve veren kuruluşun gerekli olduğunu belirler. Tipik senaryolar şunlardır:

  • Kimlik doğrulaması: Bu senaryoda, bir kullanıcının çalışma veya belirli bir kuruluşla ilişkisini kanıtlamak için VC'ye sahip olması gerekir. Bu durumda, İstek Sahibi, hedef kuruluşlar tarafından verilen doğrulanabilir kimlik bilgilerini kabul edecek şekilde yapılandırılmalıdır.

  • Yetkilendirme: Uygulama gereksinimlerine bağlı olarak, uygulamalar ayrıntılı yetkilendirme kararları ve denetim için VC özniteliklerini tüketebilir. Örneğin, bir e-ticaret web sitesi belirli bir konumdaki kuruluşların çalışanlarına indirimler sunuyorsa, VC'deki ülke/bölge talebine (varsa) göre indirim uygunluğu doğrulayabilir.

• İptali kontrol etme: Hassas kaynaklara erişmek için doğrulama kimlik bilgilerini (VC) kullanırken, özgün verenle VC'nin durumunu kontrol etmek ve iptal edilen VC'lerin erişimini reddetmek yaygın bir durumdur. Verenlerle çalışırken, iptal işleminin senaryonuzun tasarımının bir parçası olarak açıkça tartışıldığından emin olun.

• Kullanıcı deneyimi: Kullanıcılar, uygulamayla oturumu başlatmanın bir parçası olarak bir VC sunabilir. Genellikle, uygulamalar kullanıcıların sanal bilgisayarı olmayan durumları karşılamak için oturumu başlatmak için alternatif bir yöntem de sağlar.

Hesap kurtarma

Doğrulanabilir kimlik bilgileri, hesap kurtarma yaklaşımı olarak kullanılabilir. Örneğin, bir kullanıcının hesabını kurtarması gerektiğinde, aşağıdaki diyagramda gösterildiği gibi MS Graph API'lerini çağırarak bir VC sunmasını ve Microsoft Entra kimlik bilgisi sıfırlaması başlatmasını gerektiren bir web sitesine erişebilir.

Uyarı

Bu bölümde açıklanan senaryo Microsoft Entra hesaplarını kurtarmaya özgü olsa da, bu yaklaşım diğer sistemlerdeki hesapları kurtarmak için de kullanılabilir.

Diğer öğeler

Hesap portalı: VC sunusu ve doğrulaması için API çağrılarını düzenleyen web ön ucu. Bu düzenleme, Microsoft Entra Id'deki hesapları kurtarmak için Microsoft Graph çağrılarını içerebilir.

Özel mantık veya iş akışları: Kullanıcı hesabını güncelleştirmeden önce ve sonra kuruluşa özgü adımlarla mantık oluşturma. Özel mantık onay iş akışlarını, diğer doğrulamaları, günlüğe kaydetmeyi, bildirimleri vb. içerebilir.

Microsoft Graph: Hesap kurtarma gerçekleştirmek için kullanılan Microsoft Entra verilerine erişmek için temsili durum aktarımı (REST) API'lerini ve istemci kitaplıklarını kullanıma sunar.

Microsoft Entra kurumsal dizini: Hesap portalı aracılığıyla oluşturulan veya güncelleştirilen hesapları içeren Microsoft Entra kiracısı.

Tasarımla ilgili dikkat edilecek noktalar

Microsoft Entra Id ile VC özniteliği bağıntısı: Verenle işbirliği içinde VC'nin özniteliklerini tanımlarken, kullanıcıyı tanımlayan talepleri kabul ettiğinizden emin olun. Örneğin, kimlik doğrulama sağlayıcısı (IDV) çalışanları eklemeden önce kimliği doğrularsa, verilen VC'nin iç sistemlerle eşleştirilebilen talepleri içerdiğinden emin olun. Bu tür talepler bir telefon numarası, adres veya doğum tarihi olabilir. RP, sosyal güvenlik numarasının (SSN) son dört basamağı gibi bu sürecin bir parçası olarak VC'de bulunmayan bilgileri isteyebilir.

Mevcut Microsoft Entra kimlik bilgilerini sıfırlama özelliklerine sahip VC'lerin rolü: Microsoft Entra ID'nin yerleşik bir self servis parola sıfırlama (SSPR) özelliği vardır. Doğrulanabilir Kimlik Bilgileri, kullanıcıların SSPR yöntemine erişimi olmayan veya SSPR yönteminin denetimini kaybetmediği durumlarda kurtarmanın başka bir yolunu sağlamak için kullanılabilir. Kullanıcının hem bilgisayarı hem de mobil cihazı kaybettiği senaryolarda, kullanıcı kimlik kanıtı verenden bir VC'yi geri alabilir ve hesabını uzaktan kurtarmak için sunabilir.

Benzer şekilde, kullanıcıların parola olmadan MFA kimlik doğrulama yöntemlerini sıfırlamasına olanak tanıyan geçici bir erişim geçişi oluşturmak için bir VC kullanabilirsiniz.

Yetkilendirme: Kimlik bilgisi kurtarma işlemine devam etmeden önce RP'nin denetlediği bir güvenlik grubu gibi bir yetkilendirme mekanizması oluşturun. Örneğin, yalnızca belirli gruplardaki kullanıcılar VC'ye sahip bir hesabı kurtarmaya uygun olabilir.

Microsoft Entra Kimliği ile etkileşim: Çalışanların kimlik bilgilerini sıfırlayabildiğinden, web ön ucu ile Microsoft Entra Id arasındaki hizmet-hizmet iletişimi yüksek ayrıcalıklı bir sistem olarak güvenli hale getirilmelidir. Web ön ucuna mümkün olan en az ayrıcalıklı rolleri verin. Bazı örnekler şunlardır:

• RP web sitesine, kimlik doğrulama yöntemlerini sıfırlamak için MS Graph kapsamı UserAuthenticationMethod.ReadWrite.All verilen bir hizmet ilkesi kullanma yetkisi verin. User.ReadWrite.All, kullanıcı oluşturma ve silme olanağı sağlayan yetkiyi verme.

• RP'niz Azure'da çalışıyorsa, Microsoft Graph'ı çağırmak için Yönetilen Kimlikler'i kullanın. Yönetilen Kimlikler, kod veya yapılandırma dosyalarında hizmet sorumlusu kimlik bilgilerini yönetmeyle ilgili riskleri ortadan kaldırır. Daha fazla bilgi için bkz . Azure kaynakları için yönetilen kimlikler.

Kimlik yönetimini planlama

Güvenen taraflara doğrulayıcı belgeleri eklerken IAM ile ilgili dikkate alınması gerekenler aşağıdadır. Bağlı olan taraflar genellikle uygulamalardır.

Kimlik doğrulama

• Bir VC'nin konusu bir insan olmalıdır.

• Bir insanın cüzdanında VC vardır ve VC'yi etkileşimli olarak sunmalıdır. Etkileşimli olmayan akışlar, örneğin adına, desteklenmez.

İzin

• VC'nin başarılı bir sunumu, tek başına kaba bir yetkilendirme kapısı olarak kabul edilebilir. VC öznitelikleri ayrıntılı yetkilendirme kararları için de kullanılabilir.

• Süresi dolan bir VC'nin uygulamanızda bir anlamı olup olmadığını belirleyin; öyleyse, yetkilendirme denetimlerinin bir parçası olarak VC'deki talebin değerini (süre sonu) kontrol edin. Süre sonunun uygun olmadığı durumlardan biri, konunun 18'den eski olup olmadığını doğrulamak için sürücü belgesi gibi devlet tarafından verilen bir belgenin gerekli olmasıdır. VC'nin süresi dolmuş olsa bile doğum talebi tarihi geçerlidir.

• İptal edilen bir VC'nin yetkilendirme kararınızda bir anlamı olup olmadığını belirleyin.

  • Uygun değilse durum API'sini denetlemek için çağrıyı atlayın (varsayılan olarak açıktır).

  • Uygunsa, uygulamanızda özel durumların uygun şekilde işlenmesini ekleyin.

Kullanıcı profilleri

Kullanıcı profili oluşturmak için sunulan doğrulanabilir kimlik bilgilerindeki verileri kullanabilirsiniz. Profil oluşturmak için öznitelikleri kullanmak istiyorsanız aşağıdaki öğeleri göz önünde bulundurun.

• VC yayımlandığında, yayım tarihi itibarıyla özniteliklerin durum anını içerir. Doğrulanabilir kimlik bilgileri uzun geçerlilik sürelerine sahip olabilir ve profilin bir parçası olarak kullanmak için yeterince yeni kabul ettiğiniz özniteliklerin yaşını belirlemeniz gerekir.

• Bir VC'nin, RP ile her oturum başladığında sunulması gerekiyorsa, özniteliklerle geçici bir kullanıcı profili oluşturmak için VC sunumunun çıktısını kullanmayı düşünebilirsiniz. Kalıcı olmayan bir kullanıcı profili, kullanıcı özelliklerini hareketsiz durumda depolamakla ilişkili gizlilik risklerini azaltmaya yardımcı olur. Uygulamanızın konunun özniteliklerini yerel olarak kaydetmesi gerekebilir. Öyleyse, yalnızca uygulamanızın ihtiyaç duyduğu talepleri kaydedin. Tüm VC'yi kaydetmeyin.

• Uygulama kalıcı bir kullanıcı profili deposu gerektiriyorsa:

  • sub talebini, kullanıcının sabit bir tanımlayıcısı olarak kullanmayı düşünün. Bu, belirli bir konu/RP çifti için sabit olan, opak benzersiz bir özniteliktir.

  • Uygulamadan kullanıcı profilinin kaldırılmasını sağlamak için bir mekanizma tanımlayın. Microsoft Entra Doğrulanmış Kimlik sisteminin merkezi olmayan yapısı nedeniyle uygulama kullanıcısı sağlama yaşam döngüsü yoktur.

  • VC belirtecinde döndürülen kişisel veri taleplerini depolamayın.

  • Yalnızca bağlı tarafın mantığı için gereken iddiaları depolayın.

Performans için planlama

Herhangi bir çözümde olduğu gibi performansı planlamanız gerekir. Odak alanları arasında gecikme süresi, aktarım hızı ve ölçeklenebilirlik yer alır. Yayın döngüsünün ilk aşamalarında performans sorun oluşturmamalıdır. Ancak çözümünüzün benimsenmesi doğrulanabilir birçok kimlik bilgilerinin doğrulanmasıyla sonuçlandığında performans planlaması çözümünüzün kritik bir parçası haline gelebilir.

Aşağıdaki öğeler, performans planlaması yaparken dikkate alınacak alanlar sağlar:

• Microsoft Entra Doğrulanmış Kimlik verme hizmeti Batı Avrupa, Kuzey Avrupa, Batı ABD 2 ve Orta Batı ABD Azure bölgelerinde dağıtılır. Gecikme süresini sınırlamak için doğrulama ön yüzünüzü (web sitesi) ve anahtar kasanızı en yakın bölgede dağıtın.

• Aktarım hızına göre model:

  • VC doğrulama kapasitesi Azure Key Vault hizmet sınırlarına tabidir.

  • Bir VC'nin her doğrulaması için bir Key Vault imzası işlemi gerekir.

  • Azaltmayı denetleyemezsiniz; ancak azaltmanın performansı nasıl etkileyebileceğini anlamak için Azure Key Vault azaltma kılavuzunu gözden geçirin.

Güvenilirlik planı

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma için en iyi planı yapmak için aşağıdaki öğeleri göz önünde bulundurun:

• Microsoft Entra Verified ID hizmeti Batı Avrupa, Kuzey Avrupa, Batı ABD 2 ve Orta Batı ABD, Avustralya ve Japonya Azure bölgelerinde dağıtılır. Destekleyici web sunucularınızı ve destekleyici uygulamalarınızı bu bölgelerden birine, özellikle de doğrulama trafiğinizin çoğunun kaynaklanmasını beklediğiniz bölgelerde dağıtmayı göz önünde bulundurun.

• Kullanılabilirlik ve yedeklilik hedefleriniz için tasarladığınız Azure Key Vault kullanılabilirliği ve yedekliliği ile ilgili en iyi yöntemleri gözden geçirin ve birleştirin.

Güvenlik için plan

Güvenliği tasarlarken aşağıdakileri göz önünde bulundurun:

• Tek bir kiracıdaki tüm güvenen taraflar (RP), aynı DID'yi paylaştığından aynı güven sınırını paylaşır.

• Key Vault'a erişen bir web sitesi için ayrılmış hizmet sorumlusu tanımlayın.

• Özel anahtarla iletileri imzalamak için yalnızca Microsoft Entra Doğrulanmış Kimlik hizmeti ve web sitesi hizmet sorumlularının Key Vault kullanma izinleri olmalıdır.

• Key Vault'a herhangi bir insan kimliği yönetim izni atamayın. Key Vault en iyi yöntemleri hakkında daha fazla bilgi için bkz. Key Vault için Azure Güvenlik Temeli.

• Çözümünüz için destekleyici hizmetleri yönetmeye yönelik en iyi yöntemler için Azure ortamlarını Microsoft Entra ID ile güvenli hale getirme makalesini gözden geçirin.

• Kimlik sahtekarlığı risklerini azaltmak için:

  • Müşterilerin veren markasını tanımlamasına yardımcı olmak için DNS doğrulaması uygulama.

  • Son kullanıcılar için anlamlı olan etki alanlarını kullanın.

• Dağıtılmış hizmet reddi (DDOS) ve Key Vault kaynak kısıtlama risklerini azaltın. VC sunumu için yapılan her istek, hizmet sınırlarına ulaşan Key Vault imzalama işlemlerine neden olur. Verme istekleri oluşturmadan önce alternatif kimlik doğrulaması veya captcha ekleyerek trafiği koruyun.

İşlemleri planlama

İşlemleri planlarken, her kimlik bilgisi doğrulama denemesini denetimin bir parçası olarak yakalayın. Bu bilgileri denetim ve sorun giderme için kullanın. Ayrıca, müşterilerin ve destek mühendislerinin gerekirse başvurabileceği benzersiz işlem tanımlayıcıları (kimlikler) oluşturmayı da göz önünde bulundurun.

Operasyonel planlamanızın bir parçası olarak aşağıdakileri izlemeyi göz önünde bulundurun:

• Ölçeklenebilirlik için:

  • Uygulamaların uçtan uca güvenlik ölçümlerinin bir parçası olarak başarısız VC doğrulamasını izleme.

  • Kimlik bilgisi doğrulamasının uçtan uca gecikme süresini izleyin.

• Güvenilirlik ve bağımlılıklar için:

  • Doğrulama çözümü tarafından kullanılan temel bağımlılıkları izleyin.

  • Azure Key Vault izleme ve uyarılarını izleyin.

• Güvenlik için:

  • İmzalama işlemlerini takip etmek ve yapılandırma değişikliklerini izleyip uyarı vermek için Key Vault için günlüğe kaydetmeyi etkinleştirin. Daha fazla bilgi için Bkz. Key Vault günlüğünü etkinleştirme .

  • Uzun süreli saklama için Microsoft Sentinel gibi bir güvenlik bilgileri ve olay yönetimi (SIEM) sistemlerindeki günlükleri arşivleyin.

Sonraki Adımlar

VC çözümlerinin mimarisini oluşturma hakkında daha fazla bilgi edinin

• Microsoft Entra Doğrulanmış Kimlik genel bakışı

• Microsoft Entra Doğrulanmış Kimlik verme çözümünüzü planlama

Doğrulanabilir Kimlik Bilgilerini Uygulama

• Microsoft Entra Doğrulanmış Kimlik Tanıtımı

• Doğrulanabilir Kimlik Bilgilerini kullanmaya başlama

SSS