Article 21(2)(d) سؤال يطرحه البائع. الاستضافة الذاتية هي الجواب الذي يُغنيك عن الديون.

ملخّص تنفيذي. يجعل Article 21(2)(d) من NIS2 مخاطر سلسلة التوريد سؤالاً على مستوى مجلس الإدارة، لا هامشاً في وثيقة الشراء. لا يُلزم التوجيه فعلياً بالاستضافة الذاتية، غير أنه يسألك عمّا يوجد في مسار بياناتك وما الذي يحدث لك حين يمرّ أحد هؤلاء البائعين بيوم سيئ. تُلغي البنية التحتية ذاتية الاستضافة ثلاثة من المستويات الأربعة في معظم مسارات بيانات SaaS، لكنها لا تُلغي الأربعة جميعاً، والادعاء بخلاف ذلك هو تحرّك تسويقي يُورّط كبير مسؤولي أمن المعلومات أمام المدققين.

• نص التوجيه وإرشادات ENISA، بصياغة واضحة.
• مسار بيانات SaaS ذو الأربع طبقات الذي تنسى معظم الفرق رسمه.
• ما يُزيله نموذج Rediacc ذو الأداتين من سجل بائعيك، وما يُبقيه فيه.
• قائمة تدقيق شرائية من ستة أسئلة لكل بائع يدّعي أنه “جاهز لـ NIS2”.

في يوليو 2020، دفعت Blackbaud فدية وأبلغت العالم لاحقاً. أخطرت ما يزيد على 13,000 مؤسسة عميلة بعد وقوع الاختراق، وواجهت دعاوى جماعية في سبع ولايات قضائية، ودفعت في نهاية المطاف 49.5 مليون دولار في تسويات مع المدعين العامين للولايات وغرامة 3 ملايين دولار من هيئة SEC بسبب إفصاحات مضلّلة. كانت كل واحدة من تلك المؤسسات الـ13,000 تمتلك اتفاقية معالجة بيانات مع Blackbaud. راجعت معظمها تقارير SOC 2 الخاصة بـ Blackbaud. وأدرجت كثيرٌ منها Blackbaud في سجل مخاطر البائعين مع تصنيف مستوى وتاريخ تجديد ومالك مسمّى.

لم يوقف شيءٌ من ذلك التسلسل. كانت البيانات على الجانب الخاص بـ Blackbaud من الحدود. حين اختُرقت بيئة النسخ الاحتياطي لديهم، اختُرقت كل مؤسسة عميلة دفعةً واحدة.

يطرح Article 21(2)(d) من NIS2 سؤالاً أصعب من “هل دقّقت في بائعك؟”. يسأل عمّا يوجد في مسار البيانات، وما الذي يحدث لك حين يمرّ ذلك البائع بيوم سيئ. الجواب بالنسبة لمعظم الفرق هو: “نحن هم، ولم ندرك ذلك.”

هذا المقال موجَّه لكبار مسؤولي أمن المعلومات وقيادات الشراء المعيدين التفاوض على اتفاقيات معالجة البيانات في 2026. إنه قراءة في Article 21(2)(d) من منظور مسار البيانات، لا من منظور الشهادات والاعتمادات. كما أنه صريح بشأن ما لا تحلّه البنية التحتية ذاتية الاستضافة، لأن قسم الثغرات هو ما سيسأل عنه المدقق وما ستتخطاه الكتيّبات التسويقية.

ما يُوجبه 21(2)(d) فعلياً

النص الإنجليزي للتوجيه يقرأ كما يلي (لا توجد ترجمة رسمية معتمدة للعربية):

“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use […] and shall include at least the following: […] (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”

ثمة أمران في هذا النص يهمّان المشتري.

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

ثانياً، الالتزام أوسع من العقد. تُحدد إرشادات ENISA التنفيذية لعام 2024، الواردة في الملحق IV من لائحة اللجنة التنفيذية (EU) 2024/2690، الممارسة المتوقعة: الاحتفاظ بسجل موردي تكنولوجيا المعلومات والاتصالات، وتصنيفهم حسب الأهمية، وتقييم كلٍّ منهم من حيث المخاطر على عملياتك وعلى البيانات التي يعالجونها، وتجديد التقييم على دورية محددة. يُسمّي الملحق IV صراحةً “موردي الموردين” ضمن النطاق، وهو المكان الذي تكتشف فيه معظم الفرق أن سجل بائعيها ليس سجلاً حقيقياً، بل هو قائمة عقود مع لاصقة.

إن كنت تنظر إلى هذا من الجانب الشرائي، فالترجمة العملية هي: كل بائع يملك وصولاً منطقياً إلى بياناتك الإنتاجية يجب إحصاؤه وتسجيله ومراقبته وجعله قابلاً للاستبدال. “قابل للاستبدال” هو الجزء الذي يكسر معظم الترتيبات القائمة.

مسار بيانات SaaS ذو الأربع طبقات الذي تنسى معظم الفرق رسمه

اجلس مع مسؤول شراء وتتبّع ما يجري حين يكتب منتج بائع النسخ الاحتياطي سجلاً واحداً. مسار البيانات الحقيقي يبدو هكذا، من الأعلى إلى الأسفل:

1. تطبيق البائع. الكود الذي يستوعب بياناتك ويتخذ قرارات التوجيه ويطبّق منطق الأعمال. يعمل على بنية البائع التحتية. يصونه البائع ويرقّعه ويراقبه.
2. سحابة البائع. منطقة الحوسبة الضخمة أو مركز بيانات البائع الخاص الذي يعمل فيه التطبيق. وحدات التخزين والشبكات وإدارة الهوية والوصول. غالباً ما تكون مزوداً سحابياً ضخماً تربطه بالبائع اتفاقية معالجة فرعية.
3. حضانة مفاتيح البائع. مفاتيح التشفير التي تحمي البيانات الساكنة في سحابة البائع. في معظم ترتيبات SaaS، يحتفظ البائع بهذه المفاتيح. “المفاتيح التي يديرها العميل” متاحة أحياناً كخيار في المستويات الأعلى، لكن في تلك الترتيبات تظل المفاتيح في خدمة إدارة المفاتيح KMS التابعة للمزود السحابي الضخم والتي يمكن لإدارة الهوية والوصول لدى البائع استدعاؤها.
4. المعالجون الفرعيون للبائع. الخدمات الخارجية التي يستخدمها البائع (شبكة توصيل المحتوى CDN، والمراقبة، والفوترة، وأدوات دعم العملاء) والتي قد تعبر بياناتك أو تخزّنها أو تخزّن البيانات الوصفية المشتقة منها.

كل واحدة من هذه الطبقات الأربع هي إدخال في سجل موردي Article 21(2)(d) لديك. لكل منها تاريخها الخاص في الحوادث، ونطاق انفجار الاختراق الخاص بها، وسطح تفاوضها التعاقدي الخاص. حين تجدد عقدك مع بائع SaaS، تجدد الطبقات الأربع ضمنياً، لأن عقد بائع SaaS هو الوحيد الذي يمكنك التفاوض عليه.

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

Blackbaud وحضانة المفاتيح على طراز Druva ونمط التسلسل

ثمة ثلاثة تفاصيل من إيداعات Blackbaud لدى هيئة SEC تهم قراءة NIS2.

أولاً، احتفظت Blackbaud بمفاتيح تشفير بيانات العملاء، بما في ذلك بيئة النسخ الاحتياطي التي كانت هدف الاختراق. لم تكن المفاتيح التي يديرها العميل متاحة. في التقاضي اللاحق للحادث أمام هيئة SEC، وُصف ذلك بأنه ثغرة في ضوابط التحكم لا انتهاك، لأن عقود Blackbaud أجازت ذلك. إلا أن منظور NIS2 للترتيب ذاته، بموجب Article 21(2)(d)، أشد قسوةً، لأن العميل لا يستطيع تقييم مخاطر ضابط تحكم ليس لديه رؤية فيه.

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

ثالثاً، تلقّت ما يزيد على 13,000 مؤسسة عميلة إشعارات اختراق. كان كثيرٌ منها منظمات غير ربحية صغيرة ومدارس لا طاقة تشغيلية لها للاستجابة، ولا دليل استرداد بعد الكوارث، ولا بائع نسخ احتياطي ثانٍ تتحول إليه. تحوّل حادث البائع بهذا المعنى إلى حادثهم هم.

بالنسبة للنسخ الاحتياطي الحديث من SaaS على طراز Druva، تتحسن البنية في بعض الجوانب (فصل المفاتيح لكل مستأجر أكثر شيوعاً، وخيار BYOK متاح في المستويات الأعلى)، لكن مسار البيانات ذو الأربع طبقات لا يزال هو نفسه. تطبيق البائع، وسحابة البائع (عادةً AWS)، وحضانة المفاتيح (أحياناً يديرها البائع، وأحياناً BYOK في خدمة KMS للعميل، وأحياناً هجينة)، والمعالجون الفرعيون. يصل اختراق في أي طبقة إلى كل العملاء في آنٍ واحد، لأن بيانات كل عميل على الجانب ذاته من الحدود.

هذه هي الحجة البنيوية. إنها ليست هجوماً على Druva. تُدار Druva بأسلوب أكثر إحكاماً مما كانت عليه Blackbaud. الحجة هي أن بنية أي منتج نسخ احتياطي مصمّم على نهج SaaS تجعل اختراقات الطبقة الثانية والثالثة التزاماً بموجب 21(2)(d) لا يستطيع العميل الوفاء به بصورة فعلية.

الاستضافة الذاتية تُلغي ثلاثاً من الطبقات الأربع

بُنيت Rediacc بشكل مختلف. البنية الكاملة موثّقة في صفحة البنية التحتية، لكن الشكل المتعلق بسلسلة التوريد هو ثنائيتان تتواصلان عبر SSH:

• rdc يعمل على محطة عمل المشغّل. يقرأ ملف إعداد JSON مسطّح (ضمن ~/.config/rediacc/)، ويتصل بأجهزة المشغّل الخاصة عبر SSH، ويُرسل الأوامر.
• renet يعمل على خادم المشغّل الخاص بصلاحيات جذرية، ويدير صور الأقراص المشفّرة بـ LUKS2، ومشغّلات Docker المعزولة، والوكيل العكسي.

لا يسجّل المشغّل الدخول إلى بنية Rediacc-الشركة لإجراء نسخ احتياطي أو استعادة أو تفريع. لا توجد سحابة لـ Rediacc-الشركة في مسار البيانات. يُخزَّن بيانات اعتماد LUKS2 للمستودع في ملف إعداد المشغّل المحلي (وضع 0600)، ولا يُرسَل أبداً إلى الخادم أو إلى Rediacc. يبدو مسار البيانات هكذا:

1. محطة عمل المشغّل. تشغّل rdc. تحمل بيانات اعتماد LUKS2.
2. خادم المشغّل الخاص. يشغّل renet. يحمل المستودعات المشفّرة بـ LUKS2.
3. هدف النسخ الاحتياطي الخاص بالمشغّل. أي تخزين متوافق مع rclone (S3، وB2، وOneDrive، وMinIO المحلي). يستقبل الأحجام المشفّرة.

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

هذه هي حجة مسار البيانات، وهي الحجة الصحيحة التي يُبدأ بها في أي نقاش حول سجل الموردين. يستطيع منافس SaaS تقديم مفاتيح يديرها العميل (ومعظم الحديثين منهم يفعلون ذلك). لكن منافس SaaS لا يستطيع تقديم عرض “نحن لسنا معالجاً فرعياً.”

النقطة الثانية، بعد أن تُحكم حجة مسار البيانات، هي حضانة المفاتيح. مع Rediacc، تكون بيانات اعتماد LUKS2 في ملف إعداد المشغّل، وبسط الأمر ذلك. لا توجد ضمانة مفتاح، ولا خدمة استرداد يستطيع Rediacc-الشركة تشغيلها إن فقد المشغّل بيانات الاعتماد. هذه أيضاً البنية الموصى بها لـ مخزن الإعداد عديم المعرفة، حيث يُشتق مفتاح التشفير من جانب العميل من امتداد PRF لمفتاح المرور، ويخزّن الخادم كتلاً غامضة. لا يستطيع الخادم قراءة مفاتيح SSH أو بيانات اعتماد LUKS2 أو عناوين IP أو أي إعداد نصي. تدوير رمز الوصول لا يمنح الخادم قراءة استرجاعية للبيانات السابقة.

بالنسبة لـ Article 21(2)(h) (التشفير)، هذا مهم. بالنسبة لـ Article 21(2)(d) (سلسلة التوريد)، فهو أكثر أهمية، لأنه يُزيل آخر مسار وصول منطقي من Rediacc-الشركة إلى بيانات المشغّل.

ما لا تُلغيه الاستضافة الذاتية

تُحوّل الاستضافة الذاتية قائمة الموردين، لا تحذفها. ثلاثة أمور سيظل المدقق يسأل عنها:

1. لا يزال لديك موردون، لكنهم مختلفون. مورد الأجهزة (Hetzner، وHostinger، وOVH، أو مركز بياناتك، أو أجهزتك الخاصة). مشغّل الأجهزة الافتراضية (KVM، وVMware). نظام التشغيل (Debian، وUbuntu، وRHEL). سجل الحاويات (Docker Hub، وGHCR، أو سجلك الخاص). الصور الأساسية التي تسحبها خدماتك. كل واحد من هؤلاء هو إدخال في Article 21(2)(d). تُحوّل الاستضافة الذاتية قائمة الموردين، لا تحذفها.

2. لا تمتلك Rediacc ISO 27001 أو SOC 2 أو BSI C5 بعد. هذه في خارطة الطريق، لا في حوزتها حالياً. بالنسبة لفريق شراء يستخدم الشهادات كآلية بوابة، هذا احتكاك حقيقي. الرد القابل للدفاع عنه هو ما كان هذا المقال يطرحه: حجة مسار البيانات تعني أن معظم ما تُثبته تلك الشهادات (ضوابط أمن سحابة البائع، وإدارة وصول موظفيه، وإدارة معالجيه الفرعيين) خارج النطاق، لأن Rediacc-الشركة ليست في مسار البيانات. تلك الحجة تحتاج إلى صياغة دقيقة وقابلة للدفاع، لا إلى الاستعاضة بها عن الشهادات حين تكون الشهادات ما يحتاجه المشتري.

3. طبقة GRC لا تزال مسؤوليتك. تُتيح Rediacc للمشغّل سجل تدقيق مرتبطاً بالتجزئة بأكثر من 70 حدثاً (rdc audit verify يتحقق من السلسلة من البداية إلى النهاية). لكنها لا تُتيح سجل موردين أو إطار ضوابط أو سير عمل لجمع الأدلة. تلك لا تزال تأتي من Drata، وVanta، وOneTrust، أو أحد المنافسين الأوروبيين. يغطّي مقال التكلفة الحقيقية المرافق شكل التكلفة لهذا التكامل بالتفصيل.

اتفاقية معالجة البيانات التي لم تعد مضطراً إلى التفاوض عليها

لتجسيد هذا الأمر، إليك صف “قبل مقابل بعد” من سجل حقيقي لمحادثة شراء، تم إخفاء هويتها. المشتري هو شركة تصنيع ألمانية تضم 280 موظفاً مصنّفة ككيان “مهم” بموجب Annex II. كان إدخال سجل مورديها الأصلي للنسخ الاحتياطي يبدو هكذا:

بعد الانتقال إلى Rediacc على Hetzner:

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

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

قائمة التدقيق الشرائية

لأي بائع يدّعي “الجاهزية لـ NIS2” في دورة مبيعات 2026، ستة أسئلة:

1. أين يوجد مفتاح تشفير بياناتنا الساكنة؟ إن كان الجواب “في وحدة الأمان الصلبة HSM لدينا” أو “في خدمة KMS للعميل يمكننا استدعاؤها عبر إدارة الهوية والوصول”، فالبائع داخل سلسلة حضانة مفاتيحك. إن كان “في ملف إعدادك المحلي، ولا يصل أبداً إلى بنيتنا التحتية”، فهو ليس كذلك.

2. من في شركتكم يستطيع تقنياً قراءة بياناتنا، بصرف النظر عن الشروط القانونية؟ ليس “من مخوَّل”، بل “من يستطيع ذلك لو أراد وكان سجل التدقيق معطّلاً؟” إن كان الجواب رقماً غير صفري، فتلك هي مجموعتك لتقييم مخاطر التهديدات الداخلية.

3. هل تُختبر الاستعادة مقابل نسخة استنساخية من الإنتاج الحقيقي، أم مقابل بيانات اختبار اصطناعية؟ يشترط Article 21(2)(c) و(e) معاً أن يُستعاد النسخ الاحتياطي فعلياً. البائع الذي يتحقق فقط من البيانات الاصطناعية لا يتحقق من الاسترداد، بل يتحقق من سلامة ملف النسخ الاحتياطي. (للاطلاع على مزيد من التفاصيل، راجع المقال المرافق حول تقييم الفعالية المستمر.)

4. هل يُسجّل مسار التدقيق لديكم نوع الجهة الفاعلة، إنسان أم وكيل آلي، خلف كل إجراء؟ نشاط الوكيل الآلي هو الفئة الأسرع نمواً في سجلات التدقيق. سجل التدقيق لعام 2026 الذي لا يميّز بين الإنسان والوكيل الآلي سيبدو كثغرة بحلول عام 2027.

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

6. ما خطتكم للخروج إن اشترتكم جهة غير أوروبية في 2027؟ إطار الملاءمة في GDPR، وقانون Cloud Act، وقانون FISA 702 كلها أهداف متحركة. ادعاء البائع بالإقامة الجغرافية للبيانات اليوم ليس ضماناً بعد ثلاث سنوات. سؤال المشتري هو ما الذي يحدث لمسار البيانات إن تغيّرت ملكية البائع.

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

ما يعنيه هذا لدورة التجديد القادمة

إن كنت مقبلاً على تجديد عقد النسخ الاحتياطي أو خطة الاسترداد بعد الكوارث خلال الأشهر الاثني عشر القادمة وكان Article 21(2)(d) حاضراً في بطاقة أداء الشراء، فثمة ثلاث خطوات ملموسة:

1. ارسم مسار بيانات بائعك الحالي ذا الأربع طبقات على لوح أبيض. إن لم تستطع تسمية المعالج الفرعي الثالث في التسلسل، فلديك مشكلة اكتمال في السجل تسبق NIS2، والتجديد هو اللحظة المناسبة لإصلاحها.
2. طبّق قائمة الأسئلة الستة أعلاه على البائع الحالي. أرسل الإجابات إلى مسؤول حماية بياناتك ومدققك واسألهم إن كانت الثغرات مقبولة. إن شملت الثغرات الطبقة الثالثة (حضانة المفاتيح) أو الطبقة الرابعة (معالجون فرعيون لم تُحصهم)، فتلك هي نقطة الاختراق.
3. انظر كيف سيبدو سجل مورد بديل مع مستوى تحكم ذاتي الاستضافة. قارن إدخالات السجل، لا تكاليف الترخيص. تكاليف الترخيص متشابهة في حدود عامل اثنين؛ أما إدخالات السجل فذات أشكال مختلفة. (يتناول المقال المرافق حول التكلفة البنيوية لمجموعة أدوات NIS2 ما يتقلّص وما يبقى بالتفصيل.)

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

للاطلاع على الربط العلني لقدرات Rediacc بمواد NIS2، راجع NIS2 و DORA. للإطار الأشمل للامتثال، راجع نظرة عامة على الامتثال، والسيادة على البيانات، وOn-Premise.