केंद्रीय स्रोत भंडार को कहां रखा जाए?


10

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

जवाबों:


13

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


1
क्या आप अपना तर्क समझा सकते हैं कि आप यह क्यों मानते हैं कि एक वीपीएन एसएसएल / टीएलएस आधारित सर्वर से अधिक सुरक्षित है जो दोनों को "सार्वजनिक सामना" करने की आवश्यकता है? वीपीएन एसएसएल / टीएलएस के लिए पारिवारिक एन्क्रिप्शन का उपयोग करते हैं। तो अगर आप वीपीएन हैक कर सकते हैं तो आपको सब कुछ मिलेगा।
मैट

1
@ मैट यदि किसी सार्वजनिक खंड पर उसकी रिपॉजिटरी होने का कोई कारण नहीं है, तो इसे वहां क्यों रखा जाए? इसके अलावा, एक वीपीएन अपने डेवलपर्स के लिए अन्य लाभ हो सकता है। आप यह भी ध्यान देंगे कि मैंने कभी भी यह नहीं कहा कि "वीपीएन एसएसएल / टीएलएस से अधिक सुरक्षित है", इसलिए मेरे मुंह में शब्द न डालें :)
phoebus

1
सच। मुझे लगा कि myr स्टेटमेंट में सुरक्षा निहित है। शायद आप इसे अर्हता प्राप्त कर सकते हैं: "यदि आप इसे सार्वजनिक-सामना करने वाले सर्वर पर होने के बारे में चिंतित हैं"
मैट

मेरी राय में, वीपीएन के पीछे निजी सर्वर / सेवाएं स्तरित दृष्टिकोण का हिस्सा है। यह कॉन्फ़िगरेशन त्रुटियों से बचाने में मदद करता है जो स्रोत को जनता के सामने ला सकता है। आवश्यकता नहीं है, लेकिन स्मार्ट।
Martijn Heemels

4

मुझे यकीन नहीं है कि लोग क्यों सोच रहे हैं कि वीपीएन दृष्टिकोण सबसे अच्छा है। यह जरूरी नहीं कि कोई और अधिक सुरक्षित हो और केवल एक ही लाभ प्रदान करता हो, जिसके बारे में मैं सोच सकता हूं।

उदाहरण के लिए PPTP को आदर्श सुरक्षा से कमतर माना जाता है, हालांकि मेरा मानना ​​है कि यह पहली बार पेश किए जाने के बाद से कुछ हद तक सुधरा है ... इसलिए सावधान रहें कि आप कौन सा वीपीएन समाधान इस्तेमाल करते हैं। मैं OpenVPN या IPSEC के साथ जाऊँगा।

हालाँकि, आप वीपीएन के बिना एसएसएल / टीएलएस की सुविधा को नहीं हरा सकते हैं (आगे पढ़ें)। और इसे और अधिक सुरक्षित बनाने के लिए आप इसे केवल प्रमाण पत्र बना सकते हैं।

हालाँकि, यदि आपको लगता है कि आप स्रोत नियंत्रण के अलावा अन्य सेवाओं की पेशकश कर सकते हैं, तो एक वीपीएन समाधान पर विचार करें क्योंकि आप इसके ऊपर अन्य सेवाओं को टनल करेंगे।

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

मैं यहां व्यक्तिगत अनुभव से बोल सकता हूं क्योंकि मैं एक डेवलपर हूं और ऐसा करने के लिए चूतड़ में एक वास्तविक दर्द था !!! आदर्श रूप से, दोनों विकल्प पसंद किए जाते हैं।

इसलिए यदि आप वेब आदि को ब्राउज़ करने जा रहे हैं तो यह समाचारों को पढ़ने के बजाय धीमा कर सकता है। लेकिन कम से कम आपको ईमेल तक सुरक्षित पहुंच मिलती है। तो विचार करें कि आप इसे पहले कैसे उपयोग कर रहे हैं ... यदि मैं आप होता तो मैं दोनों को लागू करने पर विचार करता।


3

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

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


3

उद्योग मानक शायद इस बात पर निर्भर करता है कि आपका (या आपके ग्राहकों का) उद्योग :-) है

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

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


2

दूसरों की तरह, मैं एक वीपीएन पसंद करता हूं। एक विकल्प एसएसएच सुरंग होगा, जिसे मैं व्यावहारिक रूप से मानता हूं, वैसे भी एक तरह का वीपीएन है।


0

इसे केवल आंतरिक करें और दूरस्थ-उपयोगकर्ता वीपीएन समाधान लागू करें। / दोहा- डुप्लीकेट।


0

यदि आप कहीं से भी पहुंच चाहते हैं, तो आपको सार्वजनिक सामना करने वाले सर्वर की आवश्यकता है - यह बहुत स्पष्ट है।

उस सर्वर पर, आप जितना संभव हो उतना कम उजागर करना चाहते हैं , अधिमानतः केवल मर्क्यूरियल / तोड़फोड़ और कुछ नहीं। यह आपकी कंपनी के बाकी हिस्सों में स्रोत नियंत्रण से फैलने से सुरक्षा में उल्लंघन को रोकने के लिए है। उस कारण से, मैं मैट से सहमत हूँ जब वह कहता है कि एक वीपीएन खतरनाक हो सकता है: यह जरूरत से ज्यादा व्यापक पहुंच देता है।

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

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

HTTPS के लिए, प्रमाणीकरण फ्रंट-एंड वेबसर्वर द्वारा किया जाता है । इसका मतलब है कि यदि आप चाहें तो क्लाइंट-साइट प्रमाणपत्र की आवश्यकता हो सकती है और इसलिए SSH सार्वजनिक कुंजी प्रमाणीकरण की तरह सुरक्षा प्राप्त करें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.