> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> تتبّع نشاط API في Didit عبر سجلات تدقيق قابلة للبحث. صفِّ حسب المستخدم والطريقة والحالة والتاريخ للتدقيق والمراجعة الأمنية وتصحيح الأخطاء.

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

![سجلات التدقيق في Didit Console](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14)

***

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

| التحدي | الحل |
| - | - |
| متطلبات الامتثال التنظيمي | مسار تدقيق كامل لكل النشاط، لمدة تحفظها خطتك |
| التحقيق في الحوادث الأمنية | تتبّع دقيق لمن فعل ماذا ومتى |
| تصحيح أخطاء التكامل | الاطلاع على مسار كل طلب وحالته ومحتواه بعد التنقيح |
| مساءلة الفريق | تتبّع أعضاء الفريق الذين وصلوا إلى أي بيانات |
| مراقبة الاستخدام | فهم أنماط استهلاك API |

***

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

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

يتضمن كل سجل الحقول التالية:

| الحقل | الوصف |
| - | - |
| **الطابع الزمني** | وقت تنفيذ الطلب |
| **مستخدم** | من نفّذ الطلب: بريد عضو الفريق المصادَق عليه، أو اسم مفتاح API الذي أرسل الطلب ويظهر عليه الوسم **API key**، أو **المحقق** في حال القرار الذي اتخذه بمفرده |
| **الطريقة** | طريقة HTTP (GET وPOST وPUT وDELETE) |
| **المسار** | endpoint الخاص بـ API الذي استُدعي |
| **الحالة** | رمز استجابة HTTP |
| **عنوان IP** | عنوان IP الذي صدر منه الطلب |
| **التطبيق** | التطبيق الذي ارتبط به الطلب |

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

يُسجَّل كل قرار يتخذه [المحقق](https://docs.didit.me/ar/console/investigator.md) بمفرده ضمن **المحقق**، لا ضمن عضو أو مفتاح API. ويشمل ذلك الموافقة على جلسة أو رفضها أو طلب إعادة تقديمها، وتعيين حالة معاملة، وحل حالة أو تصعيدها أو طلب معلومات بشأنها.
يرتبط السجل بتقرير المحقق المرتبط بالقرار.
عندما يقبل شخص توصية المحقق أو يتجاوزها، يُسجَّل السجل باسم ذلك الشخص.

***

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

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

### البحث الذكي

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

| نوع البحث | مثال | السلوك |
| - | - | - |
| **مسار دقيق** | `/v1/organization/.../sessions/` | يعثر على السجلات التي تحمل مسار الطلب هذا بالضبط |
| **بريد إلكتروني دقيق** | `admin@company.com` | يعثر على السجلات الصادرة عن هذا المستخدم تحديداً |
| **IP دقيق** | `192.168.1.100` | يعثر على السجلات الصادرة من عنوان IP هذا |
| **أحرف البدل** | `/v1/*/analytics/*` | يطابق الأنماط باستخدام أحرف البدل |
| **نص عام** | `sessions` | بحث تقريبي في جميع الحقول |

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

| الفلتر | الوصف | مثال |
| - | - | - |
| **التطبيق** | التصفية حسب تطبيق بعينه | الاختيار من القائمة المنسدلة |
| **الأعضاء ومفاتيح API** | التصفية حسب مفتاح API الذي أرسل الطلبات | اختيار مفتاح من التطبيق المحدد |
| **الفاعل** | عرض ما قام به الأعضاء أو مفاتيح API أو المحقق فقط | **المحقق** |
| **الطريقة** | التصفية حسب طريقة HTTP | `GET` وَ`POST` وَ`PUT` وَ`DELETE` |
| **رمز الحالة** | التصفية حسب رمز الاستجابة | `200` وَ`401` وَ`500` |
| **النطاق الزمني** | التصفية حسب الفترة الزمنية | آخر 7 أيام، أو نطاق مخصص |

***

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

تحدد خطتك المدة التي يمكنك الرجوع إليها في سجل التدقيق، وما إذا كان بإمكانك تصديره:

| الخطة | المدة الزمنية | التصدير |
| - | - | - |
| Free | 30 يومًا | لا |
| Growth | سنة واحدة | لا |
| Scale | 3 سنوات | نعم |
| Enterprise | تحدده بنود عقدك | نعم |

أما التصدير على خطة لا تشمله فتكون استجابته `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`. وأدوار القارئ ومسؤول الامتثال والمطوّر والمسؤول والمالك تملك هذه الصلاحيات جميعاً، أما [الدور المخصص](https://docs.didit.me/ar/console/roles-permissions.md) فيُمنح له بتحديد **سجلات التدقيق** في محرر الأدوار.

***

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

> [accordion] التدقيق الامتثالي
>
> أثبت للمدققين أن لديك رؤية كاملة لكل من وصل إلى بيانات التحقق:
>
> 1. صفِّ النتائج حسب نطاق التاريخ الذي يطابق فترة التدقيق
> 2. صفِّ النتائج حسب تطبيقات أو مستخدمين محددين عند الحاجة
> 3. صدِّر النتائج أو التقط لقطة شاشة لها لتوثيقها

> [accordion] التحقيق الأمني
>
> إذا اشتبهت في وصول غير مصرّح به:
>
> 1. ابحث عن البريد الإلكتروني للمستخدم المتأثر أو عناوين IP المشبوهة
> 2. صفِّ النتائج حسب نطاق التاريخ المحيط بالحادثة المشتبه بها
> 3. ابحث عن الأنماط غير المعتادة: محاولات المصادقة الفاشلة، ونقاط endpoint غير متوقعة، وساعات غير معتادة

> [accordion] تصحيح أخطاء التكامل
>
> عند استكشاف مشكلات تكامل API وإصلاحها:
>
> 1. ابحث عن مسار endpoint المحدد
> 2. صفِّ النتائج حسب رموز الحالة `4xx` أو `5xx` للعثور على الأخطاء
> 3. سجّل الطوابع الزمنية لمقارنتها مع سجلات تطبيقك

> [accordion] مراجعة نشاط الفريق
>
> راقب كيفية استخدام فريقك للمنصة:
>
> 1. صفِّ النتائج حسب البريد الإلكتروني لأعضاء فريق محددين
> 2. راجع الجلسات والميزات التي وصلوا إليها
> 3. تأكد من أن أعضاء الفريق يتبعون الإجراءات الصحيحة

***

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

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.