البيانات الشخصية تختبئ في سجلات التطبيقات
تُعدُّ سجلات التطبيقات من أكثر أسطح GDPR التي يغفل عنها المهندسون. ليس لأن المهندسين يتجاهلون القانون. بل لأن تفاصيل المستخدمين تدخل ملفات السجلات عن طريق الخطأ.
يمكن لسجل طلب JSON واحد أن يحمل أربعة حقول من البيانات الشخصية:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
يحمل هذا الإدخال الواحد بريداً إلكترونياً وعنوان IP ورقم هاتف. اضرب ذلك في ملايين طلبات واجهة برمجة التطبيقات اليومية. النتيجة نشاط بيانات شخصية ضخم. يحتاج إلى أساس قانوني وحدود وضوابط.
مشاركة السجلات مع أطراف خارجية يرفع مخاطر GDPR
تتشارك الفرق ملفات السجلات مع أطراف خارجية طوال الوقت:
- شركات اختبار الاختراق تحصل على السجلات لرسم خريطة سلوك التطبيق
- المستشارون الخارجيون يستخدمون عينات السجلات للعثور على نقاط الضعف
- منصات السجلات (Elastic وDatadog وSplunk) تستقبل تدفقات المخرجات الكاملة
- مقاولو SRE يصلون إلى السجلات خلال الحوادث
- فرق التطوير في كيانات قانونية أخرى تستقبل الملفات لأغراض التصحيح
كل مشاركة تُثير أسئلة المادة 28 من GDPR. هل المستلم معالج بيانات؟ هل توجد اتفاقية معالجة بيانات؟ هل لديه أساس قانوني للاطلاع على تفاصيل المستخدمين في تلك الملفات؟
منصات السجلات ثغرة شائعة. إرسال المخرجات مع رسائل البريد الإلكتروني الحقيقية وعناوين IP للمستخدمين إلى Elastic Cloud أو Datadog يُنشئ رابط معالجة. يحتاج ذلك الرابط إلى اتفاقية معالجة بيانات وبنود قياسية وأداة نقل إذا كانت المنصة خارج الاتحاد الأوروبي. كل هذه تستغرق وقتاً ومراجعة قانونية.
المسار الأبسط: جرِّد تفاصيل المستخدمين قبل مغادرة الملفات لنظامك. اقرأ نظرتنا العامة على الامتثال للاطلاع على قواعد المادة 28 الكاملة.
لماذا تجعل بنية JSON الكشف صعباً
تتباين ملفات سجلات JSON في بنيتها. المسح النصي العام لا يكفي.
عمق التشعب: تظهر تفاصيل المستخدمين على أي عمق. يحمل الحقل request.headers.x-forwarded-for عناوين IP. قد يحمل الحقل response.body.errors[0].field_value مدخلات المستخدم. يفوِّت المسح النصي المستوي الحقول المدفونة في مسارات متشعبة.
مخططات غير متسقة: كل نقطة نهاية لواجهة برمجة التطبيقات تُنتج شكل مخرجات خاص بها. ملفات التحقق من الهوية تختلف عن ملفات الدفع. ملفات تحديث الملف الشخصي تختلف عن كليهما. نهج المسار الثابت يفوِّت تفاصيل المستخدمين التي تظهر في مسارات غير معتادة في سياقات الخطأ.
القيم التقنية ممزوجة مع البيانات الشخصية: يجب أن تبقى تتبعات المكدس ورموز الخطأ والطوابع الزمنية سليمة. المسح الشامل يمحو الحقول الضرورية ويجعل الملف عديم الفائدة.
النهج الصحيح هو الكشف القائم على المحتوى. أوجد تفاصيل المستخدمين بما هي عليه — نمط بريد إلكتروني، تنسيق IP، كيان مُسمَّى — لا بموقعها في البنية. هذا يتعامل مع المخططات المتغيرة دون الحاجة إلى إعداد لكل نقطة نهاية.
الاستبدال المتسق يُبقي السجلات مفيدة
المتطلب الرئيسي هو سلامة المراجع. إذا ظهر sarah.johnson@company.com في 47 إدخالاً عبر سلسلة طلبات، يجب أن تُعيَّن كل الـ 47 إلى القيمة ذاتها.
قواعد التعيين:
sarah.johnson@company.com→user1@example.com(القيمة ذاتها في الملف كله)82.123.45.67→192.0.2.1(عنوان IP توثيقي بموجب RFC 5737 — ليس حقيقياً بوضوح)+49 176 1234 5678→+49 XXX XXX XXXX(مُقنَّع)
مع هذا التعيين، يستطيع مطوِّر تتبع user1@example.com عبر 47 إدخالاً، وإعادة بناء سلسلة الطلبات، وإصلاح الخطأ — دون رؤية أي تفاصيل حقيقية للمستخدمين.
تبقى هذه الحقول الوصفية دون تغيير:
- الطوابع الزمنية (ليست بيانات مستخدم)
- رموز وأنواع الأخطاء (ليست بيانات مستخدم)
- تتبعات المكدس (قد تحتوي على معرِّفات تقنية، ليست بيانات مستخدم)
- طرق HTTP والمسارات ورموز الحالة (ليست بيانات مستخدم)
- قيم المقاييس وأرقام زمن الاستجابة (ليست بيانات مستخدم)
النتيجة ملف يعمل لأغراض التصحيح. لا يحتوي على أي تفاصيل حقيقية للمستخدمين. راجع معلوماتنا للاطلاع على الفرق بين إزالة الهوية وإزالة الهوية الزائفة بموجب GDPR.
حالة استخدام: مشاركة السجلات في اختبار الاختراق
أجرت شركة SaaS مراجعة أمنية ربع سنوية مع فريق اختبار اختراق خارجي. تطلَّب النطاق 90 يوماً من مخرجات واجهة برمجة التطبيقات الإنتاجية لرسم خريطة تدفقات التحقق من الهوية وتحليل أنماط الأخطاء.
الحجم الخام: 180 ميغابايت من ملفات JSON. عدد البيانات الشخصية: 4,200 عنوان بريد إلكتروني فريد للمستخدمين، و1,800 عنوان IP فريد، و340 رقم حساب جزئي في سياقات الأخطاء.
بدون تجريد تفاصيل المستخدمين أولاً، كانت مشاركة تلك الملفات ستتطلب:
- اتفاقية معالجة بيانات مع شركة اختبار الاختراق
- أداة نقل بموجب المادة 46 من GDPR (كانت الشركة خارج الاتحاد الأوروبي)
- مراجعة إشعار أصحاب البيانات
كل هذه تُضيف عملاً قانونياً ووقتاً.
مع تطبيق تجريد البيانات الشخصية:
- وقت المعالجة: 25 دقيقة لـ 180 ميغابايت
- المخرج: 180 ميغابايت من الملفات المتطابقة هيكلياً، جميع البريد الإلكتروني وعناوين IP استُبدلت بقيم آمنة
- النتيجة: حصل فريق اختبار الاختراق على السياق الكامل؛ لم تصلهم أي تفاصيل حقيقية للمستخدمين
- نتيجة GDPR: لا تتطلب اتفاقية معالجة بيانات — المخرج المُجرَّد لا يُعدُّ بيانات مستخدم بموجب GDPR
راجع الأسئلة الشائعة للاطلاع على الأسئلة الشائعة حول ما يُعدُّ مجهول الهوية بموجب GDPR.
دمج تجريد البيانات الشخصية في خطوط CI/CD
للفرق التي تتشارك المخرجات بانتظام، يمكن تشغيل هذه الخطوة داخل خطوط الأنابيب الموجودة.
تدوير السجلات:
- يعمل برنامج التدوير ليلاً
- تعمل خطوة التجريد قبل الأرشفة أو الشحن إلى أي منصة سجلات
- تذهب الملفات المُجرَّدة إلى الأنظمة الخارجية
- تبقى الملفات الأصلية داخلياً مع الاحتفاظ الكامل
برنامج نصي ما قبل المشاركة:
- يحتاج مهندس إلى مشاركة عينة مع مقاول
- يشغِّل البرنامج النصي:
input=raw-logs/ output=clean-logs/ - يشارك مجلد
clean-logs/ - لا حاجة لمراجعة يدوية للبيانات الشخصية
نهج العملية الجانبية:
- تُجرِّد العملية الجانبية تدفق المخرجات قبل إعادة توجيهه
- يحافظ التجريد الفوري على الفائدة لتحليل السجلات
- تستقبل المنصة صفر تفاصيل حقيقية للمستخدمين
دمج سياسة الاحتفاظ
تتطلب المادة 5(1)(e) من GDPR تحديد مدة التخزين. يناسب تجريد البيانات الشخصية أي سياسة احتفاظ.
- المخرجات الخام تُحتفَظ بها 7 أيام (للتصحيح اليومي)
- النسخ المُجرَّدة تُحتفَظ بها 90 يوماً (لتحليل الاتجاهات ومراجعة الحوادث)
- تعمل خطوة التجريد في اليوم السابع
هذا يستوفي تحديد مدة التخزين. يُزيل خطر الاحتفاظ بالمخرجات الخام على المدى الطويل.