मुख्य सामग्री पर जाएं
ऑडिट लॉग आपके संगठन के भीतर होने वाली सभी API गतिविधियों का व्यापक और खोजने योग्य रिकॉर्ड देते हैं। Didit प्लेटफ़ॉर्म पर किया गया हर अनुरोध, चाहे वह कंसोल से आए, आपके इंटीग्रेशन से या टीम के सदस्यों से, सुरक्षा, अनुपालन और समस्या-निवारण के लिए अपने आप लॉग होता है।
Didit कंसोल में ऑडिट लॉग

​
ऑडिट लॉग क्यों?

​
ऑडिट लॉग तक पहुँचना

Didit कंसोल में Settings > Organization > Audit log खोलें। इंटरफ़ेस आपके संगठन के भीतर किए गए सभी API अनुरोधों की कालक्रमिक सूची दिखाता है। हर लॉग प्रविष्टि में ये फ़ील्ड होते हैं:

​
The Investigator द्वारा लिए गए निर्णय

हर निर्णय जो Investigator स्वयं लेता है, The Investigator के अंतर्गत दर्ज होता है, किसी सदस्य या API कुंजी के अंतर्गत नहीं। इसमें किसी सत्र को स्वीकृत या अस्वीकृत करना या पुनः प्रस्तुति का अनुरोध करना, किसी लेन-देन की स्थिति सेट करना, और किसी केस को हल करना, उसे आगे बढ़ाना या उस पर जानकारी माँगना शामिल है। प्रविष्टि उस Investigator रिपोर्ट से जुड़ती है जिस पर निर्णय आधारित है। जब कोई व्यक्ति Investigator की सिफ़ारिश स्वीकार करता है या उसे बदलता है, तो प्रविष्टि उसी व्यक्ति के अंतर्गत दर्ज होती है।

​
फ़िल्टरिंग और खोज

ऑडिट लॉग इंटरफ़ेस में शक्तिशाली फ़िल्टरिंग क्षमताएँ हैं, ताकि आप ठीक वही खोज सकें जिसकी आपको तलाश है।

​
स्मार्ट खोज

खोज बार अपने आप पहचान लेता है कि आप क्या ढूँढ रहे हैं:

​
उपलब्ध फ़िल्टर

​
डेटा प्रतिधारण

आपका प्लान तय करता है कि आप ऑडिट लॉग में कितने पीछे तक पढ़ सकते हैं और क्या आप उसे एक्सपोर्ट कर सकते हैं: जिस प्लान में एक्सपोर्ट शामिल नहीं है, उस पर एक्सपोर्ट करने का प्रयास "code": "plan_limit_exceeded" के साथ 403 लौटाता है।

​
सुरक्षा और गोपनीयता

​
क्या लॉग होता है

ऑडिट लॉग API अनुरोधों का मेटाडेटा कैप्चर करते हैं:
  • अनुरोध का टाइमस्टैम्प और अवधि
  • उपयोगकर्ता की पहचान (ईमेल, उपयोगकर्ता ID), या वह API कुंजी जिसने अनुरोध किया (उसका नाम और उसके सीक्रेट के पहले कुछ अक्षर, पूरा सीक्रेट कभी नहीं)
  • अनुरोध पथ और क्वेरी पैरामीटर
  • रिस्पॉन्स स्थिति कोड
  • क्लाइंट IP पता और यूज़र एजेंट

​
API कुंजी कॉल के अनुरोध और रिस्पॉन्स बॉडी

API कुंजी से किए गए कॉल के लिए ऑडिट लॉग किसी write अनुरोध की JSON बॉडी और किसी write या त्रुटि के रिस्पॉन्स की एक रिडैक्ट की गई प्रति भी रखता है, ताकि आप देख सकें कि कॉल क्यों विफल हुआ। सफल रीड का रिस्पॉन्स नहीं रखा जाता। रिडैक्शन डिफ़ॉल्ट-डिनाय है:
  • संरचना बनी रहती है: फ़ील्ड के नाम, नेस्टिंग, मान के प्रकार, ऐरे की लंबाई और स्ट्रिंग की लंबाई।
  • कोई मान केवल तभी बना रहता है जब वह Didit के अपने आइडेंटिफ़ायर, स्टेटस, कोड, काउंट या टाइमस्टैम्प में से एक हो, Didit द्वारा परिभाषित फ़ील्ड में, और उस फ़ील्ड की अपेक्षित संरचना के साथ।
  • बूलियन केवल 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 के किसी फ़ील्ड जैसा नामित हो।

​
क्या लॉग नहीं होता

संवेदनशील डेटा की सुरक्षा के लिए निम्नलिखित अपने आप बाहर रखे जाते हैं:
  • प्रमाणीकरण टोकन और क्रेडेंशियल
  • पासवर्ड और सीक्रेट
  • सत्यापन सत्रों का व्यक्तिगत डेटा

​
एक्सेस नियंत्रण

ऑडिट लॉग देखने के लिए audit-logs की read और list अनुमतियाँ चाहिए। Reader, Compliance Officer, Developer, Admin और Owner भूमिकाओं के पास ये दोनों अनुमतियाँ हैं, और कस्टम भूमिका को रोल एडिटर में Audit logs चुनकर ये अनुमतियाँ मिलती हैं।

​
सामान्य उपयोग के मामले

ऑडिटर को यह दिखाएँ कि आपके पास यह पूरी जानकारी है कि सत्यापन डेटा को किसने एक्सेस किया:
  1. ऑडिट अवधि से मेल खाती तिथि सीमा के अनुसार फ़िल्टर करें
  2. ज़रूरत हो तो किसी विशिष्ट एप्लिकेशन या उपयोगकर्ताओं के अनुसार फ़िल्टर करें
  3. दस्तावेज़ीकरण के लिए परिणाम एक्सपोर्ट करें या उनका स्क्रीनशॉट लें
यदि आपको अनधिकृत पहुँच का संदेह है:
  1. प्रभावित उपयोगकर्ता का ईमेल या संदिग्ध IP पते खोजें
  2. संदिग्ध घटना के आसपास की तिथि सीमा के अनुसार फ़िल्टर करें
  3. असामान्य पैटर्न देखें: विफल प्रमाणीकरण प्रयास, अप्रत्याशित endpoint, असामान्य समय
API इंटीग्रेशन की समस्याओं का निवारण करते समय:
  1. विशिष्ट endpoint पथ खोजें
  2. त्रुटियाँ खोजने के लिए 4xx या 5xx स्टेटस कोड के अनुसार फ़िल्टर करें
  3. टाइमस्टैम्प नोट करें ताकि उन्हें अपने एप्लिकेशन लॉग से मिलाया जा सके
देखें कि आपकी टीम प्लेटफ़ॉर्म का उपयोग कैसे कर रही है:
  1. टीम के विशिष्ट सदस्यों के ईमेल के अनुसार फ़िल्टर करें
  2. देखें कि उन्होंने किन सत्रों और सुविधाओं तक पहुँच बनाई
  3. सुनिश्चित करें कि टीम के सदस्य उचित प्रक्रियाओं का पालन कर रहे हैं

​
सर्वोत्तम अभ्यास

  1. नियमित समीक्षा: अनियमितताओं को जल्दी पकड़ने के लिए समय-समय पर ऑडिट लॉग की समीक्षा करें।
  2. खोज को सीमित करें: अनावश्यक परिणाम कम करने और प्रासंगिक प्रविष्टियाँ तेज़ी से खोजने के लिए विशिष्ट फ़िल्टर का उपयोग करें।
  3. तिथि सीमाएँ: बड़े डेटासेट पर बेहतर प्रदर्शन के लिए हमेशा तिथि सीमा निर्दिष्ट करें।
  4. खोजों को बुकमार्क करें: त्वरित पहुँच के लिए सामान्य फ़िल्टर संयोजनों को ब्राउज़र बुकमार्क के रूप में सहेजें।
अंतिम संशोधन 7 नवंबर 2026