Kurumsal Geçiş Anahtarı Dağıtımı Zorlukları ve Çözümleri

1. Giriş: çalışanlar için kurumsal geçiş anahtarlarının operasyonel gerçekliği#

Geçiş anahtarları (passkeys) iş dünyasına giriş yaptı. Artık soru "teknoloji çalışıyor mu?" değil. Soru artık "bunu büyük ölçekte nasıl çalıştırırız?". Sürtünme noktaları operasyonel katmana taşındı: ilk kaydın (başlatma) "tavuk mu yumurtadan çıkar yumurta mı tavuktan" problemi, cihaza bağlı ve senkronize geçiş anahtarları arasındaki fark, platformlar arası birlikte çalışabilirlik ve parolaların güvensizliğine geri dönmeyen kurtarma mekanizmaları.

Bu kılavuz, Microsoft Entra ID ortamlarında geçiş anahtarı dağıtımının gerçek dünyadaki zorluklarını ele alıyor ve yapılandırma tuzaklarını, operasyonel iş akışlarını ve kurtarma stratejilerini kapsıyor. Özellikle aşağıdaki soruları ele alacağız:

1. Entra ID'deki cihaza bağlı (device-bound) ve senkronize (synced) geçiş anahtarları arasındaki fark nedir?
2. Yeni çalışanlar için parolalar olmadan geçiş anahtarlarını nasıl başlatabilirim?
3. Kullanıcılar yeni bir telefon aldıklarında ve kimlik doğrulayıcılarına erişimlerini kaybettiklerinde nasıl kurtarma yaparlar?
4. Hangi yapılandırma hataları geçiş anahtarı kayıt başarısızlıklarına neden olur?
5. Kimlik avına dirençli MFA gerektirirken B2B konuklarını (misafir) nasıl idare ederim?
6. Donanım güvenlik anahtarları (YubiKeys) mı yoksa mobil geçiş anahtarları mı kullanmalıyım?
7. Geçiş anahtarı dağıtımında Windows'un yanı sıra macOS cihazlarını nasıl idare ederim?
8. Telefon değişikliklerinden kaynaklanan yardım masası yoğunluğunu hangi proaktif önlemler önler?

2. Microsoft Entra'da geçiş anahtarlarını anlamak#

Entra'da "geçiş anahtarları" = FIDO2/WebAuthn kimlik bilgileri. Kullanıcı bir parola yerine bir kimlik doğrulayıcıda saklanan özel bir anahtara sahip olduğunu kanıtlar. WebAuthn kimlik bilgisini gerçek oturum açma kaynağına bağladığı (bu nedenle benzer bir kimlik avı sitesi bunu tekrar oynatamaz) için kimlik avına dirençlidir (phishing-resistant). Microsoft'un Geçiş Anahtarları (FIDO2) kavramları belgelerindeki genel bakışa göz atın.

Entra etkin bir şekilde farklı davranan iki "geçiş anahtarı modunu" destekler.

2.1 Entra'daki cihaza bağlı geçiş anahtarları#

Bu geçiş anahtarları tek bir fiziksel cihaza bağlıdır (senkronize edilemez). Özel anahtar belirli bir donanım unsurunda (dizüstü bilgisayarda TPM, YubiKey'de Güvenli Öğe) bulunur. Dışa aktarılamaz.

Entra'da, cihaza bağlı olma hikayesi genellikle şunlara dönüşür:

• Microsoft Authenticator geçiş anahtarları
• Windows Hello veya İş için Windows Hello (WHfB) geçiş anahtarları (Ocak 2026 itibarıyla senkronize edilmemiş)
• FIDO2 güvenlik anahtarları (YubiKey gibi donanım anahtarları)
• Akıllı Kartlar (Smartcards)

Cihaza bağlı geçiş anahtarları için Microsoft'un temel kurulum kılavuzu burada bulunabilir: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Kullanım durumları: Yüksek ayrıcalıklı erişim, "acil durum (break-glass)" hesapları, paylaşılan iş istasyonu ortamları. Dezavantaj: Yüksek sürtünme. Cihazın kaybı, kimlik bilgisinin kaybı anlamına gelir. Yüksek operasyonel maliyet (örneğin, YubiKey'lerin kargolanması).

2.2 Entra'daki senkronize geçiş anahtarları#

Bunlar bir sağlayıcı ekosisteminde saklanan ve kullanıcının cihazları arasında senkronize edilen geçiş anahtarlarıdır (örneğin iCloud Anahtar Zinciri, Google Şifre Yöneticisi veya üçüncü taraf sağlayıcılar). Özel anahtar şifrelenir ve bir bulut sağlayıcısının senkronizasyon dokusunda saklanır.

Ocak 2026 itibarıyla, Entra'da senkronize geçiş anahtarları önizleme özelliği aracılığıyla ele alınmaktadır: Senkronize geçiş anahtarları (önizleme). Senkronize geçiş anahtarlarını etkinleştirmek ve kontrol etmek için Entra Geçiş Anahtarı Profillerini (önizleme) kullanır.

Mevzuata uygunluk: Yakın zamanda NIST SP 800-63B Ek 1 tarafından AAL2 gereksinimlerini karşıladığı doğrulanmıştır. Bu, senkronize geçiş anahtarlarının genel iş gücü kullanımı için yeterince "kimlik avına dirençli" olduğunu doğrulayan devasa bir mevzuat başarısıdır.

Kullanım durumları: Bilgi işçileri, KCG (Kendi Cihazını Getir - BYOD) kullanıcıları, yönetici kolaylığı. Dezavantaj: Donanımdan daha "düşük" güvence. Bulut sağlayıcısının hesap kurtarma akışının güvenliğine bağımlılık.

Aşağıda Entra'nın desteklediği senkronize geçiş anahtarı sağlayıcılarının bir özetini bulabilirsiniz:

Bir kullanıcının Güvenlik Bilgileri sayfasında senkronize ve cihaza bağlı geçiş anahtarları net bir şekilde ayırt edilir. Aşağıda senkronize bir geçiş anahtarının (1Password'den) ve cihaza bağlı bir geçiş anahtarının (YubiKey 5C NFC) nasıl göründüğünü görebilirsiniz:

2.3 Mevzuat uyumu: NIST AAL seviyeleri#

• AAL3 tarihsel olarak dışa aktarılamayan bir özel anahtar kullanan donanım tabanlı, cihaza bağlı kimlik doğrulayıcıları (YubiKey'ler veya Akıllı Kartlar gibi) gerektiriyordu.
• AAL2 artık NIST yönergelerine göre senkronize geçiş anahtarları ile elde edilebilir.
• Nüans: Senkronize geçiş anahtarları (iCloud'dakiler gibi) standart kullanıcılar için mükemmel olsa da, en yüksek ayrıcalık seviyeleri için AAL3 "dışa aktarılamazlık" gereksinimini tam olarak karşılamayabilirler. Bu nedenle, bölümlere ayrılmış bir strateji gereklidir: Yöneticiler için Donanım anahtarları (AAL3), İş gücü için Senkronize Geçiş Anahtarları (AAL2).

2.4 Cihaz hazırlık gereksinimleri#

Cihazların kimlik avına dirençli parolasız kimlik doğrulamaya hazır olmasını sağlamak için şu minimum sürümleri çalıştırmaları gerekir:

Eski işletim sistemleri, kimlik avına dirençli parolasız kimlik doğrulamayı desteklemek için harici kimlik doğrulayıcılara (FIDO2 güvenlik anahtarları) ihtiyaç duyabilir.

Minimum sürüm gereksinimlerinin ötesinde, tarayıcı tarafı yetenek desteği de platforma göre değişir. Corbado Geçiş Anahtarı Karşılaştırması 2026 WebAuthn istemci yetenekleri analizine göre, 2026'nın 1. çeyreğinde tarayıcı desteği Koşullu Getirme (Conditional Get) ve Karma Aktarım (Hybrid Transport) için %97–100 seviyesindedir, ancak tipik bir tüketici tarayıcı karışımında Koşullu Oluşturma (Conditional Create) için yalnızca %83–92 seviyesindedir — Windows Hello bir Koşullu Oluşturma yolu olmadığı için bu kısıtlama en çok Windows'u etkiler ve Edge aynı veri setinde Koşullu Oluşturma desteğinin çok düşük olduğunu bildirir. Karşılaştırma, iş gücü ortamlarından ziyade tüketiciye yönelik B2C dağıtımlarını kapsar, ancak aynı temel tarayıcı/işletim sistemi yeteneği tavanları Entra ID sunumları için de geçerlidir; yoğun kurumsal Edge popülasyonları, genel %83–92 Koşullu Oluşturma aralığının önemli ölçüde altında kalabilir.

2.5 Kullanıcı kişiliği kimlik bilgisi önerileri#

Microsoft, kimlik bilgisi dağıtımında kullanıcı kişiliğine dayalı bir yaklaşım önermektedir. Farklı rollerin farklı güvenlik gereksinimleri ve kabul edilebilir sürtünme seviyeleri vardır:

Taşınabilir kimlik bilgileri (cihazlar arasında kullanılabilir):

Yerel kimlik bilgileri (cihaza özel):

Nihai hedef: Çoğu kullanıcının en az bir taşınabilir kimlik bilgisi artı her hesaplama cihazında yerel kimlik bilgileri olmalıdır.

3. Canlı Geçiş Anahtarı Dağıtımlarından Deneyimler#

Geçiş anahtarları dağıtmış kuruluşlarla konuşurken gerçek dünyadaki bazı sürtünme noktaları ve kalıplar fark edilmektedir.

3.1 Operasyonel değişim#

"Zorluklar teknoloji yığınında değil operasyonel katmandadır." Bu durum, "Geçiş anahtarı kayıtlı değil" hataları veya kişisel cihazlarda Windows Hello seçeneklerinin görünmemesi gibi teknik engellerin benzersiz anormallikler değil, ekosistemin mevcut olgunluğuna içkin sistemsel sürtünme noktaları olduğunu doğrular. Kurumsal operasyonlar için kilit nokta, izlemede beklenen ve beklenmeyen başarısızlıkları ayırmaktır. WebAuthn hatalarını açıkça kategorize edin ve NotAllowedError, AbortError ve Kimlik Bilgisi Yöneticisi geçiş anahtarı hatalarını ayrı sinyaller olarak izleyin. Kimlik doğrulama analitiği başvuru kitabımız bu sinyalleri sınıflandırmak için bir çerçeve sunar ve geçiş anahtarı analitiği, aktivasyon ve giriş oranları gibi geçiş anahtarına özgü KPI'ları kapsar.

3.2 Kayıt: "Tamam ya da Devam" anı#

Kayıt, önemli bir değişim yönetimi gerektiren dağıtımın tartışmasız en zor aşamasıdır.

• Kayıt öncesi karmaşıklığı: Daha önce kimlik bilgisi olmayan yeni çalışanları işe almak birincil darboğazdır. Yönetici aracılı kayda olan bağımlılık, kopuk bir kullanıcı deneyimi yaratır.
• Platform parçalanması: Tarayıcıların, İşletim Sistemlerinin ve şifre yöneticilerinin bağımsız yinelemeleri nedeniyle "Adımlarla ilgili kullanıcı hayal kırıklığı". Bu durum, bir akışın Chrome/Windows üzerinde çalışıp Safari/macOS üzerinde başarısız olduğu veya şirket cihazlarında başarılı olurken yönetilmeyen kişisel cihazlarda başarısız olduğu geçici tutarsızlıklara yol açar.

3.3 Zihinsel model boşluğu#

"Kullanıcıların kriptografiye ihtiyacı yoktur, zihinsel bir modele ihtiyacı vardır". Terminoloji karmaşası bilişsel yüke neden olur:

• Geçiş Anahtarı (Passkey)
• Güvenlik Anahtarı (Security Key)
• Donanım Anahtarı (Hardware Key)
• YubiKey
• Parolasız (passwordless)
• Windows Security
• Windows Hello
• İş için Windows Hello (WHfB)
• Microsoft Authenticator
• Telefonla Oturum Açma (Phone Sign-in)

Teknolojiye aşina olmayan kullanıcılar, hatta aşina olanlar için bile bu terimlerin farklılıkları belirgin değildir.

Son kullanıcı iletişimlerinde "kimlik avına dirençli" veya "anahtar çifti" gibi jargonlardan kaçınılmasını öneririz. Bunun yerine telefonlarını kilidini açmaya benzer şekilde "kilit açma" konseptine odaklanın: "İşletmenin sistemlerinin kilidini açmak için yüzünüzü kullanın."

3.4 İletişim kısıtlamaları#

Başlangıçta güçlü bir benimseme başarı için kritiktir, ancak iletişim ancak bir yere kadar etkili olabilir. Kullanıcılardan kimlik doğrulama yöntemlerini kontrol etmelerini isteyen düzenli e-postalar gönderemezsiniz. Genel olarak, kullanıcı davranışı için iyi bir planlama yapamazsınız. Bu gerçeklik, yalnızca kullanıcı eğitimine güvenmek yerine proaktif teknik önlemler ihtiyacını doğurur.

4. Microsoft Entra ID yapılandırması derinlemesine incelemesi#

Kurumsal bir ortamda geçiş anahtarları dağıtmak, birbirine bağlı ilkeleri anlamayı ve kurmayı gerektirir. Geçiş anahtarları sadece basitçe açabileceğiniz bir özellik değildir, çünkü her çalışanın günlük işleri üzerinde büyük bir etkisi vardır.

4.1 Kimlik doğrulama yöntemleri ilkesi#

Eski MFA ve SSPR portalları kullanımdan kaldırıldı. Tüm FIDO2 yapılandırması birleştirilmiş Kimlik Doğrulama Yöntemleri İlkesi (Authentication Methods Policy) bölümünde gerçekleşmelidir.

• FIDO2 Güvenlik Anahtarı Yöntemi: Bu etkinleştirilmeli ve hedeflenmelidir. Etkinleştirme için "Tüm Kullanıcılar"ı hedeflemenizi, ancak Koşullu Erişim yoluyla zorlamayı kontrol etmenizi öneririz.
• Anahtar Kısıtlamaları (AAGUID'ler): Her FIDO2 cihazının (örn. YubiKey 5 NFC, iOS'te Microsoft Authenticator, Google Şifre Yöneticisi) benzersiz bir Kimlik Doğrulayıcı Onay GUID'si (AAGUID) vardır. En iyi uygulama olarak, yüksek güvenlikli ortamlar için yalnızca belirli, onaylanmış AAGUID'lere İzin Vermek amacıyla "Anahtar Kısıtlamalarını Zorla" ayarını kullanın. Bu, kullanıcıların ucuz, doğrulanmamış "gri piyasa" güvenlik anahtarlarını kaydetmesini engeller.

4.2 Onay (Attestation): kritik karar noktası#

En önemli yapılandırma kararlarından biri "Onayı Zorla" (Enforce Attestation) kararıdır.

• Ne yapar: Kimlik doğrulayıcının kayıt sırasında Entra ID'ye markasını ve modelini kriptografik olarak kanıtlamasını zorunlu kılar.
• Çatışma: Senkronize Geçiş Anahtarları (iCloud Anahtar Zinciri, Bitwarden veya Google Şifre Yöneticisi gibi yazılım sağlayıcılarında saklananlar) genellikle onayı desteklemez, çünkü yazılım tabanlıdırlar ve platformdan bağımsızdırlar. Donanım tabanlı bir sertifika ile bir zorlu görevi (challenge) imzalayamazlar.
• Ödünleşim (Trade-off):
  • EVET olarak ayarlandığında: Yüksek güvence (AAL3) için gereklidir. Anahtarın donanıma bağlı olmasını sağlar. Yazılım tabanlı geçiş anahtarı sağlayıcılarını engeller.
  • HAYIR olarak ayarlandığında: Senkronize Geçiş Anahtarlarına izin verir. Güvenceyi biraz düşürür (AAL2). Yazılım tabanlı geçiş anahtarı sağlayıcılarını etkinleştirir.

Donanım anahtarı gerektiren yüksek ayrıcalıklı yöneticileriniz varsa genel bir "Onay Yok" ilkesi uygulayamazsınız. Geçiş Anahtarı Profillerini (Önizleme) kullanmalısınız:

• Profil A (Yöneticiler): Onayı Zorla = Evet
• Profil B (Genel Personel): Onayı Zorla = Hayır

4.3 Geçiş Anahtarı Profilleri açıklaması#

Geçiş Anahtarı Profillerini (Passkey Profiles) şunları tanımlamak için bir mekanizma olarak düşünün:

• "Bu kullanıcılar senkronize geçiş anahtarlarını kullanabilir"
• "Bu kullanıcılar sadece cihaza bağlı olanları kullanmalıdır"
• "Onay gereklidir veya gerekli değildir" (ve dolayısıyla: senkronize geçiş anahtarlarına izin verilir veya hariç tutulur)
• "Belirli kimlik doğrulayıcı türleriyle kısıtla (AAGUID kısıtlamaları)"

Aşağıda geçiş anahtarı profillerini yapılandırdığınız Microsoft Entra yönetici merkezindeki Geçiş Anahtarı (FIDO2) ayarları sayfasını görebilirsiniz:

Bir geçiş anahtarı profilini düzenlerken, onay zorunluluğunu, hedef türlerini (cihaza bağlı, senkronize veya her ikisi) ve belirli AAGUID kısıtlamalarını yapılandırabilirsiniz:

4.4 Koşullu Erişim ve kimlik doğrulama güçleri#

Zorlama (enforcement), Kimlik Doğrulama Güçlerini (Authentication Strengths) kullanan Koşullu Erişim (Conditional Access - CA) ilkeleri aracılığıyla ele alınabilir.

• Kimlik Avına Dirençli MFA Gücü: Bu yerleşik güç, FIDO2, İş için Windows Hello (WHfB) veya Sertifika Tabanlı Kimlik Doğrulaması (CBA) gerektirir.
• Kilitlenme Tuzağı: "Tüm Bulut Uygulamaları" için "Kimlik Avına Dirençli MFA" gerektiren bir CA ilkesi oluşturur ve bunu "Tüm Kullanıcılar"a uygularsanız, henüz bir geçiş anahtarı kaydetmemiş olan her kullanıcıyı anında kilitlersiniz. Bir geçiş anahtarı kaydetmek için oturum bile açamazlar.
• "Güvenlik Bilgilerini Kaydet" Paradoksu: Bu, CA'da belirli bir Kullanıcı Eylemidir. Güvenlik Bilgilerini Kaydetme eylemini gerçekleştirmek için Kimlik Avına Dirençli MFA'yı zorunlu kılarsanız, döngüsel bir bağımlılık (tavuk ve yumurta) yaratırsınız. Bir kullanıcı kayıt sayfasına erişmek için bir geçiş anahtarına ihtiyaç duyduğundan ilk geçiş anahtarını kaydedemez.

Burada hangi kimlik doğrulama yöntemlerinin hangi güç gereksinimlerini karşıladığına dair bir genel bakış yer almaktadır:

4.5 Sistem tarafından tercih edilen kimlik doğrulaması#

Entra ID'nin "Sistem tarafından tercih edilen çok faktörlü kimlik doğrulaması" özelliği, oturum açma motorunu kullanıcıdan kaydedilen en güvenli yöntemi istemeye zorlar.

Bir kullanıcının hem SMS'i hem de bir geçiş anahtarı kayıtlıysa, sistem varsayılan olarak geçiş anahtarını kullanır. Bu, sert bir zorunluluk olmadan geçiş anahtarının organik olarak benimsenmesini sağlar. Temelde, kimlik bilgisini kaydettikten sonra kullanıcının güvenlik duruşunu otomatik olarak "yükseltir".

Aşağıda geçiş anahtarı ile oturum açma deneyimini görebilirsiniz. Kullanıcıdan "Yüz, parmak izi, PIN veya güvenlik anahtarı" kullanması istenir ve bir tarayıcı uzantısından veya sistem kimlik bilgisi yöneticisinden geçiş anahtarını seçebilir:

4.6 macOS hususları: Platform SSO#

Karışık Windows/macOS ortamlarına sahip kuruluşlar için macOS Platform SSO, İş için Windows Hello'nun Apple karşılığını sağlar. MDM çözümleriyle birlikte kullanıldığında şunları elde edebilirsiniz:

• Mac'in Secure Enclave'ine bağlı cihaza bağlı kimlik bilgileri
• Yerel uygulamalar ve web uygulamaları arasında SSO deneyimi
• AAL2/AAL3 gereksinimlerini karşılayan kimlik avına dirençli kimlik doğrulama

Not: macOS Platform SSO, macOS 13+ ve doğru MDM yapılandırması gerektirir. Kurulum, Windows WHfB'den önemli ölçüde farklıdır, bu nedenle ayrı dağıtım yolları planlayın.

5. Yaygın yanlış yapılandırmalar: Neden "yalnızca Microsoft Authenticator ile çalışıyor"#

Hedefiniz yönetilmeyen cihazlarda senkronize geçiş anahtarları ise, bunlar en yaygın engellerdir:

5.1 Senkronize geçiş anahtarları etkinleştirilmemiş/hedeflenmemiş#

Entra'da genel olarak "FIDO2"yi etkinleştirmek yeterli değildir. Senkronize geçiş anahtarları için genellikle şunlara ihtiyacınız vardır:

• Senkronize geçiş anahtarları (önizleme) bölümünde açıklanan önizleme özelliği yolu
• Geçiş Anahtarı Profillerini kullanan bir profil yapılandırması

Bir grup, senkronize geçiş anahtarlarına izin veren bir profil tarafından hedeflenmemişse, "sadece cihaza bağlı" dünyasına geri çekilirsiniz.

5.2 Onay zorunlu (senkronize geçiş anahtarlarını engeller)#

Bu durum güvenliğe önem veren kuruluşlarda soruların çoğuna neden olur:

• Entra bazı geçiş anahtarı senaryoları için onay (attestation) isteyebilir (kimlik doğrulayıcı türünü/kaynağını doğrulamaya yardımcı olur)
• Senkronize geçiş anahtarları Entra'da onayı desteklemez, bu nedenle onay zorunlu kılındığında senkronize geçiş anahtarlarının kaydı başarısız olur ve yalnızca cihaza bağlı seçeneklerle karşılaşırsınız

5.3 AAGUID izin listesi sağlayıcıları engelliyor#

Entra, hangi kimlik doğrulayıcılara izin verileceğini kısıtlamanıza olanak tanır (genellikle AAGUID izin/engelleme listeleri aracılığıyla). Eğer yalnızca Microsoft Authenticator'a (veya dar bir kimlik doğrulayıcı setine) izin verirseniz, üçüncü taraf senkronize sağlayıcılar zımni olarak engellenebilir. Kafa karıştıran kısım ise yerel kimlik doğrulamanın (örn. Touch ID, Face ID, Windows biyometrik taraması) çalışması, ancak ardından Entra giriş sayfasında bir hata görüntülenmesidir.

5.4 Koşullu Erişim belirli geçiş anahtarı türlerini zorlar#

Geçiş anahtarları etkinleştirilmiş olsa bile, Koşullu Erişim kullanıcıları fiili olarak yöntemlerin bir alt kümesine (örn. "Sadece Authenticator" veya amaçlanan geçiş anahtarı profiline izin vermeyen bir güç yapılandırması) zorlayabilir. Pratikte bu, plan senkronize geçiş anahtarları olsa bile "Authenticator bağımlılığı" yaratır.

5.5 B2B konuk hesapları ve üye hesapları#

Dış ortaklar bir kaynak kiracısında (resource tenant) B2B konuk kullanıcılarıysa, kimlik doğrulama yöntemlerini nerede/nasıl kaydedebilecekleri konusunda bilinen sınırlamalar vardır. "Ortaklar kiracımızda geçiş anahtarlarını kullanacak" amacı güdüldüğünde, "neden çalışmıyor" sorusunun arkasındaki gizli neden genellikle budur.

6. Operasyonel zorluklar ve çözümler#

6.1 Başlatma (Bootstrapping) paradoksu#

En yaygın sorun ("Kayıt en zor kısımdır") başlatma problemidir: Şu anda hiçbir kimlik bilgisi olmayan (veya yalnızca düşük güvenceli kimlik bilgileri olan) bir kullanıcıya yüksek güvenceli bir kimlik bilgisini güvenli bir şekilde nasıl verirsiniz?

6.1.1 Geçici Erişim Geçişi (TAP)#

Geçici Erişim Geçişi (Temporary Access Pass - TAP) parolasız ilk katılım (onboarding) için mimari bir yaklaşımdır.

• Ne olduğu: Entra ID'nin "güçlü kimlik doğrulama" yöntemi olarak ele aldığı zaman sınırlı (örneğin 1 saat), yüksek entropili bir parola. Bir parola veya mevcut bir MFA ihtiyacını atlar.
• İş akışı:
  1. Kimlik Doğrulama: Yeni çalışanın kimliği doğrulanır (örn. İK süreci veya Yönetici doğrulaması yoluyla).
  2. Düzenleme: Bir yönetici (veya otomatikleştirilmiş Logic App) kullanıcı için bir TAP oluşturur.
  3. "Sihirli" Oturum Açma: Kullanıcı aka.ms/mysecurityinfo adresine gider. Kullanıcı adını ve TAP'yi girer.
  4. Kayıt: TAP "Güçlü Doğrulama" (Strong Auth) gereksinimini karşıladığından, kullanıcının Güvenlik Bilgileri bıçağına (blade) erişmesine izin verilir. "Yöntem Ekle"ye tıklar ve geçiş anahtarını kaydederler.
  5. Durağan Durum: TAP'nin süresi dolar. Kullanıcının artık kimlik avına dirençli bir kimlik bilgisi var. Hiçbir zaman bir parola yazmadılar.

6.1.2 Graph API ile Otomasyon#

Büyük kuruluşlar için manuel TAP düzenlemesi ölçeklenebilir değildir. En iyi uygulama, Microsoft Graph API aracılığıyla otomatikleştirmektir.

• Senaryo: Yeni bir işe alım, İK sisteminde (Workday/SuccessFactors) işlenir.
• Tetikleyici: Yetkilendirme (provisioning) olayı bir Azure Logic App'i tetikler.
• Eylem: Logic App, Graph API POST /users/{id}/authentication/temporaryAccessPassMethods çağrısını yapar.
• Teslimat: TAP, ilk gün erişimi için yeni çalışanın yöneticisine veya (şifrelenmiş olarak) kişisel e-postasına güvenli bir şekilde teslim edilir.

6.1.3 Yüksek güvenceli ilk katılım için Microsoft Entra Doğrulanmış Kimlik#

Uzaktan ilk katılım veya yüksek kimlik güvencesi gerektiren senaryolar için, Microsoft'un Entra Doğrulanmış Kimlik (Verified ID) özelliği ile birlikte gelen Face Check, öncelikli olarak parolasız bir kayıt yolu sağlar:

1. Kimlik ispatı: Yeni kullanıcı, bir IDV iş ortağı (hükümet kimlik taraması) aracılığıyla kimliğini doğrular.
2. Biyometrik eşleştirme: Face Check, Azure AI Vision kullanarak canlı bir özçekimi kimlik belgesi fotoğrafıyla karşılaştırır. Yalnızca bir eşleşme güven puanı paylaşılır (ham biyometrik veri yoktur).
3. Doğrulanmış kimlik bilgisi verildi: Kullanıcı bir Doğrulanmış Kimlik bilgisi alır.
4. TAP verilmesi: Başarılı doğrulamanın ardından sistem bir Geçici Erişim Geçişi (TAP) verir.
5. Geçiş anahtarı başlatma: Kullanıcı TAP kullanarak ilk geçiş anahtarını kaydeder.

Face Check akışı kullanıcılara üç adım boyunca rehberlik eder: Doğrula (kimlik bilgilerini paylaş), Onayla (yüz taraması yap) ve İncele (eşleşme sonucunu gör):

Bu akış, ilk günden itibaren gerçekten parolasız hesaplar sağlar. Hiçbir zaman parola oluşturulmaz.

6.2 Telefon değişimi sorunu (gizli ölçek zorluğu)#

Geçiş anahtarı dağıtımlarında bu genellikle yardım masası çağrılarının en büyük kaynağıdır. Büyük BYOD (Kendi Cihazını Getir) kitlelerine (örneğin, 10.000'den fazla cihaz) sahip kuruluşlar, kullanıcıların yeni telefonlar alması ve kimlik doğrulama yöntemlerini yeniden kaydetme sürecini bilmemelerinden kaynaklanan büyük miktarda destek çağrısı görebilirler.

Geçiş anahtarlarını denkleme dahil ettiğinizde bu durum daha da kritik hale gelir çünkü:

• Kullanıcılar yeni telefonlarına uygulamalar (Outlook gibi) kurarlar
• Bu uygulamalar kimlik doğrulaması ister
• MFA istemi eski telefonda belirir (ki bu telefon takas edilmiş veya silinmiş olabilir)
• Kullanıcı kilitlenir ve yardım masasını arar

6.2.1 Telefon değişimi için senaryo matrisi#

Amaç, mümkün olduğunca çok vakayı ilk iki sıraya kaydırarak yardım masası katılımını en aza indirmektir.

6.2.2 Intune kaydı hilesi#

Zekice bir öngörü: Intune kaydı için bir geçiş anahtarı talep etmek, kullanıcıları yeni telefonlarında kurumsal uygulamalara erişmeden önce derhal Microsoft Authenticator kurulumunu tamamlamaya zorlar.

• Bugün: Intune kaydı, MFA yükseltmesi gerektirir. Bu, yeni bir telefonda oturum açmak istiyorsanız, Outlook'u oraya kurduğunuz anlamına gelir. Ancak MFA istemi eski telefona gider.
• Geçiş anahtarı gereksinimiyle: Kullanıcıların kaydı tamamlamak için önce yeni telefonda Microsoft Authenticator geçiş anahtarlarını kurması gerekir. Bu, aylar sonra eski telefon ortadan kalktığında değil, hızlı bir şekilde (telefonun değiştirildiği gün) gerçekleşir.

Bu kurtarmayı çözmez, ancak zaman çizelgesini değiştirir. Kullanıcılar hala eski cihaza erişimleri varken yeni cihazlarını kaydederler.

6.3 Donanım güvenlik anahtarları lojistik sorunları da beraberinde getirir#

Donanım anahtarları (YubiKey'ler vb.) bazen evrensel çözüm olarak konumlandırılır. Teoride öyledirler, ancak gerçek dünya daha fazla zorluk gösterir:

• Lojistik kabus: Daha önce fiziksel token'lar (RSA SecurID gibi) dağıtan kuruluşlar, bunları ortadan kaldırmak için genellikle yıllar harcadı. Bir fiziksel token programını bir başkasıyla değiştirmek çekici değildir.
• Doğrudan teslim (Drop-shipping): Yubico anahtarları doğrudan kullanıcılara gönderebilir ve bunların birkaç yılda bir pil değişimine ihtiyacı yoktur (SecurID'den farklı olarak). Ancak biri anahtarını unutursa, (paylaşılan masaüstü bilgisayarlar için) oturum açamaz.
• Yerel BT yükü: Yerel amirler, unutulan anahtarlar için fiili BT desteği haline gelmemelidir.
• Maliyet: Donanım anahtarları, personel sayısına göre ölçeklenen kullanıcı başına maliyet ekler.

Donanım anahtarlarının mantıklı olduğu durumlar:

• Tier 0 yöneticileri: Etki alanı yöneticileri (Domain admins), "acil durum" hesapları
• Paylaşılan iş istasyonları: Kiosk ortamları, fabrika zeminleri, saha tabletleri
• KCG (BYOD) olmayan yükleniciler: Kişisel cihazlarını kullanmayacak olan harici kullanıcılar

6.4 Yönetilmeyen cihaz zorlukları#

Pek çok kullanıcı kişisel bir cihazda geçiş anahtarı kullanım seçeneklerini göremediğinden şikayet eder. Bu klasik bir "yönetilmeyen cihaz" sürtünme noktasıdır.

6.4.1 "Geçiş anahtarı kayıtlı değil" hatası analizi#

Kullanıcılar kurumsal bir cihazda çalışırken kişisel bir cihazda geçiş anahtarı ekleyemeyebilirler. Bunun nedeni muhtemelen Intune Uyumluluk İlkelerinin (Compliance Policies) kayıt akışıyla etkileşime girmesidir.

• Mekanizma: İş için Windows Hello (WHfB) bir platform kimlik bilgisidir. Belirli bir cihazın TPM'sine (cihaza bağlı geçiş anahtarı) bağlıdır.
• Kısıtlama: WHfB'yi kaydetmek için cihazın genellikle kiracıya katılması (Entra Joined veya Hybrid Joined) gerekir. Yalnızca "Kayıtlı" (Workplace Joined) olan kişisel bir cihaza, cihaz tamamen yönetilmiyor veya uyumlu değilse WHfB kaplarının sağlanmasını engelleyen Intune aracılığıyla ilke kısıtlamaları uygulanabilir. FIDO2 güvenlik anahtarı oturum açma gereksinimlerine bakın.
• "Geçiş Anahtarı" Seçeneği: Kişisel bir cihazda, kullanıcının kaydetmeye çalışması gereken şey (BYOD kaydı tam olarak desteklenmedikçe) İş için Windows Hello değil, bir FIDO2 Güvenlik Anahtarı (dolaşan/roaming) veya bir Cihazlar Arası Geçiş Anahtarıdır (Cross-Device Passkey) (telefonlarında).
• Entra ID Görünürlük Sorunu: Bir seçenek olarak "Windows Hello" görünmüyorsa, cihaz önkoşul olan MDM kaydını tamamlamamıştır.

6.4.2 Cihazlar Arası Kimlik Doğrulama (CDA) hataları#

Yönetilmeyen cihazlarda kullanıcılar genellikle Cihazlar Arası Kimlik Doğrulama (CDA) akışını (bilgisayardaki bir QR kodunu telefonlarıyla tarama) denerler.

• Bluetooth Bağımlılığı: CDA, hem bilgisayarda hem de telefonda Bluetooth'un etkin olmasını gerektirir. Eşleşmeleri gerekmez, ancak yakınlığı kanıtlamak için bir Bluetooth Düşük Enerji (BLE) el sıkışması (handshake) gerçekleştirmelidirler. Ayrıntılar için Microsoft Authenticator'da cihaza bağlı geçiş anahtarları belgelerini inceleyin.
• Kurumsal İlke Engelleyici: Bluetooth, kurumsal dizüstü bilgisayarlarda BIOS veya "güvenlik" için GPO aracılığıyla devre dışı bırakılmışsa, dolaşan (roaming) geçiş anahtarları için birincil mekanizmayı zaten bozmuşsunuz demektir.
• Websocket Engelleme: CDA akışı, cable.ua5v.com veya cable.auth.com adresine giden bir websocket bağlantısı kullanır. Agresif kurumsal güvenlik duvarları veya Zscaler yapılandırmaları genellikle bu alan adlarını engeller ve QR kod taramasının asılı kalmasına veya sessizce başarısız olmasına neden olur. Microsoft Authenticator geçiş anahtarı belgelerine bakın.

6.5 B2B ve dış kimlikler#

Kuruluşlar için bir diğer sıkıntılı nokta da dış danışmanlarla (B2B konukları) ilgilenmektir.

• Sorun: Bir danışman bir SharePoint sitesine erişmeye çalışır. Kiracı, "Kimlik Avına Dirençli MFA" gerektiren bir Koşullu Erişim ilkesi uygular.
• Hata: Danışman kaynak kiracısında (resource tenant) bir FIDO2 anahtarı kaydetmeye çalışır. Bu başarısız olur. Entra ID kaynak kiracısında konuk kullanıcıların FIDO2 anahtarlarını kaydetmesini desteklemez.
• Çözüm: Kiracılar Arası Erişim Ayarları
  • Mantık: Konuğu kiracınızda bir kimlik bilgisi kaydetmeye zorlamak yerine, kendi kiracılarında kullandıkları kimlik bilgisine güvenmelisiniz.
  • Yapılandırma: Dış Kimlikler (External Identities) > Kiracılar arası erişim ayarları (Cross-tenant access settings) bölümüne gidin. Ortak kuruluşu seçin. Gelen Güven (Inbound Trust) altında "Microsoft Entra kiracılarından gelen çok faktörlü kimlik doğrulamasına güven" onay kutusunu işaretleyin.
  • Sonuç: Danışman, kendi (ana) kiracısında bir YubiKey kullanarak oturum açtığında, kiracınız "MFA Karşılandı + Kimlik Avına Dirençli" diyen bir talep (claim) alır. Kullanıcının herhangi bir şey kaydetmesine gerek kalmadan erişim verilir. Bu, kimlik bilgisi yaşam döngüsü yönetimini ortağa dış kaynaklı hale getirir, yükümlülüğünüzü ve yardım masası yükünüzü azaltır.

7. Kurtarma stratejileri#

Genellikle kurtarma kararları fiili kullanıma sunumun gerisinde kalır. Kuruluşunuzun ihtiyaçlarına bağlı olarak birden fazla kurtarma seçeneği mevcuttur.

7.1 Verified ID (Doğrulanmış Kimlik) ile Self-Servis Hesap Kurtarma (SSAR)#

Microsoft Entra ID'nin yeni Self-Servis Hesap Kurtarma (SSAR) akışı (Önizlemede), yardım masası müdahalesi olmadan yüksek güvenceli kurtarmaya olanak tanır.

1. Tetikleyici: Kullanıcı oturum açamıyor. "Hesabımı kurtar" seçeneğini seçiyor.
2. Kimlik Doğrulama: Kullanıcı üçüncü taraf bir Kimlik Doğrulama (IDV) sağlayıcısına (örneğin Onfido, IDemia) yönlendirilir.
3. Belge Kontrolü: Kullanıcı, mobil kamerasını kullanarak fiziksel Sürücü Belgesini, ulusal kimliğini veya pasaportunu tarar.
4. Canlılık Kontrolü (Liveness Check): Kullanıcı bir selfie Face Check gerçekleştirir. Bu, kimlik belgesiyle (ve potansiyel olarak Entra ID'de saklanan fotoğrafla) eşleştirilir. Eşleştirme, Azure AI Vision Yüz API'lerini kullanır ve yalnızca bir güven puanı paylaşılır. Uygulamaya hiçbir ham biyometrik veri gitmez.
5. Geri Yükleme: Başarı durumunda, sistem otomatik olarak kullanıcıya bir Geçici Erişim Geçişi (TAP) verir.
6. Yeniden Kayıt: Kullanıcı TAP'yi kullanarak derhal yeni bir geçiş anahtarı kaydeder.

Öneri: Bu otomatik, biyometrik destekli kurtarma yolu, sosyal mühendisliğe (Deepfake ses saldırıları) karşı savunmasız olan "Yardım Masasını Ara" yönteminden daha üstündür.

7.2 My Staff ile Yönetici Destekli Kurtarma#

Hizmet Masası (Service Desk) yükünü azaltmak istiyor ancak tam self-servisi etkinleştiremiyorsanız, Microsoft Entra, My Staff adlı yerel bir yetkilendirilmiş yönetim özelliği içerir.

• Nasıl çalışır: "Takım Yöneticilerine" (Entra'daki Yönetim Birimleri aracılığıyla) sınırlı izinler devredin.
• Akış: Bir kullanıcı erişimini kaybederse, parola sıfırlama veya telefon numarasını güncelleme gibi desteklenen kurtarma görevleri için My Staff portalını kullanabilen yetkilendirilmiş yerel bir yöneticiyle iletişime geçebilir.
• Neden yardımcı olur: Yaygın hesap kurtarma işlerini merkezi yardım masasından uzaklaştırır ve desteği hızlandırır.

7.3 Self-Servis Kurtarma kiosku (intranet)#

Kullanıcıların genellikle WHfB güvenliğine sahip güvenilir bir dizüstü bilgisayarı olduğundan, basit bir "acil durum (break glass)" intranet sayfası oluşturabilirsiniz.

• Oluşturma: WHfB oturumu açmayı (güçlü kimlik doğrulama) gerektiren basit bir dahili web uygulaması.
• Eylem: Kimlik doğrulandıktan sonra kullanıcı "Yeni bir telefonum var" seçeneğine tıklar. Uygulama, kısa ömürlü bir Geçici Erişim Geçişi (TAP) oluşturmak ve ekranda görüntülemek için Microsoft Graph API (arka plan hizmeti) kullanır.
• Sonuç: Kullanıcı, Microsoft Authenticator uygulamasını başlatmak için bu TAP'yi yeni telefonuna yazar. Sıfır yardım masası katılımı.

Bu, politikayı zayıflatmadan "kimlik doğrulama yöntemlerini temizleme" sıfırlamalarını azaltmak için kilit kaldıraçtır. Güçlü bir "başlatıcı olarak dizüstü bilgisayar" mekanizmanız varsa, kullanıcılar mükemmel dizilimi bilmeden kurtarma yapabildikleri için iletişim yükünüz önemli ölçüde düşer.

8. Kurumsal Geçiş Anahtarı Dağıtımları İçin Öneriler#

Sunumunuzu (rollout) Olgunluk Aşamaları etrafında yapılandırın. Sürtünmeyi kabul edin ("Teknoloji hazır, operasyonlar zor") ve bu hafifletici önlemleri uygulayın.

8.1 Acil eylemler ("Düzeltme" aşaması)#

1. Bluetooth ve Güvenlik Duvarlarını Denetleyin: Kurumsal dizüstü bilgisayarların Bluetooth'a (yakınlık kontrolleri için) izin verdiğinden emin olun ve cihazlar arası hataları düzeltmek için FIDO/WebAuthn geçiş alanı adlarını (\*.cable.auth.com) beyaz listeye alın.
2. Kiracılar Arası Güveni Etkinleştirin: Konuk geçiş anahtarlarını kaydetmeye çalışmayı bırakın. B2B erişim sorunlarını hemen çözmek için kilit iş ortakları için MFA Gelen Güvenini (Inbound Trust) yapılandırın.
3. İlk Katılım (Onboarding) İçin TAP Uygulayın: "Tavuk ve yumurta" kayıt engelini çözmek için tüm yeni kullanıcı kayıtlarında Geçici Erişim Geçişi kullanımını zorunlu kılın.

8.2 Stratejik kararlar ("Mimari" aşaması)#

1. "Hibrit Güvence" Modelini Benimseyin:
   • Tier 0 (Yöneticiler): Onay ve Anahtar Kısıtlamalarını zorunlu kılın. Sadece YubiKey/Donanıma izin verilir (AAL3).
   • Tier 1 (İş Gücü): Geçiş Anahtarı Profilleri aracılığıyla Onay zorunluluğunu devre dışı bırakın. Sürtünmeyi ve maliyeti azaltmak için senkronize geçiş anahtarlarına izin verin (AAL2).
2. macOS için Plan Yapın: Windows WHfB'ye paralel bir yol olarak MDM'nizle Platform SSO'yu dağıtın.

8.3 Geleceğe hazırlık ("Optimizasyon" aşaması)#

1. SSAR için Plan Yapın: Yardım masasını bir sosyal mühendislik vektörü olarak ortadan kaldırmak için Doğrulanmış Kimlik (Verified ID) ile Self-Servis Hesap Kurtarma için bir pilot başlatın.
2. Sistem Tercihli Kimlik Doğrulama: Kullanıcıları geçiş anahtarı kaydettikleri anda otomatik olarak "yükseltmek" ve katı bir zorunluluk olmadan benimsemeyi artırmak için bu ilkeyi etkinleştirin.
3. Kurtarma Seçeneklerini Dağıtın: My Staff aracılığıyla Yönetici Destekli TAP'yi ve/veya bir Self-Servis Kurtarma Kiosku uygulayın.
4. Intune Geçiş Anahtarı Gereksinimi: Yeni cihazlarda erken kaydı zorlamak için Intune kaydı için geçiş anahtarı gereksinimini düşünün.

8.4 Sorun giderme matrisi#

9. Kimlik Avına Dirençli Parolasız Çalışma Kitabı ile dağıtımı izleme#

Microsoft, Azure Monitor'da günlükleri (log) olan kuruluşların sunum sürecini izlemek için kullanabileceği bir Kimlik Avına Dirençli Parolasız Çalışma Kitabı (Phishing-Resistant Passwordless Workbook) yayınladı. Buna Entra yönetici merkezinden İzleme > Çalışma Kitapları (Monitoring > Workbooks) altından erişebilirsiniz:

Çalışma kitabının iki ana bölümü vardır:

9.1 Kayıt Hazırlığı Aşaması (Enrollment Readiness Phase)#

Oturum açma günlüklerini analiz etmek ve hangi kullanıcıların kayda hazır olduğunu, hangilerinin engellenebileceğini belirlemek için bu sekmeyi kullanın. İşletim sistemi platformuna (Windows, macOS, iOS, Android) ve kimlik bilgisi türüne (Authenticator Uygulaması Geçiş Anahtarı, FIDO2 Güvenlik Anahtarı, Sertifika Tabanlı Kimlik Doğrulaması) göre filtreleme yapabilirsiniz:

Çalışma kitabı şunları gösterir:

• Kayıt için Hazır Kullanıcı/Cihaz Çiftleri: seçilen kimlik bilgisi türünü kaydedebilen kullanıcılar
• Hazır Olmayan Kullanıcı/Cihaz Çiftleri: kayıt sorunları (örn. eski işletim sistemi sürümleri) yaşayabilecek kullanıcılar

İyileştirme eylemlerine (örn. işletim sistemi yükseltmeleri, cihaz değiştirmeleri veya alternatif kimlik bilgisi seçenekleri) ihtiyaç duyan kullanıcıların listelerini dışa aktarabilirsiniz.

9.2 Zorlama Hazırlığı Aşaması (Enforcement Readiness Phase)#

Kullanıcılar yalnızca kimlik avına dirençli kimlik doğrulamasına hazır olduğunda, Zorlama Hazırlığı (Enforcement Readiness) sekmesini kullanın. İlk olarak, kimlik avına dirençli MFA gerektiren Sadece Rapor (Report-Only) tabanlı bir Koşullu Erişim ilkesi oluşturun. Bu, oturum açma günlüklerini, zorlama (enforcement) aktif olsaydı erişimin engellenip engellenmeyeceği hakkındaki verilerle doldurur.

Gösterge paneli şunları gösterir:

• Kapsam dahilindeki Toplam kullanıcı
• Sadece Rapor Başarılı - zorlamayı geçecek kullanıcılar
• İlke Karşılanmadı - engellenecek kullanıcılar (bunları araştırın!)
• Cihaz Durumu, Cihaz Platformu ve İstemci Uygulaması dökümleri

Belirli kullanıcıların neden engelleneceğini araştırmak için İlave Veri Analizi (Further Data Analysis) sekmesini kullanın. Bu veriler, zorlamayı etkinleştirmeden önce düzeltme için hedeflenecek kullanıcıları belirlemenize yardımcı olur.

9.3 Yardım masası izleme ile dalga tabanlı sunum#

Microsoft, dağıtımların esnek tarih aralıklarıyla dalgalar halinde yürütülmesini önerir. Yardım masası çağrı/bilet hacmini bir sinyal olarak izleyin:

• Bilet hacmi artıyor: Dağıtımları, iletişimleri ve zorlama eylemlerini yavaşlatın
• Bilet hacmi düşüyor: Etkinlikleri tekrar hızlandırın

Her dalga için Microsoft Entra ID güvenlik grupları oluşturun ve grupları ilkelerinize kademeli olarak ekleyin. Bu, destek ekiplerinin bunalmasını önler.

10. Senkronize Geçiş Anahtarı pilot uygulama kontrol listesi#

Hedef Microsoft Authenticator bağımlılığı olmadan senkronize geçiş anahtarları ise, şu pilot uygulama duruşunu takip edin:

1. Senkronize geçiş anahtarlarını (önizleme) etkinleştirin Senkronize geçiş anahtarları (önizleme) adımlarını izleyin.

2. Geçiş Anahtarı Profillerini (önizleme) kullanın ve pilot grubu hedefleyin Geçiş Anahtarı Profillerinde açıklandığı gibi senkronize geçiş anahtarlarına izin veren bir profil oluşturun/atayın.

3. Onayı zorunlu kılmayın (en azından pilot grup için) Onayı zorunlu kılmak, Geçiş Anahtarları (FIDO2) kavramları belgelerine göre senkronize geçiş anahtarlarını hariç tutar.

4. Başlangıçta katı AAGUID izin listelerinden kaçının Akışı onaylamak için izin verici bir şekilde başlayın, ardından hangi sağlayıcılara izin vermek istediğinizi bildiğinizde kısıtlamaları sıkılaştırın. Bkz. Geçiş anahtarlarını etkinleştirme (FIDO2).

5. Koşullu Erişimin Microsoft Authenticator'ı zorlamadığını doğrulayın CA/kimlik doğrulama güçlerinin hedeflediğiniz geçiş anahtarı profiline hala izin verdiğinden emin olun (aksi takdirde Microsoft Authenticator bağımlılığı gibi görünür).

6. Kimlik modelini (üye veya konuk) doğrulayın Kullanıcılar konuk ise, profilleri ayarlamakla zaman harcamadan önce kiracı modelinizdeki beklenen desteklenebilirliği doğrulayın.

11. Sonuç#

Kurumsal geçiş anahtarı dağıtımı operasyonel olarak karmaşıktır, ancak ileriye giden yol iyi tanımlanmıştır. İşte yukarıda gündeme getirilen ana operasyonel sorularla uyumlu kilit cevaplar:

1. Cihaza bağlı ve senkronize geçiş anahtarları: Cihaza bağlı kimlik bilgileri (örn. Microsoft Authenticator, Windows Hello, YubiKeys, akıllı kartlar) kesinlikle tek bir cihaza bağlıdır ve AAL3'ü karşılar. Senkronize geçiş anahtarları (örn. iCloud Anahtar Zinciri, Google Şifre Yöneticisi) cihazlar arasında çalışır ve AAL2'yi karşılar. Çoğu kuruluşun her ikisine de ihtiyacı vardır: yöneticiler için donanım kimlik doğrulayıcıları (AAL3) ve daha geniş iş gücü için senkronize geçiş anahtarları (AAL2).

2. Yeni çalışanların başlatılması: İşe alım sırasındaki tavuk-yumurta sorununu çözmek için Geçici Erişim Geçişi (TAP) kullanın. Büyük ölçekli dağıtımlar için bunu Graph API üzerinden otomatikleştirin. Yüksek güvenceli kullanım senaryoları için, ilk katılımı Entra Doğrulanmış Kimlik (Verified ID) ve Face Check ile destekleyin.

3. Telefon değişimi kurtarma: Birden fazla kurtarma yöntemi sunun: Self-Servis Kurtarma Kiosku (başlatıcı cihaz olarak bir dizüstü bilgisayar kullanın), My Staff aracılığıyla Yönetici Destekli TAP ve uç durumlar için Verified ID (Doğrulanmış Kimlik) ile SSAR (Self-Servis Hesap Kurtarma).

4. Yapılandırma hataları: En sık yapılan hatalar arasında onayın (attestation) genel olarak zorunlu kılınması, senkronize geçiş anahtarları için önizleme özelliklerinin etkinleştirilmemesi, aşırı katı AAGUID izin listeleri ve döngüsel bağımlılıklar yaratan Koşullu Erişim (CA) ilkeleri yer alır.

5. B2B konukları: B2B konukları için geçiş anahtarlarını doğrudan kiracınızda kaydetmekten kaçının. Bunun yerine, konuğun ana kiracısından gelen kimlik bilgilerini doğrulamak için Kiracılar Arası Erişim Güvenini (Cross-Tenant Access Trust) etkinleştirin.

6. Donanım anahtarları ile mobil geçiş anahtarları: Donanım güvenlik anahtarları belirli yüksek güvenlikli roller (yöneticiler, paylaşılan iş istasyonları) için gereklidir ancak büyük ölçekte lojistik engeller sunar. Mobil geçiş anahtarları genellikle iş gücü için daha pratiktir.

7. Windows ile birlikte macOS: Windows dağıtımlarına paralel olarak macOS'ta geçiş anahtarı desteğini etkinleştirmek için JAMF/MDM ile Platform SSO kullanın. Platforma özgü iş akışları için plan yapın.

8. Proaktif önlemler: Etkin olmayan cihazları belirlemek ve kullanıcıları kilitlenme gerçekleşmeden önce düzeltme yapmaya teşvik etmek için Intune kullanın. Erken benimsemeyi teşvik etmek için geçiş anahtarı kaydını Intune kaydı için bir önkoşul yapmayı düşünün. Başlatıcı cihazlar olarak dizüstü bilgisayarları kullanan self-servis bir kurtarma iş akışı oluşturun.

Teknoloji hazır. Asıl zorluk operasyonel yürütmededir. Kurtarma planlaması sonradan düşünülen bir şey değil, ilk günden itibaren ayrılmaz bir parça olmalıdır. Altyapı sağlamlaştığında, geçiş anahtarlarının iş gücünüz genelinde birincil kimlik doğrulama yöntemi olmasını sağlamak için geçiş anahtarı girişinin benimsenmesini optimize etmeye odaklanın.

Corbado Hakkında

Corbado, büyük ölçekte tüketici kimlik doğrulaması yöneten CIAM ekipleri için Passkey Intelligence Platform'tur. IDP loglarının ve genel analytics araçlarının göremediğini görmenizi sağlarız: hangi cihazların, OS sürümlerinin, tarayıcıların ve credential manager'ların passkey desteklediğini; kayıtların neden girişe dönüşmediğini; WebAuthn akışının nerede başarısız olduğunu; bir OS ya da tarayıcı güncellemesinin girişi sessizce ne zaman bozduğunu — hem de Okta, Auth0, Ping, Cognito veya kendi IDP'nizi değiştirmeden. İki ürün: Corbado Observe, passkey'ler ve diğer tüm giriş yöntemleri için observability sağlar. Corbado Connect, analytics entegre managed passkey'ler sunar (IDP'nizin yanında). VicRoads, Corbado ile 5M+ kullanıcı için passkey çalıştırıyor (%80+ passkey aktivasyonu). Bir Passkey uzmanıyla görüşün →

Sıkça Sorulan Sorular (SSS)#

Koşullu Erişim'de kimlik avına dirençli MFA'yı etkinleştirmek neden tüm kullanıcılarımı kilitliyor?#

Tüm bulut uygulamaları için kimlik avına dirençli MFA gerektiren bir Koşullu Erişim (Conditional Access) ilkesi oluşturmak, henüz bir geçiş anahtarı kaydetmemiş olan tüm kullanıcıları anında engeller, buna Güvenlik Bilgileri kayıt sayfasına erişim de dahildir. 'Güvenlik Bilgilerini Kaydet' paradoksu olarak adlandırılan bu döngüsel bağımlılık, ilk kayıtlarını tamamlayabilmeleri için uygulamayı zorunlu hale getirmeden önce etkilenen kullanıcılara bir Geçici Erişim Geçişi (Temporary Access Pass) vermeniz gerektiği anlamına gelir.

Kiracım kimlik avına dirençli MFA gerektirdiğinde B2B konuk kullanıcıları nasıl idare ederim?#

Entra ID, konuk kullanıcıların bir kaynak kiracısına FIDO2 anahtarları kaydetmesini desteklemez, bu nedenle konuklar için geçiş anahtarı kaydını zorunlu kılmaya çalışmak başarısız olur. Doğru düzeltme, Dış Kimlikler altındaki Kiracılar Arası Erişim Ayarlarını, konuğun kendi (ana) kiracısından gelen MFA taleplerine güvenecek şekilde yapılandırmaktır; bu, kendi kuruluşlarında kullandıkları bir YubiKey'in kiracınızda herhangi bir kayıt olmadan kimlik avına dirençli MFA gereksiniminizi karşıladığı anlamına gelir.

Geçiş anahtarıyla oturum açarken cihazlar arası QR kod kimlik doğrulamasının sessizce başarısız olmasına ne sebep olur?#

Cihazlar Arası Kimlik Doğrulaması (Cross-Device Authentication), BLE yakınlık el sıkışmasını tamamlamak için hem bilgisayarda hem de telefonda Bluetooth'un etkinleştirilmesini gerektirir, bu nedenle Bluetooth'u devre dışı bırakan herhangi bir kurumsal ilke akışı tamamen bozar. Akış ayrıca cable.auth.com adresine bir WebSocket bağlantısı kullanır; bu, güvenlik duvarları veya Zscaler yapılandırmaları tarafından sıkça engellenir ve QR kod taramasının net bir hata mesajı olmadan askıda kalmasına veya başarısız olmasına neden olur.

Canlı zorlamayı (enforcement) açmadan önce hangi çalışanların kimlik avına dirençli MFA'ya hazır olduğunu nasıl izlerim?#

Entra yönetici merkezi altındaki İzleme > Çalışma Kitapları yoluyla erişilebilen Microsoft'un Kimlik Avına Dirençli Parolasız Çalışma Kitabı, hangi kullanıcı/cihaz çiftlerinin platform ve kimlik bilgisi türüne göre kayıt yapabileceğini gösteren bir Kayıt Hazırlığı (Enrollment Readiness) görünümü sunar. Zorlama hazırlığı için, kimlik avına dirençli MFA gerektiren sadece raporlamaya yönelik (report-only) bir Koşullu Erişim ilkesi oluşturun; böylece oturum açma günlükleri, canlı zorlamayı etkinleştirmeden önce hangi kullanıcıların engelleneceğini ortaya çıkarır.

Yeni bir telefon alan ve geçiş anahtarına erişimini kaybeden çalışanlar için en iyi kurtarma stratejisi nedir?#

Önerilen yaklaşım katmanlıdır: WHfB güvenliğine sahip bir dizüstü bilgisayar kullanan Self-Servis Kurtarma Kiosku, Graph API aracılığıyla bir Geçici Erişim Geçişi oluşturur ve yardım masası katılımı olmadan çoğu durumu kapsar. Dizüstü bilgisayarı olmayan kullanıcılar için My Staff portalı aracılığıyla Yönetici Destekli TAP, kurtarmayı doğrudan yöneticilere devreder ve Entra Doğrulanmış Kimlik biyometrik Face Check ile Self-Servis Hesap Kurtarma, tam kimlik yeniden doğrulaması gerektiren uç durumları ele alır.

Daha fazla okuma#

Kurumsal FIDO2/geçiş anahtarı dağıtımları hakkında derinlemesine incelemeler için, Microsoft Entra kimlik doğrulaması hakkında düzenli olarak pratik rehberlik yayınlayan Merill Fernando ve Jan Bakker gibi uzmanları takip edin.