سجل التدقيق

يجيب سجلّ التدقيق عن سؤال واحد يخصّ مساحتك: من فعل ماذا، ومتى، وعلى أيّ شيء. كل إجراء يغيّر الحالة, إنشاء وكيل، أو تغيير دور عضو، أو ربط تكامل، أو حذف معرفة, يكتب مدخلًا واحدًا غير قابل للتعديل. يتعرّف AnyBot على 559 إجراءات مُدقَّقة عبر المنصّة، فالتغطية هي السطح كاملًا لا مجرّد عيّنة مختارة.

تشريح المدخل

يسجّل كل صفّ البنية نفسها، فيُقرأ أيّ إجراء بالطريقة نفسها:

ما الذي يغطّيه

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

كيف ترتبط الأجزاء ببعضها

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

مقاومة العبث

السجلّ أكثر من كونه إلحاقيًّا فقط. فكل مدخل جديد يُختَم داخل سلسلة تجزئة: تجزئته هي sha256(entry-contents | previous entry's hash). ولأنّ كل مدخل يتضمّن المدخل الذي سبقه، فإنّ تعديل أيّ صفّ تاريخيّ أو حذفه يغيّر تجزئته ويكسر كل تجزئة تليه, وهو ما يكتشفه فحص السلامة ويحدّد موضعه بدقّة. والختم يعمل بمبدأ الفشل المفتوح: لا يمكنه أبدًا أن يعيق الإجراء الجاري تسجيله أو يبطئه، والمدخلات المكتوبة قبل إطلاق ميزة السلسلة يُبلَّغ عنها بصدق بوصفها سابقة للسلسلة بدل الوثوق بها ضمنيًّا.

الخصوصية: ما الذي يُحجَب

بُني سجلّ التدقيق ليكون آمنًا للقراءة:

• عناوين IP لا تُكشَف أبدًا عبر واجهة التدقيق البرمجية, بحكم التصميم, ولا حتى للمالكين والمشرفين. فهي تُلتقَط للسجلّ لا لتُعرَض.
• تُختصَر وكلاء المستخدم إلى تسمية تقريبية للمتصفّح / نظام التشغيل / الجهاز. دون أيّ بصمة تعريفية.
• الأسرار ومعلومات PII لا تدخل أيّ مدخل أبدًا. فتغيير كلمة مرور، أو رمز وصول، أو بيانات اعتماد API، أو سجلّ موافقة، يُسجَّل باسم الحقل وفرق آمن, لا بالقيمة أبدًا.

مثال تطبيقي

يرقّي زميلٌ في الفريق عضوًا آخر من عضو إلى مشرف. يُكتب مدخل واحد:

• الإجراء, space.member_updated · التسمية «تغيير دور/أذونات عضو»
• الحسّاسية, high · النتيجة, success
• الفاعل, العضو الذي أجرى الترقية · الكيان, العضو المُرقَّى
• التغيير, role: member → admin
• الطابع الزمني + بيانات العميل التقريبية (عرض المالك/المشرف)

ولاحقًا، يفتح مشغّلٌ ذلك السجلّ من لوحة الإدارة. ولأنّه عالي الحسّاسية، فإنّ فعل الاطّلاع عليه يُدقَّق هو نفسه (audit_log.viewed), فالسجلّ يدقّق مدقّقيه. (يقع هذا التدقيق الذاتي في لوحة المشغّل/المشرف، لا في عرض التدقيق داخل المساحة.)

من يمكنه قراءته

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

الأسئلة الشائعة

هل يمكن تعديل مدخل أو إزالته؟ لا. السجلّ إلحاقيّ فقط، وسلسلة التجزئة تجعل أيّ تغيير لاحق قابلًا للاكتشاف.

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

هل يظهر الوكيل بوصفه فاعلًا؟ نعم, تُنسَب الأحداث الآلية والمدفوعة بردود النداء إلى الوكيل/النظام لا إلى شخص، فلا تُخلَط التغييرات التي يجريها الوكيل الذكي بتلك التي يجريها البشر.

التالي

• الأدوار والأذونات
• الأمان ومعالجة البيانات
• المساحات