الامتثال لـ SOX و GDPR في عملية إصدار Salesforce

الإجابة باختصار: قانون SOX يطلب منك إثبات أن الشخص الذي بنى التغيير ليس هو من أطلقه للإنتاج، وأن كل تغيير في الإنتاج يرجع إلى طلب معتمد. أما GDPR فيطلب إثبات أن البيانات الشخصية جرى تقليلها وحمايتها، حتى داخل بيئات الـ sandbox. والخبر الجيد أن أي pipeline عادي في Salesforce ينتج معظم هذه الأدلة أصلاً، فالمطلوب هو ضبط الـ pipeline بحيث يفرض الضوابط بنفسه بدل إعادة تجميعها يدوياً مرة كل سنة.

ما الذي يطلبه SOX و GDPR فعلياً من عملية الإصدار؟

قانونان مختلفان، لكن لهما مطلب مشترك واحد: ضوابط مصمّمة ومفروضة وقابلة للإثبات.

• SOX (ساربينز-أوكسلي) ينطبق على الشركات المدرجة في الولايات المتحدة. المادة 404 تُلزم الإدارة بتقييم الرقابة الداخلية على التقارير المالية. وعملياً، يختبر المدقق ضوابط تقنية المعلومات العامة: من يستطيع تعديل الأنظمة التي تُنتج الأرقام المالية، وكيف تُعتمد هذه التعديلات، وهل الصلاحيات مناسبة.
• GDPR ينطبق كلما عالجت بيانات شخصية لأشخاص داخل الاتحاد الأوروبي. وفي سياق الإصدار، الالتزامات المهمة هي تقليل البيانات (المادة 5)، وحماية البيانات بالتصميم وبشكل افتراضي (المادة 25)، وأمن المعالجة (المادة 32).

لا يذكر أي منهما أداة بعينها. كلاهما يطلب الأشياء الثلاثة نفسها: ضابط، ودليل على تنفيذه، ودليل على أنه نُفّذ في كل مرة.

أي أجزاء من الـ org تقع داخل النطاق؟

ليست كلها، وتحديد ذلك مبكراً هو ما يبقي التدقيق صغيراً. نطاق SOX يتبع الأرقام المالية:

• الكائنات والأتمتة التي تغذّي الاعتراف بالإيراد والفوترة وعروض الأسعار والتوقعات: Opportunity و Order و Product و Price Book وإعدادات CPQ أو Revenue Cloud وعمليات اعتماد الخصومات.
• أي شيء يستطيع تغيير هذه القيم بدون تدخل بشري: الـ Flows ومحفزات Apex وقواعد التحقق ومستخدمي التكامل.
• الـ Profiles و Permission Sets و Permission Set Groups التي تمنح صلاحية التعديل على ما سبق.

نطاق GDPR شكله معكوس: يتبع البيانات الشخصية أينما كانت، أي غالباً Contact و Lead و Case و Person Account ونصوص المحادثات وكل نسخة sandbox منها.

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

كيف تفرض فصل المهام دون إبطاء الإصدارات؟

فصل المهام يعني أن كاتب التغيير لا يمكن أن يكون هو من ينقله إلى الإنتاج. الـ change sets لا تستطيع فرض ذلك، لأن من يملك النشر يملك البناء أيضاً. ضع الضابط داخل الـ pipeline بدلاً من ذلك:

1. اسحب صلاحيات النشر من الأشخاص في الإنتاج. هوية التكامل الخاصة بالـ pipeline وحدها هي التي تنشر. صلاحيات Modify All Data و Modify Metadata في الإنتاج تخص هذه الهوية، لا المطورين ولا المسؤولين.
2. اجعل الـ pull request نقطة الضبط. اشترط مراجعة معتمدة واحدة على الأقل من شخص غير الكاتب، وعطّل الاعتماد الذاتي في قواعد حماية الفروع.
3. افصل الاعتماد حسب البيئة. الترقية إلى UAT يمكن أن يعتمدها قائد الفريق التقني، أما الإطلاق للإنتاج فيحتاج أيضاً مالك العملية من جانب الأعمال.
4. سجّل مسار الطوارئ بدل منعه. عمليات النشر الاستثنائية ستحدث. حدّد من يحق له تشغيلها، واشترط توثيق بند عمل خلال 24 ساعة، ودع الـ pipeline يسجّلها كاستثناء. المدقق يقبل استثناءً موثقاً، ولا يقبل استثناءً غير موثق.

ما أدلة التغيير التي يقبلها المدقق؟

المدققون يعملون بالعينات. يختارون عدداً من تغييرات الإنتاج ويطلبون منك تتبع كل واحد من الطلب حتى الإطلاق. الـ pipeline يجيب بروابط لا بلقطات شاشة:

• بند العمل، مع السبب التجاري واسم مقدّم الطلب.
• الـ commits التي تُظهر بدقة أي بيانات وصفية تغيّرت.
• الـ pull request، مع هوية المراجع وختم الوقت.
• دليل الاختبار: اختبارات Apex والتغطية والتحليل الساكن أو مخرجات المراجعة الآلية للكود.
• سجل النشر: الـ org الهدف ورقم النشر ومن شغّله والنتيجة.

خاصيتان تجعلان هذا الدليل ينجح: أن يكون غير قابل للتعديل حتى لا يعدّل أحد التاريخ لاحقاً، وأن يكون كاملاً، أي لا يوجد طريق إلى الإنتاج يتجاوزه. الـ pipeline الذي يغطي 90% من التغييرات يسقط في الضابط، لأن العينة قد تقع في الـ 10% الباقية.

كيف تتعامل مع البيانات الشخصية في الـ sandbox دون مخالفة GDPR؟

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

• ازرع البيانات ولا تنسخها كاملة. اسحب شريحة تمثيلية بدل قاعدة البيانات كلها. بيانات أقل تعني تعرضاً أقل وتحديثاً أسرع.
• أخفِ البيانات عند الوصول. أخفِ هوية الحقول الشخصية أو استبدلها ضمن عملية التحديث نفسها، لا كمهمة لاحقة يتذكرها أحدهم يوم الخميس. Salesforce Data Mask يغطي الأنماط القياسية.
• قيّد الوصول إلى الـ sandbox كما في الإنتاج. نفس الـ profiles، ونفس الانضباط في الـ permission sets، ونفس إجراءات إنهاء الوصول. الـ partial sandbox ببريد إلكتروني حقيقي وprofile متساهل هي أكثر ملاحظة نراها.

كم من الوقت يجب الاحتفاظ بالأدلة؟

أطول مما يحتفظ به Salesforce نيابة عنك. الـ Setup Audit Trail يحتفظ بنافذة متحركة مدتها 180 يوماً ويمكن تنزيلها كملف CSV. أما Field History Tracking فيحتفظ بنحو 18 شهراً في الواجهة و24 شهراً عبر الـ API، إلا إذا اشتركت في Field Audit Trail ضمن Shield وضبطت سياسة احتفاظ. دورات SOX سنوية والأدلة تُطلب عن الفترة كاملة، فالنوافذ الأصلية لا تكفي وحدها.

Git مع منصة الـ DevOps يحلّان ذلك بهدوء: تاريخ المستودع دائم، وسجلات النشر تعيش خارج الـ org بدل أن تنتهي صلاحيتها بداخله.

كيف يبدو الـ pipeline المتوافق من البداية إلى النهاية؟

1. كل تغيير يبدأ كبند عمل له سبب تجاري واضح، ويدخل نظام التحكم بالإصدارات.
2. المراجعة الآلية والاختبارات تعمل على الـ pull request قبل أن ينظر إليها إنسان.
3. معتمد غير الكاتب يوقّع، مع معتمد ثانٍ عند بوابة الإنتاج.
4. هوية الـ pipeline وحدها تنشر، وكل نشر يكتب سجلاً غير قابل للتعديل.
5. تحديثات الـ sandbox تُزرع وتُخفى بياناتها بنفس الأتمتة، والأدلة قابلة للتصدير عند الطلب.

لا شيء من هذا يحتاج منتج امتثال منفصل. يحتاج فقط عملية الإصدار التي كنت تريدها أصلاً، مضبوطة بحيث تكون الضوابط هي الطريق الوحيد. معظم منصات Salesforce DevOps يمكن إعدادها بهذا الشكل، ومنها Copado و Gearset و AutoRABIT و Flosum و Serpent. وتجد أدلة عملية أخرى مثل هذا الدليل في مكتبة SF Guides عندنا.

FAQ

هل ينطبق SOX على الـ org كلها؟

لا. النطاق يتبع التقارير المالية: عروض الأسعار والطلبات والفوترة وكائنات الإيراد والأتمتة التي تمسّها. وثّق الحدود بنفسك قبل أن يوسّعها المدقق.

هل يمكن تحقيق الامتثال لـ SOX باستخدام change sets؟

صعب جداً. الـ change sets لا تفصل الكاتب عن الناشر ولا تترك سجل اعتماد مرتبطاً، فينتهي بك الأمر ببناء طبقة أدلة يدوية بجانبها.

هل الـ full sandbox ببيانات إنتاج مخالفة لـ GDPR؟

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

من يجب أن يعتمد الإطلاق للإنتاج؟

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