سجل التدقيق قيدٌ غير قابل للتعديل يوثّق من فعل ماذا ومتى داخل نظام الدعم الفني: الاطلاع، التعديل، التصدير، تغيير الصلاحيات. أهميته أنه المصدر الوحيد الذي يحدّد نطاق أي حادثة أمنية. بدونه لا تستطيع الإجابة عن سؤال «ما حجم التسريب؟»، فتضطر لافتراض الأسوأ والإبلاغ عنه.
سجل التدقيق ضابط لا يُلاحَظ إطلاقًا حتى تحتاجه. لا يمنع حادثة، ولا يسرّع تذكرة، ولا يظهر أثره في أي مؤشر تشغيلي. ثم تقع الحادثة، فيصبح الفرق بين جهة تعرف بالضبط أن ثلاث تذاكر انكشفت، وجهة تفترض أن الأربعين ألفًا كلها انكشفت لأنها لا تملك ما ينفي ذلك.
الفرق بين الحالتين ليس تقنيًّا فحسب — بل هو الفرق بين إشعار محدود لثلاثة أشخاص، وإعلان عام يمسّ سمعة الجهة كلها. هذا المقال يفصّل ما يجب أن يحتويه السجل في نظام الدعم الفني، وكيف يُحمى، وكم يُحفظ، وكيف يُقرأ.
لماذا سجل التدقيق ليس رفاهية؟
سجل التدقيق يخدم أربع وظائف متمايزة، وأغلب الجهات تدرك واحدة منها فقط:
الوظيفة الأولى هي الأثمن، وتظهر قيمتها في أسوأ لحظة ممكنة. مثال افتراضي للتوضيح: جهة اكتشفت أن حساب فنّي دعم كان مخترقًا لأسبوعين. السؤال الأول الذي ستواجهه هو: ماذا رأى المهاجم؟ إن وُجد سجل يبيّن أن الحساب فتح إحدى عشرة تذكرة بعينها، فالنطاق محدّد والاستجابة متناسبة. وإن لم يوجد، فليس أمام الجهة إلا افتراض أن كل ما كان في نطاق صلاحية ذلك الحساب قد انكشف.
الفارق بين السيناريوهين هو الفارق بين حادثة تُدار وحادثة تُدير الجهة. ولا يمكن استدراك ذلك بعد وقوع الحادثة — السجل إما كان يعمل قبلها أو لم يكن.
ماذا يجب أن يُسجَّل؟
الخطأ الأكثر شيوعًا هو تسجيل عمليات الكتابة دون عمليات القراءة. النظام يسجّل «فلان عدّل التذكرة» ولا يسجّل «فلان اطّلع على التذكرة». لكن التسريب فعل قراءة لا فعل كتابة. من يسرق البيانات لا يعدّلها — يقرأها ويصوّرها وينصرف، تاركًا سجلًّا نظيفًا تمامًا.
| الحدث | الأهمية | لماذا |
|---|---|---|
| تصدير جماعي للبيانات | حرجة | القناة الأسرع لخروج حجم كبير من البيانات في فعل واحد |
| تغيير الصلاحيات والأدوار | حرجة | تصعيد الامتيازات خطوة أولى في أغلب الاختراقات |
| الاطلاع على تذكرة مصنّفة حسّاسة | حرجة | القراءة هي فعل التسريب نفسه، لا التعديل |
| تنزيل مرفق | عالية | المرفق قد يحوي بيانات أضعاف ما في التذكرة نفسها |
| محاولات دخول فاشلة متتالية | عالية | مؤشر مبكر على محاولة اختراق حساب |
| انتحال هوية مستخدم | عالية | صلاحية قوية تحتاج أثرًا كاملًا لكل استخدام |
| حذف تذكرة أو مرفق | عالية | قد يكون إخفاءً لأثر لا صيانةً للبيانات |
| تعديل تذكرة مغلقة | متوسطة | تغيير سجل تاريخي بعد اعتماده |
| تعديل إعدادات النظام | متوسطة | تعطيل ضابط أمني قد يسبق الاختراق |
| الاطلاع على تذكرة عادية | أساسية | حجمها كبير لكنها ما يحدّد النطاق عند التحقيق |
ولكل قيد في السجل حدّ أدنى من الحقول لا يكون مفيدًا بدونه: من (هوية المستخدم لا اسم العرض)، ماذا (الفعل والسجل المتأثّر بمعرّفه)، متى (طابع زمني دقيق بمنطقة زمنية موحّدة)، من أين (عنوان IP ومعرّف الجلسة)، والنتيجة (نجح الفعل أم رُفض). القيد الناقص لأحد هذه الحقول يكاد يكون بلا قيمة تحقيقية.
حماية السجل نفسه من التلاعب
سجل يستطيع مدير النظام تعديله ليس سجل تدقيق — هو ملاحظات. المبدأ الحاكم: الإلحاق فقط (Append-Only). يُكتب القيد ولا يُعدَّل ولا يُحذف من أحد، بما في ذلك أعلى صلاحية في النظام. أول ما يفعله مهاجم متمكّن هو محو أثره؛ فإن كان السجل قابلًا للمحو، سقط الضابط كله في اللحظة التي تحتاجه فيها.
- السجل للقراءة فقط في واجهة النظام لكل الأدوار بلا استثناء — بما فيها مدير النظام.
- يُنسخ السجل إلى وجهة مستقلة (نظام إدارة سجلات مركزي) بصلاحيات منفصلة عن صلاحيات نظام التذاكر.
- تُطبَّق آلية تحقّق من السلامة تكشف أي تعديل لاحق على القيود.
- من يدير نظام التذاكر لا يدير مستودع السجلات — فصل المهام هنا ليس تفصيلًا، بل أساس مصداقية السجل كله.
- تُوحَّد المنطقة الزمنية في كل القيود؛ سجل بمناطق زمنية مختلطة يستحيل بناء تسلسل زمني موثوق منه.
- تُراقَب أعطال التسجيل نفسها: توقّف السجل عن الكتابة حادثةٌ تستحق تنبيهًا فوريًّا، لا صمتًا.
- يُتّخذ قرار صريح: هل يتوقّف النظام إن تعذّرت الكتابة في السجل، أم يواصل بلا تسجيل؟ لكل خيار ثمنه، والمهم أن يكون مقصودًا.
مدة الحفظ ومشكلة الحجم
هنا تظهر مفارقة حقيقية. حماية البيانات تدفعك لتقليل ما تحتفظ به، والتدقيق الأمني يدفعك للاحتفاظ بأثر كل شيء — وسجل التدقيق نفسه يحوي بيانات شخصية عن موظفيك. المفارقة لا تُحلّ بالمبدأ بل بالتفصيل: صنّف السجلات، ولكلّ صنف مدةٌ ومسوّغ.
| الطبقة | المحتوى | الغرض |
|---|---|---|
| ساخنة | كل الأحداث بتفصيلها الكامل، قابلة للبحث الفوري | التحقيق النشط والاستجابة للحوادث |
| دافئة | الأحداث الحرجة والعالية فقط، بحث أبطأ | التحقيقات المتأخّرة والمراجعات الدورية |
| باردة | أرشيف مضغوط، استرجاع بطلب | الإثبات عند النزاع والتدقيق الخارجي |
| محذوفة | — | انتهاء المسوّغ ومدة الاحتفاظ المقرّرة |
لا تُحدَّد المدد الفعلية من مقال — تُحدَّد من سياسة جهتك والمتطلبات النافذة عليها وطبيعة بياناتها. لكن المبدأ ثابت: التدرّج يوازن بين قدرة التحقيق وكلفة التخزين والتزام تقليل الاحتفاظ. وحدّة الأثر واضحة: سجل قصير المدة قد يعني اكتشاف اختراق مضى عليه أشهر بلا أي أثر يمكن فحصه. راجع سياسة الاحتفاظ ببيانات التذاكر وحذفها لبناء الجدول متكاملًا.
السجل الذي لا يقرأه أحد
أكثر سجلات التدقيق في العالم لم تُقرأ ولا مرة واحدة. تُفعَّل الخاصية، ويُوضع علامة صحّ في قائمة الامتثال، وتُترك تكتب في صمت إلى الأبد. وهذا يعطّل وظيفتين من الأربع: الكشف يستحيل بلا قراءة، والردع يزول حين يدرك الفريق أن أحدًا لا ينظر.
الخطوة الخامسة هي أنفع ما في هذه القائمة كلها. تمرين نصف ساعة يكشف أن حقلًا ناقص، أو أن الاطلاع لا يُسجَّل أصلًا، أو أن البحث في السجل يستغرق ساعات. الاكتشاف اليوم مجاني، والاكتشاف أثناء الحادثة باهظ. ولوحات التقارير والمؤشرات تجعل هذه المراجعة إجراءً روتينيًّا لا مشروعًا.
وللجهات الحكومية اعتبارات إضافية في هذا الباب تتعلق بالإثبات والتدقيق الخارجي، فُصّلت في سجل التدقيق في الجهات الحكومية.
الأسئلة الشائعة
ما الفرق بين سجل التدقيق وسجل النظام (System Log)؟
سجل النظام تقني يوثّق الأخطاء والأداء والاستثناءات، وجمهوره المطوّرون ومشغّلو البنية التحتية. سجل التدقيق يوثّق أفعال المستخدمين على البيانات، وجمهوره الأمن والالتزام والتحقيق. الاثنان مختلفان في المحتوى والحماية ومدة الحفظ، والخلط بينهما يعني أنك تملك سجلًّا واحدًا لا يؤدّي أيًّا من الوظيفتين جيدًا.
هل تسجيل كل عمليات الاطلاع يؤثّر على الأداء؟
حجم سجل الاطلاع أكبر بمراتب من سجل التعديل، وهذه كلفة تخزين حقيقية لا تُنكر. لكن المفاضلة ليست بين الأداء والتسجيل، بل بين كلفة التخزين وقدرتك على تحديد نطاق حادثة. الحلّ الشائع: تسجيل كل الاطلاع مع تدرّج في الحفظ — تفصيل كامل قصير المدى، وأحداث حرجة طويلة المدى.
هل يجوز تعديل سجل التدقيق لحذف بيانات شخصية بناءً على طلب؟
هذا تعارض حقيقي بين مبدأ سلامة السجل وحقوق أصحاب البيانات، ولا يُحسم بقاعدة عامة. الاتجاه العملي الشائع هو التعامل مع سجل التدقيق كفئة لها مسوّغ مستقل يوازن الحقوق، لا حذفه. لكن كيفية تطبيق ذلك على حالتك مسألة تُعرض على مستشارك القانوني والجهة المختصة، ولا يصحّ الاستدلال عليها من مقال.
هل نحتاج نظام SIEM لنظام التذاكر؟
ليس بالضرورة كنقطة بداية. إن كان لديك SIEM قائم فضمّ سجلات التذاكر إليه منطقي ومفيد. وإن لم يكن، فسجل تدقيق داخلي محكم ومنسوخ إلى وجهة مستقلة ومُراجَع دوريًّا يقطع الشوط الأكبر. الأولوية للسجل الصحيح المقروء، لا للأداة الفاخرة التي تجمع سجلًّا ناقصًا.
من يجب أن يملك صلاحية قراءة سجل التدقيق؟
أضيق دائرة ممكنة: الأمن السيبراني، الالتزام أو الخصوصية، والتدقيق الداخلي. مع ملاحظة جوهرية: السجل يحوي بيانات عن أداء الموظفين وسلوكهم، فقراءته صلاحية حسّاسة بذاتها. اجعل قراءة السجل نفسها مسجَّلة — من قرأ السجل ومتى — وإلا فقد أنشأت نقطة عمياء في قلب ضابطك الأمني.