Yetenek

Çok Faktörlü Kimlik Doğrulama

Üç MFA yöntemi. Tek politika motoru. Harici MFA bulutuna bağımlılık yok.

TR7; TOTP authenticator uygulamaları, SMS OTP ve e-posta OTP yöntemlerini aynı erişim politikası altında toplar. MFA kararı; servis, kullanıcı grubu, cihaz güveni, lokasyon, oturum riski ve erişilen varlığın hassasiyetine göre gateway üzerinde verilir. Kullanıcı her girişte gereksiz doğrulama adımlarıyla yavaşlatılmaz. Düşük riskli uygulamalar ikinci faktör istemeyebilir; production sistemleri her girişte TOTP zorunlu kılabilir; kritik bir oturumda risk değişirse TR7 oturum içinde yeniden MFA isteyebilir. TOTP gizli anahtarları, yedek kodlar ve güvenilir cihaz bilgileri platformda şifreli saklanır. Kabul, ret ve step-up kararları harici MFA bulutuna gönderilmeden, TR7'nin kendi kimlik ve politika düzleminde alınır. Sonuç: Kullanıcı için daha az sürtünme; güvenlik ekibi için daha güçlü kontrol; kurum için yerel, merkezi ve dış MFA servislerine bağımlı olmayan doğrulama katmanı.

3
Yerleşik desteklenen MFA yöntemi
0
Kimlik doğrulama yolundaki harici MFA bulutu
30g
Varsayılan güvenilir cihaz penceresi

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ı.

01

Ş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.

02

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.

03

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.

04

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.

05

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.

06

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?
RFC 6238 uygulayan her uygulama — Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, Yubico Authenticator, FreeOTP ve platformun kendi authenticator'ı. Kayıt standart bir QR kodu ile çalışır; satıcıya özgü bir uygulama gerekmez.
Platform hangi SMS sağlayıcıları üzerinden OTP teslim edebilir?
HTTP API sunan her sağlayıcı — Twilio, Vonage, Infobip, MessageBird, Plivo veya operatör ağındaki kendi SMS gateway'iniz. Platform mesajı oluşturur, yapılandırılmış endpoint'i çağırır ve teslimi takip eder; sağlayıcı değiştirmek bir kod değişikliği değil, bir konfigürasyon değişikliğidir.
Bir kullanıcı authenticator uygulamasına erişimini kaybederse ne olur?
TOTP kaydında verilen yedek kodlar authenticator uygulamasının kaybını karşılar — her kod tek kullanımlık, şifrelenerek saklanır ve bir kez tüketilerek erişim geri alınır. Yedek kodlar da mevcut değilse yöneticiler, yeni bir TOTP kaydı verilmeden önce kimlik doğrulamayı yeniden yapan destek aracılı bir kurtarma akışı çalıştırır. Kurtarma eylemleri kendi başlarına denetlenir ve zaman sınırlıdır.
Kullanıcı güvenilir cihaz penceresini kaldırabilir veya kısaltabilir mi?
Evet. Son kullanıcılar güvenilir cihazları kendi profil sayfalarından iptal edebilir; yöneticiler de her kullanıcı veya cihaz için güven süresini iptal edebilir veya kısaltabilir. Güven durumu ayrıca; kullanıcı parolasını değiştirdiğinde, cihaz parmak izi değiştiğinde veya koşullu erişim politikası bir risk sinyaline dayanarak güveni iptal ettiğinde otomatik olarak geçersiz kılınır.
Aktif bir oturum içinde MFA tekrar istenebilir mi?
Evet. Koşullu erişim politikası veya sürekli güven değerlendirmesi bir risk değişimi tespit ettiğinde — coğrafya değişimi, uç nokta güven düşüşü, anomalik davranış — gateway, kullanıcıyı giriş sayfasından baştan başlatmadan aynı oturum içinde taze bir MFA challenge'ı dayatabilir. Yükseltme politika odaklıdır ve kullanıcı istemi yalnızca politika gerekli gördüğünde görür.

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.