एक बाकी सेवा के रूप में CouchDB पहुंच असुरक्षित लगता है। कोई भी डेटाबेस को हिट कर सकता है और इसे प्रकट होने के बाद दस्तावेजों को हटा/जोड़ सकता है।कैसे CouchDB सुरक्षित करने के लिए
कॉच डीबी को सुरक्षित करने के लिए क्या रणनीतियां हैं?
क्या आपने कॉच डीबी दस्तावेज http://couchdb.apache.org/docs/overview.html पढ़ा है? इसमें एक "सुरक्षा और सत्यापन" अनुभाग है जो आपकी कुछ चिंताओं को संबोधित करता है।
हाँ, मैंने पैराग्राफ पढ़ा है। रीडर सूचियों के बारे में बात करते हैं, और कहते हैं कि एक सुरक्षा मॉडल है, मैं पाठकों की सूची में जोड़ने के लिए कैसे, उदाहरण, एपीआई जैसे विशिष्टताओं की तलाश कर रहा हूं, – steveolyo
आपको लगता है कि आपने कुछ शोध किया है । यह सुनिश्चित नहीं है कि इससे मदद मिलेगी: http://books.couchdb.org/relax/reference/security, यदि आपने नहीं किया है तो इसे एक नज़र दें। –
इसमें कुछ अच्छी जानकारी है, अभी भी काम की ज़रूरत है। मुझे एहसास है कि couchdb अभी भी अपने बचपन में है। शायद पठन सूचियां अभी तक लागू नहीं की गई हैं। – steveolyo
एकमात्र चीज जो वास्तव में सुरक्षा के अनुसार काम करती है वह आपके सोफेडीबी कॉन्फ़िगरेशन में ऐसा कुछ है।
[couch_httpd_auth]
require_valid_user=true
[admins]
admin = sekrit
यह सभी कोच डीबी पर मूल HTTP लेख डालता है। यहां तक कि यह क्लाइंट पुस्तकालयों में भी अच्छा समर्थन नहीं है। पायथन के लिए उदा। आपको a patched library की आवश्यकता है।
दूसरा दृष्टिकोण कॉच डीबी के सामने प्रॉक्सी डालना है और प्रॉक्सी प्रमाणीकरण और प्रमाणीकरण कार्य करने दें। कॉच डीबी के रीस्टफुल डिजाइन के कारण यह काफी आसान है।
अन्य सभी दृष्टिकोणों को अब अत्यधिक प्रयोगात्मक माना जाना चाहिए।
सोफे के सामने एक प्रॉक्सी डालना एक अच्छा विचार है, लेकिन कुछ ओवरहेड जोड़ता है। मुझे वर्तमान में प्रॉक्सी के रूप में अपाचे है। मुझे लगता है कि मैं फिर से बदल दूंगा स्टैक ओवरफ्लो – steveolyo
यह आपके मूल प्रश्न से थोड़ा अलग हो सकता है। यदि आपका कॉचडब एक पूर्ण सर्वर ऐप के लिए केवल बैक-एंड स्टोर है, तो आप सर्वर ऐप का उपयोग करने के लिए एक विशेष खाता बना सकते हैं और couchdb तक पहुंच के लिए उन प्रमाणपत्रों की आवश्यकता होती है।
दूसरी तरफ, एक शुद्ध सोफे ऐप जिसे लोग सीधे जावास्क्रिप्ट क्लाइंट के माध्यम से हिट करते हैं, सुरक्षित होने की बहुत सारी देखभाल की आवश्यकता होती है।
पुनर्लेखन का उपयोग वैकल्पिक नहीं है। आपको एक vhosts कॉन्फ़िगरेशन की आवश्यकता है जो आपके डोमेन को आपके पुनर्लेखन के माध्यम से अनुरोधों को मजबूर करता है।
मार्गों को पुनर्निर्मित करें */_ all_docs और/*/_ design/* 404 पृष्ठ पर। अन्यथा उपयोगकर्ता प्रत्येक दस्तावेज़ को सूचीबद्ध कर सकते हैं या अपना पूरा ऐप प्राप्त कर सकते हैं।
जेनेरिक ऑब्जेक्ट एक्सेस, यानी/dbname /: आईडी को एक शो में लिखें जो उपयोगकर्ता को दस्तावेज़ देखने की अनुमति नहीं है, तो पहुंच से इनकार कर सकते हैं। दुर्भाग्यवश अनुलग्नकों के दस्तावेज़-आधारित पहुंच नियंत्रण के लिए कोई समकक्ष कामकाज नहीं है।
हमने _users पर GET अनुरोधों को फ़िल्टर करने के लिए हैप्रोक्सी का उपयोग किया। उपयोगकर्ता के रिकॉर्ड प्राप्त करने या अपने सभी उपयोगकर्ताओं को सूचीबद्ध करने के लिए बाहर से किसी के लिए कोई कानूनी कारण नहीं है। हम चाहते हैं कि उपयोगकर्ता पंजीकरण कर सकें ताकि हमें लेखन पहुंच की आवश्यकता हो। वर्तमान में सोफे एक डीबी तक पढ़ने की पहुंच को अवरुद्ध नहीं कर सकता है और साथ ही लिखने की अनुमति देता है। यह एक बग है। हैप्रोक्सी जैसी चीज़ों के साथ फ़िल्टरिंग अब हमारे लिए सबसे अच्छा कामकाज है।
_users द्वारा प्रदान की जाने वाली चीज़ों के अतिरिक्त संपर्क जानकारी रखने के लिए अपने स्वयं के डेटाबेस का उपयोग करें। यह पहुंच पर अधिक नियंत्रण की अनुमति देता है।
validate_doc_update को किसी भी ऐसे लेखन को ध्यान से अस्वीकार कर देना चाहिए जिसकी अनुमति नहीं दी जानी चाहिए।
हर मामले में आपको कल्पना करने की आवश्यकता है कि सिस्टम को समझने वाला कोई भी व्यक्ति इसे बदलने और हमले के उन मार्गों को बंद करने के लिए क्या कर सकता है।
200 9 से बहुत कुछ बदल गया है, इसलिए मैं यहां एक जवाब फेंकने जा रहा हूं। यह उत्तर this page on the wiki से खींचा गया है।
CouchDB में _users डेटाबेस है जो उपयोगकर्ताओं को परिभाषित करने के उद्देश्य से कार्य करता है।यहां विकी से सीधे जिस्ट है:
फिर, किसी दिए गए डेटाबेस के लिए आप नाम या भूमिका से अनुमतियां परिभाषित कर सकते हैं। जिस तरह प्रमाणीकरण लागू किया गया है वह _session डेटाबेस के माध्यम से है। _session डीबी को वैध उपयोगकर्ता नाम और पासवर्ड भेजना एक प्रमाणीकरण कुकी देता है। यह कॉच डीबी प्रमाणीकरण के लिए कई विकल्पों में से एक है। कुछ और विकल्प हैं:
इसके अलावा, जो होस्टिंग सेवा आप उपयोग कर रहे हैं पर निर्भर करता है, आप SSL पर सोफे पर पहुंच को प्रतिबंधित करने का विकल्प होगा।
नोड, सोफे और अन्य प्रौद्योगिकियों के बीच प्रभावी रूप से क्षैतिज रूप से स्केल करते हैं (अधिक सर्वर जोड़ते हुए) डेवलपर्स पर एक दिलचस्प प्रकार का दबाव या प्रोत्साहन दिया जाता है ताकि वे इस तरह से अच्छी तरह से स्केल कर सकें। लेकिन यह सब एक साथ एक अलग मुद्दा है।
फरवरी 2013 तक (और कॉच डीबी 1.2) कॉच डीबी का सुरक्षा मॉडल मेरे लिए पर्याप्त लचीला नहीं लगता है। इसके साथ चिपके रहने से बुरा नहीं होगा और यदि आपको सुरक्षा की परवाह नहीं है तो यह आपको बहुत समय बचा सकता है, यदि आप असली दुनिया के उपयोगकर्ताओं के लिए उत्पादन में जा रहे हैं तो यह लागू नहीं है।
बाद के मामले में आपको एक अलग प्रमाणीकरण मिडलवेयर के साथ जाना चाहिए। यह कस्टम प्रमाणीकरण अपेक्षाकृत आसान लागू करने की संभावना देता है। चाहे वह ओथ, कुकीज़ या एसएसएल हो, आप पर पूरा नियंत्रण होगा और तीसरे पक्ष की सेवाओं (या अपने स्वयं के मालिकाना तंत्र) प्रमाणीकरण फिर से अपेक्षाकृत सरल लगता है। सुरक्षा के बारे में बात करते हुए, मुझे डीओएस हमलों की भी परवाह होगी और ऐसा लगता है कि आप कॉच डीबी के माध्यम से कॉच डीबी को अनुरोधों की मात्रा को सीमित नहीं कर पाएंगे।
प्रति-दस्तावेज़ प्राधिकरण के लिए कोई स्पष्ट समर्थन नहीं होने के कारण आपको अपने स्वयं के स्तर की भी आवश्यकता होगी (विवरण के लिए this देखें)। बिल्कुल सही उदाहरण मोबाइल एप्लिकेशन को बहुत से उपयोगकर्ताओं के साथ बनाए रखना है जो एक-दूसरे के बीच डेटा साझा नहीं करते हैं। TouchDB इसके लिए उपयुक्त है, लेकिन फिर आप शायद प्रत्येक उपयोगकर्ता के लिए CouchDB के साथ बैकएंड पर एक अलग डेटाबेस नहीं बनाएंगे, क्योंकि यह पूरी तरह से स्केलेबल नहीं है। एक अलग मिडलवेयर के साथ आप किसी दस्तावेज़ में एक विशेष फ़ील्ड की जांच कर सकते हैं जो उस उपयोगकर्ता को पहचानता है जिस पर यह दस्तावेज़ संबंधित है, या किसी अन्य प्रकार की एसीएल को आप नियोजित करना चाहते हैं।
सुरक्षा समस्याओं को सुलझाने से पहले मैं वास्तविक दुनिया के अनुप्रयोग में किसी भी प्रदर्शन के मुद्दों के बारे में नहीं सोचूंगा। इस प्रकार यूआरएल को फिर से लिखने के लिए nginx को तैनात करना भी सार्वजनिक सर्वर पर फेनेलिस कोच डीबी को तैनात करने से कहीं बेहतर है। और इसके अलावा, nginx के साथ प्रदर्शन हिट नगण्य होगा।
पर एक नए व्यक्ति के रूप में प्रश्न इस जानकारी के टुकड़े के लिए धन्यवाद। क्या आप हमें ब्लॉग पोस्ट या आलेख पर इंगित कर सकते हैं जो इस बीच का वर्णन करेगा गहराई में थोड़ा और दृष्टिकोण दृष्टिकोण? यह वास्तव में इस मुद्दे पर बहुत से लोगों को कुश्ती में मदद करेगा। – psp
CouchDB कुकीज़, एसएसएल, OAuth, और बहु-उपयोगकर्ता करता है ठीक:
from couchdb import Server
s = Server("https://user:[email protected]:6984")
अनुरोध कुकी:
यहाँ अजगर में कुछ वास्तविक कोड है यूआरएल ऊपर इनकोडिंग और नीचे, ज़ाहिर
कीआप _SESSION पोस्ट शरीर
के रूप में दोनों सर्वर() निर्माता में साख दो बार पहले कुकी साथ आरंभ करने के लिए डाल करने के लिए भी हैअब आप एक कुकी प्राप्त हुआ है, यह निकालने
cookie = message["Set-Cookie"].split(";", 1)[0].strip()
अब, बाहर निकलने के अजगर और पुनः आरंभ
इसके बाद, एक सर्वर वस्तु का अनुरोध करें, लेकिन उपयोगकर्ता नाम और पासवर्ड इस बार बिना
s = Server("https://example.com:6984")
s.resource.headers["Cookie"] = cookie
हाँ, कोई पासवर्ड नहीं, डेटाबेस तक पहुंचने का प्रयास करें:
db = s["database"]
वैकल्पिक रूप से कुकी को आखिरी बार बनाने के लिए सर्वर पक्ष पर "लगातार" कुकी विकल्प सेट करें।
इस मुद्दे के लिए कोई अद्यतन? मुझे यकीन है कि 2 साल में बहुत कुछ बदल गया है ... –