بناء الأمان في الميزة أثناء مرحلة التصميم

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

بعد هذا التحول، شهدنا ميزات تُشحن بسرعة ووقت السوق للميزات الجديدة ينخفض بسرعة. كما أن DevOps كانت بمثابة الأساس للعديد من الممارسات الأخرى مثل MLOps وDataOps وGitOps، وبالتأكيد ظهرت العديد من الممارسات الأخرى.

اليوم سنتحدث عن واحدة من هذه الممارسات التي قد يكون العديد منكم على دراية بها، والتي تُدعى DevSecOps (عمليات أمان التطوير). فما هو DevSecOps؟

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

الآن، دعونا نناقش كيف يمكن تطبيقه في مراحل مختلفة من دورة حياة تطويرنا بحيث يكون الكود الذي نقوم بشحنه فعّالًا وآمنًا.

عادةً، ينطوي عملية شحن ميزة على الخطوات التالية:

  1. التطوير – حيث تتم بناء الميزة
  2. التوزيع – حيث يتم إنشاء القطع الفنية وتحضيرها للتسليم
  3. النشر – حيث يتم إطلاق الميزة في بيئة الإنتاج

لنناقش الخطوات التي يمكن اتخاذها لتعزيز موقف الأمان للميزة التي نقوم ببنائها خلال مرحلة التطوير.

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

قم بإجراء نمذجة التهديد

ببساطةقل، نمذجة التهديدات هي “عملية تحديد الثغرات، وأداء تقييم المخاطر وتنفيذ التخفيفات الموصى بها بحيث لا تتعرض وضعية أمان المنتجات/المنظمات للخطر”.”

دعونا نأخذ مثالاً لفهم ذلك. تخيل أنك تقوم بتطوير واجهة برمجة التطبيقات (API) التي:

  • تدرج المنتجات في كتالوج المنتجات الخاص بك.
  • تبحث عن منتج أو نوع منتج.
HTTP

 

يمكن أن تبدو نمذجة التهديدات مثل هذا:

functionality vulnerability risk assessment recommended mitigation
يمكن للمستخدمين غير المعتمدين البحث عن المنتجات يمكن للمهاجمين تنفيذ هجمات DDoS (رفض الخدمة الموزعة)، مما يؤدي إلى إغراق قاعدة البيانات وبنية واجهة برمجة التطبيقات عالي – يمكن أن يؤدي إلى توقف الخدمة وتقليل التوفر استخدم بوابة API أو محدد معدل لمنع هجمات DDoS.
يدخل المستخدم سلسلة استعلام في حقل البحث يمكن أن ينفذ هجوم حقن SQL مثل إدراج “1=1” عالي – يمكن أن يحذف المهاجم جدول الإنتاج تأكد من إجراء التحقق/التعقيم المناسب على المدخلات.
يتلقى المستخدم تفاصيل المنتج كشف الحقول الداخلية مثل معرفات قواعد البيانات، رموز الحالة، و أرقام الإصدار يمكن أن يمنح المهاجمين معلومات حرجة حول هيكل قاعدة البيانات أو النظام الأساسي. متوسطة – يمكن للمهاجم استخدام هذه التنفيذات الداخلية لتنفيذ هجمات مثل جمع المعلومات قم بإرسال التفاصيل المطلوبة فقط للمستخدم.

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

يمكن أن تساعد الأدوات مثل أدوات تهديدات Microsoft و OWASP Threat Dragons في تحديدها.

مثال على نموذج تهديد في أداة نمذجة التهديدات من Microsoft

عرض التحليل


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

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

  • استخدامات تشفير ضعيفة. على سبيل المثال، يُعتبر استخدام SHA1 أو MD5 ضعيفًا.CA530 هو مثال على تحذير ينشئه C# عند استخدام أي دوال تشفير ضعيفة في الشيفرة.
  • هجمات حقن SQL. CA2100 هو مثال على فحص إذا كانت الشيفرة عرضة لأي هجمات حقن
  • كلمات مرور محفوظة بشكل ثابت، وآليات مصادقة وترخيص ضعيفة، و يمكن أيضًا اكتشاف تهيئات البنية التحتية بشكل خاطئ باستخدام تحليلات ثابتة.

هناك أدوات قائمة في هذا المجال أيضًا. SonarQube، CodeQL، Roslyn Analyzer، OWASP Dependency Check، و Snyk تقدم بعض العروض الرائعة في هذا المجال.

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

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

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

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

الاستنتاج

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

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

Source:
https://dzone.com/articles/building-security-into-design-phase