2011-10-18 18 views
6

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

हम इसे और अधिक सुरक्षित बनाना चाहते हैं। विशेष रूप से हम ऑपरेशन टीम को डेटाबेस कनेक्शन पासवर्ड और अन्य कुंजियों को पढ़ने से रोकना चाहते हैं जो वर्तमान में कॉन्फ़िगरेशन फ़ाइल में हैं।

ध्यान रखने योग्य एक और कारक यह है कि ऑपरेशन टीम आवेदन के निर्माण और तैनाती के लिए ज़िम्मेदार है।

हमारे विकल्प क्या हैं? समाधान को मैन्युअल रूप से पुनरारंभ करने के साथ-साथ ओएस रीबूट होने पर एप्लिकेशन को स्वचालित रूप से प्रारंभ करने का समर्थन करने की आवश्यकता होती है।

अद्यतन

समाधान मैं अब की जांच कर रहा हूँ (उनके सुझाव, जो मोटे तौर चरण 1 में तब्दील हो के लिए अदाम्सकी को टिप):

  1. एक आवरण निष्पादन योग्य है कि एक उपयोगकर्ता के लिए setuid है लिखें जो अनुप्रयोगों को शुरू/बंद करता है और जेबॉस निर्देशिका पेड़ में कॉन्फ़िगरेशन फ़ाइलों और सब कुछ का मालिक है।

  2. निर्माण के बाद WAR पर हस्ताक्षर करने के लिए jarsigner का उपयोग करें। युद्ध की इमारत विकास द्वारा की जाएगी। setuid रैपर हस्ताक्षर की पुष्टि करेगा, यह सत्यापित करता है कि युद्ध को छेड़छाड़ नहीं किया गया है।

  3. केवल हस्ताक्षरित WAR को तैनात करने के लिए तैनाती प्रक्रिया बदलें। setuid रैपर भी JBoss तैनाती निर्देशिका में WAR को स्थानांतरित कर सकता है।

    http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords

    यह कम से कम सुनिश्चित करता है कि आप न सिर्फ सीधे पासवर्ड पढ़ा लेकिन कुछ गंभीर प्रयास करने की जरूरत है सकते हैं:

+0

नोट: किसी भी हस्ताक्षर करने के केवल यदि आप एक वास्तविक प्रमाण पत्र और नहीं एक selfsigned एक का उपयोग समझ में आता है। इसके अतिरिक्त JVM अभी भी छेड़छाड़ की जा सकती है। –

+0

ठीक है, JDK स्थापित है, साथ ही लॉक करने की आवश्यकता होगी विशेष रूप से 'cacerts' dir। – sourcedelica

उत्तर

3

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

कोई कोड आवश्यक नहीं है; अच्छा और सरल

+0

वे एप्लिकेशन कैसे शुरू करते हैं? स्टार्टअप स्क्रिप्ट setuid बनाओ? – sourcedelica

+0

हां, आप इसे इस तरह से कर सकते हैं। – Adamski

+0

मैं नहीं कर सकता स्क्रिप्ट ही setuid (मैं इस प्रतिबंध के बारे में भूल) लेकिन मैं एक आवरण निष्पादन जो स्क्रिप्ट चलाने से लिख सकते हैं, और आवरण setuid बनाते हैं। – sourcedelica

3

आप इसे दिलचस्प देखने के लिए कैसे जेट्टी लोगों को इस समस्या के पास आते हैं मिल सकती है एक मानवीय पठनीय संस्करण प्राप्त करने के लिए।

यदि जेटी लाइसेंस आप जो करना चाहते हैं उसके अनुरूप है, तो आप बस अपना कोड उठा सकते हैं।

+0

आप जेट्टी के लिए उपयोग की आवश्यकता होगी कोड और एन्क्रिप्शन कुंजी, जो दोनों के स्रोत नियंत्रण में होगा डिक्रिप्ट। हम्म .. – sourcedelica

+0

हमें बताएं कि आपको क्या मिल रहा है। याद रखें कि यदि कोई कंप्यूटर इसका उपयोग कर सकता है, तो इसे डीकोड किया जा सकता है। प्रस्तावित दृष्टिकोण के साथ –

+0

अद्यतन प्रश्न। – sourcedelica

0

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

फ़ाइल सिस्टम पर एन्क्रिप्ट किए गए पासवर्ड स्टोर करें। ऐसा करने के लिए आप या तो जावा क्रिप्टोग्राफी या XML encryption का उपयोग कर सकते हैं।ऐसे अन्य विन्यास विवरण के साथ एक डेटाबेस में पासवर्ड के रूप में

या

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

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