EC2 के लिए केवल-VPN नियम: हर जुड़ा सुरक्षा समूह सहमत होना चाहिए

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

नियम लिखने से पहले सेवा लिखें

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

अनुवाद और रूटिंग सामने आते ही ये दोनों पते लोगों की अपेक्षा से अधिक बार अलग हो जाते हैं।

तीन स्रोत मॉडल, तीन अलग नियम

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

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

हर जुड़े समूह में संघ पढ़ें

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

AWS नियम संदर्भ सुरक्षा समूहों को केवल-अनुमति देने वाला बताता है और कहता है कि सभी जुड़े समूहों के नियम एकत्रित होते हैं, और यही इस विफलता के पीछे पूरा तंत्र है।

नेटवर्क ACL एक अलग, स्टेटलेस नीति है जिसमें क्रमबद्ध अनुमति और अस्वीकृति प्रविष्टियाँ होती हैं, और उनका मूल्यांकन इंस्टेंस पर नहीं बल्कि सबनेट पर होता है।

अस्वीकृति की दीवार से उत्तर न दें

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

इंस्टेंस से सार्वजनिक पता हटाना अधिक मजबूत गारंटी है, और यह प्रशासनिक और अनुप्रयोग परिणामों वाला एक आर्किटेक्चरल परिवर्तन भी है, अनुमति सूची पर एक चेकबॉक्स नहीं।

नए सत्र के साथ परीक्षण करें और अंदर आने का रास्ता रखें

किसी भी मौजूदा अनुमति को हटाने से पहले, एक स्वीकृत स्वतंत्र प्रशासनिक पथ की पुष्टि करें, क्योंकि जिस नियम को आप हटाने वाले हैं वही हो सकता है जिस पर आपके सत्र की रिकवरी निर्भर है। फिर VPN से एक नया अनुमत कनेक्शन और स्वीकृत गैर-VPN परीक्षण पथ से एक नया अस्वीकृत कनेक्शन परखें। मौजूदा ट्रैक किए गए सत्र नियम परिवर्तनों को इस तरह सह लेते हैं कि पुराने खुले शेल स्वीकृति के साक्ष्य के रूप में बेकार हो जाते हैं।

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