क्या सर्वर वातावरण चर में महत्वपूर्ण पासवर्ड संग्रहीत करना सुरक्षित है?


23

मेरे पास सर्वरों का एक समूह है, प्रत्येक विन्यास फाइल के साथ जो वर्तमान में संवेदनशील, मिशन-महत्वपूर्ण प्रणालियों (संदेश कतार, डेटा स्टोर और अन्य सेवाओं) के लिए सादे-पाठ पासवर्ड हैं।

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

क्या यह वास्तव में सादे-पाठ कॉन्फ़िगरेशन फ़ाइलों में पासवर्ड से बचने का सबसे अच्छा तरीका है, या कोई बेहतर तरीका है?


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

अच्छा विचार है, फ्रैंक। यदि आप क्रिप्टो का उपयोग करते हैं, तो आप किस प्रकार की प्रणाली का उपयोग करेंगे? RSA / SSH कुंजी, चाबी का गुच्छा उपकरण, या कुछ और के आधार पर कुछ? हम वर्तमान में Linux> 2.6 सिस्टम जैसे CentOS और Amazon का उपयोग करते हैं।
स्टीव एचएचएच

जवाबों:


11

यदि आप एक लिनक्स सिस्टम पर हैं, तो / proc / * / environ पर देखें और निर्णय लें कि पर्यावरण चर संवेदनशील जानकारी को संग्रहीत करने के लिए एक अच्छी जगह है या नहीं। / proc / स्वयं वर्तमान प्रक्रिया है:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

कभी ध्यान न दें कि पर्यावरण चर को सेट करने वाली चीज़ शायद कहीं फ़ाइल पढ़ रही है।

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

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



3
हां, कार्यक्रम चलाने वाले उपयोगकर्ता के स्वामित्व वाली मोड 0600 के साथ एक फ़ाइल उसी लोगों द्वारा सुलभ है जो कार्यक्रम के वातावरण तक पहुंच सकते हैं। लेकिन, जैसा कि मैंने उल्लेख किया है, पर्यावरण शायद एक फ़ाइल को पढ़कर कॉन्फ़िगर किया गया है, इसलिए वातावरण में डेटा की प्रतिलिपि बनाने से डेटा उपलब्ध होने वाले स्थानों की संख्या में वृद्धि हो रही है। और पर्यावरण, डिफ़ॉल्ट रूप से, बच्चे की प्रक्रियाओं के लिए दोहराया गया है। और बग या जानबूझकर डिजाइन निर्णयों के बारे में कई कार्यक्रमों के बाहरी साधनों को क्वेरी करने के लिए बाहरी साधन हैं (सोचें phpinfo ())। यदि कोई फ़ाइल किसी भी तरह से शामिल होगी, तो हमले की सतह क्यों बढ़ेगी?
डेनिसॉयर

1
आपके द्वारा दिए गए tr कमांड ने मेरे लिए काम नहीं किया - यह किया:cat /proc/self/environ | tr '\0' '\n'
0

मैं अपने फोन में हूँ इसलिए यह बताना मुश्किल है ... यह एक शून्य होना चाहिए; क्या आपने "ओ" अक्षर टाइप किया है?
dannysauer

8

अंत में, यदि आपके पास कोई डेटा है जिसे पढ़ने के साथ-साथ लिखा जाना भी आवश्यक है , तो आप पासवर्ड के साथ कुछ की रक्षा करने जा रहे हैं (या यदि आप वास्तव में पागल हैं, भौतिक हार्डवेयर स्मार्ट कार्ड और पिन के साथ), नहीं आपके पास एन्क्रिप्शन की कितनी परतें हैं।

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

यदि मैं वास्तव में एक मिशन-महत्वपूर्ण प्रणाली में कुछ जानकारी की रक्षा करना चाहता था तो मैं क्या करूँगा:

  1. पूर्ण डिस्क एन्क्रिप्शन का उपयोग करें, ताकि संपूर्ण स्थिर संग्रहण की सामग्री एन्क्रिप्ट की गई हो।

  2. मशीनों तक भौतिक पहुँच को प्रतिबंधित करें। एक सुरक्षित लॉकिंग तंत्र के साथ मशीन के चेसिस को लॉक करें और कुंजियों के लिए भौतिक पहुंच को नियंत्रित करें। पहुंच के लिए द्वारपाल होने के लिए मांसपेशी (सशस्त्र गार्ड)।

  3. डिवाइस के ऑपरेटिंग सिस्टम में बारीक दानेदार अनिवार्य अभिगम नियंत्रण (मैक) लागू करें। आप GNU / Linux पर SELinux जैसी किसी चीज़ से शुरुआत कर सकते हैं और इसे Enforcing पर सेट कर सकते हैं, और फिर उत्पादन सॉफ़्टवेयर की सटीक आवश्यकताओं के लिए नीति को दर्ज़ कर सकते हैं, उन खातों को बिल्कुल (और केवल) उन अनुमतियों की अनुमति देते हैं, जिनकी उन्हें उन फ़ाइलों की आवश्यकता होती है, जिनकी उन्हें आवश्यकता होती है।

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

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

यह पूरी सूची नहीं है, लेकिन विशेष रूप से बिंदु 4 शायद आपके लिए प्रासंगिक है, हालांकि यदि आप 3 के माध्यम से कम से कम 1 चरण नहीं करते हैं, तो बिंदु 4 और बिंदु 5 पर विचार करना आपकी बहुत मदद करने वाला नहीं है, क्योंकि आपकी प्रणाली काफी मौलिक स्तर पर सुरक्षित नहीं है।


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

"यह सिस्टम सुरक्षा बनाम सुविधा के मूल प्रश्न को उबालता है" - मेरे जवाब से उद्धृत - जो आपकी टिप्पणी पर समान रूप से लागू होता है। आप एक ही समय में सुरक्षा और सुविधा को अधिकतम नहीं कर सकते ।
allquixotic

1
# 1 इस मामले में महत्वपूर्ण है कि रैम का कुछ हिस्सा डिस्क (स्वैपिंग) को हिट करता है या यदि यह एक ssd सेक्टर को हिट करता है जो बाद में "खराब" हो जाता है और ओएस से दूर चला जाता है लेकिन फिर भी राम के उस टुकड़े को रखता है। यहां तक ​​कि जब डिस्क को वर्तमान में अनलॉक किया जाता है, तो डेटा का हिस्सा प्लॉट पर हाथापाई करता है।
अकीरा २

3

एक पर्यावरण चर में एक पासवर्ड पास करना उतना ही सुरक्षित है जितना कि प्रोग्राम को फ़ाइल से पढ़ना। केवल उसी उपयोगकर्ता के रूप में चलने वाली प्रक्रियाएं किसी प्रक्रिया के वातावरण को पढ़ सकती हैं , और इन प्रक्रियाओं को वैसे ही फ़ाइलों को पढ़ने की अनुमति है।

ध्यान दें कि यह कमांड लाइन पर एक पासवर्ड पास करने से अलग है। कमांड लाइन के तर्क एक ही मशीन पर चलने वाली सभी प्रक्रियाओं द्वारा पठनीय हैं (सख्त उपायों को छोड़कर), केवल उसी उपयोगकर्ता के रूप में चलने वाली प्रक्रियाएं नहीं।

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

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

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

एक पासवर्ड को एक फाइल में रखा जाना चाहिए जो कॉन्फ़िगरेशन फ़ाइलों से अलग है जो संस्करण नियंत्रण के तहत और सामान्य परिनियोजन तंत्र से हैं। सुविधाजनक होने पर पर्यावरण में पासवर्ड डालना ठीक है, लेकिन यह यथासंभव छोटे कार्यक्रमों के लिए किया जाना चाहिए।

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