أمان كود

النسخ الاحتياطي / التعافي من الكوارث

• سجل من 14 نسخة احتياطية كاملة لكل قاعدة بيانات كود لمدة 3 أشهر على الأقل: نسخة/يوم لمدة 7 أيام، ونسخة/أسبوع لمدة 4 أسابيع، ونسخة/شهر لمدة 3 أشهر.
• النسخ الاحتياطية مكرّرة في 3 مراكز بيانات مختلفة على الأقل.
• المواقع الفعلية لمراكز بياناتنا محددة في سياسة الخصوصية.
• يمكنك أيضًا تنزيل نسخ احتياطية يدوية من بياناتك الحية في أي وقت عبر لوحة التحكم.
• يمكنك التواصل مع مكتب المساعدة لدينا لاستعادة أي من تلك النسخ الاحتياطية على قاعدة بياناتك الحية (أو بجانبها).
• تجاوز أعطال الأجهزة: للخدمات المستضافة على خوادم فعلية، حيث يمكن أن يقع عطل في الأجهزة، نطبّق نسخًا احتياطيًا محليًا جاهزًا للتشغيل مع مراقبة وإجراء تحويل يدوي.
• التعافي من الكوارث: في حال وقوع كارثة كاملة، مع تعطّل مركز بيانات بالكامل لفترة ممتدة بما يمنع التحويل إلى نسختنا الاحتياطية المحلية الجاهزة (لم يحدث ذلك حتى الآن، وهذه خطة أسوأ الاحتمالات)، فإن أهدافنا هي:
  • هدف نقطة الاستعادة (RPO) = 24 ساعة. أي أن أقصى ما قد تفقده هو 24 ساعة من العمل إذا تعذّر استرجاع البيانات واضطررنا لاستعادة آخر نسخة احتياطية يومية.
  • هدف زمن الاستعادة (RTO) = 24 ساعة للاشتراكات المدفوعة، و48 ساعة للتجارب المجانية والعرض التعليمي ومستخدمي الخطة المجانية وغيرهم. وهو الزمن اللازم لاستعادة الخدمة في مركز بيانات آخر إذا وقعت كارثة وتوقف مركز بيانات بالكامل.
  • كيف يتحقق ذلك: نراقب نسخنا الاحتياطية اليومية بفاعلية، وهي مكرّرة في مواقع بعيدة متعددة. ولدينا تجهيز تلقائي لنشر خدماتنا في موقع استضافة جديد. ويمكن حينها استعادة البيانات من نسخ اليوم السابق خلال ساعات قليلة (لأكبر العناقيد)، مع إعطاء الأولوية للاشتراكات المدفوعة.
    ونحن نستخدم النسخ اليومية وسكربتات التجهيز معًا في عملياتنا اليومية، لذا يُختبَر جزآ إجراء التعافي من الكوارث باستمرار.

أمان قاعدة البيانات

• تُحفَظ بيانات العميل في قاعدة بيانات مخصصة — بلا مشاركة للبيانات بين العملاء.
• قواعد التحكم في الوصول إلى البيانات تحقّق عزلًا كاملًا بين قواعد بيانات العملاء العاملة على العنقود نفسه، فلا يمكن الوصول من قاعدة بيانات إلى أخرى.

أمان كلمات المرور

• كلمات مرور العملاء محمية بتشفير PBKDF2+SHA512 المعياري في الصناعة (بملح وتمديد لآلاف الجولات).
• لا يملك موظفو كود صلاحية الوصول إلى كلمة مرورك ولا يمكنهم استرجاعها لك، والخيار الوحيد عند فقدانها هو إعادة تعيينها.
• تُنقَل بيانات اعتماد الدخول دائمًا بأمان عبر HTTPS.
• بل يملك مسؤولو قاعدة بيانات العميل خيار تهيئة حد المعدل ومدة التهدئة لمحاولات الدخول المتكررة.
• سياسات كلمات المرور: لدى مسؤولي قاعدة البيانات إعداد مدمج لفرض حد أدنى لطول كلمة مرور المستخدم. أما سياسات كلمات المرور الأخرى مثل فئات المحارف المطلوبة فغير مدعومة افتراضيًا لأنه ثبت أنها عكسية النتيجة. انظر مثلًا [Shay et al. 2016]), وكذلك NIST SP 800-63b.

وصول الموظفين

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

أمان النظام

• كل خوادم كود Cloud تعمل بتوزيعات Linux محصّنة مع أحدث ترقيعات الأمان.
• عمليات التثبيت مخصصة للغرض وحدّية لتقليل عدد الخدمات التي قد تحوي ثغرات (بلا حزمة PHP/MySQL مثلًا).
• قلة من مهندسي كود الموثوقين لديهم تصريح بإدارة الخوادم عن بُعد، والوصول ممكن فقط بزوج مفاتيح SSH شخصي مشفّر، من حاسوب بتشفير كامل للقرص.

الأمن المادي

تُستضاف خوادم كود Cloud في مراكز بيانات موثوقة في مناطق مختلفة من العالم (مثل OVH وGoogle Cloud)، ويجب أن تتجاوز جميعها معايير الأمان المادي لدينا:

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

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

• نحن لا نخزّن معلومات بطاقات الائتمان في أنظمتنا أبدًا.
• تُنقَل معلومات بطاقتك الائتمانية دائمًا بأمان ومباشرةً بينك وبين ممتثل لمعيار PCI مزوّدو الدفع (انظر القائمة على سياسة الخصوصية صفحة).

تشفير البيانات

• كل اتصالات البيانات مع نسخ العملاء محمية بتشفير SSL بطول 256 بت (HTTPS).
• كل اتصالات البيانات الداخلية بين خوادمنا محمية أيضًا بتشفير من طرف إلى طرف
• خوادمنا تحت مراقبة أمنية صارمة، ومحدَّثة دائمًا ضد أحدث ثغرات SSL
• كل شهادات SSL لدينا تستخدم معاملًا بطول 2048 بت مع سلاسل شهادات SHA-2 كاملة — تصنيف A+
• كل بيانات العملاء (محتوى قاعدة البيانات والملفات المخزّنة) مشفّرة في حالة السكون، في الإنتاج وفي النسخ الاحتياطية، بخوارزمية AES-256

الدفاع الشبكي

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

أمان البرمجيات

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

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

آمن بحكم التصميم

صُمّم كود بطريقة تمنع أشيع الثغرات الأمنية:

• يُمنَع حقن SQL باستخدام واجهة برمجية عالية المستوى لا تتطلب كتابة استعلامات SQL يدويًا.
• تُمنَع هجمات XSS باستخدام نظام قوالب عالي المستوى يهرّب البيانات المحقونة تلقائيًا.
• يمنع الإطار الوصول عبر RPC إلى الدوال الخاصة، ما يصعّب إدخال ثغرات قابلة للاستغلال.

اطّلع أيضًا على أبرز ثغرات OWASP القسم لترى كيف صُمّم كود من الأساس لمنع ظهور مثل هذه الثغرات.

عمليات تدقيق أمني مستقلة

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

لكننا لا نستطيع الإفصاح عن أي من تلك النتائج، لأنها سرّية وتخصّ الجهات الطالبة. رجاءً لا تسأل ;-)

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

أبرز ثغرات OWASP

إليك موقف كود من أبرز مسائل الأمان في تطبيقات الويب، كما أوردها Open Web Application Security Project (OWASP):

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

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

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

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

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

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

• تنفيذ الملفات الضارة: الشيفرة المعرّضة لتضمين الملفات عن بُعد (RFI) تتيح للمهاجمين تضمين شيفرة وبيانات ضارة، ما يؤدي إلى هجمات مدمّرة قد تصل إلى اختراق الخادم بالكامل.

  لا يتيح كود دوالّ لتضمين الملفات عن بُعد. لكنه يسمح للمستخدمين ذوي الصلاحيات بتخصيص المزايا عبر إضافة تعبيرات يقوم النظام بتقييمها. وتُقيَّم هذه التعبيرات دائمًا في بيئة معزولة ومنقّاة لا تتيح سوى الوصول إلى الدوال المسموح بها.

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

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

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

  يستخدم كود التجزئة الآمنة وفق معايير الصناعة لكلمات مرور المستخدمين (افتراضيًا PBKDF2 + SHA-512 مع تمديد المفتاح) لحماية كلمات المرور المخزنة. كما يمكن استخدام أنظمة مصادقة خارجية مثل OAuth 2.0 أو LDAP لتفادي تخزين كلمات المرور محليًا أصلًا.

• الاتصالات غير الآمنة: كثيرًا ما تُخفق التطبيقات في تشفير حركة الشبكة عندما يكون ذلك ضروريًا لحماية الاتصالات الحساسة.

  تعمل كود Cloud عبر HTTPS افتراضيًا.

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

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

الإبلاغ عن الثغرات الأمنية

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