एउटा क्लाउड सेवाका लागि नेटिभ TLS, SSH फर्वार्ड वा VPN

प्रश्न विरलै दुई क्लाउड मेसिनबीच केही इन्क्रिप्ट गर्ने हो कि भन्ने हुन्छ; प्रश्न तपाईं कुन इन्टरफेस इन्क्रिप्ट गर्दै हुनुहुन्छ र कसले कसको पहिचान जाँच्छ भन्ने हो। म यी कुराकानी नेटवर्क रेखाचित्रबाट नभई सेवाबाट सुरु गर्छु, किनकि सेवालाई पहिले नै थाहा छ उसलाई के चाहिन्छ। तीन सीमाले अधिकांश अवस्था ढाक्छन्: एपको आफ्नै TLS, SSH मार्फत फर्वार्ड गरिएको एउटा TCP पोर्ट, र प्रत्येक सहभागीलाई ठेगाना दिने राउटेड ओभरले। तिनीहरू शक्तिको क्रममा होइन, समस्याको कति भाग ढाक्छन् भन्ने क्रममा राखिन्छन्।

नेटवर्कबाट होइन, सेवाबाट सुरु गर्नुहोस्

प्रक्रियाबाट बाहिर जानुहोस्। यो कुन प्रोटोकल बोल्छ, क्लाइन्टले कुन नाम प्रमाणित गर्नेछ, र कसलाई बिल्कुलै जडान खोल्न अनुमति छ? ती तीन उत्तरले कुनै पनि तुलना तालिकाभन्दा छिटो विकल्प हटाउँछन्, र सेवाको आफ्नै कन्फिगरेसनले सामान्यतया केही मिनेटमै तिनको जवाफ दिन्छ।

8443 पोर्टमा पहिले नै HTTPS दिने सानो आन्तरिक API लिनुहोस्, api.internal.example का लागि प्रमाणपत्रसहित। होस्टमा ss -ltnp ले यो केसँग बाँधिएको छ देखाउँछ, र openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ले प्रमाणपत्र क्लाइन्टले वास्तवमै प्रयोग गर्ने नामका लागि मान्य छ कि छैन देखाउँछ। दुवै स्वस्थ भए, सेवाले आफ्नै प्रवाह सुरक्षित गर्न सक्छ र केवल पहुँच बाँकी रहन्छ। यो नेटवर्क बनाउनुभन्दा धेरै सानो समस्या हो।

चरण 1: के सेवा आफैंको रक्षा गर्छ?

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

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

चरण 2: के एउटा TCP पोर्ट नै सम्पूर्ण आवश्यकता हो?

जब आवश्यकता साँच्चै एउटा TCP पोर्ट हो, फर्वार्ड काम गर्ने सबैभन्दा सानो कुरा हो। SSH स्थानीय फर्वार्डले त्यो पोर्ट पहिले नै अवस्थित प्रमाणित जडानमार्फत लैजान्छ।

आकार ssh -N -L 8443:127.0.0.1:8443 [email protected] हो, र महत्त्वपूर्ण विवरण लक्ष्य ठेगाना हो: 127.0.0.1 टाढाको पक्षमा समाधान हुन्छ, त्यसैले सेवासँगको जडान तपाईंको ल्यापटपबाट नभई बास्टियनबाट खुल्छ। स्थानीय श्रोतालाई -L 127.0.0.1:8443:... जसरी साँघुरो रूपमा बाँध्नुहोस् ताकि तपाईंले दुर्घटनावश सेवा आफ्नै स्थानीय नेटवर्कमा प्रकाशित नगर्नुहोस्। सर्भर पक्षमा, क्लाइन्टको असल व्यवहारमा भर पर्नुभन्दा खाताले के फर्वार्ड गर्न सक्छ सीमित गर्नुहोस्। PermitOpen, AllowTcpForwarding local र GatewayPorts no पूर्वनिर्धारित ती तीन सेटिङ हुन् जसले सामान्य रिलेलाई विशिष्ट च्यानलमा बदल्छन्।

सम्झौता दुवै दिशामा साँघुरो छ। SSH ले आफ्नै च्यानलको रक्षा गर्छ, र बास्टियनबाट अर्को एपसम्मको अर्को हपलाई आफ्नै सुरक्षा चाहिन्छ। केवल बास्टियनको loopback मा सुन्ने सेवाको जोखिम अर्को नेटवर्कबाट पुग्ने सेवाभन्दा पूर्ण रूपमा फरक हुन्छ, र फर्वार्डले त्यो बदल्दैन। सुरुङलाई तिनको विकल्प ठान्नुभन्दा एपको प्रमाणीकरण र TLS जाँच कायम राख्नुहोस्।

एउटै मालिकको एउटा जडानका लागि यो राम्रोसँग काम गर्छ। ठूलो मापनमा यो प्रणाली बन्छ: स्थानीय पोर्ट द्वन्द्व, सुपरिवेक्षण, कुञ्जी घुमाउने र रिबुटपछि फर्वार्ड कसले पुनः सुरु गर्छ भन्ने प्रश्न।

चरण 3: के राउटिङ नै वास्तविक आवश्यकता हो?

त्यो सूची सबैभन्दा सानो विकल्पको इमानदार मूल्य हो, र त्यसैले टोलीले अन्ततः बिर्सिएका केही पृष्ठभूमि आदेशलाई व्यवस्थापित कुराले बदल्छन्। प्रतिस्थापन आफैंमा VPN होइन। यदि आवश्यकता अझै एउटा TCP पोर्ट हो, कागजात गरिएको मालिकसहितको सुपरिवेक्षित फर्वार्ड ओभरलेभन्दा सस्तो चल्छ र तपाईंले देख्न सक्ने तरिकाले असफल हुन्छ। सौन्दर्य माप्नुअघि परिचालन स्वामित्व माप्नुहोस्।

राउटिङ नै आवश्यकता हुँदा राउटिङ सही उत्तर बन्छ। सामान्य IP जडान चाहिने धेरै एप, TCP फर्वार्डले बोक्न नसक्ने प्रोटोकल, वा होस्टबीच सर्ने सेवाहरू — सबै एउटै दिशा देखाउँछन्।

ओभरलेले सहभागीलाई ठेगाना र मार्ग दिन्छ, त्यसपछि वास्तविक काम सुरु हुन्छ: नओभरल्याप हुने दायरा, मार्ग स्वामित्व, DNS, दर्ता, रद्द र साथी हराउँदा के हुन्छ। यीमध्ये केही पनि ठेगानासँगै आउँदैन। ओभरलेमा स्वीकारिएको साथी पनि गन्तव्यमा हरेक कार्यका लागि स्वतः अधिकृत हुँदैन, त्यसैले सेवा-स्तरीय प्रमाणीकरण रहन्छ।

त्यसपछि तपाईंसँग के छ

तपाईंले छोड्ने अभिलेखमा दुई कुरा पर्छन्। पहिलो क्लाइन्टले प्रमाणित गर्नुपर्ने पहिचान हो, किनकि केही काम गराउन नाम जाँच ढिलो हुनासाथ यी हरेक सीमा चुपचाप बिग्रन्छन्। दोस्रो हटाउने चरण हो: पहुँच सकिँदा कुन कुञ्जी, कुन नियम वा कुन मार्ग हराउँछ, र त्यो कसले गर्छ।

यो यात्रा जहाँ सुरु भयो त्यहीँ, सेवामा टुंगिन्छ। वास्तविक ट्राफिक ढाक्ने र तपाईंले प्रमाणित गर्न खोज्नुभएका साथीलाई प्रमाणित गर्ने सीमा छान्नुहोस्, त्यसपछि पहुँच कसरी अद्यावधिक, अनुगमन र हटाइन्छ लेख्नुहोस्। OpenSSH सन्दर्भ साँघुरो सम्झौताको वाचा गर्नुअघि फर्वार्डिङ विकल्प पुष्टि गर्ने ठाउँ हो। यदि तपाईं हटाउने चरण एक वाक्यमा वर्णन गर्न सक्नुहुन्न भने, सीमा समस्याभन्दा ठूलो छ।