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 पछाडि हुनु उपयोगी टोपोलोजी जानकारी हो, तर यो ती तीन प्रश्नमध्ये कुनैको उत्तर होइन।