2008-08-14 16 views
8

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

क्या

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

दोनों विंडोज़ और लिनक्स समाधान की सराहना की!

उत्तर

10

अपना पासवर्ड सुरक्षित करने का सबसे अच्छा तरीका एक का उपयोग करना बंद करना है। एक विश्वसनीय कनेक्शन का उपयोग करें: How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0। फिर आपके पास छिपाने के लिए कुछ भी नहीं है - अपने web.config और दुनिया को स्रोत प्रकाशित करें, फिर भी वे आपके डेटाबेस को हिट नहीं कर सकते हैं।

यदि यह आपके लिए काम नहीं करेगा, तो configuration encryption system in ASP.NET में निर्मित का उपयोग करें।

1

सादा पाठ? अगर वे आपके सर्वर पर हैं, तो मुझे उम्मीद है कि सर्वर सुरक्षित है ताकि अनधिकृत पहुंच की अनुमति न दी जा सके। अगर लोग सर्वर पर आपकी कॉन्फ़िगरेशन फ़ाइलों तक पहुंच सकते हैं, तो कुछ पहले गलत हो गया है।

+0

इस रणनीति के बाद गहराई से रक्षा बनाने का अवसर खो जाएगा। –

1

स्पष्टीकरण: सुरक्षा, रख-रखाव (जैसे लॉगिन बदलने की जरूरत है, मैं इसे बाद में पा सकते हैं, आदि) के मामले में

@lomax: शायद मैं शारीरिक सर्वर के उपयोग के साथ हर किसी को नहीं चाहते हो सकता है (उदाहरण के लिए sysadmins) पासवर्ड देखने के लिए।

धन्यवाद!

0

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

हालांकि, यह वास्तव में obfuscation से कहीं अधिक नहीं है, क्योंकि आपका कोड कहीं भी कुछ स्रोत भंडार में संग्रहीत होने की संभावना है।

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

आप आईपी द्वारा केवल अपनी वेब ऐप मशीनों से कनेक्शन स्वीकार करने के लिए डेटाबेस सर्वर को लॉक कर सकते हैं।

आखिरकार, आपकी समस्या यह है कि कुंजी (आपके डीबी उपयोगकर्ता नाम/पासवर्ड जोड़ी) को आपके वेब ऐप्स द्वारा प्रोग्रामेटिक, अप्रयुक्त उपयोग के लिए उपलब्ध होना आवश्यक है।

3

मैं लोमैक्सक्स से सहमत हूं: यदि कोई पहले से ही सर्वर पर है या इसके पास व्यापक पहुंच है (एक sysadmin की तरह), गेम काफी अधिक है। तो विचार उस सर्वर का उपयोग करना होगा जिस पर आप भरोसा करते हैं कि यह उस डिग्री के लिए सुरक्षित है जिसे आप चाहते हैं। विशेष रूप से:

  • आप sysadmins पर भरोसा करने की जरूरत है
  • आप एक ही सर्वर पर किसी और जो चल रहा है कोड पर भरोसा करने की जरूरत है (यही कारण है कि साझा होस्टिंग एक बड़ा है नहीं-नहीं मेरे लिए)

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

+0

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

1

ज्यादातर मामलों में, मेरा मानना ​​है कि यह एक सादे पाठ फ़ाइल में पासवर्ड को खराब करने के लिए पर्याप्त है (उदाहरण के लिए।बेस 64 के साथ)। आप रूट एक्सेस के साथ एक निर्धारित sysadmin के खिलाफ संग्रहीत पासवर्ड को पूरी तरह से सुरक्षित नहीं कर सकते हैं, इसलिए वास्तव में कोशिश करने की कोई आवश्यकता नहीं है। सरल obfuscation, हालांकि, एक कंधे surfer के लिए पासवर्ड गलती से खुलासा के खिलाफ की रक्षा करता है।

एक अधिक जटिल विकल्प एक समर्पित सुरक्षित पासवर्ड सर्वर है कि या तो स्थापित करने के लिए है:

  • एक पासवर्ड डिक्रिप्शन सेवा
  • वास्तव में अन्य कम सुरक्षित सर्वर द्वारा उपयोग के लिए पासवर्ड संग्रहीत करता है प्रदान करता है

उपयोग किए गए नेटवर्क प्रोटोकॉल के आधार पर, यह tcpdump के साथ एक दुष्ट sysadmin के खिलाफ सुरक्षा नहीं कर सकता है। और यह शायद एक डीबगर के साथ एक निर्धारित sysadmin के खिलाफ रक्षा नहीं करेगा, या तो। उस समय, यह केर्बेरोज टिकट जैसे कुछ देखने का समय हो सकता है।

5

PostgreSQL उनके दस्तावेज़ में इस तरह की स्थिति के लिए nice solution प्रदान करता है। अनिवार्य रूप से, आप रिमोट मशीन पर PostgreSQL सर्वर पोर्ट पर अपनी मशीन पर एक पोर्ट को पुल करने के लिए एसएसएच का उपयोग करते हैं। इसमें प्रमाणीकरण के तीन चरण हैं:

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

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

संपादित करें: मुझे यह जोड़ना चाहिए कि यह किसी भी डेटाबेस के साथ काम करेगा जो एक टीसीपी/आईपी पोर्ट को सुनता है। यह PostgreSQL में वर्णित होता है। और आप पोर्ट प्रतिबंधों को करने के लिए iptables (या लिनक्स के बराबर) चाहते हैं। this देखें।

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

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