قائمة مراجعة Salesforce Security Review: كيف تستعد وتنجح

لا يُسمح بـ Managed 2GPs المنشأة من TRIAL Dev Hubs

لا يستطيع فريق Security Review مراجعة Managed 2GPs المنشأة من TRIAL Dev Hubs.

تأكد من أن managed 2GP لديك أُنشئت باستخدام Dev Hub داخل Partner Business Org (PBO) لديك.

بعد ذلك، تأكد من أنك طلبت تفعيل PBO حتى يمكن نقلها من حالة TRIAL إلى حالة ACTIVE.

يجب عليك تسجيل case واختيار "Partner Community & AppExchange" كمنتج، واختيار "Security Review"، ثم طلب التفعيل.

أدرج نتائج فحص تطبيق الويب للنطاقات الخارجية 

يجب أن يتضمن طلبك أي نتائج فحص لتطبيقات الويب الخاصة بالنطاقات الخارجية غير التابعة لـ Salesforce والمندمجة مع تطبيقك.

أضف أي endpoints غير تابعة لـ Salesforce في طلبك، سواء كبيئات composite و/أو في إعدادات remote site داخل Salesforce test org لديك. مثال https://testapi.net/

تعد نطاقات أو endpoints غير التابعة لـ Salesforce ضمن نطاق مراجعة الأمان إذا كانت مدمجة مع مكون Salesforce لديك بأي طريقة، مثل أن يجري تطبيقك callouts إليها، أو تخزن أي بيانات Salesforce، أو تُستخدم لأغراض أخرى مثل المصادقة.

قدم نتائج فحص من إحدى أدوات فحص تطبيقات الويب المعتمدة لأي مواقع ضمن نطاق المراجعة.

• تشمل أدوات الفحص المعتمدة OWASP ZAP أو Chimera أو Burp Suite.
• يجب تصحيح أي مشكلات عالية الخطورة يكتشفها OWASP ZAP أو Burp Suite.
• يجب أيضا تصحيح كل المشكلات المصنفة بغير “Informational/Other” في Chimera.
• قدم نتائج فحص نظيفة، أو أرفق النتائج بوثائق تشرح النتائج الإيجابية الكاذبة.
• بدلا من ذلك، إذا لم تُكتشف أي مشكلات، قدم لقطة شاشة للـ endpoint الذي تم فحصه.

قدم أي بيانات مصادقة ضرورية، مثل أسماء المستخدمين وكلمات المرور أو API keys، قد يحتاجها فريق Security Review لاختبار هذه التكاملات الخارجية.

Identity challenge مفعل: حل بديل

Identity challenge مفعل في مؤسستك. كحل بديل، ستحتاج إلى إدراج نطاقات IP الخاصة بـ Salesforce في safelist.

يمكنك إنشاء org جديدة مع إدراج عناوين IP في القائمة المسموحة وتعطيل multi-factor authentication (MFA) باتباع الخطوات في هذا الرابط.

أو اتبع الخطوات أدناه في مؤسستك الحالية:

• عطّل MFA بالخطوات التالية:
  1. سجّل الدخول إلى org وانتقل إلى قسم setup.
  2. ابحث عن “Session Settings” في شريط البحث أعلى اليسار.
  3. انتقل إلى session settings، ثم “Session Security Levels”.
  4. اختر Two-Factor Authentication من High Assurance واضغط remove.
  5. اضغط save في أسفل الصفحة.
• أدرج نطاقات IP الخاصة بـ Salesforce وكذلك النطاقات والعناوين التالية في safelist:
  • 13.108.0.0 - 13.111.255.255
  • 62.17.146.0 - 62.17.146.255
  • 85.222.134.0 - 85.222.134.255
  • 104.161.246.0 - 104.161.246.255
  • 182.71.125.154 - 182.71.125.155
  • 182.72.29.238 و136.232.119.246

فرض قواعد المشاركة في الكلاسات

افرض المشاركة في الكلاسات التي تصل إلى كائنات Salesforce القياسية أو المخصصة أو تعدلها.

لتجنب هذه الثغرة، ستحتاج إلى التصريح عن هذه الكلاسات باستخدام "with sharing".

ملاحظة: يتم فرض المشاركة أو عدم فرضها في الكلاس الذي ينفذ استعلامات DML. إذا استدعى كلاس "with sharing" كلاسا آخر "without sharing" ينفذ الاستعلامات، فسيتم استرداد أو تعديل الكائنات من دون فرض المشاركة.

يتم إعداد أمان الكائنات (CRUD) وأمان مستوى الحقل (FLS) على profiles وpermission sets، ويمكن استخدامهما لتقييد الوصول إلى الكائنات القياسية والمخصصة والحقول الفردية. يجب على مطوري Force.com تصميم تطبيقاتهم بحيث تفرض إعدادات CRUD وFLS الخاصة بالمؤسسة على الكائنات القياسية والمخصصة، وأن تتعامل بسلاسة مع الحالات التي يكون فيها وصول المستخدم مقيدا.

من حالات الاستخدام التي قد يكون فيها تجاوز CRUD/FLS مقبولا:

• إنشاء roll up summaries أو تجميعات لا تعرض البيانات مباشرة.
• تعديل كائنات أو حقول مخصصة مثل السجلات أو metadata النظام التي لا ينبغي أن تكون متاحة مباشرة للمستخدم عبر CRUD/FLS.
• حالات يكون فيها منح وصول مباشر إلى الكائن المخصص نموذجا أمنيا أقل أمانا.

تأكد من توثيق حالات الاستخدام هذه كجزء من طلبك.

معلومات حساسة في Debug

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

لا ينبغي تسجيل أي بيانات حساسة أو PII باستخدام طريقة system.debug.

ثغرة انتهاك المشاركة

تستخدم منصة Force.com قواعد مشاركة البيانات على نطاق واسع. يمكن أن يكون لكل كائن أذونات فريدة تحدد أي مستخدمين وprofiles يمكنهم القراءة والإنشاء والتعديل والحذف. تُفرض هذه القيود عند استخدام كل standard controllers. عند استخدام كلاس Apex مخصص، لا تُحترم أذونات profile المدمجة وقيود أمان مستوى الحقل أثناء التنفيذ. السلوك الافتراضي هو أن كلاس Apex لديه القدرة على قراءة وتحديث كل البيانات داخل المؤسسة. وبما أن هذه القواعد لا تُفرض، يجب على المطورين الذين يستخدمون Apex الحرص على عدم كشف بيانات حساسة بالخطأ، كانت ستظل عادة مخفية عن المستخدمين بسبب أذونات profiles أو أمان مستوى الحقل أو organization-wide defaults. وهذا مهم بشكل خاص لصفحات Visualforce. يجب أن تصرح الكلاسات صراحة بـ with sharing عندما يكون ذلك ممكنا.

إجراء مراجعة شاملة

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

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

ارجع إلى موارد الأمان. 

راجع موارد أمان Salesforce وإرشادات البرمجة الآمنة والأدوات والتدريب، وكذلك موارد ISV Security Review للاستعداد لعملية مراجعة أمان AppExchange.

بالإضافة إلى الاختبار اليدوي، شغّل فحوصات مؤتمتة باستخدام أدوات مثل Salesforce Code Analyzer وOWASP ZAP وCheckmarx.
Salesforce Code Analyzer - Overview & Guide
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner

موارد إضافية:

مزيد من المعلومات هنا إرشادات الأمان لتطوير Apex وVisualforce

للحصول على مواد تدريبية تفاعلية أكثر تفصيلا، راجع trailhead الجديد لـ ISV Security Review

يمكنك متابعة التنبيهات، والمشاركة في النقاشات، ونشر التعليقات والأسئلة في Security Review Collaboration Group ضمن Partner Community.

أنشئ قائمة تحقق مخصصة لطلبك. استخدم Security Review Submission Requirements Checklist Builder.

إذا قدمت إصدار package للمراجعة وفشل مع ملاحظات من فريق الأمان، فتأكد عند استعدادك لجدولة متابعة Security Review من مراعاة النقطتين المهمتين الآتيتين.

1.  إذا غيرت كودا يعمل على منصة Salesforce، فيجب عليك رفع إصدار جديد من managed package.
   • من Publishing Console، اضغط تبويب 'Listings'.
   • اضغط على listing الخاص بك.
   • اربط إصدار managed package الجديد الذي رفعته بالـ listing عبر الضغط على زر 'Select Package' الأخضر.
   • انتقل إلى تبويب 'Packages' واضغط رابط 'Start Review' بجوار حقل Security Review في أحدث إصدار لديك.
   • اتبع معالج security review وعملية التقديم العادية.
     
     
2.  إذا أصلحت فقط كودا يعمل خارج Salesforce، فعدّل معلومات طلب مراجعة الأمان الحالي:
   • من Publishing Console، اضغط تبويب 'Listings' إذا لم يكن لدى تطبيقك أي Salesforce package، وإلا فاضغط تبويب 'Packages'.
   • اضغط على listing في تبويب 'Listings'، أو إذا كنت في تبويب 'Packages' فمرر إلى أحدث إصدار package قدمته.
   • اضغط رابط "Edit Review"، إما في تبويب 'APP' الخاص بالـ listing أو بجوار إصدار package في تبويب 'Packages'. قد يظهر الرابط أيضا باسم "Submitted" بدلا من "Edit Review".
   • اتبع معالج security review وحدّث أي معلومات تغيرت.
   • يلزم تسجيل case واختيار "Partner Community & AppExchange" كمنتج و"Security Review" كموضوع لإبلاغ Security Review Operations Team بأنك تعيد تقديم منتجك للمراجعة. أدرج اسم package والمعرّف والإصدار، أو رابط listing، في وصف case.

يسعدنا مشاركة أي معلومات مفيدة ونوصيك بمعرفة المزيد عن تأثيرنا في دورة الإصدارات في Salesforce

احجز عرضا توضيحيا لمعرفة المزيد عن كيفية تمكين Serpent لاستراتيجية Salesforce DevOps لديك اليوم. Serpent من Tekunda يقدم أدوات قوية لمساعدة فرق DevOps لديك، بما في ذلك التحكم المدمج في الإصدارات، وأنظمة النشر المستمر والإصدارات، وأدوات الدمج، والعديد من أدوات الاختبار المختلفة.