كيف تجهّز الـ org في Salesforce لتدقيق خارجي

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

ما الذي يطلبه المدقق فعلياً من فريق Salesforce؟

معظم النصائح حول تدقيق Salesforce تتحدث عن فحص صحة داخلي: حقول ميتة وتقارير غير مستخدمة وتنظيف المساحة. عمل تنظيمي مفيد، لكنه ليس ما يختبره المدقق الخارجي. تحت SOX أو SOC 2 أو ISO 27001، يأخذ عينة ويطلب منك إثبات ضابط:

• دليل الصلاحيات. قائمة مستخدمين بالـ profiles والـ permission sets والأدوار، ومن اعتمد كل صلاحية ومتى روجعت آخر مرة.
• دليل التغيير. لعيّنة من تغييرات الإنتاج: الطلب والاعتماد ونتيجة الاختبار وسجل النشر.
• دليل الاحتفاظ والحذف. أي بيانات شخصية لديك، وكم تحتفظ بها، وإثبات أن طلبات الحذف نُفّذت.

تقريباً كل ملاحظة نراها تأتي من واحدة من هذه الثلاث، لا من page layout غير مرتب.

ما الذي يقع داخل النطاق، ومن يحدده؟

أنت تحدده أولاً ثم تدافع عنه. النطاق يتبع المخاطر لا الهيكل التنظيمي:

• التقارير المالية (SOX): عروض الأسعار والطلبات والفوترة وكائنات الإيراد وأي أتمتة تستطيع تغيير هذه القيم، بما فيها مستخدمو التكامل.
• البيانات الشخصية (GDPR وما يشبهه): Contact و Lead و Case و Person Account ونصوص المحادثات وكل نسخة sandbox.
• الصلاحيات المرتفعة: Modify All Data و View All Data و Manage Users و Author Apex، وكل من يستطيع النشر.

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

كيف تنتج دليل الصلاحيات بدون لقطات شاشة؟

لقطات الشاشة تتقادم بسرعة ولا تقول شيئاً عن الـ 51 أسبوعاً الباقية من السنة. صدّر البيانات بدلاً منها، وفق جدول:

1. استعلم عن كائنات الصلاحيات. PermissionSetAssignment و ObjectPermissions و FieldPermissions تعطيك الصورة الحقيقية، بما في ذلك ما يأتي عبر permission set groups.
2. صدّر Login History. يحتفظ Salesforce بستة أشهر متاحة ويتيح تنزيلها كملف CSV. الحسابات الخاملة بصلاحيات فعّالة هي الملاحظة الكلاسيكية.
3. شغّل Security Health Check و Optimizer واحتفظ بالمخرجات. المدققون يقبلون تقييماً ذاتياً مؤرخاً كدليل على وجود مراقبة.
4. راجع كل ربع سنة، بمعتمد محدد بالاسم. مراجعة صلاحيات لم يوقّعها أحد ليست ضابطاً. سجّل المراجع والتاريخ والاستثناءات.

مستخدمو التكامل يستحقون سطراً خاصاً. عادةً يحملون أوسع الصلاحيات وأقل قدر من التدقيق، والمدققون تعلّموا أن ينظروا هناك أولاً.

كيف تنتج دليل التغيير؟

هنا تؤلم الـ change sets. لا تفصل من يبني عن من ينشر ولا تترك اعتماداً مرتبطاً. الـ pipeline يجيب بروابط: بند العمل وسببه التجاري، والـ commit الذي يُظهر بدقة أي بيانات وصفية تحركت، والـ pull request بمراجع غير الكاتب، ونتيجة الاختبار، وسجل النشر.

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

التاريخ الأصلي في المنصة يساعد لكنه لا يحمل كل شيء. الـ Setup Audit Trail يحتفظ بـ 180 يوماً ويمكن الاستعلام عنه عبر كائن SetupAuditTrail قبل تنظيفه. و Field History Tracking يحتفظ بنحو 18 شهراً في الواجهة و24 عبر الـ API، إلا إذا اشتركت في Field Audit Trail مع Salesforce Shield وضبطت سياسة احتفاظ. دورات التدقيق سنوية، فاحتفظ بنسختك في Git ومنصة الـ DevOps.

كيف تثبت الاحتفاظ والحذف؟

الاحتفاظ هو السؤال الأسوأ إجابةً، لأن لا أحد يملكه. ثلاثة مستندات تحسمه:

• خريطة بيانات: أي كائنات وحقول تحمل بيانات شخصية، والأساس القانوني لكل منها.
• جدول احتفاظ لكل كائن، مع تسمية آلية الحذف (مهمة مجدولة، أرشفة، حذف نهائي).
• سجل حذف يُظهر أن طلبات المحو نُفّذت، بما في ذلك داخل الـ sandbox والنسخ الاحتياطية.

سطر الـ sandbox هو ما يفاجئ الفرق عادةً. الـ full sandbox المحدّثة من الإنتاج هي نسخة من البيانات الشخصية نفسها في بيئة أقل ضبطاً. ازرع مجموعة جزئية وأخفِ الحقول الشخصية ضمن مهمة التحديث، حتى يوثّق الضابط نفسه.

كيف تستعد في أسبوعين بدل شهرين؟

1. اليوم 1-2: اكتب مذكرة النطاق وحدد مالكاً لكل حزمة أدلة.
2. اليوم 3-5: صدّر بيانات الصلاحيات، وشغّل Health Check، واحصر كل مستخدم تكامل وكل profile مرتفع الصلاحية.
3. اليوم 6-8: اختر عشرة تغييرات إنتاج حديثة عشوائياً وتتبّع كلاً منها من البداية للنهاية. ما لا تستطيع تتبعه هو ملاحظتك الحقيقية.
4. اليوم 9-10: اكتب جدول الاحتفاظ وراجع التعامل مع بيانات الـ sandbox.
5. ثم أتمت ما فعلته يدوياً للتو، حتى تصبح السنة القادمة عملية تصدير لا مشروعاً.

الخطوة الأخيرة هي اللعبة كلها. الفرق التي تمر بسلام ليست صاحبة أنظف org، بل صاحبة ضوابط تعمل وحدها وتترك أثراً. Tekunda تبني Salesforce بهذه الطريقة كشريك SI و ISV و PDO معتمد، وقد مرّرنا حزماً مُدارة عبر مراجعة أمان AppExchange في الرعاية الصحية والخدمات اللوجستية والتصنيع، حيث يضع طرف آخر مستوى الإثبات المطلوب.

FAQ

كم يحتفظ Salesforce بتاريخ تغييرات الإعداد؟

الـ Setup Audit Trail يحتفظ بـ 180 يوماً ثم ينظّفها. صدّرها وفق جدول أو احتفظ بالسجل نفسه في منصة الـ DevOps لديك.

هل نحتاج Salesforce Shield لاجتياز التدقيق؟

ليس بالضرورة. Shield يمدد الاحتفاظ بتاريخ الحقول ويضيف Event Monitoring، لكن الضوابط وأدلتها أهم من الترخيص.

كم مرة نراجع الصلاحيات؟

كل ربع سنة للصلاحيات المرتفعة ومستخدمي التكامل، وسنوياً على الأقل لبقية المستخدمين، مع معتمد محدد بالاسم في كل مرة.

هل الـ full sandbox ببيانات الإنتاج مشكلة؟

قد تكون. عاملها كعملية معالجة: ازرع مجموعة جزئية بدل النسخ الكامل، وأخفِ الحقول الشخصية أثناء التحديث، وقيّد الوصول كما في الإنتاج.