ऑडिट लॉग का इस्तेमाल

आपके संगठन की हर 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जिस एंडपॉइंट को कॉल किया गया
StatusHTTP रिस्पॉन्स का स्टेटस
IP addressरिक्वेस्ट कहां से आई
Applicationयह किस एप्लिकेशन से जुड़ी थी

लॉग 365 दिनों तक रखे जाते हैं और उसके बाद अपने आप डिलीट हो जाते हैं।

#यह असल में किस काम आता है

चार स्थितियां जहां यही सही टूल है:

  • "इस वर्कफ़्लो को किसने बदला?" कोई फ़्लो जो कल से अलग व्यवहार कर रहा है, आमतौर पर उसके पीछे कोई एडिट होता है, और लॉग यह बता देता है कि किसने किया।
  • किसी घटना की जांच करना। ठीक-ठीक यह पता लगाना कि किसने, कहां से, किस क्रम में क्या एक्सेस किया।
  • किसी इंटीग्रेशन को डीबग करना। यह देखना कि आपके अपने कोड ने असल में कौन-सी रिक्वेस्ट भेजीं, न कि आप क्या सोचते हैं कि उसने भेजीं - जिसमें वे भी शामिल हैं जो 4xx में गईं।
  • एक्सेस कंट्रोल का सबूत देना। किसी ऑडिटर को यह दिखाना कि सत्यापन डेटा तक पहुंच जवाबदेह और समीक्षा योग्य है।

#फ़िल्टर करना

किसी लंबी लिस्ट को छोटा करने के लिए उपयोगकर्ता, एंडपॉइंट या तारीख़ की सीमा से फ़िल्टर करें। जब आप किसी ख़ास बात की जांच कर रहे हों, तो टाइमस्टैंप से शुरू करके बाहर की तरफ़ बढ़ें - कोई रिक्वेस्ट कभी अकेले नहीं होती, और उसके ठीक आस-पास की कॉल्स अक्सर पूरी कहानी बता देती हैं।

#API-की से हुई रिक्वेस्ट एप्लिकेशन के नाम पर दर्ज होती हैं, किसी व्यक्ति के नाम पर नहीं

API-की से हुई रिक्वेस्ट के पीछे कोई उपयोगकर्ता नहीं होता जिसके नाम दर्ज किया जाए, इसलिए यह एप्लिकेशन के नाम पर दिखती है। यही सही तरीका है - प्लेटफ़ॉर्म को सच में नहीं पता होता कि यह कॉल आपकी किस सर्विस या इंजीनियर ने की।

इसका व्यावहारिक असर: कई सर्विस में शेयर की गई एक ही की किसी घटना की जांच को काफ़ी मुश्किल बना देती है। अगर आपके लिए जवाबदेही मायने रखती है, तो हर इस्तेमाल करने वाले को अपना अलग एप्लिकेशन और की दें।

#लॉग में क्या है, और क्या नहीं है

लॉग एक्टिविटी दर्ज करता है - किसने क्या कॉल किया, कब, कहां से, और क्या स्टेटस लौटा। यह एक मेटाडेटा ट्रेल है, सत्यापन डेटा की कॉपी नहीं।

अगर आपको यह जानना है कि इन एंट्री में ग्राहक का निजी डेटा दिखता है या नहीं - डेटा-प्रोटेक्शन रिव्यू के दौरान अक्सर उठने वाला सवाल - तो इसका जवाब किसी हेल्प पेज से अंदाज़ा लगाने के बजाय अपने Didit संपर्क से लें और उसे दर्ज कर लें। यह ठीक वैसी ही बात है जिसका सबूत आपकी अपनी DPIA में मांगा जाएगा।

#इसे कौन देख सकता है

ऑडिट लॉग तक पहुंच रोल पर निर्भर है। Compliance Officer में यह शामिल है; Reader के पास व्यापक पहुंच नहीं होती। Owner इसे किसी कस्टम रोल को दे सकते हैं। देखें टीम सदस्यों को आमंत्रित करना और रोल तय करना

किसी टीम सदस्य को हटाने से लॉग में मौजूद उसका इतिहास नहीं हटता - यही तो इसकी पूरी बात है। जिस ट्रेल को आप एडिट कर सकें, वह ट्रेल है ही नहीं।

#एक्सपोर्ट और रिपोर्ट भी लॉग होती हैं

सेशन का PDF या CSV एक्सपोर्ट बनाना भी एक API कॉल है, इसलिए यह भी यहां दिखता है कि इसे किसने किया। यह तब काम आता है जब आपको दिखाना हो कि सत्यापन के सबूतों तक पहुंच खुली नहीं, नियंत्रित है। देखें सत्यापन रिपोर्ट डाउनलोड करना

#अगर आपको 365 दिनों से ज़्यादा चाहिए

रिटेंशन 365 दिनों पर तय है। अगर आपकी ज़रूरत इससे ज़्यादा की है, तो अपनी ज़रूरत का डेटा एक तय समय-अंतराल पर एक्सपोर्ट करें और उसे अपने सिस्टम में रखें - बिल्कुल वैसे ही जैसे आप सेशन के सबूत ख़ुद रखते हैं। ज़रूरी अवधि तय करना आपकी टीम का कंप्लायंस फ़ैसला है; किसी अंदाज़े के आधार पर डिज़ाइन न करें।

Note

ऑडिट-लॉग रिटेंशन और सत्यापन-डेटा रिटेंशन अलग-अलग सेटिंग हैं। सेशन डेटा के लिए छोटी रिटेंशन विंडो सेट करने से ऑडिट लॉग छोटा नहीं होता, और उल्टा भी सच है। देखें Didit आपके उपयोगकर्ताओं का डेटा कैसे सुरक्षित रखता है