كيف تطلب تقييم أمان لموقعك في الإسكندرية وتتسلم تقريرًا قابلًا للاستخدام؟

١. حوّل القلق إلى سؤال محدد

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

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

٢. املأ نطاق العمل قبل إعطاء صلاحية الدخول

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

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

٣. اتفق على الموعد ومسؤولي الاتصال والتوقف

استخدم الترتيب التالي كنموذج تشغيلي، ثم عدّله بحسب ساعات عمل الاستوديو وتوفر المطور:

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

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

٤. حدّد شكل الأدلة وطريقة حمايتها

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

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

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

٥. قيّم التقرير بالأدلة، وتعامل بوضوح مع تنبيهات الأدوات

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

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

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

٦. اكتب شروط إعادة الفحص وحدود الخدمات المستضافة

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

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

٧. انسخ هذه البنود إلى سجل المشروع

أكمل البنود التالية مع جهة التقييم قبل تسليم أي صلاحية:

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

اطلب من الطرفين شرح المستند نفسه بلغة بسيطة. إذا اختلف تفسير بند، فاحسموه قبل أول فحص.

أسئلة شائعة

هل عدم وجود مشكلات مؤكدة يعني أن الموقع آمن؟

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

هل يثبت التقرير أمان مزود الدفع؟

لا، إذا كان المزود مستبعدًا من النطاق. وثّق هذا الحد واطلب الأدلة المناسبة عن المزود بصورة مستقلة.

هل نحذف تنبيه الأداة الذي لم نتأكد منه؟

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