خدمة
هندسة أمان التطبيقات
قرار في البناء، لا مرحلة تسبق الإطلاق.
لفرق تريد أن يكون الأمان خاصية في البرمجية لا تقريراً عنها. نعمل على الأجزاء التي يكلف تداركها لاحقاً — التفويض وإدارة الجلسات وإدارة الأسرار ومخاطر الاعتماديات — ونثبتها باختبارات تحاول كسر النظام.
القرار
متى يكون هذا هو القرار الصحيح.
الأمان الذي يصل كفحص قبل أسبوعين من الإطلاق يلتقط الأمور الرخيصة ويفوّت الباهظة. الترويسات المفقودة والمكتبات القديمة حقيقية لكنها سطحية. أما التحكم المعطوب في الصلاحيات — أن يصل مستخدم إلى سجل مستأجر آخر بتغيير معرّف — فهو أكثر الثغرات الخطيرة شيوعاً في برمجيات الأعمال، ولا يلتقطه أي ماسح بموثوقية لأنه يبدو تماماً كطلب مشروع.
هذا الصنف من الثغرات مشكلة في البنية. فإذا كان التفويض يُفرَض بإخفاء عناصر القائمة، أو بفحص تتذكر بعض المسارات استدعاءه، فالسؤال ليس هل توجد ثغرة بل أين هي. وإدخال نموذج متسق في تطبيق مكتمل من أكثر التغييرات كلفة على الإطلاق.
لذلك نجعله قراراً في البناء: كل طلب مفوَّض على الخادم في مواجهة المستخدم الفاعل، واختبارات تطلب عمداً بيانات مستأجر آخر وتتحقق من الرفض، وأسرار لم تدخل المستودع أصلاً.
ما الذي تحصل عليه
ما الذي يشمله العمل.
التفويض افتراضياً
كل نقطة نهاية مفوَّضة على الخادم في مواجهة المستخدم الفاعل، والرفض هو الافتراض لا الاستثناء.
اختبارات تهاجم النظام
اختبارات آلية تطلب سجلات مستأجر آخر وترفع الصلاحيات وتعيد إرسال رموز منتهية، وتتحقق من رفض كلٍّ منها. تُشغَّل عند كل عملية دفع للشيفرة.
إدارة الجلسات والرموز
انتهاء الصلاحية والتجديد والإبطال مصممة كما ينبغي، حتى تنتهي الجلسة المنتهية بشكل نظيف بدل التكرار إلى ما لا نهاية.
إدارة الأسرار
بيانات الاعتماد خارج المستودع وخارج ملفات الإعداد، قابلة للتدوير دون إعادة نشر، مع إجراء تدوير موثّق.
الاعتماديات وسلسلة التوريد
مراجعة آلية للاعتماديات مع سياسة تحدد ما يوقف الإصدار، إضافةً إلى ملفات قفل وبناءات قابلة للتكرار.
النقل والترويسات
إعدادات TLS وHSTS وCSP وما يليها تُضبط عند الأصل وتُتحقق، بما في ذلك إعدادات مستوى البروتوكول التي تعطّل العملاء بصمت.
التقنيات
بماذا نبنيه.
تُختار لكل مشروع. لا شيء هنا يُفرَض افتراضياً، والفريق الذي سيصونها يزن بقدر المشكلة نفسها.
مراجعة
نمذجة التهديدات على البيانات والأدوار، قبل أن يثبت التصميم.
الاختبار
اختبارات تفويض في التكامل المستمر، وفحص للاعتماديات عند كل بناء، ومراجعة يدوية دورية للمسارات المهمة.
البنية التحتية
حسابات خدمة بأقل الصلاحيات، وحدود للشبكة، ونسخ احتياطية جُرِّبت استعادتها فعلاً.
المراقبة
تنبيهات على إخفاقات المصادقة وحالات رفض التفويض ومعدلات الأخطاء، لأن مجرد المحاولة إشارة تستحق الانتباه.
الاستجابة
إجراء مكتوب لليوم الذي يسوء فيه شيء، مُتفق عليه قبل أن يحدث.
مقارنة
فحص قبل الإطلاق مقابل اعتبار الأمان قراراً في البناء.
الماسحات تستحق التشغيل وتلتقط أشياء حقيقية. لكنها لا تلتقط نوع الثغرة الذي يكلف الأعمال فعلاً.
| الجانب | فحص قبل الإطلاق | مدمج من البداية |
|---|---|---|
| تحكم معطوب في الصلاحيات | تفوت في الغالب — طلب سجل مستأجر آخر يبدو مطابقاً تماماً لطلب مشروع | اختبارات تطلب عمداً بيانات مستأجر آخر وتتحقق من الرفض، في كل عملية دفع للشيفرة |
| اعتماديات قديمة | تُكتشف، وهذا مفيد فعلاً | تُكتشف أبكر، ومعها سياسة تحدد ما الذي يوقف الإصدار |
| ترويسات مفقودة وإعدادات TLS | يُكتشف | تُضبط عند الأصل وتُتحقق، بما في ذلك إعدادات مستوى البروتوكول التي تعطّل العملاء بصمت |
| أسرار داخل المستودع | تُكتشف بعد أن تكون قد دخلت سجل المستودع | لا تُرفَع إلى المستودع أصلاً، ويمكن تغييرها دون إعادة نشر |
| متى تظهر المشكلات | قبل أسبوعين من الإطلاق، حين تكون البنية قد ثبتت | بينما لا يزال تغيير التصميم رخيصاً |
| تكلفة الإصلاح | إعادة بناء نموذج الصلاحيات بعد الإطلاق تكلف أسابيع مع ترحيل للبيانات | أيام في البداية، ثم لا شيء تقريباً |
كيف يسير الأمر
من أول حديث حتى الإطلاق.
إرشادي لعمل بهذا الشكل. التجربة الأولية ليست اختيارية — ولا يُنقل شيء قبل أن يقول مستخدموه إنه يصمد.
- 3-5 أيام
نمذجة التهديدات
البيانات والأدوار وما الذي قد يسعى إليه المهاجم فعلاً — قبل أن يثبت التصميم.
- 2-3 أسابيع
الأسس
تفويض على الخادم عند كل نقطة نهاية، وإدارة للجلسات والرموز، وأسرار خارج المستودع مع إجراء تدوير موثّق.
- 1-2 أسبوع
اختبارات تحاكي المهاجم
اختبارات آلية تتجاوز حدود المستأجرين وترفع الصلاحيات وتعيد إرسال رموز منتهية، موصولة بالتكامل المستمر حتى يفشل البناء عند أي تراجع.
- بشكل دائم
مستمر
سياسة للاعتماديات، وتنبيهات عند رفض التفويض، وإجراء استجابة مكتوب ومتفق عليه قبل الحاجة إليه.
بعد الإطلاق
ما الذي يتغير.
- أكثر الثغرات الخطيرة شيوعاً في برمجيات الأعمال تغطيها اختبارات لا آمال.
- تنتهي الجلسة المنتهية بشكل نظيف بدل تكرار طلب ميت حتى ينهار شيء ما.
- التسريب يتحول إلى تدوير لبيانات الاعتماد، لا إلى إعادة نشر وحادثة أمنية.
- يعود اختبار الاختراق بنتائج قليلة، لأن الثغرات المكلفة أُزيلت من التصميم أصلاً.
وُصفت نوعياً عن قصد. نحن لا ننشر نسب تحسّن لا نستطيع نسبتها إلى عميل بعينه وبموافقته.
أسئلة
أسئلة شائعة.
هل هذا اختبار اختراق؟
لا. اختبار الاختراق تقييم في لحظة زمنية تجريه جهة مستقلة، وينبغي أن تكلّف به جهة منفصلة — ويمكننا مساعدتك في تحديد نطاقه. أما هذا فهو الهندسة التي تجعل ذلك الاختبار يعود بنتائج قليلة، وهي تستمر بعد حفظ التقرير.
لدينا ماسح أمني بالفعل. أليس ذلك كافياً؟
الماسحات تستحق التشغيل وتلتقط أشياء حقيقية، لكنها تلتقط في الغالب اعتماديات معروفة الثغرات وترويسات مفقودة. أما التحكم المعطوب في الصلاحيات — أكثر الثغرات الخطيرة شيوعاً في برمجيات الأعمال — فيبدو كطلب مشروع ويحتاج اختبارات مكتوبة على نموذج صلاحياتك أنت.
هل يمكنكم مراجعة تطبيق لدينا بالفعل؟
نعم. مراجعة قاعدة شيفرة قائمة تستغرق عادةً أسبوعاً إلى أسبوعين وتنتج قائمة مرتبة بالأولوية مع التعليل، لا تصديراً خاماً من ماسح. ويمكننا تنفيذ الإصلاحات أو تسليمها لفريقك.
هل يبطئ هذا وتيرة العمل؟
قليلاً في البداية، وأقل بكثير من إضافته لاحقاً. اختبارات التفويض وسياسة الاعتماديات تضيف أياماً في البداية؛ أما إعادة بناء نموذج الصلاحيات بعد الإطلاق فتكلف أسابيع وترحيلاً للبيانات.
فريقنا صغير. أليس هذا أكثر مما نحتاج؟
عمل التفويض كذلك، لأنه رخيص في البداية وباهظ لاحقاً، وهو الثغرة الأرجح لكشف بيانات عميل لعميل آخر. أما نمذجة التهديدات الكاملة والمراقبة المستمرة فيمكن أن تنتظر حتى يوجد ما يستحق المراقبة.
هل تتولون شهادات الامتثال؟
ننفّذ الهندسة التي تجعل التدقيق سهلاً — التحكم في الصلاحيات وسجلات التدقيق والتشفير ومدد الاحتفاظ والإجراءات الموثّقة — لكننا لسنا مدققين ولا نصدر شهادات. وحيث ينطبق إطار بعينه، أشرك المدقق مبكراً وسنبني وفق ما يطلبه فعلاً.