दूरस्थ लिनक्स व्यवस्थापक सलाहकार - सर्वश्रेष्ठ अभ्यास [बंद]


19

हम भारत में अपने लिनक्स प्रशासक के रूप में एक सलाहकार को उलझा रहे हैं। हम उसे अच्छी तरह से नहीं जानते हैं और उसे अपना काम करने के लिए अपने सभी सर्वरों के लिए रूट एक्सेस की आवश्यकता होती है (सुरक्षा ऑडिट सहित)।

ऐसे काम के लिए एक दूरस्थ सलाहकार को सक्षम करने के लिए सबसे अच्छा अभ्यास क्या है कि हम किसी भी घातक गतिविधियों के खिलाफ सुरक्षित हैं?

अग्रिम में धन्यवाद।


66
यदि आप किसी पर भरोसा नहीं करते हैं, तो उन्हें अपने सर्वर तक पहुंच न दें। अवधि। किसी पर भरोसा करें जिस पर आप भरोसा कर सकें।
EEAA

6
यह सोचकर मदद नहीं कर सकता कि क्या यह उच्च-अप द्वारा अनिवार्य कार्रवाई है और आप इसके खिलाफ गोला-बारूद / अच्छे तर्क की तलाश कर रहे हैं?
मैट

5
LOL ... क्या यह एक अच्छा विचार है?
ewwhite

5
यदि आप किसी को अपने सर्वर पर रूट एक्सेस दे रहे हैं, तो आपके पास मशीन पर व्यवस्थित गतिविधियों से खुद को व्यवस्थित रूप से सुरक्षित रखने के लिए बिल्कुल कोई रास्ता नहीं है।
क्रेग

3
आशा है कि आपके पास अच्छे ऑफ़लाइन बैकअप हैं
कैफीनअविकास 20

जवाबों:


55

नहीं है । इसके अलावा, आप के ज्यादा खतरे के रूप में कर रहे हैं अयोग्यता के रूप में द्वेष मैं क्या विशिष्ट तरीका कंपनियों को संभालने के देखा है से।

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

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

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

अब जब मैंने "अयोग्यता" का हिस्सा संभाला है,

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

तो, एक स्थानीय पर विचार करें। यदि नहीं, तो किसी ऐसे व्यक्ति पर विचार करें जिसे आपने खुद को वीटो किया है और सीधे काम पर रखा है


35
मैं एक कठिन समय के लिए एक आदमी को विशेषाधिकार प्राप्त का उपयोग कर रहा हूँ, मेरे पास से एक दरवाजा अकेले किसी को 12 समय क्षेत्र दूर। मेरा दिमाग चकराता है कि कोई इसे विकल्प भी समझेगा।
EEAA

7
यदि आप एक बॉडी शॉप से ​​गुजर रहे हैं, तो आप यह भी नहीं जान पाएंगे कि कौन वास्तव में उन रूट क्रेडेंशियल्स के कब्जे में है, आपको इस बात की कोई गारंटी नहीं है कि आपके सिस्टम पर काम करने वाला व्यक्ति आज वही व्यक्ति है जो कल उन पर काम करेगा, आपको इस बात की कोई गारंटी नहीं है कि ये लोग शाब्दिक रूप से आपके रूट-स्तरीय पासवर्ड (ईमेलों) को स्पष्ट रूप से एक-दूसरे को ईमेल करने वाले हैं (मैंने इसे कई बार देखा है), और इसी तरह।
क्रेग

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

@MontyHarder क्या आपको (कुछ) उपयोगकर्ताओं को sudoअपने आप को जड़ तक उभारने का अधिकार होना चाहिए ? यदि नहीं, तो क्या आप suबिना रूट किए, और वितरण, एक रूट पासवर्ड का उपयोग करने के लिए अपने सर्वोत्तम अभ्यासों की रूपरेखा तैयार कर सकते हैं?
MadHatter

2
@MontyHarder जो बहुत मायने रखता है, यह सिर्फ वही नहीं है जो आपने पहली बार कहा था; sudoऔर suदो पूरी तरह से अलग चीजें हैं। स्पष्टीकरण देने के लिए धन्यवाद।
MadHatter

33

जैसा कि उल्लेख किया गया है, ऐसा न करें।

एकमात्र तरीका जो आप अपनी रक्षा करने में सक्षम होंगे वह कुछ इस तरह से है:

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

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

जैसा कि मैंने सिफारिश की है, हालांकि, आप एक ज्ञात, विश्वसनीय व्यक्ति को काम पर रखने से बहुत बेहतर हैं।


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

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

खैर, विश्वास अर्जित करना होगा। :)
भगोड़ा

10

ऐसे काम के लिए एक दूरस्थ सलाहकार को सक्षम करने के लिए सबसे अच्छा अभ्यास क्या है कि हम किसी भी घातक गतिविधियों के खिलाफ सुरक्षित हैं?

कानूनी दृष्टिकोण से: पहले से परिश्रम और अनुबंध के उल्लंघन के लिए सख्त दंड।

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

फिर गाजर लागू करें : उचित मूल्य का भुगतान करें, आकर्षक काम, अद्भुत सहयोगियों, अच्छी काम करने की स्थिति और लाभ आदि की पेशकश करें ( यदि आप मूंगफली का भुगतान करते हैं तो आपको बंदर मिलते हैं। )

और छड़ी : अपने रोजगार / सेवा अनुबंध की शर्तों का उल्लंघन करें और हम आपके वकीलों को आप पर बिमार कर देंगे और आपको दिवालिया कर देंगे!

दुर्भाग्य से उपरोक्त दोनों सीमा और समय सीमा पार करते समय और अधिक कठिन हो जाते हैं।

एक बार जब आप किसी को काम पर रखने का फैसला करते हैं:

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

यह प्रश्न बताता है कि मैं आमतौर पर अपने ग्राहकों से मेरे लिए रिमोट एक्सेस स्थापित करने के लिए क्या कहता हूं, जो आपके लिए भी एक शुरुआती बिंदु हो सकता है।


3
"यदि आप मूंगफली का भुगतान करते हैं तो आपको बंदर मिलते हैं" या हाथी। हालांकि यह सोचना आता है, मुझे यकीन नहीं है कि यह बंदरों से बेहतर या बदतर है।
एक CVn

बस जोड़ने के लिए, आपके उत्तर के "छड़ी" भाग को लागू करना कठिन हो सकता है यदि दूसरा पक्ष किसी दूसरे देश में है। आपको पहले किसी जानकार / अनुभवी वकील से सलाह लेनी चाहिए कि कुछ गलत होने की क्या संभावनाएँ हैं।
user121391

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

7

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

एक वर्चुअलाइजेशन हाइपरवाइजर (VMware, Xctorver, Hyper-V, आदि) के रूप में अपने लिनक्स उदाहरणों को होस्ट करें।

दूरस्थ व्यवस्थापक को हाइपरवाइज़र के लिए प्रशासनिक पहुँच न दें। दूरस्थ व्यवस्थापक को केवल VM की स्वयं की रूट एक्सेस प्राप्त होगी।

एक हाइपरविजर आधारित बैकअप सिस्टम को लागू करें (Unitrends, Veeam, vSphere Data Protection, etc.)

प्रत्येक लिनक्स वीएम के प्रति दिन कम से कम एक स्नैपशॉट रखें, जब तक आप आवश्यक महसूस करते हैं तब तक वापस जा रहे हैं।

दूरस्थ व्यवस्थापक को बैकअप रिपॉजिटरी तक लिखने की पहुँच न दें।

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

यह एक हाइपरवाइजर साइड-चैनल हमले के खिलाफ सबूत नहीं होगा, जो संभावित रूप से एक वीएम के भीतर से घुड़सवार हो सकता है जो हमलावर के पास रूट एक्सेस है।

यदि आपके बैकअप समय में बहुत पीछे नहीं जाते हैं, तो यह आपकी रक्षा नहीं करेगा।

आपको पूरी तरह से भरोसा करने की आवश्यकता है कि आपके हाइपरवाइज़र और बैकअप इन्फ्रास्ट्रक्चर पर किसका नियंत्रण है।

यदि आप क्लाउड (AWS, Azure, आदि) में ऐसा कर रहे हैं, तो कार्यान्वयन विवरण अलग-अलग होंगे, लेकिन सामान्य अवधारणा समान होगी।

संक्षेप में, उन पार्टियों के बीच जिम्मेदारियों को विभाजित करें जो केवल एक दूसरे के साथ व्यापारिक साझेदार नहीं हैं, केवल उन लोगों के साथ जो आप पर भरोसा करते हैं।


1
जब तक आप वह सब कर चुके होते हैं, तब तक आप सिस्टम प्रशासक हो चुके होते हैं और आप रिमोट की कमी या पीएफवाई को काम पर रखते हैं।
क्रिग्गी

3
पूरी तरह से नहीं। आप केवल हाइपरवाइज़र और बैकअप का प्रशासन कर रहे हैं। जो, वास्तव में, कुछ भी नहीं है। लेकिन यह जरूरी नहीं कि एक ही कौशल या प्रशासनिक बोझ हो। संभावना यह है कि यदि आप वर्चुअलाइजेशन (हम कर रहे हैं) कर रहे हैं, कि आपके पास एक व्यक्ति या जो भी व्यक्ति VM के वैसे भी हो रहा है, का प्रभारी है।
क्रेग

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

@ user121391: मैं वास्तव में असहमत नहीं हो सकता, विशेष रूप से डेटा बहिष्कार मुद्दे के साथ। एक बार डेटा लेने के बाद, यह पूरी तरह से आपके नियंत्रण से बाहर है।
क्रेग

-1

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


3
मूल रूप से चल रहे अपाचे को कॉन्फ़िगर करने और पुनः आरंभ करने की अनुमति देना मूल रूप से रूट विशेषाधिकार दे रहा है। यह आसान है कि अपाचे प्रक्रिया द्वारा निष्पादित एक मनमाना बाइनरी हो, जैसे कि पाइप लॉग को। अपाचे को बेहतर तरीके से सेट करें ताकि यह गैर-रूट के रूप में चल सके और फिर भी विशेषाधिकार प्राप्त बंदरगाहों से बंधे रह सकें। मैंने अतीत में इस स्थिति में यही किया है।
एमवीजी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.