أمن نظام الصيانة المؤسسي: متطلبات وأدلة تحقق قبل التعاقد

حدّد ما تشتريه وما سيدخل نطاق التقييم

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

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

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

اكتب المتطلب بحيث يمكن اتخاذ قرار بشأنه

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

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

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

اقرأ نطاق تقرير الاختبار قبل خلاصته

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

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

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

المصادقة والوصول يحتاجان اختبار دورة الاستخدام

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

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

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

التشفير سؤال عن المسار والمفاتيح وحدود المسؤولية

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

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

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

لا تترك الملفات والجوال خارج السؤال الأمني

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

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

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

السجل المفيد يثبت الحدث ويحفظ حدوده

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

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

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

نتيجة الفحص تحتاج معالجة وإعادة تحقق

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

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

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

راجع كيف تستمر الضوابط بعد التسليم

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

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

اتفق على التعامل مع الحادث والانقطاع

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

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

قارن العروض على الأدلة والمسؤوليات نفسها

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

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

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

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

ما الذي تثبته في العرض الفني قبل التعاقد؟

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

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