एक क्लाउड सेवा के लिए नेटिव 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 संदर्भ संकीर्ण अनुबंध का वादा करने से पहले फ़ॉरवर्डिंग विकल्पों की पुष्टि करने की जगह है। अगर आप हटाने के चरण को एक वाक्य में नहीं बता सकते, तो सीमा समस्या से बड़ी है।