إزاي تحافظ على أمان org في Salesforce وفريقك بيكبر

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

إيه اللي بيضعّف أمان Salesforce فعلًا مع نمو الفريق؟

آليتين، ومفيش واحدة فيهم شكلها اختراق يوم ما بتحصل.

• تضخّم الصلاحيات. الوصول بيتمنح كسلسلة استثناءات. حد محتاج تقرير يوم الجمعة، بياخد permission set، ويفضل معاه ثلاث سنين. اضرب ده في كل تعيين وكل مشروع وكل شخص مشي وما اتسحبش منه الوصول.
• مستخدمو تكامل بصلاحيات زايدة. الوسيط محتاج يكتب على كائنين، فبياخد ملف System Administrator، لأن ده أسرع طريق تخلّي المزامنة تشتغل.

الاتنين تراكميين بطبيعتهم. مفيش حاجة في المنصة بتسحب الوصول من نفسها. الاختلال ده، سهل تمنحه ومحدش مسؤول عن سحبه، هو كل قصة إزاي org مصممة كويس بتتحوّل لمشكلة تدقيق خلال سنتين.

ليه بيحصل تضخّم الصلاحيات حتى في الفرق المنضبطة؟

لأن الطريق السريع والطريق الصح بيوديوا لاتجاهين مختلفين:

• النسخ أسهل من النمذجة. نسخ ملف تعريف بياخد دقيقة، وبناء permission set group صح بياخد بعد ضهر كامل، فالـ orgs بتنتهي بعشرات الملفات شبه المتطابقة اللي محدش بيجرؤ يدمجها.
• الوصول المؤقت من غير تاريخ انتهاء. ‏Salesforce مش هيسحبه بدالك، ومفيش تذكرة بتفكّر حد بيه.
• محدش مسؤول عن السحب. المنح ليه طالب، والسحب ملهوش حد، وعلشان كده مراجعات الوصول بتتجدول وبعدين بتتخطى بهدوء.
• الصلاحيات الحساسة بتختبي في المجموع. اتنين permission set بريئين ممكن يتجمّعوا على قدرة ما كانش أي واحد فيهم قاصدها.

أي نموذج صلاحيات بينجو من نمو الفريق؟

النموذج اللي بيتوسّع ممل وموثّق كويس. المهم إنك تلتزم بيه قبل ما توصل لـ 200 مستخدم، مش بعدها.

1. ملف تعريف أساسي بالحد الأدنى. ادّي الملف بس اللي كل مستخدم بنفس نوع الرخصة محتاجه. مفيش وصول لكائنات بيخص وظيفة معينة.
2. ‏Permission sets للقدرات مش للأشخاص. الـ permission set بيوصف مهمة، فاسمه لازم يعيش بعد الشخص اللي احتاجه أول مرة.
3. ‏Permission set groups للأدوار، مع الكتم لما المجموعة تدّي زيادة بسيطة. دي الآلية اللي بتخليك تركّب دورًا من غير ما تنسخ ملف تعريف جديد.
4. أتمِت الإسناد بـ User Access Policies علشان الداخلين والمنتقلين ياخدوا وصولهم بمعايير مش بالذاكرة.
5. خلّي الصلاحيات الخطرة على قائمة مسمّاة. ‏Modify All Data و View All Data و API Enabled والتصدير و Manage Users كلها تستاهل مالكًا ومبررًا مكتوبًا لكل حامل. لو القائمة دي أطول من فريق قيادتك، تبقى لقيت أول مشروع ليك.

شرح أقل امتياز من Salesforce Ben رفيق كويس لو عايز التفاصيل خطوة بخطوة. أما قرار التصميم اللي فوق فلازم ييجي منك إنت.

ليه مستخدمو التكامل أكبر نقطة عمياء؟

لأنهم غير مرئيين في أي نقاش عن الأمان. ما بيدخلوش تهيئة، وما بيسيبوش الشركة أبدًا، ومحدش بيراجعهم لما مشروع يخلص. وفي نفس الوقت غالبًا بيمسكوا وصولًا للبيانات أوسع من أي إنسان في الـ org وبيتوثّقوا من غير أي مطالبة MFA.

أربع قواعد بتصمد مع زيادة عدد التكاملات:

• مستخدم تكامل واحد لكل تكامل. المستخدمون المشتركون بيخلوا من المستحيل تعرف مين كتب سجلًا، ومن المستحيل تسحب صلاحية نظام من غير ما تكسر التاني.
• استخدم رخصة التكامل عبر الـ API فقط قدر الإمكان. ‏Salesforce بتوفّر خمس رخص Salesforce Integration مجانية في إصدارات Enterprise و Unlimited و Performance، بلا أي وصول للواجهة، وده بيشيل فئة كاملة من سوء الاستخدام.
• حدّد النطاق بالكائنات والحقول مش بملفات التعريف. اكتب إيه اللي مسموح للتكامل يلمسه، وافرضه بـ permission set متعمول للتكامل ده لوحده.
• قيّد بالـ IP وراقب الحجم. سلوك مستخدم التكامل متوقّع، يعني أي شذوذ فيه دلالته أقوى بكتير من شذوذ النشاط البشري.

أي ضوابط بتصمد فعلًا مع التوسّع؟

دي الضوابط اللي بتفضل شغالة لما الفريق يتضاعف، مرتبة بحسب العائد على الجهد:

1. انشر الصلاحيات عبر خط الأنابيب مش بإيدك في الإنتاج. لما تغييرات الوصول تبقى في التحكم بالإصدارات، كل منح بيبقى ليه صاحب ومراجعة وتاريخ. الضابط ده لوحده بيخلّي الأربعة اللي بعده ممكنين.
2. اعمل مراجعة وصول دورية بمالك مسمّى وأجندة ثابتة: قائمة الصلاحيات الخطرة، ومستخدمو التكامل، وأي حد اتغيّر دوره الربع اللي فات.
3. حدّد عرفًا لانتهاء الوصول الاستثنائي، حتى لو هتفرضه بتذكير في التقويم. الوصول من غير تاريخ نهاية وصول دائم.
4. تابع Health Check و Setup Audit Trail كاتجاه، مش كصورة شاشة قبل التدقيق.
5. ضم الصلاحيات لمراجعة الكود. فرق ملف تعريف أو permission set يستاهل نفس التدقيق زي Apex، لأنه ممكن يعمل ضرر أكبر وأسرع.

تعرف إزاي إن الكلام ده شغال؟

اختار مؤشرات المفروض تنزل. عُدّ حاملي كل صلاحية خطرة. عُدّ الصلاحيات الممنوحة خارج permission set group. عُدّ مستخدمي التكامل اللي عندهم وصول للواجهة. عُدّ ملفات التعريف. لو الأربع أرقام دي مش بتنزل ربعًا بعد ربع، يبقى وضعك الأمني بينحرف حتى لو ما حصلش مشكلة لحد دلوقتي.

FAQ

هل ملفات التعريف اتلغت في Salesforce؟

لأ، وما زلت محتاج واحد لكل مستخدم. التوجيه العملي إنك تخلي ملفات التعريف بالحد الأدنى وتعبّر عن كل اللي خاص بالدور عبر permission sets و permission set groups.

كل قد إيه تتراجع الصلاحيات؟

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

هل مستخدمو التكامل محتاجين MFA؟

مستخدمو التكامل عبر الـ API بيتوثّقوا من نظام لنظام، فالضوابط المفيدة هي تقييد الـ IP وصلاحيات ضيقة ومراقبة، مش مطالبة MFA مش هيشوفها إنسان.

هل دي مشكلة أدوات أمان؟

الأدوات بتساعدك تشوف التضخّم، لكنها مش بتقرر مين المفروض يبقى عنده وصول. القرارات معمارية، وعلشان كده الحل مكانه في عملية التسليم عندك مش في عملية شراء.

إحنا بنبني على Salesforce كشريك SI و ISV و PDO معتمد، وعدّينا حزم من مراجعة أمان AppExchange في الرعاية الصحية واللوجستيات والتصنيع، يعني نموذج الصلاحيات حاجة بنصمّمها مش بنرثها. لو الـ org بتاعتك كبرت أسرع من نموذج الوصول بتاعها، اتكلم معانا.