رفض طلب MFA في VPN: ما ينبغي على العميل فعله

يبدو طلب MFA المرفوض كمشكلة في الشبكة، لكنه ليس كذلك. طلب الخادم عاملًا ثانيًا، فجاء العامل سلبيًا أو لم يصل أصلًا، ورُفضت الجلسة قبل وجود أي نفق. ما يحدث بعد ذلك مسألة تتعلق بسلوك العميل: إظهار الفشل وترك المستخدم يبدأ محاولة نظيفة، أو إعادة المحاولة بطرق تولّد طلبات أكثر وتؤدي في النهاية إلى تفعيل حماية الحساب. والمسار الثاني هو كيف يتحول رمز أُدخل بشكل خاطئ إلى حساب مقفل.

تحقق من الطلب الذي فشل

ابدأ بتحديد الطلب الذي فشل. إشعار الدفع، ورمز TOTP، وإثبات FIDO، وكذلك تدفق SAML؛ فكل منها يفشل بطريقة مختلفة، والعميل يعرف عادة أيها طلب. الرفض، والتحدي المنتهي، وفشل التسليم الذي لم يصل إلى الجهاز أبدًا، كلها تنتهي إلى الخطأ العام نفسه، لذا فإن حالة العميل نفسها هي غالبًا المكان الوحيد الذي يبقى فيه الفارق.

تستحق هذه الحالة تسجيلًا دقيقًا. سجّل معرّف التحدي أو مرجع المعاملة، ونوع العامل، والطابع الزمني، والنتيجة، لكن لا تسجّل الرمز أو الإثبات أبدًا. فمعرّف التحدي هو ما يمكّن المسؤول من العثور على الحدث لدى مزوّد الهوية؛ وبدونه تبدأ محادثة الدعم بعبارة «في وقت ما خلال الساعة الماضية» وتنتهي عندها عادة. تعامل معه كبيانات وصفية تشخيصية، لا كسرّ.

أعد المحاولة مرة واحدة، عن قصد، بتحدٍّ جديد

ينبغي أن تكون إعادة المحاولة محاولة جديدة بتحدٍّ جديد، لا إعادة تشغيل للتحدي القديم. عندما يعيد العميل استخدام التحدي السابق، إما أن يرفضه مزوّد الهوية باعتباره قديمًا، أو، وهو الأسوأ، أن يقبل موافقة كانت مخصصة للمحاولة الأسبق. اطلب تحدٍّا جديدًا، واعرضه، ودع المستخدم يتصرف بناءً على التحدي المعروض حاليًا على الشاشة.

محاولتان مع توقف قصير بينهما هو الافتراضي المعقول؛ أما حلقة بلا حدود فليست كذلك. وإذا فشلت المحاولة الثانية بالطريقة نفسها، فتوقف وأبلغ بدلًا من الاستمرار.

ما يجب على العميل ألا يفعله

يجب على العميل ألا يفعل أشياء عدة تبدو مفيدة وليست كذلك. فلا يجوز أن يواصل إرسال إشعارات الدفع حتى يضغط أحدهم على «موافقة»، لأن ذلك يدرّب المستخدمين على الموافقة على طلبات لم يبدؤوها، وهو بالضبط السلوك الذي تعتمد عليه أدوات التصيّد. ولا يجوز أن يتراجع إلى عامل أضعف لأن العامل القوي فشل، ولا أن يعطّل التحقق من هوية الخادم لتجاوز شكوى شهادة ظهرت في الوقت نفسه. كل واحد من هذه الاختصارات الثلاثة يحوّل فشل مصادقة إلى حادث أمني.

كذلك يجب ألا يبتلع الفشل بصمت. فالعميل الذي يغلق الاتصال ويعرض مؤشر تحميل يترك المستخدم دون أي فكرة عما إذا كان عليه إعادة المحاولة أو الانتظار أو الاتصال بالدعم. أظهر الفشل مع نوع العامل ورمز قصير، وأبقِ الرسالة خالية من الأسرار، واجعل إجراء إعادة المحاولة صريحًا لا تلقائيًا.

إذا لم يكن الشخص الجالس أمام لوحة المفاتيح هو من بدأ الطلب، فالإجراء الصحيح هو تركه مرفوضًا والإبلاغ عنه عبر مسار الدعم الموثّق. فالموافقة على طلب لإسكات الضجيج هي نمط الفشل، لا الحل.

ما ينبغي تسجيله للدعم

بالنسبة إلى الدعم، السجل المفيد صغير. الوقت التقريبي مع المنطقة الزمنية، والحساب، والعميل وإصداره، ونوع العامل، والحالة غير السرية لكل محاولة: طُلبت، رُفضت، انتهت مهلتها، وُوفق عليها لكن رفضتها السياسة.

أبقِ ساعتي العميل والخادم في الاعتبار أيضًا. فـ TOTP فحص لنافذة زمنية، لذا فإن جهازًا انحرفت ساعته ينتج رموزًا تبدو صالحة وتفشل في كل مرة، والعميل الذي يبلّغ عن رمز غير صالح دون الإشارة إلى الانحراف يدفع الناس إلى إعادة تعيين بيانات اعتماد لم تكن خاطئة أصلًا. وعلى المستخدم الذي يفشل تسجيل دخوله بشكل متكرر أن يتحقق من إصدار العميل المدعوم، وحالة التسجيل، ومسار الاستعادة الموثّق قبل توليد مزيد من الطلبات.

يستحق مسار الاستعادة العناية نفسها التي يستحقها مسار تسجيل الدخول. يوجد سير عمل الجهاز المفقود تحديدًا كي لا يتحول الرفض إلى إذن بتجاوز المصادقة، وينبغي للعميل أن يربط بعملية المؤسسة الموثّقة بدلًا من ارتجال واحدة.

القاعدة التي ينبغي البناء عليها هي أن الرفض نتيجة، لا عقبة. أبلغ عنه مرة واحدة بوضوح، مع سياق كافٍ للتصرف، ودع المحاولة التالية تكون محاولة جديدة. إن إرشادات CISA بشأن المصادقة متعددة العوامل المقاومة للتصيّد تشرح سبب خطورة نمط «الطلب حتى الموافقة» من الأصل، وهي المرجع الجدير بالاستشهاد به عندما يقترح أحدهم حلقة إعادة محاولة. وكل ما يضيفه العميل بعد الرفض ينبغي أن يجعل القرار التالي أسهل لإنسان، لا أن يزيل القرار منه.