تحتفظ شركة Northwind Traders بسجل جرد واحد لكل استخدام لتقنيات التشفير يعمل على حماية حدود الأعمال، ويُحدد لكل سجل مالك للنظام يكون مسؤولاً عن مسار الانتقال الخاص به. يقبل السجل بيانات حول البروتوكول والخوارزمية والشهادة والمكتبة وأدلة الملكية المرصودة، ثم يُنتج خريطة جاهزة لاتخاذ القرار توضح التبعيات المعرضة لمخاطر الحوسبة الكمومية، بدلاً من مجرد قائمة بالشهادات. ويتمثل التهديد في استراتيجية “الجمع الآن وفك التشفير لاحقاً” (harvest-now-decrypt-later) التي تستهدف حركة بيانات العملاء والمدفوعات والبيانات الإدارية المحمية حالياً بتشفير المفتاح العام، وهي حماية قد يتمكن حاسوب كمومي مستقبلي - يتمتع بقدرات كسر التشفير - من اختراقها.
تتقاطع المسارات الحيوية لشركة Northwind مع عدة حدود للثقة؛ حيث تتصل واجهة المتجر العامة وتطبيق الهاتف المحمول بـ EdgeGW؛ وتقوم EdgeGW بمصادقة الهوية مع نظام Orders باستخدام بروتوكول TLS المتبادل (mutual TLS)؛ وتقوم AuthN بتوقيع رموز JWT التي تقبلها بوابة الإدارة وواجهات برمجة التطبيقات (APIs)؛ ويتصل نظام PayBridge بمزود خدمة الدفع؛ كما تقوم عمليات CI/CD بتوقيع المخرجات البرمجية القابلة للنشر. وتُنشئ هيئات إصدار الشهادات (سواء المؤسسية أو العامة) جذوراً منفصلة للثقة. لذا، فإن المدقق الذي يعثر على شهادة RSA-2048 عند إحدى نقاط الحافة لا يمكنه الجزم - في تلك المرحلة - ما إذا كانت الآلية التشفيرية ذاتها تُستخدم أيضاً لتوقيع الإصدارات البرمجية، أو مصادقة الخدمات، أو التحقق من صحة رموز الوصول (access tokens).
تُبرز البنية الهندسية حدود المجموعة بوضوح قبل أن نقوم بتخصيص السجلات لها:
يوضح هذا الرسم البياني سبب عدم كفاية مجرد حصر الشهادات؛ إذ تضع بروتوكولات مثل TLS وmTLS وعمليات التحقق من JWT والحزم البرمجية تقنيات التشفير بالمفتاح العام في أدوار بروتوكولية متميزة ولها جهات مسؤولة (مالكون) مختلفة.
نظراً لأن مفتاح RSA-2048 نفسه يمكن أن يؤدي وظائف متعددة، فإن نظام Northwind يسجل الاستخدام التشفيري باعتباره خوارزمية واحدة تعمل لغرض واحد وضمن نطاق (حدود) واحد. وتُعتبر كل من شهادة خادم TLS، وتبادل المفاتيح عبر ECDH، وتوقيع JWT استخدامات منفصلة، حتى وإن كان منتج واحد هو من يتيحها. وتكتسب هذه التفرقة أهميتها لأن إنشاء المفاتيح الهجين (hybrid key establishment) يمكن أن يقلل من مخاطر انكشاف السرية في مسار TLS المدعوم، في حين يظل توقيع JWT غير المُعدَّل قابلاً للتزوير في ظل نموذج التهديد الكمي.
يوثق كل سجل الأدلة اللازمة لاتخاذ قرار الاستبدال لاحقاً، وتشمل:
تعمل الحقول المطلوبة على الفصل بين مرحلة الاكتشاف ومرحلة اتخاذ القرار. تكشف مراقبة مجموعة خوارزميات التشفير (cipher-suite) عن وجود انكشاف أمني يتعلق ببروتوكول ECDH، إلا أن إصدار المكتبة ومسار التغيير هما اللذان يحددان ما إذا كان بإمكان EdgeGW اعتماد تطبيق هجين. كما يتطلب سجل التوقيع تحديد مواقع جهات التحقق؛ إذ أن تغيير الجهة الموقِّعة دون تحديث بوابة الإدارة، وبوابة واجهة برمجة التطبيقات (API gateway)، وآلية التحقق من النشر، يؤدي إلى تقويض الثقة. وتستعرض المقارنة التالية التفاصيل المفقودة التي تحول عادةً دون تحوّل قوائم الجرد -الدقيقة في جوهرها- إلى خطط عمل تنفيذية:
يوضح هذا الجدول أن اكتشاف الخوارزميات أمر ضروري ولكنه غير كافٍ؛ إذ تحدد عوامل الملكية، ونطاق وصول جهة التحقق، وإصدار المنتج ما إذا كان يمكن بالفعل نشر بديل قياسي.
قاعدة اتخاذ القرار السجل الذي يفتقر إلى الغرض والمالك يصف “نتاجاً برمجياً” (artifact) وليس “اعتمادية تشفيرية” قابلة للترحيل.
بعد تثبيت المخطط الهيكلي، تبدأ Northwind العمل عند الحدود التي تنقل بيانات حساسة طويلة الأمد أو تفرض قرارات جوهرية تتعلق بالسلامة (integrity). يغطي المسار client→EdgeGW بروتوكول TLS الخارجي؛ ويغطي المسار EdgeGW→Orders بروتوكول mTLS الداخلي؛ ويغطي المكون AuthN عملية توقيع JWT وجميع جهات التحقق؛ ويغطي المكون PayBridge اعتمادية طرف ثالث؛ بينما تغطي عمليات CI/CD توقيع النواتج البرمجية. يجب أن يسجل الجرد خوارزمية ECDH بشكل منفصل عن AES؛ لأن AES قد تظل مناسبة للاستخدام، في حين تتطلب عملية إنشاء المفاتيح باستخدام ECDH استبدالاً أو انتقالاً هجيناً.
أي إدخال يتطلب كلاً من ترحيل جهة التوقيع وجرداً لجهات التحقق الموزعة: سجل توقيع JWT في AuthN أم سجل mTLS في المسار EdgeGW→Orders؟
يستخدم الجرد المكتمل سجلات قائمة على الأدلة لثماني نتائج تم رصدها في Northwind، ويصنّف النتائج وفقاً لمستويات التعرض للخوارزميات RSA-2048 وECDH وECDSA P-256: