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

يُسجَّل كل طلب API في مؤسستك لمدة 365 يومًا - من، وماذا، ومتى، ومن أين، وتحت أي تطبيق. إنه أول مكان تنظر إليه عندما تحتاج إلى معرفة ما حدث.

Short answer

يُسجَّل كل طلب API في مؤسستك تلقائيًا ويُحتفظ به لمدة 365 يومًا - سواء جاء من الكونسول أو من تكاملك أو من زملائك في الفريق. تجده ضمن Audit Logs في الشريط الجانبي.

#ما الذي يُسجَّل

سجلات التدقيق في كونسول Didit تعرض نشاط API مع الطوابع الزمنية ورموز الحالة
  1. صفِّ حسب العضو أو المسار أو الطريقة أو التاريخ للإجابة عن سؤال 'من غيّر هذا'.
  2. يفصل Method وStatus بين عملية قراءة وتغيير فعلي أخذ مفعوله.
  3. العضو الذي نفّذ الطلب.
  4. من أين جاء الطلب - وهذا التفصيل هو ما يحوّل السجل إلى دليل.
كل طلب API في المؤسسة، محفوظ لمدة 365 يومًا.

كل طلب يُوجَّه إلى منصة Didit داخل مؤسستك، أيًا كان مصدره. كل إدخال يحمل:

الحقلالتفصيل
Timestampوقت تنفيذ الطلب
Userالبريد الإلكتروني للمستخدم الموثّق. يكون فارغًا لطلبات مفتاح API، والتي تُنسب إلى التطبيق بدلًا من ذلك
MethodGET وPOST وPUT وDELETE
Pathنقطة النهاية التي استُدعيت
Statusحالة استجابة HTTP
IP addressمن أين جاء الطلب
Applicationالتطبيق الذي ينتمي إليه

تُحفظ السجلات لمدة 365 يومًا ثم تُحذف تلقائيًا.

#الغرض الحقيقي منها

أربع حالات تكون فيها الأداة المناسبة:

  • "من غيّر سير العمل هذا؟" عادةً ما يكون وراء أي مسار يتصرف بشكل مختلف عن الأمس تعديل ما، والسجل يذكر اسم من قام به.
  • التحقيق في حادثة. تتبع ما جرى الوصول إليه بالضبط، ومن قام بذلك، ومن أي عنوان، وبأي ترتيب.
  • تصحيح أخطاء تكامل. رؤية الطلبات التي نفّذتها شيفرتك فعليًا، لا التي تظن أنها نفّذتها - بما فيها تلك التي انتهت برمز 4xx.
  • توثيق ضبط الوصول. إثبات لمدقق أن الوصول إلى بيانات التحقق منسوب ويمكن مراجعته.

#التصفية

صفِّ حسب المستخدم أو نقطة النهاية أو نطاق التاريخ لتضييق قائمة طويلة. عندما تحقق في شيء محدد، ابدأ من الطابع الزمني وتوسّع منه للخارج - فنادرًا ما يحدث طلب بمفرده، والطلبات المحيطة به مباشرة عادةً ما ترسم الصورة الكاملة.

#طلبات مفتاح API تُنسب إلى التطبيق لا إلى شخص

ليس لطلب مفتاح API مستخدم يُنسب إليه، لذا يظهر منسوبًا إلى التطبيق. هذا هو التمثيل الصادق - فالمنصة فعليًا لا تعرف أي من خدماتك أو مهندسيك قام بالطلب.

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

#ما الموجود في السجل وما هو غير موجود

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

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

#من يمكنه رؤيته

الوصول إلى سجل التدقيق يتبع الدور. يشمله دور Compliance Officer؛ أما Reader فليس لديه وصول واسع. يمكن لأصحاب المؤسسة منحه لدور مخصص. راجع دعوة أعضاء الفريق وتحديد الأدوار.

إزالة أحد الزملاء لا تزيل سجل نشاطه من السجل - وهذا بالضبط هو الهدف. المسار الذي يمكنك تعديله ليس مسارًا.

#عمليات التصدير والتقارير تُسجَّل أيضًا

توليد ملف PDF لجلسة أو تصدير بصيغة CSV هو طلب API، لذا يظهر هنا مع اسم من نفّذه. هذا مفيد عندما تحتاج إلى إثبات أن الوصول إلى أدلة التحقق مضبوط لا مفتوح. راجع تنزيل تقرير التحقق.

#إذا احتجت مدة أطول من 365 يومًا

مدة الاحتفاظ ثابتة عند 365 يومًا. إذا كان التزامك أطول من ذلك، صدّر ما تحتاجه وفق جدول زمني واحتفظ به في نظامك الخاص - وهو النمط نفسه المتبع للاحتفاظ بأدلة الجلسات بنفسك. تحديد المدة المطلوبة قرار امتثال يخص فريقك؛ لا تبنِ تصميمك على افتراض.

Note

مدة الاحتفاظ بسجل التدقيق ومدة الاحتفاظ ببيانات التحقق إعدادان منفصلان. ضبط نافذة احتفاظ قصيرة لبيانات الجلسة لا يقصّر سجل التدقيق، والعكس صحيح أيضًا. راجع كيف تحمي Didit بيانات مستخدميك.