الخدمة 5: الامتثال لحماية البيانات وهندسة دورة حياة البيانات

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

العمل هنا ليس ملء قالب جاهز. بل ربط كل بند بمقابل حقيقي: أي بيانات تُجمَع ولماذا، وكم تُحفَظ، ومن يصل إليها، وكيف تُقنَّع، وما الذي يُحذَف فعلاً حين يصل طلب حذف. وكل رقم أدناه مقيس من شيفرة تعمل في أنظمتي.

لماذا هذه الخدمة؟

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

منهجي المعماري

1) تثبيت مدة الحفظ داخل الشيفرة

كتابة "تسعون يوماً" في إشعار خصوصية أمر سهل؛ أما ضمان زوال السجل فعلاً في اليوم الحادي والتسعين فعمل آخر. مدة الحفظ ثابتٌ مكتوب على الصنف البرمجي، ومهمة خلفية تعمل مرة كل يوم تنظّف السجلات المنتهية بحذف على دفعات.

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

2) ألّا يُترَك التقنيع للتخمين

لا يكفي قول "لا تُسجّل رقم الهوية"؛ بل يجب تعريف كيف يُكتب إن لزم تسجيله. وقاعدة التقنيع تشترط خوارزمية HMAC-SHA256 وناتجاً لا يقلّ عن 128 بت.

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

3) جعل الحذف دالّة تعمل

حين يرسل صاحب البيانات طلب حذف لا يكفي أن يكون الجواب "تسلّمنا طلبكم"؛ بل ينبغي أن تكون أصناف البيانات المحذوفة قابلة للعدّ. يُجمَع الحذف في دالّة واحدة تمشي على شجرة المستخدم كاملة بالترتيب: الملف الشخصي، وسجل الموافقة، والترتيبات الدورية، والمشاركات وما تحتها من تصويتات، والدعوات، وسجل الهوية.

وثمة استثناء مقصود: سجل المشتريات لا يُحذَف بل يتحوّل إلى أثرٍ لا يحمل بيانات شخصية. والسبب تنظيمي مالي؛ إذ يجب الاحتفاظ بسجل المعاملة. والحل الصحيح ليس تجاهل السجل بل تجريده من المعرّف وفصله عن الشخص.

4) تأريخ نص الامتثال

محتوى الامتثال إن كُتب مرة وتُرك يشيخ بصمت. وسياسة المراجعة تربط كل بند بصنف دورية، وتثبّت الملفات المشتقّة من قانون حماية البيانات ومن OWASP على دورة ربع سنوية، لأن جهة خارجية تُصدر التحديثات. والبند غير المطابق يسقط في الفحص الآلي؛ أي أن "نسيان التحديث" لا يمرّ بصمت.

ما الذي أقدّمه

الأرقام التي تعمل في أنظمتي

ما يلي ليس أمثلة بل قيم مقيسة من شيفرتي أنا. وأصدق طريقة لشرح الامتثال هي أن تُظهر كيف طبّقته على نظامك.

التقنيات التي أستخدمها

خدمات خلفية في ASP.NET Core، وتجزئة بـ HMAC-SHA256 مع تمليح، وسجلات مُهيكَلة على Serilog مع مُثرِيات تقنيع، وكنس حفظ على دفعات في MSSQL، وحذف حسابات من جهة الخادم عبر Firebase Admin SDK، ومسار موافقة Google UMP، وفحص آلي لتواريخ ملفات القواعد.

ما أتركه عن قصد

في الامتثال، الوعد المبالَغ فيه أخطر من الوعد الناقص. وما يلي حدود مقصودة:

مخرجات المشروع

لمن تناسب؟

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

لماذا أنا؟

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

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

الخلاصة

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