كيف نبني برمجيات آمنة لعملائنا

نبدأ بمراجعة التهديدات

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

ممارسات البرمجة الآمنة

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

المصادقة وضبط الوصول

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

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

التحقق من المدخلات

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

الأسرار والإعدادات

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

فحص الاعتمادات والسحابة

المنتجات الحديثة في معظمها شيفرة كتبها غيرنا. نفحص الاعتمادات بحثًا عن الثغرات المعروفة، ونثبّت الإصدارات بملفات القفل، ونحدّث بانتظام وليس بعد الحوادث فقط. أما حساب السحابة (AWS أو Azure أو Google Cloud أو Vercel أو Cloudflare) فنراجع إعداداته بحثًا عن الأخطاء الشائعة: تخزين عام، وأدوار واسعة أكثر من اللازم، وسجلات غائبة، وواجهات إدارة مكشوفة.

مراجعة الشيفرة

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

الاختبار قبل كل إصدار

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

المراجعة الأمنية قبل الإطلاق

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

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

ما نطلبه منك

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

إذا اكتُشفت ثغرة في منتجك

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

سياسة الإفصاح الخاصة بنا

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

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