2012-12-21 10 views
15

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

संपादित करें:

मुझे बनाने के लिए संदर्भ स्पष्ट करने देते हैं सवाल कम व्यापक:

  1. यहाँ एक जावा वेब अनुप्रयोग संबोधित किया जाता है
  2. अधिक विशेष रूप से यह वसंत ढांचा संस्करण 3 प्रयोग किया जाता है
  3. वसंत सुरक्षा 3.1 एप्लिकेशन को सुरक्षित करने के लिए उपयोग किया जाता है
  4. एक mysql5 डेटाबेस उपलब्ध है
  5. आवेदन सर्वर tomcat6 या tomcat7
  6. सर्वर मशीन मेरे नियंत्रण में नहीं

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

यहां, मुझे एक ईमेल पासवर्ड सुरक्षित करना होगा (जिसे एक डीबी में संग्रहीत किया जाएगा)। मैं इस जानकारी को औसत महत्वपूर्ण मानता हूं।

जो मैं यहां देख रहा हूं, वह उचित प्रयास के साथ सबसे अच्छा समाधान है।

तो सवाल बहुत स्पष्ट है: आप इस जानकारी को कहां स्टोर करेंगे?

  1. क्या आप इसे डेटाबेस में संग्रहीत करते हैं? तो इसे एन्क्रिप्ट किया जाना चाहिए और इसके लिए एक और कुंजी की आवश्यकता है (और आप इस दूसरी कुंजी को कहां स्टोर करते हैं?)
  2. क्या आप इसे .war पैकेज में संग्रहीत करते हैं? आप स्रोतों पर अनधिकृत पहुंच को कैसे रोकते हैं?
  3. क्या आप एक अलग रणनीति अपनाते हैं?

आपकी रणनीति के लिए प्रेरणा की सराहना की जाएगी। धन्यवाद

+2

यह भी देखें कि "मैं सिस्टम के लिए कुंजी को सुरक्षित रूप से कहां स्टोर करूं जहां स्रोत दिखाई दे रहा है?" http://security.stackexchange.com/questions/5994/where-do-i-securely-store-the-key-for-a-system-where-the- स्रोत-is-visible, और "पासवर्ड के लिए सर्वोत्तम अभ्यास - एक गुप्त कुंजी को संरक्षित करना "http://security.stackexchange.com/questions/20076/best-practice-for-password-protecting-a-secret-key, –

+0

यह उपयोग के मामले और पर्यावरण पर इतना निर्भर करता है कि यह है किसी भी सार्थक तरीके से जवाब देना असंभव है; इसके बजाय कुंजी प्रबंधन पर एक किताब खरीदें। –

उत्तर

10

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

  • डीबी
  • अनुप्रयोग ("हार्डकोडेड")
  • सर्वर पर कहीं और, कि चलाता है:

    मूल रूप से वहाँ कुंजी भंडारण के लिए 3 उम्मीदवारों, पहले 2 जिनमें से आप का उल्लेख कर रहे हैं वेब ऐप, अक्सर एक फ़ाइल

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

यह तीसरे उम्मीदवार का उपयोग करने के लिए भी मेरे लिए प्रेरणा है।

  • उसी ऐप्लिकेशन के विभिन्न उदाहरणों आसानी से विभिन्न कुंजी है, तो एक के एक समझौता स्वचालित रूप से सभी दूसरों
  • करने के लिए सर्वर एक तरह से समझौता किया है, तो प्रसारित नहीं कर पाएगा हो सकता है, कि अनुमति देता है: तर्क यह है किसी भी फाइल को पढ़ने के लिए हमलावर, यह किसी भी तरह से गेम है: आप उसे ऐप बाइनरी या डीबी
  • वेब सर्वर पर फ़ाइल सिस्टम सुरक्षा एक अच्छी तरह से समझी गई विषय
  • ब्रेक पढ़ने से रोकने में सक्षम नहीं होंगे -इन्स, जो पूर्ण फाइल सिस्टम एक्सेस को सांख्यिकीय रूप से बहुत कम अक्सर उपयोग करते हैं, एप्लिकेशन या डेटाबेस ब्रेक-इन्स
+0

ठीक है, तो आप सर्वर मशीन की फ़ाइल सिस्टम में फ़ाइल बनाने के लिए कहते हैं और सादा पाठ में पासवर्ड लिखने के लिए। बेशक, मुझे उस फ़ाइल पर सख्त अनुमति स्थापित करनी है (उदाहरण के लिए केवल "एप्लिकेशन-उपयोगकर्ता" इसे पढ़ सकता है)। एक सामान्य परिदृश्य वह है जिसमें सर्वर मशीन आपके नियंत्रण में नहीं है। व्यवस्थापक उपयोगकर्ता वैसे भी सब कुछ कर सकता है। शायद कुंजी के साथ फ़ाइल क्लाइंट साइड कुंजी के साथ एन्क्रिप्ट किया जा सकता है। लेकिन यह एक और जटिल वास्तुकला का संकेत देगा जो हमेशा उपलब्ध नहीं है। ठीक है, हम प्रदाता पर भरोसा नहीं कर सकते हैं। – MaVVamaldo

+1

कुंजी को किसी फ़ाइल में डालना (या एक कंटेनर जैसा कि @AleksanderGralak द्वारा सुझाया गया था) बिना किसी अतिरिक्त कदम के किया जा सकता है, जैसे हार्डकोडेड कुंजी के साथ कुंजी एन्क्रिप्ट करना। एक दुष्ट व्यवस्थापक एक सफल रूट-स्तरीय हमलावर जैसा ही है: कुछ भी सुरक्षित नहीं है –

+0

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

7

कोई फर्क नहीं पड़ता कि आपको कहीं भी गुप्त कुंजी को स्टोर करने की आवश्यकता है। यहां तक ​​कि यदि आप तय करते हैं (जो मूर्खतापूर्ण है) कि आप मैन्युअल रूप से कुंजी प्रदान करते हैं, तो कुंजी स्मृति में रहती है और कोई इसे ढूंढ सकता है।

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

मैं कंटेनर में द्वितीयक कुंजी स्टोर करने के लिए एप्लिकेशन कॉन्फ़िगरेशन के लिए जाऊंगा। इस तरह केवल आपके आवेदन के पास इस गुणों तक पहुंच होगी। तो उस कुंजी तक पहुंच प्राप्त करने के लिए हमलावर को आपके आवेदन या कंटेनर पर नियंत्रण रखना होगा।

तो निम्न परिदृश्यों संभालने:

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

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

आपके पास जितने अधिक ताले हैं उतने अधिक सुरक्षित हैं। जैसा कि यह मानक दरवाजा ताला के साथ है। ताले विभिन्न विक्रेताओं और विभिन्न तंत्रों से होना चाहिए। लेकिन अंत में कुशल burglar वैसे भी मिल जाएगा।

+0

@ एलेक्ससेंडर: क्या आपके पास कोई ट्यूटोरियल है कि हम इसे जावा में कैसे कार्यान्वित कर सकते हैं? कंटेनर में दूसरी कुंजी कैसे स्टोर करें और कैसे दोनों सेकेंडरी और प्रोमरी कुंजी डीबी में डेटा एन्क्रिप्ट कर सकते हैं। – anand

+0

जावा में विभिन्न उपयोगकर्ताओं के लिए फ़ाइलों की फाइल सिस्टम अनुमतियों को हम कैसे प्रतिबंधित कर सकते हैं? – anand

+0

@ एलियन 01 बस स्पष्ट करने के लिए। पूरे डेटाबेस को एन्क्रिप्ट करना इस मुद्दे के दायरे से बाहर है और जहां तक ​​मुझे पता है कि यह अधिक प्रयोगात्मक विचार है तो वास्तविक चीज़। तो हमारी स्थिति में एक रहस्य ईमेल के लिए एक पासवर्ड है। तो आप अनुप्रयोग संदर्भ में एन्क्रिप्शन कुंजी स्टोर करते हैं: http://stackoverflow.com/questions/372686/how-can-i-specify-system-properties-in-tomcat-configuration-on-startup तब आप सममित एन्क्रिप्शन का उपयोग करते हैं पासवर्ड एन्क्रिप्ट करें। अब आप डीबी से पासवर्ड पुनर्प्राप्त कर सकते हैं और इसे डिक्रिप्ट कर सकते हैं और एसएमटीपी सर्वर तक पहुंचने के लिए उपयोग कर सकते हैं। –

0

फाइल सिस्टम ठीक है, उपयोगकर्ता अनुमतियां चुनें और युद्ध पर अनुदान अनुमति का उपयोग करें।वहां बहुत से सुरक्षा छेद थे जो केवल डेटाबेस या युद्ध सामग्री तक पहुंच खोलते हैं

संबंधित मुद्दे