تخطَّ إلى المحتوى
SteveTechArcSteveTechArc Courses

احمِ واحتفظ وأثبِت

متاح أيضًا بـ28 لغة

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

A heavy round vault door standing open onto rows of plain archive boxes, one shelf already empty and a cart waiting outside.
صورة مولّدة بالذكاء الاصطناعي

الوحدة 6 من 6 في فصل جودة البيانات وحوكمتها، الفصل 5 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: الموافقة والحق في النسيان · التالي: الفصل التالي، البيانات الرئيسية والهوية

السؤال الذي تجيب عنه هذه الوحدة: كيف تحمي البيانات، وتحتفظ بها المدة المطلوبة، وتثبت ذلك؟

حددنا المالكين والسياسات، وأبقينا البيانات السيئة خارجًا، وكتبنا القاموس، وتتبّعنا سلسلة النَّسَب، وصنّفنا ما يهم، وتعلمنا القوانين، ونمذجنا الموافقة. الآن علينا أن نشغّل ذلك كله. تصل البيانات، وتُستخدم، وتُنسخ، وتتغير، وتتقادم، وفي النهاية يجب أن يرحل بعضها. وذات يوم سيسأل أحدهم: أثبِت ما حدث.

الحوكمة تتبع البيانات

Section titled “الحوكمة تتبع البيانات ”

لا أفكر في الحوكمة بوصفها ميزة واحدة. أفكر فيما يحدث للبيانات من لحظة دخولها حتى ننتهي منها:

الالتقاط ← التصنيف ← الحماية ← الاستخدام ← الاحتفاظ ← الحذف ← التدقيق

ليست سبع عمليات تقنية: بل سبعة أسئلة على المعمارية أن تجيب عنها. الالتقاط والتصنيف غطيناهما: أبقِ الأخطاء المكلفة خارجًا (الوحدة 2)، واعرف أي البيانات حساسة (الوحدة 3). التصنيف يقرر ما يحدث في كل مرحلة لاحقة، لذا تكمل هذه الوحدة من هناك.

دورة حياة البيانات المحكومة دورة حياة البيانات المحكومة في سبع مراحل، لكل منها سؤالها وأمثلة على آليات Salesforce. الالتقاط: هل هي جيدة بما يكفي لإدخالها؟ قواعد التحقق، وقواعد التكرار، والحقول الإلزامية، وبوابة جودة؛ الوحدة 2. التصنيف: ما مدى حساسيتها؟ حقول تصنيف البيانات للحساسية والامتثال والمالك؛ الوحدة 3. الحماية: من يجوز له رؤيتها وتغييرها؟ المشاركة، والأذونات، والوصول إلى الحقول، وتشفير Shield، وإخفاء البيانات في sandbox؛ الوحدة 6. الاستخدام: هل هذا الاستخدام مسموح؟ نموذج الموافقة، وغرض استخدام البيانات، ووصول التكاملات والوكلاء؛ الوحدة 5. الاحتفاظ: كم نحتفظ بها؟ سياسات الاحتفاظ، والأرشيفات، وbig objects؛ الوحدة 6. الحذف: ماذا يحدث في النهاية؟ Privacy Center، ومهام الحذف، وإزالة ما يحدد الهوية؛ الوحدة 5. التدقيق: هل نستطيع إثباته؟ سجل تاريخ الحقول، وField Audit Trail، وEvent Monitoring مُرسَلًا إلى SIEM؛ الوحدة 6. وفي الأسفل: الأدوات تدعم السياسة؛ ولا تحددها. المرحلة السؤال آليات SALESFORCE، مثلًا تُدرَّس في 1 · الالتقاط هل هي جيدة بما يكفي لإدخالها؟ قواعد التحقق، قواعد التكرار، الحقول الإلزامية، بوابة جودة الوحدة 2 2 · التصنيف ما مدى حساسيتها؟ حقول تصنيف البيانات: الحساسية، الامتثال، المالك الوحدة 3 3 · الحماية من يجوز له رؤيتها وتغييرها؟ المشاركة، الأذونات، الوصول إلى الحقول، تشفير Shield، إخفاء البيانات في sandbox الوحدة 6 4 · الاستخدام هل هذا الاستخدام مسموح؟ نموذج الموافقة، غرض استخدام البيانات، وصول التكاملات والوكلاء الوحدة 5 5 · الاحتفاظ كم نحتفظ بها؟ سياسات الاحتفاظ، الأرشيفات، big objects الوحدة 6 6 · الحذف ماذا يحدث في النهاية؟ Privacy Center، مهام الحذف، إزالة ما يحدد الهوية الوحدة 5 7 · التدقيق هل نستطيع إثباته؟ سجل تاريخ الحقول، Field Audit Trail، Event Monitoring إلى SIEM الوحدة 6 الأدوات تدعم السياسة؛ ولا تحددها. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

سبعة أسئلة على امتداد حياة البيانات. الأدوات تدعم السياسة؛ ولا تحددها.

الحماية: طابِق الضابط مع البيانات

Section titled “الحماية: طابِق الضابط مع البيانات ”

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

التشفير ضابط، لا امتثال

Section titled “التشفير ضابط، لا امتثال ”

بالنسبة للبيانات الخاضعة للتنظيم، قد يكون التشفير أثناء التخزين مطلوبًا، وموقفي أن Shield هو الجواب للمتطلبات التنظيمية الأساسية مثل هذا. يشفّر Shield Platform Encryption الحقول والملفات أثناء التخزين. لكن «شفّرناها، إذن نحن ممتثلون» خطأ مرتين. التشفير ضابط واحد بين الوصول، والاحتفاظ، والتدقيق، والموافقة، والمراقبة، وتقليل البيانات، والحذف. وله مفاضلات وظيفية تصمم لها مسبقًا. مع المخطط الاحتمالي (probabilistic) الافتراضي، لا يمكن استخدام حقل مشفّر في عبارات SOQL WHERE أو GROUP BY أو ORDER BY ولا في عوامل التصفية الخاصة بإدارة البيانات؛ أما التشفير الحتمي (deterministic) فيتنازل عن قليل من القوة كي تستطيع التصفية على الحقل. لا يمكن للحقول المشفّرة أن تقود قواعد المشاركة القائمة على المعايير، ولا يمكنك فرز طرق عرض القوائم بها (General Shield Platform Encryption Considerations (opens in a new tab)؛ Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). لذا فالتشفير ليس مربع اختيار في النهاية. إنه قرار معماري. يتعمق فصل أمن البيانات أكثر.

لا تنسخ مخاطر بيئة الإنتاج إلى sandbox

Section titled “لا تنسخ مخاطر بيئة الإنتاج إلى sandbox ”

بيئة الإنتاج مُحكمة الإغلاق. ثم يحدّث أحدهم sandbox كاملة، فيصبح لدى المطورين، والمختبِرين، والمتعاقدين، وتكاملات الاختبار نسخ من بيانات شخصية حقيقية لم يحتاجوا إليها قط. البيئة تغيرت؛ وحساسية البيانات لم تتغير. أدوات الإخفاء في Salesforce موجودة لهذا بالضبط. لاحظ تغييرًا: الحزمة المُدارة Data Mask تبلغ نهاية خدمتها في 31 ديسمبر 2026، وخليفتها هي Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). لكن الأداة تدعم السياسة، والسؤال يأتي أولًا: هل تحتاج هذه البيئة إلى بيانات حساسة حقيقية أصلًا؟ إذا كانت بيانات واقعية غير حساسة تكفي للاختبار، فذلك هو الجواب الأفضل.

الاستخدام: الإذن لا يتعلق بالناس فقط

Section titled “الاستخدام: الإذن لا يتعلق بالناس فقط ”

المستخدمون، والتكاملات، والتحليلات، والشركاء، والأتمتة، والوكلاء كلهم يستخدمون البيانات. الموافقة (الوحدة 5)، والملكية (الوحدة 1)، والتصنيف (الوحدة 3) تلتقي هنا أثناء التشغيل. هل ينبغي لهذا المستخدم أن يرى رقم هاتف المستلم؟ هل ينبغي لهذا التكامل أن يحصل عليه، أو Snowflake، أو هذا الوكيل لأغراض التأريض بالبيانات؟ لا يمكن أن يكون الجواب «حسنًا، تقنيًا يستطيع». هذا هو الفرق بين القدرة والحوكمة: المعمارية تقرر هل ينبغي ذلك.

الاحتفاظ: الاحتفاظ بكل شيء إلى الأبد ليس حيادًا

Section titled “الاحتفاظ: الاحتفاظ بكل شيء إلى الأبد ليس حيادًا ”

لدى كثير من المؤسسات سياسة احتفاظ عَرَضية: إلى الأبد. لم يقررها أحد؛ كانت مساحة التخزين متاحة، فبقيت البيانات. لكن الاحتفاظ بالبيانات يكلّف تخزينًا وأداءً، ويوسّع التعرض لمخاطر الخصوصية والأمن، ويضيف التزامات اكتشاف، ويمنحك أماكن أكثر للبحث فيها حين يطلب أحدهم أن يُنسى. لكل فئة مهمة: لماذا نحتفظ بها، وإلى متى، وما الذي يبدأ العدّ، وهل هناك حد أدنى قانوني أو حد أقصى للخصوصية، وماذا يحدث في النهاية: أرشفة، أم حذف، أم إزالة لما يحدد الهوية؟

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

الحذف: دورة الحياة تحتاج إلى مخرج

Section titled “الحذف: دورة الحياة تحتاج إلى مخرج ”

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

التاريخ بيانات أيضًا

Section titled “التاريخ بيانات أيضًا ”

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

تتبّع تاريخ الحقول القياسي يتابع حتى 20 حقلًا لكل كائن ويحتفظ بالتغييرات حتى 18 شهرًا، وحتى 24 شهرًا عبر الـ API فقط، باستخدام Data Loader أو queryAll() (Field History Tracking Overview (opens in a new tab)). وبالنسبة لحقول النص الطويل، يسجل فقط أن الحقل عُدّل، لا ما كان يقوله: فجوة إذا كان ذلك دليلك. Field Audit Trail، جزء من Shield أو يُشترى منفردًا، يتابع حتى 200 حقل لكل كائن ويحتفظ بالتاريخ إلى أن تحذفه، في أرشيف تصل إليه عبر الـ API (Field Audit Trail (opens in a new tab)). موقفي: سجل تاريخ الحقول القياسي هو الافتراضي؛ استخدم Field Audit Trail حين تتطلب لائحة تنظيمية أو التزام امتثال تاريخًا أطول وقابلًا للإثبات. لا لأن «التدقيق يبدو جيدًا».

التدقيق والمراقبة ليسا الشيء نفسه

Section titled “التدقيق والمراقبة ليسا الشيء نفسه ”

سجل تاريخ الحقول يجيب عن أسئلة حول التغييرات على حقول مختارة. أما الأسئلة الأوسع (من سجّل الدخول، ومن صدّر البيانات، وأي واجهات API استُدعيت، ومن اطّلع على ماذا) فهي مراقبة، وهذا هو Event Monitoring. في تجربتي يُحتاج إليه عادة مع العملاء الأكثر خضوعًا للتنظيم، وإليك أقوى مواقفي في هذا الفصل: هيّئه قبل أن تحتاج إليه، ووجّه الأحداث مسبقًا إلى مستودع، مثل Splunk أو أي SIEM آخر.

وإليك السبب. ملفات سجل الأحداث تُحفظ يومًا واحدًا دون الإضافة المدفوعة، ولبعض أنواع الأحداث فقط؛ و30 يومًا افتراضيًا مع Shield أو إضافة Event Monitoring، وحتى 365 يومًا إذا مددت الاحتفاظ (Event Monitoring FAQ (opens in a new tab)). وكل ما هو أقدم يضيع ما لم تكن قد صدّرته. ولا يمكن استرجاع السجلات المدفوعة لأي فترة قبل بدء عقدك (الأسئلة الشائعة نفسها): شراء الإضافة بعد الحادثة لا يعيد الماضي. لذا فإن واحدة من أسوأ المحادثات التي قد يخوضها معماري تسير هكذا: «هل نستطيع أن نرى ماذا حدث قبل ستة أشهر؟» «لا.» «لماذا؟» «لم نكن نلتقطها.» لا يصحّ أن تقع في مشكلة ثم تكتشف أنك لم تكن تلتقط تلك الأحداث وتخزّنها. عندها يكون الجواب قد ضاع ببساطة.

الدليل الذي لم تحتفظ به قد ضاع مخطط مسارات (swim lane) بثلاثة مسارات: Salesforce، الذي تُحفظ سجلات أحداثه 30 يومًا افتراضيًا؛ وSIEM، الذي يحتفظ بها المدة التي تقولها السياسة؛ ومحقق من الأمن أو الامتثال. الخطوة 1، في Salesforce: تُلتقط الأحداث، مثل تسجيلات الدخول والتصديرات واستدعاءات API. الخطوة 2: تُرسَل إلى SIEM كل يوم. الخطوة 3، في SIEM: تُحفظ لأكثر من 30 يومًا. الخطوة 4: بعد ستة أشهر يسأل المحقق SIEM ماذا حدث. الخطوة 5: يجيب SIEM، ها هو. الخطوة 6: يسأل المحقق Salesforce ماذا كان سيحدث دون SIEM. الخطوة 7، بالأحمر: ضاعت بعد 30 يومًا. وفي الأسفل: هيّئه قبل أن تحتاج إليه؛ لا يمكن استرجاع السجلات لأي فترة قبل أن تبدأ في الاحتفاظ بها. بعد ستة أشهر، يسأل أحدهم ماذا حدث Salesforce SIEM تُحفظ المدة التي تقولها السياسة المحقق الأمن، الامتثال أحداث تُلتقط: تسجيلات الدخول، التصديرات، استدعاءات API 1 تُرسَل كل يوم 2 تُحفظ لأكثر من 30 يومًا 3 ماذا حدث قبل ستة أشهر؟ 4 ها هو 5 ولو لم نرسلها؟ 6 ضاعت بعد 30 يومًا ضاعت بعد 30 يومًا 7 هيّئه قبل أن تحتاج إليه. لا يمكن استرجاع السجلات لأي فترة قبل أن تبدأ في الاحتفاظ بها. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

هيّئه قبل أن تحتاج إليه.

لكن لا تنتقل إلى الطرف الآخر: «سجّل كل شيء». ما الذي تحاول إثباته؟ أي الأحداث مهمة، ومن يحتاجها، وإلى متى، ومن يجوز له قراءة السجلات، وهل يمكن أن تحتوي السجلات نفسها على بيانات حساسة؟ التسجيل يُنشئ بيانات، وتلك البيانات تحتاج إلى حوكمة أيضًا. والأدلة تحتاج إلى مالك: من يملك المستودع، ويراجع التنبيهات، ويتحقق من أن الاحتفاظ يعمل، ويلاحظ أن التغذية توقفت بصمت قبل ثلاثة أشهر؟ التقنية بلا ملكية ليست حوكمة؛ عدنا إلى المالك والأمين والقيّم في الوحدة 1.

أثبِت الضابط، لا الإعداد فقط

Section titled “أثبِت الضابط، لا الإعداد فقط ”

«بيانات المستلم متاحة فقط للطواقم المكلّفة بالمحطة.» كيف نعرف؟ إعدادات الأمن تُظهر ما ينبغي أن يحدث. والأدلة التشغيلية (من اطّلع عليها فعلًا، والتصديرات غير المعتادة، وتكامل يسحبها، وضوابط وصول تغيرت) تُظهر ما حدث فعلًا. الحوكمة الجيدة تحتاج غالبًا إلى الاثنين.

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

Steve Trucking: دورة الحياة على حقل واحد

Section titled “Steve Trucking: دورة الحياة على حقل واحد ”

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

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

الحوكمة لا تنتهي أبدًا

Section titled “الحوكمة لا تنتهي أبدًا ”

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

ما الذي يقرره المعماري هنا

Section titled “ما الذي يقرره المعماري هنا ”
  • أي ضوابط الحماية تحصل عليها كل فئة من البيانات، بناءً على التصنيف والسياسة والاستخدام الفعلي، بما في ذلك مفاضلات التشفير.
  • كم من الوقت تُحفظ البيانات وسجل تاريخها، وما الذي يبدأ العدّ، وماذا يحدث في النهاية.
  • متى يكفي سجل تاريخ الحقول القياسي، ومتى تستدعي لائحة تنظيمية Field Audit Trail.
  • أي الأحداث تُلتقط، وأين تُخزَّن الأدلة بعد مدة احتفاظ المنصة، ومن يملكها.
  • كيف تُثبت المعمارية تصرفات البشر والتكاملات والوكلاء المهمة بعد وقوعها.

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

للاستزادة

Section titled “للاستزادة ”