Kullanıcıları değil, kimlik doğrulama sisteminizi suçlayın: Phishing'in asıl sorunu bu

Şüpheli Bağlantılara Tıklamayın: Artık İşe Yaramayan Bir Tavsiye

Her yıl güvenlik eğitimleri kullanıcılara aynı şeyi söylüyor: URL'ye bak, HTTPS var mı kontrol et, tanımadığın sitelerde şifre girme. Teoride mantıklı tavsiyeler. Ama gerçekte o kadar karmaşık kimlik doğrulama sistemleri kurduk ki, kullanıcılardan her üç ayda bir değişen bir bilmeceyi çözmelerini istiyoruz.

Kabul etmesi zor bir gerçek var: phishing saldırıları her zaman kullanıcı hatası değil. Çoğu zaman mimari hatası.

Meşru Siteler Bile Dolandırıcılık Gibi Görünüyor

Kendi kuruluşunun giriş akışını bir düşün. Çoğu şirket gibiysen, o giriş butonu muhtemelen kullanıcıları üçüncü taraf kimlik sağlayıcıları, federated kimlik doğrulama servisleri ve açıkçası phishing girişimlerine şüpheli derecede benzeyen tokenize endpoint'ler arasında bir labirentten geçiriyordur.

https://uygulama.sirketin.com → 
https://kimlik.kimliksalayici.io/sirketin →
https://sso.federat servis.com/oturum/token →
https://dogrula.auth-islemci.com/mfa

Bu URL'lerden hiçbiri şirketinin domaininde barınmıyor. Hiçbiri akılda kalıcı değil. Hiçbiri kullanıcılara gerçekle sahteyi ayırt etmeleri için şans tanımıyor.

Bir saldırganın bu deneyimi kopyalaması için sadece üç şeye ihtiyacı var: ikna edici bir şablon, çalınmış bir logo ve bir şifre alanı. URL'nin kendisi anlamsız hale geldi çünkü kullanıcıları onu görmezden gelmeye eğittik.

URL'ler Bu İş İçin Hiç Tasarlanmamıştı

Açık olalım—URL yapısı doğası gereği kafa karıştırıcı ve teknik olmayan kullanıcıların onu geliştiriciler gibi parse etmesini beklememeliyiz.

Şu URL'yi düşün:

https://login.staging.internal.example-corp.com/auth/verify

Çoğu kullanıcı "staging" ve "internal" gördüğünde gözleri kayar. Şirket adını arıyor ve bulduğunda bile, çevresindeki altyapının meşru mu yoksa ince bir taklit mi olduğunu anlayamıyor.

Hostname spesifikten genele doğru okunur (login → staging → internal → example-corp → com), bu da en önemli tanımlayıcı—gerçek domain—ortada gömülü durumda demek. Kullanıcılar URL'nin herhangi bir yerinde marka adı aramayı öğreniyor ve bu tam olarak phisherların istismar ettiği alışkanlık.

Protokol → Alt Domain(ler) → Domain → TLD → Path
    |          |           |       |      |
 HTTPS      login      example   com    /auth

Geliştiriciler bunu sezgisel olarak anlar. URL'leri şöyle normalleştirdiğimizde, sıradan kullanıcıların şansı yok:

https://auth.sirket.suspicious-vendor.io
https://sirket.auth-vendor.io/sso/abc123
https://auth-vendor.io/sirket-signin

Geliştirici Sorumluluğu

İşte konunun burada sana bağlandığı yer: kullanıcıları varsayılan olarak koruyan kimlik doğrulama deneyimleri tasarlama gücün var.

Kullanıcıları üçüncü taraf domainler labirentinde gezdirmek yerine, şu ilkeleri düşün:

1. Kendi kimlik domainini sahiplen. Ana marka domainin kimlik doğrulamayı halletmeli. Üçüncü taraf kimlik sağlayıcıları kullanmak zorundaysan, özel alt domain kullanımını zorunlu kıl:

✓ https://login.sirketin.com
✗ https://auth.saglayici.com/sirketin

2 tutarlı alt domain hiyerarşisi. Ana uygulaman uygulama.sirket.com'daysa, kimlik doğrulaman auth.sirket.com'da olmalı—başkasının altyapısı altında üç kat derine gömülü değil.

3. Akıllı yönlendirme yap. Harici servislere (anketler, ödeme işlemcileri, destek portalları) bağlantı vermek zorundaysan, kendi domaininden sunucu tarafı yönlendirmeleri kullan. Bu kullanıcılara tutarlı bir deneyim sunar ve "kendi domainimizden gelmiyorsa bizim değil" mesajını pekiştirir.

4. SMS ve telefon numaralarına aynı şekilde davran. "Bu numarayı ara" veya "bu kodu mesajla" mesajları, e-posta linkleri kadar tehlikeli. Her zaman kullanıcıların zaten güvendiği bir sayfada iletişim bilgilerini dahil et.

Kullanıcılarla Birlikte Ölçeklenen Güvenlik İnşa Etmek

RFC 2119 terminolojisi sadece bürokratik jargon değil—bir tasarım felsefesi. Kimlik doğrulama güvenliği bir "OLMALI" olduğunda, bugün içinde bulunduğumuz durum ortaya çıkıyor: meşru siteler dolandırıcılıktan ayırt edilemez hale gelen federated kimlik servislerinin vahşi batısı.

Güvenlikte kazanacak olan kuruluşlar, kullanıcıları en zayıf halka olarak görmeyi bırakıp, güvenli seçimi kolay seçim haline getiren sistemler kurmaya başlayanlar.

Çünkü gerçek şu: bir tasarım problemini güvenlik eğitimiyle çözemezsin.

Bu Senin Girişimi veya İşletmen İçin Ne Anlama Geliyor

Kimlik doğrulama akışları inşa ediyor veya bakımını yapıyorsan, şimdi bir denetim zamanı. Kendine sor:

• Yeni bir kullanıcı, tek başına URL'ye bakarak giriş sayfanı tanıyabilir mi?
• Tüm kimliği doğrulanmış deneyimlerin, kullanıcılarının tanıdığı domainler üzerinden mi yönlendiriliyor?
• Üçüncü taraf servislerin BYO domain özelliklerini mi kullanıyorsun, yoksa varsayılan URL'lerini mi kabul ediyorsun?

Bu sadece güvenlik gösterisi hakkında değil—güven inşa etmek hakkında. Kimlik doğrulama deneyiminden emin olan kullanıcılar, ürününe güvenen kullanıcılardır.

NameOcean'da domain stratejisinin güvenlik mimarisiyle nasıl kesiştiğini gördük. Domainin sadece bir adres değil—kullanıcı güveninin temeli. Onun senin için çalıştığından, sana karşı çalışmadığından emin ol.