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

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

تستعرض هذه المقالة الفرق التشفيري، وخصوصية ما هو مطلوب الآن إطاراً إطاراً، وأنماط الإخفاق في العالم الحقيقي التي تتطابق مع فجوات معمارية متوقَّعة، ونقاط الضعف الأربع التي لا تزال معظم المنصات تتركها مفتوحة.

الفارق التشفيري الذي يحسم كل شيء

لكلمة "مقاوم للتصيّد" تعريف رسمي في NIST SP 800-63B-4، النشر النهائي لإرشادات المُصادِقات الفيدرالية في أغسطس 2025. يحدّد القسم 4.1.5 أربعة متطلبات تراكمية. أولاً، مقاومة انتحال المُتحقِّق: يربط المُصادِق ردّه تشفيرياً بأصل المُتحقِّق، بحيث لا يستطيع وكيل خصم في المنتصف ترحيل الرد. ثانياً، مقاومة إعادة التشغيل: تستخدم كل مصادقة قيمة عشوائية لمرة واحدة (nonce) أو تحدياً جديداً. ثالثاً، سرّ مصادقة غير قابل للتصدير: لا يستطيع المفتاح الخاص مغادرة حدّه العتادي. رابعاً، نية مستخدم صريحة: على المستخدم أداء إجراء يشير إلى الموافقة على هذه المصادقة، لا أن تُعتمد تلقائياً.

أنظف طريقة لرؤية ما يعنيه هذا هي مقارنة TOTP والدفع و FIDO2/WebAuthn بالاختبارات الأربعة.

كلمة المرور لمرة واحدة القائمة على الوقت رقم من ستة أعداد مُشتقّ من HMAC-SHA1(shared_secret, time_window). وهي غير مرتبطة بهوية من يسأل. فالمستخدم الذي يحطّ على accouts-google.com، وهي صفحة تصيّد منتحلة باسم مشابه، ويُدخل كلمة مروره لمرة واحدة، يكون قد سلّم المهاجم رمزاً يستطيع المهاجم إعادة تشغيله على accounts.google.com الحقيقي خلال نافذة الصلاحية البالغة ثلاثين ثانية. يُخفق TOTP في اختبار مقاومة انتحال المُتحقِّق. إنه مصادقة متعددة العوامل، لكنه ليس مصادقة متعددة العوامل مقاومة للتصيّد.

إشعار الدفع مع النقر للموافقة أضعف إذا لم تُفرض مطابقة الأرقام. فرسالة الدفع لا تحمل أي إثبات بأن هذه الموافقة هي لمحاولة تسجيل الدخول هذه. والمهاجم الذي يملك اسم المستخدم وكلمة المرور يستطيع إغراق مطالبات الدفع حتى ينقر المستخدم "نعم"، وهو بالضبط ما حدث في خرق Uber عام 2022. والدفع مع مطابقة الأرقام يضيّق النافذة لأن على المستخدم إدخال رقم معروض على شاشة تسجيل الدخول في تطبيق المصادقة، لكن المستخدم لا يزال هو من يربط "الرقم على الشاشة" بـ"الرقم على الهاتف"، ويستطيع المهاجم سباق تسجيل دخول مع تسجيل الدخول المتوقَّع للمستخدم الشرعي. مكّنت Microsoft مطابقة الأرقام افتراضياً في فبراير 2023 ولم تعد تقدّم الدفع بدونها؛ والنقطة الجوهرية أن موافقة الدفع وحدها ليست مرتبطة تشفيرياً بالمُتحقِّق.

يجتاز FIDO2 مع WebAuthn الاختبارات الأربعة جميعها. يُولّد التسجيل زوج مفاتيح جديداً على المُصادِق (مرتبطاً بالعتاد لمفاتيح الأمان؛ مرتبطاً بالعنصر الآمن على iOS أو Android لمُصادِقات المنصة). ولا يغادر المفتاح الخاص العنصر الآمن أبداً. وعند وقت المصادقة، يرسل الطرف المعتمِد تحدياً مع rpId الخاص به (أصله). ويزوّد المتصفح المُصادِق بالأصل الفعلي الذي يقف عليه المستخدم، ويوقّع المُصادِق نسخةً تتضمن التحدي وذلك الأصل الفعلي. ويتحقق الطرف المعتمِد من التوقيع بالمفتاح العام الذي خزّنه عند التسجيل. وعلى المستخدم لمس مفتاح الأمان (نية صريحة). والتوقيع يكون على الأصل الذي رصده المتصفح، ما يعني أن التوقيع الذي يحصده مهاجم على accouts-google.com لن يتحقق على accounts.google.com لأن الأصل في النسخة الموقّعة خاطئ. هذه مقاومة انتحال المُتحقِّق بصيغة تشفيرية، لا بصيغة سياسة.

والخاصية ذاتها تنطبق على بطاقات PIV الذكية وفق مواصفة FIPS 201: تبادل مصادقة عميل TLS أو Kerberos PKINIT يوقّع التحدي بالمفتاح الخاص المخزّن في العنصر الآمن المقاوم للعبث في البطاقة، حيث تعرّف الشهادة الأصل. وورقة الحقائق الصادرة عن CISA في أكتوبر 2022 حول المصادقة متعددة العوامل المقاومة للتصيّد مباشرة في هذه النقطة: "المصادقة الوحيدة المقاومة للتصيّد المتاحة على نطاق واسع هي مصادقة FIDO/WebAuthn والمصادقة القائمة على البنية التحتية للمفتاح العام (PKI)". وكل عامل آخر يُخفق في واحد من اختبارات 800-63B-4 الأربعة.

ما الذي تشترطه الأطر الرئيسية الآن

النمط متسق عبر الولايات القضائية. تختلف المفردات. ولا يختلف الاتجاه.

NIST SP 800-63B-4 (الولايات المتحدة، أغسطس 2025). نقل النشر النهائي عدة أمور من "مُهمَل" إلى "مُقيَّد عند كل مستوى من مستويات ضمان المصادقة". فالمُصادِقات خارج النطاق القائمة على الرسائل القصيرة والشبكة الهاتفية العامة (PSTN) مقيّدة الآن عند المستويات 1 و2 و3؛ ويتطلب استخدامها تقييم مخاطر، وإشعار المستخدم، وخطة هجرة، وعلى مزوّد خدمة بيانات الاعتماد تقديم بديل غير مقيّد. والبريد الإلكتروني صراحةً ليس قناة خارج النطاق. وعلى المستوى 2 تقديم خيار واحد على الأقل مقاوم للتصيّد ولو لم يكن الافتراضي. ويشترط المستوى 3 مُصادِقاً مرتبطاً بالعتاد بمقاومة انتحال المُتحقِّق ومفتاح خاص غير قابل للتصدير؛ ومفاتيح المرور القابلة للمزامنة (التي يمكن نسخ مفتاحها الخاص بين الأجهزة عبر مزامنة مشفّرة من طرف إلى طرف) تتأهّل للمستوى 2 لا للمستوى 3.

NIST SP 800-53 Rev 5 (الفيدرالي في الولايات المتحدة). عائلة IA-2 هي مجموعة الضوابط المرجعية: IA-2(1) المصادقة متعددة العوامل للحسابات المتميزة (منخفض/متوسط/عالٍ في حدود FedRAMP الدنيا)، و IA-2(2) المصادقة متعددة العوامل للحسابات غير المتميزة (متوسط/عالٍ)، و IA-2(5) يحظر الحسابات المشتركة غير المميَّزة، و IA-2(6) يشترط أن يكون العامل الثاني على جهاز منفصل أو قناة معزولة تشفيرياً، و IA-2(8) مصادقة مقاومة لإعادة التشغيل، و IA-2(12) قبول بيانات اعتماد PIV للموظفين الفيدراليين والمتعاقدين. وتوجّه مذكرة FedRAMP حول المصادقة متعددة العوامل المقاومة للتصيّد الصادرة في أبريل 2024 مقيّمي 3PAO إلى تقييم مقاومة التصيّد وفق تعريف 800-63B-4 §4.1.5، معاملةً الاختبار التراكمي بوصفه السقف.

OMB M-22-09 (الفيدرالي في الولايات المتحدة، يناير 2022). اشترط الإجراء 3 من كل الوكالات المدنية الفيدرالية فرض المصادقة متعددة العوامل المقاومة للتصيّد للموظفين والمتعاقدين والشركاء بنهاية السنة المالية 2024 (30 سبتمبر 2024). واشترط الإجراء 4 من الوكالات تقديم المصادقة متعددة العوامل المقاومة للتصيّد خياراً للأنظمة المواجِهة للجمهور. وتسمّي الحاشية 11 PIV و WebAuthn الآليتين المؤهّلتين. وتذكر المذكرة مباشرةً أن المصادقة متعددة العوامل عبر الرسائل القصيرة والصوت وكلمة المرور لمرة واحدة ليست كافية لهدف انعدام الثقة الفيدرالي. والتعهّد بالأمن بحكم التصميم الصادر عن CISA في مايو 2024، الموقّع من أكثر من 200 مورّد بينهم Microsoft و Google و AWS و IBM و Cisco و Okta، ألزم الموقّعين بزيادة استخدام المصادقة متعددة العوامل بشكل قابل للقياس عبر منتجاتهم خلال سنة من التوقيع، مع تأكيد صريح على المصادقة متعددة العوامل المُفعّلة افتراضياً.

PCI DSS 4.0.1 (دولي، المدفوعات). يحمل المتطلب 8 معظم تفاصيل المصادقة متعددة العوامل. يشترط 8.4.1 المصادقة متعددة العوامل لكل وصول إداري غير عبر وحدة التحكم (non-console) إلى بيئة بيانات حاملي البطاقات (منقولاً من 3.2.1). ويشترط 8.4.2، الإلزامي منذ 31 مارس 2025، المصادقة متعددة العوامل لكل وصول إلى بيئة بيانات حاملي البطاقات، لا الإداري فحسب؛ فالمطوّرون ومهندسو الدعم والأطراف الثالثة ومستخدمو الاستعلام داخل النطاق افتراضياً. ويشترط 8.4.3 المصادقة متعددة العوامل لكل وصول شبكي عن بُعد ينشأ خارج شبكة الكيان وقد يصل إلى بيئة بيانات حاملي البطاقات. ويضع 8.5.1، الإلزامي أيضاً منذ 31 مارس 2025، أربعة متطلبات تراكمية لتهيئة النظام: مقاوم لإعادة التشغيل، ولا تجاوز من قِبل أي مستخدم بمن فيهم المسؤولون إلا باستثناء موثّق محدّد المدة، وما لا يقل عن نوعين مختلفين من العوامل، واشتراط نجاح كل العوامل قبل الوصول. وتحظر الفقرتان (ب) و(د) معاً صراحةً تدفقات الاحتياط التي تقبل المستخدم عند عدم توفر العامل الثاني. ويعالج المتطلب 8.6 الاستخدام التفاعلي لحسابات النظام والتطبيق والخدمة: يجب أن تُدار، ويجب ألا تحمل بيانات اعتماد مُرمّزة بشكل ثابت في النصوص البرمجية أو ملفات التهيئة، ويجب أن يكون لها تدوير لكلمة المرور قائم على تحليل مخاطر موثّق.

ISO 27001:2022 (دولي). يغطّي الملحق A.5.17 دورة حياة معلومات المصادقة؛ ويقيّد A.8.2 حقوق الوصول المتميز مع توصية صريحة بالمصادقة متعددة العوامل في ISO 27002:2022 الفقرة 8.2؛ ويجعل A.8.5 المصادقة الآمنة توصية المصادقة متعددة العوامل صريحة في نص الضابط نفسه، مع توجيه التنفيذ في ISO 27002:2022 الفقرة 8.5 الذي يدعو إلى مصادقة تشفيرية أو ببطاقة ذكية أو برمز أو بيومترية للأنظمة عالية المخاطر ويوجّه المنفّذين إلى عدم الكشف عن العامل الذي أخفق أثناء تسجيل دخول فاشل. وأُغلقت نافذة الانتقال من 2013 إلى 2022 في 31 أكتوبر 2025، تاركةً 27001:2022 وحده بتوقعاته الصريحة للمصادقة متعددة العوامل.

SOC 2 (الولايات المتحدة، AICPA). أضافت نقاط التركيز المنقّحة لعام 2022 لـ CC6.1 إشارة صريحة إلى المصادقة متعددة العوامل للوصول عن بُعد والوصول المتميز، وتشير نقاط تركيز CC6.1 الآن أيضاً إلى مصادقة حساب الخدمة والمصادقة بين الآلة والآلة. وتُترجَم حماية الحدود في CC6.6 عملياً إلى مصادقة متعددة العوامل على أي واجهة إدارية يمكن الوصول إليها خارجياً. وقد تشدّدت توقعات المدققين بين 2024 و2026 على نقطتين محددتين: الحسابات الإدارية المشتركة تُشار إليها بوصفها خللاً في الضوابط ما لم تُثبت المساءلة الفردية، والمصادقة متعددة العوامل عند مزوّد الهوية المتحد لم تعد دليلاً كافياً بمفردها. ويختبر المدققون الآن تهيئة الطرف المعتمِد للتأكد من أنه سيرفض فعلاً تسجيل دخول لم يؤكّد ادعاء مصادقة متعددة العوامل، لأن الأطراف المعتمِدة التي تُخفق في التحقق من ادعاءي amr و acr من مزوّد الهوية تقبل جلسات بعوامل ضعيفة إلى الموارد المحمية.

توجيه NIS2 (الاتحاد الأوروبي). تفرض المادة 21(2)(ي) صراحةً "استخدام المصادقة متعددة العوامل أو حلول المصادقة المستمرة" بوصفها تدبير أمن سيبراني أدنى. وتفصّل لائحة التنفيذ للمفوضية (الاتحاد الأوروبي) 2024/2690 الصادرة في 17 أكتوبر 2024 المتطلبات التقنية في الملحق النقطة 6.7 المصادقة: مصادقة متعددة العوامل أو مصادقة قوية مكافئة للحسابات المتميزة، والحسابات التي تؤدّي إدارة على أنظمة الشبكة والمعلومات، والوصول عن بُعد، والوصول إلى البيانات الحساسة، والوصول إلى الواجهات الإدارية. وصياغة "المصادقة المستمرة" هي إحدى إسهامات NIS2 المميّزة وتشير إلى تحقق مستمر بعد تسجيل الدخول عبر التحليلات السلوكية، وإشارات الثقة المرتبطة بالجهاز، وكشف شذوذ الجلسة. وتشير إرشادات التنفيذ التقنية الصادرة عن ENISA إلى المصادقة متعددة العوامل المقاومة للتصيّد بوصفها الافتراضي للأدوار عالية المخاطر، مستشهدةً بـ FIDO2/WebAuthn والمصادقة القائمة على PKI بوصفهما التقنيتين المؤهّلتين.

قاعدة الأمن في HIPAA (الرعاية الصحية في الولايات المتحدة). يقترح مشروع القاعدة المقترحة في ديسمبر 2024، المنشور في السجل الفيدرالي في 6 يناير 2025، أهمّ إعادة كتابة منذ 2003. ويُلغى تمييز "القابل للمعالجة" مقابل "المطلوب"؛ ويشترط القسم المقترح 164.312(د) صراحةً المصادقة متعددة العوامل للوصول إلى المعلومات الصحية الإلكترونية المحمية ولأي إجراء يؤثر في تهيئة الأمن أو الوصول المتميز أو وظائف النسخ الاحتياطي والاسترداد. وتشير القاعدة المقترحة إلى NIST SP 800-63B للإرشاد التقني حول قوة المُصادِق. ونافذة الامتثال 180 يوماً بعد نشر القاعدة النهائية؛ وأُغلقت التعليقات في مارس 2025، مع توقّع صدور القاعدة النهائية في 2026.

FINMA (سويسرا). يتوقّع التعميم 2023/1 حول المخاطر التشغيلية والمرونة، الساري منذ 1 يناير 2024، أساليب مصادقة متناسبة مع المخاطر، مع مصادقة قوية للمستخدمين المتميزين والوصول عن بُعد. ويوسّع الملحق 3 التوقّع ليشمل مزوّدي الخدمات السحابية الذين تستخدمهم المصارف السويسرية، الذين عليهم إثبات فرض مصادقة متعددة العوامل مكافئة لفرض المصرف نفسه. وتسمّي إرشادات FINMA 05/2025، السارية في 1 يناير 2026، المصادقة متعددة العوامل المقاومة للتصيّد توقعاً لمسؤولي النظام ولأي مسار وصول قد يصل إلى بيانات العملاء أو أنظمة المصرفية الأساسية. وأشار راصد المخاطر للربع الأول من 2025 إلى المصادقة متعددة العوامل على حسابات المشغّلين والمطوّرين لدى مزوّدي المنصات السحابية المُسنَدة (outsourced) بوصفها فجوة متكررة.

ADHICS V2 (الإمارات العربية المتحدة). يُلزِم معيار دائرة الصحة في أبوظبي بالمصادقة متعددة العوامل لكل وصول إلى المعلومات الصحية المحمية، لا الإداري فحسب، بصرف النظر عن المنشأ الداخلي أو الخارجي. وتُسمّى المصادقة المقاومة للتصيّد النهج المفضّل لحسابات المشغّلين السريريين والمسؤولين. ويشترط AC 3.7 مهلات انتهاء الجلسة وإعادة المصادقة للعمليات الحساسة. والحسابات المشتركة محظورة؛ ويتطلب كل وصول إلى المعلومات الصحية المحمية هوية فريدة مع عامل ثانٍ، بما في ذلك من داخل الشبكة الموثوقة.

SAMA (المملكة العربية السعودية). يشترط النطاق 3.3.5 من إطار الأمن السيبراني فرض المصادقة متعددة العوامل بناءً على سياسات تراعي دقّتها المستخدم والمجموعة والوحدة التنظيمية والجلسة والجهاز والموقع والوقت. ويُلزِم النطاق 3.3.5.4 بمصادقة متعددة العوامل مُعزَّزة برموز عتادية للحسابات المتميزة وفصل بيانات الاعتماد المتميزة عن غير المتميزة. ويشترط النطاق 3.3.5.6 المصادقة متعددة العوامل لأي وصول إداري خارجي من طرف ثالث. وصياغة دقّة "المستخدم والمجموعة والوحدة التنظيمية والجلسة والجهاز والموقع والوقت" من بين أكثر توقعات المصادقة متعددة العوامل صراحةً لكل سياق في أي إطار، مستبقةً المصادقة القائمة على المخاطر وأنماط التصعيد بحكم التصميم.

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

أنماط الإخفاق التي تتطابق مع الفجوات المعمارية

الخروقات التي طبعت الفترة من 2022 إلى 2025 يتطابق كل منها مع إخفاق معماري محدد، وتتكرر الإخفاقات بتواتر كافٍ بحيث ينبغي قراءتها بوصفها أنماطاً لا حوادث.

كان خرق Uber في سبتمبر 2022 حالة إنهاك بالدفع. اشترى المهاجم بيانات اعتماد متعاقد، وضغط مطالبة المصادقة متعددة العوامل مراراً لأكثر من ساعة، وراسل المتعاقد على WhatsApp منتحلاً صفة دعم تقنية المعلومات في Uber. فوافق المتعاقد. وانتقل المهاجم إلى Slack الداخلي، وخزينة الوصول المتميز، و AWS، و Google Workspace، و HackerOne. والدرس المعماري أن موافقة الدفع دون مطابقة الأرقام تدرّب المستخدمين على النقر "نعم" انعكاسياً، والمهاجم يحتاج إلى نقرة واحدة فقط.

كان خرق Cisco في مايو 2022 حالة تصيّد لكلمة المرور لمرة واحدة عبر وكيل عكسي. صيّد المهاجم بيانات اعتماد Google لموظف في Cisco كانت محفوظة في Chrome ومُزامَنة من حساب شخصي، ثم هندس اجتماعياً الموظف عبر الصوت والرسائل القصيرة لقبول إشعارات الدفع للمصادقة متعددة العوامل. ونال المهاجم وصول VPN. والدرس المعماري أن TOTP والدفع المُسلَّمين عبر طقم تصيّد بوكيل عكسي (EvilProxy و Evilginx و Modlishka، يُباع كخدمة بنحو 400 دولار شهرياً على منتديات الجريمة السيبرانية) يتيح للمهاجم حصاد كلا العاملين في الوقت الفعلي وإعادة تشغيلهما.

كان خرق Reddit في فبراير 2023 حالة تصيّد موجّه. قدّم مهاجم صفحة هبوط تحاكي بوّابة شبكة Reddit الداخلية. أدخل الموظف بيانات الاعتماد وكلمة المرور لمرة واحدة. ونال المهاجم وثائق داخلية وشِفرة مصدرية. وكانت المصادقة متعددة العوامل المقاومة للتصيّد لتمنعه لأن تأكيد WebAuthn ما كان ليُصدَّق على أصل التصيّد.

كان اختراقا MGM Resorts و Caesars Entertainment في سبتمبر 2023 حالتي هندسة اجتماعية لمكتب المساعدة. انتحلت مجموعة Scattered Spider صفة موظفين رُفعت تفاصيلهم من LinkedIn، واتصلت بمكتب الخدمة، وطلبت إعادة تعيين كلمة المرور وإعادة تعيين المصادقة متعددة العوامل. وأجرى مكتب المساعدة عمليات إعادة التعيين دون إثبات هوية خارج النطاق. ودفعت Caesars نحو 15 مليون دولار؛ وأفصحت MGM عن أثر تشغيلي يبلغ نحو 100 مليون دولار في الربع الثالث من 2023 عبر عمليات الغرف وماكينات القمار ومفاتيح الفنادق والحجز عبر الإنترنت. والدرس المعماري أن تدفق استرداد المصادقة متعددة العوامل هو سطح الهجوم الجديد. والمتطلب 8.5.1(ب) من PCI DSS 4.0.1 ("لا يمكن تجاوز المصادقة متعددة العوامل من قِبل أي مستخدمين بمن فيهم المستخدمون الإداريون") هو استجابة الأطر.

كان اقتحام Microsoft Midnight Blizzard في نوفمبر 2023، المُفصَح عنه في يناير 2024، حالة حساب قديم. اخترقت APT29 حساب اختبار في مستأجر غير إنتاجي لم تكن المصادقة متعددة العوامل مفعّلة فيه عبر رشّ كلمات المرور، ثم أساءت استخدام تطبيق OAuth بامتيازات مرفوعة للانتقال إلى Exchange Online المؤسسي. والدرس المعماري أن "لدينا مصادقة متعددة العوامل مفروضة على نطاق المؤسسة" بلا معنى إذا استمرت حسابات الاستثناء؛ فحسابات الاختبار والحسابات القديمة وحسابات الخدمة المنسية بلا مصادقة متعددة العوامل هي ناقل الدخول الأكثر شيوعاً.

كان خرق Change Healthcare في فبراير 2024 حالة غياب تام للمصادقة متعددة العوامل. استخدمت BlackCat بيانات اعتماد Citrix مسروقة على بوّابة وصول عن بُعد بلا مصادقة متعددة العوامل. وشهد الرئيس التنفيذي لـ UnitedHealth أمام لجنة المالية في مجلس الشيوخ الأمريكي بأن بيانات الاعتماد المخترقة كانت لبوّابة Citrix لم تكن لديها مصادقة متعددة العوامل. وتأثّر نحو 190 مليون أمريكي؛ وأُبلغ عن تكلفة إجمالية تبلغ نحو 2.45 مليار دولار عبر إفصاحات 2024. والدرس المعماري أن بوّابة وصول عن بُعد واحدة بلا مصادقة متعددة العوامل تستطيع اختراق البنية التحتية للمدفوعات في صناعة بأكملها.

كانت اختراقات عملاء Snowflake في مايو ويونيو 2024 حالات مستأجر مُعطّل افتراضياً. استخدمت مجموعة المهاجمين UNC5537 بيانات اعتماد حصدتها برمجيات سرقة المعلومات من 2020 حتى 2024 لتسجيل الدخول إلى نحو 165 مستأجراً من عملاء Snowflake. ولم تكن Snowflake تفرض المصادقة متعددة العوامل افتراضياً على حسابات العملاء في ذلك الوقت. وشمل الضحايا Ticketmaster (560 مليون سجل)، و AT&T (110 ملايين سجل لبيانات المكالمات والرسائل الوصفية)، و Santander، و Advance Auto Parts، و Neiman Marcus، و LendingTree. وانتقلت Snowflake إلى المصادقة متعددة العوامل افتراضياً للحسابات الجديدة في يوليو 2024 وأعلنت المصادقة متعددة العوامل الإلزامية للمستخدمين البشر بحلول نوفمبر 2025. والدرس المعماري أن المصادقة متعددة العوامل المُعطّلة افتراضياً على مستوى المنصة تنقل مخاطر التهيئة إلى العميل، وكثير من العملاء لا يهيّئونها.

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

نقاط الضعف الأربع التي لا تزال معظم المنصات تتركها مفتوحة

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

الأولى حسابات الخدمة والهويات غير البشرية. أشار تقرير CrowdStrike للتهديدات العالمية لعام 2024 إلى إساءة استخدام الحسابات الصالحة في غالبية الاقتحامات، وتظهر حسابات الخدمة على نحو غير متناسب لأنها غالباً ما تكون مُعفاة من سياسات المصادقة متعددة العوامل والتدوير. ويعالج المتطلب 8.6 من PCI DSS 4.0.1 هذا لبيئات حاملي البطاقات تحديداً: الاستخدام التفاعلي لحسابات النظام والتطبيق والخدمة يجب أن يُدار، ويجب ألا يحمل بيانات اعتماد مُرمّزة بشكل ثابت في النصوص البرمجية أو ملفات التهيئة، ويجب أن يكون له تدوير لكلمة المرور قائم على تحليل المخاطر. والإجابة المعمارية هي هويات أعباء عمل قصيرة الأجل: AWS IAM Roles for Service Accounts على EKS، و AWS IAM Roles Anywhere لأعباء العمل في الموقع (قائمة على شهادات X.509، بلا مفاتيح وصول طويلة الأجل)، و GCP Workload Identity Federation، و Azure Managed Identities، أو SPIFFE/SPIRE التي تُصدر SVIDs قصيرة الأجل. ويلغي النمط مفتاح API الطويل الأجل بوصفه فئة بيانات اعتماد.

الثانية تدفق الاسترداد والتجاوز. المتطلب 8.5.1(ب) من PCI DSS 4.0.1 مباشر: لا يمكن تجاوز المصادقة متعددة العوامل من قِبل أي مستخدمين بمن فيهم المستخدمون الإداريون. وتدفقات الاسترداد التي ترتدّ إلى روابط البريد السحرية أو أسئلة الأمان أو رموز الاسترداد عبر الرسائل القصيرة فقط غير ممتثلة بنيوياً ما لم تُقرَن بإدارة استثناءات موثّقة. والإجابة المعمارية هي اشتراط عامل مقاوم للتصيّد عند الاسترداد (مفتاح أمان عتادي ثانٍ مُسجّل عند التسجيل، رموز استرداد مطبوعة مخزّنة مادياً) واشتراط تحقق خارج النطاق عبر مكالمة فيديو مع مطابقة صورة هوية أو تحقق شخصي للأدوار عالية المخاطر. وتحتاج حسابات الطوارئ (break-glass) إلى توثيق صريح، وتقسيم بيانات الاعتماد بين حاملين من الأمن ومن الإدارة التنفيذية، وتخزين مختوم يكشف العبث في خزنة، وتنبيه تدقيق على كل استخدام، ومصادقة متعددة العوامل عبر مفتاح أمان عتادي مخزّن مع بيانات الاعتماد.

الثالثة تجديد الجلسة. رموز تحديث OAuth 2.0 رموز حاملة (bearer)؛ وإذا سُرّبت، تتيح للمهاجم الاحتفاظ بجلسة إلى أجل غير مسمّى. والإجابة المعمارية هي إبطال الرموز عند أحداث المخاطر واشتراط إعادة المصادقة على فترات. وتنفّذ هذا النمط جميعها Microsoft Entra Continuous Access Evaluation، و AWS IAM Identity Center، و Okta Identity Threat Protection، مع إبطال الرمز خلال دقائق من حدث مخاطر مثل سفر مستحيل، أو تغيير كلمة المرور، أو تغيير امتثال الجهاز.

الرابعة المصادقة المُصعَّدة للعمليات الحساسة. ينبغي اشتراط إعادة المصادقة لتصدير البيانات، وتدوير المفاتيح، وإسناد الأدوار، وتغيير الفوترة، وحذف الحساب، وتفعيل الأدوار المتميزة، بصرف النظر عن عمر الجلسة. وتفعيل Azure AD Privileged Identity Management، و"الوصول إلى API المحمي بالمصادقة متعددة العوامل" في AWS IAM باستخدام شرط aws:MultiFactorAuthAge، و"وضع sudo" في GitHub للعمليات الحساسة على المستودعات هي الأنماط المرجعية. ويقرأ الطرف المعتمِد ادعاءي amr و acr من رمز مزوّد الهوية ويعيد اشتراط المصادقة إذا كانت القوة أو الحداثة المؤكَّدة غير كافية.

الإجابة المعمارية

تعامل نوفانترا المصادقة متعددة العوامل بوصفها نية تصميم بمستوى 2026 لا ميزةً مُعاد تكييفها، والالتزامات أدناه هي الإجابة المعمارية خلفها.

تفرض نوفانترا المصادقة متعددة العوامل على كل مسار تسجيل دخول، بما في ذلك الدخول الموحّد (SSO) المتحد مع تحقق الطرف المعتمِد من ادعاءي amr و acr بدلاً من قبول أي جلسة مُصادَق عليها. وعوامل مقاومة للتصيّد (مفاتيح FIDO2/WebAuthn العتادية، ومفاتيح المرور للمنصة عند المستوى 2، و PIV في السياقات الفيدرالية) بوصفها المسار المُوصى به، مع توفر TOTP والرسائل القصيرة فقط مع اشتراك صريح وتحذير تدقيقي. ولا تجاوز عند إخفاق العامل الثاني؛ ولا ارتداد إلى عوامل أضعف. وفرض على نطاق المستأجر يغطّي حسابات الاختبار والقديمة والخدمة والطوارئ دون استثناء، مع تقرير على نطاق المستأجر قابل للتصدير عند الطلب يُظهر أي الحسابات مفعّلة فيها المصادقة متعددة العوامل، ونوع العامل، وآخر تحدٍّ ناجح وفاشل.

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

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

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