आपके संगठन की हर API रिक्वेस्ट 365 दिनों के लिए दर्ज रहती है - किसने, क्या, कब, कहां से और किस एप्लिकेशन के तहत किया। क्या हुआ, यह जानने के लिए यहीं देखें।
आपके संगठन की हर API रिक्वेस्ट अपने आप लॉग होती है और 365 दिनों तक रखी जाती है - कंसोल से, आपके इंटीग्रेशन से, और आपके टीम सदस्यों से भी। यह सेटिंग्स → ऑडिट लॉग के तहत मिलेगी। इन्वेस्टिगेटर अपने आप जो भी फ़ैसला लेता है, वह भी यहीं जाँचकर्ता के नाम से दर्ज होता है।
#क्या दर्ज होता है
आपके संगठन के भीतर Didit प्लेटफ़ॉर्म को की गई हर रिक्वेस्ट, चाहे वह किसी ने भी की हो। हर एंट्री में यह होता है:
| फ़ील्ड | जानकारी |
|---|---|
| Timestamp | रिक्वेस्ट कब की गई |
| User | किसने किया: वह सदस्य जिसने रिक्वेस्ट की; API-की से हुई रिक्वेस्ट के लिए, की का नाम, API कुंजी टैग के साथ; Didit जो काम अपने आप करता है, उसके लिए Didit; और इन्वेस्टिगेटर के अपने आप लिए गए फ़ैसले के लिए जाँचकर्ता |
| Method | GET, POST, PUT, DELETE |
| Path | जिस एंडपॉइंट को कॉल किया गया |
| Status | HTTP रिस्पॉन्स का स्टेटस |
| IP address | रिक्वेस्ट कहां से आई |
| Application | यह किस एप्लिकेशन से जुड़ी थी |
लॉग 365 दिनों तक रखे जाते हैं और उसके बाद अपने आप डिलीट हो जाते हैं।
एक नए डिज़ाइन वाला ऑडिट लॉग, जो हर बदलाव को शब्दों में बताता है और जो आप देख रहे हैं उसे एक्सपोर्ट कर सकता है, धीरे-धीरे रोल आउट हो रहा है। जब तक यह आपके संगठन तक नहीं पहुंचता, पेज यहां बताया गया रिक्वेस्ट लॉग दिखाता है।
#यह असल में किस काम आता है
चार स्थितियां जहां यही सही टूल है:
- "इस वर्कफ़्लो को किसने बदला?" कोई फ़्लो जो कल से अलग व्यवहार कर रहा है, आमतौर पर उसके पीछे कोई एडिट होता है, और लॉग यह बता देता है कि किसने किया।
- किसी घटना की जांच करना। ठीक-ठीक यह पता लगाना कि किसने, कहां से, किस क्रम में क्या एक्सेस किया।
- किसी इंटीग्रेशन को डीबग करना। यह देखना कि आपके अपने कोड ने असल में कौन-सी रिक्वेस्ट भेजीं, न कि आप क्या सोचते हैं कि उसने भेजीं - जिसमें वे भी शामिल हैं जो 4xx में गईं।
- एक्सेस कंट्रोल का सबूत देना। किसी ऑडिटर को यह दिखाना कि सत्यापन डेटा तक पहुंच जवाबदेह और समीक्षा योग्य है।
#फ़िल्टर करना
किसी लंबी लिस्ट को छोटा करने के लिए उपयोगकर्ता (कोई सदस्य, कोई API-की, Didit या जाँचकर्ता), एंडपॉइंट या तारीख़ की सीमा से फ़िल्टर करें। जब आप किसी ख़ास बात की जांच कर रहे हों, तो टाइमस्टैंप से शुरू करके बाहर की तरफ़ बढ़ें - कोई रिक्वेस्ट कभी अकेले नहीं होती, और उसके ठीक आस-पास की कॉल्स अक्सर पूरी कहानी बता देती हैं।
#API-की से हुई रिक्वेस्ट की के नाम पर दर्ज होती हैं, किसी व्यक्ति के नाम पर नहीं
API-की से हुई रिक्वेस्ट के पीछे कोई व्यक्ति नहीं होता जिसके नाम दर्ज किया जाए, इसलिए इसके बजाय यह की का नाम दिखाती है। यही सही तरीका है - प्लेटफ़ॉर्म को सच में नहीं पता होता कि यह कॉल आपकी किस सर्विस या इंजीनियर ने की।
इसका व्यावहारिक असर: कई सर्विस में शेयर की गई एक ही की किसी घटना की जांच को काफ़ी मुश्किल बना देती है। अगर आपके लिए जवाबदेही मायने रखती है, तो हर सर्विस को उसकी अपनी की दें। देखें अपनी API-की का प्रबंधन करना।
#इन्वेस्टिगेटर के अपने फ़ैसले इन्वेस्टिगेटर के नाम दर्ज होते हैं
जब इन्वेस्टिगेटर आपकी दी हुई स्वायत्तता के भीतर अपने आप फ़ैसला लेता है, तो एंट्री में किसी व्यक्ति या की का नहीं, बल्कि जाँचकर्ता का नाम होता है। इसमें उसका हर फ़ैसला आता है: किसी सेशन को अनुमोदित या अस्वीकार करना या यूज़र से उसे दोबारा भेजने के लिए कहना, किसी ट्रांज़ैक्शन का स्टेटस तय करना, और किसी केस को हल करना, उसे एस्केलेट करना या उस पर जानकारी मांगना। इनमें से हर एंट्री उस फ़ैसले के पीछे की इन्वेस्टिगेटर रिपोर्ट से लिंक होती है, ताकि आप देख सकें कि उसे क्या मिला और उसने आपकी पॉलिसी का कौन-सा नियम लागू किया।
जब कोई व्यक्ति इन्वेस्टिगेटर की रिपोर्ट पर फ़ैसला लेता है, यानी उसकी सिफ़ारिश स्वीकार करता है या उसे ओवरराइड करता है, तो एंट्री उसी व्यक्ति के नाम दर्ज होती है, उसके किसी भी दूसरे बदलाव की तरह। इन्वेस्टिगेटर का पूरा रिकॉर्ड, उसकी रिपोर्ट, सवालों और सुरक्षा नियमों के साथ, उसके अपने गतिविधि लॉग में रहता है। देखें इन्वेस्टिगेटर को नियंत्रित करें और उसकी निगरानी करें।
#लॉग में क्या है, और क्या नहीं है
लॉग एक्टिविटी दर्ज करता है - किसने क्या कॉल किया, कब, कहां से, और क्या स्टेटस लौटा। यह एक मेटाडेटा ट्रेल है, सत्यापन डेटा की कॉपी नहीं।
अगर आपको यह जानना है कि इन एंट्री में ग्राहक का निजी डेटा दिखता है या नहीं - डेटा-प्रोटेक्शन रिव्यू के दौरान अक्सर उठने वाला सवाल - तो इसका जवाब किसी हेल्प पेज से अंदाज़ा लगाने के बजाय अपने Didit संपर्क से लें और उसे दर्ज कर लें। यह ठीक वैसी ही बात है जिसका सबूत आपकी अपनी DPIA में मांगा जाएगा।
#इसे कौन देख सकता है
ऑडिट लॉग तक पहुंच रोल पर निर्भर है। Compliance Officer में यह शामिल है; Reader के पास व्यापक पहुंच नहीं होती। Owner इसे किसी कस्टम रोल को दे सकते हैं। देखें टीम सदस्यों को आमंत्रित करना और रोल तय करना।
किसी टीम सदस्य को हटाने से लॉग में मौजूद उसका इतिहास नहीं हटता - यही तो इसकी पूरी बात है। जिस ट्रेल को आप एडिट कर सकें, वह ट्रेल है ही नहीं।
#एक्सपोर्ट और रिपोर्ट भी लॉग होती हैं
सेशन का PDF या CSV एक्सपोर्ट बनाना भी एक API कॉल है, इसलिए यह भी यहां दिखता है कि इसे किसने किया। यह तब काम आता है जब आपको दिखाना हो कि सत्यापन के सबूतों तक पहुंच खुली नहीं, नियंत्रित है। देखें सत्यापन रिपोर्ट डाउनलोड करना।
#अगर आपको 365 दिनों से ज़्यादा चाहिए
रिटेंशन 365 दिनों पर तय है। अगर आपकी ज़रूरत इससे ज़्यादा की है, तो अपनी ज़रूरत का डेटा एक तय समय-अंतराल पर एक्सपोर्ट करें और उसे अपने सिस्टम में रखें - बिल्कुल वैसे ही जैसे आप सेशन के सबूत ख़ुद रखते हैं। ज़रूरी अवधि तय करना आपकी टीम का कंप्लायंस फ़ैसला है; किसी अंदाज़े के आधार पर डिज़ाइन न करें।
ऑडिट-लॉग रिटेंशन और सत्यापन-डेटा रिटेंशन अलग-अलग सेटिंग हैं। सेशन डेटा के लिए छोटी रिटेंशन विंडो सेट करने से ऑडिट लॉग छोटा नहीं होता, और उल्टा भी सच है। देखें Didit आपके उपयोगकर्ताओं का डेटा कैसे सुरक्षित रखता है।
अभी भी अटके हैं? किसी व्यक्ति से बात करें।
अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।