سجل التدقيق: تتبع نشاط API والامتثال

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

---

​

لماذا سجلات التدقيق

---

​

الوصول إلى سجلات التدقيق

افتح Settings > Organization > Audit log في Didit Console. تعرض الواجهة قائمة مرتبة زمنياً بجميع طلبات API التي صدرت داخل مؤسستك. يتضمن كل سجل الحقول التالية:

​

القرارات التي يتخذها المحقق

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

---

​

التصفية والبحث

توفّر واجهة سجلات التدقيق فلاتر قوية تساعدك على العثور على ما تبحث عنه بدقة.

​

البحث الذكي

يكتشف شريط البحث تلقائياً نوع ما تبحث عنه:

​

الفلاتر المتاحة

---

​

الاحتفاظ بالبيانات

تحدد خطتك المدة التي يمكنك الرجوع إليها في سجل التدقيق، وما إذا كان بإمكانك تصديره: أما التصدير على خطة لا تشمله فتكون استجابته 403 مع "code": "plan_limit_exceeded".

---

​

الأمان والخصوصية

​

ما يتم تسجيله

تسجّل سجلات التدقيق البيانات الوصفية لطلبات API:

• الطابع الزمني للطلب ومدته
• هوية المستخدم (البريد الإلكتروني، ومعرّف المستخدم)، أو مفتاح API الذي أرسل الطلب (اسمه وأول بضعة أحرف من سرّه، دون السر الكامل أبداً)
• مسار الطلب ومعاملات الاستعلام
• رموز حالة الاستجابة
• عنوان IP للعميل ووكيل المستخدم (user agent)

​

نصوص طلبات الاستدعاءات ونصوص استجاباتها لمفاتيح API

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

• يبقى البناء كما هو: أسماء الحقول، والتداخل، وأنواع القيم، وأطوال المصفوفات، وأطوال النصوص.
• تبقى القيمة فقط إذا كانت من معرّفات Didit الخاصة بها، أو حالاتها، أو رموزها، أو أعدادها، أو طوابعها الزمنية، وذلك في حقل تُعرّفه Didit وبالشكل الذي يتوقعه ذلك الحقل.
• تبقى القيمة المنطقية (boolean) فقط في حقل تُعرّفه Didit.
• تُستبدل كل قيمة أخرى بعلامة تحدد نوعها وطولها، مثل [redacted:string:12] أو [redacted:number:5] أو [redacted:boolean]، أما null فيبقى null.
• يُستبدل اسم الحقل الذي ليس معرّفاً بسيطاً، مثل بريد إلكتروني أو رقم هاتف مستخدم كمفتاح، بالعلامة [redacted:key:23].
• يُستبدل المحتوى الذي ليس JSON، مثل النماذج أو رفع الملفات، بملاحظة تذكر نوعه.
• يُقتطع ما تبقى عند 4,096 حرفاً.

تخضع معاملات الاستعلام للتنقيح نفسه. تبقى الرؤوس القياسية فقط، مثل content-type وَuser-agent ورؤوس حد المعدل، أما بقية الرؤوس فتُحذف مع قيمها. لا تُحفظ أبداً أي قيمة يرسلها نظامك، كما في metadata أو vendor_data، حتى لو كان اسم حقلها يشبه أسماء حقول Didit.

​

ما لا يتم تسجيله

لحماية البيانات الحساسة، تُستبعد تلقائياً العناصر التالية:

• رموز المصادقة (token) وبيانات الاعتماد
• كلمات المرور والأسرار
• البيانات الشخصية الواردة من جلسات التحقق

​

التحكم في الوصول

يتطلب عرض سجل التدقيق إذنَي القراءة وسرد المورد audit-logs. وأدوار القارئ ومسؤول الامتثال والمطوّر والمسؤول والمالك تملك هذه الصلاحيات جميعاً، أما الدور المخصص فيُمنح له بتحديد سجلات التدقيق في محرر الأدوار.

---

​

حالات الاستخدام الشائعة

---

​

أفضل الممارسات

1. المراجعة المنتظمة: راجع سجلات التدقيق دوريًا لاكتشاف الحالات غير الطبيعية مبكرًا.
2. تضييق نطاق البحث: استخدم عمليات تصفية محددة لتقليل الضوضاء والعثور على الإدخالات ذات الصلة بسرعة أكبر.
3. نطاقات التاريخ: حدد دائمًا نطاق تاريخ لتحسين الأداء عند التعامل مع مجموعات بيانات كبيرة.
4. حفظ عمليات البحث: احفظ تركيبات التصفية الشائعة كإشارات مرجعية في المتصفح للوصول السريع إليها.