एक आवेदन के लिए आवश्यक क्रेडेंशियल्स कैसे स्टोर करें?


13

हर कोई कह रहा है कि संस्करण नियंत्रण (git) में क्रेडेंशियल्स को स्टोर करना एक बुरी बात है। इसलिए क्रेडेंशियल्स को स्टोर करने के अन्य तरीके होने चाहिए जो बहुत बेहतर हैं।

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

एप्लिकेशन की क्रेडेंशियल्स कैसे प्रबंधित करें?


4
इसके अलावा यह शायद एक उत्तर के लिए बहुत व्यापक है जो एक पुस्तक का आकार नहीं है।
कोडरंगर

1
@ कोडरंगर अपनी प्रस्तुति को देखते हुए, विभिन्न प्रकार के रहस्यों का आपका वर्गीकरण महान है। और मैं देख सकता हूं कि आप इसकी किताब को कैसे सोचते हैं ... लेकिन ऊपर दिए गए सवाल एक वर्गीकरण के लिए नहीं पूछते हैं, केवल एक समस्या के लिए एक समाधान (एस)।
एवगेनी

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

1
यह बहुत व्यापक है। ऐसा करने के लिए कम से कम 14 टूल उपलब्ध हैं, जिसमें कस्टम स्क्रिप्टिंग या टेम्प्लेट शामिल नहीं हैं: gist.github.com/maxvt/bb49a6c7243163b8120625fc8ae3f3cd अतिरिक्त विवरण की आवश्यकता है (जैसे कि एक CLI आवश्यक है, यह क्लाउड-देशी समाधान के लिए या बड़े के लिए है) अखंड अनुप्रयोगों, आदि)
अलेक्जेंड्रे

जवाबों:


5

एक आवेदन के रहस्यों का उचित प्रबंधन हमेशा एक चुनौती रहा है। बादल को अपनाने के साथ नई चुनौतियां आईं। क्लाउड में रहस्यों को संग्रहीत करने की वास्तविकता और चुनौतियों के बारे में एक महान OWASP प्रस्तुति है

आपको यह सुनकर आश्चर्य हो सकता है कि स्रोत कोड में रहस्यों को संग्रहीत करना समाधान (या "वास्तुकला") में से एक है। ऐसा इसलिए, क्योंकि अभी, इसके लिए कोई सही वास्तुकला या तरीका नहीं है। अंत में, आपके रहस्यों को एन्क्रिप्ट किया जा सकता है ... लेकिन एन्क्रिप्शन कुंजी की रखवाली क्या है? "सभी तरह से नीचे कछुए", उन्होंने कहा।

प्रत्येक प्रकार के गुप्त प्रबंधन की अपनी ताकत और कमजोरियां हैं और प्रस्तुति पहले से ही कवर करती है। इसके बजाय, मैं उन कुछ विशेषताओं पर जाने की कोशिश करूँगा जिन्हें आप गुप्त (क्रेडेंशियल) प्रबंधन समाधान में देख सकते हैं:

  • अभिगम नियंत्रण: क्या आप प्रवेशों को लिखित पहुँच दे सकते हैं और अनुप्रयोगों तक पहुँच पढ़ सकते हैं? क्या आप पढ़ सकते हैं कि कौन से एप्लिकेशन पढ़ने में सक्षम हैं (एप्लिकेशन ए की केवल उन रहस्यों तक पहुंच है)?
  • ऑडिट लॉग: कई अनुपालन रिपोर्टों के लिए आवश्यक है और अगर कुछ गड़बड़ है तो यह पता लगाने का एक अच्छा तरीका है
  • रहस्यों का सुरक्षित भंडारण: कैसे समाधान रहस्य संग्रहीत है? एन्क्रिप्ट किया गया DB? एन्क्रिप्टेड FS? एन्क्रिप्शन कुंजी कौन / क्या, यदि कोई है? इस कुंजी का उपयोग कैसे किया जाता है - एक बार स्टार्टअप पर और फिर सुरक्षित रूप से त्याग दिया गया?
  • कुंजी / पासवर्ड रोटेशन या नवीनीकरण: यदि किसी रहस्य से छेड़छाड़ की जाती है, तो क्या आप इसे रद्द कर सकते हैं और अनुप्रयोगों को एक अद्यतन रहस्य भेज सकते हैं? क्या एप्लिकेशन को गुप्त प्रबंधन सेवा को पूल करना चाहिए?
  • संगतता: इनमें से कुछ समाधान कुछ भाषाओं या ढांचे के साथ तंग एकीकरण प्रदान करते हैं। कुछ REST API प्रदान करते हैं। क्या आप इसमें रुचि रखते हैं?

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


3

विशुद्ध रूप से EC2- आधारित वातावरण के लिए, सबसे आसान उपाय AWS IAM भूमिकाओं और S3 बाल्टी नीतियों का उपयोग करना है। इस पैटर्न के कुछ योगों में भंडारण के लिए S3 के बजाय एन्क्रिप्शन और DynamoDB के लिए KMS शामिल हैं, लेकिन मुझे या तो उपयोग करने के लिए बहुत ही आकर्षक कारण नहीं मिला है। की जाँच करें https://github.com/poise/citadel , यह विशेष रूप से बावर्ची उपयोगकर्ताओं के उद्देश्य से है, लेकिन अंतर्निहित पैटर्न कुछ भी के लिए काम करता है, तो आप सिर्फ S3 से वास्तविक डाउनलोड करने के लिए अपने स्वयं के सहायक बनाने के लिए हो सकता है।


1
भविष्य के लिए, यह प्रश्न के पहले और अधिक विशिष्ट संस्करण का जवाब देता है।
कोडरंग

2
AWS अब केएमएस के माध्यम से एन्क्रिप्शन सहित कुंजी-मूल्य भंडारण के लिए एक समर्पित सेवा प्रदान करता है: aws.amazon.com/ec2/systems-manager/parameter-store
bnzmnzhnz
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.