Phishing’e Dayanıklı MFA: FIDO2 ve Passkey’e Geçiş Planı

MFA açık bir hesap, MFA açıkken ele geçirilebilir. Saldırgan kullanıcıyı sahte oturum açma sayfasına çeker, parolayı ve tek kullanımlık kodu gerçek servise anlık olarak aktarır; ikinci faktör doğrulanır, oturum çerezi saldırganın eline geçer. Elinizdeki MFA yöntemleri bu senaryoda ne kadar dayanır, FIDO2 güvenlik anahtarı, Windows Hello for Business ve passkey arasında nasıl seçim yaparsınız, Microsoft Entra ID’de phishing’e dayanıklı MFA’ya kullanıcıları kilitlemeden nasıl geçersiniz — sırasıyla bunlara bakıyoruz.

Hangi MFA yöntemi hangi saldırıda düşer

“MFA var” cevabı, hangi yöntemin kullanıldığını söylemez. Belirleyici soru şudur: saldırgan kullanıcıyı kandırıp ikinci faktörü kendi oturumunda kullanabiliyor mu?

Yöntem	Saldırı karşısındaki durum	Phishing’e dayanıklı mı?
SMS / sesli arama	SIM değiştirme, kodun sahte sayfaya girilmesi	Hayır
TOTP (uygulama kodu)	Kod sahte sayfaya girilir, AiTM ile aktarılır	Hayır
Push bildirimi	MFA yorgunluğu, AiTM sırasında onay	Hayır (numara eşleştirme riski azaltır)
FIDO2 / passkey	Origin’e bağlı imza; sahte alan adında çalışmaz	Evet
Windows Hello for Business	TPM’e bağlı anahtar, cihaz dışına çıkmaz	Evet
Sertifika tabanlı kimlik doğrulama	Özel anahtar akıllı kartta veya cihazda	Evet (çok faktörlü yapılandırıldığında)

Adversary-in-the-middle (AiTM) saldırısında sahte sayfa, kullanıcı ile gerçek oturum açma servisi arasında ters vekil sunucu (reverse proxy) gibi çalışır. Kullanıcı parolasını ve kodunu girer, gerçek servis MFA’yı başarıyla tamamlar, dönen oturum çerezini saldırgan kopyalar. Bundan sonra ne parolaya ne koda ihtiyacı kalır. MFA yorgunluğu farklı işler: parola zaten saldırgandadır, art arda push isteği gönderilir ve kullanıcının birine “Onayla” demesi beklenir. Microsoft Authenticator’daki numara eşleştirme bu ikinci senaryoyu ciddi ölçüde zorlaştırır. AiTM’i durdurmaz. Kullanıcı gerçek bir oturum açtığını sandığı için ekrandaki numarayı kendi eliyle girer.

Olay incelemelerinde sık rastlanan tablo şudur: oturum açma günlüğünde MFA “başarılı” görünür, kullanıcı da “kodu ben girdim” der. İkisi de doğrudur. Sorun yöntemin kendisindedir.

Phishing’e dayanıklılık protokolden gelir

FIDO2, W3C WebAuthn ve FIDO Alliance’ın CTAP protokollerinden oluşur. Kayıt sırasında doğrulayıcı (güvenlik anahtarı, telefon veya TPM) her hizmet için ayrı bir anahtar çifti üretir; özel anahtar doğrulayıcıdan çıkmaz, hizmete yalnızca açık anahtar kaydedilir. Oturum açarken hizmet bir challenge gönderir, doğrulayıcı bunu imzalar. İşin düğüm noktası, imzanın relying party kimliğine (RP ID), yani alan adına bağlı olmasıdır. Tarayıcı, isteğin geldiği origin’i doğrulayıcıya kendisi iletir; login.microsoftonline.com için kaydedilmiş bir kimlik bilgisi, benzer görünen sahte alan adında hiç sunulmaz. Kullanıcı sahte sayfayı fark etmese bile imza üretilemez.

Yani koruma kullanıcının dikkatine bağlı değildir. Protokol bunu kendisi yapar.

İki sınırı baştan bilin. Birincisi: cihaza bulaşmış zararlı yazılımın, kimlik doğrulaması bittikten sonra oturum belirteçlerini çalması FIDO2’nin kapsamı dışındadır; buna karşı uç nokta güvenliği, uyumlu cihaz koşulu ve belirteç koruması gibi oturum kontrolleri gerekir. İkincisi kayıt ve kurtarma yoludur: kullanıcı yeni anahtarını zayıf bir yöntemle kaydedebiliyorsa, saldırgan da aynı kapıdan kendi anahtarını ekler.

FIDO2 anahtarı, Windows Hello ve passkey: hangisi kime

Üç seçenek aynı kriptografik temeli paylaşır; dağıtım, maliyet ve günlük kullanım farklıdır. Kurumsal siber güvenlik tasarımlarında tek yöntem yerine kullanıcı profiline göre bir karma kurmak genelde daha gerçekçidir.

Kriter	FIDO2 güvenlik anahtarı	Windows Hello for Business	Authenticator’da passkey
Anahtarın yeri	Donanım anahtarı (USB/NFC)	Cihazdaki TPM	Telefon (cihaza bağlı)
Ek donanım	Gerekir	Gerekmez (TPM 2.0 önerilir)	Kurumsal veya kişisel telefon
Paylaşımlı cihaz	Uygun	Uygun değil	Kısmen
Başka cihazda oturum	Anahtar takılarak	Yalnız kayıtlı cihazda	Bluetooth yakınlığı ile çapraz cihaz
Tipik kullanıcı	Yöneticiler, üretim, vardiya	Kurumsal dizüstü kullanıcıları	Mobil ağırlıklı kullanıcılar

FIDO2 güvenlik anahtarı yöneticiler ve acil durum hesapları için en net seçenektir: cihazdan bağımsızdır, kaybolunca iptal edilir, kopyalanamaz. Entra ID’de anahtar modelleri AAGUID ile kısıtlanabilir; böylece yalnız kurumun satın aldığı ve sertifikalı modeller kayıt olur. Kullanıcının kendi aldığı ucuz bir anahtar envantere sızmaz.

Windows Hello for Business kullanıcı açısından en az sürtünmeli seçenektir; PIN veya biyometri yalnızca cihazdaki TPM anahtarını açar, ağ üzerinden gitmez. Hibrit ortamlarda şirket içi kaynaklara tek oturumla erişim için Microsoft’un önerdiği dağıtım modeli cloud Kerberos trust’tır; key trust ve certificate trust modelleri ek PKI veya etki alanı denetleyicisi gereklilikleri getirir. Sahada en sık takıldığımız yer burasıdır: eski bir dağıtım rehberine bakılarak certificate trust seçilir, PKI yükü gereksiz yere omuza alınır.

Passkey, FIDO2 kimlik bilgisinin genel adıdır. Microsoft Authenticator’daki cihaza bağlı passkey, ek donanım almadan telefonu phishing’e dayanıklı bir doğrulayıcıya çevirir. Bulut hesabıyla senkronize edilen passkey’lerin Entra ID’deki destek durumu değişmektedir; politikaya almadan önce Microsoft’un güncel dokümantasyonundan doğrulayın ve anahtarın kişisel bir bulut hesabına çıkmasının risk modelinize uyup uymadığına karar verin.

Entra ID’de authentication strength politikası

Bir yöntemi etkinleştirmek, onu zorunlu kılmaz. Entra ID’de iki ayrı katman vardır. Kimlik doğrulama yöntemleri politikası hangi yöntemin hangi grup için kayda ve kullanıma açık olduğunu belirler. Authentication strength ise Conditional Access içinde, belirli bir erişim için hangi yöntem birleşimlerinin kabul edileceğini tanımlar. Yerleşik üç güç seviyesi vardır: Multifactor authentication strength, Passwordless MFA strength ve Phishing-resistant MFA strength. Sonuncusu Windows Hello for Business, FIDO2/passkey ve çok faktörlü sertifika tabanlı kimlik doğrulamayı kabul eder. Biri olmadan diğeri işe yaramaz.

1. Entra yönetim merkezinde Authentication methods > Policies altında Passkey (FIDO2) yöntemini hedef grup için açın; gerekiyorsa attestation zorunluluğunu ve AAGUID kısıtlamasını etkinleştirin.
2. Temporary Access Pass’i (TAP) yalnız kayıt ve kurtarma grubuna açın.
3. Yeni bir Conditional Access politikası oluşturun: hedef kullanıcılar pilot grup, hedef kaynak tüm kaynaklar ya da önce yönetim portalları, erişim denetimi Require authentication strength > Phishing-resistant MFA.
4. Politikayı önce Report-only modunda çalıştırın; oturum açma günlüklerinde koşulu karşılayamayan kullanıcıları izleyin.
5. Acil durum hesaplarını politikadan hariç tutun, ama bu hesapları da FIDO2 anahtarıyla koruyun.

Politika çerçevesinin genel tasarımı, hariç tutma ve adlandırma kuralları için Conditional Access planlama rehberine bakın. Yerleşik güç seviyelerinin tam yöntem listesi Microsoft’un authentication strengths dokümantasyonunda yer alır.

Zorunluluğu açmadan önce mevcut kayıt durumunu ölçün. Kim hazır, kim değil — tahmin değil, rapor. Microsoft Graph PowerShell ile kullanıcı bazında kayıtlı yöntemler şöyle çıkarılır:

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

# Kullanıcı bazında kayıtlı yöntemler
$rapor = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$rapor | Select-Object UserPrincipalName, IsAdmin,
    @{n='Yontemler'; e={$_.MethodsRegistered -join ','}} |
    Export-Csv .\mfa-kayit-durumu.csv -NoTypeInformation -Encoding UTF8

# Yöneticiler arasında passkey veya WHfB kaydı olmayanlar
$rapor | Where-Object { $_.IsAdmin -and
    -not ($_.MethodsRegistered -match 'passKeyDeviceBound|fido2|windowsHelloForBusiness') } |
    Select-Object UserPrincipalName

MethodsRegistered alanında dönen değer adları API sürümüne göre farklılık gösterebilir; filtreyi kendi kiracınızdan aldığınız örnek çıktıya göre ayarlayın. İlk çalıştırmada filtre boş dönüyorsa önce ham çıktıya bakın; çoğu zaman sorun değer adının yazımıdır.

Kayıt, kayıp anahtar ve kurtarma

Phishing’e dayanıklı yöntem, en zayıf kayıt yolu kadar güçlüdür. Kullanıcı yeni passkey’i yalnız SMS ile doğrulanmış bir oturumdan kaydedebiliyorsa, çalınmış bir SMS koduyla saldırgan da kendi anahtarını ekler. Kayıt ve kurtarma bu yüzden ayrı bir süreç olarak tasarlanır:

• İlk kayıt: Kimliği yardım masasınca doğrulanmış kullanıcıya kısa ömürlü, tek kullanımlık TAP verilir; kullanıcı TAP ile oturum açıp passkey veya WHfB kaydını yapar. TAP ömrü yapılandırılabilir; kayıt için kısa tutun.
• Kimlik doğrulama: Yardım masasının TAP vermeden önce uygulayacağı doğrulama adımı yazılı olmalı (ör. yöneticiden geri arama, görüntülü doğrulama). Sosyal mühendislik tam olarak bu adımı hedefler.
• İkinci doğrulayıcı: Yöneticilere iki güvenlik anahtarı kaydedin, biri güvenli yerde yedek dursun; kayıpta yardım masasına bağımlılık azalır.
• Kayıp anahtar: Kayıp anahtar kullanıcının kayıtlı yöntemlerinden silinir, aktif oturumlar iptal edilir (Revoke-MgUserSignInSession), yeniden kayıt TAP ile yapılır.
• Kayıt politikası: “Register security information” kullanıcı eylemi için ayrı bir Conditional Access politikası, kaydın yalnız güvenilir konumdan, uyumlu cihazdan ya da TAP ile yapılmasını şart koşabilir.

Aşamalı geçiş: yöneticilerden başlayın

Geçiş, riskin en yüksek olduğu hesaplardan başlar; her aşama bir öncekinden gelen destek verisiyle planlanır. Herkesi aynı gün zorunluluğa almak, pazartesi sabahı yardım masasını kilitler.

Aşama	Kapsam	Zorunluluk	Çıkış kriteri
0. Hazırlık	Yöntem politikası, TAP, kayıt politikası	Yok	Yardım masası prosedürü hazır
1. Yöneticiler	Entra rolleri, acil durum hesapları	Yönetim portalları ve tüm kaynaklar	Tüm yöneticilerde 2 doğrulayıcı
2. Hassas roller	Finans, İK, üst yönetim, asistanlar	Tüm kaynaklar	Report-only’de başarısız oturum kalmadı
3. Genel kullanıcı	Departman bazlı dalgalar	Tüm kaynaklar	Zayıf yöntemler kaldırıldı
4. İstisnalar	Paylaşımlı cihaz, eski uygulama	Telafi edici kontrol	İstisna listesi sahipli ve süreli

Yönetici hesaplarında geçişi tam zamanında yetkilendirmeyle birlikte ele alın: rol aktivasyonunda phishing’e dayanıklı yöntem istemek, Entra ID PIM yapılandırması ile birleşince kalıcı ayrıcalık ve zayıf MFA riskini birlikte kapatır. Finans ve üst yönetim aşamasında e-posta tarafındaki kimlik avı kontrollerini de gözden geçirin; bu konu kurumsal e-postada phishing riskini azaltma yazısında anlatılıyor.

Sahada en sık gördüğümüz hatalar:

• Authentication strength politikasını doğrudan “On” modunda tüm kullanıcılara açmak, report-only aşamasını atlamak.
• Eski protokollerle (IMAP, POP, SMTP AUTH) oturum açan uygulamaları envantere almamak; bunlar FIDO2 kullanamaz, ayrıca engellenmeleri gerekir.
• Paylaşımlı üretim terminallerinde WHfB planlamak; bu senaryoda güvenlik anahtarı daha uygundur.
• Kayıt sürecini SMS ile korumaya devam etmek.
• Risk tabanlı politikalar devreye girmeden geçişi “bitti” saymak; anormal oturumlar için Entra ID Protection risk politikaları tamamlayıcıdır.

Ölçüm için oturum açma günlüklerinde Authentication details alanını izleyin: zorunlu gruplarda başarılı oturumların tamamı phishing’e dayanıklı yöntemle yapılmalı, zayıf yönteme düşen oturum kalmamalı, istisna listesi her çeyrekte gözden geçirilmeli. İstisna listesinin sahibi yoksa liste büyür. Kimlik doğrulama tasarımını erişim süreçlerinin geneliyle birlikte ele almak isterseniz kimlik ve erişim yönetimi hizmetimizi inceleyebilirsiniz; Microsoft 365 kiracısının bütününe yönelik kontroller Microsoft 365 güvenliği kapsamında ele alınır.

Sık sorulan sorular

Numara eşleştirmeli push bildirimi phishing’e dayanıklı sayılır mı?

Hayır. Numara eşleştirme MFA yorgunluğu saldırısını zorlaştırır, ama AiTM saldırısında kullanıcı gerçek bir oturum açtığını sanarak numarayı kendisi girer ve oturum çerezi yine çalınır. Phishing’e dayanıklılık için kimlik bilgisinin alan adına bağlı olması gerekir; bunu FIDO2, Windows Hello for Business ve sertifika tabanlı kimlik doğrulama sağlar.

Passkey ile FIDO2 güvenlik anahtarı arasındaki fark nedir?

İkisi de FIDO2 kimlik bilgisidir. Güvenlik anahtarı ayrı bir donanımdır ve kimlik bilgisi o donanımdan çıkmaz. Passkey ise telefon veya bilgisayar gibi bir cihazda saklanan kimlik bilgisidir; cihaza bağlı olabilir ya da bir bulut hesabıyla senkronize edilebilir. Kurum politikasında hangi türün kabul edileceğini ayrıca belirleyin.

Kullanıcı güvenlik anahtarını kaybederse ne yapılmalı?

Kayıp anahtar kullanıcının kayıtlı yöntemlerinden silinir, aktif oturumlar iptal edilir, kimliği yardım masasınca doğrulanan kullanıcıya kısa ömürlü bir Temporary Access Pass verilip yeni doğrulayıcı kaydettirilir. Yöneticilere baştan ikinci bir yedek anahtar kaydetmek bu süreci kısaltır.

Acil durum hesapları da FIDO2 kullanmalı mı?

Evet. Acil durum hesapları genellikle Conditional Access politikalarından hariç tutulur; bu yüzden kendi kimlik doğrulamaları güçlü olmalıdır. Ayrı ve güvenli yerde saklanan FIDO2 anahtarları hem politika dışlamasının riskini azaltır hem de Microsoft’un yönetim portalları için getirdiği MFA zorunluluğunu karşılar.