MFA artık opsiyonel değil — ama kontrol dışına taşmak zorunda da değil
Parola tek başına artık güvenli bir sınır değildir. Kimlik bilgileri phishing ile çalınır, farklı servislerde yeniden kullanılır, sızıntı listelerinde satılır ve açık giriş ekranlarında otomatik olarak denenir. Bu yüzden ikinci faktör, modern güvenlik mimarisinin temel gereksinimi hâline gelmiştir.
Ancak MFA eklemek, her uygulamanın önüne ayrı bir doğrulama servisi koymak veya kimlik doğrulamanın en kritik anını tamamen üçüncü taraf bir buluta taşımak anlamına gelmemelidir. Kullanıcı başına sürekli lisans maliyeti, dış servis bağımlılığı, farklı yönetim panelleri ve parçalı politika yapısı zamanla güvenliği sadeleştirmek yerine karmaşıklaştırır.
Daha büyük sorun ise tek tip MFA yaklaşımıdır. Her uygulama aynı riski taşımaz, her kullanıcı aynı bağlamdan erişmez, her oturum aynı güven seviyesinde başlamaz. Bir kurum wiki'si için TOTP yeterli olabilir; production sunucuları ve domain controller erişimi her girişte TOTP istemeli ve güvenilir cihaz kısayoluna izin vermemelidir. Düşük riskli bir intranet uygulaması ise her girişte kullanıcıyı gereksiz kod ekranlarıyla yavaşlatmamalıdır.
MFA'nın görevi kullanıcıya sürekli engel çıkarmak değil, risk yükseldiğinde güven seviyesini yükseltmektir. Bunun için doğrulama kararları; uygulama, kullanıcı grubu, cihaz durumu, lokasyon, oturum riski ve erişilen varlığın hassasiyetine göre verilmelidir.
MFA ayrı bir bulut bağımlılığı değil; kurumun kendi erişim politikasının yerel, kademeli ve denetlenebilir bir parçası olmalıdır.
Yaklaşımımız
Tek bir politika motoru altında üç faktör türü — hepsi zaten sahip olduğunuz platformda çalışır.
Üç yöntem, tek politika motoru
TOTP, SMS ve e-posta OTP'nin tamamı aynı MFA yapılandırma modeli ile çalışır. Yöneticiler hangi yöntemlerin genel olarak mevcut olacağını, bir servis için hangilerinin zorunlu olduğunu ve hangilerini kullanıcının seçebileceğini — ayrı satıcı konsollarına girmeden ve kullanıcı başına MFA ücreti ödemeden — tek yerden belirler.
MFA politikası servis bazlıdır, her şeye tek duvar değil
Her servis veya servis grubu kendi MFA gereksinimini bildirir: MFA yok, herhangi bir faktör, belirli bir yöntem veya zincirlenmiş faktör kombinasyonu. Düşük riskli intranet uygulamaları sürtünmesiz kalır; yüksek riskli yönetici arayüzleri daha güçlü gereksinimleri dayatır; aradakiler güvende olmak için aşırı korunmak zorunda kalmaz.
Tekrarlanan erişim için güvenilir cihaz kısayolu
Politika izin verdiğinde kullanıcı MFA anında cihazını güvenilir olarak işaretleyebilir ve yapılandırılabilir bir süre boyunca — varsayılan 30 gün — ikinci faktörü atlayabilir. Güven cihaza bağlıdır, ağa değil; ve hem yönetici konsolundan hem de kullanıcının kendi profil sayfasından iptal edilebilir.
Bağlam değiştiğinde oturum içi adım-yükseltme MFA
Sürekli güven değerlendirmesi her aktif oturumu izler. Operatörün IP'si ülke değiştirirse, uç nokta güven skoru düşerse veya davranış anomalize olursa gateway, kullanıcıyı giriş sayfasından baştan başlatmadan taze bir MFA challenge'ı dayatabilir.
Yetenekler
Üç faktör teslim kanalı, artı etraflarındaki politika ve kurtarma araçları.
TOTP authenticator uygulamaları — RFC 6238, QR ile kayıt ve şifreli gizli anahtar deposu
Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, Yubico Authenticator, FreeOTP ve diğer her RFC 6238 uygulamasıyla uyumlu standart zaman tabanlı tek kullanımlık parolalar. Kayıt sunucu tarafında render edilen bir QR kodu üzerinden çalışır; paylaşılan gizli anahtar şifrelenerek saklanır, log'a düşmez ve yönetici konsolunda hiçbir zaman gösterilmez. Algoritma, basamak sayısı ve geçerlilik penceresi profil bazında yapılandırılır.
Kendi SMS gateway'iniz üzerinden SMS OTP
Zaten kullandığınız HTTP yetenekli SMS sağlayıcısı üzerinden SMS ile teslim edilen OTP kodları — Twilio, Vonage, Infobip, MessageBird, yerel operatör API'si veya kendi iç gateway'iniz. Platform mesajı oluşturur, yapılandırılmış HTTP endpoint'ine çağrı yapar ve teslimi takip eder; kullanıcılarınız ile ihtiyaç duydukları kodlar arasında bir SMS bayisi durmaz.
Alıcı maskelemeli e-posta OTP
Kullanıcının doğrulanmış e-posta adresine teslim edilen OTP kodları. Giriş sayfası adresi yalnızca maskelenmiş biçimde gösterir (örneğin y***@example.com); böylece parolayı çalmış bir saldırgan hedef e-postayı öğrenemez. Kurtarma kanalı ve düşük riskli doğrulama akışları için kullanışlıdır.
TOTP kurtarması için yedek kodlar
Kayıt anında TOTP kullanıcılarına tek kullanımlık yedek kodlar verilir — şifrelenerek saklanır, bir kez gösterilir ve kullanıcı telefonuna erişimini kaybettiğinde tüketilir. Tüketilen her kod 'kullanıldı' olarak işaretlenir ve bir daha kabul edilmez; kalan kodlar kullanıcı veya yönetici tarafından yeniden üretilebilir.
Tek konfigürasyon altında servis bazlı MFA matrisi
Yöneticiler MFA gereksinimlerini servis, servis grubu veya sonuç (outcome) bazında haritalandırır. Belirli bir servis herhangi bir faktör, belirli bir faktör veya bir zincir talep edebilir — örneğin para transferi operasyonları için girişte TOTP artı taze bir SMS doğrulaması. Matris sürümlüdür, denetlenebilir, ve tek yerdeki değişiklik uygulandığı her yere yayılır.
Yüksek hassasiyetli akışlar için zincirlenmiş MFA
Tek bir faktör yeterli olmadığında servisler iki veya daha fazla faktörü tanımlı bir sırada talep edebilir — örneğin oturum başlangıcında TOTP artı hassas bir işlem çağrıldığında taze bir e-posta veya SMS kodu. Zincir politika odaklıdır ve yapılandırılabilir; kullanıcılar ek adımı yalnızca risk gerektirdiğinde görür.
Adım-yükseltme MFA — kullanıcı değil, politika yükselir
Rutin bir oturum için zaten TOTP'yi tamamlamış bir kullanıcı, daha hassas bir kaynağa ulaştığında oturum içinde yeniden challenge'lanabilir. Yükseltme politika odaklıdır, yeniden giriş değildir; oturum devam eder ve kullanıcı bağlamı, açık pencereleri veya devam eden işini kaybetmeden yalnızca ek challenge'ı tamamlar.
Kullanıcı profilinden self-servis kayıt ve kurtarma
Kullanıcılar TOTP'yi kaydeder, yedek kodları yeniden üretir, güvenilir cihazları yönetir ve e-posta veya telefon numaralarını doğrular — destek talebi açmadan, tek bir profil sayfası üzerinden. Yöneticiler; kimlik doğrulama gerektiğinde yeniden kayıt zorlama, güvenilir cihaz iptal etme veya faktör sıfırlama yetkisini korur.
Operasyonel derinlik
MFA'yı bir checkbox olmaktan çıkarıp savunulabilir bir kimlik doğrulama katmanına dönüştüren altyapı.
Şifreli gizli anahtar depolama ve anahtar yalıtımı
TOTP gizli anahtarları, yedek kodlar ve güvenilir cihaz token'ları platform yönetimindeki anahtarlarla şifrelenerek saklanır; oturum ve politika verilerinden ayrı tutulur. Yönetici operatörler metadata'yı (kayıt durumu, son kullanım, güvenilir cihaz sayısı) görür ama gizli anahtarın kendisini asla görmez.
Kanal bazlı deneme takibi ve kilitleme
Her OTP kanalı kendi deneme sayacını tutar — hatalı TOTP girişleri, hatalı SMS kod girişleri, hatalı e-posta kod girişleri — yapılandırılabilir eşikler aşıldığında kanal kilitlenir. Kilitleme platformun daha geniş login-attack-protection katmanıyla koordine olur; böylece tek bir kullanıcı bir faktörü brute-force ederken aynı anda ikinci faktörü deneyemez.
Her UI yüzeyinde alıcı maskeleme
E-posta adresleri, telefon numaraları ve authenticator adları doğrulama UI'sinde son kullanıcıya her zaman maskelenmiş biçimde gösterilir. Parolayı bilen ama ikinci faktöre sahip olmayan bir saldırgan hedefi okuyup yönlendirme yapamaz — başka birinin omzunun üstünden bakan biri de kayıt detaylarını toplayamaz.
Yapılandırılabilir OTP biçimi ve geçerlilik penceresi
Kod uzunluğu (6, 8 veya daha fazla), gruplama ayırıcıları (123-456 veya 123456), saniye cinsinden geçerlilik penceresi ve yeniden gönderme bekleme süresi MFA profili bazında yapılandırılır. Uyumluluk kapsamlı akışlar daha uzun kodlar ve daha kısa pencereler talep edebilir; rutin akışlar standart 6 haneli, 60 saniyelik kodlarla kullanıcı dostu kalır.
Bekleme süreli ve suistimal korumalı yeniden gönderme
Kullanıcılar orijinal kod ulaşmadığında yeniden gönderme isteyebilir — yeniden gönderme mekanizmasını SMS bombalama aracı olarak kullanmayı engelleyen yapılandırılabilir bir bekleme süresine bağlı olarak. Hız sınırları kanal bazlı deneme sayaçlarıyla birlikte takip edilir ve denetim log'larında görünür.
Deneme bazlı denetim izi
Her MFA denemesi — başarılı, başarısız, yeniden gönderildi, kilitlendi — zaman damgası, kaynak IP, user agent, kanal ve politika motorunun aldığı karar ile loglanır. Denetim akışı platformun SIEM streaming hedefine beslenir; böylece güvenlik ekipleri MFA anomalilerini telemetrinin geri kalanıyla ilişkilendirebilir.
Hangi senaryolarda kullanılır
Ayrıcalıklı yönetici erişimi
Domain controller'lar, production veritabanları, platformun kendi yönetici konsolu — bunlar mevcut en güçlü zinciri dayatır. Yaygın bir desen oturum başlangıcında TOTP artı yıkıcı bir işlem çağrıldığında taze SMS doğrulamasıdır; en yüksek etkili sistemler için güvenilir cihaz kısayolu açılmaz.
Finans ve hazine operasyonları
Para transferi ve mutabakat sistemleri zincirlenmiş MFA talep edebilir — girişte TOTP artı işlem anında taze OTP — böylece tek bir çalınmış faktör para hareketi yaratamaz. Step-up politika sürtünmeyi her sayfa yüklemesinde değil işlem sınırında tutar.
Saha çalışanları ve vardiyalı kullanıcılar
Sabit masası veya güvenilir dizüstüsü olmayan kullanıcılar kurum SMS gateway'i üzerinden SMS OTP ile, SMS güvenilirliği zayıf olduğunda ise e-posta OTP ile kimlik doğrular. Alıcı maskeleme ve kanal bazlı kilitleme, aynı telefon bir vardiyaya hizmet ederken bile akışı güvende tutar.
Uyumluluk kapsamlı sistemler (PCI, HIPAA, KVKK, ISO 27001)
Denetçiler kapsam içindeki sistemlere giden her ayrıcalıklı erişim yolunda MFA arar. Servis bazlı politika gereksinimi denetçi için açıkça ifade eder — düşük riskli iç servislerin önüne aynı duvarı dikmeden.
Sık sorulanlar
TOTP için hangi authenticator uygulamaları destekleniyor?
Platform hangi SMS sağlayıcıları üzerinden OTP teslim edebilir?
Bir kullanıcı authenticator uygulamasına erişimini kaybederse ne olur?
Kullanıcı güvenilir cihaz penceresini kaldırabilir veya kısaltabilir mi?
Aktif bir oturum içinde MFA tekrar istenebilir mi?
MFA'yı kendi düzleminize geri alın
Üç yöntem, tek politika motoru, üçüncü taraf MFA bulutu yok — servis bazlı ve risk bazlı yapılandırılır. Kendi uygulamalarınız üzerinde canlı bir kurulumda gezdirelim.