VPN uchun MFA so‘rovi rad etildi: mijoz nima qilishi kerak
Rad etilgan MFA so‘rovi — muvaffaqiyatsiz kirish, qayta urinishlar sikli emas. So‘rovni aniqlang, xatoni ko‘rinadigan holda saqlang va qo‘llab-quvvatlash nima so‘rashini yozib oling.
Rad etilgan MFA so‘rovi tarmoq muammosiga o‘xshaydi, lekin u emas. Server ikkinchi omilni so‘radi, omil salbiy qaytdi yoki umuman kelmadi va sessiya biron tunnel paydo bo‘lishidan oldin rad etildi. Keyin nima bo‘lishi mijoz xatti-harakati masalasidir: xatoni ko‘rsatib, foydalanuvchiga toza urinish boshlash imkonini berish yoki ko‘proq so‘rovlar yaratib, oxir-oqibat hisob himoyasini ishga tushiradigan usullar bilan qayta urinish. Ikkinchi yo‘l — bitta noto‘g‘ri terilgan kodning qulflangan hisobga aylanish yo‘li.
Qaysi so‘rov muvaffaqiyatsiz bo‘lganini tekshiring
Qaysi so‘rov muvaffaqiyatsiz bo‘lganini aniqlashdan boshlang. Push bildirishnomasi, TOTP kodi, FIDO tasdiqlovi va SAML oqimi har biri turlicha muvaffaqiyatsiz bo‘ladi va mijoz odatda qaysi birini so‘raganini biladi. Rad etish, muddati o‘tgan chaqiriq va qurilmaga hech qachon yetib bormagan yetkazib berish xatosi — barchasi bir xil umumiy xato bilan tugaydi, shuning uchun farq ko‘pincha faqat mijozning o‘z holatida saqlanib qoladi.
Bu holatni aniq qayd etishga arziydi. Chaqiriq identifikatorini yoki tranzaksiya havolasini, omil turini, vaqt belgisini va natijani yozing, lekin hech qachon kodni yoki tasdiqlovni yozmang. Chaqiriq identifikatori administratorga voqeani identifikatsiya provayderi tomonida topish imkonini beradi; usiz qo‘llab-quvvatlash suhbati «oxirgi soat ichida qayerdadir» degan so‘z bilan boshlanadi va odatda shu yerda tugaydi. Unga sir sifatida emas, diagnostik metadata sifatida qarang.
Yangi chaqiriq bilan bir marta, ataylab qayta urinib ko‘ring
Qayta urinish yangi chaqiriq bilan yangi urinish bo‘lishi kerak, eskisini qayta ijro etish emas. Mijoz oldingi chaqiriqni qayta ishlatsa, identifikatsiya provayderi uni eskirgan deb rad etadi yoki, undan yomoni, avvalgi urinish uchun mo‘ljallangan tasdiqni qabul qiladi. Yangi chaqiriq so‘rang, uni ko‘rsating va foydalanuvchi hozir ekranda turgan chaqiriq bo‘yicha harakat qilsin.
O‘rtasida qisqa tanaffus bilan ikki urinish — oqilona standart; cheksiz sikl esa emas. Ikkinchi urinish ham xuddi shunday muvaffaqiyatsiz bo‘lsa, davom etish o‘rniga to‘xtang va xabar bering.
Mijoz nima qilmasligi kerak
Mijoz foydali ko‘rinadigan, lekin aslida unday bo‘lmagan bir nechta ishni qilmasligi kerak. Kimdir «tasdiqlash» tugmasini bosmaguncha push bildirishnomalarini yuborishda davom etmasligi kerak, chunki bu foydalanuvchilarni o‘zlari boshlamagan so‘rovlarni tasdiqlashga o‘rgatadi va fishing to‘plamlari aynan shu xatti-harakatga tayanadi. Kuchli omil muvaffaqiyatsiz bo‘ldi deb zaif omilga qaytmasligi kerak va bir vaqtda paydo bo‘lgan sertifikat shikoyatini chetlab o‘tish uchun server identifikatsiyasini tekshirishni o‘chirmasligi kerak. Bu uchta qisqa yo‘lning har biri autentifikatsiya xatosini xavfsizlik hodisasiga aylantiradi.
Shuningdek, xatoni indamay yutib yubormasligi kerak. Ulanishni yopib, aylanuvchi ko‘rsatkichni ko‘rsatadigan mijoz foydalanuvchini qayta urinish, kutish yoki qo‘llab-quvvatlashga qo‘ng‘iroq qilish haqida hech qanday tasavvursiz qoldiradi. Xatoni omil turi va qisqa kod bilan ko‘rsating, xabarni sirlardan xoli tuting va qayta urinish harakatini avtomatik emas, aniq qiling.
Agar so‘rovni klaviatura yonidagi shaxs boshlamagan bo‘lsa, to‘g‘ri harakat — uni rad etilgan holda qoldirish va tasdiqlangan qo‘llab-quvvatlash yo‘li orqali xabar berish. Shovqinni to‘xtatish uchun so‘rovni tasdiqlash — muvaffaqiyatsizlik namunasi, yechim emas.
Qo‘llab-quvvatlash uchun nimalarni yozib olish kerak
Qo‘llab-quvvatlash uchun foydali yozuv kichik. Vaqt mintaqasi bilan taxminiy vaqt, hisob, mijoz va versiya, omil turi hamda har bir urinishning sir bo‘lmagan holati: so‘ralgan, rad etilgan, muddati o‘tgan, tasdiqlangan, lekin siyosat tomonidan rad etilgan.
Mijoz va server soatlarini ham kuzatib turing. TOTP vaqt oynasini tekshirishdir, shuning uchun soati siljigan qurilma to‘g‘ri ko‘rinadigan, lekin har safar muvaffaqiyatsiz bo‘ladigan kodlar ishlab chiqaradi va siljishni aytmasdan yaroqsiz kod haqida xabar beradigan mijoz odamlarni hech qachon noto‘g‘ri bo‘lmagan hisob ma’lumotlarini tiklashga yuboradi. Kirishi qayta-qayta muvaffaqiyatsiz bo‘lgan foydalanuvchi ko‘proq so‘rovlar yaratishdan oldin qo‘llab-quvvatlanadigan mijoz versiyasini, ro‘yxatdan o‘tish holatini va hujjatlashtirilgan tiklash oqimini tekshirishi kerak.
Tiklash yo‘li kirish yo‘li kabi e’tiborga loyiq. Yo‘qolgan qurilma uchun ish oqimi rad etish autentifikatsiyani chetlab o‘tishga ruxsatga aylanmasligi uchun mavjud va mijoz o‘ziniki o‘ylab topish o‘rniga tashkilotning hujjatlashtirilgan jarayoniga havola berishi kerak.
Asos qilib olinadigan qoida: rad etish — natija, to‘siq emas. Bu haqda bir marta, aniq, harakat qilish uchun yetarli kontekst bilan xabar bering va keyingi urinish yangi bo‘lsin. CISA ning fishingga chidamli MFA bo‘yicha qo‘llanmasi «tasdiqlanmaguncha so‘rash» namunasi nima uchun boshidanoq xavfli ekanini tushuntiradi va kimdir qayta urinishlar siklini taklif qilganda unga havola qilishga arziydi. Mijoz rad etishdan keyin qo‘shadigan hamma narsa keyingi qarorni inson uchun osonlashtirishi kerak, qarorni undan tortib olmasligi kerak.