2009-04-03 14 views
9

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

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

उत्तर

6

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

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

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

संपादित करें: ओह रोबोफॉर्म में एसएसएल पर ऑनलाइन पासवर्ड सिंक सेवा भी है। तो आप सिंक्रनाइज़ेशन के माध्यम से लोगों को पासवर्ड पुनर्प्राप्त कर सकते हैं। एक बार जब आप इसका इस्तेमाल करते हैं तो यह बहुत अच्छा होता है।

5

आपको रूट सर्वर को किसी भी सर्वर, उत्पादन या अन्यथा हाथ से नहीं सौंपना चाहिए (या उपयोग नहीं करना चाहिए)। आपको पासवर्ड साझा नहीं करना चाहिए।

लोगों को अपने स्वयं के उपयोगकर्ता आईडी के साथ स्वयं (प्रमाणीकरण) के रूप में लॉग इन करना चाहिए; यह तस्वीर का एक आधा है।

जब उचित रूप से लॉग इन किया जाता है तो उन्हें अधिकार के रूप में अधिकार (चित्र का प्राधिकरण पक्ष) दिया जाना चाहिए। आप सामान्य ओएस प्रयोजनों के लिए sudo जैसी चीजों का उपयोग कर सकते हैं, और डेटाबेस के अंदर अधिकार तंत्र आदि

ये दो अलग-अलग मुद्दे हैं। धाराओं को पार मत करो!

1

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

लिफाफा खोलने वाले किसी भी व्यक्ति को पासवर्ड बदलने और नए पासवर्ड को नए मुहरबंद लिफाफे में रखना आवश्यक था। लिफाफा अक्सर खोला नहीं गया था।

यह प्रणाली शायद वास्तव में खराब पेशेवर अभ्यास है, लेकिन एक छोटी सी दुकान में जहां सभी को सभी जानते थे, यह अच्छी तरह से काम करता था।

0

आप पासवर्ड साझा करने के लिए anypasswordpro ​​जैसे प्रोग्राम का उपयोग कर सकते हैं। यह एन्क्रिप्टेड है और इसमें पहुंच के स्तर हैं :)

0

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

एक उपाय जो मैंने छोटे समूहों के साथ उपयोगी पाया है, एक obfuscation प्रोटोकॉल स्थापित करना है।

उदाहरण के लिए, सभी पासवर्ड भेजी या ध्वनि मेल, ईमेल, IM, या कागज के माध्यम से संग्रहीत 1 एक यादृच्छिक चरित्र या शब्द प्रत्येक पासवर्ड चरित्र 3 के बीच में रख दिया गया है) ने अपने पात्रों के आदेश वापस ले 2)) बैठती उच्चारण पासवर्ड अक्षर।

पासवर्ड:: VMaccp @ SS1

Obfuscated:

उदाहरण के लिए

से कम एक 2 तों df तों 23 एसडी पेशाब fd देख DFS देख fxz ay df ईएम एसडी VEE

कुंजी स्थापित करने के लिए है किसी प्रकार का एन्कोडिंग जो प्रोटोकॉल को जानने के बिना किसी को समझने के लिए लगभग असंभव है, जिसे याद रखना आसान है।

ध्यान रखें कि यह छोटे समूहों के लिए जीवन-या-मृत्यु सुरक्षा के बिना है। स्पष्ट रूप से बड़े समूहों या अत्यधिक संवेदनशील वित्तीय डेटा की रक्षा करने वाले लोगों के लिए अधिक बोझिल उपायों के लिए उपयुक्त हैं।

1

एक प्रोटोटाइप & आर & डी प्रयोगशाला, जहां मैं पूर्व में काम किया, वहाँ थे 'मानक' प्रयोगशाला जड़, शान्ति की व्यवस्थापकीय पहुंच, स्विच, आदि इन सरल, आसान याद करने के लिए, और साथ मौखिक रूप से साझा कर रहे हैं जैसी चीजों के लिए पासवर्ड में जो भी उन्हें चाहिए। आम तौर पर, यदि आप शारीरिक रूप से प्रयोगशाला में शामिल हो सकते हैं, तो आप इन पासवर्डों के लिए अधिकृत थे।

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

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

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

विभिन्न प्रकार के सिस्टम और प्रयोगशालाओं के लिए विभिन्न मानक। यह उचित है। मुझे लगता है कि जब पासवर्ड को शार्ड करने की आवश्यकता होती है, तो यह सही होता है कि पासवर्ड सरल, छोटा और मौखिक रूप से संवाद किया जाता है (या तो व्यक्तिगत रूप से या फ़ोन पर)। मुझे लगता है कि एकमात्र पासवर्ड जिसे कभी साझा नहीं किया जाना चाहिए वह मेरे व्यक्तिगत खाते में से एक है। किसी भी रूट/एडमिन/टूल विशिष्ट पासवर्ड का कम से कम एक अन्य सिर में बैक अप लिया जाना चाहिए ... अगर किसी तरीके से दर्ज नहीं किया गया है।

संबंधित मुद्दे