كيف تُحفظ قائمة التوقيع الإلكتروني الجماعي آمنة؟
ثبّت كل مهمة توقيع بملخص المستند والإصدار والموقِّع ومفتاح عملية فريد؛ وتحقق من الصلاحية لحظة التنفيذ، ووحّد التكرارات، ولا تعتبر النجاح إلا للمخرجات المتحقق منها.
عند ازدياد الكثافة ليس الهدف تسريع القائمة فحسب. بل يلزم آلة حالة تمنع توقيع المستند نفسه مرتين، وتقدم PDF معدّلًا بموافقة قديمة، وظهور خطأ خدمة مؤقت كنجاح دائم، وانفصال إثبات التوقيع عن سجل العمل.
بأي هوية تُقبل مهمة التوقيع في القائمة؟
يجب أن تستند هوية المهمة ليس إلى اسم الملف فحسب؛ بل إلى هوية المستند والإصدار غير القابل للتغيير والملخص التشفيري وهوية الموقِّع وسياسة التوقيع ونوع العملية المقصود.
تشير صفحة BTK المحدّثة التي تشرح إطار القانون رقم 5070 إلى أن التوقيع الإلكتروني الآمن يمكّن من كشف أي تعديل لاحق على البيانات الموقَّعة. كما يشرح محتوى الأسئلة الشائعة التقنية لدى BTK ضوابط إمكانية اطلاع صاحب التوقيع على البيانات قبل التوقيع وعدم إخراج بيانات إنشاء التوقيع من الأداة. ونتيجة تصميم القائمة واضحة: إذا أُعيد إنتاج PDF بعد موافقة المستخدم على إصدار، فلا يجب أن تستمر المهمة نفسها، بل تُفتح موافقة جديدة بملخص جديد. [1] [2]
| الحقل | لماذا هو مطلوب؟ | قاعدة الانتقال |
|---|---|---|
| هوية المستند وإصداره | يبيّن لأي مخرج مضبوط تنتمي المهمة. | إذا تغير الإصدار تُنقل المهمة الحالية إلى حالة الملغاة؛ وتُفتح مهمة جديدة. |
| ملخص المستند | يربط سلسلة البتات المعتمدة بمدخل التوقيع. | يعيد المستهلك حساب الملخص قبل التوقيع؛ ويتوقف عند عدم التطابق. |
| الموقِّع والدور | يتيح تقييم الصلاحية لمستند وعملية محددين. | إذا لم يكن الدور أو الشهادة مناسبًا لا تنتقل المهمة إلى مرحلة التوقيع. |
| مفتاح Idempotency | يمنع أن يولّد تكرار الطلب المنطقي نفسه توقيعًا ثانيًا. | يعيد المفتاح نفسه النتيجة المسجلة؛ ولا ينشئ أثرًا جانبيًا جديدًا. |
| إصدار السياسة والصيغة | يحفظ قاعدة التحقق المطبَّقة. | لا يعيد تفسير تغيير القاعدة المهام المفتوحة بصمت. |
| الحالة وأثر العملية | يتيح إعادة بناء كل انتقال من القبول إلى الأرشفة. | لا تُطبَّق إلا الانتقالات المسموح بها على جانب الخادم. |
أي الحالات يجب الفصل بينها في القائمة؟
ثلاثية «منتظر، ناجح، خاطئ» غير كافية؛ فيجب فصل حالات القبول والفحص المسبق والموافقة البشرية والتوقيع والتحقق والأرشفة والفحص.
- قُبلت: يُحفظ المستند المصدر والإصدار والملخص ومفتاح idempotency بشكل ذرّي.
- الفحص المسبق: تُدقَّق صلاحية الوصول إلى المستند والصيغة والملكية ودور الموقِّع واختيار الشهادة ومطابقة السياسة.
- بانتظار الموافقة: يرى صاحب التوقيع الإصدار الصحيح للمستند الذي سيُوقَّع ويمنح الموافقة لعملية محددة.
- جارٍ التوقيع: يستلم الـWorker المهمة بقفل قصير الأمد؛ وحتى لو انقضت مدة القفل يمنع سجل idempotency الأثر الجانبي الثاني.
- جارٍ التحقق: يُتحقَق تقنيًا من التوقيع الناتج في سياق المستند الموقَّع والشهادة.
- أُرشِف: يُحفظ المخرج الموقَّع ونتيجة التحقق وإثبات الطابع الزمني وأثر العملية في ربط السجل نفسه.
- يلزم فحص: يُسنَد إلى المسؤول المخوّل التحقق الغامض أو الخطأ الدائم أو التعارض دون تحويله إلى نجاح تلقائي.
يوصي دليل OWASP لتفويض العمليات بحفظ بيانات العملية ذات المعنى على الخادم، وتنفيذ الخطوات بالتسلسل، وربط تفويض فريد بكل عملية. ويعني هذا ألا يثق مستهلك القائمة بحقل «تمت الموافقة» القادم من المتصفح؛ بل يعيد التحقق من ملخص المستند والصلاحية وانتقال الحالة من سجل الخادم. [5]
كيف تُعاد المحاولة دون إنتاج توقيع مزدوج؟
أعد المحاولة على الأخطاء المؤقتة فقط بشكل محدد ومتأخر؛ واربط كل محاولة بمفتاح idempotency نفسه واحفظ نتيجة التوقيع الخارجية بشكل ذرّي.
يوصي دليل OWASP لأمن منطق الأعمال بتخزين مفتاح idempotency مع النتيجة بشكل معاملاتي (transactional) للطلبات الخارجية التي تغيّر الحالة. إذا انقطع الاتصال بالشبكة بعد أن أرسل الـWorker الطلب إلى خدمة التوقيع، فالافتراض بأنه «لم تأتِ استجابة، لم تحدث العملية» خطير. يجب أولًا الاستعلام بال مفتاح العمل نفسه عن نتيجة مسجلة أو هوية عملية لدى المزوّد؛ ولا يُعاد الإرسال إلا إذا ثبت عدم حدوث العملية. [4]
صنّف الأخطاء: انقطاع الاتصال القصير والازدحام المؤقت الذي يعلنه الخدمة صراحةً قابلان لإعادة المحاولة؛ أما المستخدم غير المصرّح له، أو ملخص المستند المتغير، أو اختيار شهادة غير صالح، أو فشل التحقق فلا يُعاد تلقائيًا. يمكن للمحاولات المتأخرة استخدام انتظار متزايد وانحراف عشوائي؛ لكن يجب تحديد عدد المحاولات والمدة الإجمالية وفق هدف الخدمة وتقييم الخطر لدى المؤسسة، لا الإعلان عن رقم كوني بلا مصدر.
متى تُعدّ العملية ناجحة فعلًا؟
تكوّن الملف الموقَّع وحده ليس نجاحًا؛ بل يجب حفظ قيمة التوقيع وربط المستند وشهادة التوقيع وسياسة التحقق ونتيجة الطابع الزمني عند الحاجة معًا.
يعرّف ETSI EN 319 102-1 V1.4.1 مدخلات ونتائج عمليات إنشاء AdES والتحقق منه؛ ويبيّن أن الحالات الناجحة والفاشلة والغامضة في نتيجة التحقق ليست الشيء نفسه. في سير عمل VizyonTech يجب ألا يغلق الـWorker العمل لأن الملف كُتب فحسب؛ بل يحفظ قاعدة التحقق المستخدمة ونتيجتها، وينقل النتيجة الفاشلة أو الغامضة إلى قائمة الفحص. [3]
يعرّف RFC 3161 الطابع الزمني بوصفه بروتوكول طلب-استجابة يوفر دليلًا على وجود بيانات معينة قبل وقت محدد. لذا إذا لزم الطابع الزمني فلا يُكتفى بسجل «طُلب»؛ بل يُربط بعملية التوقيع نفسها بصمة الرسالة (message imprint) وحالة الاستجابة والرمز المُعاد (token) ونتيجة التحقق. ولا تُعدّ nonce أو ملخص مستند غير متطابق، أو استجابة متأخرة، أو طلب مرفوض نجاحًا. [6]
تعتمد حاجة التحقق طويل الأمد على الصيغة والسياسة ومدة الحفظ. وبدلًا من افتراض ملف الأرشفة نفسه لكل توقيع، يجب تطبيق إجراء المؤسسة والمعايير التقنية السارية كسياسة خاضعة لإدارة الإصدارات.
كيف يحمي الازدحام النظام وصاحب التوقيع؟
عندما تجاوزت سرعة القبول سعة التوقيع لا تكدّس أعمالًا بلا حدود؛ بل طبّق حصصًا لكل عميل/مؤسسة وأولوية وضغطًا عكسيًا (backpressure) ومقاييس تقادم ظاهرة.
- السعة العادلة: يجب ألا تُرجئ حزمة عميل واحد كبيرة أعمال المؤسسات الأخرى إلى ما لا نهاية؛ بل تكون حدود المستأجر والأولوية واضحة.
- الضغط العكسي: عند بلوغ القائمة العتبة التشغيلية المحددة يُبطأ قبول الحزم الجديدة أو يُجدول لوقت مخطط.
- ظهور مدة العمل: لا يكفي المتوسط وحده؛ بل يجب تتبع أقدم عمل منتظر وعمر كل حالة وعدد المحاولات وقائمة الفحص كلٌّ على حدة.
- قفل قصير، سجل دائم: يكون قفل الـWorker مؤقتًا؛ أما هوية العمل وتاريخ المحاولات والنتيجة فيجب أن تكون دائمة.
- المراقبة الآمنة: يجب ألا تتضمن السجلات محتوى المستند أو بيانات الوصول أو PIN أو المفتاح الخاص أو بيانات شخصية غير ضرورية.
- الإلغاء المضبوط: يمكن إلغاء العمل الذي لم يُوقَّع بعد؛ أما إذا تكوّن التوقيع فلا يُحذف المخرج، بل تُرفع الحالة وقرار التوزيع إلى فحص المسؤول المخوّل.
أي السيناريوهات يجب اختبارها قبل التشغيل الفعلي؟
شغّل بشكل موثَّق ليس المسار الناجح فحسب؛ بل سيناريوهات انهيار الـWorker وانقضاء المهلة والتسليم المزدوج وتغيير المستند وفقدان الصلاحية والتحقق الغامض.
- عند ورود مفتاح idempotency نفسه مع طلبين متزامنين، هل يتكوّن مخرج توقيع واحد فقط؟
- عند اكتمال استدعاء التوقيع وفقدان الاستجابة، هل يجد التكرار النتيجة المسجلة؟
- إذا تغيّر المستند بعد الموافقة، هل يوقف فحص الملخص العمل ويطلب موافقة جديدة؟
- إذا تغيّر دور الموقِّع أو حالة شهادته أثناء الانتظار، هل يعيد المستهلك تقييم ذلك؟
- عند غموض نتيجة التحقق، هل تمتنع المنظومة عن إرسال إشعار تسليم ناجح؟
- هل يمكن للمسؤول المخوّل إعادة تشغيل العمل في قائمة الأخطاء مع حفظ السبب والمحاولات السابقة؟
- هل يستطيع سجل الأرشفة إظهار المخرج الموقَّع ونتيجة التحقق والطابع الزمني وأثر العملية تحت الإصدار نفسه؟
كيف يتناول VizyonTech هذا المسار؟
يُهيّئ VizyonTech الخطوات من إنتاج التقرير إلى الموافقة البشرية، ومن قائمة التوقيع الإلكتروني إلى التحقق والأرشفة، مع أدوار المؤسسة وإصدار المستند وقواعد الاستثناء.
في تصميم التوقيع الجماعي نستخرج أولًا أنواع المستندات الفعلية وأدوار الموقِّعين وسياسة الشهادة والطابع الزمني وسيناريوهات انقطاع الخدمة وقنوات التسليم. ثم نتحقق في مسار مستندات تجريبي من هوية العمل الفريدة والانتقالات المسموح بها وسلوك التكرار وقائمة الفحص والمقاييس التشغيلية الظاهرة.
كيف يُصحَّح تقرير موقَّع لاحقًا في دليل مراجعة التقرير الموقَّع إلكترونيًاأما كيفية تحقق المستخدم النهائي من المخرج الحالي فنتناولها في في دليل صفحة التحقق من التقرير . وللتخطيط لتجربة آمنة بحجم مستندات مؤسستك وسيناريوهات الأخطاء يمكنكم التواصل مع VizyonTech.
المراجع
- BTK — معلومات عامة حول التوقيع الإلكتروني (تاريخ الصفحة 16 يناير 2026؛ إطار القانون رقم 5070 بشأن التوقيع الإلكتروني).
- BTK — الأسئلة الشائعة بشأن التوقيع الإلكتروني (شروحات القانون رقم 5070 والتنظيم الثانوي المؤرخ 6 يناير 2005).
- ETSI — EN 319 102-1، إجراءات إنشاء التوقيعات الرقمية AdES والتحقق منها؛ الجزء 1 (V1.4.1، يونيو 2024).
- OWASP — دليل مرجعي مختصر لأمن منطق الأعمال (فحوصات idempotency والانتقال الذرّي وشرط التزامن؛ تم التحقق بتاريخ 25 يوليو 2026).
- OWASP — دليل مرجعي مختصر لتفويض المعاملات (التفويض على جانب الخادم والربط ببيانات العملية والتفرد؛ تم التحقق بتاريخ 25 يوليو 2026).
- IETF RFC Editor — RFC 3161، بروتوكول الختم الزمني للبنية التحتية للمفتاح العام X.509 على الإنترنت (أغسطس 2001؛ محدَّث بـRFC 5816).
تم التحقق من المصادر بتاريخ 25 يوليو 2026. في التطبيق يجب أيضًا التأكد من تنظيمات BTK المحدّثة وإجراء المؤسسة وسياسة التوقيع وخدمة التوقيع الإلكتروني المستخدمة وقواعد التحقق من الصيغة.