VPN पर Cassandra: क्लाइंट और नोड के लिए अलग पहुँच

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

तीनों समूहों में से हर एक को अपना उत्तर मिलता है, और नीचे के अनुभाग उन्हें जोखिम के क्रम में लेते हैं।

तीन समूह, तीन निर्णय

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

आम गलती एक सपाट निजी खंड बनाकर यह मान लेना है कि VPN सीमा बाकी काम कर देगी। इसके भीतर, क्लाइंट पोर्ट तक पहुँचने वाला एप्लिकेशन आमतौर पर अंतर-नोड पोर्ट तक भी पहुँच जाता है, और ऑपरेटर के प्रशासनिक उपकरण अक्सर एप्लिकेशन के उसी जंप होस्ट पर बैठते हैं। इन सबको एक साथ सपाट करने का अर्थ है कि एक समझौता-ग्रस्त एप्लिकेशन पहचान के पास पहले से ही अपनी क्वेरी से अधिक पहुँच है। डिज़ाइन दस्तावेज़ में तीन समूहों को तीन पंक्तियों के रूप में बनाएं, हर एक के साथ वह नियम जो उसे अनुमति देता है, और खाली जगहें किसी के उन्हें बनाने से पहले दिखाई देंगी।

क्लाइंट को क्या चाहिए, और उससे अधिक कुछ नहीं

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

इसीलिए एक निजी पते की असंगति परिचित पैटर्न बनाती है: सफल पहला कनेक्शन और फिर समयबाह्य। घोषित पतों और क्लाइंट रूटिंग को जानबूझकर कॉन्फ़िगर करें; एक असंगति सुधारने के लिए पूरे क्लस्टर को इंटरनेट पर प्रकाशित करना रूटिंग बग के बदले ऐसा प्रदर्शन देता है जिसे वापस नहीं लिया जा सकता।

एप्लिकेशन का डेटाबेस प्रमाणीकरण और भूमिका अनुमतियाँ भी यथास्थान रखें। साझा अनूदित VPN पता कई उपयोगकर्ताओं या सेवाओं का प्रतिनिधित्व कर सकता है, इसलिए यह कभी भी अलग डेटाबेस पहचान का विकल्प नहीं है।

क्लाइंट-से-नोड और अंतर-नोड अलग-अलग एन्क्रिप्ट करें

Apache का सुरक्षा दस्तावेज़ क्लाइंट-से-नोड और अंतर-नोड एन्क्रिप्शन को अलग कॉन्फ़िगरेशन मानता है, और एक सक्षम करने से दूसरा सक्षम नहीं होता। यह अंतर VPN के भीतर भी लागू होता है, क्योंकि टनल अपने ही खंड की रक्षा करती है और एप्लिकेशन प्रक्रिया से डेटाबेस प्रक्रिया तक या क्लस्टर सदस्यों के हर जोड़े के बीच स्वतः विस्तारित नहीं होती।

जो कॉन्फ़िगरेशन टेम्पलेट के डिफ़ॉल्ट को विरासत में लेने के बजाय दोनों को स्पष्ट रूप से चालू करता है, वह लगभग ऐसा दिखता है:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

जिन सर्वर कॉन्फ़िगरेशन में वैकल्पिक क्लाइंट एन्क्रिप्शन की अनुमति है, वहाँ TLS स्वीकार करना बिना एन्क्रिप्शन वाले कनेक्शन स्वीकार करने के साथ सह-अस्तित्व में रह सकता है, इसलिए इरादा नहीं, प्रभावी नीति पढ़ें। उन एंडपॉइंट के लिए प्रमाणपत्र नाम, विश्वास वितरण और नवीनीकरण की योजना बनाएं जिनसे हर क्लाइंट वास्तव में संपर्क करता है; होस्टनाम को IP पते से बदलना क्लाइंट की पहचान जाँच बदलता है, केवल उसका रूट नहीं।

प्रशासन को अपने अलग पथ पर रखें

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

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

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

डिज़ाइन क्या वादा करता है

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

डिज़ाइन दस्तावेज़ में तीन वाक्यों के साथ समाप्त करें: कौन से क्लाइंट क्वेरी कर सकते हैं, कौन से नोड संवाद कर सकते हैं और कौन से ऑपरेटर प्रशासन कर सकते हैं। VPN के पीछे होना उपयोगी टोपोलॉजी जानकारी है, लेकिन यह उन तीन प्रश्नों में से किसी का उत्तर नहीं है।