VPN MFA isteği reddedildi: istemci ne yapmalı

Reddedilen MFA isteği bir ağ sorunu gibi görünür ve değildir. Sunucu ikinci bir faktör istedi, faktör olumsuz döndü ya da hiç ulaşmadı ve oturum herhangi bir tünel oluşmadan önce reddedildi. Bundan sonra olanlar istemci davranışı meselesidir: hatayı ortaya koyup kullanıcının temiz bir deneme başlatmasına izin vermek ya da daha fazla istek üreten ve sonunda hesap korumasını devreye sokan biçimlerde yeniden denemek. İkinci yol, yanlış yazılmış tek bir kodun kilitli bir hesaba dönüşme yoludur.

Hangi isteğin başarısız olduğunu kontrol edin

Hangi isteğin başarısız olduğunu belirleyerek başlayın. Push bildirimi, TOTP kodu, FIDO doğrulaması ve SAML akışı her biri farklı biçimde başarısız olur ve istemci genellikle hangisini istediğini bilir. Reddetme, süresi geçmiş meydan okuma ve cihaza hiç ulaşmayan teslim hatası hep aynı genel hatayla sonlanır, bu yüzden fark çoğu zaman yalnızca istemcinin kendi durumunda yaşamaya devam eder.

Bu durumu tam olarak kaydetmeye değer. Meydan okuma tanımlayıcısını veya işlem referansını, faktör türünü, zaman damgasını ve sonucu kaydedin, ancak kodu veya doğrulamayı asla kaydetmeyin. Meydan okuma tanımlayıcısı, bir yöneticinin olayı kimlik sağlayıcı tarafında bulmasını sağlayan şeydir; o olmadan destek görüşmesi «son bir saat içinde bir ara» diye başlar ve genellikle orada biter. Ona sır olarak değil, tanılama üst verisi olarak davranın.

Yeni bir meydan okumayla bir kez, bilerek yeniden deneyin

Yeniden deneme, eskisinin tekrarı değil, yeni bir meydan okumayla yeni bir deneme olmalıdır. İstemci önceki meydan okumayı yeniden kullandığında kimlik sağlayıcı ya onu eskimiş diye reddeder ya da daha kötüsü, önceki deneme için tasarlanmış bir onayı kabul eder. Yeni bir meydan okuma isteyin, gösterin ve kullanıcının şu anda ekranda olan üzerinde işlem yapmasına izin verin.

Aralarında kısa bir duraklama olan iki deneme makul bir varsayılandır; sınırsız bir döngü değildir. İkinci deneme aynı şekilde başarısız olursa devam etmek yerine durun ve bildirin.

İstemcinin yapmaması gerekenler

İstemci yardımcı görünen ama olmayan birkaç şeyi yapmamalıdır. Biri «onayla» dokunana kadar push bildirimi göndermeye devam etmemelidir, çünkü bu kullanıcılara kendilerinin başlatmadığı istekleri onaylamayı öğretir ve phishing kitlerinin güvendiği davranış tam olarak budur. Güçlü faktör başarısız oldu diye daha zayıf bir faktöre düşmemelidir ve aynı anda ortaya çıkan bir sertifika şikayetini aşmak için sunucu kimlik denetimini kapatmamalıdır. Bu üç kestirmenin her biri bir kimlik doğrulama hatasını güvenlik olayına dönüştürür.

Hatayı sessizce yutmamalıdır da. Bağlantıyı kapatıp dönen bir gösterge çizen istemci, kullanıcıyı yeniden denemesi, beklemesi ya da desteği araması gerekip gerekmediğini bilmeden bırakır. Hatayı faktör türü ve kısa bir kodla gösterin, mesajı sırlardan arındırın ve yeniden deneme eylemini otomatik değil açık hale getirin.

İsteği klavyedeki kişi başlatmadıysa doğru eylem onu reddedilmiş bırakmak ve doğrulanmış destek yolundan bildirmektir. Gürültüyü kesmek için bir isteği onaylamak başarısızlık örüntüsüdür, çözüm değil.

Destek için neler kaydedilmeli

Destek için yararlı kayıt küçüktür. Saat dilimiyle yaklaşık zaman, hesap, istemci ve sürüm, faktör türü ve her denemenin gizli olmayan durumu: istendi, reddedildi, süresi doldu, onaylandı ama ilke tarafından reddedildi.

İstemci ve sunucu saatlerini de göz önünde tutun. TOTP bir zaman penceresi denetimidir, bu yüzden saati kayan bir cihaz geçerli görünen ama her seferinde başarısız olan kodlar üretir ve geçersiz kodu kaymayı belirtmeden bildiren istemci, insanları hiçbir zaman yanlış olmayan kimlik bilgilerini sıfırlamaya gönderir. Oturum açması tekrar tekrar başarısız olan bir kullanıcı daha fazla istek üretmeden önce desteklenen istemci sürümünü, kayıt durumunu ve belgelenmiş kurtarma akışını kontrol etmelidir.

Kurtarma yolu, oturum açma yolu kadar özen hak eder. Kayıp cihaz için iş akışı tam da reddin kimlik doğrulamayı atlama iznine dönüşmemesi için vardır ve istemci kendi akışını uydurmak yerine kuruluşun belgelenmiş sürecine bağlantı vermelidir.

Üzerine inşa edilmesi gereken kural, reddin bir sonuç olduğu, engel olmadığıdır. Bir kez, açıkça, harekete geçmeye yeterli bağlamla bildirin ve bir sonraki deneme yeni olsun. CISA’nın phishing’e dayanıklı MFA konusundaki rehberi «onaylanana kadar sor» örüntüsünün neden baştan tehlikeli olduğunu açıklar ve biri yeniden deneme döngüsü önerdiğinde atıf yapmaya değer kaynak odur. İstemcinin retten sonra eklediği her şey bir sonraki kararı insan için kolaylaştırmalı, kararı ondan almamalıdır.