लॉग में क्या जानकारी कभी नहीं दिखनी चाहिए? [बन्द है]

Question

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

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

उसी तरह से:

• पासवर्ड ,
• आईपी ​​पते और नेटवर्क जानकारी (मैक पता, होस्ट नाम, आदि) information,
• डेटाबेस का उपयोग,
• उपयोगकर्ता और संग्रहीत व्यावसायिक डेटा से प्रत्यक्ष इनपुट

ट्रेस में कभी नहीं दिखना चाहिए।

तो लॉग से किस प्रकार की अन्य जानकारी को गायब कर दिया जाना चाहिए? क्या पहले से कोई दिशानिर्देश हैं जो मैं उपयोग कर सकता हूं?

---

^{, जाहिर है, मैं आईआईएस या अपाचे लॉग के रूप में चीजों के बारे में बात नहीं कर रहा हूं। मैं जिस बारे में बात कर रहा हूं, वह सूचना है जो केवल आवेदन को डिबग करने के इरादे से एकत्र की जाती है, न कि अविश्वसनीय संस्थाओं की गतिविधि का पता लगाने के लिए।}

---

संपादित करें: आपके उत्तर और आपकी टिप्पणियों के लिए धन्यवाद। चूंकि मेरा प्रश्न बहुत सटीक नहीं है, इसलिए मैं टिप्पणियों में पूछे गए सवालों के जवाब देने की कोशिश करूंगा:

• मैं लॉग के साथ क्या कर रहा हूं?

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

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

• क्या मैं विशिष्ट क्षेत्रों के बारे में बात कर रहा हूं?

नहीं, मैं केवल सामान्य व्यावसायिक अनुप्रयोगों पर काम कर रहा हूं, इसलिए केवल संवेदनशील डेटा व्यवसाय डेटा है। विशिष्ट नियमों द्वारा कवर किए गए स्वास्थ्य या अन्य क्षेत्रों से संबंधित कुछ भी नहीं है। लेकिन इसके बारे में बात करने के लिए धन्यवाद, मुझे संभवतः उन क्षेत्रों के बारे में कुछ सुरागों के बारे में जानकारी लेनी चाहिए जो मैं दिशानिर्देशों में शामिल कर सकता हूं।

• क्या डेटा एन्क्रिप्ट करना आसान नहीं है?

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

Comments

क्या आप लॉग स्तर को ध्यान में रख रहे हैं? मेरा मतलब है, यह debugएक फ़ाइल नाम के लिए ठीक हो सकता है , लेकिन infoएक फ़ाइल नाम के लिए नहीं ।

— जेरेमी हीलर

@ जेरेमी हेइलर: मैं केवल लॉग डेटा के बारे में बात कर रहा हूं जो या तो हार्ड डिस्क (अक्सर असुरक्षित तरीके से) और / या इंटरनेट के माध्यम से डिबगिंग उद्देश्यों के लिए एप्लिकेशन के डेवलपर्स को भेजा जाता है।

— आर्सेनी मौरज़ेंको 20

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

— FrustratedWithFormsDesigner

यह जानने के बिना कि आप क्या कर रहे हैं, यह वास्तव में कठिन है कि संवेदनशील डेटा क्या है। क्या आपको विनियामक चिंताएँ हैं (PCI या HIPAA या जो भी हो)?

— डेविड थॉर्नले

यदि आप उस विशिष्ट क्षेत्र के बारे में बात कर सकते हैं जिसमें आप काम कर रहे हैं, तो security.stackexchange.com पर पूछें क्योंकि सुरक्षा / अनुपालन विशेषज्ञ आपको नियामक, कानूनी या अन्य सुरक्षा मुद्दों के बारे में बता सकते हैं।

Answer 1

मेरा मानना ​​है कि इसे संभालने का सबसे अच्छा तरीका लॉग फ़ाइलों को अनुप्रयोग के लिए सिर्फ एक अन्य उपयोगकर्ता इंटरफ़ेस के रूप में माना जाता है। तथ्य यह है कि जानकारी को पाठ फ़ाइलों में संग्रहीत किया जाता है, सामग्री को उपयोगकर्ता इंटरफ़ेस में नियमित स्क्रीन पर प्रदर्शित जानकारी से अलग नहीं बनाती है।

इस बारे में सोचें कि यदि आप एक नियमित उपयोगकर्ता इंटरफ़ेस में प्रदर्शित करना चाहते हैं तो आप उसी जानकारी की सुरक्षा कैसे करेंगे। आपको यह पहचानना होगा कि उपयोगकर्ता कौन था और फिर केवल उस जानकारी को उजागर करें जिसे यह उपयोगकर्ता देखने का हकदार था।

लॉग फ़ाइलों में जानकारी उसी तरह से व्यवहार किया जाना चाहिए। आपको पहले उत्तर देना चाहिए कि लॉग फ़ाइल को देखने के लिए किसे हकदार होना चाहिए और उन्हें कौन सी जानकारी देखने की अनुमति दी जानी चाहिए।

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

Answer 2

क्रेडिट कार्ड की जानकारी कभी भी लॉग इन नहीं होनी चाहिए।

आईडी नंबर (जैसे कि US में SSN या इज़राइल में Teudat Zehut #)।

नेटवर्क कंप्यूटर नाम, नेटवर्क साझा पथ।

Comments

PCI-DSS मानक कार्ड नंबर को किसी भी तरह, आकार या रूप में संग्रहीत करने से रोकता है।

— तैंगुरेना

@ तंगुरेना सच नहीं है, वे भंडारण की अनुमति देते हैं लेकिन इसके लिए आवश्यक है कि इसे ठीक से संरक्षित किया जाए। (PCI-DSS आवश्यकताएँ और सुरक्षा आकलन V2.0 अक्टूबर 2010, आवश्यकता 3)

— न्यूटपियन

Answer 3

स्वास्थ्य बीमा पोर्टेबिलिटी और जवाबदेही अधिनियम 1996 (HIPAA) द्वारा कवर की गई व्यक्तिगत रूप से पहचान योग्य स्वास्थ्य जानकारी। यह लेख निम्नलिखित उदाहरणों को सूचीबद्ध करता है:

• स्वास्थ्य देखभाल के दावे या स्वास्थ्य देखभाल संबंधी जानकारी, जैसे चिकित्सक के दौरे और चिकित्सकों और अन्य प्रदाता कर्मचारियों द्वारा किए गए नोटों का प्रलेखन;
• स्वास्थ्य देखभाल भुगतान और प्रेषण सलाह;
• स्वास्थ्य देखभाल लाभों का समन्वय;
• स्वास्थ्य देखभाल का दावा स्थिति;
• स्वास्थ्य योजना में नामांकन और विघटन;
• स्वास्थ्य योजना के लिए पात्रता;
• स्वास्थ्य योजना प्रीमियम भुगतान;
• रेफरल प्रमाणपत्र और प्राधिकरण;
• चोट की पहली रिपोर्ट;
• स्वास्थ्य दावा संलग्नक।

Answer 4

यदि सुरक्षा एक चिंता है, तो लॉग फ़ाइल को एन्क्रिप्ट करें

Answer 5

मेरे सर के ऊपर से चला गया....

क्रेडिट कार्ड की जानकारी लॉग में नहीं होनी चाहिए। SSN (या SIN) डेटा लॉग में नहीं होना चाहिए।

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

Answer 6

हाँ लेकिन।

कुछ मुद्दों को डीबग करने के लिए आपको वास्तविक डेटा की आवश्यकता होती है।

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

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

यदि डेटा महत्वपूर्ण है, तो आपको इस डेटा की अखंडता, सुसंगतता और सुरक्षा की रक्षा करने वाले सिस्टम स्थापित करने में कीमत चुकानी होगी।

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

Comments

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

— डेविड थॉर्नले

Answer 7

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

लॉग संदेश सुस्त रखें :)