VPN MFA sorğusu rədd edildi: müştəri nə etməlidir

Rədd edilmiş MFA sorğusu şəbəkə problemi kimi görünür, amma deyil. Server ikinci faktor tələb etdi, faktor mənfi qayıtdı və ya heç vaxt gəlmədi və sessiya hər hansı tunel yaranmadan rədd edildi. Bundan sonra baş verənlər müştərinin davranışı məsələsidir: uğursuzluğu göstərib istifadəçiyə təmiz cəhdə başlamağa imkan vermək və ya daha çox sorğu yaradan və nəhayət hesab müdafiəsini işə salan üsullarla təkrar cəhd etmək. İkinci yol, səhv yazılmış bir kodun kilidli hesaba çevrilməsinin yoludur.

Hansı sorğunun uğursuz olduğunu yoxlayın

Hansı sorğunun uğursuz olduğunu müəyyən etməklə başlayın. Push bildirişi, TOTP kodu, FIDO təsdiqi və SAML axını hər biri fərqli şəkildə uğursuz olur və müştəri adətən hansını istədiyini bilir. İmtina, vaxtı keçmiş çağırış və cihaza heç vaxt çatmayan çatdırılma xətası hamısı eyni ümumi xəta ilə bitir, ona görə də fərq çox vaxt yalnız müştərinin öz vəziyyətində qalır.

Bu vəziyyəti dəqiq qeyd etməyə dəyər. Çağırış identifikatorunu və ya əməliyyat istinadını, faktor növünü, vaxt möhürünü və nəticəni qeyd edin, lakin heç vaxt kodu və ya təsdiqi yazmayın. Çağırış identifikatoru administratorun hadisəni kimlik provayderinin tərəfində tapmasına imkan verən şeydir; o olmadan dəstək söhbəti “keçən saat ərzində bir vaxt” ifadəsi ilə başlayır və adətən orada bitir. Ona sirr kimi deyil, diaqnostik metadata kimi yanaşın.

Yeni çağırışla bir dəfə, qəsdən təkrar cəhd edin

Təkrar cəhd köhnənin təkrarı deyil, yeni çağırışla yeni cəhd olmalıdır. Müştəri əvvəlki çağırışı yenidən istifadə etdikdə, kimlik provayderi ya onu köhnəlmiş kimi rədd edir, ya da daha pisi, əvvəlki cəhd üçün nəzərdə tutulmuş təsdiqi qəbul edir. Təzə çağırış tələb edin, onu göstərin və istifadəçinin hazırda ekranda olan çağırış üzərində hərəkət etməsinə imkan verin.

Aralarında qısa fasilə olan iki cəhd məqbul standartdır; sonsuz dövrə deyil. İkinci cəhd eyni şəkildə uğursuz olarsa, davam etmək əvəzinə dayanın və məlumat verin.

Müştəri nə etməməlidir

Müştəri faydalı görünən və olmayan bir neçə şey etməməlidir. Kimsə “təsdiq”ə basana qədər push bildirişləri göndərməyə davam etməməlidir, çünki bu, istifadəçiləri özlərinin başlatmadığı sorğuları təsdiqləməyə öyrədir və fişinq dəstlərinin dayandığı davranış məhz budur. Güclü faktor uğursuz olduğu üçün zəif faktora keçməməli və eyni vaxtda ortaya çıxan sertifikat şikayətini keçmək üçün server kimliyi yoxlamasını söndürməməlidir. Bu üç qısayolun hər biri autentifikasiya uğursuzluğunu təhlükəsizlik insidentinə çevirir.

Həm də uğursuzluğu səssizcə udmamalıdır. Bağlantını bağlayan və fırlanan göstərici göstərən müştəri istifadəçini təkrar cəhd etmək, gözləmək və ya dəstəyə zəng etmək barədə heç bir fikir olmadan qoyur. Uğursuzluğu faktor növü və qısa kodla göstərin, mesajı sirlərdən təmiz saxlayın və təkrar cəhd əməliyyatını avtomatik deyil, açıq edin.

Əgər sorğu klaviaturadakı şəxs tərəfindən başladılmayıbsa, düzgün hərəkət onu rədd edilmiş saxlamaq və təsdiqlənmiş dəstək yolu ilə bildirməkdir. Səsi kəsmək üçün sorğunu təsdiqləmək düzəliş deyil, uğursuzluq modelidir.

Dəstək üçün nə qeyd etmək lazımdır

Dəstək üçün faydalı qeyd kiçikdir. Saat qurşağı ilə təxmini vaxt, hesab, müştəri və versiya, faktor növü və hər cəhdin sirr olmayan statusu: soruşuldu, imtina edildi, vaxtı bitdi, təsdiqləndi amma siyasətlə rədd edildi.

Müştəri və server saatlarını da göz önündə saxlayın. TOTP zaman pəncərəsi yoxlamasıdır, ona görə saatı sürüşmüş cihaz hər dəfə uğursuz olan etibarlı görünüşlü kodlar yaradır və sürüşməni qeyd etmədən etibarsız kod bildirən müştəri insanları heç vaxt səhv olmayan etimadnamələri sıfırlamağa yönəldir. Girişi dəfələrlə uğursuz olan istifadəçi daha çox sorğu yaratmazdan əvvəl dəstəklənən müştəri versiyasını, qeydiyyat vəziyyətini və sənədləşdirilmiş bərpa axınını yoxlamalıdır.

Bərpa yolu giriş yolu qədər diqqətə layiqdir. İtirilmiş cihaz iş axını məhz rəddin autentifikasiyadan yan keçmə icazəsinə çevrilməməsi üçün mövcuddur və müştəri özü uydurmaq əvəzinə təşkilatın sənədləşdirilmiş prosesinə keçid verməlidir.

İnşa etməli olduğunuz qayda budur: rədd nəticədir, maneə deyil. Onu bir dəfə, aydın şəkildə, hərəkət etmək üçün kifayət qədər kontekstlə bildirin və növbəti cəhdin yeni cəhd olmasına imkan verin. CISA-nın fişinqə davamlı MFA üzrə təlimatı “təsdiqə qədər soruş” modelinin niyə ilk növbədə təhlükəli olduğunu izah edir və kimsə təkrar cəhd dövrəsi təklif etdikdə istinad etməyə dəyər mənbə məhz budur. Müştərinin rəddən sonra əlavə etdiyi hər şey növbəti qərarı insan üçün asanlaşdırmalı, qərarı ondan almamalıdır.