أمن سلسلة التوريد: المورد يُقاس بأدلة لا باستبيان

أربعة أرقام تحدد حجم المشكلة

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

• 30% من الاختراقات في تقرير Verizon DBIR 2025 شملت طرفًا ثالثًا (من 22,052 حادثة و12,195 اختراقًا مؤكدًا)، أي ضعف النسبة المسجلة في التقرير السابق (15%). ثلاث حوادث من كل عشر لم تكن عن ثغرة في جدارك، بل عن مسار دخلته أنت بنفسك عبر عقد.
• استغلال الثغرات كوسيلة وصول أولى ارتفع 34% ليصبح نحو 20% من الاختراقات. الثغرة التي تُستغل ليست بالضرورة في نظامك؛ قد تكون في مكتبة سحبها فريقك أمس.
• 2,773 جهة و95.8 مليون فرد في حادثة MOVEit Transfer (مايو 2023، Cl0p، CVE-2023-34362) بحسب حصر Emsisoft. والأهم من الرقم: من 2,098 ضحية معروفة، كان 1,690 (نحو 80%) لا يستخدمون MOVEit أصلًا. أصابهم الاختراق لأن بياناتهم كانت على نظام طرف آخر.
• أكثر من 500 حزمة في دودة npm المسماة Shai-Hulud (سبتمبر 2025، تنبيه CISA في 23 سبتمبر، وتقرير CERT/CC رقم VU#534320): سكربت تثبيت يسرق رموز GitHub وAWS وGCP وAzure ورموز npm، ثم يعيد نشر الحزمة عبر الرموز المسروقة نفسها.

الاستنتاج العملي: ميزانيتك الأمنية توزَّع على ثلاثة أسطح — حدودك، وكود غيرك الذي يعمل داخل حدودك، وبياناتك التي تعمل داخل حدود غيرك. الاستبيان يخدم السطح الثالث جزئيًا، ويكاد لا يخدم الثاني إطلاقًا.

ثلاثة مسارات، لا مسار واحد

الخلط بين هذه المسارات هو سبب أكثر قرارات الموردين سوءًا، لأن كلًا منها يحتاج دليلًا مختلفًا تمامًا:

1. كود يعمل بصلاحياتك

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

2. بيانات اعتماد تسكن عندك

حساب خدمة لمورد، أو مفتاح API، أو مستخدم تكامل. هنا السؤال: ماذا يقرأ، وماذا يكتب، وهل الاعتماد دائم أم قصير العمر، ومن في المورد يملكه. هذه هي الفئة التي تنتج معظم الحوادث الفعلية لأن أحدًا لم يكتب أبدًا قائمة كاملة بها.

3. بيانات سلّمتها إليهم

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

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

ما الذي استُهدف فعلًا في 2024 و2025: مسار النشر، لا الكود

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

• tj-actions/changed-files (مارس 2025): أعيد توجيه الوسوم من v1 إلى v45.0.7 إلى التزام خبيث، فسرّبت مهام التكامل المستمر رموزًا، وتأثر أكثر من 23,000 مستودع. تنبيه CISA صدر في 18 مارس 2025. من ثبّت الالتزام بالبصمة (SHA) بدل الوسم لم يتأثر.
• polyfill.io (يونيو 2024): نطاق ومستودع انتقلا إلى مالك جديد (Funnull) في فبراير 2024، ثم بدأ تقديم تعليمات برمجية مشروطة بالجهاز إلى نحو 110,000 موقع. من ثبّت المكتبة محليًا لم يتأثر، ومن بقي يطلبها من نطاق الطرف الثالث في وسم الصفحة سُلِّم جهاز المستخدم.
• XZ Utils (CVE-2024-3094): الحمولة لم تكن في تاريخ git، بل في ملفات الإصدار التي تبني منها التوزيعات، عبر ماكرو في نظام البناء. أي أن مراجعة الكود على GitHub لم تكن كافية لرؤيتها.
• Shai-Hulud: سكربت ما بعد التثبيت هو الحدث، والرمز المسروق هو الوقود. الحماية هنا ليست مراجعة الكود بل منع السكربتات عند التثبيت في بيئة البناء، وتقييد الرموز بصلاحية القراءة فقط.

هذا يقلب ترتيب الأسئلة المعهود. السؤال الأول ليس هل هذا المورد مسؤول، بل هل يستطيع هذا المسار أن يغيّر ما أُصادق عليه. الأدلة المقابلة معروفة ومجانية: تثبيت الإصدارات ببصمة، وملف قفل مُلتزَم في المستودع، وتوقيع الإصدارات وبيانات مصدرها (provenance) وهي متاحة على npm منذ أبريل 2023، وقائمة مكونات برمجية (SBOM) بالعناصر الدنيا التي نشرتها NTIA في يوليو 2021، ومستوى نضج بناء مثل SLSA 1.0 (أبريل 2023). لا تحتاج إلى شراء شيء لتطبيقها؛ تحتاج إلى قرار كتابي بأن النشر لا يمر بغيرها.

لماذا يفشل الاستبيان: سقف الشهادة نفسها

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

ولا يعني هذا إسقاط الشهادات، بل وضعها في موقعها: شرط عبور لا شرط كفاية. أربعة أسئلة تُكمل الناقص وتُجاب بأدلة لا بشهادات:

1. أي حساب في جهة المورد يستطيع الوصول إلى تكاملنا، وهل يملكه شخص محدد بالاسم؟
2. ماذا يستطيع هذا الحساب أن يقرأ، وماذا أن يكتب — على مستوى الجدول أو الحقل؟
3. هل الاعتماد دائم أم يُصدر عند الطلب، وما أقصى عمر له، وهل يُبطَل تلقائيًا عند انتهاء العقد؟
4. ما آخر تغيير في صلاحيات هذا الحساب، ومن طلبه، وأي سجل يثبته؟

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

خريطة الوصول: المستند الذي لا يوجد عند أحد

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

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

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

نموذج تصنيف بالنقاط: خمسة محاور وعتبات صريحة

التصنيف بلا عتبات يصبح رأيًا. النموذج التالي يعطي كل مورد درجة من 5 إلى 15 على خمسة محاور، كل محور من 1 إلى 3، ثم يحدد طبقة تعامل واضحة. استخدمه كما هو أول مرة، وعدّله بعد أول ربع عندك بيانات حقيقية عنه.

المحور	1 نقطة	2 نقطتان	3 نقاط
مدى الوصول	بيانات عامة أو لا وصول	بيانات داخلية أو قراءة محدودة	بيانات شخصية حساسة أو إنتاج كامل
الصلاحية	قراءة فقط	كتابة أو تغيير تهيئة	إدارة أو إنشاء مستخدمين
عمر الاعتماد	أقل من ساعة	مقيّد بالوقت ومُدار	دائم بلا مالك محدد
الأطراف الرابعة	لا معالجين فرعيين	قائمة منشورة ومعروفة	سلسلة غير معروفة أو تتغير بلا إشعار
قابلية الفصل	يمكن إيقافه في ساعات	أيام، مع بديل	لا بديل لأسابيع أو أشهر

ثم تُقرأ الدرجة على ثلاث طبقات:

• الطبقة الأولى (12–15): تقييم كامل قبل التجديد، واختبار تقني على جانبك، ومراجعة ربع سنوية، وبند تعويض واضح في العقد.
• الطبقة الثانية (8–11): استبيان مع أدلة محددة (سجلات صلاحيات، قائمة معالجين فرعيين)، ومراجعة نصف سنوية.
• الطبقة الثالثة (5–7): مراجعة سنوية وتحقّق تعاقدي فقط.
• قاعدة تجاوز: أي مورد يحصل على 3 في محور الصلاحية أو الأطراف الرابعة يُعامَل كطبقة أولى ولو كانت درجته أقل. الدرجة الإجمالية تخفي محورًا واحدًا كارثيًا، والقاعدة تمنع ذلك.

ثلاثة أمثلة محسوبة: بوابة دفع (3+3+2+3+3 = 14، طبقة أولى)، نظام تذاكر داخلي (2+2+2+2+2 = 10، طبقة ثانية)، مزوّد ترجمة بلا بيانات شخصية (1+1+1+2+1 = 6، طبقة ثالثة). المهم ليس الرقم، بل أن المشتريات والأمن يعملان على النموذج نفسه، وأن كل تغيير في الدرجة يُسجَّل بسببه.

ما يُختبر فعلًا: جانبك أنت، وبإذن مكتوب للجانب الآخر

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

على جانبك (لا يحتاج إذنًا من أحد) أربعة اختبارات تعطي إشارة أقوى من أي استبيان:

1. مراجعة صلاحيات الحساب: أعِد تمثيل صلاحيات حساب التكامل على بيئة محاكاة، وجرّب قراءة جدول لم يُقصد له أن يُقرأ. النتيجة دليل، لا وصف.
2. اختبار الإبطال: أوقف الحساب ثم قِس الزمن حتى تختفي آثاره من الأنظمة المتصلة. مورد يُبقي الجلسة ساعات بعد الإبطال مشكلة أكبر من مورد بلا شهادة.
3. اختبار انتهاء العقد: على بيئة تجريبية، شغّل إجراء الفصل كما هو مكتوب في العقد. إن كان مكتوبًا ولم يُنفَّذ، فالعيب في الإجراء لا في النص.
4. فحص مخرجات البناء: هل يحتوي ما نُشر على ما بُني، وهل ملفات القفل موجودة في المستودع، وهل التوقيع يُتحقق منه عند التنزيل.

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

الأطراف الرابعة: القائمة التي تُنسى ثم تُكلّف

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

• قائمة منشورة ومحدّثة بالمعالجين الفرعيين والخدمات التي يقدمونها، مع تاريخ آخر تحديث.
• إشعار مسبق بالتغيير (ثلاثون يومًا حد أدنى معقول) وحق اعتراض مكتوب. مورد لا يمنحك حق الاعتراض يمنحك إشعارًا فقط، والفرق كبير.
• تمرير الالتزامات: التزاماتك مع عميلك أو جهة تنظيمية تُمرَّر نصًا إلى المعالج الفرعي، لا تُترك لتفسيره.

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

خريطة الضوابط: من رقم الضابط إلى المستند

الضوابط السعودية للمكوّن الرابع في الضوابط الأساسية ECC-2:2024 مكتوبة بوضوح، لكنها تُقرأ عادة كقائمة التزامات لا كقائمة مستندات. الجدول التالي يقرأها بالاتجاه المعاكس: ما المستند الذي يثبت كل ضابط يوم التدقيق.

الضابط	ما يطلبه	المستند الذي يقابله
4-1-1	أن يتضمن العقد مع الطرف الخارجي متطلبات الأمن السيبراني، وأن تُعتمد قبل التوقيع	ملف العقد مع ملحق أمني مُعتمد وتاريخ اعتماده
4-1-2-1	اتفاقية سرية، وإتلاف آمن للمعلومات عند انتهاء الخدمة	بند الإتلاف + شهادة إتلاف موقّعة عند الخروج
4-1-2-2	قنوات وإجراءات للإبلاغ عن الحوادث بين الطرفين	ورقة واحدة: من يتصل بمن، خلال كم، وبأي نموذج
4-1-2-3	إلزام الطرف الخارجي بتطبيق متطلبات الجهة والأنظمة ذات الصلة	نص التمرير في العقد أو ملحقه
4-1-3-1	تقييم مخاطر قبل التعاقد على إسناد أو خدمات مُدارة، وعند أي تغيير تنظيمي	تقييم مخاطر بتاريخ، ونسخة مُحدّثة عند تغيير الضوابط
4-1-3-2	أن تكون مراكز العمليات الأمنية المُدارة التي تُدار عن بعد موجودة بالكامل داخل المملكة	بند موقع الخدمة والبنية في العقد + إقرار من المورد
4-1-4	مراجعة دورية لأمن الطرف الخارجي	جدول مراجعة دورية ونتائج آخر مراجعة (SOC، استبيان، اختبار)
4-2-3-1	تصنيف البيانات قبل استضافتها، وإعادتها بصيغة قابلة للاستخدام عند الانتهاء	سجل تصنيف + بند إعادة البيانات وصيغتها
4-2-3-2	فصل بيئة الجهة عن بيئات العملاء الآخرين	وصف الفصل (حساب منفصل، شبكة، تخزين) + شهادة المورد
4-2-4	مراجعة دورية لخدمات الحوسبة السحابية	نتيجة المراجعة وتاريخ التجديد

وللجهات الخاضعة لمؤسسة النقد، يضيف إطار الأمن السيبراني SAMA CSF المكوّن 3.4 (أمن الأطراف الثالثة): إدارة العقود والموردين (3.4.1)، والإسناد الخارجي (3.4.2) الذي يستلزم موافقة مسبقة على الإسناد الجوهري، والحوسبة السحابية (3.4.3) التي تشترط حق المراجعة والفصل وعدم إعادة الاستخدام. والأهم عمليًا: على الجهات إبلاغ المؤسسة فورًا بأي حادثة متوسطة أو أعلى عبر القناة المخصصة، وهو التزام يبدأ قبل أن تعرف أنت ما حدث عند موردك.

أما نظام حماية البيانات الشخصية فيمنح هذا العمل أساسًا قانونيًا لا اختياريًا: المادة الثامنة تُلزم الجهة باختيار معالج يقدم ضمانات كافية، وبالتحقق من التزامه بشكل مستمر. أي أن سؤال هل لديك أدلة ليس سؤال نضج إداري، بل التزام. وتضيف المادة 18 الإتلاف عند انتهاء الغرض، والمادة 31 متطلبات السجلات، ويحدد اللائحة التنفيذية إبلاغ الجهة المختصة خلال 72 ساعة من العلم بالحادثة. وفي الإمارات تضع المادة 9 من القانون 45/2021 إبلاغ مفوض البيانات، والمادة 20 التزامات المعالج بعقد مكتوب. هذه مواد تقرأ على موردك كما تقرأ على نفسك.

عشر بنود في العقد تعمل أكثر من عشر أدوات

لا يُصلح العقد عيبًا تقنيًا، لكنه يحدد ما تستطيع فعله في اللحظة التي ينكشف فيها العيب. هذه البنود العشرة تُطلب مرة، وتُنقذ في اليوم الصعب:

1. تعريف الأمن السيبراني في العقد بإحالة إلى الضوابط المذكورة أعلاه بالرقم، لا بعبارة عامة.
2. حدود البيانات: تصنيف البيانات المسموح بمعالجتها، وما يُمنع نقلًا أو تخزينًا.
3. الموقع: أين تُعالج البيانات وأين تُخزن، وأي التزام يتحرك إن تغيّر الموقع.
4. الإبلاغ: مهلة إبلاغ (24 ساعة معقولة) وحد أدنى من المحتوى: ماذا حدث، أي اعتماد استُخدم، أي سجلات، أي بيانات، ومن تأثر.
5. التعاون في التحقيق: التزام بالسجلات وتقديمها، ومدد الاحتفاظ بها، وحقك في الوصول إليها.
6. المعالجون الفرعيون: قائمة، وإشعار مسبق، وحق اعتراض، وتمرير الالتزامات.
7. الاختبار والمراجعة: حق مراجعة موثقة (تقرير، أو جلسة، أو زيارة عند الحاجة) بلا تكلفة إضافية معقولة.
8. الفصل والإتلاف: مدة إبطال الوصول بعد الانتهاء، وشهادة إتلاف، وما يبقى في النسخ الاحتياطية ومتى يُحذف.
9. الإشعار بحادثة طرف رابع: أن حادثة معالج فرعي تُعامل كحادثة المورد نفسه، بالمدد نفسها.
10. الأثر: تعويض محدد، وسقف مسؤولية لا يُلغي الالتزامات الأمنية، وحق إنهاء فوري عند إخفاء حادثة.

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

أول 72 ساعة حين يكون المورد هو المخترق

الترتيب هنا يختلف عن حادثة داخلية، لأن أول قرار هو قرار وصول لا قرار تحليل: أوقف الصلاحية، وأبقِ العلاقة. الخطوات بالترتيب:

1. افتح خريطة الوصول واسأل: ما مدى هذا الحساب بالضبط؟ الإجابة تحدد حجم الحادثة في الدقيقة الأولى.
2. أبطل الاعتماد (مفتاح، رمز، حساب) لا العقد. الإلغاء العاطفي للتعاقد في الساعة الأولى يخسرك تعاون المورد في التحقيق.
3. اطلب كتابيًا ستة عناصر: التوقيت، الاعتماد المستخدم، سجلات التكامل، أصناف البيانات المتأثرة، المعالجون الفرعيون المتأثرون، وإجراء الاحتواء. حدد موعدًا للرد (24 ساعة).
4. احفظ سجلاتك أنت قبل أن تُدوَّر: طلبات الواجهة البرمجية، وتسجيل الدخول، والتغييرات. كثيرًا ما تُفقد هذه في محاولة التنظيف السريعة.
5. قيّم التزاماتك بالإبلاغ: في السعودية 72 ساعة للجهة المختصة بحماية البيانات، وإبلاغ فوري للقطاع المالي عند حادثة متوسطة أو أعلى، وأي التزام تعاقدي مع عملائك يبدأ عدّه من الآن لا من يقينك.
6. اكتب ما ستفعله بالبيانات الخارجة: هل تعرف أصنافها؟ هل في العقد بند إتلاف؟ هل تعرف صيغة الإعادة؟ هذه الأسئلة تُجاب قبل الحادثة أو لا تُجاب.

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

ستة أرقام تُقاس كل ربع

إدارة الموردين تموت بالصمت، لأن لا أحد يقيسها. ستة أرقام كافية، وكلها تُستخرج من سجلات موجودة:

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

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

ثلاثون يومًا، الأرخص أولًا

إن لم يكن لديك برنامج إدارة موردين أصلًا، فالترتيب التالي ينتج أثرًا في شهر بلا ميزانية جديدة:

1. الأسبوع 1: خريطة الوصول لعشرين موردًا من سجلات المصادقة، مع مالك بالاسم لكل صف.
2. الأسبوع 2: نقّط الخريطة بالنموذج أعلاه، واعرض على المشتريات قائمة الطبقة الأولى مع سبب واحد لكل اختيار.
3. الأسبوع 3: تحقّق من ملفات قفل الإصدارات في المستودعات الحرجة، وثبّت ما لم يكن مثبتًا. هذا عمل هندسي بخيل الأثر الكبير.
4. الأسبوع 4: جلسة تمرين على مورد واحد: نفّذ خطوات الـ72 ساعة كتابيًا، ودوّن ما فشل.

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

حدود هذه الصفحة

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

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

أسئلة شائعة

هل شهادة ISO 27001 للمورد تكفي لاعتماده؟

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

كم مرة نراجع المورد الواحد؟

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

هل نطلب تقرير SOC 2 Type II من كل مورد؟

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

كيف نقيس مدى الوصول بلا أدوات مكلفة؟

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

هل يجوز أن نختبر أنظمة المورد تقنيًا؟

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

ما الحد الأدنى النظامي في السعودية لتقييم الموردين؟

في الضوابط الأساسية ECC-2:2024 يغطي المكوّن 4-1 الأطراف الخارجية: اعتماد متطلبات أمن سيبراني في العقد (4-1-1)، ومحتوى أدنى يشمل السرية والإتلاف وإجراءات الإبلاغ (4-1-2)، وتقييم مخاطر قبل الإسناد (4-1-3-1)، ومراجعة دورية (4-1-4). ويضيف نظام حماية البيانات الشخصية في المادة الثامنة التزامًا بالتحقق المستمر من التزام المعالج، أي أن الأدلة ليست اختيارية.

ماذا نفعل إذا رفض المورد الإفصاح عن معالجيه الفرعيين؟

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

أمن سلسلة التوريد مسؤولية المشتريات أم الأمن؟

مسؤولية مشتركة بلا نقطة فاصلة: الأمن يحدد الضوابط والأدلة ويقرأ السجلات، والمشتريات تملك العقد والتفاوض على البنود، والمالك التقني للخدمة يوقّع على خريطة الوصول. الفشل يحدث عندما يُفترض أن الطرف الآخر يفعلها؛ والنجاح يبدأ من مستند واحد يشترك فيه الثلاثة، وهو خريطة الوصول الموقّعة.