مركز الثقة في ويب بايونير

1. 01 مهندس
2. 02 مستودع Git
3. 03 مراجعة الكود
4. 04 بناء واختبار آلي
5. 05 بيئة تجريبية
6. 06 موافقة
7. 07 الإنتاج
8. 08 مراقبة

فصل البيئات

العمل الجاد لا يجري على الخادم الحي. نفصل بين بيئة التطوير والبيئة التجريبية وبيئة الإنتاج، ولكل منها إعداداتها وصلاحياتها وبياناتها.

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

إدارة التغيير

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

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

أمان الكود المصدري

الكود هو المنتج. نتعامل معه على هذا الأساس.

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

الوصول إلى بيئة الإنتاج

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

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

الهويات وإدارة الوصول

الحسابات المشتركة هي أسرع طريق لفقدان القدرة على معرفة من فعل ماذا.

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

أمان البنية التحتية

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

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

أمان التطبيقات

نبني وفق ما هو متعارف عليه في قائمة OWASP لأكثر عشر مخاطر شيوعا في تطبيقات الويب، ونعالجها في الكود لا في التوثيق فقط.

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

أمان تطبيقات الجوال

التطبيق ليس حدود الأمان. الخادم هو الحدود.

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

المدفوعات وبيانات البطاقات

أهم ما يجب أن تعرفه عن أي متجر نبنيه: بيانات البطاقة لا تمر من عندنا أصلا.

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

حماية البيانات

بيانات عملائك ليست بياناتنا، ونتعامل معها على هذا الأساس.

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

إدارة الأسرار

أكثر التسريبات شيوعا ليست اختراقا، بل مفتاح ترك داخل مستودع كود.

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

النسخ الاحتياطي والتعافي

النسخة الاحتياطية التي لم تختبر ليست نسخة احتياطية. جدول النسخ ومدة الاستبقاء يحددان في اتفاق الدعم لكل نظام.

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

المراقبة والرصد

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

• مراقبة توفر الخدمة من الخارج، لاكتشاف التوقف قبل أن يبلغ عنه مستخدم.
• جمع مقاييس الخادم والتطبيق في لوحات متابعة. أدواتنا الحالية: Prometheus و Grafana.
• تتبع أخطاء التطبيق لحظة حدوثها مع تجميع الأخطاء المتكررة. أداتنا الحالية: Sentry مستضاف ذاتيا.
• تحليل سجلات الخادم لرصد الأنماط غير الطبيعية وحركة الزحف المسيئة.
• تنبيهات تلقائية عند تجاوز حدود التوفر أو الأداء أو معدل الأخطاء.
• مراقبة صلاحية شهادات TLS وتواريخ انتهاء النطاقات.

إدارة الثغرات والتحديثات

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

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

ضمان الجودة

الثقة ليست أمنا فقط. النظام الذي يعمل بشكل خاطئ يكلفك مثل النظام المخترق.

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

استمرارية الأعمال

السؤال العملي هو: ماذا لو اختفى المهندس الذي بنى هذا؟ الإجابة يجب ألا تكون كارثة.

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

الأفراد والسرية وإنهاء الوصول

نوقع اتفاقية سرية قبل استلام أي مادة حساسة تخص المشروع.

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

مزودو التقنية

أي نظام حديث يعتمد على أطراف ثالثة. الشفافية هي أن تعرف من هم قبل التوقيع، لا بعده.

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

ملكية الكود والبيانات والبنية التحتية

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

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

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

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

إن كنت تعتقد أنك اكتشفت مشكلة أمنية في نظام تملكه ويب بايونير أو تشغله، راسلنا قبل نشرها في أي مكان آخر.

support@web-pioneer.com

أرفق ما يكفي لإعادة إنتاج المشكلة. سنؤكد الاستلام ونعود إليك بما توصلنا إليه.

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

من يملك الكود المصدري؟

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

هل توقعون اتفاقية عدم إفشاء؟

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

هل يمكن أن تبقى البنية التحتية تحت ملكيتنا؟

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

هل يمكنكم العمل داخل حسابنا السحابي الحالي؟

نعم. نعمل داخل حسابك على AWS أو Google Cloud أو Azure أو غيرها، بصلاحيات محددة النطاق، وتبقى الفوترة والملكية عندك.

كيف يضبط الوصول إلى بيئة الإنتاج؟

الوصول مقيد ولا يمنح تلقائيا لكل من يعمل على المشروع. الدخول بمفاتيح SSH خلف جدار ناري، بحساب مستقل لكل شخص، بصلاحيات بقدر المسؤولية، وتسحب عند انتهاء الحاجة. التغييرات قابلة للتتبع.

هل تقدم نسخ احتياطية؟

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

هل تخزنون بيانات بطاقات الدفع؟

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

هل تنفذون اختبار اختراق؟

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

كيف تتعاملون مع الأعطال؟

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

هل تدعمون التطبيقات بعد الإطلاق؟

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

هل يمكنكم استلام وترحيل تطبيق قائم بناه فريق آخر؟

نعم. نبدأ بمراجعة تقنية للكود والبنية التحتية والوضع الأمني، ونعطيك تقريرا بما وجدناه قبل أي التزام بالتطوير. أحيانا تكون التوصية ألا تعيد البناء.

ماذا نستلم بالضبط عند التسليم النهائي؟

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

الخطوة التالية

سؤال محدد قبل التعاقد؟

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

تواصل معنا بيانات الشركة →