Yöneticilerle başlayın ve onlara Conditional Access üzerinden yerleşik Phishing-resistant MFA kimlik doğrulama gücünü (authentication strength) zorunlu kılın. Bu güç yalnızca Windows Hello for Business veya bir platform kimlik bilgisine, bir FIDO2 güvenlik anahtarına ya da Entra sertifika tabanlı kimlik doğrulamaya (multifactor) izin verir. İlkenin kapsadığı kaynaklarda bu hesaplar için SMS ve push onayları artık ilkeyi karşılamaz. Parola istemi ise yerinde kalır (bkz. Neler ters gidebilir).
Neden önce yöneticiler
Microsoft'un kimlik doğrulama genel bakışı, SMS, e-posta OTP veya authenticator uygulamalarına dayalı MFA'nın uzaktan phishing'e açık olduğunu belirtiyor. Saldırganlar bu yöntemde kullanıcının cihazına dokunmadan parolaları veya tek kullanımlık kodları çalabiliyor. Microsoft bunların yerine Windows Hello for Business, passkey (FIDO2), FIDO2 güvenlik anahtarı veya sertifika tabanlı kimlik doğrulamayı öneriyor. Çalınan bir kodun en pahalıya mal olduğu yer yönetici hesabıdır ve küçük bir ekibin taşıması gereken hesap sayısı da yalnızca bir avuçtur.
Ortadaki yerleşik seçenek konusunda dikkatli olun. Authentication strengths dokümantasyonuna göre Passwordless MFA gücü, Microsoft Authenticator ile telefondan oturum açmayı da içerir. Phishing-resistant gücü içermez.
Tenant'ı hazırlayın
Passkey (FIDO2) tüm Entra ID sürümlerinde ek lisans gerektirmeden kullanılabilir. Conditional Access için Entra ID P1 gerekir.
Ayarlar Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2) altında yer alır. En az Authentication Policy Administrator rolüne ihtiyacınız var. Üç ayrıntı önemlidir:
- Passkey profillerine geçiş tek yönlüdür. Sonradan geri dönemezsiniz ve mevcut genel ayarlarınız bir Default profile taşınır. Default dahil en fazla üç profil desteklenir.
- Allow self-service set up Yes olmalıdır, aksi halde kullanıcılar Security info üzerinden passkey kaydedemez. Bu ayar profil bazlı değil, genel bir ayardır.
- Kayıt için son beş dakika içinde tamamlanmış bir MFA gerekir.
Yöneticiler için dokümantasyonun kendi örneği, passkey türü Device-bound ve Enforce attestation değeri Yes olan bir profildir. Device-bound, özel anahtarın bir güvenlik anahtarı veya Microsoft Authenticator gibi tek bir fiziksel cihazdan asla çıkmadığı anlamına gelir. Senkronize passkey'ler attestation'ı desteklemez ve Microsoft bunları phishing'e dayanıklı ama attestation'sız diğer authenticator'larla aynı güvenlik düzeyinde değerlendirmenizi söylüyor. NIST metni, en yüksek seviyesi olan AAL3'te dışa aktarılamayan anahtara sahip, phishing'e dayanıklı bir authenticator şart koşar. Bu nedenle Entra'nın sunduğu seçenekler arasında en yakın karşılık device-bound anahtarlardır.
Authentication strength ile zorunlu kılın
Bir Conditional Access ilkesi oluşturun, hedef olarak yönetici rollerinizi veya grubunuzu seçin ve grant controls altında Require authentication strength seçeneğini belirleyin. Phishing-resistant MFA'yı seçin. Yerleşik MFA gücü bu denetime eşdeğer olduğu için bunu aynı ilkede Require multifactor authentication ile birleştiremezsiniz.
Yerleşik güçler düzenlenemez ve yeni yöntemler çıktıkça Microsoft bunları günceller. İzin verilen yöntemlerin sabit bir kümesine ihtiyacınız varsa özel bir güç oluşturun.
SMS'i herkes için kapatmak zorunda değilsiniz. Güç, Authentication methods ilkesinin üzerinde durur ve bir senaryo için onu daraltır. Çalışanlar olağan kaynaklar için parola ve push onayını kullanmaya devam edebilirken yöneticiler daha sıkı ilkeye tabi tutulur.
Neler ters gidebilir
Yönetici yine ilk olarak parolasını girer. Conditional Access ilk kimlik doğrulamadan sonra değerlendirilir, dolayısıyla güç ancak o noktada phishing'e dayanıklı bir yöntem ister.
Bir kullanıcı birincil yöntem olarak parolayla oturum açarsa ve güç Windows Hello for Business gerektiriyorsa, kendisine bu yöntem sorulmaz. Oturumu yeniden başlatması, Sign-in options'ı seçmesi ve gereken yöntemi seçmesi gerekir. Bunu yönetici talimatlarınıza ekleyin.
İki denetim farklı anlarda devreye girer. Enforce attestation yalnızca kayıt sırasında uygulanır. Bu yüzden attestation olmadan kaydedilmiş bir passkey, ayarı açtığınızda oturum açarken engellenmez. Sonrasında yönetici anahtarlarını yeniden kaydedin. AAGUID'e göre anahtar kısıtlamaları hem kayıtta hem oturum açmada geçerlidir. Daha önce izin verilen bir AAGUID'i kaldırırsanız, o modeli kaydeden herkes dışarıda kalır.
Profil çakışması izin vericidir ve passkey ilkesi düzeyinde hem kaydı hem oturum açmayı etkiler. Bir kullanıcı birden fazla profilin kapsamına girdiğinde, bir passkey, belirli bir sıra gözetilmeksizin en az bir profili tamamen karşılıyorsa kabul edilir. Dolayısıyla "tüm senkronize veya device-bound" grubunda da yer alan bir yönetici, passkey ilkesi açısından senkronize bir passkey kaydedip kullanabilir. Kaynaklar, Conditional Access gücünün bunu kabul edip etmediğini belirtmiyor, bu yüzden bu durumu test edin.
Bir sonraki adım olarak, geçişten sonra Enable and target altındaki Default profile'ı kontrol edin. Hedefi All users ise ve senkronize passkey'lere izin veriyorsa, hedefi yöneticilerinizi içermeyen gruplara çevirin. Yöneticileri bunun yerine Passkey (FIDO2) ilkesinden hariç tutmayın: hariç tutulan bir grup FIDO2 kaydından ve oturum açmadan tamamen engellenir ve bu, her türlü dahil etmeyi geçersiz kılar.
Oturum açma sıklığı (sign-in frequency) ile güç farklı zamanlarda karşılanabilir. Passkey gücü ve 1 saatlik oturum açma sıklığıyla, 24 saat önceki bir passkey ile oturum açma artı bugünkü bir Windows Hello cihaz kilidi açma, ikisini de karşılar. Yöneticiler için kısa sıklıklara güveniyorsanız bu durumu test edin.
Temporary Access Pass, MFA gücünde yer alır ancak phishing'e dayanıklı güçte yer almaz. Kaynakların belirtmediği, bize ait bir çıkarım: Temporary Access Pass üzerine kurulu bir kurtarma veya ilk kurulum akışı ilkeyi karşılamaz, bu yüzden bir istisna ya da ayrı bir ilke gerektirir. Bunu olay anında değil, zorunlu kılmadan önce karara bağlayın.
Nereden başlamalı
- Yönetici rolü olan tüm hesapları listeleyin ve pilot grup için iki veya üçünü seçin.
- Passkey profillerine geçin, Default profile'ın hedefini kontrol edin, Device-bound ve Enforce attestation değeri Yes olan bir yönetici profili oluşturun ve bunu yalnızca pilot gruba hedefleyin.
- Pilot yönetici başına en az iki authenticator kaydedin, örneğin bir güvenlik anahtarı ve Windows Hello, ve her biriyle oturum açmanın çalıştığını doğrulayın.
- Pilot grup için Phishing-resistant MFA gücüyle Conditional Access ilkesini oluşturun. Genel uygulama olarak (burada kullanılan Microsoft sayfaları acil erişim (break-glass) hesaplarını kapsamıyor), acil erişim hesaplarını hariç tutun ve her birine kendi FIDO2 anahtarını verin.
- Tüm yöneticilere genişletin. Attestation zorunlu kılınmadan önce kaydedilmiş passkey'leri, ancak her yönetici attestation'lı bir anahtarı yeniden kaydettikten sonra kaldırın, böylece kimse dışarıda kalmaz.
- Sonucu test ettirin. Danışmanlık ekibimiz ilkeyi inceleyebilir, bir sızma testi ise herhangi bir yönetici yolunun hâlâ daha zayıf bir yöntemi kabul edip etmediğini gösterir.
