حزام اختبار لتنقيح السجلات: مشاريع تخرج الأمن السيبراني

السجل مفيد حتى يصبح نسخة ثانية من البيانات

في مشاريع تخرج الأمن السيبراني، تضيف الفرق سجلات لتشخيص الأعطال، لكن نسخ request body كاملاً قد ينقل كلمة مرور أو رمز جلسة إلى مخزن أطول عمراً وأوسع وصولاً. مشروع تخرج الأمن السيبراني هنا يبني حزام اختبار يعالج سجلات اصطناعية قبل السماح بتغيير serializer أو collector. المقصود اختبار سياسة مكتوبة، لا الادعاء بأن التعبير النمطي يكتشف كل سر محتمل.

اكتب قائمة بالحقول المحظورة والمسموحة وأسبابها. OWASP يوصي بتجنب تسجيل كلمات المرور ورموز الجلسات ومعلومات حساسة غير لازمة، وبحماية السجلات من العبث والوصول غير المناسب. حافظ على قرارات المشروع قابلة للمراجعة؛ كلمة «تنقيح» وحدها لا تحدد هل يحذف الحقل أو يستبدله بعلامة ثابتة أو يختصره.

اجعل بيانات الاختبار صناعية

أنشئ سجلات JSON فيها email تجريبي، وpassword ثابت مخصص للfixture، وAuthorization header وهمي، ومعرف طلب لا يحمل معنى حقيقياً. أضف أسماء حقول بديلة مثل access_token وsessionId وصيغاً متداخلة داخل metadata. لا تستخدم dump من الإنتاج حتى بعد استبدال الاسم؛ قد تبقى سمات أو نصوص حرة تكشف الشخص أو المؤسسة.

لكل fixture اكتب النتيجة المتوقعة: حقل يحذف، قيمة تستبدل بـ[REDACTED]، أو حقل يبقى لأنه ضروري للتحقيق. ضع نوع قاعدة التنقيح ونسختها في التقرير. إذا استعملت OpenTelemetry Collector، وثائق التحويل توضح إمكان معالجة بيانات الإشارات؛ اختبر المعالج بإعداد محلي منفصل ولا تعد أن إضافة معالج واحد تغطي مصادر logs كلها.

قواعد محددة قبل regex

ابدأ بمعالجة بنية JSON حتى تستطيع استهداف المسار مثل user.password، بدلاً من بحث نصي يطمس كل كلمة مشابهة. للنص الحر، ضع قواعد محدودة موثقة مع أمثلة إيجابية وسلبية، واذكر أن regex قد يتجاوز الصيغ المشفرة أو المقطعة. أضف مستوى severity لتقرير الحالات، لكن لا تحفظ نص القيمة التي اعتبرها الفاحص حساسة.

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

تغيير صغير يسبب رجوع التسريب

افترض أن التطبيق كان يسجل object يحوي status وrequest_id فقط، ثم أضاف مطور حقل body للتشخيص. اجعل fixture فيها password وcomment بريء، ويجب أن يظل comment إذا أجازت السياسة ذلك بينما تختفي password. هذا يكشف قاعدة عامة مثل «احذف body كله» قد تمنع التشخيص، وقاعدة «احتفظ بكل شيء» تسرب بيانات. القرار يجب أن يظهر في schema لا أن يدفن في interceptor.

قارن السجل قبل التنقيح وبعده بواسطة JSON path، ثم افحص أن القيمة الأصلية لا تظهر في الرسالة أو stack trace أو ملف debug. احتفظ بحقل سبب الحذف، مثلاً credential-field، دون تسجيل قيمة. هذه تجربة يكتبها الطالب؛ لا توحِ بأن الفحص أثبت سلامة جميع سجلات المنتج.

مصفوفة القبول والفشل

اختبر أسماء حقول معروفة، تفاوت الأحرف الكبيرة، بنية nested، قائمة من العناصر، null، نصاً طويلاً، قيمة URL فيها query secret، وخطأ serializer. معيار القبول أن لا تظهر fixture السرية في خرج التنقيح، وأن الحقول المسموح بها تبقى متاحة. أضف اختباراً يفشل عند تغيير schema وإضافة حقل غير مصنف، لكن اجعل سياسة التعامل معه قراراً معلناً: حجب محافظ أو تحذير للمراجع.

تحقق من الملفات الناتجة كلها، لا استدعاء الدالة فقط. قد يطبع logger استثناءً يحوي الكائن الأصلي عند فشل التنقيح؛ اختبر مسار الاستثناء ذاته. راجع صلاحية المستخدمين لمجلد التقارير ومدة الاحتفاظ به. الإخفاء في واجهة العرض لا يكفي إذا بقي النص في ملف raw أو telemetry exporter.

نتائج لها حدود صريحة

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

يسلم مشروع التخرج fixtures آمنة، سياسة حقول، محرك قواعد، تقريراً لا يكشف القيم، وشرحاً لمسارات الفشل. يرتبط العمل بخدمة مشاريع التخرج وتطوير التطبيقات. وهو مختلف عن تدقيق صلاحيات CI: يعالج محتوى السجل بعد إنشائه، ولا يقرر من يستطيع تشغيل workflow. تفصل إرشادات OWASP Logging ضوابط المحتوى عن إدارة الوصول والاحتفاظ، وتشرح وثائق OpenTelemetry للتحويل موضع معالجة الإشارات.