أليكس ماكولوك: الخدمات الأساسية قد تواجه الانقطاع بدون هجوم إلكتروني

قد تتعرض خدمة حيوية للتوقف في أي وقت دون الحاجة إلى حدوث هجوم سيبراني ناجح. إن تعثر مزود البرمجيات أو انقطاع الدعم يمكن أن يضع المؤسسة أمام تحدٍ حقيقي، وهو: هل يمكنها الاستمرار في العمل عندما يتعذر على مزود البرمجيات تقديم الدعم للتطبيقات التي تعتمد عليها؟

هذا هو السؤال الرئيسي الذي تمحورت حوله نقاشات «البوابة التقنية» مع أليكس ماكولوك، مدير تطوير الأسواق في الشرق الأوسط بشركة ‎Escode‎. يرى ماكولوك أن مجرد وجود خطط مكتوبة وضمانات تعاقدية لا يكفي لإثبات المرونة التشغيلية ‎(Operational Resilience)‎؛ إذ تحتاج المؤسسات إلى أدلة ملموسة تثبت أن ترتيبات الاستمرارية يمكن تفعيلها، وأن المواد التقنية اللازمة للتعافي محدثة ومجربة بشكل فعلي.

كما يوضح ماكولوك دور برنامج الحساب الضامن للبرمجيات ‎(Software Escrow)‎، وأهمية التحقق الفني ‎(Technical Verification)‎ ضمن نطاق الخدمة المتفق عليه. يتناول أيضًا التمييز بين حق الوصول إلى البرمجيات والقدرة الفعلية على دعم التعافي. ومما لا شك فيه أنه يناقش كيفية تحديد نقاط الاعتماد الأكثر تأثيرًا في الأعمال، والأسئلة التي يجب على مجالس الإدارة طرحها قبل حدوث أي اضطرابات.

وفيما يلي نص الحوار:

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

لا يمكن إنكار أن الأمن السيبراني هو ركيزة أساسية للمرونة، لكنه ليس النقطة الوحيدة التي يجب على المؤسسات الاستعداد لها.

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

مما تغفله المؤسسات في بعض الأحيان هو مدى اعتمادها على المزود الذي يقدم التطبيق الحيوي. فإذا لم يعد هذا المزود قادرًا على الدعم، يصبح السؤال الجوهرى: ما الخيارات العملية المتاحة للمؤسسة للمحافظة على استمرارية العمليات التشغيلية ‎(Operational Continuity)‎ لهذه الخدمة الحيوية؟

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

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

يجب أن تكون نقطة البداية ليست البرمجيات ذاتها، بل العملية الحيوية التي تعتمد عليها.

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

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

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

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

٣. تمتلك العديد من المؤسسات خطط لاستمرارية الأعمال وضمانات تعاقدية. أين تظهر الفجوة الحقيقية بين امتلاك خطة لاستمرارية العمل على الورق وبين وجود قدرة فعالة على التعافي يمكن تفعيلها عند حدوث الاضطرابات؟

تظهر الفجوة عندما تفترض المؤسسات أن وجود ترتيب تعاقدي أو خطة موثقة يعني تلقائياً أنها تمتلك قدرة التعافي.

لا تكون للخطة قيمة ما لم يكن بالإمكان تفعيلها فعلياً.

فيما يتعلق بالبرمجيات الحيوية، تحتاج المؤسسات إلى حقوق وصول واضحة، والمواد التقنية الحديثة، ووثائق كافية، ومعرفة تشغيلية، وإجراءات تعافٍ تم اختبارها، مع وجود شروط واضحة للإنهاء والتسليم ‎(Release Conditions)‎. ويتوجب الحفاظ على هذه الترتيبات وتحديثها كلما تغيرت البرمجيات مع مرور الوقت.

تكتسب هذه القضية أهمية خاصة في الحساب الضامن للبرمجيات. إذ تحدد اتفاقية الحساب الضامن للبرمجيات حقوق الوصول إلى المواد المودعة ‎(Deposited Materials)‎ وشروط الإنهاء والتسليم. لكن وجود هذه الحقوق وحده لا يثبت قدرة تلك المواد على دعم التعافي؛ بل يجب إجراء التحقق الفني للتأكد من مدى قابليتها للاستخدام وفقاً للنطاق المتفق عليه للاختبارات.

لذا من الواضح أن المبدأ هو: يجب التحقق من المرونة، لا افتراضها.

ينبغي لترتيبات الاستمرارية القوية أن تكون قادرة على تقديم دليل على أن المواد المودعة مكتملة ومحدثة، وقادرة على دعم التعافي عند الحاجة.

٤. تولي الشركة أهمية كبيرة للتحقق التقني المستقل، بدلاً من الاكتفاء بإيداع البرمجيات دون اختبار فعلي لقدرتها على الاستخدام. ما الذي يجب على المؤسسات اختباره تحديدًا لضمان أن البرمجيات المودعة والمواد الضرورية للتعافي قابلة للاستخدام في سيناريو حقيقي للتعافي؟

يجب أولاً التمييز بين الوصول إلى المواد وقابليتها للاستخدام.

في برنامج الحساب الضامن للبرمجيات، يقوم مطور البرمجيات بإيداع الموارد البرمجية، بما في ذلك كود المصدر ‎(Source Code)‎ والوثائق المطلوبة، لدى وكيل الحساب الضامن للبرمجيات الذي يعمل كطرف ثالث مستقل. تحدد الاتفاقية شروط تسليم تلك المواد إلى المستفيد ‎(Beneficiary)‎. ويشمل دور الوكيل التحقق الفني من المواد واختبارها وفقاً للنطاق المتفق عليه، للإجابة عن السؤال المهم: هل يمكن استخدام هذه المواد لاستعادة تشغيل البرمجيات عند الحاجة؟

على مستوى أساسي، تحتاج المؤسسات إلى التأكد من أن المواد المودعة كاملة ومحدثة، وتشمل كافة الملفات المشار إليها في الاتفاقية، وأن الوثائق التقنية شاملة وكافية.

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

كما تعتبر اختبارات السيناريوهات ‎(Scenario Testing)‎ مفيدة للغاية، حيث تنقل النقاش من التوثيق إلى التعافي الفعلي.

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

لذا، لا يقتصر السؤال الجوهري على ما إذا تم إيداع كود المصدر، بل يتعلق بما إذا كانت المواد المودعة مكتملة ومحدثة وقادرة على دعم التعافي بشكل فعلي.

٥. يعزز النظام الجديد لإدارة المخاطر التشغيلية الصادر عن مصرف الإمارات العربية المتحدة المركزي التركيز على المرونة التشغيلية والعمليات الحيوية والاعتماد على الأطراف الثالثة. كيف يغير هذا التوجه التنظيمي الأسئلة التي ينبغي على المؤسسات المالية طرحها حول مزودي البرمجيات الحيوية؟

من المهم أنه ليس هناك نص محدد في نظام المصرف المركزي يفرض الحساب الضامن للبرمجيات كمتطلب محدد.

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

بالنسبة للمؤسسات المالية، يصبح هذا التحول جوهريًا في طبيعة النقاش حول مزودي البرمجيات الحيوية.

تتحول الأسئلة إلى: ما هي أوجه الاعتماد على برمجيات الأطراف الثالثة التي تدعم عملياتنا الحيوية؟ ماذا يحدث إذا لم يتوفر لنا خدمات أحد هؤلاء المزوّدين؟ هل يمكن توفير بديل خلال الإطار الزمني المطلوب؟ إذا كان الاستبدال صعباً، ما هي خيارات الاستمرارية المتاحة لدينا؟

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

يمكن لهذه التدابير أن تدعم الأهداف الأكثر شمولاً للمرونة التشغيلية والاستعداد، لكنها لا يجب أن تُعتبر كمزيد من الضمانات للامتثال التنظيمي.

٦. قد تفترض العديد من المؤسسات أن إيداع كود المصدر في حساب ضامن للبرمجيات يوفر لها حماية كافية. فما هي الأسباب الأكثر شيوعاً التي قد تجعل هذه الترتيبات عاجزة عن توفير قدرة فعالة على التعافي عند الحاجة الفعلية؟

المسألة الأساسية تكمن في أن القدرة على الوصول إلى المواد المودعة لا تعني تلقائياً أنه يمكن استخدامها بفاعلية.

قد تنص اتفاقية الحساب الضامن على حق الوصول إلى الموارد البرمجية، لكن المواد المودعة قد تكون غير مكتملة، أو غير محدثة، أو غير موثقة بشكل كافٍ. وفي بعض الأحيان، قد تتسلم المؤسسة كود المصدر لكنها تظل تفتقر إلى تعليمات النشر أو معلومات التهيئة أو المعرفة التشغيلية أو أية مكونات تقنية ضرورية لاستعادة تشغيل التطبيق.

لذا، فإن التحقق الفني يصبح ذا أهمية كبرى.

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

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

لذا، ينبغي أن يكون الهدف هو الانتقال من مجرد الحصول على حماية تعاقدية إلى امتلاك قدرة حقيقية للتعافي يمكن تفعيلها عند الحاجة.

٧. تزداد الأهمية بالسيادة الرقمية والمرونة التنظيمية والاعتماد على مزودين خارجيين للتكنولوجيا في منطقة الشرق الأوسط. هل أصبحت المؤسسات في المنطقة أكثر نضجًا في تقييم استمرارية البرمجيات، أم لا تزال هناك فجوات كبيرة؟

من الواضح أن الاهتمام في المنطقة بشأن المرونة التشغيلية والاعتماد على الأطراف الثالثة وقدرة إثبات أن ترتيبات الاستمرارية عملية ومحدثة يتزايد ملحوظ.

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

أحد التحولات المهمة هو الانتقال من السؤال عما إذا كانت ترتيبات الاستمرارية موجودة، إلى السؤال عما إذا كانت قد خضعت للاختبار بالفعل.

وعن البرمجيات الحيوية، يجب أن يكون لدى المؤسسة القدرة على إثبات أن المواد اللازمة للتعافي محدثة، وأن المعرفة والوثائق المطلوبة متوافرة، وأن ترتيبات الاستمرارية قابلة للتفعيل إذا تعذر على المزود الاستمرار في تقديم الدعم.

تتبلور هنا أهمية التحقق الفني المستقل.

الاتجاه الأوسع هو نحو تحقيق مرونة فعلية وقابلة للتحقق والتطبيق، بدلاً من الاكتفاء بالحماية التعاقدية.

٨. إذا كنت تقدم المشورة اليوم إلى مجلس إدارة أو فريق تنفيذي، فما هي أهم ثلاثة أسئلة ينبغي عليهم طرحها لتقييم قدرة مؤسستهم على الاستمرار في العمل إذا توقف مزود برمجيات حيوية فجأة عن دعم تطبيق أساسي؟

سأطرح ثلاثة أسئلة أساسية.

أولًا: هل قمنا بإعداد ترتيبات الاستمرارية قبل وقوع أي اضطرابات؟

يجب أن تفهم المؤسسة أوجه الاعتماد على البرمجيات التي تدعم العمليات الحيوية، والتأكد من أن الترتيبات المناسبة موجودة بالفعل.

ثانيًا: هل تحققنا بشكل مستقل من أن هذه الترتيبات ستؤدي الغرض منها بفعالية؟

فلا يكفي أن يعرفوا أن كود المصدر أو المواد التقنية قد أودعت في مكان ما. تحتاج المؤسسة إلى أدلة قوية على أن هذه المواد مكتملة ومحدثة وقادرة على دعم التعافي.

ثالثًا: هل يمكن تفعيل هذه الترتيبات فعليًا إذا تعذر على المزود الاستمرار في تقديم الدعم؟

هذا يعني ضرورة توافر الحقوق القانونية، والمواد التقنية، والمعرفة التشغيلية، والإجراءات الواضحة، وقدرة على التعافي خضعت للاختبار لضمان استجابة فعالة.

تعكس هذه الأسئلة الثلاثة ما نراه كجوهر مرونة البرمجيات ‎(Software Resilience)‎:

مرونة تبنى منذ مرحلة التصميم.
مرونة يتم التحقق منها، لا يتم افتراضها.
جاهزية للتصدي للاضطرابات.

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