مشاركة عبر

توصيات لتأمين دورة حياة تطوير

ينطبق على توصية قائمة مراجعة Power Platform Well-Architected Security:

SE:02 الحفاظ على دورة حياة تطوير آمنة باستخدام بيئة تزويد البرامج التي تم تصلبها، والأتمتة في الغالب، القابلة للتدقيق. ادمج تصميم آمن باستخدام نمذجة التهديدات للحماية من التطبيقات التي تؤدي إلى هزيمة الأمان.

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

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

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

التعريفات

المصطلح تعريف
دورة حياة تطوير الأمان مجموعة من الممارسات التي توفرها Microsoft والتي تدعم متطلبات ضمان الأمان والامتثال.
دورة حياة تطوير البرمجيات (SDLC) عملية نظامية ومتعددة لتطوير أنظمة البرامج.

استراتيجيات التصميم الأساسية

ينبغي دمج إجراءات الأمان عند نقاط متعددة في دورة حياة تطوير البرامج (SDLC) الموجودة لضمان:

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

توفر الأقسام التالية استراتيجيات أمان لمراحل SDLC الشائعة.

مرحلة المتطلبات

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

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

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

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

مرحلة التصميم

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

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

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

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

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

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

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

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

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

  • تجنب الترميز الثابت. تجنب الترميز الصعب عناوين URL والمفاتيح. على سبيل المثال، تجنب الترميز الثابت في إجراء Power Automate HTTP عنوان URL أو مفتاح خدمة الخلفية. وبدلا من ذلك، استخدم موصلا مخصصا أو استخدم متغير البيئة وعنوان URL، ومخزن Azure الأساسي لمفتاح API.

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

‏‫ملاحظة

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

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

لمزيد من المعلومات، راجع توصيات بشأن تحليل التهديدات.

مرحلة التطوير الاختباري

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

أن يكون مدربا جيدا على ممارسات التعليمات البرمجية الآمنة

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

يجب أن يطلب من المطورين إكمال هذا التدريب قبل بدء العمل على أعباء Power Platform العمل.

إجراء مراجعات داخلية للتعليمات البرمجية للند لتعزيز التعليم المتواصل.

استخدام أدوات تحليل التعليمات البرمجية

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

إجراء اختبار الزغب

استخدم البيانات التي تم شكلها بشكل غير متوقع وغير متوقع للتحقق من الثغرات الأمنية والتحقق من معالجة الأخطاء، التي تكون مهمة بشكل خاص مع الحلول التي تتضمن. Power Pages

اكتب رمزًا كافيًا فقط

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

حماية بيئات المطورين

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

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

عمليات نشر التعليمات البرمجية الآمنة

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

الاحتفاظ بمخزون م تحديثي لكل مكون مدمج في التطبيق الخاص بك

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

من المستحسن استخدام خطوط الغاز من Power Platform أجل عمليات النشر الخاصة بك. توسيع التدفقات باستخدام GitHub Actions. إذا كنت تستخدم مهام سير عمل GitHub، ففضل المهام التي تعمل ب تأليف Microsoft. بالإضافة إلى ذلك، تحقق من المهام لأنها تعمل في سياق أمان خطوط المبيعات الأساسية الخاصة بك.

استكشف استخدام أساسيات الخدمة للنشر.

مرحلة الإنتاج

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

الاحتفاظ بالإصدارات اليدوية

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

الإصلاحات غير المثبت بها

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

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

‏‫ملاحظة

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

الحفاظ على البيئات المختلفة منفصلة

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

استخدام الكشف عن المعلومات

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

صيانة التطبيق

الهدف من هذه المرحلة هو التأكد من عدم تجاوز الأمان مع مرور الوقت. SDLC هي عملية سرعة مستمرة. يتم تطبيق المفاهيم التي تم تناولها في المراحل السابقة على هذه المرحلة بسبب تغير المتطلبات بمرور الوقت.

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

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

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

ولتحسين ممارسات الترميز الآمنة باستمرار لمواكبة بيئة التهديدات.

SDL في Microsoft Power Platform

تم بناء Power Platform بالاستناد إلى ثقافة ومنهجية التصميم الآمن. يتم تعزيز الثقافة والمنهجية بشكل مستمر من خلال الممارسات الرائدة في المجال من Microsoft من ناحية دورة حياة تطوير الأمان ‏(SDL) ونمذجة التهديدات.

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

تأخذ أيضًا نمذجة التهديدات في الاعتبار جميع التغييرات التي تطرأ على الخدمات الموجودة بالفعل من خلال المراجعات المنتظمة المستمرة. كما أن الاعتماد على نموذج STRIDE يساعد على معالجة المشاكل الأكثر شيوعًا في التصميم غير الآمن.

دورة حياة تطوير الأمان (SDL) من Microsoft تعادل نموذج نضج ضمان برنامج OWASP ‏(SAMM). وقد تم بناء كليهما على الموقع حيث يتكامل التصميم الآمن مع أمان تطبيق الويب. لمزيد من المعلومات، راجع OWASP أهم 10 مخاطر:نا نواة في Power Platform.

تبسيط Power Platform

توصى دورة حياة تطوير أمان Microsoft (SDL) با والممارسات الآمنة التي يمكنك تطبيقها على دورة حياة التطوير الخاصة بك. لمزيد من المعلومات، راجع دورة حياة تطوير أمان Microsoft.

تم تضمين أدوات تم تضمينها ل DevOps وأدوات SAST (اختبار أمان التطبيق الثابت) كجزء من أمان GitHub Advanced و Azure DevOps. ومن الممكن أن تساعدك هذه الأدوات في تعقب نتيجة أمان لمنظمتك.

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

قائمة مراجعة الأمان

راجع مجموعة التوصيات الكاملة.

قائمة مراجعة الأمان

  • Last updated on