सवाल सिस्टम प्रशासक की एक टीम पासवर्ड को सुरक्षित रूप से कैसे साझा करती है?


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


81
2018-06-02 23:50


मूल


संबंधित देखें serverfault.com/questions/3696/...  serverfault.com/questions/2186/...  serverfault.com/questions/10285/...  serverfault.com/questions/21374/... - Zoredache
बीटीडब्ल्यू सैकड़ों बहुत परेशान संख्या है। क्या होता है जब टीम के सदस्यों में से एक को निकाल दिया जाता है? सैकड़ों पासवर्ड अपडेट करना दर्दनाक होगा। - Zoredache
"सैकड़ों एक बहुत परेशान संख्या" चीज पर सेकेंड किया गया। मुझे लगता है कि आपको शायद बैक अप लेने और पुनर्विचार करने की आवश्यकता है कि आप वर्तमान में जो कुछ हासिल कर चुके हैं उस पर प्लास्टर चिपकाने के बजाय आप पहली सुरक्षा चीज़ को कैसे प्रबंधित कर रहे हैं। - Maximus Minimus
कुछ हद तक संबंधित: serverfault.com/questions/119892  विशेष रूप से यह उत्तर: serverfault.com/questions/119892/company-password-management/... - Nathan Hartley


जवाब:


मैं शायद कॉर्पोरेट इंट्रानेट पर होस्ट किए गए एक कस्टम वेब-आधारित समाधान लिखूंगा। (पर एक नज़र डालें http://lastpass.com प्रेरणा के लिए, या इसका उपयोग करने के लिए। पासवर्ड साझा करना इसकी विशेषताओं में से एक है, हालांकि यह आपके वॉल्यूम के लिए काम नहीं कर सकता है।)

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

मुद्दा यह है कि हम वास्तव में आपके परिदृश्य को नहीं जानते हैं। आप सैकड़ों मिशन-महत्वपूर्ण पासवर्ड क्यों साझा कर रहे हैं? क्या वे आपके बैकऑफिस इंट्रानेट, वीपीएन के लिए हैं, या वे ग्राहक पासवर्ड हैं जिन्हें आप किसी कारण से सादे पाठ में रखते हैं? क्या वे सभी लोग हैं जिन्हें आपको उसी इंस्टॉलेशन में साझा करने की आवश्यकता है? क्या एक एन्क्रिप्टेड सीडी या सुरक्षित रूप से संग्रहीत मुद्रित तालिका की तरह भौतिक रूपान्तरण वास्तव में काम करेगा? या दुनिया भर में फैले आपके sysadmins हैं, उन्हें साझा करने के इलेक्ट्रॉनिक साधन बनाते हैं केवल उपाय?


14
2018-06-02 23:58



आईएमओ अपनी खुद की सुरक्षा / एन्क्रिप्शन प्रणाली का निर्माण लगभग किसी समस्या का सही दृष्टिकोण नहीं है। - Zoredache
@Zoredache, यह बकवास का एक भार है। हालांकि, मुझे लगता है कि पासवर्ड होस्ट करने के लिए वेब-आधारित समाधान बेवकूफ है - लेकिन उसने मैसनफोर्ड इंट्रानेट कहा था। हालांकि अभी भी जोखिम भरा है। अन्य सभी नेटवर्क समाधान के लिए वही। - d-_-b
@ ज़ोरशेड, ओपी एक कस्टम एन्क्रिप्शन सिस्टम नहीं बना रहा है, ऐसा लगता है कि उसकी जरूरत सिर्फ एक सुरक्षित डेटाबेस है। @sims मुझे एक अच्छी तरह से डिज़ाइन किए गए वेब-आधारित समाधान के साथ कुछ भी गलत नहीं लगता है। अप-वोट किए गए उत्तर से पता चलता है कि (वेब-आधारित! = Http; वेब-आधारित = ऑनलाइन संग्रहीत)। माना जाता है कि, एक बार जब मैं इस प्रश्न पर दूसरी बार पढ़ता हूं, तो मैं मानता हूं कि पासवर्ड के टन साझा करने का मूल मॉडल अनावश्यक होने की संभावना है, और यह कि एक बेहतर समाधान तक पहुंचा जा सकता है। लेकिन ओपी ने मुझे यह निर्णय लेने के लिए पर्याप्त जानकारी नहीं दी है ... - msanford
> @Zoredache, यह बकवास का एक भार है। <उम, सिम्स, आप बल्ले से बाहर सबसे अधिक एन्क्रिप्शन लोगों के चेहरे में काफी उड़ान भर रहे हैं। एन्क्रिप्शन डिजाइन करना मुश्किल है, इसे सार्थक एन्क्रिप्शन करना अभी भी कठिन है। schneier.com/essay-037.html  कभी-कभी कम बुराई - जिसे आप जानते हैं - बेहतर विकल्प है, जब आप जो बुराई से नहीं जानते हैं (यानी एक डिज़ाइन जो अनचाहे, गैर-सहकर्मी-समीक्षा की जाती है, में बग हो सकती है, सुरक्षा छेद हो सकती है आदि। ) - Avery Payne
@Avery - एक क्रिप्टोग्राफिक प्रणाली को डिजाइन करना कठिन है और विशेषज्ञों को छोड़ दिया जाना चाहिए, हां। कोशिश की गई और परीक्षण किए गए टूल का उपयोग करना, जैसे साझा टेक्स्ट फ़ाइल पर जीपीजी, या Keepass (जो एईएस और एसएचए -256 के .NET कार्यान्वयन का उपयोग करता है) आपके सिस्टम को डिज़ाइन नहीं कर रहा है। - mfinni


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

जब पासवर्ड की लिखित प्रतिलिपि रखना जरूरी होता है, तो इसे एक लिफाफे में सील करें और मुहर में बैठे हों। पासवर्ड का उपयोग करते समय पासवर्ड बदलें। जब पासवर्ड बदल जाता है तो यह एक नया लिफाफा सील कर देता है।

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


38
2018-06-03 00:04



संभावित विशेषाधिकार वृद्धि के साथ प्रशासकों के लिए अनधिकृत उपयोगकर्ता खातों के लिए +1, * निक्स सर्वर पर मैं एसएसडीडी के लिए केवल डीएसए / आरएसए प्रमाणीकरण का उपयोग करके गठबंधन करता हूं। यदि आप लिनक्स के तहत ग्राफिकल टूल्स के साथ सामान कर रहे हैं तो आप एक अनुकूलित पॉलिसीकिट कॉन्फ़िगरेशन का भी उपयोग कर सकते हैं। - Aaron Tate
इस। जब वे साझा क्रेडेंशियल्स का उपयोग कर रहे हैं तो उपयोगकर्ताओं के लिए पहुंच रद्द करना एक पूर्ण दुःस्वप्न है। जहां भी संभव हो, उपयोगकर्ताओं के अद्वितीय खाते के माध्यम से प्रतिनिधि का उपयोग करें। ऐसी कुछ स्थितियां होती हैं जहां एक सामान्य पासवर्ड अपरिहार्य है, लेकिन साझा पासवर्ड के 'सैकड़ों' महत्वपूर्ण डिजाइन दोष को चिल्लाते हैं। - Chris Thorpe
मैं आम तौर पर पासवर्ड साझा नहीं करने के साथ सहमत हूं, लेकिन ऐसी कई स्थितियां हैं जहां एक आवश्यक लॉगिन, विक्रेता साइट्स के साथ नेटवर्क डिवाइस हैं जहां सभी सिसडमिन ऑर्डर करने के लिए एक ही लॉगिन का उपयोग करते हैं, और एसक्यूएल उपयोगकर्ता या स्थानीय व्यवस्थापक पासवर्ड जहां ज़रूरी। यही कारण है कि मुझे लगता है कि केपस इसके लिए सबसे अच्छा है: यह कई प्लेटफार्मों पर काम करता है, सुरक्षा का एक अच्छा सौदा करने की अनुमति देता है, और आसानी से सैकड़ों पासवर्ड व्यवस्थित करता है। - Paul Kroon
हमारे पास इस पर एक भिन्नता है, जहां हमारे पास रूट पासवर्ड लिखा गया है लेकिन एक सुरक्षित में बंद कर दिया गया है कि केवल सिस्टम टीम के पास खोलने की कुंजी है। हमारे मूल पासवर्ड स्वयं 16 वर्ण लंबे होते हैं और याद रखने के लिए असंभव होने के लिए इस तरह से उत्पन्न होते हैं। हां, वहां कुछ असुरक्षा है, लेकिन अगर कोई सुरक्षित में टूट जाता है, तो मुझे संदेह है कि हमें बड़ी समस्याएं हैं। - Frenchie
यहां हमारी टीम के लिए वास्तविक उपयोग-केस परिदृश्य है: वेब-आधारित अनुप्रयोगों के लिए पासवर्ड साझा करना जहां वे एक खाते के लिए एकाधिक लॉगिन का समर्थन नहीं करते हैं। इसलिए यदि टीम में एक से अधिक व्यक्ति को उस खाते तक पहुंचने में सक्षम होना चाहिए, तो उस खाते के लिए पासवर्ड साझा करने का एक तरीका होना चाहिए। - Jordan Reiter


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


10
2018-06-02 23:59



कीपस कई प्लेटफार्मों का समर्थन करता प्रतीत होता है, मेरी आंखों में एक बड़ी जीत (मैं एक मिश्रित मंच वातावरण में काम करता हूं)। "ऑटो-टाइप" सुविधा भी उपयोगी लगती है। - Avery Payne
नेटवर्क पर पासवर्ड रखने के लिए बेवकूफ विचार। - d-_-b
@ सिम्स - तो आप उन्हें कैसे साझा करते हैं? कीपस स्टोर के लिए एन्क्रिप्टेड फ़ाइल का उपयोग करता है। यह एक यूनिक्स सर्वर पर एक जीपीजी-एन्क्रिप्टेड टेक्स्ट फ़ाइल का एक और अधिक उपयोग करने योग्य संस्करण है जिसे हर किसी के पास पहुंच है। - mfinni
@ सिम्स - मैं आम तौर पर आपके साथ सहमत हूं, लेकिन यह सुरक्षा बनाम उत्पादकता की स्थिति बनता है। मैं इस तरह किसी सर्वर में रूट का पासवर्ड नहीं रखना चाहता, लेकिन लेयर 2 स्विच का एडमिन पासवर्ड जिसमें केवल एक ही लॉगिन है, इसके लिए एक अच्छा उम्मीदवार है। एक बिंदु है जब सुरक्षा उल्लंघन के बाद इसे साफ करने के लिए चीजों को और अधिक सुरक्षित तरीके से करने में अधिक काम होता है। इसके अलावा, सभी एन्क्रिप्शन के शीर्ष पर, आपके पास फ़ाइल पर एडी / एनटीएफएस सुरक्षा होगी, और एक यादृच्छिक स्थान में फ़ाइल (जिसे कुछ भी नाम दिया जा सकता है) डालकर थोड़ा अस्पष्टता होगी। - Paul Kroon
मैं एक विंडोज मशीन के बारे में सोच नहीं रहा था। लेकिन हाँ, अगर आपके पास उस स्विच के लिए केवल एक उपयोगकर्ता हो सकता है, तो मुझे लगता है कि यह समझ में आता है। अन्यथा बिल कहता है, साझा पासवर्ड के लिए नहीं कहें, जो कुंजी के बारे में भी मेरा मुद्दा था। - d-_-b


कुछ लोगों के बीच सैकड़ों पासवर्ड साझा करने के लिए सर्वोत्तम प्रथाएं क्या हैं?

आसान, यह दो स्वादों में आता है:

  1. आप सादा और सरल नहीं करते हैं। यदि आप ऐसा करना चुनते हैं, तो आप बाहरी विश्वसनीय प्राधिकारी को पासवर्ड प्रमाणीकरण स्थगित कर देते हैं और वहां से प्रमाणीकरण को नियंत्रित करते हैं।

  2. आप करते हैं, लेकिन ऐसा करने में, आपके पास बाहरी एक्सेस नियंत्रण होते हैं जिनमें पासवर्ड या सुरक्षा टोकन होते हैं जो आपके द्वारा उपयोग की जाने वाली प्रणाली के अंदर दर्ज नहीं होते हैं (यानी पासवर्ड का रिकॉर्ड किसी अन्य पासवर्ड से सुरक्षित होता है जिसमें सीमित उपलब्धता होती है)। इसके साथ कई समस्याएं हैं।

ये पासवर्ड मिशन महत्वपूर्ण डेटा की रक्षा करते हैं, और कभी भी एक छोटी टीम से परे दिखाई नहीं दे सकते हैं।

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

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

  • सक्रिय निर्देशिका।  शायद समूह के सबसे प्रसिद्ध, आपको केर्बेरोज को प्रमाणीकरण विकल्प के रूप में देता है, और मूल डीएस के लिए एलडीएपी प्रदान करता है।
  • सांबा / विनबाइंड।  इसे "एक्टिव डायरेक्टरी लाइट" के रूप में सोचें, आपको एडी की सभी सुविधाएं नहीं मिलती हैं बल्कि एनटी 4 (लैनमैन हैश सोचें) के आधार पर एक पुराना मॉडल नहीं मिलता है। यह सांबा 4 के एडी एकीकरण के साथ सप्लाई किया जाएगा और शायद "दूर जाना" होगा।
  • नोवेल निर्देशिका सेवाएं।  मुझे इसके बारे में पर्याप्त जानकारी नहीं है, लेकिन मुझे पता है कि यह अभी भी मौजूद है। बहुत से सरकारी संस्थाएं अभी भी एनडीएस चलाती हैं, इसलिए यदि आप उस "सेक्टर" में काम कर रहे हैं तो यह आपके लिए ब्याज होगा। नोवेल ने हाल ही में लिनक्स सेवा के रूप में चलाने के लिए एनडीएस को पोर्ट किया, लेकिन मुझे नहीं पता कि यह अभी भी एक सक्रिय उत्पाद है (लगभग 2005)।
  • एलडीएपी + केर्बेरोस।  यह मूल रूप से "घर उगाया" सक्रिय निर्देशिका है, सभी "अच्छी सुविधाओं" से कम है। हालांकि, वे एक स्थिर, परिपक्व कोड बेस के साथ भी ज्ञात घटक हैं, इसलिए इन सेवाओं का एकीकरण आमतौर पर चीजों को काम करने के लिए आवश्यक "अनुकूलन" की सीमा है।
  • एसएसएच कुंजी + (यहां सिस्टम प्रशासन कार्यक्रम डालें, शायद कठपुतली)।केवल उपयोगी जहां आपके पास बोर्ड में एसएसएच है और सभी उपकरणों को इस तरह से एक्सेस किया जाता है। कुंजी को आवश्यकतानुसार सौंप दिया जा सकता है और रद्द कर दिया जा सकता है, और एसएसएच कुंजी अनुदान पहुंच के रूप में पासवर्ड "अप्रासंगिक" बन जाते हैं। कठपुतली जैसी प्रणाली का उपयोग करने से आप एसएसएच कुंजी जोड़ने / रद्द करने के लिए आदेशों को जारी करके सैकड़ों मशीनों को अपडेट कर सकते हैं।
  • उपरोक्त के कुछ संयोजन।

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


5
2018-06-03 20:37





मुझे पता है कि यह एक पुराना सवाल है लेकिन मैं हाल ही में एक ओपनसोर्स वेब आधारित समाधान में आया था कॉर्पोरेट वॉल्ट यह कुछ के लिए दिलचस्प हो सकता है। मुझे अभी तक इसे आजमाने का मौका नहीं मिला है।


2
2017-12-16 00:31





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


1
2018-06-03 02:57





कुछ बातें:

  • जैसा कि अन्य ने कहा है, यह एक बुरा विचार है। एक एलडीएपी, आदि का प्रयोग करें
  • यदि आप किसी भी कारण से ऐसा करने के लिए प्रतिबद्ध हैं, कम से कम पासवर्ड को समेकित करें। 100 अप्रबंधित पासवर्ड का अर्थ है कि आप पासवर्ड अपडेट नहीं कर रहे हैं।
  • उन्हें कागज पर रखें। आवश्यकता है कि कर्मचारी एक अलग रंग की स्याही में पेपर पर हस्ताक्षर करें ताकि यह निर्धारित किया जा सके कि शीट की प्रतिलिपि बनाई गई है या नहीं।
  • यदि आप यूनिक्स पर हैं, तो एक बार पासवर्ड उत्पन्न करने के लिए S / KEY का उपयोग करें। स्टोर कहीं कहीं सुरक्षित है।

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

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

इस तरह की प्रक्रिया गर्दन में दर्द है, लेकिन लोगों के लिए अधिक साधु प्रथाओं को अपनाने के लिए एक प्रोत्साहन के रूप में कार्य करेगा। यदि आप जो कुछ मैंने वर्णन किया है, उसके जैसा कुछ नहीं करते हैं, तो पासवर्ड को लॉक करने की गति से गुज़रना न करें, क्योंकि आप किसी भी तरह से किसी भी तरह से उल्लंघन करेंगे।


1
2018-06-03 15:06