ثلاثة ضوابط أصبحت شروطاً أساسية للدخول في شراء البرمجيات الخاضعة للتنظيم، وأصبحت كذلك وفق جدول زمني مضغوط على نحو غير معتاد. المصادقة متعددة العوامل على كل تسجيل دخول. تشفير البيانات أثناء سكونها وأثناء نقلها افتراضياً. مسارات تدقيق يمكن إثبات سلامتها تشفيرياً. قبل خمس سنوات، كان كل من الثلاثة ميزةً تضعها في قائمة أسعار الفئة المؤسسية. واليوم، يظهر كل من الثلاثة بوصفه متطلباً إلزامياً في كل إطار رئيسي يتعيّن على المؤسسة الخاضعة للتنظيم الامتثال له، والإيقاع الذي تحرّكت به جميعها لافت بما يكفي ليستحق التسمية.
النافذة الممتدة ثمانية عشر شهراً من أكتوبر 2024 إلى يوليو 2025 هي حين اكتمل التقارب. فقد صدرت لائحة التنفيذ للمفوضية (الاتحاد الأوروبي) 2024/2690 الخاصة بـ NIS2 في 17 أكتوبر 2024، مُترجِمةً المادة 21 إلى ما يزيد على 150 ضابطاً قابلاً للتدقيق. وبدأت بوّابة Microsoft Azure بفرض المصادقة متعددة العوامل في 15 أكتوبر 2024. ونُشر مشروع القاعدة المقترحة (NPRM) لقاعدة الأمن في HIPAA في 27 ديسمبر 2024، مزيلاً تمييز "القابل للمعالجة" مقابل "المطلوب" بالكامل. وأصبحت الضوابط المؤجَّلة التاريخ في PCI DSS 4.0.1، بما فيها المصادقة متعددة العوامل الشاملة لبيئة بيانات حاملي البطاقات، إلزامية في 31 مارس 2025. وأُغلقت نافذة الانتقال من ISO 27001:2013 في 31 أكتوبر 2025، تاركةً ISO 27001:2022 وحده بتوقعاته الصريحة للمصادقة متعددة العوامل وتشديده على التشفير. وصدرت النسخة النهائية من NIST SP 800-63B-4 في يوليو 2025، مُحكِمةً المصادقة متعددة العوامل المقاومة للتصيّد عند مستويي ضمان المصادقة 2 و3. ووسّعت AWS فرض المصادقة متعددة العوامل لحساب الجذر إلى حسابات الأعضاء في المؤسسة في 17 يونيو 2025. والموعد النهائي للامتثال لـ ADHICS V2 في الربع الرابع من 2025. وإرشادات FINMA رقم 05/2025 السارية في 1 يناير 2026.
الضوابط الثلاثة ذاتها. ثمانية عشر شهراً. تسعة أطر عبر ست ولايات قضائية. لقد تحوّل سؤال الشراء من "هل لديك هذه" إلى "هل صُمّمت داخل النظام أم رُكّبت عليه"، لأن كل مشترٍ خاضع للتنظيم يُطلب منه إثباتها، ومورّد المشتري إما أن يجعل ذلك سهلاً أو يجعله مستحيلاً.
التحوّل: ثلاثة ضوابط، ثمانية عشر شهراً، كل إطار رئيسي
التقارب ليس أداة سردية. إنه حدث تقويمي بتواريخ سريان مسمّاة. لكل من الضوابط الثلاثة مساره الخاص عبر أدبيات الأطر، وانتهى كل منها إلى المكان ذاته في الوقت ذاته تقريباً.
تحرّكت المصادقة متعددة العوامل من توصية لـ NIST عام 2017 بشأن إيقاف الرسائل القصيرة (SMS) بوصفها عاملاً خارج النطاق، مروراً بمتطلب PCI DSS 3.2.1 عام 2018 الذي غطّى الوصول الإداري فقط لبيئة بيانات حاملي البطاقات، إلى تفويض OMB M-22-09 عام 2022 بالمصادقة متعددة العوامل المقاومة للتصيّد عبر الوكالات المدنية الفيدرالية الأمريكية، إلى مراجعة ISO 27001 عام 2022 التي جعلت المصادقة متعددة العوامل صريحة في الملحق A.8.5، وأخيراً إلى تاريخ سريان المصادقة متعددة العوامل الشاملة في PCI DSS 4.0.1 في 31 مارس 2025 والنشر النهائي لـ NIST SP 800-63B-4 في يوليو 2025 الذي أحال فعلياً العوامل القابلة للتصيّد إلى التقاعد عند مستوى ضمان المصادقة 2 وما فوقه. وفرضها مزوّدو السحابة بالتوازي: المصادقة متعددة العوامل إلزامية في بوّابة Microsoft Azure منذ 15 أكتوبر 2024، والمصادقة متعددة العوامل لحساب الجذر على حسابات الإدارة في AWS في مايو 2024 وحسابات الأعضاء في يونيو 2025، وفرض التحقق بخطوتين (2SV) في Google Workspace عبر الإصدارات في 2024.
اتبع التشفير قوساً أبطأ لكنه وصل إلى النقطة ذاتها. فقد سمّت المادة 32(1)(أ) من GDPR "إخفاء الهوية الجزئي وتشفير البيانات الشخصية" مثالاً على إجراء مناسب منذ 2018. وحوّل المجلس الأوروبي لحماية البيانات (EDPB) والسلطات الإشرافية الوطنية ذلك المثال إلى حد أدنى إنفاذي عبر غرامات 2023 و2024، بما فيها عقوبة الغارانتي الإيطالي البالغة 79 مليون يورو بحق ENEL Energia مستندةً إلى المادتين 5(1)(و) و32. وأصبحت متطلبات تشفير البيانات المخزّنة والمنقولة في PCI DSS 4.0.1 (المتطلبان 3 و4، بحد أدنى AES-128 وبشكل نمطي AES-256، و TLS 1.2 أو أعلى) مفروضةً بالكامل في 31 مارس 2025. ونشرت NIST أولى معايير التشفير ما بعد الكَمّي (FIPS 203 ML-KEM و FIPS 204 ML-DSA و FIPS 205 SLH-DSA) في 13 أغسطس 2024، ويُلزِم الجدول الزمني لـ CNSA 2.0 الآن باستخدام خوارزميات مقاومة للكَمّ في أنظمة الأمن القومي الأمريكية الجديدة بحلول 1 يناير 2027. وجعل مشروع القاعدة المقترحة لـ HIPAA تشفير المعلومات الصحية الإلكترونية المحمية أثناء السكون والنقل إلزامياً، مزيلاً الاستثناء القابل للمعالجة. وتبعت ذلك الإعدادات الافتراضية لمزوّدي السحابة: شفّر S3 الكائنات الجديدة افتراضياً منذ يناير 2023، ويشفّر Google Cloud Storage افتراضياً مع خيار المفاتيح المُدارة من العميل على كل خدمة.
تحرّكت سلامة مسار التدقيق أخيراً وأسرع. فقد دمجت مراجعة ISO 27001 عام 2022 ضوابط التسجيل الثلاثة لعام 2013 (من A.12.4.1 إلى A.12.4.3) في ضابط واحد هو A.8.15 مع حماية صريحة من التلاعب بالسجلات. وأصبح المتطلب 10.3.2 من PCI DSS 4.0.1 ("حماية ملفات سجل التدقيق لمنع التعديلات من قِبل الأفراد") والمتطلب 10.3.4 (مراقبة سلامة الملفات مع التنبيه عند التعديل) إلزاميين في 31 مارس 2025. ويدعو كل من ملحق لائحة التنفيذ 2024/2690 الخاصة بـ NIS2 وإرشادات التنفيذ التقنية الصادرة عن ENISA إلى الحماية التشفيرية للسجلات حيثما كان مناسباً. أما الحماية التشفيرية لمعلومات التدقيق في NIST SP 800-53 AU-9(3) فقد كانت مدوّنة منذ سنوات؛ والفرق في 2025 أن مقيّمي 3PAO التابعين لـ FedRAMP باتوا يشيرون إليها بشكل روتيني. تتناول المقالتان المرافقتان حول الأدلة المستمرة ومسارات التدقيق المقاومة للعبث تحوّل سلامة سجلات التدقيق بالتفصيل.
النمط عبر الثلاثة جميعها: وصل كل إطار رئيسي إلى المتطلب التشغيلي ذاته خلال ثمانية عشر شهراً، بتواريخ سريان متداخلة متجمّعة بين أكتوبر 2024 ونهاية 2025. التحوّل ليس قادماً. لقد حدث.
المصادقة متعددة العوامل: من المسؤول فقط إلى كل مكان، والآن مقاومة للتصيّد
لا تزال معظم المنصات التي تقدّم المصادقة متعددة العوامل في 2026 تقدّم النسخة التي بدأت الجهات التنظيمية بشطبها من الأطر. كلمات مرور لمرة واحدة قائمة على الوقت تُسلَّم إلى تطبيق مصادقة. رموز الرسائل القصيرة. إشعارات الدفع دون مطابقة الأرقام. كلٌّ منها قابل للتجاوز على نطاق واسع: يشير تقرير Verizon للتحقيقات في خروقات البيانات لعام 2025 صراحةً إلى المصادقة متعددة العوامل عبر الدفع وكلمات المرور لمرة واحدة ومطابقة الأرقام بوصفها "متجاوَزة على نطاق واسع" ويشير إلى بدائل مقاومة للتصيّد. ووجد التقرير أن بيانات الاعتماد المخترقة كانت ناقل الوصول الأولي في 22% من الخروقات المُحلّلة وأن 88% من الهجمات على تطبيقات الويب الأساسية شملت بيانات اعتماد مسروقة. وقد نُشر نحو 2.8 مليار كلمة مرور على الأسواق الإجرامية في عام 2024 وحده.
تقاربت استجابة الأطر على المصادقة متعددة العوامل المقاومة للتصيّد: بيانات اعتماد مرتبطة بالعتاد باستخدام FIDO2 و WebAuthn، أو بطاقات PIV الذكية في السياقات الفيدرالية، مع نية مستخدم صريحة ومفاتيح خاصة غير قابلة للتصدير. وكانت ورقة الحقائق الصادرة عن CISA في أكتوبر 2022 مباشرةً: "المصادقة الوحيدة المقاومة للتصيّد المتاحة على نطاق واسع هي مصادقة FIDO/WebAuthn". وفرض OMB M-22-09 المصادقة متعددة العوامل المقاومة للتصيّد عبر الوكالات المدنية الفيدرالية الأمريكية. ويشترط NIST SP 800-63B-4، الذي صدرت نسخته النهائية في يوليو 2025، أن يقدّم مستوى ضمان المصادقة 2 خياراً مقاوماً للتصيّد وأن يستخدم مستوى ضمان المصادقة 3 مُصادِقاً مقاوماً للتصيّد بمفتاح خاص غير قابل للتصدير.
الصورة عبر الأطر في 2026، مروراً بالأطر الدولية والغربية قبل منطقة الشرق الأوسط وشمال إفريقيا: المادة 32 من GDPR التي شدّدتها ممارسة EDPB لتصبح توقعاً أساسياً للمصادقة متعددة العوامل للأنظمة التي تعالج البيانات الشخصية، لا سيما الوصول عن بُعد والوصول الإداري. والمادة 21(2)(ي) من NIS2 التي تسمّي صراحةً "استخدام المصادقة متعددة العوامل أو حلول المصادقة المستمرة" تدبيراً أدنى، مع تفصيل لائحة التنفيذ 2024/2690 للضوابط التقنية. ويوجّه ISO 27001:2022 A.8.5 المصادقة الآمنة المنفّذين إلى استخدام المصادقة متعددة العوامل وعدم الكشف عن العامل الذي أخفق أثناء تسجيل دخول فاشل. ويشير SOC 2 CC6.1 صراحةً إلى المصادقة متعددة العوامل للوصول المتميز والوصول عن بُعد في نقاط التركيز المنقّحة لعام 2022. ويُلزِم المتطلب 8.4.2 من PCI DSS 4.0.1 بالمصادقة متعددة العوامل لكل وصول إلى بيئة بيانات حاملي البطاقات (لا الإداري فحسب) ويضع المتطلب 8.5 متطلبات تهيئة النظام دون أي تجاوز عند إخفاق العامل الثاني. ويغطّي NIST SP 800-53 IA-2(1) الحسابات المتميزة و IA-2(2) الحسابات غير المتميزة. وينقل مشروع القاعدة المقترحة لـ HIPAA في ديسمبر 2024 المصادقة متعددة العوامل من القابلة للمعالجة إلى المطلوبة، مع متطلبات حماية صريحة لأي إجراء يغيّر امتيازات المستخدم أو الوصول إلى المعلومات الصحية المحمية. ويتوقّع تعميم FINMA 2023/1 المصادقة متعددة العوامل للوصول المتميز والوصول عن بُعد بما يتسق مع وضعية المرونة التشغيلية الأوسع. ويُلزِم ADHICS V2 بالمصادقة متعددة العوامل لكل وصول إلى المعلومات الصحية المحمية، لا الإداري فحسب. ويشترط النطاق 3.3.5 من إطار الأمن السيبراني لـ SAMA مصادقة متعددة العوامل وسياسات وصول دقيقة لكل مستخدم ومجموعة ووحدة تنظيمية، بسياسات تتباين بحسب نوع الجلسة والجهاز والموقع والوقت.
يُعدّ خرق Change Healthcare في فبراير 2024 المثال الأكثر إفادةً عن تكلفة الغياب في هذه الحقبة. فقد استخدمت برمجية الفدية BlackCat بيانات اعتماد Citrix مسروقة على بوّابة بلا مصادقة متعددة العوامل، مؤثرةً في نهاية المطاف في نحو 190 مليون أمريكي، وهو أكبر خرق في قطاع الرعاية الصحية في تاريخ الولايات المتحدة. وكان رئيس الأمن السيبراني في UnitedHealth Group نفسه على علم بغياب المصادقة متعددة العوامل عن تلك البوّابة رغم سياسة الشركة. وأُبلغ عن تكلفة الهجوم المباشرة على UnitedHealth بنحو 872 مليون دولار، مع تجاوز الضرر الاقتصادي عبر نظام مدفوعات الرعاية الصحية الأمريكي لذلك. وتتبّع اختراقات عملاء Snowflake خلال 2024 (Ticketmaster و AT&T و Santander و Advance Auto Parts، من بين نحو 165 بيئة متأثرة) النمط ذاته: مصادقة متعددة العوامل غائبة أو ضعيفة على حسابات المستأجرين، ودخول المهاجمين عبر بيانات اعتماد مسروقة. وانتقلت Snowflake لاحقاً نحو فرض المصادقة متعددة العوامل افتراضياً للحسابات الجديدة. وطالما استشهدت Microsoft ببيانات داخلية تفيد بأن المصادقة متعددة العوامل تحجب أكثر من 99.2% من هجمات اختراق الحسابات؛ والخروقات التي وقعت بالفعل أصابت بأغلبية ساحقة الجزء الصغير الذي لا يملكها.
التشفير: من القابل للمعالجة إلى المطلوب
التشفير هو الضابط الذي صمدت فيه استثناءات "القابل للمعالجة" أطول مدة وأُزيلت الآن في كل مكان تقريباً. فقد جعلت قاعدة الأمن في HIPAA تشفير المعلومات الصحية الإلكترونية المحمية "قابلاً للمعالجة" عام 2003، وهو ما فسّرته كيانات مشمولة كثيرة بأنه "اختياري إذا وُثّق"، واستمرت الممارسة عقدين من الزمن. ويُلغي مشروع القاعدة المقترحة في ديسمبر 2024 ذلك التفسير: يصبح التشفير أثناء السكون والنقل مطلوباً لكل المعلومات الصحية الإلكترونية المحمية، مع استثناءات محدودة.
صورة الأطر عبر التشفير في 2026: تسمّي المادة 32(1)(أ) من GDPR "إخفاء الهوية الجزئي وتشفير البيانات الشخصية" تدبيراً تقنياً مناسباً، مع توفير إرشادات EDPB 01/2025 بشأن إخفاء الهوية الجزئي (المعتمدة في يناير 2025) أول تفسير تقني مفصّل لما يتطلبه إخفاء الهوية الجزئي فعلاً (فصل المعلومات الإضافية، والضوابط التشفيرية، وإدارة المفاتيح). وتشترط المادة 21(2)(ح) من NIS2 "سياسات وإجراءات بشأن استخدام التشفير، وحيثما كان مناسباً، التعمية"، مع تفصيل لائحة التنفيذ 2024/2690 لما يعنيه ذلك عملياً. ويوحّد ISO 27001:2022 A.8.24 استخدام التشفير ضوابط 2013 وهو صريح بشأن دورة حياة إدارة المفاتيح. ويشترط SOC 2 CC6.7 التشفير أثناء النقل والحركة وإزالة المعلومات السرية. ويُلزِم المتطلب 3 من PCI DSS 4.0.1 بتشفير بيانات الحساب المخزّنة (رقم الحساب الأساسي غير قابل للقراءة، بحد أدنى AES-128 وبشكل نمطي AES-256)، ويشترط المتطلب 4 استخدام TLS 1.2 أو أعلى للنقل مع حظر TLS 1.0/1.1. ويغطّي NIST SP 800-53 SC-8 سرية وسلامة النقل و SC-13 الحماية التشفيرية (المُصادَق عليها وفق FIPS). ويجعل مشروع القاعدة المقترحة لـ HIPAA تشفير المعلومات الصحية الإلكترونية المحمية أثناء السكون والنقل إلزامياً. ويتوقّع تعميم FINMA 2023/1 مصادقةً قويةً لوحدات التشفير وحمايةً للاتصالات متوائمةً مع الحدود الدنيا الدولية. ويُلزِم ADHICS V2 باستخدام AES-256 للمعلومات الصحية المحمية أثناء السكون والنقل، مع إدارة مفاتيح مدعومة بوحدة أمان عتادية (HSM) أو نظام إدارة مفاتيح (KMS) وحوكمة صارمة للمفاتيح. ويُلزِم النطاق 3.3.6 لـ SAMA باستخدام AES-256 للبيانات أثناء السكون (تشفير قاعدة البيانات والقرص) و AES-256 مع TLS 1.2 أو أعلى أثناء النقل، مع HSM أو KMS قوي للمفاتيح.
أصبح الانتقال إلى ما بعد الكَمّي الآن الموعد النهائي الذي يلوح في الأفق. فقد أصدرت NIST أولى معايير التشفير ما بعد الكَمّي في 13 أغسطس 2024 (FIPS 203 ML-KEM لتغليف المفاتيح، و FIPS 204 ML-DSA للتوقيعات الرقمية، و FIPS 205 SLH-DSA بديلاً قائماً على التجزئة). وتشترط مراحل CNSA 2.0 أن تمتثل عمليات نشر أنظمة الأمن القومي الأمريكية الجديدة لـ CNSA 2.0 بحلول 1 يناير 2027، والهجرة الكاملة لأنظمة الأمن القومي بحلول 2030، والإنفاذ الكامل بنهاية 2031، وأن تكون كل أنظمة الأمن القومي مقاومة للكَمّ بحلول 2035. وتُدخِل تعديلات NIS2 لعام 2026 سياسات هجرة التشفير ما بعد الكَمّي مستهدفةً الإنجاز بين 2030 و2035. والمنصات القادرة على تدوير الخوارزميات وأنواع المفاتيح دون إعادة بناء من الصفر ستجتاز الهجرة؛ أما المنصات التي رمّزت خيارات الخوارزميات بشكل ثابت في طبقة تخزينها فستواجه مشروع إعادة بناء للمنصة. تتناول المقالة المرافقة حول مفاتيح التشفير التي يتحكم بها العميل المرونة التشفيرية بوصفها توقعاً لـ NIS2 بالتفصيل.
مسارات التدقيق: من "سجّل كل شيء" إلى "أثبت السلامة"
سلامة مسار التدقيق هي الضابط الثالث المتقارب وصاحب أحدّ منحدر داخل النافذة. تستعرض المقالة المرافقة حول مسارات التدقيق المقاومة للعبث البدائيات التشفيرية بعمق. وخلاصة قصة التقارب هي أن كل إطار بات يشترط الآن لا مجرد وجود السجلات، بل إمكان إثبات سلامة السجل نفسه. ويجعل ISO 27001:2022 A.8.15 حماية التلاعب بالسجلات صريحة. ويحظر المتطلب 10.3.2 من PCI DSS 4.0.1 تعديل ملفات سجل التدقيق من قِبل الأفراد ويشترط المتطلب 10.3.4 مراقبة سلامة الملفات مع التنبيه. ويسمّي NIST SP 800-53 AU-9(3) دوال التجزئة الموقّعة الآلية التشفيرية المعترف بها. ويُحكِم مشروع القاعدة المقترحة لـ HIPAA الاحتفاظ بسجلات التدقيق وحماية سلامتها. وتشترط لائحة التنفيذ 2024/2690 الخاصة بـ NIS2 حماية السجلات من الوصول والتعديل غير المصرح بهما؛ وتضيف إرشادات ENISA أن السلامة ينبغي أن تكون قابلة للتحقق بوسائل تشفيرية حيثما كان مناسباً. ويشترط تعميم FINMA 2023/1 تسجيلاً شاملاً وموثوقاً مع حماية للسلامة على مدى فترة احتفاظ مصرفية تبلغ عشر سنوات. ويُلزِم ADHICS V2 بتسجيل مدمج مع نظام إدارة معلومات الأمن والأحداث (SIEM) مع حماية من الوصول أو التعديل أو الإتلاف غير المصرح به. ويشترط النطاق 3.3.14.1 لـ SAMA أن تُعرَّف سجلات الأحداث وتُولَّد ويُحتفظ بها وتُحمى من التغييرات غير المصرح بها وتُراجَع بانتظام.
التقارب على سلامة مسار التدقيق هو ما يجعل الضابطين الأولين قابلين للقياس. فالمصادقة متعددة العوامل قوية بقدر قوة الدليل على أنها انخرطت فعلاً في كل محاولة تسجيل دخول خلال نافذة التدقيق. والتشفير قوي بقدر قوة الدليل على من استخدم المفتاح ومتى. وكلا الدليلين يقيمان في مسار التدقيق. والمنصة التي تملك المصادقة متعددة العوامل والتشفير لكنها لا تستطيع إثبات مسار تدقيق أيّ منهما تطلب من الجهة التنظيمية فعلياً أن تأخذ الضوابط على الثقة. وقد أُحيلت تلك الوضعية إلى التقاعد عبر الأطر في الوقت ذاته الذي أصبحت فيه الضوابط نفسها إلزامية.
الأسئلة التي تميّز "الشروط الأساسية" عن "نية التصميم"
تحوّل سؤال الشراء بطريقة محددة. كان يُطرح "هل تدعم المصادقة متعددة العوامل والتشفير وسجلات التدقيق"، بإجابات مربعات اختيار مقبولة. وقد أصبح الآن "هل تستطيع إثبات كل من الثلاثة، عند الطلب، بطريقة يمكن للمدقق التحقق منها". قائمة تحقق قصيرة وغير مريحة لأي فريق يقيّم منصة في 2026.
- فرض المصادقة متعددة العوامل، مقاومة للتصيّد افتراضياً. هل المصادقة متعددة العوامل على كل تسجيل دخول، بما في ذلك مزوّدو الهوية المتحدون (federated)، مع خيارات مقاومة للتصيّد (FIDO2 و WebAuthn ومفاتيح الأمان العتادية) بوصفها المسار المُوصى به؟ هل العوامل الضعيفة (الرسائل القصيرة، والدفع دون مطابقة الأرقام، وكلمات المرور لمرة واحدة عبر البريد الإلكتروني) اختياريةٌ مع تحذير على الأقل لا افتراضية؟ هل تستطيع المنصة إنتاج سجل تدقيق لكل تحدٍّ للمصادقة متعددة العوامل أُطلق ولكل تحدٍّ لم يُطلق، مع السبب؟
- التشفير مع حفظ المفاتيح بتحكم العميل. هل تُشفَّر البيانات أثناء السكون بـ AES-256 وأثناء النقل بـ TLS 1.2 أو أعلى؟ والأهم، من يحفظ المفتاح؟ المنصة التي تحفظ المفتاح لديها حدّ ثقة لا يستطيع العميل إلغاؤه دون الاتصال بالمورّد. وقد دفعت إرشادات EDPB لما بعد Schrems II والأطر المرافقة حفظ المفاتيح نحو العميل لأي عبء عمل حساس.
- سلامة مسار التدقيق، قابلة للإثبات عبر التصدير. هل تستطيع المنصة إنتاج تصدير يكشف العبث لمسار التدقيق لسجل محدد، ولفترة محددة، مع تحقق تشفيري؟ تتناول المقالة المرافقة حول مسارات التدقيق المقاومة للعبث البدائيات.
- المرونة التشفيرية للهجرة إلى ما بعد الكَمّي. هل تستطيع المنصة تدوير الخوارزميات (الانتقال من RSA-2048 إلى ML-KEM، ومن ECDSA إلى ML-DSA) دون إعادة بناء من الصفر؟ تتوقّع المادة 21 من NIS2 ذلك؛ ويفرضه الجدول الزمني لـ CNSA 2.0؛ والمنصات التي رمّزت خيارات الخوارزميات بشكل ثابت ستواجه مشروع إعادة بناء للمنصة وفق موعد نهائي.
- الثلاثة جميعها معروضة بوصفها قابلة للتهيئة والتدقيق والتصدير، لا بوصفها ادعاءات تسويقية. المنصة التي تدعم المصادقة متعددة العوامل والتشفير وتسجيل التدقيق في الإنتاج لكنها لا تستطيع عرض تهيئة أيٍّ منها أو تدقيقه أو تصديره للعميل قد بنت الضوابط لنفسها، لا للجهة التنظيمية للعميل.
المنصة التي تجيب عن كل سؤال بمصنوع معماري بدلاً من فقرة إنشائية تُنتج الضوابط بوصفها نية تصميم. والمنصة التي تطلب وقتاً لـ"دراسة التفاصيل" تُنتج الضوابط بوصفها سطحاً تسويقياً.
الإجابة المعمارية
تحوّل الضوابط الثلاثة إلى شروط أساسية في وقت واحد هو تحوّل تقوده الجهات التنظيمية، والمنصات التي تتعامل معه جيداً تعامل كل واحد من الثلاثة بوصفه خاصية بنيوية للنظام، لا ميزة على خارطة طريق. بُنيت نوفانترا على هذا الأساس: المصادقة متعددة العوامل والتشفير والتدقيق معمارية أساسية، لا ميزات مُركّبة على فئة سعرية.
مصادقة متعددة العوامل إلزامية منذ اليوم الأول، على كل نوع من حسابات نوفانترا، مع خيارات مقاومة للتصيّد بوصفها المسار المُوصى به. مصادقة متعددة العوامل لمسؤول التثبيت عند أول تسجيل دخول دون إمكان الانسحاب. تكامل مع مزوّد الهوية المتحد يحافظ على فرض المصادقة متعددة العوامل بدلاً من معاملة الدخول الموحّد (SSO) بوصفه إعفاءً. دعم مفاتيح الأمان العتادية (FIDO2 و WebAuthn) بدرجة مستويي ضمان المصادقة 2 و3. سياسة كلمة مرور لكل مؤسسة وربط الجلسات بالحالات التي تكون فيها العوامل الإضافية مناسبة. تتناول المقالة المرافقة في السجل حول المصادقة متعددة العوامل بوصفها الأساس الذي لم يعد اختيارياً تفاصيل التنفيذ.
تشفّر نوفانترا افتراضياً في كل مكان حساس، مع مفاتيح يتحكم بها العميل بوصفها التزاماً معمارياً. AES-256 أثناء السكون، و TLS 1.2 أو أعلى أثناء النقل، مع تغليف المفتاح الرئيسي تحت مزوّد يديره العميل: AWS KMS في حساب العميل، و Azure Key Vault تحت اشتراك العميل، و HashiCorp Vault Transit على بنية العميل التحتية، ووحدات الأمان العتادية PKCS#11 تحت تشغيل العميل المباشر. عزل مفاتيح لكل مؤسسة بحيث لا تستطيع مفاتيح عميل واحد فك تشفير بيانات عميل آخر. مرونة تشفيرية مُصمَّمة داخل النظام بحيث تكون الهجرة إلى ما بعد الكَمّي تغييراً في التهيئة، لا إعادة كتابة. تتناول المقالة المرافقة حول مفاتيح التشفير التي يتحكم بها العميل المعمارية بالتفصيل.
تدفّق التدقيق لدى نوفانترا هو تدفق أحداث مُسلسَل بالتجزئة يكشف العبث، قابل للتصدير عند الطلب، قابل للتحقق من قِبل المدقق دون تعاون المورّد. أحداث للإلحاق فقط، مُسلسَلة بالتجزئة عند الورقة، وجذور Merkle موقّعة على كل نافذة، وترسيخ خارجي اختياري لأعلى فئة ضمان. تخزين مدعوم بتقنية الكتابة لمرة واحدة (WORM) من تحت مع احتفاظ يطابق أصرم إطار منطبق. أدوات تحقق منشورة وقابلة للممارسة. تتناول المقالتان المرافقتان حول الأدلة المستمرة ومسارات التدقيق المقاومة للعبث المعمارية بالتفصيل. وللعملاء الذين تتطلب ولايتهم القضائية أو نموذجهم التهديدي ذلك، يشغّل النشر السيادي لدى نوفانترا الحزمة بأكملها داخل بنية العميل التحتية الخاصة.
لا واحد من الثلاثة ميزة. كلٌّ منها التزام بنيوي يصبح حاملاً للثقل في اللحظة التي يوقّع فيها مشترٍ خاضع للتنظيم العقد، لأن كل إطار رئيسي بات يتوقّع وجود كل منها، قابلاً للتهيئة من قِبل العميل، قابلاً للتدقيق من قِبل الجهة التنظيمية، وقابلاً للتصدير عند الطلب. وأغلقت نافذة التقارب الممتدة ثمانية عشر شهراً من أكتوبر 2024 إلى منتصف 2025 الحلقة: الجهات التنظيمية للمشترين تسأل؛ والمشترون يسألون مورّديهم؛ والمورّدون إما أن لديهم المعمارية اللازمة بالفعل، أو سيكتبونها خلال جولة التمويل التالية. لقد تحرّكت الأطر. وعلى المعمارية أن تتبع.