مقدمة
يُرسي قانون المرونة التشغيلية الرقمية (DORA) إطارًا شاملًا لتعزيز الصمود الرقمي للكيانات المالية في جميع أنحاء الاتحاد الأوروبي. وبينما تنصبّ الاهتمامات في الغالب على إدارة مخاطر ICT الداخلية بموجب المادة 21، فإن المادة 28 تُحوّل التركيز نحو الخارج، معالجةً المخاطر التي يُدخلها مزوّدو خدمات ICT من الطرف الثالث.
في بيئات المؤسسات الحديثة، يعتمد تسليم البرمجيات اعتمادًا كبيرًا على منصات خارجية كمزوّدي السحابة وأدوات CI/CD SaaS وخدمات استضافة الشفرة المصدرية والحلول الأمنية المُدارة. تُدرج المادة 28 من DORA هذه التبعيات رسميًا ضمن النطاق، مطالبةً المنظمات بـتحديد مخاطر ICT للطرف الثالث وتقييمها والتحكم فيها ورصدها باستمرار.
تشرح هذه المقالة ما تشترطه المادة 28 من DORA فعلًا، ولماذا تتأثر خطوط أنابيب CI/CD وأدوات DevSecOps تأثرًا مباشرًا، وكيف ينبغي للمنظمات التعامل مع الامتثال في البيئات الخاضعة للتنظيم.
ما تغطيه المادة 28 من DORA
تُرسي المادة 28 من DORA إطارًا منظّمًا لـإدارة مخاطر ICT للطرف الثالث، ويرمي هدفها إلى ضمان حفاظ الكيانات المالية على مرونتها التشغيلية حتى حين تُقدَّم الخدمات الحرجة من قِبل موردين خارجيين.
على المستوى الإجمالي، تُلزم المادة 28 المنظماتِ بـ:
- تحديد قائمة جرد بمزوّدي خدمات ICT من الطرف الثالث والحفاظ عليها
- تصنيف المزوّدين بناءً على الأهمية الحرجة والمخاطر
- إجراء العناية الواجبة قبل الإلحاق
- تحديد بنود الأمن والتدقيق الإلزامية في العقود
- رصد مخاطر الطرف الثالث باستمرار
- إدارة مخاطر التركّز وسلاسل التبعية
- إعداد استراتيجيات الخروج واختبارها
خلافًا لمقاربات إدارة الموردين التقليدية، تُعامل المادة 28 من DORA موردي ICT بوصفهم مكوّنات متكاملة في مشهد المخاطر التشغيلية، لا مجرد اعتبارات هامشية للاستعانة بمصادر خارجية.
لماذا تقع CI/CD وDevSecOps صراحةً ضمن النطاق
رغم عدم إشارة DORA صراحةً إلى CI/CD أو DevSecOps، فإن المادة 28 تسري عليهما بوضوح في التطبيق العملي.
تعتمد خطوط أنابيب CI/CD الحديثة على خدمات ICT متعددة من الطرف الثالث، منها:
- منصات استضافة الشفرة المصدرية (مثل Git hosting SaaS)
- منصات تنسيق CI/CD
- منفّذو الإنشاء وبيئات التنفيذ المُدارة
- مستودعات القطع الأثرية وسجلات الحاويات
- إدارة التبعيات ومنظومات الحزم
- البنية التحتية السحابية وخدمات وقت التشغيل المُدارة
يمكن لكل من هذه الخدمات أن تؤثر في:
- سلامة الشفرة
- أمن سلسلة توريد البرمجيات
- توافر خطوط أنابيب التسليم
- جداول زمنية الاستجابة للحوادث
- الأدلة وقابلية التدقيق
بموجب المادة 28، يجب التعامل مع هذه المنصات بوصفها مزوّدي خدمات ICT من الطرف الثالث، وحوكمة مخاطرها بالصرامة ذاتها المعمول بها للأنظمة الداخلية.
تصنيف الطرف الثالث لـ ICT وتحديد أهميته الحرجة
أحد المتطلبات الجوهرية للمادة 28 هو تصنيف مزوّدي ICT من الطرف الثالث.
يجب على المنظمات تقييم:
- ما إذا كان المزوّد يدعم وظائف حرجة أو مهمة
- التأثير المحتمل لإخفاق المزوّد
- مستوى قابلية الاستبدال
- التبعية للمقاولين من الباطن والأطراف الرابعة
في سياقات CI/CD، كثيرًا ما تُصنَّف المنصات التي تؤثر مباشرةً في الشفرة أو الإنشاءات أو عمليات النشر بوصفها مزوّدي ICT عاليَي التأثير أو حرجَين، حتى وإن كانت خدمات SaaS مستخدَمة على نطاق واسع.
يُحدّد هذا التصنيف عمق الضوابط المطلوبة، بما فيها البنود التعاقدية وحقوق التدقيق والتزامات الرصد.
المتطلبات التعاقدية والحوكمية
تُركّز المادة 28 تركيزًا قويًا على الحوكمة التعاقدية.
يجب أن تتضمّن عقود مزوّدي ICT من الطرف الثالث أحكامًا تغطي:
- متطلبات أمن المعلومات
- التحكم في الوصول وفصل المهام
- جداول زمنية لإشعارات الحوادث
- حقوق التدقيق والفحص
- قيود موقع البيانات ومعالجتها
- استمرارية الأعمال والتعافي من الكوارث
- شروط الخروج والإنهاء
بالنسبة لأدوات CI/CD وDevSecOps، يعني ذلك أن العقود يجب أن تُعالج صراحةً:
- أمن بيئات الإنشاء والنشر
- الحماية من حقن الشفرة غير المصرّح به
- الاحتفاظ بالأدلة لأغراض التدقيق
- الشفافية في المقاولين من الباطن والبنية التحتية المشتركة
الرصد المستمر وجمع الأدلة
DORA Article 28 does not allow for “set-and-forget” vendor risk management.
يُتوقَّع من المنظمات:
- رصد أداء الطرف الثالث لـ ICT وأمنه باستمرار
- تتبع الحوادث المتعلقة بخدمات الطرف الثالث
- الاحتفاظ بأدلة قابلة للتدقيق على أنشطة الرقابة
- إعادة تقييم ملفات المخاطر بمرور الوقت
في بيئات CI/CD، يشمل ذلك في الغالب:
- سجلات منصات CI/CD من الطرف الثالث
- سجلات الوصول والنشاط
- أدلة سلامة القطع الأثرية (التوقيعات، SBOMs)
- تقارير الحوادث المتعلقة بالخدمات الخارجية
- سجلات التغيير والموافقات المرتبطة بأدوات المورّد
يتوافق هذا المتطلب توافقًا وثيقًا مع ممارسات DevSecOps التي تُركّز على الأتمتة وقابلية التتبع والحوكمة المبنية على الأدلة.
استراتيجيات الخروج ومخاطر التركّز
تشترط المادة 28 صراحةً على المنظمات إعداد استراتيجيات الخروج من خدمات ICT للطرف الثالث.
يشمل ذلك:
- القدرة على إنهاء العقود دون تعطّل غير مقبول
- خطط الهجرة إلى مزوّدين بديلين
- ضوابط لتجنب مخاطر التركّز المفرط
في التطبيق العملي، يُعدّ هذا أحد أصعب جوانب الامتثال للمادة 28، لا سيما لمنصات CI/CD والسحابة حيث يشيع الارتباط بمورّد محدد.
يجب على المنظمات إثبات أن:
- خطوط أنابيب التسليم الحرجة لا تعتمد على مورّد واحد دون تخفيف المخاطر
- خطط الخروج موثّقة وواقعية وتُراجَع دوريًا
- التبعيات على المعالجين من الباطن مفهومة ومُدارة
العلاقة مع المادة 21 من DORA
لا تقف المادة 28 من DORA منفردةً، بل تُوسّع المادة 21 وتُكمّلها.
- المادة 21 تنصبّ على إدارة مخاطر ICT الداخلية والضوابط
- المادة 28 تُطبّق تلك المبادئ على مزوّدي خدمات ICT الخارجيين
في بيئات DevSecOps الخاضعة للتنظيم، يعني ذلك أن:
- ضوابط الأمن المُطبَّقة داخليًا يجب تطبيقها أيضًا عبر منصات الطرف الثالث
- الأدلة المُجمَّعة من خطوط أنابيب CI/CD يجب أن تشمل أدوات الطرف الثالث
- يجب أن تمتد الحوكمة والمساءلة عبر الحدود التنظيمية
تُشكّل المادتان 21 و28 معًا نموذجًا لإدارة المخاطر المستمرة عبر سلسلة التسليم الرقمي بأكملها.
الأخطاء الشائعة للمادة 28 في بيئات CI/CD
تُعاني المنظمات كثيرًا من المادة 28 بسبب:
- Treating CI/CD SaaS platforms as “low-risk utilities”
- غياب الرؤية في المعالجين من الباطن الذين يستخدمهم الموردون
- غياب حقوق التدقيق في عقود SaaS القياسية
- عدم وجود استراتيجية خروج محددة من أدوات CI/CD الحرجة
- الاحتفاظ غير الكافي بالأدلة المرتبطة بخدمات الطرف الثالث
كثيرًا ما تظهر هذه الثغرات أثناء المراجعات التنظيمية أو التدقيق، حتى في المنظمات ذات ممارسات DevSecOps الناضجة.
ما الذي يلي ذلك
تُقدّم هذه المقالة الأساس المفاهيمي للمادة 28 من DORA. في المقالات التالية من هذه السلسلة، سنستعرض:
- أنماط البنية المعمارية للمادة 28 من DORA لبيئات CI/CD والسحابة
- حزمة أدلة المادة 28: ما يتوقعه المدققون فعلًا
- قائمة تدقيق عملية لمخاطر ICT للطرف الثالث
- سيناريوهات المخاطر والمؤشرات التحذيرية الخاصة بـ CI/CD للطرف الثالث
تُقدّم هذه الموارد مجتمعةً خارطة طريق عملية لتطبيق إدارة مخاطر الطرف الثالث المتوافقة مع DORA في بيئات DevSecOps الحديثة.
