उपयोगकर्ता क्या करते हैं इसका ट्रैक कैसे रखें

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

परिचय

मैं एक समाधान वास्तुकार के रूप में काम करता हूं वित्तीय सेवाओं में। पंक्ति को संशोधित करने वाले अंतिम उपयोगकर्ता का रिकॉर्ड रखना महत्वपूर्ण है। सरलतम मामलों में, पता लगाने की क्षमता के लिए संशोधन के टाइमस्टैम्प को रिकॉर्ड करने के लिए पर्याप्त है परिवर्तनों का। यहां एक तालिका का एक सरल उदाहरण दिया गया है जो ग्राहक अनुबंधों को संग्रहीत करती है जिसमें last_changed . शामिल हैं उपयोगकर्ता और टाइमस्टैम्प के लिए कॉलम।

फिर भी, कुछ मामलों में, यह पर्याप्त नहीं है। हमारे पास अक्सर पूर्ण पता लगाने की क्षमता होनी चाहिए (“छवियों” के पहले और बाद में . सहित डेटा का)। कुछ मामलों में, हमें ऑडिटेबिलिटी की भी आवश्यकता होती है (कौन, क्या, कब)।

दुर्भाग्य से, हमारे कई सिस्टम ट्रैसेबिलिटी और ऑडिटेबिलिटी प्रदान करने के लिए डिज़ाइन नहीं किए गए थे। हमें रिवर्स इंजीनियर . की आवश्यकता थी सिस्टम में इन व्यवसाय संचालन आवश्यकताओं।

पता लगाने की क्षमता

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

यहां आप प्रत्येक ऑडिट ट्रेल आइटम के लिए एक प्रविष्टि देख सकते हैं, साथ ही प्रत्येक कॉलम के पहले और बाद के मान बदल गए हैं। साथ ही, यदि कोई पंक्ति हटा दी जाती है, तो हम उस जानकारी को functioncode . के साथ सहेजते हैं हटाने का संकेत दे रहा है। हमने "ऑपरेशन" (बनाएं, अपडेट करें, हटाएं) के नाम या विवरण के बजाय, संशोधन के प्रकार को निर्दिष्ट करने वाले फ़ंक्शन (सी, आर, डी) के कोड को स्टोर करने के लिए वर्कर (1) का उपयोग करना चुना है (बनाएं, अपडेट करें, हटाएं) . instance_key इसमें उस आइटम की प्राथमिक कुंजी होती है जिसे ट्रेस करने योग्यता के लिए जोड़ा, संशोधित या हटाया गया था।

फिर भी, हो सकता है कि आपकी डेटा एक्सेस परत आपके लिए आवश्यक कार्यक्षमता प्रदान न करे। अन्य उत्पादों के लिए, हमारी डेटा एक्सेस परत नहीं थी। उन मामलों में, पता लगाने की क्षमता को जटिल परिवर्तनों की आवश्यकता थी। उदाहरण के लिए, आपको पुनर्प्राप्ति और लॉगिंग . की आवश्यकता हो सकती है संशोधन से पहले किसी भी डेटा का। जैसा कि मैंने लिखा है, यह संभव है लेकिन इसे लागू करना जटिल हो सकता है। एक पंक्ति को संशोधित करने से पहले डेवलपर्स को प्रत्येक पंक्ति की पुनर्प्राप्ति बनानी होगी। किसी अपडेट को बिना चयन के चलाना संभव नहीं होगा।

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

एक साधारण तालिका का उपयोग किया जा सकता है यदि केवल उपलब्ध जानकारी नया मान है और पिछला मान नहीं है।

ऑडिटेबिलिटी

कुछ स्थितियों में, हमें यह सुनिश्चित करना चाहिए कि सिस्टम में की गई सभी कार्रवाइयां पूरी तरह से ऑडिट करने योग्य हैं . किसने किस समय लॉग इन किया? प्रत्येक उपयोगकर्ता ने केवल डेटा देखने सहित, सिस्टम में कौन-सी कार्रवाइयां कीं? यह महत्वपूर्ण है क्योंकि यदि उपयोगकर्ता किसी भुगतान को देखता है तो यह महत्वपूर्ण हो सकता है।

सुक्ष्म अनुरेखण प्राप्त करने के लिए केवल डेटाबेस एक्सेस को देखना मुश्किल हो सकता है। हमें अक्सर उच्च स्तर पर देखना चाहिए और किए गए कार्यों या सेवाओं की जांच करनी चाहिए। कुछ मामलों में, हम यह जानने के लिए प्रत्येक सेवा कॉल का पता लगाने में सक्षम थे कि उपयोगकर्ता ने किस समय क्या किया। वेब सेवा इनपुट/आउटपुट नियंत्रक के साथ, सेवा अनुरोधों को दर्ज करना काफी आसान था।

यहाँ एक साधारण उपयोगकर्ता ऑडिट लॉग का एक उदाहरण है जहाँ हम प्रत्येक उपयोगकर्ता द्वारा की जाने वाली क्रिया को रिकॉर्ड करते हैं। मैं अगले खंड "प्रूफ़" में इस दृष्टिकोण के बारे में कुछ मुद्दों पर चर्चा करता हूँ।

एक संक्षिप्त तालिका विवरण नीचे दिया गया है:

user_audit तालिका में डेटा ऑडिट प्रविष्टियाँ हैं जो टाइमस्टैम्प हैं। प्राथमिक कुंजी में audit_entry_time . होते हैं स्टाम्प प्लस user_id और bank_id साथ ही action . का नाम प्रदर्शन किया। फ़ील्ड के अर्थ होते हैं जो उनके नाम के अनुरूप होते हैं। ऑडिट टेबल result को स्टोर करती है कार्रवाई की, साथ ही वास्तविक class जिसने कार्रवाई को अंजाम दिया, उसका इनपुट parameters और कोई भी errors ।

यहां एक ऑडिट ट्रेल का एक और उदाहरण दिया गया है जहां हम डेटा की पहले और बाद की छवियों को रिकॉर्ड करते हैं जिन्हें एक विशेष तालिका में संशोधित किया गया था (प्रदर्शन की गई कार्रवाई, उपयोगकर्ता क्रेडेंशियल और टाइमस्टैम्प के साथ)।

audit_trail तालिका में डेटा के पहले और बाद की छवियों की ऑडिट प्रविष्टियां हैं। प्राथमिक कुंजी में audit_gen_key होता है यह एप्लिकेशन द्वारा उत्पन्न एक कुंजी है। फ़ील्ड के अर्थ होते हैं जो उनके नाम के अनुरूप होते हैं। डेटाबेस तालिका का नाम जिसके लिए यह ऑडिट ट्रेल प्रविष्टि दर्ज की गई है, modified_table . में संग्रहीत है , साथ ही "पहले" छवि prev_value . में संग्रहीत है और "बाद" छवि new_value . में . module जो संशोधन कर रहा है और funct_type संशोधन (बनाएँ, अद्यतन करें, हटाएं) भी संग्रहीत हैं। अंत में, user_id . की ऑडिट जानकारी (और संबंधित bank_id ) प्लस परिवर्तन का टाइमस्टैम्प (date_last_changed )

फिर हमने एक चुनौती मारा। ट्रेसिबिलिटी जानकारी और ऑडिटेबिलिटी जानकारी दोनों को लॉग करते समय, लॉगिंग दो बार होती है। ऑडिट के दृष्टिकोण से, यह कष्टप्रद है। लेखापरीक्षकों को यह सुनिश्चित करना चाहिए कि इन दो लॉगों के बीच जानकारी समान है।

सबूत

एक अन्य चुनौती थी सभी उपयोगकर्ता कार्रवाइयों . की लॉगिंग सुनिश्चित करना . वित्तीय सेवा उद्योग में लेखा परीक्षकों द्वारा अक्सर इसकी आवश्यकता होती है।

अब हमारे सामने असली चुनौती है। हमारा समाधान केंद्रीय ट्रेसबिलिटी और ऑडिटेबिलिटी लॉगिंग सुनिश्चित करना था। केंद्रीय "इंटरफ़ेस" यह सुनिश्चित करता है कि उस इंटरफ़ेस के सभी कार्यान्वयन में लॉगिंग शामिल है। यह सुनिश्चित करना सीधा था कि सभी उपयुक्त वर्ग इंटरफ़ेस को लागू कर रहे थे।

बेशक, यह लॉगिंग का 100% प्रमाण सुनिश्चित नहीं करता है। यह एक मजबूत सुरक्षा जांच है कि सभी उपयुक्त वर्ग आवश्यकतानुसार लॉगिंग कर रहे थे।

निष्कर्ष

किसी मौजूदा सिस्टम में इंजीनियरिंग की नई व्यावसायिक कार्यक्षमता को उलट देना हमेशा एक चुनौती होती है। यह तब और भी अधिक हो सकता है जब क्रियान्वित कार्यक्षमता मूल में जाती है।