ابنِ جردًا تشفيريًا للاستعداد لما بعد الكم في السعودية

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

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

ماذا يطلب البنك المركزي؟ وما المعنى التقني؟

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

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

لا يفرض التعميم خوارزمية واحدة لكل التطبيقات. وهذه نقطة مهمة. اعتمد NIST معيار ML-KEM لإنشاء المفاتيح، وML-DSA وSLH-DSA للتوقيعات، لكن دعم البروتوكولات ونضج المكتبات ومنظومات الشهادات ووحدات HSM والتوافق مع الشركاء تختلف. لذلك يسبق الجرد وترتيب الأولويات عملية الهجرة.

احصر استخدام التشفير لا الشهادات وحدها

يعد تصدير بيانات مدير الشهادات مدخلًا مفيدًا، لكنه ليس جردًا كاملًا. يوجد تشفير المفتاح العام داخل TLS وmTLS بين الخدمات، وتوقيع الشيفرة وصور الحاويات، وتوقيع تطبيقات الهاتف، وJWT وSSH وVPN، ومحركات قواعد البيانات، ومسارات النسخ الاحتياطي، ووحدات HSM، وأجهزة الدفع، وتبادل الملفات مع الشركاء، ومنتجات SaaS الخارجية. تظهر بعض الأصول للماسحات، بينما لا يظهر بعضها إلا في الإعدادات أو الشيفرة أو جهاز تجاري مغلق.

ابنِ الاكتشاف من عدة مصادر أدلة. استعلم من مديري الشهادات السحابيين وLoad Balancers وبوابات API وKubernetes Ingress وService Mesh وKMS وسجلات HSM. افحص المستودعات وSBOM بحثًا عن مكتبات التشفير وإعدادات البروتوكول. راقب Handshakes في نقاط رصد معتمدة. واطلب من الموردين خارطة طريق لما بعد الكم ومسار الترقية المدعوم. اجمع هذه الإشارات تحت معرف أصل واحد بدل إبقاء قوائم منفصلة لا يمكن مقارنتها.

لا تخزن المفاتيح الخاصة أو الأسرار في الجرد. خزّن مرجعًا إلى حد إدارتها، مثل معرف KMS أو قسم HSM أو معرف مدير الشهادة. ويجب تقييد الوصول إلى الكتالوج لأنه يكشف المعمارية الأمنية، مع إبقائه قابلًا للاستخدام من الفرق المسؤولة عن المعالجة.

استخدم عقدًا عمليًا للأصل التشفيري

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

{
  "asset_id": "crypto-api-gateway-prod-tls",
  "service": "customer-payments-api",
  "owner": "payments-platform",
  "environment": "production",
  "use": "external TLS key establishment and authentication",
  "algorithm": "ECDHE_ECDSA",
  "implementation": "managed-api-gateway",
  "key_boundary": "cloud-kms-reference",
  "data_class": "restricted",
  "confidentiality_years": 10,
  "third_parties": ["gateway-provider", "certificate-authority"],
  "rotation_tested_at": "2026-09-15",
  "evidence": ["config-snapshot:sha256:...", "tls-scan:sha256:..."],
  "migration_state": "vendor-roadmap-required"
}

ضع نسخة لإصدار المخطط وسجل وقت ملاحظة كل حقل واحتفظ ببصمات الأدلة بصورة لا تقبل التعديل. الجرد القديم خطير لأن الشهادات تتجدد والخدمات تنتقل وتظهر اعتمادات غير مُدارة. حدّد هدفًا لحداثة البيانات حسب الخطورة؛ فواجهة دفع مكشوفة للإنترنت تحتاج فحصًا أكثر من أداة داخلية مؤرشفة.

رتب الأولويات حسب التعرض والعمر وقابلية التغيير

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

وللتوقيع وإنشاء المفاتيح آثار فشل مختلفة. قد يهدد التوقيع الضعيف مصدر البرمجيات والهوية واعتماد المعاملات، بينما قد يكشف ضعف إنشاء المفاتيح السرية. ويتأثر التشفير المتماثل والـHash بطريقة مختلفة عن أنظمة المفتاح العام؛ لذلك فإن برنامجًا عامًا لـ«استبدال كل AES» سيستهلك الجهد من دون اتباع نموذج المخاطر المطلوب.

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

ابنِ المرونة التشفيرية قبل فرض الهجرة

تعني المرونة التشفيرية أن النظام يستطيع تغيير الخوارزميات والإعدادات والمفاتيح والموردين من دون إعادة كتابة سير العمل التجاري. لكنها ليست طبقة سحرية تخفي كل الفروق. تختلف واجهات Key Encapsulation عن التوقيع؛ وقد تؤثر المفاتيح والتوقيعات الأكبر في Handshakes والحزم والشهادات والطوابير والتخزين؛ وتتطلب بعض الأوضاع الهجينة اتفاق الطرفين على بناء بروتوكولي محدد.

أنشئ حدودًا تشفيرية صريحة. تطلب شيفرة التطبيق عمليات مثل establish_session أو sign_release أو verify_partner_message أو wrap_data_key عبر واجهة Capability لها إصدار. تختار السياسة تنفيذًا معتمدًا حسب البيئة والشريك. تسجل Telemetry عائلة الخوارزمية والنتيجة من دون كشف المفاتيح أو المحتوى الحساس. ويبقى Rollback الطارئ ممكنًا لأن المسار السابق القابل للتشغيل يظل متاحًا أثناء الانتقال المنضبط.

لا تخترع بناءً تشفيريًا. استخدم خوارزميات معيارية عبر تطبيقات موثوقة ومصانة، واتبع توجيهات البروتوكول المحدد. يسجل NIST المعايير FIPS 203 و204 و205 كمعايير نهائية، بينما توضح مواده الانتقالية أن المؤسسات ما زالت تحتاج إلى الاكتشاف واختبارات التوافق وخارطة طريق. وجود خوارزمية معيارية شرط ضروري، لكنه لا يكفي لبناء بروتوكول إنتاج آمن.

اختبر التوافق كرسم للاعتمادات

نادراً ما تكون وحدة الهجرة Microservice واحدة. قد يمر مسار TLS عبر مكتبة عميل ونظام هاتف وCDN وWAF وLoad Balancer وService Mesh وتطبيق ومسبار مراقبة. وقد يمر مسار التوقيع عبر خدمة بناء وHSM وسجل حزم ووحدة نشر ومحقق داخل Runtime. يجب أن يمثل الجرد هذه العلاقات كرسم اعتمادات، لأن ترقية عقدة واحدة من دون البقية قد تسبب انقطاعًا.

أنشئ مصفوفة توافق لكل مسار ذي أولوية. سجل الأوضاع الكلاسيكية وما بعد الكم والهجينة المعتمدة؛ وأحجام المفاتيح والتوقيعات؛ وزمن Handshake والتحقق؛ ودعم HSM؛ وقيود الشهادات؛ وسلوك الفشل؛ وRollback. نفّذ الاختبارات بأحجام بيانات وتزامن شبيهين بالإنتاج. لا يثبت Unit Test نجاح المسار إذا رفض Proxy وسيط Handshake أكبر أو عجز SDK لدى الشريك عن قراءة الشهادة الجديدة.

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

انشر على مراحل مع أدلة ومسار رجوع

استخدم تسلسلًا يبدأ بالاكتشاف وتحديد الملكية والتصنيف، ثم اختبار المختبر وShadow أو Canary، فالتوسع المراقب، وأخيرًا الإيقاف. يجب أن يملك كل Gate مسؤولًا ودليلًا موضوعيًا. تشمل الأدلة المفيدة لقطات إعدادات موقعة ونتائج ماسحات وتصديقات الاعتمادات وتقارير توافق ومقارنات الزمن والأخطاء ووثائق قدرات HSM والتزامات الموردين وتمارين Rollback.

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

يجب أن ينتج Backlog الهجرة من استعلامات الجرد. مثال: الأصول ذات الأولوية التي تستخدم مفتاحًا عامًا متأثرًا بالكم وتحمي بيانات تمتد سريتها أكثر من خمس سنوات وتعتمد على مورد بلا خارطة طريق مؤرخة. هذا أكثر قابلية للتنفيذ من عرض شرائح يحدث يدويًا.

أفضل الاستخدامات ومتى نؤجل الهجرة

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

لا تستبدل بروتوكول إنتاج لمجرد أن مكتبة تجريبية توفر Primitive لما بعد الكم. انتظر عندما لا يكون البناء البروتوكولي معياريًا، أو لا تستطيع الأطراف المطلوبة التوافق، أو يفتقر التطبيق إلى مستوى التحقق المطلوب، أو لا يمكن تنفيذ Rollback بأمان. وتأجيل هجرة معينة لا يبرر تأجيل الاكتشاف؛ فالجرد والملكية وتصنيف عمر البيانات وأسئلة الموردين مفيدة الآن.

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

أنماط سيئة يجب تجنبها

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

ومن الأنماط السيئة أيضًا تغيير التطبيق والبنية التحتية معًا من دون Gate توافق قابل للرصد. افصل تفعيل القدرة عن تحويل المرور. يجب أن تُحصر Feature Flags في مسار تشفيري محدد، وتحمي من الاستخدام العشوائي، وتخضع للمراجعة. ولا يكون Kill Switch حقيقيًا حتى يُختبر تحت الحمل.

خطة تنفيذية لتسعين يومًا

في أول 30 يومًا، أنشئ مخطط الجرد والملاك ومستودع الأدلة وطرق الاكتشاف المعتمدة. استورد الشهادات وبيانات KMS وHSM والنقاط المكشوفة للإنترنت وسياسات Service Mesh وأنظمة التوقيع واتصالات الموردين عالية القيمة. سمِّ الحقول المجهولة بدل تخمينها.

في الأيام 31–60، طابق التكرارات وثبت الملكية وصنف عمر البيانات وأهمية العمل وابنِ رسوم الاعتمادات للمسارات الأعلى خطورة. اطلب بيانات قدرات مؤرخة من الموردين، وطابق دعم البروتوكولات مع المعايير المعتمدة. اختر Pilot محدودًا وحدد مقاييس النجاح والفشل والرجوع.

في الأيام 61–90، نفذ اختبارات التوافق والأداء، وانشر أول سجلات قرارات الهجرة، وشغّل Canary حيث يكون مناسبًا، ثم أعد النتائج إلى نموذج التقييم. ابنِ لوحة تظهر التغطية وحداثة البيانات والملكية المجهولة ومعوقات الموردين عالية الخطورة واختبارات Rotation وحالة الهجرة. لا تكمل هذه الخطوات انتقالًا يمتد سنوات، لكنها تنشئ طبقة تحكم موثوقة للقرارات التالية.

الخلاصة التنفيذية

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

يربط الجرد القوي الحقائق التقنية بحساسية البيانات وأثر العمل وقيود الموردين والأدلة. بهذه القاعدة تستطيع الفرق تبني المعايير النهائية عندما تصبح البروتوكولات والتطبيقات جاهزة، وتأجيل هجرة غير آمنة بسبب موثق، ونقل المسارات ذات الأولوية عبر مراحل مقاسة وقابلة للرجوع.

إعداد: Noor Yasser