Bir özel yazılımda kullanıcı adı ve parola ekranının çalışması, güvenli giriş sisteminin tamamlandığı anlamına gelmez. Parolanın ele geçirilmesi, aynı bilgilerin başka sitelerden denenmesi, oturum belirtecinin çalınması, kayıp telefon üzerinden ikinci faktörün sıfırlanması veya yönetici hesabının açık bırakılması gibi riskler giriş ekranının ötesinde ortaya çıkar.
Güvenli kimlik doğrulama; kullanıcı hesabının oluşturulmasından parola saklamaya, ikinci faktörden oturum süresine, hesap kurtarmadan işlem kayıtlarına kadar bütün bir yaşam döngüsüdür. Bu rehber, özel yazılım geliştirme projelerinde güvenli giriş, 2FA ve oturum yönetiminin iş ihtiyacıyla birlikte nasıl planlanacağını açıklar.
Kimlik doğrulama, yetkilendirme ve oturum yönetimi farklıdır
Bu üç kavram birbiriyle bağlantılı olsa da aynı işi yapmaz. Kimlik doğrulama, kullanıcının iddia ettiği hesaba erişme hakkını kanıtlamasıdır. Yetkilendirme, doğrulanan kullanıcının hangi ekranı, veriyi ve işlemi kullanabileceğini belirler. Oturum yönetimi ise başarılı girişten sonraki istekleri aynı kullanıcı ve yetki bağlamıyla ilişkilendirir.
| Katman | Temel soru | Örnek kontrol | Yaygın hata |
|---|---|---|---|
| Kimlik doğrulama | Kullanıcı gerçekten kim? | Parola, TOTP, güvenlik anahtarı veya passkey | Yalnızca parolaya güvenmek |
| Yetkilendirme | Bu kullanıcı ne yapabilir? | Rol, şube, kayıt ve işlem bazlı erişim | Butonu gizlemeyi yetki kontrolü sanmak |
| Oturum yönetimi | Sonraki istekler hangi doğrulanmış kullanıcıya ait? | Güvenli oturum kimliği, süre ve sonlandırma | Çalınan oturumun uzun süre geçerli kalması |
OWASP, oturum yönetimini sunucunun kullanıcıyla yapılan ardışık istekleri aynı kimlik ve erişim kontrolleriyle ilişkilendirmesi olarak tanımlar. Oturum kimliği ele geçirildiğinde saldırgan, kullanıcının güçlü giriş yöntemini tekrar uygulamadan onun adına işlem yapabilir OWASP Authentication Cheat Sheet.
Temel güvenlik ilkesi: Kullanıcı güçlü biçimde giriş yapsa bile oturum belirteci zayıf korunuyorsa saldırgan parolayı veya ikinci faktörü bilmeden hesabı kullanabilir. Giriş güvenliği ile oturum güvenliği aynı plan içinde ele alınmalıdır.
Önce hesap türleri ve risk seviyesi belirlenmelidir
Her kullanıcı aynı veri ve işlem gücüne sahip değildir. Yönetici, finans sorumlusu, saha personeli, müşteri, bayi ve entegrasyon hesabına aynı giriş politikası uygulanması güvenlik veya kullanılabilirlik açısından doğru olmayabilir.
Planlama sırasında hesaplar aşağıdaki ölçütlerle sınıflandırılabilir:
- Erişebildiği kişisel, finansal veya ticari veri
- Silme, ödeme, dışa aktarma ve yetki değiştirme gücü
- İnternete açık mı, kurum ağıyla sınırlı mı olduğu
- İnsan kullanıcı mı, servis veya entegrasyon hesabı mı olduğu
- Hesap ele geçirildiğinde oluşabilecek iş ve itibar etkisi
- Kullanıcının kendi cihazını mı, kurum cihazını mı kullandığı
- Hangi ülkelerden, ağlardan veya çalışma saatlerinden erişim beklendiği
Örneğin müşterinin sipariş durumunu görüntülediği hesap ile bütün müşteri verisini dışa aktarabilen yönetici hesabı aynı güvenlik seviyesinde değerlendirilmemelidir. Yüksek yetkili hesaplarda zorunlu MFA, daha kısa oturum, yeniden doğrulama ve ayrıntılı işlem kaydı uygulanabilir.
Güvenli giriş ekranı nasıl planlanmalıdır?
Giriş ekranı sade görünse de arka planda hesap keşfi, otomatik parola denemesi ve hizmet engelleme risklerine karşı korunmalıdır. Kullanıcı adının veya e-posta adresinin sistemde kayıtlı olup olmadığını açıkça söyleyen farklı hata mesajları, saldırganın hesap listesi oluşturmasına yardımcı olabilir.
Giriş akışında şu kontroller uygulanabilir:
- Var olan ve olmayan hesaplar için kullanıcıya benzer hata mesajı göstermek
- Hatalı girişleri hesap, IP, cihaz ve davranış sinyalleriyle sınırlamak
- Artan bekleme süresi, bot kontrolü veya risk bazlı doğrulama kullanmak
- Giriş denemelerini ve önemli anormallikleri kayıt altına almak
- Başarılı girişten sonra oturum kimliğini yenilemek
- Yeni cihaz veya olağan dışı konum girişini kullanıcıya bildirmek
- Yönetici ve servis hesaplarını genel kullanıcı girişinden ayırmak
OWASP, credential stuffing saldırısını başka veri ihlallerinden elde edilen kullanıcı adı-parola çiftlerinin hedef sisteme denenmesi olarak açıklar. Yalnızca IP engellemek yeterli olmayabilir; MFA, hız sınırı, davranış analizi ve risk bazlı kontroller birlikte kullanılmalıdır OWASP Credential Stuffing Prevention Cheat Sheet.
Hesabı belirli sayıda yanlış denemede kalıcı olarak kilitlemek de saldırganın kullanıcıları sistem dışına itmesine yol açabilir. Kademeli bekleme, geçici sınırlandırma, kullanıcı bildirimi ve güvenli kurtarma akışı birlikte düşünülmelidir.
Parola politikası nasıl olmalıdır?
Güvenli parola politikası, kullanıcıyı belirli aralıklarla büyük harf, sayı ve sembol değiştirerek benzer parolalar üretmeye zorlamak değildir. Uzun, tahmin edilmesi zor ve daha önce ele geçirilmemiş parolaların kullanılmasını desteklemelidir.
NIST SP 800-63B’nin güncel sürümü, yalnızca parola kullanılan tek faktörlü girişlerde en az 15 karakter; parolanın MFA içinde kullanıldığı durumlarda en az 8 karakter öngörür. En az 64 karakterlik azami uzunluğa izin verilmesini, karakter türü zorunluluklarının uygulanmamasını, parolaların periyodik değiştirilmemesini ve bilinen zayıf ya da ele geçirilmiş parolalarla karşılaştırılmasını belirtir NIST SP 800-63B.
Uygulamada parola alanı için şu kararlar alınabilir:
- Uzun parola ve parola cümlelerine izin vermek
- Parolayı sessizce kesmemek
- Parola yöneticisi ve otomatik doldurma kullanımını engellememek
- Yapıştırma işlemini kapatmamak
- Bilinen zayıf ve ihlal edilmiş parolaları engellemek
- Kullanıcıya anlaşılır güç ve hata geri bildirimi vermek
- Parolanın gösterilmesi için kontrollü görünürlük seçeneği sunmak
- Şüpheli ele geçirme durumunda parola değişikliğini zorunlu kılmak
Parolalar geri çözülebilir biçimde saklanmamalıdır. Modern, yavaş ve parola saklama amacıyla tasarlanmış algoritma; her parola için benzersiz salt ve uygun maliyet parametreleriyle kullanılmalıdır. Kullanılan dil veya framework’ün güvenilir kimlik kütüphanesi tercih edilmeli, özel şifreleme yöntemi geliştirilmemelidir OWASP Password Storage Cheat Sheet.
2FA ve MFA arasındaki fark nedir?
2FA, iki farklı faktör kullanan kimlik doğrulamadır. MFA ise iki veya daha fazla faktörü kapsayan genel terimdir. Faktörler; kullanıcının bildiği bilgi, sahip olduğu cihaz veya anahtar ve kendisine ait biyometrik doğrulama gibi farklı kategorilerden gelmelidir.
Parola ve güvenlik sorusu iki ayrı ekran olsa da ikisi de “bilinen bilgi” olduğu için gerçek 2FA oluşturmaz. Parola ile telefon üzerindeki doğrulama uygulamasının ürettiği kod ise farklı faktör kategorilerini birleştirebilir.
| Yöntem | Güçlü yönü | Sınırlılığı | Uygun kullanım |
|---|---|---|---|
| TOTP doğrulama uygulaması | Mobil şebekeye bağlı değildir ve yaygın desteklenir. | Kod sahte giriş ekranına girilebilir; cihaz kaybı yönetilmelidir. | Çoğu yönetim paneli ve kurumsal kullanıcı |
| SMS kodu | Kullanıcı için tanıdık ve kurulumu kolaydır. | Hat taşıma, mesaj yönlendirme ve teslim sorunlarına daha açıktır. | Daha güçlü seçenek sunulamıyorsa geçiş veya yedek yöntem |
| E-posta kodu | Ek uygulama gerektirmez. | E-posta hesabı aynı cihazda açık olabilir; bağımsız faktör gücü sınırlıdır. | Düşük riskli doğrulama veya bildirim desteği |
| Donanım güvenlik anahtarı | Güçlü ve phishing’e dayanıklı doğrulama sağlayabilir. | Dağıtım, yedek anahtar ve kayıp cihaz süreci gerekir. | Yönetici, finans ve yüksek riskli hesaplar |
| Passkey / WebAuthn | Alan adına bağlı açık anahtar kimliğiyle phishing direnci ve kolay kullanım sunabilir. | Cihaz, senkronizasyon ve hesap kurtarma senaryoları planlanmalıdır. | Yeni nesil parola azaltma veya parolasız giriş |
NIST, parolaların phishing’e dayanıklı olmadığını belirtir. WebAuthn ise web uygulamalarının belirli bir hizmet alanına bağlı açık anahtar kimlik bilgileri oluşturup kullanmasını sağlar NIST SP 800-63B W3C Web Authentication Level 3.
2FA kimler için zorunlu olmalıdır?
Yüksek yetkili hesaplarda MFA isteğe bağlı bırakılmamalıdır. Yönetici, finans, insan kaynakları, veri dışa aktarma, kullanıcı yetkisi değiştirme ve sistem ayarı yönetme gücüne sahip roller daha sıkı korunmalıdır.
Diğer kullanıcılar için de sistemin riskine göre zorunlu veya kademeli model uygulanabilir:
- İlk girişte veya MFA kurulumu tamamlanana kadar sınırlı erişim
- Yeni cihaz ya da alışılmadık konumda ikinci doğrulama
- Toplu dışa aktarma, ödeme veya yetki değişikliğinde step-up authentication
- Uzun süredir kullanılmayan hesap yeniden açıldığında MFA
- Parola sıfırlama veya MFA yöntemi değişikliğinde mevcut faktörle yeniden doğrulama
OWASP, kullanıcıyı her adımda ikinci faktörle yormak yerine yeni cihaz, yeni konum veya yüksek riskli işlem gibi durumlarda risk bazlı doğrulama uygulanabileceğini belirtir OWASP Multifactor Authentication Cheat Sheet.
Risk bazlı yaklaşım, MFA’yı tamamen kapatmak anlamına gelmez. Hangi sinyalin ne kadar güvenilir olduğu, yanlış alarm durumunda kullanıcının nasıl devam edeceği ve saldırganın sinyalleri nasıl taklit edebileceği değerlendirilmelidir.
MFA kurulumu ve faktör değiştirme süreci nasıl korunmalıdır?
İkinci faktör ekleme veya değiştirme işlemi, hesabın ele geçirilmesi için hedef olabilir. Saldırgan aktif oturumu ele geçirdikten sonra kendi telefonunu hesaba bağlayabiliyorsa MFA hesabı korumak yerine saldırganın kalıcı erişimini güçlendirebilir.
Faktör yaşam döngüsünde şu kontroller bulunmalıdır:
- Yeni faktör eklemeden önce parola veya mevcut faktörle yeniden doğrulama
- QR kodu veya başlangıç sırrını yalnızca kısa süre ve tek kurulum için gösterme
- Kurulumun geçerli kodla tamamlandığını doğrulama
- Faktör değişikliğini e-posta veya ayrı bildirim kanalıyla kullanıcıya haber verme
- Yüksek yetkili hesaplarda değişiklik için ek onay veya bekleme süresi
- Eski faktörü yeni yöntem başarıyla doğrulanmadan kaldırmama
- Faktör ekleme, silme ve kurtarma işlemlerini loglama
Kullanıcı telefonunu değiştirebilir veya güvenlik anahtarını kaybedebilir. Bu nedenle kurtarma akışı tasarlanmadan MFA yayına alınmamalıdır. OWASP; tek kullanımlık kurtarma kodları, birden fazla faktör kaydı veya kimliği güçlü biçimde doğrulayan destek süreci gibi yöntemlerin uygulamanın riskine göre değerlendirilmesini önerir OWASP Multifactor Authentication Cheat Sheet.
Hesap kurtarma neden giriş kadar kritiktir?
Güçlü parola ve MFA kullanan sistemin “şifremi unuttum” ekranı yalnızca e-posta adresi ve tahmin edilebilir soruyla hesabı açıyorsa bütün güvenlik zinciri en zayıf noktadan kırılır. Kurtarma işlemi, mevcut giriş yöntemini atladığı için aynı veya daha yüksek güvenlik seviyesinde tasarlanmalıdır.
Güvenli parola sıfırlama akışında:
- Hesabın varlığını açık etmeyen tutarlı mesaj ve yanıt süresi kullanmak
- Yeterince rastgele, tek kullanımlık ve kısa süreli sıfırlama belirteci üretmek
- Belirteci güvenli kanaldan göndermek ve sunucuda güvenli biçimde doğrulamak
- Geçerli belirteç sunulmadan hesabı kilitlememek veya değiştirmemek
- Parola değiştiğinde mevcut oturumları sonlandırma seçeneği sunmak
- Kullanıcıya parola ya da faktör değişikliğini bildirmek
- Destek ekibinin manuel kurtarma yetkisini sınırlamak ve kaydetmek
OWASP, var olan ve olmayan hesaplarda tutarlı mesaj kullanılmasını, sıfırlama belirteçlerinin tek kullanımlık ve süreli olmasını, güvenlik sorularının ise tek kurtarma yöntemi olarak kullanılmamasını önerir OWASP Forgot Password Cheat Sheet.
Oturum belirteci nasıl saklanmalıdır?
Web tabanlı yönetim panellerinde oturum kimliği çoğunlukla cookie ile taşınır. Belirtecin tarayıcıdaki JavaScript tarafından okunabilmesi, XSS açığı durumunda çalınma riskini artırabilir. Oturum cookie’si HTTPS dışında gönderilmemeli ve gereksiz alan adlarıyla paylaşılmamalıdır.
Cookie tabanlı oturumlarda aşağıdaki özellikler değerlendirilmelidir:
- Secure: Cookie yalnızca HTTPS bağlantısında gönderilir.
- HttpOnly: JavaScript’in oturum cookie’sine doğrudan erişmesini engeller.
- SameSite: Siteler arası isteklerde cookie gönderimini sınırlandırmaya yardımcı olur.
- Domain ve Path: Cookie’nin erişebileceği alanı mümkün olduğunca daraltır.
- Max-Age veya Expires: Gerektiğinden uzun kalıcı oturum oluşmasını önler.
MDN, oturum cookie’lerinde Secure kullanılmasını, JavaScript erişimi gerekmeyen cookie’lerde HttpOnly ayarlanmasını ve SameSite değerinin mümkün olduğunca Lax veya Strict seçilmesini önerir MDN Secure Cookie Configuration.
Oturum belirtecinin içeriğinde kullanıcı adı, rol, kişisel veri veya tahmin edilebilir bilgi bulunmamalıdır. Sunucu taraflı oturum modelinde istemci yalnızca anlamsız bir kimlik taşır; yetki ve oturum durumu sunucuda tutulur. İmzalı token kullanılıyorsa iptal, anahtar dönüşümü, kısa ömür ve hassas veriyi token içine koymama kararları ayrıca planlanmalıdır.
Oturum kimliği ne zaman yenilenmelidir?
Kullanıcı giriş yaptığında anonim oturumun aynı kimlikle yetkili oturuma dönüşmesi session fixation riskine yol açabilir. Bu nedenle başarılı girişten sonra yeni oturum kimliği üretilmeli ve eski kimlik geçersiz kılınmalıdır.
Oturum kimliğinin yenilenmesi gereken başlıca durumlar şunlardır:
- Anonim durumdan giriş yapılmış duruma geçiş
- Kullanıcının rol veya yetkisinin yükselmesi
- Parola ya da MFA faktörünün değiştirilmesi
- Hassas işleme yeniden doğrulama sonrası geçiş
- Belirlenen yenileme süresinin dolması
OWASP, kimlik doğrulama ve yetki seviyesi değişikliklerinde oturum kimliğinin yeniden üretilmesini ve önceki kimliğin yok edilmesini önerir OWASP Session Management Cheat Sheet.
Oturum süresi nasıl belirlenmelidir?
“Beni hatırla” seçeneği kullanıcı deneyimini kolaylaştırabilir; ancak yüksek yetkili panelde aylarca açık kalan oturum ciddi risk oluşturur. Tek bir süre bütün kullanıcılar ve işlemler için uygun değildir.
Oturum yönetiminde üç farklı süre düşünülebilir:
| Süre türü | Ne zaman sona erer? | Amacı |
|---|---|---|
| Boşta kalma süresi | Belirli süre hiçbir geçerli etkinlik olmadığında | Açık bırakılan oturumun kullanım süresini sınırlar. |
| Mutlak süre | Kullanıcı aktif olsa bile girişten belirli süre sonra | Çalınan oturumun sınırsız yenilenmesini önler. |
| Yenileme süresi | Oturum devam ederken belirli aralıkta kimlik yenilendiğinde | Aynı belirtecin uzun süre kullanılmasını azaltır. |
OWASP, boşta kalma ve mutlak oturum zaman aşımının sunucu tarafında uygulanmasını önerir. Süreler uygulamanın riski ve kullanıcı göreviyle dengelenmelidir OWASP Session Management Cheat Sheet.
Uzun form dolduran kullanıcı zaman aşımı öncesinde uyarılabilir ve taslak verisi korunabilir. Ancak yalnızca tarayıcıdaki sayaçla oturumu uzatmak güvenli değildir; gerçek geçerlilik sunucu tarafından kontrol edilmelidir.
Aktif cihazlar ve uzaktan oturum kapatma
Kullanıcı hesabına hangi cihazlardan giriş yapıldığını görebilmeli ve tanımadığı oturumları kapatabilmelidir. Yönetici de işten ayrılan çalışan, kayıp cihaz veya şüpheli olay durumunda belirli kullanıcının bütün oturumlarını sonlandırabilmelidir.
Aktif oturum ekranında şu bilgiler gösterilebilir:
- Cihaz veya tarayıcı türü
- Yaklaşık konum veya ülke bilgisi
- İlk giriş ve son etkinlik zamanı
- Mevcut oturum işareti
- Oturumu sonlandırma işlemi
Konum bilgisi kesin gerçek olarak sunulmamalıdır; IP tabanlı tahminler hatalı olabilir. Cihaz parmak izi de tek başına kimlik doğrulama faktörü sayılmamalıdır. Bu veriler risk sinyali ve kullanıcı farkındalığı için kullanılabilir.
Parola değişikliği, MFA sıfırlama, rol düşürme ve hesap pasifleştirme gibi olaylarda hangi oturumların otomatik kapatılacağı açıkça tanımlanmalıdır.
SSO ve kurumsal kimlik sağlayıcı ne zaman kullanılmalıdır?
Bir işletme Microsoft Entra ID, Google Workspace veya başka bir kurumsal kimlik sağlayıcı kullanıyorsa çalışanların her özel yazılım için ayrı parola oluşturması yerine SSO değerlendirilebilir. Kullanıcı kurumdan ayrıldığında merkezi hesabın kapatılması bağlı uygulamalara erişimi de sonlandırabilir.
SSO entegrasyonunda uygulamanın kimlik doğrulamayı dış sağlayıcıya bırakması, yetkilendirmeyi de tamamen bırakması anlamına gelmez. Uygulama; gelen kimliğin hangi şirket, rol, şube ve veri kapsamına bağlı olduğunu kendi kurallarıyla doğrulamalıdır.
API entegrasyonu kapsamında OpenID Connect veya SAML gibi standartlar kullanılabilir. Sağlayıcıdan gelen e-posta adresini tek başına güvenilir anahtar kabul etmek yerine değişmeyen kullanıcı kimliği, tenant, issuer ve audience gibi bağlamlar doğrulanmalıdır. Servis hesapları ise insan kullanıcı girişinden ayrı kimlik bilgisi ve yetki modeliyle yönetilmelidir.
Giriş ve oturum olayları nasıl izlenmelidir?
Güvenlik kayıtları yalnızca başarısız parola sayısını tutmamalıdır. Hesap ele geçirme veya içeriden kötüye kullanım belirtilerini görebilmek için kimlik doğrulama yaşam döngüsü izlenmelidir.
Kaydedilebilecek olaylar şunlardır:
- Başarılı ve başarısız giriş denemeleri
- MFA kurulumu, kaldırılması ve başarısız ikinci faktör denemeleri
- Parola ve hesap kurtarma talepleri
- Yeni cihaz, olağan dışı konum veya hızlı ülke değişimi
- Oturum oluşturma, yenileme ve sonlandırma
- Rol, yetki ve yönetici hesabı değişiklikleri
- Toplu veri dışa aktarma ve yüksek riskli işlemler
- Hız sınırına takılan veya bot davranışı gösteren istekler
Parola, OTP, kurtarma kodu, oturum belirteci ve gizli anahtar gibi değerler loglara yazılmamalıdır. İşlem kayıtları rol bazlı erişimle korunmalı ve yönetim panelinde yalnızca aksiyon alınabilecek biçimde gösterilmelidir.
Gerçekçi bir güvenli giriş senaryosu
Varsayımsal olarak müşteriler, saha personeli, operasyon yöneticileri ve finans ekibi tarafından kullanılan bir servis yönetim yazılımını düşünelim. Müşteriler kendi taleplerini görüntülerken finans ekibi ödeme bilgilerine, yöneticiler ise kullanıcı ve rol ayarlarına erişiyor olsun.
Müşteri hesaplarında uzun parola, hız sınırı ve riskli girişte ek doğrulama uygulanabilir. Saha personelinde TOTP veya passkey desteklenebilir. Finans ve yönetici rollerinde MFA zorunlu tutulur; toplu dışa aktarma, banka bilgisi değiştirme ve kullanıcı yetkisi verme işlemlerinde tekrar doğrulama istenir.
Başarılı girişte oturum kimliği yenilenir. Cookie yalnızca HTTPS üzerinden, HttpOnly ve uygun SameSite ayarıyla taşınır. Yönetici oturumları daha kısa boşta kalma ve mutlak süreye sahip olur. Kullanıcı aktif cihazlarını görüntüler ve tanımadığı oturumu kapatabilir.
Telefonunu kaybeden çalışan tek kullanımlık kurtarma kodunu kullanabilir veya kimlik kontrolünden geçen destek sürecine yönlendirilir. Faktör değişikliği mevcut e-posta ve yöneticiye bildirilir; önceki oturumlar sonlandırılır. Bu senaryo gerçek bir şirket veya güvenlik garantisi değildir; rol ve risk bazlı planlama mantığını göstermek için hazırlanmıştır.
Güvenli giriş, 2FA ve oturum yönetimi kontrol listesi
- Kullanıcı, yönetici, finans ve servis hesapları ayrı risk seviyelerinde mi?
- Kimlik doğrulama ile rol ve veri yetkileri ayrı kontrol ediliyor mu?
- Giriş hata mesajları hesap varlığını açık ediyor mu?
- Parola yöneticisi, uzun parola ve yapıştırma destekleniyor mu?
- Zayıf ve ihlal edilmiş parolalar engelleniyor mu?
- Parolalar modern parola hash yöntemiyle saklanıyor mu?
- Yüksek yetkili hesaplarda MFA zorunlu mu?
- TOTP yanında phishing’e dayanıklı passkey veya güvenlik anahtarı değerlendirildi mi?
- MFA faktörü değiştirilirken mevcut faktörle yeniden doğrulama yapılıyor mu?
- Kurtarma kodları tek kullanımlık ve güvenli biçimde saklanıyor mu?
- Parola sıfırlama belirteci kısa süreli ve tek kullanımlık mı?
- Başarılı giriş ve yetki değişiminde oturum kimliği yenileniyor mu?
- Oturum cookie’sinde Secure, HttpOnly ve uygun SameSite ayarı var mı?
- Boşta kalma ve mutlak oturum süresi sunucu tarafında uygulanıyor mu?
- Kullanıcı aktif cihazlarını görüp oturum kapatabiliyor mu?
- Parola, OTP ve oturum belirteçleri loglardan çıkarılıyor mu?
- Şüpheli giriş ve faktör değişiklikleri kullanıcıya bildiriliyor mu?
- Güvenlik akışları test ve kalite kontrollerine dâhil mi?
Sonuç: Güvenli giriş tek ekran değil, hesap yaşam döngüsüdür
Özel yazılımda güvenli giriş; güçlü parola alanından daha geniş bir konudur. Hesap türleri, MFA yöntemi, faktör değişikliği, kurtarma, oturum saklama, süreler, yetki değişimi, cihaz yönetimi ve izleme birlikte planlanmalıdır.
Her kullanıcıya aynı güvenlik sürtünmesini uygulamak yerine rol ve işlem riskine göre katmanlı yapı kurulabilir. Yüksek yetkili hesaplarda phishing’e dayanıklı yöntemler, kısa oturumlar ve yeniden doğrulama tercih edilirken düşük riskli görevlerde kullanıcı deneyimi korunabilir. Güvenlik akışlarının proje sonunda eklenen eklentiler değil, özel web yazılımı mimarisinin temel bileşenleri olması gerekir.
Sıkça Sorulan Sorular
2FA ile MFA arasındaki fark nedir?
2FA, kullanıcının iki farklı faktörle kimliğini doğrulamasıdır. MFA ise iki veya daha fazla faktörü kapsayan genel terimdir. Faktörlerin farklı kategorilerden gelmesi gerekir: kullanıcının bildiği parola, sahip olduğu telefon veya güvenlik anahtarı ve cihaz üzerinde kullandığı biyometrik doğrulama gibi. Parola ile güvenlik sorusu iki farklı adım olsa da ikisi de bilinen bilgi olduğu için gerçek 2FA sayılmaz. Parola ile TOTP uygulaması veya passkey ise farklı faktör özelliklerini birleştirebilir.
SMS ile doğrulama güvenli midir?
SMS, yalnızca parolaya göre ek koruma sağlayabilir; ancak en güçlü ikinci faktör değildir. Hat taşıma saldırıları, mesaj yönlendirme, teslim gecikmesi ve mobil şebeke bağımlılığı gibi riskleri vardır. Yönetici, finans veya yüksek değerli hesaplarda TOTP, donanım güvenlik anahtarı ya da phishing’e dayanıklı passkey gibi seçenekler öncelikli değerlendirilmelidir. SMS, daha güçlü yöntem sunulamayan geçiş döneminde veya kontrollü yedek yöntem olarak kullanılabilir. Hesap kurtarma süreci yalnızca SMS numarasına dayandırılmamalıdır.
Passkey parola ve 2FA’nın yerine geçebilir mi?
Passkey, WebAuthn tabanlı açık anahtar kimlik bilgisi kullanır ve hizmetin alan adına bağlı olduğu için phishing’e karşı güçlü koruma sağlayabilir. Kullanıcı cihazını PIN veya biyometrik yöntemle açarak doğrulama yapabilir. Uygun uygulamada parola ve ayrı OTP adımının yerine geçebilir. Ancak cihaz kaybı, senkronize passkey, yedek cihaz, kurumsal hesap devri ve kurtarma süreçleri planlanmalıdır. Bütün kullanıcı cihazlarının ve tarayıcılarının destek durumu incelenmeli; geçiş döneminde alternatif güvenli giriş yöntemi korunmalıdır.
Oturum ne kadar süre açık kalmalıdır?
Bütün uygulamalar için geçerli tek bir süre yoktur. Süre; kullanıcının rolü, eriştiği veri, yaptığı işlemler ve çalışma biçimine göre belirlenmelidir. Yönetici ve finans hesaplarında boşta kalma süresi daha kısa, mutlak oturum süresi daha sınırlı olabilir. Uzun saha formlarında kullanıcı zaman aşımından önce uyarılmalı ve taslak verisi korunmalıdır. Süre kontrolü yalnızca tarayıcıdaki sayaçla değil sunucu tarafında uygulanmalıdır. Hassas işlemlerde oturum açık olsa bile yeniden parola, MFA veya passkey doğrulaması istenebilir.
Parola değiştiğinde bütün oturumlar kapatılmalı mı?
Şüpheli ele geçirme veya kullanıcı talebi varsa bütün aktif oturumların sonlandırılması en güvenli yaklaşımdır. Normal parola değişikliğinde kullanıcıya mevcut cihaz dışındaki oturumları kapatma seçeneği sunulabilir; uygulamanın riskine göre tüm oturumlar otomatik de kapatılabilir. MFA faktörü sıfırlama, yönetici rolü değişimi, hesap pasifleştirme ve destek üzerinden kurtarma gibi yüksek riskli olaylarda eski oturumların geçerli kalması önerilmez. Oturum iptali sunucu tarafında yapılmalı; yalnızca tarayıcı cookie’sini silmekle sınırlı kalmamalıdır.
Kullanıcı telefonunu kaybederse 2FA erişimi nasıl geri alınmalıdır?
Kullanıcıya MFA kurulumu sırasında tek kullanımlık kurtarma kodları verilebilir veya birden fazla güvenli faktör kaydetmesine izin verilebilir. Bunlar bulunmuyorsa destek ekibi açık ve kayıtlı bir kimlik doğrulama süreci uygulamalıdır. Yalnızca e-posta adresi, telefon numarası veya güvenlik sorusu hesabı açmak için yeterli kabul edilmemelidir. Faktör değişikliği yüksek riskli işlem olarak görülmeli, mevcut kanallara bildirim gönderilmeli ve gerekirse bekleme süresi uygulanmalıdır. Kurtarma tamamlandığında eski faktörler ve şüpheli oturumlar iptal edilmelidir.
