Örnek sorular
Security Authn AuthzZorluk 2
Bir kullanıcı geçerli bir parolayla başarıyla giriş yapıyor ama sonra istekteki bir ID'yi değiştirerek başka bir kullanıcının özel sipariş geçmişini açmaya çalışıyor. İstek engelleniyor. Bunu hangi güvenlik kontrolü yakaladı?
- aKimlik doğrulama, çünkü ikinci istekte parola tekrar kontrol edildi
- bYetkilendirme, çünkü sistem istenen kaynak için izinleri kontrol etti✓
- cŞifreleme, çünkü istekteki ID okunamaz durumdaydı
- dRate limiting, çünkü kısa sürede çok fazla istek gönderildi
Açıklama:Kullanıcı zaten kimlik doğrulamasını geçmişti (giriş başarılıydı); engelleme, sistem bu doğrulanmış kimliğin belirli bir kaynağa erişim iznine sahip olup olmadığını değerlendirdiğinde gerçekleşti — bu kontrol, kaç istek gönderildiğinden bağımsız olarak yetkilendirmedir.
Security Authn AuthzZorluk 2
Bir sistem kullanıcıyı teknik olarak doğru şekilde kimlik doğrulasa da neden yine de yanlış bir güvenlik kararı verebilir?
- aÇünkü kimlik doğrulama ve yetkilendirme her zaman birlikte başarısız olur
- bÇünkü doğru kimlik doğrulama otomatik olarak her kaynağa tam erişim verir
- cÇünkü yetkilendirme, doğru kimlik doğrulamadan bağımsız olarak hata verebilir✓
- dÇünkü parolalar yetkilendirme kurallarından daha hızlı süresi dolar
Açıklama:Kimlik doğrulama ve yetkilendirme ayrı ayrı uygulanan kontrollerdir. Kusursuz işleyen bir giriş akışı, ardından gelen kodun artık bilinen kimliğin ne yapabileceğini doğru şekilde kısıtlayıp kısıtlamadığı hakkında hiçbir şey söylemez — bu, sık hata yapılan ayrı bir katmandır.
Security Authn AuthzZorluk 2
Bir backend ekibi, session tabanlı kimlik doğrulamadan; kimlik iddialarını taşıyan ve sunucu taraflı bir sorgu yapılmadan doğrulanabilen kendi kendine yeten token'lara geçiyor. Kabul ettikleri temel trade-off nedir?
- aDaha kolay yatay ölçeklenme, ama verilmiş bir kimlik bilgisinin anında iptalinin zorlaşması✓
- bDaha zor yatay ölçeklenme, ama verilmiş her kimlik bilgisinin anında iptali
- cÖlçeklenme veya iptalde bir değişiklik yok, sadece farklı bir tel formatı
- dToken'lar kimlik doğrulama ihtiyacını tamamen ortadan kaldırır
Açıklama:Kendi kendine yeten token'lar sunucu taraflı bir oturum deposu sorgusuna ihtiyaç duymaz, bu yüzden herhangi bir stateless sunucu onları doğrulayabilir — ölçeklenme için iyidir. Bedeli, ekstra bir iptal mekanizması (kara liste, kısa ömür vb.) eklenmedikçe token'ın süresi dolana kadar geçerli kalmasıdır; oysa bir oturum sunucu tarafında anında silinebilir.
Security Authn AuthzZorluk 3
Session tabanlı ve token tabanlı kimlik yönetimini karşılaştıran hangi ifade doğrudur?
- aSession tabanlı yaklaşımlar doğası gereği güvensiz, token tabanlı yaklaşımlar doğası gereği güvenlidir
- bToken tabanlı yaklaşımlar asla süresi dolmaz, session tabanlı yaklaşımlar her zaman süresi dolar
- cSession tabanlı yaklaşımlar hiçbir koşulda birden fazla sunucuda çalışamaz
- dİkisinin de ölçeklenme ve iptal konusunda farklı trade-off'ları vardır; hiçbiri evrensel olarak üstün değildir✓
Açıklama:Hiçbir model kategorik olarak 'daha güvenli' değildir — seçim, sunucu taraflı durum (kolay iptal, ölçeklenmek için paylaşılan oturum deposu gerektirir) ile kendi kendine yeten token'lar (kolay ölçeklenme, anında iptalin daha zor olması) arasında bir mühendislik trade-off'udur. Güvenlik her iki durumda da doğru uygulamaya bağlıdır.
Security Authn AuthzZorluk 2
Bir saldırgan bir phishing sayfasıyla kullanıcının parolasını çalıyor, ardından sahte bir destek çağrısıyla kullanıcıyı MFA uygulamasındaki tek kullanımlık kodu sesli olarak okumaya ikna ediyor. Bu senaryo MFA hakkında neyi gösterir?
- aMFA işe yaramaz çünkü parolalar phishing ile ele geçirilebilir
- bMFA riski azaltır ama insan faktörünü hedef alan sosyal mühendisliğe karşı bağışık değildir✓
- cMFA yalnızca ikinci faktör bir donanım cihazı olduğunda başarısız olur
- dBu senaryo imkansızdır çünkü MFA kodları sözlü olarak paylaşılamaz
Açıklama:MFA, otomatik veya yalnızca parolaya dayalı saldırılara karşı çıtayı gerçek anlamda yükseltir ama ikinci faktörü elinde tutan insanı hedef alan sosyal mühendisliğe (ör. birini tek kullanımlık kodu söylemeye ikna etmek) karşı bağışık değildir; zayıf noktayı tamamen ortadan kaldırmak yerine kaydırır.
Security Authn AuthzZorluk 2
Bir giriş endpoint'i parolayı kontrol ediyor ve doğruysa, ikinci faktör istenmeden hemen oturumda mfa_verified = true ayarlıyor. Bu ne tür bir zayıflık yaratır?
- aMFA adımı, bayrak doğrulamadan önce güvenilir sayıldığı için fiilen atlanmış olur✓
- bHiçbir şey — parola kontrolünden hemen sonra bayrağı ayarlamak standart doğru kalıptır
- cBu yalnızca parola da zayıfsa önemlidir
- dOturum çerezi secure olarak işaretlendiği sürece bu güvenlidir
Açıklama:Oturum, ikinci faktör gerçekten doğrulanmadan MFA-doğrulanmış olarak işaretlenirse, bu bayrağa güvenen sonraki kod, yalnızca parola kontrolü yapılmışken girişi tam çok faktörlü gibi ele alır — bu, MFA'nın amacını sessizce boşa çıkaran bir mantık hatasıdır.